Ang mga modernong data center ay may daan-daang aktibong device na sakop ng iba't ibang uri ng pagsubaybay. Ngunit kahit na ang isang perpektong engineer na may perpektong pagsubaybay sa kamay ay magagawang maayos na tumugon sa isang pagkabigo sa network sa loob lamang ng ilang minuto. Sa isang ulat sa kumperensya ng Next Hop 2020, ipinakita ko ang isang pamamaraan ng disenyo ng network ng data center na may natatanging tampok - ang data center ay nagpapagaling sa sarili sa loob ng millisecond. Mas tiyak, ang inhinyero ay mahinahon na inaayos ang problema, habang ang mga serbisyo ay hindi lamang napapansin ito.
Para sa maraming mga network engineer, ang data center network ay nagsisimula, siyempre, sa ToR, na may switch sa rack. Ang ToR ay karaniwang may dalawang uri ng mga link. Ang mga maliliit ay pumunta sa mga server, ang iba - mayroong N beses na higit pa sa kanila - pumunta sa unang antas ng mga spine, iyon ay, sa mga uplink nito. Ang mga uplink ay karaniwang itinuturing na pantay, at ang trapiko sa pagitan ng mga uplink ay balanse batay sa 5-tuple hash, na kinabibilangan ng proto, src_ip, dst_ip, src_port, dst_port. Walang mga sorpresa dito.
Susunod, ano ang hitsura ng arkitektura ng mga eroplano? Ang mga spine ng unang antas ay hindi konektado sa isa't isa, ngunit konektado sa pamamagitan ng superspins. Ang titik X ay magiging responsable para sa mga superspin, ito ay halos tulad ng isang cross-connect.
At ito ay malinaw na, sa kabilang banda, ang tori ay konektado sa lahat ng mga spine ng unang antas. Ano ang mahalaga sa larawang ito? Kung mayroon kaming pakikipag-ugnayan sa loob ng rack, kung gayon ang pakikipag-ugnayan, siyempre, ay dumadaan sa ToR. Kung ang pakikipag-ugnayan ay napupunta sa loob ng modyul, ang pakikipag-ugnayan ay dumaan sa mga tinik ng unang antas. Kung intermodular ang interaksyon - gaya dito, ToR 1 at ToR 2 - ang interaksyon ay dadaan sa mga spine ng una at pangalawang antas.
Sa teorya, ang ganitong arkitektura ay madaling masusukat. Kung mayroon tayong port capacity, isang reserbang espasyo sa data center at isang pre-laid fiber, kung gayon ang bilang ng mga eroplano ay maaaring palaging tumaas, at sa gayon ay tumataas ang kabuuang kapasidad ng system. Sa papel, ito ay napakadaling gawin. Magiging ganyan sa totoong buhay. Ngunit ang kwento ngayon ay hindi tungkol doon.
Gusto kong makagawa ng tamang konklusyon. Marami kaming mga landas sa loob ng data center. Sila ay may kondisyon na independyente. Ang isang paraan sa loob ng data center ay posible lamang sa loob ng ToR. Sa loob ng module, mayroon kaming parehong bilang ng mga landas sa bilang ng mga eroplano. Ang bilang ng mga landas sa pagitan ng mga module ay katumbas ng produkto ng bilang ng mga eroplano at ang bilang ng mga superspin sa bawat eroplano. Upang gawing mas malinaw, upang madama ang sukat, ibibigay ko ang mga numero na wasto para sa isa sa mga sentro ng data ng Yandex.
Mayroong walong eroplano, bawat eroplano ay may 32 superspins. Bilang resulta, lumalabas na mayroong walong mga landas sa loob ng modyul, at sa inter-module na interaksyon ay mayroon nang 256 sa kanila.
Iyon ay, kung bubuo tayo ng Cookbook, sinusubukang matutunan kung paano bumuo ng mga fault-tolerant na data center na nagpapagaling sa kanilang mga sarili, kung gayon ang planar architecture ang tamang pagpipilian. Pinapayagan ka nitong lutasin ang problema sa pag-scale, at sa teoryang ito ay madali. Mayroong maraming mga independiyenteng landas. Ang tanong ay nananatili: paano nakaligtas ang gayong arkitektura sa mga pagkabigo? Mayroong iba't ibang mga pag-crash. At pag-uusapan natin ito ngayon.
Hayaang magkasakit ang isa sa ating mga superspin. Dito ako bumalik sa arkitektura ng dalawang eroplano. Mananatili kami sa kanila bilang isang halimbawa dahil mas madaling makita kung ano ang nangyayari dito na may mas kaunting mga gumagalaw na bahagi. Hayaang magkasakit ang X11. Paano ito makakaapekto sa mga serbisyong nakatira sa loob ng mga data center? Marami ang nakasalalay sa kung ano talaga ang hitsura ng kabiguan.
Kung ang kabiguan ay mabuti, ito ay nahuli sa antas ng automation ng parehong BFD, ang automation ay masayang naglalagay ng mga joints ng problema at ihiwalay ang problema, kung gayon ang lahat ay maayos. Mayroon kaming maraming mga landas, ang trapiko ay agad na inilipat sa mga alternatibong ruta, at ang mga serbisyo ay walang mapapansin. Ito ay isang magandang senaryo.
Ang isang masamang senaryo ay kung mayroon tayong patuloy na pagkalugi, at hindi napapansin ng automation ang problema. Upang maunawaan kung paano ito nakakaapekto sa application, kakailanganin naming gumugol ng kaunting oras sa pagtalakay kung paano gumagana ang TCP protocol.
Sana ay hindi ko mabigla ang sinuman sa impormasyong ito: Ang TCP ay isang handshake protocol. Iyon ay, sa pinakasimpleng kaso, ang nagpadala ay nagpapadala ng dalawang packet, at tumatanggap ng pinagsama-samang ack sa kanila: "Nakatanggap ako ng dalawang packet."
Pagkatapos nito, magpapadala siya ng dalawa pang pakete, at mauulit ang sitwasyon. Humihingi ako ng paumanhin nang maaga para sa ilang pagpapasimple. Ang senaryo na ito ay tama kung ang window (bilang ng mga packet sa paglipad) ay dalawa. Siyempre, hindi ito ang kaso sa pangkalahatan. Ngunit ang konteksto ng pagpapasa ng packet ay hindi apektado ng laki ng window.
Ano ang mangyayari kung mawala ang package 3? Sa kasong ito, ang tatanggap ay makakatanggap ng mga packet 1, 2 at 4. At tahasan niyang ipapaalam sa nagpadala gamit ang SACK na opsyon: "Alam mo, tatlo ang dumating, ngunit ang gitna ay nawala." Sabi niya "Ack 2, SACK 4".
Ang nagpadala sa sandaling ito ay eksaktong inuulit ang packet na nawala nang walang anumang problema.
Ngunit kung ang huling pakete sa window ay nawala, ang sitwasyon ay magiging ibang-iba.
Natatanggap ng tatanggap ang unang tatlong packet at una sa lahat ay magsisimulang maghintay. Salamat sa ilang mga pag-optimize sa Linux kernel TCP stack, maghihintay ito para sa isang ipinares na packet, maliban kung may tahasang indikasyon sa mga flag na ito ang huling packet o isang katulad nito. Maghihintay ito hanggang sa mag-expire ang Delayed ACK timeout at pagkatapos ay magpadala ng acknowledgement para sa unang tatlong packet. Ngunit ngayon ang nagpadala ay maghihintay. Hindi niya alam kung nawala ang pang-apat na pakete o malapit nang dumating. At upang hindi ma-overload ang network, susubukan nitong maghintay para sa tahasang indikasyon na nawala ang packet, o ang pag-expire ng timeout ng RTO.
Ano ang RTO timeout? Ito ang maximum mula sa RTT na kinakalkula ng TCP stack at ilang pare-pareho. Ano ang pare-parehong ito, tatalakayin natin ngayon.
Ngunit mahalaga na kung tayo ay malas muli at ang ikaapat na pakete ay nawala muli, pagkatapos ay ang RTO ay doble. Ibig sabihin, ang bawat hindi matagumpay na pagtatangka ay pagdodoble ng timeout.
Ngayon tingnan natin kung ano ang katumbas ng base na ito. Bilang default, ang minimum na RTO ay 200ms. Ito ang pinakamababang RTO para sa mga data packet. Para sa mga SYN packet, iba ito, 1 segundo. Tulad ng nakikita mo, kahit na ang unang pagtatangka na muling magpadala ng mga packet ay aabutin ng 100 beses na mas mahaba kaysa sa RTT sa loob ng data center.
Ngayon bumalik sa aming senaryo. Ano ang nangyayari sa serbisyo? Nagsisimulang mawalan ng mga packet ang serbisyo. Hayaan ang serbisyo na maging masuwerteng sa simula at mawalan ng isang bagay sa gitna ng window, pagkatapos ay makakatanggap ito ng SACK, muling ipadala ang mga nawawalang packet.
Ngunit kung mauulit ang malas, mayroon tayong RTO. Ano ang mahalaga dito? Oo, marami tayong landas sa network. Ngunit ang trapiko ng TCP ng isang partikular na koneksyon sa TCP ay patuloy na dadaan sa parehong sirang stack. Ang pagkawala ng packet, sa kondisyon na ang aming magic X11 ay hindi lumabas sa sarili nitong, ay hindi humahantong sa daloy ng trapiko sa mga lugar na hindi problema. Sinusubukan naming maghatid ng isang packet sa parehong sirang stack. Ito ay humahantong sa isang cascading failure: ang isang data center ay isang set ng mga nakikipag-ugnayan na application, at ang ilan sa mga TCP na koneksyon ng lahat ng mga application na ito ay nagsisimulang bumaba - dahil ang superspin ay nakakaapekto sa lahat ng mga application na nasa loob ng DC. Tulad ng kasabihan: kung hindi ka nagsapatos ng kabayo, ang kabayo ay napipiya; ang kabayo limped - ang ulat ay hindi naihatid; hindi naihatid ang mensahe - natalo sila sa digmaan. Dito lamang napupunta ang bilang ng mga segundo mula sa sandaling mangyari ang problema hanggang sa yugto ng pagkasira na nagsimulang maramdaman ng mga serbisyo. Nangangahulugan ito na ang mga gumagamit ay maaaring hindi makatanggap ng isang bagay sa isang lugar.
Mayroong dalawang klasikong solusyon na umakma sa isa't isa. Ang una ay ang mga serbisyong nagsisikap na maglatag ng mga dayami at lutasin ang problemang tulad nito: βMag-tweak tayo ng isang bagay sa TCP stack. At gumawa tayo ng mga timeout sa antas ng aplikasyon o pangmatagalang session ng TCP na may mga panloob na pagsusuri sa kalusugan. Ang problema ay ang mga ganitong solusyon: a) hindi man lang sukat; b) napakahusay na nasubok. Iyon ay, kahit na ang serbisyo ay hindi sinasadyang na-configure ang TCP stack upang ito ay maging mas mahusay, una, ito ay malamang na hindi naaangkop sa lahat ng mga application at lahat ng mga data center, at pangalawa, malamang, hindi nito mauunawaan kung ano ang ginawa nang tama at kung ano hindi. Iyon ay, ito ay gumagana, ngunit ito ay gumagana nang hindi maganda at hindi sukat. At kung may problema sa network, sino ang dapat sisihin? Syempre NOC. Ano ang ginagawa ng NOC?
Maraming mga serbisyo ang naniniwala na sa NOC, ang trabaho ay ganito. Ngunit upang maging tapat, hindi lamang.
Ang NOC sa klasikal na pamamaraan ay nakikibahagi sa pagbuo ng maraming pagsubaybay. Ang mga ito ay parehong black box monitoring at white box monitoring. Tungkol sa halimbawa ng black box-monitoring ng mga spines Alexander Klimenko sa nakaraang Next Hop. Sa pamamagitan ng paraan, gumagana ang pagsubaybay na ito. Ngunit kahit na ang perpektong pagsubaybay ay magkakaroon ng time lag. Kadalasan ito ay ilang minuto. Matapos itong gumana, ang mga inhinyero na naka-duty ay nangangailangan ng oras upang i-double-check ang operasyon nito, i-localize ang problema, at pagkatapos ay patayin ang lugar ng problema. Iyon ay, sa pinakamahusay na kaso, ang paggamot sa problema ay tumatagal ng 5 minuto, sa pinakamasamang 20 minuto, kung hindi kaagad malinaw kung saan nangyayari ang mga pagkalugi. Malinaw na sa lahat ng oras na ito - 5 o 20 minuto - ang aming mga serbisyo ay patuloy na masasaktan, na marahil ay hindi maganda.
Ano ang gusto mong matanggap? Marami tayong landas. At tiyak na lumitaw ang mga problema dahil ang mga daloy ng TCP na hindi pinalad ay patuloy na gumagamit ng parehong ruta. Kailangan namin ng isang bagay na magbibigay-daan sa amin na gumamit ng maraming ruta sa loob ng iisang koneksyon sa TCP. Mukhang may solusyon na tayo. Mayroong TCP, na tinatawag na - multipath TCP, iyon ay, TCP para sa maraming mga landas. Totoo, ito ay binuo para sa isang ganap na naiibang gawain - para sa mga smartphone na may ilang mga aparato sa network. Upang i-maximize ang paglipat o gawin ang pangunahing / backup na mode, isang mekanismo ang binuo na malinaw na lumilikha ng ilang mga thread (session) para sa application at pinapayagan kang lumipat sa pagitan ng mga ito kung sakaling mabigo. O, gaya ng sinabi ko, i-maximize ang bandwidth.
Ngunit mayroong isang nuance dito. Upang maunawaan kung ano ito, kailangan nating tingnan kung paano naka-set up ang mga stream.
Ang mga thread ay nakatakda nang sunud-sunod. Ang unang stream ay unang naka-install. Ang mga kasunod na daloy ay itatakda gamit ang cookie na napagkasunduan na sa loob ng thread na iyon. At narito ang problema.
Ang problema ay kung ang unang thread ay hindi na-install, ang pangalawa at pangatlong thread ay hindi kailanman lalabas. Iyon ay, hindi malulutas ng multipath TCP ang pagkawala ng SYN packet sa unang stream. At kung nawala ang SYN, ang multipath na TCP ay magiging normal na TCP. Kaya, sa isang kapaligiran ng data center, hindi ito makakatulong sa amin na malutas ang problema ng mga pagkalugi sa pabrika at matutunan kung paano gumamit ng maraming mga landas kung sakaling mabigo.
Ano ang makakatulong sa atin? Ang ilan sa inyo ay nahulaan na mula sa pangalan na ang mahalagang field sa aming karagdagang kuwento ay ang IPv6 flow label header field. Sa katunayan, ito ay isang field na lumilitaw sa v6, wala ito sa v4, ito ay tumatagal ng 20 bits, at nagkaroon ng kontrobersya tungkol sa paggamit nito sa loob ng mahabang panahon. Ito ay lubhang kawili-wili - may mga hindi pagkakaunawaan, isang bagay ay naayos sa loob ng balangkas ng RFC, at sa parehong oras, isang pagpapatupad ay lumitaw sa Linux kernel na hindi kailanman naidokumento kahit saan.
Iminumungkahi kong samahan mo ako sa isang maliit na pagsisiyasat. Tingnan natin kung ano ang nangyayari sa Linux kernel sa nakalipas na ilang taon.
taong 2014. Ang isang inhinyero mula sa isang malaki at kagalang-galang na kumpanya ay nagdaragdag sa pag-andar ng Linux kernel ang pag-asa ng halaga ng label ng daloy sa hash ng socket. Ano ang sinusubukan nilang ayusin dito? Ito ay may kaugnayan sa RFC 6438 na tinalakay ang sumusunod na isyu. Sa loob ng data center, madalas na naka-encapsulate ang IPv4 sa mga IPv6 packet, dahil ang mismong pabrika ay IPv6, ngunit dapat na maibigay ang IPv4. Sa mahabang panahon may mga problema sa mga switch na hindi maaaring tumingin sa ilalim ng dalawang IP header upang makapunta sa TCP o UDP at makahanap ng src_ports, dst_ports doon. Ito ay lumabas na ang hash, kung titingnan mo ang unang dalawang IP header, ay naging halos maayos. Upang maiwasan ito, upang gumana nang tama ang pagbabalanse ng naka-encapsulated na trapikong ito, iminungkahi na magdagdag ng hash mula sa 5-tuple na naka-encapsulated na packet sa halaga ng field ng label ng daloy. Tinatayang pareho ang ginawa para sa iba pang mga encapsulation scheme, para sa UDP, para sa GRE, sa huli ay ginamit ang GRE Key field. Sa isang paraan o iba pa, ang mga layunin dito ay malinaw. At least sa puntong iyon ay naging kapaki-pakinabang sila.
Noong 2015, isang bagong patch ang nagmula sa parehong iginagalang na engineer. Siya ay napaka-interesante. Sinasabi nito ang sumusunod - isa-random namin ang hash kung sakaling magkaroon ng negatibong kaganapan sa pagruruta. Ano ang isang negatibong kaganapan sa pagruruta? Ito ang RTO na napag-usapan natin kanina, ibig sabihin, ang pagkawala ng buntot ng bintana ay isang kaganapan na talagang negatibo. Totoo, medyo mahirap hulaan kung ano ito.
2016, another respected company, malaki din. Pina-parse nito ang mga huling saklay at ginagawa ito upang ang hash na dati naming ginawang random ay nabago na ngayon sa bawat SYN retransmit at pagkatapos ng bawat RTO timeout. At sa liham na ito, sa una at huling pagkakataon, ang tunay na layunin ay tunog - upang matiyak na ang trapiko sa kaganapan ng pagkawala o labis na karga ng mga channel ay may posibilidad ng malambot na pag-rerouting, gamit ang maraming mga landas. Siyempre, pagkatapos noon ay maraming publikasyon, madali mong mahahanap ang mga ito.
Bagama't hindi, hindi mo magagawa, dahil wala pang isang publikasyon sa paksang ito. Pero alam namin!
At kung hindi mo lubos na nauunawaan ang ginawa, sasabihin ko sa iyo ngayon.
Ano ang nagawa, anong functionality ang naidagdag sa Linux kernel? Nagbabago ang txhash sa isang random na halaga pagkatapos ng bawat kaganapan sa RTO. Ito ang parehong negatibong resulta ng pagruruta. Ang hash ay depende sa txhash na ito at ang flow label ay depende sa skb hash. Mayroong ilang mga kalkulasyon sa mga pag-andar dito, ang lahat ng mga detalye ay hindi maaaring ilagay sa isang slide. Kung ang sinuman ay mausisa, maaari kang pumunta sa kernel code at suriin.
Ano ang mahalaga dito? Ang halaga ng field ng label ng daloy ay nagbabago sa isang random na numero pagkatapos ng bawat RTO. Paano ito nakakaapekto sa aming malas na stream ng TCP?
Sa kaso ng SACK, walang nagbago dahil sinusubukan naming ipadala muli ang isang kilalang nawawalang packet. So far so good.
Ngunit sa kaso ng RTO, sa kondisyon na nagdagdag kami ng label ng daloy sa hash function sa ToR, maaaring mag-iba ang ruta ng trapiko. At kung mas maraming eroplano, mas malamang na makahanap ng landas na hindi apektado ng pag-crash sa isang partikular na device.
Isang problema ang nananatili - RTO. Ang isa pang ruta, siyempre, ay matatagpuan, ngunit maraming oras ang ginugol dito. Ang 200ms ay marami. Ang isang segundo ay karaniwang ligaw. Kanina, pinag-usapan ko ang tungkol sa mga timeout na nagko-configure ng mga serbisyo. Kaya, ang isang segundo ay isang timeout na karaniwang nagse-set up ng isang serbisyo sa antas ng aplikasyon, at dito ang serbisyo ay magiging medyo tama. Bukod dito, inuulit ko, ang tunay na RTT sa loob ng modernong data center ay humigit-kumulang 1 millisecond.
Ano ang maaaring gawin tungkol sa mga timeout ng RTO? Ang timeout na responsable para sa RTO sa kaso ng pagkawala ng mga data packet ay maaaring medyo madaling i-configure mula sa espasyo ng gumagamit: mayroong isang IP utility, at ang isa sa mga parameter nito ay naglalaman ng parehong rto_min. Isinasaalang-alang na, siyempre, kailangan mong i-RTO hindi sa buong mundo, ngunit para sa mga ibinigay na prefix, ang gayong mekanismo ay mukhang gumagana.
Totoo, sa SYN_RTO lahat ay medyo mas malala. Ito ay natural na napapako. Ang halaga ay naayos sa core - 1 segundo, at iyon na. Hindi mo ito maaabot mula sa espasyo ng user. May isang paraan lamang.
Ang eBPF ay sumagip. Sa madaling salita, ito ay mga maliliit na programang C. Maaari silang ipasok sa mga kawit sa iba't ibang lugar sa pagpapatupad ng kernel stack at TCP stack, kung saan maaari mong baguhin ang napakalaking bilang ng mga setting. Sa pangkalahatan, ang eBPF ay isang pangmatagalang trend. Sa halip na maglagari ng dose-dosenang mga bagong parameter ng sysctl at palawakin ang IP utility, ang paggalaw ay nasa direksyon ng eBPF at pinalawak ang functionality nito. Sa eBPF, maaari mong dynamic na baguhin ang mga kontrol ng congestion at iba't ibang mga setting ng TCP.
Ngunit mahalaga para sa amin na sa tulong nito maaari mong i-twist ang mga halaga ng SYN_RTO. At mayroong isang pampublikong nai-post na halimbawa: . Ano ang ginagawa dito? Ang halimbawa ay gumagana, ngunit sa kanyang sarili ay napaka-magaspang. Ipinapalagay dito na sa loob ng data center inihahambing natin ang unang 44 bits, kung magkatugma ang mga ito, makikita natin ang ating sarili sa loob ng DC. At sa kasong ito, binabago namin ang halaga ng SYN_RTO timeout sa 4ms. Ang parehong gawain ay maaaring gawin nang mas maganda. Ngunit ang simpleng halimbawang ito ay nagpapakita kung ano ang a) posible; b) medyo madali.
Ano ang alam na natin? Na ang planar architecture ay nagbibigay-daan sa pag-scale, lumalabas na lubhang kapaki-pakinabang para sa amin kapag binuksan namin ang label ng daloy sa ToR at nakakuha ng pagkakataong dumaloy sa mga lugar na may problema. Ang pinakamahusay na paraan upang mapababa ang mga halaga ng RTO at SYN-RTO ay ang paggamit ng mga programang eBPF. Ang tanong ay nananatili: ligtas bang gamitin ang label ng daloy para sa pagbabalanse? At mayroong isang nuance dito.
Ipagpalagay na mayroon kang serbisyo sa network na nakatira sa anycast. Sa kasamaang-palad, wala akong panahon upang magdetalye tungkol sa anycast, ngunit isa itong distributed na serbisyo kung saan available ang iba't ibang pisikal na server sa parehong IP address. At narito ang isang posibleng problema: ang kaganapan sa RTO ay maaaring mangyari hindi lamang kapag dumaan ang trapiko sa pabrika. Maaari rin itong mangyari sa antas ng buffer ng ToR: kapag naganap ang isang incast na kaganapan, maaari pa itong mangyari sa host kapag may naibuhos ang host. Kapag naganap ang isang kaganapan sa RTO at binago nito ang label ng daloy. Sa kasong ito, ang trapiko ay maaaring pumunta sa isa pang anycast instance. Ipagpalagay na ito ay isang stateful na anycast, naglalaman ito ng estado ng koneksyon - maaari itong maging isang L3 Balancer o ilang iba pang serbisyo. Pagkatapos ay lumitaw ang isang problema, dahil pagkatapos ng RTO, ang koneksyon ng TCP ay dumating sa server, na walang alam tungkol sa koneksyon sa TCP na ito. At kung wala kaming pagbabahagi ng estado sa pagitan ng mga server ng anycast, mawawala ang naturang trapiko at masisira ang koneksyon ng TCP.
Ano ang maaaring gawin dito? Sa loob ng iyong kinokontrol na kapaligiran, kung saan mo pinagana ang pagbabalanse ng label ng daloy, kailangan mong ayusin ang halaga ng label ng daloy kapag ina-access ang mga server ng anycast. Ang pinakamadaling paraan ay gawin ito sa pamamagitan ng parehong eBPF program. Ngunit narito ang isang napakahalagang punto - ano ang gagawin kung hindi ka nagpapatakbo ng isang network ng data center, ngunit isang operator ng telecom? Ito rin ang problema mo: simula sa ilang bersyon ng Juniper at Arista, isinama nila ang flow label sa hash function bilang default - sa totoo lang, sa hindi ko maintindihang dahilan. Ito ay maaaring magdulot sa iyo ng pagbaba ng mga koneksyon sa TCP mula sa mga user na dumadaan sa iyong network. Samakatuwid, lubos kong inirerekumenda na suriin ang iyong mga setting ng router sa lokasyong ito.
Sa isang paraan o iba pa, tila sa akin ay handa na tayong magpatuloy sa mga eksperimento.
Nang i-on namin ang flow label sa ToR, inihanda ang eBPF ng ahente, na nabubuhay na ngayon sa mga host, nagpasya kaming hindi na maghintay para sa susunod na malaking kabiguan, ngunit magsagawa ng mga kinokontrol na pagsabog. Kinuha namin ang ToR, na may apat na uplink, at ginawa ang mga patak sa isa sa mga ito. Gumawa sila ng isang panuntunan, sabi nila - ngayon ay nawawala ang lahat ng mga packet. Tulad ng makikita mo sa kaliwa, mayroon kaming per-packet monitoring, na bumaba sa 75%, iyon ay, 25% ng mga packet ang nawala. Sa kanan ay ang mga graph ng mga serbisyong nabubuhay sa likod ng ToR na ito. Sa katunayan, ito ay mga graph ng trapiko ng mga joint na may mga server sa loob ng rack. Tulad ng makikita mo, sila ay lumubog nang mas mababa. Bakit sila lumubog nang mas mababa - hindi ng 25%, ngunit sa ilang mga kaso ng 3-4 na beses? Kung ang koneksyon ng TCP ay hindi pinalad, patuloy itong sumusubok na maabot ang sirang interface. Pinalala pa ito ng karaniwang pag-uugali ng serbisyo sa loob ng DC - para sa isang kahilingan ng user, nabuo ang N kahilingan sa mga panloob na serbisyo, at mapupunta ang tugon sa user, alinman kapag tumugon ang lahat ng data source, o kapag na-trigger ang timeout sa ang antas ng aplikasyon, na kailangan pa ring i-configure. Ibig sabihin, lahat ay napaka, napakasama.
Ngayon ang parehong eksperimento, ngunit naka-enable ang label ng daloy. Tulad ng makikita mo, sa kaliwa, ang aming batch monitoring ay lumubog ng parehong 25%. Ito ay ganap na tama, dahil wala itong alam tungkol sa mga retransmit, nagpapadala ito ng mga packet at binibilang lamang ang ratio ng bilang ng naihatid at nawala na mga packet.
At sa kanan ay ang iskedyul ng mga serbisyo. Hindi mo makikita ang epekto ng magkasanib na problema dito. Ang trapiko sa parehong millisecond na iyon ay dumaloy mula sa lugar ng problema patungo sa tatlong natitirang mga uplink na hindi naapektuhan ng problema. Mayroon kaming isang network na nagpapagaling sa sarili.
Ito ang aking huling slide, oras na upang mag-stock. Ngayon, sana alam mo kung paano bumuo ng isang self-healing data center network. Hindi mo na kailangang dumaan sa Linux kernel archive at maghanap ng mga espesyal na patch doon, alam mo na nalulutas ng label ng Flow ang problema sa kasong ito, ngunit kailangan mong lapitan nang mabuti ang mekanismong ito. At muli kong binibigyang-diin na kung isa kang carrier, hindi mo dapat gamitin ang flow label bilang hash function, kung hindi, masisira mo ang mga session ng iyong mga user.
Para sa mga network engineer, kailangang maganap ang isang conceptual shift: ang network ay hindi nagsisimula sa ToR, hindi sa isang network device, ngunit sa isang host. Ang isang medyo kapansin-pansin na halimbawa ay kung paano namin ginagamit ang eBPF kapwa upang baguhin ang RTO at upang ayusin ang label ng daloy patungo sa mga serbisyo ng anycast.
Ang flow label mechanic ay tiyak na angkop para sa iba pang gamit sa loob ng kinokontrol na administratibong segment. Ito ay maaaring trapiko sa pagitan ng mga data center, o maaari mong gamitin ang mga naturang mekanika sa isang espesyal na paraan upang makontrol ang papalabas na trapiko. Pero pag-uusapan ko ito, sana sa susunod. Maraming salamat sa iyong atensyon.
Pinagmulan: www.habr.com