V prvih dveh člankih sem obravnaval vprašanje avtomatizacije in orisal njen okvir, v drugem pa sem se dotaknil virtualizacije mreže, kot prvega pristopa k avtomatizaciji nastavitev storitev.
Zdaj pa je čas, da narišem shemo fizične mreže.

Če niste intimno seznanjeni z napravami mrež podatkovnih centrov, vam toplo priporočam, da začnete z članek o njih.

Vse številke:

• 0. ADSK. Del Nič. Načrtovanje
• 1. ADSK. Prvi del (ki sledi ničli). Virtualizacija mreže
• 2. ADSK. Drugi Del. Oblikovanje Mreže

Vse prakse opisane v tej seriji bi morale biti uporabne za mrežo katerega koli tipa, katere koli velikosti in z raznolikostjo prodajalcev (ne). Vendar pa ni mogoče opisati univerzalnega primera uporabe teh pristopov. Zato se bom osredotočil na sodobno arhitekturo mreže DC: Fabric Clos.
DCI bomo naredili na MPLS L3VPN.

Poleg fizične mreže deluje Overlay-mreža s hosta (to je lahko VXLAN OpenStacka ali Tungsten Fabric ali karkoli drugega, kar od mreže zahteva le osnovno IP-povezljivost).

V tem primeru bo to relativno preprost scenarij za avtomatizacijo, ker imamo veliko opreme, ki se konfigurira na enak način.

Izbrali bomo sferični DC v vakuumu:

• Ena različica oblikovanja povsod.
• Dva prodajalca, ki tvorita dve ravnini mreže.
• Eden DC izgleda kot drugi kot dve kapljici vode.

Vsebina

• Fizična topologija
• Usmerjanje
• IP-načrt
• Mala
• Zaključek
• Koristne poveznice

Naj naš ponudnik storitev LAN_DC na primer gosti učne video posnetke o preživetju v zaljubljenih dvigalih.

V metropolijah je to izjemno priljubljeno, zato je potrebno veliko fizičnih naprav.

Najprej bom opisal mrežo približno tako, kot bi si želeli videti. Potem pa jo bom poenostavil za malo.

Fizična topologija

Lokacije

LAN_DC bo imel 6 DC-jev:

• Rusija (RU):
  • Moskva (msk)
  • Kazan (kzn)

• Španija (SP):
  • Barcelona (bcn)
  • Malaga (mlg)

• Kitajska (CN):
  • Šanghaj (sha)
  • Sian (sia)

Znotraj DC (Intra-DC)

V vseh DC-jih so identične mreže notranje povezljivosti, temeljene na topologiji Clos.
Kakšne so mreže Clos in zakaj prav te — v ločenem članku.

V vsakem DC-ju je 10 omar z napravami, te se bodo številčile kot A, B, C In tako naprej.

V vsaki omari je 30 naprav. Te nas ne zanimajo.

Prav tako je v vsaki omari stikalo, na katerega so priključene vse naprave — to je Top of the Rack switch — ToR ali drugače v terminologiji tovarne Clos bomo imenovali Leaf.

Splošni načrt tovarne.

Imenujemo jih XXX-leafY, gde XXX — tridimenzionalna okrajšava ToR, ter Y — zaporedna številka. Na primer, kzn-leaf11.

V člankih si bom dovolil razmeroma prosto uporabljati termine Leaf in ToR kot sinonime. Vendar pa je treba upoštevati, da to ni res.
ToR je stikalo, nameščeno v omari, na katerega so priključeni strežniki.
Leaf je vloga naprave v fizični mreži ali stikalo prve ravni v terminologiji toplotne mreže.
Torej Leaf != ToR.
Torej Leaf lahko predstavlja EndofRaw stikalo, na primer.
V okviru tega članka pa se bomo vseeno sklicevali na njih kot na sinonime.

Vsako ToR stikalo je povezano s štirimi višjimi agregatnimi stikali — Spine. Za Spine je dodeljena ena omara v DČ. Imenujemo jih podobno: XXX-spineY.

V tej isti omari bo stalo omrežno opremo za povezljivost med DČ — 2 usmerjevalnika z MPLS na krovu. A v veliki meri — to so iste ToR. Torej z vidika Spine stikal ni nobene razlike med običajnim ToR s priključenimi stroji ali usmerjevalnikom za DCI — oboje enako usmerja.

Takšna posebna ToR stikala imenujemo Edge-leaf. Mi jih bomo imenovali XXX-edgeY.

Izgledalo bo tako.

Na zgornjem načrtu sem resnično postavil edge in leaf na isto raven. Klasične tridimenzionalne mreže so nas naučile, da obravnavamo uplink (od tod izraz), kot povezave navzgor. A tukaj se izkaže, da 'uplink' DCI gre nazaj navzdol, kar nekaterim nekoliko zameša običajno logiko. V primeru velikih mrež, ko se podatkovni centri še delijo na manjše enote — POD‘e (Točka dostave), dodeljujejo posebej Edge-POD‘e za DCI in izhod v zunanje mreže.

Za lažje razumevanje bom kasneje risal Edge nad Spine, pri čemer bomo imeli v mislih, da na Spine ni nobene inteligence in ni razlik pri delu z običajnimi Leaf in Edge-leaf (čeprav tukaj lahko pride do posebnosti, a na splošno je tako).

Načrt tovarne z Edge-leaf.

Trojica Leaf, Spine in Edge tvorita Underlay mrežo ali tovarno.

Naloga omrežne tovarne (beri Underlay), kot smo se že dogovorili v prejšnji izdaji, je zelo in zelo preprosta — zagotoviti IP-povezljivost med stroji tako v okviru enega DČ kot tudi med njimi.
Zato se mreža i naziva fabrikom, isto kao što je fabrika preklapanja unutar modularnih mrežnih kutija, o čemu se detaljnije može pročitati u SDSМ14.

Uopšte, takva topologija se naziva fabrikom, jer se fabric u prevodu prevodi kao tkivo. I teško je ne složiti se:

Fabrika je potpuno L3. Nema VLAN-ova, nema broadcast-a — ovakvi naši sjajni programeri u LAN_DC znaju da pišu aplikacije koje funkcionišu u L3 paradigmi, a virtuelne mašine ne zahtevaju Live Migration sa očuvanjem IP adrese.

I još jednom: odgovor na pitanje zašto fabrika i zašto L3 — u posebnoj članku.

DCI — Interkonekcija Data Centara (Inter-DC)

DCI će biti organizovan pomoću Edge-Leaf, dakle, oni su naš izlaz u magistralu.
Za jednostavnost, pretpostavimo da su DC međusobno povezani direktnim vezama.
Isključujemo iz razmatranja spoljašnju povezanost.

Svestan sam da svaki put kada uklonim neki komponent, značajno pojednostavljujem mrežu. I prilikom automatizacije naše apstraktne mreže sve će biti u redu, a u realnoj će se pojaviti problemi.
To je tačno. I opet, cilj ove serije je da razmislimo i radimo na pristupima, a ne heroički rešavamo izmišljene probleme.

Na Edge-Leaf podlozi se nalazi VPN i prenosi se preko MPLS magistrale (to je onaj direktni link).

Tako izgleda visoko nivo sheme.

Usmerjanje

Za rutiranje unutar DC-a koristićemo BGP.
Na MPLS magistrali OSPF+LDP.
Za DCI, tj. organizaciju povezanosti u podlozi — BGP L3VPN preko MPLS-a.

Opšta shema rutiranja

Na fabrici nema OSPF-a i ISIS-a (protokol rutiranja zabranjen u Ruskoj Federaciji).

A to znači da neće biti Auto-discovery i računanja najkraćih puteva — samo ručna (zapravo automatska — ipak pričamo o automatizaciji) konfiguracija protokola, susedstva i politika.

Shema rutiranja BGP unutar DC-a

Zašto BGP?

Na tu temu postoji cela RFC imena Facebook-a i Ariste, gde se objašnjava kako graditi veoma velike data centar mreže, koristeći BGP. Čita se gotovo kao fikcija, veoma preporučujem za mirno veče.

A takođe, ceo odeljak u mom članku je posvećen tome. Tamo vas i upučujem.

Ali ako ukratko, nijedna IGP nije pogodna za mreže velikih data centara, gde se broj mrežnih uređaja broji u hiljadama.

Poleg tega bo uporaba BGP povsod omogočila, da se ne razpršimo po podpori več različnih protokolov in sinhronizaciji med njimi.

Če povem po resnici, na naši tovarni, ki verjetno ne bo hitro rasla, bi zadostovalo tudi OSPF. To so resnično težave megaskalerjev in oblačnih titanov. Vendar si lahko predstavljamo, da bomo to potrebovali, in uporabljali BGP, kot je predlagal Pjotr Lapuhov.

Politike usmerjanja

Na Leaf stikalih bomo v BGP uvozili prefikse z Underlay vmesnikov s omrežji.
Imeli bomo BGP sejo med vsako paresom Leaf-Spine, v kateri bodo ti Underlay prefiksi napovedani po omrežju.

Znotraj enega podatkovnega centra bomo širili specifike, ki smo jih uvozili na ToR. Na Edge-Leaf jih bomo agregirali in napovedali v oddaljene DC ter jih spustili do ToR. To pomeni, da bo vsak ToR natančno vedel, kako priti do drugega ToR v istem DC-ju in kje je vstopna točka, da doseže ToR v drugem DC-ju.

V DCI bodo poti posredovane kot VPNv4. Za to bo na Edge-Leaf vmesniku v smeri tovarne postavljen VRF, poimenujmo ga UNDERLAY, in sosedsko razmerje s Spine na Edge-Leaf se bo vzpostavilo znotraj VRF, med Edge-Leaf pa v VPNv4 družini.

Prav tako bomo prepovedali ponovno napovedovanje poti, prejetih od spine, nazaj nanje.

Na Leaf in Spine ne bomo uvažali Loopback-ov. Potrebovali jih bomo le za določitev Router ID.

Na Edge-Leaf pa ga bomo uvozili v Global BGP. Med Loopback naslovi Edge-Leaf bodo vzpostavili BGP sejo v IPv4 VPN-family med seboj.

Med EDGE napravami bomo imeli raztegnjeno povezavo na OSPF+LDP. Vse v eni coni. Zelo preprosta konfiguracija.

Tako izgleda slika usmerjanja.

BGP ASN

Edge-Leaf ASN

Na Edge-Leaf bo en ASN v vseh DC-jih. To je pomembno, da bo med Edge-Leaf iBGP in se ne bomo srečali z odtenki eBGP. Naj bo to 65535. V resnici bi to lahko bilo število javne AS.

Spine ASN

Na Spine bomo imeli en ASN na DC. Začeli bomo s prvim številom iz območja zasebnih AS — 64512, 64513 in tako naprej.

Zakaj ASN na DC?

To vprašanje razgradimo na dva dela:

• Zakaj enaki ASN na vseh spineih enega DC?
• Zakaj različni v različnih DC-jih?

Zakaj enaki ASN na vseh spineih enega DC?

Tako bo videti AS-Path podlage na robnem vozlišču:
[leafX_ASN, spine_ASN, edge_ASN]
Ko poskušamo napovedati nazaj na Spine, ga bo ta zavrgel, ker je njegov AS (Spine_AS) že v seznamu.

Vendar nas znotraj podatkovnega centra popolnoma zadostuje, da se poti podlage, ki se dvignejo do roba, ne morejo spuščati navzdol. Vsa komunikacija med gostitelji znotraj podatkovnega centra se mora dogajati na nivoju spine.

Aglomerirane poti iz drugih podatkovnih centrov pa bodo vseeno prosto dosegle ToR-e — njihov AS-Path bo vseboval samo ASN 65535 — številko AS robnih vozlišč, ker so bile tam ustvarjene.

Zakaj so različne v različnih podatkovnih centrih

Teoretično bi morda potrebovali povezati Loopback-e nekaterih servisnih virtualnih strojev med podatkovnimi centri.

Na primer, na gostitelju se lahko zažene Route Reflector ali tisti prav VNGW (Virtual Network Gateway), ki se preko BGP poveže s ToRom in napove svoj loopback, ki mora biti dostopen iz vseh podatkovnih centrov.

Tako bo izgledal njegov AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

In nikjer ne bi smelo biti ponavljajočih se ASN.

To pomeni, da morata biti Spine_DC1 in Spine_DC2 različna, prav tako leafX_DC1 in leafY_DC2, kar pravzaprav tudi dosežemo.

Kot verjetno veste, obstajajo hrosti, ki omogočajo sprejemanje poti z ponavljajočimi se ASN kljub mehanizmu preprečevanja zank (allowas-in na Cisco). In to ima celo povsem zakonite uporabe. Vendar pa je to potencialna ranljivost omrežja. Osebno sem v to večkrat padel.

In če imamo možnost, da ne uporabljamo nevarnih stvari, jo bomo izkoristili.

Leaf ASN

Imeli bomo edinstven ASN na vsakem leaf stikalu znotraj celotnega omrežja.
To počnemo iz razlogov, navedenih zgoraj: AS-Path brez zank, konfiguracija BGP brez vložkov.

Da bi poti med leaf-i prosto prehajale, mora AS-Path izgledati takole:
[leafX_ASN, spine_ASN, leafY_ASN]
kjer bi bilo dobro, da se leafX_ASN in leafY_ASN razlikujeta.

To je nujno tudi za situacijo z napovedovanjem loopbacka VNF med DC-ji:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Uporabljali bomo 4-bajtni ASN in ga generirali na podlagi ASN spine in številke leaf stikala, in sicer, takole: Spine_ASN.0000X.

Tako je videti slika z ASN.

IP-načrt

Principialno moramo dodeliti naslove za naslednje povezave:

1. Naslovi omrežja Underlay med ToR in strojem. Morajo biti unikatni znotraj celotnega omrežja, da se kateri koli stroj lahko poveže z vsakim drugim. Odlično se prilega 10/8. Za svaki ormar po /26 s rezervom. Izdvojićemo po /19 za DC i /17 za region.
2. Link adrese između Leaf/Tor i Spine.

   Želeli bismo ih dodeljivati algoritamski, odnosno izračunavati iz imena uređaja koji treba da se povežu.

   Neka to bude… 169.254.0.0/16.
   Tačno. 169.254.00X.Y/31, gde X — broj Spine, Y — P2P-mreža /31.
   To će omogućiti pokretanje do 128 ormara, i do 10 Spine u DC. Link adrese mogu (i hoće) da se ponavljaju iz DC u DC.

3. Veza između Spine i Edge-Leaf organizovaće se na podmrežama 169.254.10X.Y/31, gde je isto tako X — broj Spine, Y — P2P-mreža /31.
4. Link adrese iz Edge-Leaf u MPLS-magistralu. Ovde je situacija donekle drugačija — mesto povezivanja svih delova u jedan kolač, pa ne možemo ponovo koristiti iste adrese — potrebno je izabrati sledeću slobodnu podmrežu. Zato ćemo uzeti 192.168.0.0/16 i izvlačiti slobodne iz nje.
5. Adrese Loopback. Dodelićemo im celu oblast 172.16.0.0/12.
   • Leaf — po /25 u DC — istih 128 ormara. Izdvojićemo po /23 za region.
   • Spine — po /28 u DC — do 16 Spine. Izdvojićemo po /26 za region.
   • Edge-Leaf — po /29 u DC — do 8 kutija. Izdvojićemo po /27 za region.

Ako u DC ne budemo imali dovoljno dodeljenih oblasti (a nećemo — mi se ipak borimo za hiper-skalabilnost), jednostavno ćemo izdvojiti sledeći blok.

Evo kakva je situacija sa IP-adresiranjem.

Loopback-i:

Prefiks
Uloga uređaja
Region
DC

172.16.0.0/23
edge
 
 

172.16.0.0/27
sl
 

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
spine
 
 

172.16.2.0/26
sl
 

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
leaf
 
 

172.16.8.0/23
sl
 

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

Underlay:

Prefiks
Region
DC

10.0.0.0/17
sl
 

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

Mala

Dva dobavljača. Jedna mreža. ADSEM.

Juniper + Arista. Ubuntu. Stara dobra Eva.

Broj resursa na našoj virtuelnoj mašini u Miranu je ipak ograničen, pa ćemo za praksu koristiti ovako pojednostavljenu mrežu.

Dva data centra: Kazanj i Barselona.

• Po dva spajna u svakom: Juniper i Arista.
• Po jedan tor (Leaf) u svakom — Juniper i Arista, sa jednim povezanom hostom (uzećemo laki Cisco IOL za ovo).
• Po jedna node Edge-Leaf (za sada samo Juniper).
• Jedan Cisco prekidač da vlada svima.
• Pored mrežnih kutija, pokrenuta je virtuelna mašina za upravljanje. Pod upravom Ubuntu.
  Ima pristup svim uređajima, na njoj će se vrteti IPAM/DCIM sistemi, zbirka Pythonskih skripti, Ansible i šta god drugo što nam može biti potrebno.

Puna konfiguracija svi mrežni uređaji koje ćemo pokušati da reprodukujemo pomoću automatizacije.

Zaključek

Da li je tako uobičajeno? Da se ispod svake stavke napravi kratak zaključak?

Dakle, izabrali smo trostepenu Kloza mrežu unutar DC-a, budući da očekujemo mnogo East-West prometa i želimo ECMP.

Omrežili smo fizično (underlay) in virtualno (overlay) omrežje. Ooverlay se začne z gostiteljem, kar poenostavi zahteve do underleya.

Izbrali smo BGP kot protokol usmerjanja za omrežja underlay zaradi njegove razširljivosti in prilagodljivosti politik.

Imeli bomo ločene vozle za organizacijo DCI — Edge-leaf.
Na osrednji do simetrični poti bo OSPF+LDP.
DCI bo implementiran na osnovi MPLS L3VPN.
Za P2P povezave bomo IP naslove izračunavali algoritmično na podlagi imen naprav.
Loopback naslove bomo dodelili glede na vlogo naprav in njihovo lokacijo.
Underlay prefiksi bodo dodeljeni samo Leaf preklopnikom na osnovi njihove lokacije.

Predpostavimo, da trenutno še nimamo nameščene opreme.
Zato bodo naši naslednji koraki - vnesti jih v sisteme (IPAM, inventar), organizirati dostop, generirati konfiguracijo in jo namestiti.

V naslednjem članku se bomo osredotočili na Netbox — sistem za inventarizacijo in upravljanje IP prostora v podatkovnem centru.

Hvala

• Andrey Glaazkov aka @glazgoo za lekturo in popravke
• Alexander Klimenko aka @v00lk za lekturo in popravke
• Artem Chernbay za KDPV

Izvor: habr.com