U prva dva članka postavio sam pitanje automatizacije i nagovijestio njezin okvir; u drugom sam se osvrnuo na virtualizaciju mreže kao prvi pristup automatizaciji postavljanja usluga.
Sada je vrijeme za izradu sheme fizičke mreže.

Ako niste dobro upoznati s uređajem mreža data centara, toplo preporučujem da počnete s članakom o njima.

Svi brojevi:

• 0. ADSM. Nulti dio. Planiranje
• 1. ADSM. Prvi dio (koji dolazi nakon nultog). Virtualizacija mreže
• 2. ADSM. Drugi dio. Dizajn mreže

Praktike opisane u ovoj seriji trebale bi se moći primijeniti na mrežu bilo koje vrste, bilo kojeg opsega s bilo kakvom raznolikošću dobavljača (ne). Međutim, nije moguće opisati univerzalni primjer primjene ovih pristupa. Stoga ću se fokusirati na modernu arhitekturu mreže DC-a: Clos Fabric.
DCI ćemo raditi na MPLS L3VPN.

Iznad fizičke mreže radi Overlay mreža s hosta (to može biti VXLAN OpenStacka ili Tungsten Fabric ili bilo što drugo što zahtijeva samo osnovnu IP povezanost).

U tom slučaju dobit ćemo relativno jednostavan scenarij za automatizaciju, jer imamo mnogo opreme koja se postavlja na isti način.

Odabrat ćemo sferični DC u vakuumu:

• Jedna verzija dizajna posvuda.
• Dva dobavljača koja čine dvije ravnine mreže.
• Jedan DC izgleda kao drugi kao dvije kapi vode.

Sadržaj

• Fizička topologija
• Usmjeravanje
• IP plan
• Laboratorij
• Zaključak
• Koristitne veze

Neka naš Krovni Davatelj LAN_DC bude, na primjer, domaćin edukativnim videozapisima o preživljavanju u zaglavljenim liftovima.

U metropolama to uživa veliku popularnost, stoga je potrebno puno fizičkih mašina.

Prvo ću opisati mrežu otprilike onakvu kakvu bih je želio vidjeti. A onda ću je pojednostaviti za laboratorij.

Fizička topologija

Lokacije

LAN_DC će imati 6 DC-a:

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

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

• Kina (CN):
  • Šangaj (sha)
  • Sijan (sia)

Unutra DC-a (Intra-DC)

U svim DC-ima identične mrežne strukture unutarnje povezanosti, temeljene na topologiji Clos.
Što su Clos mreže i zašto upravo one — u posebnom članku.

U svakom DC-u po 10 ormara s mašinama, bit će numerisani kao A, B, C I tako dalje.

U svakom ormaru po 30 mašina. One nas neće zanimati.

Također u svakom ormaru je prekidač, na koji su spojene sve mašine — to je Top of the Rack switch — ToR ili u terminima fabrike Clos nazivamo ga Leaf.

Opća shema fabrike.

Nazvat ćemo ih XXX-leafY, gdje XXX — tročlana skraćenica DC, a Y — redni broj. Na primjer, kzn-leaf11.

U člancima ću se slobodno odnositi prema terminima Leaf i ToR kao sinonimima. Međutim, treba imati na umu da to nije tako.
ToR je prekidač postavljen u ormar, na koji se povezuju strojevi.
Leaf je uloga uređaja u fizičkoj mreži ili prekidač prvog nivoa u terminima Cloza topologije.
Dakle, Leaf != ToR.
Dakle, Leaf može biti EndofRaw prekidač, na primjer.
Međutim, u okviru ovog članka i dalje ćemo ih tretirati kao sinonime.

Svaki ToR prekidač je zauzvrat povezan s četiri viša agregacijska prekidača — Spine. Za Spine je odvojena jedna ormarska jedinica u DC. Imenovaćemo ih na sličan način: XXX-spineY.

U istoj će jedinici stajati mrežna oprema za vezu između DC — 2 usmjerivača s MPLS na brodu. Ali u suštini, to su isti ToR-ovi. Dakle, s aspekta Spine prekidača, nema nikakve razlike između običnog ToR-a s povezanim strojevima ili usmjerivača za DCI — svejedno je proslediti.

Takvi posebni ToR-ovi nazivaju se Edge-leaf. Mi ćemo ih nazivati XXX-edgeY.

Izgledat će ovako.

Na gornjem dijagramu, edge i leaf su zaista smješteni na istom nivou. Klasične trostupne mreže naučile su nas da gledamo uplink (otuda i termin) kao linkove prema gore. A ovdje imamo „uplink“ DCI koji ide nazad dolje, što nekima malo narušava poznatu logiku. U slučaju velikih mreža, kada se data centri dalje dijele na manje jedinice — POD‘e (Point Of Delivery), izdvajaju se posebni Edge-POD‘i za DCI i izlaz u vanjske mreže.

