În primele două articole am ridicat problema automatizării și am schițat cadrul acesteia, în al doilea am făcut o retragere în virtualizarea rețelei, ca primă abordare a automatizării configurației serviciilor.
Acum este timpul să desenați o diagramă a rețelei fizice.
Dacă nu sunteți familiarizat cu configurarea rețelelor de centre de date, vă recomand cu tărie să începeți cu .
Toate problemele:
Practicile descrise în această serie ar trebui să fie aplicabile oricărui tip de rețea, de orice dimensiune, cu orice varietate de furnizori (nu). Cu toate acestea, este imposibil să descriem un exemplu universal de aplicare a acestor abordări. Prin urmare, mă voi concentra pe arhitectura modernă a rețelei DC: .
Vom face DCI pe MPLS L3VPN.
O rețea Overlay rulează deasupra rețelei fizice de la gazdă (aceasta ar putea fi VXLAN OpenStack sau Tungsten Fabric sau orice altceva care necesită doar conectivitate IP de bază de la rețea).
În acest caz, obținem un scenariu relativ simplu pentru automatizare, deoarece avem o mulțime de echipamente care sunt configurate în același mod.
Vom alege un DC sferic în vid:
- O versiune de design peste tot.
- Doi furnizori care formează două planuri de rețea.
- Un DC este ca altul ca două mazăre într-o păstăie.
Conținut
- Topologie fizică
- Dirijare
- plan IP
- Laba
- Concluzie
- Link-uri utile
Permiteți furnizorului nostru de servicii LAN_DC, de exemplu, să găzduiască videoclipuri de instruire despre supraviețuirea în lifturi blocate.
În mega-orașe, acest lucru este extrem de popular, așa că aveți nevoie de o mulțime de mașini fizice.
În primul rând, voi descrie rețeaua aproximativ așa cum mi-aș dori să fie. Și apoi o voi simplifica pentru laborator.
Topologie fizică
Locații
LAN_DC va avea 6 DC-uri:
- Rusia (RU):
- Moscova (MSK)
- Kazan (KZN)
- Spania (SP):
- Barcelona (bcn)
- Malaga (MLG)
- China (CN):
- Shanghai (sha)
- Xi'an (ambii)
În interiorul DC (Intra-DC)
Toate DC-urile au rețele de conectivitate interne identice bazate pe topologia Clos.
Ce fel de rețele Clos sunt și de ce se află într-un mod separat .
Fiecare DC are 10 rafturi cu mașini, acestea vor fi numerotate ca A, B, C Și așa mai departe.
Fiecare raft are 30 de mașini. Nu ne vor interesa.
De asemenea, în fiecare rack există un comutator la care sunt conectate toate mașinile - acesta este Comutatorul de sus a rackului - ToR sau altfel, în ceea ce privește fabrica Clos, o vom numi Frunze.
Schema generală a fabricii.
Le vom chema XXX-frunzeYUnde XXX - abrevierea de trei litere DC, și Y - număr de serie. De exemplu, kzn-frunza11.
În articolele mele îmi voi permite să folosesc termenii Leaf și ToR destul de frivol ca sinonime. Cu toate acestea, trebuie să ne amintim că nu este cazul.
ToR este un comutator instalat într-un rack la care sunt conectate mașinile.
Leaf este rolul unui dispozitiv într-o rețea fizică sau un comutator de prim nivel în ceea ce privește topologia Cloes.
Adică Leaf != ToR.
Deci, Leaf poate fi un comutator EndofRaw, de exemplu.
Cu toate acestea, în cadrul acestui articol, le vom trata în continuare ca sinonime.
Fiecare comutator ToR este conectat la rândul său la patru comutatoare de agregare de nivel superior - Șira spinării. Un rack în DC este alocat pentru Spines. Îl vom numi în mod similar: XXX-coloana vertebralăY.
Același rack va conține echipamente de rețea pentru conectivitate între routerele DC - 2 cu MPLS la bord. Dar, în general, acestea sunt aceleași Termeni de referință. Adică, din punctul de vedere al comutatoarelor Spine, ToR-ul obișnuit cu mașini conectate sau un router pentru DCI nu contează deloc - doar redirecționarea.
Astfel de TdR speciale sunt numite Margine-frunză. Le vom chema XXX-margineY.
Va arata asa.
În diagrama de mai sus, am plasat de fapt marginea și frunza la același nivel. Ne-au învățat să considerăm uplinking-ul (de unde termenul) ca uplink-uri. Și aici se dovedește că „uplinkul” DCI se retrage, ceea ce pentru unii rupe ușor logica obișnuită. În cazul rețelelor mari, când centrele de date sunt împărțite în unități și mai mici - POD‘s (Punctul de livrare), evidențiați persoana Edge-PODpentru DCI și acces la rețele externe.
Pentru ușurință de percepție în viitor, voi desena în continuare Edge peste Spine, în timp ce vom reține că nu există inteligență pe Spine și nu există diferențe atunci când lucrați cu Leaf și Edge-leaf obișnuite (deși pot exista nuanțe aici , dar în general Acest lucru este adevărat).
Schema unei fabrici cu frunze marginale.
Treimea de frunze, coloana vertebrală și margine formează o rețea sau o fabrică.
Sarcina unei fabrici de rețea (a se citi Underlay), așa cum am definit deja în , foarte, foarte simplu - pentru a oferi conectivitate IP între mașini atât în cadrul aceluiași DC, cât și între ele.
De aceea, rețeaua se numește fabrică, la fel ca, de exemplu, o fabrică de comutație în interiorul cutiilor de rețea modulare, despre care puteți citi mai multe în .
În general, o astfel de topologie se numește fabrică, deoarece țesătură în traducere înseamnă țesătură. Și e greu să fii de acord:
Fabrica este complet L3. Fără VLAN, fără Broadcast - avem astfel de programatori minunați la LAN_DC, ei știu să scrie aplicații care trăiesc în paradigma L3, iar mașinile virtuale nu necesită Live Migration cu păstrarea adresei IP.
Și încă o dată: răspunsul la întrebarea de ce fabrica și de ce L3 este separat .
DCI - Interconectarea centrului de date (Inter-DC)
DCI va fi organizat folosind Edge-Leaf, adică sunt punctul nostru de ieșire către autostradă.
Pentru simplitate, presupunem că DC-urile sunt conectate între ele prin legături directe.
Să excludem conectivitatea externă din considerare.
Sunt conștient că de fiecare dată când elimin o componentă, simplific semnificativ rețeaua. Și când ne automatizăm rețeaua abstractă, totul va fi bine, dar pe cea reală vor fi cârje.
Asta este adevărat. Totuși, scopul acestei serii este de a gândi și de a lucra la abordări, nu de a rezolva eroic probleme imaginare.
Pe Edge-Leafs, stratul de bază este plasat în VPN și transmis prin coloana vertebrală MPLS (aceeași legătură directă).
Aceasta este diagrama de nivel superior pe care o obținem.
Dirijare
Pentru rutarea în DC vom folosi BGP.
Pe trunchiul MPLS OSPF+LDP.
Pentru DCI, adică organizarea conectivității în subteran - BGP L3VPN peste MPLS.
Schema generală de rutare
Nu există OSPF sau ISIS (protocol de rutare interzis în Federația Rusă) în fabrică.
Aceasta înseamnă că nu va exista Auto-descoperire sau calcul al celor mai scurte căi - doar manual (de fapt automat - vorbim aici despre automatizare) configurarea protocolului, vecinătății și politicilor.
Schema de rutare BGP în DC
De ce BGP?
Pe acest subiect există numit după Facebook și Arista, care spune cum să construiești foarte larg rețelele de centre de date folosind BGP. Se citește aproape ca o ficțiune, o recomand cu căldură pentru o seară lângă.
Și există și o întreagă secțiune în articolul meu dedicată acestui lucru. Unde te duc și .
Dar, pe scurt, niciun IGP nu este potrivit pentru rețelele de centre de date mari, unde numărul de dispozitive de rețea se ridică la mii.
În plus, utilizarea BGP peste tot vă va permite să nu pierdeți timpul cu suportarea mai multor protocoale diferite și sincronizarea între ele.
Mâna pe inimă, în fabrica noastră, care cu un grad mare de probabilitate nu va crește rapid, OSPF ar fi suficient pentru ochi. Acestea sunt de fapt problemele megascalers și ale titanilor din nor. Dar să ne imaginăm doar pentru câteva versiuni că avem nevoie de el și vom folosi BGP, așa cum a lăsat moștenire Pyotr Lapukhov.
Politici de rutare
Pe comutatoarele Leaf, importăm prefixele din interfețele de rețea Underlay în BGP.
Vom avea o sesiune BGP între fiecare o pereche Leaf-Spine, în care aceste prefixe Underlay vor fi anunțate prin rețea înainte și înapoi.
Într-un singur centru de date, vom distribui specificațiile pe care le-am importat în ToRe. Pe Edge-Leafs le vom agrega și le vom anunța DC la distanță și le vom trimite către TOR. Adică, fiecare ToR va ști exact cum să ajungă la un alt ToR din același DC și unde este punctul de intrare pentru a ajunge la ToR într-un alt DC.
În DCI, rutele vor fi transmise ca VPNv4. Pentru a face acest lucru, pe Edge-Leaf, interfața către fabrică va fi plasată într-un VRF, să-i spunem UNDERLAY, iar vecinătatea cu Spine pe Edge-Leaf se va ridica în cadrul VRF, iar între Edge-Leafs în VPNv4- familie.
De asemenea, vom interzice reanunțarea rutelor primite de la spini înapoi către ei.
Pe Leaf și Spine nu vom importa Loopback-uri. Avem nevoie de ei doar pentru a determina ID-ul routerului.
Dar pe Edge-Leafs îl importăm în Global BGP. Între adresele Loopback, Edge-Leafs va stabili o sesiune BGP în familia VPN IPv4 între ele.
Vom avea o coloană vertebrală OSPF+LDP între dispozitivele EDGE. Totul este într-o zonă. Configurare extrem de simplă.
Aceasta este poza cu rutare.
BGP ASN
Edge-Leaf ASN
Edge-Leafs va avea un ASN în toate DC-urile. Este important să existe iBGP între Edge-Leafs și să nu fim prinși în nuanțele eBGP. Să fie 65535. În realitate, acesta ar putea fi numărul unui AS public.
Coloana vertebrală ASN
Pe Spine vom avea un ASN per DC. Să începem aici cu primul număr din gama de AS privat - 64512, 64513 și așa mai departe.
De ce ASN pe DC?
Să împărțim această întrebare în două:
- De ce ASN-urile sunt aceleași pe toate coloanele unui DC?
- De ce sunt diferite în diferite DC?
De ce sunt aceleași ASN-uri pe toate coloanele unui DC?
Iată cum va arăta AS-Path-ul traseului Underlay pe Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Când încercați să îl faceți reclamă înapoi la Spine, îl va renunța deoarece AS-ul său (Spine_AS) este deja în listă.
Totuși, în cadrul DC suntem pe deplin mulțumiți că rutele Underlay care urcă spre Edge nu vor putea coborî. Toată comunicarea dintre gazde din DC trebuie să aibă loc la nivelul coloanei vertebrale.
În același timp, rutele agregate ale altor DC vor ajunge în orice caz cu ușurință la ToR - AS-Path-ul lor va avea doar ASN 65535 - numărul de AS Edge-Leafs, pentru că acolo au fost create.
De ce sunt diferite în diferite DC?
Teoretic, ar putea fi nevoie să tragem Loopback și unele mașini virtuale de servicii între DC-uri.
De exemplu, pe gazdă vom rula Route Reflector sau (Virtual Network Gateway), care se va bloca cu TopR prin BGP și își va anunța loopback-ul, care ar trebui să fie accesibil de la toate DC-urile.
Deci, așa va arăta AS-Path-ul său:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Și nu ar trebui să existe ASN-uri duplicat nicăieri.
Adică, Spine_DC1 și Spine_DC2 trebuie să fie diferite, la fel ca leafX_DC1 și leafY_DC2, care este exact ceea ce ne apropiem.
După cum probabil știți, există hack-uri care vă permit să acceptați rute cu ASN-uri duplicate, în ciuda mecanismului de prevenire a buclei (permis-in pe Cisco). Și chiar are utilizări legitime. Dar acesta este un potențial decalaj în stabilitatea rețelei. Și eu personal am căzut în asta de câteva ori.
Și dacă avem ocazia să nu folosim lucruri periculoase, vom profita de ea.
Frunza ASN
Vom avea un ASN individual pe fiecare comutator Leaf din întreaga rețea.
Facem acest lucru din motivele prezentate mai sus: AS-Path fără bucle, configurație BGP fără marcaje.
Pentru ca rutele dintre Leafs să treacă fără probleme, AS-Path ar trebui să arate astfel:
[leafX_ASN, spine_ASN, leafY_ASN]
unde leafX_ASN și leafY_ASN ar fi bine să fie diferite.
Acest lucru este necesar și pentru situația cu anunțul unui loopback VNF între DC-uri:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
Vom folosi un ASN de 4 octeți și îl vom genera pe baza ASN-ului Spine și a numărului comutatorului Leaf, și anume, astfel: Spine_ASN.0000X.
Aceasta este poza cu ASN.
plan IP
În principiu, trebuie să alocăm adrese pentru următoarele conexiuni:
- Subpuneți adresele de rețea între ToR și mașină. Ele trebuie să fie unice în întreaga rețea, astfel încât orice mașină să poată comunica cu oricare alta. Potrivire excelentă 10/8. Pentru fiecare rack sunt /26 cu o rezerva. Vom aloca /19 per DC și /17 pe regiune.
- Adrese de legătură între Leaf/Tor și Spine.
Aș dori să le atribui algoritmic, adică să le calculez din numele dispozitivelor care trebuie conectate.
Să fie... 169.254.0.0/16.
și anume, 169.254.00X.Y/31Unde X - numărul coloanei vertebrale, Y — Rețea P2P /31.
Acest lucru vă va permite să lansați până la 128 de rafturi și până la 10 spine în DC. Adresele linkurilor pot (și vor) fi repetate de la DC la DC. - Organizăm joncțiunea Spine-Edge-Leaf pe subrețele 169.254.10X.Y/31, unde exact la fel X - numărul coloanei vertebrale, Y — Rețea P2P /31.
- Conectați adresele de la Edge-Leaf la coloana vertebrală MPLS. Aici situația este oarecum diferită - locul în care toate piesele sunt conectate într-o singură placă, deci reutilizarea acelorași adrese nu va funcționa - trebuie să selectați următoarea subrețea liberă. Prin urmare, să luăm ca bază 192.168.0.0/16 iar noi îi vom scoate pe cei liberi din el.
- Adrese Loopback. Vom oferi întreaga gamă pentru ei 172.16.0.0/12.
- Leaf - /25 per DC - aceleași 128 de rafturi. Vom aloca /23 pe regiune.
- Spine - /28 per DC - până la 16 Spine. Să alocăm /26 pe regiune.
- Edge-Leaf - /29 per DC - până la 8 cutii. Să alocăm /27 pe regiune.
Dacă nu avem suficiente intervale alocate în DC (și nu vor exista - pretindem că suntem hiperscaleri), pur și simplu selectăm următorul bloc.
Aceasta este poza cu adresa IP.
Loopback:
prefix
Rolul dispozitivului
Regiune
DC
172.16.0.0/23
margine
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
ambii
172.16.2.0/23
coloană vertebrală
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
ambii
172.16.8.0/21
frunze
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
ambii
Underlay:
prefix
Regiune
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
ambii
Laba
Doi vânzători. O singură rețea. ADSM.
Juniper + Arista. Ubuntu. Bună Eve bătrână.
Cantitatea de resurse de pe serverul nostru virtual din Mirana este încă limitată, așa că pentru practică vom folosi o rețea simplificată la limită.
Două centre de date: Kazan și Barcelona.
- Câte doi spini: Ienupăr și Arista.
- Câte un torus (frunză) în fiecare - Juniper și Arista, cu o gazdă conectată (să luăm o IOL Cisco ușoară pentru asta).
- Câte un nod Edge-Leaf fiecare (deocamdată doar Juniper).
- Un comutator Cisco pentru a le guverna pe toate.
- În plus față de cutiile de rețea, rulează o mașină de control virtuală. Rulează Ubuntu.
Are acces la toate dispozitivele, va rula sisteme IPAM/DCIM, o grămadă de scripturi Python, Ansible și orice altceva am putea avea nevoie.
a tuturor dispozitivelor din rețea, pe care vom încerca să le reproducem folosind automatizare.
Concluzie
Se accepta si asta? Ar trebui să scriu o scurtă concluzie sub fiecare articol?
Așa că am ales Rețeaua Kloz în interiorul DC, deoarece ne așteptăm la mult trafic Est-Vest și vrem ECMP.
Rețeaua a fost împărțită în fizică (sublay) și virtuală (overlay). În același timp, suprapunerea începe de la gazdă - simplificând astfel cerințele pentru substrat.
Am ales BGP ca protocol de rutare pentru rețelele de rețea pentru scalabilitatea și flexibilitatea politicii sale.
Vom avea noduri separate pentru organizarea DCI - Edge-leaf.
Coloana vertebrală va avea OSPF+LDP.
DCI va fi implementat pe baza MPLS L3VPN.
Pentru legăturile P2P, vom calcula adresele IP algoritmic pe baza numelor dispozitivelor.
Vom atribui loopback-uri în funcție de rolul dispozitivelor și locația lor secvenţial.
Prefixe de bază - numai pe comutatoarele Leaf secvenţial în funcţie de locaţia lor.
Să presupunem că acum nu avem echipamentul instalat.
Prin urmare, următorii pași vor fi să le adăugăm la sisteme (IPAM, inventar), să organizăm accesul, să generăm o configurație și să o implementăm.
În articolul următor ne vom ocupa de Netbox - un sistem de inventariere și management pentru spațiul IP într-un DC.
Mulțumesc
- Andrey Glazkov aka @glazgoo pentru corecturi și corecții
- Alexander Klimenko aka @v00lk pentru corecturi și editări
- Artyom Chernobay pentru KDPV
Sursa: www.habr.com