Olemme kehittäneet datakeskuksen verkkosuunnittelun, joka mahdollistaa yli 100 tuhannen palvelimen laskentaklustereiden käyttöönoton, joiden kaistanleveys on yli yksi petabyytti sekunnissa.
Dmitri Afanasjevin raportista opit uuden suunnittelun perusperiaatteista, skaalaustopologioista, tähän liittyvistä ongelmista, niiden ratkaisuvaihtoehdoista, nykyaikaisten verkkolaitteiden edelleenlähetystason toimintojen reitittämisen ja skaalauksen ominaisuuksista ”tiheästi kytkettynä” topologiat suurella määrällä ECMP-reittejä. Lisäksi Dima kertoi lyhyesti ulkoisen kytkennän organisoinnista, fyysisestä kerroksesta, kaapelointijärjestelmästä ja tavoista lisätä kapasiteettia edelleen.
- Hyvää iltapäivää kaikki! Nimeni on Dmitri Afanasjev, olen verkkoarkkitehti Yandexissä ja suunnittelen ensisijaisesti datakeskusverkkoja.
Tarinani koskee päivitettyä Yandex-palvelinkeskusten verkkoa. Se on pitkälti suunnittelumme kehitystä, mutta samalla on joitain uusia elementtejä. Tämä on yleisesitys, koska pieneen aikaan pakattiin paljon tietoa. Aloitamme valitsemalla loogisen topologian. Sitten tarkastellaan ohjaustasoa ja datatason skaalautuvuuden ongelmia, valitaan mitä tapahtuu fyysisellä tasolla ja tarkastellaan joitain laitteiden ominaisuuksia. Tarkastellaanpa hieman MPLS:n datakeskuksen tapahtumia, josta puhuimme jokin aika sitten.
Joten mikä on Yandex kuormien ja palveluiden suhteen? Yandex on tyypillinen hyperscaler. Jos tarkastelemme käyttäjiä, käsittelemme ensisijaisesti käyttäjien pyyntöjä. Myös erilaisia suoratoistopalveluita ja tiedonsiirtoa, koska meillä on myös tallennuspalveluita. Jos lähempänä taustaa, siellä näkyvät infrastruktuurikuormitukset ja palvelut, kuten hajautettu objektitallennus, tietojen replikointi ja tietysti pysyvät jonot. Yksi työkuormien päätyypeistä on MapReduce ja vastaavat järjestelmät, stream-käsittely, koneoppiminen jne.
Millainen on infrastruktuuri, jonka päällä tämä kaikki tapahtuu? Olemme jälleen melko tyypillinen hyperskaalaaja, vaikka olemme ehkä hieman lähempänä spektrin pienempää hyperskaalaajaa. Mutta meillä on kaikki ominaisuudet. Käytämme hyödykelaitteistoa ja horisontaalista skaalausta aina kun mahdollista. Meillä on täydellinen resurssien yhdistäminen: emme työskentele yksittäisten koneiden, yksittäisten telineiden kanssa, vaan yhdistämme ne suureksi vaihtokelpoisten resurssien pooliksi joidenkin lisäpalveluiden kanssa, jotka käsittelevät suunnittelua ja allokointia ja toimivat koko poolin kanssa.
Joten meillä on seuraava taso - käyttöjärjestelmä laskentaklusteritasolla. On erittäin tärkeää, että hallitsemme täysin käyttämäämme teknologiapinoa. Hallitsemme päätepisteitä (isäntiä), verkko- ja ohjelmistopinoa.
Meillä on useita suuria datakeskuksia Venäjällä ja ulkomailla. Niitä yhdistää MPLS-tekniikkaa käyttävä runko. Sisäinen infrastruktuurimme on lähes kokonaan rakennettu IPv6:lle, mutta koska meidän on palveltava ulkoista liikennettä, joka tulee edelleen pääosin IPv4:n kautta, meidän on jotenkin toimitettava IPv4:n kautta tulevat pyynnöt käyttöliittymäpalvelimille ja vähän enemmän ulkoiseen IPv4-Internetiin. esimerkiksi indeksointiin.
Muutamassa viimeisessä palvelinkeskusten verkkosuunnittelun iteraatiossa on käytetty monikerroksisia Clos-topologioita ja ne ovat vain L3-muotoisia. Lähdimme L2:sta jokin aika sitten ja huokaisimme helpotuksesta. Lopuksi, infrastruktuurimme sisältää satoja tuhansia laskenta- (palvelin) esiintymiä. Suurin klusterin koko jokin aika sitten oli noin 10 tuhatta palvelinta. Tämä johtuu suurelta osin siitä, miten nuo samat klusteritason käyttöjärjestelmät, aikataulut, resurssien allokointi jne. voivat toimia. Koska infrastruktuuriohjelmistojen puolella on tapahtunut edistystä, tavoitekoko on nyt noin 100 tuhatta palvelinta yhdessä laskentaklusterissa, ja Meillä on tehtävänä - pystyä rakentamaan verkkotehtaita, jotka mahdollistavat tehokkaan resurssien yhdistämisen tällaisessa klusterissa.
Mitä haluamme datakeskusverkolta? Ensinnäkin on paljon halpaa ja melko tasaisesti jakautunutta kaistanleveyttä. Koska verkko on selkäranka, jonka kautta voimme yhdistää resursseja. Uusi tavoitekoko on noin 100 tuhatta palvelinta yhdessä klusterissa.
Haluamme tietysti myös skaalautuvan ja vakaan ohjaustason, koska niin suuressa infrastruktuurissa päänsärkyä syntyy paljon jopa satunnaisista tapahtumista, emmekä halua ohjaustason tuovan meille myös päänsärkyä. Samalla haluamme minimoida sen tilan. Mitä pienempi tila, sitä paremmin ja vakaammin kaikki toimii ja sitä helpompi on diagnosoida.
Tietenkin tarvitsemme automaatiota, koska tällaista infrastruktuuria on mahdotonta hallita manuaalisesti, ja se on ollut mahdotonta jo jonkin aikaa. Tarvitsemme mahdollisimman paljon operatiivista tukea ja CI/CD-tukea siinä määrin kuin se voidaan tarjota.
Tällaisten palvelinkeskusten ja klustereiden kokojen myötä tehtävä asteittaisen käyttöönoton ja laajentamisen tukemisesta ilman palvelun keskeytymistä on tullut varsin akuutiksi. Jos tuhannen koneen kokoisissa klustereissa, ehkä lähes kymmenentuhatta konetta, ne voitaisiin silti ottaa käyttöön yhtenä toimenpiteenä - eli suunnittelemme infrastruktuurin laajentamista ja useita tuhansia koneita lisätään yhtenä toimenpiteenä, silloin sadan tuhannen koneen kokoinen klusteri ei synny heti näin, se rakennetaan ajan kuluessa. Ja on toivottavaa, että koko tämän ajan se, mikä on jo pumpattu pois, eli käyttöön otettu infrastruktuuri, on käytettävissä.
Ja yksi vaatimus, joka meillä oli ja jätettiin: monivuokrauksen tuki eli virtualisointi tai verkon segmentointi. Nyt meidän ei tarvitse tehdä tätä verkkokangastasolla, koska sirpalointi on mennyt isännille ja tämä on tehnyt skaalauksesta erittäin helppoa meille. IPv6:n ja suuren osoiteavaruuden ansiosta meidän ei tarvinnut käyttää päällekkäisiä osoitteita sisäisessä infrastruktuurissa, vaan kaikki osoitteet olivat jo ainutlaatuisia. Ja sen tosiasian ansiosta, että olemme vieneet suodatuksen ja verkon segmentoinnin isäntiin, meidän ei tarvitse luoda virtuaalisia verkkokokonaisuuksia konesaliverkkoihin.
Erittäin tärkeä asia on se, mitä emme tarvitse. Jos jotkin toiminnot voidaan poistaa verkosta, tämä helpottaa elämää huomattavasti ja yleensä laajentaa käytettävissä olevien laitteiden ja ohjelmistojen valikoimaa, mikä tekee diagnosoinnista erittäin yksinkertaista.
Joten mitä emme tarvitse, mistä olemme voineet luopua, emme aina ilolla sen tapahtuessa, mutta suurella helpotuksella, kun prosessi on saatu päätökseen?
Ensinnäkin L2:n hylkääminen. Emme tarvitse L2:ta, ei todellista tai emuloitua. Käyttämätön suurelta osin siksi, että hallitsemme sovelluspinoa. Sovelluksemme ovat vaakasuunnassa skaalautuvia, ne toimivat L3-osoitteiden kanssa, he eivät ole kovin huolissaan siitä, että jokin yksittäinen ilmentymä on sammunut, he yksinkertaisesti ottavat käyttöön uuden, sitä ei tarvitse ottaa käyttöön vanhassa osoitteessa, koska siellä on klusterissa olevien koneiden erillinen palveluiden etsintä ja valvonta. Emme delegoi tätä tehtävää verkostolle. Verkon tehtävänä on toimittaa paketteja pisteestä A pisteeseen B.
Meillä ei myöskään ole tilanteita, joissa osoitteet liikkuvat verkon sisällä, ja tätä on seurattava. Monissa malleissa tätä tarvitaan tyypillisesti virtuaalikoneen liikkuvuuden tukemiseen. Emme käytä virtuaalikoneiden liikkuvuutta suuren Yandexin sisäisessä infrastruktuurissa, ja lisäksi uskomme, että vaikka näin tehdään, sen ei pitäisi tapahtua verkkotuella. Jos se todella on tehtävä, se on tehtävä isäntätasolla ja työnnettävä osoitteet, jotka voivat siirtyä peittokuviin, jotta ne eivät kosketa tai tee liikaa dynaamisia muutoksia itse aluskatteen reititysjärjestelmään (siirtoverkko). .
Toinen tekniikka, jota emme käytä, on monilähetys. Jos haluat, voin kertoa sinulle yksityiskohtaisesti miksi. Tämä helpottaa elämää huomattavasti, sillä jos joku on käsitellyt sitä ja katsonut tarkalleen, miltä monilähetysohjaustaso näyttää kaikissa paitsi yksinkertaisimmissa asennuksissa, se on iso päänsärky. Ja mikä parasta, on vaikea löytää esimerkiksi hyvin toimivaa avoimen lähdekoodin toteutusta.
Lopuksi suunnittelemme verkostomme niin, etteivät ne muutu liikaa. Voimme luottaa siihen, että ulkoisten tapahtumien virta reititysjärjestelmässä on pieni.
Mitä ongelmia syntyy ja mitä rajoituksia tulee ottaa huomioon konesaliverkkoa kehitettäessä? Kustannukset tietysti. Skaalautuvuus, taso, jolle haluamme kasvaa. Tarve laajentaa palvelua pysäyttämättä. Kaistanleveys, saatavuus. Näkyvyys siitä, mitä verkossa tapahtuu valvontajärjestelmille, operatiivisille ryhmille. Automaatiotuki - jälleen niin paljon kuin mahdollista, koska erilaisia tehtäviä voidaan ratkaista eri tasoilla, mukaan lukien lisäkerrosten käyttöönotto. No, ei [mahdollisesti] riippuvainen myyjistä. Vaikka eri historiallisina ajanjaksoina, riippuen siitä, mitä osiota katsot, tämä itsenäisyys oli helpompi tai vaikeampi saavuttaa. Jos otamme poikkileikkauksen verkkolaitteiden siruista, niin viime aikoihin asti oli hyvin ehdollista puhua riippumattomuudesta toimittajista, jos haluttiin myös siruja, joilla on korkea suorituskyky.
Mitä loogista topologiaa käytämme verkkomme rakentamiseen? Tämä on monitasoinen Clos. Itse asiassa todellisia vaihtoehtoja ei tällä hetkellä ole. Ja Clos-topologia on melko hyvä, jopa verrattuna erilaisiin kehittyneisiin topologioihin, jotka ovat nyt enemmän akateemisen kiinnostuksen alueella, jos meillä on suuret kantalukukytkimet.
Miten monitasoinen Clos-verkko on karkeasti rakennettu ja mitä eri elementtejä siinä kutsutaan? Ensinnäkin tuuli nousi suuntautumaan missä on pohjoinen, missä on etelä, missä on itä, missä on länsi. Tällaisia verkkoja rakentavat yleensä ne, joilla on erittäin suuri länsi-idän liikenne. Mitä tulee muihin elementteihin, yläosassa on virtuaalinen kytkin, joka on koottu pienemmistä kytkimistä. Tämä on Clos-verkkojen rekursiivisen rakentamisen pääidea. Otamme elementtejä jollain kantasanalla ja yhdistämme ne niin, että saamaamme voidaan pitää suuremman kantaluvun kytkintä. Jos tarvitset vielä enemmän, toimenpide voidaan toistaa.
Tapauksissa, joissa esimerkiksi kaksitasoinen Clos, kun on mahdollista selkeästi tunnistaa kaaviossani pystysuorat komponentit, niitä kutsutaan yleensä tasoiksi. Jos rakentaisimme Closin, jossa on kolme tasoa selkäkytkimiä (jotka kaikki eivät ole raja- tai ToR-kytkimiä ja joita käytetään vain kauttakulkuun), koneet näyttäisivät monimutkaisemmilta; kaksitasoiset näyttävät täsmälleen tältä. Kutsumme ToR- tai lehtikytkimien lohkoa ja niihin liittyviä ensimmäisen tason selkäkytkimiä Podiksi. Podin yläosassa olevat spine-1-tason selkäkytkimet ovat Podin yläosa, Podin yläosa. Kytkimet, jotka sijaitsevat koko tehtaan yläosassa, ovat tehtaan yläkerros, Top of kangas.
Tietenkin herää kysymys: Clos-verkkoja on rakennettu jo jonkin aikaa, itse idea on yleensä peräisin klassisen puhelintoiminnan, TDM-verkkojen, ajoilta. Ehkä jotain parempaa on ilmestynyt, ehkä jotain voidaan tehdä paremmin? Kyllä ja ei. Teoriassa kyllä, käytännössä lähitulevaisuudessa ehdottomasti ei. Koska on olemassa useita mielenkiintoisia topologioita, joitain niistä käytetään jopa tuotannossa, esimerkiksi Dragonflya käytetään HPC-sovelluksissa; On myös mielenkiintoisia topologioita, kuten Xpander, FatClique, Jellyfish. Jos katsot raportteja konferensseista, kuten SIGCOMM tai NSDI viime aikoina, voit löytää melko suuren määrän teoksia vaihtoehtoisista topologioista, joilla on parempia ominaisuuksia (jollakin toisella) kuin Closilla.
Mutta kaikilla näillä topologioilla on yksi mielenkiintoinen ominaisuus. Se estää niiden toteuttamisen konesaliverkoissa, joita yritämme rakentaa hyödykelaitteistolle ja jotka maksavat melko kohtuullisesti. Kaikissa näissä vaihtoehtoisissa topologioissa suurin osa kaistanleveydestä ei valitettavasti ole käytettävissä lyhimpiä polkuja pitkin. Siksi menetämme välittömästi mahdollisuuden käyttää perinteistä ohjaustasoa.
Teoriassa ratkaisu ongelmaan on tiedossa. Näitä ovat esimerkiksi linkin tilan modifikaatiot k-lyhintä polkua käyttäen, mutta taaskaan ei ole olemassa sellaisia protokollia, jotka olisivat toteutettu tuotannossa ja laajasti saatavilla laitteissa.
Lisäksi, koska suurin osa kapasiteetista ei ole käytettävissä lyhimpiä polkuja pitkin, meidän on muutettava enemmän kuin vain ohjaustasoa valitaksemme kaikki nämä polut (ja muuten, tämä on huomattavasti enemmän tilaa ohjaustasossa). Meidän on vielä muokattava edelleenlähetystasoa, ja yleensä tarvitaan vähintään kaksi lisäominaisuutta. Tämä on kyky tehdä kaikki pakettien edelleenlähetystä koskevat päätökset kertaluonteisesti, esimerkiksi isännässä. Itse asiassa tämä on lähdereititystä, joskus yhteenliittämisverkkoja koskevassa kirjallisuudessa tätä kutsutaan all-at-once-välityspäätöksiksi. Ja adaptiivinen reititys on verkkoelementeissä tarvitsemamme toiminto, joka tiivistyy esimerkiksi siihen, että valitsemme seuraavan hypyn jonon pienimmän kuormituksen perusteella. Esimerkiksi muut vaihtoehdot ovat mahdollisia.
Suunta on siis mielenkiintoinen, mutta valitettavasti emme voi soveltaa sitä juuri nyt.
Okei, päädyimme Closin loogiseen topologiaan. Miten skaalaamme sen? Katsotaan kuinka se toimii ja mitä voidaan tehdä.
Clos-verkossa on kaksi pääparametria, joita voimme jollain tavalla vaihdella ja saada tiettyjä tuloksia: elementtien kantaluku ja verkon tasojen lukumäärä. Minulla on kaavio siitä, kuinka molemmat vaikuttavat kokoon. Ihannetapauksessa yhdistämme molemmat.
Voidaan nähdä, että Clos-verkon lopullinen leveys on eteläisen kannan kaikkien tasojen selkäkytkimien tulo, kuinka monta linkkiä meillä on alaspäin, kuinka se haarautuu. Näin skaalaamme verkon koon.
Mitä tulee kapasiteettiin, erityisesti ToR-kytkimissä, on kaksi skaalausvaihtoehtoa. Voimme joko käyttää nopeampia linkkejä, säilyttäen samalla yleisen topologian, tai voimme lisätä tasoja.
Jos katsot Clos-verkon laajennettua versiota (oikeassa alakulmassa) ja palaat tähän kuvaan, jossa on alla oleva Clos-verkko...
... silloin tämä on täsmälleen sama topologia, mutta tällä dialla se on koottu tiiviimmin ja tehtaan tasot ovat päällekkäin. Se on sama.
Miltä Clos-verkon skaalaus näyttää numeroissa? Tässä annan tietoja siitä, mikä maksimileveys verkko voidaan saada, kuinka paljon telineitä, ToR-kytkimiä tai lehtikytkimiä, jos niitä ei ole telineissä, voimme saada riippuen siitä, mitä kytkinradiksia käytämme selkätasoille, ja kuinka monta tasoa käytämme.
Tässä on kuinka monta telinettä meillä voi olla, kuinka monta palvelinta ja kuinka paljon tämä kaikki voi suunnilleen kuluttaa 20 kW:n telineen perusteella. Hieman aiemmin mainitsin, että tähtäämme noin 100 tuhannen palvelimen klusterikokoon.
Voidaan nähdä, että koko tässä suunnittelussa kaksi ja puoli vaihtoehtoa ovat kiinnostavia. Saatavilla on kaksi kerrosta piikkejä ja 64-porttisia kytkimiä, mikä jää hieman alle. Sitten on täydellisesti sopivat vaihtoehdot 128-porttisille (kantaluvulla 128) kaksitasoisille spine-kytkimille tai 32-tasoisille kytkimille. Ja kaikissa tapauksissa, joissa on enemmän kantalukuja ja kerroksia, voidaan tehdä erittäin suuri verkko, mutta jos tarkastellaan odotettua kulutusta, tyypillisesti siellä on gigawattia. Kaapeli on mahdollista vetää, mutta tuskin saamme yhtä paljon sähköä yhteen paikkaan. Jos tarkastelet datakeskusten tilastoja ja julkisia tietoja, löydät hyvin harvoja palvelinkeskuksia, joiden arvioitu kapasiteetti on yli 150 MW. Suuremmat ovat yleensä datakeskuskampuksia, useita suuria palvelinkeskuksia, jotka sijaitsevat melko lähellä toisiaan.
On toinen tärkeä parametri. Jos katsot vasenta saraketta, käytettävissä oleva kaistanleveys on lueteltu siellä. On helppo havaita, että Clos-verkossa merkittävä osa porteista käytetään kytkimien kytkemiseen toisiinsa. Käytettävä kaistanleveys, hyödyllinen kaistale, on jotain, joka voidaan antaa ulos, palvelimia kohti. Luonnollisesti puhun ehdollisista porteista ja erityisesti bändistä. Verkon sisäiset linkit ovat pääsääntöisesti nopeampia kuin linkit palvelimiin, mutta kaistanleveysyksikköä kohden, niin paljon kuin voimme lähettää sen palvelinlaitteistollemme, itse verkossa on silti jonkin verran kaistanleveyttä. Ja mitä enemmän tasoja teemme, sitä suuremmat ovat tämän raidan ulkopuoliset kustannukset.
Lisäksi edes tämä lisäbändi ei ole aivan sama. Vaikka jännevälit ovat lyhyitä, voimme käyttää jotain DAC:ta (direct attach copper, eli twinax-kaapeleita) tai monimuotooptiikkaa, jotka maksavat jopa enemmän tai vähemmän kohtuullista rahaa. Heti kun siirrymme pidemmälle jännevälille - nämä ovat yleensä yksimuotooptiikkaa, ja tämän lisäkaistanleveyden hinta nousee huomattavasti.
Ja taas, palatakseni edelliseen diaan, jos luomme Clos-verkon ilman ylitilausta, on helppo katsoa kaaviota, nähdä kuinka verkko on rakennettu - lisäämällä jokainen selkäkytkintaso, toistamme koko nauhan, joka oli pohja. Plus taso - plus sama taajuus, sama määrä portteja kytkimissä kuin edellisellä tasolla ja sama määrä lähetin-vastaanottimia. Siksi on erittäin toivottavaa minimoida selkärangan kytkimien tasojen lukumäärä.
Tämän kuvan perusteella on selvää, että haluamme todella rakentaa jotain, kuten kytkimiä, joiden kantaluku on 128.
Tässä periaatteessa kaikki on sama kuin mitä juuri sanoin; tämä on dia myöhemmin harkittavaksi.
Mitä vaihtoehtoja voimme valita sellaisiksi kytkimiksi? Meille on erittäin iloinen uutinen, että nyt tällaisia verkkoja voidaan vihdoin rakentaa yksisiruisille kytkimille. Ja tämä on erittäin siistiä, niissä on paljon mukavia ominaisuuksia. Esimerkiksi niillä ei ole juuri mitään sisäistä rakennetta. Tämä tarkoittaa, että ne hajoavat helpommin. Ne hajoavat kaikin tavoin, mutta onneksi ne rikkoutuvat kokonaan. Modulaarisissa laitteissa on suuri määrä vikoja (erittäin epämiellyttäviä), kun naapureiden ja ohjaustason näkökulmasta näyttää toimivan, mutta esimerkiksi osa kankaasta on kadonnut ja se ei toimi täydellä kapasiteetilla. Ja liikenne siihen on tasapainotettu sen perusteella, että se on täysin toimiva ja voimme ylikuormittua.
Tai esimerkiksi taustalevyn kanssa syntyy ongelmia, koska modulaarisen laitteen sisällä on myös nopeat SerDes - se on todella monimutkainen sisällä. Joko edelleenlähetyselementtien väliset merkit ovat synkronoituja tai niitä ei ole synkronoitu. Yleensä mikä tahansa tuottava modulaarinen laite, joka koostuu suuresta määrästä elementtejä, sisältää pääsääntöisesti saman Clos-verkon sisällään, mutta se on erittäin vaikea diagnosoida. Usein jopa myyjän itsensä on vaikea diagnosoida.
Ja siinä on suuri määrä vikaskenaarioita, joissa laite hajoaa, mutta ei putoa topologiasta kokonaan. Koska verkkomme on suuri, identtisten elementtien välillä tasapainoilua käytetään aktiivisesti, verkko on hyvin säännöllinen, eli yksi polku, jolla kaikki on kunnossa, ei eroa toisesta, meidän on kannattavampaa yksinkertaisesti menettää osa laitteet topologiasta kuin päätyä tilanteeseen, jossa osa niistä näyttää toimivan, mutta osa ei.
Seuraava yksisiruisten laitteiden hieno ominaisuus on, että ne kehittyvät paremmin ja nopeammin. Heillä on myös yleensä parempi kapasiteetti. Jos otamme ne suuret kootut rakenteet, jotka meillä on ympyrän päällä, niin saman nopeuden porttien kapasiteetti telineyksikköä kohti on lähes kaksi kertaa parempi kuin modulaarisilla laitteilla. Yhden sirun ympärille rakennetut laitteet ovat huomattavasti halvempia kuin modulaariset ja kuluttavat vähemmän energiaa.
Mutta tietysti tämä kaikki syystä, on myös haittoja. Ensinnäkin kantaluku on lähes aina pienempi kuin modulaaristen laitteiden. Jos saamme yhden sirun ympärille rakennetun laitteen, jossa on 128 porttia, niin saamme nyt ilman ongelmia modulaarisen, jossa on useita satoja portteja.
Tämä on huomattavasti pienempi välitystaulukoiden koko ja pääsääntöisesti kaikki tietotason skaalautumiseen liittyvä. Matalat puskurit. Ja pääsääntöisesti melko rajoitettu toiminnallisuus. Mutta käy ilmi, että jos tiedät nämä rajoitukset ja huolehdit ajoissa niiden kiertämisestä tai yksinkertaisesti ottamisesta huomioon, tämä ei ole niin pelottavaa. Se, että kantaluku on pienempi, ei ole enää ongelma laitteissa, joissa kantaluku on 128 ja jotka ovat vihdoin ilmestyneet, voimme rakentaa kahteen kerrokseen piikkiä. Mutta silti on mahdotonta rakentaa mitään pienempää kuin kaksi, mikä kiinnostaisi meitä. Yhdellä tasolla saadaan erittäin pieniä klustereita. Jopa aikaisemmat mallimme ja vaatimuksemme ylittivät ne.
Itse asiassa, jos ratkaisu yhtäkkiä on jossain partaalla, on silti olemassa tapa skaalata. Koska viimeinen (tai ensimmäinen), alin taso, johon palvelimet on kytketty, ovat ToR-kytkimet tai lehtikytkimet, meidän ei tarvitse yhdistää yhtä telinettä niihin. Siksi, jos ratkaisu jää noin puoleen, voit harkita yksinkertaisesti suuren kantaluvun käyttämistä alemmalla tasolla ja esimerkiksi kahden tai kolmen telineen yhdistämistä yhdeksi kytkimeksi. Tämä on myös vaihtoehto, sillä on hintansa, mutta se toimii varsin hyvin ja voi olla hyvä ratkaisu, kun sinun täytyy saavuttaa noin kaksinkertainen koko.
Yhteenvetona totean, että rakennamme topologialle, jossa on kaksi tasoa piikit ja kahdeksan tehdaskerrosta.
Mitä fysiikalle tapahtuu? Hyvin yksinkertaisia laskelmia. Jos meillä on kaksi tasoa, meillä on vain kolme tasoa kytkimiä, ja odotamme, että verkossa on kolme kaapelisegmenttiä: palvelimista lehtikytkimiin, selkärankaan 1, selkärankaan 2. Vaihtoehdot, joita voimme käyttö on - nämä ovat twinax, multimode, single mode. Ja tässä meidän on harkittava, mitä nauhaa on saatavilla, kuinka paljon se maksaa, mitkä ovat fyysiset mitat, mitkä jännevälit voimme kattaa ja miten päivitämme.
Kustannusten suhteen kaikki voidaan laittaa riviin. Twinaxit ovat huomattavasti halvempia kuin aktiivinen optiikka, halvempia kuin monimuotolähetin-vastaanottimet, jos ottaa sen per lento, jonkin verran halvempaa kuin 100 gigabitin kytkinportti. Ja huomaa, että se maksaa vähemmän kuin yksimuotooptiikka, koska lennoilla, joilla vaaditaan yksitila, datakeskuksissa on useista syistä järkevää käyttää CWDM:ää, kun taas rinnakkainen single mode (PSM) ei ole kovin kätevää työskennellä. kanssa, erittäin suuria pakkauksia saadaan kuituja, ja jos keskitymme näihin teknologioihin, saamme suunnilleen seuraavan hintahierarkian.
Vielä yksi huomautus: valitettavasti ei ole kovin mahdollista käyttää purettuja 100-4x25-monimuotoportteja. SFP28-lähetin-vastaanottimien suunnitteluominaisuuksien vuoksi se ei ole paljon halvempi kuin 28 Gbit QSFP100. Ja tämä monimuotojen purkaminen ei toimi kovin hyvin.
Toinen rajoitus on, että laskentaklustereiden koosta ja palvelimien lukumäärästä johtuen palvelinkeskuksemme osoittautuvat fyysisesti suuriksi. Tämä tarkoittaa, että vähintään yksi lento on suoritettava singlemodilla. Jälleen, podien fyysisen koon vuoksi ei ole mahdollista käyttää kahta twinaxia (kuparikaapelia).
Tämän seurauksena, jos optimoimme hinnan ja otamme huomioon tämän rakenteen geometrian, saamme yhden twinax-välin, yhden monimuotoisen ja yhden yksimuotoisen CWDM:n avulla. Tämä ottaa huomioon mahdolliset päivityspolut.
Tältä näyttää viime aikoina, mihin ollaan menossa ja mikä on mahdollista. Ainakin on selvää, kuinka siirtyä kohti 50 gigabitin SerDejä sekä moni- että yksimoodissa. Lisäksi, jos tarkastellaan, mitä yksimuotoisissa lähetin-vastaanottimissa on nyt ja tulevaisuudessa 400G:lle, usein jopa 50G SerDien tullessa sähköpuolelta, 100 Gbps kaistaa kohti voi jo mennä optiikkaan. Siksi on täysin mahdollista, että 50:een siirtymisen sijaan siirrytään 100 gigabitin SerDeen ja 100 Gbps:n kaistakohtaiseen nopeuteen, koska monien myyjien lupausten mukaan niiden saatavuutta odotetaan melko pian. Ajanjakso, jolloin 50G SerDit olivat nopeimpia, ei näytä olevan kovin pitkä, koska 100G SerDien ensimmäiset kopiot tulevat myyntiin melkein ensi vuonna. Ja jonkin ajan kuluttua ne ovat todennäköisesti kohtuullisen rahan arvoisia.
Vielä yksi vivahde fysiikan valinnasta. Periaatteessa voimme käyttää jo 400 tai 200 gigabitin portteja 50G SerDesillä. Mutta käy ilmi, että tässä ei ole paljon järkeä, koska, kuten sanoin aiemmin, haluamme kytkimiin melko suuren kantaluvun, tietysti järkeä. Haluamme 128. Ja jos meillä on rajallinen sirukapasiteetti ja lisäämme linkin nopeutta, niin kantaluku luonnollisesti pienenee, ihmeitä ei tapahdu.
Ja voimme lisätä kokonaiskapasiteettia käyttämällä lentokoneita, eikä siitä aiheudu erityisiä kustannuksia; voimme lisätä koneiden lukumäärän. Ja jos menetämme kantaluvun, meidän on otettava käyttöön lisätaso, joten nykyisessä tilanteessa, nykyisellä suurimmalla käytettävissä olevalla sirua kohti, on tehokkaampaa käyttää 100 gigabitin portteja, koska ne mahdollistavat saada suurempi kantaluku.
Seuraava kysymys on, miten fysiikka on organisoitu, mutta kaapeliinfrastruktuurin näkökulmasta. Osoittautuu, että se on järjestetty melko hauskalla tavalla. Kaapelointi lehtikytkimien ja ensimmäisen tason piikien välillä - siellä ei ole paljon linkkejä, kaikki on rakennettu suhteellisen yksinkertaisesti. Mutta jos otamme yhden tason, sisällä tapahtuu niin, että meidän on yhdistettävä kaikki ensimmäisen tason piikit kaikkien toisen tason piikien kanssa.
Lisäksi yleensä on joitain toiveita siitä, miltä sen pitäisi näyttää datakeskuksen sisällä. Halusimme esimerkiksi kovasti yhdistää kaapelit nippuun ja vetää ne niin, että yksi tiheä patch-paneeli meni kokonaan yhdeksi patch-paneeliksi, niin ettei pituudeltaan ollut eläintarhaa. Onnistuimme ratkaisemaan tämän ongelman. Jos katsot aluksi loogista topologiaa, voit nähdä, että tasot ovat itsenäisiä, jokainen taso voidaan rakentaa yksinään. Mutta kun lisäämme tällaisen niputuksen ja haluamme vetää koko patch-paneelin patch-paneeliksi, meidän on sekoitettava eri tasoja yhden nipun sisällä ja esitettävä välirakenne optisten ristiliitäntöjen muodossa, jotta ne pakataan uudelleen siitä, miten ne on koottu. yhdellä segmentillä , miten ne kerätään toisessa segmentissä. Tämän ansiosta saamme mukavan ominaisuuden: kaikki monimutkaiset kytkennät eivät ylitä telineitä. Kun jotain on kietottava hyvin voimakkaasti yhteen, "aukaise tasot", kuten Clos-verkoissa joskus kutsutaan, se kaikki keskittyy yhden telineen sisään. Meillä ei ole kovin osiin purettuja, yksittäisiä linkkejä myöten, vaihtamista telineiden välillä.
Tältä se näyttää kaapeliinfrastruktuurin loogisen organisoinnin kannalta. Vasemmalla olevassa kuvassa moniväriset lohkot kuvaavat kahdeksan kappaletta ensimmäisen tason selkäkytkimien lohkoja ja neljä niistä tulevaa kaapelinippua, jotka menevät ja leikkaavat spine-2-kytkimien lohkoista tulevien nippujen kanssa. .
Pienet neliöt osoittavat risteyksiä. Vasemmassa yläkulmassa on erittely kustakin tällaisesta risteyksestä, tämä on itse asiassa 512 x 512 portin ristikytkentämoduuli, joka pakkaa kaapelit uudelleen niin, että ne tulevat kokonaan yhteen telineeseen, jossa on vain yksi spine-2-taso. Ja oikealla, tämän kuvan skannaus on hieman yksityiskohtaisempi suhteessa useisiin podeihin selkärangan 1 tasolla ja kuinka se on pakattu ristiin, miten se tulee selkärangan 2 tasolle.
Tältä se näyttää. Ei vielä täysin koottu spine-2 jalusta (vasemmalla) ja ristikytkentäteline. Valitettavasti siellä ei ole paljon nähtävää. Tätä koko rakennetta otetaan parhaillaan käyttöön yhdessä laajennettavissa olevista suurista palvelinkeskuksistamme. Tämä on työn alla, se näyttää kauniimmalta, se on täytetty paremmin.
Tärkeä kysymys: valitsimme loogisen topologian ja rakensimme fysiikan. Mitä ohjaustasolle tapahtuu? Se on varsin hyvin tiedossa käyttökokemuksesta, on lukuisia raportteja, että linkkitilaprotokollat ovat hyviä, niiden kanssa on ilo työskennellä, mutta valitettavasti ne eivät skaalaudu hyvin tiheästi kytketyssä topologiassa. Ja on yksi päätekijä, joka estää tämän - näin tulva toimii linkkitilaprotokollassa. Jos otat vain tulvausalgoritmin ja katsot kuinka verkkomme on rakennettu, voit nähdä, että jokaisessa vaiheessa tulee erittäin suuri fanout, ja se yksinkertaisesti tulvii ohjaustason päivityksillä. Erityisesti tällaiset topologiat sekoittuvat erittäin huonosti perinteisen tulvausalgoritmin kanssa linkkitilaprotokollassa.
Vaihtoehtona on käyttää BGP:tä. Kuinka valmistaa se oikein, kuvataan RFC 7938:ssa BGP:n käytöstä suurissa palvelinkeskuksissa. Perusideat ovat yksinkertaiset: etuliitteiden minimimäärä isäntäkohtaisesti ja yleensä minimimäärä etuliitteitä verkossa, käytä aggregointia, jos mahdollista, ja tukahduta polunhaku. Haluamme erittäin huolellisen, hyvin kontrolloidun päivitysten jakelun, niin sanotun laaksovapaan. Haluamme, että päivitykset otetaan käyttöön tarkalleen kerran, kun ne kulkevat verkon läpi. Jos ne ovat peräisin pohjasta, ne nousevat ylös ja avautuvat enintään kerran. Ei saa olla siksakkia. Siksakit ovat erittäin huonoja.
Tätä varten käytämme suunnittelua, joka on riittävän yksinkertainen taustalla olevien BGP-mekanismien käyttämiseksi. Eli käytämme paikallisessa linkissä toimivaa eBGP:tä, ja autonomiset järjestelmät määritetään seuraavasti: autonominen järjestelmä ToR:ssa, autonominen järjestelmä yhden Podin koko spine-1-kytkimien lohkossa ja yleinen autonominen järjestelmä koko Topissa. Kankaasta. Ei ole vaikea katsoa ja nähdä, että jopa BGP:n normaali toiminta antaa meille haluamamme päivitysten jakelun.
Luonnollisesti osoitus ja osoitteiden yhdistäminen on suunniteltava siten, että se on yhteensopiva reitityksen rakentamistavan kanssa, jotta se varmistaa ohjaustason vakauden. L3-osoitteet kuljetuksissa on sidottu topologiaan, koska ilman sitä on mahdotonta saavuttaa aggregaatiota, ilman tätä yksittäiset osoitteet hiipivät reititysjärjestelmään. Ja vielä yksi asia on, että aggregointi ei valitettavasti sekoitu kovin hyvin monitiehen, koska kun meillä on monitie ja meillä on aggregaatio, kaikki on hyvin, kun koko verkko on kunnossa, siinä ei ole vikoja. Valitettavasti heti kun verkossa ilmaantuu vikoja ja topologian symmetria katoaa, voimme päästä siihen pisteeseen, josta yksikkö ilmoitettiin, josta emme voi mennä pidemmälle minne meidän pitää mennä. Siksi on parasta aggregoida siellä, missä ei ole enempää monitietä, meidän tapauksessamme nämä ovat ToR-kytkimiä.
Itse asiassa se on mahdollista yhdistää, mutta huolellisesti. Jos voimme tehdä hallitun erittelyn verkkohäiriöiden sattuessa. Mutta tämä on melko vaikea tehtävä, mietimme jopa, olisiko mahdollista tehdä tämä, onko mahdollista lisätä ylimääräistä automaatiota ja äärellisiä koneita, jotka potkaisivat BGP: n oikein saadakseen halutun käyttäytymisen. Valitettavasti nurkkatapausten käsittely on hyvin epäselvää ja monimutkaista, eikä tätä tehtävää ratkaista hyvin liittämällä ulkoisia liitteitä BGP:hen.
Tässä suhteessa on tehty erittäin mielenkiintoista työtä RIFT-protokollan puitteissa, jota käsitellään seuraavassa raportissa.
Toinen tärkeä asia on kuinka datatasot skaalautuvat tiheissä topologioissa, joissa meillä on suuri määrä vaihtoehtoisia polkuja. Tässä tapauksessa käytetään useita lisätietorakenteita: ECMP-ryhmät, jotka puolestaan kuvaavat Next Hop -ryhmiä.
Normaalisti toimivassa verkossa, ilman vikoja, kun nousemme Clos-topologiaa, riittää vain yhden ryhmän käyttäminen, koska kaikki mikä ei ole paikallista, kuvataan oletusarvoisesti, voimme mennä ylös. Kun mennään ylhäältä alas etelään, kaikki polut eivät ole ECMP:tä, ne ovat yksipolkuja. Kaikki on hyvin. Ongelmana on, ja klassisen Clos-topologian erikoisuus on, että jos katsomme kankaan yläosaa, mitä tahansa elementtiä, on vain yksi polku mihin tahansa alla olevaan elementtiin. Jos tällä polulla tapahtuu virheitä, tämä tietty tehtaan yläosassa oleva elementti ei kelpaa juuri niille etuliitteille, jotka ovat katkenneen polun takana. Mutta muun osalta se on voimassa, ja meidän on jäsennettävä ECMP-ryhmät ja otettava käyttöön uusi tila.
Miltä datatason skaalautuvuus näyttää nykyaikaisissa laitteissa? Jos teemme LPM:n (pisin etuliitesovitus), kaikki on melko hyvin, yli 100 2 etuliitettä. Jos puhumme Next Hop -ryhmistä, niin kaikki on pahempaa, 4-16 tuhatta. Jos puhumme taulukosta, joka sisältää kuvauksen Next Hopsista (tai viereisyydestä), tämä on jossain 64k - XNUMXk. Ja tästä voi tulla ongelma. Ja tässä tulemme mielenkiintoiseen poikkeamaan: mitä tapahtui MPLS:lle datakeskuksissa? Periaatteessa halusimme tehdä sen.
Kaksi asiaa tapahtui. Teimme mikrosegmentoinnin isännissä; meidän ei enää tarvinnut tehdä sitä verkossa. Se ei ollut kovin hyvä eri valmistajien tuella, ja vielä enemmän avoimilla toteutuksilla valkoisissa laatikoissa MPLS:llä. Ja MPLS, ainakin sen perinteiset toteutukset, yhdistyy valitettavasti erittäin huonosti ECMP:n kanssa. Ja siksi.
Tältä näyttää IP-osoitteen ECMP-välitysrakenne. Suuri määrä etuliitteitä voi käyttää samaa ryhmää ja samaa Next Hops -lohkoa (tai vierekkäisyyttä, tätä voidaan kutsua eri dokumentaatioissa eri laitteille). Asia on siinä, että tätä kuvataan lähteväksi portiksi ja mihin MAC-osoite pitää kirjoittaa, jotta oikeaan Next Hopiin päästään. IP:ssä kaikki näyttää yksinkertaiselta, voit käyttää hyvin suurta määrää etuliitteitä samalle ryhmälle, samalle Next Hops -lohkolle.
Klassinen MPLS-arkkitehtuuri tarkoittaa, että lähtevästä liitännästä riippuen etiketti voidaan kirjoittaa eri arvoiksi. Siksi meidän on säilytettävä ryhmä ja Next Hops -lohko jokaiselle syötetunnisteelle. Ja tämä ei valitettavasti skaalaudu.
On helppo huomata, että suunnittelussamme tarvitsimme noin 4000 ToR-kytkintä, maksimileveys oli 64 ECMP-polkua, jos siirrytään spine-1:stä poispäin spine-2:ta kohti. Tuskin pääsemme yhteen ECMP-ryhmien taulukkoon, jos vain yksi ToR-etuliite katoaa, emmekä pääse Next Hops -taulukkoon ollenkaan.
Kaikki ei ole toivotonta, koska segmenttireitityksen kaltaiset arkkitehtuurit sisältävät maailmanlaajuisia nimikkeitä. Muodollisesti olisi mahdollista romuttaa kaikki nämä Next Hops -lohkot uudelleen. Tätä varten tarvitset jokerikorttityyppisen toiminnon: ota tarra ja kirjoita se uudelleen samaksi ilman tiettyä arvoa. Mutta valitettavasti tämä ei ole kovin läsnä käytettävissä olevissa toteutuksissa.
Ja lopuksi meidän on tuotava ulkoinen liikenne datakeskukseen. Kuinka tehdä se? Aikaisemmin liikenne tuotiin Clos-verkkoon ylhäältä. Eli oli reunareitittimiä, jotka yhdistettiin kaikkiin kankaan päällä oleviin laitteisiin. Tämä ratkaisu toimii melko hyvin pienissä ja keskikokoisissa kokoissa. Valitettavasti, jotta voimme lähettää liikenteen symmetrisesti koko verkkoon tällä tavalla, meidän täytyy saapua samanaikaisesti kaikkiin Top of kangasn elementteihin, ja kun niitä on yli sata, käy ilmi, että tarvitsemme myös suuren radix reunareitittimissä. Yleensä tämä maksaa rahaa, koska reunareitittimet ovat toimivampia, niiden portit ovat kalliimpia ja muotoilu ei ole kovin kaunis.
Toinen vaihtoehto on käynnistää tällainen liikenne alhaalta. On helppo todeta, että Clos-topologia on rakennettu siten, että alhaalta eli ToR-puolelta tuleva liikenne jakautuu tasaisesti tasojen kesken koko Top of kangasn läpi kahdessa iteraatiossa kuormiten koko verkkoa. Tästä syystä esittelemme erityisen Podin, Edge Podin, joka tarjoaa ulkoisen liitännän.
On vielä yksi vaihtoehto. Näin tekee esimerkiksi Facebook. He kutsuvat sitä Fabric Aggregatoriksi tai HGRIDiksi. Lisäselkätaso otetaan käyttöön useiden datakeskusten yhdistämiseksi. Tämä suunnittelu on mahdollista, jos meillä ei ole lisätoimintoja tai kapselointimuutoksia rajapinnoissa. Jos ne ovat ylimääräisiä kosketuspisteitä, se on vaikeaa. Tyypillisesti toimintoja on enemmän ja palvelinkeskuksen eri osia erottava kalvo. Ei ole mitään järkeä tehdä tällaista kalvoa suureksi, mutta jos sitä jostain syystä todella tarvitaan, on järkevää harkita mahdollisuutta ottaa se pois, tehdä siitä mahdollisimman leveä ja siirtää se isännille. Näin tekevät esimerkiksi monet pilvioperaattorit. Heillä on päällekkäisyyksiä, ne alkavat isännistä.
Mitä kehitysmahdollisuuksia näemme? Ensinnäkin CI/CD-putken tuen parantaminen. Haluamme lentää niin kuin testaamme ja testaamme tapaamme lentää. Tämä ei toimi kovin hyvin, koska infrastruktuuri on suuri ja sitä on mahdotonta kopioida testejä varten. Sinun on ymmärrettävä, miten testauselementtejä voidaan ottaa tuotantoinfrastruktuuriin pudottamatta sitä.
Parempi instrumentointi ja parempi valvonta eivät ole lähes koskaan tarpeettomia. Koko kysymys on ponnistelun ja tuoton tasapaino. Jos voit lisätä sen kohtuullisella vaivalla, erittäin hyvä.
Avoimet käyttöjärjestelmät verkkolaitteille. Paremmat protokollat ja paremmat reititysjärjestelmät, kuten RIFT. Tutkimusta tarvitaan myös parempien ruuhkanhallintajärjestelmien käyttöön ja ehkä RDMA-tuen käyttöönottoon ainakin joissain kohdissa klusterin sisällä.
Kun katsomme pidemmälle tulevaisuuteen, tarvitsemme kehittyneitä topologioita ja mahdollisesti verkkoja, jotka kuluttavat vähemmän yleiskustannuksia. Tuoreista asioista on viime aikoina ilmestynyt julkaisuja HPC Cray Slingshotin kangasteknologiasta, joka perustuu perus Ethernetiin, mutta jossa on mahdollisuus käyttää paljon lyhyempiä otsikoita. Tämän seurauksena yleiskustannukset vähenevät.
Kaiken tulee olla mahdollisimman yksinkertaista, mutta ei yksinkertaisempaa. Monimutkaisuus on skaalautuvuuden vihollinen. Yksinkertaisuus ja säännölliset rakenteet ovat ystäviämme. Jos voit skaalata jonnekin, tee se. Ja yleensäkin, on hienoa olla nyt mukana verkkoteknologioissa. Paljon mielenkiintoisia asioita on meneillään. Kiitos.
Lähde: will.com