المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

ملفات السجلات المطلوبة

تحليل السجلات للأدلة الأولية

تجميع معلومات حول إعداد UCS

اقتراح لمراقبة FI على نحو استباقي

معلومات ذات صلة

المقدمة

يقدم المستند خطوات للتحقيق في عطل 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.

- حزمة سجل دعم UCSM التقني

- تحقق مما إذا كان ملف تفريغ الأساسي قد تم إنشاؤه في وقت حدث إعادة التمهيد.

يمكنك البحث عن ملفات تفريغ المراكز من خلال 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