مشاركة عبر

إرشادات أساس العمليات ل Azure Red Hat OpenShift

  • مقالة

يوفر Azure Red Hat OpenShift مجموعات OpenShift قابلة للتطوير بدرجة كبيرة ومدارة بالكامل عند الطلب. من خلال تصميم الحل الخاص بك بشكل صحيح مع وضع الإدارة والمراقبة في الاعتبار، يمكنك العمل نحو التميز التشغيلي ونجاح العملاء.

اعتبارات التصميم

ضع في اعتبارك العوامل التالية:

  • راجع مصفوفة مسؤولية Azure Red Hat OpenShift لفهم كيفية مشاركة مسؤوليات المجموعات بين Microsoft وRed Hat والعملاء.
  • كن على دراية بحدود جهاز Azure الظاهريوالمناطق المدعومة. تأكد من توفر سعة لتوزيع الموارد.
  • كن على دراية بطرق عزل أحمال العمل منطقيا داخل نظام مجموعة وفعليا في مجموعات منفصلة.
  • كن على دراية بطرق لمساعدة Kubernetes على فهم صحة أحمال العمل الخاصة بك.
  • كن على دراية بأحجام الأجهزة الظاهرية المختلفة وتأثير استخدام واحد أو آخر.
  • كن على دراية بطرق مراقبة وتسجيل Azure Red Hat OpenShift للحصول على رؤى حول صحة مواردك وتوقع المشكلات المحتملة. يمكن لكل من نظام المجموعة والتطبيقات التي تعمل في الأعلى إنشاء العديد من الأحداث. استخدم التنبيهات للمساعدة في التمييز بين إدخالات السجل للأغراض التاريخية والإدخالات التي تتطلب إجراء فوريا.
  • كن على دراية بالتحديثات والترقيات الهامة للنظام. يتم تطبيق تحديثات التصحيح الهامة على المجموعات تلقائيا بواسطة مهندسي موثوقية موقع Azure Red Hat OpenShift (SRE). يمكن للعملاء الذين يرغبون في تثبيت تحديثات التصحيح مسبقا القيام بذلك.
  • كن على دراية بقيود الموارد لنظام المجموعة وأحمال العمل الفردية.
  • كن على دراية بالاختلافات بين التحجيم التلقائي للجراب الأفقيوالتحجيم التلقائي للمجموعة.
  • راجع دورة حياة الدعم وفهم نهج دعم الإصدار. يدعم Azure Red Hat OpenShift الإصدارات الثانوية الحالية والسابقة المتوفرة بشكل عام فقط من Red Hat OpenShift Container Platform. تتطلب طلبات الدعم أن يكون نظام المجموعة ضمن إصدار مدعوم.
  • راجع متطلبات تكوين نظام المجموعة للحفاظ على قابلية دعم نظام المجموعة.
  • راجع الشبكات عبر مساحات الأسماء لتأمين نسبة استخدام الشبكة داخل نظام المجموعة باستخدام نهج الشبكة.

