مشاركة عبر

الإصلاح بعد كارثة في Azure Service Fabric

  • مقالة

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

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

تجنب الكوارث

الهدف الرئيسي من Azure Service Fabric هو مساعدتك في تصميم بيئتك وخدماتك بطريقة تجعل أنواع الفشل الشائعة لا ترقى إلى كوارث.

يوجد نوعان بشكل عام من سيناريوهات الكوارث/ الفشل:

  • أخطاء الأجهزة والبرامج
  • أخطاء التشغيل

أخطاء الأجهزة والبرامج

لا يمكن التنبؤ بأخطاء الأجهزة والبرامج. أسهل طريقة للنجاة من الأخطاء هي تشغيل المزيد من نسخ الخدمة عبر حدود أخطاء الأجهزة أو البرامج.

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

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

عندما تمتد الخدمة عبر مثيلات فعلية متعددة (آلات، رفوف، مراكز بيانات، مناطق)، فإنك لا تزال عرضة لبعض أنواع الفشل المتزامن. لكن حالات الفشل الفردية وحتى المتعددة من نوع معين (على سبيل المثال، فشل جهاز ظاهري واحد أو ارتباط شبكة) يتم التعامل معها تلقائياً وبالتالي لم تعد "كارثة."

يوفر Service Fabric آليات لتوسيع المجموعة ويعالج إعادة العقد والخدمات الفاشلة. ويسمح Service Fabric أيضاً بتشغيل العديد من مثيلات خدماتك لمنع الفشل غير المخطط له من التعيين إلى كوارث حقيقية.

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

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

أخطاء التشغيل

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

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

أفضل الطرق لتجنب هذه الأنواع من أخطاء التشغيل هي:

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

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

إدارة حالات الفشل

الهدف من Service Fabric هو الإدارة التلقائية لحالات الفشل. ولكن للتعامل مع بعض أنواع حالات الفشل يجب أن تحتوي الخدمات على تعليمة برمجية إضافية. يجب عدم معالجة الأنواع الأخرى من حالات الفشل تلقائياً لأسباب تتعلق بالسلامة واستمرارية الأعمال.

التعامل مع حالات الفشل الفردية

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

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

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

التعامل مع حالات الفشل المنسقة

يمكن أن تكون حالات الفشل المنسقة في نظام مجموعة بسبب فشل وتغييرات البنية الأساسية المخطط لها أو غير المخطط لها، أو تغييرات البرامج المخطط لها. مناطق البنية الأساسية لنماذج Service Fabric التي تواجه حالات الفشل المنسقة كمجالات أخطاء. تم تصميم المناطق التي ستواجه تغييرات منسقة في البرامج على أنها مجالات ترقية. لمزيد من المعلومات عن مجالات الخطأ وترقية المجالات وطوبولوجيا نظام المجموعة، راجع Describe a Service Fabric cluster by using Cluster Resource Manager.

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

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

عندما تقوم بتشغيل Service Fabric في Azure، تتم إدارة مجالات الخطأ ومجالات الترقية تلقائياً. في بيئات أخرى، قد لا يكونون الأمر كذلك. إذا كنت تقوم بإنشاء نظام مجموعاتك الخاصة محلياً، فتأكد من تعيين تخطيط المجال الخاطئ وتخطيطه بشكل صحيح.

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

يمكنك تصور تخطيط نظام مجموعتك باستخدام خريطة المجموعة المتوفرة في Service Fabric Explorer:

العقد المنتشرة عبر مجالات الخطأ في Service Fabric Explorer

ملاحظة

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

معالجة أخطاء الأجهزة أو البرامج المتزامنة

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

يمكن أن تحدث أيضاً حالات فشل عشوائية متعددة في وقت واحد. من المرجح أن تؤدي إلى وقت تعطل أو كارثة فعلية.

خدمات عديمة الحالة

يشير عدد المثيلات لخدمة عديمة الحالة إلى العدد المطلوب من المثيلات التي يجب تشغيلها. عند فشل أي مثيل من المثيلات (أو جميعها)، يستجيب Service Fabric عن طريق إنشاء مثيلات بديلة تلقائياً على العقد الأخرى. يستمر Service Fabric في إنشاء بدائل حتى تعود الخدمة إلى عدد المثيلات المطلوب.

