U prva dva članka pokrenuo sam pitanje automatizacije i skicirao njen okvir, u drugom sam se povukao u mrežnu virtualizaciju, kao prvi pristup automatizaciji konfiguracije servisa.
Sada je vrijeme da nacrtate dijagram fizičke mreže.

Ako niste upoznati s postavljanjem mreža podatkovnih centara, toplo preporučujem da počnete s članke o njima.

Sva pitanja:

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

Praksa opisana u ovoj seriji trebala bi biti primjenjiva na bilo koju vrstu mreže, bilo koje veličine, s bilo kojom raznolikošću dobavljača (ne). Međutim, nemoguće je opisati univerzalni primjer primjene ovih pristupa. Stoga ću se usredotočiti na modernu arhitekturu DC mreže: Tvornica Kloz.
Radit ćemo DCI na MPLS L3VPN.

Overlay mreža radi na vrhu fizičke mreže s glavnog računala (to može biti OpenStack VXLAN ili Tungsten Fabric ili bilo što drugo što zahtijeva samo osnovnu IP vezu s mrežom).

U ovom slučaju dobivamo relativno jednostavan scenarij za automatizaciju, jer imamo mnogo opreme koja je konfigurirana na isti način.

Izabrat ćemo sfernu istosmjernu struju u vakuumu:

• Jedna verzija dizajna posvuda.
• Dva dobavljača formiraju dvije mrežne ravnine.
• Jedan DC je kao drugi kao dva graška u mahuni.

sadržaj

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

Neka naš pružatelj usluga LAN_DC, na primjer, ugosti video zapise o preživljavanju u zaglavljenim dizalima.

U velegradovima je ovo iznimno popularno, pa vam je potrebno puno fizičkih strojeva.

Prvo ću opisati mrežu otprilike onakvu kakvu bih želio da bude. A onda ću to 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)

Unutar DC (Intra-DC)

Svi DC-ovi imaju identične interne mreže povezivanja temeljene na Clos topologiji.
Kakve su to Clos mreže i zašto su u odvojenom članak.

Svaki DC ima 10 regala sa strojevima, oni će biti numerirani kao A, B, C I tako dalje.

Svaki stalak ima 30 strojeva. Neće nas zanimati.

Također u svakom stalku postoji prekidač na koji su spojeni svi strojevi - to je Vrh Rack sklopke - ToR ili drugačije, u smislu tvornice Clos, nazvat ćemo je List.

Opći dijagram tvornice.

Pozvat ćemo ih XXX-listYGdje XXX - troslovna kratica DC, i Y - serijski broj. Na primjer, kzn-list11.

U svojim člancima dopustit ću si prilično neozbiljno koristiti pojmove Leaf i ToR kao sinonime. Međutim, moramo zapamtiti da to nije slučaj.
ToR je sklopka ugrađena u stalak na koji su spojeni strojevi.
Leaf je uloga uređaja u fizičkoj mreži ili preklopnika prve razine u smislu Cloes topologije.
To jest, Leaf != ToR.
Tako Leaf može biti EndofRaw prekidač, na primjer.
No, u okviru ovog članka ipak ćemo ih tretirati kao sinonime.

Svaki ToR prekidač je zauzvrat povezan s četiri prekidača agregacije više razine - Kičma. Jedan stalak u DC-u je dodijeljen za Spines. Nazvat ćemo ga na sličan način: XXX- kralježnicaY.

Isti stalak sadržavat će mrežnu opremu za povezivanje između DC - 2 usmjerivača s ugrađenim MPLS-om. Ali uglavnom, to su isti ToR-ovi. To jest, sa stajališta Spine prekidača, uobičajeni ToR s povezanim strojevima ili usmjerivačem za DCI uopće nije bitan - samo prosljeđivanje.

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

Izgledat će ovako.