توصيات التصميم

  • يحتوي Azure Red Hat OpenShift على نظام بيئي غني للمشغل ويجب استخدامه لأداء الأنشطة التشغيلية وأتمتتها بكفاءة ودقة.
  • أضف تحقيقات السلامة إلى pods لمراقبة صحة التطبيق. تأكد من أن الجرابات تحتوي على livenessProbe والجاهزيةProbe. استخدم فحوصات بدء التشغيل لتحديد النقطة التي بدأ فيها التطبيق.
  • استخدم أحجام الأجهزة الظاهرية الكبيرة بما يكفي لاحتواء مثيلات حاوية متعددة حتى تحصل على فوائد زيادة الكثافة، ولكنها ليست كبيرة جدا بحيث لا يمكن لنظام مجموعتك التعامل مع حمل العمل لعقدة فاشلة.
  • تنظيم وظائف نظام المجموعة باستخدام المكونات الإضافية للقبول، والتي تستخدم عادة لفرض نهج الأمان أو قيود الموارد أو متطلبات التكوين.
  • استخدم طلبات وحدود الجراب لإدارة موارد الحوسبة داخل نظام مجموعة. تبلغ طلبات وحدود الجراب مجدول Kubernetes، الذي يعين موارد الحوسبة إلى جراب. تقييد استهلاك الموارد في مشروع باستخدام نطاقات الحد.
  • تحسين قيم طلب وحدة المعالجة المركزية والذاكرة، وزيادة كفاءة موارد نظام المجموعة باستخدام مقياس تلقائي للجراب العمودي.
  • تحتوي وحدة تحكم الويب OpenShift على جميع المقاييس على مستوى العقدة. إنشاء عملية مراقبة باستخدام تكامل Prometheus أو Container Insights المضمن.
    • يأتي Prometheus مثبتًا مسبقًا ومكونًا لأجل كتل Azure Red Hat OpenShift 4.x.
    • يمكن تمكين Container Insights عن طريق إلحاق نظام المجموعة ب Kubernetes الممكنة في Azure Arc.
    • ينشر تسجيل OpenShift مجمعات السجلات والتخزين ومكونات المرئيات.
  • أتمتة عملية تسليم التطبيق من خلال ممارسات DevOps وحلول CI/CD، مثل Pipelines/GitOps التي يوفرها OpenShift Container Platform.
  • حدد ClusterAutoScaler و MachineAutoScaler لتوسيع نطاق الأجهزة عند نفاد موارد نظام المجموعة لدعم المزيد من عمليات التوزيع.
  • توزيع عمليات التحقق من صحة الجهاز لإصلاح الأجهزة التالفة تلقائيا في تجمع الأجهزة.
  • تحجيم الجرابات لتلبية الطلب باستخدام مقياس تلقائي للجراب الأفقي.
  • استخدم نظام تنبيه لتوفير إعلامات عندما تحتاج الأشياء إلى إجراء مباشر: تنبيهات قياس Container Insights أو واجهة مستخدم التنبيه المضمنة.

استمرارية الأعمال واستعادة البيانات بعد حدوث خطأ فادح

تحتاج مؤسستك إلى تصميم قدرات مناسبة على مستوى النظام الأساسي Azure Red Hat OpenShift لتلبية متطلباتها المحددة. تحتوي خدمات التطبيق هذه على متطلبات تتعلق بهدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO). هناك اعتبارات متعددة يجب معالجتها للإصلاح بعد كارثة. خطوتك الأولى هي تحديد اتفاقية مستوى الخدمة (SLA) للبنية الأساسية والتطبيق الخاص بك. تعرف على اتفاقية مستوى الخدمة ل Azure Red Hat OpenShift. راجع قسم تفاصيل اتفاقية مستوى الخدمة للحصول على معلومات حول حسابات وقت التشغيل الشهري.

اعتبارات التصميم ل BCDR

