Kahes esimeses artiklis tõstatasin automatiseerimise teema ja visandasin selle raamistiku, teises taandusin võrgu virtualiseerimisele, mis on esimene lähenemine teenuste konfigureerimise automatiseerimisele.
Nüüd on aeg joonistada füüsilise võrgu skeem.

Kui te pole andmekeskuste võrkude seadistamisega kursis, siis soovitan tungivalt alustada artiklid nende kohta.

Kõik probleemid:

• 0. ADSM. Null osa. Planeerimine
• 1. ADSM. Esimene osa (mis on pärast nulli). Võrgu virtualiseerimine
• 2. ADSM. Teine osa. Võrgu disain

Selles seerias kirjeldatud tavad peaksid olema rakendatavad igat tüüpi võrkude, mis tahes suurusega ja erinevate tarnijate puhul (mitte). Siiski on võimatu kirjeldada universaalset näidet nende lähenemisviiside rakendamisest. Seetõttu keskendun alalisvooluvõrgu kaasaegsele arhitektuurile: Klozi tehas.
Teeme DCI MPLS L3VPN-is.

Ülekattevõrk töötab hosti füüsilise võrgu kohal (see võib olla OpenStacki VXLAN või Tungsten Fabric või mis tahes muu, mis nõuab võrgust ainult põhilist IP-ühendust).

Sel juhul saame automatiseerimiseks suhteliselt lihtsa stsenaariumi, sest meil on palju seadmeid, mis on samamoodi konfigureeritud.

Valime vaakumis sfäärilise alalisvoolu:

• Üks disainiversioon igal pool.
• Kaks müüjat, mis moodustavad kaks võrgutasandit.
• Üks DC on nagu teine ​​nagu kaks hernest kaunas.

Sisu

• Füüsiline topoloogia
• Marsruutimine
• IP-plaan
• Laba
• Järeldus
• Kasulikud lingid

Laske meie teenusepakkujal LAN_DC näiteks hostida koolitusvideoid kinnijäänud liftides ellujäämisest.

Megalinnades on see metsikult populaarne, nii et vajate palju füüsilisi masinaid.

Esiteks kirjeldan võrku ligikaudu sellisena, nagu ma sooviksin. Ja siis ma lihtsustan seda labori jaoks.

Füüsiline topoloogia

Asukohad

LAN_DC-l on 6 DC-d:

• Venemaa (RU):
  • Moskva (MSK)
  • Kaasan (kzn)

• Hispaania (SP):
  • Barcelona (bcn)
  • Malaga (mlg)

• Hiina (CN):
  • Shanghai (sha)
  • Xi'an (mõlemad)

Sees DC (intra-DC)

Kõigil alalisvooluseadmetel on identsed sisemised ühenduvusvõrgud, mis põhinevad Clos topoloogial.
Mis tüüpi Clos võrgud need on ja miks need on eraldi siit.

Igal DC-l on 10 riiulit masinatega, need nummerdatakse järgmiselt A, B, C Ja nii edasi.

Igal riiulil on 30 masinat. Nad ei huvita meid.

Samuti on igas riiulis lüliti, millega kõik masinad on ühendatud - see on Rack-lüliti ülaosa – ToR või muidu Closi tehase mõistes nimetame seda Leht.

Tehase üldskeem.

Me helistame neile XXX-lehtYKus XXX - kolmetäheline lühend DC ja Y - seerianumber. Näiteks, kzn-leht11.

Luban enda artiklites kasutada sünonüümidena üsna kergemeelselt mõisteid Leaf ja ToR. Siiski peame meeles pidama, et see pole nii.
ToR on püstikusse paigaldatud lüliti, millega on ühendatud masinad.
Leaf on seadme roll füüsilises võrgus või Cloesi topoloogias esimese taseme lüliti.
See tähendab, Leaf != ToR.
Nii et Leaf võib olla näiteks EndofRaw lüliti.
Selle artikli raames käsitleme neid siiski sünonüümidena.