Radi lakšeg shvaćanja u budućnosti, i dalje ću crtati Edge iznad Spine, s tim da ćemo imati na umu da na Spine ne postoji nikakva inteligencija i razlike u radu s običnim Leaf i Edge-leaf (iako ovdje mogu biti nijanse, ali u cjelini je tako).

Shema fabrike s Edge-leaf-ima.

Trostruka Leaf, Spine i Edge čine Underlay mrežu ili fabriku.

Zadatak mrežne fabrike (tj. Underlay), kao što smo već utvrdili u To je uzrokovalo probleme na nekim web stranicama., vrlo je jednostavan — osigurati IP povezanost između strojeva kako unutar jednog DC, tako i između.
Zato se mreža naziva fabrikom, kao što je na primjer fabrika preklapanja unutar modularnih mrežnih kutija, o čemu više možete pročitati u SDSM14.

A u svakom slučaju, ova topologija se naziva fabrikom, jer se fabric na hrvatskom prevodi kao tkanina. I teško je ne složiti se:

Fabrika je potpuno L3. Nema VLAN-ova, nema Broadcast-a — naši divni programeri u LAN_DC znaju pisati aplikacije koje žive u L3 paradigmi, a virtualne mašine ne zahtijevaju Live Migration uz zadržavanje IP adrese.

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

DCI — Data Center Interconnect (Inter-DC)

DCI će biti organiziran pomoću Edge-Leafa, što znači da su oni naša izlazna točka u magistralu.
Za jednostavnost pretpostavimo da su DC-ovi povezani direktnim linkovima.
Isključimo iz razmatranja vanjsku povezanost.

Potpuno sam svjestan da svaki put kada uklonim neki komponent, značajno pojednostavljujem mrežu. I dok će u automatizaciji naše apstraktne mreže sve biti u redu, u stvarnoj će se pojaviti problemi.
To je tako. Ipak, cilj ove serije je razmisliti i raditi na pristupima, a ne herojski rješavati izmišljene probleme.

Na Edge-Leaf-ima, underlay se stavlja u VPN i prenosi putem MPLS magistrale (onog direktnog linka).

Dobijena je ovakva visoka razina sheme.

Usmjeravanje

Za usmjeravanje unutar DC-a koristit ćemo BGP.
Na MPLS magistrali OSPF+LDP.
Za DCI, to jest organizaciju povezanosti u underlay-u — BGP L3VPN preko MPLS-a.

Opća shema usmjeravanja

U fabrici nema OSPF-a i ISIS-a (protokol usmjeravanja zabranjen u Republici Hrvatskoj).

To znači da neće biti Auto-discovery-a i izračunavanja najkraćih putanja — samo ručna (ustvari automatska — ovdje govorimo o automatizaciji) konfiguracija protokola, susjedstva i politika.

Shema usmjeravanja BGP unutar DC-a

Zašto BGP?

Na ovu temu postoji cijeli RFC ime Facebook-a i Ariste, koji objašnjavaju kako izgraditi vrlo velike mreže data centara, koristeći BGP. Čita se gotovo kao umjetnička, jako preporučujem za opušteno veče.

Također, cijeli odjeljak u mom članku posvećen je tome. Kuda vas i upučujem.

Ali ako skratim, nijedan IGP nije prikladan za mreže velikih data centara, gdje se brojevi mrežnih uređaja mjere u tisućama.

Osim toga, korištenje BGP-a svuda omogućit će da se ne raspršujemo na podršku nekoliko različitih protokola i usklađivanje između njih.

Stavljajući ruku na srce, u našoj tvornici, koja vjerojatno neće brzo rasti, bilo bi dovoljno i OSPF-a. Ovo su zapravo problemi mega-skalara i cloud titana. No, maštajmo samo nekoliko izdanja, da nam to treba, i koristit ćemo BGP, kako je nalazio Petar Lapuho.

Politike usmjeravanja

Na Leaf prekidačima uvozimo u BGP prefikse s Underlay sučelja s mrežama.
Imat ćemo BGP sesiju između svake parice Leaf-Spine, u kojoj će se ti Underlay prefiksi najavljivati kroz mrežu.

Unutar jednog data centra ćemo distribuirati specifičnosti koje smo uvezli na ToR-u. Na Edge-Leaf-ovima ćemo ih agregirati i najaviti u udaljene DC-ove i spuštati do ToR-ova. Dakle, svaki ToR će točno znati kako doći do drugog ToR-a u ovom DC-u i gdje je ulazna točka da bi stigao do ToR-a u drugom DC-u.

