Kaks artiklit tagasi tõstsin esile automatiseerimise teema ja visandasin selle raamistiku. Teises tegin lühikese kõrvalepõike võrgu virtualiseerimisse, kui esimesse lähenemisse teenuste seadistamiseks automatiseerimise kaudu.
Nüüd on aeg joonistada välja füüsilise võrgu skeem.

Kui teil ei ole piisavalt kogemusi andmekeskuste seadmetega, soovitan tungivalt alustada siit. artiklist nende kohta..

Kõik väljaanded:

• 0. ADVM. Nullosa. Planeerimine
• 1. ADVM. Esimene osa (mis järgneb nullosale). Võrgu virtualiseerimine
• 2. ADVM. Teine osa. Võrgu disain

Selles seerias kirjeldatud praktikad peaksid olema kohaldatavad mis tahes tüüpi, suurusega võrku, olenemata tootjatest (ei). Siiski ei saa kirjeldada universaalset näidet nende lähenemiste rakendamiseks. Seetõttu keskendun kaasaegsele andmekeskuse võrgu arhitektuurile: Closuri tehasele..
DCI teeme MPLS L3VPN-l.

Füüsilise võrgu kohal töötab Overlay-võrk, mis on hostist (see võib olla OpenStack'i VXLAN või Tungsten Fabric või midagi muud, mis nõuab võrgu põhisisese IP-ühendust).

Sel juhul on automatiseerimiseks suhteliselt lihtne stsenaarium, kuna meil on palju seadmeid, mis seadistuvad ühtemoodi.

Valime sfäärilise andmekeskuse vaakumis:

• Üks disainiversioon igas kohas.
• Kaks vendorit, moodustades kaks võrgu tasandit.
• Üks andmekeskus sarnaneb teisele nagu kaks tilka vett.

Sisu

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

Las meie teenusepakkuja LAN_DC näiteks korraldab üleelamisvideote hostimist kinni jäänud liftides.

Suurtes linnades on see uskumatult populaarne, seega on vaja palju füüsilisi masinaid.

Esmalt kirjeldan võrku sellisena, nagu ma sooviksin seda näha. Seejärel lihtsustan laboris.

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)

Andmekeskuse vahel (Intra-DC)

Kõigis andmekeskustes on identsed sisevõrgud, mis põhinevad Clos'i topoloogial.
Mis on Clos'i võrgud ja miks just need - sellest räägime eraldi. artiklis.

Igas andmekeskuses on 10 riiulit masinatega, neid numeeritakse nagu A, B, C Ja nii edasi.

Igas riiulis on 30 masinat. Need meid ei huvita.

Igas rack'is on lüliti, kuhu on ühendatud kõik masinad — see on Racki pealüliti — ToR või nagu Clozi tehase terminoloogias nimetame seda Leaf.

Üldine skeem tehast.

Nimetame neid XXX-leafY, kus XXX — kolme tähega lühend andmekeskuse kohta ja Y — järjestusnumber. Näiteks, kzn-leaf11.

Oma artiklites luban endale suhteliselt vabalt kasutada termineid Leaf ja ToR sünonüümidena. Siiski, tuleb meeles pidada, et see ei ole õige.
ToR on rackis paigaldatud lüliti, kuhu on ühendatud masinad.
Leaf on seadme roll füüsilises võrgus või Clozi topoloogia esmaklassiline lüliti.
Seega Leaf != ToR.
Leaf'ina võib olla näiteks EndofRaw-lüliti.
Kuid käesolevas artiklis käsitleme neid siiski sünonüümidena.

Iga ToR-lüliti on omakorda ühendatud nelja kõrgema taseme agregaatlülitiga — Spine. Spine'ide jaoks on igas andmekeskuses eraldatud üks rack. Nimetame neid sarnaselt: XXX-spineY.

Samas rack'is asub tugiseadmed DC-vaheühendamiseks — kaks marsruuterit MPLS-iga. Aga suure pildi puhul on need samad ToR-id. See tähendab, et Spine-lülitite vaatenurgast ei muuda midagi, kas seal on tavaline ToR, kuhu on ühendatud masinad, või DCI jaoks mõeldud marsruuter — mõlemal juhul on see edasi suunamine.

Need spetsiaalsed ToR-id nimetatakse Edge-leaf. Me nimetame neid XXX-edgeY.

See näeb välja selline.

Ülaltoodud skeemil on edge ja leaf tõesti samal tasemel. Klassikalised kolmetasandilised võrgud on harjutanud meid nägema, et uplink (sealt ka termin) on lingid ülespoole. Siin aga läheb „uplink” DCI kaudu tagasi alla, mis mõne inimese jaoks võib tavapärast loogikat veidi murda. Suurte võrkude puhul, kus andmekeskused jagunevad veelgi väiksemateks üksusteks — POD’d (Point Of Delivery), eraldi välja toomas Edge-POD’d DCI ja väliste võrkude jaoks.

