Share via

مراجعة Azure Well-Architected Framework - Azure Application Gateway v2

  • مقالة

توفر هذه المقالة أفضل الممارسات المعمارية لعائلة Azure Application Gateway v2 من وحدات SKU. تستند الإرشادات إلى الركائز الخمس للتميز المعماري:

نفترض أن لديك معرفة عملية ب Azure Application Gateway وأنك على دراية جيدة بميزات v2 SKU. لمزيد من المعلومات، راجع ميزات بوابة تطبيق Azure.

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

الموثوقية

نعترف بحدوث حالات الفشل في السحابة. بدلاً من محاولة منع وقوع حالات الفشل كليًا، فإن الهدف هو تقليل آثار المكون الذي فشل. استخدم المعلومات التالية لتقليل المثيلات الفاشلة.

قائمة مراجعة التصميم

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

  • انشر المثيلات في تكوين واعي بالمنطقة حيثما كان ذلك متاحاً.
  • استخدم Application Gateway مع Web Application Firewall (WAF) داخل شبكة ظاهرية لحماية نسبة استخدام الشبكة الواردة HTTP/S من الإنترنت.
  • في عمليات التوزيع الجديدة، استخدم Azure Application Gateway v2 ما لم يكن هناك سبب مقنع لاستخدام Azure Application Gateway v1.
  • التخطيط لتحديثات القواعد
  • استخدام فحوصات السلامة للكشف عن عدم توفر الواجهة الخلفية
  • مراجعة تأثير إعدادات الفاصل الزمني والحد على تحقيقات السلامة
  • التحقق من تبعيات انتقال البيانات من الخادم من خلال نقاط النهاية الصحية

التوصيات

استكشف جدول التوصيات التالي لتحسين تكوين بوابة التطبيق للموثوقية.

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

- يؤدي تعيين فاصل زمني أعلى إلى تحميل أعلى على خدمتك. يرسل كل مثيل Application Gateway تحقيقات السلامة الخاصة به، لذا فإن 100 مثيل كل 30 ثانية يعني 100 طلب لكل 30 ثانية.
- يؤدي تعيين فاصل زمني أقل إلى ترك المزيد من الوقت قبل اكتشاف انقطاع التيار الكهربائي.
- قد يعني تعيين حد منخفض غير صحي أن حالات الفشل القصيرة العابرة قد تؤدي إلى تعطل الواجهة الخلفية.
- تعيين حد عال قد يستغرق وقتا أطول لأخذ خلفية من التدوير.
التحقق من تبعيات انتقال البيانات من الخادم من خلال نقاط النهاية الصحية لنفترض أن كل خلفية لها تبعياتها الخاصة لضمان عزل حالات الفشل. على سبيل المثال، قد يكون للتطبيق المستضاف خلف Application Gateway واجهات خلفية متعددة، كل منها متصل بقاعدة بيانات مختلفة (نسخة متماثلة). عند فشل مثل هذه التبعية، قد يعمل التطبيق ولكنه لن يرجع نتائج صالحة. لهذا السبب، يجب أن تتحقق نقطة النهاية الصحية من صحة جميع التبعيات بشكل مثالي. ضع في اعتبارك أنه إذا كان لكل استدعاء إلى نقطة النهاية الصحية استدعاء تبعية مباشر، فستتلقى قاعدة البيانات هذه 100 استعلام كل 30 ثانية بدلا من 1. لتجنب ذلك، يجب أن تخزن نقطة النهاية الصحية حالة التبعيات مؤقتا لفترة زمنية قصيرة.
عند استخدام خدمتيْ Front Door وApplication Gateway من Azure لحماية تطبيقات HTTP/S، استخدم نُهج جدار حماية تطبيقات الويب في Front Door وأغلِق Application Gateway لاستلام نسبة استخدام الشبكة من Azure Front Door فقط. يمكن أن تجبرك بعض السيناريوهات على تنفيذ القواعد على Application Gateway على وجه التحديد. على سبيل المثال، إذا كانت قواعد ModSec CRS 2.2.9 أو CRS 3.0 أو CRS 3.1 مطلوبة، يمكن تنفيذ هذه القواعد فقط على Application Gateway. وعلى العكس من ذلك، لا يتوفر تحديد السعر والتصفية الجغرافية إلا على Azure Front Door، وليس على AppGateway.

يساعدك Azure Advisor على ضمان وتحسين استمرارية التطبيقات المهمة للأعمال. راجع توصيات Azure Advisor.

