သူ့ကိုယ်သူ ကုသပေးသည့် ကွန်ရက်တစ်ခု- Flow Label ၏ မှော်ဆန်မှုနှင့် Linux kernel ပတ်လည်ရှိ စုံထောက်။ Yandex အစီရင်ခံစာ

ခေတ်မီဒေတာစင်တာများတွင် စောင့်ကြည့်မှုအမျိုးအစားအမျိုးမျိုးဖြင့် လွှမ်းခြုံထားသည့် တက်ကြွသောစက်ပစ္စည်းရာပေါင်းများစွာရှိသည်။ သို့သော် လက်ထဲတွင် ပြီးပြည့်စုံသော စောင့်ကြည့်မှုရှိသော ပြီးပြည့်စုံသော အင်ဂျင်နီယာတစ်ဦးပင်လျှင် မိနစ်အနည်းငယ်အတွင်း ကွန်ရက်ချို့ယွင်းမှုကို မှန်ကန်စွာ တုံ့ပြန်နိုင်မည်ဖြစ်သည်။ Next Hop 2020 ကွန်ဖရင့်တွင် အစီရင်ခံစာတစ်ခုတွင် ထူးခြားသောအင်္ဂါရပ်ပါရှိသော ဒေတာစင်တာသည် မီလီစက္ကန့်အတွင်း သူ့ကိုယ်သူ ကုသပေးသည့် ဒေတာစင်တာ ကွန်ရက်ဒီဇိုင်းနည်းစနစ်ကို တင်ပြခဲ့သည်။ ပို၍တိကျသည်မှာ၊ အင်ဂျင်နီယာသည် ပြဿနာကို အေးအေးဆေးဆေး ဖြေရှင်းပေးသည်၊ ဝန်ဆောင်မှုများသည် ၎င်းကို သတိမထားမိဘဲ ဖြစ်နေသည်။

- အစကတော့၊ ခေတ်မီ DC ရဲ့ ဖွဲ့စည်းပုံကို မသိတဲ့သူတွေအတွက် အတော်လေး အသေးစိတ် နိဒါန်းတစ်ခု ပြောပြပါမယ်။


ကွန်ရက်အင်ဂျင်နီယာများစွာအတွက်၊ data center network သည် rack အတွင်းခလုတ်တစ်ခုဖြင့် ToR ဖြင့်စတင်သည်။ ToR တွင် များသောအားဖြင့် လင့်ခ်နှစ်မျိုးရှိသည်။ သူငယ်များသည် ဆာဗာများသို့သွားသည်၊ အခြားသူများ - ၎င်းတို့အနက် N အဆပိုများသည် - ဆိုလိုသည်မှာ ၎င်း၏ အထက်လင့်ခ်များသို့ ပထမအဆင့် ကျောရိုးဆီသို့ သွားကြသည်။ Uplinks များကို အများအားဖြင့် တူညီသည်ဟု ယူဆကြပြီး uplinks များကြား လမ်းကြောင်းသည် proto၊ src_ip၊ dst_ip၊ src_port၊ dst_port တို့ပါ၀င်သော 5-tuple hash ကို အခြေခံ၍ ဟန်ချက်ညီပါသည်။ ဤနေရာတွင် အံ့သြစရာမရှိပါ။


နောက်တစ်ခု၊ လေယာဉ်တွေရဲ့ တည်ဆောက်ပုံက ဘယ်လိုလဲ။ ပထမအဆင့်၏ကျောရိုးများသည် တစ်ခုနှင့်တစ်ခုမချိတ်ဆက်သော်လည်း superspins ဖြင့်ချိတ်ဆက်ထားသည်။ အက္ခရာ X သည် superspins အတွက်တာဝန်ယူမည်ဖြစ်ပြီး၊ ၎င်းသည် cross-connect နှင့်တူသည်။


အခြားတစ်ဖက်တွင်၊ တိုရီသည် ပထမအဆင့်၏ကျောရိုးအားလုံးနှင့် ချိတ်ဆက်ထားကြောင်း ထင်ရှားသည်။ ဤပုံတွင် အဘယ်အရာက အရေးကြီးသနည်း။ အကယ်၍ ကျွန်ုပ်တို့သည် rack အတွင်းတွင် အပြန်အလှန်ဆက်သွယ်မှုရှိပါက၊ အပြန်အလှန်ဆက်သွယ်မှုသည် ToR မှတဆင့်သွားပါသည်။ အပြန်အလှန်အကျိုးသက်ရောက်မှုသည် module အတွင်းသို့ဝင်ပါက၊ အပြန်အလှန်ဆက်သွယ်မှုသည်ပထမအဆင့်၏ကျောရိုးများမှတဆင့်သွားပါသည်။ အကယ်၍ အပြန်အလှန်အကျိုးသက်ရောက်မှုသည် ToR 1 နှင့် ToR 2 ဖြစ်သည်ဆိုလျှင်၊ အပြန်အလှန်ဆက်သွယ်မှုသည် ပထမအဆင့်နှင့် ဒုတိယအဆင့်နှစ်ခုစလုံး၏ ကျောရိုးများကိုဖြတ်သန်းသွားမည်ဖြစ်သည်။


သီအိုရီအရ၊ ထိုသို့သော ဗိသုကာပညာသည် အလွယ်တကူ အတိုင်းအတာတစ်ခုအထိ ချဲ့ထွင်နိုင်သည်။ အကယ်၍ ကျွန်ုပ်တို့တွင် ဆိပ်ကမ်းစွမ်းရည်၊ ဒေတာစင်တာတွင် နေရာလွတ်တစ်ခုနှင့် ကြိုတင်ချထားသော ဖိုက်ဘာတစ်ခုရှိလျှင် လေယာဉ်အရေအတွက်ကို အမြဲတမ်း တိုးလာနိုင်သည်၊ ထို့ကြောင့် စနစ်၏ အလုံးစုံစွမ်းရည်ကို တိုးမြင့်စေသည်။ စာရွက်ပေါ်မှာ ဒီလိုလုပ်ရတာ အရမ်းလွယ်တယ်။ တကယ့်လက်တွေ့ဘဝမှာလည်း ဒီလိုပါပဲ။ ဒါပေမယ့် ဒီနေ့ ဇာတ်လမ်းက အဲဒီအကြောင်း မဟုတ်ပါဘူး။


မှန်ကန်တဲ့ ကောက်ချက်ချစေချင်တယ်။ ကျွန်ုပ်တို့တွင် ဒေတာစင်တာအတွင်း လမ်းကြောင်းများစွာရှိသည်။ ၎င်းတို့သည် အခြေအနေအရ လွတ်လပ်သည်။ ဒေတာစင်တာအတွင်းရှိ နည်းလမ်းတစ်ခုသည် ToR အတွင်းသာ ဖြစ်နိုင်သည်။ မော်ဂျူးအတွင်းတွင်၊ ကျွန်ုပ်တို့တွင် လေယာဉ်အရေအတွက်နှင့် တူညီသောလမ်းကြောင်းများရှိသည်။ မော်ဂျူးများကြားရှိ လမ်းကြောင်းအရေအတွက်သည် လေယာဉ်တစ်ခုစီရှိ လေယာဉ်အရေအတွက်နှင့် superspins အရေအတွက်နှင့် ညီမျှသည်။ ပိုမိုရှင်းလင်းစေရန်၊ အတိုင်းအတာကိုခံစားရန်၊ Yandex ဒေတာစင်တာတစ်ခုအတွက် တရားဝင်သောနံပါတ်များကို ကျွန်ုပ်ပေးပါမည်။