Iga ToR-lüliti on omakorda ühendatud nelja kõrgema taseme koondlülitiga - Seljaosa. Üks rack DC-s on eraldatud Spinesi jaoks. Nimetame seda sarnaselt: XXX-selgY.

Sama rack sisaldab võrguseadmeid MPLS-iga DC-2 ruuterite ühendamiseks. Kuid üldiselt on need samad ToR-id. See tähendab, et Spine'i lülitite seisukohast pole tavaline ühendatud masinate või DCI ruuteriga ToR üldse oluline - lihtsalt edastamine.

Selliseid spetsiaalseid ToR-e nimetatakse Ääre-leht. Me helistame neile XXXservY.

See näeb välja selline.

Ülaltoodud diagrammil asetasin serva ja lehe tegelikult samale tasemele. Klassikalised kolmekihilised võrgud Nad õpetasid meid pidama üleslinkimist (sealt see termin pärineb) üleslinkidena. Ja siin selgub, et DCI “üleslink” läheb alla tagasi, mis mõne jaoks rikub pisut tavalist loogikat. Suurte võrkude puhul, kui andmekeskused on jagatud veelgi väiksemateks üksusteks - POD's (Point Of Delivery), tõstke esile isik Edge-PODDCI jaoks ja juurdepääsuks välistele võrkudele.

Tuleviku tajumise hõlbustamiseks joonistan siiski Edge over Spine'i, samas peame meeles, et Spine'i puhul pole intelligentsust ning tavalise Leaf'i ja Edge-leafiga töötamisel pole erinevusi (kuigi siin võib olla nüansse , kuid üldiselt See on tõsi).

Servalehtedega tehase skeem.

Leaf, Spine ja Edge kolmsus moodustavad aluskatte võrgu või tehase.

Võrgutehase (loe Underlay) ülesanne, nagu me juba aastal määratlesime viimane number, väga-väga lihtne – pakkuda IP-ühendust nii sama alalisvoolu masinate vahel kui ka nende vahel.
Seetõttu nimetatakse võrku tehaseks, nagu ka näiteks modulaarsete võrgukastide sees asuvat lülitustehast, mille kohta saate lähemalt lugeda SDSM14.

Üldiselt nimetatakse sellist topoloogiat tehaseks, kuna kangas tähendab tõlkes kangast. Ja raske on mitte nõustuda:

Tehas on täiesti L3. Ei mingit VLAN-i, ei mingit leviedastust – meil on LAN_DC-s nii suurepärased programmeerijad, nad teavad, kuidas kirjutada L3 paradigmas elavaid rakendusi ja virtuaalmasinad ei vaja IP-aadressi säilitamisega reaalajas migratsiooni.

Ja veel kord: vastus küsimusele, miks tehas ja miks L3 on eraldi siit.

DCI – andmekeskuste ühendus (inter-DC)

DCI korraldatakse Edge-Leafi abil, see tähendab, et need on meie kiirteele väljumise punktid.
Lihtsuse huvides eeldame, et DC-d on omavahel ühendatud otselinkide kaudu.
Jätame välise ühenduvuse vaatlusest välja.

Olen teadlik, et iga kord, kui ma komponendi eemaldan, lihtsustan võrku oluliselt. Ja kui me oma abstraktset võrku automatiseerime, on kõik hästi, kuid tegelikul on kargud.
See on tõsi. Selle sarja mõte on siiski mõelda ja töötada lähenemisviiside kallal, mitte aga kangelaslikult väljamõeldud probleeme lahendada.

Edge-Leafsil asetatakse aluskate VPN-i ja edastatakse MPLS-i magistraalvõrgu kaudu (sama otselink).

See on tipptaseme diagramm, mille saame.

Marsruutimine

DC-siseseks marsruutimiseks kasutame BGP-d.
MPLS pagasiruumil OSPF+LDP.
DCI jaoks, st maa-aluse ühenduvuse korraldamiseks - BGP L3VPN MPLS-i kaudu.

Üldine marsruutimisskeem

Tehases puudub OSPF ega ISIS (Vene Föderatsioonis keelatud marsruutimisprotokoll).

