نظرة عامة على فحوصات صحة بوابة التطبيق

  • مقالة

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

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

سلوك الفحوصات

عنوان IP المصدر

يعتمد عنوان IP المصدر للفحوصات على نوع الخادم الخلفي:

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

عمليات الفحص

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

Diagram showing Application Gateway initiating health probes to individual backend targets within a backend pool

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

Diagram showing health probes report on the Backend Health page

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

فواصل الفحص الزمنية

ينطبق نفس تكوين الفحص على كل مثيل من Application Gateway. على سبيل المثال، إذا كانت بوابة التطبيق تحتوي على مثيلين وتم تعيين الفاصل الزمني للتحقيق إلى 20 ثانية، فسيرسل كلا المثيلين مسبار السلامة كل 20 ثانية.

بمجرد أن يكتشف الفحص استجابة فاشلة، يبدأ عداد "عتبة غير سليمة" ويضع علامة على الخادم على أنه غير سليم إذا كان العدد الفاشل المتتالي يطابق الحد المكون. وفقا لذلك، إذا قمت بتعيين هذا الحد غير السليم ك 2، فسيكتشف الفحص اللاحق أولا هذا الفشل. ستقوم بوابة التطبيق بعد ذلك بوضع علامة على الخادم على أنه غير صحي بعد فحصين فاشلين متتاليين [الكشف الأول 20 ثانية + (فحصان فاشلان متتاليان * 20 ثانية)].

إشعار

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

فحص السلامة الافتراضي

تقوم بوابة التطبيق تلقائيًا بتكوين اختبار الصحة الافتراضي عندما لا تقوم بإعداد أي تكوين تحقيقي متخصص. يعمل سلوك المراقبة عن طريق إجراء طلب HTTP GET إلى عناوين IP أو FQDN الذي تم تكوينه في تجمع الخلفية. بالنسبة للفحوصات الافتراضية، في حالة تكوين إعدادات http الخلفية لـ HTTPS، يستخدم الفحص HTTPS لاختبار سلامة الخوادم الخلفية.

على سبيل المثال: يمكنك تكوين بوابة التطبيق لاستخدام خوادم الواجهة الخلفية A وB وC لتلقي حركة مرور شبكة HTTP على المنفذ 80. تختبر مراقبة السلامة الافتراضية الخوادم الثلاثة كل 30 ثانية للحصول على استجابة HTTP سليمة مع مهلة 30 ثانية لكل طلب. تحتوي استجابة HTTP الصحية على رمز حالة بين 200 و 399. في هذه الحالة، يبدو طلب HTTP GET لفحص السلامة مثل http://127.0.0.1/. راجع أيضا رموز استجابة HTTP في بوابة التطبيق.

في حالة فشل فحص السلامة الافتراضي للخادم A، تتوقف application gateway عن إعادة توجيه الطلبات إلى هذا الخادم. يستمر التحقيق الافتراضي في البحث عن الخادم "أ" كل 30 ثانية. عندما يستجيب الخادم A بنجاح لطلبٍ واحدٍ من فحص سلامة افتراضي، تبدأ application gateway في إعادة توجيه الطلبات إلى الخادم مرةً أخرى.

إعدادات الفحص السليمة الافتراضية

خاصية الفحص قيمة ‏‏الوصف
التحقق من عنوان URL <البروتوكول>://127.0.0.1:<port>/ يجري توريث البروتوكول والمنفذ من إعدادات HTTP الخلفية التي يرتبط بها الفحص
الفاصل الزمني 30 مقدار الوقت بالثواني للانتظار قبل إرسال فحص السلامة التالي.
المهلة 30 مقدار الوقت بالثواني الذي تنتظره application gateway للحصول على استجابة فاحصة قبل وضع علامة على الفحص على أنه غير سليم. إذا اُكتشِف أن الفحص غير سليم، تُوضع علامة على الخلفية المقابلة على الفور على أنها سليمة.
حد غير سليم 3 يحكم عدد الفحوصات التي من المقرر إرسالها في حالة حدوث فشل في فحص السلامة القياسي. في وحدة حفظ المخزون v1، يجري إرسال هذه فحوصات السلامة الإضافية هذه في تتابع سريع لتحديد سلامة الخلفية بسرعة ولا تنتظر فاصل الفحص الزمني. بالنسبة إلى v2 SKU، تنتظر تحقيقات السلامة الفاصل الزمني. يتم وضع علامة على الخادم الخلفي لأسفل بعد أن يصل عدد فشل التحقيق المتتالي إلى الحد غير السليم.

يبحث الفحص الافتراضي فقط في <البروتوكول>://127.0.0.1:<port> لتحديد الحالة الصحية. إذا كنت بحاجة إلى تكوين اختبار الصحة للانتقال إلى عنوان URL مخصص أو تعديل أي إعدادات أخرى، يجب عليك استخدام تحقيقات مخصصة. لمزيد من المعلومات حول تحقيقات HTTPS، راجع نظرة عامة على إنهاء TLS والنهاية إلى نهاية TLS مع بوابة التطبيق.

فحص السلامة المخصص

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

إعدادات فحوصات السلامة المخصصة

يوفر الجدول التالي تعريفات لخصائص فحوصات السلامة المخصصة.