လေယာဉ်ရှစ်စင်းရှိပြီး လေယာဉ်တစ်ခုစီတွင် စူပါစပန့် ၃၂ ခုရှိသည်။ ရလဒ်အနေဖြင့်၊ module အတွင်းတွင်လမ်းကြောင်းရှစ်ခုရှိကြောင်းနှင့် inter-module အပြန်အလှန်ဆက်သွယ်မှုနှင့်အတူ၎င်းတို့ထဲမှ 32 ခုရှိနေပြီဖြစ်သည်။

ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် Cookbook တစ်ခုကို တီထွင်နေပြီး ၎င်းတို့ကိုယ်မိမိ ကုစားနိုင်သော အမှား-ခံနိုင်ရည်ရှိသော ဒေတာစင်တာများကို မည်သို့တည်ဆောက်ရမည်ကို လေ့လာရန်ကြိုးစားနေပါက၊ Planar Architecture သည် မှန်ကန်သောရွေးချယ်မှုဖြစ်သည်။ ၎င်းသည် သင့်အား အတိုင်းအတာပြဿနာကို ဖြေရှင်းနိုင်စေပြီး သီအိုရီအရ လွယ်ကူသည်။ လွတ်လပ်တဲ့လမ်းတွေ အများကြီးရှိတယ်။ မေးခွန်းကျန်နေသေးတယ်- ဒီလိုဗိသုကာလက်ရာဟာ ကျရှုံးမှုတွေကို ဘယ်လိုရှင်သန်မလဲ။ အပျက်အစီးတွေ အမျိုးမျိုးရှိတယ်။ ပြီးတော့ ဒါကို အခုပဲ ဆွေးနွေးမယ်။


ကျွန်ုပ်တို့၏ စူပါစပန့်များထဲမှ တစ်ဦးဖျားနာပါစေ။ ဤတွင် ကျွန်တော်သည် လေယာဉ်နှစ်စင်း၏ တည်ဆောက်ပုံကို ပြန်ရောက်ခဲ့သည်။ ရွေ့လျားနေသော အစိတ်အပိုင်းများ အနည်းငယ်ဖြင့် ဤနေရာတွင် ဖြစ်ပျက်နေသည်များကို ရိုးရိုးရှင်းရှင်း သိမြင်ရန် ပိုမိုလွယ်ကူမည်ဖြစ်သောကြောင့် ၎င်းတို့ကို နမူနာအဖြစ် ကျွန်ုပ်တို့ လိုက်နာပါမည်။ X11 ဖျားပါစေ။ ၎င်းသည် ဒေတာစင်တာများအတွင်း နေထိုင်သည့် ဝန်ဆောင်မှုများကို မည်သို့အကျိုးသက်ရောက်မည်နည်း။ ရှုံးနိမ့်မှုက ဘယ်လိုမြင်လဲဆိုတဲ့အပေါ်မှာ အများကြီးမူတည်ပါတယ်။


အကယ်၍ ရှုံးနိမ့်မှုကောင်းပါက တူညီသော BFD ၏ အလိုအလျောက်စနစ်အဆင့်တွင် ဖမ်းမိနိုင်သည်၊ အလိုအလျောက်စနစ်သည် ပြဿနာအဆစ်များကို ပျော်ရွှင်စွာ ထည့်သွင်းကာ ပြဿနာကို သီးခြားခွဲထုတ်လိုက်သည်ဆိုလျှင် အရာအားလုံး အဆင်ပြေပါသည်။ ကျွန်ုပ်တို့တွင် လမ်းကြောင်းများစွာရှိသည်၊ ယာဉ်ကြောအသွားအလာကို အခြားလမ်းကြောင်းများသို့ ချက်ချင်းလမ်းကြောင်းပြောင်းသွားပြီး ဝန်ဆောင်မှုများသည် မည်သည့်အရာကိုမျှ သတိပြုမိမည်မဟုတ်ပါ။ ဒါက ကောင်းတဲ့ မြင်ကွင်းပါ။


မကောင်းတဲ့ မြင်ကွင်းတစ်ခုက ကျွန်ုပ်တို့မှာ အဆက်မပြတ် ဆုံးရှုံးမှုရှိနေရင်၊ အလိုအလျောက်စနစ်က ပြဿနာကို သတိမထားမိပါဘူး။ ၎င်းသည် အပလီကေးရှင်းအပေါ် မည်ကဲ့သို့အကျိုးသက်ရောက်သည်ကို နားလည်ရန်၊ ကျွန်ုပ်တို့သည် TCP protocol အလုပ်လုပ်ပုံကို ဆွေးနွေးရန် အချိန်အနည်းငယ်ယူရမည်ဖြစ်ပါသည်။


ဤအချက်အလက်ကြောင့် မည်သူ့ကိုမျှ ထိတ်လန့်မသွားစေရန် မျှော်လင့်ပါသည်။ TCP သည် လက်ဆွဲခြင်းပရိုတိုကောတစ်ခုဖြစ်သည်။ ဆိုလိုသည်မှာ အရိုးရှင်းဆုံးအခြေအနေတွင်၊ ပေးပို့သူသည် အထုပ်နှစ်ထုပ်ကို ပေးပို့ပြီး ၎င်းတို့အပေါ် စုစည်းထားသော အိတ်ကို လက်ခံရရှိသည်- "ကျွန်တော်သည် အထုပ်နှစ်ထုပ်ကို လက်ခံရရှိခဲ့သည်။"


အဲဒီနောက်မှာတော့ နောက်ထပ် အထုပ်နှစ်ထုပ်ကို ပို့ပေးမှာဖြစ်ပြီး အခြေအနေက ထပ်ဖြစ်မှာပါ။ ရိုးရှင်းမှုအချို့အတွက် ကြိုတင်တောင်းပန်အပ်ပါသည်။ ဝင်းဒိုး (ပျံသန်းမှုတွင် ထုပ်ပိုးအရေအတွက်) သည် နှစ်ခုဖြစ်နေပါက ဤအခြေအနေသည် မှန်ကန်ပါသည်။ ဟုတ်ပါတယ်၊ ဒါက ယေဘူယျအားဖြင့်တော့ ကိစ္စမရှိပါဘူး။ ဒါပေမယ့် packet forwarding context ကို window size နဲ့ မထိခိုက်ပါဘူး။


ပက်ကေ့ဂျ် 3 ပျောက်သွားရင် ဘာဖြစ်မလဲ။ ဤကိစ္စတွင်၊ လက်ခံသူသည် အထုပ် 1၊ 2 နှင့် 4 ကို လက်ခံရရှိမည်ဖြစ်သည်။ ထို့နောက် SACK ရွေးချယ်မှုကို အသုံးပြု၍ ပေးပို့သူအား အတိအလင်း အကြောင်းကြားပါမည်- "မင်းသိပါတယ်၊ သုံးခုရောက်လာပေမယ့် အလယ်မှာ ပျောက်သွားတယ်။" သူက "Ack 2၊ SACK 4" လို့ ပြောပါတယ်။


ဤအခိုက်အတန့်တွင် ပေးပို့သူသည် ပြဿနာမရှိဘဲ ပျောက်ဆုံးသွားသော ပက်ကေ့ခ်ျကို အတိအကျ ပြန်ဆိုသည်။


ဒါပေမယ့် window ထဲက နောက်ဆုံး packet ပျောက်သွားရင် အခြေအနေက အရမ်းကွာခြားသွားပါလိမ့်မယ်။

