مرونة في التصميم: كيف يعزز نشر العنقود قابلية التوسع والموثوقية والتعافي للمؤسسات
يبني نشر العنقود (Cluster deployment) نظاماً مرناً عن طريق توزيع أعباء العمل عبر الـ Pods (وحدات منطقية قد تتضمن عدة حاويات) تعمل على عقد (خوادم) مختلفة. يحسن هذا النهج الأداء، ويزيل نقاط الفشل الفردية، ويوفر أساساً للقابلية للتوسع الأفقي. بالنسبة للمؤسسات، تعد العناقيد (Clusters) لبنة بناء رئيسية لحماية العمليات التجارية، وجودة الخدمة، وسمعة العلامة التجارية.
تتناول هذه المقالة عمليات نشر العنقود لـ ONLYOFFICE في بيئات Kubernetes و OpenShift من عدة زوايا: الموثوقية والقابلية للتوسع، واستراتيجية الترقية (بما في ذلك التحديثات بدون وقت توقف)، والمراقبة والشفافية، بالإضافة إلى التحجيم العملي والمتطلبات الفنية.
إذا كنتم مهتمين بتشغيل ONLYOFFICE في ECS أيضاً، فهذا ممكن، ويمكنكم الاتصال بنا لمزيد من المعلومات حول خيار النشر هذا.
نشر العنقود وفوائده
يوفر نشر العنقود بنية قوية، عالية التوافر، قابلة للتوسع، ومتسامحة مع الأخطاء مصممة لتلبية متطلبات بيئات الإنتاج. من خلال توزيع عبء العمل، يضمن التوافر العالي، والاستخدام الأمثل للموارد، وتحسين الأداء. تخفف هذه البنية من نقاط الفشل الفردية، وتدعم التوسع الأفقي، وتعزز موثوقية النظام، مما يجعلها مثالية للتطبيقات الحساسة للمهمة. تجدر الإشارة إلى أنه على الرغم من أنه من الممكن تماماً نشر وصيانة العنقود بأنفسكم، إلا أننا نقترح بشدة استخدام حلول العنقود الخاصة بنا المقدمة كخدمة للحصول على مرونة أفضل وتسامح مع الخطأ جنباً إلى جنب مع التوافر العالي.
يعد نشر العنقود أمراً بالغ الأهمية لبيئات الإنتاج حيث يكون وقت التشغيل أمراً بالغ الأهمية ويسبب التوقف مخاطر تجارية جسيمة. من خلال تشغيل عدة Pods على عدة عقد (nodes) داخل العنقود، يمكن للنظام التعامل بسلاسة مع أي إخفاقات دون مقاطعة تقديم الخدمة.
على سبيل المثال، إذا واجه Pod/عقدة واحدة في العنقود وقت توقف، تتولى الـ Pods/العقد الأخرى عبء العمل، مما يضمن خدمة غير منقطعة للمستخدمين النهائيين. يقلل هذا التصميم من خطر التوقف، والذي يمكن أن يؤدي إلى خسارة الإيرادات، أو الإضرار بالعلامة التجارية، أو ضياع الفرص.
بناء مؤسسات مرنة: مزايا عمليات نشر عنقود Kubernetes/OpenShift التي تقدمها ONLYOFFICE
مع حلول ONLYOFFICE لـ Kubernetes/OpenShift، يمكنكم بناء بنيتكم التحتية الخاصة عالية التوافر، والمتسامحة مع الأخطاء، والقابلة للتوسع والتي ستضمن عدم تأثر تجربتكم في التحرير بأي مشاكل في الأجهزة أو عبء العمل.
إذن، ما هو حل عنقود ONLYOFFICE Kubernetes/OpenShift النموذجي؟ تحديداً، نقوم بتطوير مخططات Helm التي تسمح لكم بنشر حلنا في البيئات المقابلة. بناءً على احتياجاتكم، يمكنكم تخصيص النشر الحالي وتعديله ليتناسب مع متطلباتكم الخاصة باتباع إرشاداتنا والاتصال بنا في حال احتجتم إلى أي توضيحات أو مساعدة إضافية.
على سبيل المثال، تغطي إرشاداتنا الرئيسية لتثبيت Kubernetes Docs عدداً كبيراً من السيناريوهات التي من المحتمل أن ترغبوا في تنفيذها داخل بيئتكم. تحققوا من الإرشادات
لدينا أيضاً نشر عنقود منفصل لحل DocSpace. انظروا الإرشادات
يرجى الملاحظة: تعمل حلول العنقود هذه مع إصدارات Enterprise/Developer من برامجنا فقط، مما يتطلب منكم الحصول على ترخيص خاص مدفوع.
بمجرد النشر، سيكون حلنا موزعاً عبر عدة عقد، كل منها تشغل مجموعة من الـ Pods لضمان توزيع عبء العمل والتسامح مع الخطأ. على سبيل المثال، سيتم نشر حل Docs الخاص بنا ليس فقط كحاوية Docker واحدة ولكن كـ Pods منفصلة لـ docservice و converter، بما في ذلك Pods منفصلة للتبعيات مثل RabbitMQ و Redis و PostgreSQL و Nginx Ingress (ومع ذلك، يرجى ملاحظة أن التثبيت الأساسي لا يشمل تجميع التبعيات). ستكون لديكم أيضاً إمكانية تغيير التبعيات التي ستستخدمونها، حيث يدعم Docs تبعيات مختلفة. لذا، إذا كان لديكم أي شيء معين في الاعتبار، فهناك فرصة جيدة أنه ممكن بالفعل معنا.
إذا كانت لديكم أي أسئلة، فلا تترددوا في الاتصال بفريق الدعم لدينا لمزيد من المعلومات.
باختصار، تتضمن إرشاداتنا للتجميع (clustering) في بيئات Kubernetes/OpenShift جميع الأدوات الضرورية التي قد ترغبون في تنفيذها – مراقبة العنقود، وتغييرات التكوين، والتحديثات، والتوسع الأفقي والمزيد.
انتظروا، ولكن ماذا عن التحديثات؟ كيف يمكنكم ضمان عدم وجود وقت توقف؟
تحديثات بدون وقت توقف مع Kubernetes Docs Shards
يضمن حل Kubernetes Docs Shards الخاص بنا تحديثات سلسة. تسمح الأجزاء (Shards) (وحدات عبء العمل المقسمة) للـ Pods بالتحديث دون تعطيل الخدمة. بينما تكون بعض الـ Pods غير متصلة للتحديثات، تتولى الأخرى عبء العمل، مما يتيح تعاوناً غير منقطع حتى يتم نشر الإصدار الجديد بالكامل.
أدوات المراقبة
باستخدام حل Kubernetes/OpenShift المقدم من ONLYOFFICE، يمكنكم تمكين أدوات المراقبة التي ستساعدكم في جعل عملية البنية التحتية المبنية حديثاً شفافة.
- يمكنكم تمكين المقاييس باتباع هذا الجزء من الدليل.
- بعد ذلك، يمكنكم استخدام Grafana، على سبيل المثال، لتصور المقاييس.
- ستبدو النتيجة هكذا.
المتطلبات الفنية لـ ONLYOFFICE Kubernetes/OpenShift
كمرجع لكم، إذا قررتم نشر، على سبيل المثال، عنقود Kubernetes/OpenShift داخل بنيتكم التحتية، يمكننا تقديم تقديرات تقريبية فيما يتعلق بالموارد/المواصفات الفنية التي ستخدمكم كمرجع في تخطيط بنيتكم التحتية الخاصة.
عندما يتعلق الأمر بالمواصفات الفعلية، تجدر الإشارة إلى أننا نقدم المعلومات لعقد العمل (worker nodes) (وليس العقد الرئيسية).
بالنسبة لعقدة العمل، يمكنكم استخدام الحد الأدنى للصيغة وهو 4CPU/8Gb RAM لـ 1000 اتصال.
فيما يتعلق بمتطلبات النظام، وعدد النسخ المتماثلة والتخزين، يرجى الاطلاع على المعلومات على النحو التالي.
لـ 500 اتصال، ستكون:
- Converter: 2 نسخة متماثلة (replicas)
- Docservice: 2 نسخة متماثلة (replicas)
- يوصى باستخدام ما لا يقل عن 10Gi من التخزين الدائم لكل 100 مستخدم نشط لـ ONLYOFFICE Docs = الحد الأدنى 50Gb
لـ 1000 اتصال، ستكون:
- Converter: 2-3 نسخ متماثلة
- Docservice: 2-3 نسخ متماثلة
- باتباع نفس الصيغة = الحد الأدنى 100Gb
لـ 2000 اتصال، ستكون:
- Converter: 4-6 نسخ متماثلة
- Docservice: 4-6 نسخ متماثلة
- باتباع نفس الصيغة = الحد الأدنى 200Gb
لـ 5000 اتصال، ستكون:
- Converter: حوالي 10-15 نسخة متماثلة
- Docservice: حوالي 10-15 نسخة متماثلة
- باتباع نفس الصيغة = حوالي الحد الأدنى 500Gb
فيما يتعلق بحدود الموارد للخدمات، هذه هي المواصفات التي نستخدمها لـ 10,000 اتصال وفقاً لاختباراتنا.
الطلبات (Requests):
- الذاكرة: 256Mi
- وحدة المعالجة المركزية (CPU): 100m
الحدود (Limits):
- الذاكرة: 6Gi
- وحدة المعالجة المركزية (CPU): 4000m
ومع ذلك، نظراً لحقيقة أنه في بعض الأحيان يمكن للمستخدم فتح ملف كبير جداً، فمن الممكن أن يتجاوز حتى هذا الحد البالغ 6Gb. في الوقت نفسه، بشكل عام، نوصي بالتالي باستخدام ما لا يقل عن 6Gb للموارد.
نشر ONLYOFFICE في العنقود
يمكنكم بسهولة تثبيت ONLYOFFICE Docs و DocSpace في عنقود Kubernetes أو OpenShift باستخدام Helm. لتتمكنوا من استخدام ONLYOFFICE في العنقود الخاصة بكم، يرجى الحصول على ترخيص خاص.
الأسئلة الشائعة: نشر العنقود مع ONLYOFFICE
س: ما هو نشر العنقود، ولماذا هو مهم؟
يقوم نشر العنقود بتوزيع أعباء العمل عبر عقد متعددة، مما يضمن التوافر العالي، والتسامح مع الأخطاء، وقابلية التوسع. إنه يقلل من وقت التوقف ويحمي العمليات التجارية، مما يجعله مثالياً للبيئات الحساسة للمهمة.
س: ما هي فوائد استخدام ONLYOFFICE لعمليات نشر عنقود Kubernetes/OpenShift؟
يوفر ONLYOFFICE بنية تحتية عالية التوافر، ومتسامحة مع الأخطاء، وقابلة للتوسع. يضمن تجارب تحرير غير منقطعة، حتى أثناء مشاكل الأجهزة أو عبء العمل، ويدعم التكامل السلس مع تبعيات مختلفة.
س: كيف يتعامل ONLYOFFICE مع التحديثات بدون وقت توقف؟
يتيح ONLYOFFICE Docs المقدم كـ Kubernetes Shards تحديثات بدون وقت توقف. بينما يتم تحديث بعض الـ Pods، تستمر الأخرى في التعامل مع أعباء العمل، مما يضمن خدمة غير منقطعة.
س: ما هي أدوات المراقبة المتاحة لعناقيد ONLYOFFICE؟
يدعم ONLYOFFICE أدوات المراقبة مثل Grafana لتصور المقاييس. تتوفر أدلة مفصلة لمساعدتكم في تمكين وتكوين هذه الأدوات لتشغيل شفاف للبنية التحتية.
س: ما هي المتطلبات الفنية لنشر عناقيد ONLYOFFICE؟
تتوسع متطلبات الموارد بناءً على عدد الاتصالات، مع الحد الأدنى للصيغة وهو 4CPU/8Gb RAM لـ 1000 اتصال لعقدة العمل.
س: ما هي التراخيص المطلوبة لنشر عنقود ONLYOFFICE؟
تتوفر حلول عنقود ONLYOFFICE لإصدارات Enterprise/Developer وتتطلب ترخيصاً خاصاً مدفوعاً.
س: أين يمكنني العثور على أدلة النشر لعناقيد ONLYOFFICE؟
س: هل يمكنني تخصيص النشر ليناسب احتياجاتي؟
نعم، يوفر ONLYOFFICE مخططات Helm التي تسمح لكم بتخصيص عمليات النشر بناءً على متطلباتكم المحددة. الدعم متاح أيضاً لمزيد من المساعدة.
س: كيف يمكنني الاتصال بـ ONLYOFFICE لمزيد من المعلومات؟
للحصول على مساعدة إضافية أو استفسارات، يمكنكم التواصل مع فريق دعم ONLYOFFICE أو المبيعات.
ONLYOFFICE ١. أنشئ حسابك المجاني من
،٢. قم بعرض و تحرير أو التعاون على المستندات، الجداول ، العروض التقديمية