الأمان

الأمان هو أحد أهم جوانب أي تصميم. توفر بوابة التطبيق ميزات لتوظيف كل من مبدأ الامتياز الأقل والدفاع في الدفاع. نوصي بمراجعة مبادئ تصميم الأمان.

قائمة مراجعة التصميم

  • إعداد نهج TLS لتحسين الأمان
  • استخدام AppGateway لإنهاء TLS
  • استخدام Azure Key Vault لتخزين شهادات TLS
  • عند إعادة تشفير نسبة استخدام الشبكة الخلفية، تأكد من أن شهادة الخادم الخلفي تحتوي على كل من المراجع المصدقة الجذر والمتوسطة (CAs)
  • استخدام خادم DNS مناسب لموارد تجمع الواجهة الخلفية
  • الامتثال لجميع قيود NSG لبوابة التطبيق
  • الامتناع عن استخدام UDRs على الشبكة الفرعية لبوابة التطبيق
  • كن على دراية بتغييرات سعة بوابة التطبيق عند تمكين WAF

التوصيات

استكشف جدول التوصيات التالي لتحسين تكوين Application Gateway للأمان.

التوصية الميزة
إعداد نهج TLS لتحسين الأمان إعداد نهج TLS لمزيد من الأمان. احرص على استخدام أحدث إصدار من نهج TLS (AppGwSslPolicy20170401S). هذا يفرض TLS 1.2 وتشفير أقوى.
استخدام AppGateway لإنهاء TLS هناك مزايا لاستخدام بوابة التطبيق لإنهاء TLS:

- يتحسن الأداء لأن الطلبات التي تنتقل إلى الخلفيات المختلفة يجب إعادة المصادقة على كل خلفية.
- استخدام أفضل للخوادم الخلفية لأنها لا تحتاج إلى إجراء معالجة TLS
- التوجيه الذكي عن طريق الوصول إلى محتوى الطلب.
- إدارة الشهادات بشكل أسهل لأن الشهادة تحتاج فقط إلى تثبيت على بوابة التطبيق.
استخدام Azure Key Vault لتخزين شهادات TLS تم دمج بوابة التطبيق مع Key Vault. يوفر هذا أمانا أقوى، وفصلا أسهل بين الأدوار والمسؤوليات، ودعما للشهادات المدارة، وعملية أسهل لتجديد الشهادات والتناوب.
عند إعادة تشفير نسبة استخدام الشبكة الخلفية، تأكد من أن شهادة الخادم الخلفي تحتوي على كل من المراجع المصدقة الجذر والمتوسطة (CAs) يجب إصدار شهادة TLS للخادم الخلفي بواسطة مرجع مصدق معروف. إذا لم يتم إصدار الشهادة من قبل مرجع مصدق موثوق به، تتحقق بوابة التطبيق مما إذا كانت شهادة المرجع المصدق المصدر قد تم إصدارها من قبل مرجع مصدق موثوق به، وهكذا حتى يتم العثور على مرجع مصدق موثوق به. ثم يتم إنشاء اتصال آمن فقط. وإلا، فإن Application Gateway يضع علامة على الواجهة الخلفية على أنها غير صحية.
استخدام خادم DNS مناسب لموارد تجمع الواجهة الخلفية عندما يحتوي تجمع الواجهة الخلفية على FQDN قابل للحل، تستند دقة DNS إلى منطقة DNS خاصة أو خادم DNS مخصص (إذا تم تكوينه على VNet)، أو يستخدم DNS الافتراضي الذي توفره Azure.
الامتثال لجميع قيود NSG لبوابة التطبيق يتم دعم مجموعات أمان الشبكة على الشبكة الفرعية لبوابة التطبيق، ولكن هناك بعض القيود. على سبيل المثال، يحظر بعض الاتصالات مع نطاقات منافذ معينة. تأكد من فهم الآثار المترتبة على هذه القيود. للحصول على التفاصيل، راجع مجموعات أمان الشبكة.
الامتناع عن استخدام UDRs على الشبكة الفرعية لبوابة التطبيق يمكن أن يؤدي استخدام المسارات المعرفة من قبل المستخدم (UDR) على الشبكة الفرعية لبوابة التطبيق إلى حدوث بعض المشكلات. قد تكون الحالة الصحية في الخلفية غير معروفة. قد لا يتم إنشاء سجلات ومقاييس بوابة التطبيق. نوصي بعدم استخدام UDRs على الشبكة الفرعية لبوابة التطبيق حتى تتمكن من عرض تسجيلات الحالة الصحية للواجهة الخلفية والمقاييس. إذا كانت مؤسستك تحتاج إلى استخدام UDR في الشبكة الفرعية لبوابة التطبيق، فيرجى التأكد من مراجعة السيناريوهات المدعومة. لمزيد من المعلومات، راجع المسارات المدعومة المعرفة من قبل المستخدم.
كن على دراية بتغييرات سعة بوابة التطبيق عند تمكين WAF عند تمكين WAF، يجب تخزين كل طلب مؤقتا بواسطة بوابة التطبيق حتى يصل بالكامل والتحقق مما إذا كان الطلب يتطابق مع أي انتهاك للقاعدة في مجموعة القواعد الأساسية الخاصة به ثم إعادة توجيه الحزمة إلى مثيلات الخلفية. بالنسبة لتحميلات الملفات الكبيرة (30 ميغابايت+ في الحجم)، يمكن أن يؤدي هذا إلى زمن انتقال كبير. نظرا لأن متطلبات سعة بوابة التطبيق مختلفة مع WAF، لا نوصي بتمكين WAF على Application Gateway دون الاختبار والتحقق المناسبين.