လက်ခံသူသည် ပထမအထုပ်သုံးထုပ်ကို လက်ခံရရှိပြီး ပထမဦးစွာစောင့်ဆိုင်းရန် စတင်သည်။ Linux kernel ၏ TCP stack တွင် ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်မှုအချို့ကြောင့်၊ ၎င်းသည် နောက်ဆုံးထုပ်ပိုးခြင်း သို့မဟုတ် ထိုကဲ့သို့သောအရာတစ်ခုဖြစ်ကြောင်း အလံများတွင် အတိအလင်းဖော်ပြခြင်းမရှိပါက တွဲထားသောပက်ကတ်ကို စောင့်ပါမည်။ Delayed ACK timeout ကုန်ဆုံးချိန်အထိ စောင့်ဆိုင်းပြီး ပထမသုံးထုပ်အတွက် အသိအမှတ်ပြုချက်ကို ပေးပို့ပါမည်။ ယခုမူကား ပေးပို့သူအား စောင့်မျှော်နေပေလိမ့်မည်။ စတုတ္ထအထုပ် ပျောက်သလား သို့မဟုတ် ရောက်ရှိလာတော့မည်ကို သူမသိဘူး။ ကွန်ရက်ကို ဝန်ပိုမချစေရန်၊ ပက်ကတ်ပျောက်ဆုံးသွားခြင်း သို့မဟုတ် RTO အချိန်ကုန်ဆုံးခြင်း၏ သက်တမ်းကုန်ဆုံးကြောင်း ပြတ်သားစွာ သက်သေပြရန် စောင့်ဆိုင်းနေမည်ဖြစ်သည်။


RTO အချိန်ကုန်ခြင်းဆိုတာဘာလဲ။ ၎င်းသည် TCP stack မှတွက်ချက်သော RTT နှင့် အချို့သော ကိန်းသေများမှ အများဆုံးဖြစ်သည်။ ဒီကိန်းသေကဘာလဲ၊ အခု ဆွေးနွေးမယ်။


ဒါပေမယ့် ထပ်ပြီးကံမကောင်းလို့ စတုတ္ထ packet ပျောက်သွားရင် RTO က နှစ်ဆတိုးလာဖို့ အရေးကြီးတယ်။ ဆိုလိုသည်မှာ မအောင်မြင်သောကြိုးပမ်းမှုတိုင်းသည် အချိန်ကုန်ခြင်း၏ နှစ်ဆဖြစ်သည်။


အခု ဒီအခြေခံက ဘာနဲ့ညီလဲ ကြည့်ရအောင်။ ပုံမှန်အားဖြင့်၊ အနည်းဆုံး RTO သည် 200ms ဖြစ်သည်။ ဤသည်မှာ ဒေတာပက်ကတ်များအတွက် အနည်းဆုံး RTO ဖြစ်သည်။ SYN ပက်ကတ်များအတွက် 1 စက္ကန့်ကွာခြားသည်။ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ပက်ကေ့ခ်ျများပြန်လည်ပေးပို့ရန် ပထမဆုံးကြိုးပမ်းမှုသည် ဒေတာစင်တာအတွင်းရှိ RTT ထက် အဆ 100 ပိုကြာမည်ဖြစ်သည်။


ယခု ကျွန်ုပ်တို့၏ အခြေအနေသို့ ပြန်သွားရန်။ ဝန်ဆောင်မှုမှာ ဘာဖြစ်နေတာလဲ။ ဝန်ဆောင်မှုသည် အထုပ်များကို ဆုံးရှုံးသွားတော့သည်။ ဝန်ဆောင်မှုကို အစပိုင်းတွင် ကံကောင်းစေပြီး ပြတင်းပေါက်အလယ်တွင် တစ်စုံတစ်ခု ဆုံးရှုံးပါစေ၊ ထို့နောက် ၎င်းသည် SACK ရရှိပြီး ပျောက်ဆုံးသွားသော ပက်ကေ့ခ်ျများကို ပြန်လည်ပေးပို့ပါ။


ဒါပေမယ့် ကံဆိုးမှုတွေ ထပ်ဖြစ်ရင်၊ ငါတို့မှာ RTO ရှိတယ်။ ဒီနေရာမှာ အရေးကြီးတာက ဘာလဲ။ ဟုတ်တယ်၊ ငါတို့မှာ ကွန်ရက်ထဲမှာ လမ်းကြောင်းတွေအများကြီးရှိတယ်။ သို့သော် TCP ချိတ်ဆက်မှုတစ်ခု၏ TCP အသွားအလာသည် တူညီသောကျိုးပဲ့နေသော stack ကို ဆက်လက်ဖြတ်သန်းသွားမည်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ မှော်ပညာ X11 သည် သူ့ဘာသာသူ မထွက်သောကြောင့် ပက်ကေ့ချ်ဆုံးရှုံးမှုသည် ပြဿနာမရှိသော နေရာများသို့ စီးဆင်းသွားစေရန် မဖြစ်ပေါ်စေပါ။ တူညီသောကျိုးပဲ့နေသော stack မှတဆင့် packet တစ်ခုကို ပေးပို့ရန် ကြိုးစားနေပါသည်။ ၎င်းသည် cascading ချို့ယွင်းမှုကိုဖြစ်ပေါ်စေသည်- ဒေတာစင်တာသည် အပြန်အလှန်အကျိုးပြုသည့်အက်ပ်လီကေးရှင်းအစုတစ်ခုဖြစ်ပြီး၊ ဤအပလီကေးရှင်းအားလုံး၏ TCP ချိတ်ဆက်မှုအချို့သည် စတင်ကျဆင်းသွားသည် - အဘယ်ကြောင့်ဆိုသော် superspin သည် data center အတွင်းရှိ application အားလုံးကိုအကျိုးသက်ရောက်သောကြောင့်ဖြစ်သည်။ မြင်းမစီးရင် မြင်းက ထော့နဲ့ထော့နဲ့၊ မြင်းတွေ ထော့နဲ့ ထော့နဲ့ - အစီရင်ခံစာ မပို့ဘူး။ မက်ဆေ့ချ်မပို့ဘူး - သူတို့ စစ်ရှုံးတယ်။ ဤနေရာ၌သာ ဝန်ဆောင်မှုများ စတင်ခံစားရသည့် ပြဿနာသည် ပျက်စီးခြင်းအဆင့်အထိ စက္ကန့်ပိုင်းမျှသာ ဖြစ်သည် ။ ဆိုလိုသည်မှာ အသုံးပြုသူများသည် တစ်နေရာရာတွင် တစ်စုံတစ်ရာကို ရရှိမည်မဟုတ်ကြောင်း ဆိုလိုသည်။


တစ်ခုနှင့်တစ်ခု အားဖြည့်ပေးသော ဂန္တဝင်ဖြေရှင်းနည်း နှစ်ခုရှိသည်။ ပထမအချက်မှာ ကောက်ရိုးများကိုချထားပြီး ဤကဲ့သို့သောပြဿနာကိုဖြေရှင်းရန် ကြိုးစားနေသည့်ဝန်ဆောင်မှုများဖြစ်သည်- “TCP stack မှာ တစ်ခုခုကို ညှိကြည့်ရအောင်။ ထို့အပြင် အတွင်းပိုင်းကျန်းမာရေးစစ်ဆေးမှုများနှင့်အတူ အက်ပ်အဆင့်အချိန်ကုန်သွားခြင်း သို့မဟုတ် ကြာရှည်သော TCP ဆက်ရှင်များကို ပြုလုပ်ကြပါစို့။ ပြဿနာမှာ ထိုသို့သော ဖြေရှင်းနည်းများ ဖြစ်သည်- က) အတိုင်းအတာ လုံးဝ မလုပ်ပါနှင့်။ ခ) အလွန်ညံ့ဖျင်းသောစမ်းသပ်မှု။ ဆိုလိုသည်မှာ၊ ဝန်ဆောင်မှုသည် TCP stack ကို မတော်တဆ configure လုပ်လိုက်လျှင်ပင်၊ ပထမဦးစွာ၊ ၎င်းသည် အပလီကေးရှင်းအားလုံးနှင့် ဒေတာစင်တာအားလုံးနှင့် သက်ဆိုင်နိုင်ဖွယ်မရှိသလို၊ ဒုတိယအနေနှင့်၊ ဖြစ်နိုင်ချေများသည်မှာ၊ ၎င်းသည် အဘယ်အရာလုပ်ဆောင်ခဲ့သည်ကို မှန်ကန်စွာ နားလည်မည်မဟုတ်ပါ။ မဟုတ်ဘူး ဆိုလိုသည်မှာ ၎င်းသည် အလုပ်လုပ်သော်လည်း ညံ့ဖျင်းပြီး အတိုင်းအတာမရှိပေ။ ကွန်ရက်ပြဿနာရှိလျှင် မည်သူကို အပြစ်တင်ရမည်နည်း။ ဟုတ်ပါတယ် NOC ။ NOC ဘာလုပ်သလဲ။

