مشاركة عبر

النمذجة الصحية لأحمال العمل الحرجة للمهام

  • مقالة

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

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

يمكن توسيع نمذجة الصحة إلى المهام التشغيلية التالية للنشر الحرج للمهمة:

  • Application Health Service - مكون التطبيق على مجموعة الحوسبة التي توفر واجهة برمجة تطبيقات لتحديد صحة الطابع.

  • المراقبة - جمع عدادات الأداء والتطبيق التي تقيم صحة وأداء التطبيق والبنية التحتية.

  • التنبيه - تنبيهات قابلة للتنفيذ للمشكلات أو الانقطاعات في البنية الأساسية والتطبيق.

  • تحليل الفشل - تصنيف وتحليل أي حالات فشل بما في ذلك توثيق السبب الجذري.

تشكل هذه المهام نموذجا صحيا شاملا للبنية التحتية الحرجة للمهام. ويمكن بل وينبغي أن يكون وضع نموذج صحي جزءا شاملا لا يتجزأ من أي نشر بالغ الأهمية للمهمة.

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

خدمة صحة التطبيق

خدمة صحة التطبيق (HealthService) هي مكون تطبيق موجود مع خدمة الكتالوج (CatalogService) ومعالج الخلفية (BackgroundProcessor) داخل نظام مجموعة الحوسبة. توفر HealthService واجهة برمجة تطبيقات REST ل Azure Front Door للاتصال لتحديد صحة الطابع. HealthService هو مكون معقد يعكس حالة التبعيات، بالإضافة إلى الخاصة به.

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

  • يحاول إجراء استعلام مقابل Azure Cosmos DB.

  • يحاول إرسال رسالة إلى مراكز الأحداث. تتم تصفية الرسالة بواسطة عامل الخلفية.

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

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

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

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

التكوين

تحتوي HealthService و CatalogService على إعدادات تكوين شائعة بين المكونات باستثناء الإعدادات التالية المستخدمة حصريا بواسطة HealthService:

الإعداد القيمة‬
HealthServiceCacheDurationSeconds يتحكم في وقت انتهاء صلاحية ذاكرة التخزين المؤقت، بالثوان.
HealthServiceStorageConnectionString سلسلة الاتصال لحساب التخزين حيث يجب أن يكون ملف الحالة موجودا.
HealthServiceBlobContainerName حاوية التخزين حيث يجب أن يكون ملف الحالة موجودا.
HealthServiceBlobName اسم ملف الحالة - سيبحث فحص السلامة عن هذا الملف.
HealthServiceOverallTimeoutSeconds مهلة الفحص بأكمله - افتراضيا إلى 3 ثوان. إذا لم ينتهي الفحص في هذا الفاصل الزمني، فستبلغ الخدمة عن عدم الصحة.

تنفيذ

يتم إجراء جميع عمليات التحقق بشكل غير متزامن وبالتوازي. إذا فشل أي منهما، اعتبار الطابع بأكمله غير متوفر.

يتم تخزين نتائج الفحص مؤقتا في الذاكرة، باستخدام ASP.NET Core MemoryCacheالقياسية وغير الموزعة . يتم التحكم في انتهاء صلاحية ذاكرة التخزين المؤقت بواسطة SysConfig.HealthServiceCacheDurationSeconds ويتم تعيينه إلى 10 ثوان بشكل افتراضي.

إشعار

SysConfig.HealthServiceCacheDurationSeconds يقلل إعداد التكوين من الحمل الإضافي الذي تم إنشاؤه بواسطة عمليات التحقق من الصحة حيث لن يؤدي كل طلب إلى استدعاء انتقال البيانات من الخادم إلى الخدمات التابعة.

يوضح الجدول التالي تفاصيل عمليات التحقق من الصحة للمكونات في البنية الأساسية:

المكون فحص الصحة
كائن ثنائي كبير الحجم لحساب التخزين يخدم فحص الكائن الثنائي كبير الحجم حاليا غرضين:
1. اختبر ما إذا كان من الممكن الوصول إلى Blob Storage. يتم استخدام حساب التخزين من قبل مكونات أخرى في الطابع ويعتبر موردا مهما.
2. "إيقاف تشغيل" منطقة يدويا عن طريق حذف ملف الحالة.
تم اتخاذ قرار تصميم بأن الفحص سيبحث فقط عن وجود ملف حالة في حاوية الكائن الثنائي كبير الحجم المحددة. لا تتم معالجة محتوى الملف. هناك إمكانية لإعداد نظام أكثر تطورا يقرأ محتوى الملف ويعيد حالة مختلفة استنادا إلى محتوى الملف.
أمثلة المحتوى صحية وغير صحية وصيانة.
ستؤدي إزالة ملف الحالة إلى تعطيل الطابع. تأكد من وجود الملف الصحي بعد نشر التطبيق. سيؤدي عدم وجود ملف الحماية إلى استجابة الخدمة دائما مع غير صحي. لن يتعرف Front Door على الواجهة الخلفية على أنها متوفرة.
يتم إنشاء الملف بواسطة Terraform ويجب أن يكون موجودا بعد نشر البنية الأساسية.
مركز الأحداث تتم معالجة التقارير الصحية لمراكز الأحداث بواسطة EventHubProducerService. تبلغ هذه الخدمة عن صحة جيدة إذا كانت قادرة على إرسال رسالة جديدة إلى مراكز الأحداث. للتصفية، تحتوي هذه الرسالة على خاصية تعريف تمت إضافتها إليها:
HEALTHCHECK=TRUE
يتم تجاهل هذه الرسالة على الطرف المتلقي. AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() يتحقق إعداد التكوين من الخاصية HEALTHCHECK .
Azure Cosmos DB تتم معالجة تقارير صحة Azure Cosmos DB بواسطة CosmosDbService، الذي يبلغ عن صحة جيدة إذا كان:
1. قادر على الاتصال بقاعدة بيانات Azure Cosmos DB وتنفيذ استعلام.
2. قادر على كتابة مستند اختبار إلى قاعدة البيانات.
يحتوي مستند الاختبار على مجموعة قصيرة من مدة البقاء، يقوم Azure Cosmos DB بإزالتها تلقائيا.
تقوم HealthService بإجراء فحصين منفصلين. إذا كان Azure Cosmos DB في حالة لا تعمل فيها القراءة والكتابة، فإن التحقيقين يضمنان تشغيل تنبيه.

استعلامات Azure Cosmos DB

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

SELECT GetCurrentDateTime ()

ينشئ استعلام الكتابة وهميا ItemRating مع الحد الأدنى من المحتوى:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

مراقبة‬

يتم استخدام Azure Log Analytics كسجلات ومقاييس مخزن مركزي لجميع مكونات التطبيق والبنية الأساسية. يتم استخدام Azure Application Insights لجميع بيانات مراقبة التطبيق. يحتوي كل طابع في البنية الأساسية على مساحة عمل Log Analytics مخصصة ومثيل Application Insights. يتم استخدام مساحة عمل Log Analytics منفصلة للموارد المشتركة عالميا مثل Front Door وAzure Cosmos DB.

جميع الطوابع قصيرة الأجل ويتم استبدالها باستمرار بكل إصدار جديد. يتم نشر مساحات عمل Log Analytics لكل طابع كمورد عمومي في مجموعة موارد مراقبة منفصلة كموارد تحليلات السجل. لا تشارك هذه الموارد دورة حياة الطابع.

لمزيد من المعلومات، راجع مصدر البيانات الموحد للتحليل المترابط.

