الموثوقية في 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، والتي تمثل عمال الحوسبة الذين يديرون التعليمات البرمجية للتطبيق الخاص بك. لمزيد من المعلومات، راجع خطة Azure App Service. على الرغم من أن النظام الأساسي يبذل جهدا لنشر المثيلات عبر مجالات خطأ مختلفة، فإنه لا ينشر المثيلات تلقائيا عبر مناطق التوفر.
توصيات نشر الإنتاج
بالنسبة إلى عمليات توزيع الإنتاج، يجب عليك:
- استخدم خطط خدمة التطبيقات المتميزة v3.
- تمكين التكرار في المنطقة، والذي يتطلب من خطة App Service استخدام ثلاثة مثيلات كحد أدنى.
- تمكين التكرار في المنطقة، والذي يتطلب من خطة App Service استخدام ثلاثة مثيلات كحد أدنى.
أخطاء عابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. إنهم يصححون أنفسهم بعد فترة زمنية قصيرة. من المهم أن تتعامل تطبيقاتك مع الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة من Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمعرفة المزيد حول معالجة الأخطاء العابرة، راجع توصيات تسليم الأخطاء العابرة.
عادة ما تعالج SDKs التي توفرها Microsoft الأخطاء العابرة. نظرا لأنك تستضيف تطبيقاتك الخاصة على Azure App Service، فكر في كيفية تجنب التسبب في أخطاء عابرة عن طريق التأكد من أنك:
نشر مثيلات متعددة من خطتك. تقوم Azure App Service بإجراء تحديثات تلقائية وأشكال أخرى من الصيانة على مثيلات خطتك. إذا أصبح المثيل غير صحي، يمكن للخدمة استبدال هذا المثيل تلقائيا بمثيل سليم جديد. أثناء عملية الاستبدال، يمكن أن تكون هناك فترة قصيرة عندما يكون المثيل السابق غير متوفر ومثيل جديد غير جاهز بعد لخدمة نسبة استخدام الشبكة. يمكنك التخفيف من تأثير هذا السلوك عن طريق نشر مثيلات متعددة من خطة App Service.
استخدم فتحات النشر. تسمح فتحات توزيع Azure App Service بنشر تطبيقاتك دون توقف. استخدم فتحات النشر لتقليل تأثير عمليات النشر وتغييرات التكوين للمستخدمين. يقلل استخدام فتحات النشر أيضا من احتمال إعادة تشغيل التطبيق الخاص بك. تؤدي إعادة التشغيل إلى حدوث خطأ عابر.
تجنب التوسع صعوداً أو لأسفل. بدلا من ذلك، حدد مستوى وحجم مثيل يلبي متطلبات الأداء الخاصة بك تحت الحمل النموذجي. توسيع نطاق المثيلات فقط لمعالجة التغييرات في حجم حركة المرور. يمكن أن يؤدي التحجيم لأعلى ولأسفل إلى إعادة تشغيل التطبيق.
دعم منطقة القابلية للوصول
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل كل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
لمزيد من المعلومات حول مناطق التوفر في Azure، راجع ما هي مناطق التوفر؟
يمكن تكوين Azure App Service كمنطقة زائدة عن الحاجة، ما يعني أن مواردك موزعة عبر مناطق توفر متعددة. يساعد الانتشار عبر مناطق متعددة أحمال العمل الإنتاجية على تحقيق المرونة والموثوقية. دعم منطقة التوفر هو خاصية لخطة App Service.
يتم تحديد انتشار المثيل مع نشر المنطقة المكررة باستخدام القواعد التالية. تنطبق هذه القواعد حتى مع تحجيم التطبيق وتحجيمه:
- الحد الأدنى لعدد مثيلات خطة App Service هو ثلاثة.
- تنتشر المثيلات بالتساوي إذا حددت سعة أكبر من ثلاثة، وكان عدد المثيلات قابلا للقسمة على ثلاثة.
- يتم توزيع أي عدد مثيل يتجاوز 3*N عبر المنطقتين المتبقيتين.
عندما يخصص النظام الأساسي ل App Service مثيلات لخطة App Service المكررة في المنطقة، فإنه يستخدم موازنة منطقة أفضل جهد تقدمها مجموعات مقياس الجهاز الظاهري Azure الأساسية. تكون خطة App Service متوازنة إذا كانت كل منطقة تحتوي على نفس عدد الأجهزة الظاهرية، أو بالإضافة إلى واحد أو ناقصه، في جميع المناطق الأخرى. لمزيد من المعلومات، راجع موازنة المنطقة.
بالنسبة لخطط App Service التي لم يتم تكوينها كتكرار للمنطقة، لا تتسم مثيلات الجهاز الظاهري بالمرونة في مواجهة حالات فشل منطقة التوفر. يمكنهم تجربة وقت تعطل أثناء انقطاع التيار الكهربائي في أي منطقة في تلك المنطقة.
المناطق المدعومة
يمكن نشر خطط App Service المكررة في المنطقة في أي منطقة تدعم مناطق التوفر.
لمعرفة المناطق التي تدعم مناطق التوفر ل App Service Environment v3، راجع المناطق.
المتطلبات
يتم دعم مناطق التوفر فقط على بصمة App Service الأحدث. حتى إذا كنت تستخدم إحدى المناطق المدعومة، إذا لم تكن مناطق التوفر مدعومة لمجموعة الموارد الخاصة بك، فستتلقى خطأ. للتأكد من أن أحمال العمل الخاصة بك تهبط على طابع يدعم مناطق التوفر، قد تحتاج إلى إنشاء مجموعة موارد جديدة وخطة App Service وخدمة التطبيقات.
- يجب نشر ما لا يقل عن ثلاثة مثيلات لخطتك.
الاعتبارات
تستمر التطبيقات التي يتم نشرها في خطة 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، راجع التسعير.
تكوين دعم منطقة التوفر
لنشر خطة Azure App Service جديدة مكررة في المنطقة، حدد الخيار Zone redundant عند نشر الخطة.
لنشر بيئة خدمة تطبيق Azure جديدة مكررة في المنطقة، راجع إنشاء بيئة خدمة التطبيقات.
يمكن تكوين تكرار المنطقة فقط عند إنشاء خطة App Service جديدة. إذا كانت لديك خطة App Service موجودة ليست متكررة في المنطقة، فاستبدلها بخطة جديدة مكررة للمنطقة. لا يمكنك تحويل خطة App Service موجودة لاستخدام مناطق التوفر. وبالمثل، لا يمكنك تعطيل تكرار المنطقة على خطة App Service موجودة.
تخطيط القدرات وإدارتها
للتحضير لفشل منطقة التوفر، يجب الإفراط في توفير سعة الخدمة. يضمن هذا النهج أن الحل يمكن أن يتسامح مع فقدان 1/3 من السعة والاستمرار في العمل دون انخفاض الأداء أثناء الانقطاعات على مستوى المنطقة. نظرا لأن النظام الأساسي ينشر الأجهزة الظاهرية عبر ثلاث مناطق وتحتاج إلى حساب فشل منطقة واحدة على الأقل، اضرب ذروة عدد مثيلات حمل العمل بعامل zones/(zones-1)أو 3/2. على سبيل المثال، إذا كان حمل العمل الذروة النموذجي يتطلب أربعة مثيلات، يجب توفير ستة مثيلات: (2/3 * 6 مثيلات) = 4 مثيلات.
توجيه نسبة استخدام الشبكة بين المناطق
أثناء العمليات العادية، يتم توجيه نسبة استخدام الشبكة بين جميع مثيلات خطة App Service المتوفرة عبر جميع مناطق التوفر.
تجربة المنطقة لأسفل
الكشف والاستجابة. النظام الأساسي لخدمة التطبيقات مسؤول عن الكشف عن فشل في منطقة توفر والاستجابة. لا تحتاج إلى القيام بأي شيء لبدء تجاوز فشل المنطقة.
الطلبات النشطة. عندما تكون منطقة التوفر غير متوفرة، يتم إنهاء أي طلبات قيد التقدم متصلة بمثيل خطة App Service في منطقة التوفر المعيبة. يجب إعادة المحاولة.
إعادة توجيه نسبة استخدام الشبكة. عندما تكون المنطقة غير متوفرة، تكتشف Azure App Service المثيلات المفقودة من تلك المنطقة. يحاول تلقائيا العثور على مثيلات استبدال جديدة. ثم ينشر نسبة استخدام الشبكة عبر المثيلات الجديدة حسب الحاجة.
إذا كان لديك مقياس تلقائي تم تكوينه، وإذا قرر أن هناك حاجة إلى المزيد من المثيلات، فإن التحجيم التلقائي يصدر أيضا طلبا إلى App Service لإضافة المزيد من المثيلات. لمزيد من المعلومات، راجع توسيع نطاق تطبيق في Azure App Service.
إشعار
سلوك التحجيم التلقائي مستقل عن سلوك النظام الأساسي لخدمة التطبيقات. لا تحتاج مواصفات عدد مثيلات التحجيم التلقائي إلى أن تكون مضاعفا لثلاثة.
هام
لا يوجد ما يضمن نجاح طلبات المزيد من المثيلات في سيناريو خفض المنطقة. يحدث الملء الخلفي للمثيلات المفقودة على أساس أفضل جهد. إذا كنت بحاجة إلى سعة مضمونة عند فقدان منطقة توفر، فيجب عليك إنشاء خطط App Service وتكوينها لحساب فقدان منطقة. يمكنك القيام بذلك عن طريق الإفراط في توفير سعة خطة App Service.
إرجاع الموارد
عند استرداد منطقة التوفر، تقوم Azure App Service تلقائيا بإنشاء مثيلات في منطقة التوفر المستردة، وإزالة أي مثيلات مؤقتة تم إنشاؤها في مناطق التوفر الأخرى، وتوجيه نسبة استخدام الشبكة بين مثيلاتك كالمعتاد.
اختبار حالات فشل المنطقة
يدير النظام الأساسي ل Azure App Service توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الموارد لخطط App Service المكررة في المنطقة. نظرا لإدارة هذه الميزة بالكامل، لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها.
الدعم متعدد المناطق
Azure App Service هي خدمة من منطقة واحدة. إذا أصبحت المنطقة غير متوفرة، فإن التطبيق الخاص بك غير متوفر أيضا.
حلول بديلة متعددة المناطق
للتأكد من أن التطبيق الخاص بك يصبح أقل عرضة لفشل منطقة واحدة، تحتاج إلى نشر التطبيق الخاص بك إلى مناطق متعددة:
- نشر التطبيق الخاص بك إلى المثيلات في كل منطقة.
- تكوين نهج موازنة التحميل وتجاوز الفشل.
- قم بنسخ بياناتك عبر المناطق بحيث يمكنك استرداد حالة التطبيق الأخيرة.
على سبيل المثال البنيات التي توضح هذا النهج، راجع:
- هندسة مرجعية: تطبيق ويب متعدد المناطق متوفر بشكل كبير.
- تطبيقات App Service متعددة المناطق للتعافي من الكوارث
للمتابعة مع برنامج تعليمي ينشئ تطبيقا متعدد المناطق، راجع البرنامج التعليمي: إنشاء تطبيق متعدد المناطق متوفر بشكل كبير في Azure App Service.
للحصول على مثال للنهج الذي يوضح هذه البنية، راجع توزيع المؤسسة عالي التوفر باستخدام App Service Environment.
نسخ احتياطية
عند استخدام المستوى الأساسي أو أعلى، يمكنك نسخ تطبيق App Service احتياطيا إلى ملف باستخدام إمكانات النسخ الاحتياطي والاستعادة لخدمة التطبيقات. لمزيد من المعلومات، راجع النسخ الاحتياطي للتطبيق واستعادته في Azure App Service.
هذه الميزة مفيدة إذا كان من الصعب إعادة نشر التعليمات البرمجية الخاصة بك، أو إذا قمت بتخزين الحالة على القرص. بالنسبة لمعظم الحلول، يجب ألا تعتمد على النسخ الاحتياطية ل App Service. استخدم الطرق الأخرى الموضحة في هذه المقالة لدعم متطلبات المرونة.
اتفاقية على مستوى الخدمة (SLA)
تصف اتفاقية مستوى الخدمة (SLA) ل Azure App Service التوفر المتوقع للخدمة. كما يصف الشروط التي يجب الوفاء بها لتحقيق توقعات التوفر هذه. لفهم هذه الشروط، راجع اتفاقيات مستوى الخدمة (SLA) للخدمات عبر الإنترنت.
عند نشر خطة App Service المكررة في المنطقة، تزداد نسبة وقت التشغيل المحددة في اتفاقية مستوى الخدمة.