ဝန်ဆောင်မှုများစွာသည် NOC တွင် အလုပ်သည် ဤကဲ့သို့ဖြစ်မည်ဟု ယုံကြည်ကြသည်။ ဒါပေမယ့် ရိုးရိုးသားသားပြောရရင်တော့ မဟုတ်ဘူး။


ဂန္ထဝင်အစီအစဥ်တွင် NOC သည် များစွာသောစောင့်ကြည့်မှုဖွံ့ဖြိုးတိုးတက်ရေးတွင် ပါဝင်နေသည်။ ၎င်းတို့သည် black box စောင့်ကြည့်ခြင်း နှင့် white box monitoring နှစ်မျိုးလုံးဖြစ်သည်။ ကျောရိုး၏ black box-စောင့်ကြည့်ခြင်း၏ဥပမာအကြောင်း ပြောတယ်။ Alexander Klimenko သည် အတိတ် Next Hop စကားမစပ်၊ ဤစောင့်ကြည့်မှုအလုပ်လုပ်သည်။ ဒါပေမယ့် ပြီးပြည့်စုံတဲ့ စောင့်ကြည့်မှုတောင်မှ အချိန်နောက်ကျနေလိမ့်မယ်။ များသောအားဖြင့် မိနစ်များစွာကြာတတ်သည်။ ၎င်းအလုပ်လုပ်ပြီးနောက်၊ တာဝန်ကျအင်ဂျင်နီယာများသည် ၎င်း၏လုပ်ငန်းဆောင်ရွက်မှုကို နှစ်ဆစစ်ဆေးရန်၊ ပြဿနာကို ဒေသစံညွှန်းသတ်မှတ်ပြီးနောက် ပြဿနာဧရိယာကို ငြိမ်းသတ်ရန် အချိန်လိုအပ်သည်။ ဆိုလိုသည်မှာ၊ အကောင်းဆုံးအခြေအနေတွင်၊ ဆုံးရှုံးမှုကိုချက်ချင်းမသိသာပါက၊ အဆိုးဆုံးမိနစ် 5 တွင်ပြဿနာ၏ကုသမှုသည် 20 မိနစ်ကြာသည်။ ဤအချိန် - 5 မိနစ် သို့မဟုတ် 20 မိနစ် - ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများ ဆက်လက်ထိခိုက်နေမည်မှာ ရှင်းနေသည်မှာ မကောင်းနိုင်ပါ။


ဘာကို ခံယူချင်လဲ။ ငါတို့မှာ လမ်းတွေအများကြီးရှိတယ်။ ကံမကောင်းသည့် TCP စီးဆင်းမှုများသည် တူညီသောလမ်းကြောင်းကို ဆက်လက်အသုံးပြုနေသောကြောင့် ပြဿနာများ တိကျစွာဖြစ်ပေါ်လာပါသည်။ ကျွန်ုပ်တို့သည် TCP ချိတ်ဆက်မှုတစ်ခုအတွင်း လမ်းကြောင်းများစွာကို သုံးနိုင်စေမည့် အရာတစ်ခု လိုအပ်ပါသည်။ ကျွန်တော်တို့မှာ အဖြေတစ်ခုရှိပုံရတယ်။ လမ်းကြောင်းများစွာအတွက် TCP ဟုခေါ်သော multipath TCP၊ ဆိုလိုသည်မှာ TCP ရှိသည်။ မှန်ပါသည်၊ ၎င်းကို ကွန်ရက်ကိရိယာများစွာရှိသည့် စမတ်ဖုန်းများအတွက် လုံးဝကွဲပြားခြားနားသောအလုပ်အတွက် တီထွင်ခဲ့ခြင်းဖြစ်သည်။ လွှဲပြောင်းမှုကို တိုးမြှင့်ရန် သို့မဟုတ် ပင်မ/အရန်မုဒ်ကို ပြုလုပ်ရန်၊ အပလီကေးရှင်းအတွက် စာတွဲများ (ဆက်ရှင်များ) အများအပြားကို ပွင့်လင်းမြင်သာစွာ ဖန်တီးပေးပြီး ချို့ယွင်းချက်ရှိပါက ၎င်းတို့ကြားတွင် ပြောင်းနိုင်စေမည့် ယန္တရားတစ်ခုကို တီထွင်ခဲ့သည်။ ဒါမှမဟုတ် ကျွန်တော်ပြောခဲ့သလိုပဲ bandwidth ကို ချဲ့လိုက်ပါ။

ဒါပေမယ့် ဒီနေရာမှာ ကွဲလွဲချက်တစ်ခုရှိတယ်။ အဲဒါက ဘာလဲဆိုတာ နားလည်ဖို့၊ stream တွေကို ဘယ်လိုသတ်မှတ်မလဲဆိုတာကို ကြည့်ရပါလိမ့်မယ်။


Threads များကို ဆင့်ကဲသတ်မှတ်ထားပါသည်။ ပထမဆုံး stream ကို အရင် install လုပ်ပါ။ နောက်ဆက်တွဲ စီးဆင်းမှုများကို ထိုတွဲအတွင်း သဘောတူထားပြီးဖြစ်သော ကွတ်ကီးကို အသုံးပြု၍ သတ်မှတ်ပေးပါသည်။ ပြီးတော့ ဒီမှာ ပြဿနာရှိတယ်။


ပြဿနာမှာ ပထမ thread ကို မတပ်ဆင်ပါက ဒုတိယနှင့် တတိယ thread များ ပေါ်လာမည်မဟုတ်ပါ။ ဆိုလိုသည်မှာ၊ multipath TCP သည် ပထမ stream တွင် SYN packet ဆုံးရှုံးမှုကို မဖြေရှင်းနိုင်ပါ။ SYN ပျောက်ဆုံးပါက multipath TCP သည် ပုံမှန် TCP ဖြစ်လာသည်။ ထို့ကြောင့်၊ ဒေတာစင်တာပတ်ဝန်းကျင်တွင်၊ ၎င်းသည် စက်ရုံရှိ ဆုံးရှုံးမှုပြဿနာကို ဖြေရှင်းရန်နှင့် ချို့ယွင်းမှုဖြစ်သည့်အခါ လမ်းကြောင်းများစွာကို အသုံးပြုနည်းကို လေ့လာရန် ကူညီပေးမည်မဟုတ်ပါ။


