Vituo vya kisasa vya data vina mamia ya vifaa vinavyotumika vinavyofunikwa na aina tofauti za ufuatiliaji. Lakini hata mhandisi kamili aliye na ufuatiliaji kamili mkononi ataweza kujibu ipasavyo kutofaulu kwa mtandao kwa dakika chache tu. Katika ripoti katika mkutano wa Next Hop 2020, niliwasilisha mbinu ya usanifu wa mtandao wa kituo cha data ambayo ina kipengele cha kipekee - kituo cha data hujiponya kwa milisekunde. Kwa usahihi zaidi, mhandisi hurekebisha shida kwa utulivu, wakati huduma hazitambui.
Kwa wahandisi wengi wa mtandao, mtandao wa kituo cha data huanza, bila shaka, na ToR, na kubadili kwenye rack. ToR kawaida huwa na aina mbili za viungo. Vidogo huenda kwa seva, wengine - kuna mara N zaidi yao - kwenda kuelekea miiba ya ngazi ya kwanza, yaani, kwa uplinks zake. Viunga vya juu kwa kawaida huchukuliwa kuwa sawa, na trafiki kati ya viungo vya juu husawazishwa kulingana na heshi yenye nakala 5, inayojumuisha proto, src_ip, dst_ip, src_port, dst_port. Hakuna mshangao hapa.
Ifuatayo, usanifu wa ndege unaonekanaje? Miiba ya ngazi ya kwanza haijaunganishwa kwa kila mmoja, lakini imeunganishwa kwa njia ya superspins. Herufi X itawajibika kwa superspins, ni karibu kama kiunganishi.
Na ni wazi kwamba, kwa upande mwingine, tori zimeunganishwa na miiba yote ya ngazi ya kwanza. Ni nini muhimu katika picha hii? Ikiwa tuna mwingiliano ndani ya rack, basi mwingiliano, bila shaka, hupitia ToR. Ikiwa mwingiliano huingia ndani ya moduli, basi mwingiliano hupitia miiba ya ngazi ya kwanza. Ikiwa mwingiliano ni wa kati - kama hapa, ToR 1 na ToR 2 - basi mwingiliano utapitia miiba ya viwango vya kwanza na vya pili.
Kinadharia, usanifu kama huo unaweza kupunguzwa kwa urahisi. Ikiwa tuna uwezo wa bandari, hifadhi ya nafasi katika kituo cha data na fiber iliyowekwa tayari, basi idadi ya ndege inaweza kuongezeka kila mara, na hivyo kuongeza uwezo wa jumla wa mfumo. Kwenye karatasi, hii ni rahisi sana kufanya. Itakuwa hivyo katika maisha halisi. Lakini hadithi ya leo si kuhusu hilo.
Nataka mahitimisho sahihi yatolewe. Tuna njia nyingi ndani ya kituo cha data. Wanajitegemea kwa masharti. Njia moja ndani ya kituo cha data inawezekana tu ndani ya ToR. Ndani ya moduli, tuna idadi sawa ya njia kama idadi ya ndege. Idadi ya njia kati ya moduli ni sawa na bidhaa ya idadi ya ndege na idadi ya superspins katika kila ndege. Ili kuifanya iwe wazi, kuhisi kiwango, nitatoa nambari ambazo ni halali kwa moja ya vituo vya data vya Yandex.
Kuna ndege nane, kila ndege ina superspins 32. Kama matokeo, zinageuka kuwa kuna njia nane ndani ya moduli, na kwa mwingiliano wa moduli tayari kuna 256 kati yao.
Hiyo ni, ikiwa tunatengeneza Cookbook, kujaribu kujifunza jinsi ya kujenga vituo vya data vinavyostahimili makosa ambavyo vinajiponya, basi usanifu wa mpango ni chaguo sahihi. Inakuwezesha kutatua tatizo la kuongeza, na kinadharia ni rahisi. Kuna njia nyingi za kujitegemea. Swali linabaki: usanifu kama huo unawezaje kuishi kushindwa? Kuna ajali mbalimbali. Na tutajadili hili sasa.
Acha mmoja wa superspins wetu awe mgonjwa. Hapa nilirudi kwenye usanifu wa ndege mbili. Tutashikamana nazo kama mfano kwa sababu itakuwa rahisi kuona kinachoendelea hapa na sehemu chache zinazosonga. Acha X11 awe mgonjwa. Je, hii itaathiri vipi huduma zinazoishi ndani ya vituo vya data? Mengi inategemea jinsi kushindwa kunavyoonekana.
Ikiwa kushindwa ni nzuri, inachukuliwa kwa kiwango cha automatisering ya BFD sawa, automatisering huweka kwa furaha viungo vya tatizo na hutenganisha tatizo, basi kila kitu ni sawa. Tuna njia nyingi, trafiki inaelekezwa upya papo hapo kwa njia mbadala, na huduma hazitaona chochote. Hii ni scenario nzuri.
Hali mbaya ni ikiwa tuna hasara za mara kwa mara, na otomatiki haitambui shida. Ili kuelewa jinsi hii inavyoathiri programu, tutalazimika kutumia muda kidogo kujadili jinsi itifaki ya TCP inavyofanya kazi.
Natumai sitamshtua mtu yeyote na habari hii: TCP ni itifaki ya kupeana mkono. Hiyo ni, katika kesi rahisi zaidi, mtumaji hutuma pakiti mbili, na hupokea ack ya jumla juu yao: "Nilipokea pakiti mbili."
Baada ya hayo, atatuma pakiti mbili zaidi, na hali hiyo itarudia. Ninaomba msamaha mapema kwa kurahisisha. Hali hii ni sahihi ikiwa dirisha (idadi ya pakiti katika ndege) ni mbili. Bila shaka, hii si lazima iwe hivyo kwa ujumla. Lakini muktadha wa usambazaji wa pakiti hauathiriwi na saizi ya dirisha.
Ni nini hufanyika ikiwa tutapoteza kifurushi cha 3? Katika kesi hii, mpokeaji atapokea pakiti 1, 2 na 4. Na atajulisha mtumaji kwa uwazi kwa kutumia chaguo la SACK: "Unajua, watatu walikuja, lakini katikati ilipotea." Anasema "Ack 2, SACK 4".
Mtumaji kwa wakati huu anarudia hasa pakiti ambayo ilipotea bila matatizo yoyote.
Lakini ikiwa pakiti ya mwisho kwenye dirisha imepotea, hali itaonekana tofauti sana.
Mpokeaji hupokea pakiti tatu za kwanza na kwanza kabisa huanza kusubiri. Shukrani kwa uboreshaji fulani katika safu ya TCP ya kernel ya Linux, itasubiri pakiti iliyooanishwa, isipokuwa kama kuna dalili wazi katika bendera kwamba hii ndiyo pakiti ya mwisho au kitu kama hicho. Itasubiri hadi muda wa kuisha kwa ACK uliochelewa kuisha na kisha kutuma kibali kwa pakiti tatu za kwanza. Lakini sasa mtumaji atakuwa anasubiri. Hajui kama kifurushi cha nne kimepotea au kinakaribia kufika. Na ili usizidishe mtandao, itajaribu kusubiri dalili wazi kwamba pakiti imepotea, au kumalizika kwa muda wa RTO.
Muda wa kuisha kwa RTO ni nini? Hiki ndicho cha juu zaidi kutoka kwa RTT kilichokokotwa na mrundikano wa TCP na baadhi ya mara kwa mara. Ni nini hii mara kwa mara, sasa tutajadili.
Lakini ni muhimu kwamba ikiwa hatuna bahati tena na pakiti ya nne imepotea tena, basi RTO huongezeka mara mbili. Hiyo ni, kila jaribio lisilofanikiwa ni mara mbili ya muda ulioisha.
Sasa hebu tuone msingi huu ni sawa na nini. Kwa chaguo-msingi, kiwango cha chini cha RTO ni 200ms. Hiki ndicho kiwango cha chini cha RTO kwa pakiti za data. Kwa pakiti za SYN, ni tofauti, sekunde 1. Kama unavyoona, hata jaribio la kwanza la kutuma tena pakiti litachukua muda mrefu mara 100 kuliko RTT ndani ya kituo cha data.
Sasa rudi kwenye scenario yetu. Nini kinaendelea na huduma? Huduma huanza kupoteza pakiti. Hebu huduma iwe na bahati ya awali na kupoteza kitu katikati ya dirisha, kisha inapokea SACK, kutuma tena pakiti zilizopotea.
Lakini ikiwa bahati mbaya inarudia, basi tuna RTO. Ni nini muhimu hapa? Ndiyo, tuna njia nyingi katika mtandao. Lakini trafiki ya TCP ya muunganisho fulani wa TCP itaendelea kupitia mrundikano uleule uliovunjika. Upotevu wa pakiti, mradi uchawi wetu X11 hautoke peke yake, hauongoi trafiki kuelekea maeneo ambayo hayana shida. Tunajaribu kuwasilisha pakiti kupitia rafu sawa iliyovunjika. Hii inasababisha kushindwa kwa kasi: kituo cha data ni seti ya programu zinazoingiliana, na baadhi ya miunganisho ya TCP ya programu hizi zote huanza kuharibika - kwa sababu superspin huathiri programu zote zilizo ndani ya DC. Kama katika msemo: ikiwa hautavaa viatu vya farasi, farasi hulegea; farasi alilegea - ripoti haikutolewa; ujumbe haukuwasilishwa - walipoteza vita. Ni hapa tu hesabu huenda kwa sekunde kutoka wakati shida inatokea hadi hatua ya uharibifu ambayo huduma huanza kuhisi. Hii ina maana kwamba watumiaji wanaweza kupokea kitu mahali fulani.
Kuna suluhisho mbili za kawaida zinazosaidiana. Ya kwanza ni huduma ambazo zinajaribu kuweka majani na kutatua tatizo kama hili: "Wacha tubadilishe kitu kwenye safu ya TCP. Na tufanye vipindi vya muda vya programu au vipindi vya muda mrefu vya TCP kwa ukaguzi wa ndani wa afya. Shida ni kwamba suluhisho kama hizo: a) hazipunguzi kabisa; b) kujaribiwa vibaya sana. Hiyo ni, hata ikiwa huduma itasanidi kwa bahati mbaya safu ya TCP ili iwe bora, kwanza, hii haiwezekani kutumika kwa programu zote na vituo vyote vya data, na pili, uwezekano mkubwa, haitaelewa kile kilichofanywa kwa usahihi na nini. sivyo. Hiyo ni, inafanya kazi, lakini inafanya kazi vibaya na haina kiwango. Na ikiwa kuna tatizo la mtandao, nani wa kulaumiwa? Bila shaka NOC. NOC inafanya nini?
Huduma nyingi zinaamini kuwa katika NOC, kazi huenda kama hii. Lakini kuwa waaminifu, sio tu.
NOC katika mpango wa classical inashiriki katika maendeleo ya ufuatiliaji wengi. Hizi zote ni ufuatiliaji wa kisanduku cheusi na ufuatiliaji wa kisanduku cheupe. Kuhusu mfano wa sanduku nyeusi-ufuatiliaji wa miiba Alexander Klimenko kwenye Next Hop iliyopita. Kwa njia, ufuatiliaji huu unafanya kazi. Lakini hata ufuatiliaji kamili utakuwa na muda wa muda. Kawaida ni dakika kadhaa. Baada ya kufanya kazi, wahandisi walio kwenye kazi wanahitaji muda wa kuangalia mara mbili uendeshaji wake, kutaja tatizo, na kisha kuzima eneo la tatizo. Hiyo ni, katika hali nzuri zaidi, matibabu ya tatizo huchukua dakika 5, wakati mbaya zaidi ya dakika 20, ikiwa haijulikani mara moja ambapo hasara hutokea. Ni wazi kwamba wakati huu wote - dakika 5 au 20 - huduma zetu zitaendelea kuumiza, ambayo labda si nzuri.
Je, ungependa kupokea nini? Tuna njia nyingi sana. Na matatizo hutokea kwa sababu mtiririko wa TCP ambao hauna bahati huendelea kutumia njia sawa. Tunahitaji kitu ambacho kitaturuhusu kutumia njia nyingi ndani ya muunganisho mmoja wa TCP. Inaweza kuonekana kuwa tuna suluhisho. Kuna TCP, ambayo inaitwa hivyo - multipath TCP, yaani, TCP kwa njia nyingi. Kweli, ilitengenezwa kwa kazi tofauti kabisa - kwa simu mahiri ambazo zina vifaa kadhaa vya mtandao. Ili kuongeza uhamishaji au kufanya hali ya msingi / chelezo, utaratibu ulitengenezwa ambao huunda kwa uwazi nyuzi kadhaa (vikao) vya programu na hukuruhusu kubadili kati yao ikiwa itashindwa. Au, kama nilivyosema, ongeza bandwidth.
Lakini kuna nuance hapa. Ili kuelewa ni nini, itabidi tuangalie jinsi mitiririko inavyowekwa.
Threads ni kuweka sequentially. Mtiririko wa kwanza umewekwa kwanza. Mitiririko inayofuata huwekwa kwa kutumia kidakuzi ambacho tayari kimekubaliwa ndani ya mazungumzo hayo. Na hapa ndio shida.
Shida ni kwamba ikiwa uzi wa kwanza haujasakinishwa, nyuzi za pili na za tatu hazitakuja kamwe. Hiyo ni, TCP ya njia nyingi haisuluhishi upotezaji wa pakiti ya SYN katika mkondo wa kwanza. Na ikiwa SYN itapotea, TCP ya njia nyingi inakuwa TCP ya kawaida. Kwa hiyo, katika mazingira ya kituo cha data, haitatusaidia kutatua tatizo la hasara katika kiwanda na kujifunza jinsi ya kutumia njia nyingi katika kesi ya kushindwa.
Ni nini kinachoweza kutusaidia? Baadhi yenu tayari mmekisia kutoka kwa jina kwamba sehemu muhimu katika hadithi yetu zaidi itakuwa sehemu ya kichwa cha lebo ya mtiririko wa IPv6. Hakika, hii ni shamba inayoonekana katika v6, haipo katika v4, inachukua bits 20, na kumekuwa na utata kuhusu matumizi yake kwa muda mrefu. Hii inafurahisha sana - kulikuwa na mabishano, kitu kiliwekwa ndani ya mfumo wa RFC, na wakati huo huo, utekelezaji ulionekana kwenye kernel ya Linux ambayo haijawahi kuandikwa popote.
Nakushauri ujiunge nami kwenye uchunguzi mdogo. Wacha tuangalie kile ambacho kimekuwa kikitokea kwenye kernel ya Linux katika miaka michache iliyopita.
mwaka 2014. Mhandisi kutoka kampuni kubwa na yenye sifa nzuri anaongeza utendakazi wa kinu cha Linux utegemezi wa thamani ya lebo ya mtiririko kwenye heshi ya soketi. Je, wanajaribu kurekebisha nini hapa? Hii inahusiana na RFC 6438 ambayo ilijadili suala lifuatalo. Ndani ya kituo cha data, IPv4 mara nyingi huingizwa katika pakiti za IPv6, kwa sababu kiwanda yenyewe ni IPv6, lakini IPv4 lazima itolewe kwa namna fulani. Kwa muda mrefu kulikuwa na matatizo na swichi ambazo hazikuweza kuangalia chini ya vichwa viwili vya IP ili kufikia TCP au UDP na kupata src_ports, dst_ports huko. Ilibadilika kuwa hashi, ikiwa unatazama vichwa viwili vya kwanza vya IP, iligeuka kuwa karibu fasta. Ili kuepusha hili, ili kusawazisha trafiki hii iliyofunikwa ifanye kazi kwa usahihi, ilipendekezwa kuongeza heshi kutoka kwa pakiti iliyofunikwa ya nakala-5 hadi thamani ya uwanja wa lebo ya mtiririko. Takriban sawa ilifanyika kwa mipango mingine ya encapsulation, kwa UDP, kwa GRE, mwishowe uwanja wa GRE Key ulitumiwa. Njia moja au nyingine, malengo hapa ni wazi. Na angalau wakati huo kwa wakati walikuwa muhimu.
Mnamo 2015, kiraka kipya kinatoka kwa mhandisi huyo anayeheshimiwa. Anavutia sana. Inasema yafuatayo - tutabadilisha hashi nasibu ikiwa kuna tukio hasi la uelekezaji. Tukio hasi la uelekezaji ni nini? Hii ndio RTO ambayo tulijadili hapo awali, ambayo ni, kupotea kwa mkia wa dirisha ni tukio ambalo ni mbaya sana. Kweli, ni vigumu kukisia ni nini.
2016, kampuni nyingine inayoheshimiwa, pia kubwa. Huchanganua mikongojo ya mwisho na kuifanya ili heshi ambayo tuliweka nasibu hapo awali sasa ibadilishwe kwa kila utumaji upya wa SYN na baada ya kila wakati kuisha kwa RTO. Na katika barua hii, kwa mara ya kwanza na ya mwisho, lengo la mwisho linasikika - kuhakikisha kwamba trafiki katika tukio la kupoteza au overload ya njia ina uwezekano wa rerouting laini, kwa kutumia njia nyingi. Bila shaka, baada ya hapo kulikuwa na machapisho mengi, unaweza kupata kwa urahisi.
Ingawa hapana, huwezi, kwa sababu hakujakuwa na chapisho moja juu ya mada hii. Lakini tunajua!
Na ikiwa hauelewi kikamilifu kilichofanywa, nitakuambia sasa.
Ni nini kimefanywa, ni utendaji gani umeongezwa kwenye kernel ya Linux? txhash hubadilika kuwa thamani nasibu baada ya kila tukio la RTO. Haya ni matokeo sawa ya uelekezaji hasi. Heshi inategemea txhash hii na lebo ya mtiririko inategemea skb heshi. Kuna baadhi ya mahesabu juu ya kazi hapa, maelezo yote hayawezi kuwekwa kwenye slide moja. Ikiwa mtu yeyote ana hamu ya kujua, unaweza kupitia nambari ya kernel na uangalie.
Ni nini muhimu hapa? Thamani ya uga wa lebo ya mtiririko hubadilika hadi nambari nasibu baada ya kila RTO. Je, hii inaathiri vipi mtiririko wetu wa bahati mbaya wa TCP?
Kwa upande wa GUNIA, hakuna kilichobadilika kwa sababu tunajaribu kutuma tena pakiti inayojulikana iliyopotea. Hadi sasa nzuri sana.
Lakini kwa upande wa RTO, mradi tumeongeza lebo ya mtiririko kwenye kipengele cha kukokotoa kwenye ToR, trafiki inaweza kuchukua njia tofauti. Na ndege nyingi zaidi, kuna uwezekano mkubwa wa kupata njia ambayo haiathiriwa na ajali kwenye kifaa fulani.
Tatizo moja linabaki - RTO. Njia nyingine, bila shaka, inapatikana, lakini muda mwingi hutumiwa juu yake. 200ms ni nyingi. Ya pili ni kwa ujumla pori. Hapo awali, nilizungumza juu ya muda wa kuisha ambao husanidi huduma. Kwa hiyo, pili ni muda wa muda ambao kwa kawaida huweka huduma katika ngazi ya maombi, na katika hili huduma itakuwa hata sawa. Aidha, narudia, RTT halisi ndani ya kituo cha kisasa cha data ni karibu 1 millisecond.
Nini kinaweza kufanywa kuhusu kuisha kwa muda kwa RTO? Muda wa kuisha ambao unawajibika kwa RTO katika kesi ya upotezaji wa pakiti za data inaweza kusanidiwa kwa urahisi kutoka kwa nafasi ya mtumiaji: kuna matumizi ya IP, na moja ya vigezo vyake ina rto_min sawa. Kwa kuzingatia kwamba, kwa kweli, unahitaji kugeuza RTO sio kimataifa, lakini kwa viambishi awali, utaratibu kama huo unaonekana kufanya kazi kabisa.
Kweli, kwa SYN_RTO kila kitu ni mbaya zaidi. Imepigiliwa misumari kwa asili. Thamani imewekwa katika msingi - sekunde 1, na ndivyo hivyo. Huwezi kuifikia kutoka kwa nafasi ya mtumiaji. Kuna njia moja tu.
eBPF inakuja kuwaokoa. Ili kuiweka kwa urahisi, haya ni programu ndogo za C. Wanaweza kuingizwa kwenye ndoano kwenye maeneo tofauti katika utekelezaji wa stack ya kernel na stack ya TCP, ambayo unaweza kubadilisha idadi kubwa sana ya mipangilio. Kwa ujumla, eBPF ni mwenendo wa muda mrefu. Badala ya kuona kadhaa ya vigezo vipya vya sysctl na kupanua matumizi ya IP, harakati iko katika mwelekeo wa eBPF na kupanua utendakazi wake. Ukiwa na eBPF, unaweza kubadilisha vidhibiti vya msongamano na mipangilio mingine mbalimbali ya TCP.
Lakini ni muhimu kwetu kwamba kwa msaada wake unaweza kupotosha maadili ya SYN_RTO. Na kuna mfano uliotumwa kwa umma: . Nini kinafanyika hapa? Mfano unafanya kazi, lakini yenyewe ni mbaya sana. Inachukuliwa hapa kuwa ndani ya kituo cha data tunalinganisha bits 44 za kwanza, ikiwa zinafanana, basi tunajikuta ndani ya DC. Na katika hali hii, tunabadilisha thamani ya SYN_RTO kuisha hadi 4ms. Kazi sawa inaweza kufanywa kwa uzuri zaidi. Lakini mfano huu rahisi unaonyesha nini kinawezekana a); b) rahisi kiasi.
Tunajua nini tayari? Kwamba usanifu wa sayari huruhusu kuongeza ukubwa, inakuwa muhimu sana kwetu tunapowasha lebo ya mtiririko kwenye ToR na kupata fursa ya kuzunguka maeneo yenye matatizo. Njia bora ya kupunguza maadili ya RTO na SYN-RTO ni kutumia programu za eBPF. Swali linabaki: ni salama kutumia lebo ya mtiririko kwa kusawazisha? Na kuna nuance hapa.
Tuseme una huduma kwenye mtandao inayoishi katika utangazaji wowote. Kwa bahati mbaya, sina wakati wa kuelezea kwa undani juu ya utangazaji wowote, lakini ni huduma iliyosambazwa ambapo seva tofauti za mwili zinapatikana kwenye anwani sawa ya IP. Na hapa kuna shida inayowezekana: tukio la RTO linaweza kutokea sio tu wakati trafiki inapita kwenye kiwanda. Inaweza pia kutokea katika kiwango cha bafa ya ToR: tukio la incast linapotokea, linaweza kutokea hata kwa seva pangishi wakati mpangishi anamwaga kitu. Wakati tukio la RTO linatokea na hubadilisha lebo ya mtiririko. Katika kesi hii, trafiki inaweza kwenda kwa mfano mwingine wowote. Tuseme ni onyesho la hali ya juu, lina hali ya muunganisho - inaweza kuwa Balancer ya L3 au huduma nyingine. Kisha tatizo linatokea, kwa sababu baada ya RTO, uunganisho wa TCP unafika kwenye seva, ambayo haijui chochote kuhusu uhusiano huu wa TCP. Na ikiwa hatuna ugavi wa hali kati ya seva za matangazo yoyote, basi trafiki kama hiyo itasimamishwa na muunganisho wa TCP utavunjika.
Nini kifanyike hapa? Ndani ya mazingira yako yanayodhibitiwa, ambapo unawezesha kusawazisha lebo ya mtiririko, unahitaji kurekebisha thamani ya lebo ya mtiririko unapofikia seva zozote za utumaji. Njia rahisi ni kuifanya kupitia programu sawa ya eBPF. Lakini hapa ni jambo muhimu sana - nini cha kufanya ikiwa huna kazi mtandao wa kituo cha data, lakini ni operator wa telecom? Hili ni tatizo lako pia: kuanzia na matoleo fulani ya Juniper na Arista, yanajumuisha lebo ya mtiririko katika kazi ya heshi kwa chaguo-msingi - kuwa mkweli, kwa sababu ambayo sielewi. Hii inaweza kukusababisha kuacha miunganisho ya TCP kutoka kwa watumiaji wanaopitia mtandao wako. Kwa hiyo, ninapendekeza sana kuangalia mipangilio ya router yako mahali hapa.
Njia moja au nyingine, inaonekana kwangu kuwa tuko tayari kuendelea na majaribio.
Tulipowasha lebo ya mtiririko kwenye ToR, tukatayarisha eBPF ya wakala, ambayo sasa inaishi kwenye seva pangishi, tuliamua kutosubiri hitilafu kubwa inayofuata, bali kufanya milipuko inayodhibitiwa. Tulichukua ToR, ambayo ina viunga vinne, na tukafanya matone kwenye moja wapo. Walichora sheria, walisema - sasa unapoteza pakiti zote. Kama unavyoona upande wa kushoto, tunayo ufuatiliaji wa kila pakiti, ambayo imeshuka hadi 75%, ambayo ni, 25% ya pakiti zimepotea. Upande wa kulia ni grafu za huduma zinazoishi nyuma ya ToR hii. Kwa kweli, hizi ni grafu za trafiki za viungo na seva ndani ya rack. Kama unavyoona, walizama hata chini. Kwa nini walizama chini - si kwa 25%, lakini katika baadhi ya matukio kwa mara 3-4? Ikiwa muunganisho wa TCP hauna bahati, inaendelea kujaribu kufikia kupitia kiolesura kilichovunjika. Hii inazidishwa na tabia ya kawaida ya huduma ndani ya DC - kwa ombi moja la mtumiaji, maombi ya N kwa huduma za ndani yanatolewa, na majibu yataenda kwa mtumiaji, wakati vyanzo vyote vya data vinajibu, au wakati kuisha kumeanzishwa. kiwango cha programu, ambacho bado kinahitaji kusanidiwa. Hiyo ni, kila kitu ni mbaya sana.
Sasa jaribio lile lile, lakini lebo ya mtiririko imewezeshwa. Kama unavyoona, upande wa kushoto, ufuatiliaji wetu wa kundi ulizama kwa 25%. Hii ni sahihi kabisa, kwa sababu haijui chochote kuhusu uhamisho, hutuma pakiti na huhesabu tu uwiano wa idadi ya pakiti zilizotolewa na zilizopotea.
Na kulia ni ratiba ya huduma. Hutapata athari ya kiungo cha tatizo hapa. Trafiki katika milisekunde hiyo hiyo ilitiririka kutoka eneo la tatizo hadi kwenye viunga vitatu vilivyosalia ambavyo havikuathiriwa na tatizo. Tuna mtandao unaojiponya.
Hii ni slaidi yangu ya mwisho, wakati wa kuchukua hisa. Sasa, natumai unajua jinsi ya kuunda mtandao wa kituo cha data cha kujiponya. Hutahitaji kupitia kumbukumbu ya kernel ya Linux na kutafuta viraka maalum huko, unajua kwamba lebo ya Flow hutatua tatizo katika kesi hii, lakini unahitaji kukabiliana na utaratibu huu kwa makini. Na ninasisitiza tena kwamba ikiwa wewe ni mtoa huduma, hupaswi kutumia lebo ya mtiririko kama kipengele cha kukokotoa, vinginevyo utavunja vipindi vya watumiaji wako.
Kwa wahandisi wa mtandao, mabadiliko ya dhana yanahitajika kufanyika: mtandao hauanza na ToR, si kwa kifaa cha mtandao, lakini kwa mwenyeji. Mfano mzuri kabisa ni jinsi tunavyotumia eBPF kubadilisha RTO na kurekebisha lebo ya mtiririko kuelekea huduma zozote za utangazaji.
Mitambo ya lebo ya mtiririko hakika inafaa kwa matumizi mengine ndani ya sehemu ya usimamizi inayodhibitiwa. Hii inaweza kuwa trafiki kati ya vituo vya data, au unaweza kutumia mechanics kama hiyo kwa njia maalum ili kudhibiti trafiki inayotoka. Lakini nitazungumza juu ya hili, natumai, wakati ujao. Asante sana kwa umakini wako.
Chanzo: mapenzi.com