See tähendab, et automaatset avastamist ega lühimate teede arvutamist ei toimu – protokolli, naabruskonna ja poliitikate seadistamine toimub ainult käsitsi (tegelikult automaatselt – me räägime siin automatiseerimisest).

BGP marsruutimise skeem DC-s

Miks BGP?

Sellel teemal on kogu RFC Facebooki ja Arista nimeline, mis räägib kuidas ehitada väga suur andmekeskuste võrgud, mis kasutavad BGP-d. Loeb peaaegu nagu ilukirjandust, soovitan soojalt tuimaks õhtuks.

Ja minu artiklis on sellele pühendatud ka terve jaotis. Kuhu ma sind viin ja ma saadan.

Kuid siiski kokkuvõttes ei sobi ükski IGP suurte andmekeskuste võrkudesse, kus võrguseadmete arv ulatub tuhandetesse.

Lisaks võimaldab BGP kasutamine kõikjal mitte raisata aega mitme erineva protokolli toetamisele ja nendevahelisele sünkroonimisele.

Käsi südamel, meie tehases, mis suure tõenäosusega kiiresti ei kasva, piisaks OSPF-ist silmadele. Need on tegelikult megaskalaatorite ja pilvetitaanide probleemid. Kujutagem aga ette, et meil on seda vaja vaid mõne väljalase jaoks ja me kasutame BGP-d, nagu Pjotr ​​Lapuhhov pärandas.

Marsruutimiseeskirjad

Leaf-lülitite puhul impordime eesliited Underlay võrguliidestest BGP-sse.
Vahepeal on meil BGP seanss iga Leaf-Spine paar, milles need aluskatte eesliited siin-seal üle võrgu teatavaks tehakse.

Ühes andmekeskuses levitame ToRe-sse imporditud spetsifikatsioone. Edge-Leafsil koondame need kokku ja anname neist teada kaug-DC-dele ja saadame need alla TOR-idele. See tähendab, et iga ToR teab täpselt, kuidas pääseda teise ToR-i samas DC-s ja kus on sisenemispunkt, et jõuda teises DC-sse.

DCI-s edastatakse marsruudid VPNv4-na. Selleks paigutatakse Edge-Leafil tehasepoolne liides VRF-i, nimetagem seda ALUSKIRIks ning Spine on Edge-Leaf naabrus tõuseb VRF-is ja Edge-Leaf-ide vahel VPNv4-s. perekond.

Samuti keelame ogadest tagasi nende juurde saadud marsruutide uuesti väljakuulutamise.

Lehtedel ja lülisammastel me loopbacki ei impordi. Vajame neid ainult ruuteri ID määramiseks.

Kuid Edge-Leafsil impordime selle globaalsesse BGP-sse. Loopback-aadresside vahel loovad Edge-Leafs omavahel IPv4 VPN-perekonnas BGP-seansi.

Meil on EDGE-seadmete vahel OSPF+LDP magistraal. Kõik on ühes tsoonis. Äärmiselt lihtne konfiguratsioon.

See on marsruudiga pilt.

BGP ASN

Edge-Leaf ASN

Edge-Leafsil on kõigis DC-des üks ASN. Oluline on, et Edge-Leafide vahel oleks iBGP ja me ei takerdu eBGP nüanssidesse. Olgu selleks 65535. Tegelikkuses võib see olla avaliku AS-i number.

Lülisammas ASN

Spine'il on meil üks ASN DC kohta. Alustame siin kõige esimese numbriga era-AS-i vahemikust - 64512, 64513 ja nii edasi.

Miks ASN DC-s?

Jagame selle küsimuse kaheks:

• Miks on ASN-id ühe alalisvoolu kõigil selgroogidel ühesugused?
• Miks need on erinevates DC-des erinevad?

Miks on ühe alalisvoolu kõigil selgrool samad ASN-id?

Edge-Leafi aluskatte marsruudi AS-tee näeb välja selline:
[leafX_ASN, spine_ASN, edge_ASN]
Kui proovite seda Spine'ile tagasi reklaamida, loobub see sellest, kuna selle AS (Spine_AS) on juba loendis.

