Nexus 7000 Supervisor 2/2E Compact Flash Failure Recovery

المقدمة

يصف هذا وثيقة ال Nexus 7000 مشرف 2/2E مضغوط إخفاق إصدار يوثق في برمجية خلل CSCus22805، كل يمكن إخفاق سيناريو، وخطوة إستعادة. 

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

إن يفشل أي من الخطوات في الحلول البديلة، اتصل ب cisco TAC ل إضافي يمكن إستعادة خيار. 

الخلفية

يتم تزويد كل مشرف N7K 2/2E بأجهزة فلاش eUSB في تهيئة RAID1، واحد رئيسي وواحد نسخة مطابقة. فهي توفر معا مستودعات غير متطايرة لصور التمهيد وتكوين بدء التشغيل وبيانات التطبيقات الثابتة.

وما يمكن أن يحدث هو خلال فترة من الأشهر أو السنوات في الخدمة، وقد يتم قطع اتصال أحد هذه الأجهزة بناقل USB، مما يتسبب في قيام برنامج RAID بإسقاط الجهاز من التكوين. لا يزال الجهاز يعمل بشكل طبيعي مع جهاز 1/2. ومع ذلك، عند سقوط الجهاز الثاني خارج الصفيف، تتم إعادة تحميل ذاكرة التمهيد المؤقتة (bootflash) على أنها للقراءة فقط، مما يعني أنه لا يمكنك حفظ التكوين أو الملفات في ذاكرة التمهيد المؤقتة (bootflash)، أو السماح لوحدة الاستعداد بالمزامنة مع الجهاز النشط في حالة إعادة تحميله.

لا يوجد تأثير تشغيلي على الأنظمة التي تعمل في حالة فشل ذاكرة الفلاش المزدوجة، ومع ذلك يلزم إعادة تحميل المشرف المتضرر للتعافي من هذه الحالة. علاوة على ذلك، لن تنعكس أي تغييرات في التكوين الجاري تشغيله في بدء التشغيل وستفقد في حالة انقطاع التيار.

الأعراض

وقد ظهرت هذه الأعراض:

• فشل تشخيص ذاكرة الفلاش المدمجة

 switch# show diagnostic result module 5

 Current bootup diagnostic level: complete
 Module 5: Supervisor module-2  (Standby)

         Test results: (. = Pass, F = Fail, I = Incomplete,
         U = Untested, A = Abort, E = Error disabled)

          1) ASICRegisterCheck-------------> .
          2) USB---------------------------> .
          3) NVRAM-------------------------> .
          4) RealTimeClock-----------------> .
          5) PrimaryBootROM----------------> .
          6) SecondaryBootROM--------------> .
          7) CompactFlash------------------> F  <=====
          8) ExternalCompactFlash----------> .
          9) PwrMgmtBus--------------------> U
         10) SpineControlBus---------------> .
         11) SystemMgmtBus-----------------> U
         12) StatusBus---------------------> U
         13) StandbyFabricLoopback---------> .
         14) ManagementPortLoopback--------> .
         15) EOBCPortLoopback--------------> .
         16) OBFL--------------------------> .

• تعذر تنفيذ 'بدء تشغيل النسخ'

dcd02.ptfrnyfs# copy running-config startup-config
 [########################################] 100%
 Configuration update aborted: request was aborted 

• تصبح منافذ eUSB للقراءة فقط أو لا تستجيب

switch %MODULE-4-MOD_WARNING: Module 2 (Serial number: JAF1645AHQT) reported warning
 due to The compact flash power test failed in device DEV_UNDEF (device error 0x0)

switch %DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 1 has failed test CompactFlash 20
 times on device Compact Flash due to error The compact flash power test failed

• حالات فشل ISSU، عادة عند محاولة تجاوز الفشل إلى المشرف في وضع الاستعداد

تشخيص

لتشخيص الحالة الحالية لبطاقات Compact Flash (الذاكرة المؤقتة) التي تحتاج إلى إستخدام هذه الأوامر الداخلية. لاحظ أن الأمر لن يتم تحليله، وأنه يجب أن يتم شطبه خارجا بشكل كامل:

المحول# إظهار RAID الداخلي للنظام | GREP -A 1 "معلومات حالة RAID الحالية"

switch# إظهار الملف الداخلي للنظام /proc/mdstat

في حالة وجود مشرفين في الهيكل، ستحتاج إلى فحص حالة المشرف في وضع الاستعداد أيضا لتحديد سيناريو الفشل الذي تواجهه. تحقق من هذا الإجراء من خلال تعليق الأمر مسبقا باستخدام الكلمة الأساسية "slot x" حيث يمثل "x" رقم الفتحة للمشرف في وضع الاستعداد. وهذا يتيح لك تشغيل الأمر عن بعد على وضع الاستعداد.

المحول# الفتحة 2 show داخلي RAID للنظام | GREP -A 1 "معلومات حالة RAID الحالية"

المحول# slot 2 show system داخلي /proc/mdstat

ستقوم هذه الأوامر بإعطاء الكثير من إحصائيات RAID وأحداثها، غير أنك تهتم فقط بالمعلومات الحالية RAID. 

في سطر "بيانات RAID من CMOS"، تريد أن تنظر إلى القيمة السداسية العشرية بعد 0xa5.  سيظهر هذا عدد الوميض التي قد تواجه مشكلة حاليا. 

على سبيل المثال:

 switch# show system internal raid | grep -A 1 "Current RAID status info"
 Current RAID status info:
 RAID data from CMOS = 0xa5 0xc3

من هذا الإخراج تريد أن تنظر إلى الرقم الموجود بجانب 0xa5 وهو 0xc3.  يمكنك بعد ذلك إستخدام هذه المفاتيح لتحديد ما إذا كان فلاش المدمج الأساسي أو الثانوي قد فشل، أو كليهما. يظهر الإخراج أعلاه 0xc3 الذي يخبرنا بأن كلا من الومضات المضغوطة الأساسية والثانوية قد فشلت.

في مخرجات "/proc/mdstat" تأكد أن كل الأقراص تظهر على أنها "U"، والتي تمثل "U"p:

switch# slot 2 show system internal file /proc/mdstat
Personalities : [raid1]
md6 : active raid1 sdc6[0] sdb6[1]
      77888 blocks [2/1] [_U]

md5 : active raid1 sdc5[0] sdb5[1]
      78400 blocks [2/1] [_U]

md4 : active raid1 sdc4[0] sdb4[1]
      39424 blocks [2/1] [_U]

md3 : active raid1 sdc3[0] sdb3[1]
      1802240 blocks [2/1] [_U]

في هذا السيناريو، ترى أن الفلاش المدمج الأساسي ليس up [_u]. سيظهر الإخراج السليم جميع الكتل على هيئة [u].

ملاحظة: يجب أن يظهر كلا المنفذين كأمرين صحيحين (0xf0 و [u]) لتشخيص المشرف على أنه صحي. لذلك إذا رأيت مخرج 0xf0 في بيانات CMOS لكن رأيت [_u] في /proc/mdstat، المربع غير صحي.

السيناريوهات

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

على سبيل المثال، إذا رأيت أن الرمز هو 0xe1 على المشرف النشط و0xd2 في وضع الاستعداد، فسيكون هذا 1 فشل" على Active و1 فشل" على وضع الاستعداد الذي هو حرف السيناريو "d".

مشرف واحد:

المشرفون المزدوجون:

إجراء الاسترداد لكل سيناريو

سيناريوهات فشل المشرف الواحد

السيناريو أ (فشل واحد على النشط)

سيناريو الاسترداد:

    فشل ٪1 على النشط

خطوات الحل:

1. تحميل أداة إسترداد ذاكرة الفلاش لإصلاح ذاكرة التمهيد المؤقتة (bootflash). يمكنك تنزيل أداة الاسترداد من CCO ضمن أدوات مساعدة للنظام الأساسي N7000 أو إستخدام الارتباط أدناه:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

يتم تضمينه في ملف tar gz المضغوط، الرجاء فك ضغطه للبحث عن أداة .gbin للاسترداد وقارئ .pdf. راجع الملف التمهيدي، وقم بتحميل أداة .gbin على bootflash الخاصة بالجهاز N7K. بينما تم تصميم هذا الاسترداد بحيث لا يؤثر ويمكن تنفيذه مباشرة، يوصي TAC بالأداء في نافذة الصيانة في حالة ظهور أي مشاكل غير متوقعة. بعد أن يكون الملف على bootflash، يمكنك تشغيل أداة الاسترداد باستخدام:

switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6    : active raid1 sdd6[2] sdc6[0] 
    77888 blocks [2/1] [U_]  <-- "U_" represents the broken state
        resync=DELAYED
        
md5    : active raid1 sdd5[2] sdc5[0] 
    78400 blocks [2/1] [U_]
        resync=DELAYED
        
md4    : active raid1 sdd4[2] sdc4[0] 
    39424 blocks [2/1] [U_]
        resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0] 
    1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>

switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0] 
    77888 blocks [2/2] [UU]  <-- "UU" represents the fixed state
    
md5 :active raid1 sdd5[1] sdc5[0] 
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0] 
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0] 
    1802240 blocks [2/2] [UU]
unused devices: <none>

السيناريو ب (فشل السيناريو 2 في الوضع النشط)

سيناريو الاسترداد:

    فشل ٪2 في وضع Active

خطوات الحل:

ملاحظة: عادة ما يظهر هذا في حالات فشل ذاكرة الفلاش المزدوجة، فقد لا يتمكن إعادة تحميل البرنامج من إستعادة RAID بالكامل وقد يتطلب تشغيل أداة الاسترداد أو عمليات إعادة التحميل التالية لاستعادة البيانات. وفي كل مرة تقريبا، يتم حلها باستخدام إعادة بيع فعلية للوحدة النمطية للمشرف. لذلك، إذا كان الوصول المادي إلى الجهاز ممكنا، بعد نسخ التكوين إحتياطيا خارجيا، يمكنك محاولة إجراء إسترداد سريع تكون له أعلى فرصة للنجاح عن طريق إعادة تعيين المشرف ماديا عندما يكون جاهزا لإعادة تحميل الجهاز. سيؤدي هذا إلى إزالة الطاقة بالكامل من المشرف كما يجب أن يسمح باسترداد كلا قرصي وحدة التحكم RAID. انتقل إلى الخطوة 3 إذا كان إسترداد إعادة البيع الفعلي جزئيا فقط، أو الخطوة 4 إذا لم يكن ناجحا بالكامل حيث أن النظام لم يتم تمهيده بالكامل.

سيناريوهات فشل المشرف المزدوج

السيناريو C (فشل 0 في الوضع النشط، فشل واحد في وضع الاستعداد)

سيناريو الفشل:

    فشل |0 في Active

    فشل ٪1 في وضع الاستعداد

خطوات الحل:

في سيناريو إعداد مشرف مزدوج، مع عدم وجود حالات فشل في الذاكرة المؤقتة على النشط وفشل واحد في وضع الاستعداد، يمكن إجراء إسترداد غير مؤثر.


1. بما أن النشط لا يحتوي على حالات فشل وأن الاستعداد به فشل واحد فقط، يمكن تحميل أداة إسترداد Flash على النشط وتنفيذه. بعد تشغيل الأداة، ستقوم تلقائيا بنسخ نفسها إلى وضع الاستعداد ومحاولة إعادة مزامنة الصفيف.  يمكن تنزيل أداة الاسترداد هنا:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

بمجرد تنزيل الأداة، قم بفك ضغطها، وتحميلها إلى ذاكرة التمهيد الخاصة بالصندوق، ستحتاج إلى تنفيذ الأمر التالي لبدء الاسترداد:

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

ستبدأ الأداة في تشغيل الأقراص غير المتصلة واكتشافها ثم تحاول إعادة ضبطها باستخدام صفيف RAID.

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                 
بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.

2. إذا كانت "أداة إسترداد Flash" غير ناجحة، نظرا لأن كلا القرصين في وضع النشط قيد التشغيل، فيجب أن يكون في وضع الاستعداد القدرة على المزامنة بنجاح مع وضع "إعادة التحميل" النشط.

لذلك، في نافذة مجدولة، قم بتنفيذ وحدة نمطية x خارج الخدمة" للمشرف في وضع الاستعداد، يوصى بالوصول إلى وحدة التحكم في وضع الاستعداد لمراقبة عملية التمهيد في حالة ظهور أي مشاكل غير متوقعة. بعد أن يكون المشرف معطلا، انتظر بضع ثوان ثم قم بتنفيذ "عدم وجود وحدة نمطية x" للاستعداد. انتظر حتى يتم تمهيد وضع الاستعداد بالكامل في حالة "ha-standby".

