استكشاف أخطاء vSocket Azure HA وإصلاحها

نظرة عامة

يوفر هذا المقال رؤى حول مشاكل النشر الشائعة لـ vSocket HA Azure ويقدم خطوات لاستكشاف الأخطاء وإصلاحها. يهدف هذا الدليل إلى المساعدة في تحديد ومعالجة العقبات المحتملة أثناء وبعد نشر الحل HA إما عبر برنامج HA أو السوق.

الأعراض

عند نشر Azure vSocket HA، قد تواجه الأعراض التالية:

• فشل برنامج HA
  • الفشل في تنفيذ برنامج create_ha_settings في النشر اليدوي.
  • مشاكل في نشر vSocket الثانوي عبر السوق.
• فشل الاستهداف التلقائي HA
  • فشل اختبارات API لـ HA من واجهة Socket WebUI.
  • فشل الاستهداف التلقائي لـ HA الذي يؤدي إلى عدم توجيه الحركة إلى vSocket الثانوي.
• حالة HA غير جاهزة
  • يعرض CMA أن حالة HA للموقع غير جاهزة

الأسباب المحتملة

تتضمن الأسباب الأكثر شيوعًا لفشل نشر HA ما يلي:

• استخدام DNS غير عام في Azure.
• واجهة الإدارة تفتقر إلى الوصول إلى الإنترنت.
• أذونات حساب Azure غير كافية.
• إعدادات مجموعة الأمان والتوجيه المقيدة في Azure.
• فشل في تعيين عنوان IP العائم لواجهة LAN.
• مشاكل اتصال LAN.

استكشاف المشكلة

استكشاف فشل برنامج HA

يؤكد برنامج Azure HA (create_ha_settings) ونشر vSocket الثانوي عبر السوق أن اشتراك Azure يحتوي على اثنين من vSockets الصالحة ثم تعيين أدوار الهوية التي تنشئ آلية HA والاستهداف التلقائي. إذا فشلت تشغيل البرنامج، اتبع خطوات استكشاف الأخطاء وإصلاحها التالية:

مراجعة سجلات النشاط

• في Azure، يتم تخزين سجلات النشاط جميع الأحداث التي حدثت داخل كل مورد Azure. راجع هذه السجلات إذا لم يكن النشر ناجحًا ولم يتم تعيين أحد الأدوار. تصفح إلى VM أو NIC واختر سجل النشاط
  

مراجعة قيود تسمية Azure 

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

  قيمة معلمة disk.name غير صالحة. (الرمز: InvalidParameter، الهدف: disk.name)

مراجعة تكوين DNS لـ Azure

• تأكد من أن DNS الافتراضي لـ Azure تم تكوينه لكل من VNET وNICs المرتبطة. إذا لم يكن DNS الافتراضي مكون في Azure في كل من VNET وNIC، فسوف يفشل إنشاء الدور.
• للتحقق من تكوين DNS لـ Azure، راجع إصلاح مشاكل تكوين DNS 

مراجعة أذونات Azure

• لتشغيل برنامج HA بنجاح، تأكد من أن مستخدم Azure لديه أذونات مالك. اذهب إلى مجموعة الموارد > التحكم في الوصول IAM > عرض وصولي، وتحقق من تعيين حساب المستخدم كمالك أو دور أعلى. راجع الأدوار المدمجة في Azure.
  
  
  

التحقق من تعيين دور Azure 

• قم بتشغيل الخطوات الواردة في التحقق من تعيين دور Azure  لتأكيد أن دور الهوية المدرج في مجموعة الموارد مُعين لـ NICs LAN، الشبكة الفرعية LAN، وكلا VMs لـ vSocket.

إعادة تشغيل برنامج HA

• كملاذ أخير، يمكن إعادة تشغيل برنامج HA (create_ha_settings) بمجرد التحقق من الخطوات السابقة.
• تأكد من تجديد رمز Azure وإزالة الهوية المدارة لـ Azure إذا تم إنشاؤها أثناء تشغيل البرنامج الأول.

استكشاف فشل تجاوز الفشل لـ HA

إذا كان برنامج HA يعمل بنجاح ولكن تجاوز الفشل لـ HA vSocket لا يحدث كما هو متوقع (مثلاً الحركة لم يتم توجيها إلى vSocket الثانوي)، اتبع هذه الخطوات:

تشغيل اختبار واجهة برمجة التطبيقات لـ HA

• من واجهة Socket WebUI، قم بتشغيل أداة اختبار واجهة برمجة التطبيقات من كلا vSockets التي تؤكد أن نداء واجهة برمجة التطبيقات إلى Azure يمكن إجراؤه بنجاح. أي أخطاء في الأذونات أو تعيينات عنوان IP العائم يمكن رؤيتها هنا.
  

مراجعة سجل النشاط

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

التحقق من عنوان IP العائم