Na gornjem dijagramu zapravo sam postavio rub i list na istu razinu. Klasične troslojne mreže Naučili su nas da uplinking (otuda i izraz) smatramo uplinkovima. I ovdje se ispostavlja da se DCI "uplink" vraća natrag, što za neke malo ruši uobičajenu logiku. U slučaju velikih mreža, kada su podatkovni centri podijeljeni na još manje jedinice - POD's (Mjesto isporuke), označite pojedinca Rub-PODza DCI i pristup vanjskim mrežama.

Radi lakše percepcije u budućnosti, i dalje ću crtati Edge over Spine, dok ćemo imati na umu da nema inteligencije na Spineu i nema razlika pri radu s običnim Leafom i Edge-leafom (iako ovdje može biti nijansi , ali općenito Ovo je istina).

Shema tvornice s rubnim listovima.

Trojstvo lista, kralježnice i ruba tvori podložnu mrežu ili tvornicu.

Zadatak mrežne tvornice (čitaj Underlay), kao što smo već definirali u zadnji broj, vrlo, vrlo jednostavno - osigurati IP povezivost između strojeva unutar istog DC-a i između njih.
Zato se mreža naziva tvornicom, kao što je npr. tvornica sklopki unutar modularnih mrežnih kutija, o čemu više možete pročitati u SDSM14.

Općenito se takva topologija naziva tvornica, jer fabric u prijevodu znači tkanina. I teško je ne složiti se:

Tvornica je potpuno L3. Nema VLAN-a, nema Broadcasta - imamo tako divne programere u LAN_DC, oni znaju pisati aplikacije koje žive u L3 paradigmi, a virtualni strojevi ne zahtijevaju Live Migration sa očuvanjem IP adrese.

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

DCI - Međusobno povezivanje podatkovnog centra (Inter-DC)

DCI će biti organiziran preko Edge-Leafa, odnosno oni su naša izlazna točka na autocestu.
Radi jednostavnosti, pretpostavljamo da su DC-ovi međusobno povezani izravnim vezama.
Isključimo vanjsku 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 štaka.
To je istina. Ipak, poanta ove serije je promišljanje i rad na pristupima, a ne herojsko rješavanje izmišljenih problema.

Na Edge-Leafs, podloga se postavlja u VPN i prenosi preko MPLS okosnice (ista izravna veza).

Ovo je dijagram najviše razine koji dobivamo.

Usmjeravanje

Za usmjeravanje unutar DC-a koristit ćemo BGP.
Na MPLS trunk OSPF+LDP.
Za DCI, odnosno organiziranje povezanosti u podzemlju - 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ćih puteva - samo ručno (zapravo automatsko - ovdje govorimo o automatizaciji) postavljanje protokola, susjedstva i pravila.

BGP shema usmjeravanja unutar DC-a

Zašto BGP?

Na ovu temu postoji cijeli RFC nazvan po Facebooku i Aristi, koji govori kako graditi vrlo velika mreže podatkovnih centara koristeći BGP. Čita se gotovo kao fikcija, toplo je preporučujem za tromo večer.

A postoji i cijeli odjeljak u mom članku posvećen ovome. Kamo da te vodim i šaljem.

Ipak, ukratko, niti jedan IGP nije prikladan za mreže velikih podatkovnih centara, gdje se broj mrežnih uređaja kreće u tisućama.

Osim toga, korištenje BGP-a posvuda omogućit će vam da ne gubite vrijeme na podržavanje nekoliko različitih protokola i sinkronizaciju među njima.

Ruku na srce, u našoj tvornici, koja s velikim stupnjem vjerojatnosti neće brzo rasti, OSPF bi bio dovoljan za oči. To su zapravo problemi megaskalera i titana oblaka. Ali zamislimo da nam treba samo za nekoliko izdanja i koristit ćemo BGP, kao što nam je Pyotr Lapukhov ostavio.

Pravila usmjeravanja

Na Leaf preklopnicima uvozimo prefikse iz Underlay mrežnih sučelja u BGP.
Imat ćemo BGP sesiju između svaki par Leaf-Spine, u kojem će se ti prefiksi Underlaya tu i tamo objaviti preko mreže.