المراقبة: مصادر البيانات

  • إعدادات التشخيص: يتم تكوين جميع خدمات Azure المستخدمة في Azure Mission-Critical لإرسال جميع بيانات التشخيص الخاصة بها بما في ذلك السجلات والمقاييس إلى مساحة عمل تحليلات السجل المحددة (العمومية أو المخصصة). تحدث هذه العملية تلقائيا كجزء من نشر Terraform. سيتم تحديد الخيارات الجديدة تلقائيا وإضافتها كجزء من terraform apply.

  • مراقبة Kubernetes: تستخدم إعدادات التشخيص لإرسال سجلات ومقاييس خدمة Azure Kubernetes (AKS) إلى Log Analytics. تم تكوين AKS لاستخدام Container Insights. تنشر Container Insights OMSAgentForLinus عبر Kubernetes DaemonSet على كل عقدة في مجموعات AKS. OMSAgentForLinux قادر على جمع سجلات ومقاييس إضافية من داخل مجموعة Kubernetes ويرسلها إلى مساحة عمل Log Analytics المقابلة لها. تحتوي هذه السجلات والمقاييس الإضافية على بيانات أكثر دقة حول الحجيرات والنشرات والخدمات وصحة نظام المجموعة بشكل عام. للحصول على مزيد من الرؤى من المكونات المختلفة مثل ingress-nginx، مدير الشهادات، والمكونات الأخرى التي تم نشرها في Kubernetes بجوار حمل العمل الحرج للمهمة، من الممكن استخدام استخراج Prometheus. يقوم استخراج Prometheus بتكوين OMSAgentForLinux لاستخراج مقاييس Prometheus من نقاط النهاية المختلفة داخل نظام المجموعة.

  • بيانات تتبع استخدام Application Insights: يستخدم Application Insights لجمع بيانات تتبع الاستخدام من التطبيق. تم وضع علامة على التعليمات البرمجية لجمع البيانات حول أداء التطبيق باستخدام Application Insights SDK. يتم جمع المعلومات الهامة، مثل رمز الحالة الناتج ومدة استدعاءات التبعية والعدادات للاستثناءات غير المعالجة. يتم استخدام هذه المعلومات في Health Model وهي متاحة للتنبيه واستكشاف الأخطاء وإصلاحها.

المراقبة: اختبارات توفر Application Insights

لمراقبة توفر الطوابع الفردية والحل الشامل من وجهة نظر خارجية، يتم إعداد اختبارات توفر Application Insights في مكانين:

  • اختبارات التوفر الإقليمية: يتم إعداد هذه الاختبارات في مثيلات Application Insights الإقليمية وتستخدم لمراقبة توفر الطوابع. تستهدف هذه الاختبارات المجموعات وحسابات التخزين الثابتة للطوابع مباشرة. لاستدعاء نقاط الدخول للمجموعات مباشرة، تحتاج الطلبات إلى حمل عنوان معرف Front Door الصحيح، وإلا يتم رفضها من قبل وحدة تحكم الدخول.

  • اختبار التوفر العالمي: يتم إعداد هذه الاختبارات في مثيل Application Insights العمومي وتستخدم لمراقبة توفر الحل الشامل عن طريق اختبار ping Front Door. يتم استخدام اختبارين: أحدهما لاختبار استدعاء واجهة برمجة التطبيقات مقابل CatalogService والآخر لاختبار الصفحة الرئيسية لموقع الويب.

المراقبة: الاستعلامات

يستخدم Azure Mission-Critical استعلامات مختلفة بلغة استعلام Kusto (KQL) لتنفيذ استعلامات مخصصة كوظائف لاسترداد البيانات من Log Analytics. يتم تخزين هذه الاستعلامات كملفات فردية في مستودع التعليمات البرمجية الخاص بنا، مفصولة عن عمليات النشر العمومية والطوابع. يتم استيرادها وتطبيقها تلقائيا عبر Terraform كجزء من كل تشغيل لمسار البنية الأساسية.

يفصل هذا الأسلوب منطق الاستعلام عن طبقة المرئيات. يتم استدعاء استعلامات Log Analytics مباشرة من التعليمات البرمجية، على سبيل المثال من HealthService API. مثال آخر هو من أداة تصور مثل لوحات معلومات Azure أو مراقبة المصنفات أو Grafana.

المراقبة: التصور

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

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

التنبيه

التنبيهات هي جزء مهم من استراتيجية العمليات الشاملة. يجب استخدام المراقبة الاستباقية مثل استخدام لوحات المعلومات مع التنبيهات التي تثير الاهتمام الفوري للمشكلات.

تشكل هذه التنبيهات امتدادا لنموذج الصحة، عن طريق تنبيه المشغل إلى تغيير في الحالة الصحية، إما إلى حالة متدهورة/صفراء أو إلى حالة غير صحية/حمراء. من خلال تعيين التنبيه إلى العقدة الجذر ل Health Model، يكون المشغل على دراية فورية بأي مستوى عمل يؤثر على حالة الحل: بعد كل شيء، ستتحول هذه العقدة الجذر إلى اللون الأصفر أو الأحمر إذا أبلغ أي من تدفقات المستخدم أو الموارد الأساسية عن مقاييس صفراء أو حمراء. يمكن للمشغل توجيه انتباهه إلى تصور Health Model لاستكشاف الأخطاء وإصلاحها.