• من واجهة Socket WebUI، استعمل أداة Ping، اختر واجهة LAN، وقم بالتحقق من عنوان IP العائم. إذا لم يكن هذا الاختبار ناجحًا، تابع مع التحقق من تعيين عنوان IP العائم
  

التحقق من تعيين عنوان IP العائم

• لتوجيه الحركة إلى vSocket الرئيسي، يقوم Azure بتعيين عنوان IP العائم إلى LAN NIC لـ vSocket الرئيسي الحالي. انتقل إلى LAN NIC > تكوين IP في VM vSocket الأساسي وتحقق من أن عنوان IP العائم موجود ك"ثانوي". إذا لم يكن كذلك، تابع مع الخطوات التالية.

التحقق من تعيين دور Azure 

• أثناء نشر vSocket Azure، يتم إنشاء دور هوية HA وتخزينه في الهويات المُدارة لـ Azure
• يجب أن يتم تعيين دور معين بواسطة المستخدم فقط لكل مورد. إذا كانت السياسة تضيف هويات معينة بواسطة النظام في Azure، فيجب استبعاد vSockets منها.

• يتم تعيين هذا الدور للموارد الافتراضية المختلفة التي ترتبط بـ vSocket. المكونات في البنية التحتية لـ Azure التي تستخدم الدور هي:

  • واجهة شبكة LAN (NIC) لكل vSocket
  • الشبكة الفرعية LAN المرتبطة بـ NICs LAN
  • كلا VSocket VMs
• يمكن التحقق من تعيين الدور لـ NICs تحت التحكم في الوصول > تعيين الأدوار ويجب أن يتم تعيينه لكل من NICs LAN الأساسي والثانوي.
  
• يمكن التحقق من تعيين الدور لـ الشبكة الفرعية LAN تحت VNET > الشبكة الفرعية، ثم اختر الشبكة الفرعية LAN وانقر إدارة المستخدمين > تعيين الأدوار. 
  
• بالنسبة لكل VM vSocket، يمكن التحقق من دور الهوية تحت الأمان > الهوية > تعيين المستخدم كما هو واضح في لقطة الشاشة أدناه. لا ينبغي تعيين أي دور معين بواسطة النظام لـ VM.
• إذا لم يتم تثبيت دور هوية HA على أي من الموارد المذكورة أعلاه، فقد تكون عملية النشر قد فشلت في القيام بذلك. يمكنك تشغيل برنامج Cato HA مرة أخرى إذا كان الدور مفقودًا من أي من الموارد المعنية. بدلاً من ذلك، يمكن إعادة نشر vSocket الثانوي في Azure من خلال السوق ، والتي ستقوم بتثبيت الأدوار الهوية HA المفقودة.

التحقق من أن واجهة الإدارة لديها DNS ووصول إلى الإنترنت

• تحقق من أن واجهة الإدارة لديها وصول إلى الإنترنت ويمكنها الاتصال بخادم DNS المكون.

• تحقق من حل DNS لـmanagement.azure.com من بوابة Azure. يستخدم نداء واجهة برمجة تطبيقات HA هذا FQDN.

  • اذهب إلى الآلة الافتراضية > Socket > تشغيل الأمر > RunShellScript
  • أدخل dig management.azure.com في مربع النص
  • انقر تشغيل
• سيتم عرض إخراج dig في البوابة مع استجابة DNS.
  
  
• إذا لم يكن هناك حل DNS، راجع إصلاح مشاكل تكوين DNS.
• من نفس الصفحة، حاول الوصول إلى أي مورد على الإنترنت للتأكد من الوصول إلى الإنترنت. مثلاً، ping -c 4 8.8.8.8 إذا لم يكن ping ناجحًا، تابع مع الخطوات التالية.
  

تحقق مما إذا كانت مجموعة أمان الشبكة تحجب الحركة الصادرة.

• طريقة سريعة للتحقق هي الذهاب إلى واجهة الشبكة MGMT في Azure والضغط على "قواعد الأمان الفعالة" في الجانب السفلي الأيسر من الشاشة.
• تُظهر لقطة الشاشة أدناه عدم وجود NSG مُعين، لذلك لا يتم حظر الحركة الصادرة.

تحقق من توجيه واجهة MGMT لحركة الإنترنت.

• في حالة توجيه حركة واجهة MGMT عبر جدار حماية طرف ثالث في Azure، تحقق من السماح باتصالات UDP/53 وTCP/443 الصادرة.
• يمكن مراجعة جدول الطرق على صفحة واجهة الإدارة في Azure بالضغط على خيار "الطرق الفعالة".
• تُظهر لقطة الشاشة أدناه الطريق لحركة الإنترنت باستخدام الإنترنت كـ "نوع القفزة التالية"، لذلك الجدار الناري لا يحجب الحركة.
  

مراجعة القفزة التالية في جدول التوجيه

