Esimese kahe artikli jooksul tõstsin esile automatiseerimise küsimuse ja koostasin selle raamistiku, teises tegin kõrvalepõike võrgu virtualiseerimise teemasse, kuna see on esimene lähenemine teenuste seadistamise automatiseerimisele.
Ja nüüd on aeg joonistada füüsilise võrgu skeem.

Kui te ei ole andmekeskuste võrguseadmestiku lähedane tuttav, siis soovitan tungivalt alustada artiklist nende kohta.

Kõik väljaanded:

• 0. ADSK. Nullosa. Planeerimine
• 1. ADSK. Esimene osa (mis on pärast nullosa). Võrgu virtualiseerimine
• 2. ADSK. Teine osa. Võrgu disain

Selles sarjas käsitletud praktikad peaksid olema kohaldatavad igat tüüpi, igas suuruses ja igasuguste müüjate võrkudesse (ei). Kuid universaalset näidet nende lähenemiste rakendamisest ei saa kirjeldada. Seega keskendun kaasaegsele andmekeskuste võrgu arhitektuurile: Clossi tehas.
DCI rakendame MPLS L3VPN-il.

Füüsilise võrgu kohal töötab Overlay-võrk masinast (see võib olla VXLAN OpenStackis või Tungsten Fabric või mis tahes muu, mis nõuab võrgu ainult baas IP-ühenduvust).

Sellisel juhul tekib võrreldamatult lihtne automatiseerimise stsenaarium, kuna meil on palju seadmeid, mis seadistuvad ühesuguses järjekorras.

Valime sfäärilise andmekeskuse vaakumis:

• Üks disainiversioon igal pool.
• Kaks müüjat, kes moodustavad kaks võrgu tasandit.
• Üks andmekeskus sarnaneb teisele nagu kaks tilka vett.

Sisukord

• Füüsiline topoloogia
• Marsruutimine
• IP-plaan
• Labor
• Kokkuvõte
• Kasulikud lingid

Olgu meie teenusepakkuja LAN_DC näiteks hostitud ellujäämisvideotest kinni jäänud liftides.

Suurtes linnades on see ülisuure populaarsusega, seega on füüsilisi masinaid vaja palju.

Esmalt kirjeldan võrku umbkaudu sellisena, nagu tahaks, et see välja näeks. Ja seejärel lihtsustan labori jaoks.

Füüsiline topoloogia

Asukohad

LAN_DC-l on 6 andmekeskust:

• Venemaa (RU):
  • Moskva (msk)
  • Kazan (kzn)

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

• Hiina (CN):
  • Shanghai (sha)
  • Xi'an (sia)

Andmekeskuses (Intra-DC)

Kõigis andmekeskustes on identsete sisekeerise võrkude, mis põhinevad Clossi topoloogial.
Mis on Clossi võrgud ja miks just need - eraldi artiklis.

Igas andmekeskuses 10 riiulit masinatega, neid hakatakse numereerima järgmiselt A, B, C Ja nii edasi.

Igas riiulis on 30 masinat. Need meid ei huvita.

Samuti on igas riiulis lüliti, kuhu on ühendatud kõik masinad - see on Top of the Rack switch - ToR või muidu Clossi tehase terminoloogias nimetame seda Leaf.

Üks üldine tehas.

Nimetame neid XXX-leafY, kus XXX — kolme täheline lühend DC, Y — järjekorranumber. Näiteks, kzn-leaf11.

Olen artikkelides piisavalt vabalt kasutama terminite Leaf ja ToR sünonüümidena. Kuid tuleb meeles pidada, et see nii ei ole.
ToR on rack-mount lüliti, millele on ühendatud masinad.
Leaf on seadme roll füüsilises võrgus või esimese taseme lüliti Clos topoloogias.
Seega Leaf != ToR.
Nii võib Leaf'i olla näiteks EndofRaw-lüliti.
Kuid selle artikli raames käsitleme neid siiski sünonüümidena.

Iga ToR-lüliti on omakorda ühendatud nelja kõrgema aggregaatlülitiga — Spine. Spine'idele on määratud üks rack DC-s. Nime paneme analoogselt: XXX-spineY.

