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

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

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

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

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

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

• استخدم خطط خدمة التطبيقات المتميزة v3/v4.

• تمكين تكرار المنطقة. للتعرف على متطلبات تكرار المنطقة وكيفية تمكينها، راجع قسم دعم منطقة التوفر

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

أخطاء عابرة

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

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

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

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

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

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

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

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

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

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

دعم المنطقة

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

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

المتطلبات

يجب استخدام أنواع خطط Premium v2-4. لعرض مزيد من المعلومات، تأكد من تحديد المستوى المناسب في أعلى هذه الصفحة.

• يجب استخدام أنواع خطط Premium v2-4 أو Isolated v2 وأن يكون لديك مثيلان على الأقل من الخطة.

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

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

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

  az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
  

• يجب نشر مثيلين على الأقل في خطتك.

الاعتبارات

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

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

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

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

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

  az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
  

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

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

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

  az rest --method get --url https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/instances?api-version=2024-04-01
  

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

التكلفة

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

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

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

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

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

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

• إنشاء خطة App Service جديدة مع تكرار المنطقة. لنشر خطة App Service جديدة مكررة للمنطقة، حدد الخيار Zone redundant عند نشر الخطة في مدخل Microsoft Azure أو تعيين خاصية خطة zoneRedundant App Service إلى true في أمر Azure CLI أو أمر Azure PowerShell أو ملف Bicep أو قالب Azure Resource Manager:

  az appservice plan create -g MyResourceGroup -n MyPlan --zone-redundant --number-of-workers 2 --sku P1V3
  

  إشعار

  إذا كنت تستخدم Azure CLI لتعديل الخاصية zone-redundant ، يجب تحديد --number-of-workers الخاصية ، وهي عدد المثيلات، واستخدام سعة أكبر من أو تساوي 2.

  Bicep

  resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
      name: appServicePlanName
      location: location
      sku: {
          name: sku
          capacity: 2
      }
      kind: 'linux'
      properties: {
          reserved: true
          zoneRedundant: true
      }
  }
  

• ترحيل خطة App Service موجودة إلى تكرار المنطقة. إذا كانت لديك خطة App Service موجودة تدعم تكرار المنطقة (الحد الأقصى للمناطق المتاحة أكبر من 1)، يمكنك تمكين تكرار المنطقة عن طريق تعيين خاصية خطة zoneRedundant App Service إلى true في Azure CLI أو ملف Bicep أو قالب Resource Manager الخاص بك:

  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
  

  إشعار

  إذا كنت تستخدم Azure CLI لتعديل الخاصية zoneRedundant ، يجب تحديد sku.capacity الخاصية ، وهي عدد المثيلات، واستخدام سعة أكبر من أو تساوي 2.

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

  إشعار

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

• تعطيل تكرار المنطقة. لتعطيل التكرار في المنطقة، قم بتعيين خاصية خطة zoneRedundant App Service إلى false أو استخدم Azure CLI:

  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
  

  إشعار

  إذا كنت تستخدم Azure CLI لتعطيل الخاصية zoneRedundant ، يجب تحديد الخاصية sku.capacity ، وإلا تعيين القيمة افتراضيا إلى 1.

• إنشاء خطة App Service جديدة مع تكرار المنطقة.

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

  2. لإنشاء خطة App Service في مدخل Microsoft Azure، حدد Zone redundant. لإنشاء الخطة باستخدام أمر Azure CLI أو أمر Azure PowerShell أو ملف Bicep أو قالب Resource Manager، قم بتعيين خاصية خطة zoneRedundant App Service إلى true، كما في نموذج التعليمات البرمجية التالي:

  az appservice plan create -g MyResourceGroup -n MyPlan --app-service-environment MyAse --zone-redundant --number-of-workers 2 --sku I1V2
  

  إشعار

  إذا كنت تستخدم Azure CLI لتعديل الخاصية zoneRedundant ، يجب تحديد number-of-workers الخاصية ، وهي عدد المثيلات، واستخدام سعة أكبر من أو تساوي 2.

  Bicep

  resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
      name: appServicePlanName
      location: location
      hostingEnvironmentProfile: {
          id: '...'
      }
      sku: {
          name: sku
          capacity: 2
      }
      kind: 'linux'
      properties: {
          reserved: true
          zoneRedundant: true
      }
  }
  

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

  az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=true
  

  Bicep

  resource asev3 'Microsoft.Web/hostingEnvironments@2020-12-01' = {
      name: aseName
      location: location
      kind: 'ASEV3'
      dependsOn: [
          virtualnetwork
      ] 
      properties: {
          ...
          zoneRedundant: true
      }
  }
  

  إشعار

  عند تغيير حالة تكرار المنطقة ل App Service Environment، يمكنك بدء ترقية تستغرق 12-24 ساعة لإكمالها. أثناء عملية الترقية، لا تواجه أي مشاكل في وقت التعطل أو الأداء.

  بالنسبة لخطط App Service v2 المعزولة، إذا كانت App Service Environment زائدة عن الحاجة في المنطقة، يمكن جعل خطط App Service زائدة عن الحاجة في المنطقة. تحتوي كل خطة App Service على إعداد التكرار للمنطقة المستقلة الخاصة بها، ما يعني أنه يمكنك الحصول على مزيج من الخطط المكررة للمنطقة وغير المتكررة في بيئة خدمة التطبيقات. لتمكين تكرار المنطقة على خطة Isolated v2 App Service، قم بتعيين خاصية خطة zoneRedundant App Service إلى true Azure CLI أو استخدمه.

  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
  

  إشعار

  إذا كنت تستخدم Azure CLI لتعديل الخاصية zoneRedundant ، يجب تحديد sku.capacity الخاصية ، وهي عدد المثيلات، واستخدام سعة أكبر من أو تساوي 2.

  Bicep

  resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
      name: appServicePlanName
      location: location
      hostingEnvironmentProfile: {
          id: '...'
      }
      sku: {
          name: sku
          capacity: 2
      }
      kind: 'linux'
      properties: {
          reserved: true
          zoneRedundant: true
      }
  }
  

• تعطيل تكرار المنطقة. لتعطيل التكرار في المنطقة، يمكنك تعيين خطة App Service أو خاصية App Service Environment zoneRedundant إلى false أو استخدام Azure CLI:

  az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=false
  
  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
  

  إشعار

  إذا كنت تستخدم Azure CLI لتعطيل الخاصية zoneRedundant ، يجب تحديد الخاصية sku.capacity ، وإلا تعيين القيمة افتراضيا إلى 1.

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

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

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

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

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

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

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

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

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

• الكشف والاستجابة: يكتشف النظام الأساسي ل App Service تلقائيا حالات الفشل في منطقة التوفر ويبدأ الاستجابة. لا يلزم تدخل يدوي لبدء تجاوز فشل المنطقة.

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

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

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

  هام

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

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

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

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

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

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

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

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

نهج بديلة متعددة المناطق

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

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

ترتبط الموارد التالية بهذا النهج:

• بنية مرجعية: تطبيق ويب متعدد المناطق متوفر بشكل كبير

• النهج التي يجب مراعاتها

• البرنامج التعليمي: إنشاء تطبيق متعدد المناطق متوفر بشكل كبير في App Service

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

نسخ احتياطية

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

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

الموثوقية أثناء صيانة الخدمة

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

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

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

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

لمعرفة المزيد حول تفضيلات الصيانة، راجع تفضيلات الترقية للصيانة المخطط لها لبيئة خدمة التطبيقات.

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

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

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

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

• الموثوقية في Azure