مهام ASR5x00 Session Manager - وصف الوظيفة، العطل، عمليات الاسترداد، وسجلات العطل

المقدمة

يصف هذا المستند ويشرح ميزات موثوقية البرامج وتوفر الخدمة وتجاوز الأعطال لسلسلة موجه خدمات التجميع (ASR) 5x00 من Cisco. يعرض تعريف عطل البرنامج على ASR5x00 وتأثير تعطل البرنامج. يمضي المقال ليؤكد أنه حتى في حالة الأعطال غير المتوقعة للبرامج، فإن الطريقة التي يمكن بها ل ASR5x00 تحقيق هدف التوفر "من فئة الناقل" نظرا لمرونة البرامج المتأصلة وتوافرها. لا يجب على مشترك الأجهزة المحمولة التفكير في توفر الخدمة. يتمثل هدف Cisco في عدم ضياع أي جلسة بسبب أي أعطال أجهزة أو برامج واحدة، والتي تتضمن فقد نظام كامل، بمعنى آخر - موثوقية درجة الصوت. يتم إستهداف ميزات موثوقية البرامج الموجودة على ASR5x00 لتكون قادرة على تحقيق أهداف توفر الخدمة "من فئة شركة النقل" حتى في الحالات التي قد تحدث فيها حالات فشل غير متوقعة في شبكة شركة التشغيل.

بنية البرامج: مصممة لتوفير المرونة

تحتوي ASR5x00 على مجموعة من مهام البرامج الموزعة عبر بطاقة خدمات الحزمة (PSC) أو بطاقة معالجة البيانات (DPC) وبطاقة إدارة النظام (SMC) أو بطاقات الإدارة والإدخال/الإخراج (MIO) المصممة لأداء مجموعة متنوعة من الوظائف المحددة.

على سبيل المثال، فإن مهمة مدير الجلسة مسؤول عن معالجة الجلسات لمجموعة من المشتركين وأداء خدمات داخل السطر مثل نظير إلى نظير (P2P)، فحص حزمة عميق (DPI)، وهكذا، على حركة مرور المستخدم. تعد مهمة مدير المصادقة والتفويض والمحاسبة (AAA) مسؤولة عن إنشاء أحداث الفوترة لتسجيل إستخدام حركة مرور المشترك وما إلى ذلك. يتم تشغيل مهام مدير الجلسة ومدير AAA على بطاقة PSC/DPC.

تم حجز بطاقة SMC/MIO للتشغيل والصيانة (O&M) والمهام المتعلقة بالنظام الأساسي. يتم تقسيم نظام ASR5x00 فعليا إلى أنظمة فرعية مختلفة للبرامج مثل النظام الفرعي لجلسة العمل لمعالجة جلسات عمل المشترك والنظام الفرعي لشبكة VPN المسؤول عن تعيين عنوان IP والتوجيه وما إلى ذلك. ويتكون كل نظام فرعي من مهمة جهاز تحكم يشرف على سلامة النظام الفرعي الذي يتحكم فيه. يتم تشغيل مهام وحدة التحكم على بطاقة SMC/MIO. يتم دمج مهام مدير الجلسة ومدير AAA معا لمعالجة جلسة عمل المشترك لأغراض التحكم وحركة مرور البيانات والفوترة. عند تمكين إسترداد جلسة العمل في النظام، تقوم كل مهمة من مهام مدير جلسة العمل بإجراء نسخ إحتياطي لحالة مجموعة المشتركين الخاصة بها مع مهمة مدير AAA النظير التي سيتم إستردادها في حالة تعطل مدير جلسة العمل.

ما هو الحادث؟

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

تأثيرات تعطل إدارة جلسة العمل

