السلام عليكم ورحمة الله وبركاته...
موضوعنا اليوم فى غاية الأهمية من حيث ال Redundancy
وحيث ان كل المعلومات من أول كورس CCNA وكورس CCNP تتحدث حول عمل ال Redundancy والتغلب على ال Single-point Fail-Over
كان كل المعلومات حول ال fail فى ال Protocols أو ال Device ككل...
الموضوع ضمن مواضيع كورس Switch اللى هوا منهج ال 813-642
====
الموضوع سهل جداً ان شاء الله...ومش فيه أى صعوبة على الاطلاق..
فى البداية هنبسط الموضوع شوية..
لو تلاحظ ان سيسكو فى كل حاجة تحب تقولك اييه...Redundancy ...صح
فى كل حاجة لازم يبقى ليها بديل عنده...تلاقيها ]دايما فى حل مشكلة ال fail-over
دايما تعمل مثلاُ ال Hello/Dead Timers عشان ال Routers-Neighbor يبقى Down يبدأ يبحث عن مسار تانى,,
دايما تلاقيها تقولك خلى ال Distribution-layer فيها أكتر من MLS وليهم برده Redundancy Links
كل حاجة بتحاول تخلى منها اتنين...عشان لما واحد يبقى Down التانى يقوم مكانه بدون ما تتعطل الخدمة...ودى تسمة دايما ال optimized network أو ال Converged Network
يبقى وصلنا ان دايما ال Redundancy مهمة فى حالة التعطل...
تخيل ان فى سيناريو ان مثلاً ال MLS الموجود فى ال dist-layer اتعطل منه جزء منعه عن العمل جزئياً..أو حصل hang لأحد أجزاؤه..
يعنى تخيل مثلاً انت عندك فى البيت جهازين وعاملهم Clustering سواء كانوا بيخدموا على عايه..مش دى النقطة..وفى واحد هوا active والتانى Stand-by
المفروض لما ال Active يفصل ويبقى Down يسلم المهمة / أو الStand يستلم المهمة لوحده...صح كده
تخيل بقى ان الHard-Disk حصله Fail ال Server ال Active دا حصله Hang..ف بالتأكيد مش هيقدر يرد على ال Requests الى هتوصله..وكمان ال Stand مش هياخد دوره ويبقى Active فهتفضل المشكلة موجودة...وحلها ايييه...انك يبقى عندك Backup-Hard وكمان عامل Mirror مع ال Hard الأول عشان لما ال Hard الأول يقف الهارد التانى موجود وعيه نفس البيانات.
دا كدا كان عند ال Servers وشغل Microsoft و Linux
تعالى للشغل الخاص بينا..وهو شغل ال Cisco Devices
هنتكلم عن ال Redundancy لل 4500 وال 6500
دائما ما بيستخدموا فى ال Dist / Core layer ....ودايما Cisco بت Recommend ان مش يبقى عندك Single-Point failure
فعشان نعمل كده...عندنا Three Otions وهم
Route Processor Redundancy - RPR
Sateful Switchover - SSO
None-Stop Forwarding - NSF
تعالى نتكلم عن ال Route Processor Redundancy
فكرة عمل ال RPR هى ان ال MLS موجود داخله...اتنين روتر بروسيسور....Two RP
واحد بيكون شغال Active والتانى Stand...أول ما ال active يحصل فيه مشكلة..يبدأ ال Stand ياخد ال Role بتاعته ويبقى هوا Active
سهله خااالص...ايه المشكلة بقى..؟؟
المشكلة ان ال Active processor بيكون عيه ال Data كلها...لازم نقولها ب ال english عشان نفهمها....All Process are initialized on Active RP
يعنى كل العمليات ال MLS بيعملها موجوده على ال Active...هتقولى وايه المشكلة فى كده...؟؟!!
المشكلة ان اما ال active RP يبقى Down لأى سبب..بيبدأ ال Stand RP يتحول ل active ....وبيبدأ يشغل ال Processes اللى كانت على ال Active مرة تانية من أول وجديد...كأنك بالظبط
عملت restart للراوتر..يعنى ال Neighbors هتبقى Down وكل ال Tables اللى عنده هيتعملها Clear وتبنى من أول وجديد...ودا بياخد من 3 - 5 دقايق,,,وحسب ال Services اللى MLS بيعملها ممكن يزيد الوقت عن كده...
وبعد كده عملوا تطوير شوية لل RPR وبقت النسخة الأحدث منه RPR+ وفيه ال Time بتاع ال Fail-Over أقل...بقى من 30 - 60 ثانىة
أخر حاجة..ومهمة جداً..وتعتبر ال trick هنا....ان الحاجة الوحيدة اللى بتفضل موجودة...هيا ال Static-Route بس....ولا يفضل هذا النوع من ال Redundancy لطول الوقت المستغرق..وكثرة العمليات اللى بيقوم بيها مرة أخرى أثناء ال Fail-Over
====
ننتقل لل option التانى...وهو ال Stateful Switch-Over
يعد ال SSO تطوير لل RPR بنوعيه...للاختلافات اللى تمت عليه...تعالى نشوف مع بعض ايه اللى بيحصل فى النوع دا من ال Redundancy
النوع دا الهدف الأكبر منه هو تقليل الوقت ال مستغرق فى عملية ال Fail-over عن طريق بعض العمليات..
ان ال Active RP بيقوم عادى جداً..وكل العمليات شغالة عليه بدون اى مشكلة...بس الفرق هنا فى ال عملية ال Boot-UP لل Active وال Stand-by مختلفة
أول ما ال active يعمل ال boot بتاعه ويخلص...ال Stand برده بيعمل Initializing عادى برده لمعظم العمليات ال Active عملها...يعنى اعتبر ان الاتنين عملوا نفس العمليات..وال Active هوا اللى بيباشر العمليات كلها..و ال Stand هنا كل اللى بيعمله ان هوا Keep track Of Updates on Active RP ....يعنى أى تغيير او تحديث يحصل على ال Active RP نسخة منه بتروح لل Stand-By RP برده..
جميييل جداً....ودا أكيييد يوفر وقت كتيير لما ال Active يحصله fail وال Stand ياخد مكانه..مش هيحتاج يتعلم كل حاجة من أول وجديد زى النوع السابق اللى هوا ال RPR
والوقت المستغرق فى ال fail-over بيكون كحد أقصى 3 ثوانى فى ال 6500 وأقل من ثانية فى ال 4500
أما ال Trick هنا...ان ال Links مش هتبقى Down ولا أى حاجة..لأن ال SSO بيتتبع ال status الخاصة ب ال UP/Down بكل ال Ports وال active يفضل active زى ما هوا..وبالتالى كل ال Layer-2 Protocols زى ما هيا لأن ال Port Status لم تتغير زى ال STP مثلاً مش هيتأثر على الاطلاق...وأخيراً بس ان كل ال layer-3 Information must be re-learned..يعنى يبنى ال Tables من تانى بس..
وعشان تفعل ال SSO يتكون من
Switch(Config )# Redundancy
Switch(Config-Red)#Mode SSO
========
ال Option الثالث من ال Redundancy وهو ال None-Stop Forwarding
ال NSF بنى على ال SSO وبترافق معاه فى ال Redundancy Settings
بيقوم ال NSF على خصائص ال SSO السابقة كلها مع تحسيت ال Fail-over الخاص ب Layer-3
وكما تلاحظ ان ال SSO كان بيشتغل كويس جداً مع ال fail-over الخاص ب Layer-2 ولا يوجد أى شىء يخص Layer-2 يتغير سواء كان protocol أو Port Status وانما كان عملية ال Re-build خاصة ب layer-3
وهنا جاء دور ال NSF ليتغلب على هذا المشكلة..عن طريق ان ال Stand-by RP بياخد Copy من كل حاجة موجودة فى لا Active RP و ال Fail-over بيتم فى أقل من ثانية..وال Layer-3 Traffic بيفضل زى ما هوا..لأن ال Stand-By كان واخد Copy من ال RIB , CEF , FIB tables وبيفضل يشتغل عليهم...ولو فى أى تحديث تم على هذه ال Tables خلال الثانية اللى حصل فيها ال Fail بيعمل Update لل Tables اللى عنده..
ويفعل هذا النوع من ال Redundancy تحت ال Routing protocol Configuration..لأن كما تلاحظ ان التحسين والاضافة اللى تمت على ال SSO هى ال Layer-3
مثال ذلك..
Router(Config)# Router OPSF 1
Router(Config-router)#NSF
==========
فى النهاية..
يارب أكون قدرت أوضح الموضوع..والكل يستفيد ان شاء الله.
ولو فى أى استفسار أو حاجة أى جزء غير واضح..ان شاء الله نوضحه مرة أخرى.
بالتوفيق ان شاء الله..
يارب,
المفضلات