မာတိကာ သို့ သွားရန်

၅ · Hyper-Scale ကွန်ရက်များရှိ IGPs

ယခုအချိန်အထိ သင်လေ့လာခဲ့သမျှ အရာအားလုံးသည် enterprise ကွန်ရက်များ၊ service provider များနှင့် သာမန်အရွယ်အစားရှိသော data center များအတွက် မှန်ကန်ပါသည်။ သို့သော် သင်၏ ရည်မှန်းချက်သည် hyper-scaler ကြီးများ (Google, AWS, Meta) ရှိ network engineering ရာထူးတစ်ခု ဖြစ်ပါက စည်းမျဉ်းများသည် လုံးဝပြောင်းလဲသွားပါလိမ့်မည်။

Router ပေါင်း သောင်းနှင့်ချီ၍ ကိုင်တွယ်လည်ပတ်ရသည့်အခါ ရိုးရာ link-state protocol များသည် ချွတ်ယွင်းအားနည်းလာကြသည်။ အောက်တွင် FAANG network များသည် IGP များကို မည်သို့ သဘောထားရှုမြင်ကြသည်နှင့် ၎င်းတို့ကို အဘယ်ကြောင့် အသုံးပြုခြင်းမရှိတော့သည်အထိ ပြန်လည်ဒီဇိုင်းဆွဲခဲ့ကြသည်ကို ရှင်းပြထားပါသည်။

Link-state protocol များ (OSPF နှင့် IS-IS) သည် ကောင်းမွန်စွာ scale လုပ်နိုင်သော်လည်း အကန့်အသတ်မရှိ scale မလုပ်နိုင်ပါ။ ၎င်းတို့သည် အခြေခံအားဖြင့် အချက် ၃ ချက်ကြောင့် လည်ပင်းညှစ်ခံရတတ်သည် (bottlenecked) -

၁။ Flooding ဝန်ပိမှု (The Blast Radius)

Link-state area တစ်ခုအတွင်း router တိုင်းတွင် identical database မိတ္တူတစ်ခုစီ ရှိနေရပါမည်။ Link တစ်ခု flap ဖြစ်သွားတိုင်း (ပြတ်တောက်/ပြန်တက်တိုင်း) LSA/LSP တစ်ခု ထုတ်လွှင့်ပြီး ထို area အတွင်းရှိ router တိုင်း ထံသို့ flood ပြုလုပ်ဖြန့်ဝေသည်။ အကယ်၍ သင့်တွင် switch ပေါင်း ၁,၀၀၀ ပါဝင်သော Clos fabric (spine-leaf) တစ်ခု ရှိနေပါက link တစ်ခုတည်း flap ဖြစ်ရုံမျှဖြင့် အပ်ဒိတ်လှိုင်းလုံးကြီးတစ်ခု (shockwave of updates) ရိုက်ခတ်သွားပါလိမ့်မည်။ Hyper-scale data center တစ်ခုတွင် link flap ဖြစ်မှုများသည် မိနစ်တိုင်းနီးပါး ဖြစ်ပွားနေတတ်သည်။ အကယ်၍ သင်သည် ကြီးမားသော fabric ကြီးတစ်ခုလုံးပေါ်တွင် single OSPF area တစ်ခုတည်းကို run ထားပါက သင်၏ router များသည် packet များကို ပို့ဆောင်ပေးရမည့်အစား flooded updates များကို CPU အပြည့်သုံး၍ စီမံတွက်ချက်နေရခြင်းဖြင့်သာ အချိန်ကုန်သွားပါလိမ့်မည်။

၂။ SPF တွက်ချက်မှု အချိန်ကြာမြင့်ခြင်း (SPF computation time)

Dijkstra ၏ algorithm သည် O(E \log V) ဖြစ်ပြီး V မှာ vertices (routers) နှင့် E မှာ edges (links) ဖြစ်ကြသည်။ Spines ရာပေါင်းများစွာနှင့် Leaves ထောင်ပေါင်းများစွာ ပါဝင်သော သိပ်သည်းစွာ ဆက်သွယ်ထားသည့် Clos topology တွင် edges အရေအတွက်သည် မိုးထိအောင် များပြားလှသည်။ ထို graph ကြီးပေါ်တွင် full SPF computation တစ်ခုကို တွက်ချက်ခြင်းသည် သိသာထင်ရှားသော CPU အချိန်နှင့် memory ပမာဏကို ကုန်ကျစေပါသည်။

၃။ Distributed state သည် စဉ်းစားသုံးသပ်ရန် ခက်ခဲခြင်း

