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

التعيين

يوفر هذا الدليل إطارًا مفصلًا لاستكشاف الأخطاء وإصلاحها للتعامل مع المشكلات الشائعة التي تحدث أثناء نشر AWS vSocket عالي التوافر (HA). سواء تم النشر يدويًا أو عبر AWS Marketplace، تهدف هذه الخطوات إلى المساعدة في تحديد المشكلات المحتملة وحلها بشكل فعال.

الأعراض

قد تتضمن المشكلات الشائعة في عمليات نشر AWS vSocket HA ما يلي:

• فشل الاستهداف التلقائي HA

  • فشلت اختبارات HA API من vSocket WebUI.

  • فشل الانتقال اللازم في HA مما يؤدي إلى عدم توجيه الحركة إلى vSocket الثانوي.

• حالة HA غير جاهزة

  • يعرض CMA حالة HA للموقع على أنها "غير جاهزة"

الأسباب الممكنة

غالبًا ما تكون أعطال عمليات نشر HA بسبب الآتي:

• استخدام DNS غير عام في AWS.

• واجهة الإدارة تفتقر إلى الوصول إلى الإنترنت.

• خطأ في تكوين دور IAM.

• إعدادات مجموعة الأمان والتوجيه في AWS مقيدة.

• فشل في تعيين واجهة الشبكة المناسبة لجداول توجيه LAN.

• مشاكل اتصال LAN.

استكشاف المشكلة وحلها

مهم:

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

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

إذا لم يتم توجيه الحركة إلى vSocket الثانوي أثناء الانتقال اللازم، فكر في تنفيذ خطوات استكشاف الأخطاء التالية:

تشغيل اختبار HA API

• من vSocket WebUI، قم بتشغيل أداة اختبار API لكل من vSockets.

• تتحقق هذه الأداة من نجاح استدعاء API لـ AWS.

• يمكن رؤية أي أخطاء تتعلق بالأذونات أو تحديثات جداول التوجيه هنا.
  

التحقق من إعدادات DNS في AWS

• تحقق من تكوين خادم DNS الافتراضي لـ AWS لوحدة VPC المرتبطة. 

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

• إذا تم تكوين خادم DNS مخصص (على سبيل المثال، خادم DNS خاص)، تأكد من أنه يمكنه حل النطاقات العامة. تحقق من أنه يمكن حل FQDN ec2.<region>.amazonaws.com (مثل ec2.us-east-1.amazonaws.com)، الذي يستخدمه الواجهة البرمجية.

• يجب على مجموعة الأمان المرتبطة بواجهة إدارة MGMT السماح بطلبات DNS إلى 8.8.8.8 و8.8.4.4، حتى لو تم تكوين خادم DNS الافتراضي لـ AWS.

تحقق من جدول توجيه LAN

• لتوجيه الحركة إلى vSocket الرئيسي، تعين AWS الواجهة الشبكية المحلية الحالية لـ vSocket الرئيسي إلى جدول توجيه LAN.

• انتقل إلى VPC > جداول التوجيه وحدد جدول توجيه LAN. تحت لسان Routes، تحقق من أن واجهة شبكة LAN لـ vSocket الرئيسي هي بوابة المسار الافتراضي (الهدف). إذا لم يكن كذلك، تابع مع الخطوات التالية.  

• يرجى ملاحظة أنه يمكن تعديل جدول التوجيه المحلي يدويًا كحل مؤقت إذا لم تكن بطاقة NIC الهدف قد تغيرت أثناء الانتقال اللازم.

التحقق من دور IAM

• أثناء نشر AWS vSocket، يتم إنشاء دور HA IAM Role وربطه بكل من vSockets الأولية والثانوية.

• تحت صفحة تفاصيل كل مثيل، تأكد من تعيين دور IAM الصحيح.  

• انقر على رابط دور IAM، وتحت تبويب الأذونات، تحقق من أن سياسة IAM تحتوي على البيان الصحيح، كما هو مبين أدناه.  

ملاحظة: في حالة فقدان دور IAM، بمجرد إضافة الدور، يجب إعادة تشغيل الوصلات لكي يتم تفعيل الأدوار المضافة.

التحقق من إعدادات IMDS

• تأكد من أن كلا vSockets يستخدمان إعدادات IMDS متطابقة (اختياري أو مطلوب). لمزيد من المعلومات، راجع وثائق AWS.

• بدءًا من بناء vSocket 20.0.18221، يتم دعم IMDSv2.

• لتعديل إعدادات IMDS، اختر المثيل، وتحت الإجراءات، انقر على إعدادات المثيل > تعديل خيارات بيانات المثيل.

التحقق من مجموعة الأمان للشبكة.

• تأكد من أن مجموعة الأمان للشبكة لا تحظر حركة المرور الصادرة لواجهة الإدارة.

• تحت EC2 > واجهات الشبكة، ابحث عن مجموعة الأمان المرتبطة بواجهة الإدارة 

• تحقق من أن قواعد المجموعة الأمنية الصادرة تسمح بالمنافذ 80 و 443 و 53. في هذه الحالة، يتم السماح بجميع حركة الخروج.
  

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

• إذا كان يتم توجيه حركة مرور واجهة MGMT عبر جدار حماية تابع لجهة خارجية في AWS، تحقق من السماح باتصالات UDP/53 وTCP/80 وTCP/443 الصادرة.

• من صفحة واجهات الشبكة، انقر على معرف الشبكة الفرعية لواجهة MGMT. 

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

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

• في علامة التبويب خريطة الموارد لـ VPC، يتم تمثيل جميع الشبكات الفرعية المرتبطة وإعدادات توجيهها بصريًا لسهولة الرجوع إليها

• تأكد من اقتران IP مرن بواجهة MGMT. يمكن رؤية ذلك من علامة تبويب الشبكات للمثيل. يمكن تحديد واجهة MGMT من خلال فهرس الجهاز الخاص بها بالقيمة 0. يجب أن تكون واجهات WAN وLAN مقترنة بفهارس الجهازين 1 و2 على التوالي.  

التحقق من سجلات CloudTrail

• قم بتمكين AWS CloudTrail لتسجيل استدعاءات API لـ AWS لتتبع التعديلات الفاشلة في جدول توجيه LAN أثناء الانتقال الضروري في HA.

• يمكنك اتباع العملية لإنشاء الأثر، وتحديد دلو S3 لتخزين السجلات، وتحديد أحداث الإدارة التي تتضمن نشاط API. انظر إنشاء أثر.
  

استكشاف حالة 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 لـ AWS vSocket وستُرسَل فقط من vSocket الماستر إلى vSocket الاحتياطي. تحدث حالة انقسام الدماغ عندما يمتلك كلا vSockets دور الرئيسي، وهو ما قد يحدث بسبب مشكلات اتصال LAN بين vSockets التي تخلق وضعًا لا تصل فيه رسائل HA Keepalive إلى vSocket الثانوي

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

• تحقق مما إذا كانت مجموعة أمان الشبكة تحظر المنفذ UDP/20480. وسيلة سريعة للتحقق من قواعد NSG هي الذهاب إلى كل واجهة شبكة محلية في AWS والتحقق من القواعد الواردة والصادرة كما هو موضح في تحقق مما إذا كانت مجموعة الأمان الشبكي تحجب حركة المرور الصادرة.

• تأكد من أن كلتا واجهتي LAN مرتبطتان بشبكتي LAN فرعيتين مختلفتين.

• قم بتنفيذ التقاط الحزمة من واجهة الويب لكل من vSockets وحدد ما إذا كان vSocket الثانوي يتلقى إشارات الحياة المرسلة من قبل الأساسي.

حل المشكلات التي تم اكتشافها

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

• لإصلاح مشكلات تكوين DNS، تحقق من تكوين خادم DNS الافتراضي لـ AWS لـ VPC.

• تحت تفاصيل VPC، ابحث عن مجموعة DHCP المُعدَّة لها.

• افتح مجموعة خيارات DHCP وتحقق من أن خادم اسم النطاق المعرف هو AmazonProvidedDNS.

• لا يمكن تغيير خوادم أسماء النطاق الموجودة. لذلك، أنشئ مجموعة خيارات DHCP جديدة، والتي ستستخدم AmazonProvidedDNS افتراضيًا.

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

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

• من المهم إزالة الآلة الافتراضية ولكن الاحتفاظ بواجهات الشبكة، وعنوان IP العام المرتبط، ودور IAM قبل إعادة نشر vSocket.

• بالإضافة إلى ذلك، تذكر إعادة ضم دور IAM الصحيح إلى vSocket عن طريق تحديد مثيل vSocket > الأمان > ضم دور IAM وتعيين دور AWS-HA.

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

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

• وصف واضح للمشكلة، بما في ذلك أية رسائل خطأ.

• إعدادات DNS في VPC.

• نتائج اختبار API.

• لقطات شاشة لجدول توجيه LAN والأدوار المكونة لـ IAM.

• إذا أمكن، ملفات CloudTrail في وقت فشل الفشل.