• تأكد من أن جدول توجيه LAN يشير إلى عنوان IP العائم. قم بتغيير عنوان IP القفزة التالية وفقًا لذلك إذا لزم الأمر.

استكشاف حالة HA غير جاهزة

إذا كان CMA يظهر أن حالة HA غير جاهزة وكلا vSockets يعملان، سيتخذ كل منهما دور الرئيسي (سيناريو تفكك الدماغ). قد تكون هناك مشكلتان مرتبطتان:

• كلا vSockets يعملان بإصدارات مختلفة من البرامج الثابتة
• رسائل الاحتفاظ بـ HA لا تصل إلى vSocket الثانوي

يوصى بالتحقق من صفحات كلا vSockets WebUI لتأكيد حالة HA لكل منها. سيناريو تفكك الدماغ سيظهر إذا كان كلا vSockets الأساسي والثانوي في دور الرئيسي. ستظهر واجهة WebUI الدور الحالي في أعلى صفحة المراقبة الرئيسية.

مراجعة إصدارات البرامج الثابتة

لتلبية معايير الإصدارات المتوافقة، يجب أن تعمل كلا vSockets بالإصدار الكبير نفسه، مثل v17.xx.yy أو v18.xx.yy. تقوم vSockets بترقية أولية بعد النشر الأول. إذا فشل أحد vSockets في الترقية، يجب استكشاف هذه المشكلة. قم بتقديم تذكرة دعم للإبلاغ عن هذه المشكلة.

التحقق من HA Keepalives

تستخدم حزم Keepalive المنفذ UDP/20480 لـ Azure vSocket وسيتم إرسالها فقط من vSocket الرئيسي إلى vSocket الاحتياطي. تحدث حالة انقسام الدماغ عندما يمتلك كلا vSockets دور الرئيسي، وهو ما قد يحدث بسبب مشكلات اتصال LAN بين vSockets التي تخلق وضعًا لا تصل فيه رسائل HA Keepalive إلى vSocket الثانوي. 

قم بتشغيل الفحوصات التالية لتأكيد اتصال LAN:

• تحقق مما إذا كانت مجموعة أمان الشبكة تحظر المنفذ UDP/20480. طريقة سريعة للتحقق من قواعد NSG هي الذهاب إلى كل واجهة شبكة LAN في Azure والنقر على "قواعد الأمان الفعالة" في الجانب السفلي الأيسر من الشاشة.
• تأكيد أن كلا واجهتي LAN مرتبطتين مع نفس الشبكة الفرعية LAN.
• تشغيل التقاط الحزم من واجهة الويب لكلا vSockets وتحديد ما إذا كانت keepalives المرسلة من الأساسي تُستلم بواسطة vSocket الثانوي.

حل المشكلات المكتشفة

تجديد رمز Azure

• إذا تم استخدام Azure Cloud Shell لنشر برنامج HA النصي، افتح جلسة جديدة وأعد المصادقة. سيؤدي ذلك إلى تجديد الرمز المستخدم للاستعلام عن API.
  

إصلاح مشكلات تكوين DNS

• لإصلاح تكوين DNS الخاص بـ Azure وضبطه إلى القيمة الافتراضية، انتقل إلى الشبكة الافتراضية > خوادم DNS وواجهات الشبكة > خوادم DNS، وتأكد من أنك تستخدم الخيار الافتراضي أو خادم DNS عام. أوقف تشغيل VM لإجراء أي تغييرات متعلقة بـ DNS ثم أعد تشغيله.
  
  

إلغاء تسجيل وإعادة نشر Azure vSocket

• إذا استمرت فشل الحزمة النصية HA أو الفشل في التحويل بعد اتباع جميع خطوات استكشاف الأخطاء الواردة أعلاه، يمكن إلغاء تسجيل وإعادة نشر واحد أو كلا vSockets. انظر إعادة نشر مواقع vSocket عالية التوفر
• من المهم اتباع الإرشادات وإزالة الآلة الافتراضية وواجهات الشبكة وعناوين IP العامة المرتبطة والهوية المُدارة قبل إعادة نشر vSocket.
• إذا تمت إعادة نشر فقط المثيل الرئيسي لـ vSocket، يجب تشغيل برنامج HA النصي المخصص (create_ha_settings) لربط كلا مثيلين vSocket لـ HA.

رفع الحالات إلى دعم Cato

أرسل تذكرة دعم بنتائج خطوات استكشاف الأخطاء المذكورة أعلاه. الرجاء تضمين المعلومات التالية في التذكرة:

• وصف واضح للمشكلة، بما في ذلك أية رسائل خطأ.
• نتائج اختبار DNS لـ management.azure.com
• نتائج اختبار API.
• لقطات شاشة لعنوان IP العائم المخصص، دور الهوية المكوَّن، المسارات الفعالة، والقواعد الأمنية الفعالة.
• لقطات شاشة سجل نشاط Azure ، بما في ذلك أي أخطاء تم العثور عليها.