V prvých dvoch článkoch som nastolil problematiku automatizácie a načrtol jej rámec, v druhom som ustúpil do virtualizácie siete, ako prvého prístupu k automatizácii konfigurácie služieb.
Teraz je čas nakresliť diagram fyzickej siete.

Ak nie ste oboznámení s nastavením sietí dátových centier, dôrazne odporúčam začať s články o nich.

Všetky problémy:

• 0. ADSM. Časť nula. Plánovanie
• 1. ADSM. Prvá časť (ktorá je po nule). Virtualizácia siete
• 2. ADSM. Druhá časť. Návrh siete

Postupy opísané v tejto sérii by mali byť použiteľné pre akýkoľvek typ siete, akejkoľvek veľkosti, s rôznymi dodávateľmi (nie). Nie je však možné opísať univerzálny príklad aplikácie týchto prístupov. Preto sa zameriam na modernú architektúru DC siete: Továreň Kloz.
Urobíme DCI na MPLS L3VPN.

Prekrývacia sieť beží nad fyzickou sieťou od hostiteľa (môže to byť OpenStack's VXLAN alebo Tungsten Fabric alebo čokoľvek iné, čo vyžaduje len základné IP pripojenie zo siete).

V tomto prípade dostaneme relatívne jednoduchý scenár pre automatizáciu, pretože máme veľa zariadení, ktoré sú nakonfigurované rovnakým spôsobom.

Vyberieme sférický jednosmerný prúd vo vákuu:

• Všade jedna dizajnová verzia.
• Dvaja predajcovia tvoriaci dve sieťové roviny.
• Jedno DC je ako druhé ako dva hrášky v struku.

Obsah

• Fyzická topológia
• Smerovanie
• IP plán
• Laba
• Záver
• Užitočné odkazy

Nechajte napríklad nášho poskytovateľa služieb LAN_DC hostiť školiace videá o prežití v uviaznutých výťahoch.

V megacities je to veľmi populárne, takže potrebujete veľa fyzických strojov.

Najprv popíšem sieť približne tak, ako by som ju chcel mať. A potom to zjednoduším pre laboratórium.

Fyzická topológia

Miesta

LAN_DC bude mať 6 DC:

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

• Španielsko (SP):
  • Barcelona (bcn)
  • Malaga (MLG)

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

Vnútri DC (Intra-DC)

Všetky DC majú identické interné prepojovacie siete založené na topológii Clos.
O aké siete Clos ide a prečo sú samostatné článok.

Každé DC má 10 stojanov so strojmi, budú očíslované ako A, B, C A tak ďalej.

Každý stojan má 30 strojov. Nebudú nás zaujímať.

V každom stojane je tiež prepínač, ku ktorému sú pripojené všetky stroje - to je Horná časť prepínača Rack - ToR alebo inak, v podmienkach továrne Clos, to budeme nazývať List.

Všeobecná schéma továrne.

Zavoláme im XXX-listYKde XXX - trojpísmenová skratka DC, a Y - sériové číslo. Napríklad, kzn-list11.

Vo svojich článkoch si dovolím výrazy Leaf a ToR používať dosť frivolne ako synonymá. Musíme si však uvedomiť, že to tak nie je.
ToR je prepínač inštalovaný v stojane, ku ktorému sú pripojené stroje.
Leaf je úlohou zariadenia vo fyzickej sieti alebo prepínača prvej úrovne z hľadiska topológie Cloes.
Teda List != ToR.
Takže Leaf môže byť napríklad prepínač EndofRaw.
V rámci tohto článku ich však budeme stále považovať za synonymá.

Každý prepínač ToR je zase pripojený k štyrom agregačným prepínačom vyššej úrovne - Chrbtica. Jeden stojan v DC je pridelený pre Spines. Pomenujeme to podobne: XXX-chrbticaY.

Rovnaký rack bude obsahovať sieťové vybavenie pre konektivitu medzi smerovačmi DC - 2 s MPLS na doske. Celkovo sú to však tie isté ToR. Čiže z pohľadu Spine switchov na obyčajnom ToR s pripojenými strojmi alebo routerom pre DCI vôbec nezáleží - len preposielanie.

Takéto špeciálne ToR sú tzv Okrajový list. Zavoláme im XXX-hranaY.

Bude to vyzerať takto.

Vo vyššie uvedenom diagrame som skutočne umiestnil okraj a list na rovnakú úroveň. Klasické trojvrstvové siete Naučili nás považovať uplink (odtiaľ ten pojem) za uplinky. A tu sa ukazuje, že „uplink“ DCI sa vracia nadol, čo pre niektorých mierne porušuje obvyklú logiku. V prípade veľkých sietí, keď sú dátové centrá rozdelené na ešte menšie jednotky - POD's (Point Of Delivery), zvýraznite jednotlivé Edge-POD's pre DCI a prístup k externým sieťam.

Pre uľahčenie vnímania v budúcnosti stále nakreslím Edge cez Spine, pričom budeme mať na pamäti, že na Spine nie je žiadna inteligencia a neexistujú žiadne rozdiely pri práci s bežným Leafom a Edge-leafom (aj keď tu môžu byť nuansy , ale vo všeobecnosti je to pravda).

Schéma továrne s okrajovými listami.

Trojica Leaf, Spine a Edge tvorí sieť alebo továreň Underlay.

Úloha továrne siete (čítaj Underlay), ako sme už definovali v posledné vydanie, veľmi, veľmi jednoduché - poskytnúť IP konektivitu medzi strojmi v rámci toho istého DC a medzi nimi.
Preto sa sieť nazýva továreň, podobne ako napríklad továreň na prepínanie vo vnútri modulárnych sieťových boxov, o ktorej sa viac dočítate v SDSM14.

Vo všeobecnosti sa takáto topológia nazýva továreň, pretože tkanina v preklade znamená tkanina. A je ťažké nesúhlasiť:

Továreň je kompletne L3. Žiadna VLAN, žiadne vysielanie – v LAN_DC máme takých úžasných programátorov, ktorí vedia písať aplikácie, ktoré žijú v L3 paradigme a virtuálne stroje nevyžadujú Live Migration so zachovaním IP adresy.

A ešte raz: odpoveď na otázku, prečo je továreň a prečo je L3 v oddelení článok.

DCI - Data Center Interconnect (Inter-DC)

DCI budú organizované pomocou Edge-Leaf, to znamená, že sú naším výstupným bodom na diaľnicu.
Pre jednoduchosť predpokladáme, že DC sú navzájom prepojené priamymi spojmi.
Vylúčme z úvahy externú konektivitu.

Som si vedomý toho, že pri každom odstránení komponentu výrazne zjednoduším sieť. A keď zautomatizujeme našu abstraktnú sieť, všetko bude v poriadku, ale na tej skutočnej budú barličky.
Toto je pravda. Zmyslom tejto série je však premýšľať a pracovať na prístupoch, nie hrdinsky riešiť vymyslené problémy.

Na Edge-Leafs je podložka umiestnená vo VPN a prenášaná cez chrbticu MPLS (rovnaké priame prepojenie).

Toto je diagram najvyššej úrovne, ktorý dostaneme.

Smerovanie

Pre smerovanie v rámci DC budeme používať BGP.
Na kufri MPLS OSPF+LDP.
Pre DCI, teda organizovanie konektivity v podzemí - BGP L3VPN cez MPLS.

Všeobecná schéma smerovania

Vo výrobe neexistuje OSPF ani ISIS (smerovací protokol zakázaný v Ruskej federácii).

To znamená, že nebude existovať žiadne automatické zisťovanie ani výpočet najkratších ciest – iba manuálne (v skutočnosti automatické – tu hovoríme o automatizácii) nastavenie protokolu, susedstva a politík.

Schéma smerovania BGP v rámci DC

Prečo BGP?

Na túto tému existuje celé RFC pomenovaný po Facebooku a Arista, ktorý hovorí, ako stavať veľmi veľký siete dátových centier využívajúce BGP. Číta sa to skoro ako beletria, vrelo odporúčam na mdlý večer.

A tomu je venovaná aj celá jedna časť v mojom článku. Kam ťa vezmem a posielam.

Ale stále skrátka žiadne IGP nie je vhodné pre siete veľkých dátových centier, kde počet sieťových zariadení ide do tisícov.

Navyše, používanie BGP všade vám umožní nestrácať čas podporou niekoľkých rôznych protokolov a synchronizáciou medzi nimi.

Ruku na srdce, v našej továrni, ktorá s vysokou mierou pravdepodobnosti rapídne rásť nebude, by OSPF na oči stačil. To sú vlastne problémy megascalerov a oblačných titanov. Ale predstavme si len pre niekoľko vydaní, že to potrebujeme, a budeme používať BGP, ako odkázal Pyotr Lapukhov.

Pravidlá smerovania

Na prepínačoch Leaf importujeme predpony zo sieťových rozhraní Underlay do BGP.
Medzitým budeme mať reláciu BGP každý pár Leaf-Spine, v ktorom budú tieto predpony Underlay oznamované cez sieť sem a tam.

V rámci jedného dátového centra budeme distribuovať špecifikácie, ktoré sme importovali do ToRe. Na Edge-Leafs ich zhrnieme a oznámime ich vzdialeným DC a pošleme ich TOR. To znamená, že každý ToR bude presne vedieť, ako sa dostať k inému ToR v rovnakom DC a kde je vstupný bod, ako sa dostať k ToR v inom DC.

V DCI budú trasy prenášané ako VPNv4. Aby ste to dosiahli, na Edge-Leaf sa rozhranie smerom k továrni umiestni do VRF, nazvime to UNDERLAY, a okolie s Spine na Edge-Leaf sa zdvihne v rámci VRF a medzi Edge-Leafs vo VPNv4- rodina.

Zakážeme tiež opätovné ohlasovanie trás prijatých od chrbtov späť k nim.

Na Leaf a Spine nebudeme importovať Loopbacky. Potrebujeme ich len na určenie ID smerovača.

Ale na Edge-Leafs to importujeme do Global BGP. Medzi adresami Loopback vytvorí Edge-Leafs reláciu BGP v rodine IPv4 VPN navzájom.

Medzi zariadeniami EDGE budeme mať chrbticu OSPF+LDP. Všetko je v jednej zóne. Extrémne jednoduchá konfigurácia.

Toto je obrázok s trasovaním.

BGP ASN

Edge-Leaf ASN

Na Edge-Leafs bude jedno ASN vo všetkých DC. Je dôležité, aby medzi Edge-Leafs existovalo iBGP a nenechali sme sa zachytiť nuansami eBGP. Nech je to 65535. V skutočnosti by to mohlo byť číslo verejného AS.

Chrbtica ASN

Na Spine budeme mať jedno ASN na DC. Začnime tu úplne prvým číslom z radu súkromných AS - 64512, 64513 A tak ďalej.

Prečo ASN na DC?

Rozdeľme túto otázku na dve časti:

• Prečo sú ASN rovnaké na všetkých chrbtoch jedného DC?
• Prečo sa líšia v rôznych DC?

Prečo sú rovnaké ASN na všetkých chrbtoch jedného DC?

Takto bude vyzerať AS-Path of the Underlay na Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Keď sa ho pokúsite inzerovať späť na Spine, zahodí ho, pretože jeho AS (Spine_AS) je už v zozname.

V rámci DC sme však úplne spokojní, že trasy Underlay, ktoré stúpajú na Edge, nebudú môcť ísť dole. Všetka komunikácia medzi hostiteľmi v rámci DC musí prebiehať na úrovni chrbtice.

V tomto prípade sa agregované trasy iných DC v každom prípade ľahko dostanú k ToR - ich AS-Path bude mať iba ASN 65535 - počet AS Edge-Leafs, pretože tam boli vytvorené.

Prečo sa líšia v rôznych DC?

Teoreticky možno budeme musieť pretiahnuť Loopback a niektoré servisné virtuálne stroje medzi DC.

Napríklad na hostiteľovi spustíme Route Reflector resp rovnaký VNGW (Virtual Network Gateway), ktorá sa uzamkne s TopR cez BGP a oznámi svoju slučku, ktorá by mala byť dostupná zo všetkých DC.

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

A nikde by nemali byť duplicitné ASN.

To znamená, že Spine_DC1 a Spine_DC2 sa musia líšiť, rovnako ako leafX_DC1 a leafY_DC2, k čomu sa práve blížime.

Ako pravdepodobne viete, existujú hacky, ktoré vám umožňujú akceptovať trasy s duplicitnými ASN napriek mechanizmu prevencie slučky (povolenie na Cisco). A má dokonca legitímne využitie. Toto je však potenciálna medzera v stabilite siete. A osobne som do toho párkrát spadol.

A ak máme možnosť nepoužívať nebezpečné veci, využijeme to.

List ASN

Budeme mať individuálne ASN na každom prepínači Leaf v celej sieti.
Robíme to z vyššie uvedených dôvodov: AS-Path bez slučiek, konfigurácia BGP bez záložiek.

Aby trasy medzi listami prešli hladko, AS-Path by mala vyzerať takto:
[leafX_ASN, spine_ASN, leafY_ASN]
kde leafX_ASN a leafY_ASN by bolo pekné byť odlišné.

Vyžaduje sa to aj pre situáciu s oznámením spätnej väzby VNF medzi DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Použijeme 4-bajtové ASN a vygenerujeme ho na základe Spine's ASN a čísla prepínača Leaf, konkrétne takto: Chrbtica_ASN.0000X.

Toto je obrázok s ASN.

IP plán

V zásade musíme prideliť adresy pre nasledujúce pripojenia:

1. Podkladové sieťové adresy medzi ToR a strojom. Musia byť jedinečné v rámci celej siete, aby každý stroj mohol komunikovať s ktorýmkoľvek iným. Skvele sedí 10/8. Pre každý stojan je /26 s rezervou. Rozdelíme /19 na DC a /17 na kraj.
2. Prepojte adresy medzi Leaf/Tor a Spine.

   Chcel by som ich priradiť algoritmicky, to znamená vypočítať ich z názvov zariadení, ktoré je potrebné pripojiť.

   Nechaj to byť... 169.254.0.0/16.
   Totiž 169.254.00 31 X.Y/XNUMXKde X - číslo chrbtice, Y — P2P sieť /31.
   To vám umožní spustiť až 128 stojanov a až 10 spinov v DC. Adresy odkazov sa môžu (a budú) opakovať z DC do DC.

3. Organizujeme spojenie Spine-Edge-Leaf na podsieťach 169.254.10 31 X.Y/XNUMXkde presne to isté X - číslo chrbtice, Y — P2P sieť /31.
4. Prepojte adresy z Edge-Leaf na chrbticu MPLS. Tu je situácia trochu iná - miesto, kde sú všetky časti spojené do jedného koláča, takže opätovné použitie rovnakých adries nebude fungovať - ​​musíte vybrať ďalšiu voľnú podsieť. Preto berme ako základ 192.168.0.0/16 a tie voľné z nej vyhrabeme.
5. Adresy spätnej slučky. Dáme za ne celý sortiment 172.16.0.0/12.
   • List - /25 na DC - rovnakých 128 stojanov. Na kraj pridelíme /23.
   • Chrbtica - /28 na DC - do 16 Chrbtica. Rozdeľme /26 na kraj.
   • Edge-Leaf - /29 na DC - až 8 boxov. Rozdeľme /27 na kraj.

Ak v DC nemáme dostatok pridelených rozsahov (a žiadne nebudú – tvrdíme, že sme hyperškálovače), jednoducho vyberieme ďalší blok.

Toto je obrázok s IP adresovaním.

Spätné slučky:

prefix
Úloha zariadenia
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
chrbtica
 
 

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

Podklad:

prefix
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

Dvaja predajcovia. Jedna sieť. ADSM.

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

Množstvo zdrojov na našom virtuálnom serveri v Mirane je zatiaľ obmedzené, takže pre prax použijeme sieť, ktorá je zjednodušená na maximum.

Dve dátové centrá: Kazaň a Barcelona.

• Každý z dvoch chrbtov: Juniper a Arista.
• Jeden torus (Leaf) v každom - Juniper a Arista, s jedným pripojeným hostiteľom (zoberme si na to ľahkú Cisco IOL).
• Každý jeden uzol Edge-Leaf (zatiaľ iba Juniper).
• Jeden prepínač Cisco bude vládnuť všetkým.
• Okrem sieťových boxov beží virtuálny riadiaci stroj. Spustený Ubuntu.
  Má prístup ku všetkým zariadeniam, bude spúšťať systémy IPAM/DCIM, množstvo skriptov Python, Ansible a čokoľvek iné, čo by sme mohli potrebovať.

Úplná konfigurácia všetkých sieťových zariadení, ktoré sa pokúsime reprodukovať pomocou automatizácie.

Záver

Je to tiež akceptované? Mám pod každý článok napísať krátky záver?

Tak sme si vybrali trojúrovňový Sieť Kloz v DC, pretože očakávame veľkú premávku z východu na západ a chceme ECMP.

Sieť bola rozdelená na fyzickú (podkladová) a virtuálnu (prekrývacia). Súčasne prekrytie začína od hostiteľa - čím sa zjednodušia požiadavky na podloženie.

Zvolili sme BGP ako smerovací protokol pre sieťové siete pre jeho škálovateľnosť a flexibilitu politiky.

Budeme mať samostatné uzly na organizovanie DCI - Edge-leaf.
Chrbtica bude mať OSPF+LDP.
DCI bude implementované na základe MPLS L3VPN.
Pre P2P prepojenia vypočítame IP adresy algoritmicky na základe názvov zariadení.
Slučky budeme prideľovať postupne podľa úlohy zariadení a ich umiestnenia.
Predpony podkladu - iba na prepínačoch Leaf postupne na základe ich umiestnenia.

Predpokladajme, že momentálne ešte nemáme nainštalované zariadenie.
Preto bude naším ďalším krokom ich pridanie do systémov (IPAM, inventár), organizácia prístupu, vygenerovanie konfigurácie a jej nasadenie.

V ďalšom článku sa budeme zaoberať Netboxom - inventarizačným a riadiacim systémom pre IP priestor v DC.

Ďakujem

• Andrey Glazkov aka @glazgoo za korektúry a opravy
• Alexandrovi Klimenkovi alias @v00lk za korektúry a úpravy
• Arťom Černobaj pre KDPV

Zdroj: hab.com