بعد نسخ الاحتياطي، تحقق من RAID باستخدام أداة التحكم slot x show system internal raid" و"slot x show system internal file /proc/mdstat".

إذا لم يتم إجراء نسخ إحتياطي كامل لكل من القرصين بعد إعادة تحميلهما، فقم بتشغيل أداة الاسترداد مرة أخرى.

3. إذا لم تكن أداة إعادة التحميل والاسترداد ناجحة، فمن المستحسن محاولة إعادة تعيين الوحدة النمطية الاحتياطية في النافذة بشكل فعلي لمحاولة مسح الحالة.  إذا لم تكن عملية إعادة البيع الفعلية ناجحة، فحاول تنفيذ "نظام init" من وضع تمهيد المحول عن طريق اتباع خطوات إسترداد كلمة المرور للدخول إلى هذا الوضع أثناء التمهيد.  إذا لم تنجح بعد، اتصل ب TAC لمحاولة الاسترداد اليدوي.

السيناريو D (فشل واحد في الوضع النشط وفشل 0 في وضع الاستعداد)

سيناريو الاسترداد:

    فشل ٪1 على النشط

    فشل |0 في وضع الاستعداد

خطوات الحل:

في سيناريو إعداد مشرف مزدوج، مع فشل 1 flash على النشط وعدم وجود حالات فشل على الاستعداد، يمكن إجراء إسترداد غير مؤثر باستخدام أداة إسترداد Flash (الذاكرة المؤقتة).


1. بما أن وضع الاستعداد لا يحتوي على حالات فشل وأن النشط به فشل واحد فقط، يمكن تحميل "أداة إسترداد Flash" على النشط وتنفيذه. بعد تشغيل الأداة، ستقوم تلقائيا بنسخ نفسها إلى وضع الاستعداد ومحاولة إعادة مزامنة الصفيف.  يمكن تنزيل أداة الاسترداد هنا:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

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

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

ستبدأ الأداة في تشغيل الأقراص غير المتصلة واكتشافها ثم تحاول إعادة ضبطها باستخدام صفيف RAID.

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                
بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.



2. إذا كانت أداة إسترداد ذاكرة Flash (الذاكرة المؤقتة) غير ناجحة، فإن الخطوة التالية ستكون تنفيذ تبديل النظام" إلى تجاوز فشل الوحدات النمطية للمشرف في إطار الصيانة.

لذلك، في نافذة مجدولة، قم بتنفيذ تبديل النظام"، يوصى بالحصول على وصول وحدة التحكم لمراقبة عملية التمهيد في حالة ظهور أي مشاكل غير متوقعة.  انتظر حتى يتم تمهيد وضع الاستعداد بالكامل في حالة "ha-standby".

بعد نسخ الاحتياطي، تحقق من RAID باستخدام أداة التحكم slot x show system internal raid" و"slot x show system internal file /proc/mdstat".

إذا لم يتم إجراء نسخ إحتياطي كامل لكل من القرصين بعد إعادة تحميلهما، فقم بتشغيل أداة الاسترداد مرة أخرى.


3. إذا لم تكن أداة إعادة التحميل والاسترداد ناجحة، فمن المستحسن محاولة إعادة تعيين الوحدة النمطية الاحتياطية في النافذة بشكل فعلي لمحاولة مسح الحالة.  إذا لم تكن عملية إعادة البيع الفعلية ناجحة، فحاول تنفيذ "نظام init" من وضع تمهيد المحول عن طريق اتباع خطوات إسترداد كلمة المرور للدخول إلى هذا الوضع أثناء التمهيد.  إذا لم تنجح بعد، اتصل ب TAC لمحاولة الاسترداد اليدوي.

السيناريو E (فشل واحد في الوضع النشط، فشل واحد في وضع الاستعداد)

سيناريو الاسترداد:

    فشل ٪1 على النشط

    فشل ٪1 في وضع الاستعداد

خطوات الحل:

في حالة حدوث عطل فلاش واحد في كل من الطراز النشط والحامل الاحتياطي، لا يزال من الممكن تحقيق حل بديل غير مؤثر.


1. بما أنه لا يوجد مشرف في حالة القراءة فقط، فإن الخطوة الأولى هي محاولة إستخدام أداة إسترداد Flash (الذاكرة المؤقتة).

يمكن تنزيل أداة الاسترداد هنا:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

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

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

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

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                

                                                                                       
 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                  
بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.


إذا إستعاد كلا المشرفين حالة [u]، فيكون الاسترداد مكتملا.  إذا كان الاسترداد جزئيا أو لم ينجح، فانتقل إلى الخطوة 2.


2. في حالة فشل أداة الاسترداد، حدد الحالة الحالية ل RAID على الوحدات النمطية. في حالة إستمرار وجود فشل فلاش واحد على كليهما، حاول إجراء "تبديل النظام" الذي سيقوم بإعادة تحميل النشاط الحالي وفرض الاستعداد على الدور النشط.

بعد إعادة تحميل النشاط السابق في "ha-standby"، تحقق من حالة RAID الخاصة به كما ينبغي إستردادها أثناء إعادة التحميل.
في حالة إسترداد المشرف بنجاح بعد التحويل، يمكنك محاولة تشغيل أداة إسترداد ذاكرة الفلاش مرة أخرى لمحاولة إصلاح فشل القرص الأحادي على المشرف النشط الحالي، أو "تبديل النظام" آخر لإعادة تحميل النشاط الحالي وفرض الاستعداد النشط والحالي السابق الذي تم إصلاحه مرة أخرى على الدور النشط. تحقق من أن المشرف الذي تم إعادة تحميله قد تم إصلاح كلا القرصين مرة أخرى، ثم أعد تشغيل أداة الاسترداد إذا لزم الأمر.


3. إذا كان المحول لا يقوم خلال هذه العملية بإصلاح RAID، فقم بتنفيذ وحدة x خارج الخدمة" للاحتياطي ثم "لا توجد وحدة تزويد بالطاقة بسرعة x" لإزالة الطاقة وإعادة تطبيقها بشكل كامل على الوحدة.