Link-state routing သည် အပြည့်အဝ distributed စနစ်ဖြစ်သည်- Router တိုင်းသည် မိမိ၏ local database မိတ္တူပေါ် အခြေခံ၍ သီးခြားစီ ဆုံးဖြတ်ချက်ချကြသည်။ အကယ်၍ vendor တစ်ခု၏ switch ပေါ်ရှိ SPF implementation တွင် bug တစ်ခုခု ရှိနေပါက သို့မဟုတ် လမ်းခရီးတွင် LSP တစ်ခု ပျက်စီးသွားပါက router များသည် မတူညီသော လမ်းကြောင်းများကို တွက်ချက်မိကြလိမ့်မည်။ ယင်းသည် scale ကြီးမားသော network များတွင် troubleshoot လုပ်ရန် အလွန်ခက်ခဲသည့် micro-loops များကို ဖြစ်ပေါ်စေသည်၊ အကြောင်းမှာ ကွန်ရက်တစ်ခုလုံးသည် အချက်အလက်အမှား (lie) ပေါ်တွင် အခြေခံ လှုပ်ရှားနေသောကြောင့် ဖြစ်သည်။

FAANG အဖွဲ့အစည်းများ၏ ဖြေရှင်းချက်များ

Link-state ၏ ကန့်သတ်ချက်များဆီသို့ ရောက်ရှိလာသည့်အခါ သင်ရွေးချယ်စရာ ၂ လမ်းရှိသည်- Topology အခင်းအကျင်းကို ပြောင်းလဲခြင်း သို့မဟုတ် Protocol ကို ပြောင်းလဲခြင်း ဖြစ်သည်။ Hyper-scaler များသည် နှစ်မျိုးစလုံးကို ပြုလုပ်ကြသည်။

IGP အစား BGP ဖြင့် အစားထိုးခြင်း (The Jupiter Approach)

၂၀၁၂ ခုနှစ်တွင် Google သည် ၎င်းတို့၏ data center fabric ဗိသုကာဖြစ်သော Jupiter ဆိုင်ရာ စာတမ်းတစ်စောင်ကို ထုတ်ဝေခဲ့သည်။ အကျော်ကြားဆုံး အချက်တစ်ချက်မှာ ၎င်းတို့သည် IGP ကို လုံးဝ အသုံးမပြုခဲ့ကြခြင်း ဖြစ်သည်။

OSPF သို့မဟုတ် IS-IS အစား Jupiter သည် နေရာတိုင်းတွင် (Top-of-Rack မှသည် Spine အထိ) eBGP ကို underlay အဖြစ် အသုံးပြုထားသည်။

eBGP ကို အဘယ်ကြောင့် အသုံးပြုသနည်း - - Distance-vector သည် ပြတ်တောက်မှုများအတွက် firewall တစ်ခုသဖွယ် လုပ်ဆောင်ပေးခြင်း- BGP သည် ၎င်း၏ direct peers များဆီသို့သာ updates ပို့ပေးပြီး မိမိ၏ အကောင်းဆုံး (best) လမ်းကြောင်းကိုသာ ကြေညာသည်။ Topology တစ်ခုလုံးကို flood မလုပ်ပါ။ ၎င်းသည် flapping link တစ်ခု၏ ထိခိုက်မှု အတိုင်းအတာ (blast radius) ကို အလွန်အမင်း ကန့်သတ်ပေးသည်။ - Shared database မလိုအပ်ခြင်း- Router များသည် topology တစ်ခုလုံးကို သိရှိရန် မလိုအပ်ပါ; Next hop ကိုသာ သိရှိရန် လိုအပ်သည်။ - Traffic Engineering- BGP ၏ policy engine (route maps, AS-path prepending, communities) သည် OSPF ၏ metric ပြောင်းလဲမှုများထက် များစွာ ပိုမိုပြောင်းလွယ်ပြင်လွယ် ရှိသည်။

ဤဒီဇိုင်း (RFC 7938: Use of BGP for Routing in Large-Scale Data Centers) သည် ခေတ်သစ် data center များအတွက် စံပြပုံစံဖြစ်လာခဲ့သည်။ FAANG အင်တာဗျူးတစ်ခုတွင် ဆာဗာပေါင်း ၅၀,၀၀၀ ရှိသော data center တစ်ခုကို မည်သို့ route လုပ်မည်နည်းဟု မေးမြန်းခံရပါက မျှော်လင့်ထားသော အဖြေမှာ OSPF မဟုတ်ဘဲ eBGP သာ ဖြစ်သည်။

ဗဟိုချုပ်ကိုင်မှု စနစ် (Centralized Control: SDN နှင့် B4)

Google ၏ global WAN ဖြစ်သော B4 သည် အများသုံး internet ထက်ပင် traffic ပိုမိုများပြားစွာ သယ်ဆောင်ထားသည်။ သို့သော် ဧရာမ IS-IS areas ကြီးများ run ထားသော ရိုးရာ ISP backbone နှင့် မတူဘဲ B4 သည် Software-Defined Networking (SDN) ကို အသုံးပြုထားသည်။

