Ang modernong mga sentro sa datos adunay gatusan ka aktibo nga mga himan nga nasakup sa lainlaing mga klase sa pag-monitor. Apan bisan ang usa ka hingpit nga inhenyero nga adunay hingpit nga pag-monitor sa kamot makahimo sa husto nga pagtubag sa usa ka kapakyasan sa network sa pipila lang ka minuto. Sa usa ka taho sa komperensya sa Next Hop 2020, gipresentar nako ang usa ka pamaagi sa disenyo sa network sa data center nga adunay usa ka talagsaon nga bahin - ang sentro sa datos nag-ayo sa kaugalingon sa millisecond. Mas tukma, ang inhenyero kalmado nga nag-ayo sa problema, samtang ang mga serbisyo wala makamatikod niini.
Alang sa daghang mga network engineer, ang data center network nagsugod, siyempre, uban sa ToR, nga adunay switch sa rack. Ang ToR kasagaran adunay duha ka matang sa mga link. Ang gagmay nga mga bata moadto sa mga server, ang uban - adunay N ka beses nga mas daghan kanila - moadto sa una nga lebel nga mga tunok, nga mao, sa mga uplink niini. Ang mga uplink kasagarang giisip nga managsama, ug ang trapiko tali sa mga uplink gibalanse base sa 5-tuple hash, nga naglakip sa proto, src_ip, dst_ip, src_port, dst_port. Walay mga surpresa dinhi.
Sunod, unsa ang hitsura sa arkitektura sa mga eroplano? Ang mga tunok sa unang lebel dili konektado sa usag usa, apan konektado pinaagi sa superspins. Ang letra nga X mahimong responsable sa mga superspin, kini halos sama sa usa ka cross-connect.
Ug klaro nga, sa laing bahin, ang tori konektado sa tanan nga mga tunok sa unang lebel. Unsa ang importante niini nga hulagway? Kung kita adunay interaksyon sa sulod sa rack, nan ang interaksyon, siyempre, moagi sa ToR. Kung ang interaksyon moadto sa sulod sa module, nan ang interaksyon moagi sa mga tunok sa unang lebel. Kung intermodular ang interaksyon - sama dinhi, ToR 1 ug ToR 2 - nan ang interaksyon moagi sa mga tunok sa una ug ikaduha nga lebel.
Sa teoriya, ang ingon nga arkitektura dali nga masukod. Kung kita adunay kapasidad sa pantalan, usa ka reserba sa wanang sa data center ug usa ka pre-laid fiber, nan ang gidaghanon sa mga eroplano kanunay nga madugangan, sa ingon nagdugang ang kinatibuk-ang kapasidad sa sistema. Sa papel, kini sayon ββkaayo nga buhaton. Ingon ana unta sa tinuod nga kinabuhi. Apan ang istorya karon dili bahin niana.
Gusto nako ang husto nga mga konklusyon nga makuha. Daghan kami mga agianan sulod sa data center. Sila adunay kondisyon nga independente. Usa ka paagi sa sulod sa data center posible lamang sa sulod sa ToR. Sa sulod sa module, kita adunay parehas nga gidaghanon sa mga agianan sama sa gidaghanon sa mga eroplano. Ang gidaghanon sa mga agianan tali sa mga module parehas sa produkto sa gidaghanon sa mga eroplano ug ang gidaghanon sa mga superspin sa matag eroplano. Aron mas klaro, aron mabati ang sukdanan, ihatag nako ang mga numero nga balido alang sa usa sa mga sentro sa datos sa Yandex.
Adunay walo ka mga eroplano, ang matag eroplano adunay 32 ka superspins. Ingon usa ka sangputanan, nahimo nga adunay walo ka mga agianan sa sulod sa module, ug sa inter-module nga interaksyon adunay 256 na niini.
Kana mao, kung nag-develop kita og Cookbook, naningkamot nga makat-on kung unsaon pagtukod ang mga fault-tolerant data center nga nag-ayo sa ilang kaugalingon, nan ang planar nga arkitektura mao ang husto nga pagpili. Gitugotan ka niini nga masulbad ang problema sa pag-scale, ug sa teorya kini dali. Adunay daghang independente nga mga agianan. Ang pangutana nagpabilin: sa unsang paagi ang ingon nga arkitektura makalahutay sa mga kapakyasan? Adunay lain-laing mga crashes. Ug ato kining hisgotan karon.
Pasagdi nga masakit ang usa sa atong mga superspin. Dinhi mibalik ko sa arkitektura sa duha ka eroplano. Magpabilin kami kanila isip usa ka pananglitan tungod kay mas sayon ββββnga makita kung unsa ang nahitabo dinhi nga adunay gamay nga paglihok nga mga bahin. Pasagdi nga magsakit si X11. Sa unsang paagi kini makaapekto sa mga serbisyo nga nagpuyo sulod sa mga sentro sa datos? Daghan ang nagdepende kung unsa ang hitsura sa kapakyasan.
Kung ang kapakyasan maayo, nadakpan kini sa lebel sa automation sa parehas nga BFD, ang automation malipayon nga nagbutang sa mga problema sa mga lutahan ug gilain ang problema, nan maayo ang tanan. Daghan kami nga mga agianan, ang trapiko gibalhin dayon sa mga alternatibong ruta, ug ang mga serbisyo dili makamatikod bisan unsa. Maayo ni nga senaryo.
Ang usa ka dili maayo nga senaryo mao kung kita adunay kanunay nga pagkawala, ug ang automation wala makamatikod sa problema. Aron masabtan kung giunsa kini makaapekto sa aplikasyon, kinahanglan namon nga mogahin og gamay nga oras sa paghisgot kung giunsa ang TCP protocol molihok.
Nanghinaut ko nga dili nako makurat ang bisan kinsa sa kini nga kasayuran: Ang TCP usa ka protocol sa paglamano. Kana mao, sa pinakasimple nga kaso, ang nagpadala nagpadala og duha ka pakete, ug nakadawat og usa ka cumulative ack sa kanila: "Nakadawat ako og duha ka pakete."
Human niana, magpadala siyag duha pa ka pakete, ug masubli ang kahimtang. Nangayo kog pasaylo daan para sa pagpayano. Husto kini nga senaryo kung ang bintana (gidaghanon sa mga pakete sa paglupad) duha. Siyempre, kini dili kinahanglan nga mahitabo sa kinatibuk-an. Apan ang konteksto sa pagpasa sa pakete wala maapektuhan sa gidak-on sa bintana.
Unsa ang mahitabo kung mawala ang package 3? Sa kini nga kaso, ang nakadawat makadawat mga pakete 1, 2 ug 4. Ug klaro niyang ipahibalo ang nagpadala gamit ang kapilian nga SACK: "Nahibal-an nimo, tulo ang miabot, apan ang tunga nawala." Ingon siya "Ack 2, SACK 4".
Ang nagpadala niining higayona gisubli sa eksakto ang pakete nga nawala nga walaβy mga problema.
Apan kung nawala ang katapusang pakete sa bintana, lahi kaayo ang hitsura sa kahimtang.
Ang nakadawat makadawat sa unang tulo ka pakete ug una sa tanan magsugod sa paghulat. Salamat sa pipila ka mga pag-optimize sa TCP stack sa Linux kernel, kini maghulat alang sa usa ka gipares nga pakete, gawas kung adunay usa ka tin-aw nga timailhan sa mga bandila nga kini ang katapusan nga pakete o ingon niana. Maghulat kini hangtud nga ang Nalangan nga ACK timeout matapos ug dayon ipadala ang usa ka pag-ila alang sa unang tulo ka mga pakete. Apan karon ang nagpadala maghulat. Wa siya masayod kon nawala ba o hapit na moabot ang ikaupat nga pakete. Ug aron dili ma-overload ang network, sulayan nga maghulat alang sa klaro nga timailhan nga nawala ang pakete, o ang pag-expire sa oras sa RTO.
Unsa ang RTO timeout? Kini ang pinakataas gikan sa RTT nga gikalkulo sa TCP stack ug ang uban kanunay. Unsa kini nga kanunay, atong hisgutan karon.
Apan importante nga kung madisgrasya na usab ug mawala na usab ang ikaupat nga pakete, magdoble ang RTO. Sa ato pa, ang matag dili molampos nga pagsulay usa ka pagdoble sa timeout.
Karon tan-awon nato kung unsa ang katumbas niini nga base. Sa kasagaran, ang minimum nga RTO kay 200ms. Kini ang minimum nga RTO alang sa mga pakete sa datos. Alang sa mga pakete sa SYN, lahi kini, 1 segundo. Sama sa imong nakita, bisan ang una nga pagsulay sa pagpadala pag-usab sa mga pakete magkinahanglan og 100 ka beses nga mas taas kaysa RTT sulod sa data center.
Karon balik sa among senaryo. Unsa ang nahitabo sa serbisyo? Ang serbisyo nagsugod sa pagkawala sa mga pakete. Himoa nga ang serbisyo sa sinugdan swerte ug mawad-an sa usa ka butang sa tunga-tunga sa bintana, unya makadawat kini og SACK, ipadala pag-usab ang nawala nga mga pakete.
Pero kung magbalikbalik ang malas, naa tay RTO. Unsa ang importante dinhi? Oo, kami adunay daghang mga agianan sa network. Apan ang trapiko sa TCP sa usa ka partikular nga koneksyon sa TCP magpadayon nga moagi sa parehas nga guba nga stack. Ang pagkawala sa pakete, basta ang among magic X11 dili mogawas sa iyang kaugalingon, dili mosangpot sa trapiko nga moagos ngadto sa mga dapit nga dili problema. Kami naningkamot sa paghatud sa usa ka pakete pinaagi sa parehas nga nabuak nga stack. Kini modala ngadto sa usa ka cascading kapakyasan: ang usa ka data center mao ang usa ka hugpong sa mga interakting nga mga aplikasyon, ug ang pipila sa mga TCP koneksyon sa tanan niini nga mga aplikasyon magsugod sa degrade - tungod kay ang superspin makaapekto sa tanan nga mga aplikasyon nga anaa sa sulod sa DC. Sama sa panultihon: kung dili ka magsapatos sa usa ka kabayo, ang kabayo limps; ang kabayo nagpiang - ang taho wala gihatag; wala gihatag ang mensahe - napildi sila sa gubat. Dinhi lamang ang pag-ihap moadto sa mga segundo gikan sa higayon nga ang problema nahitabo hangtod sa yugto sa pagkadaot nga nagsugod nga gibati ang mga serbisyo. Kini nagpasabut nga ang mga tiggamit mahimong dili makadawat usa ka butang bisan diin.
Adunay duha ka klasiko nga mga solusyon nga nagsangkap sa usag usa. Ang una mao ang mga serbisyo nga naningkamot sa pagbutang og mga straw ug pagsulbad sa problema sama niini: "Atong i-tweak ang usa ka butang sa TCP stack. Ug maghimo ta og mga timeout sa lebel sa aplikasyon o dugay na nga mga sesyon sa TCP nga adunay internal nga pagsusi sa kahimsog. Ang problema mao nga ang ingon nga mga solusyon: a) dili sukdon sa tanan; b) dili maayo nga nasulayan. Kana mao, bisan kung ang serbisyo wala tuyoa nga nag-configure sa TCP stack aron kini mahimong mas maayo, una, kini dili lagmit nga magamit sa tanan nga mga aplikasyon ug sa tanan nga mga sentro sa datos, ug ikaduha, lagmit, dili kini masabtan kung unsa ang gibuhat sa husto ug unsa dili. Kana mao, kini nagtrabaho, apan kini dili maayo nga trabaho ug dili sukod. Ug kung adunay problema sa network, kinsa ang mabasol? Syempre NOC. Unsa ang gibuhat sa NOC?
Daghang mga serbisyo ang nagtuo nga sa NOC, ang trabaho ingon niini. Pero sa tinuod lang, dili lang.
Ang NOC sa klasikal nga laraw naglambigit sa pagpalambo sa daghang pagmonitor. Kini pareho nga black box monitoring ug white box monitoring. Mahitungod sa pananglitan sa black box-monitoring sa mga tunok Alexander Klimenko sa miaging Next Hop. Pinaagi sa dalan, kini nga pag-monitor molihok. Apan bisan ang hingpit nga pag-monitor adunay usa ka lagyo sa oras. Kasagaran kini pipila ka minuto. Human kini molihok, ang mga inhenyero nga nag-duty nanginahanglan ug panahon sa pag-double check sa operasyon niini, pag-localize sa problema, ug dayon pagpalong sa lugar nga adunay problema. Kana mao, sa pinakamaayo nga kaso, ang pagtambal sa problema nagkinahanglan og 5 minutos, sa pinakagrabe nga 20 minutos, kung dili dayon makita kung diin mahitabo ang mga pagkawala. Klaro nga niining tanan nga panahon - 5 o 20 ka minuto - ang among mga serbisyo magpadayon nga masakit, nga tingali dili maayo.
Unsa ang gusto nimong madawat? Daghan kaayo mig dalan. Ug ang mga problema motungha sa tukma tungod kay ang TCP nga mga agos nga dili suwerte nagpadayon sa paggamit sa parehas nga ruta. Nagkinahanglan kami og usa ka butang nga magtugot kanamo sa paggamit sa daghang mga ruta sulod sa usa ka koneksyon sa TCP. Morag naa tay solusyon. Adunay TCP, nga gitawag nga - multipath TCP, nga mao, TCP alang sa daghang mga dalan. Tinuod, kini gihimo alang sa usa ka hingpit nga lahi nga buluhaton - alang sa mga smartphone nga adunay daghang mga aparato sa network. Aron mapadako ang pagbalhin o paghimo sa panguna / backup nga mode, usa ka mekanismo ang naugmad nga klaro nga nagmugna daghang mga hilo (mga sesyon) alang sa aplikasyon ug gitugotan ka nga magbalhin sa taliwala nila kung adunay kapakyasan. O, sama sa akong giingon, i-maximize ang bandwidth.
Apan adunay usa ka nuance dinhi. Aron mahibal-an kung unsa kini, kinahanglan naton tan-awon kung giunsa ang pag-set up sa mga sapa.
Ang mga hilo gipahimutang nga sunud-sunod. Ang una nga sapa gi-install una. Ang mga sunod-sunod nga agos itakda gamit ang cookie nga nauyonan na sulod niana nga hilo. Ug ania ang problema.
Ang problema mao nga kung ang una nga hilo dili ma-install, ang ikaduha ug ikatulo nga mga hilo dili na moabut. Kana mao, ang multipath TCP dili makasulbad sa pagkawala sa SYN packet sa unang sapa. Ug kung nawala ang SYN, ang multipath nga TCP mahimong normal nga TCP. Mao nga, sa usa ka palibot sa data center, dili kini makatabang kanamo nga masulbad ang problema sa mga pagkawala sa pabrika ug mahibal-an kung giunsa ang paggamit sa daghang mga agianan kung adunay kapakyasan.
Unsay makatabang kanato? Ang uban kaninyo nakatag-an na gikan sa ngalan nga ang IPv6 flow label header field mahimong importanteng field sa among dugang nga istorya. Sa tinuud, kini usa ka uma nga makita sa v6, wala kini sa v4, nagkinahanglag 20 bits, ug adunay kontrobersiya bahin sa paggamit niini sa dugay nga panahon. Makapainteres kaayo kini - adunay mga panaglalis, usa ka butang ang giayo sa sulod sa balangkas sa RFC, ug sa parehas nga oras, usa ka pagpatuman ang nagpakita sa kernel sa Linux nga wala gyud madokumento bisan diin.
Gisugyot ko nga apil ka kanako sa usa ka gamay nga imbestigasyon. Atong tan-awon kung unsa ang nahitabo sa Linux kernel sa miaging pipila ka tuig.
tuig 2014. Ang usa ka inhenyero gikan sa usa ka dako ug inila nga kompanya nagdugang sa pag-andar sa Linux kernel ang pagsalig sa kantidad sa label sa dagan sa hash sa socket. Unsa ang ilang gipaningkamutan nga ayohon dinhi? Kini may kalabutan sa RFC 6438 nga naghisgot sa mosunod nga isyu. Sa sulod sa data center, ang IPv4 kanunay nga gi-encapsulated sa IPv6 packets, tungod kay ang pabrika mismo mao ang IPv6, apan ang IPv4 kinahanglan nga ihatag. Sulod sa dugay nga panahon adunay mga problema sa mga switch nga dili makita ubos sa duha ka IP header aron makaadto sa TCP o UDP ug makit-an ang src_ports, dst_ports didto. Nahibal-an nga ang hash, kung imong tan-awon ang una nga duha nga mga header sa IP, nahimo nga hapit naayo. Aron malikayan kini, aron ang pagbalanse niining gi-encapsulated nga trapiko molihok sa husto, kini gisugyot sa pagdugang sa usa ka hash gikan sa 5-tuple encapsulated packet ngadto sa bili sa flow label field. Gibana-bana nga parehas ang gihimo alang sa ubang mga laraw sa encapsulation, alang sa UDP, alang sa GRE, sa ulahi gigamit ang GRE Key field. Sa usa ka paagi o sa lain, ang mga tumong dinhi klaro. Ug labing menos niadtong puntoha sa panahon sila mapuslanon.
Sa 2015, usa ka bag-ong patch gikan sa parehas nga respetado nga inhenyero. Interesado kaayo siya. Kini nag-ingon sa mosunod - kita randomize sa hash sa kaso sa usa ka negatibo nga routing panghitabo. Unsa ang usa ka negatibo nga routing nga panghitabo? Kini ang RTO nga atong gihisgutan sa sayo pa, sa ato pa, ang pagkawala sa ikog sa bintana usa ka panghitabo nga negatibo gyud. Tinuod, medyo lisud ang pagtag-an kung unsa kini.
2016, laing respetado nga kompanya, dako sab. Gi-parse niini ang katapusang mga crutches ug gihimo kini aron ang hash nga kaniadto gihimo namong random mausab na karon sa matag SYN retransmit ug human sa matag RTO timeout. Ug sa kini nga sulat, sa una ug katapusan nga higayon, ang katapusan nga katuyoan tunog - aron masiguro nga ang trapiko kung adunay pagkawala o sobra nga gibug-aton sa mga kanal adunay posibilidad nga hinay nga pag-usab sa ruta, gamit ang daghang mga agianan. Siyempre, pagkahuman niana adunay daghang mga publikasyon, dali nimo kini makit-an.
Bisan kung dili, dili nimo mahimo, tungod kay walaβy usa ka publikasyon bahin niini nga hilisgutan. Apan nahibal-an namon!
Ug kung dili nimo hingpit nga masabtan kung unsa ang nahimo, sultihan ko ikaw karon.
Unsa ang nahimo, unsa nga gamit ang gidugang sa Linux kernel? Ang txhash nagbag-o sa usa ka random nga kantidad pagkahuman sa matag RTO nga panghitabo. Kini mao ang sama nga negatibo nga routing resulta. Ang hash nagdepende niini nga txhash ug ang flow label nagdepende sa skb hash. Adunay pipila ka mga kalkulasyon sa mga gimbuhaton dinhi, ang tanan nga mga detalye dili ibutang sa usa ka slide. Kung adunay interesado, mahimo nimong susihon ang kernel code ug susihon.
Unsa ang importante dinhi? Ang bili sa flow label field mausab ngadto sa random nga numero human sa matag RTO. Sa unsang paagi kini makaapekto sa atong walay suwerte nga TCP stream?
Sa kaso sa usa ka SACK, walaβy nabag-o tungod kay gisulayan namon nga ipadala pag-usab ang nahibal-an nga nawala nga pakete. Sa ingon nga layo sa ingon nga maayo.
Apan sa kaso sa RTO, basta nagdugang kami og label sa dagan sa hash function sa ToR, ang trapiko mahimong moagi sa laing ruta. Ug ang daghang mga eroplano, mas lagmit nga makit-an ang usa ka agianan nga dili maapektuhan sa pagkahagsa sa usa ka partikular nga aparato.
Usa ka problema ang nagpabilin - RTO. Ang laing ruta, siyempre, nakit-an, apan daghang oras ang gigugol niini. Daghan kaayo ang 200ms. Ang ikaduha mao ang kasagaran nga wildness. Sa sayo pa, naghisgot ako bahin sa mga timeout nga nag-configure sa mga serbisyo. Mao nga, ang usa ka segundo usa ka timeout nga kasagarang nagtakda sa usa ka serbisyo sa lebel sa aplikasyon, ug sa kini nga serbisyo mahimong medyo tama. Dugang pa, akong gisubli, ang tinuod nga RTT sa sulod sa usa ka modernong data center kay mga 1 millisecond.
Unsa ang mahimo bahin sa mga oras sa RTO? Ang timeout nga maoy responsable sa RTO sa kaso sa pagkawala sa mga data packet mahimong sayon ββnga ma-configure gikan sa user space: adunay IP utility, ug ang usa sa mga parameter niini naglangkob sa samang rto_min. Sa pagkonsiderar nga, siyempre, kinahanglan nimo nga ibalik ang RTO dili sa tibuuk kalibutan, apan alang sa gihatag nga mga prefix, ang ingon nga mekanismo morag nagtrabaho.
Tinuod, sa SYN_RTO ang tanan mas grabe. Kini natural nga gilansang. Ang bili gitakda sa kinauyokan - 1 segundos, ug mao kana. Dili nimo kini maabot gikan sa user space. Adunay usa lamang ka paagi.
eBPF moabut sa pagluwas. Sa yanong pagkasulti, kini mga gagmay nga mga programa sa C. Mahimo kini nga ibutang sa mga kaw-it sa lainlaing mga lugar sa pagpatuman sa kernel stack ug TCP stack, diin mahimo nimong usbon ang daghang mga setting. Sa kinatibuk-an, ang eBPF usa ka dugay nga uso. Imbis sa paggabas sa daghang mga bag-ong mga parameter sa sysctl ug pagpalapad sa IP utility, ang kalihukan naa sa direksyon sa eBPF ug gipalapad ang pagpaandar niini. Uban sa eBPF, mahimo nimong mabag-o ang mga kontrol sa congestion ug lainlain nga mga setting sa TCP.
Apan hinungdanon alang kanamo nga sa tabang niini mahimo nimo nga i-twist ang mga kantidad sa SYN_RTO. Ug adunay usa ka publiko nga gi-post nga pananglitan: . Unsa ang gibuhat dinhi? Ang panig-ingnan nagtrabaho, apan sa iyang kaugalingon lisud kaayo. Gituohan dinhi nga sa sulod sa data center atong itandi ang unang 44 bits, kon sila magkaparehas, nan atong makita ang atong kaugalingon sulod sa DC. Ug sa kini nga kaso, usbon namo ang bili sa SYN_RTO timeout ngadto sa 4ms. Ang sama nga buluhaton mahimo nga labi ka matahum. Apan kining yano nga pananglitan nagpakita kung unsa ang a) posible; b) medyo sayon.
Unsa may atong nahibaloan? Nga ang planar nga arkitektura nagtugot sa scaling, kini nahimo nga labi ka mapuslanon alang kanamo kung among i-on ang label sa dagan sa ToR ug makuha ang higayon nga mag-agay sa mga lugar nga adunay problema. Ang labing kaayo nga paagi sa pagpaubos sa mga kantidad sa RTO ug SYN-RTO mao ang paggamit sa mga programa sa eBPF. Ang pangutana nagpabilin: luwas ba nga gamiton ang label sa dagan alang sa pagbalanse? Ug adunay usa ka nuance dinhi.
Ibutang ta nga ikaw adunay serbisyo sa network nga nagpuyo sa anycast. Ikasubo, wala akoy panahon sa pag-detalye bahin sa anycast, apan kini usa ka giapod-apod nga serbisyo diin ang lainlaing mga pisikal nga server magamit sa parehas nga IP address. Ug ania ang usa ka posible nga problema: ang RTO nga panghitabo mahimong mahitabo dili lamang kung ang trapiko moagi sa pabrika. Mahimo usab kini mahitabo sa lebel sa buffer sa ToR: kung adunay mahitabo nga incast nga panghitabo, mahimo pa kini mahitabo sa host kung ang host nag-ula sa usa ka butang. Kung mahitabo ang usa ka panghitabo sa RTO ug giusab niini ang label sa dagan. Sa kini nga kaso, ang trapiko mahimong moadto sa lain nga anycast nga pananglitan. Pananglit kini usa ka stateful nga anycast, kini adunay usa ka estado sa koneksyon - mahimo kini usa ka L3 Balancer o uban pang serbisyo. Unya mitungha ang usa ka problema, tungod kay pagkahuman sa RTO, ang koneksyon sa TCP moabut sa server, nga walaβy nahibal-an bahin sa kini nga koneksyon sa TCP. Ug kung wala kami pagpaambit sa estado tali sa bisan unsang mga server sa cast, ang ingon nga trapiko ihulog ug ang koneksyon sa TCP maguba.
Unsa ang mahimo dinhi? Sulod sa imong kontrolado nga palibot, diin imong gi-enable ang pagbalanse sa flow label, kinahanglan nimo nga ayohon ang kantidad sa flow label kung mag-access sa bisan unsang mga server sacast. Ang labing kadali nga paagi mao ang pagbuhat niini pinaagi sa parehas nga programa sa eBPF. Apan ania ang usa ka hinungdanon kaayo nga punto - unsa ang buhaton kung dili ka mag-operate sa usa ka network sa data center, apan usa ka operator sa telecom? Kini ang imong problema usab: sugod sa pipila nga mga bersyon sa Juniper ug Arista, gilakip nila ang label sa dagan sa hash function nga default - aron matinuoron, sa usa ka hinungdan nga wala nako masabtan. Mahimo kini nga hinungdan nga imong ihulog ang mga koneksyon sa TCP gikan sa mga tiggamit nga moagi sa imong network. Busa, girekomendar nako nga susihon ang imong mga setting sa router sa kini nga lokasyon.
Sa usa ka paagi o sa lain, para nako andam na kami nga magpadayon sa mga eksperimento.
Sa dihang among gi-on ang flow label sa ToR, giandam ang eBPF sa ahente, nga karon nagpuyo sa mga host, kami nakahukom nga dili na maghulat alang sa sunod nga dako nga kapakyasan, apan sa pagpahigayon sa kontrolado nga mga pagbuto. Gikuha namo ang ToR, nga adunay upat ka mga uplink, ug naghimo og mga tulo sa usa niini. Naghimo sila usa ka lagda, ingon nila - karon nawala nimo ang tanan nga mga pakete. Sama sa imong makita sa wala, kami adunay per-packet monitoring, nga mius-os ngadto sa 75%, sa ato pa, 25% sa mga pakete ang nawala. Sa tuo mao ang mga graph sa mga serbisyo nga nagpuyo luyo niini nga ToR. Sa tinuud, kini ang mga graph sa trapiko sa mga lutahan nga adunay mga server sa sulod sa rack. Sama sa imong nakita, sila naunlod bisan sa ubos. Ngano nga sila nahulog nga mas ubos - dili sa 25%, apan sa pipila ka mga kaso sa 3-4 ka beses? Kung ang koneksyon sa TCP dili swerte, kini nagpadayon sa pagsulay sa pagkab-ot pinaagi sa guba nga interface. Gipasamot kini sa kasagaran nga kinaiya sa serbisyo sulod sa DC - alang sa usa ka hangyo sa user, ang N hangyo sa internal nga mga serbisyo nahimo, ug ang tubag moadto sa user, bisan kung ang tanan nga mga tinubdan sa datos motubag, o kung ang usa ka timeout ma-trigger sa ang lebel sa aplikasyon, nga kinahanglan pa nga i-configure. Sa ato pa, ang tanan daotan kaayo.
Karon ang parehas nga eksperimento, apan gipaandar ang label sa dagan. Sama sa imong makita, sa wala, ang among batch nga pag-monitor nahulog sa parehas nga 25%. Kini hingpit nga husto, tungod kay wala kini nahibal-an bahin sa mga retransmit, nagpadala kini og mga pakete ug nag-ihap lamang sa ratio sa gidaghanon sa mga gipadala ug nawala nga mga pakete.
Ug sa tuo mao ang eskedyul sa mga serbisyo. Dili nimo makit-an ang epekto sa usa ka problema nga hiniusa dinhi. Ang trapiko sa parehas nga millisecond midagayday gikan sa lugar nga adunay problema hangtod sa tulo nga nahabilin nga mga uplink nga wala maapektuhan sa problema. Kami adunay usa ka network nga nag-ayo sa iyang kaugalingon.
Kini ang akong katapusan nga slide, panahon sa pag-stock. Karon, nanghinaut ko nga nahibal-an nimo kung giunsa ang paghimo sa usa ka network nga sentro sa datos sa pag-ayo sa kaugalingon. Dili nimo kinahanglan nga moagi sa Linux kernel archive ug mangita alang sa mga espesyal nga patch didto, nahibal-an nimo nga ang Flow label nagsulbad sa problema sa kini nga kaso, apan kinahanglan nimo nga duolon kini nga mekanismo pag-ayo. Ug gipasiugda nako pag-usab nga kung ikaw usa ka carrier, dili nimo gamiton ang label sa dagan ingon usa ka hash function, kung dili nimo mabuak ang mga sesyon sa imong mga tiggamit.
Alang sa mga inhenyero sa network, kinahanglan nga mahitabo ang usa ka pagbalhin sa konsepto: ang network wala magsugod sa ToR, dili sa usa ka aparato sa network, apan sa usa ka host. Ang usa ka makapakurat nga panig-ingnan mao kung giunsa naton gigamit ang eBPF pareho aron mabag-o ang RTO ug aron ayohon ang label sa dagan padulong sa bisan unsang serbisyo sa pagcast.
Ang mekaniko sa label sa daloy sigurado nga angay alang sa uban pang mga gamit sa sulod sa kontrolado nga bahin sa administratibo. Mahimo kini nga trapiko tali sa mga sentro sa datos, o mahimo nimong gamiton ang ingon nga mga mekaniko sa usa ka espesyal nga paagi aron makontrol ang paggawas nga trapiko. Apan hisgutan ko kini, hinaut, sa sunod. Salamat kaayo sa imong pagtagad.
Source: www.habr.com