مشاركة عبر

نظرة عامة على حل التعافي من الكوارث النشط السلبي لخدمة Azure Kubernetes (AKS)

  • مقالة

عند إنشاء تطبيق في خدمة Azure Kubernetes (AKS) واختيار منطقة Azure أثناء إنشاء الموارد، فإنه تطبيق من منطقة واحدة. عندما تصبح المنطقة غير متوفرة أثناء حدوث كارثة، يصبح التطبيق الخاص بك غير متوفر أيضا. إذا قمت بإنشاء نشر متطابق في منطقة Azure ثانوية، يصبح تطبيقك أقل عرضة لكارثة منطقة واحدة، ما يضمن استمرارية العمل، ويتيح لك أي نسخ متماثل للبيانات عبر المناطق استرداد حالة التطبيق الأخيرة.

يوضح هذا الدليل حل التعافي من الكوارث النشط السلبي ل AKS. ضمن هذا الحل، ننشر مجموعتي AKS مستقلتين ومتطابقتين في منطقتين من مناطق Azure المقترنة مع مجموعة واحدة فقط تخدم حركة المرور بنشاط.

إشعار

تمت مراجعة الممارسة التالية داخليا وفحصها بالاشتراك مع شركائنا في Microsoft.

نظرة عامة على الحل النشط السلبي

في نهج التعافي من الكوارث هذا، لدينا مجموعتان مستقلتان من AKS يتم توزيعهما في منطقتين من مناطق Azure. ومع ذلك، فإن واحدة فقط من المجموعات تخدم حركة المرور بنشاط في أي وقت. تحتوي المجموعة الثانوية (لا تخدم حركة المرور بشكل نشط) على نفس بيانات التكوين والتطبيق مثل نظام المجموعة الأساسي ولكنها لا تقبل أي حركة مرور ما لم يوجهها مدير حركة مرور Azure Front Door.

السيناريوهات والتكوينات

يتم تنفيذ هذا الحل بشكل أفضل عند استضافة التطبيقات التي تعتمد على الموارد، مثل قواعد البيانات، التي تخدم حركة المرور بنشاط في منطقة واحدة. في السيناريوهات التي تحتاج فيها إلى استضافة التطبيقات عديمة الحالة المنتشرة عبر كلتا المنطقتين، مثل التحجيم الأفقي، نوصي بالنظر في حل نشط-نشط، حيث يتضمن active-passive زمن انتقال إضافي.

المكونات

يستخدم حل التعافي من الكوارث النشط السلبي العديد من خدمات Azure. تتضمن بنية المثال هذه المكونات التالية:

مجموعات ومناطق متعددة: يمكنك نشر مجموعات AKS متعددة، كل منها في منطقة Azure منفصلة. أثناء العمليات العادية، يتم توجيه حركة مرور الشبكة إلى مجموعة AKS الأساسية التي تم تعيينها في تكوين Azure Front Door.

ترتيب أولويات نظام المجموعة المكون: يمكنك تعيين مستوى ترتيب الأولويات بين 1-5 لكل نظام مجموعة (مع 1 هو الأولوية العليا و5 يكون أقل أولوية). يمكنك تعيين مجموعات متعددة إلى نفس مستوى الأولوية وتحديد الوزن لكل نظام مجموعة. إذا أصبحت المجموعة الأساسية غير متوفرة، يتم توجيه حركة المرور تلقائيا إلى المنطقة التالية المحددة في Azure Front Door. يجب أن تمر جميع حركة المرور عبر Azure Front Door حتى يعمل هذا النظام.

Azure Front Door: يوازن تحميل Azure Front Door ويوجه حركة المرور إلى مثيل Azure Application Gateway في المنطقة الأساسية (يجب وضع علامة على نظام المجموعة بالأولوية 1). في حالة فشل المنطقة، تعيد الخدمة توجيه نسبة استخدام الشبكة إلى نظام المجموعة التالي في قائمة الأولوية.

لمزيد من المعلومات، راجع توجيه حركة المرور المستندة إلى الأولوية.

زوج النظام المحوري: يتم نشر زوج محوري لكل مثيل AKS إقليمي. تدير نهج Azure Firewall Manager قواعد جدار الحماية عبر كل منطقة.

Key Vault: يمكنك توفير Azure Key Vault في كل منطقة لتخزين الأسرار والمفاتيح.

Log Analytics: تخزن مثيلات Log Analytics الإقليمية مقاييس الشبكات الإقليمية وسجلات التشخيص. يخزن المثيل المشترك المقاييس وسجلات التشخيص لجميع مثيلات AKS.

