توزيع المؤسسات عالي التوفر باستخدام App Service Environment

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

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

يمكن أن تكون خدمات Azure التي تدعم مناطق التوفر مناطقية أو متكررة في المنطقة أو كليهما. يمكن نشر خدمات المناطق في منطقة معينة. يمكن نشر الخدمات المكررة للمنطقة تلقائيا عبر المناطق. للحصول على إرشادات وتوصيات مفصلة، راجع دعم منطقة التوفر. كان الإصدار السابق من App Service Environment (v2) يدعم عمليات النشر المناطقية فقط، ولكن الإصدار الحالي (v3) يدعم عمليات النشر المتكررة في المنطقة.

يتوفر تنفيذ مرجعي لهذه البنية على GitHub.

الهندسة

قم بتنزيل ملف Visio لهذه البنية.

الموارد الموجودة في الشبكات الفرعية لبيئة خدمة التطبيقات في هذا التنفيذ المرجعي هي نفس الموارد الموجودة في بنية توزيع App Service Environment القياسية. يستخدم هذا التنفيذ المرجعي قدرات المنطقة المكررة ل App Service Environment v3 وAzure Cache for Redis لتوفير توفر أعلى. لاحظ أن نطاق بنية المرجع هذه يقتصر على منطقة واحدة.

Workflow

يصف هذا القسم طبيعة توفر الخدمات المستخدمة في هذه البنية:

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

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

• بوابة التطبيق v2 هي منطقة زائدة عن الحاجة. مثل الشبكة الظاهرية، فإنها تمتد عبر مناطق توفر متعددة لكل منطقة. لذلك، تعد بوابة تطبيق واحدة كافية لنظام متوفر بشكل كبير، كما هو موضح في البنية المرجعية. تستخدم البنية المرجعية WAF SKU لبوابة التطبيق، والتي توفر حماية متزايدة من التهديدات والثغرات الأمنية الشائعة، استنادا إلى تنفيذ مجموعة القواعد الأساسية (CRS) لمشروع أمان تطبيق الويب المفتوح (OWASP). لمزيد من المعلومات، راجع تغيير حجم Application Gateway v2 وWAF v2.

• Azure Firewall يحتوي على قابلية وصول عالية مضمّنة. يمكن أن يعبر مناطق متعددة دون أي تكوين إضافي.

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

• معرف Microsoft Entra هو خدمة عالمية عالية التوفر ومكررة للغاية، تمتد عبر مناطق التوفر والمناطق. لمزيد من المعلومات، راجع Advancing Microsoft Entra availability.

• توفر إجراءات GitHub إمكانات التكامل المستمر والنشر المستمر (CI/CD) في هذه البنية. نظرا لوجود App Service Environment في الشبكة الظاهرية، يتم استخدام جهاز ظاهري كصندوق انتقال في الشبكة الظاهرية لنشر التطبيقات في خطط App Service. ينشئ الإجراء التطبيقات خارج الشبكة الظاهرية. لتحسين الأمان واتصال RDP/SSH السلس، ضع في اعتبارك استخدام Azure Bastion ل jumpbox.

• ذاكرة التخزين المؤقت Azure ل Redis هي خدمة متكررة في المنطقة. تعمل ذاكرة التخزين المؤقت المكررة للمنطقة على الأجهزة الظاهرية المنشورة عبر مناطق توفر متعددة. توفر هذه الخدمة مرونة وتوافرا أعلى.

الاعتبارات

تطبق هذه الاعتبارات ركائز إطار العمل جيد التصميم في Azure، وهي مجموعة من المبادئ التوجيهية التي يمكنك استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

التوافر

بيئة خدمة التطبيق

يمكنك نشر App Service Environment عبر مناطق التوفر لتوفير المرونة والموثوقية لأحمال العمل المهمة لأعمالك. يعرف هذا التكوين أيضا باسم تكرار المنطقة.

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

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

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

مرونة

تشكل التطبيقات التي تعمل في App Service Environment تجمع الواجهة الخلفية ل Application Gateway. عندما يأتي طلب إلى التطبيق من الإنترنت العام، تقوم البوابة بإعادة توجيه الطلب إلى التطبيق الذي يعمل في App Service Environment. تنفذ هذه البنية المرجعية عمليات التحقق من الصحة داخل واجهة الويب الأمامية الرئيسية، votingApp. يتحقق فحص الصحة هذا مما إذا كانت واجهة برمجة تطبيقات الويب وذاكرة التخزين المؤقت Redis سليمة. يمكنك مشاهدة التعليمات البرمجية التي تنفذ هذا التحقيق في Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

توضح التعليمات البرمجية التالية كيف يقوم البرنامج النصي commands_ha.azcli بتكوين تجمعات الواجهة الخلفية والتحقيق الصحي لبوابة التطبيق:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

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

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

تحسين التكلفة

يتعلق تحسين التكلفة بخفض النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

اعتبارات التكلفة لبنية قابلية الوصول العالية مشابهة لاعتبارات التوزيع القياسي.

الاختلافات التالية يمكن أن تؤثر على التكلفة:

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

إن المفاضلة مع نظام متاح للغاية ومرنة وآمنة للغاية هي زيادة التكلفة. استخدم حاسبة التسعير لتقييم احتياجاتك فيما يتعلق بالتسعير.

اعتبارات النشر

يستخدم هذا التنفيذ المرجعي نفس البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD على مستوى الإنتاج مثل التوزيع القياسي، مع جهاز ظاهري واحد فقط ل jumpbox. ومع ذلك، قد تقرر استخدام مربع انتقال واحد لكل منطقة من المناطق الثلاث. تستخدم هذه البنية مربع انتقال واحد فقط لأن jumpbox لا يؤثر على توفر التطبيق. يتم استخدام jumpbox فقط للتوزيع والاختبار.

نشر هذا السيناريو

للحصول على معلومات حول نشر التنفيذ المرجعي لهذه البنية، راجع GitHub readme. استخدم البرنامج النصي للتوزيع عالي التوفر.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

• ديب بهاتاخاريا | مهندس حلول السحابة
• سهاس راو | مهندس حلول السحابة

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

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