في إطار العملية العادية، تعالج مهمة مدير جلسة العمل مجموعة من جلسات عمل المشترك وحركة مرور البيانات المقترنة للجلسات مع مهمة مدير AAA نظير التي تعالج فوترة جلسات عمل المشترك هذه. عند حدوث عطل في إدارة جلسة العمل، لن يعود موجودا في النظام. في حالة تمكين إسترداد جلسة العمل في النظام، يتم إجراء مهمة "مدير جلسة عمل الاستعداد" لتصبح نشطة في نفس بطاقة PSC/DPC. تقوم مهمة مدير الجلسة الجديدة هذه بإعادة عقد جلسات عمل المشترك أثناء إتصالها بمهمة مدير AAA النظير. تتراوح عملية الاسترداد من 50 مللي ثانية إلى بضع ثوان معتمدا على عدد جلسات العمل التي كانت نشطة في مدير جلسة العمل في وقت التعطل وتحميل وحدة المعالجة المركزية بشكل عام على البطاقة وما إلى ذلك. لا توجد خسارة في جلسات عمل المشترك التي تم إنشاؤها بالفعل في مدير جلسة العمل الأصلية في هذه العملية. من المرجح أيضا أن تتم إستعادة أي جلسة للمشتركين كانت في طور الإنشاء وقت حدوث التحطم وذلك بسبب إعادة نقل البروتوكولات وما إلى ذلك. يمكن افتراض أن أي حزم بيانات كانت في مرحلة الانتقال عبر النظام في وقت حدوث عطل ما مرتبطة بفقدان الشبكة بواسطة الكيانات المتصلة باتصال الشبكة وسيتم إعادة إرسالها وسيقوم مدير الجلسة الجديدة بمتابعة الاتصال. سيتم الاحتفاظ بمعلومات الفوترة للجلسات التي تنقلها إدارة الجلسة في إدارة AAA النظير.

متى ينبغي ان يقلق المشغل؟

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

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

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

ملاحظة: يضم الهيكل النموذجي المزود بعدد يتراوح بين 7 و 14 بطاقة PSC أو 4-10 بطاقات DPC نحو 120-160 مدير جلسة، ويتوقف ذلك على عدد بطاقات PSC/DPC، وسيؤدي تعطل واحد إلى فقدان نحو 1/40 أو 1/80 من الإحصاءات. عندما يتولى مدير جلسة عمل إحتياطي المهمة، فإنه يبدأ بتجميع الإحصائيات مرة أخرى من الصفر.

كيف نعرف ما إذا حدث عطل؟

سيؤدي عطل إلى تشغيل حدث "فخ SNMP" إلى محطة مراقبة شبكة، مثل خدمة مراقبة الأحداث (EMS) وبواسطة أحداث syslog. كما يمكن ملاحظة الأعطال التي حدثت في النظام باستخدام الأمر show crash list. لاحظ أن هذا الأمر يسرد كل من أحداث الأعطال غير المتوقعة والمتوقعة كما هو موضح مسبقا. يمكن تمييز هذين النوعين من أحداث عطل بواسطة رأس يصف كل عطل.

يتم الإشارة إلى تعطل المهمة متبوعا باسترداد جلسة عمل ناجحة بواسطة رسالة السجل هذه:

"Death notification of task <name>/<instance id> on <card#>/<cpu#> sent to parent
 task <parent name>/<instance id> with failover of <task name>/<instance id>
 on <card#>/<cpu#>"

تم الإشارة إلى تعطل مهمة تعذر إستردادها بواسطة رسالة السجل هذه:

"Death notification of task <name>/<instance id> on <card#>/<cpu#> sent to parent
 task <parent name>/<instance id>"

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

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

 ******** show crash list *******
Tuesday May 26 05:54:14 BDT 2015
=== ==================== ======== ========== =============== =======================
#           Time         Process  Card/CPU/        SW          HW_SER_NUM
                                     PID         VERSION       MIO / Crash Card
=== ==================== ======== ========== =============== =======================