على سبيل المثال، افترض أن الخدمة عديمة الحالة لها قيمة InstanceCount -1. تعني هذه القيمة أنه يجب تشغيل مثيل واحد على كل عقدة في نظام المجموعة. إذا فشلت بعض هذه الحالات، فسيكتشف Service Fabric أن الخدمة ليست في حالتها المطلوبة وسيحاول إنشاء مثيلات على العقد المفقودة فيها.

الخدمات ذات الحالة

هناك نوعان من الخدمات ذات الحالة:

  • خدمة ذات حالة بحالة مستمرة.
  • خدمة ذات حالة بحالة غير مستمرة. (يتم تخزين الحالة في الذاكرة.)

يعتمد الاسترداد من فشل الخدمة ذات الحالة على نوع الخدمة ذات الحالة، وعدد النسخ المتماثلة الموجودة في الخدمة، وعدد النسخ المتماثلة التي فشلت.

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

عند فشل حصة النسخ المتماثلة، يتم الإعلان عن القسم بأنه في حالة فقدان حصة. لنفترض أن القسم يحتوي على خمس نسخ متماثلة، ما يسمح يعني أن هناك ثلاث نسخ متماثلة على الأقل مضمونة بالحصول على بيانات كاملة. في حالة فشل الحصة (ثلاث من خمس) من النسخ المتماثلة، لا يمكن لـService Fabric تحديد ما إذا كانت النسخ المتماثلة المتبقية (اثنان من خمس) تحتوي على بيانات كافية لاستعادة القسم. في الحالات التي يكتشف فيها Service Fabric فقدان الحصة، يكون سلوكه الافتراضي هو منع عمليات الكتابة الإضافية إلى القسم، والإعلان عن فقدان الحصة، وانتظار استعادة حصة النسخ المتماثلة.

