Hem desenvolupat un disseny de xarxa de centres de dades que permet el desplegament de clústers informàtics de més de 100 mil servidors amb un ample de banda de bisecció màxim de més d'un petabyte per segon.
A partir de l'informe de Dmitry Afanasyev coneixereu els principis bàsics del nou disseny, les topologies d'escala, els problemes que sorgeixen amb això, les opcions per resoldre'ls, les característiques d'encaminament i l'escala de les funcions del pla de reenviament dels dispositius de xarxa moderns en "densament connectat". topologies amb un gran nombre de rutes ECMP . A més, Dima va parlar breument sobre l'organització de la connectivitat externa, la capa física, el sistema de cablejat i les maneres d'augmentar encara més la capacitat.
- Bona tarda a tothom! Em dic Dmitry Afanasyev, sóc arquitecte de xarxes a Yandex i dissenyo principalment xarxes de centres de dades.
La meva història tractarà sobre la xarxa actualitzada de centres de dades Yandex. És molt una evolució del disseny que teníem, però al mateix temps hi ha alguns elements nous. Aquesta és una presentació general perquè hi havia molta informació per empaquetar en poc temps. Començarem escollint una topologia lògica. A continuació, hi haurà una visió general del pla de control i els problemes amb l'escalabilitat del pla de dades, una elecció del que passarà a nivell físic i veurem algunes característiques dels dispositius. Toquem una mica el que està passant en un centre de dades amb MPLS, del que vam parlar fa un temps.
Aleshores, què és Yandex en termes de càrregues i serveis? Yandex és un hiperescalador típic. Si mirem els usuaris, processem principalment les sol·licituds dels usuaris. També diversos serveis de streaming i transferència de dades, perquè també disposem de serveis d'emmagatzematge. Si està més a prop del backend, hi apareixen càrregues i serveis d'infraestructura, com ara emmagatzematge d'objectes distribuïts, replicació de dades i, per descomptat, cues persistents. Un dels principals tipus de càrregues de treball és MapReduce i sistemes similars, processament de fluxos, aprenentatge automàtic, etc.
Com és la infraestructura sobre la qual passa tot això? De nou, som un hiperescalador força típic, tot i que potser estem una mica més a prop del costat de l'hiperescala menor de l'espectre. Però tenim tots els atributs. Utilitzem maquinari bàsic i escala horitzontal sempre que sigui possible. Tenim una agrupació completa de recursos: no treballem amb màquines individuals, bastidors individuals, sinó que les combinem en un gran conjunt de recursos intercanviables amb alguns serveis addicionals que s'ocupen de la planificació i l'assignació, i treballem amb tot aquest grup.
Així que tenim el següent nivell: el sistema operatiu al nivell de clúster informàtic. És molt important que controlem completament la pila de tecnologia que fem servir. Controlem els punts finals (amfitrions), la xarxa i la pila de programari.
Tenim diversos centres de dades grans a Rússia ia l'estranger. Estan units per una columna vertebral que utilitza tecnologia MPLS. La nostra infraestructura interna es basa gairebé completament en IPv6, però com que hem de servir el trànsit extern que encara prové principalment per IPv4, d'alguna manera hem de lliurar les sol·licituds que arribin a través d'IPv4 als servidors d'interfície, i una mica més anar a IPv4 extern - Internet - per exemple, per a la indexació.
Les últimes iteracions dels dissenys de xarxes de centres de dades han utilitzat topologies Clos multicapa i només són L3. Vam deixar L2 fa una estona i vam respirar alleujats. Finalment, la nostra infraestructura inclou centenars de milers d'instàncies de computació (servidor). La mida màxima del clúster fa un temps era d'uns 10 mil servidors. Això es deu en gran part a com poden funcionar aquests mateixos sistemes operatius a nivell de clúster, programadors, assignació de recursos, etc. Com que s'ha produït un progrés pel que fa al programari d'infraestructura, la mida objectiu és ara uns 100 mil servidors en un clúster informàtic i Tenim una tasca: ser capaços de construir fàbriques de xarxa que permetin l'agrupació eficient de recursos en aquest clúster.
Què volem d'una xarxa de centres de dades? En primer lloc, hi ha molta amplada de banda barata i distribuïda de manera bastant uniforme. Perquè la xarxa és la columna vertebral a través de la qual podem agrupar recursos. La nova mida objectiu és d'uns 100 mil servidors en un clúster.
També, per descomptat, volem un pla de control escalable i estable, perquè en una infraestructura tan gran sorgeixen molts maldecaps fins i tot per esdeveniments simplement aleatoris, i no volem que el pla de control també ens porti mal de cap. Al mateix temps, volem minimitzar l'estat que hi ha. Com més petita sigui la condició, millor i més estable funciona tot, i més fàcil serà diagnosticar.
Per descomptat, necessitem l'automatització, perquè és impossible gestionar una infraestructura d'aquest tipus manualment, i fa temps que ho és. Necessitem suport operatiu tant com sigui possible i suport CI/CD en la mesura que es pugui proporcionar.
Amb aquestes mides de centres de dades i clústers, la tasca de donar suport al desplegament i l'expansió incrementals sense interrupció del servei s'ha tornat força aguda. Si en clústers d'una mida de mil màquines, potser prop de deu mil màquines, encara es podrien desplegar com una sola operació, és a dir, estem planejant una ampliació de la infraestructura i s'afegeixen diversos milers de màquines com una operació, llavors un clúster d'una mida de cent mil màquines no sorgeix immediatament així, es construeix durant un període de temps. I és desitjable que durant tot aquest temps el que ja s'ha bombejat, la infraestructura que s'ha desplegat, estigui disponible.
I un requisit que teníem i que vam deixar: suport per a multitenancy, és a dir, virtualització o segmentació de xarxa. Ara no cal que ho fem a nivell de teixit de xarxa, perquè la fragmentació ha anat als amfitrions i això ens ha facilitat l'escala. Gràcies a IPv6 i un gran espai d'adreces, no calia utilitzar adreces duplicades a la infraestructura interna; totes les adreces ja eren úniques. I gràcies al fet que hem portat el filtratge i la segmentació de xarxa als amfitrions, no necessitem crear cap entitat de xarxa virtual a les xarxes de centres de dades.
Una cosa molt important és allò que no necessitem. Si algunes funcions es poden eliminar de la xarxa, això fa la vida molt més fàcil i, per regla general, amplia l'elecció d'equips i programari disponibles, fent el diagnòstic molt senzill.
Aleshores, què és el que no necessitem, a què hem pogut renunciar, no sempre amb alegria en el moment en què va passar, sinó amb gran alleujament quan s'acaba el procés?
En primer lloc, abandonar la L2. No necessitem L2, ni real ni emulada. No s'utilitza en gran part pel fet que controlem la pila d'aplicacions. Les nostres aplicacions són escalables horitzontalment, funcionen amb adreçament L3, no els preocupa gaire que alguna instància individual hagi sortit, simplement en publiquen una de nova, no cal que es desplega a l'adreça antiga, perquè hi ha una nivell separat de descobriment i supervisió de les màquines situades al clúster. No deleguem aquesta tasca a la xarxa. La feina de la xarxa és lliurar paquets del punt A al punt B.
Tampoc tenim situacions en què les adreces es moguin dins de la xarxa, i això s'ha de controlar. En molts dissenys, això sol ser necessari per donar suport a la mobilitat de VM. No fem servir la mobilitat de les màquines virtuals a la infraestructura interna del gran Yandex i, a més, creiem que encara que es faci això no hauria de passar amb el suport de xarxa. Si realment s'ha de fer, s'ha de fer a nivell d'amfitrió i empènyer adreces que poden migrar a superposicions, per no tocar ni fer massa canvis dinàmics al sistema d'encaminament de la mateixa subposició (xarxa de transport). .
Una altra tecnologia que no fem servir és la multidifusió. Si vols, et puc explicar detalladament per què. Això fa la vida molt més fàcil, perquè si algú s'hi ha ocupat i ha mirat exactament com és el pla de control multicast, en totes les instal·lacions menys en les més senzilles, això és un gran maldecap. I, a més, és difícil trobar una implementació de codi obert que funcioni bé, per exemple.
Finalment, dissenyem les nostres xarxes perquè no canviïn massa. Podem comptar amb el fet que el flux d'esdeveniments externs al sistema d'encaminament és petit.
Quins problemes sorgeixen i quines restriccions s'han de tenir en compte quan desenvolupem una xarxa de centres de dades? Cost, és clar. Escalabilitat, el nivell al qual volem créixer. La necessitat d'ampliar sense aturar el servei. Ample de banda, disponibilitat. Visibilitat del que està passant a la xarxa per a sistemes de monitorització, per a equips operatius. Suport d'automatització: de nou, tant com sigui possible, ja que es poden resoldre diferents tasques a diferents nivells, inclosa la introducció de capes addicionals. Bé, no [possiblement] depèn dels venedors. Encara que en diferents períodes històrics, segons quina secció es miri, aquesta independència era més fàcil o més difícil d'aconseguir. Si prenem una secció transversal dels xips de dispositius de xarxa, fins fa poc era molt condicionat parlar d'independència dels venedors, si també volíem xips d'alt rendiment.
Quina topologia lògica utilitzarem per construir la nostra xarxa? Aquest serà un Clos multinivell. De fet, de moment no hi ha alternatives reals. I la topologia Clos és força bona, fins i tot si es compara amb diverses topologies avançades que ara estan més a l'àrea d'interès acadèmic, si tenim interruptors de radix grans.
Com s'estructura aproximadament una xarxa Clos multinivell i com s'anomenen els diferents elements que hi ha? En primer lloc, la rosa dels vents, per orientar-se on és el nord, on és el sud, on és l'est, on és l'oest. Les xarxes d'aquest tipus solen ser construïdes per aquells que tenen un trànsit molt gran d'oest a est. Pel que fa a la resta d'elements, a la part superior hi ha un interruptor virtual muntat a partir d'interruptors més petits. Aquesta és la idea principal de la construcció recursiva de xarxes Clos. Agafem elements amb algun tipus de radix i els connectem de manera que el que obtenim es pugui considerar com un interruptor amb una base més gran. Si necessiteu encara més, el procediment es pot repetir.
En casos, per exemple, amb Clos de dos nivells, quan és possible identificar clarament components que són verticals al meu diagrama, se solen anomenar plans. Si haguéssim de construir un Clos amb tres nivells d'interruptors de la columna vertebral (tots els quals no són interruptors de límit o ToR i que només s'utilitzen per al trànsit), els avions semblarien més complexos; els de dos nivells semblen exactament així. Anomenem un bloc de ToR o interruptors de fulla i els interruptors de columna de primer nivell associats amb ells un Pod. Els interruptors de la columna vertebral del nivell de la columna vertebral-1 a la part superior del Pod són la part superior del Pod, la part superior del Pod. Els interruptors que es troben a la part superior de tota la fàbrica són la capa superior de la fàbrica, la part superior de la tela.
Per descomptat, sorgeix la pregunta: les xarxes Clos s'han construït des de fa temps; la idea en si mateixa prové generalment dels temps de la telefonia clàssica, les xarxes TDM. Potser ha aparegut alguna cosa millor, potser alguna cosa es pot fer millor? Sí i no. Teòricament sí, a la pràctica en un futur proper definitivament no. Com que hi ha una sèrie de topologies interessants, algunes d'elles fins i tot s'utilitzen en producció, per exemple, Dragonfly s'utilitza en aplicacions HPC; També hi ha topologies interessants com Xpander, FatClique, Jellyfish. Si mireu els informes de conferències com SIGCOMM o NSDI recentment, podeu trobar un nombre bastant gran de treballs sobre topologies alternatives que tenen millors propietats (una o altra) que Clos.
Però totes aquestes topologies tenen una propietat interessant. Impedeix la seva implementació a les xarxes de centres de dades, que estem intentant construir amb maquinari bàsic i que costen diners força raonables. En totes aquestes topologies alternatives, malauradament la major part de l'ample de banda no és accessible a través dels camins més curts. Per tant, de seguida perdem l'oportunitat d'utilitzar el pla de control tradicional.
Teòricament, es coneix la solució del problema. Es tracta, per exemple, de modificacions de l'estat de l'enllaç utilitzant el camí més curt de k, però, de nou, no hi ha protocols d'aquest tipus que s'implementarien en producció i que estarien àmpliament disponibles en equips.
A més, com que la major part de la capacitat no és accessible a través dels camins més curts, hem de modificar més que només el pla de control per seleccionar tots aquests camins (i, per cert, això és significativament més estat al pla de control). Encara hem de modificar el pla de reenviament i, per regla general, calen almenys dues funcions addicionals. Aquesta és la capacitat de prendre totes les decisions sobre el reenviament de paquets una vegada, per exemple, a l'amfitrió. De fet, aquest és l'encaminament de la font, de vegades a la literatura sobre xarxes d'interconnexió això s'anomena decisions d'enviament tot alhora. I l'encaminament adaptatiu és una funció que necessitem als elements de xarxa, que es redueix, per exemple, al fet que seleccionem el següent salt en funció de la informació sobre la menor càrrega de la cua. Com a exemple, altres opcions són possibles.
Per tant, la direcció és interessant, però, per desgràcia, ara mateix no la podem aplicar.
D'acord, ens vam establir per la topologia lògica Clos. Com l'escalarem? A veure com funciona i què es pot fer.
En una xarxa Clos hi ha dos paràmetres principals que d'alguna manera podem variar i obtenir uns resultats determinats: la base d'elements i el nombre de nivells de la xarxa. Tinc un diagrama esquemàtic de com tots dos afecten la mida. L'ideal és que combinem tots dos.
Es pot veure que l'amplada final de la xarxa Clos és el producte de tots els nivells d'interruptors de columna de la base sud, quants enllaços tenim avall, com es ramifica. Així és com escalem la mida de la xarxa.
Pel que fa a la capacitat, especialment als commutadors ToR, hi ha dues opcions d'escalat. O podem, mantenint la topologia general, utilitzar enllaços més ràpids, o podem afegir més plans.
Si mireu la versió ampliada de la xarxa Clos (a la cantonada inferior dreta) i torneu a aquesta imatge amb la xarxa Clos a continuació...
... llavors aquesta és exactament la mateixa topologia, però en aquesta diapositiva es col·lapsa de manera més compacta i els plans de la fàbrica es superposen entre si. És el mateix.
Com es veu escalar una xarxa Clos en xifres? Aquí proporciono dades sobre quina amplada màxima es pot obtenir una xarxa, quin nombre màxim de bastidors, interruptors ToR o interruptors de fulla, si no estan en bastidors, podem obtenir en funció de quina base d'interruptors utilitzem per als nivells de columna, i quants nivells fem servir.
Aquí teniu quants bastidors podem tenir, quants servidors i aproximadament quant pot consumir tot això en funció de 20 kW per bastidor. Una mica abans he esmentat que estem apuntant a una mida de clúster d'uns 100 mil servidors.
Es pot veure que en tot aquest disseny són interessants dues opcions i mitja. Hi ha una opció amb dues capes d'espines i commutadors de 64 ports, que es queda una mica curt. A continuació, hi ha opcions perfectament adaptades per a interruptors de columna de 128 ports (amb radix 128) amb dos nivells, o interruptors amb radix 32 amb tres nivells. I en tots els casos, on hi ha més radixes i més capes, es pot fer una xarxa molt gran, però si ens fixem en el consum previst, normalment hi ha gigawatts. És possible posar un cable, però és poc probable que obtinguem tanta electricitat en un lloc. Si mireu les estadístiques i les dades públiques dels centres de dades, podeu trobar molt pocs centres de dades amb una capacitat estimada de més de 150 MW. Els més grans solen ser campus de centres de dades, diversos centres de dades grans situats bastant a prop els uns dels altres.
Hi ha un altre paràmetre important. Si mireu la columna de l'esquerra, hi apareix l'amplada de banda utilitzable. És fàcil veure que en una xarxa Clos una part important dels ports s'utilitzen per connectar commutadors entre si. L'amplada de banda útil, una tira útil, és quelcom que es pot donar a l'exterior, cap als servidors. Naturalment, parlo de ports condicionals i concretament de la banda. Per regla general, els enllaços dins de la xarxa són més ràpids que els enllaços cap a servidors, però per unitat d'ample de banda, per molt que puguem enviar-lo al nostre equip de servidor, encara hi ha una mica d'ample de banda dins de la pròpia xarxa. I com més nivells fem, més gran serà el cost específic de proporcionar aquesta franja a l'exterior.
A més, fins i tot aquesta banda addicional no és exactament la mateixa. Tot i que els intervals són curts, podem utilitzar alguna cosa com DAC (cobre d'acoblament directe, és a dir, cables twinax) o òptiques multimode, que costen fins i tot diners més o menys raonables. Tan bon punt passem a intervals més llargs, per regla general, es tracta d'òptiques de mode únic i el cost d'aquest ample de banda addicional augmenta notablement.
I de nou, tornant a la diapositiva anterior, si creem una xarxa Clos sense sobresubscripció, llavors és fàcil mirar el diagrama, veure com es construeix la xarxa; afegint cada nivell d'interruptors de columna, repetim tota la tira que hi havia a la inferior. Nivell més: més la mateixa banda, el mateix nombre de ports als interruptors que hi havia al nivell anterior i el mateix nombre de transceptors. Per tant, és molt desitjable minimitzar el nombre de nivells d'interruptors de la columna vertebral.
A partir d'aquesta imatge, està clar que realment volem construir-nos en alguna cosa com interruptors amb una base de 128.
Aquí, en principi, tot és igual que el que acabo de dir; aquesta és una diapositiva per considerar-la més endavant.
Quines opcions hi ha que podem triar com a tals interruptors? És una notícia molt agradable per a nosaltres que ara aquestes xarxes finalment es puguin construir amb commutadors d'un sol xip. I això és molt xulo, tenen moltes característiques agradables. Per exemple, gairebé no tenen estructura interna. Això vol dir que es trenquen més fàcilment. Es trenquen de moltes maneres, però afortunadament es trenquen completament. En els dispositius modulars hi ha un gran nombre d'avaries (molt desagradables), quan des del punt de vista dels veïns i del pla de control sembla que funciona, però, per exemple, s'ha perdut part de la tela i no funciona. a ple rendiment. I el trànsit cap a ella s'equilibra en funció del fet que és totalment funcional i ens podem sobrecarregar.
O, per exemple, sorgeixen problemes amb el pla posterior, perquè dins del dispositiu modular també hi ha SerDes d'alta velocitat: és realment complex a l'interior. O els signes entre els elements de reenviament estan sincronitzats o no. En general, qualsevol dispositiu modular productiu que consta d'un gran nombre d'elements, per regla general, conté la mateixa xarxa Clos al seu interior, però és molt difícil de diagnosticar. Sovint és difícil fins i tot per al propi venedor diagnosticar.
I té un gran nombre d'escenaris de fallada en què el dispositiu es degrada, però no cau completament de la topologia. Com que la nostra xarxa és gran, s'utilitza activament l'equilibri entre elements idèntics, la xarxa és molt regular, és a dir, un camí en el qual tot està en ordre no és diferent de l'altre camí, és més rendible per a nosaltres simplement perdre una mica de els dispositius de la topologia que acabar en una situació en què alguns d'ells semblen funcionar, però alguns no.
La següent característica agradable dels dispositius d'un sol xip és que evolucionen millor i més ràpid. També solen tenir una millor capacitat. Si prenem les grans estructures muntades que tenim en un cercle, aleshores la capacitat per unitat de bastidor per a ports de la mateixa velocitat és gairebé el doble que la dels dispositius modulars. Els dispositius construïts al voltant d'un sol xip són notablement més barats que els modulars i consumeixen menys energia.
Però, és clar, tot això és per un motiu, també hi ha desavantatges. En primer lloc, la base és gairebé sempre més petita que la dels dispositius modulars. Si podem aconseguir un dispositiu construït al voltant d'un xip amb 128 ports, podem obtenir-ne un de modular amb diversos centenars de ports ara sense cap problema.
Aquesta és una mida notablement més petita de les taules de reenviament i, per regla general, tot el relacionat amb l'escalabilitat del pla de dades. Tampons poc profunds. I, per regla general, una funcionalitat força limitada. Però resulta que si coneixeu aquestes restriccions i teniu cura a temps d'evitar-les o simplement de tenir-les en compte, això no fa tanta por. El fet que la base sigui més petita ja no és un problema en dispositius amb una base de 128 que finalment han aparegut recentment; podem construir en dues capes d'espines. Però encara és impossible construir res més petit que dos que sigui interessant per a nosaltres. Amb un nivell s'obtenen clústers molt petits. Fins i tot els nostres dissenys i requisits anteriors encara els superaven.
De fet, si de sobte la solució es troba a la vora, encara hi ha una manera d'escalar. Atès que l'últim (o primer) nivell més baix on els servidors estan connectats són interruptors ToR o interruptors de fulla, no estem obligats a connectar-hi un bastidor. Per tant, si la solució es queda curta aproximadament la meitat, podeu pensar simplement en utilitzar un interruptor amb una base gran al nivell inferior i connectar, per exemple, dos o tres bastidors en un interruptor. Aquesta també és una opció, té els seus costos, però funciona força bé i pot ser una bona solució quan necessites arribar al doble de la mida.
En resum, estem construint sobre una topologia amb dos nivells d'espines, amb vuit capes de fàbrica.
Què passarà amb la física? Càlculs molt senzills. Si tenim dos nivells d'espines, llavors només tenim tres nivells d'interruptors, i esperem que hi hagi tres segments de cable a la xarxa: des dels servidors als interruptors de fulla, a l'espina 1, a l'espina 2. Les opcions que podem use are: són twinax, multimode, mode únic. I aquí hem de considerar quina tira està disponible, quant costarà, quines són les dimensions físiques, quins trams podem cobrir i com actualitzarem.
Pel que fa al cost, tot es pot alinear. Twinaxes són significativament més barats que les òptiques actives, més barats que els transceptors multimode, si ho prens per vol des del final, una mica més barat que un port de commutació de 100 gigabits. I, si us plau, tingueu en compte que costa menys que l'òptica de mode únic, perquè en els vols on es requereix el mode únic, als centres de dades per diverses raons té sentit utilitzar CWDM, mentre que el mode únic paral·lel (PSM) no és molt còmode per treballar. amb, s'obtenen paquets molt grans de fibres, i si ens centrem en aquestes tecnologies, obtenim aproximadament la següent jerarquia de preus.
Una nota més: malauradament, no és molt possible utilitzar ports multimode desmuntats de 100 a 4x25. A causa de les característiques de disseny dels transceptors SFP28, no és molt més barat que 28 Gbit QSFP100. I aquest desmuntatge per multimode no funciona molt bé.
Una altra limitació és que a causa de la mida dels clústers informàtics i del nombre de servidors, els nostres centres de dades resulten ser físicament grans. Això vol dir que almenys un vol s'haurà de fer amb un singlemod. De nou, a causa de la mida física dels Pods, no serà possible executar dos trams de twinax (cables de coure).
Com a resultat, si optimitzem el preu i tenim en compte la geometria d'aquest disseny, obtenim un span de twinax, un span de multimode i un span de monomode mitjançant CWDM. Això té en compte possibles camins d'actualització.
Això és el que sembla recentment, cap a on ens dirigim i què és possible. Està clar, almenys, com avançar cap a SerDes de 50 gigabits tant per a multimode com per a monomode. A més, si observeu què hi ha als transceptors monomode ara i en el futur per a 400G, sovint fins i tot quan arriben 50G SerDes del costat elèctric, 100 Gbps per carril ja poden anar a l'òptica. Per tant, és molt possible que en comptes de passar a 50, hi hagi una transició a 100 Gigabit SerDes i 100 Gbps per carril, perquè segons les promeses de molts venedors, s'espera la seva disponibilitat força aviat. El període en què 50G SerDes van ser els més ràpids, sembla, no serà gaire llarg, perquè les primeres còpies de 100G SerDes es llançaran gairebé l'any vinent. I després d'un temps després d'això, probablement valdran diners raonables.
Un matís més sobre l'elecció de la física. En principi, ja podem utilitzar ports de 400 o 200 Gigabit utilitzant 50G SerDes. Però resulta que això no té gaire sentit, perquè, com he dit abans, volem una base bastant gran als interruptors, dins del raonament, és clar. Volem 128. I si tenim una capacitat de xip limitada i augmentem la velocitat de l'enllaç, aleshores el radix disminueix naturalment, no hi ha miracles.
I podem augmentar la capacitat total utilitzant avions, i no hi ha costos especials; podem afegir el nombre d'avions. I si perdem el radix, haurem d'introduir un nivell addicional, així que en la situació actual, amb la capacitat màxima disponible actual per xip, resulta que és més eficient utilitzar ports de 100 gigabits, perquè et permeten per obtenir una base més gran.
La següent pregunta és com s'organitza la física, però des del punt de vista de la infraestructura del cable. Resulta que està organitzat d'una manera força divertida. Cablejat entre els interruptors de fulla i les espines de primer nivell: no hi ha molts enllaços, tot es construeix de manera relativament senzilla. Però si agafem un avió, el que passa a dins és que hem de connectar totes les espines del primer nivell amb totes les del segon nivell.
A més, per regla general, hi ha alguns desitjos sobre com hauria de ser dins del centre de dades. Per exemple, teníem moltes ganes de combinar cables en un paquet i estirar-los de manera que un panell de connexió d'alta densitat entrés completament en un panell de connexió, de manera que no hi hagués zoo en termes de longitud. Hem aconseguit resoldre aquest problema. Si mireu inicialment la topologia lògica, podeu veure que els plans són independents, cada pla es pot construir pel seu compte. Però quan afegim aquest paquet i volem arrossegar tot el panell de connexió a un panell de connexió, hem de barrejar diferents plans dins d'un paquet i introduir una estructura intermèdia en forma de connexions creuades òptiques per tornar-les a empaquetar des de com es van muntar. en un segment, en com es recolliran en un altre segment. Gràcies a això, obtenim una característica agradable: tota la commutació complexa no va més enllà dels bastidors. Quan necessites entrellaçar alguna cosa amb molta força, "desplegar els avions", com de vegades s'anomena a les xarxes Clos, tot es concentra dins d'un bastidor. No disposem d'enllaços molt desmuntats, fins a enllaços individuals, canviant entre bastidors.
Així es veu des del punt de vista de l'organització lògica de la infraestructura del cable. A la imatge de l'esquerra, els blocs multicolors representen blocs d'interruptors de columna de primer nivell, vuit peces cadascuna, i quatre paquets de cables procedents d'ells, que van i s'entrecreuen amb els paquets procedents dels blocs dels interruptors de la columna vertebral-2. .
Els quadrats petits indiquen interseccions. A la part superior esquerra hi ha un desglossament de cadascuna d'aquestes interseccions, en realitat es tracta d'un mòdul de connexió creuada de ports de 512 per 512 que torna a empaquetar els cables perquè entrin completament en un bastidor, on només hi ha un pla de la columna vertebral-2. I a la dreta, una exploració d'aquesta imatge és una mica més detallada en relació amb diversos Pods al nivell de la columna vertebral-1, i com s'empaqueta en una connexió creuada, com arriba al nivell de la columna vertebral-2.
Això és el que sembla. El suport spine-2 encara no completament muntat (a l'esquerra) i el suport de connexió creuada. Malauradament, no hi ha molt a veure. Tota aquesta estructura s'està desplegant ara mateix en un dels nostres grans centres de dades que s'està ampliant. Aquesta és una obra en curs, quedarà millor, s'omplirà millor.
Una pregunta important: vam triar la topologia lògica i vam construir la física. Què passarà amb l'avió de control? És prou conegut per l'experiència operativa, hi ha una sèrie d'informes que els protocols d'estat d'enllaç són bons, és un plaer treballar amb ells, però, malauradament, no s'escalen bé en una topologia densament connectada. I hi ha un factor principal que ho impedeix: així és com funciona la inundació en els protocols d'estat d'enllaç. Si només agafeu l'algoritme d'inundació i mireu com està estructurada la nostra xarxa, podreu veure que hi haurà un gran ventall a cada pas, i simplement inundarà el pla de control amb actualitzacions. Concretament, aquestes topologies es barregen molt malament amb l'algoritme d'inundació tradicional dels protocols d'estat d'enllaç.
L'opció és utilitzar BGP. Com preparar-lo correctament es descriu a la RFC 7938 sobre l'ús de BGP en grans centres de dades. Les idees bàsiques són senzilles: nombre mínim de prefixos per host i, generalment, nombre mínim de prefixos a la xarxa, utilitzar l'agregació si és possible i suprimir la recerca de camins. Volem una distribució d'actualitzacions molt acurada, molt controlada, el que s'anomena valley free. Volem que les actualitzacions es despleguin exactament una vegada mentre passen per la xarxa. Si s'originen a la part inferior, pugen, desplegant-se no més d'una vegada. No hi hauria d'haver ziga-zagues. Les ziga-zagues són molt dolentes.
Per fer-ho, utilitzem un disseny prou senzill com per utilitzar els mecanismes BGP subjacents. És a dir, utilitzem eBGP que s'executa a l'enllaç local, i els sistemes autònoms s'assignen de la següent manera: un sistema autònom a ToR, un sistema autònom a tot el bloc d'interruptors de la columna vertebral-1 d'un Pod i un sistema autònom general a la part superior. de Teixit. No és difícil mirar i veure que fins i tot el comportament normal de BGP ens dóna la distribució d'actualitzacions que volem.
Naturalment, l'adreçament i l'agregació d'adreces s'han de dissenyar de manera que sigui compatible amb la forma en què es construeix l'encaminament, de manera que garanteixi l'estabilitat del pla de control. L'adreçament L3 en transport està lligat a la topologia, perquè sense això és impossible aconseguir l'agregació; sense això, les adreces individuals s'introduiran al sistema d'encaminament. I una altra cosa és que l'agregació, malauradament, no es barreja molt bé amb la multi-camí, perquè quan tenim multi-camí i tenim agregació, tot està bé, quan tota la xarxa està sana, no hi ha fallades. Malauradament, tan bon punt apareixen fallades a la xarxa i es perd la simetria de la topologia, podem arribar al punt des del qual s'ha anunciat la unitat, des del qual no podem anar més lluny on hem d'anar. Per tant, el millor és agregar on no hi ha més camins múltiples, en el nostre cas es tracta d'interruptors ToR.
De fet, és possible agregar, però amb cura. Si podem fer una desagregació controlada quan es produeixen errors de xarxa. Però aquesta és una tasca bastant difícil, fins i tot ens vam preguntar si seria possible fer-ho, si seria possible afegir automatització addicional i màquines d'estats finits que dispararien correctament BGP per obtenir el comportament desitjat. Malauradament, el processament de casos de cantonada no és molt evident i complex, i aquesta tasca no es resol bé adjuntant fitxers adjunts externs a BGP.
En aquest sentit s'ha fet un treball molt interessant en el marc del protocol RIFT, que es comentarà en el proper informe.
Una altra cosa important és com escalar els plans de dades en topologies denses, on tenim un gran nombre de camins alternatius. En aquest cas, s'utilitzen diverses estructures de dades addicionals: grups ECMP, que al seu torn descriuen els grups Next Hop.
En una xarxa de funcionament normal, sense fallades, quan pugem la topologia Clos, n'hi ha prou amb utilitzar un sol grup, perquè tot allò que no és local està descrit per defecte, podem pujar. Quan anem de dalt a baix cap al sud, aleshores tots els camins no són ECMP, són camins d'un sol camí. Tot està bé. El problema és, i la peculiaritat de la topologia Clos clàssica és que si mirem la part superior de la tela, a qualsevol element, només hi ha un camí cap a qualsevol element a continuació. Si es produeixen errors al llarg d'aquest camí, aquest element en particular a la part superior de la fàbrica esdevé invàlid precisament per als prefixos que hi ha darrere del camí trencat. Però per a la resta és vàlid, i hem d'analitzar els grups ECMP i introduir un nou estat.
Com és l'escalabilitat del pla de dades als dispositius moderns? Si fem LPM (concordança de prefix més llarga), tot està força bé, més de 100 prefixos. Si estem parlant de grups Next Hop, tot és pitjor, 2-4 mil. Si estem parlant d'una taula que conté una descripció de Next Hops (o adjacències), això és entre 16k i 64k. I això pot convertir-se en un problema. I aquí arribem a una digressió interessant: què va passar amb MPLS als centres de dades? En principi, volíem fer-ho.
Van passar dues coses. Vam fer microsegmentació als amfitrions; ja no calia fer-ho a la xarxa. No va ser molt bo amb el suport de diferents venedors, i més encara amb implementacions obertes en caixes blanques amb MPLS. I MPLS, almenys les seves implementacions tradicionals, malauradament, es combina molt malament amb ECMP. I per això.
Així és l'estructura de reenviament ECMP per a IP. Un gran nombre de prefixos poden utilitzar el mateix grup i el mateix bloc Next Hops (o adjacències, això es pot anomenar de manera diferent en documentació diferent per a diferents dispositius). La qüestió és que es descriu com el port de sortida i a què cal reescriure l'adreça MAC per arribar al següent salt correcte. Per a IP, tot sembla senzill, podeu utilitzar un nombre molt gran de prefixos per al mateix grup, el mateix bloc Next Hops.
L'arquitectura MPLS clàssica implica que, depenent de la interfície de sortida, l'etiqueta es pot reescriure a diferents valors. Per tant, hem de mantenir un grup i un bloc Next Hops per a cada etiqueta d'entrada. I això, per desgràcia, no escala.
És fàcil veure que en el nostre disseny necessitàvem uns 4000 interruptors ToR, l'amplada màxima era de 64 camins ECMP, si ens allunyem de la columna vertebral-1 cap a la columna vertebral-2. Amb prou feines entrem a una taula de grups ECMP, si només desapareix un prefix amb ToR i no entrem a la taula Next Hops.
No tot és desesperançador, perquè arquitectures com Segment Routing impliquen etiquetes globals. Formalment, seria possible tornar a col·lapsar tots aquests blocs Next Hops. Per fer-ho, necessiteu una operació de tipus comodí: agafeu una etiqueta i torneu-la a escriure a la mateixa sense un valor concret. Però, malauradament, això no està gaire present a les implementacions disponibles.
I, finalment, hem de portar trànsit extern al centre de dades. Com fer-ho? Anteriorment, el trànsit s'introduïa a la xarxa de Clos des de dalt. És a dir, hi havia encaminadors de vora que es connectaven a tots els dispositius de la part superior de la tela. Aquesta solució funciona força bé en mides petites i mitjanes. Malauradament, per tal d'enviar el trànsit simètricament a tota la xarxa d'aquesta manera, hem d'arribar a tots els elements Top of fabric simultàniament, i quan n'hi ha més d'un centenar, resulta que també necessitem un gran radix a els encaminadors de vora. En general, això costa diners, perquè els encaminadors de punta són més funcionals, els ports d'ells seran més cars i el disseny no és molt bonic.
Una altra opció és iniciar aquest trànsit des de baix. És fàcil comprovar que la topologia Clos està construïda de manera que el trànsit que ve des de baix, és a dir, des del costat del ToR, es distribueix uniformement entre els nivells per tota la part superior de la tela en dues iteracions, carregant tota la xarxa. Per tant, introduïm un tipus especial de pod, Edge Pod, que proporciona connectivitat externa.
Hi ha una opció més. Això és el que fa Facebook, per exemple. L'anomenen Fabric Aggregator o HGRID. S'està introduint un nivell de columna addicional per connectar diversos centres de dades. Aquest disseny és possible si no tenim funcions addicionals o canvis d'encapsulació a les interfícies. Si són punts de contacte addicionals, és difícil. Normalment, hi ha més funcions i una mena de membrana que separa diferents parts del centre de dades. No té sentit fer una membrana tan gran, però si realment es necessita per algun motiu, té sentit considerar la possibilitat de treure-la, fer-la el més ampla possible i transferir-la als amfitrions. Això ho fan, per exemple, molts operadors de núvol. Tenen superposicions, parteixen dels amfitrions.
Quines oportunitats de desenvolupament veiem? En primer lloc, millorar el suport per al pipeline CI/CD. Volem volar com ho posem a prova i provar com volem. Això no funciona molt bé, perquè la infraestructura és gran i és impossible duplicar-la per a proves. Heu d'entendre com introduir elements de prova a la infraestructura de producció sense deixar-los caure.
Una millor instrumentació i un millor seguiment gairebé mai no són superfluos. Tota la qüestió és un equilibri d'esforç i retorn. Si ho podeu afegir amb un esforç raonable, molt bé.
Sistemes operatius oberts per a dispositius de xarxa. Millors protocols i millors sistemes d'encaminament, com RIFT. També cal investigar l'ús de millors esquemes de control de la congestió i potser la introducció, almenys en alguns punts, del suport RDMA dins del clúster.
Mirant cap al futur, necessitem topologies avançades i possiblement xarxes que utilitzen menys despeses generals. De les novetats, recentment hi ha hagut publicacions sobre la tecnologia de teixit per a HPC Cray Slingshot, que es basa en Ethernet de productes bàsics, però amb l'opció d'utilitzar capçaleres molt més curtes. Com a resultat, es redueix la sobrecàrrega.
Tot s'ha de mantenir el més senzill possible, però no més senzill. La complexitat és l'enemic de l'escalabilitat. La senzillesa i les estructures regulars són els nostres amics. Si pots fer-ho en algun lloc, fes-ho. I, en general, és fantàstic estar involucrat en tecnologies de xarxa ara. Hi ha moltes coses interessants passant. Gràcies.
Font: www.habr.com