Edasi liikudes, et tõlgendamine oleks mugavam, joonistan ma siiski Edge'i Spine'i peale, kuigi peame meeles pidama, et Spine'il puudub igasugune intelligentsus ning töötamine tavaliste Leafide ja Edge-leafidega ei erine (kuigi siin võivad olla nüansid, kuid üldiselt on see nii).

Tehase skeem koos Edge-leafidega.

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

Võrgu tehase ülesanne (loe Underlay), nagu oleme juba määratlenud eelmisel väljaandel, on väga ja väga lihtne — tagada IP-ühenduvus masinate vahel nii ühe andmekeskuse sees kui ka nende vahel.
Seetõttu nimetatakse võrku tehaseks, nagu näiteks ühendustehas modulaarses võrgukarbis, millest saab rohkem lugeda SDS14.

Üldiselt nimetatakse sarnast topoloogiat tehaseks, kuna fabric tõlkes tähendab kangast. Ja raske pole nõustuda:

Tehas on täielikult L3. Ükski VLAN, ükski Broadcast — meie LAN_DC imelised programmeerijad oskavad kirjutada rakendusi, mis elavad L3 paradigmas, ja virtuaalmasinad ei vaja IP-aadressi salvestamisega Live Migration'i.

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

DCI — Andmekeskuste omavaheline ühendus (Inter-DC)

DCI korraldatakse Edge-Leaf abil, see tähendab, et need on meie väljapääsupunkt kiirusel.
Lihtsuse huvides eeldame, et andmekeskused on omavahel ühendatud otseühendustega.
Jätame kõrvale välise ühenduvuse.

Ma mõistan, et iga kord, kui ma mõnda komponenti eemaldan, lihtsustan ma võrku oluliselt. Ja kui me automatiseerime meie abstraktset võrku, on kõik korras, kuid reaalses olukorras võivad ilmneda probleemid.
Nii see on. Ja ometi on selle sarja ülesanne mõelda ja töötada lähenemisviiside kallal, mitte kangelaslikult otsustada välja pakutud probleeme.

Edge-Leaf’ides on aluskihiks VPN, mis edastatakse MPLS-i selgroo kaudu (just see otsene link).

Selline on kõrgetasemeline skeem.

Marshuutiing

Andmekeskuse siseseks marsruutimiseks kasutame BGP-d.
MPLS-i selgroos OSPF+LDP.
DCI jaoks, see tähendab ühenduvuse korraldamiseks aluskihis — BGP L3VPN MPLS-i üle.

Üldine marsruutimise skeem

Tehases pole OSPF-i ega ISIS-e (Venemaa Föderatsioonis keelatud marsruutimise protokoll).

Ja see tähendab, et automaatset avastamist ja lühimate tee arvutamist ei toimu — ainult käsitsi (tegelikult automaatne — me räägime ju automatiseerimisest) protokolli, naabruse ja poliitikate seadistamine.

BGP marsruutimise skeem andmekeskuse sees

Miks BGP?

Sellel teemal on kogu RFC Facebooki ja Arista nimel, kus räägitakse, kuidas ehitada väga suuri andmete keskuste võrgud, kasutades BGP-d. Loetakse peaaegu kui kunstiteksti, soovitan tungivalt kauni õhtu jaoks.

Ja veel terve peatükk minu artiklis on sellele pühendatud. Kuhu ma teid suunangi..

Aga siiski, lühidalt öeldes, ei sobi ükski IGP suurtel andmekeskuste võrkudele, kus võrgu seadmete arv läheb tuhandetesse.

Lisaks võimaldab BGP-i kasutamine igal pool vältida mitme erineva protokolli toetamise ja nende vahelise sünkroniseerimise hajutamist.

Käsi südamel, meie tehases, mis tõenäoliselt ei hakka kiiresti kasvama, piisaks täielikult ka OSPF-ist. Need on tõeliselt probleemid megaskaalajate ja pilvetitaanide jaoks. Aga fantaseerime vaid paar numbrit, et meil on seda vaja, ja kasutame BGP-d, nagu jättis meile Peter Lapukhov.

Marsruutimisreeglid

Leaf-lülititel impordime BGP-sse eellagi inglise keele prefikseid allkartuste liidestelt.
Meil on BGP-seanss iga paarile Leaf-Spine, kus need eellagi prefiksid kuulutatakse üle võrgu ringi. seal ja tagasi.

