استكشاف أخطاء 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.

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

مهم:

هام: قبل بدء عملية استكشاف الأخطاء وإصلاحها، تأكد من التحقق من جميع المتطلبات الأساسية لنشر vSocket في Azure HA. راجع تكوين HA لـ Azure vSockets ونشر Azure vSockets من السوق

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

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

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

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

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

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

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

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

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

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

• للتحقق من تكوين DNS في Azure، انظر إصلاح مشكلات تكوين DNS

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

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

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

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

إعادة تشغيل برنامج 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 العائم

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

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

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

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

يجب ربط هوية HA بشكل صحيح بجميع موارد 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. للتحقق من ذلك، انتقل إلى الأمان > الهوية > المعين للنظام وتأكد من أن الخيار الحالة مضبوط على إيقاف لكل VM vSocket.

• إذا لم يتم تثبيت دور هوية HA على أي من الموارد المذكورة أعلاه، فقد يكون فشل عملية النشر في القيام بذلك. يمكنك تشغيل نص Cato HA مرة أخرى إذا كان الدور مفقودًا من أي من الموارد المعنية. بدلاً من ذلك، يمكن إعادة نشر vSocket الثانوي في Azure من خلال السوق ،والتي ستقوم بتثبيت الأدوار الهوية HA المفقودة.

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

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

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

  • اذهب إلى الآلة الافتراضية > Socket > تشغيل الأمر > RunShellScript

  • أدخل dig management.azure.com في مربع النص

  • انقر تشغيل

• سيتم عرض إخراج الحفر في البوابة مع استجابة DNS.
  

• إذا لم تكن هناك حلول DNS، انظر إصلاح مشكلات تكوين DNS.

• من نفس الصفحة، حاول الوصول إلى أي مورد على الإنترنت للتأكد من الوصول إلى الإنترنت. مثلاً، ping -c 4 8.8.8.8 إذا لم يكن ping ناجحًا، تابع مع الخطوات التالية.
  

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

تنويه:

ملاحظة: إذا تم تنفيذ الحل 2-NIC على vSockets. قم بتنفيذ خطوة استكشاف الأخطاء وإصلاحها هذه على واجهة WAN.

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

• توضح لقطة الشاشة أدناه أنه لم يتم تعيين NSG، لذا لم يتم حظر حركة المرور الصادرة.

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

تنويه:

ملاحظة: إذا تم تنفيذ الحل 2-NIC على vSockets. قم بتنفيذ خطوة استكشاف الأخطاء وإصلاحها هذه على واجهة WAN.

• في حالة توجيه حركة واجهة 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 ، بما في ذلك أي أخطاء تم العثور عليها.