U prva dva članka sam pokrenuo pitanje automatizacije i skicirao njen okvir, u drugom sam se povukao u virtuelizaciju mreže, kao prvi pristup automatizaciji konfiguracije servisa.
Sada je vrijeme da nacrtamo dijagram fizičke mreže.
Ako niste upoznati sa postavljanjem mreža centara podataka, toplo preporučujem da počnete od .
Sva pitanja:
Prakse opisane u ovoj seriji trebale bi biti primjenjive na bilo koju vrstu mreže, bilo koje veličine, s bilo kojim različitim dobavljačima (ne). Međutim, nemoguće je opisati univerzalni primjer primjene ovih pristupa. Stoga ću se fokusirati na modernu arhitekturu DC mreže: .
Radit ćemo DCI na MPLS L3VPN.
Overlay mreža radi na vrhu fizičke mreže sa hosta (ovo može biti OpenStackov VXLAN ili Tungsten Fabric ili bilo šta drugo što zahtijeva samo osnovnu IP konekciju iz mreže).
U ovom slučaju dobijamo relativno jednostavan scenario za automatizaciju, jer imamo dosta opreme koja je konfigurisana na isti način.
Mi ćemo izabrati sferni DC u vakuumu:
- Jedna dizajnerska verzija svuda.
- Dva dobavljača formiraju dvije mrežne ravni.
- Jedan DC je kao drugi kao dva graška u mahuni.
Sadržaj
- Fizička topologija
- Routing
- IP plan
- Laba
- zaključak
- korisni linkovi
Neka naš serviser LAN_DC, na primjer, ugošćuje videozapise obuke o preživljavanju u zaglavljenim liftovima.
U megagradovima je ovo veoma popularno, tako da vam treba puno fizičkih mašina.
Prvo ću opisati mrežu otprilike onakvu kakvu bih želio da bude. A onda ću to pojednostaviti za laboratoriju.
Fizička topologija
Lokacije
LAN_DC će imati 6 DC-ova:
- Rusija (RU):
- Moskva (msk)
- Kazanj (kzn)
- Španija (SP):
- Barcelona (bcn)
- Malaga (mlg)
- Kina (CN):
- Šangaj (sha)
- Xi'an (sia)
Unutar DC (Intra-DC)
Svi DC-ovi imaju identične interne mreže povezivanja zasnovane na Clos topologiji.
Kakve su to Clos mreže i zašto su u zasebnoj .
Svaki DC ima 10 rekova sa mašinama, oni će biti numerisani kao A, B, C I tako dalje.
Svaki stalak ima 30 mašina. Oni nas neće zanimati.
Također u svakom stalku postoji prekidač na koji su sve mašine povezane - to je Vrh Rack prekidača - ToR ili drugačije, u smislu fabrike Clos, nazvaćemo je list.
Opšti dijagram fabrike.
Pozvaćemo ih XXX-listYgde XXX - troslovna skraćenica DC, i Y - serijski broj. Na primjer, kzn-leaf11.
U svojim člancima dozvoliću sebi da koristim termine Leaf i ToR prilično neozbiljno kao sinonime. Međutim, moramo imati na umu da to nije slučaj.
ToR je prekidač instaliran u stalak na koji su mašine povezane.
Leaf je uloga uređaja u fizičkoj mreži ili prekidača prvog nivoa u smislu Cloes topologije.
To jest, 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 sa četiri prekidača za agregaciju višeg nivoa - kičma. Jedan stalak u DC-u je dodijeljen za Spines. Nazvat ćemo ga slično: XXX-kičmaY.
Isti stalak će sadržavati mrežnu opremu za povezivanje između DC - 2 rutera sa MPLS na ploči. Ali uglavnom, ovo su isti zadaci. Odnosno, sa stanovišta Spine prekidača, uobičajeni ToR sa povezanim mašinama ili ruterom za DCI uopće nije bitan - samo prosljeđivanje.
Takvi posebni zadaci se nazivaju Rubni list. Pozvaćemo ih XXX-ivicaY.
To će izgledati ovako.
U dijagramu iznad, postavio sam ivicu i list na isti nivo. Naučili su nas da razmatramo uplink (otuda i termin) kao uplink. I ovdje se ispostavlja da se DCI “uplink” vraća nazad, što za neke malo ruši uobičajenu logiku. U slučaju velikih mreža, kada su data centri podijeljeni na još manje jedinice - Pod's (točka isporuke), označite odvojeno Edge-POD's za DCI i pristup vanjskim mrežama.
Radi lakše percepcije u budućnosti, i dalje ću crtati ivicu preko kičme, s tim da ćemo imati na umu da na kralježnici nema inteligencije i da nema razlika u radu sa regularnim listom i ivičnim listom (iako ovdje može biti nijansi , ali općenito je to istina).
Shema fabrike sa rubnim listovima.
Trojstvo lista, kičme i ivice čini podložnu mrežu ili fabriku.
Zadatak tvornice mreže (čitaj Underlay), kao što smo već definirali u , vrlo, vrlo jednostavno - osigurati IP konekciju između mašina kako unutar istog DC-a tako i između njih.
Zato se mreža naziva tvornica, baš kao, na primjer, tvornica komutatora unutar modularnih mrežnih kutija, o čemu više možete pročitati u .
Općenito, takva topologija se naziva tvornica, jer tkanina u prijevodu znači tkanina. I teško je ne složiti se:
Fabrika je u potpunosti L3. Nema VLAN-a, nema Broadcast-a - imamo tako divne programere na LAN_DC-u, oni znaju da pišu aplikacije koje žive u L3 paradigmi, a virtuelne mašine ne zahtevaju Live Migration sa očuvanjem IP adrese.
I još jednom: odgovor na pitanje zašto je fabrika i zašto je L3 u posebnom .
DCI - Interconnect centara podataka (Inter-DC)
DCI će se organizovati koristeći Edge-Leaf, odnosno oni su naša izlazna tačka na autoput.
Radi jednostavnosti, pretpostavljamo da su DC-ovi međusobno povezani direktnim vezama.
Isključimo eksternu povezanost iz razmatranja.
Svjestan sam da svaki put kada uklonim komponentu, značajno pojednostavim mrežu. A kad automatiziramo našu apstraktnu mrežu, sve će biti u redu, ali na pravoj će biti štake.
Istina je. Ipak, poenta ove serije je razmišljanje i rad na pristupima, a ne herojski rješavanje izmišljenih problema.
Na Edge-Leafs, podloga se postavlja u VPN i prenosi kroz MPLS kičmu (ista direktna veza).
Ovo je dijagram najvišeg nivoa koji dobijamo.
Routing
Za rutiranje unutar DC-a koristit ćemo BGP.
Na MPLS trank OSPF+LDP.
Za DCI, odnosno organizovanje povezivanja u podzemlju - BGP L3VPN preko MPLS-a.
Opća shema rutiranja
U fabrici ne postoji OSPF ili ISIS (protokol rutiranja zabranjen u Ruskoj Federaciji).
To znači da neće biti automatskog otkrivanja ili izračunavanja najkraćih puteva - samo ručno (zapravo automatsko - ovdje govorimo o automatizaciji) postavljanje protokola, susjedstva i politika.
BGP šema rutiranja unutar DC-a
Zašto BGP?
O ovoj temi postoji nazvan po Facebooku i Aristi, koji govori kako se graditi vrlo velike mreže data centara koji koriste BGP. Čita se skoro kao fikcija, toplo ga preporučujem za tmurno veče.
A u mom članku postoji i cijeli odjeljak posvećen tome. Gde da te odvedem i .
Ali ipak, ukratko, nijedan IGP nije pogodan za mreže velikih data centara, gdje se broj mrežnih uređaja kreće u hiljade.
Osim toga, korištenje BGP-a svugdje će vam omogućiti da ne gubite vrijeme na podršku nekoliko različitih protokola i sinhronizaciju između njih.
Ruku na srce, u našoj fabrici, koja sa velikim stepenom verovatnoće neće naglo rasti, OSPF bi bio dovoljan za oči. To su zapravo problemi megaskalera i oblačnih titana. Ali zamislimo samo za nekoliko izdanja da nam je potreban, a mi ćemo koristiti BGP, kao što je Pyotr Lapukhov zavještao.
Politika rutiranja
Na Leaf prekidačima uvozimo prefikse sa Underlay mrežnih interfejsa u BGP.
Imaćemo BGP sesiju između svaki par Leaf-Spine, u kojem će ovi Underlay prefiksi biti objavljeni preko mreže naprijed-natrag.
Unutar jednog data centra distribuirat ćemo specifikacije koje smo uvezli u ToRe. Na Edge-Leafs-u ćemo ih agregirati i najaviti udaljenim DC-ovima i poslati ih dolje u TOR-ove. Odnosno, svaki ToR će tačno znati kako doći do drugog ToR u istom DC-u i gdje je ulazna tačka da se dođe do ToR-a u drugom DC-u.
U DCI, rute će se prenositi kao VPNv4. Da bi se to uradilo, na Edge-Leaf-u, sučelje prema fabrici će biti postavljeno u VRF, nazovimo ga UNDERLAY, a susjedstvo sa Spine on Edge-Leaf će se uzdići unutar VRF-a, a između Edge-Leafs-a u VPNv4- porodica.
Također ćemo zabraniti ponovno objavljivanje ruta primljenih od kičme natrag do njih.
Na Leaf i Spine nećemo uvoziti Loopbackove. Oni nam trebaju samo da odredimo ID rutera.
Ali na Edge-Leafs ga uvozimo u Global BGP. Između Loopback adresa, Edge-Leafs će uspostaviti BGP sesiju u IPv4 VPN porodici međusobno.
Imaćemo OSPF+LDP okosnicu između EDGE uređaja. Sve je u jednoj zoni. Izuzetno jednostavna konfiguracija.
Ovo je slika sa rutiranjem.
BGP ASN
Edge-Leaf ASN
Edge-Leafs će imati jedan ASN u svim DC-ovima. Važno je da postoji iBGP između Edge-Leafs-a, i da se ne zaglavimo u nijansama eBGP-a. Neka bude 65535. U stvarnosti, ovo bi mogao biti broj javnog AS-a.
Spine ASN
Na Spineu ćemo imati jedan ASN po DC-u. Počnimo ovdje s prvim brojem iz raspona privatnog AS - 64512, 64513 i tako dalje.
Zašto ASN na DC?
Podijelimo ovo pitanje na dva:
- Zašto su ASN-ovi isti na svim spinovima jednog DC-a?
- Zašto se razlikuju u različitim DC-ima?
Zašto su isti ASN-ovi na svim spinovima jednog DC-a?
Ovako će izgledati AS-puta rute podloge na rubnom listu:
[leafX_ASN, spine_ASN, edge_ASN]
Kada pokušate da ga oglašavate nazad na Spine, on će ga odbaciti jer je njegov AS (Spine_AS) već na listi.
Međutim, unutar DC-a smo u potpunosti zadovoljni da rute Underlay koje se penju do Ivice neće moći da se spuste. Sva komunikacija između domaćina unutar DC-a mora se odvijati unutar nivoa kičme.
U ovom slučaju, agregirane rute drugih DC-ova će u svakom slučaju lako doći do ToR-ova - njihova AS-puta će sadržavati samo ASN 65535 - broj AS Edge-Leafs, jer su tamo stvoreni.
Zašto se razlikuju u različitim DC-ima?
Teoretski, možda ćemo morati da prevučemo Loopback i neke servisne virtuelne mašine između DC-ova.
Na primjer, na hostu ćemo pokrenuti Route Reflector ili (Virtual Network Gateway), koji će se zaključati sa TopR preko BGP-a i najaviti 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 ne bi trebalo biti duplih ASN-ova.
To jest, Spine_DC1 i Spine_DC2 moraju biti različiti, baš kao leafX_DC1 i leafY_DC2, što je upravo ono čemu se približavamo.
Kao što verovatno znate, postoje hakovi koji vam omogućavaju da prihvatite rute sa dupliranim ASN-ovima uprkos mehanizmu za sprečavanje petlje (allowas-in na Cisco-u). Čak ima i legitimnu upotrebu. Ali ovo je potencijalni jaz u stabilnosti mreže. I ja sam lično upao u to par puta.
A ako imamo priliku da ne koristimo opasne stvari, mi ćemo je iskoristiti.
Leaf ASN
Imat ćemo individualni ASN na svakom Leaf prekidaču u cijeloj mreži.
Ovo radimo iz gore navedenih razloga: AS-puta bez petlji, BGP konfiguracija bez oznaka.
Da bi rute između listova prolazile glatko, AS-put bi trebao izgledati ovako:
[leafX_ASN, spine_ASN, leafY_ASN]
gdje bi leafX_ASN i leafY_ASN bilo lijepo da se razlikuju.
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]
Koristićemo 4-bajtni ASN i generisati ga na osnovu ASN-a kičme i broja prekidača lista, naime, ovako: Spine_ASN.0000X.
Ovo je slika sa ASN-om.
IP plan
U osnovi, moramo dodijeliti adrese za sljedeće veze:
- Podložne mrežne adrese između ToR i mašine. Moraju biti jedinstveni unutar cijele mreže tako da bilo koja mašina može komunicirati s bilo kojom drugom. Odlično pristaje 10/8. Za svaki stalak ima /26 sa rezervom. Dodijelit ćemo /19 po DC i /17 po regiji.
- Link adrese između Leaf/Tor i Spine.
Želio bih ih algoritamski dodijeliti, odnosno izračunati ih prema nazivima uređaja koje je potrebno povezati.
Neka bude... 169.254.0.0/16.
Naime 169.254.00X.Y/31gde X - broj kičme, Y — P2P mreža /31.
Ovo će vam omogućiti da pokrenete do 128 stakova i do 10 Spine-a u DC-u. Link adrese se mogu (i hoće) ponavljati od DC do DC. - Organizujemo spoj Spine-Edge-Leaf na podmrežama 169.254.10X.Y/31, gdje potpuno isto X - broj kičme, Y — P2P mreža /31.
- Povežite adrese od Edge-Leaf do MPLS okosnice. Ovdje je situacija nešto drugačija - mjesto gdje su svi dijelovi povezani u jednu pitu, tako da ponovno korištenje istih adresa neće raditi - potrebno je odabrati sljedeću slobodnu podmrežu. Stoga, uzmimo za osnovu 192.168.0.0/16 a slobodne ćemo izvući iz njega.
- Loopback Addresses. Za njih ćemo dati cijeli asortiman 172.16.0.0/12.
- List - /25 po DC - istih 128 regala. Dodijelit ćemo /23 po regiji.
- Kičma - /28 po DC - do 16 Kičma. Dodijelimo /26 po regiji.
- Edge-Leaf - /29 po DC - do 8 kutija. Dodijelimo /27 po regiji.
Ako nemamo dovoljno dodijeljenih raspona u DC-u (a neće ih biti - tvrdimo da smo hiperskaleri), jednostavno odabiremo sljedeći blok.
Ovo je slika sa IP adresiranjem.
Loopbacks:
Prefiks
Uloga uređaja
Lokacija
DC
172.16.0.0/23
ivica
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
Lokacija
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 prodavca. Jedna mreža. ADSM.
Juniper + Arista. Ubuntu. Dobra stara Eve.
Količina resursa na našem virtuelnom serveru u Mirani je i dalje ograničena, pa ćemo za praksu koristiti mrežu koja je pojednostavljena do krajnjih granica.
Dva data centra: Kazan i Barselona.
- Po dvije bodlje: Juniper i Arista.
- Po jedan torus (Leaf) u svakom - Juniper i Arista, sa jednim povezanim hostom (uzmimo lagani Cisco IOL za ovo).
- Po jedan čvor Edge-Leaf (za sada samo Juniper).
- Jedan Cisco prekidač za upravljanje svima.
- Pored mrežnih kutija, radi i virtuelna kontrolna mašina. Pokretanje Ubuntua.
Ima pristup svim uređajima, pokretaće IPAM/DCIM sisteme, gomilu Python skripti, Ansible i sve ostalo što bi nam moglo zatrebati.
svih mrežnih uređaja, koje ćemo pokušati reproducirati pomoću automatizacije.
zaključak
Da li je i to prihvaćeno? Trebam li napisati kratak zaključak ispod svakog članka?
Pa smo izabrali Zatvaranje mreže unutar DC-a, budući da očekujemo dosta saobraćaja istok-zapad i želimo ECMP.
Mreža je podijeljena na fizičku (underlay) i virtualnu (overlay). U isto vrijeme, prekrivanje počinje od hosta - čime se pojednostavljuju zahtjevi za podlogu.
Izabrali smo BGP kao protokol rutiranja za mrežne mreže zbog njegove skalabilnosti i fleksibilnosti politike.
Imaćemo odvojene čvorove za organizovanje DCI - Edge-leaf.
Okosnica će imati OSPF+LDP.
DCI će biti implementiran na bazi MPLS L3VPN.
Za P2P veze, izračunat ćemo IP adrese algoritamski na osnovu naziva uređaja.
Dodijelit ćemo povratne petlje prema ulozi uređaja i njihovoj lokaciji uzastopno.
Podložni prefiksi - samo na Leaf prekidačima uzastopno na osnovu njihove lokacije.
Pretpostavimo da trenutno još nemamo instaliranu opremu.
Stoga će naši sljedeći koraci biti da ih dodamo u sisteme (IPAM, inventar), organiziramo pristup, generišemo konfiguraciju i postavimo je.
U sljedećem članku ćemo se pozabaviti Netboxom – sistemom za inventarizaciju i upravljanje IP prostorom u DC-u.
Hvala ti
- Andrey Glazkov aka @glazgoo za lekturu i ispravke
- Alexander Klimenko aka @v00lk za lekturu i uređivanje
- Artjom Černobaj za KDPV
izvor: www.habr.com