Ühes andmekeskuses laiendame spetsiifilisust, mille oleme importinud Toris. Edge-Leaf’idel kogume ja kuulutame need välja kaugematesse andmekeskustesse ning suuname need Toridesse. Iga Tor teab täpselt, kuidas teise Torini jõuda samas andmekeskuses ja kus on sisenemispunkt, et jõuda Torini teises andmekeskuses.

DCI-s edastatakse marsruudid VPNv4 vormingus. Selleks pannakse Edge-Leaf interfääri suunas tehasesse VRF, mida nimetame UNDERLAY, ja naabrus Spine’i suunas Edge-Leaf’il tõstetakse VRF sees, samas kui Edge-Leaf’ide vahel on VPNv4-family.

Me keelame ka marsruutide uuesti kuulutamise, mis on saadud spiinidelt, tagasi neile endile.

Leaf ja Spine ei impordi Loopback’e. Need on vajalikud ainult Router ID määramiseks.

Kuid Edge-Leaf’idel impordime selle Global BGP-sse. Loopback-aadresside vahel loovad Edge-Leaf'id üksteisega BGP-seansi IPv4 VPN-family-s.

EDGE-seadmete vahel on meil OSPF+LDP baasil lai magistraal. Kõik ühes tsoonis. Üks kõige lihtsamaid konfiguratsioone.

Nii näeb marsruutimine välja.

BGP ASN

Edge-Leaf ASN

Edge-Leaf’ides on ühes DC-s üks ASN. See on oluline, et Edge-Leaf’ide vahel oleks iBGP ning et me ei satuks eBGP nüansside otsa. Olgu see 65535. Tegelikkuses võiks see olla avaliku AS-i number.

Spine ASN

Spine'is on meil üks ASN DC kohta. Alustame siit esimesest numbrist privaatsete AS-ide vahemikus — 64512, 64513 ja nii edasi.

Miks ASN DC-s?

Dekomponeerime selle küsimuse kaheks:

• Miks on kõikide Spine'ide ASN ühes DC-s samad?
• Miks erinevad eri DC-des?

Miks on kõikide Spine'ide ASN ühes DC-s samad

Nii näeb välja AS-Path Underlay marsruudil Edge-Leafidel:
[leafX_ASN, spine_ASN, edge_ASN]
Katses seda tagasi Spine'ile kuulutada, lükkab see selle tagasi, sest selle AS (Spine_AS) on juba nimekirjas.

Kuid DC-s oleme täiesti rahul, et Underlay marsruudid, mis tõusid Edge'ile, ei saa alla tulla. Kõik suhtlemine hostide vahel DC-s peaks toimuma spindide tasemel.

Siiski, teiste DC-de koondatud marsruudid saavad igal juhul vabalt ToR-ideni jõuda — nende AS-Pathis on vaid ASN 65535 — Edge-Leaf'ide AS-i number, sest just seal need loodi.

Miks on erinevad eri DC-des?

Teoreetiliselt võib osutuda vajalikuks juhtida Loopback'e mõne teenindava virtuaalmasina vahel andmekeskuste vahel.

Näiteks käivitatakse meil hostis Route Reflector või see sama VNGW (Virtuaalne Võrgu Lüüsi), mis BGP kaudu ühendub ToR-iga ja kuulutab välja oma Loopback'i, mis peab olema ligipääsetav kõigist andmekeskustest.

Nii et selline 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, samamoodi nagu leafX_DC1 ja leafY_DC2, millele me just läheneme.

