الموثوقية في Azure Spring Apps

تحتوي هذه المقالة على معلومات مفصلة حول المرونة الإقليمية مع مناطق التوفر والتعافي من الكوارث عبر المناطق ودعم استمرارية الأعمال ل Azure Spring Apps.

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

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

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

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

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

المتطلبات الأساسية

  • لا يتوفر التكرار في المنطقة في الخطة الأساسية.

  • تدعم Azure Spring Apps مناطق التوفر في المناطق التالية:

    • شرق أستراليا
    • جنوب البرازيل
    • وسط كندا
    • Central US
    • شرق آسيا
    • شرق الولايات المتحدة
    • East US 2
    • وسط فرنسا
    • وسط غرب ألمانيا
    • أوروبا الشمالية
    • شرق اليابان
    • وسط كوريا
    • جنوب أفريقيا
    • South Central US
    • جنوب شرق آسيا
    • جنوب المملكة المتحدة
    • أوروبا الغربية
    • West US 2
    • غرب الولايات المتحدة الأمريكية 3

إنشاء مثيل Azure Spring Apps مع تمكين مناطق التوفر

إشعار

يمكنك تمكين تكرار المنطقة فقط عند إنشاء مثيل خدمة Azure Spring Apps. لا يمكنك تغيير خاصية تكرار المنطقة بعد الإنشاء.

يمكنك تمكين تكرار المنطقة في Azure Spring Apps باستخدام Azure CLI أو مدخل Azure.

لإنشاء خدمة في Azure Spring Apps مع تمكين تكرار المنطقة باستخدام Azure CLI، قم بتضمين المعلمة --zone-redundant عند إنشاء الخدمة الخاصة بك، كما هو موضح في المثال التالي:

az spring create \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name> \
    --location <location> \
    --zone-redundant true

تمكين المورد الخاص بك مع تمكين مناطق التوفر

يمكنك تمكين المورد الخاص بك في Azure Spring Apps، مثل التخزين المستمر الخاص بك. ومع ذلك، يجب التأكد من تمكين تكرار المنطقة للمورد الخاص بك. لمزيد من المعلومات، راجع كيفية تمكين التخزين المستمر الخاص بك في Azure Spring Apps.

تجربة تعطل المنطقة

عندما يفشل مثيل تطبيق لأنه موجود على عقدة جهاز ظاهري في منطقة فاشلة، تقوم Azure Spring Apps بإنشاء مثيل تطبيق جديد للتطبيق الفاشل على عقدة جهاز ظاهري أخرى في منطقة توفر أخرى. قد يواجه المستخدمون مقاطعة قصيرة خلال هذا الوقت. لا يلزم إجراء المستخدم وستتم استعادة مثيل Azure Spring Apps المتأثر بواسطة الخدمة.

التسعير

لا توجد تكلفة إضافية مرتبطة بتمكين تكرار المنطقة. تحتاج فقط إلى الدفع مقابل خطة Standard أو Enterprise، المطلوبة لتمكين التكرار في المنطقة.

التعافي من الكوارث عبر المناطق واستمرارية الأعمال

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

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

لا توفر خدمة Azure Spring Apps التعافي من الكوارث الجغرافية، ولكن يمكن أن يساعد التخطيط الدقيق في حمايتك من مواجهة وقت التعطل.

لضمان قابلية الوصول العالية والحماية من الكوارث، انشر تطبيقاتك المستضافة في Azure Spring Apps إلى مناطق متعددة. يوفر Azure قائمة بالمناطق المقترنة بحيث يمكنك تخطيط عمليات نشر التطبيق وفقا لذلك.

ضع في اعتبارك العوامل الرئيسية التالية عند تصميم البنية الخاصة بك:

  • التوفر في المنطقة. لتقليل تأخر الشبكة ووقت الإرسال، اختر منطقة تدعم تكرار منطقة Azure Spring Apps، أو منطقة جغرافية قريبة من المستخدمين.
  • المناطق المُقترنة في Azure. لضمان تحديثات النظام الأساسي المنسقة وجهود الاسترداد ذات الأولوية إذا لزم الأمر، اختر المناطق المقترنة داخل المنطقة الجغرافية التي اخترتها.
  • توفر الخدمة. حدد ما إذا كان يجب تشغيل المناطق المقترنة بالحرارة/الساخنة أو الساخنة/الدافئة أو الساخنة/الباردة.

