مشاركة عبر

نظرة عامة على الحل السلبي البارد لخدمة Azure Kubernetes (AKS)

  • مقالة

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

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

إشعار

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

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

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

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

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

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

المكونات

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

مجموعات ومناطق متعددة: يمكنك نشر مجموعات AKS متعددة، كل منها في منطقة Azure منفصلة. عند الحاجة إلى التطبيق، يتم تنشيط نظام المجموعة الخاملة لتلقي حركة مرور الشبكة.

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

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

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

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

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

إذا لم تعمل المجموعة الخاملة بشكل صحيح بسبب مشكلة في منطقة 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 يوفر القدرة على إنشاء تجربة فوضى على مجموعتك.

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

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