Kaasaegsetes andmekeskustes on sadu aktiivseid seadmeid, mis on kaetud erinevat tüüpi seirega. Kuid isegi täiuslik insener, kellel on täiuslik järelevalve, suudab võrgutõrkele õigesti reageerida vaid mõne minutiga. Konverentsi Next Hop 2020 raportis tutvustasin andmekeskuse võrgukujunduse metoodikat, millel on ainulaadne omadus – andmekeskus paraneb ennast millisekunditega. Täpsemalt lahendab insener probleemi rahulikult, samas kui teenindused lihtsalt ei märka seda.
Paljude võrguinseneride jaoks algab andmekeskuste võrk loomulikult ToR-iga, lülitiga riiulis. ToR-il on tavaliselt kahte tüüpi linke. Väiksemad lähevad serveritesse, teised - neid on N korda rohkem - esimese taseme spine'ide poole, see tähendab selle üleslinkide poole. Üleslinke peetakse tavaliselt võrdseks ja üleslinkide vaheline liiklus tasakaalustatakse 5-kordse räsi põhjal, mis sisaldab proto, src_ip, dst_ip, src_port, dst_port. Siin pole üllatusi.
Järgmiseks, milline näeb välja lennukite arhitektuur? Esimese taseme ogad ei ole omavahel ühendatud, vaid on ühendatud superspinnide abil. Täht X vastutab superspinnide eest, see on peaaegu nagu ristühendus.
Ja on selge, et teisest küljest on torid ühendatud kõigi esimese taseme ogadega. Mis on sellel pildil oluline? Kui meil on interaktsioon riiuli sees, siis suhtlemine toimub loomulikult läbi ToR-i. Kui interaktsioon toimub mooduli sees, siis interaktsioon läbib esimese taseme selgroogu. Kui interaktsioon on intermodulaarne – nagu siin, ToR 1 ja ToR 2 –, siis interaktsioon läbib nii esimese kui ka teise taseme selgroogu.
Teoreetiliselt on selline arhitektuur kergesti skaleeritav. Kui meil on pordi maht, andmekeskuses ruumireserv ja eelnevalt paigaldatud kiud, siis saab lennukite arvu alati suurendada, suurendades seeläbi süsteemi üldist läbilaskevõimet. Paberil on seda väga lihtne teha. Päris elus oleks see nii. Aga tänane lugu sellest ei räägi.
Tahan, et tehakse õiged järeldused. Meil on andmekeskuse sees palju teid. Nad on tinglikult sõltumatud. Üks viis andmekeskusesse on võimalik ainult ToR-i sees. Mooduli sees on meil sama palju teid kui tasapindade arv. Moodulitevaheliste radade arv võrdub tasandite arvu ja iga tasapinna superspinnide arvu korrutisega. Selgemaks muutmiseks ja skaala tunnetamiseks annan numbrid, mis kehtivad ühe Yandexi andmekeskuse jaoks.
Lennukeid on kaheksa, igal lennukil on 32 superspinni. Selle tulemusena selgub, et mooduli sees on kaheksa teed ja moodulitevahelise suhtluse korral on neid juba 256.
See tähendab, et kui arendame kokaraamatut, et õppida, kuidas ehitada tõrketaluvusega andmekeskusi, mis paranevad ise, siis on tasapinnaline arhitektuur õige valik. See võimaldab teil skaleerimisprobleemi lahendada ja teoreetiliselt on see lihtne. Sõltumatuid teid on palju. Jääb küsimus: kuidas selline arhitektuur ebaõnnestumisi üle elab? Avariisid on erinevaid. Ja me arutame seda nüüd.
Las üks meie superspinnidest jääb haigeks. Siin pöördusin tagasi kahe tasapinna arhitektuuri juurde. Jääme nende näidete juurde, sest vähemate liikuvate osadega on lihtsalt lihtsam näha, mis siin toimub. Las X11 jääb haigeks. Kuidas see mõjutab andmekeskustes elavaid teenuseid? Palju sõltub sellest, kuidas rike tegelikult välja näeb.
Kui rike on hea, tabatakse see sama BFD automatiseerimise tasemel, automaatika paneb rõõmsalt probleemsed liigendid ja isoleerib probleemi, siis on kõik korras. Meil on palju teid, liiklus suunatakse koheselt ümber alternatiivsetele marsruutidele ja teenindused ei märka midagi. See on hea stsenaarium.
Halb stsenaarium on see, kui meil on pidevaid kadusid ja automaatika ei märka probleemi. Et mõista, kuidas see rakendust mõjutab, peame kulutama veidi aega TCP-protokolli toimimise üle.
Loodan, et ma ei šokeeri selle teabega kedagi: TCP on käepigistuse protokoll. See tähendab, et kõige lihtsamal juhul saadab saatja kaks paketti ja saab nende kohta kumulatiivse kinnituse: "Ma sain kaks paketti."
Pärast seda saadab ta veel kaks pakki ja olukord kordub. Vabandan juba ette mõningase lihtsustamise pärast. See stsenaarium on õige, kui aken (pakettide arv lennu ajal) on kaks. Loomulikult ei pruugi see üldiselt nii olla. Kuid akna suurus ei mõjuta pakettide edastamise konteksti.
Mis juhtub, kui kaotame paketi 3? Sel juhul saab saaja kätte paketid 1, 2 ja 4. Ja ta teavitab saatjat sõnaselgelt, kasutades valikut KOTTI: "Tead, kolm tuli, aga keskmine läks kaduma." Ta ütleb "Ack 2, SACK 4".
Saatja kordab sel hetkel täpselt kaduma läinud paketti ilma probleemideta.
Kui aga viimane pakett aknas kaotsi läheb, näeb olukord hoopis teistsugune välja.
Saaja saab kolm esimest pakki ja hakkab esmalt ootama. Tänu Linuxi kerneli TCP-pinu mõningatele optimeerimistele ootab see seotud paketti, välja arvatud juhul, kui lippude sees on selgesõnaline märge, et see on viimane pakett või midagi sellist. See ootab, kuni hilinenud ACK-i ajalõpp aegub, ja saadab seejärel kinnituse esimese kolme paketi kohta. Nüüd aga jääb saatja ootama. Ta ei tea, kas neljas pakk on kadunud või saabumas. Ja selleks, et võrku mitte üle koormata, püüab see oodata selgesõnalist märguannet paketi kadumise kohta või RTO ajalõpu aegumist.
Mis on RTO ajalõpp? See on TCP-pinu ja mõne konstandi arvutatud RTT maksimum. Mis see konstant on, arutame nüüd.
Kuid on oluline, et kui meil jälle ei vea ja neljas pakett jälle kaotsi läheb, siis RTO kahekordistub. See tähendab, et iga ebaõnnestunud katse on ajalõpu kahekordistamine.
Nüüd vaatame, millega see alus on võrdne. Vaikimisi on minimaalne RTO 200 ms. See on andmepakettide minimaalne RTO. SYN-pakettide puhul on see erinev, 1 sekund. Nagu näete, võtab isegi esimene katse pakettide uuesti saatmiseks andmekeskuses 100 korda kauem aega kui RTT.
Nüüd tagasi meie stsenaariumi juurde. Mis teenusega toimub? Teenus hakkab pakette kaotama. Las teenusel alguses veab ja kaotab midagi keset akent, siis saab KOTTI, saadab kadunud paketid uuesti.
Aga kui halb õnn kordub, on meil RTO. Mis on siin oluline? Jah, meil on võrgus palju teid. Kuid ühe konkreetse TCP-ühenduse TCP-liiklus jätkab sama katkise virna läbimist. Kui meie võlu X11 iseenesest ei kustu, ei põhjusta paketi kadumine liiklust piirkondadesse, mis pole probleemsed. Püüame paki toimetada sama katkise virna kaudu. See toob kaasa kaskaadtõrke: andmekeskus on interakteeruvate rakenduste kogum ja osa kõigi nende rakenduste TCP-ühendustest hakkab lagunema – kuna superspin mõjutab kõiki andmekeskuses olevaid rakendusi. Nagu ütluses: kui sa hobust ei kinga, siis hobune lonkab; hobune lonkas - aruannet ei edastatud; sõnumit ei edastatud – nad kaotasid sõja. Ainult siin loetakse sekundit probleemi ilmnemise hetkest kuni halvenemise staadiumini, mida teenused tunnevad. See tähendab, et kasutajad ei pruugi kuskil midagi kätte saada.
Klassikalisi lahendusi on kaks, mis üksteist täiendavad. Esimene neist on teenused, mis püüavad õlekõrsi laduda ja probleemi lahendada järgmiselt: „Tipime midagi TCP-virnas. Ja tehkem rakenduse tasemel ajalõpe või pikaajalisi TCP seansse koos sisemiste tervisekontrollidega. Probleem on selles, et sellised lahendused: a) ei skaleeru üldse; b) väga halvasti testitud. See tähendab, et isegi kui teenus konfigureerib kogemata TCP-virna nii, et see muutuks paremaks, ei ole see tõenäoliselt rakendatav kõigi rakenduste ja andmekeskuste jaoks ning teiseks ei saa see tõenäoliselt aru, mida õigesti tehti ja mida mitte. See tähendab, et see töötab, kuid töötab halvasti ja ei skaleeru. Ja kui on võrguprobleem, kes on süüdi? Muidugi NOC. Mida NOC teeb?
Paljud teenistused usuvad, et NOC-is läheb töö umbes nii. Aga ausalt öeldes mitte ainult.
NOC klassikalises skeemis tegeleb paljude seiresüsteemide väljatöötamisega. Need on nii musta kasti jälgimine kui ka valge kasti jälgimine. Seljade musta kasti jälgimise näitest Aleksander Klimenko minevikust Next Hop. Muide, see jälgimine töötab. Kuid isegi täiuslikul jälgimisel on ajaline viivitus. Tavaliselt on see mitu minutit. Pärast selle toimimist vajavad valves olevad insenerid aega, et kontrollida selle toimimist, lokaliseerida probleem ja seejärel probleemne piirkond kustutada. See tähendab, et parimal juhul võtab probleemi lahendamine aega 5 minutit, halvemal juhul 20 minutit, kui pole kohe näha, kus kahjud tekivad. On selge, et kogu selle aja – 5 või 20 minutit – jäävad meie teenused haiget tegema, mis pole ilmselt hea.
Mida sa tahaksid saada? Meil on nii palju teid. Ja probleemid tekivad just seetõttu, et õnnetud TCP-vood kasutavad jätkuvalt sama marsruuti. Vajame midagi, mis võimaldab meil kasutada mitut marsruuti ühe TCP-ühenduse sees. Näib, et meil on lahendus. Seal on TCP, mida nimetatakse nn - multipath TCP, st TCP paljude teede jaoks. Tõsi, see töötati välja täiesti erineva ülesande jaoks - nutitelefonidele, millel on mitu võrguseadet. Edastamise maksimeerimiseks või esmase / varurežiimi muutmiseks töötati välja mehhanism, mis loob rakenduse jaoks läbipaistvalt mitu lõime (seanssi) ja võimaldab teil rikke korral nende vahel vahetada. Või, nagu ma ütlesin, maksimeerida ribalaiust.
Kuid siin on nüanss. Et mõista, mis see on, peame vaatama, kuidas voogusid seadistatakse.
Niidid seatakse järjestikku. Esimene voog installitakse kõigepealt. Järgmised vood määratakse seejärel selles lõimes juba kokkulepitud küpsise abil. Ja siin on probleem.
Probleem on selles, et kui esimest lõime ei installita, ei tule teist ja kolmandat lõime kunagi üles. See tähendab, et mitme teekonnaga TCP ei lahenda SYN-paketi kadumist esimeses voos. Ja kui SYN kaob, muutub mitmetee TCP tavaline TCP. Seega ei aita see andmekeskuse keskkonnas meil lahendada tehases tekkivate kadude probleemi ja õppida, kuidas rikke korral kasutada mitut teed.
Mis saab meid aidata? Mõned teist on juba nime järgi aimanud, et meie edasises loos saab oluliseks väljaks IPv6 voosildi päise väli. Tõepoolest, see on väli, mis ilmub versioonis v6, seda pole v4-s, see võtab 20 bitti ja selle kasutamise üle on olnud vaidlusi pikka aega. See on väga huvitav - oli vaidlusi, RFC raames parandati midagi ja samal ajal ilmus Linuxi tuumasse rakendus, mida kunagi kuskil ei dokumenteeritud.
Soovitan teil minuga väikese uurimisega liituda. Heidame pilgu sellele, mis on viimastel aastatel Linuxi tuumas toimunud.
aasta 2014. Suure ja maineka ettevõtte insener lisab Linuxi tuuma funktsionaalsusele voosildi väärtuse sõltuvuse pesa räsist. Mida nad siin parandada üritavad? See on seotud standardiga RFC 6438, mis arutas järgmist probleemi. Andmekeskuse sees on IPv4 sageli kapseldatud IPv6 pakettidesse, sest tehas ise on IPv6, aga IPv4 tuleb kuidagi välja anda. Pikka aega oli probleeme lülititega, mis ei saanud vaadata kahe IP päise alt, et pääseda TCP-le või UDP-le ja leida sealt src_ports, dst_ports. Selgus, et räsi, kui vaadata kahte esimest IP-päist, osutus peaaegu fikseerituks. Selle vältimiseks, et selle kapseldatud liikluse tasakaalustamine toimiks õigesti, tehti ettepanek lisada 5-kordse kapseldatud paketi räsi voosildi välja väärtusele. Ligikaudu sama tehti ka teiste kapseldamisskeemidega, UDP jaoks, GRE jaoks, viimases kasutati GRE Key välja. Nii või teisiti on eesmärgid siin selged. Ja vähemalt sel hetkel olid need kasulikud.
2015. aastal tuleb samalt lugupeetud insenerilt uus plaaster. Ta on väga huvitav. See ütleb järgmist – negatiivse marsruutimissündmuse korral randomiseerime räsi. Mis on negatiivne marsruutimise sündmus? See on RTO, mida me varem arutasime, see tähendab, et akna saba kaotamine on sündmus, mis on tõesti negatiivne. Tõsi, suhteliselt raske on arvata, millega tegu.
2016, teine lugupeetud ettevõte, samuti suur. See analüüsib viimased kargud ja muudab selle nii, et räsi, mille me varem randomiseerisime, muudetakse nüüd iga SYN-i kordusedastuse ja pärast iga RTO ajalõpu järel. Ja selles kirjas kõlab esimest ja viimast korda ülim eesmärk – tagada, et kanalite kaotsimineku või ülekoormuse korral oleks liiklusel võimalik pehme ümbermarsruutimine, kasutades mitut teed. Muidugi pärast seda ilmus palju väljaandeid, leiate need lihtsalt üles.
Kuigi ei, te ei saa, sest sellel teemal pole avaldatud ühtegi väljaannet. Aga me teame!
Ja kui te ei saa täielikult aru, mida tehti, siis ma ütlen teile nüüd.
Mida on tehtud, mis funktsionaalsust on Linuxi tuumale lisatud? txhash muutub pärast iga RTO sündmust juhuslikuks väärtuseks. See on sama negatiivne marsruutimise tulemus. Räsi sõltub sellest txräsist ja voo silt sõltub skb räsist. Siin on funktsioonide kohta mõned arvutused, kõiki detaile ei saa ühele slaidile paigutada. Kui kedagi huvitab, võib kerneli koodi läbi vaadata ja kontrollida.
Mis on siin oluline? Voolusildi välja väärtus muutub pärast iga RTO-d juhuslikuks numbriks. Kuidas see mõjutab meie õnnetut TCP-voogu?
SACK-i puhul pole midagi muutunud, kuna proovime teadaolevalt kadunud paketti uuesti saata. Siiamaani on kõik korras.
Kuid RTO puhul, eeldusel, et oleme lisanud ToR-i räsifunktsioonile voosildi, võib liiklus kulgeda erineval marsruudil. Ja mida rohkem lennukeid, seda tõenäolisem on leida tee, mida konkreetse seadme õnnetus ei mõjuta.
Üks probleem jääb alles - RTO. Teine marsruut muidugi leitakse, aga sellele kulub palju aega. 200 ms on palju. Sekund on üldiselt metsikus. Varem rääkisin ajalõppudest, mis konfigureerivad teenuseid. Niisiis, sekund on ajalõpp, mis tavaliselt seadistab teenuse rakenduse tasemel ja selles on teenus isegi suhteliselt õige. Veelgi enam, kordan, tänapäevase andmekeskuse tegelik RTT on umbes 1 millisekund.
Mida saab teha RTO ajalõpudega? Ajalõpu, mis vastutab RTO eest andmepakettide kadumise korral, saab kasutajaruumist suhteliselt lihtsalt konfigureerida: IP-utiliit on olemas ja selle üks parameeter sisaldab sama rto_min. Arvestades, et loomulikult peate RTO-d keerama mitte globaalselt, vaid etteantud eesliidete jaoks, tundub selline mehhanism üsna töötav.
Tõsi, SYN_RTO-ga on kõik mõnevõrra halvem. See on loomulikult naelutatud. Väärtus on südamikus fikseeritud – 1 sekund ja ongi kõik. Te ei pääse sellele kasutajaruumist ligi. On ainult üks viis.
eBPF tuleb appi. Lihtsamalt öeldes on need väikesed C-programmid. Neid saab sisestada kerneli pinu ja TCP-pinu täitmisel erinevatesse kohtadesse konksudesse, millega saab muuta väga suurt hulka seadistusi. Üldiselt on eBPF pikaajaline trend. Selle asemel, et saagida kümneid uusi sysctl-i parameetreid ja laiendada IP-utiliiti, liigutakse eBPF-i ja selle funktsionaalsuse laiendamise suunas. eBPF-iga saate dünaamiliselt muuta ummikute juhtelemente ja mitmesuguseid muid TCP-sätteid.
Kuid meie jaoks on oluline, et selle abil saate SYN_RTO väärtusi väänata. Ja seal on avalikult postitatud näide: . Mida siin tehakse? Näide töötab, kuid on iseenesest väga konarlik. Siin eeldatakse, et andmekeskuse sees võrdleme esimesed 44 bitti, kui need ühtivad, siis leiame end DC seest. Ja sel juhul muudame SYN_RTO ajalõpu väärtuseks 4 ms. Sama ülesannet saab teha palju elegantsemalt. Kuid see lihtne näide näitab, mis on a) võimalik; b) suhteliselt lihtne.
Mida me juba teame? Et tasapinnaline arhitektuur võimaldab skaleerimist, osutub see meile äärmiselt kasulikuks, kui lülitame ToR-il sisse voolusildi ja saame võimaluse probleemsetes piirkondades ringi liikuda. Parim viis RTO ja SYN-RTO väärtuste alandamiseks on eBPF programmide kasutamine. Jääb küsimus: kas voolumärgistuse kasutamine tasakaalustamisel on ohutu? Ja siin on nüanss.
Oletame, et teil on võrgus teenus, mis töötab Anycastis. Kahjuks ei ole mul aega anycasti kohta üksikasjalikult rääkida, kuid see on hajutatud teenus, kus erinevad füüsilised serverid on saadaval samal IP-aadressil. Ja siin on võimalik probleem: RTO sündmus võib ilmneda mitte ainult siis, kui liiklus läbib tehast. See võib esineda ka ToR-puhvri tasemel: kui toimub incast sündmus, võib see juhtuda isegi hostis, kui host midagi maha puistab. Kui toimub RTO sündmus ja see muudab voo silti. Sel juhul võib liiklus suunata teise mis tahes ülekande eksemplari. Oletame, et see on olekupõhine anycast, see sisaldab ühenduse olekut – see võib olla L3 Balancer või mõni muu teenus. Siis tekib probleem, sest peale RTO-d saabub serverisse TCP ühendus, mis ei tea sellest TCP ühendusest midagi. Ja kui meil pole anycasti serverite vahel olekute jagamist, siis selline liiklus katkeb ja TCP-ühendus katkeb.
Mida siin teha saab? Kontrollitud keskkonnas, kus lubate voosildi tasakaalustamise, peate Anycast-serveritele juurdepääsul voosildi väärtuse fikseerima. Lihtsaim viis on seda teha sama eBPF programmi kaudu. Siin on aga väga oluline punkt – mida teha, kui te ei opereeri andmekeskuse võrku, kuid olete sideoperaator? See on ka teie probleem: alustades Juniperi ja Arista teatud versioonidest, lisavad nad vaikimisi räsifunktsiooni voolusildi - ausalt öeldes, ilma põhjuseta, millest ma aru saan. See võib põhjustada teie võrku läbivate kasutajate TCP-ühenduste katkemise. Seetõttu soovitan tungivalt kontrollida oma ruuteri sätteid selles kohas.
Nii või teisiti mulle tundub, et oleme valmis katsetega edasi minema.
Kui lülitasime ToR-il sisse voolusildi, valmistasime ette agendi eBPF-i, mis nüüd hostidel elab, otsustasime mitte oodata järgmist suurt riket, vaid korraldada kontrollitud plahvatusi. Võtsime ToR-i, millel on neli üleslinki, ja langetasime ühele neist. Nad koostasid reegli, ütlesid - nüüd kaotate kõik paketid. Nagu näete vasakul, on meil paketipõhine jälgimine, mis on langenud 75% -ni, see tähendab, et 25% pakettidest läheb kaotsi. Paremal on selle ToRi taga elavate teenuste graafikud. Tegelikult on need liiklusgraafikud riiuli sees olevate serveritega. Nagu näha, vajusid need veelgi madalamale. Miks nad vajusid madalamale - mitte 25%, vaid mõnel juhul 3-4 korda? Kui TCP-ühendus ebaõnnestub, proovib see ühendust saada katkise liidese kaudu. Seda süvendab teenuse tüüpiline käitumine DC-s – ühe kasutaja päringu jaoks genereeritakse N siseteenuste päringut ja vastus saadetakse kasutajale, kas siis, kui kõik andmeallikad vastavad või kui ajalõpp käivitatakse rakenduse tase, mis tuleb veel konfigureerida. See tähendab, et kõik on väga-väga halb.
Nüüd sama katse, kuid voolu silt on lubatud. Nagu näete, langes vasakul meie partii jälgimine sama 25%. See on täiesti õige, sest ta ei tea midagi kordusedastustest, saadab pakette ja loeb lihtsalt kohale toimetatud ja kadunud pakettide arvu suhet.
Ja paremal on teenuste ajakava. Probleemse liigese mõju te siit ei leia. Liiklus liikus samade millisekundite jooksul probleemsest piirkonnast kolmele ülejäänud üleslingile, mida probleem ei mõjutanud. Meil on võrgustik, mis paraneb ise.
See on minu viimane slaid, aeg teha kokkuvõtteid. Nüüd loodan, et teate, kuidas luua iseparanevat andmekeskuste võrku. Te ei pea Linuxi kerneli arhiivi läbi käima ja sealt spetsiaalseid plaastreid otsima, teate, et Flow silt lahendab antud juhul probleemi, kuid peate sellele mehhanismile hoolikalt lähenema. Ja rõhutan veelkord, et kui olete vedaja, siis ärge kasutage voosilti räsifunktsioonina, muidu rikute oma kasutajate seansse.
Võrguinseneride jaoks peab toimuma kontseptuaalne nihe: võrk ei alga ToR-ist, mitte võrguseadmest, vaid hostist. Üsna ilmekas näide on see, kuidas me kasutame eBPF-i nii RTO muutmiseks kui ka voosildi kinnitamiseks anycasti teenuste suunas.
Voolumärgistuse mehaanik sobib kindlasti ka muudeks kasutusteks kontrollitud haldussegmendis. See võib olla andmekeskuste vaheline liiklus või saate sellist mehaanikat erilisel viisil väljamineva liikluse juhtimiseks kasutada. Aga ma loodan, et ma räägin sellest järgmisel korral. Tänan teid väga tähelepanu eest.
Allikas: www.habr.com