V prvních dvou článcích jsem nastolil problematiku automatizace a nastínil její rámec, ve druhém jsem odbočil do virtualizace sítě jako prvního přístupu k automatizaci konfigurace služeb.
A nyní je čas nakreslit schéma fyzické sítě.

Pokud nejste s organizací sítí datových center nakrátko, pak důrazně doporučuji začít články o nich.

Všechna vydání:

• 0. ADSM. Část nula. Plánování
• 1. ADSM. Část první (která je po nule). Virtualizace sítě
• 2. ADSM. Část dvě. Návrh sítě

Postupy popsané v této sérii by měly být použitelné pro jakýkoli typ sítě, jakékoli měřítko a různé dodavatele (ne). Nelze však popsat univerzální příklad aplikace těchto přístupů. Proto se zaměřím na moderní architekturu DC sítě: Továrna Kloz.
Uděláme DCI na MPLS L3VPN.

Na vrcholu fyzické sítě je překryvná síť od hostitele (může to být OpenStack's VXLAN nebo Tungsten Fabric, nebo cokoli jiného, ​​co vyžaduje pouze základní IP konektivitu ze sítě).

V tomto případě dostáváme relativně jednoduchý scénář pro automatizaci, protože máme mnoho zařízení nakonfigurovaných stejným způsobem.

Zvolíme sférický DC ve vakuu:

• Všude jedna designová verze.
• Dva prodejci tvořící dvě síťové roviny.
• Jeden DC je jako druhý jako dvě kapky vody.

Obsah

• Fyzická topologie
• Směrování
• IP plán
• Laba
• Závěr
• Užitečné odkazy

Nechte například našeho poskytovatele služeb LAN_DC hostit školicí videa o přežití uvízlých výtahů.

V megaměstech je to velmi populární, takže potřebujete spoustu fyzických strojů.

Nejprve popíšu síť přibližně tak, jak bych ji chtěl vidět. A pak to zjednoduším pro laboratoř.

Fyzická topologie

Místa

LAN_DC bude mít 6 DC:

• Rusko (RU):
  • Moskva (MSK)
  • Kazaň (kzn)

• Španělsko (SP):
  • Barcelona (Bcn)
  • Malaga (MLG)

• Čína (CN):
  • Šanghaj (sha)
  • Xi'an (sia)

Uvnitř DC (Intra-DC)

Všechny DC mají identické vnitřní propojovací sítě založené na Klose topologii.
Co jsou sítě Kloz a proč přesně jsou - v samostatném článek.

Každé DC má 10 stojanů s auty, budou očíslovány jako A, B, C A tak dále.

V každém stojanu je 30 strojů. Nebudou nás zajímat.

V každém stojanu je také přepínač, ke kterému jsou připojeny všechny stroje - to je Horní část přepínače Rack - ToR nebo jinak, z hlediska továrny Klose, tomu budeme říkat List.

Obecné schéma továrny.

Vyjmenujeme je XXX-listYKde XXX - třípísmenná zkratka DC, a Y - sériové číslo. Například, kzn-list11.

Dovolím si ve svých článcích používat termíny Leaf a ToR spíše lehkovážně jako synonyma. Je však třeba mít na paměti, že tomu tak není.
ToR je rackový přepínač, ke kterému se stroje připojují.
Leaf je role zařízení ve fyzické síti nebo přepínače první úrovně z hlediska topologie Klose.
Tedy Leaf != ToR.
Takže Leaf může být například přepínač EndofRaw.
V rámci tohoto článku je však budeme stále považovat za synonyma.

Každý přepínač ToR je zase připojen ke čtyřem vyšším agregačním přepínačům - Páteř. Pod Spine's je v DC přidělen jeden stojan. Pojmenujeme to takto: XXX-páteřY.

Ve stejném racku bude síťové vybavení pro konektivitu mezi DC - 2 routery s MPLS na desce. Ale celkově jsou to stejné Tory. Čili z pohledu Spine switchů nezáleží na obvyklém ToR s připojenými stroji nebo routeru pro DCI - jedna sakra.

Takové speciální ToR se nazývají Okrajový list. Vyjmenujeme je XXX-okrajY.

Bude to vypadat takto.

Ve výše uvedeném diagramu jsem skutečně umístil okraj a list na stejnou úroveň. Klasické třívrstvé sítě nás naučili považovat uplink (ve skutečnosti odtud ten termín) za propojení. A zde se ukazuje, že „uplink“ DCI se vrací dolů, což pro některé trochu narušuje obvyklou logiku. V případě velkých sítí, kdy jsou datová centra rozdělena na ještě menší jednotky - POD's (Point Of Delivery), přidělte jednotlivce Edge-POD's pro DCI a přístup k externím sítím.

Pro snadnější vnímání v budoucnu stále nakreslím Edge over Spine, přičemž budeme mít na paměti, že na Spine není žádná inteligence a neexistují žádné rozdíly při práci s obyčejným Leafem a Edge-leafem (i když mohou existovat nuance , ale obecně je to pravda).

Tovární schéma s okrajovými listy.

Trinity Leaf, Spine a Edge tvoří podkladovou síť nebo továrnu.

Úkol síťové továrny (čti Underlay), jak jsme již definovali v poslední vydání, velmi, velmi jednoduché - poskytovat IP konektivitu mezi stroji v rámci stejného DC i mezi nimi.
Síť se proto nazývá továrna, stejně jako například továrna na přepínání uvnitř modulárních síťových boxů, o které se více dočtete v SDSM14.

Obecně se takové topologii říká továrna, protože tkanina v překladu je tkanina. A je těžké nesouhlasit:

Továrna je kompletně L3. Žádné VLANy, žádné vysílání – to jsou skvělí programátoři, které máme v LAN_DC, umí psát aplikace, které žijí v paradigmatu L3, a virtuální stroje nevyžadují Live Migration s uložením IP adresy.

A ještě jednou: odpověď na otázku, proč je továrna a proč je L3 v samostatném článek.

DCI – Data Center Interconnect (Inter-DC)

DCI bude organizováno s pomocí Edge-Leaf, to znamená, že jsou naším výstupním bodem na dálnici.
Pro jednoduchost předpokládáme, že DC jsou propojeny přímými spoji.
Vynechme z úvahy vnější spojení.

Jsem si vědom toho, že pokaždé, když odeberu komponentu, značně zjednoduším síť. A při automatizaci naší abstraktní sítě bude vše v pořádku, ale na té skutečné se objeví berličky.
To je pravda. A přesto je smyslem této série přemýšlet a pracovat na přístupech, a ne hrdinsky řešit fiktivní problémy.

Na Edge-Leafs je podklad umístěn ve VPN a přenášen přes MPLS páteř (stejný přímý odkaz).

Zde je získáno takové schéma nejvyšší úrovně.

Směrování

Pro směrování v rámci DC budeme používat BGP.
Na páteřní síti MPLS OSPF+LDP.
U DCI, tedy organizace konektivity v podkladu - BGP L3VPN přes MPLS.

Obecné schéma směrování

V továrně nejsou žádné OSPF a ISIS (směrovací protokol zakázaný v Ruské federaci).

A to znamená, že nedojde k žádnému Auto-discovery a výpočtu nejkratších cest – pouze ručnímu (vlastně automatickému – zde mluvíme o automatizaci) nastavení protokolu, sousedství a zásad.

Schéma směrování BGP uvnitř DC

Proč BGP?

Existují celé RFC s názvem Facebook a Arista, který říká, jak stavět velmi velký sítě datových center využívající BGP. Čte se to skoro jako fikce, vřele doporučuji na rozvláčný večer.

V mém článku je tomu také věnována celá jedna sekce. Kam vás mohu vzít a poslat.

Ale přesto zkrátka žádný IGP není vhodný pro sítě velkých datových center, kde jde počet síťových zařízení do tisíců.

Navíc použití BGP všude vám umožní nestříkat na podporu několika různých protokolů a synchronizaci mezi nimi.

Ruku na srdce, v naší továrně, která s největší pravděpodobností rychle neporoste, by pro naše oči OSPF stačil. To je vlastně problém mega scalerů a cloudových titánů. Ale představme si pro pár problémů, že to potřebujeme, a použijeme BGP, jak odkázal Peter Lapukhov.

Zásady směrování

Na přepínačích Leaf importujeme předpony ze síťových rozhraní Underlay do BGP.
Mezitím budeme mít relaci BGP každý dvojice Leaf-Spine, ve které budou tyto Underlay prefixy tu a tam oznamovány po síti.

Uvnitř jednoho datového centra budeme distribuovat specifika, která jsme importovali do Tor. Na Edge-Leafs je shromáždíme a oznámíme je vzdáleným DC a pošleme je dolů do Tors. To znamená, že každý Tor bude přesně vědět, jak se dostat k jinému Tor ve stejném DC a kde je vstupní bod, jak se dostat k Toru v jiném DC.

V DCI budou trasy přenášeny jako VPNv4. Za tímto účelem bude na Edge-Leaf rozhraní směrem k továrně umístěno do VRF, nazvěme to UNDERLAY, a okolí s páteří na Edge-Leaf se zvedne uvnitř VRF a mezi Edge-Leafs v rodině VPNv4.

Rovněž zakážeme opětovné vyhlašování tras přijatých od páteřáků zpět k nim.

Na Leaf a Spine nebudeme importovat Loopbacky. Budeme je potřebovat pouze k určení ID routeru.

Ale na Edge-Leafs to importujeme do Global BGP. Mezi adresami Loopback Edge-Leafs vytvoří relaci BGP v rodině IPv4 VPN navzájem.

Mezi EDGE zařízeními budeme mít kmen natažený na OSPF + LDP. Vše v jedné zóně. Extrémně jednoduchá konfigurace.

Zde je obrázek s trasováním.

BGP ASN

Okrajový list ASN

Na Edge-Leafs bude jedno ASN ve všech DC. Je důležité, že mezi Edge-Leafs je iBGP a nenarážíme na nuance eBGP. Nechť je to 65535. Ve skutečnosti by to mohlo být veřejné číslo AS.

Páteř ASN

Na Spine budeme mít jedno ASN na DC. Začněme zde od úplně prvního čísla z řady soukromých AS - 64512, 64513 A tak dále.

Proč ASN na DC?

Pojďme si tuto otázku rozložit na dvě části:

• Proč stejné ASN na všech páteřích jednoho DC?
• Proč se liší v různých DC?

Proč stejné ASN na všech páteřích jednoho DC

Takto bude vypadat AS-cesta podložní trasy na Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Když se to pokusíte oznámit zpět Spine, bude vyřazeno, protože jeho AS (Spine_AS) je již na seznamu.

V rámci DC jsme však naprosto spokojeni, že trasy Underlay, které se zvedly k Edge, nebudou moci sestoupit. Veškerá komunikace mezi hostiteli v rámci DC musí probíhat na úrovni páteří.

Agregované trasy ostatních DC se přitom v každém případě volně dostanou k Torům - jejich AS-Path bude obsahovat pouze ASN 65535 - počet AS Edge-Leafs, protože právě na nich byly vytvořeny.

Proč se liší v různých DC

Teoreticky možná budeme muset přetáhnout Loopback a některé servisní virtuální stroje mezi DC.

Například na hostiteli spustíme Route Reflector resp stejný VNGW (Virtual Network Gateway), která se uzamkne s Torem přes BGP a oznámí svou smyčku, která by měla být dostupná ze všech DC.

Takže takto bude vypadat jeho AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

A nikde by se neměla opakovat ASN.

To znamená, že Spine_DC1 a Spine_DC2 se musí lišit, stejně jako leafX_DC1 a leafY_DC2, což je přesně to, k čemu se blížíme.

Jak pravděpodobně víte, existují hacky, které vám umožňují přijímat trasy s duplicitními ASN navzdory mechanismu prevence smyčky (allowas-in na Cisco). A dokonce má legitimní využití. To je ale potenciální díra ve stabilitě sítě. A já osobně jsem do toho párkrát spadl.

A pokud máme možnost nepoužívat nebezpečné věci, tak ji využijeme.

List ASN

Na každém Leaf switchi v rámci celé sítě budeme mít individuální ASN.
Děláme to z výše uvedených důvodů: AS-Path bez smyček, konfigurace BGP bez záložek.

Aby trasy mezi listy procházely hladce, AS-Path by měla vypadat takto:
[leafX_ASN, spine_ASN, leafY_ASN]
kde leafX_ASN a leafY_ASN by byly hezké, kdyby byly odlišné.

To je také vyžadováno pro situaci s oznámením zpětné vazby VNF mezi DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Použijeme 4bajtové ASN a vygenerujeme jej na základě ASN páteře a čísla přepínače Leaf, konkrétně takto: Páteř_ASN.0000X.

Zde je takový obrázek s ASN.

IP plán

V zásadě potřebujeme přidělit adresy pro následující připojení:

1. Podložte síťové adresy mezi ToR a strojem. Musí být jedinečné v rámci celé sítě, aby každý stroj mohl komunikovat s jakýmkoli jiným. Skvěle sedí 10/8. Pro každý stojan / 26 s rezervou. Přidělíme /19 na DC a /17 na region.
2. Propojte adresy mezi Leaf/Tor a Spine.

   Chtěl bych je přiřadit algoritmicky, to znamená vypočítat z názvů zařízení, která je třeba připojit.

   Nech to být... ​​169.254.0.0/16.
   Konkrétně 169.254.00 31 X.Y/XNUMXKde X - Číslo páteře, Y — P2P síť /31.
   To vám umožní provozovat až 128 racků a až 10 Spine v DC. Linkové adresy se mohou (a budou) opakovat z DC do DC.

3. Společná páteř - Edge-Leaf organizovat na podsítě 169.254.10 31 X.Y/XNUMXkde přesně to samé X - Číslo páteře, Y — P2P síť /31.
4. Propojte adresy z Edge-Leaf na páteř MPLS. Zde je situace poněkud odlišná - spojení všech částí do jednoho koláče, takže nebudete moci znovu použít stejné adresy - musíte si vybrat další volnou podsíť. Proto bereme jako základ 192.168.0.0/16 a my se z toho vyhrabeme.
5. Loopback adresy. Dejme jim celý rozsah 172.16.0.0/12.
   • List - /25 každý u DC - stejných 128 stojanů. Přidělte /23 na region.
   • Páteř - o /28 na DC - až 16 Páteř. Přidělte /26 na region.
   • Edge-Leaf - /29 při DC - až 8 krabic. Přidělte /27 na region.

Pokud nemáme v DC dostatek přidělených rozsahů (a nebudeme je mít – předstíráme, že jsme hyperscaler), jednoduše vybereme další blok.

Zde je obrázek s IP adresováním.

Loopbacky:

Předpona
Role zařízení
Kraj
DC

172.16.0.0/23
hrana
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
MSK

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
Bcn

172.16.0.40/29
MLG

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
sia

172.16.2.0/23
páteř
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
MSK

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
Bcn

172.16.2.80/28
MLG

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
sia

172.16.8.0/21
list
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
MSK

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
Bcn

172.16.10.128/25
MLG

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
sia

Podložka:

Předpona
Kraj
DC

10.0.0.0/17
ru
 

10.0.0.0/19
MSK

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
Bcn

10.0.160.0/19
MLG

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
sia

Laba

Dva prodejci. Jedna síť. ADSM.

Juniper + Arista. Ubuntu. Stará dobrá Evo.

Množství prostředků na našem virtuálním stroji v Miranu je stále omezené, takže pro praxi využijeme takto zjednodušenou síť na maximum.

Dvě datová centra: Kazaň a Barcelona.

• Každé dvě zatočení: Juniper a Arista.
• Jeden torus (Leaf) v každém - Juniper a Arista, s jedním připojeným hostitelem (vezměme na to lehkou Cisco IOL).
• Každý jeden Edge-Leaf uzel (zatím jen Juniper).
• Jeden Cisco přepínač, který bude vládnout všem.
• Kromě síťových boxů byl spuštěn i správce virtuálních strojů. Pod Ubuntu.
  Má přístup ke všem zařízením, bude spouštět systémy IPAM / DCIM, spoustu skriptů Python, ansible a cokoli dalšího, co bychom mohli potřebovat.

Plná konfigurace všechna síťová zařízení, která se pokusíme reprodukovat pomocí automatizace.

Závěr

Je to také přijato? Pod každým článkem udělat krátký závěr?

Tak jsme si vybrali tříúrovňový Kloz síť uvnitř DC, protože očekáváme velký provoz z východu na západ a chceme ECMP.

Síť jsme rozdělili na fyzickou (podložení) a virtuální (překrytí). Současně překrývání začíná od hostitele – tím se zjednodušují požadavky na překrytí.

Jako směrovací protokol routeru si zvolili BGP pro jeho škálovatelnost a flexibilitu zásad.

Budeme mít samostatné uzly pro organizaci DCI - Edge-leaf.
Na páteři bude OSPF+LDP.
DCI bude implementováno na základě MPLS L3VPN.
U P2P spojení vypočítáme IP adresy algoritmicky na základě názvů zařízení.
Loopbacky budou přiřazeny podle role zařízení a jejich umístění postupně.
Předpony podkladu - pouze u přepínačů Leaf v sérii na základě jejich umístění.

Předpokládejme, že právě nemáme nainstalované žádné zařízení.
Naším dalším krokem tedy bude dostat je do systémů (IPAM, inventář), uspořádat přístup, vygenerovat konfiguraci a nasadit ji.

V příštím článku se budeme zabývat Netboxem, systémem inventarizace a správy IP prostoru v DC.

dík

• Andrey Glazkov aka @glazgoo pro korektury a úpravy
• Alexandru Klimenko aka @v00lk za korektury a úpravy
• Artyom Černobay pro KDPV

Zdroj: www.habr.com