تشخيص المشكلات من خلال مراجعة التكوينات والمقاييس
قد يؤدي مراقبة أداء "Azure Load Balancer" إلى إعطاء تحذير مبكر لأي حالات فشل محتملة. يوفر Azure Monitor العديد من المقاييس الهامة التي تستخدمها لفحص الاتجاهات في أداء Load Balancer. يمكنك أيضًا تشغيل التنبيهات إذا فشل واحد أو أكثر من الأجهزة الظاهرية (VMs) في طلبات التحقيق الصحية.
في المثال السيناريو، يمكنك مراقبة أداء نظام التحميل المتوازن للتأكد من أن الأداء يفي بالمتطلبات. إذا تم إيقاف تشغيل الأداء، وبدء فشل الاتصالات بالأجهزة الظاهرية، يمكنك استكشاف أخطاء النظام وإصلاحها لتحديد السبب وإصلاح المشكلة. بنهاية هذه الوحدة، ستتمكن من:
- وصف المقاييس المتوفرة لقياس الإنتاجية والأداء لنظام متوازن التحميل.
- استخدم صفحة صحة المورد في بوابة Azure لمراقبة صحة النظام.
- شرح كيفية حل المشاكل الشائعة في نظام التحميل المتوازن.
استخدام Azure Monitor لاستكشاف أخطاء موازن التحميل وإصلاحها
باستخدام "Azure Monitor"، يمكنك التقاط وفحص سجلات التشخيص وبيانات الأداء لموازنة التحميل.
اتصال جهاز العرض
يمكنك تصور مقاييس لـ "Load Balancer" باستخدام جزء "Metrics" في مدخل "Azure". من منظور استكشاف أخطاء الاتصال وإصلاحها، فإن أهم المقاييس هي Data Path Availability وحالة التقصي الصحي.
يختبر Load Balancer باستمرار توفر المسار إلى عنوان IP الأمامية من خلال قواعد موازنة التحميل وتجمع النهاية الخلفية إلى التطبيقات قيد التشغيل على VMs الخاص بك. يتم تسجيل هذه المعلومات على أنها مقياس Data Path Availability. تطبيق مقياس متوسط يظهر متوسط التوافر لفترة زمنية معينة. هذا التجميع هو قيمة بين 0 (عدم توفر) و100، حيث يتوفر مسار واحد على الأقل ناجح من عنوان IP الأمامية إلى VM في تجمع النهاية الخلفية.
مقياس حالة التقصي الصحي مشابه، ولكنه ينطبق فقط على التحقيق الصحي لـ VMs بدلاً من المسار الكامل من خلال Load Balancer. مرة أخرى، يوفر تجميع Avg لهذا المقياس قيمة بين 0 (جميع الأجهزة الظاهرية غير صحية وفشلت في الاستجابة) و100، حيث تستجيب جميع الأجهزة الظاهرية للتحقيق الصحي.
تظهر لقطة الشاشة التالية المخطط لمتوسط Data Path Availability ومتوسط Health Probe Status لموازن التحميل مع جهازي VMs في التجمع الخلفي. واحدة من الآلات لا تستجيب للتقصي الصحي. متوسط Health Probe Status تحوم حول علامة 50 في المئة.
طريقة أخرى لفحص هذه القياسات استخدام تجميع عدد. يمكن أن يوفر هذا النهج رؤى أخرى حول المشكلات المحتملة في التكوين الخاص بك. يعرض المثال التالي الرسومات البيانية لعدد قياسات حالة التحقيق الصحي ومدى توفر مسار البيانات. يوضح الرسم البياني عدد المسابر الناجحة التي تم إنجازها بمرور الوقت.
نقطة مثيرة للاهتمام في هذا المخطط هي أن عدد تحقيقات توفر مسار البيانات الناجحة ظل ضمن نطاق متناسق. ومع ذلك، تم ارتفاع عدد عمليات التحقق من حالة التحقيق الصحي الناجحة للحظات ومن ثم انخفض إلى حوالي نصف القيمة قبل حدوث الارتفاع.
في الإعداد المستخدم لإنشاء هذا الرسم البياني، يحتوي تجمع النهاية الخلفية على جهازي VMs فقط. تم إيقاف أحد هذه الأجهزة، لمحاكاة فشل. يوضح مقياس توفر مسار البيانات أنه لا يزال من الممكن أن يتصل تطبيق عميل بالتطبيق الذي يعمل على VM العامل المتبقي. ولكن حالة التحقيق الصحي تشير إلى أن الصحة العامة للمجموعة الخلفية ليست سوى نصف ما كانت عليه في السابق.
عرض صحة الخدمة
صفحة صحة الموارد لـ " Load Balancer" تقارير عن الحالة العامة للنظام الخاص بك. يمكنك الوصول إلى هذه الصفحة في المدخل من "Azure Monitor". حدد "Service Health"، ثم حدد "Resource "Health، وبعد ذلك حدد "Load Balancer" كنوع مورد.
حدد موازن التحميل الخاص بك. ترى تقريرا يفصل التاريخ الصحي للخدمة الخاصة بك. يمكنك توسيع أي عنصر في التقرير لعرض التفاصيل. تعرض الصورة التالية التلخيص الذي تم إنشاؤه عند أخذ أحد VMs في تجمع النهاية الخلفية دون اتصال.
مراقبة حمل العمل لكل VM
تمكنك المقاييس الأخرى المتوفرة لـ "Load Balancer" من تعقب عدد وحدات البايت وحزم الشبكة التي تمر عبر موازن التحميل لكل نهاية أمامية. يتم تعريف الواجهة الأمامية كمزيج من عنوان IP لـ "موازن التحميل" والبروتوكول المستخدم لقبول الطلبات الواردة ورقم المنفذ المستخدم من قبل قاعدة موازنة التحميل للاتصال بـ VMs. يمكن أن توفر هذه المقاييس مقياسًا لمقياس سرعة نقل النظام لكل VM نشط.
يوضح الرسم البياني التالي متوسط عدد الحزم المتدفقة من خلال موازن التحميل في أثناء تشغيل حمل عمل اختبار من 500 مستخدم متزامن لمدة دقيقتين. تم تشغيل عبء العمل مرتين. في المرة الأولى، يحتوي تجمع النهاية الخلفية على مثيلين VM. بالنسبة إلى تشغيل الثاني تم إيقاف تشغيل أحد VMs (محاكاة فشل).
في هذا المخطط، تضاعف متوسط عدد الحزمة لكل نهاية أمامية عند إيقاف تشغيل VM واحد. حجم العمل هذا قد يزيد التحميل الزائد على VM المتبقية، ما قد يؤدي إلى تمديد أوقات الاستجابة وحالات توقف ممكنة.
التحقيق في المشاكل الشائعة مع موازن التحميل ومعالجتها
يغطي هذا القسم بعض سيناريوهات الفشل الشائعة التي قد تصادفها مع موازن التحميل. يلخص كل سيناريو أعراض فشل وكيف يمكن حل المشكلة.
لا تستجيب VMs خلف موازن التحميل لحركة المرور على منفذ التحقيق
قد تكون هذه المشكلة نتيجة المشكلات التالية:
لا تستمع VMs في تجمع النهاية الخلفية على منفذ التحقيق الصحيح.
تحقق من تعيين التحقيق الصحي بشكل صحيح في موازن التحميل. تأكد من أن التعليمات البرمجية للتطبيق التي تعمل على كل VM تستجيب بشكل مناسب لطلبات التحقيق. يجب أن ترجع رسالة استجابة HTTP 200 (موافق).
NSG للشبكة الفرعية شبكة الاتصال الظاهرية التي تستضيف VMs بحظر منفذ التحقيق.
تحقق من تكوين NSG للشبكة الفرعية شبكة الاتصال الظاهرية التي تحتوي على VMs. تأكد من أن NSG يسمح بحركة المرور من موازن التحميل لتمرير من خلال منفذ التحقيق الصحي.
أنت تحاول الوصول إلى موازن التحميل من نفس VM وبطاقة الشبكة الظاهرية. لا تتعلق هذه المشكلة بالتحقيق ولكن بسيناريو مسار بيانات غير معتمد.
أنت تحاول الوصول إلى الواجهة الأمامية لموازنة التحميل من VM في تجمع النهاية الخلفية.
كل من هذه العناصر هي مشاكل تصميم التطبيق. تجنب إرسال طلبات إلى نفس مثيل "موازن التحميل" من VM في تجمع النهاية الخلفية.
VM في تجمع النهاية الخلفية غير صحي
في هذه الحالة، يستجيب معظم VMs بشكل طبيعي، ولكن لا يستجيب جهاز واحد أو جهازان آخران. لأن بعض VMs قبول حركة المرور، من المحتمل أن يتم تكوين التحقيق صحة بشكل صحيح. لا تقوم NSG للشبكة الفرعية بحظر المنفذ المستخدم من قبل التحقيق الصحي. المشكلة ربما تكمن في VMs غير صحية. قد تكون هذه المشكلة بسبب عدم الوصول إلى VMs أو خفضه، أو وجود مشكلة في تطبيق على هذه الأجهزة.
استخدم الخطوات التالية لتحديد سبب المشكلة مع VM غير صحية:
- تسجيل الدخول إلى VM غير صحية للتحقق من أنه يصل. تحقق من أن الجهاز الظاهري يمكنه الاستجابة إلى الفحوصات الأساسية مثل pingأو rdpأو طلبات ssh من VM آخر في تجمع النهاية الخلفية.
- إذا كان الجهاز الظاهري لأعلى ويمكن الوصول إليها، تحقق من تشغيل التطبيق.
- تشغيل
netstat -anالأمر والتحقق من أن المنافذ المستخدمة من قبل التحقيق الصحية والتطبيق مسرودة كـ LISTENING.
تكوينات خاطئة في موازن التحميل
يتطلب "موازن التحميل" تكوين قواعد التوجيه التي توجه حركة المرور الواردة من الواجهة الأمامية إلى تجمع النهاية الخلفية بشكل صحيح. إذا كانت قاعدة التوجيه مفقودة أو لم يتم تكوينها بشكل صحيح، يتم إسقاط نسبة استخدام الشبكة التي تصل إلى الواجهة الأمامية. بمجرد إسقاط حركة المرور، يتم الإبلاغ عن التطبيق للعملاء على أنه غير قابل للوصول.
التحقق من صحة التوجيه من خلال موازن التحميل من الواجهة الأمامية إلى تجمع النهاية الخلفية. يمكنك استخدام أدوات مثل Ping وTCPing وnetsh، والتي تتوفر لنظامي التشغيل Windows وLinux. يمكنك أيضا استخدام psping على النوافذ. تصف الأقسام التالية كيفية استخدام هذه الأدوات.
استخدام ping
يختبر أمر ping اتصال ping من خلال نقطة نهاية باستخدام بروتوكول ICMP. للتحقق من توفر توجيه من العميل إلى VM من خلال Load Balancer، شغل الأمر التالي. استبدل <عنوان> ip بعنوان IP لمثيل Load Balancer.
ping -n 10 <ip address>
| Switch | الوصف |
|---|---|
| -n | يحدد رمز التبديل هذا عدد طلبات ping لإرسالها. |
يبدو الإخراج النموذجي كما يلي:
ping -n 10 nn.nn.nn.nn
Pinging nn.nn.nn.nn with 32 bytes of data:
Reply from nn.nn.nn.nn: bytes=32 time=34ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Ping statistics for nn.nn.nn.nn:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 34ms, Average = 30ms
استخدام PsPing
اختبار الأمر PsPing الاتصال ping خلال نقطة نهاية. يقيس هذا الأمر أيضًا زمن الوصول وتوافر عرض النطاق الترددي للخدمة. للتحقق من توفر توجيه من العميل إلى VM من خلال Load Balancer، شغل الأمر التالي. استبدال <عنوان IP> و<المنفذ> بعنوان IP ومنفذ الواجهة الأمامية لمثيل موازنة التحميل.
psping -n 100 -i 0 -q -h <ip address>:<port>
| وضع علامة | الوصف |
|---|---|
| -n | تحديد عدد عمليات تنفيذ عمليات الـ ping. |
| -i | الإشارة إلى الفاصل الزمني بالثواني بين التكرارات. |
| -q | منع الإخراج في أثناء ping. يتم عرض ملخص فقط في النهاية. |
| -h | طباعة مدرج تكراري يظهر زمن الوصول للطلبات. |
يبدو الإخراج النموذجي كما يلي:
TCP connect to nn.nn.nn.nn:nn:
101 iterations (warmup 1) ping test: 100%
TCP connect statistics for nn.nn.nn.nn:nn:
Sent = 100, Received = 100, Lost = 0 (0% loss),
Minimum = 7.48ms, Maximum = 9.08ms, Average = 8.30ms
Latency Count
7.48 3
7.56 2
7.65 2
7.73 2
7.82 7
7.90 4
7.98 4
8.07 6
8.15 9
8.24 9
8.32 11
8.40 7
8.49 11
8.57 12
8.66 3
8.74 2
8.82 2
8.91 1
8.99 2
9.08 1
استخدام tcping بين الـ 2
الأداة المساعدة tcping مشابهة ل ping إلا أنها تعمل عبر اتصال TCP بدلا من ICMP. استخدم tcping كما يلي:
tcping <ip address> <port>
يبدو الإخراج النموذجي كما يلي:
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.042ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.810ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.266ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.181ms
Ping statistics for nn.nn.nn.nn:nn
4 probes sent.
4 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 9.042ms, Maximum = 9.810ms, Average = 9.325ms
استخدام netsh
الأداة المساعدة netsh هي أداة تكوين شبكة اتصال للغرض العام. استخدم الأمر التتبع في netsh لالتقاط حركة مرور شبكة الاتصال. ثم قم بتحليله باستخدام أداة مثل Wireshark. استخدم تتبع netsh لفحص حزم الشبكة المرسلة والمستلمة بواسطة psping عند اختبار الاتصال من خلال موازن التحميل كما يلي:
بدء تشغيل تتبع شبكة اتصال من موجه الأوامر الذي يتم تشغيله كمسؤول. يتتبع المثال التالي حركة مرور عميل إنترنت (طلبات HTTP) من وإلى عنوان IP المحدد. استبدال <عنوان IP> بعنوان مثيل موازنة التحميل. بيانات التتبع مكتوبة إلى ملف يسمى trace.etl.
netsh trace start ipv4.address=<ip address> capture=yes scenario=internetclient tracefile=trace.etlتشغيل psping لاختبار الاتصال من خلال موازن التحميل.
psping -n 100 -i 0 -q <ip address>:<port>إيقاف التتبع.
netsh trace stopيستغرق هذا الأمر بضع دقائق لإكماله لأنه يرتبط بالمعلومات ويدمجها في أثناء إنشاء ملف إخراج التتبع.
ابدأ تشغيل Wireshark ثم افتح ملف التتبع.
إضافة عامل التصفية التالي إلى التتبع. استبدال <nn> برقم منفذ الواجهة الأمامية لموازنة التحميل.
TCP.Port==80 or TCP.Port==<nn>إضافة مصدر طلب HTTP والوجهة كـ حقول إلى إخراج التتبع.
فحص رسائل التتبع:
- إذا لم تكن هناك حزم واردة إلى موازن التحميل، فمن المحتمل أن تكون هناك مشكلة في أمان الشبكة أو مشكلة توجيه معرّفة من قبل المستخدم.
- إذا لم يتم إرجاع أي حزم صادرة إلى العميل، فمن المحتمل أن يكون هناك مشكلة في تكوين التطبيق أو مشكلة توجيه معرّفة من قبل المستخدم.
VM جدار الحماية أو NSG حظر المنفذ
إذا تم تكوين الشبكة وموازن التحميل بشكل صحيح، يكون الجهاز الظاهري قيد التشغيل، والتطبيق قيد التشغيل، يمكن أن يقوم جدار الحماية أو تكوين NSG للأجهزة الظاهرية بحظر المنفذ المستخدم من قبل التحقيق الصحي أو التطبيق. استخدم الخطوات التالية لتحديد ما إذا كانت هذه هي الحالة:
إذا كان هناك جدار حماية على VM، فقد يكون حظر الطلبات على المنافذ المستخدمة من قبل التحقيق الصحي والتطبيق. التحقق من تكوين جدار الحماية على المضيف للتأكد من أنه يسمح حركة المرور على المنافذ المستخدمة من قبل التحقيق الصحة والتطبيق.
تحقق من أن أي NSG لـ NIC VM يسمح بالدخول والخروج على المنافذ الضرورية. تحقق من وجود قاعدة رفض كافة في NSG على NIC VM التي لها أولوية أعلى من القاعدة الافتراضية.
هام
يمكنك إقران NSG مع شبكة فرعية وNIC الفردية من VMs في الشبكة الفرعية. ربما قمت بتكوين NSG لشبكة فرعية للسماح لحركة المرور بالمرور عبر منفذ. ومع ذلك، إذا أغلقت NSG لـ VM نفس المنفذ، فلن تحصل على الطلبات من خلال ذلك VM.
قيود موازن التحميل
موازن التحميل يعمل في الطبقة 4 في مكدس شبكة ISO ولا يفحص أو التلاعب بأي شكل آخر محتويات حزم الشبكة. لا يمكنك استخدامه لتنفيذ التوجيه المستند إلى المحتوى.
يتم إنهاء كافة طلبات العميل بواسطة VM في تجمع النهاية الخلفية. موازن التحميل غير مرئي للعملاء. إذا لم تتوفر أجهزة ظاهرية، يفشل طلب العميل. لا يمكن للتطبيقات العميلة التواصل مع أو استجواب حالة موازن التحميل أو أي من مكوناته.
إذا كنت بحاجة إلى تطبيق موازنة التحميل استنادًا إلى محتويات الرسائل، ففكر في استخدام بوابة تطبيقات Azure. أو يمكنك تكوين خادم ويب وكيل لمعالجة طلبات العملاء الواردة وتوجيهها نحو VMs معينة.