Olyan adatközponti hálózattervet fejlesztettünk ki, amely 100 ezer szervernél nagyobb számítási klaszterek telepítését teszi lehetővé másodpercenként egy petabájt feletti csúcsfelező sávszélességgel.
Dmitrij Afanasjev beszámolójából megismerheti az új tervezés alapelveit, a skálázási topológiákat, az ezzel kapcsolatos problémákat, megoldási lehetőségeket, a modern hálózati eszközök továbbítási sík funkcióinak útválasztási és skálázásának sajátosságait „sűrű kapcsolódásban” topológiák nagyszámú ECMP-útvonallal. Ezen kívül Dima röviden beszélt a külső csatlakozás megszervezéséről, a fizikai rétegről, a kábelezési rendszerről és a kapacitás további növelésének módjairól.
- Jó napot mindenki! A nevem Dmitrij Afanasjev, hálózati építész vagyok a Yandexnél, és elsősorban adatközponti hálózatokat tervezek.
A történetem a Yandex adatközpontok frissített hálózatáról fog szólni. Ez nagymértékben az eddigi dizájn evolúciója, de ugyanakkor van néhány új elem is. Ez egy áttekintő bemutató, mert sok információt kellett rövid időbe becsomagolni. Kezdjük a logikai topológia kiválasztásával. Majd lesz egy áttekintés a vezérlési síkról és az adatsík skálázhatóságával kapcsolatos problémákról, választhatunk arról, hogy mi fog történni fizikai szinten, és megnézzük az eszközök néhány jellemzőjét. Érintsük meg egy kicsit, mi történik egy MPLS-s adatközpontban, amiről már régen beszéltünk.
Tehát mi a Yandex a terhelések és a szolgáltatások szempontjából? A Yandex egy tipikus hiperskálázó. Ha a felhasználókat nézzük, akkor elsősorban a felhasználói kéréseket dolgozzuk fel. Különféle streaming szolgáltatások és adatátvitel is, mert vannak tárolási szolgáltatásaink is. Ha közelebb van a háttérhez, akkor ott megjelennek az infrastrukturális terhelések és szolgáltatások, mint például az elosztott objektumtárolás, az adatreplikáció és természetesen az állandó várólisták. A munkaterhelések egyik fő típusa a MapReduce és hasonló rendszerek, a streamfeldolgozás, a gépi tanulás stb.
Milyen az infrastruktúra, amelyen mindez megtörténik? Ismét egy tipikus hiperskálázók vagyunk, bár talán egy kicsit közelebb vagyunk a spektrum kisebb hiperskálás oldalához. De minden tulajdonságunk megvan. Ahol lehetséges, árucikk hardvert és vízszintes skálázást használunk. Teljes erőforrás-összevonásunk van: nem egyedi gépekkel, egyedi rackekkel dolgozunk, hanem ezeket egy nagy, cserélhető erőforráskészletté egyesítjük néhány további szolgáltatással, amelyek tervezéssel és allokációval foglalkoznak, és ezzel a teljes készlettel dolgozunk.
Tehát megvan a következő szint - az operációs rendszer a számítási klaszter szintjén. Nagyon fontos, hogy teljes mértékben ellenőrizzük az általunk használt technológiai halmazt. Mi irányítjuk a végpontokat (hostokat), a hálózatot és a szoftververmet.
Számos nagy adatközpontunk van Oroszországban és külföldön. Ezeket egy MPLS technológiát alkalmazó gerinc köti össze. Belső infrastruktúránk szinte teljes egészében IPv6-ra épül, de mivel továbbra is elsősorban IPv4-en keresztül érkező külső forgalmat kell kiszolgálnunk, valahogyan el kell juttatnunk az IPv4-en keresztül érkező kéréseket a frontend szerverekre, és egy kicsit többet a külső IPv4-internetre. például indexeléshez.
Az adatközponti hálózatok utolsó néhány iterációja többrétegű Clos topológiát használt, és csak L3-as. Nemrég elhagytuk az L2-t, és megkönnyebbülten felsóhajtottunk. Végül infrastruktúránk több százezer számítási (szerver) példányt tartalmaz. A maximális fürtméret egy ideje körülbelül 10 ezer szerver volt. Ez nagyrészt annak köszönhető, hogy ugyanazok a fürtszintű operációs rendszerek, ütemezők, erőforrás-allokáció stb. hogyan működhetnek. Mivel az infrastruktúra-szoftverek terén előrelépés történt, a célméret jelenleg körülbelül 100 ezer szerver egy számítási klaszterben, ill. Feladatunk van – olyan hálózati gyárakat építeni, amelyek hatékony erőforrás-összevonást tesznek lehetővé egy ilyen klaszterben.
Mit akarunk egy adatközponti hálózattól? Először is sok az olcsó és meglehetősen egyenletesen elosztott sávszélesség. Mert a hálózat a gerinc, amelyen keresztül az erőforrásokat egyesíthetjük. Az új célméret körülbelül 100 ezer szerver egy fürtben.
Természetesen szeretnénk egy skálázható és stabil vezérlősíkot is, mert egy ekkora infrastruktúrán rengeteg fejfájás keletkezik már pusztán véletlenszerű eseményekből is, és nem akarjuk, hogy a vezérlősík is fejfájást okozzon. Ugyanakkor minimalizálni akarjuk benne az állapotot. Minél kisebb az állapot, annál jobban és stabilabban működik minden, és annál könnyebben diagnosztizálható.
Természetesen szükségünk van automatizálásra, mert egy ilyen infrastruktúrát nem lehet kézzel kezelni, és ez egy ideje lehetetlen. Szükségünk van a lehető legnagyobb mértékű működési támogatásra és a CI/CD támogatásra, amennyire csak lehet.
Ilyen méretű adatközpontok és fürtök mellett a növekményes üzembe helyezés és a szolgáltatás megszakítás nélküli bővítésének támogatása igencsak akuttá vált. Ha az ezer gépes, esetleg közel tízezer gépes klasztereken egy műveletként mégis kiterülhetnének - vagyis az infrastruktúra bővítését tervezzük, és több ezer gépet adnak hozzá egy műveletként, akkor egy százezer gépes klaszter nem jön létre azonnal így, hanem egy idő alatt épül fel. És kívánatos, hogy mindvégig rendelkezésre álljon a már kiszivattyúzott, a kiépített infrastruktúra.
És egy követelmény, amit meghagytunk: több bérlés támogatása, azaz virtualizáció vagy hálózati szegmentálás. Most már nem kell ezt megtennünk a hálózati szövet szintjén, mert a sharding a gazdagéphez került, és ez nagyon megkönnyítette a méretezést. Az IPv6-nak és a nagy címtartománynak köszönhetően nem kellett duplikált címeket használnunk a belső infrastruktúrában, már minden címzés egyedi volt. És annak köszönhetően, hogy a szűrést és a hálózati szegmentálást átvittük a gazdagépekre, nem kell virtuális hálózati entitásokat létrehoznunk az adatközponti hálózatokban.
Nagyon fontos, hogy mire nincs szükségünk. Ha egyes funkciók eltávolíthatók a hálózatból, az nagyban megkönnyíti az életet, és általában kibővíti a rendelkezésre álló berendezések és szoftverek választékát, ami nagyon egyszerűvé teszi a diagnosztikát.
Tehát mi az, amire nincs szükségünk, miről tudtunk lemondani, nem mindig örömmel, amikor megtörtént, de nagy megkönnyebbüléssel, amikor a folyamat befejeződik?
Először is az L2 elhagyása. Nincs szükségünk L2-re, sem valódi, sem emulált. Használatlan nagyrészt annak a ténynek köszönhető, hogy mi irányítjuk az alkalmazás veremét. Alkalmazásaink vízszintesen skálázhatók, L3 címzéssel működnek, nem nagyon aggódnak, hogy kiment valami egyedi példány, egyszerűen kidobnak egy újat, azt nem kell a régi címen kiteríteni, mert van egy a fürtben elhelyezkedő gépek külön szintű szolgáltatáskeresése és felügyelete . Ezt a feladatot nem ruházzuk át a hálózatra. A hálózat feladata a csomagok eljuttatása A pontból B pontba.
Nálunk sincs olyan helyzet, amikor a címek a hálózaton belül mozognak, és ezt figyelni kell. Sok tervben ez általában szükséges a virtuális gépek mobilitásának támogatásához. A nagy Yandex belső infrastruktúrájában nem használjuk ki a virtuális gépek mobilitását, sőt, úgy gondoljuk, hogy ha ez meg is történik, hálózati támogatással ez nem történhet meg. Ha valóban meg kell tenni, akkor azt a gazdagép szintjén kell megtenni, és olyan címeket kell beküldeni, amelyek átfedésekbe vándorolhatnak, hogy ne érintsék meg, vagy ne hajtsanak végre túl sok dinamikus változtatást magának az alátétnek (szállítási hálózatnak) az útválasztási rendszerében. .
Egy másik technológia, amelyet nem használunk, a multicast. Ha akarod, részletesen elmondom, miért. Ez nagyban megkönnyíti az életet, mert ha valaki foglalkozott vele és megnézte, hogy pontosan hogyan is néz ki a multicast vezérlősík, a legegyszerűbb telepítések kivételével az nagy fejtörést okoz. S mi több, nehéz például jól működő nyílt forráskódú implementációt találni.
Végül úgy tervezzük meg hálózatainkat, hogy ne változzanak túl sokat. Számíthatunk arra, hogy az útválasztási rendszerben kicsi a külső események áramlása.
Milyen problémák merülnek fel és milyen megszorításokkal kell számolni adatközponti hálózat kialakításánál? Költség, természetesen. Skálázhatóság, az a szint, amelyre növekedni szeretnénk. A szolgáltatás leállítása nélküli terjeszkedés szükségessége. Sávszélesség, elérhetőség. A hálózaton zajló események láthatósága a felügyeleti rendszerek, az operatív csapatok számára. Automatizálási támogatás - ismét, amennyire csak lehetséges, mivel a különböző feladatok különböző szinteken oldhatók meg, beleértve a további rétegek bevezetését. Nos, nem [esetleg] az eladóktól függ. Bár a különböző történelmi időszakokban, attól függően, hogy melyik részt nézi, ez a függetlenség könnyebben vagy nehezebben volt elérhető. Ha a hálózati eszközök chipek keresztmetszetét vesszük, akkor egészen a közelmúltig nagyon feltételes volt, hogy a gyártóktól való függetlenségről beszéljünk, ha nagy áteresztőképességű chipeket is akartunk.
Milyen logikai topológiát fogunk használni hálózatunk felépítéséhez? Ez egy többszintű Clos lesz. Valójában jelenleg nincsenek valódi alternatívák. És a Clos topológia egész jó, még akkor is, ha összehasonlítjuk a különböző fejlett topológiákkal, amelyek most inkább a tudományos érdeklődés körébe tartoznak, ha nagy radix kapcsolóink vannak.
Hogyan épül fel nagyjából egy többszintű Clos hálózat, és hogyan nevezik benne a különböző elemeket? Először is feltámadt a szél, hogy tájékozódjon hol észak, hol dél, hol kelet, hol nyugat. Az ilyen típusú hálózatokat általában azok építik ki, akiknek nagyon nagy a nyugat-keleti forgalmuk. Ami a többi elemet illeti, a tetején egy kisebb kapcsolókból összeállított virtuális kapcsoló található. Ez a Clos hálózatok rekurzív felépítésének fő ötlete. Valamilyen radixszel rendelkező elemeket veszünk, és összekapcsoljuk őket, hogy amit kapunk, az egy nagyobb radixú kapcsolónak tekinthető. Ha még többre van szüksége, az eljárás megismételhető.
Azokban az esetekben, például a kétszintű Clos-oknál, amikor egyértelműen azonosíthatók az ábrán függőlegesen álló alkatrészek, ezeket általában síknak nevezik. Ha egy Clos-t építenénk háromszintű gerinckapcsolókkal (melyek nem határ- vagy ToR kapcsolók, és csak tranzitra szolgálnak), akkor a síkok bonyolultabbak, a kétszintűek pontosan így néznek ki. A ToR vagy levélkapcsolók blokkját és a hozzájuk kapcsolódó első szintű gerinckapcsolókat Pod-nak nevezzük. A spine-1 szint gerinckapcsolói a Pod tetején a Pod teteje, a Pod teteje. Az egész gyár tetején található kapcsolók a gyár felső rétege, a Top of text.
Felmerül persze a kérdés: Clos hálózatokat már egy ideje építenek, maga az ötlet általában a klasszikus telefonálás, a TDM hálózatok idejéből származik. Talán valami jobb jelent meg, esetleg lehet valamit jobban csinálni? Igen és nem. Elméletileg igen, a gyakorlatban a közeljövőben biztosan nem. Mivel számos érdekes topológia létezik, ezek egy részét még a termelésben is használják, például a Dragonfly-t HPC alkalmazásokban használják; Vannak érdekes topológiák is, például Xpander, FatClique, Jellyfish. Ha megnézzük a közelmúltban a SIGCOMM vagy az NSDI konferenciákon készült jelentéseket, meglehetősen sok olyan munkát találhatunk alternatív topológiákon, amelyek jobb tulajdonságokkal rendelkeznek (egyik vagy másik), mint a Clos.
De ezeknek a topológiáknak van egy érdekes tulajdonsága. Megakadályozza azok megvalósítását az adatközponti hálózatokban, amelyeket árucikk hardverekre próbálunk építeni, és amelyek meglehetősen ésszerű pénzbe kerülnek. Ezen alternatív topológiák mindegyikében a sávszélesség nagy része sajnos nem érhető el a legrövidebb utakon. Ezért azonnal elveszítjük a hagyományos vezérlősík használatának lehetőségét.
Elméletileg a probléma megoldása ismert. Ilyenek például a link állapotának k-legrövidebb útvonalon történő módosításai, de ismét nem léteznek olyan protokollok, amelyeket a termelésben implementálnának és széles körben elérhetők lennének a berendezéseken.
Sőt, mivel a kapacitás nagy része nem érhető el a legrövidebb utakon, nem csak a vezérlősíkot kell módosítanunk az összes útvonal kiválasztásához (és mellesleg ez lényegesen több állapot a vezérlősíkon). Még módosítanunk kell a továbbítási síkot, és általában legalább két további szolgáltatásra van szükség. Ez a lehetőség arra, hogy a csomagtovábbítással kapcsolatos összes döntést egyszer hozzuk meg, például a gazdagépen. Valójában ez forrásútválasztás, az összekapcsolási hálózatokról szóló szakirodalomban ezt néha all-at-once továbbítási döntéseknek nevezik. Az adaptív útválasztás pedig egy olyan funkció, amelyre szükségünk van a hálózati elemeken, ami például arra vezethető vissza, hogy a következő ugrást a sor legkisebb terhelésére vonatkozó információk alapján választjuk ki. Például más lehetőségek is lehetségesek.
Így az irány érdekes, de sajnos most nem tudjuk alkalmazni.
Oké, megállapodtunk a Clos logikai topológiánál. Hogyan méretezzük? Lássuk, hogyan működik, és mit lehet tenni.
Egy Clos hálózatban két fő paraméter van, amelyeket valahogy variálhatunk, és bizonyos eredményeket kaphatunk: az elemek gyöke és a szintek száma a hálózatban. Van egy sematikus diagramom arról, hogy mindkettő hogyan befolyásolja a méretet. Ideális esetben a kettőt kombináljuk.
Látható, hogy a Clos hálózat végső szélessége a déli radix összes gerinckapcsolójának szorzata, hogy hány linkünk van lefelé, hogyan ágaz el. Így méretezzük a hálózat méretét.
A kapacitást illetően, különösen a ToR kapcsolókon, két skálázási lehetőség van. Vagy az általános topológia megtartása mellett használhatunk gyorsabb hivatkozásokat, vagy hozzáadhatunk több síkot is.
Ha megnézi a Clos hálózat kibővített változatát (a jobb alsó sarokban), és visszatér ehhez a képhez az alábbi Clos hálózattal...
... akkor ez pontosan ugyanaz a topológia, de ezen a dián tömörebben van összecsukva, és a gyári síkok egymásra vannak rakva. Ez ugyanaz.
Hogyan néz ki egy Clos-hálózat méretezése számokban? Itt adok adatokat arról, hogy mekkora maximális szélesség érhető el egy hálózaton, mekkora számú rack, ToR kapcsoló vagy lapos kapcsoló, ha nincsenek rackben, akkor kaphatunk attól függően, hogy milyen radix kapcsolót használunk a gerincszintekhez, ill. hány szintet használunk.
Íme, hány rackünk lehet, hány szerverünk és körülbelül mennyit fogyaszthat mindez 20 kW-onként rack-enként. Kicsit korábban említettem, hogy körülbelül 100 ezer szerveres klaszterméretre törekszünk.
Látható, hogy ebben az egész kialakításban két és fél lehetőség érdekes. Létezik két rétegű gerincvel és 64 portos kapcsolókkal felszerelt opció, ami kicsit elmarad. Aztán vannak tökéletesen illeszkedő lehetőségek a 128 portos (128-as radix-szel) kétszintű gerinckapcsolókhoz, vagy a 32-es radix-os háromszintes kapcsolókhoz. És minden esetben, ahol több a radix és több a réteg, nagyon nagy hálózatot lehet csinálni, de ha a várható fogyasztást nézzük, akkor jellemzően gigawattok vannak. Lehet kábelt lefektetni, de nem valószínű, hogy egy helyen kapunk ennyi áramot. Ha megnézzük az adatközpontok statisztikáit és nyilvános adatait, nagyon kevés olyan adatközpontot találhatunk, amelynek becsült teljesítménye meghaladja a 150 MW-ot. A nagyobbak általában adatközponti campusok, több nagy adatközpont, amelyek elég közel helyezkednek el egymáshoz.
Van még egy fontos paraméter. Ha megnézi a bal oldali oszlopot, ott látható a használható sávszélesség. Könnyen belátható, hogy a Clos hálózatban a portok jelentős része switchek egymáshoz kötésére szolgál. A használható sávszélesség, hasznos sáv az, amit kívül, a szerverek felé lehet adni. Természetesen a feltételes portokról beszélek, és konkrétan a zenekarról. A hálózaton belüli linkek általában gyorsabbak, mint a szerverekre mutató linkek, de egységnyi sávszélességre vetítve, amennyire ki tudjuk küldeni a szerver berendezésünkre, magán a hálózaton belül még mindig van sávszélesség. És minél több szintet készítünk, annál nagyobb a fajlagos költsége annak, hogy ezt a csíkot kívülre helyezzük.
Ráadásul még ez a kiegészítő sáv sem teljesen ugyanaz. Bár a fesztávok rövidek, használhatunk valami olyasmit, mint a DAC (direkt csatolású réz, azaz twinax kábelek), vagy többmódusú optika, ami még többé-kevésbé ésszerű pénzbe kerül. Amint áttérünk a hosszabb tartományokra - ezek általában egymódusú optikák, és ennek a további sávszélességnek a költsége észrevehetően megnő.
És ismét visszatérve az előző diához, ha túljelentkezés nélkül hozunk létre egy Clos hálózatot, akkor könnyen megnézheti a diagramot, megnézheti, hogyan épül fel a hálózat - minden egyes gerinckapcsoló szint hozzáadásával megismételjük a teljes sávot, amely a alsó. Plusz szint - plusz ugyanaz a sáv, ugyanannyi port a kapcsolókon, mint az előző szinten, és ugyanannyi adó-vevő. Ezért nagyon kívánatos a gerinckapcsolók szintjének minimalizálása.
A kép alapján jól látható, hogy nagyon szeretnénk valami 128-as radix-os kapcsolókra építeni.
Itt elvileg minden ugyanaz, mint amit az imént mondtam, ez egy dia a későbbi megfontolásra.
Milyen lehetőségek közül választhatunk ilyen kapcsolóként? Nagyon kellemes hír számunkra, hogy most végre egychipes kapcsolókra is épülhetnek ilyen hálózatok. És ez nagyon klassz, sok szép funkciójuk van. Például szinte nincs belső szerkezetük. Ez azt jelenti, hogy könnyebben eltörnek. Mindenféle módon eltörnek, de szerencsére teljesen eltörnek. A moduláris eszközökben sok a hiba (nagyon kellemetlen), amikor a szomszédok és a vezérlősík szempontjából úgy tűnik, hogy működik, de például a szövet egy része elveszett és nem működik teljes kapacitással. A forgalom pedig kiegyensúlyozott az alapján, hogy teljesen működőképes, és túlterhelhetünk.
Vagy például problémák merülnek fel a hátlappal, mert a moduláris eszköz belsejében nagy sebességű SerDek is vannak - ez belül nagyon összetett. A továbbítási elemek közötti jelek vagy szinkronban vannak, vagy nincsenek szinkronban. Általában minden nagy számú elemből álló produktív moduláris eszköz általában ugyanazt a Clos-hálózatot tartalmazza, de nagyon nehéz diagnosztizálni. Gyakran még magának az eladónak is nehéz diagnosztizálni.
És számos meghibásodási forgatókönyve van, amelyekben az eszköz leromlik, de nem esik ki teljesen a topológiából. Mivel a hálózatunk nagy, az azonos elemek közötti egyensúlyozást aktívan használják, a hálózat nagyon szabályos, vagyis az egyik út, amelyen minden rendben van, semmiben sem különbözik a másiktól, így kifizetődőbb, ha egyszerűen elveszítünk valamennyit. az eszközöket a topológiából, mint hogy olyan helyzetbe kerüljön, amikor egyesek működni látszanak, de némelyikük nem.
Az egychipes eszközök következő jó tulajdonsága, hogy jobban és gyorsabban fejlődnek. Általában jobb a kapacitásuk is. Ha a nagy összeszerelt szerkezeteket körre vesszük, akkor az azonos sebességű portok rack egységenkénti kapacitása majdnem kétszer akkora, mint a moduláris eszközöké. Az egyetlen chip köré épített eszközök észrevehetően olcsóbbak, mint a modulárisak, és kevesebb energiát fogyasztanak.
De persze ennek mindennek van oka, vannak hátrányai is. Először is, a radix szinte mindig kisebb, mint a moduláris eszközöké. Ha egy chip köré épített, 128 portos eszközt kapunk, akkor most már probléma nélkül kaphatunk egy több száz portos modulárist.
Ez a továbbítási táblák észrevehetően kisebb mérete, és általában minden, ami az adatsík méretezhetőségével kapcsolatos. Sekély pufferek. És általában meglehetősen korlátozott funkcionalitás. De kiderül, hogy ha ismeri ezeket a korlátozásokat, és időben gondoskodik azok megkerüléséről vagy egyszerűen csak figyelembe veszi őket, akkor ez nem olyan ijesztő. Az, hogy a radix kisebb, a mostanában végre megjelent 128-as radixú készülékeken már nem probléma, két réteg tüskébe építhetünk. De még mindig lehetetlen kettőnél kisebbet építeni, ami számunkra érdekes. Egy szinttel nagyon kicsi klasztereket kapunk. Még a korábbi terveink és követelményeink is meghaladták azokat.
Valójában, ha hirtelen a megoldás valahol a szélén van, akkor is van mód a méretezésre. Mivel az utolsó (vagy első) legalacsonyabb szint, ahol a szerverek csatlakoztatva vannak, a ToR kapcsolók vagy a levélkapcsolók, nem kell egy rack-et csatlakoztatnunk hozzájuk. Ezért, ha a megoldás körülbelül a felére esik, megfontolhatja, hogy egyszerűen használjon egy nagy radixszel rendelkező kapcsolót az alsó szinten, és például két vagy három állványt kapcsoljon egy kapcsolóba. Ez is egy opció, ennek megvannak a költségei, de egész jól működik, és jó megoldás lehet, ha kb kétszer akkora méretet kell elérni.
Összefoglalva: egy topológiára építünk, kétszintű gerincekkel, nyolc gyári réteggel.
Mi lesz a fizikával? Nagyon egyszerű számítások. Ha két szintű gerincünk van, akkor csak három szintű kapcsolónk van, és arra számítunk, hogy három kábelszakasz lesz a hálózatban: a szerverektől a levélkapcsolókig, a gerinc 1-ig, a gerinc 2-ig. felhasználása - ezek twinax, multimode, single mode. És itt meg kell fontolnunk, hogy milyen szalag érhető el, mennyibe kerül, mik a fizikai méretei, milyen fesztávokat tudunk lefedni, és hogyan fejlesztjük.
Költség szempontjából mindent sorba lehet állítani. A Twinaxok lényegesen olcsóbbak az aktív optikánál, olcsóbbak a multimódusú adó-vevőknél, ha a végétől járatonként veszed, valamivel olcsóbbak, mint egy 100 gigabites switch port. És kérjük, vegye figyelembe, hogy kevesebbe kerül, mint az egymódusú optika, mert azokon a járatokon, ahol egymódusra van szükség, az adatközpontokban több okból is célszerű a CWDM használata, míg a párhuzamos egymódusú (PSM) nem túl kényelmes. nagyon nagy kiszerelésű szálakat kapunk, és ha ezekre a technológiákra koncentrálunk, akkor megközelítőleg a következő árhierarchiát kapjuk.
Még egy megjegyzés: sajnos nem nagyon lehet szétszerelt 100-4x25-ös multimódusú portokat használni. Az SFP28 adó-vevők tervezési jellemzői miatt nem sokkal olcsóbb, mint a 28 Gbit QSFP100. És ez a többmódú szétszerelés nem működik túl jól.
További korlát, hogy a számítási klaszterek mérete és a szerverek száma miatt adatközpontjaink fizikailag nagynak bizonyulnak. Ez azt jelenti, hogy legalább egy repülést singlemoddal kell végrehajtani. Ismételten a Podok fizikai mérete miatt nem lesz lehetséges két twinax (rézkábel) futtatása.
Ennek eredményeként, ha az árra optimalizálunk, és figyelembe vesszük ennek a kialakításnak a geometriáját, egy span twinaxot, egy többmódusú és egy egymódusú tartományt kapunk a CWDM használatával. Ez figyelembe veszi a lehetséges frissítési útvonalakat.
Így néz ki mostanában, merre tartunk és mi lehetséges. Világos legalább, hogyan kell elmozdulni az 50 gigabites SerDes felé mind a többmódusú, mind az egymódusú módban. Sőt, ha megnézzük, mi van most és a jövőben az egymódusú adó-vevőkben a 400G-nál, sokszor akkor is, amikor elektromos oldalról 50G-s SerDek érkeznek, sávonként 100 Gbps már mehet az optikára. Ezért nagyon is valószínű, hogy az 50-re való átállás helyett 100 Gigabit SerDekre és sávonként 100 Gbps-ra térnek át, mert sok gyártó ígérete szerint ezek elérhetősége meglehetősen hamar várható. Az az időszak, amikor az 50G-s SerDek voltak a leggyorsabbak, úgy tűnik, nem lesz túl hosszú, mert a 100G-s SerDek első példányai szinte jövőre jelennek meg. És egy idő után valószínűleg megérnek ésszerű pénzt.
Még egy árnyalat a fizika kiválasztásával kapcsolatban. Elvileg már 400 vagy 200 Gigabites portot is használhatunk 50G SerDes használatával. De kiderült, hogy ennek nincs sok értelme, mert ahogy korábban mondtam, elég nagy radixot akarunk a kapcsolókon, természetesen az ésszerűség határain belül. 128-at akarunk. És ha korlátozott a chip kapacitásunk, és növeljük a link sebességét, akkor a radix természetesen csökken, nincsenek csodák.
Az összkapacitást pedig repülőgépekkel tudjuk növelni, és nincs külön költség, hozzáadhatjuk a gépek számát. Ha pedig elveszítjük a radixot, akkor egy plusz szintet kell bevezetnünk, így a jelenlegi helyzetben a jelenlegi maximálisan elérhető chipenkénti kapacitás mellett kiderül, hogy hatékonyabb a 100 gigabites portok használata, mert ezek lehetővé teszik. hogy nagyobb radixot kapjunk.
A következő kérdés az, hogy a fizika hogyan szerveződik, de a kábeles infrastruktúra szempontjából. Kiderül, hogy elég viccesen van megszervezve. Kábelezés a lapos kapcsolók és az első szintű tüskék között - ott nincs sok kapcsolat, minden viszonylag egyszerűen van felépítve. De ha egy síkot veszünk, akkor belül az történik, hogy össze kell kapcsolnunk az első szint összes tüskéjét a második szint összes tüskéjével.
Ráadásul általában van néhány kívánság arra vonatkozóan, hogyan nézzen ki az adatközpontban. Például nagyon szerettük volna kötegbe kötni a kábeleket, és úgy húzni őket, hogy egy nagy sűrűségű patch panel teljes egészében egy patch panelbe kerüljön, így hosszát tekintve nincs állatkert. Ezt a problémát sikerült megoldanunk. Ha először megnézzük a logikai topológiát, láthatjuk, hogy a síkok függetlenek, minden sík önállóan is felépíthető. De amikor hozzáadunk egy ilyen kötegelést, és a teljes javítópanelt egy patch panelbe akarjuk húzni, akkor egy kötegben különböző síkokat kell kevernünk, és be kell vezetnünk egy közbenső struktúrát optikai keresztkapcsolatok formájában, hogy újracsomagoljuk őket az összeállításuk szerint. az egyik szegmensen , hogyan lesznek összegyűjtve egy másik szegmensben. Ennek köszönhetően egy jó tulajdonságot kapunk: az összes komplex kapcsolás nem megy túl a rackeken. Amikor valamit nagyon erősen össze kell fonni, „ki kell bontani a síkokat”, ahogy a Clos hálózatokban néha nevezik, akkor mindez egy rack belsejében összpontosul. Nálunk nincs erősen szétszedett, egészen az egyes láncszemekig váltó állványok között.
Így néz ki ez a kábeles infrastruktúra logikus felépítése szempontjából. A bal oldali képen a sokszínű blokkok első szintű gerinckapcsolók blokkjait ábrázolják, egyenként nyolc darabot, és négy, azokból érkező kábelköteget, amelyek mennek és keresztezik a gerinc-2 kapcsolók blokkjaiból érkező kötegeket. .
A kis négyzetek kereszteződéseket jelölnek. A bal felső sarokban az egyes ilyen kereszteződések bontása látható, ez valójában egy 512 x 512 portos keresztcsatlakozó modul, amely újracsomagolja a kábeleket úgy, hogy azok teljesen egy rackbe kerüljenek, ahol csak egy gerinc-2 sík van. A jobb oldalon pedig ennek a képnek a szkennelése egy kicsit részletesebb a gerinc-1 szintjén lévő több Poddal kapcsolatban, és hogyan van csomagolva egy keresztkötésben, hogyan jön a gerinc-2 szintre.
Így néz ki. A még nem teljesen összeszerelt spine-2 állvány (bal oldalon) és a cross-connect állvány. Sajnos nincs ott sok látnivaló. Ezt a teljes struktúrát jelenleg az egyik bővítés alatt álló nagy adatközpontunkban telepítjük. Ez egy folyamatban lévő munka, szebben fog kinézni, jobban ki lesz töltve.
Egy fontos kérdés: a logikai topológiát választottuk és felépítettük a fizikát. Mi lesz a vezérlősíkkal? Üzemeltetési tapasztalatból elég jól ismert, számos híradás érkezett arról, hogy a link állapot protokollok jók, öröm velük dolgozni, de sajnos nem skálázódnak jól egy sűrűn kapcsolódó topológián. És van egy fő tényező, ami ezt megakadályozza – így működik az elárasztás a kapcsolatállapot-protokollokban. Ha csak az elárasztási algoritmust vesszük, és megnézzük a hálózatunk felépítését, láthatjuk, hogy minden lépésnél nagyon nagy fanout lesz, és egyszerűen elárasztja a vezérlősíkot frissítésekkel. Pontosabban, az ilyen topológiák nagyon rosszul keverednek a hagyományos elárasztási algoritmusokkal a kapcsolatállapot-protokollokban.
A választás a BGP használata. A helyes előkészítés módját az RFC 7938 írja le a BGP nagy adatközpontokban való használatáról. Az alapötletek egyszerűek: az előtagok minimális száma állomásonként és általában minimális számú előtag a hálózaton, lehetőség szerint használjon összesítést, és tiltsa le az útvonalkeresést. A frissítések nagyon körültekintő, nagyon ellenőrzött terjesztését akarjuk, amit úgy hívnak, hogy völgy ingyenes. Azt akarjuk, hogy a frissítések pontosan egyszer kerüljenek telepítésre, amint áthaladnak a hálózaton. Ha alulról erednek, felfelé mennek, legfeljebb egyszer bontakoznak ki. Nem lehetnek cikcakkok. A cikcakk nagyon rossz.
Ehhez olyan kialakítást használunk, amely elég egyszerű ahhoz, hogy a mögöttes BGP-mechanizmusokat használjuk. Ez azt jelenti, hogy helyi linken futó eBGP-t használunk, és az autonóm rendszerek a következőképpen vannak hozzárendelve: egy autonóm rendszer a ToR-on, egy autonóm rendszer az egyik Pod gerinc-1 kapcsolóinak teljes blokkján, és egy általános autonóm rendszer a teljes tetején. a Fabric. Nem nehéz észrevenni, hogy még a BGP normál viselkedése is biztosítja számunkra a kívánt frissítések elosztását.
Természetesen a címzést és a cím-aggregációt úgy kell megtervezni, hogy az kompatibilis legyen az útválasztás felépítésével, hogy biztosítsa a vezérlősík stabilitását. Az L3-as címzés a szállításban a topológiához van kötve, mert e nélkül nem lehet összesítést elérni, enélkül az egyes címek bekúsznak az útválasztási rendszerbe. És még valami, hogy az aggregáció sajnos nem nagyon keveredik a többútvonalassal, mert amikor van többútvonalunk és van aggregációnk, akkor minden rendben van, ha az egész hálózat egészséges, akkor nincs benne hiba. Sajnos, amint meghibásodások jelennek meg a hálózatban, és a topológia szimmetriája elveszik, eljuthatunk oda, ahonnan az egységet bejelentették, ahonnan már nem tudunk továbbmenni oda, ahová kell. Ezért a legjobb ott aggregálni, ahol nincs további többutas, esetünkben ezek a ToR kapcsolók.
Valójában lehet összesíteni, de óvatosan. Ha tudunk ellenőrzött szétbontást végezni hálózati meghibásodások esetén. De ez elég nehéz feladat, még azon is gondolkodtunk, hogy meg lehet-e ezt csinálni, lehet-e további automatizálást, véges állapotú gépeket hozzáadni, amelyek helyesen rúgják a BGP-t, hogy elérje a kívánt viselkedést. Sajnos a sarokesetek feldolgozása nagyon nem nyilvánvaló és bonyolult, és ezt a feladatot nem lehet jól megoldani külső mellékletek BGP-hez csatolásával.
Nagyon érdekes munka történt ezzel kapcsolatban a RIFT protokoll keretein belül, amelyről a következő jelentésben lesz szó.
Egy másik fontos dolog, hogy az adatsíkok hogyan méreteződnek sűrű topológiákban, ahol nagyszámú alternatív útvonalunk van. Ebben az esetben több további adatstruktúra is használatos: ECMP-csoportok, amelyek viszont a Next Hop csoportokat írják le.
Normálisan működő hálózatban, meghibásodás nélkül, ha felfelé megyünk a Clos topológián, akkor elég csak egy csoportot használni, mert minden ami nem lokális, az alapból le van írva, felfelé mehetünk. Amikor fentről lefelé haladunk dél felé, akkor nem minden útvonal ECMP, hanem egyútvonal. Minden rendben. A baj az, hogy a klasszikus Clos topológia sajátossága, hogy ha a textil tetejét nézzük, akkor bármelyik elemnél csak egy út vezet az alatta lévő elemekhez. Ha ezen az útvonalon hibák lépnek fel, akkor ez a gyár tetején lévő elem pont azokra az előtagokra válik érvénytelenné, amelyek a megszakadt út mögött vannak. De a többire érvényes, és az ECMP csoportokat elemezni kell, és új állapotot kell bevezetnünk.
Hogyan néz ki az adatsík méretezhetősége a modern eszközökön? Ha csinálunk LPM-et (leghosszabb prefix egyezés), akkor minden nagyon jó, több mint 100 ezer előtag. Ha a Next Hop csoportokról beszélünk, akkor minden rosszabb, 2-4 ezer. Ha egy táblázatról beszélünk, amely tartalmazza a Next Hops (vagy szomszédság) leírását, akkor ez valahol 16k és 64k között van. És ebből probléma lehet. És itt elérkeztünk egy érdekes kitérőhöz: mi történt az MPLS-szel az adatközpontokban? Elvileg meg akartuk csinálni.
Két dolog történt. Mikroszegmentációt végeztünk a gazdagépeken, a hálózaton már nem volt szükségünk rá. Nem volt túl jó a különböző gyártók támogatásával, és még inkább a nyílt implementációkkal, fehér dobozokon MPLS-szel. Az MPLS pedig, legalábbis a hagyományos megvalósításai, sajnos nagyon rosszul kombinálható az ECMP-vel. És ezért.
Így néz ki az ECMP IP továbbítási struktúrája. Nagyszámú előtag használhatja ugyanazt a csoportot és ugyanazt a Next Hops blokkot (vagy szomszédságokat, ezt a különböző dokumentumokban eltérően lehet nevezni a különböző eszközökhöz). A lényeg az, hogy ez a leírás szerint a kimenő port, és hogy mire kell átírni a MAC-címet, hogy a megfelelő Next Hop-hoz jussunk. Az IP esetében minden egyszerűnek tűnik, nagyon sok előtagot használhat ugyanahhoz a csoporthoz, ugyanahhoz a Next Hops blokkhoz.
A klasszikus MPLS architektúra azt jelenti, hogy a kimenő felülettől függően a címke különböző értékekre írható át. Ezért minden bemeneti címkéhez meg kell tartanunk egy csoportot és egy Next Hops blokkot. És ez sajnos nem skálázódik.
Könnyen belátható, hogy tervezésünk során körülbelül 4000 ToR kapcsolóra volt szükségünk, a maximális szélesség 64 ECMP útvonal volt, ha a gerinc-1-től a gerinc-2 felé haladunk. Alig jutunk be egy ECMP-csoporttáblázatba, ha csak egy ToR-es előtag eltűnik, és egyáltalán nem jutunk be a Next Hops táblába.
Ez nem reménytelen, mert az olyan architektúrák, mint a Segment Routing, globális címkéket tartalmaznak. Formálisan lehetséges lenne újra összecsukni ezeket a Next Hops blokkokat. Ehhez egy wild card típusú műveletre van szükség: vegyünk egy címkét és írjuk át ugyanarra, konkrét érték nélkül. De ez sajnos nem nagyon van jelen a rendelkezésre álló megvalósításokban.
Végül pedig külső forgalmat kell hoznunk az adatközpontba. Hogyan kell csinálni? Korábban felülről vezették be a forgalmat a Clos hálózatba. Vagyis voltak szélső útválasztók, amelyek a szövet tetején lévő összes eszközhöz csatlakoztak. Ez a megoldás egészen jól működik kis és közepes méreteknél. Sajnos ahhoz, hogy ilyen módon szimmetrikusan továbbítsuk a forgalmat a teljes hálózatra, egyszerre kell megérkeznünk a Top of fabric minden eleméhez, és amikor száznál több van belőlük, akkor kiderül, hogy szükségünk van egy nagy radix a szélső útválasztókon. Ez általában pénzbe kerül, mert a szélső routerek funkcionálisabbak, a rajtuk lévő portok drágábbak lesznek, és a design nem túl szép.
Egy másik lehetőség az ilyen forgalmat alulról indítani. Könnyen ellenőrizhető, hogy a Clos topológia úgy van felépítve, hogy az alulról, vagyis a ToR oldalról érkező forgalom két iterációban egyenletesen oszlik el a szintek között a teljes Top of szövetben, a teljes hálózatot terhelve. Ezért bevezetünk egy speciális Pod típust, az Edge Podot, amely külső csatlakozást biztosít.
Van még egy lehetőség. Ezt csinálja például a Facebook. Fabric Aggregatornak vagy HGRID-nek hívják. Egy további gerincszintet vezetnek be több adatközpont összekapcsolására. Ez a kialakítás akkor lehetséges, ha az interfészeken nincsenek további funkciók, vagy tokozási változtatások. Ha ezek további érintkezési pontok, akkor nehéz. Jellemzően több funkció és egyfajta membrán választja el az adatközpont különböző részeit. Nincs értelme egy ilyen membránt nagyra csinálni, de ha valamiért valóban szükség van rá, akkor érdemes megfontolni annak lehetőségét, hogy elvigyük, minél szélesebbre tegyük és átadjuk a gazdáknak. Ezt például sok felhőszolgáltató megteszi. Átfedéseik vannak, a házigazdáktól indulnak.
Milyen fejlesztési lehetőségeket látunk? Először is a CI/CD folyamat támogatásának javítása. Úgy akarunk repülni, ahogyan tesztelünk, és tesztelni akarunk, ahogyan repülünk. Ez nem működik túl jól, mert az infrastruktúra nagy, és lehetetlen megkettőzni a tesztekhez. Meg kell értenie, hogyan lehet tesztelési elemeket bevezetni a termelési infrastruktúrába anélkül, hogy eldobná azt.
A jobb műszerezettség és a jobb ellenőrzés szinte soha nem felesleges. Az egész kérdés az erőfeszítés és a megtérülés egyensúlya. Ha ésszerű erőfeszítéssel hozzá tudod adni, nagyon jó.
Nyílt operációs rendszerek hálózati eszközökhöz. Jobb protokollok és jobb útválasztási rendszerek, mint például a RIFT. Kutatásra van szükség a jobb torlódás-ellenőrzési sémák használatában is, és talán – legalábbis bizonyos pontokon – az RDMA támogatás bevezetése a klaszteren belül.
A távolabbi jövőre nézve fejlett topológiákra és esetleg olyan hálózatokra van szükségünk, amelyek kevesebb többletköltséget használnak. A friss dolgok közül a közelmúltban megjelentek publikációk a HPC Cray Slingshot szövettechnológiájáról, amely commodity Ethernet-re épül, de jóval rövidebb fejlécek használatára is lehetőség van. Ennek eredményeként csökken a rezsi.
Mindennek a lehető legegyszerűbbnek kell lennie, de nem egyszerűbbnek. A komplexitás a méretezhetőség ellensége. Az egyszerűség és a szabályos szerkezetek a barátaink. Ha valahol ki tudod léptetni, tedd meg. És általában véve nagyszerű, hogy most részt veszünk a hálózati technológiákban. Nagyon sok érdekes dolog történik. Köszönöm.
Forrás: will.com