Samuti seisab samas rackis võrguseade DC vahelise ühenduse jaoks — 2 ruuterit MPLS-iga. Kuid vähemasti on need samad ToR'id. Seega ei oma Spine-lülitite jaoks mingit tähtsust, kas seal on tavaline ToR koos ühendatud masinatega või ruuter DCI jaoks — mõlemad edastavad sama.

Selliseid spetsiaalseid ToR'e nimetatakse Edge-leaf. Me nimetame neid XXX-edgeY.

See näeb välja niimoodi.

Ülaltoodud skeemis on edge ja leaf tõepoolest ühel tasemel. Klassikalised kolmetasandilised võrgud on meid harjutanud vaheühendit (just sealt ka termin) pidama ülespoole suunatud linkideks. Siin aga on DCI "ülevahe" tagasi allapoole, mis mõnevõrra rikub tuttavat loogikat. Suurte võrkude korral, mil andmekeskused jagunevad veel väiksemateks üksusteks — POD’, (Point Of Delivery), määratakse eraldi Edge-POD’id DCI ja väliste võrkude juurde.

Edasiarusaamise jaoks joonistan ma siiski Edge Spine'i kohale, samas peame meeles, et Spine'l ei ole mingit intelligentsust ja erinevusi tavapäraste Leaf'ide ja Edge-leaf'ide vahel (kuigi siin võivad olla nüansid, kuid üldiselt see niimoodi on).

Skeem Edge-leaf'idega.

Kolmik Leaf, Spine ja Edge moodustavad Underlay-võrgu või tehase.

Võrgu tehase (loe Underlay) ülesanne, nagu me oleme juba määratlenud toetatud Cookies Having Independent Partitioned State (CHIPS). See põhjustas probleeme mõnede saitidega., on väga ja väga lihtne – tagada IP-ühenduse masinate vahel nii ühes DC-s kui ka nende vahel.
Seetõttu nimetatakse võrguks tehast, nagu näiteks tehase lülitust modulaarsete võrgukarbikeste sees, millest lähemalt võib lugeda SDM14.

Tegelikult nimetatakse seda topoloogiat tehaseks, kuna 'fabric' tõlkes tähendab see kangast. Ja raske on mitte nõustuda:

Tehas on täielikult L3. Pole VLAN-e, pole Broadcasti - meil on LAN_DC's imelised programmeerijad, kes oskavad kirjutada rakendusi, mis eksisteerivad L3 paradigmas, ja virtuaalmasinad ei vaja Live Migration'i IP-aadressi säilitamisega.

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

DCI - Andmekeskuste vahelise ühenduse loomine (Inter-DC)

DCI korraldatakse Edge-Leaf abil, seega nad on meie punkt, kus pääseb kiiruskaubikule.
Lihtsuse huvides eeldame, et andmekeskused on omavahel ühendatud otseühendustega.
Jätame kõrvale välist ühenduvust.

Mõistan, et iga kord, kui ma eemaldan mingi komponendi, lihtsustan ma võrku oluliselt. Ja kui meie abstraktse võrgu automatiseerimisega kõik toimib hästi, siis reaalses olukorras võivad tekkida probleemid.
See on tõsi. Ja siiski on selle seeria eesmärk mõelda ja töötada lähenemiste kallal, mitte kangesti lahendada välja mõeldud probleeme.

Edge-Leaf'idel asetatakse underlay VPN-i ja see edastatakse läbi MPLS kiiruskaubiku (see sama otseühendus).

Siin on selline kõrgetasemeline skeem.

Marsruutimine

Andmekeskuses sisedünaamiliseks marsruutimiseks kasutame BGP-d.
MPLS kiiruskaubikul OSPF+LDP.
DCI jaoks, ehkki ühenduse loomine underlay's - BGP L3VPN üle MPLS-i.

Üksikasjalik marsruutimise skeem

Tehases ei ole OSPF ega ISIS (Venemaal keelatud marsruutimisprotokoll).