U DCI, rute će se prenositi kao VPNv4. Za to će na Edge-Leaf sučelju prema tvornici biti smješteno u VRF, nazovimo ga UNDERLAY, i susjedstvo sa Spine-om na Edge-Leaf-u će se podizati unutar VRF-a, dok će između Edge-Leaf-ova biti u VPNv4 obitelji.

Također ćemo zabraniti ponovno oglašavanje ruta koje smo dobili sa Spine-ova, natrag na njih.

Na Leaf i Spine nećemo uvoziti Loopback-ove. Trebat će nam samo za određivanje Router ID-a.

Na Edge-Leaf-ovima uvozimo ga u Global BGP. Između Loopback adresa, Edge-Leaf-ovi će uspostaviti BGP sesiju u IPv4 VPN obitelji jedni s drugima.

Između EDGE uređaja imat ćemo proširenu magistralu na OSPF+LDP. Sve u jednoj zoni. Izuzetno jednostavna konfiguracija.

Ovo je slika s usmjeravanjem.

BGP ASN

Edge-Leaf ASN

Na Edge-Leaf-ovima će biti jedan ASN u svim DC-ovima. To je važno kako bi između Edge-Leaf-ova bio iBGP, i da ne bi naišli na nijanse eBGP-a. Neka to bude 65535. U stvarnosti, to bi mogao biti broj javnog AS-a.

Spine ASN

Na Spine-u ćemo imati jedan ASN po DC-u. Počinjemo ovdje s prvim brojem iz raspona privatnih AS - 64512, 64513 i tako dalje.

Zašto ASN po DC-u?

Razložimo ovo pitanje na dva:

• Zašto isti ASN na svim Spine-ovima jednog DC-a?
• Zašto različiti u različitim DC-ovima?

Zašto isti ASN na svim Spine-ovima jednog DC-a

Ovako će izgledati AS-Path Underlay rute na Edge-Leaf-u:
[leafX_ASN, spine_ASN, edge_ASN]
Pri pokušaju ponovnog oglašavanja natrag na Spine, on će ga odbaciti jer je njegov AS (Spine_AS) već na popisu.

Međutim, unutar DC-a potpuno nam odgovara što Underlay rute, koje su se podigle do Edge-a, ne mogu se spustiti nazad. Sva komunikacija između hostova unutar DC-a treba se odvijati unutar razine spine.

Istovremeno, agregirane rute drugih DC-a u svakom slučaju će neometano dolaziti do ToR-ova — njihov AS-Path će sadržavati samo ASN 65535 — broj AS Edge-Leaf-ova, jer su baš na njima stvorene.

Zašto su različite u različitim DC-ima

Teoretski, može nam biti potrebno provući Loopback-ove nekih servisnih virtualnih strojeva između DC-a.

Na primjer, na hostu ćemo pokrenuti Route Reflector ili taj VNGW (Virtual Network Gateway), koji će se putem BGP-a povezati s ToR-om i objaviti svoj loopback, koji bi trebao biti dostupan iz svih DC-a.

Tako će izgledati njegov AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

I ovdje ne bi smjelo biti ponavljajućih ASN-ova.

To jest, Spine_DC1 i Spine_DC2 trebali bi biti različiti, kao i leafX_DC1 i leafY_DC2, do čega upravo dolazimo.

Kao što vjerojatno znate, postoje hackovi koji omogućuju primanje ruta s ponavljajućim ASN-ovima unatoč mehanizmu za sprečavanje petlji (allowas-in na Cisco-u). I ovo ima čak i legitiman primjena. No, to je potencijalna rupa u otpornosti mreže. I osobno sam se nekoliko puta našao u tome.

I ako imamo mogućnost ne koristiti opasne stvari, iskoristit ćemo je.

Leaf ASN

Imat ćemo individualni ASN na svakom Leaf switchu unutar cijele mreže.
Radimo to zbog razloga navedenih iznad: AS-Path bez petlji, BGP konfiguracija bez zakrpa.

Da bi rute između Leaf-ova neometano prolazile, AS-Path treba izgledati ovako:
[leafX_ASN, spine_ASN, leafY_ASN]
gdje bi leafX_ASN i leafY_ASN trebali biti različiti.

To je potrebno i za situaciju s objavom loopback-a VNF između DC-a:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Koristit ćemo 4-bajtni ASN i generirati ga na osnovu ASN Spine-a i broja Leaf switcha, i to ovako: Spine_ASN.0000X.

Ovako izgleda slika s ASN-om.

IP plan

Osnovno, trebamo dodijeliti adrese za sljedeće veze:

1. Adrese mreže Underlay između ToR-a i stroja. One moraju biti jedinstvene unutar cijele mreže, kako bi svaka mašina mogla kontaktirati svaku drugu. Odgovarajuće je 10/8. Za svaki ormar ćemo odrediti /26 s viškom. Dodijelit ćemo /19 na DC i /17 na regiju.
2. Veze između Leaf/Tor-a i Spine-a.

   Željeli bismo da se dodjeljuju algoritamski, tj. da se izračunavaju na temelju imena uređaja koji treba povezati.

   Neka to bude… 169.254.0.0/16.
   Naime 169.254.00X.Y/31, gdje X — broj Spine, Y — P2P-mreža /31.
   To će omogućiti pokretanje do 128 rackova i do 10 Spine u DC-u. Link adrese mogu (i hoće) se ponavljati iz DC-a u DC.

3. Veza između Spine i Edge-Leaf bit će organizirana na podmrežama 169.254.10X.Y/31, gdje će također X — broj Spine, Y — P2P-mreža /31.
4. Link adrese iz Edge-Leaf prema MPLS-uređaju. Ovdje je situacija malo drugačija — mjesto povezivanja svih dijelova u jednu cjelinu, stoga nismo u mogućnosti ponovo upotrijebiti iste adrese — potrebno je odabrati sljedeću slobodnu podmrežu. Stoga ćemo uzeti 192.168.0.0/16 i iz nje izvući slobodne.
5. Adrese Loopback. Dodijelit ćemo im cijeli raspon 172.16.0.0/12.
   • Leaf — po /25 na DC — to su također 128 rackova. Dodijelit ćemo po /23 za regiju.
   • Spine — po /28 na DC — do 16 Spine. Dodijelit ćemo po /26 za regiju.
   • Edge-Leaf — po /29 na DC — do 8 kutija. Dodijelit ćemo po /27 za regiju.

Ako u DC-u ne bude dovoljno dodijeljenih raspona (a neće — pretendiramo na hiperskaliranje), jednostavno dodijelimo sljedeći blok.

To je slika IP adresiranja.

Loopback-ovi:

Prefiks
Uloga uređaja
Regija
DC

172.16.0.0/23
edge
 
 

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
spine
 
 

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
leaf
 
 

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

Underlay:

Prefiks
Regija
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

Laboratorij

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

Juniper + Arista. Ubuntu. Stara dobra Eva.

Količina resursa na našoj virtualnoj mašini u Miranu je ipak ograničena, stoga ćemo za praksu koristiti ovako pojednostavljenu mrežu.

Dva data centra: Kazanj i Barcelona.

• Po dva spine u svakom: Juniper i Arista.
• Po jedan tor (Leaf) u svakom — Juniper i Arista, s jednim povezanom hostom (uzet ćemo lagani Cisco IOL za ovo).
• Po jednom čvoru Edge-Leaf (za sada samo Juniper).
• Jedan Cisco prekidač da njima svima upravlja.
• Osim mrežnih kutija pokrenuta je virtualna upravljačka mašina. Pod upravom Ubuntua.
  Ima pristup svim uređajima, na njoj će raditi IPAM/DCIM sustavi, paket Python skripti, Ansible i što god drugo što nam može zatrebati.

Potpuna konfiguracija svih mrežnih uređaja koju ćemo pokušati reproducirati pomoću automatizacije.

Zaključak

Je li to tako uobičajeno? Raditi kratak sažetak ispod svakog članka?

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

Podijelili smo mrežu na fizičku (underlay) i virtualnu (overlay). Pri tome overlay počinje od hosta — time smo pojednostavili zahtjeve za underlay.

Odabrali smo BGP kao protokol usmjeravanja anedralnih mreža zbog njegove skalabilnosti i fleksibilnosti politika.

Imat ćemo posebne čvorove za organizaciju DCI — Edge-leaf.
Na magistrali će biti OSPF+LDP.
DCI će biti implementiran na temelju MPLS L3VPN-a.
Za P2P veze IP adrese ćemo izračunavati algoritamski na temelju imena uređaja.
Loopback adrese ćemo dodjeljivati prema ulozi uređaja i njihovom rasporedu.
Underlay prefiksi — samo na Leaf prekidačima, nedvosmisleno, na temelju njihovog rasporeda.

Pretpostavimo da trenutno nemamo postavljenu opremu.
Stoga su naši sljedeći koraci — unijeti ih u sustave (IPAM, inventar), organizirati pristup, generirati konfiguraciju i implementirati je.

U sljedećem članku ćemo se baviti Netboxom — sustavom za inventar i upravljanje IP prostorom u DC-u.

Hvala

• Andreju Glazkovu aka @glazgoo za lekturu i ispravke
• Aleksandru Klimenku aka @v00lk za lekturu i ispravke
• Artemu Černobaju za KDPV

Izvor: habr.com