SDN ဗိသုကာတွင် "ဦးနှောက်" (control plane) ကို "ကြွက်သား" (data plane) ထံမှ ခွဲထုတ်ထားသည် - ၁။ Router များသည် direct neighbours များကို ရှာဖွေရန်နှင့် အခြေခံချိတ်ဆက်မှု ရရှိရန်အတွက် ပေါ့ပါးသော IGP (IS-IS သို့မဟုတ် OSPF ကဲ့သို့) ကို ဆက်လက် run ကြသည်။ ၂။ Centralized controller သည် ဤ topology graph တစ်ခုလုံးကို စုပ်ယူရယူသည်။ ၃။ Controller သည် traffic လိုအပ်ချက်များနှင့် link capacities အားလုံး၏ global view အပြည့်အစုံ ရှိနေသဖြင့် flow တိုင်းအတွက် အကောင်းဆုံး လမ်းကြောင်းများကို ကိုယ်တိုင် တွက်ချက်သည်။ ၄။ ထို့နောက် Router များ၏ forwarding tables များကို (OpenFlow, P4 သို့မဟုတ် Segment Routing အသုံးပြု၍) တိုက်ရိုက် သတ်မှတ်ညွှန်ကြားပေးသည်။

ဤပုံစံတွင် IGP သည် routing ဆုံးဖြတ်ချက်များကို ချမှတ်ပေးနေခြင်း မဟုတ်တော့ဘဲ physical graph ကို ရှာဖွေဖော်ထုတ်ပေးသည့် telemetry ယန္တရားတစ်ခုမျှသာ ဖြစ်သွားတော့သည်။

Segment Routing (SR-MPLS / SRv6)

Hyper-scaler များသည် IGP ကို သုံးသည့်တိုင်အောင် အသုံးပြုပုံချင်း မတူညီကြပေ။ Segment Routing သည် packet ပေါ်တွင် labels များ (သို့မဟုတ် IPv6 headers များ) ကို ဆင့်ထပ်ထည့်သွင်းခြင်း (stacking) ဖြင့် source node အနေဖြင့် packet တစ်ခု ကွန်ရက်ကို ဖြတ်သန်းသွားရမည့် လမ်းကြောင်းကို တိုက်ရိုက်ညွှန်ကြားစေနိုင်သည်။

Tunnels များ တည်ဆောက်ရန် ရှုပ်ထွေးသော RSVP-TE protocol များကို run ရမည့်အစား hyper-scaler များသည် IS-IS တွင် SR extensions များကိုသာ ပေါင်းထည့်လိုက်ကြသည်။ IS-IS က node labels များကို ဖြန့်ဝေပေးပြီး centralized controller က ingress router အား မည်သည့် label stack ကို push လုပ်ရမည်ကို ပြောပြသည်။ Core network သည် အပြည့်အဝ stateless ဖြစ်သွားသည် — ထိပ်ဆုံး label ပေါ် အခြေခံ၍ forward လုပ်ပေးရုံသာ ဖြစ်သည်။

ဤအချက်ကြောင့်ပင် ခေတ်သစ် hyper-scale WAN များတွင် OSPF ထက် IS-IS ကို အလွန်အမင်း ပိုမိုနှစ်သက်ကြခြင်း ဖြစ်သည်- ၎င်း၏ TLV ဖွဲ့စည်းပုံကြောင့် Segment Routing extensions များကို ထည့်သွင်းရန် အလွန်လွယ်ကူသောကြောင့် ဖြစ်သည်။

အင်တာဗျူးများအတွက် အဓိက မှတ်သားဖွယ်ရာများ

သင်သည် နည်းပညာကုမ္ပဏီကြီးများတွင် network engineering ရာထူးတစ်ခုအတွက် အင်တာဗျူး ဖြေဆိုနေပါက Scale (အရွယ်အစား ကြီးမားမှု) ကို သင်နားလည်ကြောင်း ပြသရမည် ဖြစ်သည်။

  • Router ထောင်ပေါင်းများစွာ ပါဝင်သော ကွန်ရက်တစ်ခုအတွက် single OSPF area ကို ဘယ်တော့မှ အဆိုမပြုပါနှင့်။
  • Blast radius နှင့် convergence နှင့် ပတ်သက်၍ distributed protocols (OSPF/IS-IS) နှင့် distance-vector protocols (BGP) အကြား အပေးအယူ အားသာချက်/အားနည်းချက်များကို ရှင်းပြနိုင်ရန် အသင့်ပြင်ထားပါ။
  • ခေတ်သစ် ဗိသုကာများတွင် IGP ၏ အဓိကတာဝန်မှာ user traffic များကို တိုက်ရိုက် route လုပ်ပေးရန် မဟုတ်ဘဲ BGP next-hop သို့မဟုတ် SDN controller ဆီသို့ ရောက်ရှိနိုင်စေရန်သာ ဖြစ်ကြောင်း နားလည်ထားပါ။