لمزيد من المعلومات، راجع الاستجابة التلقائية للحوادث.

تحليل الفشل

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

يسرد الجدول التالي أمثلة لحالات الفشل للمكونات المختلفة لتنفيذ مرجع Azure Mission-Critical.

الخدمة مخاطر التأثير/التخفيف/التعليق انقطاع
معرِّف Microsoft Entra يصبح معرف Microsoft Entra غير متوفر. لا يوجد حاليا أي تخفيف محتمل في مكانه. لن يخفف النهج متعدد المناطق من أي انقطاع لأنه خدمة عالمية. هذه الخدمة هي تبعية صعبة. يتم استخدام معرف Microsoft Entra لعمليات وحدة التحكم مثل إنشاء عقد AKS جديدة أو سحب صور الحاوية من ACR أو للوصول إلى Key Vault عند بدء تشغيل الجراب. من المتوقع أن تكون المكونات الحالية قيد التشغيل قادرة على الاستمرار في التشغيل عندما يواجه معرف Microsoft Entra مشكلات. من المحتمل أن تكون القرون الجديدة أو عقد AKS غير قادرة على إنتاجها. في عمليات التحجيم مطلوبة خلال هذا الوقت، قد يؤدي ذلك إلى انخفاض تجربة المستخدم وربما انقطاع التيار الكهربائي. جزئي
Azure DNS يصبح Azure DNS غير متوفر ويفشل تحليل DNS. إذا أصبح Azure DNS غير متوفر، من المحتمل أن تفشل دقة DNS لطلبات المستخدم وبين المكونات المختلفة للتطبيق. لا يوجد حاليا أي تخفيف محتمل لهذا السيناريو. لن يخفف النهج متعدد المناطق من أي انقطاع لأنه خدمة عالمية. Azure DNS هو تبعية صعبة. لن تساعد خدمات DNS الخارجية كنسخة احتياطية، لأن جميع مكونات PaaS المستخدمة تعتمد على Azure DNS. تجاوز DNS بالتبديل إلى IP ليس خيارا. لا تحتوي خدمات Azure على عناوين IP ثابتة ومضمونة. كامل
Front Door انقطاع الواجهة الأمامية العام. إذا تعطل Front Door بالكامل، فلن يكون هناك أي تخفيف. هذه الخدمة هي تبعية صعبة. ‏‏نعم‬
Front Door أخطاء تكوين التوجيه/الواجهة الأمامية/الخلفية. يمكن أن يحدث بسبب عدم التطابق في التكوين عند النشر. يجب أن يتم اكتشافه في مراحل الاختبار. تكوين الواجهة الأمامية مع DNS خاص بكل بيئة. التخفيف: يجب أن يعمل التراجع إلى التكوين السابق على إصلاح معظم المشكلات. نظرا لأن التغييرات تستغرق بضع دقائق في Front Door للنشر، فسيتسبب ذلك في انقطاع التيار الكهربائي. كامل
Front Door يتم حذف شهادة TLS/SSL المدارة. يمكن أن يحدث بسبب عدم التطابق في التكوين عند النشر. يجب أن يتم اكتشافه في مراحل الاختبار. من الناحية الفنية سيظل الموقع يعمل، ولكن أخطاء شهادة TLS/SSL ستمنع المستخدمين من الوصول إليه. التخفيف من المخاطر: قد تستغرق إعادة إصدار الشهادة حوالي 20 دقيقة، بالإضافة إلى إصلاح البنية الأساسية لبرنامج ربط العمليات التجارية وإعادة تشغيلها. كامل
Azure Cosmos DB تتم إعادة تسمية قاعدة البيانات/المجموعة. يمكن أن يحدث بسبب عدم التطابق في التكوين عند النشر - سيقوم Terraform بالكتابة فوق قاعدة البيانات بأكملها، مما قد يؤدي إلى فقدان البيانات. يمكن منع فقدان البيانات باستخدام تأمينات مستوى قاعدة البيانات/المجموعة. لن يتمكن التطبيق من الوصول إلى أي بيانات. يجب تحديث تكوين التطبيق وإعادة تشغيل الحجيرات. ‏‏نعم‬
Azure Cosmos DB الانقطاع الإقليمي تم تمكين عمليات الكتابة متعددة المناطق في Azure Mission-Critical. إذا كان هناك فشل في القراءة أو الكتابة، يعيد العميل محاولة العملية الحالية. يتم توجيه جميع العمليات المستقبلية بشكل دائم إلى المنطقة التالية بترتيب التفضيل. في حالة وجود إدخال واحد في قائمة التفضيلات (أو كانت فارغة) ولكن الحساب يحتوي على مناطق أخرى متوفرة، سيتم توجيهها إلى المنطقة التالية في قائمة الحسابات. لا
Azure Cosmos DB تقييد واسع النطاق بسبب نقص وحدات الطلب. اعتمادا على عدد وحدات الطلب وموازنة التحميل المستخدمة على مستوى Front Door، يمكن تشغيل بعض الطوابع الساخنة على استخدام Azure Cosmos DB بينما يمكن أن تخدم الطوابع الأخرى المزيد من الطلبات. التخفيف: توزيع تحميل أفضل أو المزيد من وحدات الطلب. لا
Azure Cosmos DB القسم ممتلئ حد حجم القسم المنطقي ل Azure Cosmos DB هو 20 غيغابايت. إذا وصلت بيانات مفتاح القسم داخل الحاوية إلى هذا الحجم، فستفشل طلبات الكتابة الإضافية مع ظهور الخطأ "وصل مفتاح القسم إلى الحد الأقصى للحجم". جزئي (تم تعطيل كتابة قاعدة البيانات)
Azure Container Registry الانقطاع الإقليمي يستخدم سجل الحاوية Traffic Manager للفشل بين مناطق النسخ المتماثلة. يجب إعادة توجيه أي طلب تلقائيا إلى منطقة أخرى. في أسوأ الأحوال، لا يمكن سحب صور Docker لبضع دقائق بواسطة عقد AKS أثناء حدوث تجاوز فشل DNS. لا
Azure Container Registry الصورة (الصور) المحذوفة لا يمكن سحب أي صور. يجب أن يؤثر هذا الانقطاع فقط على العقد التي تم إنتاجها/إعادة تمهيدها حديثا. يجب أن تحتوي العقد الموجودة على الصور المخزنة مؤقتا. **التخفيف: إذا تم الكشف عن إعادة تشغيل أحدث مسارات البناء بسرعة، يجب أن يعيد الصور إلى السجل. لا
Azure Container Registry التحكم بالنطاق الترددي* يمكن أن يؤدي التقييد إلى تأخير عمليات توسيع النطاق التي يمكن أن تؤدي إلى انخفاض الأداء مؤقتا. التخفيف من المخاطر: يستخدم Azure Mission-Critical وحدة SKU المميزة التي توفر عمليات قراءة 10 آلاف في الدقيقة. تم تحسين صور الحاوية وامتلكت أعدادا صغيرة فقط من الطبقات. تم تعيين ImagePullPolicy إلى IfNotPresent لاستخدام الإصدارات المخزنة مؤقتا محليا أولا. تعليق: يتكون سحب صورة حاوية من عمليات قراءة متعددة، اعتمادا على عدد الطبقات. عدد عمليات القراءة في الدقيقة محدودة ويعتمد على حجم ACR SKU. لا
Azure Kubernetes Service فشل ترقية نظام المجموعة يجب أن تحدث ترقيات عقدة AKS في أوقات مختلفة عبر الطوابع. إذا فشلت ترقية واحدة، فلا ينبغي أن تتأثر المجموعة الأخرى. يجب نشر ترقيات نظام المجموعة بطريقة متجددة عبر العقد لمنع جميع العقد من أن تصبح غير متوفرة. لا
Azure Kubernetes Service يتم إيقاف جراب التطبيق عند تقديم الطلب. قد يؤدي ذلك إلى مواجهة المستخدم النهائي لأخطاء وتجربة مستخدم ضعيفة. التخفيف من المخاطر: يزيل Kubernetes بشكل افتراضي الحجيرات بطريقة رشيقة. تتم إزالة الحجيرات من الخدمات أولا ويتلقى حمل العمل SIGTERM مع فترة سماح لإنهاء الطلبات المفتوحة وكتابة البيانات قبل الإنهاء. تحتاج التعليمات البرمجية للتطبيق إلى فهم SIGTERM وقد تحتاج فترة السماح إلى تعديل إذا كان حمل العمل يستغرق وقتا أطول لإيقاف التشغيل. لا
Azure Kubernetes Service سعة الحساب غير متوفرة في المنطقة لإضافة المزيد من العقد. ستفشل عمليات التوسيع/التوسيع، ولكن لا ينبغي أن تؤثر على العقد الموجودة وتشغيلها. من الناحية المثالية، يجب أن تتحول حركة المرور تلقائيا إلى مناطق أخرى لموازنة التحميل. لا
Azure Kubernetes Service يصل الاشتراك إلى الحصة الأساسية لوحدة المعالجة المركزية لإضافة عقد جديدة. ستفشل عمليات التوسيع/التوسيع، ولكن لا ينبغي أن تؤثر على العقد الموجودة وتشغيلها. من الناحية المثالية، يجب أن تتحول حركة المرور تلقائيا إلى مناطق أخرى لموازنة التحميل. لا
Azure Kubernetes Service لا يمكن إصدار/تجديد شهادات Let's Encrypt TLS/SSL. يجب أن يبلغ نظام المجموعة عن أنه غير سليم تجاه Front Door ويجب أن تتحول نسبة استخدام الشبكة إلى طوابع أخرى. التخفيف: تحقق من السبب الجذري لفشل المشكلة/التجديد. لا
Azure Kubernetes Service عند تكوين طلبات/حدود الموارد بشكل غير صحيح، يمكن أن تصل الحجيرات إلى استخدام وحدة المعالجة المركزية بنسبة 100٪ وطلبات الفشل. يجب أن تكون آلية إعادة محاولة التطبيق قادرة على استرداد الطلبات الفاشلة. يمكن أن تتسبب عمليات إعادة المحاولة في مدة طلب أطول، دون عرض الخطأ على العميل. سيؤدي التحميل الزائد في النهاية إلى فشل. لا (إذا لم يكن التحميل زائدا)
Azure Kubernetes Service صور الحاوية / السجل التابع لجهة خارجية غير متوفرة تتطلب بعض المكونات مثل cert-manager وingress-nginx تنزيل صور الحاوية ومخططات helm من سجلات الحاويات الخارجية (نسبة استخدام الشبكة الصادرة). في حالة عدم توفر واحد أو أكثر من هذه المستودعات أو الصور، قد لا تتمكن المثيلات الجديدة على العقد الجديدة (حيث لم يتم تخزين الصورة مؤقتا بالفعل) من البدء. التخفيف المحتمل: في بعض السيناريوهات، قد يكون من المنطقي استيراد صور حاوية تابعة لجهة خارجية إلى سجل الحاوية لكل حل. وهذا يضيف تعقيدا إضافيا وينبغي تخطيطه وتشغيله بعناية. جزئيا (أثناء عمليات المقياس والتحديث/الترقية)
مركز الأحداث لا يمكن إرسال الرسائل إلى مراكز الأحداث يصبح الطابع غير قابل للاستخدام لعمليات الكتابة. يجب أن تكتشف الخدمة الصحية هذا تلقائيا وتخرج الطابع من التدوير. لا
مركز الأحداث لا يمكن قراءة الرسائل بواسطة BackgroundProcessor سيتم وضع الرسائل في قائمة الانتظار. يجب ألا تفقد الرسائل لأنها مستمرة. حاليا، لا تغطي خدمة الصحة هذا الفشل. يجب أن يكون هناك مراقبة/تنبيه في مكان على العامل للكشف عن الأخطاء في قراءة الرسائل. التخفيف من المخاطر: يجب تعطيل الطابع يدويا حتى يتم إصلاح المشكلة. لا
حساب التخزين يصبح حساب التخزين غير قابل للاستخدام من قبل العامل للإشارة إلى التحقق من مراكز الأحداث لن يعالج الطابع الرسائل من مراكز الأحداث. يتم استخدام حساب التخزين أيضا بواسطة HealthService. من المتوقع أن يتم الكشف عن المشكلات المتعلقة بالتخزين بواسطة HealthService ويجب إخراج الطابع من التدوير. يمكن توقع أن تتأثر الخدمات الأخرى الموجودة في الطابع بشكل متزامن. لا
حساب التخزين يواجه موقع الويب الثابت مشكلات. إذا واجهت خدمة موقع الويب الثابت مشكلات، يجب الكشف عن هذا الفشل بواسطة Front Door. لن يتم إرسال حركة المرور إلى حساب التخزين هذا. يمكن أن يخفف التخزين المؤقت في Front Door أيضا من هذه المشكلة. لا
Key Vault Key Vault غير متوفر للعمليات GetSecret . في بداية القرون الجديدة، سيقوم برنامج تشغيل AKS CSI بإحضار جميع الأسرار من Key Vault وسيفشل. لن تتمكن Pods من البدء. هناك تحديث تلقائي حاليا كل 5 دقائق. سيفشل التحديث. يجب أن تظهر الأخطاء في ولكن الكبسولة تستمر في kubectl describe pod العمل. لا
Key Vault Key Vault غير متوفر لعمليات GetSecret أو SetSecret . لا يمكن تنفيذ عمليات النشر الجديدة. حاليا، قد يتسبب هذا الفشل في توقف البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع بالكامل، حتى إذا تأثرت منطقة واحدة فقط. لا
Key Vault تقييد Key Vault يحتوي Key Vault على حد 1000 عملية لكل 10 ثوان. بسبب التحديث التلقائي للبيانات السرية، يمكنك من الناحية النظرية الوصول إلى هذا الحد إذا كان لديك العديد من (الآلاف) من القرون في طابع. التخفيف المحتمل: تقليل تكرار التحديث بشكل أكبر أو إيقاف تشغيله تماما. لا
التطبيق خطأ في التكوين سلسلة الاتصال أو أسرار غير صحيحة تم إدخالها إلى التطبيق. يجب تخفيفه عن طريق النشر التلقائي (يعالج البنية الأساسية لبرنامج ربط العمليات التجارية التكوين تلقائيا) وطرح التحديثات باللون الأزرق والأخضر. لا
التطبيق بيانات الاعتماد منتهية الصلاحية (مورد الطابع) على سبيل المثال، إذا تم تغيير رمز SAS المميز لمركز الحدث أو مفتاح حساب التخزين دون تحديثه بشكل صحيح في Key Vault بحيث يمكن للقرون استخدامها، فسيفشل مكون التطبيق المعني. يجب أن يؤثر هذا الفشل بعد ذلك على Health Service، ويجب إخراج الطابع من التدوير تلقائيا. التخفيف من المخاطر: استخدم المصادقة المستندة إلى معرف Microsoft Entra لجميع الخدمات التي تدعمها. يتطلب AKS pods للمصادقة باستخدام هوية حمل عمل Microsoft Entra (معاينة). تم النظر في استخدام Pod Identity في التنفيذ المرجعي. تم العثور على أن Pod Identity لم تكن مستقرة بما فيه الكفاية حاليا وتم اتخاذ قرار ضد استخدامها للبنية المرجعية الحالية. يمكن أن تكون هوية الجراب حلا في المستقبل. لا
التطبيق بيانات الاعتماد منتهية الصلاحية (مورد مشترك عالميا) على سبيل المثال، إذا تم تغيير مفتاح Azure Cosmos DB API دون تحديثه بشكل صحيح في جميع مخازن مفاتيح الطابع بحيث يمكن للقرون استخدامها، فستفشل مكونات التطبيق المعنية. سيؤدي هذا الفشل إلى خفض جميع الطوابع في نفس الوقت ويتسبب في انقطاع على مستوى حمل العمل. للحصول على طريقة ممكنة حول الحاجة إلى المفاتيح والأسرار باستخدام مصادقة Microsoft Entra، راجع العنصر السابق. كامل
الشبكة الظاهرية استنفاد مساحة عنوان IP للشبكة الفرعية إذا استنفدت مساحة عنوان IP على شبكة فرعية، فلا يمكن أن تحدث أي عمليات توسيع، مثل إنشاء عقد AKS جديدة أو pods. لن يؤدي ذلك إلى انقطاع ولكن قد يقلل من الأداء ويؤثر على تجربة المستخدم. التخفيف: زيادة مساحة IP (إن أمكن) . إذا لم يكن هذا خيارا، فقد يساعد على زيادة الموارد لكل عقدة (وحدات SKU أكبر للجهاز الظاهري) أو لكل جراب (المزيد من وحدة المعالجة المركزية/الذاكرة)، بحيث يمكن لكل جراب التعامل مع المزيد من نسبة استخدام الشبكة، وبالتالي تقليل الحاجة إلى التوسع. لا

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

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

التنفيذ: مهمة حرجة على الإنترنت