Unutar jednog podatkovnog centra distribuirat ćemo specifikacije koje smo uvezli u ToRe. Na Edge-Leafs ćemo ih agregirati i objaviti udaljenim DC-ovima i poslati dolje TOR-ovima. To jest, svaki ToR će točno znati kako doći do drugog ToR-a u istom DC-u i gdje je ulazna točka za doći do ToR-a u drugom DC-u.

U DCI-ju, rute će se prenositi kao VPNv4. Da biste to učinili, na Edge-Leaf-u, sučelje prema tvornici bit će postavljeno u VRF, nazovimo ga UNDERLAY, a susjedstvo sa Spine na Edge-Leaf-u će se podići unutar VRF-a, a između Edge-Leaf-a u VPNv4- obitelj.

Također ćemo zabraniti ponovno objavljivanje ruta primljenih od spinesa natrag njima.

Na Leaf i Spine nećemo uvoziti povratne petlje. Potrebni su nam samo za određivanje ID-a usmjerivača.

Ali na Edge-Leafs ga uvozimo u Global BGP. Između Loopback adresa, Edge-Leafs će međusobno uspostaviti BGP sesiju u IPv4 VPN-obitelji.

Imat ćemo OSPF+LDP okosnicu između EDGE uređaja. Sve je u jednoj zoni. Izuzetno jednostavna konfiguracija.

Ovo je slika s usmjeravanjem.

BGP ASN

Rubni list ASN

Na Edge-Leafs bit će jedan ASN u svim DC-ovima. Važno je da između Edge-Leaf-ova postoji iBGP i ne zaokupljamo se nijansama eBGP-a. Neka to bude 65535. U stvarnosti bi to mogao biti broj javnog AS-a.

Kralježnica ASN

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

Zašto ASN na DC-u?

Podijelimo ovo pitanje na dva dijela:

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

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

Ovako će izgledati AS-staza Underlay rute na Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Kada ga pokušate reklamirati natrag Spineu, on će ga odbaciti jer je njegov AS (Spine_AS) već na popisu.

Međutim, unutar DC-a potpuno smo zadovoljni da se Underlay rute koje se penju do ruba neće moći spustiti. Sva komunikacija između domaćina unutar DC-a mora se odvijati unutar razine kralježnice.

U ovom slučaju, agregirane rute drugih DC-ova će u svakom slučaju lako doći do ToR-ova - njihov AS-Path će imati samo ASN 65535 - broj AS Edge-Leafs, jer su tamo stvoreni.

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

Teoretski, možda ćemo morati povući Loopback i neke servisne virtualne strojeve između DC-ova.

Na primjer, na hostu ćemo pokrenuti Route Reflector ili isti VNGW (Virtual Network Gateway), koji će se zaključati s TopR-om putem BGP-a i najaviti svoj povratni pristup, koji bi trebao biti dostupan 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.

Odnosno, Spine_DC1 i Spine_DC2 moraju biti različiti, baš kao i leafX_DC1 i leafY_DC2, čemu se upravo približavamo.

Kao što vjerojatno znate, postoje hakovi koji vam omogućuju prihvaćanje ruta s dvostrukim ASN-ovima unatoč mehanizmu za sprječavanje petlje (allowas-in na Ciscu). Čak ima i legitimnu upotrebu. Ali ovo je potencijalni jaz u stabilnosti mreže. I osobno sam par puta upao u to.

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

List ASN

Imat ćemo pojedinačni ASN na svakom Leaf preklopniku u cijeloj mreži.
To činimo iz gore navedenih razloga: AS-Path bez petlji, BGP konfiguracija bez knjižnih oznaka.

Kako bi rute između listova prolazile glatko, AS-Path 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]

Koristit ćemo 4-bajtni ASN i generirati ga na temelju Spineovog ASN-a i broja prekidača lista, naime ovako: Kralježnica_ASN.0000X.

