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

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

استكشاف فشل الانتقال الضروري في HA

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

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

• من vSocket WebUI، قم بتشغيل أداة اختبار API لكل من vSockets.
• تتحقق هذه الأداة من نجاح استدعاء API لـ AWS.
• يمكن رؤية أي أخطاء تتعلق بالأذونات أو تحديثات جداول التوجيه هنا.
  

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

• تحقق من تكوين خادم DNS الافتراضي لـ AWS لوحدة VPC المرتبطة. 
• للتحقق من تكوين DNS في AWS، انظر إصلاح مشكلات تكوين DNS 
• إذا كان خادم DNS مخصص (مثل خادم DNS خاص) مُكوَّن، تأكد من أنه يمكنه حل النطاقات العامة. تحقق من أنه يمكنه حل اسم المجال الكامل ec2.<region>.amazonaws.com (مثل ec2.us-east-1.amazonaws.com)، الذي يستخدمه API.
• يجب على مجموعة الأمان المرتبطة بواجهة إدارة 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 Keepalive لا تصل إلى vSocket الثانوي

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

التحقق من إصدارات البرمجيات

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

التحقق من HA Keepalives

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

قم بإجراء الفحوصات التالية لتأكيد الاتصال بالشبكة المحلية:

• تحقق مما إذا كانت مجموعة الأمان الشبكية تمنع منفذ UDP/20480. طريقة سريعة للتحقق من قواعد NSG هي الذهاب إلى كل واجهة شبكة LAN في AWS والتحقق من القواعد الواردة والصادرة كما هو مبين في تحقق ما إذا كانت مجموعة الأمان الشبكية تحظر حركة المرور الصادرة.
• تأكد من أن كلا من واجهات LAN مرتبطة بشبكات فرعية مختلفة.
• قم بتنفيذ التقاط الحزمة من WebUI لكلا 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.

رفع الحالات إلى دعم كاتو

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

• وصف واضح للمشكلة، بما في ذلك رسائل الخطأ إن وجدت.
• إعدادات DNS في VPC.
• نتائج اختبار API.
• لقطات شاشة لجدول توجيه LAN والأدوار المكونة لـ IAM.
• إذا أمكن، ملفات CloudTrail في وقت فشل الفشل.