ضع في اعتبارك العوامل التالية:

  • يجب أن تستخدم مجموعة Azure Red Hat OpenShift مجموعات أجهزة متعددة لتوفير الحد الأدنى من التوفر للتطبيق الخاص بك.
  • تعيين طلبات الحجرة والحدود. يتيح تعيين هذه الحدود ل Kubernetes:
    • قم بتعيين موارد وحدة المعالجة المركزية والذاكرة بكفاءة إلى pods.
    • لديك كثافة حاوية أعلى على عقدة.
    • زيادة الموثوقية مع انخفاض التكاليف بسبب الاستخدام الأفضل للأجهزة.
  • انشر العقد عبر جميع المناطق المتاحة للحصول على قابلية وصول أعلى.
    • اختر منطقة تدعم مناطق التوفر.
    • للحصول على فائدة المناطق كاملة، يجب أن تدعم كافة تبعيات الخدمة أيضاً المناطق. إذا كانت خدمة تابعة لا تدعم المناطق، فمن المحتمل أن يؤدي فشل المنطقة إلى فشل هذه الخدمة. راجع أنواع الأقراص المستخدمة عند نشر حمل العمل عبر المناطق.
    • للحصول على توفر أعلى يتجاوز ما يمكن أن تحققه مناطق التوفر، قم بتشغيل مجموعات متعددة في مناطق مقترنة مختلفة. إذا كان مورد Azure يدعم التكرار الجغرافي، فوفر الموقع حيث سيكون للخدمة المكررة منطقتها الثانوية.
  • إنشاء نسخ احتياطية للتطبيقات والبيانات باستمرار.
    • يمكن نسخ الخدمة غير ذات الحالة بكفاءة.
    • إذا كنت بحاجة إلى تخزين الحالة في نظام المجموعة، فنسخ البيانات احتياطيا بشكل متكرر في المنطقة المقترنة.
  • ترقية مجموعاتك وصيانتها.
    • حافظ دائما على تحديث نظام المجموعة الخاص بك. تحقق من ترقيات نظام المجموعة.
    • كن على دراية بعملية الإصدار والإهمال.
    • التحكم في الترقيات من خلال الجداول الزمنية.
    • راجع الحاجة إلى تحديث إطلاق الكناري لأحمال العمل الهامة.
  • للاتصال بالشبكة في حالة حدوث تجاوز الفشل:
    • إذا كنت بحاجة إلى توزيع نسبة استخدام الشبكة عبر المناطق، ففكر في استخدام Azure Front Door.
  • لتجاوز الفشل المخطط له وغير المخطط له:
    • عند إعداد كل خدمة من خدمات Azure، اختر الميزات التي تدعم الإصلاح بعد كارثة. على سبيل المثال، إذا تم اختيار Azure Container Registry ، فمكنه للنسخ المتماثل الجغرافي. إذا سقطت منطقة ما، يمكنك سحب الصور من المنطقة المنسوخة نسخا متماثلا.
  • الحفاظ على قدرات DevOps الهندسية للوصول إلى أهداف مستوى الخدمة.

توصيات التصميم ل BCDR