لمزيد من الاقتراحات، راجع مبادئ الركيزة الأمنية.

يساعدك Azure Advisor على ضمان وتحسين استمرارية التطبيقات المهمة للأعمال. راجع توصيات Azure Advisor.

تعريفات السياسة

  • يجب تمكين جدار حماية تطبيق الويب (WAF) لبوابة التطبيق. انشر تطبيق جدار الحماية لتطبيق الويب للعامة التي تواجه تطبيقات الويب لمزيد من المعاينة على الحركة الواردة. يوفر جدار حماية تطبيق الويب حماية مركزية لتطبيقات الويب الخاصة بك من الاختراقات والثغرات الأمنية الشائعة مثل إضافة SQL والبرمجة عبر الموقع وعمليات تضمين الملفات المحلية والبعيدة. يمكنك أيضا تقييد الوصول إلى تطبيقات الويب الخاصة بك حسب البلدان/المناطق ونطاقات عناوين IP ومعلمات http (المعلمات) الأخرى عبر القواعد المخصصة.
  • يجب أن يستخدم جدار حماية تطبيق الويب (WAF) الوضع المحدد لبوابة التطبيق. تفويضات تنشيط استخدام وضع "الكشف" أو "المنع" في نهج جدار حماية تطبيق الويب لبوابة التطبيق.
  • يجب تمكين Azure DDoS Protection. يجب تمكين حماية DDoS لجميع الشبكات الظاهرية مع شبكة فرعية تعد جزءا من بوابة تطبيق مع IP عام.

يتم سرد جميع تعريفات النهج المضمنة المتعلقة بشبكات Azure في النهج المضمنة - الشبكة.

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

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. نوصي بمراجعة مبادئ تصميم تحسين التكلفة.

قائمة مراجعة التصميم

  • تعرف على أسعار بوابة التطبيق
  • مراجعة الموارد غير المستغلة
  • إيقاف مثيلات Application Gateway غير المستخدمة
  • لديك نهج توسيع وتوسيع النطاق
  • مراجعة مقاييس الاستهلاك عبر معلمات مختلفة

التوصيات

استكشف جدول التوصيات التالي لتحسين تكوين Application Gateway لتحسين التكلفة.

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

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

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

لمزيد من المعلومات، راجع ما هو Azure Application Gateway v2؟
مراجعة مقاييس الاستهلاك عبر معلمات مختلفة تتم فوترتك استنادا إلى مثيلات محدودة من Application Gateway استنادا إلى المقاييس التي تتبعها Azure. تقييم المقاييس المختلفة ووحدات السعة وتحديد محركات التكلفة. لمزيد من المعلومات، راجع إدارة التكلفة والفوترة من Microsoft.

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

- وحدات السعة المفوترة المقدرة
- وحدات السعة القابلة للفوترة الثابتة
- وحدات السعة الحالية

لمزيد من المعلومات، راجع مقاييس بوابة التطبيق.

تأكد من حساب تكاليف النطاق الترددي.

لمزيد من الاقتراحات، راجع مبادئ ركيزة تحسين التكلفة.