Container Registry: يتم تخزين صور الحاوية لحمل العمل في سجل حاوية مدار. باستخدام هذا الحل، يتم استخدام مثيل Azure Container Registry واحد لجميع مثيلات Kubernetes في نظام المجموعة. يتيح لك النسخ المتماثل الجغرافي ل Azure Container Registry نسخ الصور نسخا متماثلا إلى مناطق Azure المحددة ويوفر وصولا مستمرا إلى الصور حتى إذا واجهت منطقة انقطاعا.

عملية تجاوز الفشل

إذا أصبح مكون خدمة أو خدمة غير متوفر في منطقة واحدة، يجب توجيه نسبة استخدام الشبكة إلى منطقة تتوفر فيها هذه الخدمة. تتضمن البنية متعددة المناطق العديد من نقاط الفشل المختلفة. في هذا القسم، نغطي نقاط الفشل المحتملة.

Application Pods (إقليمي)

ينشئ كائن توزيع Kubernetes نسخا متماثلة متعددة من pod (ReplicaSet). إذا لم يكن أحدها متوفرا، يتم توجيه نسبة استخدام الشبكة بين النسخ المتماثلة المتبقية. تحاول مجموعة النسخ المتماثلة Kubernetes الاحتفاظ بالعدد المحدد من النسخ المتماثلة وتشغيلها. إذا انخفض مثيل واحد، يجب إعادة إنشاء مثيل جديد. يمكن لفحوصات الحياة التحقق من حالة التطبيق أو العملية قيد التشغيل في الجراب. إذا كان pod غير مستجيب، فإن مسبار الحياة يزيل الحاوية، ما يجبر ReplicaSet على إنشاء مثيل جديد.

لمزيد من المعلومات، راجع Kubernetes ReplicaSet.

Application Pods (Global)

عندما تصبح منطقة بأكملها غير متوفرة، لن تكون المجموعات في نظام المجموعة متاحة لخدمة الطلبات. في هذه الحالة، يقوم مثيل Azure Front Door بتوجيه كافة نسبة استخدام الشبكة إلى المناطق الصحية المتبقية. تستمر مجموعات Kubernetes والقرون في هذه المناطق في تقديم الطلبات. للتعويض عن زيادة نسبة استخدام الشبكة والطلبات إلى المجموعة المتبقية، ضع في اعتبارك الإرشادات التالية:

  • تأكد من أن موارد الشبكة والحوسبة بحجم مناسب لاستيعاب أي زيادة مفاجئة في نسبة استخدام الشبكة بسبب تجاوز الفشل في المنطقة. على سبيل المثال، عند استخدام واجهة شبكة حاويات Azure (CNI)، تأكد من أن لديك شبكة فرعية يمكنها دعم جميع عناوين IP للحاوية مع تحميل نسبة استخدام الشبكة.
  • استخدم التحجيم التلقائي للجراب الأفقي لزيادة عدد النسخ المتماثلة للجراب للتعويض عن الطلب الإقليمي المتزايد.
  • استخدم التحجيم التلقائي لنظام مجموعة AKS لزيادة عدد عقد مثيل Kubernetes للتعويض عن الطلب الإقليمي المتزايد.

تجمعات عقدة Kubernetes (إقليمية)

في بعض الأحيان، يمكن أن يحدث فشل مترجم لحساب الموارد، مثل أن تصبح الطاقة غير متوفرة في حامل واحد من خوادم Azure. لحماية عقد AKS من أن تصبح فشلا إقليميا أحادي النقطة، استخدم مناطق توفر Azure. تضمن مناطق التوفر فصل عقد AKS في كل منطقة توفر فعليا عن تلك المحددة في مناطق توفر أخرى.

تجمعات عقدة Kubernetes (عمومية)

في فشل إقليمي كامل، يوجه Azure Front Door نسبة استخدام الشبكة إلى المناطق السليمة المتبقية. مرة أخرى، تأكد من تعويض زيادة نسبة استخدام الشبكة والطلبات إلى المجموعة المتبقية.

استراتيجية اختبار تجاوز الفشل

على الرغم من عدم وجود آليات متاحة حاليا داخل AKS لتجاوز منطقة نشر بأكملها لأغراض الاختبار، فإن Azure Chaos Studio يوفر القدرة على إنشاء تجربة فوضى على مجموعتك.

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

إذا كنت تفكر في حل مختلف، فشاهد المقالات التالية: