Došly nám IPv4 adresy v management síti a rozhodli jsme se celou tuto část sítě předělat, abychom vyřešili i další problémy, které se za posledních pár let nasbíraly.
Vysvětlivky:
Management síť je u nás síť, která je určená pouze pro IPMI, iDRAC, iLo a další nezávislá zařizení (APC PDU, management porty switchů), atd.
IPv4 v management síti bohužel stále musíme ještě používat, protože některé Supermicro servery po upgradu firmware mají IPv6 vypnutou. Jinak bychom
IPv4 úplně vypnuli a používali jen IPv6.
Původní stav
V původním návrhu jsme nepočítali s tím, že bychom se vůbec rozšířili dál, než mimo sál, ve kterém jsme byli, a počítali jsme s maximem 1-2 racků na hodně dlouhou dobu dopředu. Ta doba přišla celkem rychle a dostali jsme se do stavu, že musíme brát racky v dalších sálech, než ve kterém se nacházíme. Stejně tak jako množství racků trochu přerostlo naše původní plány.
Protože máme servery ve více lokalitách, tak každá lokalita má pro potřeby management sítě přiřazené interní adresy z rozsahu 10.x.y.z/16. Tyto rozsahy jsou dále děleny na /24 rozsahy podle potřeby. Tzn. /24 rozsah pro IPMI, /24 rozsah pro switche. V IPv6 světe analogicky jen rozsahy jsou /64.
Firewall se stará o filtraci provozu a připojení k VPN, abychom se mohli bezpečně k managementům jednotlivých zařízení dostat.
Hlavním lákadlem pro nás byl fakt, že jsme měli fyzicky oddělené management sítě od zbytku provozu. Když se tedy něco stalo (nikdy se nic nestalo), tak jsme měli jistotu, že se budeme moc ke switchům připojit.
Do racku tedy vede celkem velké množství kabelů:
- 2xN uplink (většinou 4 páry optického kabelu) vždy tak, aby uplink byl redundantní. Každý z agregačních prvků/racků může vypadnout a provoz obslouží druhý.
- 1x UTP IPMI pro připojení IPMI/iDrac/iLo karet serverů
- Nx UTP kabel pro připojení managemt portů TOR switchů
Nedostatek kabelů
V momentě, kdy jsme se rozhodli přidat TOR switch, tak jsme museli řešit, jak jej připojit k management síti. Možnosti byly:
- Natáhnout nový kabel
- Rozdvojit stávající kabel
- Umístit do racku další malý switch pro management porty switchů
Nedostatek adres
Ukázalo se, že 253 adres (1 pro GW) pro managementy začalo být málo. Řešení by v tomto případě mohlo být zvětšit rozsah na /23 a získat tím bez práce další prostor pro zařízení.
Nepořádek na síti
Pro připojení managementů serverů používáme L2 switche, většinou bez jakéhokoliv managementu. Několikrát se nám stalo, že jeden ze switchů začal dělat na síti nepořádek. Abychom takové zařízení našli, tak jsme museli postupně odpojovat části sítě.
Nemožnost připojit racky v jiných sálech
Pro připojení managemt switchů používáme metalickou síť. Ta má omezení 100 metrů délky. To nám znemožnilo připojit racky v jiných sálech. Navíc se za propoje platí měsíční poplatky, které nám začaly připadat zbytečné.
Nový stav
Dlouhodobě plánujeme přejít ze switchované sítě na plně routovanou síť. Rozhodli jsme se tedy udělat každý rack soběstačný a nezávislý na jednom centrálním prvku. Každý rack tedy obsahuje svůj vlastní firewall, který je připojen přes TOR switch/e do zbytku sítě.
Do každého racku tedy nově vedou jen uplink porty. V rámci těchto portů máme vyhrazenou jednu VLAN pro routovanou síť směrem k jednotlivým management firewallům.
Každý rack má přiřazený jeden /64 IPv6 rozsah, který sdílí IPMI, switche i další zařízení. Switche mají v rámci této /64 přiřazený menší rozsah, kde můžeme nastavovat specifická filtrovací pravidla. Konfigurace switchů je statická, IPMI používají SLAAC. Pokud bychom chtěli v budoucnu oddělit switche do vlastního rozsahu, tak stačí jen přidat další routry. IPv4 vůbec směrem k firewallům vedena není. Ta se zpřístupňuje jen přes VPN, ke které jednotlivé firewally připojují.
Nedostatek kabelů již není problém, protože se vždy připojujeme zařízení v rámci jednoho racku a uplinky do racku vést musí.
Nedostatek adres jsme tím vyřešili, protože každý rack má vlastní /24 IPv4 a /64 IPv6 rozsah. Víc jak 253 zařízení v jednom racku snad nikdy mít nebudeme. V případě potřeby přidání dalších rozsahů ale máme možnost jednoduše přidat. Zachovali jsme rozsahy 10.x.y.z/16 na lokalitu a zatím nečekáme, že bychom brzy měli víc jak 255 racků v jedné lokalitě.
Odolnost proti nepořádku na síti je tímto zvýšena, protože případné komplikace ovlivní vždy jen jeden rack. Pokud se tedy něco nestane v peering VLANě. Do budoucna toto nejspíš eliminujeme tak, že každý rack bude mít svou peering vlanu a provoz mimo rack bude plně routovaný.
Můžeme připojit další racky v jiných sálech díky použití optických kabelů, které nemají omezené délky.
Nevýhody nové management sítě
Je potřeba se ale na tuto architekturu dívat objektivně, takže ani nové řešení není dokonalé a máme identifikovaná slabá místa.
V případě, kdy máme jen jeden TOR switch v racku, tak se k němu v případě nehody nemáme jak dostat a je potřeba fyzický zásah.
V momentě, kdy se nám ucpe uplink do racku, tak budeme mít ztrátovost i na management síti. Toho se ale zatím moc nebojíme, protože do většiny racků máme připojených alespoň 40Gbps, což je víc než je potřeba.
Začali jsme automaticky kontrolovat zařízení v jednotlivých rackcích podle management karet. Pravidelně si z jednotlivých management firewallů stahujeme seznam připojených zařízení a porovnáváme to s dokumentací. Pokud se v racku objeví zařízení, které tam nemá být nebo které je neregistrované, tak automaticky dostáváme notifikace.
Přibylo nám v síti víc zařízení, o která se musíme starat. Která musíme monitorovat, aktualizovat a konfigurovat. Díky automatizaci nám to ale takové problémy nedělá.
Závěr
Zatím nové schéma používáme jen krátkou dobu. Až časem budeme schopni vyhodnotit, jestli to byl správný nebo špatný krok. V každém případě se nám ale povedlo síť z pohledu kabeláže zjednodušit a eliminovat některé problémy, které nás trápily. Můžeme se dál rozšiřovat podle potřeby bez nutnosti být omezeni na jeden sál nebou malou oblast a racky se nám daří držet vzájemně nezávislé.
A jak takový rack vypadá?