فيما يلي أفضل الممارسات لتصميمك:

  • يتم توفير مجموعات Azure Red Hat OpenShift بثلاث عقد وحدة تحكم وثلاث عقد عاملة أو أكثر. تأكد من إنشاء نظام المجموعة في منطقة تدعم مناطق التوفر بحيث تنتشر العقد عبر المناطق.
  • للحصول على قابلية وصول عالية، انشر هذه العقد إلى مناطق توفر مختلفة. نظرا لأنك تحتاج إلى مجموعات أجهزة مختلفة لكل منطقة توفر، قم بإنشاء ثلاث مجموعات أجهزة على الأقل.
  • لا تقم بتشغيل أحمال عمل إضافية على عقد وحدة التحكم. بينما يمكن جدولتها على عقد وحدة التحكم، فإنه سيسبب مشكلات إضافية في استخدام الموارد والاستقرار التي يمكن أن تؤثر على نظام المجموعة بأكمله.
  • إنشاء مجموعات أجهزة البنية الأساسية للاحتفاظ بمكونات البنية الأساسية. قم بتطبيق تسميات Kubernetes معينة على هذه الأجهزة ثم قم بتحديث مكونات البنية الأساسية للتشغيل على تلك الأجهزة فقط.
  • كلما أمكن، قم بإزالة حالة الخدمة من داخل الحاويات. بدلا من ذلك، استخدم النظام الأساسي Azure كخدمة (PaaS) التي تدعم النسخ المتماثل متعدد المناطق.
  • يجب أن تحدد عمليات التوزيع متطلبات موارد الجراب. يمكن للمجدول بعد ذلك جدولة الجراب بشكل مناسب. تنخفض الموثوقية بشكل كبير عندما لا تتم جدولة الحجيرات.
  • قم بإعداد نسخ متماثلة متعددة في التوزيع للتعامل مع الاضطرابات مثل فشل الأجهزة. بالنسبة للأحداث المخطط لها مثل التحديثات والترقيات، يمكن أن تضمن ميزانية التعطيل وجود العدد المطلوب من النسخ المتماثلة للحجيرة للتعامل مع الحمل المتوقع للتطبيق.
  • استخدم قيود طوبولوجيا الجراب لجدولة القرون تلقائيا على العقد في جميع أنحاء نظام المجموعة.
  • قد تستخدم تطبيقاتك التخزين لبياناتها ويجب أن تضمن التوفر عبر المناطق إذا لزم الأمر:
    • استخدام تخزين RWX مع فئة تخزين Azure Files المضمنة.
    • استخدام برامج تشغيل CSI لتوفير التخزين.
  • إنشاء نسخة احتياطية للتطبيق والتخطيط للاستعادة:
  • تقدير حدود موارد الجراب. اختبار وإنشاء أساس. ابدأ بالقيم المتساوية للطلبات والحدود. بعد ذلك، قم بضبط هذه القيم تدريجيا حتى تقوم بإنشاء حد يمكن أن يتسبب في عدم الاستقرار في نظام المجموعة. يمكن تحديد حدود الجراب في بيانات التوزيع الخاصة بك. يحسن التحجيم التلقائي للجراب العمودي قيم طلب وحدة المعالجة المركزية والذاكرة ويمكنه زيادة كفاءة موارد نظام المجموعة إلى أقصى حد.
    • يمكن للميزات المضمنة معالجة حالات الفشل والاضطرابات في بنية الخدمة. تساعد هذه التكوينات على تبسيط كل من أتمتة التصميم والتوزيع. عندما تحدد المؤسسة معيارا لاتفاقية مستوى الخدمة وRTO وRPO، يمكنها استخدام الخدمات المضمنة في Kubernetes وAzure لتحقيق أهداف العمل.
  • ضع في اعتبارك استراتيجيات الأزرق/الأخضر أو الكناري لنشر إصدارات جديدة من التطبيق.
  • قم بتعيين ميزانيات تعطيل pod/priority للحد من عدد النسخ المتماثلة للحجيرة التي يسمح لنظام المجموعة بإسقاطها لعمليات الصيانة، وبالتالي ضمان التوفر.
  • فرض حصص الموارد النسبية على مساحات أسماء الخدمة. ستضمن الحصة النسبية للمورد على مساحة الاسم تعيين طلبات وحدود جراب بشكل صحيح على نشر.
    • يمكن أن يتسبب تعيين حصص الموارد النسبية على مستوى نظام المجموعة في حدوث مشاكل عند توزيع خدمات الشركاء التي لا تحتوي على طلبات وحدود مناسبة.
  • قم بتخزين صور الحاوية في Azure Container Registryونسخ السجل جغرافيا إلى كل منطقة.
  • استخدم مناطق متعددة ومواقع نظيرة لاتصال Azure ExpressRoute . إذا حدث انقطاع يؤثر على منطقة Azure أو موقع موفر نظير، يمكن أن تساعد بنية الشبكة المختلطة المكررة في ضمان الاتصال عبر أماكن العمل دون انقطاع.
  • ربط المناطق مع نظير الشبكة الظاهرية العالمية. إذا كانت المجموعات بحاجة إلى التحدث مع بعضها البعض، يمكن تحقيق توصيل كلتا الشبكتين الظاهريتين ببعضهما البعض من خلال تناظر الشبكة الظاهرية. تربط هذه التقنية الشبكات الظاهرية ببعضها البعض لتوفير نطاق ترددي عال عبر شبكة Microsoft الأساسية، حتى عبر مناطق جغرافية مختلفة.
  • استخدم بروتوكول anycast المقسم المستند إلى TCP، Azure Front Door، لتوصيل المستخدمين النهائيين على الفور بأقرب Front Door POP (نقطة حضور). تتضمن المزيد من ميزات Azure Front Door ما يلي:
    • إنهاء TLS
    • مجال مخصص
    • جدار حماية تطبيق الويب
    • إعادة كتابة عنوان URL
    • تقارب الجلسة

الخطوات التالية

تعرف على اعتبارات التصميم والتوصيات لأتمتة النظام الأساسي وDevOps في مناطق هبوط Azure.