يساعدك Azure Advisor على ضمان وتحسين استمرارية التطبيقات المهمة للأعمال. راجع توصيات Azure Advisor.

التميز التشغيلي

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

قائمة مراجعة التصميم

  • مراقبة مقاييس السعة
  • تمكين التشخيصات على بوابة التطبيق وجدار حماية تطبيق الويب (WAF)
  • استخدام Azure Monitor Network Insights
  • مطابقة إعدادات المهلة مع تطبيق الواجهة الخلفية
  • مراقبة مشكلات تكوين Key Vault باستخدام Azure Advisor
  • تكوين ومراقبة قيود منفذ SNAT
  • ضع في اعتبارك قيود منفذ SNAT في تصميمك

التوصيات

استكشف جدول التوصيات التالي لتحسين تكوين Application Gateway للتميز التشغيلي.

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

- عدد المضيفين غير الصحيين
- حالة الاستجابة (البعد 4xx و5xx)
- حالة استجابة الواجهة الخلفية (البعد 4xx و5xx)
- وقت استجابة البايت الأخير للواجهة الخلفية
- إجمالي الوقت لبوابة التطبيق

لمزيد من المعلومات، راجع مقاييس بوابة التطبيق.
تمكين التشخيصات على بوابة التطبيق وجدار حماية تطبيق الويب (WAF) تسمح لك سجلات التشخيص بعرض سجلات جدار الحماية وسجلات الأداء وسجلات الوصول. استخدم هذه السجلات لإدارة واستكشاف المشكلات المتعلقة بمثيلات بوابة التطبيق وإصلاحها. لمزيد من المعلومات، راجع سجلات الحماية والتشخيص الخلفية لبوابة التطبيق.
استخدام Azure Monitor Network Insights يوفر Azure Monitor Network Insights عرضا شاملا لصحة موارد الشبكة ومقاييسها، بما في ذلك Application Gateway. للحصول على تفاصيل إضافية وقدرات مدعومة لبوابة التطبيق، راجع رؤى شبكة Azure Monitor.
مطابقة إعدادات المهلة مع تطبيق الواجهة الخلفية تأكد من تكوين إعدادات IdleTimeout لمطابقة خصائص وحدة الاستماع وحركة المرور لتطبيق الواجهة الخلفية. يتم تعيين القيمة الافتراضية إلى أربع دقائق ويمكن تكوينها إلى 30 كحد أقصى. لمزيد من المعلومات، راجع إعادة تعيين TCP لموازن التحميل ومهلة الخمول.

لاعتبارات حمل العمل، راجع مراقبة صحة التطبيق للموثوقية.
مراقبة مشكلات تكوين Key Vault باستخدام Azure Advisor تتحقق بوابة التطبيق من إصدار الشهادة المجدد في Key Vault المرتبطة في كل فاصل زمني مدته 4 ساعات. إذا تعذر الوصول إليه بسبب أي تكوين Key Vault غير صحيح، فإنه يسجل هذا الخطأ ويدفع توصية Advisor المقابلة. يجب عليك تكوين تنبيهات Advisor للبقاء على اطلاع دائم وإصلاح مثل هذه المشكلات على الفور لتجنب أي مشكلات متعلقة بمستوى التحكم أو البيانات. لمزيد من المعلومات، راجع التحقيق في أخطاء مخزن المفاتيح وحلها. لتعيين تنبيه لهذه الحالة المحددة، استخدم نوع التوصية كحل مشكلة Key Vault Azure لبوابة التطبيق.
ضع في اعتبارك قيود منفذ SNAT في تصميمك قيود منفذ SNAT مهمة للاتصالات الخلفية على بوابة التطبيق. هناك عوامل منفصلة تؤثر على كيفية وصول بوابة التطبيق إلى حد منفذ SNAT. على سبيل المثال، إذا كانت الواجهة الخلفية عنوان IP عاما، فستتطلب منفذ SNAT الخاص بها. لتجنب قيود منفذ SNAT، يمكنك زيادة عدد المثيلات لكل بوابة تطبيق، أو توسيع الواجهات الخلفية للحصول على المزيد من عناوين IP، أو نقل الواجهات الخلفية إلى نفس الشبكة الظاهرية واستخدام عناوين IP الخاصة للخلفيات.

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

لمزيد من الاقتراحات، راجع مبادئ ركيزة التميز التشغيلي.

يساعدك Azure Advisor على ضمان وتحسين استمرارية التطبيقات المهمة للأعمال. راجع توصيات Azure Advisor.

