مشاركة عبر

الموثوقية في Azure App Service

  • مقالة

توضح هذه المقالة دعم الموثوقية في Azure App Service، والتي تغطي كلا من المرونة داخل المنطقة مع مناطق التوفر والمعلومات حول عمليات النشر متعددة المناطق.

المرونة هي مسؤولية مشتركة بينك وبين Microsoft، لذلك تتناول المقالة أيضا طرقا لك لبناء حل مرن يلبي احتياجاتك.

Azure App Service هي خدمة تستند إلى HTTP لاستضافة تطبيقات الويب وواجهة برمجة تطبيقات REST وخلفيات الجوال. تضيف Azure App Service قوة Microsoft Azure إلى تطبيقك، مع إمكانات الأمان وموازنة التحميل والتحجيم التلقائي والإدارة التلقائية. لاستكشاف كيف يمكن لخدمة تطبيقات Azure تعزيز موثوقية ومرونة حمل عمل التطبيق الخاص بك، راجع لماذا تستخدم App Service؟

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

توصيات نشر الإنتاج

بالنسبة إلى عمليات توزيع الإنتاج، يجب عليك:

  • استخدم خطط خدمة التطبيقات المتميزة v3.
  • تمكين التكرار في المنطقة، والذي يتطلب من خطة App Service استخدام ثلاثة مثيلات كحد أدنى.
  • تمكين التكرار في المنطقة، والذي يتطلب من خطة App Service استخدام ثلاثة مثيلات كحد أدنى.

أخطاء عابرة

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

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

على الرغم من أن SDKs التي توفرها Microsoft عادة ما تتعامل مع الأخطاء العابرة، لأنك تستضيف تطبيقاتك الخاصة على Azure App Service، تحتاج إلى التفكير في كيفية تجنب التسبب في أخطاء عابرة عن طريق التأكد من أنك:

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

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

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

دعم منطقة القابلية للوصول

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

يتم تحديد انتشار المثيل مع نشر المنطقة المكررة داخل القواعد التالية، حتى مع تحجيم التطبيق داخل وخارج:

  • الحد الأدنى لعدد مثيلات خطة App Service هو ثلاثة.
  • إذا حددت سعة أكبر من ثلاثة، وكان عدد المثيلات قابلا للقسمة على ثلاثة، يوزع المثيلات بالتساوي.
  • يتم توزيع أي عدد مثيل يتجاوز 3*N عبر المنطقتين المتبقيتين.

عندما يخصص النظام الأساسي ل App Service مثيلات لخطة App Service المكررة في المنطقة، فإنه يستخدم موازنة منطقة أفضل جهد تقدمها مجموعات مقياس الجهاز الظاهري Azure الأساسية. تكون خطة App Service "متوازنة" إذا كانت كل منطقة تحتوي على نفس عدد الأجهزة الظاهرية، أو +/- جهاز ظاهري واحد، في جميع المناطق الأخرى التي تستخدمها خطة App Service.

بالنسبة لخطط App Service التي لم يتم تكوينها كتكرار للمنطقة، فإن مثيلات الجهاز الظاهري ليست مرنة في مواجهة حالات فشل منطقة التوفر. يمكنهم تجربة وقت تعطل أثناء انقطاع التيار الكهربائي في أي منطقة في تلك المنطقة.

المتطلبات

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

المناطق المدعومة

يمكن نشر خطط App Service المكررة في المنطقة في أي منطقة تدعم مناطق التوفر.

لمعرفة المناطق التي تدعم مناطق التوفر ل App Service Environment v3، راجع المناطق.

الاعتبارات

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

التكلفة

عند استخدام خطط App Service Premium v2 أو Premium v3، لا توجد تكلفة إضافية مرتبطة بتمكين مناطق التوفر طالما أن لديك ثلاثة مثيلات أو أكثر في خطة App Service. سيتم تحصيل رسوم منك استناداً إلى خطة App Service SKU والسعة التي تحددها وأي مثيلات تقوم بتحجيمها استناداً إلى معايير التحجيم التلقائي. إذا قمت بتمكين مناطق التوفر ولكن حددت سعة أقل من ثلاثة، يفرض النظام الأساسي الحد الأدنى لعدد المثيلات من ثلاثة ويفرض عليك رسوما لتلك المثيلات الثلاثة.