استخدم Azure Traffic Manager لتوجيه نسبة استخدام الشبكة

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

إذا كانت لديك تطبيقات في Azure Spring Apps تعمل في مناطق متعددة، يمكن ل Azure Traffic Manager التحكم في تدفق نسبة استخدام الشبكة إلى تطبيقاتك في كل منطقة. حدد نقطة نهاية Azure Traffic Manager لكل مثيل خدمة باستخدام IP المثيل. يجب الاتصال باسم DNS Azure Traffic Manager الذي يشير إلى مثيل خدمة Azure Spring Apps. يوازن تحميل Azure Traffic Manager نسبة استخدام الشبكة عبر نقاط النهاية المحددة. إذا ضربت كارثة مركز بيانات، يوجه Azure Traffic Manager نسبة استخدام الشبكة من تلك المنطقة إلى زوجها، ما يضمن استمرارية الخدمة.

استخدم الخطوات التالية لإنشاء مثيل Azure Traffic Manager لمثيلات Azure Spring Apps:

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

    اسم الخدمة الموقع التطبيق
    service-sample-a شرق الولايات المتحدة البوابة / خدمة المصادقة / خدمة الحساب
    service-sample-b أوروبا الغربية البوابة / خدمة المصادقة / خدمة الحساب
  2. إعداد مجال مخصص لمثيلات الخدمة. لمزيد من المعلومات، راجع البرنامج التعليمي: تعيين مجال مخصص موجود إلى Azure Spring Apps. بعد الإعداد الناجح، سيتم ربط مثيلي الخدمة بنفس المجال المخصص، مثل bcdr-test.contoso.com.

  3. إنشاء مدير نسبة استخدام الشبكة ونقطة نهاية اثنين. للحصول على الإرشادات، راجع التشغيل السريع: إنشاء ملف تعريف Traffic Manager باستخدام مدخل Microsoft Azure، والذي ينتج ملف تعريف Traffic Manager التالي:

    • اسم DNS لـ Traffic Manager: http://asa-bcdr.trafficmanager.net
    • ملفات تعريف نقطة النهاية:
    ملف التعريف نوع استهداف الأولوية إعدادات الرأس المخصصة
    ملف تعريف نقطة النهاية أ نقطة النهاية الخارجية service-sample-a.azuremicroservices.io 1 host: bcdr-test.contoso.com
    ملف تعريف نقطة النهاية ب نقطة النهاية الخارجية service-sample-b.azuremicroservices.io 2 host: bcdr-test.contoso.com
  4. إنشاء سجل CNAME في منطقة DNS مشابهة للمثال التالي: bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.

تم إعداد البيئة الآن. إذا استخدمت قيم المثال في المقالات المرتبطة، يجب أن تكون قادرا على الوصول إلى التطبيق باستخدام https://bcdr-test.contoso.com.

استخدام Azure Front Door وAzure Application Gateway لتوجيه نسبة استخدام الشبكة

Azure Front Door هي نقطة إدخال عالمية قابلة للتطوير تستخدم شبكة الحافة العمومية من Microsoft لإنشاء تطبيقات ويب سريعة وآمنة وقابلة للتطوير على نطاق واسع. يوفر Azure Front Door نفس التكرار والتوجيه متعدد المناطق الجغرافية إلى أقرب منطقة مثل Azure Traffic Manager. يوفر Azure Front Door أيضا ميزات متقدمة مثل إنهاء بروتوكول TLS ومعالجة طبقة التطبيق وجدار حماية تطبيق الويب (WAF). لمزيد من المعلومات، راجع ما هو Azure Front Door؟

يوضح الرسم التخطيطي التالي بنية مثيل خدمة Azure Spring Apps متعدد المناطق، ومتكامل مع الشبكة الظاهرية. يوضح الرسم التخطيطي تكوين الوكيل العكسي الصحيح لبوابة التطبيق والواجهة الأمامية مع مجال مخصص. تستند هذه البنية إلى السيناريو الموضح في كشف التطبيقات مع TLS من طرف إلى طرف في شبكة ظاهرية. يجمع هذا الأسلوب بين مثيلي حقن الشبكة الظاهرية ل Azure Spring Apps المدمجين في Application-Gateway في مثيل متكرر جغرافيا.

Diagram showing the architecture of a multi-region Azure Spring Apps service instance.

الخطوات التالية