المقدمة
يقدم المستند خطوات للتحقيق في عطل Unified Computing System Fabric Interconnect (FI) أو فشل إعادة تمهيد غير متوقع.
على المستوى العالي، قد تؤدي المشاكل التالية إلى إعادة تشغيل FI
- فشلت عملية Kernel الفضائية ( المعروفة باسم Kernel Panic )
- نفدت ذاكرة Kernel (نفاد الذاكرة - OOM يؤدي إلى قتل عملية مستخدم لاستعادة الذاكرة)
- تم تعطيل عملية مساحة المستخدم ( ex. - NetStack و fcoe_mgr و callHome وما إلى ذلك )
- مشكلة في البرنامج الثابت (سيناريو نادر، على سبيل المثال - CSCuq46105) أو فشل مكون الأجهزة (مثل SSD المستخدم للتخزين)
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
مدير نظام الحوسبة الموحدة (UCS) من Cisco
واجهة سطر الأوامر (CLI) لمدير نظام الحوسبة الموحدة (UCS) من Cisco
ملفات السجلات المطلوبة
عند إعادة تمهيد FI بشكل غير متوقع، قم بجمع السجلات التالية وتحميلها إلى طلب خدمة TAC.
- تحقق مما إذا كان ملف تفريغ الأساسي قد تم إنشاؤه في وقت حدث إعادة التمهيد.
يمكنك البحث عن ملفات تفريغ المراكز من خلال CLI أو واجهة المستخدم الرسومية
مراقبة نطاق UCS-Fi #
UCS-Fi /monitoring # sysdebug
يعرض UCS-Fi /monitoring/sysdebug # تفاصيل المراكز
- إذا تم تكوين FI لتصدير السجلات إلى خادم syslog، فالرجاء تجميع رسائل السجل من خادم syslog للجهاز الذي يوفر 7 أيام من المحفوظات قبل إعادة تمهيد الطابع الزمني.
- تتبع مكدس Kernel ( إذا كان إعادة التشغيل ناتجا عن ذعر kernel )
تحليل السجلات للأدلة الأولية
1) التحقق من سبب إعادة التشغيل والختم الزمني من نظام التشغيل Nexus (NX-OS) show version " إخراج الأمر
2) التحقق من إخراج الأمر show logging nvram " لرسائل السجل قبل طابع وقت إعادة التمهيد
3) التحقق من رسائل السجل المخزنة على خادم syslog للحصول على أدلة إضافية
4) إذا تم تشغيل إعادة التشغيل بسبب تعطل عملية مساحة المستخدم، فتحقق من تفريغ المركز الذي يطابق اسم العملية وطابع وقت إعادة التشغيل.
6) إذا كان ذعر kernel، فتحقق من مخرج تتبع مكدس kernel في ملف باسم sw_kernel_trace_log "
من UCSM 2.2.1b، تضمنت هذا مبرد UCSM عرض حزمة دعم فني.
بالنسبة لإصدار UCSM الأقدم من 2.2.1b، يرجى تجميع إخراج الأوامر التالية
connect nxos
show logging onboard kernel-trace | no-more
show logging onboard obfl-history | no-more
show logging onboard stack-trace | no-more
show logging onboard internal kernel | no-more
show logging onboard internal kernel-big | no-more
show logging onboard internal platform | no-more
show logging onboard internal reset-reason | no-more
7) يحتوي " topout.log" على إخراج الأمر " top" كل ثانيتين. قبل إعادة التمهيد، يحفظ UCSM المجموعة القديمة من السجلات على هيئة ملف /opt/sam_logs.tgzويمكن أن يوفر معلومات حول الذاكرة أو الاستخدام أو العمليات.
8) إذا لاحظت وجود رسائل مثل "خارج الذاكرة" (OOM) أدت إلى قتل عملية وقد يؤدي تعطل العملية إلى إعادة تشغيل FI وسيتم تحريره كسبب لإعادة التعيين.في مثل هذه السيناريوهات، من المحتمل أن تكون العملية ضحية حالة انخفاض الذاكرة وقد لا تكون السبب وراء عطل أو تسريب الذاكرة.
تجميع معلومات حول إعداد UCS
تساعد الإجابة على الأسئلة التالية في فهم إعداد النظام وحالته بشكل أفضل قبل إعادة التشغيل.
1) هل حدثت هذه المشكلة من قبل ؟
2) هل هناك أي نشاط معين حول وقت اعادة ؟
3) أية تغييرات تم إجراؤها مؤخرا على البرامج / الأجهزة / التكوين (FI) ؟
4) هل تتم مراقبة FI بواسطة أي تطبيقات خارجية ( عبر SNMP ، XML API ) ؟
5) إذا كانت الإجابة بنعم، فما مدى استبيان التطبيقات للبيانات الواردة في تقرير العمليات المالية ؟ ما هي المعلومات التي تم استقصاؤها على فترات منتظمة من خلال هذا التطبيق ؟ ( استعلامات SNMP السابقة )
6) هل هناك أي عاصفة مرورية باتجاه ميناء إدارة FI ؟
7) هل إعداد المقياس هذا ؟ (عدد الهياكل والخوادم النصلية والواجهات الظاهرية)
اقتراح لمراقبة FI على نحو استباقي
1) قم بتكوين UCSM لتصدير السجلات إلى خادم syslog
2) تجميع مخرجات "show operations" من الإدارة المحلية على فواصل زمنية منتظمة لمراقبة الإتجاه في وحدة المعالجة المركزية (CPU) والذاكرة
إستخدام العمليات. لا يتطلب هذا إذا كان FI يتم مراقبته بواسطة تطبيق خارجي.
معلومات ذات صلة
دليل تكوين Cisco UCS Manager
التعليقات