1   2015-May-07+11:49:25 sessmgr  04/0/09564 17.2.1          SAD171600WS/SAD172200MH
2   2015-May-13+17:40:16 sessmgr  09/1/05832 17.2.1          SAD171600WS/SAD173300G1
3   2015-May-23+09:06:48 sessmgr  03/1/31883 17.2.1          SAD171600WS/SAD1709009P
4   2015-May-25+15:58:59 sessmgr  09/1/16963 17.2.1          SAD171600WS/SAD173300G1
5   2015-May-26+01:15:15 sessmgr  04/0/09296 17.2.1          SAD171600WS/SAD172200MH

 ******** show snmp trap history verbose *******
 Fri May 22 19:43:10 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:29 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:30 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 9 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1754 calls recovered 1754 all call lines 1754 time elapsed ms 1108.
 Fri May 22 19:43:32 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:44:49 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:44:49 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:49 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:51 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 7 Cpu Number 0 fetched from aaa mgr 1741 prior to audit 1741 passed audit
 1737 calls recovered 1737 all call lines 1737 time elapsed ms 1047.
 Fri May 22 19:44:53 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:50:04 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 221 card 2 cpu 1 
: Fri May 22 19:50:04 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 221 on card 2 cpu 1
 Fri May 22 19:50:04 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 221 on card 2 cpu 1
Fri May 22 19:50:05 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 2 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1749 calls recovered 1750 all call lines 1750 time elapsed ms 1036.

 ******** show snmp trap history verbose *******
 Fri May 22 19:43:10 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:43:29 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:29 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 204 on card 9 cpu 1
 Fri May 22 19:43:30 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 9 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1754 calls recovered 1754 all call lines 1754 time elapsed ms 1108.
 Fri May 22 19:43:32 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 204 card 9 cpu 1 
 Fri May 22 19:44:49 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:44:49 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:49 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 236 on card 7 cpu 0
 Fri May 22 19:44:51 2015 Internal trap notification 183 (SessMgrRecoveryComplete)
 Slot Number 7 Cpu Number 0 fetched from aaa mgr 1741 prior to audit 1741 passed
 audit 1737 calls recovered 1737 all call lines 1737 time elapsed ms 1047.
 Fri May 22 19:44:53 2015 Internal trap notification 1099 (ManagerRestart) facility
 sessmgr instance 236 card 7 cpu 0 
 Fri May 22 19:50:04 2015 Internal trap notification 73 (ManagerFailure) facility
 sessmgr instance 221 card 2 cpu 1 
: Fri May 22 19:50:04 2015 Internal trap notification 150 (TaskFailed) facility
 sessmgr instance 221 on card 2 cpu 1
 Fri May 22 19:50:04 2015 Internal trap notification 151 (TaskRestart) facility
 sessmgr instance 221 on card 2 cpu 1
Fri May 22 19:50:05 2015 Internal trap notification 183 (SessMgrRecoveryComplete
) Slot Number 2 Cpu Number 1 fetched from aaa mgr 1755 prior to audit 1755 passed
 audit 1749 calls recovered 1750 all call lines 1750 time elapsed ms 1036.

 ******** show logs  *******
2015-May-25+23:15:53.123 [sitmain 4022 info] [3/1/4850 <sitmain:31> sittask.c:4762]
 [software internal system critical-info syslog] Readdress requested for facility
 sessmgr instance 5635 to instance 114
2015-May-25+23:15:53.122 [sitmain 4027 critical] [3/1/4850 <sitmain:31>
 crash_mini.c:908] [software internal system callhome-crash] Process Crash Info:
 time 2015-May-25+17:15:52(hex time 556358c8) card 03 cpu 01 pid 27118 procname
 sessmgr  crash_details 
