عند نشر تطبيق ويب Azure App Service في منطقة واحدة تصبح غير متوفرة بسبب الكوارث أو الانقطاع، فإنك تخاطر بأن يصبح تطبيقك غير متوفر. للتأكد من استمرار توفر التطبيق الخاص بك عندما تكون المنطقة غير متوفرة، يمكنك تنفيذ بنية متعددة المناطق. باستخدام بنية متعددة المناطق، يمكنك إنشاء نشر متطابق في منطقة Azure ثانوية. مع نشر منطقة ثانوية، يمكنك نسخ بياناتك نسخا متماثلا لاسترداد حالة التطبيق الأخيرة؛ ويمكن نسخ مكونات الحل الأخرى أيضا.
توضح هذه المقالة ثلاثة نهج معمارية متعددة المناطق شائعة الاستخدام لكل من App Service وApp Service Environments.
السياسات التي يجب مراعاتها
تتأثر خطط استمرارية الأعمال بمقياسين رئيسيين:
- هدف وقت الاسترداد (RTO)، وهو الحد الأقصى لوقت التعطل المسموح به أثناء وقوع كارثة.
- هدف نقطة الاسترداد (RPO)، وهو الحد الأقصى لفقدان البيانات الذي يمكن تحمله أثناء وقوع كارثة.
لمزيد من المعلومات حول أهداف الاسترداد مثل RTO وRPO، راجع أهداف الاسترداد والتوصيات لتحديد أهداف الموثوقية.
باستخدام النظام الأساسي Azure، يمكنك تصميم حلول تطبيقات متعددة المناطق بطرق مختلفة. توضح هذه المقالة البنيات التي تدعم متطلبات RTO وRPO المختلفة، ويكون لها مفاضلات أخرى للتكلفة والتعقيد:
| Metric | نشط-نشط | نشط-سلبي | الخاملة/ الباردة |
|---|---|---|---|
| هدف وقت الاسترداد (RTO) | في الوقت الحقيقي أو بالثوان | دقيقة | ساعات |
| هدف نقطة الاسترداد (RPO) | في الوقت الحقيقي أو بالثوان | دقيقة | ساعات |
| التكلفة | $$$ | $$ | $ |
| السيناريوهات | التطبيقات ذات المهام الحرجة | التطبيقات ذات الأولوية العالية | التطبيقات ذات الأولوية المنخفضة |
| القدرة على خدمة حركة مرور المستخدمين متعددة المناطق | نعم | لا | لا |
| نشر للتعليمات البرمجية | البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD المفضلة | البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD المفضلة | النسخ الاحتياطي والاستعادة |
| إنشاء موارد App Service جديدة أثناء وقت التعطل | غير مطلوب | غير مطلوب | المطلوب |
في حين أن الطرق الثلاثة الموضحة هنا شائعة، فإنها ليست الطريقة الوحيدة لتحقيق حل متعدد المناطق في Azure. قم بتكييف الحلول لتلبية متطلباتك الخاصة.
إشعار
يعتمد تطبيقك على الأرجح على خدمات أخرى في Azure، مثل قاعدة بيانات Azure SQL وحسابات Azure Storage وقوائم انتظار الرسائل. عند تصميم استراتيجية التعافي من الكوارث، تحتاج إلى النظر في كل من خدمات Azure التابعة هذه أيضا.
لمعرفة المزيد حول الحلول متعددة المناطق لخدمات Azure، راجع أدلة موثوقية خدمة Azure.
مراقبة
من المهم تكوين المراقبة والتنبيهات لتطبيقات الويب الخاصة بك بحيث يحصل فريقك على إعلامات في الوقت المناسب أثناء فشل المنطقة. توفر اختبارات توفر Azure Application Insights طريقة لمراقبة توفر التطبيق. لمزيد من المعلومات، راجع اختبارات توفر Application Insights.
التوزيع
يمكن أن تكون الحلول متعددة المناطق معقدة للنشر والتكوين. من المهم أن يتم الاحتفاظ بالمثيلات في كل منطقة متزامنة.
لإدارة توزيع وتكوين موارد Azure مثل App Service، استخدم آلية البنية الأساسية كتعليمية (IaC). في عملية توزيع معقدة عبر مناطق متعددة، تتطلب إدارة المناطق بشكل مستقل والحفاظ على مزامنة التكوين عبر المناطق بطريقة موثوقة عملية يمكن التنبؤ بها وقابلة للاختبار وقابلة للتكرار. ضع في اعتبارك أداة IaC مثل Bicep أو قوالب Azure Resource Manager أو Terraform.
يجب عليك أيضا تكوين البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD لنشر التعليمات البرمجية الخاصة بك، بما في ذلك عند استخدام مناطق متعددة. ضع في اعتبارك استخدام Azure Pipelines أو GitHub Actions. لمزيد من المعلومات، راجع النشر المستمر إلى Azure App Service.
بنية نشطة-نشطة
في بنية نشطة-نشطة، يتم نشر تطبيقات ويب متطابقة في منطقتين منفصلتين. يتم استخدام Azure Front Door لتوجيه نسبة استخدام الشبكة إلى كلتا المنطقتين النشطتين:
تستخدم تطبيقات App Service لكل منطقة نفس التكوين، بما في ذلك مستوى التسعير وعدد المثيلات.
أثناء العمليات العادية، يتم حظر حركة المرور العامة مباشرة إلى تطبيق App Service. يتم توجيه حركة المرور بدلا من ذلك على الرغم من Azure Front Door إلى كلتا المنطقتين النشطتين. يساعدك هذا الأسلوب على التأكد من أن الطلبات يتم فحصها بواسطة جدار حماية تطبيق الويب Azure Front Door (WAF)، أو أن يتم تأمينها أو إدارتها مركزيا.
أثناء فشل المنطقة، إذا كانت إحدى المناطق غير متصلة بالإنترنت، فإن تحقيقات صحة Azure Front Door تكتشف الأصل الخاطئ وتعيد تكوين المسارات بحيث يتم إرسال حركة المرور حصريا إلى المنطقة التي تظل متصلة بالإنترنت.
أثناء استرداد منطقة معطل (إرجاع الموارد)، تكتشف تحقيقات صحة Azure Front Door الأصل السليم واستعادة توجيه نسبة استخدام الشبكة العادي.
التوصيات
لتلبية RPO صفر لمحتوى التطبيق، استخدم حل CI/CD لنشر ملفات التطبيق على كلا تطبيقي الويب.
حيثما أمكن، قم بتخزين حالة التطبيق خارج نظام ملفات App Service كما هو الحال في قاعدة بيانات أو Azure Storage. قم بتكوين هذه المكونات لتلبية متطلبات التكرار الجغرافي.
تلميح
إذا كان التطبيق الخاص بك يعدل نظام الملفات بشكل نشط، وكانت منطقة تطبيق App Service الخاصة بك بها منطقة مقترنة، يمكنك تقليل RPO لنظام الملفات الخاص بك عن طريق الكتابة إلى مشاركة تخزين Azure مثبتة بدلا من الكتابة مباشرة إلى مشاركة المحتوى /home لتطبيق الويب. بعد ذلك، استخدم ميزات التكرار Azure Storage (GZRS أو GRS) لمشاركتك المثبتة، والتي تحتوي على RPO لمدة 15 دقيقة تقريبا.
الاعتبارات
انخفاض RTO: يعتمد RTO أثناء تجاوز الفشل الجغرافي هذا على مدى السرعة التي تكتشف بها تحقيقات السلامة المنطقة المعيبة. بشكل افتراضي، تتحقق الفحوصات كل 30 ثانية، ولكن يمكنك تكوين تكرار فحص مختلف.
موازنة التحميل وتجاوز الفشل: يستخدم هذا الأسلوب Azure Front Door لموازنة التحميل العمومي وتوزيع نسبة استخدام الشبكة وتجاوز الفشل. يوفر Azure خيارات موازنة التحميل الأخرى، مثل Azure Traffic Manager. للمقارنة بين الخيارات المختلفة، راجع خيارات موازنة التحميل - Azure Architecture Center.
نشر تطبيقات الويب Active-active App Service
اتبع هذه الخطوات لإنشاء نهج نشط-نشط لتطبيقات الويب باستخدام App Service:
إنشاء اثنين من خطط App Service في منطقتين مختلفتين من Azure. تكوين خططي App Service بشكل متطابق.
إنشاء مثيلين لتطبيق الويب الخاص بك، مع مثيل واحد في كل خطة App Service.
إنشاء ملف تعريف Azure Front Door باستخدام:
- نقطة نهاية.
- مجموعة أصل ذات أصلين، كل منها له أولوية 1. تخبر قيم الأولوية المتساوية Azure Front Door بتوجيه نسبة استخدام الشبكة إلى التطبيقات في كلتا المنطقتين بالتساوي (نشط-نشط).
- مسار.
تقييد نسبة استخدام الشبكة لتطبيقات الويب فقط من مثيل Azure Front Door.
إعداد وتكوين جميع خدمات Azure الخلفية الأخرى، مثل قواعد البيانات وحسابات التخزين وموفري المصادقة.
نشر التعليمات البرمجية لكل من تطبيقي الويب مع النشر المستمر.
يوضح لك البرنامج التعليمي Create a highly available multi-region app in Azure App Service كيفية إعداد بنية نشطة-سلبية. لنشر نهج نشط-نشط، اتبع نفس الخطوات ولكن مع استثناء واحد: في Azure Front Door، قم بتكوين كلا الأصلين في مجموعة الأصل للحصول على أولوية 1.
بنية نشطة-سلبية
في بنية نشطة-سلبية، يتم نشر تطبيقات الويب المتطابقة في منطقتين منفصلتين. يتم استخدام Azure Front Door لتوجيه نسبة استخدام الشبكة إلى منطقة واحدة فقط ( المنطقة النشطة ).
أثناء العمليات العادية، يوجه Azure Front Door نسبة استخدام الشبكة إلى المنطقة الأساسية فقط. يتم حظر حركة المرور العامة مباشرة إلى تطبيقات App Service.
أثناء فشل المنطقة، إذا أصبحت المنطقة الأساسية غير نشطة، تكشف تحقيقات صحة Azure Front Door عن الأصل الخاطئ وتبدأ في توجيه نسبة استخدام الشبكة إلى الأصل في المنطقة الثانوية. ثم تصبح المنطقة الثانوية المنطقة النشطة. بمجرد أن تصبح المنطقة الثانوية نشطة، يؤدي تحميل الشبكة إلى تشغيل قواعد التحجيم التلقائي المكونة مسبقا لتوسيع نطاق تطبيق الويب الثانوي.
أثناء استرداد منطقة معطل (إرجاع الموارد)، يقوم Azure Front Door تلقائيا بتوجيه نسبة استخدام الشبكة مرة أخرى إلى المنطقة الأساسية، وتعود البنية إلى نشطة-سلبية كما كان من قبل.
إشعار
قد تحتاج إلى توسيع مستوى التسعير للمنطقة الثانوية يدويا، إذا لم يكن لديها بالفعل الميزات المطلوبة لتشغيلها كمنطقة نشطة. على سبيل المثال، يتطلب التحجيم التلقائي مستوى قياسيا أو أعلى.
التوصيات
لتلبية RPO صفر لمحتوى التطبيق، استخدم حل CI/CD لنشر ملفات التطبيق على كلا تطبيقي الويب.
حيثما أمكن، قم بتخزين حالة التطبيق خارج نظام ملفات App Service كما هو الحال في قاعدة بيانات أو Azure Storage. قم بتكوين هذه المكونات لتلبية متطلبات التكرار الجغرافي.
تلميح
إذا كان التطبيق الخاص بك يعدل نظام الملفات بشكل نشط، وكانت منطقة تطبيق App Service الخاصة بك بها منطقة مقترنة، يمكنك تقليل RPO لنظام الملفات الخاص بك عن طريق الكتابة إلى مشاركة تخزين Azure مثبتة بدلا من الكتابة مباشرة إلى مشاركة المحتوى /home لتطبيق الويب. بعد ذلك، استخدم ميزات التكرار Azure Storage (GZRS أو GRS) لمشاركتك المثبتة، والتي تحتوي على RPO لمدة 15 دقيقة تقريبا.
الاعتبارات
عناصر التحكم في التكلفة: يتم نشر تطبيقات App Service متطابقة في منطقتين منفصلتين. لتوفير التكلفة، يتم تكوين خطة 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 لموازنة التحميل العمومي وتوزيع نسبة استخدام الشبكة وتجاوز الفشل. يوفر Azure خيارات موازنة التحميل الأخرى، مثل Azure Traffic Manager. للمقارنة بين الخيارات المختلفة، راجع خيارات موازنة التحميل - Azure Architecture Center.
نشر تطبيقات الويب ل App Service النشطة-السلبية
اتبع هذه الخطوات لإنشاء نهج نشط-سلبي لتطبيقات الويب باستخدام 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 مع مناطق التوفر ولا يوجد زوج من المناطق.
استخدم النسخ المتماثل RA-GZRS ، إذا كان متوفرا. يوفر RA-GZRS تكرار المنطقة المتزامن داخل منطقة وغير متزامن في منطقة ثانوية. كما يوفر الوصول للقراءة فقط داخل المنطقة الثانوية، وهو أمر ضروري للتأكد من أنه يمكنك استرداد النسخ الاحتياطية عندما تصبح المنطقة الأساسية لحساب التخزين غير متوفرة.
إذا لم يكن RA-GZRS متوفرا، فكون الحساب ك RA-GRS.
لدى كل من RA-GZRS وRA-GRS RPO حوالي 15 دقيقة.
لمزيد من المعلومات حول تصميم تطبيقاتك للاستفادة من التخزين المتكرر جغرافيا، راجع استخدام التكرار الجغرافي لتصميم التطبيقات عالية التوفر.
تجربة خفض المنطقة
إذا كانت المنطقة الأساسية غير متوفرة، يجب الكشف عن فقدان المنطقة. لمزيد من المعلومات، راجع المراقبة.
لإعداد المنطقة الثانوية لتلقي نسبة استخدام الشبكة، انشر جميع موارد App Service المطلوبة والموارد التابعة باستخدام النسخ الاحتياطية من حساب Azure Storage في منطقتك الثانوية.
الاعتبارات
RTO العالي: لأن هذه العملية تتطلب الكشف اليدوي والاستجابة، قد يكون RTO لهذا السيناريو ساعات أو حتى أيام. لتقليل RTO الخاص بك، قم بإنشاء واختبار دليل مبادئ شامل يوضح جميع الخطوات المطلوبة لاستعادة النسخ الاحتياطي لتطبيق الويب الخاص بك إلى منطقة Azure أخرى.
حتى بعد إنشاء التطبيق الخاص بك في المنطقة الثانوية، قد تحتاج إلى التعامل مع التعقيدات مثل سجلات DNS وشهادات TLS. تأكد من أنك خططت لكل خطوة مطلوبة لإرسال نسبة استخدام الشبكة إلى منطقتك الثانوية، واختبر خططك بانتظام.
هدف نقطة الاسترداد العالي: يمكن جدولة النسخ الاحتياطية لتحدث مرة واحدة في الساعة. إذا كان التطبيق الأساسي الخاص بك غير متصل، فقد يكون النسخ الاحتياطي الذي تستعيده في منطقة ثانوية قديما. يعتمد RPO الخاص بك على تكرار النسخ الاحتياطية بالإضافة إلى مدى سرعة نسخ هذه النسخ الاحتياطية بين المناطق.
خطوات إرشادية
تعتمد الخطوات التي تستخدمها لتكوين توزيع سلبي-بارد على ما إذا كانت منطقتك لديها زوج. لمزيد من المعلومات، راجع المناطق والمناطق المقترنة ب Azure مع مناطق التوفر ولا يوجد زوج من المناطق.
الخطوات لإنشاء منطقة سلبية باردة لتطبيق الويب الخاص بك في App Service هي كما يلي:
إنشاء حساب تخزين Azure في نفس المنطقة مثل تطبيق الويب الخاص بك. اختر مستوى الأداء القياسي وحدد التكرار كمساحة تخزين جغرافية زائدة عن الحاجة (GRS) أو تخزين متكرر للمنطقة الجغرافية (GZRS).
تمكين RA-GRS أو RA-GZRS (الوصول للقراءة للمنطقة الثانوية).
تكوين نسخة احتياطية مخصصة لتطبيق الويب الخاص بك. قد تقرر تعيين جدول زمني للنسخ الاحتياطية لتطبيق الويب الخاص بك، مثل كل ساعة.
تحقق من إمكانية استرداد ملفات النسخ الاحتياطي لتطبيق الويب في المنطقة الثانوية لحساب التخزين الخاص بك.
الخطوات التالية
مراجعة البنيات المرجعية ل Azure App Service: