ISSU

IOS Upgrade လုပ်ကြမယ်လို့ဆိုလိုက်တိုင်း ခေါင်းခဲရတာကတော့ Operations ဖက်မှာ အလုပ်လုပ်တဲ့ Network Admin တွေပေါ့။ အထူးသဖြင့် Core Router/Switch လိုမျိုးအဓိကကျတဲ့ နေရာမျိုး။ မပြောင်းခင် ပြင်ဆင်ရတာက တစ်မျိုး၊ ပြောင်းမဲ့အချိန် Maintenance Window နဲ့ သက်ဆိုင်တဲ့လူတွေနဲ့ ညှိရတာတစ်မျိုး၊ စီစဉ်ရတာမလွယ်ဘူး။ ပြီးတော့ ပြောင်းပြီးတဲ့အခါ အဆင်မပြေလို့ ပြန်ပြောင်းရတဲ့ (Fall-back) ကိစ္စတွေကရှိသေးတယ်။ ပြောရမယ်ဆိုရင် လွယ်တယ်လို့ထင်ရတဲ့ အလုပ်ပေမဲ့ တစ်ကယ်တမ်းကြတော့ သိပ်မလွယ်ပါဘူး။ နောက်တစ်ခုက ကြာချိန်ပေါ့ Down time ကနဲနိင်သမျှနဲမှရမှာ၊ Customer တွေကတော့ Down-time ဆို မရှိရင်အကောင်းဆုံးပဲလို့ပဲ သတ်မှတ်မှာပဲ။ ဒီတော့ Maintenance Window နဲ့ Downtime ကို အနဲဆုံးရအောင်စီစဉ်ရပါတယ်။ ဒါကြောင့်လဲ Redundancy တွေ၊ HA တွေ၊ Active-Passive တွေ စသဖြင့် အသုံးပြုရတာပေါ့။

အဲဒါတွေအပြင် ISSU လို့ခေါ်တဲ့ In-Service Software Upgrade က IOS Upgrade လုပ်တဲ့အချိန်မှာ Downtime အနဲဆုံးဖြစ်အောင်၊ မရှိအောင် router/switch တွေကို Reboot လုပ်စရာမလိုပဲ Upgrade လုပ်ပေးပါတယ်။ နည်းပညာလို့ဆိုတာထက် Procedure လို့ဆိုရင်ပိုမှန်ပါလိမ့်မယ်။ ဘာလို့လဲဆိုတော့ သူတကယ်အသုံးပြုသွားကတော့ NSF (Non-stop Forwarding) နဲ့ SSO (State-full Switch Over) ပါ၊ အဲဒါကို Redundant Route Processor ဒါမှမဟုတ် Redundant Supervisor Engine တို့နဲ့ တွဲသုံးထားတဲ့ Procedure ပါ။ မြင်သာအောင် ပြောရရင်တော့ Upgrade/Downgrade လုပ်နေတဲ့ အချိန်မှာ Packet forwarding ကိုမထိခိုက်စေတဲ့ လုပ်ဆောင်မှု ဆိုပါတော့။ Redundant RP/ Sup-Engine မရှိရင်တော့ မရပါဘူး၊ ဒါကိုကြည့်ရင် Router/switch အသေးလေးတွေမှာ မရဘူးဆိုတဲ့သဘောပါ။ အဓိက နေရတွေမှာ အသုံးပြုတဲ့ Modular Core Router/ Core Switch တွေမှသာ အသုံးပြုလို့ရနိုင်ပါလိမ့်မယ်။

သူကဘာလုပ်ပေးလဲဆိုရင်တော့ အရင်ဆုံး အသုံးပြုမဲ့ IOS ကို Active ကော၊ Standby မှပါ ထည့်ထား၊ ပြီးရင် Standby မှာ အဲ့ဒီ IOS အသစ်ကို ပြောင်း၊ ပြောင်းပြီးရင် Active/Standby ကို Switch-over လုပ်၊ ဒီတော့ အရင် Active က Standby အဖြစ်ပြောင်းသွားပြီး Active အသစ်က IOS အသစ်နဲ့တက်လာမှာဖြစ်ပါတယ်။ နောက်တော့မှာ အရင် Active အဟောင်း(လက်ရှိ Standby ဖြစ်သွားတဲ့) ကို IOS အသစ်ပြောင်း လိုက်တာပါ။ ဒါများ ဘာဆန်းလို့လဲဆိုရင်တော့ အဲဒီလိုအပြောင်းအလဲလုပ်နေတဲ့ အချိန်အတွင်းမှာ Packet forwarding ကိုမထိခိုက်ပဲ Downtime/Outage ကိုနဲသွားစေတာပါပဲ၊ နောက်တစ်ခုကတော့ အဆင်မပြေလို့ပဲဖြစ်ဖြစ်၊ ဆက်မလုပ်ချင်တော့ပဲဖြစ်ဖြစ် တစ်ဝက်လောက်ကနေ Auto-Rollback ပြန်လုပ်နိုင်တာပါပဲ။ ပုံမှန်အတိုင်းလုပ်မယ်ဆိုရင် အဆင်မပြေမှ ပြန်ပြောင်းရင် နောက်ထပ် Reboot တစ်ကြိမ်အတွက် အချိန်ထပ်ပေးရမယ်၊ Module တွေများရင်များသလို ကြာချိန်ပိုလိမ့်မယ်။ နောက်တစ်ခုအနေနဲ RP/Sup-Engine ကတော့ ဟုတ်ပီ Line card/ Module ကောဆိုရင်တော့ MDR လို့ခေါ်တဲ့ Minimum Disruption Restart က Ports တွေကိုအတက်အကျ(Flapping) မဖြစ်စေပဲ အသစ်တက်လာတဲ့ IOS နဲ့ ကိုက်ညီအောင် Upgrade လုပ်ပေးသွားပါလိမ့်မယ်။

Command အနေနဲ့ သိပ်အခက်ခဲမရှိပဲ ကြည့်ပြီးလိုက်လုပ်ရင် အဆင်ပြေနိုင်ပါတယ်၊ အဓိက ကတော့ Planning ပါ။ သူ့ကိုအသုံးပြုဖို့ရာအတွက် လိုအပ်ချက်တွေဖြစ်တဲ့ Redundant RP/Sup-Engine တွေနဲ့ Active RP/Sup-Engine တွေရဲ့ သုံးထားတဲ့ IOS တူဖို့၊ အရင်အသုံးပြုထားတဲ့ IOS ဟာအသစ်အသုံးပြုမဲ့ IOS ကိုတိုက်ရိုက် Upgrade လုပ်လို့ရမရ၊ ပြီးရင် SSO mode စတာတွေကို အသေးစိတ်ပြင်ဆင်ထားဖို့လိုအပ်ပါတယ်။ သူ့ရဲ့ Process Flow ကို Cisco Documentation တွေမှာပြထားတဲ့ ပုံတွေကို ကြည့်ရင်ပိုပြီးရှင်းသွားပါလိမ့်မယ်။ ဒါကို အသုံးပြုချင်းအားဖြင့် Network Admin ရဲ့အားစိုက်ထုတ်ရမှုကတော့ လျော့သွားမှာ မဟုတ်ပါဘူး၊ ဒါပေမယ့် Maintenance Window အတွင်းမှာ ဖြစ်ပေါ်နိုင်တဲ့ ပြတ်တောက်မှု၊ Downtime ကိုနဲသွားစေပြီး၊ Fallback လုပ်ဖို့ လိုအပ်လာတဲ့ အခြေအနေမျိုးမှာ အချိန်ကို ပိုမိုပြီး အသုံးချလို့ရမှာဖြစ်ပါတယ်။

 

ကိုဖြိုး