كفاءة الأداء

كفاءة الأداء هي قدرة حمل عملك على تغيير الحجم لتلبية المطالب التي يضعها المستخدمون عليها بطريقة فعالة. نوصي بمراجعة مبادئ كفاءة الأداء.

قائمة مراجعة التصميم

  • تقدير عدد مثيلات بوابة التطبيق
  • تحديد الحد الأقصى لعدد المثيلات
  • تحديد الحد الأدنى لعدد المثيلات
  • تعريف حجم الشبكة الفرعية لبوابة التطبيق
  • الاستفادة من ميزات Application Gateway V2 للتحجيم التلقائي ومزايا الأداء

التوصيات

استكشف جدول التوصيات التالي لتحسين تكوين بوابة التطبيق لكفاءة الأداء.

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

وحدات الحوسبة الحالية — تشير إلى استخدام وحدة المعالجة المركزية. 1 مثيل Application Gateway هو حوالي 10 وحدات حساب.
معدل النقل - يمكن أن يخدم مثيل Application Gateway حوالي 500 ميجابت في الثانية من معدل النقل. تعتمد هذه البيانات على نوع الحمولة.

ضع في اعتبارك هذه المعادلة عند حساب عدد المثيلات.
عدد المثيلات التقريبي

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

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

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

تعيين الحد الأقصى لعدد المثيلات إلى 125 ليس له أي آثار على التكلفة لأنه تتم محاسبتك فقط على السعة المستهلكة.
تعريف حجم الشبكة الفرعية لبوابة التطبيق تحتاج بوابة التطبيق إلى شبكة فرعية مخصصة داخل شبكة ظاهرية. يمكن أن تحتوي الشبكة الفرعية على مثيلات متعددة لمورد Application Gateway المنشور. يمكنك أيضا توزيع موارد Application Gateway الأخرى في تلك الشبكة الفرعية أو v1 أو v2 SKU.

فيما يلي بعض الاعتبارات لتعريف حجم الشبكة الفرعية:

- تستخدم بوابة التطبيق عنوان IP خاصا واحدا لكل مثيل وعنوان IP خاص آخر إذا تم تكوين عنوان IP خاص للواجهة الأمامية.
- يحتفظ Azure بخمسة عناوين IP في كل شبكة فرعية للاستخدام الداخلي.
- يمكن لبوابة التطبيق (Standard أو WAF SKU) دعم ما يصل إلى 32 مثيلا. مع أخذ 32 عنوان IP للمثيل + عنوان IP خاص للواجهة الأمامية + 5 Azure محجوز، يوصى بحد أدنى لحجم الشبكة الفرعية من /26. نظرا لأن Standard_v2 أو WAF_v2 SKU يمكن أن يدعم ما يصل إلى 125 مثيلا، باستخدام نفس الحساب، يوصى بحجم شبكة فرعية من /24.
- إذا كنت ترغب في نشر موارد Application Gateway إضافية في نفس الشبكة الفرعية، ففكر في عناوين IP الإضافية التي ستكون مطلوبة للحد الأقصى لعدد المثيلات لكل من Standard وStandard v2.
الاستفادة من ميزات التحجيم التلقائي ومزايا الأداء تقدم v2 SKU ميزة تغيير الحجم التلقائي لضمان أن Application Gateway يمكن أن ترتفع مع زيادة نسبة استخدام الشبكة. بالمقارنة مع v1 SKU، يحتوي الإصدار 2 على قدرات تعزز أداء حمل العمل. على سبيل المثال، أداء أفضل لإلغاء تحميل TLS، وأوقات نشر وتحديث أسرع، وتكرار المنطقة، والمزيد. لمزيد من المعلومات حول ميزات التحجيم التلقائي، راجع تحجيم Application Gateway v2 وWAF v2.

إذا كنت تقوم بتشغيل بوابة تطبيق v1 SKU، ففكر في الترحيل إلى Application gateway v2 SKU. لمزيد من المعلومات، راجع ترحيل بوابة تطبيق Azure وجدار حماية تطبيق الويب من الإصدار 1 إلى الإصدار 2.

يساعدك Azure Advisor على ضمان وتحسين استمرارية التطبيقات المهمة للأعمال. راجع توصيات Azure Advisor.

توصيات Azure Advisor

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

الموثوقية

الموارد الإضافية

إرشادات Azure Architecture Center

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