Assertion failure at acs/acsmgr/analyzer/ip/acs_ip_reasm.c:2970
  Function: acsmgr_deallocate_ipv4_frag_chain_entry()
  Expression: status == SN_STATUS_SUCCESS
  Proclet: sessmgr (f=87000,i=114)
  Process: card=3 cpu=1 arch=X pid=27118 cpu=~17% argv0=sessmgr
  Crash time: 2015-May-25+17:15:52 UTC
  Recent errno: 11 Resource temporarily unavailable
  Stack (11032@0xffffb000):
    [ffffe430/X] __kernel_vsyscall() sp=0xffffbd28
    [0af1de1f/X] sn_assert() sp=0xffffbd68
    [0891e137/X] acsmgr_deallocate_ipv4_frag_chain_entry() sp=0xffffbde8
    [08952314/X] acsmgr_ip_frag_chain_destroy() sp=0xffffbee8
    [089d87d1/X] acsmgr_process_tcp_packet() sp=0xffffc568
    [089da270/X] acs_process_tcp_packet_normal_path() sp=0xffffc5b8
    [089da3fd/X] acs_tcp_analyzer() sp=0xffffc638
    [0892fb39/X] do_acsmgr_process_packet() sp=0xffffc668
    [08940045/X] acs_ip_lean_path() sp=0xffffc6b8
    [0887e309/X] acsmgr_data_receive_merge_mode() sp=0xffffc9d8
    [0887f323/X] acs_handle_datapath_events_from_sm_interface() sp=0xffffca08
    [037c2e1b/X] sessmgr_sef_initiate_data_packet_ind() sp=0xffffca88
    [037c2f50/X] sessmgr_pcc_intf_send_data_packet_ind() sp=0xffffcaf8
    [061de74a/X] sessmgr_pcc_fwd_packet() sp=0xffffcb58
    [0627c6a4/X] sessmgr_ipv4_process_inet_pkt_part2_slow() sp=0xffffcf68
    [06318343/X] sessmgr_ipv4_process_inet_pkt_pgw_ggsn() sp=0xffffd378
    [0632196c/X] sessmgr_med_ipv4_data_received() sp=0xffffd418
    [0633da9a/X] sessmgr_med_data_receive() sp=0xffffd598
    [0afb977c/X] sn_epoll_run_events() sp=0xffffd5e8
    [0afbdeb8/X] sn_loop_run() sp=0xffffda98
    [0ad2b82d/X] main() sp=0xffffdb08

2015-May-25+23:15:53.067 [rct 13038 info] [5/0/7174 <rct:0> rct_task.c:305]
 [software internal system critical-info syslog] Death notification of task
 sessmgr/114 on 3/1 sent to parent task sessctrl/0 with failover of sessmgr/5635 on 3/1
2015-May-25+23:15:53.065 [evlog 2136 info] [5/0/7170 <evlogd:0> odule_persist.c:3102]
 [software internal system critical-info syslog] Evlogd crashlog: Request received to
 check the state of persistent crashlog.
2015-May-25+23:15:53.064 [sitmain 4099 info] [3/1/4850 <sitmain:31> crash_mini.c:765]
 [software internal system critical-info syslog] have mini core, get evlogd status for
 logging crash file 'crashdump-27118'
2015-May-25+23:15:53.064 [sitmain 4017 critical] [3/1/4850 <sitmain:31> sitproc.c:1544]
 [software internal system syslog] Process sessmgr pid 27118 died on card 3 cpu 1
 signal=6  wstatus=0x86
2015-May-25+23:15:53.048 [sitmain 4074 trace] [5/0/7168 <sitparent:50> crashd.c:1130]
 [software internal system critical-info syslog] Crash handler file transfer starting
 (type=2 size=0 child_ct=1 core_ct=1 pid=23021)
2015-May-25+23:15:53.047 [system 1001 error] [6/0/9727 <evlogd:1> evlgd_syslogd.c:221]
 [software internal system syslog] CPU[3/1]:  xmitcore[21648]: Core file transmitted to
 card 5 size=663207936 elapsed=0sec:908ms 
2015-May-25+23:15:53.047 [system 1001 error] [5/0/7170 <evlogd:0> evlgd_syslogd.c:221]
 [software internal system syslog] CPU[3/1]:  xmitcore[21648]: Core file transmitted to
 card 5 size=663207936 elapsed=0sec:908ms 
2015-May-25+23:15:53.047 [sitmain 4080 info] [5/0/7168 <sitparent:50> crashd.c:1091]
 [software internal system critical-info syslog] Core file transfer to SPC complete,
 received 8363207936/0 bytes 

 ******** show session recovery status verbose *******
Tuesday May 26 05:55:26 BDT 2015
Session Recovery Status:
  Overall Status        : Ready For Recovery
  Last Status Update    : 8 seconds ago

              ----sessmgr---  ----aaamgr----  demux
 cpu state    active standby  active standby  active  status
