U prva dva članka pokrenuo sam pitanje automatizacije i ocrtao njezin okvir; u drugom sam se osvrnuo na virtualizaciju mreže kao prvi pristup automatizaciji konfiguracije usluga.
Sada je vrijeme za crtanje dijagrama fizičke mreže.

Ako niste upoznati s umrežavanjem podatkovnih centara, toplo preporučujem da počnete s članke o njima.

Svi problemi:

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

Prakse opisane u ovoj seriji trebale bi biti primjenjive na bilo koju vrstu mreže, bilo koju veličinu i bilo koju vrstu dobavljača (ne). Međutim, nemoguće je opisati univerzalni primjer primjene ovih pristupa. Stoga ću se usredotočiti na modernu arhitekturu mreže podatkovnog centra: Tvornica Kloza.
Napravit ćemo DCI na MPLS L3VPN-u.

Prekrivajuća mreža radi preko fizičke mreže s glavnog računala (to može biti OpenStackov VXLAN ili Tungsten Fabric ili bilo što drugo što zahtijeva samo osnovnu IP povezivost s mreže).

U ovom slučaju, scenarij automatizacije bit će relativno jednostavan, jer imamo puno opreme koja je konfigurirana na isti način.

Odabrat ćemo sfernu istosmjernu struju u vakuumu:

• Jedna verzija dizajna svugdje.
• Dva dobavljača formiraju dvije mrežne ravnine.
• Jedan DC je isti kao drugi kao dva jaja u mahuni.

sadržaj

• Fizička topologija
• Usmjeravanje
• IP plan
• Laba
• Zaključak
• korisni linkovi

Recimo da naš LAN_DC pružatelj usluga nudi videozapise za obuku o preživljavanju u zaglavljenim liftovima.

U velikim gradovima ovo je nevjerojatno popularno, pa je potrebno mnogo fizičkih strojeva.

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

Fizička topologija

Lokacije

LAN_DC će imati 6 DC-ova:

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

• Španjolska (SP):
  • Barcelona (BCN)
  • Malaga (mlg)

• Kina (CN):
  • Šangaj (sha)
  • Xi'an (SIA)

Intra-DC

Svi DC-ovi imaju identične interne mreže povezivanja temeljene na Clos topologiji.
Što su Kloza mreže i zašto baš one - u zasebnom članku članak.

Svaki DC ima 10 stalaka sa strojevima, a numerirat će se na sljedeći način: A, B, C I tako dalje.

U svakom stalku ima 30 automobila. Nećemo biti zainteresirani za njih.

Također u svakom stalku nalazi se prekidač na koji su spojeni svi strojevi - to je Prekidač na vrhu racka - ToR ili drugačije, u smislu tvornice Kloz, nazvat ćemo je List.

Opći raspored tvornice.

Imenovat ćemo ih XXX-listYGdje XXX — troslovna kratica DC i Y — serijski broj. Na primjer, kzn-leaf11.

U svojim člancima dopustit ću si prilično neozbiljno korištenje pojmova Leaf i ToR kao sinonima. Međutim, važno je zapamtiti da to nije slučaj.
ToR je sklopka montirana u racku na koju su spojeni strojevi.
Leaf je uloga uređaja u fizičkoj mreži ili prekidač prve razine u smislu Clos topologije.
To jest, List != ToR.
Dakle, Leaf bi mogao biti, na primjer, EndofRaw prekidač.
Međutim, u okviru ovog članka i dalje ćemo ih tretirati kao sinonime.

Svaki ToR prekidač je pak spojen na četiri uzvodna agregacijska prekidača - KičmaZa spines je dodijeljen jedan rack po podatkovnom centru. Koristit ćemo iste konvencije imenovanja: XXX-kralježnicaY.

Isti će stalak smjestiti mrežnu opremu za međusobnu DC povezivost - dva usmjerivača s ugrađenim MPLS-om. Ali u biti, to su isti kao i ToR-ovi. Dakle, iz perspektive spinalnog preklopnika, nije važno je li riječ o običnom ToR-u s povezanim računalima ili DCI usmjerivaču - prosljeđivanje je isto.

Takvi posebni ToR-ovi nazivaju se Rubni listNazvat ćemo ih XXX-rubY.

Izgledat će ovako.