DC-s oleme aga täiesti rahul, et Edge'i tõusvad aluskatte marsruudid ei saa alla minna. Kogu suhtlus hostide vahel DC-s peab toimuma selgroo tasandil.

Sel juhul jõuavad teiste DC-de koondatud marsruudid igal juhul hõlpsasti ToR-idesse - nende AS-Path-il on ainult ASN 65535 - AS Edge-Leafide arv, sest seal need loodi.

Miks need on erinevates DC-des erinevad?

Teoreetiliselt peame võib-olla lohistama Loopbacki ja mõningaid teenindavaid virtuaalmasinaid DC-de vahel.

Näiteks käivitame hostis rakenduse Route Reflector või sama VNGW (Virtual Network Gateway), mis lukustub TopR-iga BGP kaudu ja teatab oma loopbackist, mis peaks olema juurdepääsetav kõigist DC-dest.

Nii näeb selle AS-Path välja selline:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Kusagil ei tohiks olla dubleerivaid ASN-e.

See tähendab, et Spine_DC1 ja Spine_DC2 peavad olema erinevad, täpselt nagu leafX_DC1 ja leafY_DC2, mis on täpselt see, millele me läheneme.

Nagu te ilmselt teate, on häkkimisi, mis võimaldavad teil aktsepteerida dubleeritud ASN-idega marsruute, hoolimata silmuse ennetamise mehhanismist (Cisco lubamine). Ja sellel on isegi õigustatud kasutusotstarve. Kuid see on potentsiaalne lünk võrgu stabiilsuses. Ja mina isiklikult sattusin sellesse paar korda.

Ja kui meil on võimalus ohtlikke asju mitte kasutada, siis kasutame seda ära.

Leht ASN

Meil on igal Leafi lülitil kogu võrgus individuaalne ASN.
Teeme seda ülaltoodud põhjustel: AS-Path ilma silmusteta, BGP konfiguratsioon ilma järjehoidjateta.

Selleks, et Leafsi vahelised marsruudid kulgeksid sujuvalt, peaks AS-Path välja nägema järgmine:
[leafX_ASN, spine_ASN, leafY_ASN]
kus leafX_ASN ja leafY_ASN oleks tore, et need erinevad.

See on vajalik ka olukorras, kus teatatakse VNF-i tagasilülitusest DC-de vahel:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Kasutame 4-baidist ASN-i ja genereerime selle Spine'i ASN-i ja Leaf-lüliti numbri põhjal, nimelt järgmiselt: Spine_ASN.0000X.

See on pilt ASN-iga.

IP-plaan

Põhimõtteliselt peame määrama aadressid järgmistele ühendustele:

1. Pane võrguaadressid ToR-i ja masina vahele. Need peavad olema kogu võrgus ainulaadsed, et mis tahes masin saaks teistega suhelda. Suurepärane sobivus 10/8. Iga riiuli jaoks on /26 varuga. Eraldame /19 alalisvoolu kohta ja /17 piirkonna kohta.
2. Linkige aadressid Leaf/Tor ja Spine vahel.

   Tahaks need määrata algoritmiliselt ehk arvutada välja ühendamist vajavate seadmete nimede järgi.

   Las see olla... 169.254.0.0/16.
   Nimelt 169.254.00X.Y/31Kus X - selgroo number, Y — P2P-võrk /31.
   See võimaldab teil käivitada kuni 128 riiulit ja kuni 10 spine'i DC-s. Lingi aadresse saab (ja saab) korrata DC-lt DC-le.