ကျွန်ုပ်တို့ကို ဘာကူညီပေးနိုင်မလဲ။ ကျွန်ုပ်တို့၏နောက်ထပ်ဇာတ်လမ်းတွင် အရေးကြီးသောအကွက်သည် IPv6 စီးဆင်းမှုအညွှန်းခေါင်းစဉ်အကွက်ဖြစ်မည်ကို သင်အချို့က ခန့်မှန်းထားပြီးဖြစ်သည်။ အမှန်စင်စစ်၊ ၎င်းသည် v6 တွင်ပေါ်လာသည့်အကွက်တစ်ခုဖြစ်ပြီး ၎င်းသည် v4 တွင်မဟုတ်ပါ၊ ၎င်းသည် 20 bits ကြာမြင့်ပြီး ၎င်း၏အသုံးပြုမှုနှင့်ပတ်သက်ပြီး အငြင်းပွားမှုများရှိနေသည်မှာ ကြာပါပြီ။ ဤအရာသည် အလွန်စိတ်ဝင်စားစရာကောင်းသည် - အငြင်းပွားမှုများရှိခဲ့သည်၊ RFC ၏ဘောင်အတွင်းတွင် တစ်စုံတစ်ခုကို ပြင်ဆင်ပြီး တစ်ချိန်တည်းတွင် မည်သည့်နေရာမှ မှတ်တမ်းတင်ထားခြင်းမရှိသော Linux kernel တွင် အကောင်အထည်ပေါ်လာပါသည်။


စုံစမ်းမှုအနည်းငယ်တွင် ကျွန်ုပ်နှင့်ပူးပေါင်းပါရန် အကြံပြုအပ်ပါသည်။ ပြီးခဲ့သောနှစ်အနည်းငယ်အတွင်း Linux kernel တွင်ဖြစ်ပျက်နေသည်များကိုကြည့်ကြပါစို့။

၂၀၁၄ ခုနှစ်။ ကြီးမားပြီး ဂုဏ်သိက္ခာရှိသော ကုမ္ပဏီတစ်ခုမှ အင်ဂျင်နီယာတစ်ဦးသည် socket ၏ hash ပေါ်တွင် flow label ၏တန်ဖိုးအပေါ်မှီခိုမှုကို Linux kernel ၏လုပ်ဆောင်နိုင်စွမ်းကို ထပ်လောင်းပေးသည်။ ဒီမှာဘာတွေပြင်ဖို့ကြိုးစားနေကြတာလဲ။ ၎င်းသည် အောက်ပါပြဿနာကို ဆွေးနွေးခဲ့သည့် RFC 2014 နှင့် သက်ဆိုင်သည်။ ဒေတာစင်တာအတွင်းတွင်၊ IPv6438 ကို စက်ရုံကိုယ်တိုင်က IPv4 ဖြစ်သောကြောင့် IPv6 ကို မကြာခဏ IPv6 ပက်ကတ်များတွင် ဖုံးအုပ်ထားသော်လည်း IPv4 ကို တစ်နည်းနည်းဖြင့် ထုတ်ပေးရပါမည်။ TCP သို့မဟုတ် UDP သို့ရောက်ရှိရန်နှင့် src_ports၊ dst_ports များကိုရှာဖွေရန် IP headers နှစ်ခုအောက်တွင် မတွေ့နိုင်သော ခလုတ်များနှင့် ပြဿနာများရှိနေသည်မှာ ကြာပါပြီ။ ပထမ IP ခေါင်းစီးနှစ်ခုကိုကြည့်လျှင် hash သည် ပြုပြင်လုနီးပါးဖြစ်သွားသည်ကို တွေ့ရပါသည်။ ၎င်းကိုရှောင်ရှားရန်၊ ဤ encapsulated traffic ၏ဟန်ချက်ညီမှုကိုမှန်ကန်စွာအလုပ်လုပ်စေရန်၊ 5-tuple encapsulated packet မှ hash တစ်ခုကို flow label အကွက်၏တန်ဖိုးသို့ထည့်သွင်းရန်အဆိုပြုခဲ့သည်။ UDP အတွက်၊ GRE အတွက်၊ အခြား encapsulation schemes များအတွက်၊ နောက်ပိုင်းတွင် GRE Key အကွက်ကို အသုံးပြုခဲ့သည်။ တစ်နည်းမဟုတ် တစ်နည်းအားဖြင့် ဤနေရာ၌ ပန်းတိုင်များသည် ရှင်းပါသည်။ အနည်းဆုံးတော့ အဲဒီအချိန်မှာ သူတို့က အသုံးဝင်တယ်။

2015 ခုနှစ်တွင်၊ တူညီသောလေးစားရသောအင်ဂျင်နီယာထံမှ Patch အသစ်တစ်ခုထွက်ပေါ်လာသည်။ သူက အရမ်းစိတ်ဝင်စားဖို့ကောင်းတယ်။ ၎င်းတွင် အောက်ပါအတိုင်းဖော်ပြထားသည် - အနုတ်လက္ခဏာလမ်းကြောင်းပြခြင်းဖြစ်ရပ်တစ်ခုအတွက် hash ကို ကျပန်းလုပ်ဆောင်ပါမည်။ အနုတ်လက္ခဏာလမ်းကြောင်းပြခြင်းဖြစ်ရပ်ကဘာလဲ။ ဤသည်မှာ စောစောက ဆွေးနွေးခဲ့သော RTO ဖြစ်ပြီး၊ ဆိုလိုသည်မှာ ပြတင်းပေါက်အမြီး ဆုံးရှုံးမှုသည် အမှန်တကယ် အပျက်သဘောဆောင်သည့် ဖြစ်ရပ်တစ်ခုဖြစ်သည်။ မှန်ပါတယ်၊ အဲဒါဘာလဲဆိုတာ ခန့်မှန်းရခက်ပါတယ်။

2016 တွင် အခြားသော လေးစားဖွယ် ကုမ္ပဏီကြီးတစ်ခုလည်း ဖြစ်သည်။ ၎င်းသည် နောက်ဆုံးချိုင်းထောက်များကို ခွဲခြမ်းစိပ်ဖြာပြီး ယခင်က ကျပန်းပြုလုပ်ထားသော hash ကို SYN ပြန်လည်ပေးပို့မှုတိုင်းနှင့် RTO အချိန်ကုန်တိုင်းပြီးနောက်တွင် ပြောင်းလဲသွားစေရန် ပြုလုပ်ပေးပါသည်။ ဤစာ၌၊ ပထမနှင့် နောက်ဆုံးအကြိမ်အတွက်၊ အန္တိမပန်းတိုင်သည် - လမ်းကြောင်းများစွာကို အသုံးပြု၍ လမ်းကြောင်းများ ဆုံးရှုံးခြင်း သို့မဟုတ် ဝန်ပိုခြင်းတွင် အသွားအလာများကြောင်း သေချာစေရန်အတွက် လမ်းကြောင်းများစွာကို ပျော့ပျောင်းစွာ လမ်းကြောင်းပြောင်းခြင်း ဖြစ်နိုင်ခြေရှိကြောင်း သေချာစေရန်။ ဟုတ်ပါတယ်၊ အဲဒီနောက်မှာ စာပေတွေ အများကြီးရှိတော့ အဲဒါတွေကို အလွယ်တကူ ရှာတွေ့နိုင်တယ်။

မဟုတ်သော်လည်း၊ ဤအကြောင်းအရာနှင့်ပတ်သက်ပြီး ထုတ်ဝေမှုတစ်ခုမျှမရှိသေးသောကြောင့် သင်မဖြစ်နိုင်ပါ။ ဒါပေမယ့် ငါတို့သိတယ်!

ပြီးခဲ့တာတွေကို နားမလည်ရင် အခုပြောပြမယ်။


