إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
App Service Environment هي ميزة Azure App Service توفر بيئة معزولة تماما ومخصصة لتشغيل تطبيقات App Service بأمان على نطاق واسع. كخدمة Azure، توفر App Service Environment مجموعة من الإمكانات لدعم متطلبات الموثوقية الخاصة بك.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
توضح هذه المقالة دعم الموثوقية في App Service Environment، بما في ذلك المرونة في مواجهة الأخطاء العابرة وفشل منطقة التوفر والانقطاعات على مستوى المنطقة. كما يصف استراتيجيات النسخ الاحتياطي والمرونة لصيانة الخدمة، ويسلط الضوء على بعض المعلومات الأساسية حول اتفاقية مستوى خدمة App Service Environment (SLA).
Note
على عكس عرض App Service العام متعدد المستأجرين الذي يشارك البنية الأساسية الداعمة، توفر App Service Environment موارد حوسبة مخصصة وعزل شبكة محسنة لعميل واحد.
توفر البيئة مزايا الموثوقية الرئيسية التالية:
- موارد الحوسبة المخصصة التي لا تتم مشاركتها مع عملاء آخرين
- عزل محسن للشبكة لتحسين الأمان والاستقرار
- القدرة على النشر في شبكتك الظاهرية لمزيد من التحكم في توجيه نسبة استخدام الشبكة ونهج الأمان
لمزيد من المعلومات حول دعم الموثوقية في App Service، راجع الموثوقية في App Service.
توصيات نشر الإنتاج للموثوقية
نوصي بتمكين تكرار المنطقة على بيئتك وخطط App Service، الأمر الذي يتطلب أن تستخدم خططك مثيلين على الأقل.
نظرة عامة على بنية الموثوقية
عند تنفيذ App Service Environment، يمكنك نشر البيئة كحاوية لخطط App Service وتطبيقات الويب. أثناء الإعداد، قم بتكوين إعدادات الشبكة الأساسية وعزل الأجهزة الاختياري. اختر ما إذا كنت تريد دعم تكرار المنطقة على البيئة إذا كانت المنطقة تدعم مناطق التوفر.
بعد إنشاء بيئتك، يمكنك إنشاء خطة واحدة أو أكثر من خطط App Service.
تحدد خطة App Service مجموعة من موارد الحوسبة التي تقوم بتشغيل تطبيقات الويب الخاصة بك. يجب تشغيل جميع تطبيقات الويب داخل خطة. يمكنك توسيع نطاق خطة للتشغيل على مثيلات جهاز ظاهري متعددة، تسمى أيضا العمال. توفر هذه المثيلات موارد الحوسبة التي تقوم بتشغيل التعليمات البرمجية للتطبيق الخاص بك. يمكن أن تستضيف خطة App Service واحدة تطبيقات متعددة. تعمل جميع التطبيقات على نفس المجموعة المشتركة من مثيلات الجهاز الظاهري.
لاستخدام App Service Environment، يجب أن تستخدم خططك مستوى تسعير الإصدار 2 المعزول. تدعم هذه الطبقة التكرار في المنطقة والتطبيقات عالية النطاق ذات المهام الحرجة.
توفر 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. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
يمكنك تكوين بيئة خدمة التطبيقات الخاصة بك كمنطقة زائدة عن الحاجة. يمكنك أيضا تكوين خطط App Service الخاصة بك لتكون زائدة عن الحاجة في المنطقة، والتي توزعها عبر مناطق توفر متعددة.
ومع ذلك، يمكنك تمكين تكرار المنطقة أو تعطيله على كل خطة. وهذا يعني أنه يمكن أن يكون لديك بعض الخطط في البيئة الخاصة بك التي هي منطقة زائدة عن الحاجة وغيرها غير ذلك.
عند إنشاء خطة App Service مكررة في المنطقة في بيئتك، يتم توزيع مثيلات خطة App Service عبر مناطق التوفر في المنطقة. لمزيد من المعلومات، راجع توزيع المثيل عبر المناطق.
Requirements
لتمكين تكرار المنطقة لبيئة خدمة التطبيقات، يجب أن تفي بالمتطلبات التالية:
دعم المنطقة: لمعرفة المناطق التي تدعم مناطق التوفر ل App Service Environment v3، راجع المناطق.
نوع الخطة: استخدم أنواع خطط الإصدار 2 المعزولة.
الحد الأدنى لعدد المثيلات: انشر مثيلين على الأقل في خطتك.
وحدة القياس: يجب نشر بيئتك إلى وحدة قياس تدعم مناطق التوفر. لا تتحكم بشكل مباشر في وحدة القياس التي تستخدمها بيئتك. بدلا من ذلك، عند إنشاء بيئة App Service، يتم تعيين البيئة إلى وحدة قياس استنادا إلى مجموعة موارد البيئة. لتحديد ما إذا كانت وحدة القياس لبيئة خدمة التطبيقات الخاصة بك تدعم تكرار المنطقة، تحقق من دعم تكرار المنطقة لبيئة خدمة التطبيقات.
إذا كانت بيئتك على وحدة قياس لا تدعم مناطق التوفر، فلا يمكنك تمكين تكرار المنطقة على بيئتك أو خططك. بدلا من ذلك، تحتاج إلى إنشاء بيئة جديدة في مجموعة موارد جديدة، وإعادة توزيع تطبيقاتك إلى خطط جديدة داخل تلك البيئة.
متطلبات التكوين: قم بتكوين كل من App Service Environment وخططك لدعم تكرار المنطقة. يمكنك تمكين تكرار المنطقة أثناء إنشاء البيئة أو عن طريق تحديث بيئة موجودة.
توزيع المثيل عبر المناطق
عند إنشاء خطة App Service زائدة عن الحاجة في المنطقة، يوزع Azure مثيلات الخطة عبر مناطق التوفر في المنطقة. يضمن هذا التوزيع بقاء تطبيقاتك متاحة حتى إذا واجهت إحدى المناطق انقطاعا.
يتبع توزيع المثيل في توزيع المنطقة المكررة قواعد محددة. تنطبق هذه القواعد أيضا مع توسيع نطاق التطبيق وإخراجه:
الحد الأدنى من الحالات: يجب أن تحتوي خطة App Service على مثيلين على الأقل لتكرار المنطقة.
الحد الأقصى لمناطق التوفر المدعومة بخطتك: يحدد Azure عدد مناطق التوفر التي يمكن لخطتك استخدامها، والتي يشار إليها باسم maximumNumberOfZones. لعرض عدد مناطق التوفر التي يمكن أن تستخدمها خطتك المحددة، راجع التحقق من دعم التكرار في المنطقة لخطة App Service.
توزيع المثيل: عند تمكين تكرار المنطقة، يوزع Azure مثيلات الخطة عبر مناطق توفر متعددة تلقائيا. يعتمد التوزيع على القواعد التالية:
إذا تجاوز عدد المثيلات maxumNumberOfZones وقسم بالتساوي، يقوم Azure بتوزيع المثيلات بالتساوي عبر المناطق.
إذا لم يتم تقسيم عدد المثيلات بالتساوي، يقوم Azure بتوزيع المثيلات المتبقية عبر المناطق المتبقية.
عندما يخصص النظام الأساسي ل App Service مثيلات لخطة App Service المكررة في المنطقة، فإنه يستخدم موازنة المنطقة بأفضل جهد التي توفرها مجموعات مقياس الجهاز الظاهري Azure الأساسية. تكون الخطة متوازنة إذا كانت كل منطقة تحتوي على نفس عدد الأجهزة الظاهرية أو تختلف بمثيل واحد عن جميع المناطق الأخرى. لمزيد من المعلومات، راجع موازنة المنطقة.
موضع المنطقة المادية: يمكنك عرض منطقة التوفر الفعلي المستخدمة لكل مثيل من مثيلات خطة App Service. لمزيد من المعلومات، راجع عرض المناطق الفعلية لخطة App Service.
Considerations
قد يؤثر انقطاع منطقة التوفر على بعض جوانب App Service، على الرغم من استمرار التطبيق في خدمة حركة المرور. تتضمن هذه السلوكيات توسيع نطاق خطة App Service وإنشاء التطبيق وتكوين التطبيق ونشر التطبيق.
عند تمكين تكرار المنطقة في خطة App Service، فإنك تقوم أيضا بتحسين المرونة أثناء تحديثات النظام الأساسي. لمزيد من المعلومات، راجع المرونة لصيانة الخدمة.
بالنسبة لخطط App Service غير الزائدة عن الحاجة في المنطقة، فإن مثيلات الجهاز الظاهري الأساسية ليست مرنة لحالات فشل منطقة التوفر. يمكنهم تجربة وقت تعطل أثناء انقطاع التيار الكهربائي في أي منطقة في تلك المنطقة.
Cost
يمكنك تمكين تكرار المنطقة على App Service Environment أو خططها دون أي تكلفة إضافية. ومع ذلك، يتطلب تكرار المنطقة لخطة ما أن تحتوي على مثيلين أو أكثر. يتم تحصيل الرسوم منك استنادا إلى خطة App Service SKU والسعة التي تحددها وأي مثيلات تقوم بتحجيمها استنادا إلى معايير التحجيم التلقائي.
إذا قمت بتمكين مناطق التوفر وحددت سعة أقل من مثيلين، فإن النظام الأساسي يفرض مثيل اثنين كحد أدنى. يفرض النظام الأساسي رسوما عليك مقابل هذين المثيلين.
Important
عند تمكين مناطق التوفر لبيئة خدمة التطبيقات، يتم تحجيم جميع خطط App Service التي تحتوي على أقل من 3 مثيلات إلى 3 مثيلات. أي خطة تحتوي على 3 مثيلات أو أكثر تظل دون تغيير. بمجرد اكتمال عملية تمكين مناطق التوفر، يمكنك توسيع نطاق خطط App Service حسب الحاجة، بما في ذلك إلى أقل من 3 مثيلات.
تكوين دعم منطقة التوفر
لمعرفة كيفية إنشاء بيئة خدمة تطبيقات جديدة زائدة عن الحاجة في المنطقة وخطط خدمة تطبيقات جديدة زائدة عن الحاجة في المنطقة، راجع تكوين بيئات خدمة التطبيقات وخطط خدمة التطبيقات المعزولة v2 لتكرار المنطقة.
Note
يستغرق التغيير في حالة تكرار المنطقة لبيئة App Service من 12 إلى 24 ساعة حتى يكتمل. أثناء عملية الترقية، لا تحدث أي مشكلات في التوقف عن العمل أو الأداء.
تخطيط القدرات وإدارتها
للاستعداد لفشل منطقة التوفر، ضع في اعتبارك الإفراط في توفير سعة خطة 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 Environments في كل منطقة.
- تكوين نهج موازنة التحميل وتجاوز الفشل.
- قم بنسخ بياناتك عبر المناطق بحيث يمكنك استرداد حالة التطبيق الأخيرة.
للحصول على مثال للنهج الذي يوضح هذه البنية، راجع نشر مؤسسة قابلية وصول عالية باستخدام App Service Environment.
النسخ الاحتياطي والاستعادة
لإجراء نسخ احتياطي لتطبيقات App Service إلى ملف، استخدم إمكانات النسخ الاحتياطي والاستعادة في App Service.
تساعد هذه الإمكانات عندما يكون من الصعب إعادة نشر التعليمات البرمجية أو عند تخزين الحالة على القرص. يجب ألا تعتمد معظم الحلول حصريا على النسخ الاحتياطية. بدلا من ذلك، استخدم الإمكانات الأخرى في هذا الدليل لدعم متطلبات المرونة الخاصة بك. ومع ذلك، تحمي النسخ الاحتياطية من بعض المخاطر التي لا تحميها الأساليب الأخرى.
Important
اعتبارا من 31 مارس 2028، لن تدعم النسخ الاحتياطية المخصصة ل Azure App Service النسخ الاحتياطي لقواعد البيانات المرتبطة. راجع إهمال النسخ الاحتياطية لقاعدة البيانات المرتبطة لمزيد من المعلومات.
بدلا من ذلك ، استخدم أدوات النسخ الاحتياطي والاستعادة الأصلية لقاعدة البيانات المرتبطة الخاصة بك. لمزيد من المعلومات، راجع النسخ الاحتياطي للتطبيق واستعادته في App Service.
المرونة في صيانة الخدمة
تقوم App Service بإجراء ترقيات منتظمة للخدمة ومهام الصيانة الأخرى. للحفاظ على السعة المتوقعة أثناء الترقية، يضيف النظام الأساسي تلقائيا مثيلات إضافية من خطة App Service أثناء عملية الترقية.
تمكين تكرار المنطقة. عند تمكين تكرار المنطقة في خطة App Service، فإنك تقوم أيضا بتحسين المرونة أثناء تحديثات النظام الأساسي. تتكون مجالات التحديث من مجموعات من الأجهزة الظاهرية التي توضع في وضع عدم الاتصال أثناء التحديث، ويتم تعيينها إلى مناطق التوفر. يضيف نشر مثيلات متعددة في خطة App Service وتمكين تكرار المنطقة لخطتك طبقة إضافية من المرونة إذا أصبح المثيل أو المنطقة غير سليمة أثناء الترقية.
تخصيص دورة الترقية. يمكنك تخصيص دورة الترقية لبيئة خدمة التطبيقات. إذا كنت بحاجة إلى التحقق من تأثير الترقيات على حمل العمل الخاص بك، فقم بتمكين الترقيات اليدوية. يسمح لك هذا الأسلوب بإجراء التحقق من الصحة والاختبار على مثيل غير إنتاجي قبل تطبيقه على مثيل الإنتاج الخاص بك.
لمزيد من المعلومات حول تفضيلات الصيانة، راجع تفضيلات الترقية للصيانة المخططة لبيئة خدمة التطبيقات.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
عند نشر خطة App Service المكررة في المنطقة، تزداد نسبة وقت التشغيل المحددة في اتفاقية مستوى الخدمة.