إن تحديد ما إذا حدثت كارثة لخدمة ذات حالة جيدة ومن ثم إدارتها يتبع ثلاث مراحل:

  1. تحديد ما إذا كانت هناك حصة أم لا.

    يتم الإعلان عن فقدان الحصة عندما تكون غالبية النسخ المتماثلة من الخدمة ذات الحالة معطلة في نفس الوقت.

  2. تحديد ما إذا كان فقدان الحصة دائماً أم لا.

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

    • بالنسبة للخدمات التي لا تحتوي على حالة مستمرة، يؤدي فشل حصة أو أكثر من النسخ المتماثلة إلى فقدان الحصة الدائم على الفور. عندما يكتشف Service Fabric فقدان الحصة في خدمة غير مستمرة ذات حالة، ينتقل على الفور إلى الخطوة 3 عن طريق إعلان فقدان البيانات (المحتمل). يعد الانتقال إلى فقدان البيانات أمراً منطقياً لأن Service Fabric يعرف عدم جدوى انتظار عودة النسخ المتماثلة. حتى في حالة استرداد البيانات، ستفقد البيانات بسبب الطبيعة غير المستمرة للخدمة.
    • بالنسبة للخدمات المستمرة ذات الحالة، يؤدي فشل حصة أو أكثر من النسخ المتماثلة إلى انتظار Service Fabric حتى تعود النسخ المتماثلة واستعادة الحصة. ينتج عن ذلك انقطاع الخدمة لأي عمليات كتابة إلى القسم المتأثر (أو "مجموعة النسخ المتماثلة") للخدمة. ومع ذلك، قد تظل القراءات ممكنة مع ضمانات تناسق منخفضة. المقدار الافتراضي للوقت الذي ينتظره Service Fabric لاستعادة الحصة لانهائي، لأن المتابعة عبارة عن حدث فقدان بيانات (محتمل) وتنطوي على مخاطر أخرى. هذا يعني أن Service Fabric لن ينتقل إلى الخطوة التالية ما لم يتخذ المسؤول إجراءً للإعلان عن فقدان البيانات.

  3. تحديد ما إذا كانت البيانات مفقودة، واستعادتها من النسخ الاحتياطية.

    إذا تم الإعلان عن فقدان الحصة (إما تلقائياً أو من خلال إجراء إداري)، ينتقل Service Fabric والخدمات لتحديد ما إذا كانت البيانات قد فُقدت بالفعل. وفي هذه المرحلة، يعرف Service Fabric أيضاً أن النسخ المتماثلة الأخرى لن تعود. وكان هذا هو القرار الذي تم اتخاذه عندما توقفنا عن انتظار فقد الحصة لحل نفسها. وعادةً ما يكون أفضل مسار عمل للخدمة هو التجميد وانتظار تدخل إداري محدد.

    عندما يستدعي Service Fabric الأسلوب OnDataLossAsync، فهذا دائماً يكن بسبب فقدان البيانات المشتبه به. ويضمن Service Fabric تسليم هذا الاستدعاء إلى أفضل نسخة متماثلة متبقية. هذه هي النسخة المتماثلة التي حققت أكبر قدر من التقدم.

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

    إذن ما الذي يفعله التنفيذ النموذجي لأسلوب OnDataLossAsync؟

    1. سجلات التنفيذ التي قام بتشغيلها OnDataLossAsync، وتقوم بإرسال أي تنبيهات إدارية ضرورية بسرعة.

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

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

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

    4. يقارن التطبيق حالة النسخة المتماثلة المتبقية مع تلك الموجودة في أي نسخ احتياطية متوفرة. إذا كنت تستخدم مجموعات موثوقة من Service Fabric، فهناك أدوات وعمليات متاحة للقيام بذلك. الهدف هو معرفة ما إذا كانت الحالة داخل النسخة المتماثلة كافية، ومعرفة ما النسخة الاحتياطية التي قد تكون مفقودة.

    5. بعد إجراء المقارنة، وبعد اكتمال الاستعادة (إذا لزم الأمر)، يجب أن تُرجع التعليمة البرمجية للخدمة القيمة true إذا تم إجراء أي تغييرات على الحالة. إذا حددت النسخة المتماثلة أنها أفضل نسخة متاحة من الحالة ولم تُجر أي تغييرات، فستُرجع التعليمة البرمجية القيمة false.

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

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

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

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

إذا اكتشفت أن النسخ المتماثلة المتبقية غير كافية للاستمرار في سيناريو فقدان البيانات، ولا يمكنك إعادة بناء حالة الخدمة من بيانات تتبع الاستخدام أو العادم، فإن تكرار النسخ الاحتياطية يحدد أفضل هدف ممكن لنقطة الاسترداد (RPO). يوفر Service Fabric العديد من الأدوات لاختبار سيناريوهات الفشل المختلفة، بما في ذلك الحصة الدائمة وفقدان البيانات التي تتطلب الاستعادة من نسخة احتياطية. يتم تضمين هذه السيناريوهات كجزء من أدوات قابلية الاختبار في Service Fabric، وتديرها Fault Analysis Service. لمزيد من المعلومات عن هذه الأدوات والأنماط، راجع Introduction to the Fault Analysis Service.

ملاحظة

يمكن أن تعاني خدمات النظام أيضاً من فقدان الحصة. التأثير خاص بالخدمة المعنية. على سبيل المثال، يؤثر فقدان الحصة في خدمة التسمية على تحليل الاسم، بينما يؤدي فقدان الحصة في خدمة Failover Manager إلى منع إنشاء خدمة جديدة وتجاوز الفشل.

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

استكشاف أخطاء فقدان الحصة وإصلاحها

قد تتعطل النسخ المتماثلة بشكل متقطع بسبب فشل مؤقت. انتظر بعض الوقت ريثما يحاول Service Fabric عرضها. إذا تعطلت النسخ المتماثلة لأكثر من المدة المتوقعة، فاتبع إجراءات استكشاف الأخطاء وإصلاحها هذه:

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

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

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

قد تؤدي الإجراءات التالية إلى فقدان البيانات. تحقق قبل اتباعها.

ملاحظة

