استكشاف أخطاء Azure Load Balancer وإصلاحها
تعمل Azure Load Balancer في طبقة النقل من مكدس الشبكة. Load Balancer تعلن عن عنوان IP عام واحد الذي يتصل به كافة العملاء. ثم تستخدم Load Balancer قواعد ترجمة العنوان والتوجيه الخاصة به لتوجيه طلبات TCP الواردة إلى إحدى مجموعة من عناوين الصادرة. بشكل عام، كل عنوان صادر مقترن بجهاز ظاهري مختلف (VM)، كل منها يقوم بتشغيل مثيل للتطبيق الخاص بك.
يستخدم Load Balancer فحصا صحيا لتحديد توفر كل جهاز ظاهري في تجمع النهاية الخلفية. يرسل Load Balancer فقط طلبات إلى VMs تشير إلى أنها سليمة.
في المثال، تلقيت تنبيهات تشير إلى أن "Load Balancer" لا يمكنه توجيه الطلبات إلى VMs في تجمع النهاية الخلفية. كنت تشك في تغيير حديث في تكوين الشبكة قد يكون السبب في المشكلة. ولكن عليك أن تفهم كيف تؤثر التغييرات على الشبكة على تشغيل Load Balancer.
بنهاية هذه الوحدة، ستتمكن من:
- وصف تكوين نموذجي من Load Balancer والمكونات المتضمنة في توجيه طلبات إلى VMs.
- شرح المشاكل الشائعة التي يمكن أن تتسبب في فشل "Load Balancer" في توزيع الطلبات على VMs.
كيف يعمل Load Balancer؟
يتضمن Azure Load Balancer العديد من المكونات:
- عنوان IP أمامي
- تجمع نهاية خلفية لعناوين VM
- قواعد توجيه واحدة أو أكثر
- تقصي صحي
- مجموعة من VMs، عادةً في شبكة ظاهرية
يوضح الرسم التخطيطي التالي كيفية عمل العناصر المختلفة المستخدمة من قِبَل "Load Balancer" معاً.
عنوان IP لواجهة أمامية وتجمع خلفي
يوفر Azure Load Balancer اتصال شفاف من نهاية إلى نهاية من عميل إلى تطبيق الذي يتم تشغيله على مجموعة من VMs. يخزن Azure Load Balancer عناوين IP الخاصة بـ VMs هذه في مستودع يشار إليه عادةً باسم تجمع النهاية الخلفية. كشف Azure Load Balancer الخاص به عنوان IP الواجهة الأمامية للعملاء. عندما يرسل عميل طلبًا إلى هذا العنوان، يحدد "Azure Load Balancer" عنوان IP VM من تجمع النهاية الخلفية. ثم يوجه Azure Load Balancer الطلب عبر عنوان IP هذا الخلفي إلى VM.
العميل ليس على دراية بـ Load Balancer. العميل يرى عنوان IP أو اسم DNS ويرسل طلبات إلى هذه الوجهة. هذه العملية هي نفسها كما لو كان العميل على اتصال مباشرة مع VM. عند وصول الطلب على VM، يتم الاحتفاظ بعنوان العميل الأصلي.
بالإضافة إلى ذلك، حمولة الرسائل المرسلة من العميل إلى VM هي معتمة إلى Load Balancer. لا يفحص Load Balancer محتويات أي رسائل أو يعالجها. إنه يعدل الرسائل بحيث يتم إرسالها إلى VM المحدد.
يحدد Load Balancer عنوان IP VM من تجمع النهاية الخلفية باستخدام خوارزمية مصممة لتوزيع الطلبات بالتساوي. تقوم Load Balancer بإنشاء شفرة تجزئة باستخدام المعلومات التالية:
- عنوان IP المصدر وعنوان المنفذ للعميل
- عنوان IP الوجهة والمنفذ
- بروتوكول شبكة الاتصال
يتم استخدام قيمة شفرة التجزئة كمفتاح للجدول الذي يحتوي على عناوين IP في تجمع النهاية الخلفية.
قابلية التوسع
يمكنك بدء تشغيل المزيد من مثيلات الجهاز الظاهري وإضافة عناوين IP الخاصة بها إلى تجمع النهاية الخلفية في أي وقت. يتضمن Load Balancer هذه المثيلات الجديدة عندما يقوم بتوزيع طلبات المستخدم.
يمكن أن يعرض Load Balancer أكثر من عنوان IP عام أمامي، وقد يحتوي على تجمعات متعددة من الواجهة الخلفية. يمكّنك هذا النظام من إعادة استخدام نفس مثيل "Load Balancer" لمعالجة طلبات أنظمة مختلفة.
قواعد التوجيه
يمكنك تعريف قواعد load-balancing لتحديد كيفية توجيه الطلبات نحو كل عنوان IP أمامي يتم تعيينه إلى تجمع الخلفية. كما تحدد قاعدة موازنة التحميل البروتوكول الذي يجب مطابقته، وبشكل اختياري منافذ المصدر (العميل) والوجهة. يتم تجاهل الطلبات الواردة التي تصل إلى عنوان IP أمامي لا تتطابق مع متطلبات البروتوكول والمنفذ بواسطة Load Balancer. يمكن لقاعدة موازنة التحميل أيضا تكوين استمرار الجلسة بحيث من المحتمل أن يتم توجيه طلبات العميل المعينة إلى نفس الجهاز الظاهري مما يسمح للتطبيقات التي تعمل على جهاز ظاهري بالاستفادة من التخزين المؤقت لعقد معلومات خاصة بجلسة العمل.
تحقيقات الصحة
يحتاج Load Balancer إلى تحديد ما إذا كان كل VM المشار إليه بواسطة تجمع النهاية الخلفية متوفرًا لمعالجة الطلبات. يتم تحديد التوفر عن طريق إضافة فحص صحة. يرسل التقصي الصحي رسائل ping منتظمة إلى منفذ الذي تحدده لـ VMs في تجمع النهاية الخلفية. أنت توفر خدمة على VMs تستجيب لرسائل ping هذه، مع رسالة HTTP 200 (OK).
عندما يفشل VM للاستجابة بعد عدد محدد من المحاولات، يفترض "Load Balancer" أنه ضار ويحذفه من قائمة VMs التي يمكنها قبول طلبات المستخدم. ثم يتم توزيع عبء العمل بين ما تبقى من VMs صحية. يستمر Load Balancer في تنفيذ الأمر ping VM لا يستجيب. إذا بدأ VM بالرد، تتم إضافته مرة أخرى إلى قائمة VMs السليمة ويبدأ في تلقي طلبات المستخدمين مرة أخرى.
إذا لم توفر مسبارًا صحيًا، فلا يعرف Load Balancer ما إذا كان الجهاز الظاهري سليمًا أم لا. بدلاً من ذلك، يفترض أن كافة VMs استجابة.
الشبكة الظاهرية
تتم استضافة الأجهزة الظاهرية المشار إليها بواسطة التجمع الخلفي في شبكة فرعية لشبكة Azure الظاهرية. يمكنك حماية VMs في هذه الشبكة عن طريق تكوين مجموعة أمان شبكة (NSG). تطبيق NSG قواعد الأمان الواردة والصادرة التي يمكن أن تحد من حركة المرور الدخول والخروج من شبكة الاتصال الظاهرية لمجموعة من نقاط النهاية المعرفة جيدًا.
على سبيل المثال، يسمح VMs في تجمع النهاية الخلفية موازن التحميل عادةً حركة المرور الواردة على المنفذ 80 (HTTP) والمنفذ 443 (HTTPS) التي تصل من خارج شبكة الاتصال الظاهرية. ولكن قد يمنع نظام VMs حركة المرور التي تظهر على منافذ أخرى.
أعراض وأسباب الفشل لدى Load Balancer
تنشأ مشاكل عند فقدان "Load Balancer" الاتصال مع واحد أو أكثر من VMs في تجمع النهاية الخلفية. وتشمل الأعراض النموذجية:
- التطبيق غير قابل للوصول.
- VMs التي تشغل التطبيق غير قابلة للوصول.
- أوقات الاستجابة بطيئة.
- طلبات المستخدم قد توقفت.
ويمكن أن تكون هناك أسباب كثيرة لهذه الإخفاقات. وهي الأكثر شيوعًا المرتبطة بالقضايا المتعلقة بمشكلات التقصي ومشكلات مسار البيانات.
قضايا التقصي
ينتج عن مشكلات التقصي عند فشل VMs واحد أو أكثر في تجمع النهاية الخلفية في الاستجابة لطلبات التحقيق الصحية. ويمكن أن تكون هذه المشكلات نتيجة:
- تكوين تقصي غير صحيح، مثل URL أو منفذ غير صحيح.
- VM الذي يفشل في الاستجابة إلى التحقيق لأن المنفذ المطلوب غير مفتوح.
مشكلات مسار البيانات
تحدث مشكلات مسار البيانات عند Load Balancer غير قادر على توجيه طلب عميل إلى التطبيق الذي يتم تشغيله على VM في تجمع النهاية الخلفية. تتضمن الأسباب المحتملة:
- تقوم قاعدة NSG أو جدار الحماية بحظر المنافذ أو عناوين IP المستخدمة من قِبَل التطبيق.
- VM معطل أو لا يستجيب. قد يكون VM قيد إيقاف التشغيل أو فشل، أو هناك مشكلة أمنية مثل شهادة منتهية الصلاحية على الخادم.
- لا يستجيب التطبيق. قد يكون VMs محملاً فوق طاقته أو التطبيق هو الاستماع على منفذ غير صحيح أو تعطل التطبيق.