ဘာတွေလုပ်ဆောင်ပြီးပြီလဲ၊ ဘယ်လုပ်ဆောင်ချက်တွေကို Linux kernel မှာ ထည့်ထားလဲ။ RTO ဖြစ်ရပ်တစ်ခုစီပြီးနောက် ကျပန်းတန်ဖိုးသို့ ပြောင်းလဲသွားသည်။ ဤသည်မှာ တူညီသော အနုတ်လက္ခဏာလမ်းကြောင်း ရလဒ်ဖြစ်သည်။ hash သည် ဤ aussh ပေါ်တွင်မူတည်ပြီး flow label သည် skb hash ပေါ်တွင်မူတည်သည်။ ဤနေရာတွင် လုပ်ဆောင်ချက်များနှင့်ပတ်သက်၍ တွက်ချက်မှုအချို့ရှိပြီး၊ အသေးစိတ်အားလုံးကို ဆလိုက်တစ်ခုတည်းတွင် ထည့်၍မရပါ။ မည်သူမဆို သိချင်ပါက၊ သင်သည် kernel ကုဒ်ကိုဖြတ်၍ စစ်ဆေးနိုင်ပါသည်။

ဒီနေရာမှာ အရေးကြီးတာက ဘာလဲ။ စီးဆင်းမှုတံဆိပ်အကွက်၏တန်ဖိုးသည် RTO တစ်ခုစီပြီးနောက် ကျပန်းနံပါတ်တစ်ခုသို့ ပြောင်းသည်။ ၎င်းသည် ကျွန်ုပ်တို့၏ ကံမကောင်းသော TCP ထုတ်လွှင့်မှုကို မည်သို့အကျိုးသက်ရောက်သနည်း။


SACK ကိစ္စတွင်၊ ကျွန်ုပ်တို့ သိရှိထားသော ပျောက်ဆုံးသွားသော ပက်ကေ့ခ်ျကို ပြန်လည်ပေးပို့ရန် ကြိုးစားနေသောကြောင့် ဘာမှမပြောင်းလဲပါ။ ယခုအထိတော့အဆင်ပြေတုန်းပဲ။


သို့သော် RTO ၏အခြေအနေတွင်၊ ToR ရှိ hash လုပ်ဆောင်ချက်တွင် စီးဆင်းမှုအညွှန်းတစ်ခုကို ကျွန်ုပ်တို့ထည့်သွင်းထားသောကြောင့်၊ ယာဉ်အသွားအလာသည် အခြားလမ်းကြောင်းတစ်ခုသို့ သွားနိုင်သည်။ လေယာဉ်တွေများလေလေ၊ စက်ပစ္စည်းတခုခုမှာ ပျက်ကျလို့ မထိခိုက်နိုင်တဲ့ လမ်းကြောင်းကို ရှာဖို့ အလားအလာ ပိုများလေပါပဲ။


ပြဿနာတစ်ခုကျန်သေးတယ် - RTO။ အခြားလမ်းကြောင်းကိုတွေ့သော်လည်း အချိန်များစွာကုန်သည်။ 200ms က အများကြီးပါ။ ဒုတိယတစ်ခုသည် ယေဘူယျအားဖြင့် တောရိုင်းဖြစ်သည်။ အစောပိုင်းက ဝန်ဆောင်မှုများကို စီစဉ်သတ်မှတ်ပေးသည့် အချိန်ကုန်သွားခြင်းအကြောင်း ပြောခဲ့သည်။ ထို့ကြောင့်၊ တစ်စက္ကန့်သည် အပလီကေးရှင်းအဆင့်တွင် ဝန်ဆောင်မှုတစ်ခုအား ပုံမှန်သတ်မှတ်ပေးသည့် အချိန်ကုန်သွားကာ ဤဝန်ဆောင်မှုသည် အတော်လေးပင် မှန်ကန်ပါလိမ့်မည်။ ထို့အပြင်၊ ခေတ်မီဒေတာစင်တာတစ်ခုအတွင်းရှိ အစစ်အမှန် RTT သည် 1 မီလီစက္ကန့်ဝန်းကျင်ဖြစ်သည်။


RTO အချိန်ကုန်ခြင်းနှင့်ပတ်သက်၍ မည်သို့လုပ်ဆောင်နိုင်သနည်း။ ဒေတာပက်ကေ့များ ဆုံးရှုံးသွားသောအခါတွင် RTO အတွက် တာဝန်ရှိသော အချိန်ကုန်ဆုံးချိန်ကို အသုံးပြုသူနေရာမှ အတော်လေး လွယ်ကူစွာ ပြင်ဆင်သတ်မှတ်နိုင်သည်- IP အသုံးဝင်မှုတစ်ခု ရှိပြီး ၎င်း၏ ကန့်သတ်ချက်များထဲမှ တစ်ခုသည် တူညီသော rto_min ပါရှိသည်။ ၎င်းကိုထည့်သွင်းစဉ်းစားခြင်းဖြင့်၊ သင်သည် RTO ကို တစ်ကမ္ဘာလုံးသို့ ပြောင်းလဲရန် လိုအပ်သော်လည်း ပေးထားသော ရှေ့ဆက်များအတွက်၊ ထိုကဲ့သို့သော ယန္တရားသည် အလုပ်ဖြစ်ပုံရသည်။


မှန်ပါသည်၊ SYN_RTO ဖြင့် အရာအားလုံးသည် အနည်းငယ်ဆိုးရွားသည်။ သဘာဝအတိုင်း ထုဆစ်ထားသည်။ တန်ဖိုးကို core - 1 စက္ကန့်တွင် ပုံသေသတ်မှတ်ထားသည်၊ ဒါပါပဲ။ အသုံးပြုသူနေရာမှ သင်မရောက်ရှိနိုင်ပါ။ နည်းလမ်းတစ်ခုပဲရှိတယ်။


eBPF သည် ကယ်တင်ခြင်းသို့ ရောက်ပါသည်။ ရိုးရိုးရှင်းရှင်းပြောရလျှင် ၎င်းတို့သည် C ပရိုဂရမ်ငယ်များဖြစ်သည်။ ၎င်းတို့ကို kernel stack နှင့် TCP stack ၏လုပ်ဆောင်မှုတွင် မတူညီသောနေရာများတွင် ချိတ်များထည့်သွင်းနိုင်ပြီး ဆက်တင်အများအပြားကို သင်ပြောင်းလဲနိုင်သည်။ ယေဘုယျအားဖြင့် eBPF သည် ရေရှည်လမ်းကြောင်းတစ်ခုဖြစ်သည်။ sysctl ဘောင်အသစ်များစွာကို မြင်ပြီး IP utility ကိုချဲ့ထွင်မည့်အစား၊ လှုပ်ရှားမှုသည် eBPF ၏ ဦးတည်ချက်ဖြစ်ပြီး ၎င်း၏လုပ်ဆောင်နိုင်စွမ်းကို ချဲ့ထွင်သည်။ eBPF ဖြင့်၊ သင်သည် ပိတ်ဆို့နေသော ထိန်းချုပ်မှုများနှင့် အခြား TCP ဆက်တင်များကို ပြောင်းလဲနိုင်သည်။


သို့သော် ၎င်း၏အကူအညီဖြင့် SYN_RTO ၏တန်ဖိုးများကို လှည့်စားနိုင်သည်မှာ ကျွန်ုပ်တို့အတွက် အရေးကြီးပါသည်။ လူသိရှင်ကြား တင်ထားသော ဥပမာတစ်ခု ရှိပါသည်။ https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. ဒီမှာဘာလုပ်တာလဲ။ ဥပမာက အလုပ်ဖြစ်ပေမဲ့ နဲ့တော့ အရမ်းကြမ်းတယ်။ ဒေတာစင်တာအတွင်း၌ ကျွန်ုပ်တို့သည် ပထမ 44 bits များကို နှိုင်းယှဉ်ပါက ၎င်းတို့နှင့် ကိုက်ညီပါက DC အတွင်း၌ ကျွန်ုပ်တို့ကိုယ်ကို တွေ့ရှိသည်ဟု ယူဆပါသည်။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် SYN_RTO အချိန်လွန်တန်ဖိုးကို 4ms သို့ပြောင်းသည်။ တူညီသောတာဝန်ကို ပို၍ သာယာစွာ လုပ်ဆောင်နိုင်သည်။ သို့သော် ဤရိုးရှင်းသော ဥပမာသည် က) ဖြစ်နိုင်ချေကို ပြသည်၊ b) အတော်လေးလွယ်ကူပါတယ်။

