Nakabuo kami ng disenyo ng network ng data center na nagbibigay-daan sa pag-deploy ng mga computing cluster na mas malaki sa 100 libong mga server na may peak bisection bandwidth na higit sa isang petabyte bawat segundo.
Mula sa ulat ni Dmitry Afanasyev matututunan mo ang tungkol sa mga pangunahing prinsipyo ng bagong disenyo, mga scaling topologies, ang mga problema na lumitaw dito, mga pagpipilian para sa paglutas ng mga ito, ang mga tampok ng pagruruta at pag-scale ng pagpapasa ng mga function ng eroplano ng mga modernong aparato sa network sa "makapal na konektado" topologies na may malaking bilang ng mga ruta ng ECMP. Bilang karagdagan, maikling nagsalita si Dima tungkol sa organisasyon ng panlabas na koneksyon, ang pisikal na layer, ang sistema ng paglalagay ng kable at mga paraan upang higit pang madagdagan ang kapasidad.
- Magandang hapon sa lahat! Ang pangalan ko ay Dmitry Afanasyev, ako ay isang arkitekto ng network sa Yandex at pangunahing nagdidisenyo ng mga network ng data center.
Ang aking kwento ay tungkol sa na-update na network ng mga sentro ng data ng Yandex. Ito ay isang ebolusyon ng disenyo na mayroon kami, ngunit sa parehong oras ay may ilang mga bagong elemento. Ito ay isang pangkalahatang-ideya na pagtatanghal dahil mayroong maraming impormasyon na dapat i-pack sa isang maliit na dami ng oras. Magsisimula tayo sa pamamagitan ng pagpili ng lohikal na topology. Pagkatapos ay magkakaroon ng pangkalahatang-ideya ng control plane at mga problema sa scalability ng data plane, isang pagpipilian kung ano ang mangyayari sa pisikal na antas, at titingnan namin ang ilang mga tampok ng mga device. Ating hawakan nang kaunti kung ano ang nangyayari sa isang data center na may MPLS, na pinag-usapan natin kanina.
Kaya, ano ang Yandex sa mga tuntunin ng mga pag-load at serbisyo? Ang Yandex ay isang tipikal na hyperscaler. Kung titingnan namin ang mga user, pangunahing pinoproseso namin ang mga kahilingan ng user. Gayundin ang iba't ibang mga serbisyo ng streaming at paglilipat ng data, dahil mayroon din kaming mga serbisyo sa pag-iimbak. Kung mas malapit sa backend, lalabas doon ang mga pag-load at serbisyo sa imprastraktura, tulad ng ibinahagi na imbakan ng bagay, pagtitiklop ng data at, siyempre, patuloy na mga pila. Ang isa sa mga pangunahing uri ng workload ay ang MapReduce at mga katulad na system, pagpoproseso ng stream, machine learning, atbp.
Paano ang imprastraktura kung saan nangyayari ang lahat ng ito? Muli, isa kaming medyo tipikal na hyperscaler, bagama't marahil ay mas malapit kami sa mas maliit na hyperscaler na bahagi ng spectrum. Ngunit mayroon kaming lahat ng mga katangian. Gumagamit kami ng commodity hardware at horizontal scaling hangga't maaari. Mayroon kaming ganap na pagsasama-sama ng mapagkukunan: hindi kami nagtatrabaho sa mga indibidwal na makina, indibidwal na mga rack, ngunit pinagsama ang mga ito sa isang malaking pool ng mga mapapalitang mapagkukunan na may ilang karagdagang mga serbisyo na tumatalakay sa pagpaplano at paglalaan, at gumagana sa buong pool na ito.
Kaya mayroon kaming susunod na antas - ang operating system sa antas ng kumpol ng computing. Napakahalaga na ganap nating kontrolin ang stack ng teknolohiya na ginagamit natin. Kinokontrol namin ang mga endpoint (host), network at software stack.
Mayroon kaming ilang malalaking data center sa Russia at sa ibang bansa. Pinag-isa sila ng isang gulugod na gumagamit ng teknolohiyang MPLS. Ang aming panloob na imprastraktura ay halos ganap na binuo sa IPv6, ngunit dahil kailangan naming maghatid ng panlabas na trapiko na higit sa lahat ay dumarating sa IPv4, kailangan naming maghatid ng mga kahilingan na dumarating sa IPv4 sa mga frontend server, at kaunti pa ay pumunta sa panlabas na IPv4- Internet - para sa halimbawa, para sa pag-index.
Ang huling ilang mga pag-ulit ng mga disenyo ng network ng data center ay gumamit ng mga multi-layer na Clos topologies at L3-only. Kanina pa kami umalis sa L2 at nakahinga ng maluwag. Sa wakas, kasama sa aming imprastraktura ang daan-daang libong mga instance ng compute (server). Ang maximum na laki ng kumpol noong nakaraan ay humigit-kumulang 10 libong mga server. Ito ay higit sa lahat dahil sa kung paano gumagana ang parehong cluster-level na mga operating system, scheduler, resource allocation, atbp. Dahil ang progreso ay nangyari sa panig ng infrastructure software, ang target na laki ay ngayon ay humigit-kumulang 100 libong mga server sa isang computing cluster, at Mayroon kaming gawain - upang makapagtayo ng mga pabrika sa network na nagbibigay-daan sa mahusay na pagsasama-sama ng mapagkukunan sa naturang cluster.
Ano ang gusto natin mula sa isang network ng data center? Una sa lahat, mayroong maraming mura at medyo pantay na ipinamamahaging bandwidth. Dahil ang network ay ang backbone kung saan maaari tayong mag-pool ng mga mapagkukunan. Ang bagong target na laki ay tungkol sa 100 libong mga server sa isang kumpol.
Siyempre, gusto rin namin ng scalable at stable na control plane, dahil sa napakalaking imprastraktura, maraming sakit ng ulo ang nanggagaling kahit na sa mga random na pangyayari, at hindi namin gusto na ang control plane ay magdulot din sa amin ng pananakit ng ulo. Kasabay nito, nais naming mabawasan ang estado sa loob nito. Kung mas maliit ang kondisyon, mas mahusay at mas matatag ang lahat ng bagay, at mas madali itong mag-diagnose.
Siyempre, kailangan natin ng automation, dahil imposibleng manu-manong pamahalaan ang naturang imprastraktura, at naging imposible ito sa loob ng ilang panahon. Kailangan namin ng suporta sa pagpapatakbo hangga't maaari at suporta sa CI/CD hangga't maaari itong maibigay.
Sa ganoong laki ng mga data center at cluster, ang gawain ng pagsuporta sa incremental na pag-deploy at pagpapalawak nang walang pagkaantala ng serbisyo ay naging talamak. Kung sa mga kumpol na may sukat na isang libong makina, marahil malapit sa sampung libong makina, maaari pa rin silang ilunsad bilang isang operasyon - iyon ay, nagpaplano kami ng pagpapalawak ng imprastraktura, at ilang libong makina ang idinagdag bilang isang operasyon, kung gayon ang isang kumpol na may sukat na isang daang libong makina ay hindi agad na lilitaw tulad nito, ito ay itinayo sa loob ng isang panahon. At kanais-nais na sa lahat ng oras na ito kung ano ang na-pump out, ang imprastraktura na na-deploy, ay dapat na magagamit.
At isang kinakailangan na mayroon kami at iniwan: suporta para sa multitenancy, iyon ay, virtualization o network segmentation. Ngayon hindi na namin kailangang gawin ito sa antas ng tela ng network, dahil ang sharding ay napunta na sa mga host, at ginawa nitong napakadali para sa amin ang pag-scale. Salamat sa IPv6 at isang malaking address space, hindi namin kailangang gumamit ng mga duplicate na address sa panloob na imprastraktura; ang lahat ng addressing ay natatangi na. At salamat sa katotohanan na kinuha namin ang pag-filter at pagse-segment ng network sa mga host, hindi namin kailangang lumikha ng anumang mga entity ng virtual network sa mga network ng data center.
Isang napakahalagang bagay ang hindi natin kailangan. Kung ang ilang mga pag-andar ay maaaring alisin mula sa network, ginagawang mas madali ang buhay, at, bilang panuntunan, pinalawak ang pagpili ng magagamit na kagamitan at software, na ginagawang napakasimple ng mga diagnostic.
Kaya, ano ang hindi natin kailangan, ano ang nagawa nating isuko, hindi palaging may saya sa oras na nangyari ito, ngunit may malaking ginhawa kapag natapos ang proseso?
Una sa lahat, ang pag-abandona sa L2. Hindi natin kailangan ang L2, hindi totoo o tinularan. Hindi nagamit higit sa lahat dahil sa katotohanan na kinokontrol namin ang application stack. Ang aming mga application ay pahalang na nasusukat, gumagana ang mga ito sa L3 addressing, hindi sila masyadong nag-aalala na may ilang indibidwal na instance na lumabas, naglalabas lang sila ng bago, hindi na ito kailangang ilunsad sa lumang address, dahil mayroong isang hiwalay na antas ng pagtuklas ng serbisyo at pagsubaybay sa mga makina na matatagpuan sa cluster. Hindi namin itinatalaga ang gawaing ito sa network. Ang trabaho ng network ay maghatid ng mga packet mula sa point A hanggang point B.
Wala rin kaming mga sitwasyon kung saan lumilipat ang mga address sa loob ng network, at kailangan itong subaybayan. Sa maraming disenyo, ito ay karaniwang kinakailangan upang suportahan ang VM mobility. Hindi namin ginagamit ang kadaliang mapakilos ng mga virtual machine sa panloob na imprastraktura ng malaking Yandex, at, bukod dito, naniniwala kami na kahit na ito ay tapos na, hindi ito dapat mangyari sa suporta ng network. Kung talagang kailangan mong gawin ito, kailangan mong gawin ito sa antas ng host, at itulak ang mga address na maaaring lumipat sa mga overlay, upang hindi mahawakan o gumawa ng masyadong maraming mga dynamic na pagbabago sa routing system ng underlay mismo (transport network) .
Ang isa pang teknolohiya na hindi namin ginagamit ay multicast. Kung gusto mo, maaari kong sabihin sa iyo nang detalyado kung bakit. Ito ay ginagawang mas madali ang buhay, dahil kung ang isang tao ay nakikitungo dito at tumingin nang eksakto kung ano ang hitsura ng multicast control plane, sa lahat maliban sa pinakasimpleng mga pag-install, ito ay isang malaking sakit ng ulo. At higit pa, mahirap makahanap ng isang mahusay na gumaganang open source na pagpapatupad, halimbawa.
Sa wakas, idinisenyo namin ang aming mga network upang hindi sila masyadong magbago. Makakaasa tayo sa katotohanan na ang daloy ng mga panlabas na kaganapan sa sistema ng pagruruta ay maliit.
Anong mga problema ang lumitaw at anong mga paghihigpit ang dapat isaalang-alang kapag bumuo kami ng isang network ng data center? Ang gastos, siyempre. Scalability, ang antas kung saan gusto nating lumago. Ang pangangailangan na palawakin nang hindi humihinto sa serbisyo. Bandwidth, availability. Visibility ng kung ano ang nangyayari sa network para sa mga monitoring system, para sa mga operational team. Suporta sa automation - muli, hangga't maaari, dahil ang iba't ibang mga gawain ay maaaring malutas sa iba't ibang antas, kabilang ang pagpapakilala ng mga karagdagang layer. Well, hindi [posibleng] umaasa sa mga vendor. Bagama't sa iba't ibang mga makasaysayang panahon, depende sa kung aling seksyon ang iyong titingnan, ang kalayaang ito ay mas madali o mas mahirap makamit. Kung kukuha kami ng cross-section ng mga chips ng network device, noon hanggang kamakailan ay napaka-kondisyon na pag-usapan ang tungkol sa kalayaan mula sa mga vendor, kung gusto rin namin ang mga chip na may mataas na throughput.
Anong lohikal na topology ang gagamitin namin para buuin ang aming network? Ito ay magiging isang multi-level na Clos. Sa katunayan, walang mga tunay na alternatibo sa ngayon. At ang Clos topology ay medyo maganda, kahit na kung ihahambing sa iba't ibang mga advanced na topologies na higit pa sa larangan ng akademikong interes ngayon, kung mayroon tayong malalaking radix switch.
Paano halos nakabalangkas ang isang multi-level na Clos network at ano ang tawag sa iba't ibang elemento dito? Una sa lahat, ang hangin ay tumaas, upang i-orient ang iyong sarili kung saan ang hilaga, kung saan ang timog, kung saan ang silangan, kung saan ang kanluran. Ang mga network ng ganitong uri ay karaniwang ginagawa ng mga may napakalaking trapiko sa kanluran-silangan. Tulad ng para sa natitirang mga elemento, sa itaas ay isang virtual switch na binuo mula sa mas maliliit na switch. Ito ang pangunahing ideya ng recursive construction ng mga network ng Clos. Kinukuha namin ang mga elemento na may ilang uri ng radix at ikinonekta ang mga ito upang ang nakukuha namin ay maituturing na switch na may mas malaking radix. Kung kailangan mo ng higit pa, ang pamamaraan ay maaaring ulitin.
Sa mga kaso, halimbawa, na may dalawang antas na Clos, kapag posible na malinaw na matukoy ang mga bahagi na patayo sa aking diagram, kadalasang tinatawag ang mga ito na mga eroplano. Kung gagawa tayo ng Clos na may tatlong antas ng spine switch (lahat ng ito ay hindi hangganan o ToR switch at ginagamit lamang para sa transit), ang mga eroplano ay magiging mas kumplikado; ang mga dalawang antas ay eksaktong ganito. Tinatawag namin ang isang bloke ng ToR o mga switch ng dahon at ang mga switch ng unang antas ng spine na nauugnay sa mga ito ay isang Pod. Ang mga switch ng spine ng spine-1 na antas sa tuktok ng Pod ay ang tuktok ng Pod, ang tuktok ng Pod. Ang mga switch na matatagpuan sa tuktok ng buong pabrika ay ang tuktok na layer ng pabrika, Tuktok ng tela.
Siyempre, bumangon ang tanong: Ang mga clos network ay naitayo nang ilang panahon; ang ideya mismo ay karaniwang nagmumula sa mga panahon ng klasikal na telephony, mga TDM network. Baka may lumitaw na mas maganda, baka may magagawa pa? Oo at hindi. Sa teoryang oo, sa pagsasanay sa malapit na hinaharap tiyak na hindi. Dahil mayroong isang bilang ng mga kagiliw-giliw na topologies, ang ilan sa mga ito ay ginagamit pa sa produksyon, halimbawa, ang Dragonfly ay ginagamit sa mga aplikasyon ng HPC; Mayroon ding mga kagiliw-giliw na topologies tulad ng Xpander, FatClique, Jellyfish. Kung titingnan mo ang mga ulat sa mga kumperensya tulad ng SIGCOMM o NSDI kamakailan, makakahanap ka ng medyo malaking bilang ng mga gawa sa mga alternatibong topologies na may mas magagandang katangian (isa o isa pa) kaysa sa Clos.
Ngunit ang lahat ng mga topolohiyang ito ay may isang kawili-wiling pag-aari. Pinipigilan nito ang kanilang pagpapatupad sa mga network ng data center, na sinusubukan naming itayo sa commodity hardware at na nagkakahalaga ng medyo makatwirang pera. Sa lahat ng mga alternatibong topologies na ito, karamihan sa bandwidth ay sa kasamaang-palad ay hindi naa-access sa pamamagitan ng pinakamaikling landas. Samakatuwid, agad kaming nawalan ng pagkakataon na gamitin ang tradisyonal na control plane.
Sa teorya, alam ang solusyon sa problema. Ito ay, halimbawa, mga pagbabago sa estado ng link gamit ang k-pinakamaikling landas, ngunit, muli, walang ganoong mga protocol na ipapatupad sa produksyon at malawak na magagamit sa kagamitan.
Bukod dito, dahil ang karamihan sa kapasidad ay hindi naa-access sa pamamagitan ng pinakamaikling mga landas, kailangan nating baguhin ang higit pa sa control plane upang piliin ang lahat ng mga landas na iyon (at sa pamamagitan ng paraan, ito ay mas makabuluhang estado sa control plane). Kailangan pa rin nating baguhin ang pagpapasahang eroplano, at, bilang panuntunan, hindi bababa sa dalawang karagdagang feature ang kinakailangan. Ito ang kakayahang gumawa ng lahat ng desisyon tungkol sa pagpapasa ng packet nang isang beses, halimbawa, sa host. Sa katunayan, ito ay source routing, minsan sa literatura sa mga interconnection network ay tinatawag itong all-at-once forwarding decisions. At ang adaptive routing ay isang function na kailangan namin sa mga elemento ng network, na kumukulo, halimbawa, sa katotohanan na pinili namin ang susunod na hop batay sa impormasyon tungkol sa pinakamaliit na load sa queue. Bilang halimbawa, posible ang iba pang mga opsyon.
Kaya, ang direksyon ay kawili-wili, ngunit, sayang, hindi natin ito mailalapat ngayon.
Okay, kami ay nanirahan sa Clos logical topology. Paano natin ito susukatin? Tingnan natin kung paano ito gumagana at kung ano ang maaaring gawin.
Sa isang Clos network, mayroong dalawang pangunahing parameter na maaari nating pag-iba-iba at makakuha ng ilang partikular na resulta: ang radix ng mga elemento at ang bilang ng mga antas sa network. Mayroon akong isang schematic diagram kung paano nakakaapekto ang pareho sa laki. Sa isip, pinagsama natin ang dalawa.
Makikita na ang huling lapad ng Clos network ay ang produkto ng lahat ng antas ng spine switch ng southern radix, kung gaano karaming mga link ang mayroon tayo pababa, kung paano ito sumasanga. Ito ay kung paano namin sukatin ang laki ng network.
Tungkol sa kapasidad, lalo na sa mga switch ng ToR, mayroong dalawang opsyon sa pag-scale. Alinman sa maaari naming, habang pinapanatili ang pangkalahatang topology, gumamit ng mas mabilis na mga link, o maaari kaming magdagdag ng higit pang mga eroplano.
Kung titingnan mo ang pinalawak na bersyon ng Clos network (sa kanang sulok sa ibaba) at bumalik sa larawang ito kasama ang Clos network sa ibaba...
... kung gayon ito ay eksaktong parehong topology, ngunit sa slide na ito ito ay gumuho nang mas compact at ang mga eroplano ng pabrika ay nakapatong sa bawat isa. Ito ay pareho.
Ano ang hitsura ng pag-scale ng isang Clos network sa mga numero? Dito nagbibigay ako ng data kung anong maximum na lapad ang maaaring makuha ng isang network, kung anong maximum na bilang ng mga rack, ToR switch o leaf switch, kung wala sila sa mga rack, makukuha natin depende sa kung anong radix ng mga switch ang ginagamit natin para sa spine -levels, at kung gaano karaming mga antas ang ginagamit namin.
Narito kung gaano karaming mga rack ang maaari nating magkaroon, kung gaano karaming mga server at humigit-kumulang kung magkano ang lahat ng ito ay maaaring ubusin batay sa 20 kW bawat rack. Medyo naunang binanggit ko na kami ay naglalayon para sa isang laki ng kumpol na humigit-kumulang 100 libong mga server.
Makikita na sa buong disenyo na ito, dalawa at kalahating mga pagpipilian ang interesado. Mayroong isang opsyon na may dalawang layer ng spines at 64-port switch, na medyo maikli. Pagkatapos ay may mga perpektong angkop na opsyon para sa 128-port (na may radix 128) spine switch na may dalawang antas, o switch na may radix 32 na may tatlong antas. At sa lahat ng mga kaso, kung saan mayroong mas maraming mga radix at mas maraming mga layer, maaari kang gumawa ng isang napakalaking network, ngunit kung titingnan mo ang inaasahang pagkonsumo, karaniwang mayroong mga gigawatt. Posibleng maglagay ng cable, ngunit malamang na hindi kami makakuha ng ganoong kalaking kuryente sa isang site. Kung titingnan mo ang mga istatistika at pampublikong data sa mga data center, makakahanap ka ng napakakaunting mga data center na may tinatayang kapasidad na higit sa 150 MW. Ang mga mas malaki ay karaniwang mga campus ng data center, ilang malalaking data center na matatagpuan malapit sa isa't isa.
May isa pang mahalagang parameter. Kung titingnan mo ang kaliwang column, nakalista doon ang magagamit na bandwidth. Madaling makita na sa isang Clos network ang isang malaking bahagi ng mga port ay ginagamit upang ikonekta ang mga switch sa isa't isa. Ang magagamit na bandwidth, isang kapaki-pakinabang na strip, ay isang bagay na maaaring ibigay sa labas, patungo sa mga server. Naturally, pinag-uusapan ko ang tungkol sa mga conditional port at partikular ang tungkol sa banda. Bilang isang patakaran, ang mga link sa loob ng network ay mas mabilis kaysa sa mga link patungo sa mga server, ngunit bawat yunit ng bandwidth, hangga't maaari naming ipadala ito sa aming kagamitan sa server, mayroon pa ring ilang bandwidth sa loob ng network mismo. At kung mas maraming antas ang ginagawa namin, mas malaki ang tiyak na halaga ng pagbibigay ng guhit na ito sa labas.
Bukod dito, kahit na ang karagdagang banda na ito ay hindi eksaktong pareho. Bagama't maikli ang mga span, maaari tayong gumamit ng isang bagay tulad ng DAC (direct attach copper, iyon ay, twinax cables), o multimode optics, na nagkakahalaga ng higit pa o hindi gaanong makatwirang pera. Sa sandaling lumipat kami sa mas mahabang span - bilang panuntunan, ito ay mga single mode na optika, at ang halaga ng karagdagang bandwidth na ito ay kapansin-pansing tumataas.
At muli, bumalik sa nakaraang slide, kung lumikha kami ng isang Clos network nang walang labis na pag-subscribe, pagkatapos ay madaling tingnan ang diagram, tingnan kung paano binuo ang network - pagdaragdag ng bawat antas ng mga switch ng spine, inuulit namin ang buong strip na nasa ibaba. Plus level - kasama ang parehong banda, ang parehong bilang ng mga port sa mga switch tulad ng mayroon sa nakaraang antas, at ang parehong bilang ng mga transceiver. Samakatuwid, ito ay lubos na kanais-nais na i-minimize ang bilang ng mga antas ng spine switch.
Batay sa larawang ito, malinaw na gusto talaga naming bumuo sa isang bagay tulad ng mga switch na may radix na 128.
Dito, sa prinsipyo, ang lahat ay pareho sa sinabi ko; ito ay isang slide para sa pagsasaalang-alang sa ibang pagkakataon.
Anong mga opsyon ang nariyan na maaari nating piliin bilang mga naturang switch? Isang napakagandang balita para sa amin na ang mga ganitong network ay maaari nang buuin sa mga single-chip switch. At ito ay napaka-cool, mayroon silang maraming magagandang tampok. Halimbawa, halos wala silang panloob na istraktura. Nangangahulugan ito na mas madali silang masira. Nasira sila sa lahat ng uri ng mga paraan, ngunit sa kabutihang palad sila ay ganap na nasira. Sa mga modular na aparato mayroong isang malaking bilang ng mga pagkakamali (napaka hindi kasiya-siya), kapag mula sa punto ng view ng mga kapitbahay at ang control plane ay tila gumagana, ngunit, halimbawa, ang bahagi ng tela ay nawala at hindi ito gumagana. sa buong kapasidad. At ang trapiko dito ay balanse batay sa katotohanan na ito ay ganap na gumagana, at maaari tayong ma-overload.
O, halimbawa, ang mga problema ay lumitaw sa backplane, dahil sa loob ng modular device mayroon ding mga high-speed SerDes - ito ay talagang kumplikado sa loob. Alinman ang mga palatandaan sa pagitan ng mga elemento ng pagpapasa ay naka-synchronize o hindi naka-synchronize. Sa pangkalahatan, ang anumang produktibong modular na aparato na binubuo ng isang malaking bilang ng mga elemento, bilang panuntunan, ay naglalaman ng parehong Clos network sa loob mismo, ngunit napakahirap i-diagnose. Kadalasan mahirap para sa mismong vendor na mag-diagnose.
At mayroon itong isang malaking bilang ng mga senaryo ng pagkabigo kung saan ang aparato ay nagpapababa, ngunit hindi ganap na nahuhulog sa topology. Dahil malaki ang aming network, aktibong ginagamit ang pagbabalanse sa pagitan ng magkatulad na mga elemento, ang network ay napaka-regular, iyon ay, ang isang landas kung saan maayos ang lahat ay hindi naiiba sa kabilang landas, mas kumikita para sa amin na mawala ang ilan sa ang mga device mula sa topology kaysa mauwi sa isang sitwasyon kung saan ang ilan sa mga ito ay tila gumagana, ngunit ang ilan sa kanila ay hindi.
Ang susunod na magandang tampok ng mga single-chip na device ay ang pag-evolve ng mga ito nang mas mahusay at mas mabilis. May posibilidad din silang magkaroon ng mas mahusay na kapasidad. Kung kukunin natin ang malalaking pinagsama-samang istruktura na mayroon tayo sa isang bilog, kung gayon ang kapasidad ng bawat rack unit para sa mga port na may parehong bilis ay halos dalawang beses na mas mahusay kaysa sa mga modular na aparato. Ang mga device na binuo sa paligid ng isang chip ay kapansin-pansing mas mura kaysa sa mga modular at kumonsumo ng mas kaunting enerhiya.
Ngunit, siyempre, lahat ng ito ay may dahilan, mayroon ding mga disadvantages. Una, ang radix ay halos palaging mas maliit kaysa sa mga modular na aparato. Kung makakakuha tayo ng isang device na binuo sa paligid ng isang chip na may 128 port, maaari tayong makakuha ng isang modular na may ilang daang port ngayon nang walang anumang problema.
Ito ay kapansin-pansing mas maliit na sukat ng mga pagpapasahang talahanayan at, bilang panuntunan, lahat ng bagay na nauugnay sa scalability ng data plane. Mababaw na buffer. At, bilang isang patakaran, sa halip limitado ang pag-andar. Ngunit lumalabas na kung alam mo ang mga paghihigpit na ito at mag-ingat sa oras na laktawan ang mga ito o isaalang-alang lamang ang mga ito, kung gayon hindi ito nakakatakot. Ang katotohanan na ang radix ay mas maliit ay hindi na problema sa mga device na may radix na 128 na sa wakas ay lumitaw kamakailan; maaari tayong bumuo sa dalawang layer ng mga spine. Ngunit imposible pa ring bumuo ng anumang mas maliit sa dalawa na kawili-wili para sa amin. Sa isang antas, napakaliit na kumpol ay nakuha. Kahit ang mga dati nating design at requirements ay lumampas pa rin sa kanila.
Sa katunayan, kung biglang ang solusyon ay nasa isang lugar sa bingit, mayroon pa ring paraan upang masukat. Dahil ang huli (o una), ang pinakamababang antas kung saan nakakonekta ang mga server ay ang mga switch ng ToR o mga switch ng dahon, hindi kami kinakailangang magkonekta ng isang rack sa kanila. Samakatuwid, kung ang solusyon ay bumaba ng halos kalahati, maaari mong isipin ang tungkol sa simpleng paggamit ng switch na may malaking radix sa mas mababang antas at pagkonekta, halimbawa, dalawa o tatlong rack sa isang switch. Isa rin itong opsyon, mayroon itong mga gastos, ngunit gumagana ito nang maayos at maaaring maging isang mahusay na solusyon kapag kailangan mong maabot ang halos dalawang beses ang laki.
Upang buod, bumubuo kami sa isang topology na may dalawang antas ng mga spine, na may walong factory layer.
Ano ang mangyayari sa pisika? Napakasimpleng mga kalkulasyon. Kung mayroon kaming dalawang antas ng mga spine, mayroon lamang kaming tatlong antas ng mga switch, at inaasahan namin na magkakaroon ng tatlong mga segment ng cable sa network: mula sa mga server hanggang sa mga switch ng dahon, hanggang sa spine 1, hanggang sa spine 2. Ang mga opsyon na maaari naming ang paggamit ay - ito ay twinax, multimode, single mode. At dito kailangan nating isaalang-alang kung anong strip ang available, magkano ang magagastos nito, kung ano ang mga pisikal na dimensyon, kung anong span ang maaari nating saklawin, at kung paano tayo mag-a-upgrade.
Sa mga tuntunin ng gastos, lahat ay maaaring ihanay. Ang mga twinax ay makabuluhang mas mura kaysa sa mga aktibong optika, mas mura kaysa sa multimode transceiver, kung kukunin mo ito sa bawat paglipad mula sa dulo, medyo mas mura kaysa sa isang 100-gigabit switch port. At, pakitandaan, mas mababa ang gastos nito kaysa sa single mode optics, dahil sa mga flight kung saan kinakailangan ang single mode, sa mga data center para sa ilang kadahilanan, makatuwirang gamitin ang CWDM, habang ang parallel single mode (PSM) ay hindi masyadong maginhawa upang gumana. na may, napakalaking mga pack ay nakuha ng mga hibla, at kung tumutok tayo sa mga teknolohiyang ito, makukuha natin ang tinatayang sumusunod na hierarchy ng presyo.
Isa pang tala: sa kasamaang-palad, hindi masyadong posible na gumamit ng mga disassembled na 100 hanggang 4x25 multimode port. Dahil sa mga tampok na disenyo ng SFP28 transceiver, hindi ito mas mura kaysa sa 28 Gbit QSFP100. At ang disassembly na ito para sa multimode ay hindi gumagana nang maayos.
Ang isa pang limitasyon ay dahil sa laki ng mga kumpol ng computing at bilang ng mga server, lumalabas na pisikal na malaki ang aming mga data center. Nangangahulugan ito na hindi bababa sa isang flight ang kailangang gawin sa isang singlemod. Muli, dahil sa pisikal na laki ng Pods, hindi posibleng magpatakbo ng dalawang span ng twinax (mga copper cable).
Bilang resulta, kung mag-o-optimize kami para sa presyo at isasaalang-alang ang geometry ng disenyong ito, makakakuha tayo ng isang span ng twinax, isang span ng multimode at isang span ng singlemode gamit ang CWDM. Isinasaalang-alang nito ang mga posibleng daanan ng pag-upgrade.
Ito ang hitsura nito kamakailan, kung saan tayo patungo at kung ano ang posible. Ito ay malinaw, hindi bababa sa, kung paano lumipat patungo sa 50-Gigabit SerDes para sa parehong multimode at singlemode. Bukod dito, kung titingnan mo kung ano ang nasa single-mode transceiver ngayon at sa hinaharap para sa 400G, madalas kahit na dumating ang 50G SerDes mula sa electrical side, 100 Gbps bawat lane ay maaari nang pumunta sa optika. Samakatuwid, posible na sa halip na lumipat sa 50, magkakaroon ng paglipat sa 100 Gigabit SerDes at 100 Gbps bawat lane, dahil ayon sa mga pangako ng maraming mga vendor, ang kanilang kakayahang magamit ay inaasahan sa lalong madaling panahon. Ang panahon kung kailan ang 50G SerDes ay ang pinakamabilis, tila, ay hindi masyadong mahaba, dahil ang mga unang kopya ng 100G SerDes ay ilalabas halos sa susunod na taon. At pagkatapos ng ilang oras pagkatapos nito ay malamang na nagkakahalaga sila ng makatwirang pera.
Isa pang nuance tungkol sa pagpili ng physics. Sa prinsipyo, maaari na tayong gumamit ng 400 o 200 Gigabit port gamit ang 50G SerDes. Ngunit lumalabas na hindi ito gaanong makatuwiran, dahil, tulad ng sinabi ko kanina, gusto namin ang isang medyo malaking radix sa mga switch, sa loob ng dahilan, siyempre. Gusto namin ng 128. At kung mayroon kaming limitadong kapasidad ng chip at pinapataas namin ang bilis ng link, pagkatapos ay natural na bumababa ang radix, walang mga himala.
At maaari nating dagdagan ang kabuuang kapasidad gamit ang mga eroplano, at walang mga espesyal na gastos; maaari nating idagdag ang bilang ng mga eroplano. At kung mawala ang radix, kailangan nating magpakilala ng karagdagang antas, kaya sa kasalukuyang sitwasyon, sa kasalukuyang maximum na magagamit na kapasidad bawat chip, lumalabas na mas mahusay na gumamit ng 100-gigabit port, dahil pinapayagan ka nila. para makakuha ng mas malaking radix.
Ang susunod na tanong ay kung paano nakaayos ang pisika, ngunit mula sa punto ng view ng imprastraktura ng cable. Ito ay lumiliko na ito ay nakaayos sa isang medyo nakakatawang paraan. Paglalagay ng kable sa pagitan ng mga leaf-switch at first-level spines - walang maraming mga link doon, ang lahat ay medyo simple. Ngunit kung sasakay tayo ng isang eroplano, ang mangyayari sa loob ay kailangan nating ikonekta ang lahat ng mga spine ng unang antas sa lahat ng mga spine ng pangalawang antas.
Dagdag pa, bilang panuntunan, mayroong ilang mga kahilingan para sa kung paano ito dapat tumingin sa loob ng data center. Halimbawa, talagang gusto naming pagsamahin ang mga cable sa isang bundle at hilahin ang mga ito upang ang isang high-density na patch panel ay ganap na napunta sa isang patch panel, nang sa gayon ay walang zoo sa mga tuntunin ng mga haba. Nagawa naming lutasin ang problemang ito. Kung una mong titingnan ang lohikal na topology, makikita mo na ang mga eroplano ay independyente, ang bawat eroplano ay maaaring itayo sa sarili nitong. Ngunit kapag nagdagdag kami ng ganoong bundling at gusto naming i-drag ang buong patch panel sa isang patch panel, kailangan naming paghaluin ang iba't ibang mga eroplano sa loob ng isang bundle at ipakilala ang isang intermediate na istraktura sa anyo ng mga optical cross-connection upang i-repack ang mga ito mula sa kung paano sila binuo. sa isang segment , sa kung paano kokolektahin ang mga ito sa isa pang segment. Salamat dito, nakakakuha kami ng magandang tampok: ang lahat ng kumplikadong paglipat ay hindi lalampas sa mga rack. Kapag kailangan mong i-intertwine ang isang bagay nang napakalakas, "unfold the planes," na kung minsan ay tinatawag sa mga Clos network, lahat ito ay puro sa loob ng isang rack. Wala kaming lubos na disassembled, hanggang sa mga indibidwal na link, lumilipat sa pagitan ng mga rack.
Ganito ang hitsura nito mula sa punto ng view ng lohikal na organisasyon ng imprastraktura ng cable. Sa larawan sa kaliwa, ang maraming kulay na mga bloke ay naglalarawan ng mga bloke ng mga switch ng unang antas ng spine, tig-walong piraso, at apat na bundle ng mga cable na nagmumula sa kanila, na pumupunta at bumalandra sa mga bundle na nagmumula sa mga bloke ng spine-2 switch .
Ang mga maliliit na parisukat ay nagpapahiwatig ng mga interseksyon. Sa kaliwang itaas ay isang breakdown ng bawat naturang intersection, ito ay talagang isang 512 by 512 port na cross-connect na module na nagre-repack ng mga cable upang ganap silang mapunta sa isang rack, kung saan mayroon lamang isang spine-2 na eroplano. At sa kanan, ang pag-scan ng larawang ito ay medyo mas detalyado kaugnay ng ilang Pod sa antas ng spine-1, at kung paano ito naka-package sa isang cross-connect, kung paano ito nanggagaling sa antas ng spine-2.
Ito ang hitsura nito. Ang hindi pa ganap na naka-assemble na spine-2 stand (sa kaliwa) at ang cross-connect stand. Sa kasamaang palad, walang gaanong makikita doon. Ang buong istrukturang ito ay ini-deploy ngayon sa isa sa aming malalaking data center na pinapalawak. This is a work in progress, it will look niceer, it will be filled out better.
Isang mahalagang tanong: pinili namin ang lohikal na topology at binuo ang pisika. Ano ang mangyayari sa control plane? Ito ay lubos na kilala mula sa karanasan sa pagpapatakbo, mayroong isang bilang ng mga ulat na ang link ng mga protocol ng estado ay mabuti, ito ay isang kasiyahang makipagtulungan sa kanila, ngunit, sa kasamaang-palad, ang mga ito ay hindi nasusukat nang maayos sa isang makapal na konektadong topology. At mayroong isang pangunahing kadahilanan na pumipigil dito - ito ay kung paano gumagana ang pagbaha sa mga protocol ng estado ng link. Kung kukunin mo lang ang algorithm ng pagbaha at titingnan kung paano nakabalangkas ang aming network, makikita mo na magkakaroon ng napakalaking fanout sa bawat hakbang, at babahain lamang nito ang control plane ng mga update. Sa partikular, ang mga naturang topologies ay napakahinang humahalo sa tradisyonal na algorithm ng pagbaha sa mga protocol ng estado ng link.
Ang pagpipilian ay gamitin ang BGP. Kung paano ito ihanda nang tama ay inilarawan sa RFC 7938 tungkol sa paggamit ng BGP sa malalaking data center. Ang mga pangunahing ideya ay simple: pinakamababang bilang ng mga prefix sa bawat host at sa pangkalahatan ay pinakamababang bilang ng mga prefix sa network, gumamit ng pagsasama-sama kung maaari, at sugpuin ang path hunting. Gusto namin ng napakaingat, napakakontroladong pamamahagi ng mga update, na tinatawag na valley free. Gusto naming i-deploy ang mga update nang eksaktong isang beses habang dumadaan ang mga ito sa network. Kung sila ay nagmula sa ibaba, sila ay umakyat, hindi hihigit sa isang beses. Dapat walang zigzags. Ang mga Zigzag ay napakasama.
Upang gawin ito, gumagamit kami ng isang disenyo na sapat na simple upang magamit ang pinagbabatayan na mga mekanismo ng BGP. Ibig sabihin, gumagamit kami ng eBGP na tumatakbo sa link na lokal, at ang mga autonomous system ay itinalaga gaya ng sumusunod: isang autonomous system sa ToR, isang autonomous system sa buong block ng spine-1 switch ng isang Pod, at isang general autonomous system sa buong Top ng Tela. Hindi mahirap tingnan at makita na kahit ang normal na pag-uugali ng BGP ay nagbibigay sa amin ng pamamahagi ng mga update na gusto namin.
Naturally, ang pagtugon at pagsasama-sama ng address ay kailangang idisenyo upang ito ay tugma sa paraan ng paggawa ng pagruruta, upang matiyak nito ang katatagan ng control plane. Ang pag-address ng L3 sa transportasyon ay nakatali sa topology, dahil kung wala ito imposibleng makamit ang pagsasama-sama; kung wala ito, ang mga indibidwal na address ay gagapang sa sistema ng pagruruta. And one more thing is that aggregation, unfortunately, not mix very well with multi-path, kasi kapag multi-path tayo at may aggregation tayo, ayos na lahat, kapag healthy ang buong network, walang failures. Sa kasamaang palad, sa sandaling lumitaw ang mga pagkabigo sa network at nawala ang simetrya ng topology, maaari tayong dumating sa punto kung saan inanunsyo ang yunit, kung saan hindi na tayo makakarating sa kung saan kailangan nating pumunta. Samakatuwid, pinakamahusay na pagsama-samahin kung saan walang karagdagang multi-path, sa aming kaso ito ay mga switch ng ToR.
Sa katunayan, posible na pagsama-samahin, ngunit maingat. Kung magagawa natin ang controlled disaggregation kapag nangyari ang mga pagkabigo sa network. Ngunit ito ay medyo mahirap na gawain, kahit na nagtaka kami kung posible bang gawin ito, kung posible bang magdagdag ng karagdagang automation, at may hangganan na mga makina ng estado na tama na sisipain ang BGP upang makuha ang nais na pag-uugali. Sa kasamaang-palad, ang pagpoproseso ng mga kaso ng sulok ay napaka-hindi-halata at kumplikado, at ang gawaing ito ay hindi mahusay na nalutas sa pamamagitan ng paglakip ng mga panlabas na attachment sa BGP.
Ang napaka-kagiliw-giliw na gawain sa bagay na ito ay ginawa sa loob ng balangkas ng RIFT protocol, na tatalakayin sa susunod na ulat.
Ang isa pang mahalagang bagay ay kung paano sumusukat ang mga data plane sa mga siksik na topologies, kung saan mayroon kaming malaking bilang ng mga alternatibong landas. Sa kasong ito, maraming karagdagang istruktura ng data ang ginagamit: Mga pangkat ng ECMP, na naglalarawan naman ng mga pangkat ng Next Hop.
Sa isang normal na gumaganang network, nang walang mga pagkabigo, kapag umakyat tayo sa Clos topology, sapat na gumamit lamang ng isang grupo, dahil ang lahat ng hindi lokal ay inilarawan bilang default, maaari tayong umakyat. Kapag pumunta tayo mula sa itaas hanggang sa ibaba hanggang sa timog, kung gayon ang lahat ng mga landas ay hindi ECMP, sila ay mga solong landas na landas. Maayos ang lahat. Ang problema ay, at ang kakaiba ng klasikong Clos topology ay kung titingnan natin ang Tuktok ng tela, sa anumang elemento, mayroon lamang isang landas sa anumang elemento sa ibaba. Kung maganap ang mga pagkabigo sa landas na ito, ang partikular na elementong ito sa tuktok ng pabrika ay magiging hindi wasto para mismo sa mga prefix na nasa likod ng sirang landas. Ngunit para sa iba ay may bisa ito, at kailangan nating i-parse ang mga grupo ng ECMP at magpakilala ng bagong estado.
Ano ang hitsura ng scalability ng data plane sa mga modernong device? Kung gagawin natin ang LPM (pinakamahabang tugma ng prefix), lahat ay medyo maganda, higit sa 100k prefix. Kung pinag-uusapan natin ang tungkol sa mga grupo ng Next Hop, kung gayon ang lahat ay mas masahol pa, 2-4 na libo. Kung pinag-uusapan natin ang isang talahanayan na naglalaman ng isang paglalarawan ng Next Hops (o mga adjacencies), kung gayon ito ay mula 16k hanggang 64k. At ito ay maaaring maging isang problema. At narito tayo sa isang kawili-wiling digression: ano ang nangyari sa MPLS sa mga data center? Sa prinsipyo, nais naming gawin ito.
Dalawang bagay ang nangyari. Gumawa kami ng micro-segmentation sa mga host; hindi na namin kailangang gawin ito sa network. Ito ay hindi napakahusay sa suporta mula sa iba't ibang mga vendor, at higit pa sa mga bukas na pagpapatupad sa mga puting kahon na may MPLS. At ang MPLS, hindi bababa sa mga tradisyonal na pagpapatupad nito, sa kasamaang-palad, ay napakahinang pinagsama sa ECMP. At dahil jan.
Ganito ang hitsura ng ECMP forwarding structure para sa IP. Ang isang malaking bilang ng mga prefix ay maaaring gumamit ng parehong pangkat at ang parehong bloke ng Next Hops (o mga adjacencies, maaaring iba ang tawag dito sa iba't ibang dokumentasyon para sa iba't ibang device). Ang punto ay inilalarawan ito bilang papalabas na port at kung saan isusulat muli ang MAC address upang makarating sa tamang Next Hop. Para sa IP ang lahat ay mukhang simple, maaari kang gumamit ng napakalaking bilang ng mga prefix para sa parehong grupo, ang parehong bloke ng Next Hops.
Ang klasikong arkitektura ng MPLS ay nagpapahiwatig na, depende sa papalabas na interface, ang label ay maaaring muling isulat sa iba't ibang mga halaga. Samakatuwid, kailangan nating panatilihin ang isang grupo at isang bloke ng Next Hops para sa bawat label ng input. At ito, sayang, ay hindi sukat.
Madaling makita na sa aming disenyo kailangan namin ng humigit-kumulang 4000 ToR switch, ang maximum na lapad ay 64 ECMP path, kung lalayo kami mula sa spine-1 patungo sa spine-2. Halos hindi kami makapasok sa isang talahanayan ng mga pangkat ng ECMP, kung isang prefix lang na may ToR ang mawawala, at hindi na kami makapasok sa talahanayan ng Next Hops.
Hindi lahat ng ito ay walang pag-asa, dahil ang mga arkitektura tulad ng Segment Routing ay may kasamang mga global na label. Sa pormal, posibleng i-collapse muli ang lahat ng mga bloke ng Next Hops na ito. Upang gawin ito, kailangan mo ng isang uri ng wild card na operasyon: kumuha ng isang label at muling isulat ito sa pareho nang walang partikular na halaga. Ngunit sa kasamaang-palad, hindi ito masyadong naroroon sa mga magagamit na pagpapatupad.
At sa wakas, kailangan nating magdala ng panlabas na trapiko sa data center. Paano ito gagawin? Dati, ang trapiko ay ipinakilala sa Clos network mula sa itaas. Ibig sabihin, may mga edge router na nakakonekta sa lahat ng device sa Tuktok ng tela. Ang solusyon na ito ay gumagana nang maayos sa maliit hanggang katamtamang laki. Sa kasamaang palad, upang maipadala ang trapiko nang simetriko sa buong network sa ganitong paraan, kailangan nating makarating sa lahat ng Tuktok ng mga elemento ng tela nang sabay-sabay, at kapag mayroong higit sa isang daan sa kanila, lumalabas na kailangan din natin ng malaking radix sa ang mga router sa gilid. Sa pangkalahatan, nagkakahalaga ito ng pera, dahil ang mga gilid ng router ay mas gumagana, ang mga port sa kanila ay magiging mas mahal, at ang disenyo ay hindi masyadong maganda.
Ang isa pang opsyon ay simulan ang naturang trapiko mula sa ibaba. Madaling i-verify na ang Clos topology ay binuo sa paraang ang trapiko na nagmumula sa ibaba, iyon ay, mula sa gilid ng ToR, ay pantay na ipinamamahagi sa mga antas sa buong Tuktok ng tela sa dalawang pag-ulit, na naglo-load sa buong network. Samakatuwid, ipinakilala namin ang isang espesyal na uri ng Pod, Edge Pod, na nagbibigay ng panlabas na koneksyon.
May isa pang pagpipilian. Ito ang ginagawa ng Facebook, halimbawa. Tinatawag nila itong Fabric Aggregator o HGRID. Ang isang karagdagang antas ng gulugod ay ipinakilala upang ikonekta ang maramihang mga sentro ng data. Posible ang disenyong ito kung wala kaming mga karagdagang function o pagbabago sa encapsulation sa mga interface. Kung mga karagdagang touch point ang mga ito, mahirap. Kadalasan, mayroong higit pang mga function at isang uri ng lamad na naghihiwalay sa iba't ibang bahagi ng data center. Walang saysay na gawing malaki ang naturang lamad, ngunit kung ito ay talagang kinakailangan para sa ilang kadahilanan, kung gayon makatuwirang isaalang-alang ang posibilidad na alisin ito, gawin itong mas malawak hangga't maaari at ilipat ito sa mga host. Ginagawa ito, halimbawa, ng maraming mga operator ng ulap. Mayroon silang mga overlay, nagsisimula sila sa mga host.
Anong mga pagkakataon sa pag-unlad ang nakikita natin? Una sa lahat, pagpapabuti ng suporta para sa pipeline ng CI/CD. Gusto naming lumipad sa paraan ng pagsubok at pagsubok sa paraan ng paglipad namin. Hindi ito gumagana nang maayos, dahil malaki ang imprastraktura at imposibleng madoble ito para sa mga pagsubok. Kailangan mong maunawaan kung paano ipasok ang mga elemento ng pagsubok sa imprastraktura ng produksyon nang hindi ito ibinabagsak.
Ang mas mahusay na instrumento at mas mahusay na pagsubaybay ay halos hindi kinakailangan. Ang buong tanong ay isang balanse ng pagsisikap at pagbabalik. Kung maaari mong idagdag ito nang may makatwirang pagsisikap, napakahusay.
Buksan ang mga operating system para sa mga device sa network. Mas mahusay na mga protocol at mas mahusay na mga sistema ng pagruruta, tulad ng RIFT. Kailangan din ng pananaliksik sa paggamit ng mas mahusay na mga scheme ng pagkontrol sa kasikipan at marahil ang pagpapakilala, kahit man lang sa ilang mga punto, ng suporta sa RDMA sa loob ng cluster.
Sa karagdagang pagtingin sa hinaharap, kailangan namin ng mga advanced na topologies at posibleng mga network na gumagamit ng mas kaunting overhead. Sa mga sariwang bagay, kamakailan ay nagkaroon ng mga publikasyon tungkol sa teknolohiya ng tela para sa HPC Cray Slingshot, na nakabatay sa commodity Ethernet, ngunit may opsyong gumamit ng mas maiikling mga header. Bilang resulta, nabawasan ang overhead.
Ang lahat ay dapat panatilihing simple hangga't maaari, ngunit hindi mas simple. Ang pagiging kumplikado ay ang kaaway ng scalability. Ang pagiging simple at regular na mga istraktura ay aming mga kaibigan. Kung maaari mong gawin ang pag-scale out sa isang lugar, gawin ito. At sa pangkalahatan, napakasarap makisali sa mga teknolohiya ng network ngayon. Mayroong maraming mga kagiliw-giliw na bagay na nangyayari. Salamat.
Pinagmulan: www.habr.com