3. Korraldame alamvõrkudes ristmiku Spine-Edge-Leaf 169.254.10X.Y/31, kus täpselt sama X - selgroo number, Y — P2P-võrk /31.
4. Linkige aadressid Edge-Leafist MPLS-i selgroogse. Siin on olukord mõnevõrra erinev - koht, kus kõik tükid on üheks pirukaks ühendatud, nii et samade aadresside taaskasutamine ei toimi - peate valima järgmise vaba alamvõrgu. Seetõttu võtame aluseks 192.168.0.0/16 ja rehame sealt vabad välja.
5. Loopback-aadressid. Anname neile kogu valiku 172.16.0.0/12.
   • Leht - /25 DC kohta - samad 128 nagid. Piirkonnale eraldame /23.
   • Selg - /28 DC kohta - kuni 16 Selg. Eraldame /26 piirkonnale.
   • Edge-Leaf - /29 DC kohta - kuni 8 kasti. Eraldame /27 piirkonnale.

Kui meil ei ole DC-s piisavalt eraldatud vahemikke (ja neid ei tule – me väidame, et oleme hüperskaalajad), valime lihtsalt järgmise ploki.

See on IP-aadressiga pilt.

Silmused:

Eesliide
Seadme roll
Piirkond
DC

172.16.0.0/23
serv
 
 

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
mõlemad

172.16.2.0/23
selg
 
 

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
mõlemad

172.16.8.0/21
leht
 
 

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
mõlemad

Aluskate:

Eesliide
Piirkond
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
mõlemad

Laba

Kaks müüjat. Üks võrk. ADSM.

Kadakas + Arista. Ubuntu. Vana hea Eve.

Meie Miranas asuva virtuaalserveri ressursside hulk on endiselt piiratud, seega kasutame praktikaks viimse piirini lihtsustatud võrku.

Kaks andmekeskust: Kaasan ja Barcelona.

• Mõlemal kaks oga: Kadakas ja Arista.
• Üks torus (Leaf) kummaski – Juniper ja Arista, ühe ühendatud hostiga (võtame selleks kerge Cisco IOL).
• Üks Edge-Leaf sõlm (praegu ainult Juniper).
• Üks Cisco lüliti valitseb neid kõiki.
• Lisaks võrgukastidele töötab virtuaalne juhtmasin. Käitab Ubuntu.
  Sellel on juurdepääs kõikidele seadmetele, see töötab IPAM/DCIM-süsteemidega, hulga Pythoni skripte, Ansible'i ja kõike muud, mida vajame.

Täielik konfiguratsioon kõigist võrguseadmetest, mida proovime automaatika abil reprodutseerida.

Järeldus

Kas see on samuti aktsepteeritud? Kas ma peaksin iga artikli alla kirjutama lühikese järelduse?

Nii et me valisime kolmetasandiline Sulge võrk alalisvoolu sees, kuna ootame palju ida-lääne suunalist liiklust ja tahame ECMP-d.

Võrk jagunes füüsiliseks (aluskiht) ja virtuaalseks (ülekate). Samal ajal algab ülekate hostist – lihtsustades sellega aluskatte nõudeid.

Valisime BGP võrguvõrkude marsruutimisprotokolliks selle mastaapsuse ja poliitika paindlikkuse tõttu.

Meil on DCI korraldamiseks eraldi sõlmed - Edge-leaf.
Põhivõrgus on OSPF+LDP.
DCI rakendatakse MPLS L3VPN baasil.
P2P-linkide puhul arvutame IP-aadressid algoritmiliselt seadmete nimede põhjal.
Loopbackid määrame vastavalt seadmete rollile ja nende asukohale järjestikku.
Aluskatte eesliited – ainult Leaf lülititel järjestikku nende asukoha alusel.

Oletame, et praegu pole meil veel seadmeid paigaldatud.
Seetõttu on meie järgmised sammud nende lisamine süsteemidesse (IPAM, inventar), juurdepääsu korraldamine, konfiguratsiooni genereerimine ja selle juurutamine.

Järgmises artiklis käsitleme Netboxi - alalisvoolu IP-ruumi inventuuri ja haldussüsteemi.

Aitäh

• Andrey Glazkov ehk @glazgoo korrektuuri ja paranduste eest
• Aleksandr Klimenko ehk @v00lk korrektuuri ja toimetuste eest
• Artjom Tšernobay KDPV eest

Allikas: www.habr.com