ငါတို့ဘာသိနေပြီလဲ? Planar Architecture သည် အတိုင်းအတာကို ချဲ့ထွင်နိုင်သောကြောင့် ToR ပေါ်ရှိ flow label ကိုဖွင့်ပြီး ပြဿနာရှိသောနေရာများတစ်ဝိုက်သို့ စီးဆင်းရန်အခွင့်အရေးရရှိသောအခါတွင် ကျွန်ုပ်တို့အတွက် အလွန်အသုံးဝင်ပါသည်။ RTO နှင့် SYN-RTO တန်ဖိုးများကို လျှော့ချရန် အကောင်းဆုံးနည်းလမ်းမှာ eBPF ပရိုဂရမ်များကို အသုံးပြုခြင်းဖြစ်သည်။ မေးစရာကျန်သည်- ဟန်ချက်ညီရန်အတွက် flow label ကိုအသုံးပြုခြင်းသည် ဘေးကင်းပါသလား။ ပြီးတော့ ဒီနေရာမှာ ထူးခြားချက်တစ်ခုရှိတယ်။


သင့်တွင် anycast တွင်နေထိုင်သော ကွန်ရက်ပေါ်တွင် ဝန်ဆောင်မှုတစ်ခုရှိသည်ဆိုပါစို့။ ကံမကောင်းစွာဖြင့်၊ ကျွန်ုပ်တွင် anycast အကြောင်းအသေးစိတ်ဖော်ပြရန် အချိန်မရှိသော်လည်း၊ မတူညီသောရုပ်ပိုင်းဆိုင်ရာဆာဗာများကို တူညီသော IP လိပ်စာတွင်ရရှိနိုင်သည့် ဖြန့်ဝေသည့်ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ ဤနေရာတွင် ဖြစ်နိုင်ချေရှိသော ပြဿနာတစ်ခုဖြစ်ပါသည်- RTO ဖြစ်ရပ်သည် စက်ရုံကိုဖြတ်သန်းသွားသည့်အခါတွင်သာ ဖြစ်ပွားနိုင်သည်။ ၎င်းသည် ToR ကြားခံအဆင့်တွင်လည်း ဖြစ်ပွားနိုင်သည်- incast ဖြစ်ရပ်တစ်ခု ဖြစ်ပေါ်လာသောအခါ၊ host တစ်ခုခု ဖိတ်စင်သွားသောအခါတွင်ပင် ၎င်းသည် host ပေါ်တွင်ပင် ဖြစ်ပေါ်နိုင်သည်။ RTO ဖြစ်ရပ်တစ်ခု ဖြစ်ပေါ်လာသည့်အခါ ၎င်းသည် flow label ကို ပြောင်းလဲသည်။ ဤကိစ္စတွင်၊ ယာဉ်အသွားအလာသည် အခြားအရာတစ်ခုခုသို့ ရောက်သွားနိုင်သည်။ ၎င်းသည် stateful anycast တစ်ခုဖြစ်သည်ဆိုပါစို့၊ ၎င်းတွင်ချိတ်ဆက်မှုအခြေအနေတစ်ခုပါရှိသည် - ၎င်းသည် L3 Balancer သို့မဟုတ်အခြားဝန်ဆောင်မှုအချို့ဖြစ်နိုင်သည်။ RTO ပြီးနောက် TCP ချိတ်ဆက်မှုသည် ဤ TCP ချိတ်ဆက်မှုအကြောင်း ဘာမျှမသိသော ဆာဗာသို့ရောက်ရှိသောကြောင့် ပြဿနာတစ်ခုဖြစ်ပေါ်လာပါသည်။ အကယ်၍ ကျွန်ုပ်တို့တွင် မည်သည့်ကာစ်ဆာဗာများကြားတွင် ပြည်နယ်ခွဲဝေမှုမရှိပါက၊ ထိုသို့သော အသွားအလာ ကျဆင်းသွားမည်ဖြစ်ပြီး TCP ချိတ်ဆက်မှု ပျက်သွားမည်ဖြစ်သည်။


ဤနေရာတွင် ဘာလုပ်နိုင်သနည်း။ flow label ချိန်ခွင်လျှာကို သင်ဖွင့်ထားသည့် သင်၏ထိန်းချုပ်ထားသောပတ်ဝန်းကျင်အတွင်း၊ anycast ဆာဗာများကိုဝင်ရောက်သည့်အခါ flow label ၏တန်ဖိုးကို သင်ပြုပြင်ရန်လိုအပ်သည်။ အလွယ်ဆုံးနည်းလမ်းမှာ eBPF ပရိုဂရမ်တစ်ခုတည်းဖြင့် ပြုလုပ်ခြင်းဖြစ်သည်။ သို့သော် ဤနေရာတွင် အလွန်အရေးကြီးသော အချက်မှာ - သင်သည် ဒေတာစင်တာ ကွန်ရက်ကို မလည်ပတ်ဘဲ တယ်လီကွန်းအော်ပရေတာ ဖြစ်နေပါက ဘာလုပ်ရမည်နည်း။ ဒါကလည်း မင်းရဲ့ပြဿနာပါပဲ- Juniper နှင့် Arista ဗားရှင်းအချို့မှစတင်ကာ ၎င်းတို့သည် မူရင်းသတ်မှတ်ချက်အတိုင်း hash function တွင် flow label ကို ထည့်သွင်းထားသည် - ရိုးရိုးသားသားပြောရလျှင် ကျွန်ုပ်နားလည်သည့်အကြောင်းမရှိဘဲ။ ၎င်းသည် သင့်ကွန်ရက်မှတစ်ဆင့် အသုံးပြုသူများထံမှ TCP ချိတ်ဆက်မှုများကို ရပ်တန့်သွားစေနိုင်သည်။ ထို့ကြောင့်၊ ဤတည်နေရာတွင် သင်၏ router ဆက်တင်များကို စစ်ဆေးကြည့်ရန် အထူးအကြံပြုလိုပါသည်။

တစ်နည်းမဟုတ်တစ်နည်း၊ ကျွန်ုပ်တို့သည် စမ်းသပ်မှုများဆီသို့ ဆက်လက်သွားရန် အဆင်သင့်ဖြစ်နေပြီဟု ယူဆပါသည်။