Ovo je slika sa ASN.

IP plan

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

1. Postavite mrežne adrese između ToR-a i stroja. Oni moraju biti jedinstveni unutar cijele mreže tako da svaki stroj može komunicirati s bilo kojim drugim. Odlično pristaje 10/8. Za svaki stalak ima /26 sa rezervom. Dodijelit ćemo /19 po DC-u i /17 po regiji.
2. Povežite adrese između Leaf/Tor i Spine.

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

   Neka bude... 169.254.0.0/16.
   naime, 169.254.00X.Y/31Gdje X - Broj kičme, Y — P2P mreža /31.
   To će vam omogućiti da pokrenete do 128 regala i do 10 spinova u DC-u. Adrese veza se mogu (i hoće) ponavljati od DC do DC.

3. Organiziramo spoj Spine-Edge-Leaf na podmrežama 169.254.10X.Y/31, gdje je potpuno isto X - Broj kičme, Y — P2P mreža /31.
4. Povežite adrese od Edge-Leaf do MPLS okosnice. Ovdje je situacija nešto drugačija - mjesto gdje su svi dijelovi povezani u jednu tortu, tako da ponovno korištenje istih adresa neće raditi - trebate odabrati sljedeću slobodnu podmrežu. Stoga, uzmimo kao osnovu 192.168.0.0/16 a mi ćemo iz njega izgrabljati one slobodne.
5. Povratne adrese. Za njih dajemo cijeli asortiman 172.16.0.0/12.
   • List - /25 po DC - isto 128 regala. Dodijelit ćemo /23 po regiji.
   • Spine - /28 po DC - do 16 Spine. Dodijelimo /26 po regiji.
   • Rubni list - /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 s IP adresiranjem.

Povratne petlje:

prefiks
Uloga uređaja
Regija
ДЦ

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
ДЦ

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 prodavača. Jedna mreža. ADSM.

Juniper + Arista. Ubuntu. Dobra stara Eva.

Količina resursa na našem virtualnom poslužitelju u Mirani je još uvijek ograničena, tako da ćemo za praksu koristiti mrežu koja je pojednostavljena do krajnjih granica.

Dva podatkovna centra: Kazan i Barcelona.

• Po dvije bodlje: Juniper i Arista.
• Jedan torus (Leaf) u svakom - Juniper i Arista, s jednim povezanim hostom (uzmimo lagani Cisco IOL za ovo).
• Svaki po jedan Edge-Leaf čvor (za sada samo Juniper).
• Jedan Cisco prekidač za upravljanje svima.
• Uz mrežne kutije radi virtualni upravljački stroj. Pokretanje Ubuntua.
  Ima pristup svim uređajima, pokretat će IPAM/DCIM sustave, hrpu Python skripti, Ansible i sve ostalo što bi nam moglo trebati.

Puna konfiguracija svih mrežnih uređaja, koje ćemo pokušati reproducirati pomoću automatizacije.

Zaključak

Je li i to prihvaćeno? Trebam li ispod svakog članka napisati kratak zaključak?

Pa smo odabrali trorazinski Kloz mreža unutar DC-a, budući da očekujemo puno prometa 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 usmjeravanja za mrežne mreže zbog njegove skalabilnosti i fleksibilnosti pravila.

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

Pretpostavimo da trenutno još nemamo instaliranu opremu.
Stoga će naši sljedeći koraci biti da ih dodamo u sustave (IPAM, inventar), organiziramo pristup, generiramo konfiguraciju i implementiramo je.

U sljedećem članku bavit ćemo se Netboxom - sustavom za popis i upravljanje IP prostorom u DC-u.

Hvala vam

• Andrey Glazkov zvani @glazgoo za lekturu i ispravke
• Alexander Klimenko zvani @v00lk za lekturu i uređivanje
• Artjom Černobaj za KDPV

Izvor: www.habr.com