الموثوقية في Azure App Service
توضح هذه المقالة دعم الموثوقية في Azure App Service، وتغطي كلا من المرونة داخل المنطقة مع مناطق التوفر والتعافي من الكوارث عبر المناطق واستمرارية الأعمال. للحصول على نظرة عامة أكثر تفصيلا حول مبادئ الموثوقية في Azure، راجع موثوقية Azure.
Azure App Service هي خدمة مستندة إلى HTTP لاستضافة تطبيقات الويب وواجهات برمجة تطبيقات REST والنهايات الخلفية للأجهزة المحمولة؛ ويضيف قوة Microsoft Azure إلى تطبيقك، مثل:
- الأمان
- موازنة الأحمال
- التحجيم التلقائي
- الإدارة الآلية
لاستكشاف كيف يمكن لخدمة تطبيقات Azure تعزيز موثوقية ومرونة حمل عمل التطبيق الخاص بك، راجع لماذا تستخدم App Service؟
دعم منطقة القابلية للوصول
مناطق توفر Azure هي ثلاث مجموعات منفصلة فعليا على الأقل من مراكز البيانات داخل كل منطقة Azure. مراكز البيانات داخل كل منطقة مجهزة ببنية أساسية مستقلة للطاقة والتبريد والشبكات. في حالة فشل المنطقة المحلية، يتم تصميم مناطق التوفر بحيث إذا تأثرت المنطقة الواحدة، فإن الخدمات الإقليمية والسعة والتوافر العالي تدعمها المنطقتين المتبقيتين.
يمكن أن تتراوح حالات الفشل من فشل البرامج والأجهزة إلى الأحداث مثل الزلازل والفيضانات والحرائق. يتم تحقيق التسامح مع الفشل مع التكرار والعزلة المنطقية لخدمات Azure. لمزيد من المعلومات التفصيلية حول مناطق التوفر في Azure، راجع المناطق ومناطق التوفر.
تم تصميم الخدمات الممكنة لمناطق توفر Azure لتوفير المستوى الصحيح من الموثوقية والمرونة. يمكن تكوينها بطريقتين. يمكن أن تكون إما زائدة عن الحاجة للمنطقة، مع النسخ المتماثل التلقائي عبر المناطق، أو منطقة، مع تثبيت المثيلات في منطقة معينة. يمكنك أيضا الجمع بين هذه الأساليب. لمزيد من المعلومات حول البنية المناطقية مقابل البنية الزائدة عن الحاجة للمنطقة، راجع توصيات لاستخدام مناطق التوفر والمناطق.
يمكن نشر Azure App Service عبر مناطق التوفر (AZ) لمساعدتك على تحقيق المرونة والموثوقية لأحمال العمل المهمة لأعمالك. تعرف على هذه البنية أيضًا باسم تكرار المنطقة.
عند تكوين خدمة التطبيقات كمنطقة زائدة عن الحاجة، ينشر النظام الأساسي تلقائيا مثيلات خطة Azure App Service عبر ثلاث مناطق في المنطقة المحددة.
يتم تحديد انتشار المثيل مع نشر المنطقة المكررة داخل القواعد التالية، حتى مع تحجيم التطبيق داخل وخارج:
- الحد الأدنى لعدد مثيلات خطة خدمة التطبيقات هو ثلاثة.
- إذا حددت سعة أكبر من ثلاثة، وكان عدد المثيلات قابلا للقسمة على ثلاثة، يوزع المثيلات بالتساوي.
- يتم توزيع أي عدد مثيل يتجاوز 3*N عبر المنطقتين المتبقيتين.
دعم منطقة التوفر هو خاصية لخطة App Service. يمكن إنشاء خطط App Service على بيئة مدارة متعددة المستأجرين أو بيئة مخصصة باستخدام App Service Environment v3. لمعرفة المزيد حول App Service Environment v3، راجع نظرة عامة على App Service Environment v3.
بالنسبة ل App Services التي لم يتم تكوينها لتكون متكررة في المنطقة، فإن مثيلات الجهاز الظاهري ليست مرنة في المنطقة ويمكن أن تواجه وقت تعطل أثناء انقطاع التيار الكهربائي في أي منطقة في تلك المنطقة.
للحصول على معلومات حول بنية توزيع المؤسسة، راجع توزيع المؤسسات عالي التوفر باستخدام App Service Environment.
المتطلبات الأساسية
المتطلبات/القيود الحالية لتمكين مناطق التوفر هي:
يتم دعم كل من Windows وLinux.
يتم دعم مناطق التوفر فقط على بصمة App Service الأحدث. حتى إذا كنت تستخدم إحدى المناطق المدعومة، فستتلقى خطأ إذا لم تكن مناطق التوفر مدعومة لمجموعة الموارد الخاصة بك. لضمان وصول أحمال العمل إلى طابع يدعم مناطق التوفر، قد تحتاج إلى إنشاء مجموعة موارد جديدة وخطة App Service وخدمة التطبيقات.
يجب أن تكون خطة App Services إحدى الخطط التالية التي تدعم مناطق التوفر:
- في بيئة متعددة المستأجرين باستخدام خطط App Service Premium v2 أو Premium v3.
- في بيئة مخصصة باستخدام App Service Environment v3، والذي يتم استخدامه مع خطط Isolated v2 App Service.
بالنسبة للبيئات المخصصة، يجب أن تكون App Service Environment v3.
هام
سيتم إيقاف الإصدارين 2 و1 من App Service Environment في 31 أغسطس 2024. يعد الإصدار 3 من App Service Environment أسهل في الاستخدام ويعمل على بنية أساسية أكثر قوة. لمعرفة المزيد حول App Service Environment v3، راجع نظرة عامة على App Service Environment. إذا كنت تستخدم حاليا App Service Environment v2 أو v1 وتريد الترقية إلى الإصدار 3، فالرجاء اتباع الخطوات الواردة في هذه المقالة للترحيل إلى الإصدار الجديد.
يتم فرض الحد الأدنى لعدد المثيلات لثلاث مناطق. سيفرض النظام الأساسي هذا العدد الأدنى خلف الكواليس إذا قمت بتحديد عدد مثيل أقل من ثلاثة.
يمكن تحديد مناطق التوفر فقط عند إنشاء خطة App Service جديدة . لا يمكن تحويل خطة App Service الموجودة مسبقا لاستخدام مناطق التوفر.
تدعم المناطق التالية Azure App Services التي تعمل على بيئات متعددة المستأجرين:
- شرق أستراليا
- جنوب البرازيل
- وسط كندا
- وسط الهند
- Central US
- شرق آسيا
- شرق الولايات المتحدة
- East US 2
- وسط فرنسا
- وسط غرب ألمانيا
- إسرائيل الوسطى
- منطقة شمال إيطاليا
- شرق اليابان
- وسط كوريا
- وسط المكسيك
- أوروبا الشمالية
- شرق النرويج
- بولندا الوسطى
- قطر الوسطى
- جنوب أفريقيا
- South Central US
- جنوب شرق آسيا
- وسط إسبانيا
- منطقة السويد الوسطى
- شمال سويسرا
- شمال الإمارات العربية المتحدة
- جنوب المملكة المتحدة
- أوروبا الغربية
- West US 2
- غرب الولايات المتحدة الأمريكية 3
- Microsoft Azure المشغل بواسطة 21Vianet - الصين الشمالية 3
- Azure Government - حكومة الولايات المتحدة فيرجينيا
لمعرفة المناطق التي تدعم مناطق التوفر ل App Service Environment v3، راجع المناطق.
إنشاء مورد مع تمكين منطقة التوفر
لنشر خدمة تطبيقات مكررة للمنطقة متعددة المستأجرين
لتمكين مناطق التوفر باستخدام Azure CLI، قم بتضمين المعلمة --zone-redundant عند إنشاء خطة App Service. يمكنك أيضاً تضمين المعلمة --number-of-workers لتحديد السعة. إذا لم تحدد سعة، فسيتم تعيين النظام الأساسي افتراضياً إلى ثلاثة. يجب تعيين السعة استناداً إلى متطلبات حمل العمل، ولكن لا تقل عن ثلاثة. من القواعد الأساسية الجيدة لاختيار السعة ضمان مثيلات كافية للتطبيق بحيث يترك فقدان منطقة واحدة من المثيلات سعة كافية للتعامل مع الحمل المتوقع.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
تلميح
لتحديد سعة المثيل، يمكنك استخدام الحساب التالي:
نظراً لأن النظام الأساسي ينشر الأجهزة الظاهرية عبر ثلاث مناطق وتحتاج إلى حساب فشل منطقة واحدة على الأقل، فقم بضرب ذروة عدد مثيلات حمل العمل بعامل المناطق/(المناطق-1) أو 3/2. على سبيل المثال، إذا كان حمل العمل الذروة النموذجي يتطلب أربعة مثيلات، يجب توفير ستة مثيلات: (2/3 * 6 مثيلات) = 4 مثيلات.
نشر خدمة تطبيقات مكررة في المنطقة باستخدام بيئة مخصصة
لمعرفة كيفية إنشاء App Service Environment v3 على خطة Isolated v2، راجع إنشاء بيئة خدمة التطبيقات.
استكشاف الأخطاء وإصلاحها
| رسالة الخطأ | الوصف | التوصية |
|---|---|---|
| لا يتوفر التكرار في المنطقة لمجموعة الموارد "RG-NAME". يرجى نشر خطة خدمة التطبيق "ASP-NAME" إلى مجموعة موارد جديدة. | يتم دعم مناطق التوفر فقط على بصمة App Service الأحدث. حتى إذا كنت تستخدم إحدى المناطق المدعومة، فستتلقى خطأ إذا لم تكن مناطق التوفر مدعومة لمجموعة الموارد الخاصة بك. | لضمان وصول أحمال العمل إلى طابع يدعم مناطق التوفر، قم بإنشاء مجموعة موارد جديدة وخطة App Service وخدمة التطبيقات. |
التسامح مع الخطأ
للتحضير لفشل منطقة التوفر، يجب الإفراط في توفير سعة الخدمة للتأكد من أن الحل يمكن أن يتسامح مع فقدان السعة 1/3 والاستمرار في العمل دون انخفاض الأداء أثناء الانقطاع على مستوى المنطقة. نظراً لأن النظام الأساسي ينشر الأجهزة الظاهرية عبر ثلاث مناطق وتحتاج إلى حساب فشل منطقة واحدة على الأقل، فقم بضرب ذروة عدد مثيلات حمل العمل بعامل المناطق/(المناطق-1) أو 3/2. على سبيل المثال، إذا كان حمل العمل الذروة النموذجي يتطلب أربعة مثيلات، يجب توفير ستة مثيلات: (2/3 * 6 مثيلات) = 4 مثيلات.
تجربة تعطل المنطقة
يتم توجيه نسبة استخدام الشبكة إلى جميع مثيلات App Service المتوفرة. في حالة تعطل المنطقة، سيكتشف النظام الأساسي لخدمة التطبيقات المثيلات المفقودة ويحاول تلقائياً العثور على مثيلات استبدال جديدة ونشر نسبة استخدام الشبكة حسب الحاجة. إذا كان لديك مقياس تلقائي تم تكوينه، وإذا قرر أن هناك حاجة إلى المزيد من المثيلات، فسيصدر التحجيم التلقائي أيضاً طلباً إلى App Service لإضافة المزيد من المثيلات. لاحظ أن سلوك التحجيم التلقائي مستقل عن سلوك النظام الأساسي لخدمة التطبيقات وأن مواصفات عدد مثيلات التحجيم التلقائي لا تحتاج إلى أن تكون مضاعفاً لثلاثة.
إشعار
ليس هناك ما يضمن نجاح طلبات المثيلات الإضافية في سيناريو المنطقة لأسفل. يحدث الملء الخلفي للمثيلات المفقودة على أساس أفضل جهد. الحل الموصى به هو إنشاء وتكوين خطط App Service لحساب فقدان منطقة كما هو موضح في القسم التالي.
ستستمر التطبيقات التي يتم نشرها في خطة App Service التي تم تمكين مناطق التوفر فيها في تشغيل نسبة استخدام الشبكة وخدمتها حتى إذا عانت المناطق الأخرى في نفس المنطقة من انقطاع. ومع ذلك، فمن الممكن أن تظل السلوكيات غير المتعلقة بوقت التشغيل بما في ذلك تحجيم خطة App Service وإنشاء التطبيق وتكوين التطبيق ونشر التطبيق تتأثر من الانقطاع في مناطق التوفر الأخرى. يضمن التكرار في المنطقة لخطط App Service فقط استمرار وقت التشغيل للتطبيقات المنشورة.
عندما يخصص النظام الأساسي لـ App Service مثيلات لخطة App Service المكررة في المنطقة، فإنه يستخدم موازنة منطقة أفضل جهد تقدمها مجموعات مقياس الجهاز الظاهري لتطبيق Azure الأساسية. ستكون خطة 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، راجع التسعير.
التعافي من الكوارث عبر المناطق واستمرارية الأعمال
يتعلق التعافي من الكوارث (DR) بالتعافي من الأحداث عالية التأثير، مثل الكوارث الطبيعية أو عمليات النشر الفاشلة التي تؤدي إلى وقت تعطل وفقدان البيانات. بغض النظر عن السبب، فإن أفضل علاج للكارثة هو خطة الإصلاح بعد الكارثة محددة جيدا ومختبرة وتصميم تطبيق يدعم الإصلاح بعد الكارثة بنشاط. قبل البدء في التفكير في إنشاء خطة التعافي من الكوارث، راجع توصيات لتصميم استراتيجية التعافي من الكوارث.
عندما يتعلق الأمر بالتعافي من الكوارث، تستخدم Microsoft نموذج المسؤولية المشتركة. في نموذج المسؤولية المشتركة، تضمن Microsoft توفر البنية الأساسية الأساسية وخدمات النظام الأساسي. في الوقت نفسه، لا تقوم العديد من خدمات Azure تلقائيا بنسخ البيانات نسخا متماثلا أو الرجوع من منطقة فاشلة للنسخ المتماثل إلى منطقة أخرى ممكنة. بالنسبة إلى هذه الخدمات، أنت مسؤول عن إعداد خطة التعافي من الكوارث التي تعمل مع حمل العمل الخاص بك. توفر معظم الخدمات التي تعمل على عروض النظام الأساسي كخدمة (PaaS) في Azure ميزات وإرشادات لدعم الإصلاح بعد الكارثة ويمكنك استخدام ميزات خاصة بالخدمة لدعم الاسترداد السريع للمساعدة في تطوير خطة الإصلاح بعد الكارثة.
يغطي هذا القسم بعض الاستراتيجيات الشائعة لتطبيقات الويب المنشورة في App Service.
عند إنشاء تطبيق ويب في App Service واختيار منطقة Azure أثناء إنشاء الموارد، يكون تطبيقا من منطقة واحدة. عندما تصبح المنطقة غير متوفرة أثناء حدوث كارثة، يصبح التطبيق الخاص بك غير متوفر أيضا. إذا قمت بإنشاء نشر متطابق في منطقة Azure ثانوية باستخدام بنية جغرافية متعددة المناطق، يصبح تطبيقك أقل عرضة لكارثة منطقة واحدة، ما يضمن استمرارية الأعمال. يتيح لك أي نسخ متماثل للبيانات عبر المناطق استرداد حالة التطبيق الأخيرة.
بالنسبة إلى تكنولوجيا المعلومات، تستند خطط استمرارية الأعمال إلى حد كبير إلى هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO). لمزيد من المعلومات حول RTO وRPO، راجع أهداف الاسترداد.
عادة ما يكون الحفاظ على اتفاقية مستوى الخدمة حول RTO غير عملي للكوارث الإقليمية، وعادة ما تصمم استراتيجية التعافي من الكوارث الخاصة بك حول RPO وحده (أي التركيز على استرداد البيانات وليس على تقليل المقاطعة). ومع ذلك، مع Azure، ليس من العملي فحسب، بل يمكن أن يكون من السهل نشر App Service لتجاوز الفشل الجغرافي التلقائي. يتيح لك هذا إمكانية إثبات الكوارث للتطبيقات الخاصة بك بشكل أكبر من خلال الاهتمام بكل من RTO وRPO.
اعتمادا على مقاييس RTO وRPO المطلوبة، يتم استخدام ثلاثة بنيات للتعافي من الكوارث بشكل شائع لكل من App Service متعددة المستأجرين وبيئات خدمة التطبيقات. يتم وصف كل بنية في الجدول التالي:
| Metric | نشط-نشط | نشط-سلبي | الخاملة/ الباردة |
|---|---|---|---|
| هدف وقت الاسترداد (RTO) | في الوقت الحقيقي أو بالثوان | دقيقة | ساعات |
| هدف نقطة الاسترداد (RPO) | في الوقت الحقيقي أو بالثوان | دقيقة | ساعات |
| التكلفة | $$$ | $$ | $ |
| السيناريوهات | التطبيقات ذات المهام الحرجة | التطبيقات ذات الأولوية العالية | التطبيقات ذات الأولوية المنخفضة |
| القدرة على خدمة حركة مرور المستخدمين متعددة المناطق | نعم | نعم/ربما | لا |
| نشر للتعليمات البرمجية | البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD المفضلة | البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD المفضلة | النسخ الاحتياطي والاستعادة |
| إنشاء موارد App Service جديدة أثناء وقت التعطل | غير مطلوب | غير مطلوب | المطلوب |
إشعار
يعتمد تطبيقك على الأرجح على خدمات البيانات الأخرى في Azure، مثل قاعدة بيانات Azure SQL وحسابات تخزين Azure. يوصى بتطوير استراتيجيات التعافي من الكوارث لكل من خدمات Azure التابعة هذه أيضا. بالنسبة لقاعدة بيانات SQL، راجع النسخ المتماثل الجغرافي النشط لقاعدة بيانات Azure SQL. بالنسبة إلى Azure Storage، راجع تكرار تخزين Azure.
التعافي من الكوارث في المنطقة الجغرافية متعددة المناطق
هناك طرق متعددة لنسخ محتوى تطبيقات الويب وتكويناتها عبر مناطق Azure في بنية نشطة-نشطة أو نشطة-سلبية، مثل استخدام النسخ الاحتياطي والاستعادة لخدمة التطبيقات. ومع ذلك، فإن النسخ الاحتياطي والاستعادة ينشئان لقطات في نقطة زمنية ويؤديان في النهاية إلى تحديات إصدار تطبيق الويب عبر المناطق. راجع الجدول التالي أدناه للمقارنة بين إرشادات الخلف والاستعادة مقابل إرشادات استرداد حفاض:
النسخ الاحتياطي والاستعادة مقابل التعافي من الكوارث
| النظام الأساسي | إرشادات النسخ الاحتياطي والاستعادة | إرشادات التعافي من الكوارث |
|---|---|---|
| تطبيقات ويب App Service (مستويات التسعير المجانية والمشتركة) |
إذا كان لديك تطبيقات ويب تم نشرها إلى المستوى المجاني أو المشترك وتتطلب الوصول إلى النسخ الاحتياطي واستعادة القدرات لتطبيقات الويب هذه، فتوسع إلى المستوى الأساسي أو أعلى. | أعد موارد App Service عبر الإنترنت في منطقة Azure مختلفة أثناء كارثة إقليمية. بدءا من 31 مارس 2025، لن يتم وضع تطبيقات App Service في وضع التعافي من الكوارث أثناء حدوث كارثة في منطقة Azure كما هو موضح في مقالة التعافي من الفشل على مستوى المنطقة. نوصي بتنفيذ تقنيات التعافي من الكوارث شائعة الاستخدام لمنع وقت التعطل وفقدان البيانات أثناء كارثة إقليمية. |
| تطبيقات ويب App Service (مستويات التسعير الأساسية والقياسية والمتميزة) |
في Azure App Service، يمكنك إجراء نسخ احتياطية مخصصة عند الطلب أو استخدام النسخ الاحتياطية التلقائية. يمكنك استعادة نسخة احتياطية عن طريق الكتابة فوق تطبيق موجود أو عن طريق الاستعادة إلى تطبيق أو فتحة جديدة. راجع النسخ الاحتياطي واستعادة تطبيقك في Azure App Service لمزيد من المعلومات. |
تتوفر الإرشادات الحالية حول كيفية إعادة موارد App Service عبر الإنترنت في منطقة Azure مختلفة أثناء كارثة إقليمية في الاسترداد من الفشل على مستوى المنطقة - Azure App Service. بدءا من 31 مارس 2025، لن يتم وضع تطبيقات ويب Azure App Service في وضع التعافي من الكوارث أثناء حدوث كارثة في منطقة Azure كما هو موضح في مقالة التعافي من الفشل على مستوى المنطقة. نحن نشجعك على تنفيذ تقنيات التعافي من الكوارث شائعة الاستخدام لمنع فقدان الوظائف أو البيانات لتطبيقات الويب الخاصة بك إذا كانت هناك كارثة إقليمية. |
| App Service Environment (V2 وV3) | في Azure App Service Environment، يمكنك إجراء نسخ احتياطية مخصصة عند الطلب أو استخدام النسخ الاحتياطية التلقائية. يمكن استعادة النسخ الاحتياطية التلقائية إلى تطبيق هدف داخل بيئة خدمة التطبيقات نفسها، وليس في بيئة خدمة التطبيقات الأخرى. يمكن استعادة النسخ الاحتياطية المخصصة إلى تطبيق هدف في بيئة App Service أخرى (مثل من بيئة خدمة تطبيقات V2 إلى بيئة خدمة تطبيقات V3). يمكن استعادة النسخ الاحتياطية إلى تطبيق هدف لنفس النظام الأساسي لنظام التشغيل مثل التطبيق المصدر. راجع النسخ الاحتياطي واستعادة تطبيقك في Azure App Service للحصول على مزيد من التفاصيل. |
نحن نشجعك على تنفيذ إرشادات التعافي من الكوارث لتطبيقات الويب المنشورة في App Service Environment باستخدام تقنيات التعافي من الكوارث شائعة الاستخدام. |
| وظائف Azure: الخطة المخصصة |
عند تشغيل تطبيق الوظائف في خطة مخصصة (خدمة التطبيقات)، يتم الاحتفاظ بمحتوى تطبيق الوظائف المطلوب باستخدام التخزين المضمن. في خطة مخصصة، يمكنك إجراء نسخ احتياطية مخصصة عند الطلب أو استخدام النسخ الاحتياطية التلقائية. يمكنك استعادة نسخة احتياطية عن طريق الكتابة فوق تطبيق موجود أو عن طريق الاستعادة إلى تطبيق أو فتحة جديدة. لمزيد من المعلومات، راجع النسخ الاحتياطي للتطبيق واستعادته في Azure App Service. لا تستخدم Azure Files بواسطة خطة مخصصة، ولكن إذا قمت بتكوين تطبيقك بشكل خاطئ باستخدام اتصال Azure Files، فلن يتم دعم النسخ الاحتياطي. |
تتوفر الإرشادات الحالية المتعلقة بكيفية إعادة موارد تطبيق الوظائف في خطة مخصصة عبر الإنترنت في منطقة Azure مختلفة أثناء كارثة إقليمية في الاسترداد من الفشل على مستوى المنطقة - Azure App Service. بدءا من 31 مارس 2025، لن يتم وضع تطبيقات App Service في وضع التعافي من الكوارث أثناء حدوث كارثة في منطقة Azure كما هو موضح في مقالة التعافي من الفشل على مستوى المنطقة. يجب عليك بدلا من ذلك التخطيط للموثوقية في تطبيقات الوظائف. يمكنك أيضا الرجوع إلى تقنيات التعافي من الكوارث شائعة الاستخدام لتطبيقات الوظائف في خطة مخصصة. |
| وظائف Azure: استهلاك Flex، خطط الاستهلاك وPremium |
لا يمكن لتطبيقات الوظائف التي تعمل في خطة Flex Consumption أو في خطة Consumption أو في خطة Premium استخدام وظائف النسخ الاحتياطي المخصصة أو التلقائية في App Service. في خطط المقياس الديناميكي هذه، يتم الاحتفاظ بمحتوى تطبيق الوظائف في Azure Storage. استخدم خيارات التكرار في تخزين Azure للتأكد من أن حساب التخزين الخاص بك يلبي أهداف التوفر والمتانة أثناء الانقطاع. يمكنك أيضا تنزيل مشروع تطبيق الوظائف الحالي كملف .zip من مدخل Microsoft Azure. |
نحن نشجعك بشدة على التخطيط للموثوقية في تطبيقات الوظائف الخاصة بك. |
لتجنب قيود أساليب النسخ الاحتياطي والاستعادة، قم بتكوين مسارات CI/CD لنشر التعليمات البرمجية في كلتا منطقتي Azure. ضع في اعتبارك استخدام Azure Pipelines أو GitHub Actions. لمزيد من المعلومات، راجع النشر المستمر إلى Azure App Service.
الكشف عن الانقطاع والإعلام والإدارة
يوصى بإعداد المراقبة والتنبيهات لتطبيقات الويب الخاصة بك للإخطارات في الوقت المناسب أثناء وقوع كارثة. لمزيد من المعلومات، راجع اختبارات توفر Application Insights.
لإدارة موارد التطبيق في Azure، استخدم آلية البنية الأساسية كتعلم برمجي (IaC). في عملية توزيع معقدة عبر مناطق متعددة، تتطلب إدارة المناطق بشكل مستقل والحفاظ على مزامنة التكوين عبر المناطق بطريقة موثوقة عملية يمكن التنبؤ بها وقابلة للاختبار وقابلة للتكرار. ضع في اعتبارك أداة IaC مثل قوالب Azure Resource Manager أو Terraform.
إعداد التعافي من الكوارث والكشف عن الانقطاع
للتحضير للتعافي من الكوارث في منطقة جغرافية متعددة المناطق، يمكنك استخدام إما بنية نشطة-نشطة أو نشطة-سلبية.
بنية Active-Active
في بنية التعافي من الكوارث النشطة-النشطة، يتم نشر تطبيقات الويب المتطابقة في منطقتين منفصلتين ويتم استخدام Azure Front door لتوجيه حركة المرور إلى كلتا المنطقتين النشطتين.
باستخدام هذا المثال للبنية:
- يتم نشر تطبيقات App Service المتطابقة في منطقتين منفصلتين، بما في ذلك مستوى التسعير وعدد المثيلات.
- يتم حظر حركة المرور العامة مباشرة إلى تطبيقات App Service.
- يتم استخدام Azure Front Door لتوجيه نسبة استخدام الشبكة إلى كلتا المنطقتين النشطتين.
- أثناء وقوع كارثة، تصبح إحدى المناطق غير متصلة، ويوجه Azure Front Door نسبة استخدام الشبكة حصريا إلى المنطقة التي تظل متصلة بالإنترنت. RTO أثناء تجاوز الفشل الجغرافي هذا يقترب من الصفر.
- يجب نشر ملفات التطبيق على كلا تطبيقي الويب باستخدام حل CI/CD. وهذا يضمن أن RPO هو صفر عمليا.
- إذا كان التطبيق الخاص بك يعدل نظام الملفات بشكل نشط، فإن أفضل طريقة لتقليل RPO هي الكتابة فقط إلى مشاركة Azure Storage المحملة بدلا من الكتابة مباشرة إلى مشاركة المحتوى /home لتطبيق الويب. بعد ذلك، استخدم ميزات التكرار Azure Storage (GZRS أو GRS) لمشاركتك المثبتة، والتي تحتوي على RPO لمدة 15 دقيقة تقريبا.
يتم تلخيص خطوات إنشاء بنية نشطة-نشطة لتطبيق الويب الخاص بك في App Service كما يلي:
إنشاء اثنين من خطط App Service في منطقتين مختلفتين من Azure. تكوين خططي App Service بشكل متطابق.
إنشاء مثيلين لتطبيق الويب الخاص بك، مع مثيل واحد في كل خطة App Service.
إنشاء ملف تعريف Azure Front Door باستخدام:
- نقطة نهاية.
- مجموعتان أصل، كل منهما ذات أولوية 1. تخبر الأولوية المتساوية Azure Front Door بتوجيه حركة المرور إلى كلتا المنطقتين بالتساوي (وبالتالي نشط-نشط).
- مسار.
تقييد نسبة استخدام الشبكة لتطبيقات الويب فقط من مثيل Azure Front Door.
إعداد وتكوين جميع خدمات Azure الخلفية الأخرى، مثل قواعد البيانات وحسابات التخزين وموفري المصادقة.
نشر التعليمات البرمجية لكل من تطبيقي الويب مع النشر المستمر.
البرنامج التعليمي: إنشاء تطبيق متعدد المناطق متوفر بشكل كبير في Azure App Service يوضح لك كيفية إعداد بنية نشطة-سلبية . تمنحك نفس الخطوات مع الحد الأدنى من التغييرات (تعيين الأولوية إلى "1" لكلا الأصلين في مجموعة الأصل في Azure Front Door) بنية نشطة-نشطة.
بنية نشطة-سلبية
في نهج التعافي من الكوارث هذا، يتم نشر تطبيقات الويب المتطابقة في منطقتين منفصلتين ويتم استخدام Azure Front door لتوجيه حركة المرور إلى منطقة واحدة فقط ( المنطقة النشطة ).
باستخدام هذا المثال للبنية:
يتم نشر تطبيقات App Service المتطابقة في منطقتين منفصلتين.
يتم حظر حركة المرور العامة مباشرة إلى تطبيقات App Service.
يتم استخدام Azure Front Door لتوجيه نسبة استخدام الشبكة إلى المنطقة الأساسية.
لتوفير التكلفة، يتم تكوين خطة App Service الثانوية ليكون لها مثيلات أقل و/أو تكون في مستوى تسعير أقل. هناك ثلاثة نهج محتملة:
المفضل أن يكون لخطة App Service الثانوية نفس مستوى التسعير الأساسي، بنفس عدد المثيلات أو أقل. يضمن هذا الأسلوب التماثل في كل من الميزة وتحجيم الجهاز الظاهري لخططي App Service. يعتمد RTO أثناء تجاوز الفشل الجغرافي فقط على الوقت لتوسيع نطاق المثيلات.
أقل تفضيلا لخطة App Service الثانوية لها نفس نوع مستوى التسعير (مثل PremiumV3) ولكن حجم الجهاز الظاهري الأصغر، مع مثيلات أقل. على سبيل المثال، قد تكون المنطقة الأساسية في طبقة P3V3 بينما المنطقة الثانوية في مستوى P1V3. لا يزال هذا النهج يضمن تماثل الميزات لخططي App Service، ولكن قد يتطلب عدم تماثل الحجم توسيع النطاق يدويا عندما تصبح المنطقة الثانوية المنطقة النشطة. يعتمد RTO أثناء تجاوز الفشل الجغرافي على الوقت لتوسيع نطاق المثيلات وتوسيع نطاقها.
الأقل تفضيلا لخطة App Service الثانوية لديها مستوى تسعير مختلف عن المثيلات الأساسية والأقل. على سبيل المثال، قد تكون المنطقة الأساسية في طبقة P3V3 بينما المنطقة الثانوية في مستوى S1. تأكد من أن خطة App Service الثانوية تحتوي على جميع الميزات التي يحتاجها تطبيقك للتشغيل. قد تتسبب الاختلافات في توفر الميزات بين الاثنين في حدوث تأخيرات في استرداد تطبيق الويب الخاص بك. يعتمد RTO أثناء تجاوز الفشل الجغرافي على الوقت لتوسيع نطاق المثيلات وتوسيع نطاقها.
يتم تكوين التحجيم التلقائي على المنطقة الثانوية في حالة أن تصبح المنطقة النشطة غير نشطة. من المستحسن أن يكون لديك قواعد تحجيم تلقائي مماثلة في كل من المناطق النشطة والسلبية.
أثناء وقوع كارثة، تصبح المنطقة الأساسية غير نشطة، وتبدأ المنطقة الثانوية في تلقي حركة المرور وتصبح المنطقة النشطة.
بمجرد أن تصبح المنطقة الثانوية نشطة، يؤدي تحميل الشبكة إلى تشغيل قواعد التحجيم التلقائي المكونة مسبقا لتوسيع نطاق تطبيق الويب الثانوي.
قد تحتاج إلى توسيع مستوى التسعير للمنطقة الثانوية يدويا، إذا لم يكن لديها بالفعل الميزات المطلوبة لتشغيلها كمنطقة نشطة. على سبيل المثال، يتطلب التحجيم التلقائي مستوى قياسيا أو أعلى.
عندما تكون المنطقة الأساسية نشطة مرة أخرى، يقوم Azure Front Door تلقائيا بتوجيه حركة المرور مرة أخرى إليها، ويعود التصميم إلى نشط-سلبي كما كان من قبل.
يجب نشر ملفات التطبيق على كلا تطبيقي الويب باستخدام حل CI/CD. وهذا يضمن أن RPO هو صفر عمليا.
إذا كان التطبيق الخاص بك يعدل نظام الملفات بشكل نشط، فإن أفضل طريقة لتقليل RPO هي الكتابة فقط إلى مشاركة Azure Storage المحملة بدلا من الكتابة مباشرة إلى مشاركة المحتوى /home لتطبيق الويب. بعد ذلك، استخدم ميزات التكرار Azure Storage (GZRS أو GRS) لمشاركتك المثبتة، والتي تحتوي على RPO لمدة 15 دقيقة تقريبا.
يتم تلخيص خطوات إنشاء بنية نشطة-سلبية لتطبيق الويب الخاص بك في App Service كما يلي:
- إنشاء اثنين من خطط App Service في منطقتين مختلفتين من Azure. قد يتم توفير خطة App Service الثانوية باستخدام أحد النهج المذكورة سابقا.
- قم بتكوين قواعد التحجيم التلقائي لخطة App Service الثانوية بحيث تتدرج إلى نفس عدد المثيلات مثل الأساسي عندما تصبح المنطقة الأساسية غير نشطة.
- إنشاء مثيلين لتطبيق الويب الخاص بك، مع مثيل واحد في كل خطة App Service.
- إنشاء ملف تعريف Azure Front Door باستخدام:
- نقطة نهاية.
- مجموعة أصل ذات أولوية 1 للمنطقة الأساسية.
- مجموعة أصل ثانية ذات أولوية 2 للمنطقة الثانوية. الفرق في الأولوية يخبر Azure Front Door أن يفضل المنطقة الأساسية عندما تكون متصلة بالإنترنت (وبالتالي نشطة-سلبية).
- مسار.
- تقييد نسبة استخدام الشبكة لتطبيقات الويب فقط من مثيل Azure Front Door.
- إعداد وتكوين جميع خدمات Azure الخلفية الأخرى، مثل قواعد البيانات وحسابات التخزين وموفري المصادقة.
- نشر التعليمات البرمجية لكل من تطبيقي الويب مع النشر المستمر.
البرنامج التعليمي: إنشاء تطبيق متعدد المناطق متوفر بشكل كبير في Azure App Service يوضح لك كيفية إعداد بنية نشطة-سلبية .
البنية الخاملة الباردة
استخدم بنية سلبية/باردة لإنشاء نسخ احتياطية منتظمة من تطبيقات الويب الخاصة بك والحفاظ عليها في حساب Azure Storage الموجود في منطقة أخرى.
باستخدام هذا المثال للبنية:
يتم نشر تطبيق ويب واحد في منطقة واحدة.
يتم نسخ تطبيق الويب احتياطيا بانتظام إلى حساب Azure Storage في نفس المنطقة.
يعتمد النسخ المتماثل عبر المناطق للنسخ الاحتياطية على تكوين تكرار البيانات في حساب تخزين Azure. يجب عليك تعيين حساب Azure Storage الخاص بك ك GZRS إذا كان ذلك ممكنا. يوفر GZRS تكرار المنطقة المتزامن داخل منطقة وغير متزامن في منطقة ثانوية. إذا لم يكن GZRS متوفرا، فكون الحساب ك GRS. لدى كل من GZRS و GRS RPO حوالي 15 دقيقة.
للتأكد من أنه يمكنك استرداد النسخ الاحتياطية عندما تصبح المنطقة الأساسية لحساب التخزين غير متوفرة، قم بتمكين الوصول للقراءة فقط إلى المنطقة الثانوية (مما يجعل حساب التخزين RA-GZRS أو RA-GRS، على التوالي). لمزيد من المعلومات حول تصميم تطبيقاتك للاستفادة من التكرار الجغرافي، راجع استخدام التكرار الجغرافي لتصميم التطبيقات عالية التوفر.
أثناء حدوث كارثة في منطقة تطبيق الويب، يجب نشر جميع الموارد المعتمدة على App Service المطلوبة يدويا باستخدام النسخ الاحتياطية من حساب Azure Storage، على الأرجح من المنطقة الثانوية مع الوصول للقراءة. قد يكون RTO ساعات أو أياما.
لتقليل RTO، يوصى بشدة بأن يكون لديك دليل مبادئ شامل يوضح جميع الخطوات المطلوبة لاستعادة النسخ الاحتياطي لتطبيق الويب الخاص بك إلى منطقة Azure أخرى.
يتم تلخيص خطوات إنشاء منطقة سلبية باردة لتطبيق الويب الخاص بك في App Service كما يلي:
إنشاء حساب تخزين Azure في نفس المنطقة مثل تطبيق الويب الخاص بك. اختر مستوى الأداء القياسي وحدد التكرار كمساحة تخزين جغرافية زائدة عن الحاجة (GRS) أو تخزين متكرر للمنطقة الجغرافية (GZRS).
تمكين RA-GRS أو RA-GZRS (الوصول للقراءة للمنطقة الثانوية).
تكوين نسخة احتياطية مخصصة لتطبيق الويب الخاص بك. قد تقرر تعيين جدول زمني للنسخ الاحتياطية لتطبيق الويب الخاص بك، مثل كل ساعة.
تحقق من إمكانية استرداد ملفات النسخ الاحتياطي لتطبيق الويب المنطقة الثانوية لحساب التخزين الخاص بك.
تلميح
بالإضافة إلى Azure Front Door، يوفر Azure خيارات موازنة التحميل الأخرى، مثل Azure Traffic Manager. للمقارنة بين الخيارات المختلفة، راجع خيارات موازنة التحميل - Azure Architecture Center.
التعافي من الكوارث في المنطقة الجغرافية أحادية المنطقة
إذا لم يكن لدى منطقة تطبيق الويب تخزين GZRS أو GRS أو إذا كنت في منطقة Azure ليست واحدة من زوج إقليمي، فستحتاج إلى استخدام التخزين المتكرر للمنطقة (ZRS) أو التخزين المتكرر محليا (LRS) لإنشاء بنية مماثلة. على سبيل المثال، يمكنك إنشاء منطقة ثانوية لحساب التخزين يدويا كما يلي:
يتم تلخيص خطوات إنشاء منطقة سلبية باردة دون GRS وGZRS كما يلي:
إنشاء حساب تخزين Azure في نفس المنطقة من تطبيق الويب الخاص بك. اختر مستوى الأداء القياسي وحدد التكرار كمساحة تخزين زائدة عن الحاجة (ZRS).
تكوين نسخة احتياطية مخصصة لتطبيق الويب الخاص بك. قد تقرر تعيين جدول زمني للنسخ الاحتياطية لتطبيق الويب الخاص بك، مثل كل ساعة.
تحقق من إمكانية استرداد ملفات النسخ الاحتياطي لتطبيق الويب المنطقة الثانوية لحساب التخزين الخاص بك.
إنشاء حساب تخزين Azure ثان في منطقة مختلفة. اختر مستوى الأداء القياسي وحدد التكرار كمساحة تخزين زائدة محليا (LRS).
باستخدام أداة مثل AzCopy، قم بنسخ النسخ الاحتياطي المخصص (ملفات Zip وXML والسجل) من المنطقة الأساسية إلى التخزين الثانوي. على سبيل المثال:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'يمكنك استخدام Azure Automation مع دفتر تشغيل PowerShell Workflow لتشغيل البرنامج النصي للنسخ المتماثل على جدول زمني. تأكد من أن جدول النسخ المتماثل يتبع جدولا مشابها للنسخ الاحتياطية لتطبيق الويب.