لدى App Service Environment v3 نموذج تسعير محدد لتكرار المنطقة. للحصول على معلومات التسعير ل App Service Environment v3، راجع التسعير.

تكوين دعم منطقة التوفر

لاستخدام تكرار المنطقة، قم بالتبديل إلى نوع خطة App Service المدعومة.

لنشر خطة Azure App Service جديدة مكررة في المنطقة، حدد الخيار Zone redundant عند نشر الخطة.

لنشر بيئة خدمة تطبيق Azure جديدة مكررة في المنطقة، راجع إنشاء بيئة خدمة التطبيقات.

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

تخطيط القدرات وإدارتها

للتحضير لفشل منطقة التوفر، يجب الإفراط في توفير سعة الخدمة للتأكد من أن الحل يمكن أن يتسامح مع فقدان السعة 1/3 والاستمرار في العمل دون انخفاض الأداء أثناء الانقطاع على مستوى المنطقة. نظراً لأن النظام الأساسي ينشر الأجهزة الظاهرية عبر ثلاث مناطق وتحتاج إلى حساب فشل منطقة واحدة على الأقل، فقم بضرب ذروة عدد مثيلات حمل العمل بعامل المناطق/(المناطق-1) أو 3/2. على سبيل المثال، إذا كان حمل العمل الذروة النموذجي يتطلب أربعة مثيلات، يجب توفير ستة مثيلات: (2/3 * 6 مثيلات) = 4 مثيلات.

توجيه نسبة استخدام الشبكة بين المناطق

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

تجربة المنطقة لأسفل

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

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

إعادة توجيه حركة المرور: عندما تكون المنطقة غير متوفرة، تكتشف Azure App Service المثيلات المفقودة من تلك المنطقة. يحاول تلقائيا العثور على مثيلات استبدال جديدة. ثم ينشر نسبة استخدام الشبكة عبر المثيلات الجديدة حسب الحاجة.

إذا كان لديك مقياس تلقائي تم تكوينه، وإذا قرر أن هناك حاجة إلى المزيد من المثيلات، فإن التحجيم التلقائي يصدر أيضا طلبا إلى App Service لإضافة المزيد من المثيلات.

إشعار

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

هام

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

إرجاع الموارد

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

اختبار حالات فشل المنطقة

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

الدعم متعدد المناطق

Azure App Service هي خدمة من منطقة واحدة. إذا أصبحت المنطقة غير متوفرة، فإن التطبيق الخاص بك غير متوفر أيضا.

حلول بديلة متعددة المناطق

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

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

على سبيل المثال البنيات التي توضح هذا النهج، راجع:

للمتابعة مع برنامج تعليمي ينشئ تطبيقا متعدد المناطق، راجع البرنامج التعليمي: إنشاء تطبيق متعدد المناطق متوفر بشكل كبير في Azure App Service.

للحصول على مثال للنهج الذي يوضح هذه البنية، راجع توزيع المؤسسة عالي التوفر باستخدام App Service Environment.

نسخ احتياطية

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

اتفاقية على مستوى الخدمة (SLA)

تصف اتفاقية مستوى الخدمة (SLA) ل Azure App Service التوفر المتوقع للخدمة. كما يصف الشروط التي يجب الوفاء بها لتحقيق توقعات التوفر هذه. لفهم هذه الشروط، من المهم مراجعة اتفاقيات مستوى الخدمة (SLA) للخدمات عبر الإنترنت.

عند نشر خطة App Service المكررة في المنطقة، تزداد نسبة وقت التشغيل المحددة في اتفاقية مستوى الخدمة.

المحتوى ذو الصلة