See tähendab, et ei tule Auto-discovery'd ega lühimate teede arvutamist - ainult käsitsi (tõeliselt automaatselt - me räägime siin automatiseerimisest) protokolli, naabruskonna ja poliitikate seadistamine.

BGP marsruutimise skeem andmekeskuses

Miks BGP?

Selle teema kohta on kogu RFC Facebooki ja Arista nimel, kus räägitakse, kuidas ehitada väga suuri andmekeskusete võrgustikke, kasutades BGP-d. Loetav peaaegu nagu ilukirjandus, väga soovitatav igavlevale õhtule.

Ja veel üks terve jaotis minu artiklis on sellele pühendatud. Kuhu ma teid saadan pealegi.

Kuid ikkagi, kui lühidalt kokku võtta, siis ei sobi ühtegi IGP-d suurt pannes andmekeskuste võrkudesse, kus võrgu seadmeid on arvuliselt juba tuhandeid.

Lisaks võimaldab BGP-i kasutamine igal pool mitte hajuda mitme erineva protokolli toetamise ja nende vahelise sünkroonimise kohale.

Kui ausalt öelda, siis meie tehases, millel tõenäoliselt ei ole plaanis kiiresti kasvada, piisaks OSPF-st. Need on tegelikult probleemid mega-skaalajate ja pilvetiitani jaoks. Kuid oletame vaid mõne väljaande jaoks, et me vajame seda, ja kasutame BGP-d, nagu Peter Lapukhov soovitas.

Marsruutimise poliitika

Leaf-lülitites toome BGP-sse eelseadistatud eelmise jaotuse aadresse.
Meil on BGP sessioon iga paaris Leaf-Spine, kus need eelmise jaotuse aadressid avaldatakse võrgus edasi-tagasi. Ühes andmekeskuses levitame spetsiifikaid, mille oleme impordi ToR-is. Edge-Leaf-seadmetes kogume neid ja avaldame kaugetesse andmekeskustesse ning suuname ToR-idesse. Ehk iga ToR teab täpselt, kuidas jõuda teise ToR-i samas andmekeskuses ja kus on sissepääsupunkt, et jõuda ToR-i teise andmekeskusesse.

DCI-s edastatakse marsruudid nagu VPNv4. Selle jaoks paigaldame Edge-Leaf liidesest tehasesse VRF, nimetame selle UNDERLAY-ks, ja naabrus Spine'iga Edge-Leaf is tõuseb VRF-i sees, ja Edge-Leaf-ide vahel VPNv4-pere all.

Ja me keelame ka marsruutide tagasiväljaandmise, mis on saadud spiinidest.

Leaf ja Spine ei impordi Loopbacke. Need on meile vajalikud vaid Router ID määramiseks.

Aga Edge-Leaf'ides impordime selle Global BGP-sse. Edge-Leaf-ide Loopback-aadresside vahel loovad nad BGP sessiooni IPv4 VPN-family omavahel.

EDGE-seadmete vahel on meil laiendatud põhijaotus OSPF+LDP. Kõik ühes tsoonis. Eextremly lihtne konfiguratsioon.

Siin on selline pilt marsruutimisest.

BGP ASN

Edge-Leaf ASN

Edge-Leaf'ides on kõigis andmekeskustes üks ASN. See on oluline, et Edge-Leaf-ide vahel oleks iBGP, et mitte sattuda eBGP nüanssidele. Olgu see 65535. Tegelikult võiks see olla avaliku AS number.

Spine ASN

Spine-l on andmekeskuses üks ASN. Alustame siit esimese numbriga eraplaneedi surve AS-diast ja edasi 64512, 64513 jne.

Miks ASN andmekeskuses?

Lahendame selle küsimuse kaheks:

Miks on kõik spiinid ühes andmekeskuses samad ASN-id?

• Miks on erinevad erinevates andmekeskustes?
• Miks on kõik spiinid ühes andmekeskuses samad ASN-id?

Nii näeb välja AS-Path küljest olnud marsruut Edge-Leaf-seadmest:

Katsel selle taasgekehtestada Spine-is, lükkab ta selle tagasi, kuna tema AS (Spine_AS) on juba loendis.
[leafX_ASN, spine_ASN, edge_ASN]
Katses, et ta taaskäivita oma Spinal, siis see lükkab selle tagasi, kuna tema AS (Spine_AS) on juba nimekirjas.

Kuid meie DC-s oleme täiesti rahul, et Underlay marsruudid, mis on tõusnud Edge'i, ei saa alla tagasi tulla. Kõik kommunikatsioon hostide vahel DC-s peab toimuma spina tasandil.

Samal ajal jõuavad teiste DC-de ühendatud marsruudid igal juhul probleemideta ToR-ide juurde — nende AS-Pathis on ainult ASN 65535 — Edge-Leaf'id, kuna just seal need loodi.

Miks erinevad erinevates DC-des

Teoreetiliselt võib meil olla vajalik Loopback'ide tõmbamine mõnede teenuslike virtuaalmasinate vahel DC-de vahel.

Näiteks meie hostis käivitub Route Reflector või see sama VNGW (Virtuaalne Võrguvärav), mis BGP kaudu ühendatakse ToR-iga ja kuulutab välja oma loopback'i, mis peaks olema kõikidest DC-dest ligipääsetav.

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

Ja siin ei tohiks olla korduvaid ASN-e.

See tähendab, et Spine_DC1 ja Spine_DC2 peavad olema erinevad, just nagu leafX_DC1 ja leafY_DC2, mille poole me liikume.