إذا لم يكن خروج الجهاز عن الخدمة ناجحا، فحاول إجراء إعادة توزيع فعلي للإستعداد.

في حالة قيام أحد المشرفين بعد تشغيل أداة الاسترداد باسترداد RAID الخاص به بينما لا يزال المشرف الآخر يعاني من فشل، يتم إجبار المشرف على التعطل الوحيد عن العمل على وضع الاستعداد مع "تبديل النظام" إذا لزم الأمر. إذا كان المشرف مع فشل واحد هو
الاستعداد بالفعل، قم بتنفيذ الأمر "وحدة x خارج الخدمة" للاستعداد و"لا يوجد وحدة طاقة x" لإزالة الطاقة وإعادة تطبيقها بشكل كامل على الوحدة النمطية. إذا كانت لا تزال غير بصدد التعافي، فحاول إعادة الضبط الفعلي للوحدة النمطية. في حالة عدم إصلاح عملية إعادة الشراء،
اقتحم داخل المفتاح جزمة رسالة حث يستعمل الكلمة إستعادة إجراء وفعل "init system" أن يعيد تشكيل ال bootflash. إذا لم ينجح ذلك بعد، فتحقق من إسترداد دليل محاولة TAC.

ملاحظة: إذا علق الاستعداد في أي نقطة في حالة "تشغيل" وليس في حالة "إستعداد"، إذا تعذر الحصول على وضع الاستعداد الكامل مع الخطوات أعلاه، فسيلزم إعادة تحميل الهيكل.

سيناريو (2 يفشل في النشط، 0 يفشل في وضع الاستعداد)

سيناريو الاسترداد:

    فشل ٪2 في وضع Active

    فشل |0 في وضع الاستعداد

خطوات الحل:

مع وجود فشلين على المشرف النشط و 0 على المشرف في وضع الاستعداد، يمكن إجراء إسترداد غير مؤثر، وذلك اعتمادا على مدى إضافة التكوين الجاري تشغيله نظرا لعدم تمكن وضع الاستعداد من مزامنة running-config مع التكوين النشط.

سيكون إجراء الاسترداد هو نسخ التكوين الجاري تشغيله الحالي من المشرف النشط وتجاوز الفشل إلى المشرف الاحتياطي السليم ونسخ التكوين الجاري تشغيله المفقود إلى التكوين النشط الجديد ثم إحضار التكوين النشط السابق عبر الإنترنت يدويا ثم تشغيل أداة الاسترداد.

2.  بمجرد نسخ تكوين التشغيل من المشرف النشط، فمن الأفضل مقارنته بتكوين بدء التشغيل لمعرفة ما تم تغييره منذ آخر عملية حفظ.  ويمكن ملاحظة ذلك باستخدام show startup-configuration".  وطبعا، ستعتمد الاختلافات كليا على البيئة، ولكن من الجيد ان نكون مدركين لما قد يكون مفقودا عندما يأتي الاستعداد على الإنترنت كشخص نشط.  كما أنها فكرة جيدة أن يتم نسخ الاختلافات بالفعل في المفكرة بحيث يمكن إضافتها بسرعة إلى المشرف النشط الجديد بعد التحويل.

3.  بعد تقييم الاختلافات، ستحتاج إلى تنفيذ تبديل مشرف.  TAC يوصي أن يتم هذا أثناء صيانة نافذة، بما أن مشاكل غير منظورة قد تحدث.  سيكون الأمر الذي يؤدي إلى نقل الفشل إلى وضع الاستعداد هو تبديل النظام".

4.  يجب أن يحدث التحويل بسرعة كبيرة وسيبدأ الاستعداد الجديد في إعادة التشغيل.  خلال هذا الوقت، ستحتاج إلى إضافة أي تكوين مفقود مرة أخرى إلى النشط الجديد.  يمكن القيام بذلك من خلال نسخ التكوين من خادم TFTP (أو حيثما تم حفظه سابقا) أو من خلال إضافة التكوين ببساطة يدويا في واجهة سطر الأوامر.  وفي معظم الحالات تكون التكوينات المفقودة قصيرة جدا ويكون خيار واجهة سطر الأوامر (CLI) هو الأكثر قابلية للتنفيذ.

5.  بعد فترة من الوقت قد يعود المشرف الاحتياطي الجديد على الإنترنت في حالة "وضع الاستعداد"، ولكن ما يحدث عادة هو أنه يعلق في حالة "تشغيل الجهاز".  يمكن عرض الحالة باستخدام الأمر show module" والإشارة إلى العمود "الحالة" بجوار الوحدة النمطية. 

إذا أصبحت وضعية الاستعداد الجديدة في حالة "تشغيل الجهاز"، فستحتاج إلى إرجاعها مرة أخرى عبر الإنترنت يدويا.  يمكن القيام بذلك من خلال إصدار الأوامر التالية، حيث تكون "x" هي الوحدة النمطية الاحتياطية المعلقة في حالة "تشغيل - تشغيل":

    (config)# الوحدة النمطية خارج الخدمة x

    (config)# no power module x

6.  بمجرد عودة وضع الاستعداد عبر الإنترنت في حالة "وضع الاستعداد"، ستحتاج بعد ذلك إلى تشغيل أداة الاسترداد لضمان اكتمال عملية الاسترداد.  يمكن تنزيل الأداة على الرابط التالي:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

بمجرد تنزيل الأداة، قم بفك ضغطها، وتحميلها إلى ذاكرة التمهيد الخاصة بالصندوق، ستحتاج إلى تنفيذ الأمر التالي لبدء الاسترداد:

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

ستبدأ الأداة في تشغيل الأقراص غير المتصلة واكتشافها ثم تحاول إعادة ضبطها باستخدام صفيف RAID.

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

switch# show system internal file /proc/mdstat

Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
    77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
    
md5 :active raid1 sdd5[1] sdc5[0]
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0]
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0]
    1802240 blocks [2/2] [UU]
unused devices: <none>

                                                                  
بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.

السيناريو G (فشل 0 في الوضع النشط وفشل 2 في وضع الاستعداد)

0 يفشل في Active، 2 في Standby

سيناريو الاسترداد:

    فشل |0 في Active

    فشل ٪2 في وضع الاستعداد

خطوات الحل:

مع وجود 0 حالات فشل على المشرف النشط و 2 على المشرف الاحتياطي، يمكن إجراء إسترداد غير مؤثر.

سيكون إجراء الاسترداد هو إجراء إعادة تحميل وضع الاستعداد.

1. عادة ما يرى المشرفون الذين يعانون من فشل ذاكرة الفلاش المزدوج أن أحد البرامج "إعادة تحميل الوحدة النمطية X" قد يقوم بإصلاح RAID جزئيا فقط أو قد يعلق برنامج إعادة التشغيل عند إعادة التمهيد.

لذلك، يوصى إما بإعادة الضبط المادي للمشرف مع فشل ذاكرة الفلاش المزدوجة لإزالة الطاقة وإعادة تطبيقها بشكل كامل على الوحدة النمطية، أو يمكنك تنفيذ ما يلي (x للفتحة الاحتياطية #):

    # الوحدة النمطية خارج الخدمة x
    # لا توجد وحدة طاقة x

إذا رأيت أن وضع الاستعداد يظل عالقا في حالة التشغيل ويحافظ في نهاية المطاف على دوران الطاقة بعد الخطوات أعلاه، فمن المحتمل أن يحدث هذا بسبب إعادة التحميل النشطة للإستعداد لعدم ظهوره في الوقت المناسب.

قد يرجع ذلك إلى محاولة تمهيد وضع الاستعداد لإعادة تهيئة ذاكرة التمهيد المؤقتة/RAID الخاصة بها، والتي قد تستغرق ما يصل إلى 10 دقائق، ولكن يتم إعادة تعيينها باستمرار بواسطة النشط قبل أن تتمكن من تحقيقها.

لحل هذه المشكلة، قم بتكوين ما يلي باستخدام 'x' للفتحة الاحتياطية # التي تم إيقاف تشغيلها:

    (config)# تمهيد يدوي للاستعداد للنظام
    (config)# reload وحدة نمطية x force-dnld
    
    سيؤدي ما سبق إلى جعله بحيث لا يقوم النشط بإعادة تعيين وضع الاستعداد تلقائيا، ثم إعادة تحميل وضع الاستعداد وإرغامه على مزامنة صورته من وضع الاستعداد النشط.
    
    انتظر من 10 إلى 15 دقيقة لمعرفة ما إذا كان في وسع الاستعداد الوصول أخيرا إلى حالة الاستعداد. بعد أن تكون في حالة الاستعداد، قم بإعادة تمكين عمليات إعادة التشغيل التلقائية للإستعداد مع:
    
    (config)# نظام لا يوجد تمهيد يدوي في وضع الاستعداد
    

6.  بمجرد عودة وضع الاستعداد عبر الإنترنت في حالة "وضع الاستعداد"، ستحتاج بعد ذلك إلى تشغيل أداة الاسترداد لضمان اكتمال عملية الاسترداد.  يمكن تنزيل الأداة على الرابط التالي:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest


بمجرد تنزيل الأداة، قم بفك ضغطها، وتحميلها إلى ذاكرة التمهيد الخاصة بالصندوق، ستحتاج إلى تنفيذ الأمر التالي لبدء الاسترداد:

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

ستبدأ الأداة في تشغيل الأقراص غير المتصلة واكتشافها ثم تحاول إعادة ضبطها باستخدام صفيف RAID.

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                                                                                                       
                                        

 switch# show system internal file /proc/mdstat
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

  
 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.

السيناريو H (فشل السيناريو H في الوضع النشط وفشل السيناريو 1 في وضع الاستعداد)

فشل ٪2 على Active، وفشل واحد على Standby

سيناريو الاسترداد:

    فشل ٪2 في وضع Active

    فشل ٪1 في وضع الاستعداد

خطوات الحل:

مع وجود فشلين على المشرف النشط و 1 على المشرف في وضع الاستعداد، يمكن إجراء إسترداد غير مؤثر، وذلك اعتمادا على مدى إضافة التكوين الجاري تشغيله نظرا لعدم تمكن وضع الاستعداد من مزامنة running-config مع التكوين النشط.


سيكون إجراء الاسترداد هو إجراء نسخ إحتياطي للتكوين الجاري تشغيله الحالي من المشرف النشط وتجاوز الفشل إلى المشرف الاحتياطي السليم ونسخ التكوين الجاري تشغيله المفقود إلى التكوين النشط الجديد ثم جلب التكوين النشط السابق عبر الإنترنت يدويا ثم تشغيل أداة الاسترداد.


1.  قم بإجراء نسخ إحتياطي للتكوين الجاري تشغيله خارجيا باستخدام "copy running-config tftp: vdc-all". يرجى ملاحظة أنه في حالة حدوث فشل ذاكرة Flash مزدوجة، لا تتوفر تغييرات التكوين منذ إعادة تحميل النظام إلى وضع القراءة فقط على تكوين بدء التشغيل. يمكنك مراجعة "إظهار أداة التحكم RAID الداخلية للنظام" للوحدة النمطية المتأثرة لتحديد وقت فشل القرص الثاني وهو المكان الذي يتم فيه تشغيل النظام للقراءة فقط. ومن هناك يمكنك مراجعة "show accounting log" لكل VDC لتحديد التغييرات التي تم إجراؤها منذ فشل ذاكرة الفلاش المزدوجة حتى تعرف ما الذي تريد إضافته إذا استمر تكوين بدء التشغيل على إعادة التحميل.

يرجى ملاحظة أنه من الممكن مسح تكوين بدء التشغيل على إعادة تحميل مشرف به فشل ذاكرة مؤقتة مزدوجة، ولهذا السبب يجب نسخ التكوين إحتياطيا خارجيا.


2.  بمجرد نسخ تكوين التشغيل من المشرف النشط، فمن الأفضل مقارنته بتكوين بدء التشغيل لمعرفة ما تم تغييره منذ آخر عملية حفظ.  ويمكن ملاحظة ذلك باستخدام "show startup-configuration".  وطبعا، ستعتمد الاختلافات كليا على البيئة، ولكن من الجيد ان نكون مدركين لما قد يكون مفقودا عندما يأتي الاستعداد على الإنترنت كشخص نشط.  كما أنها فكرة جيدة أن يتم نسخ الاختلافات بالفعل في المفكرة بحيث يمكن إضافتها بسرعة إلى المشرف النشط الجديد بعد التحويل.


3.  بعد تقييم الاختلافات، ستحتاج إلى تنفيذ تبديل مشرف.  TAC يوصي أن يتم هذا أثناء صيانة نافذة، بما أن مشاكل غير منظورة قد تحدث.  سيكون الأمر الذي يؤدي إلى تجاوز الفشل إلى وضع الاستعداد هو "تبديل النظام".


4.  يجب أن يحدث التحويل بسرعة كبيرة وسيبدأ الاستعداد الجديد في إعادة التشغيل.  خلال هذا الوقت، ستحتاج إلى إضافة أي تكوين مفقود مرة أخرى إلى النشط الجديد.  يمكن القيام بذلك من خلال نسخ التكوين من خادم TFTP (أو حيثما تم حفظه سابقا) أو من خلال إضافة التكوين يدويا ببساطة في واجهة سطر الأوامر، ولا يتم النسخ مباشرة من TFTP إلى running-configuration، ثم يتم النسخ إلى bootflash أولا، ثم إلى تشغيل التكوين.  وفي معظم الحالات تكون التكوينات المفقودة قصيرة جدا ويكون خيار واجهة سطر الأوامر (CLI) هو الأكثر قابلية للتنفيذ.


5.  بعد فترة من الوقت قد يعود المشرف الاحتياطي الجديد على الإنترنت في حالة "وضع الاستعداد"، ولكن ما يحدث عادة هو أنه يعلق في حالة "تشغيل الجهاز".  يمكن عرض الحالة باستخدام الأمر "show module" وبالإشارة إلى العمود "الحالة" الموجود بجوار الوحدة النمطية.


إذا أصبحت وضعية الاستعداد الجديدة في حالة "تشغيل الجهاز"، فستحتاج إلى إرجاعها مرة أخرى عبر الإنترنت يدويا.  يمكن القيام بذلك من خلال إصدار الأوامر التالية، حيث تكون "x" هي الوحدة النمطية الاحتياطية المعلقة في حالة "تشغيل - تشغيل":

    (config)# خارج الخدمة وحدة نمطية
    (config)# no power module x        
    
    
إذا رأيت أن وضع الاستعداد يظل عالقا في حالة التشغيل ويحافظ في نهاية المطاف على دوران الطاقة بعد الخطوات أعلاه، فمن المحتمل أن يحدث هذا بسبب إعادة التحميل النشطة للإستعداد لعدم ظهوره في الوقت المناسب.
قد يرجع ذلك إلى محاولة تمهيد وضع الاستعداد لإعادة تهيئة ذاكرة التمهيد المؤقتة/RAID الخاصة بها، والتي قد تستغرق ما يصل إلى 10 دقائق، ولكن يتم إعادة تعيينها باستمرار بواسطة النشط قبل أن تتمكن من تحقيقها.
لحل هذه المشكلة، قم بتكوين ما يلي باستخدام 'x' للفتحة الاحتياطية # التي تم إيقاف تشغيلها:

    (config)# تمهيد يدوي للاستعداد للنظام
    (config)# reload وحدة نمطية x force-dnld
    
    سيؤدي ما سبق إلى جعله بحيث لا يقوم النشط بإعادة تعيين وضع الاستعداد تلقائيا، ثم إعادة تحميل وضع الاستعداد وإرغامه على مزامنة صورته من وضع الاستعداد النشط.
    
    انتظر من 10 إلى 15 دقيقة لمعرفة ما إذا كان في وسع الاستعداد الوصول أخيرا إلى حالة الاستعداد. بعد أن تكون في حالة الاستعداد، قم بإعادة تمكين عمليات إعادة التشغيل التلقائية للإستعداد مع:
    
    (config)# نظام لا يوجد تمهيد يدوي إحتياطي
   
6.  بمجرد عودة وضع الاستعداد إلى حالة "HA-Standby"، ستحتاج بعد ذلك إلى تشغيل أداة الاسترداد لضمان اكتمال عملية الاسترداد وإصلاح فشل القرص الأحادي في النشط.  يمكن تنزيل الأداة على الرابط التالي:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest


بمجرد تنزيل الأداة، قم بفك ضغطها، وتحميلها إلى ذاكرة التمهيد الخاصة بالصندوق، ستحتاج إلى تنفيذ الأمر التالي لبدء الاسترداد:

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

ستبدأ الأداة في تشغيل الأقراص غير المتصلة واكتشافها ثم تحاول إعادة ضبطها باستخدام صفيف RAID.

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                                                                                                       

                                       
 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>
  

                                                                 
بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.

إذا لم تسترد أداة الاسترداد النشاط الحالي الذي يحتوي على فشل واحد، فحاول "تبديل النظام" آخر لضمان أن وضع الاستعداد الحالي في حالة "وضع الاستعداد".  إن لم ينجح بعد، يرجى الاتصال ب Cisco TAC

السيناريو الأول (فشل واحد في الوضع النشط وفشل إثنان في وضع الاستعداد)

سيناريو الاسترداد:

    فشل ٪1 على النشط

    فشل ٪2 في وضع الاستعداد

خطوات الحل:

في سيناريو مشرف مزدوج مع 1 إخفاق على النشط و 2 إخفاق على المشرف في وضع الاستعداد، يمكن أن يكون إستعادة غير مؤثر، غير أن في كثير من الحالات قد يكون من الضروري إعادة التحميل.

ستتم العملية أولا لإجراء نسخ إحتياطي لجميع التكوينات قيد التشغيل، ثم محاولة إسترداد الفلاش المدمج المعطل على أداة الاسترداد المستخدمة النشطة، ومن ثم، إذا نجحت، ستقوم بإعادة تحميل وضع الاستعداد يدويا وتشغيل أداة الاسترداد مرة أخرى.  إذا كانت محاولة الاسترداد الأولية غير قادرة على إستعادة ذاكرة Flash (الذاكرة المؤقتة) الفاشلة على النشط، فيجب إشراك TAC لمحاولة إسترداد يدوي باستخدام الوظيفة الإضافية ل debug.

1.  قم بإجراء نسخ إحتياطي لجميع التكوين الجاري تشغيله خارجيا باستخدام copy running-config tftp: vdc-all".  يمكنك أيضا نسخ running-config إلى واجهة USB محلية في حال عدم إعداد خادم TFTP في البيئة.

2.  بمجرد إجراء نسخ إحتياطي للتكوين الجاري تشغيله حاليا، ستحتاج بعد ذلك إلى تشغيل أداة الاسترداد لمحاولة إسترداد ذاكرة الفلاش المعطلة على الجهاز النشط.  يمكن تنزيل الأداة على الرابط التالي:

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

بمجرد تنزيل الأداة، قم بفك ضغطها، وتحميلها إلى ذاكرة التمهيد الخاصة بالصندوق، ستحتاج إلى تنفيذ الأمر التالي لبدء الاسترداد:

# تحميل bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

ستبدأ الأداة في تشغيل الأقراص غير المتصلة واكتشافها ثم تحاول إعادة ضبطها باستخدام صفيف RAID.

يمكنك التحقق من حالة الاسترداد باستخدام:

# إظهار الملف الداخلي للنظام /proc/mdstat

تحقق من إستمرار عملية الاسترداد، قد يستغرق إصلاح كافة الأقراص بالكامل إلى حالة [u] عدة دقائق. فيما يلي مثال على عملية إستعادة قيد التشغيل:                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

بعد الإنتهاء من مرحلة الاسترداد، يجب أن تبدو كما يلي:

switch# show system internal file /proc/mdstat

Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
    77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
    
md5 :active raid1 sdd5[1] sdc5[0]
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0]
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0]
    1802240 blocks [2/2] [UU]
