V prvih dveh člankih sem izpostavil problematiko avtomatizacije in orisal njen okvir, v drugem sem se umaknil v virtualizacijo omrežja, kot prvi pristop k avtomatizaciji konfiguracije storitev.
Zdaj je čas, da narišemo diagram fizičnega omrežja.

Če niste seznanjeni z nastavitvijo omrežij podatkovnih centrov, toplo priporočam, da začnete z članki o njih.

Vse težave:

• 0. ADSM. Del Zero. Načrtovanje
• 1. ADSM. Prvi del (ki je po ničli). Virtualizacija omrežja
• 2. ADSM. Drugi del. Oblikovanje omrežja

Prakse, opisane v tej seriji, bi morale biti uporabne za vse vrste omrežij, katere koli velikosti in s kakršno koli vrsto prodajalcev (ne). Nemogoče pa je opisati univerzalen primer uporabe teh pristopov. Zato se bom osredotočil na sodobno arhitekturo omrežja DC: Tovarna Kloz.
Izvedli bomo DCI na MPLS L3VPN.

Omrežje Overlay teče na vrhu fizičnega omrežja iz gostitelja (to je lahko OpenStack's VXLAN ali Tungsten Fabric ali karkoli drugega, kar zahteva samo osnovno povezljivost IP iz omrežja).

V tem primeru dobimo razmeroma preprost scenarij za avtomatizacijo, saj imamo veliko opreme, ki je konfigurirana na enak način.

Izbrali bomo sferični DC v vakuumu:

• Povsod ena različica dizajna.
• Dva prodajalca, ki tvorita dve omrežni ravnini.
• En DC je kot drugi kot dva graha v stroku.

Vsebina

• Fizična topologija
• Usmerjanje
• IP načrt
• Laba
• Zaključek
• Uporabne povezave

Naj naš ponudnik storitev LAN_DC na primer gosti videoposnetke o preživetju v zagozdenih dvigalih.

V velemestih je to izjemno priljubljeno, zato potrebujete veliko fizičnih strojev.

Najprej bom opisal omrežje približno takšno, kot bi si ga želel. In potem ga bom poenostavil za laboratorij.

Fizična topologija

Lokacije

LAN_DC bo imel 6 DC-jev:

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

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

• Kitajska (CN):
  • Šanghaj (sha)
  • Xi'an (sia)

Znotraj DC (znotraj DC)

Vsi DC-ji imajo enaka notranja povezovalna omrežja, ki temeljijo na topologiji Clos.
Kakšna Closova omrežja so in zakaj so ločena članek.

Vsak DC ima 10 stojal s stroji, oštevilčeni bodo kot A, B, C In tako naprej.

Vsako stojalo ima 30 strojev. Ne bodo nas zanimali.

Tudi v vsakem stojalu je stikalo, na katerega so priključeni vsi stroji - to je Vrh stikala Rack - ToR ali drugače, v smislu tovarne Clos, ga bomo imenovali Leaf.

Splošni diagram tovarne.

Poklicali jih bomo XXX-listYČe XXX - tričrkovna okrajšava DC, in Y - serijska številka. na primer kzn-list11.

V svojih člankih si bom dovolil izraza Leaf in ToR precej lahkomiselno uporabljati kot sopomenki. Vendar se moramo spomniti, da temu ni tako.
ToR je stikalo, nameščeno v omaro, na katero so priključeni stroji.
Leaf je vloga naprave v fizičnem omrežju ali prvonivojskega stikala v smislu topologije Cloes.
To je Leaf != ToR.
Tako je Leaf lahko na primer stikalo EndofRaw.
Vendar jih bomo v okviru tega članka še vedno obravnavali kot sinonime.

Vsako stikalo ToR je povezano s štirimi združevalnimi stikali višje ravni - Hrbtenica. Eno stojalo v DC je dodeljeno za Spines. Poimenovali ga bomo podobno: XXX-hrbtenicaY.

Isto omaro bo vsebovalo omrežno opremo za povezljivost med usmerjevalniki DC - 2 z MPLS na krovu. Toda na splošno so to isti projekti. To pomeni, da z vidika stikal Spine običajni ToR s povezanimi stroji ali usmerjevalnikom za DCI sploh ni pomemben - samo posredovanje.

Takšni posebni ToR-ji se imenujejo Robni list. Poklicali jih bomo XXX-obrobY.

Videti bo takole.

V zgornjem diagramu sem dejansko postavil rob in list na isto raven. Klasična trislojna omrežja Naučili so nas, da navzgornje povezave (od tod izraz) obravnavamo kot navzgornje povezave. In tukaj se izkaže, da se DCI "uplink" vrne navzdol, kar za nekatere nekoliko poruši običajno logiko. V primeru velikih omrežij, ko so podatkovni centri razdeljeni na še manjše enote – POD‘s (Point Of Delivery), označite posameznika Edge-PODza DCI in dostop do zunanjih omrežij.

Za lažje dojemanje v prihodnosti bom še vedno narisal Edge over Spine, pri tem pa bomo upoštevali, da na Spine ni inteligence in ni razlik pri delu z običajnim listom in robnim listom (čeprav so tukaj lahko nianse , ampak na splošno je to res).

Shema tovarne z robnimi listi.

Trojica lista, hrbtenice in roba tvori podložno mrežo ali tovarno.

Naloga mrežne tovarne (beri Underlay), kot smo že definirali v zadnja številka, zelo, zelo preprosto - zagotoviti IP povezljivost med stroji znotraj istega DC in med njimi.
Zato se omrežje imenuje tovarna, tako kot na primer stikalna tovarna znotraj modularnih omrežnih omaric, o čemer si lahko več preberete v SDSM14.

Na splošno se taka topologija imenuje tovarna, saj fabric v prevodu pomeni tkanina. In težko se je strinjati:

Tovarna je popolnoma L3. Brez VLAN-a, brez oddajanja - v LAN_DC imamo tako čudovite programerje, vedo, kako napisati aplikacije, ki živijo v paradigmi L3, in virtualni stroji ne zahtevajo Live Migration z ohranitvijo naslova IP.

In še enkrat: odgovor na vprašanje, zakaj tovarna in zakaj je L3 v ločenem članek.

DCI - povezava med podatkovnim centrom (Inter-DC)

DCI bo organiziran z Edge-Leafom, torej so naša izhodna točka na avtocesto.
Zaradi poenostavitve predpostavljamo, da so DC-ji med seboj povezani z neposrednimi povezavami.
Iz obravnave izključimo zunanjo povezljivost.

Zavedam se, da vsakič, ko odstranim komponento, močno poenostavim omrežje. In ko avtomatiziramo naše abstraktno omrežje, bo vse v redu, na pravem pa bodo bergle.
To je resnica. Vseeno je smisel te serije razmišljanje in delo na pristopih, ne pa junaško reševanje namišljenih problemov.

Na Edge-Leafs je podloga postavljena v VPN in posredovana prek hrbtenice MPLS (ista neposredna povezava).

To je diagram najvišje ravni, ki ga dobimo.

Usmerjanje

Za usmerjanje znotraj DC bomo uporabili BGP.
Na progi MPLS OSPF+LDP.
Za DCI, torej organiziranje povezljivosti v podzemlju - BGP L3VPN preko MPLS.

Splošna shema usmerjanja

V tovarni ni OSPF ali ISIS (protokol usmerjanja, prepovedan v Ruski federaciji).

To pomeni, da ne bo samodejnega odkrivanja ali izračuna najkrajših poti – samo ročna (pravzaprav avtomatska – tukaj govorimo o avtomatizaciji) nastavitev protokola, soseske in politik.

Shema usmerjanja BGP znotraj DC

Zakaj BGP?

Na to temo obstaja celoten RFC poimenovan po Facebooku in Aristi, ki pove, kako graditi zelo velika omrežja podatkovnih centrov, ki uporabljajo BGP. Bere se skoraj kot leposlovje, toplo ga priporočam za dolgočasen večer.

In temu je posvečen tudi cel razdelek v mojem članku. Kam te peljem in pošiljam.

A vseeno, skratka, noben IGP ni primeren za omrežja velikih podatkovnih centrov, kjer se število omrežnih naprav meri v tisočih.

Poleg tega vam bo uporaba BGP povsod omogočila, da ne boste izgubljali časa s podporo več različnih protokolov in sinhronizacijo med njimi.

Roko na srce, v naši tovarni, ki z veliko mero verjetnosti ne bo hitro rasla, bi bil OSPF dovolj za oči. To so pravzaprav težave megaskalerjev in titanov oblakov. Toda predstavljajmo si, da ga potrebujemo samo za nekaj izdaj, in uporabili bomo BGP, kot je zapustil Pyotr Lapukhov.

Politike usmerjanja

Na stikalih Leaf uvozimo predpone iz omrežnih vmesnikov Underlay v BGP.
Vmes bomo imeli sejo BGP vsak par Leaf-Spine, v katerem bodo te predpone Underlay objavljene po omrežju naprej in nazaj.

Znotraj enega podatkovnega centra bomo distribuirali specifikacije, ki smo jih uvozili v ToRe. Na Edge-Leafs jih bomo združili in jih objavili oddaljenim DC-jem ter jih poslali TOR-jem. To pomeni, da bo vsak ToR natančno vedel, kako priti do drugega ToR v istem DC in kje je vstopna točka za dostop do ToR v drugem DC.

V DCI se bodo poti prenašale kot VPNv4. Da bi to naredili, bo na Edge-Leaf vmesnik proti tovarni postavljen v VRF, imenujemo ga UNDERLAY, in soseska s Spine na Edge-Leaf se bo dvignila znotraj VRF in med Edge-Leafs v VPNv4- družina.

Prav tako bomo prepovedali ponovno objavo poti, prejetih od spines nazaj do njih.

Pri Leaf in Spine ne bomo uvažali povratnih zank. Potrebujemo jih samo za določitev ID-ja usmerjevalnika.

Toda na Edge-Leafs ga uvozimo v Global BGP. Med povratnimi naslovi bo Edge-Leafs med seboj vzpostavil sejo BGP v družini IPv4 VPN.

Imeli bomo hrbtenico OSPF+LDP med napravami EDGE. Vse je v eni coni. Izjemno enostavna konfiguracija.

To je slika z usmerjanjem.

BGP ASN

Edge-Leaf ASN

Edge-Leafs bodo imeli en ASN v vseh DC-jih. Pomembno je, da obstaja iBGP med Edge-Leafs in da se ne ujamemo v nianse eBGP. Naj bo 65535. V resnici bi to lahko bila številka javnega AS.

Hrbtenica ASN

Na Spine bomo imeli en ASN na DC. Začnimo tukaj s prvo številko iz obsega zasebnih AS - 64512, 64513 in tako naprej.

Zakaj ASN na DC?

Razčlenimo to vprašanje na dvoje:

• Zakaj so ASN enaki na vseh hrbtenicah enega DC?
• Zakaj se razlikujejo v različnih DC?

Zakaj so isti ASN-ji na vseh trnih enega DC?

Takole bo videti AS-pot poti Underlay na Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Ko ga poskušate oglaševati nazaj v Spine, ga bo zavrgel, ker je njegov AS (Spine_AS) že na seznamu.

Vendar pa smo znotraj DC popolnoma zadovoljni, da smeri Underlay, ki se vzpenjajo do Edge, ne bodo mogle iti navzdol. Vsa komunikacija med gostitelji znotraj DC mora potekati na ravni hrbtenice.

Hkrati bodo združene poti drugih DC-jev v vsakem primeru zlahka dosegle ToR-je - njihova AS-Path bo imela samo ASN 65535 - število AS Edge-Leafs, ker so bili tam ustvarjeni.

Zakaj se razlikujejo v različnih DC?

Teoretično bomo morda morali povleči Loopback in nekatere storitvene virtualne stroje med DC-ji.

Na primer, na gostitelju bomo pognali Route Reflector oz isti VNGW (Virtual Network Gateway), ki se bo zaklenil s TopR prek BGP in objavil svojo povratno zanko, ki bi morala biti dostopna iz vseh DC-jev.

Torej, tako bo videti njegova AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

In nikjer ne sme biti podvojenih ASN.

To pomeni, da morata biti Spine_DC1 in Spine_DC2 različna, tako kot leafX_DC1 in leafY_DC2, čemur se približujemo.

Kot verjetno veste, obstajajo vdori, ki vam omogočajo, da sprejmete poti s podvojenimi ASN kljub mehanizmu za preprečevanje zank (allowas-in pri Ciscu). In ima celo zakonito uporabo. Toda to je potencialna vrzel v stabilnosti omrežja. In osebno sem nekajkrat padel vanj.

In če imamo možnost, da ne uporabljamo nevarnih stvari, jo bomo izkoristili.

List ASN

Imeli bomo posamezen ASN na vsakem stikalu Leaf v celotnem omrežju.
To počnemo iz zgoraj navedenih razlogov: AS-Path brez zank, konfiguracija BGP brez zaznamkov.

Da bi poti med listi potekale gladko, bi morala AS-Path izgledati takole:
[leafX_ASN, spine_ASN, leafY_ASN]
kjer bi bilo lepo, če bi bila leafX_ASN in leafY_ASN različna.

To je potrebno tudi za situacijo z napovedjo povratne zanke VNF med DC-ji:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Uporabili bomo 4-bajtni ASN in ga generirali na podlagi Spine's ASN in številke stikala Leaf, in sicer takole: Hrbtenica_ASN.0000X.

To je slika z ASN.

IP načrt

V bistvu moramo dodeliti naslove za naslednje povezave:

1. Podlaga omrežne naslove med ToR in strojem. Biti morajo edinstveni v celotnem omrežju, tako da lahko kateri koli stroj komunicira s katerim koli drugim. Odlično se prilega 10/8. Vsak regal ima /26 z rezervo. Dodelili bomo /19 na DC in /17 na regijo.
2. Naslovi povezav med Leaf/Tor in Spine.

   Rad bi jih dodelil algoritemsko, torej izračunal iz imen naprav, ki jih je treba povezati.

   Naj bo ... 169.254.0.0/16.
   In sicer 169.254.00X.Y/31Če X - hrbtenična številka, Y — Omrežje P2P /31.
   To vam bo omogočilo, da zaženete do 128 stojal in do 10 bodic v DC. Naslovi povezav se lahko (in se bodo) ponavljajo od DC do DC.

3. Na podomrežjih organiziramo stičišče Spine-Edge-Leaf 169.254.10X.Y/31, kjer je popolnoma enako X - hrbtenična številka, Y — Omrežje P2P /31.
4. Povežite naslove iz Edge-Leaf v hrbtenico MPLS. Tu je situacija nekoliko drugačna - mesto, kjer so vsi kosi povezani v eno torto, zato ponovna uporaba istih naslovov ne bo delovala - morate izbrati naslednje prosto podomrežje. Zato vzemimo za osnovo 192.168.0.0/16 in iz njega bomo pobrali proste.
5. Povratni naslovi. Zanje oddamo celotno ponudbo 172.16.0.0/12.
   • Leaf - /25 na DC - enako 128 regalov. Dodelili bomo /23 na regijo.
   • Hrbtenica - /28 na DC - do 16 Hrbtenica. Dodelimo /26 na regijo.
   • Edge-Leaf - /29 na DC - do 8 škatel. Dodelimo /27 na regijo.

Če v DC nimamo dovolj dodeljenih obsegov (in jih ne bo - trdimo, da smo hiperskalerji), preprosto izberemo naslednji blok.

To je slika z naslovom IP.

Povratne zanke:

Predpona
Vloga naprave
Regija
DC

172.16.0.0/23
rob
 
 

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
hrbtenice
 
 

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

Podloga:

Predpona
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 prodajalca. Eno omrežje. ADSM.

Juniper + Arista. Ubuntu. Dobra stara Eva.

Količina sredstev na našem virtualnem strežniku v Mirani je še vedno omejena, zato bomo za prakso uporabljali do skrajnosti poenostavljeno omrežje.

Dva podatkovna centra: Kazan in Barcelona.

• Po dve bodici: Juniper in Arista.
• En torus (Leaf) v vsakem - Juniper in Arista, z enim povezanim gostiteljem (za to vzemimo lahek Cisco IOL).
• Vsak po eno vozlišče Edge-Leaf (za zdaj samo Juniper).
• Eno stikalo Cisco za upravljanje vseh.
• Poleg omrežnih omaric deluje virtualni nadzorni stroj. Poganja Ubuntu.
  Ima dostop do vseh naprav, poganjal bo sisteme IPAM/DCIM, kopico skript Python, Ansible in še vse, kar bi morda potrebovali.

Popolna konfiguracija vseh omrežnih naprav, ki jih bomo poskušali reproducirati z avtomatizacijo.

Zaključek

Je tudi to sprejeto? Ali naj pod vsakim člankom napišem kratek zaključek?

Tako smo izbrali trinivojski Omrežje Kloz znotraj DC, saj pričakujemo veliko prometa vzhod-zahod in želimo ECMP.

Omrežje je bilo razdeljeno na fizično (underlay) in virtualno (overlay). Hkrati se prekrivanje začne od gostitelja - s čimer se poenostavijo zahteve za podlogo.

Za usmerjevalni protokol za omrežna omrežja smo izbrali BGP zaradi njegove razširljivosti in prilagodljivosti pravilnika.

Imeli bomo ločena vozlišča za organiziranje DCI - Edge-leaf.
Hrbtenica bo imela OSPF+LDP.
DCI bo implementiran na podlagi MPLS L3VPN.
Za povezave P2P bomo naslove IP izračunali algoritemsko na podlagi imen naprav.
Povratne zanke bomo zaporedno dodelili glede na vlogo naprav in njihovo lokacijo.
Predpone podlage - samo na preklopih Leaf zaporedno glede na njihovo lokacijo.

Predpostavimo, da trenutno še nimamo nameščene opreme.
Zato bodo naši naslednji koraki, da jih dodamo v sisteme (IPAM, inventar), organiziramo dostop, ustvarimo konfiguracijo in jo uvedemo.

V naslednjem članku bomo obravnavali Netbox - sistem za inventar in upravljanje prostora IP v DC.

Hvala vam

• Andrej Glazkov alias @glazgoo za lektoriranje in popravke
• Alexander Klimenko alias @v00lk za lektoriranje in urejanje
• Artjom Černobaj za KDPV

Vir: www.habr.com