Kuidas teate, et on olemas vahendeid, mis lubavad marsruute korduvate ASN-idega vastu võtta, vaatamata silmusete ennetamise mehhanismile (allowas-in Cisco's). Ja sellel on isegi täiesti seaduslikud rakendused. Kuid see on potentsiaalne nõrkus võrgu usaldusväärsuses. Ja ma olen isiklikult sinna paar korda kukkunud.

Ja kui meil on võimalus mitte kasutada ohtlikke asju, siis me seda teeme.

Leaf ASN

Igal Leaf lülitil üle võrgu on individuaalne ASN.
Me teeme seda eespool nimetatud põhjustel: AS-Path ilma silmusteta, BGP konfigureerimine ilma tagajärgedeta.

Kuna marsruudid Leaf'ide vahel peavad probleemideta läbima, peaks AS-Path välja nägema nii:
[leafX_ASN, spine_ASN, leafY_ASN]
kus leafX_ASN ja leafY_ASN oleksid hea, kui need erineksid.

See on vajalik ka VNF loopback'i kuulutamise olukorras DC-de vahel:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Kasutame 4-baidist ASN-i ning genereerime selle Spine'i ASN-ist ja Leaf-sõlmest numbri põhjal, nimelt nii: Spine_ASN.0000X.

Nii näeb välja ASN.

IP-plaan

Põhimõtteliselt peame eraldama aadresse järgmisteks ühendusteks:

1. Underlay võrgu aadressid ToR-i ja masina vahel. Need peavad olema unikaalsed kogu võrgu ulatuses, et iga masin saaks suhelda mis tahes teisega. Suurepärane sobivus 10/8. Iga riiuli jaoks /26 ülejääk. Jagame välja /19 DC-dele ja /17 piirkonnale.
2. Linkimis aadressid Leaf/Tor ja Spine vahel.

   Nende määramine võiks toimuda algoritmiliselt, st arvutades seadmete nimed, mida tuleb ühendada.

   Olgu see… 169.254.0.0/16.
   Nimelt 169.254.00X.Y/31, kus X — Spine’i number, Y — P2P-verk /31.
   See võimaldab käivitada kuni 128 rack’i ja kuni 10 Spine’i andmekeskuses. Linkimisadressid võivad (ja kindlasti ka korduvad) andmekeskusest andmekeskusesse.

3. Spine ja Edge-Leaf ühendame alamsaitidega 169.254.10X.Y/31, kus täpselt samuti X — Spine’i number, Y — P2P-verk /31.
4. Linkimisadressid Edge-Leaf’ist MPLS-i peamisse. Siin on olukord mõnevõrra erinev — koht, kus kõik tükid kokku tulevad, seega samu aadresse uuesti kasutada ei saa — tuleb valida järgmine vabade alamsaitide hulk. Seetõttu võtame aluseks 192.168.0.0/16 ja hakkame sealt vabade aadresside leidma.
5. Loopback-aadressid. Andke neile kogu vahemik 172.16.0.0/12.
   • Leaf — /25 andmekeskuses — samad 128 rack’i. Eraldame /23 piirkonnale.
   • Spine — /28 andmekeskuses — kuni 16 Spine’i. Eraldame /26 piirkonnale.
   • Edge-Leaf — /29 andmekeskuses — kuni 8 seadet. Eraldame /27 piirkonnale.

Kui andmekeskuses ei piisa eraldatud vahemdest (aga ei piisa — me ju pürgime hüperkalduvusesse), eraldame lihtsalt järgmise ploki.

Selline on IP-aadressimise pilt.

Loopback'id:

Prefiks
Seadme roll
Piirkond
Andmekeskus

172.16.0.0/23
edge
 
 

172.16.0.0/27
et
 

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
spine
 
 

172.16.2.0/26
et
 

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
et
 

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

Underlay:

Prefiks
Piirkond
Andmekeskus

10.0.0.0/17
et
 

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

Labor

Kaks tootjat. Üks võrk. ADSM.

Juniper + Arista. Ubuntu. Vana hea Eva.

Meie virtuaalmasina ressurssid on siiski piiratud, seega kasutame harjutamiseks sellist äärmiselt lihtsustatud võrku.

Kaks andmekeskust: Kazan ja Barcelona.

• Igas on kaks spine'i: Juniper ja Arista.
• Igas on üks Leaf — Juniper ja Arista, ühe ühendatud hostiga (võtame selleks kergekaalulise Cisco IOL'i).
• Igas on üks Edge-Leaf node (praegu ainult Juniper).
• Üks Cisco lüliti, et neid kõik juhtida.
• Lisaks võrgukarbadele töötab virtuaalne juhtimismasin. Ubuntu juhtimisel.
  Sellel on juurdepääs kõigile seadmetele, sellel töötavad IPAM/DCIM-süsteemid, hulk Python'i skripte, Ansible ja kõik muu, mis meile vajalikuks osutub.

Täielik konfiguratsioon kõikidest võrguseadmetest, mida me proovime automaatika abil taastada.

Kokkuvõte

Kas see on samuti aktsepteeritud? Kas iga artikli alla teha lühike kokkuvõte?

Nii et valisime kolme tasandilise Kloosi võrgu andmekeskuses, kuna ootame palju East-West liiklust ja soovime ECMP-d.

Jagatud võrk füüsiliseks (underlay) ja virtuaalseks (overlay). Samal ajal algab overlay hostist — seega lihtsustasime nõudeid underlayle.

Valisime BGP marsruudiprotokolliks andmecentrifugide võrkude tõttu selle skaleeritavuse ja poliitikate paindlikkuse.

Meil on DCI korraldamiseks eraldi sõlmed – Edge-leaf.
Magistralil on OSPF+LDP.
DCI rakendatakse MPLS L3VPN baasil.
P2P-ühenduste IP-aadressid arvutame seadmete nimede põhjal.
Loopback'id määrame seadmete rolli ja asukoha põhjal järjestikku.
Andmecentrifugide eelised - ainult Leaf-lülititele järjestikku nende asukoha põhjal.

Eeldame, et meil ei ole praegu seadmeid installitud.
Seepärast on meie järgmised sammud - need süsteemidesse viia (IPAM, inventuur), ligipääsu organiseerida, konfiguratsioon genereerida ja selle juurutada.

Järgmisel artiklil käsitleme Netboxi - IP-ruumi inventuurimise ja haldamise süsteemi andmecentrifugis.

Aitäh

• Andrei Glazkovile aka @glazgoo korrektuuride ja muudatuste eest
• Aleksandr Klimentkovile aka @v00lk korrektuuride ja muudatuste eest
• Artyom Chernobayle KDPV eest

Allikas: habr.com