unused devices: <none>

                                                                  
بعد أن تكون جميع الأقراص في [u]، يتم نسخ صفيف RAID إحتياطيا بشكل كامل مع مزامنة كلا قرصين.

3.  إذا لم تتمكن، بعد تشغيل أداة الاسترداد في الخطوة 2، من إسترداد ذاكرة Compact Flash الفاشلة على المشرف النشط، فيجب عليك الاتصال ب TAC لمحاولة إجراء إسترداد يدوي باستخدام ملحق تصحيح الأخطاء من Linux.

4.  بعد التحقق من أن كلا الومضات تظهر على أنها "[u]" في النشط، يمكنك المتابعة بإعادة تشغيل المشرف في وضع الاستعداد يدويا.  يمكن القيام بذلك من خلال إصدار الأوامر التالية، حيث تكون "x" هي الوحدة النمطية الاحتياطية المعلقة في حالة "تشغيل - تشغيل":

    (config)# الوحدة النمطية خارج الخدمة x

    (config)# no power module x

يجب أن يؤدي ذلك إلى إعادة المشرف الاحتياطي إلى حالة "ha-standby" (يتم التحقق من ذلك من خلال عرض عمود الحالة في الإخراج show module").  إذا كان هذا الإجراء ناجحا فقم بالمتابعة إلى الخطوة 6، وإذا لم يكن كذلك، فجرب الإجراء الموضح في الخطوة 5.

5.  إذا رأيت أن وضع الاستعداد يظل عالقا في حالة التشغيل ويحافظ في نهاية المطاف على دوران الطاقة بعد الخطوات أعلاه، فمن المحتمل أن يحدث هذا بسبب إعادة التحميل النشطة للإستعداد لعدم ظهوره في الوقت المناسب.  قد يرجع ذلك إلى محاولة تمهيد وضع الاستعداد لإعادة تهيئة ذاكرة التمهيد المؤقتة/RAID الخاصة بها، والتي قد تستغرق ما يصل إلى 10 دقائق، ولكن يتم إعادة تعيينها باستمرار بواسطة النشط قبل أن تتمكن من تحقيقها.  لحل هذه المشكلة، قم بتكوين ما يلي باستخدام 'x' للفتحة الاحتياطية # التي تم إيقاف تشغيلها:

(config)# تمهيد يدوي للاستعداد للنظام
(config)# reload وحدة نمطية x force-dnld

سيؤدي ما سبق إلى جعله بحيث لا يقوم النشط بإعادة تعيين وضع الاستعداد تلقائيا، ثم إعادة تحميل وضع الاستعداد وإرغامه على مزامنة صورته من وضع الاستعداد النشط.

انتظر من 10 إلى 15 دقيقة لمعرفة ما إذا كان في وسع الاستعداد الوصول أخيرا إلى حالة الاستعداد. بعد أن تكون في حالة الاستعداد، قم بإعادة تمكين عمليات إعادة التشغيل التلقائية للإستعداد مع:

(config)# نظام لا يوجد تمهيد يدوي في وضع الاستعداد

6.  بمجرد عودة وضع الاستعداد عبر الإنترنت في حالة "وضع الاستعداد"، ستحتاج بعد ذلك إلى تشغيل أداة الاسترداد لضمان اكتمال عملية الاسترداد.  يمكنك تشغيل نفس الأداة الموجودة لديك على الجهاز النشط لهذه الخطوة، ولا حاجة إلى تنزيل إضافي حيث تعمل أداة الاسترداد على الجهاز النشط والاستعداد.

سيناريو j (فشل 2 في حالة الطوارئ، فشل 2 في حالة الاستعداد)

سيناريو الاسترداد:

    فشل ٪2 في وضع Active

    فشل ٪2 في وضع الاستعداد

خطوات الحل:

ملاحظة: عادة ما يظهر هذا في حالات فشل ذاكرة الفلاش المزدوجة، فقد لا يتمكن البرنامج "reload" من إستعادة RAID بالكامل وقد يتطلب تشغيل أداة الاسترداد أو عمليات إعادة التحميل التالية لاستعادة البيانات. وفي كل مرة تقريبا، يتم حلها باستخدام إعادة بيع فعلية للوحدة النمطية للمشرف. لذلك، إذا كان الوصول المادي إلى الجهاز ممكنا، بعد نسخ التكوين إحتياطيا خارجيا، يمكنك محاولة إجراء إسترداد سريع تكون له أعلى فرصة للنجاح عن طريق إعادة تعيين المشرف ماديا عندما يكون جاهزا لإعادة تحميل الجهاز. سيؤدي هذا إلى إزالة الطاقة بالكامل من المشرف كما يجب أن يسمح باسترداد كلا قرصي وحدة التحكم RAID. انتقل إلى الخطوة 3 إذا كان إسترداد إعادة البيع الفعلي جزئيا فقط، أو الخطوة 4 إذا لم يكن ناجحا بالكامل حيث أن النظام لم يتم تمهيده بالكامل.

ملخص

الأسئلة المتداولة

هل من حل دائم لهذه المسألة؟

راجع قسم "الحلول طويلة الأجل" أدناه.

لماذا لا يمكن إستعادة تجاوز فشل مزدوج في وضع الاستعداد والنشط من خلال إعادة تحميل المشرف في وضع الاستعداد وتجاوز الفشل؟

السبب في أن هذا غير ممكن هو أنه للسماح للمشرف في وضع الاستعداد بأن يأتي في حالة "ها-وضع الاستعداد"، يجب على المشرف النشط كتابة عدة أشياء إلى ذاكرة Flash المضغوطة (معلومات SNMP، وما إلى ذلك)، والتي لا يمكنه القيام بها إذا كان لديه فشل فلاش مزدوج نفسه.

ماذا يحدث إذا كانت أداة إسترداد Flash (الذاكرة المؤقتة) غير قادرة على إعادة تحميل الفلاش المدمج؟

اتصل ب cisco TAC للخيارات في هذا السيناريو.

هل يؤثر هذا الخطأ أيضا على Nexus 7700 Sup2E؟

هناك عيب منفصل ل N7700 Sup2E - CSCuv64056 .  لن تعمل أداة الاسترداد مع الطراز N7700.

هل تعمل أداة الاسترداد مع صور NPE؟

لا تعمل أداة الاسترداد لصور NPE.

هل ستقوم ISSU بإصدار رمز تم حله بحل هذه المشكلة؟

لا. ستستخدم ISSU محول مشرف، قد لا يعمل بشكل صحيح بسبب فشل الفلاش المدمج.

قمنا بإعادة ضبط اللوحة المتأثرة. تطبع حالة RAID 0xF0، ولكن إختبارات الذهب لا تزال فاشلة؟

يتم إعادة تعيين وحدات بت حالة RAID بعد إعادة ضبط اللوحة بعد تطبيق الاسترداد التلقائي.
ومع ذلك، لا يمكن إسترداد جميع حالات الفشل تلقائيا.
إذا لم تتم طباعة وحدات بت حالة RAID على أنها [2/2] [u]، فإن الاسترداد يكون غير مكتمل.
اتبع خطوات الاسترداد المدرجة

هل سيكون لفشل الفلاش أي تأثير على العملية؟

لا، ولكن قد لا يتم تحميل النظام إحتياطيا عند حدوث عطل في الطاقة. سيتم فقدان تكوين بدء التشغيل أيضا.

ما هو المطلوب لنظام التشغيل الصحي من منظور العملاء فيما يتعلق بالرصد والاسترداد؟

تحقق من حالة إختبار GOLD COMPACT بحثا عن أي حالات فشل ومحاولة إسترداد بمجرد فشل جزء الذاكرة المؤقتة الأول.

هل يمكنني إصلاح فشل فشل ذاكرة فلاش USB عن طريق تنفيذ ISSU من الرمز المتأثر إلى الإصدار الثابت؟

لن يقوم ISSU بإصلاح خطأ eUSB. الخيار الأفضل هو تشغيل أداة الاسترداد لفشل EUSB واحد على الرزمة أو إعادة تحميل الرزمة في حالة فشل SUP مزدوج.
بمجرد تصحيح المشكلة، قم بإجراء الترقية. يساعد إصلاح CSCus22805 على تصحيح فشل EUSB واحد فقط ويفعل ذلك من خلال مسح النظام في فاصل زمني منتظم ويحاول إعادة تنبيه eUSB الذي لا يمكن الوصول إليه أو للقراءة فقط باستخدام البرنامج النصي.
من النادر أن نرى حدوث عطل فجائي في المشرف بشكل متزامن، وبالتالي سيكون هذا الحل فعالا.

كم من الوقت يستغرق الأمر لإعادة ظهور المشكلة إذا قمت بإصلاح إخفاقات Flash باستخدام المكون الإضافي أو إعادة التحميل؟

وعموما ينظر إليه من خلال وقت تشغيل أطول. ولا يتم تحديد هذا العدد بدقة ويمكن أن يتراوح بين عام أو أكثر. الخلاصة هي أنه كلما زاد الضغط على الفتحة EUSB من حيث الكتابة المقروءة، زادت أحتمالية تشغيل النظام في هذا السيناريو.

يظهر إظهار نظام RAID الداخلي حالة الفلاش مرتين في أقسام مختلفة. وبعدين هالاقسام ما بتلاءم
يظهر القسم الأول الحالة الحالية ويظهر القسم الثاني حالة بدء التشغيل.
الحالة الحالية هي ما يهم ويجب أن تظهر دائما ك u.

حلول طويلة الأجل

يوجد حل بديل لهذا العيب في 6.2(14)، ولكن تمت إضافة إصلاح البرنامج الثابت إلى 6.2(16) و 7.2(x) والإصدارات اللاحقة. 

من المستحسن الترقية إلى إصدار باستخدام إصلاح البرنامج الثابت لحل هذه المشكلة بالكامل.

إذا لم تكن قادرا على الترقية إلى إصدار ثابت من NXOS، فهناك حلان محتملان. 

الحل 1 هو تشغيل أداة إسترداد الفلاش بشكل استباقي كل أسبوع باستخدام أداة الجدولة الزمنية.  تكوين المجدول التالي باستخدام أداة إسترداد الفلاش في ذاكرة التمهيد المؤقتة (bootflash):

مجدول الميزات
اسم مهمة المجدول Flash_Job

  copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
  تحميل bootflash:/flash_recovery_tool_copy

  مخرج
اسم جدول المجدول Flash_Recovery
  اسم المهمة Flash_Job
  تايم ويكلي 7

ملاحظات: 

• يجب أن يكون لاسترداد ذاكرة Flash نفس الاسم وأن يكون في ذاكرة التمهيد المؤقتة (bootflash).
• ويمثل الرقم 7 في التشكيل "تايم ويكلي 7" يوم من الأسبوع، السبت في هذه الحالة.
• يكون الحد الأقصى للتردد الذي توصي به Cisco بتشغيل أداة إسترداد Flash (الذاكرة المؤقتة) مرة في الأسبوع.

 يتم توثيق الحل 2 على إرتباط الملاحظة التقنية التالي