مشاركة عبر

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

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

عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.

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

Note

إذا كنت تبحث عن معلومات حول دعم الموثوقية في App Service Environment، فراجع الموثوقية في App Service Environment.

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

يوفر Azure Well-Architected Framework توصيات عبر الموثوقية والأداء والأمان والتكلفة والعمليات. لفهم كيفية تأثير هذه المناطق على بعضها البعض والمساهمة في حل App Service موثوق به، راجع أفضل ممارسات البنية ل App Service (تطبيقات الويب) في Azure Well-Architected Framework.

نظرة عامة على بنية الموثوقية

عند إنشاء تطبيق ويب App Service، يمكنك تحديد خطة App Service التي تقوم بتشغيل التطبيق.

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

توفر App Service ميزات التكرار التالية:

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

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

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

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

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

المرونة في مواجهة الأعطال العابرة

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

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

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

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

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

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

المرونة في مواجهة حالات فشل منطقة التوفر

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

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

Requirements

لتمكين تكرار المنطقة، يجب أن تستوفي المتطلبات التالية:

توزيع المثيل عبر المناطق

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

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

  • الحد الأدنى من الحالات: يجب أن تحتوي خطة App Service على مثيلين على الأقل لتكرار المنطقة.

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

  • توزيع المثيل: عند تمكين تكرار المنطقة، يوزع Azure مثيلات الخطة عبر مناطق توفر متعددة تلقائيا. يعتمد التوزيع على القواعد التالية:

    • إذا تجاوز عدد المثيلات maxumNumberOfZones وقسم بالتساوي، يقوم Azure بتوزيع المثيلات بالتساوي عبر المناطق.

    • إذا لم يتم تقسيم عدد المثيلات بالتساوي، يقوم Azure بتوزيع المثيلات المتبقية عبر المناطق المتبقية.

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

  • موضع المنطقة المادية: يمكنك عرض منطقة التوفر الفعلي المستخدمة لكل مثيل من مثيلات خطة App Service. لمزيد من المعلومات، راجع عرض المناطق الفعلية لخطة App Service.

Considerations

بالنسبة لخطط Premium v2 إلى v4 ، قد يؤثر انقطاع منطقة التوفر على بعض جوانب Azure App Service، على الرغم من استمرار التطبيق في خدمة نسبة استخدام الشبكة. تتضمن هذه السلوكيات توسيع نطاق خطة App Service وإنشاء التطبيق وتكوين التطبيق ونشر التطبيق.

عند تمكين تكرار المنطقة على خطة App Service Premium من الإصدار 2 إلى الإصدار 4 ، فإنك تقوم أيضا بتحسين المرونة أثناء تحديثات النظام الأساسي. لمزيد من المعلومات، راجع المرونة لصيانة الخدمة.

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

Cost

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

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

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

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

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

السلوك عندما تكون جميع المناطق صحية

توضح القائمة التالية ما يمكن توقعه عند تكوين خطط App Service لتكرار المنطقة وتشغيل جميع مناطق التوفر:

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

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

السلوك أثناء فشل المنطقة

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

توضح القائمة التالية ما يمكن توقعه عند تكوين خطط App Service لتكرار المنطقة وعدم توفر منطقة توفر واحدة أو أكثر:

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

  • الطلبات النشطة: يتم إنهاء أي طلبات قيد التقدم تتصل بمثيل خطة App Service في منطقة التوفر الخاطئة. أعد محاولة هذه الطلبات.

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

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

    Important

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

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

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

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

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

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

القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة

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

حلول مخصصة متعددة المناطق للمرونة

لتقليل مخاطر حدوث فشل في منطقة واحدة يؤثر على التطبيق الخاص بك، يمكنك نشر الخطط عبر مناطق متعددة. تساعد الخطوات التالية على تعزيز المرونة:

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

ضع في اعتبارك الموارد التالية ذات الصلة:

النسخ الاحتياطي والاستعادة

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

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

Important

اعتبارا من 31 مارس 2028، لن تدعم النسخ الاحتياطية المخصصة ل Azure App Service النسخ الاحتياطي لقواعد البيانات المرتبطة. راجع إهمال النسخ الاحتياطية لقاعدة البيانات المرتبطة لمزيد من المعلومات.

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

المرونة في صيانة الخدمة

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

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

لمزيد من المعلومات، راجع الصيانة الروتينية المخطط لها لخدمة التطبيقاتوالصيانة الروتينية لخدمة التطبيقات وإعادة التشغيل ووقت التوقف عن العمل.

اتفاقية مستوى الخدمة

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

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

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

  • Last updated on