Ni evoluigis datumcentran retdezajnon, kiu ebligas la disfaldiĝon de komputikaj aretoj pli grandaj ol 100 mil serviloj kun pinta bisekcbendolarĝo de pli ol unu petabajto sekundo.
De la raporto de Dmitry Afanasyev vi lernos pri la bazaj principoj de la nova dezajno, skalado de topologioj, la problemoj kiuj aperas kun ĉi tio, ebloj por solvi ilin, la funkcioj de vojigo kaj skalado de la plusendaj ebenaj funkcioj de modernaj retaj aparatoj en "dense konektitaj" topologioj kun granda nombro da ECMP-itineroj. Krome, Dima mallonge parolis pri la organizo de ekstera konektebleco, la fizika tavolo, la kabla sistemo kaj manieroj por plue pliigi kapaciton.
- Bonan posttagmezon al ĉiuj! Mia nomo estas Dmitry Afanasyev, mi estas reto-arkitekto ĉe Yandex kaj ĉefe desegnas datumcentrajn retojn.
Mia rakonto temas pri la ĝisdatigita reto de Yandex-datumcentroj. Ĝi estas tre evoluado de la dezajno, kiun ni havis, sed samtempe estas kelkaj novaj elementoj. Ĉi tio estas superrigarda prezento ĉar estis multe da informoj por esti pakitaj en malgrandan kvanton da tempo. Ni komencos elektante logikan topologion. Tiam estos superrigardo de la kontrolaviadilo kaj problemoj kun datumplana skaleblo, elekto de tio, kio okazos ĉe la fizika nivelo, kaj ni rigardos kelkajn funkciojn de la aparatoj. Ni tuŝu iomete pri tio, kio okazas en datumcentro kun MPLS, pri kiu ni parolis antaŭ iom da tempo.
Do, kio estas Yandex laŭ ŝarĝoj kaj servoj? Yandex estas tipa hiperskalilo. Se ni rigardas la uzantojn, ni ĉefe prilaboras uzantpetojn. Ankaŭ diversaj streaming-servoj kaj transdono de datumoj, ĉar ni ankaŭ havas stokadservojn. Se pli proksime al la backend, tiam infrastrukturaj ŝarĝoj kaj servoj aperas tie, kiel distribua objektostokado, reproduktado de datumoj kaj, kompreneble, konstantaj atendovicoj. Unu el la ĉefaj specoj de laborkvantoj estas MapReduce kaj similaj sistemoj, flutraktado, maŝinlernado ktp.
Kiel estas la infrastrukturo, sur kiu ĉio ĉi okazas? Denove, ni estas sufiĉe tipa hiperskalulo, kvankam ni eble estas iom pli proksimaj al la pli malgranda hiperskala flanko de la spektro. Sed ni havas ĉiujn atributojn. Ni uzas varan aparataron kaj horizontalan skalon kie eblas. Ni havas plenan kunigon de rimedoj: ni ne laboras kun individuaj maŝinoj, individuaj rakoj, sed kombinas ilin en grandan aron da interŝanĝeblaj rimedoj kun iuj aldonaj servoj, kiuj traktas planadon kaj asignadon, kaj laboras kun ĉi tiu tuta naĝejo.
Do ni havas la sekvan nivelon - la operaciumon ĉe la komputika grapo-nivelo. Estas tre grave, ke ni plene kontrolu la teknologian stakon, kiun ni uzas. Ni kontrolas la finpunktojn (gastigantoj), reton kaj programaron.
Ni havas plurajn grandajn datumcentrojn en Rusio kaj eksterlande. Ili estas kunigitaj de spino kiu uzas MPLS-teknologion. Nia interna infrastrukturo estas preskaŭ tute konstruita sur IPv6, sed ĉar ni bezonas servi eksteran trafikon, kiu ankoraŭ venas ĉefe per IPv4, ni devas iel liveri petojn venantajn per IPv4 al la interretaj serviloj, kaj iom pli iri al ekstera IPv4- Interreto - por ekzemple, por indeksado.
La lastaj malmultaj ripetoj de datumcentraj retdezajnoj uzis plurtavolajn Clos-topologiojn kaj estas L3-nur. Ni forlasis L2 antaŭ iom da tempo kaj spiris trankvile. Fine, nia infrastrukturo inkluzivas centojn da miloj da komputilaj (serviloj) petskriboj. La maksimuma grapulo antaŭ iom da tempo estis ĉirkaŭ 10 mil serviloj. Ĉi tio estas plejparte pro kiel tiuj samaj cluster-nivelaj operaciumoj, planiloj, resursa asignado ktp povas funkcii. Ĉar progreso okazis flanke de infrastruktura programaro, la celgrandeco nun estas ĉirkaŭ 100 mil serviloj en unu komputika areto, kaj Ni havas taskon - povi konstrui retajn fabrikojn, kiuj ebligas efikan kunigon de rimedoj en tia areto.
Kion ni volas de datumcentra reto? Antaŭ ĉio, estas multe da malmultekosta kaj sufiĉe unuforme distribuita bendolarĝo. Ĉar la reto estas la spino per kiu ni povas kunigi rimedojn. La nova cela grandeco estas proksimume 100 mil serviloj en unu areto.
Ni ankaŭ, kompreneble, volas skaleblan kaj stabilan kontrolaviadilon, ĉar sur tiel granda infrastrukturo multaj kapdoloroj ŝprucas eĉ de simple hazardaj eventoj, kaj ni ne volas, ke la kontrolaviadilo ankaŭ alportu al ni kapdolorojn. Samtempe, ni volas minimumigi la ŝtaton en ĝi. Ju pli malgranda estas la kondiĉo, des pli bone kaj pli stabila ĉio funkcias, kaj des pli facile estas diagnozi.
Kompreneble, ni bezonas aŭtomatigon, ĉar estas neeble administri tian infrastrukturon permane, kaj ĝi estis neebla de kelka tempo. Ni bezonas operacian subtenon kiel eble plej multe kaj CI/CD-subtenon tiom kiom ĝi povas esti provizita.
Kun tiaj grandecoj de datumcentroj kaj aretoj, la tasko subteni pliigan deplojon kaj vastiĝon sen interrompo de servo fariĝis sufiĉe akra. Se sur amasoj de milo da maŝinoj, eble proksime de dek mil maŝinoj, ili ankoraŭ povus esti rulitaj kiel unu operacio - tio estas, ni planas vastiĝon de la infrastrukturo, kaj pluraj miloj da maŝinoj estas aldonitaj kiel unu operacio, tiam aro de grandeco de cent mil maŝinoj ne ekestas tuj tiel, ĝi estas konstruita dum tempodaŭro. Kaj estas dezirinde, ke dum ĉi tiu tempo, kio jam estis pumpita, la infrastrukturo kiu estis deplojita, estu disponebla.
Kaj unu postulo, kiun ni havis kaj lasis: subteno por multitenado, tio estas, virtualigo aŭ reto-segmentado. Nun ni ne bezonas fari tion ĉe la reto-ŝtofa nivelo, ĉar la sharding iris al la gastigantoj, kaj ĉi tio tre facilas por ni grimpi. Danke al IPv6 kaj granda adresspaco, ni ne bezonis uzi duplikatajn adresojn en la interna infrastrukturo; ĉiuj adresoj jam estis unikaj. Kaj danke al la fakto, ke ni prenis filtradon kaj retsegmentadon al la gastigantoj, ni ne bezonas krei iujn ajn virtualajn retajn entojn en datumcentraj retoj.
Tre grava afero estas tio, kion ni ne bezonas. Se iuj funkcioj povas esti forigitaj de la reto, tio faciligas la vivon kaj, kiel regulo, pligrandigas la elekton de disponeblaj ekipaĵoj kaj programaroj, farante diagnozon tre simpla.
Do, kio estas tio, kion ni ne bezonas, kion ni povis rezigni, ne ĉiam kun ĝojo en la tempo, kiam ĝi okazis, sed kun granda malpeziĝo kiam la procezo estas finita?
Unue, forlasante L2. Ni ne bezonas L2, nek realan nek emulitan. Neuzata plejparte pro la fakto, ke ni kontrolas la aplikaĵan stakon. Niaj aplikaĵoj estas horizontale skaleblaj, ili funkcias kun L3-adresado, ili ne tre zorgas pri tio, ke iu individua instanco estingiĝis, ili simple disvolvas novan, ĝi ne bezonas esti lanĉita ĉe la malnova adreso, ĉar ekzistas aparta nivelo de servo malkovro kaj monitorado de maŝinoj situantaj en la areto. Ni ne delegas ĉi tiun taskon al la reto. La tasko de la reto estas liveri pakaĵetojn de punkto A ĝis punkto B.
Ni ankaŭ ne havas situaciojn kie adresoj moviĝas ene de la reto, kaj ĉi tio devas esti monitorita. En multaj dezajnoj tio estas tipe necesa por subteni VM-moveblecon. Ni ne uzas la moveblecon de virtualaj maŝinoj en la interna infrastrukturo de la granda Yandex, kaj, krome, ni kredas, ke eĉ se tio estas farita, ĝi ne devus okazi kun reto-subteno. Se ĝi vere devas esti farita, ĝi devas esti farita ĉe la gastiga nivelo, kaj puŝi adresojn, kiuj povas migri en superkovraĵojn, por ne tuŝi aŭ fari tro multajn dinamikajn ŝanĝojn al la envojiga sistemo de la submetaĵo mem (transporta reto). .
Alia teknologio, kiun ni ne uzas, estas multicast. Se vi volas, mi povas rakonti al vi detale kial. Ĉi tio multe pli facilas la vivon, ĉar se iu traktis ĝin kaj rigardis ĝuste kiel aspektas la multirolantaro-kontrolaviadilo, en ĉiuj krom la plej simplaj instalaĵoj, tio estas granda kapdoloro. Kaj kio estas pli, estas malfacile trovi bone funkciantan malfermfontan efektivigon, ekzemple.
Fine ni desegnas niajn retojn por ke ili ne tro ŝanĝu. Ni povas kalkuli je la fakto, ke la fluo de eksteraj eventoj en la vojsistemo estas malgranda.
Kiuj problemoj aperas kaj kiaj limigoj devas esti konsiderataj kiam ni disvolvas datumcentran reton? Kosto, kompreneble. Skalebleco, la nivelo al kiu ni volas kreski. La bezono vastiĝi sen ĉesigi la servon. Bandwidth, havebleco. Videbleco de kio okazas en la reto por monitoraj sistemoj, por operaciaj teamoj. Aŭtomatiga subteno - denove, kiel eble plej multe, ĉar malsamaj taskoj povas esti solvitaj sur malsamaj niveloj, inkluzive de la enkonduko de pliaj tavoloj. Nu, ne [eble] dependas de vendistoj. Kvankam en malsamaj historiaj periodoj, depende de kiu sekcio vi rigardas, ĉi tiu sendependeco estis pli facila aŭ pli malfacile atingi. Se ni prenas sekcon de ret-aparataj blatoj, tiam ĝis antaŭ nelonge estis tre kondiĉe paroli pri sendependeco de vendistoj, se ni ankaŭ volis blatojn kun alta rendimento.
Kian logikan topologion ni uzos por konstrui nian reton? Ĉi tio estos plurnivela Clos. Fakte, ne ekzistas realaj alternativoj nuntempe. Kaj la Clos-topologio estas sufiĉe bona, eĉ se komparite kun diversaj altnivelaj topologioj, kiuj nun estas pli en la areo de akademia intereso, se ni havas grandajn radikŝaltilojn.
Kiel plurnivela Clos-reto estas proksimume strukturita kaj kiel estas la malsamaj elementoj nomataj en ĝi? Antaŭ ĉio, la ventolezo, por orientiĝi kie estas nordo, kie estas sudo, kie estas oriento, kie estas okcidento. Retoj de ĉi tiu tipo estas kutime konstruitaj de tiuj kiuj havas tre grandan okcident-orientan trafikon. Koncerne la ceterajn elementojn, ĉe la supro estas virtuala ŝaltilo kunmetita de pli malgrandaj ŝaltiloj. Ĉi tiu estas la ĉefa ideo de rekursiva konstruado de Clos-retoj. Ni prenas elementojn kun ia radikso kaj ligas ilin por ke tio, kion ni ricevas, estu konsiderata kiel ŝaltilo kun pli granda radikso. Se vi bezonas eĉ pli, la proceduro povas esti ripetita.
En kazoj, ekzemple, kun dunivela Clos, kiam eblas klare identigi komponantojn, kiuj estas vertikalaj en mia diagramo, oni kutime nomas ilin ebenoj. Se ni konstruus Clos kun tri niveloj de spinaj ŝaltiloj (kiuj ĉiuj ne estas limo aŭ ToR-ŝaltiloj kaj kiuj estas uzataj nur por trafiko), tiam la aviadiloj aspektus pli kompleksaj; dunivelaj aspektas ĝuste tiel. Ni nomas blokon de ToR aŭ folioŝaltiloj kaj la unuanivelaj spinŝaltiloj asociitaj kun ili Pod. Spinŝaltiloj de la spino-1-nivelo ĉe la supro de la Pod estas la supro de Pod, la supro de la Pod. La ŝaltiloj, kiuj situas ĉe la supro de la tuta fabriko, estas la supra tavolo de la fabriko, Supro de ŝtofo.
Kompreneble, la demando ekestas: Clos-retoj estas konstruitaj de iom da tempo; la ideo mem ĝenerale venas de la tempoj de klasika telefonio, TDM-retoj. Eble aperis io pli bona, eble io povas esti farita pli bona? Jes kaj ne. Teorie jes, en la praktiko en la proksima estonteco certe ne. Ĉar ekzistas kelkaj interesaj topologioj, kelkaj el ili eĉ estas uzataj en produktado, ekzemple, Dragonfly estas uzata en HPC-aplikoj; Estas ankaŭ interesaj topologioj kiel Xpander, FatClique, Jellyfish. Se vi rigardas raportojn ĉe konferencoj kiel SIGCOMM aŭ NSDI lastatempe, vi povas trovi sufiĉe grandan nombron da verkoj pri alternativaj topologioj, kiuj havas pli bonajn ecojn (unu aŭ alian) ol Clos.
Sed ĉiuj ĉi topologioj havas unu interesan posedaĵon. Ĝi malhelpas ilian efektivigon en datumcentraj retoj, kiujn ni provas konstrui sur varo aparataro kaj kiuj kostas sufiĉe akcepteblan monon. En ĉiuj ĉi tiuj alternativaj topologioj, la plej granda parto de la bendolarĝo bedaŭrinde ne estas alirebla per plej mallongaj vojoj. Tial ni tuj perdas la ŝancon uzi la tradician kontrolaviadilon.
Teorie, la solvo de la problemo estas konata. Ĉi tiuj estas, ekzemple, modifoj de ligŝtato uzanta k-plej mallongan vojon, sed, denove, ne ekzistas tiaj protokoloj kiuj estus efektivigitaj en produktado kaj vaste haveblaj sur ekipaĵo.
Krome, ĉar la plej granda parto de la kapacito ne estas alirebla per plej mallongaj vojoj, ni devas modifi pli ol nur la kontrolaviadilon por elekti ĉiujn tiujn padojn (kaj cetere, tio estas signife pli da stato en la kontrolaviadilo). Ni ankoraŭ devas modifi la plusendan aviadilon, kaj, kiel regulo, almenaŭ du pliaj funkcioj estas bezonataj. Ĉi tio estas la kapablo fari ĉiujn decidojn pri pakaĵeto unufoja, ekzemple, ĉe la gastiganto. Fakte, ĉi tio estas fontvojigo, foje en la literaturo pri interkonektaj retoj tio estas nomita tut-foje plusendado de decidoj. Kaj adapta vojigo estas funkcio, kiun ni bezonas sur retaj elementoj, kio resumas, ekzemple, al tio, ke ni elektas la sekvan salton surbaze de informoj pri la malplej ŝarĝo en la atendovico. Ekzemple, aliaj opcioj estas eblaj.
Tiel, la direkto estas interesa, sed, ve, ni ne povas apliki ĝin nun.
Bone, ni decidis sur la Clos-logika topologio. Kiel ni grilos ĝin? Ni vidu kiel ĝi funkcias kaj kion oni povas fari.
En reto Clos estas du ĉefaj parametroj, kiujn ni iel povas varii kaj akiri certajn rezultojn: la radikso de elementoj kaj la nombro da niveloj en la reto. Mi havas skeman diagramon pri kiel ambaŭ influas la grandecon. Ideale, ni kombinas ambaŭ.
Oni povas vidi, ke la fina larĝo de la reto Clos estas la produkto de ĉiuj niveloj de spinaj ŝaltiloj de la suda radikso, kiom da ligiloj ni havas malsupren, kiel ĝi disbranĉiĝas. Jen kiel ni skalas la grandecon de la reto.
Koncerne kapaciton, precipe ĉe ToR-ŝaltiloj, ekzistas du skalaj opcioj. Aŭ ni povas, konservante la ĝeneralan topologion, uzi pli rapidajn ligilojn, aŭ ni povas aldoni pli da ebenoj.
Se vi rigardas la vastigitan version de la reto Clos (en la malsupra dekstra angulo) kaj revenas al ĉi tiu bildo kun la reto Clos sube...
... tiam tio estas ekzakte la sama topologio, sed sur ĉi tiu glito ĝi estas pli kompakte kolapsita kaj la ebenoj de la fabriko estas supermetitaj unu al la alia. Estas la sama.
Kiel skali reton Clos aspektas en nombroj? Ĉi tie mi donas datumojn pri kia maksimuma larĝa reto povas esti akirita, kian maksimuman nombron da rakoj, ToR-ŝaltiloj aŭ folioŝaltiloj, se ili ne estas en rakoj, ni povas ricevi depende de kia radikso de ŝaltiloj ni uzas por spino-niveloj, kaj kiom da niveloj ni uzas.
Jen kiom da rako ni povas havi, kiom da serviloj kaj proksimume kiom ĉio ĉi povas konsumi surbaze de 20 kW per rako. Iom pli frue mi menciis, ke ni celas aretgrandecon de ĉirkaŭ 100 mil serviloj.
Oni povas vidi, ke en ĉi tiu tuta dezajno interesas du ebloj kaj duono. Estas opcio kun du tavoloj de spinoj kaj 64-havenaj ŝaltiloj, kiu iomete mallonge. Tiam estas perfekte taŭgaj opcioj por 128-havenaj (kun radikso 128) spinaj ŝaltiloj kun du niveloj, aŭ ŝaltiloj kun radikso 32 kun tri niveloj. Kaj en ĉiuj kazoj, kie estas pli da radiksoj kaj pli da tavoloj, oni povas fari tre grandan reton, sed se oni rigardas la atendatan konsumon, kutime estas gigavatoj. Eblas meti kablon, sed ni verŝajne ne ricevos tiom da elektro ĉe unu loko. Se vi rigardas statistikojn kaj publikajn datumojn pri datumcentroj, vi povas trovi tre malmultajn datumcentrojn kun laŭtaksa kapacito de pli ol 150 MW. La pli grandaj estas kutime datumcentraj kampusoj, pluraj grandaj datumcentroj situantaj sufiĉe proksime unu al la alia.
Estas alia grava parametro. Se vi rigardas la maldekstran kolumnon, tie estas listigita uzebla bendolarĝo. Estas facile vidi, ke en Clos-reto grava parto de la havenoj estas uzata por konekti ŝaltilojn unu al la alia. Uzebla bendolarĝo, utila strio, estas io, kion oni povas doni ekstere, al la serviloj. Kompreneble, mi parolas pri kondiĉaj havenoj kaj specife pri la bando. Ĝenerale, ligiloj ene de la reto estas pli rapidaj ol ligiloj al serviloj, sed laŭ unuo de bendolarĝo, tiom kiom ni povas sendi ĝin al nia servila ekipaĵo, ekzistas ankoraŭ iom da bendolarĝo ene de la reto mem. Kaj ju pli da niveloj ni faras, des pli granda estas la specifa kosto provizi ĉi tiun strion al la ekstero.
Cetere, eĉ ĉi tiu aldona bando ne estas ĝuste la sama. Dum la interspacoj estas mallongaj, ni povas uzi ion kiel DAC (rekta liga kupro, tio estas, twinax kabloj), aŭ multimode optiko, kiuj kostas eĉ pli aŭ malpli akceptebla mono. Tuj kiam ni moviĝas al pli longaj intervaloj - kiel regulo, ĉi tiuj estas unureĝimaj optikoj, kaj la kosto de ĉi tiu plia bendolarĝo rimarkeble pliiĝas.
Kaj denove, revenante al la antaŭa diapozitivo, se ni kreas Clos-reton sen troabono, tiam estas facile rigardi la diagramon, vidi kiel la reto estas konstruita - aldonante ĉiun nivelon de spinaj ŝaltiloj, ni ripetas la tutan strion, kiu estis ĉe la fundo. Plus-nivelo - kaj plie la sama bando, la sama nombro da havenoj sur ŝaltiloj kiel estis ĉe la antaŭa nivelo, kaj la sama nombro da transceivers. Tial, estas tre dezirinde minimumigi la nombron da niveloj de spinaj ŝaltiloj.
Surbaze de ĉi tiu bildo, estas klare, ke ni vere volas konstrui ion kiel ŝaltiloj kun radikso de 128.
Ĉi tie, principe, ĉio estas la sama kiel tio, kion mi ĵus diris; ĉi tio estas lumbildo por konsidero poste.
Kiuj opcioj ekzistas, kiujn ni povas elekti kiel tiaj ŝaltiloj? Estas tre agrabla novaĵo por ni, ke nun tiaj retoj finfine povas esti konstruitaj sur unupetaj ŝaltiloj. Kaj ĉi tio estas tre bonega, ili havas multajn belajn funkciojn. Ekzemple, ili preskaŭ ne havas internan strukturon. Ĉi tio signifas, ke ili rompiĝas pli facile. Ili rompiĝas en ĉiaj manieroj, sed feliĉe ili rompiĝas tute. En modulaj aparatoj estas granda nombro da misfunkciadoj (tre malagrablaj), kiam el la vidpunkto de najbaroj kaj la kontrolaviadilo ŝajnas funkcii, sed, ekzemple, parto de la ŝtofo perdiĝis kaj ĝi ne funkcias. je plena kapablo. Kaj la trafiko al ĝi estas ekvilibrigita surbaze de tio, ke ĝi estas plene funkcia, kaj ni povas troŝarĝiĝi.
Aŭ, ekzemple, problemoj ekestas kun la malantaŭa ebeno, ĉar ene de la modula aparato estas ankaŭ altrapida SerDes - ĝi estas vere kompleksa interne. Aŭ la signoj inter plusendaj elementoj estas sinkronigitaj aŭ ne sinkronigitaj. Ĝenerale, ĉiu produktiva modula aparato konsistanta el granda nombro da elementoj, kutime, enhavas la saman Clos-reton en si mem, sed ĝi estas tre malfacile diagnozi. Ofte malfacilas eĉ la vendisto mem diagnozi.
Kaj ĝi havas grandan nombron da malsukcesaj scenaroj, en kiuj la aparato degradas, sed ne tute elfalas el la topologio. Ĉar nia reto estas granda, ekvilibro inter identaj elementoj estas aktive uzata, la reto estas tre regula, tio estas, unu vojo sur kiu ĉio estas en ordo ne diferencas de la alia vojo, estas pli profite por ni simple perdi iom da la aparatoj de la topologio ol finiĝi en situacio kie kelkaj el ili ŝajnas funkcii, sed kelkaj el ili ne.
La sekva bela trajto de unu-blataj aparatoj estas, ke ili evoluas pli bone kaj pli rapide. Ili ankaŭ tendencas havi pli bonan kapablon. Se ni prenas la grandajn kunmetitajn strukturojn, kiujn ni havas sur cirklo, tiam la kapacito per rakunuo por havenoj de la sama rapideco estas preskaŭ duoble pli bona ol tiu de modulaj aparatoj. Aparatoj konstruitaj ĉirkaŭ ununura blato estas rimarkeble pli malmultekostaj ol modulaj kaj konsumas malpli da energio.
Sed, kompreneble, ĉi tio estas ĉio pro kialo, ekzistas ankaŭ malavantaĝoj. Unue, la radikso estas preskaŭ ĉiam pli malgranda ol tiu de modulaj aparatoj. Se ni povas akiri aparaton konstruitan ĉirkaŭ unu blato kun 128 havenoj, tiam ni povas akiri modulan kun kelkcent havenoj nun sen problemoj.
Ĉi tio estas rimarkeble pli malgranda grandeco de plusendaj tabeloj kaj, kiel regulo, ĉio rilata al datum-ebena skalebleco. Malprofundaj bufroj. Kaj, kiel regulo, sufiĉe limigita funkcieco. Sed rezultas, ke se vi konas ĉi tiujn limigojn kaj zorgas ĝustatempe por eviti ilin aŭ simple konsideri ilin, tiam ĉi tio ne estas tiel timiga. La fakto, ke la radikso estas pli malgranda, ne plu estas problemo ĉe aparatoj kun radikso de 128, kiuj finfine aperis lastatempe; ni povas konstrui en du tavoloj de spinoj. Sed estas ankoraŭ neeble konstrui ion pli malgrandan ol du, kio estas interesa por ni. Kun unu nivelo, tre malgrandaj aretoj estas akiritaj. Eĉ niaj antaŭaj dezajnoj kaj postuloj ankoraŭ superis ilin.
Fakte, se subite la solvo estas ie sur la rando, ankoraŭ ekzistas maniero grimpi. Ĉar la lasta (aŭ unua), plej malalta nivelo kie serviloj estas konektitaj estas ToR-ŝaltiloj aŭ folioŝaltiloj, ni ne estas postulataj konekti unu rakon al ili. Sekve, se la solvo mankas ĉirkaŭ duono, vi povas pensi pri simple uzi ŝaltilon kun granda radikso ĉe la pli malalta nivelo kaj konekti, ekzemple, du aŭ tri rakojn en unu ŝaltilon. Ĉi tio ankaŭ estas eblo, ĝi havas siajn kostojn, sed ĝi funkcias sufiĉe bone kaj povas esti bona solvo kiam vi bezonas atingi proksimume duoble la grandecon.
Por resumi, ni konstruas sur topologio kun du niveloj de spinoj, kun ok fabrikaj tavoloj.
Kio okazos al fiziko? Tre simplaj kalkuloj. Se ni havas du nivelojn de spinoj, tiam ni havas nur tri nivelojn de ŝaltiloj, kaj ni atendas, ke estos tri kablaj segmentoj en la reto: de serviloj ĝis folioŝaltiloj, ĝis spino 1, ĝis spino 2. La ebloj kiujn ni povas. use are - ĉi tiuj estas twinax, multimode, single mode. Kaj ĉi tie ni devas konsideri, kia strio disponeblas, kiom ĝi kostos, kiaj estas la fizikaj dimensioj, kiajn ampleksojn ni povas kovri kaj kiel ni ĝisdatigos.
Laŭ kosto, ĉio povas esti vicigita. Twinaxes estas signife pli malmultekosta ol aktiva optiko, pli malmultekosta ol plurmodaj transriceviloj, se vi prenas ĝin per flugo de la fino, iom pli malmultekosta ol 100-gigabit-ŝaltila haveno. Kaj, bonvolu noti, ĝi kostas malpli ol unureĝima optiko, ĉar en flugoj kie unureĝimo estas postulata, en datumcentroj pro kelkaj kialoj havas sencon uzi CWDM, dum paralela unureĝimo (PSM) ne estas tre oportuna labori. kun, tre grandaj pakoj estas akiritaj fibroj, kaj se ni koncentriĝas sur ĉi tiuj teknologioj, ni ricevas proksimume la sekvan prezhierarkion.
Unu plia noto: bedaŭrinde, ne tre eblas uzi malmuntitajn 100 ĝis 4x25 plurmodajn havenojn. Pro la dezajnaj trajtoj de SFP28-riceviloj, ĝi ne estas multe pli malmultekosta ol 28 Gbit QSFP100. Kaj ĉi tiu malmuntado por multimode ne funkcias tre bone.
Alia limigo estas, ke pro la grandeco de la komputikaj aretoj kaj la nombro da serviloj, niaj datumcentroj rezultas fizike grandaj. Ĉi tio signifas, ke almenaŭ unu flugo devos esti farita per singlemod. Denove, pro la fizika grandeco de la Podoj, ne eblos funkcii du interspacojn de twinax (kupraj kabloj).
Kiel rezulto, se ni optimumigas por prezo kaj konsideras la geometrion de ĉi tiu dezajno, ni ricevas unu daŭron de twinax, unu daŭron de multreĝimo kaj unu daŭro de unureĝimo uzante CWDM. Ĉi tio konsideras eblajn ĝisdatigvojojn.
Jen kiel ĝi aspektas lastatempe, kien ni iras kaj kio eblas. Estas klare, almenaŭ, kiel moviĝi al 50-Gigabit SerDes por kaj plurmode kaj unureĝimo. Krome, se vi rigardas kio estas en unu-reĝimaj transceiiloj nun kaj estonte por 400G, ofte eĉ kiam 50G SerDes alvenas de la elektra flanko, 100 Gbps per leno jam povas iri al optiko. Sekve, estas tute eble, ke anstataŭ moviĝi al 50, estos transiro al 100 Gigabit SerDes kaj 100 Gbps por vojo, ĉar laŭ la promesoj de multaj vendistoj, ilia havebleco estas atendita sufiĉe baldaŭ. La periodo, kiam 50G SerDes estis la plej rapidaj, ŝajnas, ne estos tre longa, ĉar la unuaj kopioj de 100G SerDes ekas preskaŭ venontjare. Kaj post iom da tempo post tio ili verŝajne valoros racia mono.
Ankoraŭ unu nuanco pri la elekto de fiziko. Principe, ni jam povas uzi 400 aŭ 200 Gigabit-havenojn uzante 50G SerDes. Sed montriĝas, ke ĉi tio ne havas multe da senco, ĉar, kiel mi diris antaŭe, ni volas sufiĉe grandan radikon sur la ŝaltiloj, en prudento, kompreneble. Ni volas 128. Kaj se ni havas limigitan blaton kapaciton kaj ni pliigas la ligan rapidon, tiam la radikso nature malpliiĝas, ne estas mirakloj.
Kaj ni povas pliigi la totalan kapaciton uzante aviadilojn, kaj ne estas specialaj kostoj; ni povas aldoni la nombron da aviadiloj. Kaj se ni perdas la radikon, ni devos enkonduki plian nivelon, do en la nuna situacio, kun la nuna maksimuma disponebla kapablo per blato, rezultas, ke estas pli efika uzi 100-gigabitajn havenojn, ĉar ili permesas vin. por akiri pli grandan radikon.
La sekva demando estas kiel fiziko estas organizita, sed el la vidpunkto de kabla infrastrukturo. Montriĝas, ke ĝi estas organizita en sufiĉe amuza maniero. Kablado inter folio-ŝaltiloj kaj unuanivelaj pikiloj - tie ne estas multaj ligiloj, ĉio estas konstruita relative simple. Sed se ni prenas unu aviadilon, kio okazas interne estas, ke ni devas ligi ĉiujn spinojn de la unua nivelo kun ĉiuj spinoj de la dua nivelo.
Plie, kiel regulo, estas iuj deziroj pri kiel ĝi devus aspekti ene de la datumcentro. Ekzemple, ni vere volis kombini kablojn en pakaĵon kaj tiri ilin tiel ke unu alta denseca flikpanelo eniru tute en unu flikpanelo, tiel ke ne ekzistis zoo laŭ longoj. Ni sukcesis solvi ĉi tiun problemon. Se vi komence rigardas la logikan topologion, vi povas vidi ke la ebenoj estas sendependaj, ĉiu ebeno povas esti konstruita memstare. Sed kiam ni aldonas tian pakaĵon kaj volas treni la tutan flikpanelon en flikpanelon, ni devas miksi malsamajn aviadilojn ene de unu pakaĵo kaj enkonduki interan strukturon en la formo de optikaj kruckonektoj por repaki ilin de kiel ili estis kunmetitaj. sur unu segmento , en kiel ili estos kolektitaj sur alia segmento. Danke al ĉi tio, ni ricevas belan funkcion: la tuta kompleksa ŝanĝado ne preterpasas la rakojn. Kiam vi bezonas interplekti ion tre forte, "malfaldi la aviadilojn", kiel oni foje nomas ĝin en Clos-retoj, ĉio koncentriĝas ene de unu rako. Ni ne havas tre malmuntitajn, ĝis individuaj ligiloj, ŝanĝante inter rakoj.
Jen kiel ĝi aspektas el la vidpunkto de la logika organizo de la kabla infrastrukturo. En la bildo maldekstre, la multkoloraj blokoj prezentas blokojn de unuanivelaj spinŝaltiloj, po ok pecoj, kaj kvar faskojn da kabloj venantaj de ili, kiuj iras kaj intersekcas kun la faskoj venantaj de la blokoj de spino-2-ŝaltiloj. .
Malgrandaj kvadratoj indikas intersekciĝojn. Supre maldekstre estas paneo de ĉiu tia intersekciĝo, ĉi tio fakte estas 512 per 512 havena kruckoneksa modulo, kiu repakas la kablojn por ke ili eniru tute en unu rako, kie estas nur unu spina-2-aviadilo. Kaj dekstre, skanado de ĉi tiu bildo estas iom pli detala rilate al pluraj Pods ĉe la spino-1-nivelo, kaj kiel ĝi estas pakita en kruckonekto, kiel ĝi venas al la spino-2-nivelo.
Jen kiel ĝi aspektas. La ankoraŭ ne plene kunmetita spino-2-stando (maldekstre) kaj la kruc-koneksa stando. Bedaŭrinde, tie ne estas multe por vidi. Ĉi tiu tuta strukturo estas deplojita nun en unu el niaj grandaj datumcentroj, kiu estas vastigita. Ĉi tio estas laboro en progreso, ĝi aspektos pli bela, ĝi estos plenigita pli bone.
Grava demando: ni elektis la logikan topologion kaj konstruis la fizikon. Kio okazos al la kontrolaviadilo? Ĝi estas sufiĉe konata de funkcianta sperto, ekzistas kelkaj raportoj, ke ligaj ŝtatprotokoloj estas bonaj, estas plezuro labori kun ili, sed, bedaŭrinde, ili ne skalas bone sur dense ligita topologio. Kaj estas unu ĉefa faktoro, kiu malhelpas tion - jen kiel inundo funkcias en protokoloj de ligoŝtataj. Se vi nur prenas la inundan algoritmon kaj rigardas kiel nia reto estas strukturita, vi povas vidi, ke estos tre granda fanout ĉe ĉiu paŝo, kaj ĝi simple inundos la kontrolaviadilon per ĝisdatigoj. Specife, tiaj topologioj miksiĝas tre nebone kun la tradicia inunda algoritmo en ligŝtatprotokoloj.
La elekto estas uzi BGP. Kiel prepari ĝin ĝuste estas priskribita en RFC 7938 pri la uzo de BGP en grandaj datumcentroj. La bazaj ideoj estas simplaj: minimuma nombro da prefiksoj per gastiganto kaj ĝenerale minimuma nombro da prefiksoj en la reto, uzi agregadon se eble, kaj subpremi padĉasadon. Ni volas tre zorgeman, tre kontrolitan distribuadon de ĝisdatigoj, kio nomiĝas valo senpaga. Ni volas, ke ĝisdatigoj estu deplojitaj ĝuste unufoje kiam ili pasas tra la reto. Se ili originas ĉe la fundo, ili supreniras, disfaldante ne pli ol unufoje. Ne devus esti zigzagoj. Zigzagoj estas tre malbonaj.
Por fari tion, ni uzas dezajnon kiu estas sufiĉe simpla por uzi la subestajn BGP-mekanismojn. Tio estas, ni uzas eBGP funkciantan sur loka ligo, kaj aŭtonomaj sistemoj estas asignitaj jene: aŭtonoma sistemo sur ToR, aŭtonoma sistemo sur la tuta bloko de spino-1-ŝaltiloj de unu Pod, kaj ĝenerala aŭtonoma sistemo sur la tuta Top. de Ŝtofo. Ne estas malfacile rigardi kaj vidi, ke eĉ la normala konduto de BGP donas al ni la distribuadon de ĝisdatigoj, kiujn ni volas.
Nature, alparolado kaj adresagregacio devas esti dizajnitaj tiel ke ĝi estas kongrua kun la maniero kiel envojigo estas konstruita, tiel ke ĝi certigu stabilecon de la kontrolaviadilo. L3-adresado en transporto estas ligita al la topologio, ĉar sen tio estas maleble atingi agregadon; sen tio, individuaj adresoj ŝteliĝos en la vojsistemon. Kaj plia afero estas, ke agregado, bedaŭrinde, ne tre bone miksiĝas kun plurvoja, ĉar kiam ni havas plurvojon kaj ni havas agregadon, ĉio estas bona, kiam la tuta reto estas sana, ne estas fiaskoj en ĝi. Bedaŭrinde, tuj kiam malsukcesoj aperas en la reto kaj la simetrio de la topologio estas perdita, ni povas veni al la punkto de kiu la unuo estis anoncita, de kiu ni ne povas iri plu al kie ni devas iri. Sekve, estas plej bone kunigi kie ne ekzistas plu plurvoja, en nia kazo ĉi tiuj estas ToR-ŝaltiloj.
Fakte, eblas kunigi, sed zorge. Se ni povas fari kontrolitan malagregadon kiam okazas retaj fiaskoj. Sed ĉi tio estas sufiĉe malfacila tasko, ni eĉ scivolis, ĉu eblos fari tion, ĉu eblos aldoni plian aŭtomatigon, kaj finajn ŝtatajn maŝinojn, kiuj ĝuste piedbatus BGP por akiri la deziratan konduton. Bedaŭrinde, prilaborado de angulaj kazoj estas tre neevidente kaj kompleksa, kaj ĉi tiu tasko ne estas bone solvita alkroĉante eksterajn aldonaĵojn al BGP.
Tre interesa laboro ĉi-rilate estis farita en la kadro de la RIFT-protokolo, kiu estos priparolata en la venonta raporto.
Alia grava afero estas kiel datumaviadiloj skalas en densaj topologioj, kie ni havas grandan nombron da alternativaj vojoj. En ĉi tiu kazo, pluraj pliaj datumstrukturoj estas uzitaj: ECMP-grupoj, kiuj siavice priskribas Next Hop-grupojn.
En normale funkcianta reto, sen misfunkciadoj, kiam ni supreniras la Clos-topologion, sufiĉas uzi nur unu grupon, ĉar ĉio, kio ne estas loka estas defaŭlte priskribita, ni povas supreniri. Kiam ni iras de supre al malsupro suden, tiam ĉiuj vojoj ne estas ECMP, ili estas ununuraj vojoj. Ĉio estas en ordo. La problemo estas, kaj la propreco de la klasika Clos-topologio estas, ke se ni rigardas la Supron de ŝtofo, ĉe iu ajn elemento, ekzistas nur unu vojo al iu elemento malsupre. Se malsukcesoj okazas laŭ ĉi tiu vojo, tiam ĉi tiu aparta elemento ĉe la supro de la fabriko malvalidiĝas ĝuste por tiuj prefiksoj, kiuj kuŝas malantaŭ la rompita vojo. Sed por la cetero ĝi validas, kaj ni devas analizi la ECMP-grupojn kaj enkonduki novan ŝtaton.
Kiel aspektas la skaleblo de datumaviadiloj sur modernaj aparatoj? Se ni faras LPM (plej longa prefiksa kongruo), ĉio estas sufiĉe bona, pli ol 100k prefiksoj. Se ni parolas pri Next Hop-grupoj, tiam ĉio estas pli malbona, 2-4 mil. Se ni parolas pri tabelo, kiu enhavas priskribon de Next Hops (aŭ apudecoj), tiam ĉi tio estas ie de 16k ĝis 64k. Kaj ĉi tio povas fariĝi problemo. Kaj jen ni venas al interesa digresio: kio okazis al MPLS en datumcentroj? Principe ni volis fari ĝin.
Du aferoj okazis. Ni faris mikro-segmentadon ĉe la gastigantoj; ni ne plu bezonis fari ĝin en la reto. Ĝi ne estis tre bona kun subteno de malsamaj vendistoj, kaj eĉ pli kun malfermitaj efektivigoj sur blankaj skatoloj kun MPLS. Kaj MPLS, almenaŭ ĝiaj tradiciaj efektivigoj, bedaŭrinde, kombinas tre malbone kun ECMP. Kaj tial.
Jen kiel aspektas la plusenda strukturo de ECMP por IP. Granda nombro da prefiksoj povas uzi la saman grupon kaj la saman Next Hops-blokon (aŭ apudaĵoj, tio povas esti nomita alimaniere en malsama dokumentaro por malsamaj aparatoj). La punkto estas, ke ĉi tio estas priskribita kiel la elira haveno kaj al kio reverki la MAC-adreson por atingi la ĝustan Next Hop. Por IP ĉio aspektas simpla, vi povas uzi tre grandan nombron da prefiksoj por la sama grupo, la saman Next Hops-blokon.
La klasika MPLS-arkitekturo implicas ke, depende de la eksiĝinta interfaco, la etikedo povas esti reverkita al malsamaj valoroj. Tial ni devas konservi grupon kaj blokon Next Hops por ĉiu eniga etikedo. Kaj ĉi tio, ve, ne skalas.
Estas facile vidi, ke en nia dezajno ni bezonis ĉirkaŭ 4000 ToR-ŝaltiloj, la maksimuma larĝo estis 64 ECMP-vojoj, se ni malproksimiĝas de spino-1 al spino-2. Ni apenaŭ eniras unu tabelon de ECMP-grupoj, se nur unu prefikso kun ToR foriras, kaj ni tute ne eniras la Tabelon de Next Hops.
Ne ĉio estas senespera, ĉar arkitekturoj kiel Segment Routing implikas tutmondajn etikedojn. Formale, eblus kolapsi ĉiujn ĉi tiujn Next Hops-blokojn denove. Por fari tion, vi bezonas ĵokeran operacion: prenu etikedon kaj reverku ĝin al la sama sen specifa valoro. Sed bedaŭrinde ĉi tio ne tre ĉeestas en la disponeblaj efektivigoj.
Kaj finfine, ni devas alporti eksteran trafikon en la datumcentron. Kiel fari ĝin? Antaŭe, trafiko estis enkondukita en la Clos-reton de supre. Tio estas, estis randaj enkursigiloj, kiuj konektis al ĉiuj aparatoj sur la Supro de ŝtofo. Ĉi tiu solvo funkcias sufiĉe bone sur malgrandaj ĝis mezaj grandecoj. Bedaŭrinde, por sendi trafikon simetrie al la tuta reto tiamaniere, ni devas alveni samtempe al ĉiuj elementoj de la Supro de ŝtofo, kaj kiam estas pli ol cent el ili, rezultas, ke ni ankaŭ bezonas grandan radix sur la randaj enkursigiloj. Ĝenerale, ĉi tio kostas monon, ĉar randaj enkursigiloj estas pli funkciaj, la havenoj sur ili estos pli multekostaj, kaj la dezajno ne estas tre bela.
Alia eblo estas komenci tian trafikon de malsupre. Estas facile kontroli, ke la Clos-topologio estas konstruita tiel, ke trafiko venanta de malsupre, tio estas, de la ToR-flanko, estas egale distribuita inter la niveloj tra la tuta Supro de ŝtofo en du ripetoj, ŝarĝante la tutan reton. Tial ni enkondukas specialan tipon de Pod, Edge Pod, kiu provizas eksteran konekteblecon.
Estas unu plia eblo. Jen kion faras Facebook, ekzemple. Ili nomas ĝin Fabric Aggregator aŭ HGRID. Plia spina nivelo estas enkondukita por konekti plurajn datumcentrojn. Ĉi tiu dezajno eblas se ni ne havas pliajn funkciojn aŭ enkapsulajn ŝanĝojn ĉe la interfacoj. Se ili estas pliaj tuŝpunktoj, estas malfacile. Tipe, ekzistas pli da funkcioj kaj speco de membrano apartiganta malsamajn partojn de la datumcentro. Ne utilas fari tian membranon granda, sed se ĝi estas vere necesa ial, tiam havas sencon konsideri la eblecon forpreni ĝin, igi ĝin kiel eble plej larĝan kaj transdoni ĝin al la gastigantoj. Ĉi tio estas farita, ekzemple, de multaj nubaj operatoroj. Ili havas superkovrojn, ili komencas de la gastigantoj.
Kiajn evoluajn ŝancojn ni vidas? Unue, plibonigante subtenon por la CI/CD-dukto. Ni volas flugi kiel ni testas kaj testi kiel ni flugas. Ĉi tio ne funkcias tre bone, ĉar la infrastrukturo estas granda kaj estas neeble duobligi ĝin por testoj. Vi devas kompreni kiel enkonduki testajn elementojn en la produktan infrastrukturon sen faligi ĝin.
Pli bona instrumentado kaj pli bona monitorado preskaŭ neniam estas superfluaj. La tuta demando estas ekvilibro de penado kaj reveno. Se vi povas aldoni ĝin kun racia peno, tre bone.
Malfermaj operaciumoj por retaj aparatoj. Pli bonaj protokoloj kaj pli bonaj vojsistemoj, kiel ekzemple RIFT. Esploro ankaŭ necesas pri la uzo de pli bonaj obstrukckontrolkabaloj kaj eble la enkonduko, almenaŭ ĉe kelkaj punktoj, de RDMA-subteno ene de la areto.
Rigardante pli en la estontecon, ni bezonas altnivelajn topologiojn kaj eble retojn, kiuj uzas malpli da superkompetoj. El la freŝaj aferoj, ĵus aperis publikaĵoj pri la ŝtofa teknologio por HPC Cray Slingshot, kiu baziĝas sur varo Ethernet, sed kun la eblo uzi multe pli mallongajn kapliniojn. Kiel rezulto, superkosto estas reduktita.
Ĉio estu kiel eble plej simpla, sed ne pli simpla. Komplekseco estas la malamiko de skaleblo. Simpleco kaj regulaj strukturoj estas niaj amikoj. Se vi povas fari skalon ie, faru ĝin. Kaj ĝenerale, estas bonege esti implikita en retaj teknologioj nun. Estas multaj interesaj aferoj okazas. Dankon.
fonto: www.habr.com