Na gornjem dijagramu sam zapravo postavio rub i list na istu razinu. Klasične troslojne mreže Naučeni smo da uzlazne veze (otuda i naziv) smatramo uzlaznim vezama. Ali ovdje se DCI-jeva "uzlazna veza" vraća prema dolje, što za neke malo remeti uobičajenu logiku. U slučaju velikih mreža, kada su podatkovni centri podijeljeni na još manje jedinice— PODMjesto isporuke ('s), istaknite odvojeno Edge-PODza DCI i pristup vanjskim mrežama.

Radi lakšeg razumijevanja, u budućnosti ću i dalje crtati Edge preko Spine-a, pri čemu ćemo imati na umu da na Spine-u nema inteligencije i da nema razlika pri radu s običnim Listom i s Edge-listom (iako ovdje mogu postojati nijanse, ali općenito je to istina).

Shematski dijagram tvornice s rubnim listovima.

Trojstvo Lista, Kičme i Ruba tvori Podlogu mrežu ili tvornicu.

Zadatak tvornice mreže (čitaj Underlay), kako smo već definirali u zadnji broj, vrlo, vrlo jednostavno - osigurati IP povezivost između strojeva i unutar istog podatkovnog centra i između njih.
Zato se mreža naziva tvornicom, baš kao, na primjer, tvornica preklopnika unutar modularnih mrežnih kutija, o kojoj možete više pročitati u SDSM14.

Općenito, ova topologija se naziva tvornica, jer "tkanina" doslovno znači "tkivo". I teško je ne složiti se:

Fabric je u potpunosti L3. Nema VLAN-ova, nema Broadcastova - toliko su divni naši programeri u LAN_DC-u; znaju kako pisati aplikacije koje se pridržavaju L3 paradigme, a virtualni strojevi ne zahtijevaju Live Migration s očuvanjem IP adrese.

I još jednom: odgovor na pitanje zašto je tvornica i zašto je L3 u zasebnom članak.

DCI - Međusobna veza podatkovnih centara (Inter-DC)

DCI će biti organiziran uz pomoć Edge-Leafa, odnosno oni su naša izlazna točka u okosnicu.
Radi jednostavnosti, pretpostavimo da su DC-ovi međusobno povezani izravnim vezama.
Isključimo vanjsku povezanost iz razmatranja.

Shvaćam da svaki put kada uklonim komponentu, značajno pojednostavljujem mrežu. Iako će sve biti u redu automatizacijom naše apstraktne mreže, u stvarnosti će se stvoriti zaobilazna rješenja.
To je istina. Ipak, cilj ove serije je razmišljati i raditi na pristupima, a ne herojski rješavati imaginarne probleme.

Na Edge-Leaf mrežama, podloga se postavlja u VPN i prenosi putem MPLS okosnice (ista izravna veza).

Ovo je shema visoke razine koja se pojavljuje.

Usmjeravanje

Za usmjeravanje unutar DC-a koristit ćemo BGP.
Na MPLS okosnici OSPF+LDP.
Za DCI, odnosno organiziranje povezivosti u podlozi, BGP L3VPN preko MPLS-a.

Opća shema usmjeravanja

U tvornici nema OSPF-a ili ISIS-a (protokol usmjeravanja zabranjen u Ruskoj Federaciji).

To znači da neće biti automatskog otkrivanja ili izračuna najkraćeg puta - samo ručna (zapravo automatska - ovdje govorimo o automatizaciji) konfiguracija protokola, susjednosti i politika.

BGP dijagram usmjeravanja unutar DC-a

Zašto BGP?

Ima nešto na ovu temu cijeli RFC nazvan po Facebooku i Aristi, koji govori kako graditi vrlo velik Mreže podatkovnih centara koje koriste BGP. Čita se gotovo kao fikcija, toplo preporučujem za opuštenu večer.

I tome je posvećen cijeli odjeljak u mom članku. Kamo vas vodim? Šaljem.

Ukratko, nijedan IGP nije prikladan za velike mreže podatkovnih centara, gdje se broj mrežnih uređaja mjeri u tisućama.

Osim toga, korištenje BGP-a svugdje će eliminirati potrebu za fokusiranjem na podršku nekoliko različitih protokola i sinkronizaciju između njih.

Iskreno, OSPF bi bio više nego dovoljan za našu tvornicu, koja najvjerojatnije neće brzo rasti. To su zaista problemi za megascalere i cloud titane. Ali pretvarajmo se da nam je potreban samo za nekoliko izdanja i koristit ćemo BGP, kako je preporučio Petr Lapukhov.

Pravila usmjeravanja

Na Leaf preklopnicima uvozimo prefikse iz Underlay sučelja s mrežama u BGP.
Imat ćemo BGP sesiju između svaki par Leaf-Spine, u kojem će se ovi Underlay prefiksi najavljivati ​​naprijed-natrag kroz mrežu.

Unutar jednog podatkovnog centra, distribuirat ćemo specifične podatke uvezene u ToR. Agregirat ćemo ih na rubnim listovima i objaviti ih udaljenim podatkovnim centrima te ih slati u ToR-ove. To znači da će svaki ToR točno znati kako doći do drugog ToR-a u istom podatkovnom centru i gdje je ulazna točka za dosezanje ToR-a u drugom podatkovnom centru.

U DCI-ju, rute će se propagirati kao VPNv4. Da bi se to postiglo, Edge-Leaf sučelje okrenuto prema tkanini bit će smješteno u VRF, nazovimo ga UNDERLAY. Susjedna veza sa Spineom na Edge-Leafu bit će promovirana unutar VRF-a i između Edge-Leafova, u VPNv4 obitelji.

Također ćemo zabraniti ponovno najavljivanje ruta primljenih od spinova natrag njima.

Nećemo uvoziti povratne petlje na Leaf i Spine. Trebat će nam samo za određivanje ID-a usmjerivača.

Uvest ćemo ga u Global BGP na Edge-Leafovima. Edge-Leafovi će uspostaviti BGP sesiju između Loopback adresa u IPv4 VPN obitelji.

Imat ćemo OSPF+LDP okosnicu razapetu između EDGE uređaja. Sve će biti u jednoj zoni. Iznimno jednostavna konfiguracija.

Ovo je slika s usmjeravanjem.

BGP ASN

ASN rubnog lista

Edge-Leafovi će imati jedan ASN na svim DC-ovima. To je važno kako bi se iBGP mogao koristiti između Edge-Leafova i kako se ne bismo zapetljali u nijanse eBGP-a. Recimo da je to 65535. U stvarnosti, to bi mogao biti javni AS broj.

Kralješnica ASN

Na Spineu ćemo imati jedan ASN po DC-u. Počnimo s prvim brojem u rasponu privatnih AS-ova - 64512, 64513 i tako dalje.

Zašto ASN na DC-u?

Podijelimo ovo pitanje na dva:

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

Zašto su ASN-ovi isti na svim spinama jednog DC-a?

Evo kako će izgledati AS-putanja Underlay rute do Edge-Leafa:
[leafX_ASN, spine_ASN, edge_ASN]
Prilikom pokušaja slanja najave Spineu, bit će odbijen jer se njegov AS (Spine_AS) već nalazi na popisu.

Međutim, unutar DC-a, savršeno smo zadovoljni što se Underlay rute koje su se uzdigle do Edgea ne mogu spustiti. Sva komunikacija između hostova unutar DC-a mora se odvijati unutar spine sloja.

Istovremeno, agregirane rute drugih DC-ova će u svakom slučaju nesmetano stići do ToR-ova - njihov AS-Path će sadržavati samo ASN 65535 - AS broj Edge-Leaf-ova, jer su tamo i kreirani.

Zašto su različiti u različitim DC-ovima?

Teoretski, možda ćemo trebati prenijeti povratne veze nekih servisnih virtualnih strojeva između kontrolera domena.

Na primjer, pokrenut ćemo Route Reflector na hostu ili taj isti VNGW (Virtualni mrežni pristupnik), koji će se povezati s ToR-om putem BGP-a i najaviti svoju povratnu petlju, koja bi trebala biti dostupna sa svih DC-ova.

Dakle, ovako će izgledati njegov AS-put:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

I nigdje ovdje ne bi trebalo biti ponavljanja ASN-ova.

To jest, Spine_DC1 i Spine_DC2 moraju biti različiti, baš kao i leafX_DC1 i leafY_DC2, što je upravo ono na što dolazimo.

Kao što vjerojatno znate, postoje hakovi koji omogućuju prihvaćanje ruta s dupliciranim ASN-ovima unatoč Ciscovom mehanizmu izbjegavanja petlji (allowas-in). I to čak ima i sasvim legitimnu upotrebu. Ali to je potencijalna sigurnosna rupa. I osobno sam u to upao nekoliko puta.

A ako imamo priliku ne koristiti opasne stvari, iskoristit ćemo je.

ASN lista

Imat ćemo jedinstveni ASN na svakom Leaf switchu u cijeloj mreži.
To radimo iz gore navedenih razloga: AS-Path bez petlji, BGP konfiguracija bez stražnjih vrata.

Kako bi se osiguralo da rute između listova teku glatko, AS-putanja trebaju izgledati ovako:
[leafX_ASN, spine_ASN, leafY_ASN]
gdje bi leafX_ASN i leafY_ASN bili bolji da su različiti.

Ovo je također potrebno za situaciju s najavom VNF povratne petlje između DC-ova:
[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 temelju Spine ASN-a i broja Leaf switcha, naime, ovako: Kralješnica_ASN.0000X.

Ovo je slika s ASN-om.

IP plan

U osnovi, moramo dodijeliti adrese za sljedeće veze:

1. Podloge mrežnih adresa između ToR-a i računala. Moraju biti jedinstvene u cijeloj mreži kako bi bilo koje računalo moglo komunicirati s bilo kojim drugim. Savršeno 10/8Svaki stalak ima /26 s rezervnim prostorom. Dodijelit ćemo /19 po podatkovnom centru i /17 po regiji.
2. Poveži adrese između Leaf/Tor i Spine.

   Željeli bismo ih dodijeliti algoritamski, odnosno izračunati ih iz naziva uređaja koje je potrebno spojiti.

   Neka bude... 169.254.0.0/16.
   naime, 169.254.00X.Y/31Gdje X — Broj kralježnice, Y — P2P mreža /31.
   To će omogućiti do 128 rackova i do 10 Spine instanci po podatkovnom centru. Adrese veza mogu se (i hoće) ponavljati od podatkovnog centra do podatkovnog centra.

3. Organiziramo spoj Spine-Edge-Leaf na podmrežama 169.254.10X.Y/31, gdje je potpuno isto X — Broj kralježnice, Y — P2P mreža /31.
4. Povežite adrese s Edge-Leaf-a na MPLS okosnicu. Ovdje je situacija donekle drugačija - to je mjesto gdje su svi dijelovi povezani u jednu tortu, tako da ponovna upotreba istih adresa nije moguća - mora se odabrati sljedeća dostupna podmreža. Stoga ćemo koristiti 192.168.0.0/16 i iz njega ćemo izvući one besplatne.
5. Loopback adrese. Cijeli raspon ćemo im posvetiti. 172.16.0.0/12.
   • List — /25 po podatkovnom centru — istih 128 rackova. Dodijelit ćemo /23 po regiji.
   • Kralješnica — /28 po DC-u — do 16 Kralješnica. Dodijelit ćemo /26 po regiji.
   • Edge-Leaf — 29 jedinica po DC-u — do 8 kutija. Dodijelit ćemo 27 jedinica po regiji.

Ako nemamo dovoljno dodijeljenih raspona u DC-u (a neće ih biti - cilj nam je hiperskaliranje), jednostavno dodijelit ćemo sljedeći blok.

Ovo je slika s IP adresiranjem.

Povratne petlje:

prefiks
Uloga uređaja
Regija
DC

172.16.0.0/23
rub
 
 

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
kičma
 
 

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

Podloga:

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

Laba

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

Smreka + Arista. UbuntuDobra stara Eva.

Količina resursa na našem virtualnom stroju u Miranu je još uvijek ograničena, pa ćemo za vježbu koristiti ovu izrazito pojednostavljenu mrežu.

Dva podatkovna centra: Kazan i Barcelona.

• Po dvije bodlje: smreka i arista.
• Po jedan torus (Leaf) u svakom - Juniper i Arista, s jednim povezanim hostom (uzmimo za ovo lagani Cisco IOL).
• Jedan čvor Edge-Leaf (zasad samo Juniper).
• Jedan Cisco preklopnik za upravljanje svima.
• Uz mrežne kutije, pokreće se i upravitelj virtualnih strojeva. Pod kontrolom Ubuntu.
  Ima pristup svim uređajima, pokretat će IPAM/DCIM sustave, hrpu Python skripti, Ansible i sve ostalo što bi nam moglo zatrebati.

Potpuna konfiguracija sve mrežne uređaje, koje ćemo pokušati reproducirati pomoću automatizacije.

Zaključak

Je li ovo ista praksa? Stavite kratki sažetak ispod svakog članka?

Dakle smo odabrali troslojni Closeova mreža unutar DC-a, budući da očekujemo puno prometa istok-zapad i želimo ECMP.

Mreža je podijeljena na fizičku (podloga) i virtualnu (prekrivanje). Prekrivanje počinje s hostom, čime su pojednostavljeni zahtjevi za podlogu.

BGP je odabran kao protokol usmjeravanja za relejne mreže zbog svoje skalabilnosti i fleksibilnosti politika.

Imat ćemo odvojene čvorove za organiziranje DCI-a - Edge-leaf.
Okosnica će imati OSPF+LDP.
DCI će biti implementiran na temelju MPLS L3VPN-a.
Za P2P veze, IP adrese ćemo izračunati algoritamski na temelju imena uređaja.
Dodijelit ćemo povratne petlje prema ulozi uređaja i njihovoj lokaciji sekvencijalno.
Podložni prefiksi - samo na Leaf prekidačima sekvencijalno na temelju njihove lokacije.

Pretpostavimo da trenutno još nemamo instaliranu opremu.
Stoga će naši sljedeći koraci biti unos u sustave (IPAM, inventar), organizacija pristupa, generiranje konfiguracije i njezina implementacija.

U sljedećem članku istražit ćemo Netbox, sustav za inventarizaciju i upravljanje IP prostorom u podatkovnim centrima.

Hvala vam

• Andreyju Glazkovu, poznatom kao @glazgoo, za lekturu i uređivanje
• Zahvaljujemo Alexanderu Klimenku, poznatom kao @v00lk, na lektoriranju i uređivanju teksta.
• Artemu Černobaju za KDPV

Izvor: www.habr.com