Nagu te ilmselt teate, eksisteerivad kaksid, mis võimaldavad vastu võtta marsruute korduvate ASN-idega, vaatamata ringluse vältimise mehhanismile (allowas-in Cisco's). Ja sel on isegi täiesti seaduslikud rakendused. Kuid see on potentsiaalne nõrkus võrgu stabiilsuses. Ja ma olen isiklikult paar korda sellesse langenud.

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

Leaf ASN

Igal Leaf-i lülitil on individuaalne ASN kogu võrgu ulatuses.
Teeme seda eespool toodud kaalutlustel: AS-Path ilma silmusteta, BGP konfiguratsioon ilma tagasiviienditeta.

Et marsruudid Leaf'ide vahel sujuvalt kulgeks, peab AS-Path välja nägema nii:
[leafX_ASN, spine_ASN, leafY_ASN]
kus leafX_ASN ja leafY_ASN võiksid erineda.

See on vajalik ka VNF-i tagasipööramise kuulutuse olukorras keskuste 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, nagu järgneb: Spine_ASN.0000X.

Selline on ASN-i pilt.

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 mis tahes masin saaks suhelda mis tahes teisega. Sobib suurepäraselt 10/8. Iga racki jaoks jagame /26 üle ja meie reservi. Eraldame /19 keskusesse ja /17 regiooni.
2. Sidusad aadressid Leaf/Tor-i ja Spine'i vahel.

   Sooviks neid määrata algoritmiliselt, st arvutada 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-võrk /31.
   See võimaldab käivitada kuni 128 racki ja kuni 10 Spine'i keskuses. Sidusad aadressid võivad (ja tulevad) korduma keskuste vahel.

3. Spine — Edge-Leaf ühenduse organiseerime alamvõrkudesse 169.254.10X.Y/31, kus just nii X — Spine'i number, Y — P2P-võrk /31.
4. Edge-Leafi lingiaadressid MPLS-i selgroo jaoks. Siin on olukord veidi teine — see on koht, kus kõik tükid kokku saavad üheks, seega ei saa samu aadresse uuesti kasutada — tuleb valida järgmine vaba alamvõrk. Seetõttu võtame aluseks 192.168.0.0/16 ja hakkame sellest vabade aadresside leidmisega tegelema.
5. Loopbacki aadressid. Anname nende jaoks välja terve vahemiku 172.16.0.0/12.
   • Leaf — \/25 DC-le — sama 128 riiulit. Jagame \/23 piirkonna jaoks.
   • Spine — \/28 DC-le — kuni 16 Spine'i. Jagame \/26 piirkonna jaoks.
   • Edge-Leaf — \/29 DC-le — kuni 8 kasti. Jagame \/27 piirkonna jaoks.

Kui DC-s puuduvad meile määratud vahemikud (aga neid ei ole — me ju pürgime hüperkasvule), jagame lihtsalt järgmise ploki.

Selline on IP-aadresside jaotamine.

Loopback’id:

Eesliide
Seadme roll
Regioon
DC

172.16.0.0/23
edge
 
 

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
spine
 
 

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

Underlay:

Eesliide
Regioon
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

Labor

Kaks teenusepakkujat. Üks võrk. ADSM.

Juniper + Arista. Ubuntu. Vanad head ajad.

Meie virtuaalmasin Miras on siiski piiratud ressursside arv, seega praktiliseks harjutamiseks kasutame sedasama ultralihtsat võrku.

Kaks andmekeskust: Kazan ja Barcelona.

• Igas on kaks spine'i: Juniper ja Arista.
• Igas liinil (Leaf'il) igas — Juniper ja Arista, ühe ühendatud hostiga (kasutame selleks kergkaalu Cisco IOL-i).
• Üks Edge-Leaf sõlm (praegu ainult Juniper).
• Üks Cisco lüliti, et neid kõiki juhtida.
• Lisaks võrgukarpidele on käivitatud virtuaalne haldusmasin, mis töötab Ubuntu all.
  Sel on juurdepääs kõikidele seadmetele, seal töötavad IPAM/DCIM süsteemid, hulk Python skripte, Ansible ja kõik muu, mis meil vaja võib minna.

Täielik konfiguratsioon kõikidest võrguseadmetest, mida me üritame automatiseerimisega taastada.

Kokkuvõte

Kas nõnda on kombeks? Iga artikli alla teha lühike kokkuvõte?

Nii oleme valinud kolme tasandi Closer võrgu andmekeskuses, kuna ootame palju East-West liiklust ja soovime ECMP-d.

Oleme jaganud võrgu füüsiliseks (underlay) ja virtuaalseks (overlay). Samuti alustab overlay hostist — sellega oleme alandanud nõudeid underlayle.

Valisime BGP alameetodiks routersüsteemide peatuste jaoks tema skaleeritavuse ja poliitikate paindlikkuse tõttu.

Meil on eraldi sõlmed DCI korraldamiseks — Edge-leaf.
Põhivoolus on OSPF+LDP.
DCI rakendatakse MPLS L3VPN põhiselt.
P2P-ühenduste IP-aadresse arvutame me algoritmiliselt seadmete nimede põhjal.
Loopbackid määrame seadmete rolli ja asukoha põhjal järjestikku.
Alusprefiksid — ainult Leaf-lülititele järjestikku nende asukoha põhjal.

Oletame, et meil ei ole hetkel seadmeid paigaldatud.
Seetõttu on meie järgmised sammud — viia need süsteemidesse (IPAM, inventuur), korraldada juurdepääs, genereerida konfiguratsioon ja juurutada see.

Järgmises artiklis uurime Netboxi — IP-ruumi haldamise ja inventuurimise süsteemi andmekeskustes.

Aitäh

• Andrei Glazkovile aka @glazgoo lugemise ja paranduste eest
• Aleksandr Klimenko aka @v00lk lugemise ja paranduste eest
• Artem Chernbajale KDPV eest

Allikas: habr.com