ကျွန်ုပ်တို့သည် ToR ပေါ်ရှိ စီးဆင်းမှုတံဆိပ်ကိုဖွင့်လိုက်သောအခါ၊ ယခု host များပေါ်တွင်နေထိုင်သည့် အေးဂျင့်၏ eBPF ကိုပြင်ဆင်သောအခါ၊ နောက်တစ်ကြိမ် ကြီးမားသောကျရှုံးမှုကို မစောင့်ဘဲ ထိန်းချုပ်ထားသော ပေါက်ကွဲမှုများကို လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်။ အချိတ်အဆက်လေးခုပါရှိသော ToR ကိုယူကာ ၎င်းတို့အနက်မှတစ်ခုအပေါ်တွင် အစက်ချခဲ့သည်။ သူတို့က စည်းကမ်းဆွဲတယ်၊ အခု မင်း packet အားလုံးကို ဆုံးရှုံးသွားပြီလို့ပြောတယ်။ ဘယ်ဘက်တွင် သင်တွေ့မြင်ရသည့်အတိုင်း၊ ကျွန်ုပ်တို့တွင် 75% အထိ ကျဆင်းသွားသည့် packet တစ်ခုလျှင် စောင့်ကြည့်ခြင်း ရှိသည်၊ ဆိုလိုသည်မှာ packet များ၏ 25% ဆုံးရှုံးသွားပါသည်။ ညာဘက်တွင် ဤ ToR ၏ နောက်ကွယ်တွင် နေထိုင်သည့် ဝန်ဆောင်မှုများ၏ ဂရပ်များဖြစ်သည်။ တကယ်တော့၊ ဒါတွေဟာ rack အတွင်းမှာရှိတဲ့ ဆာဗာတွေနဲ့ အဆစ်တွေရဲ့ အသွားအလာဂရပ်ဖစ်တွေပါ။ မင်းမြင်တဲ့အတိုင်းပဲ သူတို့က နိမ့်ကျသွားတယ်။ အဘယ်ကြောင့် ၎င်းတို့သည် 25% မနိမ့်ကျဘဲ အချို့ကိစ္စများတွင် 3-4 ကြိမ် နိမ့်ကျနေသနည်း။ TCP ချိတ်ဆက်မှုကံမကောင်းပါက၊ ကျိုးပဲ့နေသောအင်တာဖေ့စ်မှတဆင့်ရောက်ရှိရန်ဆက်လက်ကြိုးစားနေပါသည်။ ၎င်းသည် DC အတွင်းရှိ ဝန်ဆောင်မှု၏ ပုံမှန်အပြုအမူဖြင့် ပိုမိုဆိုးရွားသွားသည် - အသုံးပြုသူတောင်းဆိုချက်တစ်ခုအတွက်၊ အတွင်းပိုင်းဝန်ဆောင်မှုများသို့ N တောင်းဆိုမှုများကို ထုတ်ပေးပြီး ဒေတာအရင်းအမြစ်များအားလုံးတုံ့ပြန်သည့်အခါ သို့မဟုတ် အချိန်ကုန်သွားသည့်အခါတွင် တုံ့ပြန်မှုသည် သုံးစွဲသူထံရောက်သွားမည်ဖြစ်သည်။ ပြင်ဆင်သတ်မှတ်ရန် လိုအပ်နေသေးသည့် လျှောက်လွှာအဆင့်။ ဆိုလိုသည်မှာ အရာအားလုံးသည် အလွန်ဆိုးရွားလှသည်။


ယခု တူညီသော စမ်းသပ်မှု ဖြစ်သော်လည်း flow label ကို ဖွင့်ထားသည်။ သင်မြင်နိုင်သည်အတိုင်း၊ ဘယ်ဘက်တွင်ကျွန်ုပ်တို့၏အသုတ်စောင့်ကြည့်ရေးသည်တူညီသော 25% ကျဆင်းသွားသည်။ ၎င်းသည် လုံးဝမှန်ကန်သည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် ပြန်လည်ပို့လွှတ်ခြင်းအကြောင်း ဘာမှမသိသောကြောင့် ၎င်းသည် ထုပ်ပိုးမှုများကို ပေးပို့ပြီး ပေးပို့ပြီး ဆုံးရှုံးသွားသော ပက်ကေ့ခ်ျအရေအတွက်၏ အချိုးကို ရိုးရိုးရေတွက်ပါသည်။

ညာဘက်တွင် ဝန်ဆောင်မှုများ၏ အချိန်ဇယားဖြစ်သည်။ ဤနေရာတွင် ပြဿနာအဆစ်၏ အကျိုးသက်ရောက်မှုကို သင်တွေ့လိမ့်မည်မဟုတ်ပါ။ အလားတူ မီလီစက္ကန့်များအတွင်း ယာဉ်ကြောပိတ်ဆို့မှုသည် ပြဿနာဧရိယာမှ ပြဿနာကြောင့် မထိခိုက်နိုင်သော ကျန်အချိတ်အဆက်သုံးခုဆီသို့ စီးဆင်းသွားသည်။ သူ့ဟာသူ ကုစားနိုင်တဲ့ ကွန်ရက်တစ်ခု ရထားတယ်။

ဤသည်မှာ ကျွန်ုပ်၏ နောက်ဆုံးဆလိုက်၊ စတော့ခ်ယူရန် အချိန်ဖြစ်သည်။ ယခု၊ မိမိကိုယ်ကို ကုသခြင်း ဒေတာစင်တာ ကွန်ရက်ကို မည်သို့တည်ဆောက်ရမည်ကို သင်သိမည်ဟု မျှော်လင့်ပါသည်။ သင်သည် Linux kernel archive ကိုဖြတ်သန်းပြီး ထိုနေရာတွင် အထူးပြင်ဆင်မှုများကို ရှာဖွေရန် မလိုအပ်ပါ၊ Flow တံဆိပ်သည် ဤကိစ္စရပ်တွင် ပြဿနာကို ဖြေရှင်းပေးကြောင်း သင်သိသော်လည်း ဤယန္တရားကို ဂရုတစိုက်ချဉ်းကပ်ရန် လိုအပ်ပါသည်။ အကယ်၍ သင်သည် ဝန်ဆောင်မှုပေးသူဖြစ်ပါက၊ သင်သည် စီးဆင်းမှုတံဆိပ်ကို hash လုပ်ဆောင်ချက်အဖြစ် အသုံးမပြုသင့်ပါ၊ သို့မဟုတ်ပါက သင်သည် သင်၏အသုံးပြုသူများ၏ sessions များကို ချိုးဖျက်လိမ့်မည်ဖြစ်ကြောင်း ထပ်မံအလေးပေးပါသည်။

ကွန်ရက်အင်ဂျင်နီယာများအတွက်၊ အယူအဆဆိုင်ရာ အပြောင်းအလဲတစ်ခု လိုအပ်သည်- ကွန်ရက်သည် ToR ဖြင့် စတင်ခြင်းမရှိပါ၊ ကွန်ရက်ကိရိယာတစ်ခုနှင့်မဟုတ်ဘဲ လက်ခံဆောင်ရွက်ပေးသူဖြင့် စတင်ပါသည်။ သိသိသာသာ ထင်ရှားသော ဥပမာတစ်ခုမှာ RTO ကိုပြောင်းလဲရန်နှင့် anycast ဝန်ဆောင်မှုများဆီသို့ စီးဆင်းမှုတံဆိပ်ကို ပြုပြင်ရန် eBPF နှစ်ခုလုံးကို ကျွန်ုပ်တို့အသုံးပြုပုံဖြစ်သည်။

flow label mechanic သည် ထိန်းချုပ်ထားသော စီမံခန့်ခွဲရေးအပိုင်းအတွင်း အခြားအသုံးပြုမှုများအတွက် သေချာပေါက် သင့်လျော်ပါသည်။ ၎င်းသည် ဒေတာစင်တာများကြား အသွားအလာ ဖြစ်နိုင်သည်၊ သို့မဟုတ် အထွက်လမ်းကြောင်းကို ထိန်းချုပ်ရန် အထူးနည်းလမ်းဖြင့် အဆိုပါ စက်ပြင်များကို အသုံးပြုနိုင်သည်။ ဒါပေမယ့် ဒီအကြောင်းကို နောက်တစ်ကြိမ် ဆွေးနွေးမယ်လို့ မျှော်လင့်ပါတယ်။ သင့်အာရုံစိုက်မှုအတွက် အလွန်ကျေးဇူးတင်ပါသည်။

source: www.habr.com