ليس من الآمن مطلقاً استخدام هذه الطرق بخلاف الطريقة المستهدفة ضد أقسام معينة.

  • استخدم واجهة برمجة التطبيقات Repair-ServiceFabricPartition -PartitionId أو System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId). تسمح واجهة برمجة التطبيقات هذه بتحديد معرف القسم للخروج من فقدان الحصة وفقدان البيانات المحتمل.
  • إذا واجهت نظام مجموعتك حالات فشل متكررة أدت إلى دخول الخدمات في حالة فقدان الحصة وكان احتمال فقدان البيانات أمراً مقبولاً، فإن تحديد قيمة QuorumLossWaitDuration مناسبة يمكن أن يساعد خدمتك على الاسترداد تلقائياً. سينتظر Service Fabric قيمة QuorumLossWaitDuration المقدمة (القيمة الافتراضي لانهائية) قبل إجراء الاسترداد. لا نوصي بهذه الطريقة لأنها قد تسبب خسائر غير متوقعة في البيانات.

توافر نظام مجموعة Service Fabric

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

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

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

حالات فشل مركز البيانات أو منطقة Azure

في حالات نادرة، يمكن أن يصبح مركز البيانات المادي غير متاح مؤقتاً بسبب فقدان الطاقة أو اتصال الشبكة. في هذه الحالات، لن تكون أنظمة مجموعات Service Fabric والخدمات في مركز البيانات هذا أو منطقة Azure متاحة. ومع ذلك، يتم الاحتفاظ ببياناتك.

بالنسبة لنظام المجموعة التي يتم تشغيلها في Azure، يمكنك عرض تحديثات حالات الانقطاع في صفحة حالة Azure. في حالة احتمال تعرض أحد مراكز البيانات المادية للتدمير جزئياً أو كلياً، وهو أمر بعيد الاحتمال للغاية، فقد تُفقد أي أنظمة مجموعات في Service Fabric المستضافة هناك، أو الخدمات الموجودة بداخلها. تشمل هذه الخسارة أي حالة لم يتم نسخها احتياطياً خارج مركز البيانات أو المنطقة.

هناك عدة إستراتيجيات مختلفة للنجاة من الفشل الدائم أو المستمر لمركز بيانات أو منطقة واحدة:

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

  • شغل نظام مجموعة Service Fabric واحدة والتي تمتد عبر عدة مراكز بيانات. الحد الأدنى للتكوين المدعوم لهذه الإستراتيجية هو ثلاثة مراكز بيانات. لمزيد من المعلومات، راجع Deploy a Service Fabric cluster across Availability Zones.

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

    لمزيد من المعلومات عن السياسات التي يمكن أن تساعد في تشغيل الخدمات في هذا النوع من أنظمة المجموعات، راجع Placement policies for Service Fabric services.

  • شغل نظام مجموعة Service Fabric واحدة والتي تمتد عبر مناطق متعددة باستخدام نموذج Standalone. عدد المناطق الموصى به هو ثلاثة. راجع Create a standalone cluster للحصول على تفاصيل عن إعداد Service Fabric المستقل.

حالات الفشل العشوائية التي تؤدي إلى فشل نظام المجموعة

يمتلك Service Fabric مفهوم العقد الأولية. هذه هي العقد التي تحافظ على توافر نظام المجموعة الأساسية.

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

في Azure، يدير موفر Service Fabric Resource تكوينات نظام مجموعة Service Fabric. يوزع موفر المورد العقد الأولية بشكل افتراضي عبر نطاقات الخطأ وترقية نوع العقدة الأساسية. إذا تم وضع علامة على نوع العقدة الأساسي على أنه القدرة على الصمود بدرجة فضية أو بدرجة ذهبية، فعند إزالة عقدة أولية (إما عن طريق التحجيم في نوع العقدة الأساسية أو عن طريق إزالتها يدوياً)، سيحاول نظام المجموعة تعزيز عقدة أخرى غير أولية من السعة المتاحة لنوع العقدة الأساسي. ستفشل هذه المحاولة إذا كانت لديك سعة متوفرة أقل مما يتطلبه مستوى موثوقية نظام مجموعة لنوع العقدة الأساسي.

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

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