---- -------  ------ -------  ------ -------  ------  -------------------------
 1/0 Active   24     1        24     1        0       Good                     
 1/1 Active   24     1        24     1        0       Good                     
 2/0 Active   24     1        24     1        0       Good                     
 2/1 Active   24     1        24     1        0       Good                     
 3/0 Active   24     1        24     1        0       Good                     
 3/1 Active   24     1        24     1        0       Good                     
 4/0 Active   24     1        24     1        0       Good                     
 4/1 Active   24     1        24     1        0       Good                     
 5/0 Active   0      0        0      0        14      Good (Demux)             
 7/0 Active   24     1        24     1        0       Good                     
 7/1 Active   24     1        24     1        0       Good                     
 8/0 Active   24     1        24     1        0       Good                     
 8/1 Active   24     1        24     1        0       Good                     
 9/0 Active   24     1        24     1        0       Good                     
 9/1 Active   24     1        24     1        0       Good                     
10/0 Standby  0      24       0      24       0       Good                     
10/1 Standby  0      24       0      24       0       Good

بنية تسجيل الأعطال

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

سجل الأعطال هو مستودع متواصل لمعلومات حدث الأعطال. يتم ترقيم كل حدث ويحتوي على نص مرتبط بوحدة المعالجة المركزية (CPU) أو وحدة معالجة الشبكة (NPU) أو عطل kernel. يتم تسجيل الأحداث المسجلة في سجلات ذات طول ثابت ويتم تخزينها في /flash/crashlog2.

عند حدوث عطل، يتم تخزين معلومات التعطل هذه:

1. يتم تخزين سجل الأحداث في ملف /flash/crashlog2 (سجل التصادم).
2. يتم تخزين ملف تفريغ Minicore أو NPU أو kernel المقترن في الدليل /flash/crsh2.
3. يتم تخزين تفريغ أساسي كامل في دليل تم تكوينه من قبل المستخدم.

مزامنة أحداث الأعطال والعلامات المصغرة بين بطاقات الإدارة

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

سيتم إرسال حدث الأعطال القادم إلى SMC/MIO في وضع الاستعداد وحفظه في ملف سجل الأعطال في وضع الاستعداد بالطريقة نفسها. يلزم مزامنة مكبات Minicore أو NPU أو kernel على ذاكرة الفلاش الخاصة ب SMC/MIO النشطة إلى وضع SMC/MMIO في وضع الاستعداد باستخدام الأمر rsync. عندما يتم حذف إدخال سجل crashlog أو القائمة بالكامل من خلال أمر واجهة سطر الأوامر (CLI)، يجب حذفه على كل من SMCs/MIO النشطة والاحتياطية. لا يوجد تأثير على الذاكرة. سيتم تنفيذ كافة أنشطة المزامنة المتعلقة بالأعطال بواسطة تسجيل دخول بطاقة SMC/MIO الاحتياطية، نظرا لأن تسجيل الدخول في وضع الاستعداد أقل تحميل ولأن البطاقة الاحتياطية لديها مساحة كافية لنشاط المزامنة. وبالتالي لن يتأثر أداء النظام.

الأوامر

يمكن إستخدام هذه الأوامر لاستكشاف الأخطاء وإصلاحها:

#show support details

#show crash list

#show logs

#show snmp trap history verbose

#show session recovery status verbose

#show task resources facility sessmgr instance <>

#show task resources facility sessmgr all

يتم إنشاء ملفات التحكم بعد عطل. عادة ما تقوم المشغلات بتخزينها في خادم خارجي. عادة ما يبدو اسم الملف المرجعي كعطل-<Cardnum>-<CPU Num>-<hex timestamp>-coree.gcrash-09-00-5593a1b8-core.

عند حدوث عطل، يتم تخزين معلومات التعطل هذه:

• يتم تخزين سجل الأحداث في ملف /flash/crashlog2 (سجل التصادم).
• يتم تخزين ملف تفريغ Minicore أو NPU أو kernel المقترن في الدليل /flash/crsh2.

ملخص

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