Az adatközponti hálózatokat sokáig úgy tervezték, mintha a forgalom zöme kívülről érkezne és oda is térne vissza: a felhasználó kérése beér, a szerver válaszol. A virtualizáció, a több rétegre bontott alkalmazások és a hálózaton át elért tárolók óta a csomagok többsége a szerverek között mozog. Egy weboldal betöltése mögött az alkalmazásszerver adatbázist kérdez le, gyorsítótárat olvas, naplót ír, közben a virtuális gépek a fizikai gazdagépek között költöznek, a tároló pedig egy másik rackbe replikál. A spine-leaf topológia erre a forgalmi képre épül.
A háromrétegű hálózat és a kelet-nyugati forgalom
A klasszikus adatközponti hálózat három rétegből áll. A szerverek a hozzáférési kapcsolókra csatlakoznak, ezek felfelé egy elosztó (aggregációs) kapcsolópárra, az elosztó blokkok pedig a maghálózatra. A második rétegbeli tartomány jellemzően az elosztó rétegig ér, ott van a VLAN-ok alapértelmezett átjárója is. A redundáns felfelé vezető kapcsolatok közül a feszítőfa-protokoll a hurkok elkerülése miatt egyet blokkol, így a kiépített kapacitás egy része tétlenül vár egy hibára.
A szakma két irányt különböztet meg. Az észak-déli forgalom az adatközpontba belépő és onnan kilépő forgalom, a kelet-nyugati a szerverek egymás közötti forgalma. A háromrétegű modell az előbbire készült, és a kelet-nyugati forgalomnál több gyenge pontja látszik:
- Az út hossza attól függ, hol áll a két szerver. Ha ugyanazon a hozzáférési kapcsolón, egy ugrás elég, ha két különböző elosztó blokkban, a forgalom a maghálózaton át jut célba. A késleltetés és az elérhető sávszélesség így szerverpáronként más.
- Az elosztó réteg szűk keresztmetszet. Minden blokkon belüli útválasztás és minden blokkok közötti átvitel rajta halad át, ezért bővíteni többnyire csak nagyobb eszközre cserélve lehet.
- A virtuális gépek költöztetéséhez ugyanaz a VLAN kell több helyen, ezért a második rétegbeli tartomány idővel az egész adatközpontra kiterjed. Ezzel nő a szórásos forgalom, és egy hurok vagy egy hibás eszköz az egész tartományt megbéníthatja.
Spine és leaf: minden leaf minden spine-hoz
A spine-leaf hálózatnak két rétege van. A leaf kapcsolók a rackekben állnak, rájuk csatlakozik minden, ami a hálózatot használja: szerver, tároló, tűzfal, terheléselosztó, a külvilág felé vezető útválasztó. A spine kapcsolók csak a leafeket kötik össze. A felépítés néhány egyszerű szabályon múlik:
- Minden leaf minden spine-hoz kapcsolódik, azonos sebességű linkkel.
- A spine-ok nem kapcsolódnak egymáshoz, és a leafek sem egymáshoz, kivéve egy esetleges összekötő kapcsolatot két leaf között, amelyre a szerverek kettős bekötése épül.
- A spine-ra semmi más nem csatlakozik, végpont sem, külső kapcsolat sem.
Az elv nem új. Charles Clos 1953-ban a Bell System Technical Journalban írta le a többfokozatú kapcsolóhálózatot, amelyet akkor telefonközpontokhoz terveztek. A spine-leaf ennek egy „összehajtott” változata: a bemeneti és a kimeneti fokozat ugyanaz a leaf réteg, középen a spine-ok állnak.
A szabályokból következik a topológia legfontosabb tulajdonsága. Bármely két leaf között az út leaf, spine, leaf, vagyis mindig ugyanannyi ugrás, és minden spine egy-egy egyenrangú útvonalat ad. A késleltetés kiszámítható, a két leaf közötti kapacitás pedig a leaf felfelé vezető linkjeinek összege, akárhol áll is a két rack.
Egy spine kiesése sem változtat a topológián. Ha négy spine van, egy kiesése után a leafek közötti kapacitás negyedével csökken, a forgalom a maradék hármon fut tovább, a többi eszköznek nem kell semmit újraszámolnia a megszűnt útvonalak törlésén túl. Ugyanez teszi lehetővé, hogy egy spine-t karbantartás vagy frissítés miatt üzem közben ki lehessen venni.
Különleges szerepű leafek
A harmadik szabály miatt a külvilág is leafen keresztül érkezik. A border leaf köti a hálózatot az internethez, a WAN-hoz és a campus hálózathoz, a service leafre a tűzfalak és a terheléselosztók kerülnek. Kisebb hálózatban a kettő ugyanaz a kapcsolópár.
Útválasztás a gerincben: ECMP
A leafek és a spine-ok közötti linkek harmadik rétegbeli, pont-pont útválasztott kapcsolatok. Közöttük nincs feszítőfa, nincs blokkolt port, a második rétegbeli tartomány a leafnél véget ér. Minden linknek saját kis alhálózata van (IPv4-en gyakran /31-es, amit az IETF RFC 3021 tesz lehetővé), és minden kapcsoló kap egy loopback címet, amely az azonosítója a hálózatban.
Az underlay, vagyis az alap szállítóhálózat útválasztására OSPF, IS-IS vagy BGP szolgál. Az IETF RFC 7938 (2016) részletesen leírja, hogyan lehet egy nagy adatközpontot kizárólag eBGP-vel működtetni. A protokoll megválasztásánál fontosabb, hogy minden leaf minden spine-on keresztül megtanulja a többi leaf loopback címét, mert így jön létre a fent leírt, spine-onként egy-egy egyenrangú útvonal.
Hogyan oszlik el a forgalom
Az ECMP (Equal-Cost Multi-Path) azt jelenti, hogy a kapcsoló egy célhoz az összes egyenlő költségű következő ugrást a továbbítási táblájába teszi, és a forgalmat ezek között osztja szét. Az elosztás folyamatonként történik: a kapcsoló a csomag fejlécének mezőiből, jellemzően a forrás- és célcímből, a protokollból és a portszámokból hash-értéket képez, és ez dönti el, melyik linken megy a folyamat. Így egy kapcsolat csomagjai mindig ugyanazon az úton haladnak, és nem érkeznek rossz sorrendben. A hash-alapú elosztás viselkedését az IETF RFC 2992 (2000) elemzi.
Ennek a módszernek ismert korlátai vannak:
- Egy folyamat egy link sebességét kapja meg. Egy nagy mentés vagy tárolóreplikáció hiába fut négy spine-os hálózaton, egyetlen TCP-kapcsolatként egyetlen linket használ.
- Kevés, de nagy folyamatnál az elosztás egyenetlen lehet. Ha két nagy folyamat ugyanarra a hash-értékre esik, az egyik link telítődik, a másik közben üres.
- Ha a forgalom több elosztó fokozaton halad át, például a lent tárgyalt ötfokozatú felépítésben vagy két kapcsoló közötti párhuzamos linkeken, és minden fokozat ugyanazzal a hash-függvénnyel dönt, a második fokozatban a forgalom már nem oszlik szét újra. Az alap háromfokozatú hálózatban ez ritkán jelentkezik, mert a spine-ról a cél-leaf felé többnyire egyetlen link vezet. A jelenséget a hash-függvény fokozatonkénti eltérő beállítása kezeli.
Hibaészlelés
Ha egy optikai link fizikailag megszakad, a kapcsoló azonnal érzékeli, és törli az útvonalat. Van azonban olyan hiba, amelynél a port fent marad, csak a csomagok nem jutnak át, például egy csak az egyik irányban hibás optikai modulnál. Ilyenkor az útválasztó protokoll a saját időzítőire vár, ami alapértelmezett beállítással több tíz másodperc, BGP-nél másfél perc is lehet (az IETF RFC 4271 90 másodperces tartási időt javasol). A BFD (Bidirectional Forwarding Detection, IETF RFC 5880, 2010) a szomszédok között sűrűn küldött rövid üzenetekkel ennél sokkal gyorsabban jelzi a kiesést, utána a hash a megmaradt linkekre osztja a forgalmat.
Overlay: VXLAN és EVPN
Az útválasztott underlay a második rétegbeli tartományt a leafnél lezárja. Az alkalmazásoknak viszont gyakran szükségük van rá, hogy ugyanaz az alhálózat több rackben is elérhető legyen, és egy virtuális gép a költözés után megtartsa az IP-címét. A másik korlát a VLAN-azonosító mérete: az IEEE 802.1Q szerint 12 bites, ami 4094 használható VLAN-t jelent, és ez több bérlős környezetben kevés lehet.
VXLAN
A VXLAN (IETF RFC 7348, 2014) az eredeti Ethernet-keretet UDP/IP-csomagba csomagolja, és így az útválasztott underlay-en szállítja egyik leaftől a másikig. A csomagolást és a kicsomagolást a leafen futó VTEP (VXLAN Tunnel End Point) végzi. A második rétegbeli szegmenst a 24 bites VNI azonosítja, ez nagyjából 16 millió szegmenst tesz lehetővé. Az underlay ebből csak annyit lát, hogy két leaf loopback címe között UDP-csomagok mennek a 4789-es célportra.
Két részlet a tervezésnél is számít. A külső fejléc IPv4 esetén 50 bájttal növeli a csomagot, ezért az underlay MTU-ját meg kell emelni, különben a teljes méretű keretek eldobódnak vagy töredezve érkeznek. A szabvány javaslata szerint a VTEP a külső UDP forrásportot a belső keret fejlécéből képzett hash-ből választja, így a spine-ok ECMP-je a csomagolt folyamatokat is szétosztja a linkek között.
EVPN
A VXLAN önmagában csak a csomagolást írja le. Az eredeti megoldásban a VTEP-ek elárasztással és tanulással ismerték meg egymás mögött a MAC-címeket, ehhez jellemzően multicast kellett az underlay-ben, és az ismeretlen célú keretek minden leafre eljutottak. Az EVPN (IETF RFC 7432, 2015, VXLAN felett az IETF RFC 8365, 2018) ezt a vezérlősíkot BGP-re cseréli. Minden leaf BGP-üzenetben hirdeti a mögötte megtanult MAC- és IP-címeket, a többi leaf pedig ezekből előre tudja, hová kell küldenie a keretet.
- A 2-es típusú útvonal egy MAC-címet és a hozzá tartozó IP-címet hirdeti. Ebből a leaf helyben meg tud válaszolni egy ARP-kérést, így a szórásos kérés nem megy végig a hálózaton (ARP-elnyomás).
- A 3-as típusú útvonallal jelzik a leafek, mely VNI-kben érdekeltek, ezen az alapon jut el a szórásos és az ismeretlen célú forgalom csak oda, ahol szükség van rá.
- Az 5-ös típusú útvonal (IETF RFC 9136, 2021) teljes IP-előtagot hirdet, például a border leaf mögötti külső hálózatokat.
Az EVPN-nel működik az elosztott átjáró is (IETF RFC 9135, 2021): minden leaf ugyanazzal az IP- és MAC-címmel játssza egy alhálózat alapértelmezett átjáróját. A szegmensek közötti útválasztás így már az első leafen megtörténik, és egy költöző virtuális gép az új helyén is ugyanazt az átjárót találja. Az RFC 7432 a szerverek két leafre kötését is szabványosan kezeli: a két leaf közös Ethernet-szegmens-azonosítót (ESI) kap, és a szerver felől egy linkaggregációs partnernek látszik.
Az overlay rugalmasságát egy újabb hibaréteg ellensúlyozza. Lehet, hogy az underlay-ben minden útvonal megvan, minden BGP-szomszédság él, az egyik VNI-ben mégsem jut át a forgalom, mert egy leafről hiányzik egy beállítás. A hibakereséshez mindkét réteget érteni kell, és a monitorozásnak is mindkettőt figyelnie kell.
Szegmentáció a gerinc szintjén
Az EVPN-alapú hálózatban két szinten lehet szegmentálni. A VNI egy második rétegbeli szegmens, a hagyományos VLAN megfelelője. A VRF (Virtual Routing and Forwarding) külön útválasztási tábla: az egyik VRF-ben lévő alhálózatok egyáltalán nem látják a másik VRF útvonalait. Két VRF között csak akkor jut át forgalom, ha valaki szándékosan átengedi.
Gyakori kiindulás, hogy a zónák mindegyike saját VRF-et kap: éles rendszerek, teszt és fejlesztés, mentés, felügyeleti hálózat, DMZ. A VRF-ek közötti forgalom a service leafen álló tűzfalon halad át, amely a szabályokat alkalmazza és naplóz. A zónán belüli finomabb elválasztásra a leafek hozzáférési listái vagy a gazdagépen, illetve a hipervizorban működő mikroszegmentálás szolgál. Hogy melyik zóna mivel kommunikálhat, azt a hálózat felépítése előtt érdemes rögzíteni; ehhez a belső hálózat szegmentálásáról szóló cikk ad kiindulópontot.
Amin a szegmentáció elcsúszhat
- Útvonal-szivárogtatás. A VRF-ek között útvonalakat lehet átadni a tűzfal megkerülésével is. Egy kényelmi okból beállított átadás csendben megszünteti az elválasztást, ezért minden ilyet dokumentálni és rendszeresen átnézni kell.
- Kifeszített második réteg. Ha egy VNI két telephelyre is átnyúlik, a két helyszín egy hibatartományba kerül: egy hurok vagy egy elárasztás mindkettőt érinti.
- Elérhető vezérlősík. A bérlői VRF-ekből ne lehessen elérni az underlay címeit és a kapcsolók felügyeleti felületét. A BGP-munkameneteket hitelesíteni kell (például TCP-AO-val, IETF RFC 5925), és csak az ismert szomszédokkal szabad felépülniük.
A kapcsolók felügyelete külön, sávon kívüli hálózaton fusson. Így egy hibás konfiguráció után is be lehet lépni az eszközökre, és a felügyeleti forgalom nem keveredik az üzemi forgalommal.
Bővítés és túlfoglalási arány
A túlfoglalási arány egy leaf lefelé, a szerverek felé néző kapacitásának és a felfelé, a spine-ok felé vezető kapacitásának aránya. Ha minden szerver egyszerre teljes sebességgel küldene más rackbe, ennyiszer több forgalom érkezne a felfelé vezető linkekre, mint amennyit elvisznek. Néhány egyszerű példa:
| Szerverportok a leafen | Felfelé vezető linkek | Túlfoglalási arány |
|---|---|---|
| 48 × 25 Gbit/s = 1200 Gbit/s | 4 × 100 Gbit/s = 400 Gbit/s | 3:1 |
| 48 × 25 Gbit/s = 1200 Gbit/s | 6 × 100 Gbit/s = 600 Gbit/s | 2:1 |
| 32 × 100 Gbit/s = 3200 Gbit/s | 8 × 400 Gbit/s = 3200 Gbit/s | 1:1 |
Hogy mekkora arány elfogadható, azt a forgalom dönti el. Egy általános virtualizált környezetben a szerverek ritkán küldenek egyszerre teljes sebességgel, egy tárolóhálózat, egy replikációs fürt vagy egy AI-modellek tanítására épített gépcsoport viszont tartósan terheli a linkeket. A méretezés kiindulópontja ezért a meglévő rendszerek mért forgalma, és ha a leafek elég felfelé vezető portot tartanak szabadon, az arány később is javítható.
Hol vannak a bővítés korlátai
A spine-leaf hálózat vízszintesen bővül. Új rack esetén új leaf kerül be, és minden spine-ra bekötik, ehhez minden spine-on kell egy szabad port. A spine-ok portszáma így meghatározza, hány leaf fér a hálózatba. Új spine-nal a leafek közötti kapacitás nő, de ehhez minden leafen kell egy szabad felfelé vezető port, vagyis a leafek felfelé vezető portjainak száma szabja meg, hány spine lehet. A kapcsolók által kezelt egyenrangú útvonalak száma is felső korlát.
Ha a spine-ok portjai elfogynak, a hálózat podokra bontható: minden pod egy saját spine-leaf egység, a podok spine-jait pedig egy harmadik, super-spine réteg köti össze. Ez az ötfokozatú Clos-felépítés, amelyet az RFC 7938 is leír. A váltás tervezést igényel, ezért már az első kiépítésnél érdemes eldönteni, mekkora lehet egy pod.
A bővíthetőség a papírmunkán is múlik. A kábelezési terv minden rackből minden spine-hoz rögzített útvonalat ad, a címtervben előre ki van osztva a loopback és a pont-pont címtartomány a leendő leafeknek is, a konfigurációt pedig sablonból készítik, hogy az új leaf ugyanúgy nézzen ki, mint a többi. Az üzemeltetésnél a felfelé vezető linkek kihasználtságát érdemes linkenként figyelni: ha az egyik tartósan jóval terheltebb a többinél, az egyenetlen hash-elosztásra vagy egy hiányzó útvonalra utal.
Kapcsolódó szolgáltatás: Adatközponti és gerinchálózat →