خاصية الفحص ‏‏الوصف‬
الاسم اسم الفحص. يستخدم هذا الاسم لتعريف التحقيق والإشارة إليه في إعدادات HTTP الخلفية.
بروتوكول البروتوكول المستخدم لإرسال الفحص. يجب أن يتطابق هذا مع البروتوكول المحدد في إعدادات HTTP الخلفية المرتبطة به
المضيف اسم المضيف المراد إرسال الفحص معه. في v1 SKU، يتم استخدام هذه القيمة فقط لعنوان المضيف لطلب الفحص. في v2 SKU، يتم استخدامه كعنوان مضيف وSNI
المسار المسار النسبي للفحص. يبدأ المسار الصحيح ب '/'
المنفذ في حالة تعريفه، فسيُستخدم كمنفذ الوجهة. وإلا، فإنه يستخدم نفس المنفذ مثل إعدادات HTTP المقترنة به. تتوفر هذه الخاصية فقط في وحدة حفظ المخزون v2
الفاصل الزمني فاصل الفحص الزمني بالثواني. هذه القيمة هي الفاصل الزمني بين فحصين متتاليين
المهلة مهلة الفحص بالثواني. في حالة عدم تلقي استجابة صالحة خلال فترة المهلة هذه، ستُوضع علامة على الفحص على أنه فشل
حد غير سليم الفحص في إعادة المحاولة. يتم وضع علامة لأسفل على الخادم الخلفي بعد وصول عدد فشل التحقيق المتتالي إلى الحد غير السليم

مطابقة الفحص

افتراضياً، استجابة HTTP (S) مع تعليمة الحالة البرمجية بين 200 و399 يعتبر سليم. بالإضافة إلى ذلك، تدعم فحوصات السلامة المخصصة معيارين متطابقين. يمكن استخدام المعايير المتطابقة لتعديل التفسير الافتراضي لما يجعل الاستجابة سليمة اختيارياً.

فيما يلي معايير مطابقة:

  • تطابق رمز حالة استجابة HTTP - معيار مطابقة التحقيق لقبول رمز استجابة http المحدد من قبل المستخدم أو نطاقات كود الاستجابة. يجري دعم التعليمات البرمجية لحالة الاستجابة الفردية المفصولة بفواصل أو نطاق تعليمة الحالة البرمجية.
  • مطابقة نص استجابة HTTP - فحص معيار المطابقة الذي يبحث في نص استجابة HTTP ويتطابق مع سلسلة محددة من قبل المستخدم. يبحث التطابق فقط عن وجود سلسلة محددة من المستخدم في نص الاستجابة وليست مطابقة كاملة للتعبير العادي. يجب أن تكون المطابقة المحددة 4090 حرفا أو أقل.

يمكن تحديد معايير المطابقة باستخدام الأمرNew-AzApplicationGatewayProbeHealthResponseMatch cmdlet.

على سبيل المثال:

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

يمكن إرفاق معايير المطابقة لتكوين الفحص باستخدام -Match عامل تشغيل في PowerShell.

بعض حالات الاستخدام للفحوصات المخصصة

  • إذا كان الخادم الخلفي يسمح بالوصول إلى المستخدمين المصادق عليهم فقط، فستتلقى تحقيقات بوابة التطبيق رمز استجابة 403 بدلا من 200. نظرا لأن العملاء (المستخدمين) ملزمون بمصادقة أنفسهم لنسبة استخدام الشبكة المباشرة، يمكنك تكوين حركة مرور الفحص لقبول 403 كاستجابة متوقعة.
  • عندما يحتوي الخادم الخلفي على شهادة بدل (*.contoso.com) مثبتة لخدمة مجالات فرعية مختلفة، يمكنك استخدام فحص مخصص مع اسم مضيف معين (مطلوب ل SNI) يتم قبوله لإنشاء فحص TLS ناجح والإبلاغ عن هذا الخادم على أنه سليم. مع تعيين "تجاوز اسم المضيف" في إعداد الواجهة الخلفية إلى لا، سيتم تمرير أسماء المضيفين الواردة المختلفة (المجالات الفرعية) كما هي إلى الخلفية.

اعتبارات موردي المواد النووية

التحكم الدقيق في الشبكة الفرعية لبوابة التطبيق عبر قواعد NSG ممكن في المعاينة العامة. يمكن العثور على مزيد من التفاصيل عن هذا الموضوع هنا.

مع الوظائف الحالية هناك بعض القيود:

يجب السماح بنسبة استخدام شبكة الإنترنت الواردة على منافذ TCP 65503-65534 لـ SKU بوابة التطبيق v1 ومنافذ TCP 65200-65535 لـ SKU v2 مع شبكة الوجهة الفرعية كـأيومصدر كعلامة خدمة GatewayManager. نطاق المنفذ هذا مطلوب لاتصالات البنية الأساسية لـ Azure.

بالإضافة إلى ذلك، لا يمكن حظر اتصال الإنترنت الصادر، ويجب السماح بحركة المرور الواردة من علامة AzureLoadBalancer.

لمزيد من المعلومات، شاهد نظرة عامة على تكوين بوابة Application.

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

بعد التعرف على مراقبة سلامة بوابة Application، يمكنك تكوين اختبار صحة مخصص في مدخل Microsoft Azure أو اختبار صحة مخصص باستخدام PowerShell ونموذج نشر AZure Resource Manager.