Në dy artikujt e parë, ngrita çështjen e automatizimit dhe skicova kornizën e tij, ndërsa në të dytin bëra një shkëputje në virtualizimin e rrjetit, si qasja e parë ndaj automatizimit të konfigurimit të shërbimeve.
Tani ka ardhur koha të vizatojmë skemën e rrjetit fizik.

Nëse nuk jeni në një marrëdhënie të ngushtë me pajisjet e rrjetit të qendrave të të dhënave, unë ju rekomandoj me ngulm të filloni me artikujt mbi to..

Të gjitha episodet:

• 0. ADMS. Pjesa Zero. Planifikimi
• 1. ADMS. Pjesa e parë (e cila vjen pas zeros). Virtualizimi i rrjetit
• 2. ADMS. Pjesa e Dytë. Dizajni i rrjetit

Praktikat e përshkruara në këtë seri duhet të jenë të aplikueshme për rrjetin e çdo lloji, çdo shkalle me çdo shumëllojshmëri ofruesish (jo). Megjithatë, nuk mund të përshkruhet një shembull universalisht i aplikueshëm i këtyre qasjeve. Prandaj, do të ndalem në arkitekturën moderne të rrjetit DC: Fabrika e Klouzave.
DCI do ta bëjmë në MPLS L3VPN.

Mbi rrjetin fizik funksionon një rrjet Overlay nga hosti (mund të jetë VXLAN i OpenStack ose Tungsten Fabric apo çfarëdo tjetër që kërkon nga rrjeti vetëm lidhshmëri bazike IP).

Në këtë rast do të kemi një skenar relativisht të thjeshtë për automatizimin, sepse kemi shumë pajisje që konfigurohen në të njëjtën mënyrë.

Ne do të zgjedhim një DC sfersor në vakuum:

• Një version dizajni në të gjithë vendin.
• Dy ofrues, duke formuar dy plane rrjeti.
• Një DC duket si tjetri si dy pika uji.

Përmbajtja

• Topologjia fizike
• Routimi
• Plani IP
• Laboratori
• Përfundim
• Useful links

Le të supozojmë që ofruesi ynë Shërbimi LAN_DC do të hostojë video shkollore mbi mbijetesën në ashensorët e ngecur.

Në metropolet, kjo ka një popullaritet të madh, ndaj nevojiten shumë makina fizike.

Fillimisht do ta përshkruaj rrjetin siç do të doja të ishte. Më pas do ta thjeshtoj për laboratorin.

Topologjia fizike

Lokacionet

LAN_DC do të ketë 6 DC:

• Rusia (RU):
  • Moskë (msk)
  • Kazan (kzn)

• Spanjë (SP):
  • Barcelona (bcn)
  • Málaga (mlg)

• Kina (CN):
  • Shangai (sha)
  • Xi'an (sia)

Brenda DC (Intra-DC)

Në të gjitha DC janë rrjete identike të lidhjes së brendshme, të bazuara në topologjinë e Klouzave.
Çfarë janë rrjetet e Klouzave dhe pse janë ato — në një artikull të veçantë. artikulli ynë.

Në çdo DC janë 10 ristika me makina, që do të numërohen si A, B, C Dhe kështu me radhë.

Në çdo ristë janë 30 makina. Ato nuk do të na interesojnë.

Gjithashtu, në çdo ristë ka një switch, të cilit i janë lidhur të gjitha makinat — ky është Switchi në Majën e Ristës - ToR ose ndryshe në terma të fabrikës së Klouzave do ta quajmë Gjethe.

Skema e përgjithshme e fabrikës.

Do t'i emërojmë XXX-gjerësiaYindex XXX — akronim trejë shkronjash DC, dhe Y — numri rendor. Për shembull, kzn-leaf11.

Në artikuj unë do të lejohem të flas mjaft lirshëm me terminat Leaf dhe ToR, si sinonime. Megjithatë, duhet të mbani mend se kjo nuk është aq e saktë.
ToR — është një switch i vendosur në raft, të cilit i lidhen makinat.
Leaf — është roli i një pajisjeje në rrjetin fizik ose një switch i nivelit të parë në terminologjinë e topologjisë Cloze.
Kjo do të thotë që Leaf != ToR.
Pra, Leaf mund të jetë një switch EndofRaw, për shembull.
Megjithatë, në kuadër të këtij artikulli do të flasim për to si sinonime.

Çdo switch ToR, nga ana e tij, është i lidhur me katër switch-e agregues më lart — Spine. Për Spine do të rezervojmë një raft në DC. Do t'i emërojmë ndryshe: XXX-spineY.

Në këtë raft gjithashtu do të ketë pajisje rrjeti për lidhshmërinë ndërmjet DC — 2 router-a me MPLS në bord. Por, në thelb — këta janë po ato ToR. Pra, nga pikëpamja e switch-eve Spine nuk ka asnjë rëndësi nëse ato janë ToR me makina të lidhura ose router për DCI — njësoj është të shpejtojmë.

Këta ToR të veçantë quhen Edge-leaf. Ne do t'i emërojmë XXX-edgeY.

Kështu do të duket.

Në diagramin e mësipërm, unë në të vërtetë vendosa edge dhe leaf në të njëjtin nivel. Rrjetet klasike me tri nivele na mësuan të shohim uplink (saktësisht nga këtu dhe termi) si lidhje lart. Por këtu, rezulton se "uplink" DCI shkon përsëri poshtë, gjë që për disa e prish pak logjikën e zakonshme. Në rastin e rrjeteve të mëdha, kur qendrat e të dhënave ndahen në njësi më të vogla — POD'të (Point Of Delivery), akordet e veçanta Edge-POD'të për DCI dhe dalje në rrjetet e jashtme.

Për lehtësi të kuptimit në vazhdim, unë do të vazhdoj t'i vizatoj Edge mbi Spine, megjithatë do ta mbajmë mend se nuk ka asnjë inteligjencë në Spine dhe dallime në punën me Leaf dhe Edge-leaf (edhe pse këtu mund të ketë nuanca, por në përgjithësi është kështu).

Diagrami i fabrikës me Edge-leaf.

Trioja Leaf, Spine dhe Edge formojnë një rrjet Underlay ose fabrikë.

Detyra e fabrikës së rrjetit (lexo Underlay), siç e kemi përcaktuar në numrin e kaluar, është shumë dhe shumë e thjeshtë — të sigurojë lidhshmërinë IP midis makinave si brenda një DC, ashtu edhe midis.
Pikërisht për këtë arsye rrjeti quhet fabrikë, ashtu siç është fabrika e komandës brenda kutive modulare të rrjetit, për të cilën mund të lexoni më shumë në SDS14.

Në të vërtetë, kjo topologji quhet fabrikë, sepse fabric në përkthim do të thotë tekstil. Dhe është e vështirë të mos bieni dakord:

Fabrika është plotësisht L3. Asnjë VLAN, asnjë Broadcast — këta janë programuesit tanë të mrekullueshëm në LAN_DC, në gjendje të shkruajnë aplikacione që jetojnë në paradigmat L3, dhe makinat virtuale nuk kërkojnë Migrim të Drejtë me ruajtjen e IP-së.

Dhe përsëri: përgjigjja në pyetjen pse fabrikë dhe pse L3 është në një artikulli ynë.

DCI — Interkoneksioni i Qendrës së të Dhënave (Inter-DC)

DCI do të organizohet me anë të Edge-Leaf, domethënë ata janë pika jonë e daljes në autostradë.
Për thjeshtësi le të supozojmë se DC-të janë të lidhura midis tyre me lidhje të drejta.
Le të përjashtojmë nga shqyrtimi lidhshmërinë e jashtme.

E kuptoj që çdo herë që unë heq ndonjë komponent, unë e thjeshtoj ndjeshëm rrjetin. Dhe kur automatizojmë rrjetin tonë abstrakt, gjithçka do të shkojë mirë, por në të vërtetën do të shfaqen ndihma.
Kjo është e vërtetë. Dhe megjithatë, qëllimi i kësaj serie është të mendojmë dhe të punojmë mbi qasjet, e jo të zgjidhim probleme të imagjinuara me guxim.

Në Edge-Leaf, underlay është vendosur në VPN dhe transmetohet përmes MPLS-autostradës (ajo lidhja e drejtpërdrejtë).

Kjo është skema e nivelit të lartë.

Routimi

Për ruterizimin brenda DC-së do të përdorim BGP.
Në MPLS-autostradë OSPF+LDP.
Për DCI, që do të thotë organizimi i lidhshmërisë në underlay — BGP L3VPN mbi MPLS.

Skema e përgjithshme e ruterizimit

Në fabrikë nuk ka OSPF dhe ISIS (protokolli i ruterizimit i ndaluar në Federatën Ruse).

Pra, kjo do të thotë se nuk do të ketë Auto-discovery dhe llogaritje të rrugëve më të shkurtra — vetëm konfigurim manual (në të vërtetë automatizuar — ne flasim për automatizim këtu) të protokollit, fqinjësisë dhe politikave.

Skema e ruterizimit BGP brenda DC-së

Pse BGP?

Ka një RFC të tërë në emrin e Facebook dhe Arista, ku flitet se si të ndërtohen rrjete shumë të mëdha të qendrave të të dhënave, duke përdorur BGP. Lexohet pothuajse si një letër, shumë e rekomanduar për një mbrëmje relaksuese.

Për më tepër, një seksion të plotë të artikullit tim i kushtohet këtij çështje. Ku ju dërgoj dhe dërgoj.

Por nëse e përmbledhim, asnjë IGP nuk është i përshtatshëm për rrjete të mëdha të qendrave të të dhënave, ku numri i pajisjeve rrjet është në mijëra.

Për më tepër, përdorimi i BGP gjithandej do të lejojë që të mos shpërndajmë mbështetje për protokolle të ndryshme dhe sinkronizimin mes tyre.

Duke me dorë në zemër, në fabrikën tonë, që me shumë mundësi nuk do të rritet shpejt, mjaft do të mjaftonim me OSPF. Këto janë në të vërtetë problemet e mega-shkallarëve dhe titanëve të cloud-it. Por le të fantazojmë vetëm për disa edicione, se na nevojitet, dhe do të përdorim BGP, siç e ka lënë testament Pjotr Lapukhov.

Politikat e rrugëzimit

Në Leaf-switch-at ne importojmë në BGP prefikset nga ndërfaqet Underlay me rrjetet.
Do të kemi një sesion BGP mes çdo çift Leaf-Spine, në të cilat këto prefikse Underlay do të shpallen në rrjet këtu-të aty.

Brenda një qendrë të të dhënave do të shpërndajmë specifikat, që kemi importuar në ToR. Në Edge-Leaf do t’i agregojmë dhe do t’i shpallim në qendrat e dhënave të largëta dhe do t’i çojmë deri në ToR. Kështu që çdo ToR do të dijë saktësisht si të arrijë në ToR-in tjetër në të njëjtën qendër të të dhënave dhe ku është pika e hyrjes, për t’u arrijë në ToR-in në një qendër tjetër të të dhënash.

Në DCI rrugët do të kalohen si VPNv4. Për këtë, në ndërfaqen Edge-Leaf në drejtim të fabrikës do të vendoset në VRF, ta quajmë UNDERLAY, dhe fqinjësia me Spine në Edge-Leaf do të ngrihet brenda VRF, ndërsa midis Edge-Leaf-ve do të jetë në VPNv4-family.

Po ashtu, ne do të ndalojmë rinjohjen e rrugëve të marra nga spajnat, prapa tek ato po.

Në Leaf dhe Spine ne nuk do të importojmë Loopback. Ne na nevojiten vetëm për të përcaktuar Router ID.

Por në Edge-Leaf-ët do ta importojmë në Global BGP. Ndërmjet adresave Loopback, Edge-Leaf-ët do të vendosin një sesion BGP në IPv4 VPN-family me njëri-tjetrin.

Midis pajisjeve EDGE do të kemi një autostradë të shtrirë mbi OSPF+LDP. Të gjitha në një zonë. Konfigurim ekstremisht i thjeshtë.

Kjo është pamja e rrugëzimit.

BGP ASN

Edge-Leaf ASN

Në Edge-Leaf do të ketë një ASN në të gjitha qendrat e të dhënave. Kjo është e rëndësishme, që të ketë iBGP midis Edge-Leaf-ve dhe që të mos kemi vështirësi me nuancat e eBGP. Le të jetë 65535. Në realitet ky mund të ishte numri i AS publik.

Spine ASN

Në Spine do të kemi një ASN për çdo qendër të dhënash. Le të fillojmë këtu me numrin e parë nga gamat private AS — 64512, 64513 dhe kështu me radhë.

Përse ASN në qendrat e të dhënave?

Ta dekompozoni këtë pyetje në dy:

• Përse ASN të njëjta në të gjitha spajnat e një qendër të dhënash?
• Përse të ndryshme në qendrat e ndryshme të dhënash?

Përse ASN të njëjta në të gjitha spajnat e një qendër të dhënash

Kështu do të duket AS-Path i rrugës Underlay në Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
Kur tentoni ta shpallni atë përsëri në Spine, ai do ta presë sepse AS i tij (Spine_AS) është tashmë në listë.

Megjithatë, ne brenda DC-së jemi totalisht të kënaqur që rrugët Underlay, të ngritura deri në Edge, nuk do të jenë në gjendje të zbritin poshtë. Të gjitha komunikimet midis hosteve brenda DC-së duhet të ndodhin brenda nivelit të spineve.

Megjithëse, rrugët e agreguara nga DC-të e tjera do të arrijnë pa pengesë tek ToR-at — në AS-Path e tyre do të ketë vetëm ASN 65535 — numri i AS të Edge-Leaf-ëve, sepse pikërisht atyre u janë krijuar.

Pse ndryshojnë në DC të ndryshme

Teorikisht, mund të na nevojitet të kalojmë Loopback të ndonjë makine virtuale shërbimi midis DC-ve.

Për shembull, në hostin tonë do të nisë Route Reflector ose ai i famshëm VNGW (Virtual Network Gateway), i cili përmes BGP do të lidhet me ToR-in dhe do të njoftojë loopback-un e tij, i cili duhet të jetë i aksesueshëm nga të gjitha DC-të.

Ja se si do të duket AS-Path-i i tij:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Dhe këtu nuk duhet të ketë ASN të përsëritur.

Pra, Spine_DC1 dhe Spine_DC2 duhet të jenë të ndryshëm, ashtu si leafX_DC1 dhe leafY_DC2, për të cilat po afrohemi.

Ashtu siç e dini, ekzistojnë hacks që lejojnë pranimin e rrugëve me ASN të përsëritur pavarësisht mekanizmit të parandalimit të cikleve (allowas-in në Cisco). Dhe kjo ka disa aplikime të përligjura. Por kjo është një çarje potenciale në qëndrueshmërinë e rrjetit. Dhe unë personalisht kam rënë në të disa herë.

Dhe nëse kemi mundësinë të mos përdorim gjëra të rrezikshme, ne do ta shfrytëzojmë atë.

Leaf ASN

Do të kemi një ASN individual për çdo Leaf-switch në të gjithë rrjetin.
E bëjmë këtë për arsye të përmendura më sipër: AS-Path pa cikle, konfigurimi BGP pa vulnerabilitete.

Për të lejuar që rrugët midis Leaf-ëve të kalojnë pa pengesa, AS-Path duhet të duket kështu:
[leafX_ASN, spine_ASN, leafY_ASN]
ku leafX_ASN dhe leafY_ASN do ishte mirë që të ndryshonin.

Kjo është gjithashtu e nevojshme për situatën e njoftimit të loopback-ut VNF midis DC-ve:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Do të përdorim një ASN 4-byte dhe do ta gjenerojmë atë në bazë të ASN Spine-it dhe numrit të Leaf-switch-it, pikërisht kështu: Spine_ASN.0000X.

Ja si duket ASN.

Plani IP

Në mënyrë principiale, na nevojiten adresa për lidhjet e mëposhtme:

1. Adresat e rrjetit Underlay midis ToR dhe makinerisë. Ato duhet të jenë unike në të gjithë rrjetin, që çdo makinë të mund të lidhet me çdo tjetër. Shumë të përshtatshme 10/8. Për çdo raft do të ndajmë një /26 me rezerva. Do të ndajmë /19 për DC dhe /17 për rajonin.
2. Adresat lidhëse midis Leaf/Tor dhe Spine.

   Ata do të ishte e dëshirueshme t'i caktonim algoritmikisht, dmth, të llogaritim nga emrat e pajisjeve që duhet të lidhen.

   Le të jetë… 169.254.0.0/16.
   Saktësisht 169.254.00X.Y/31index X — numri i Spine, Y — rrjeti P2P /31.
   Kjo do të mundësojë aktivizimin e deri në 128 raftesh, dhe deri në 10 Spine në DC. Adresat lidhëse mund të (dhe do të) përsëriten nga DC në DC.

3. Stina e Spine— Edge-Leaf do të organizohet në nënrrjeta 169.254.10X.Y/31, ku gjithashtu X — numri i Spine, Y — rrjeti P2P /31.
4. Adresat lidhëse nga Edge-Leaf në MPLS-rrjet. Këtu situata është pak ndryshe — vendi i lidhjes së të gjitha pjesëve në një tortë, prandaj të ripërdorësh të njëjtat adresa nuk do të jetë e mundur — duhet të zgjidhni nënrrjetin e parë të lirë. Prandaj do të marrim si bazë 192.168.0.0/16 dhe do të nxjerrim adresat e lira nga ajo.
5. Adresat Loopback. Do t'i japim të gjithë gamën 172.16.0.0/12.
   • Leaf — në /25 në DC — të njëjtat 128 raftesh. Do t'i ndajmë në /23 për rajonin.
   • Spine — në /28 në DC — deri në 16 Spine. Do t'i ndajmë në /26 për rajonin.
   • Edge-Leaf — në /29 në DC — deri në 8 kuti. Do t'i ndajmë në /27 për rajonin.

Nëse në DC nuk do të mjaftojnë gamat e ndara (dhe nuk do të mjaftojnë — ne po pretendojmë për rritje të hiper-shkallëzuar), thjesht ndajmë bllokun e ardhshëm.

Kjo është panorama e adresimit IP.

Loopback:

Prefiksi
Roli i pajisjes
Rajoni
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:

Prefiksi
Rajoni
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

Laboratori

Dy ofrues. Një rrjet. ADSHM.

Juniper + Arista. Ubuntu. E vjetër mirë Eva.

Numri i burimeve në makinën tonë virtuale në Miran është në fakt i kufizuar, prandaj për praktikë do të përdorim një rrjet të tillë të thjeshtuar në maksimum.

Dy qendrat e të dhënave: Kazan dhe Barcelona.

• Dy spine në çdo njësi: Juniper dhe Arista.
• Një tor (Leaf) në çdo njësi — Juniper dhe Arista, me një mikpritës të lidhur (do të marrim Cisco IOL për këtë).
• Një nodë Edge-Leaf (për momentin vetëm Juniper).
• Një këtëç Cisco për t'i udhëhequr të gjithë.
• Përveç kutive rrjetë, është aktivizuar një makinë virtuale menaxhuese. Nën menaxhimin e Ubuntu.
  Ajo ka qasje në të gjitha pajisjet, në të do të funksionojnë sistemet IPAM/DCIM, një grup skenari Python, ansible dhe çdo gjë tjetër që na nevojitet.

Konfigurimi i plotë i të gjitha pajisjeve rrjetore që do të përpiqemi ta riprodhojmë përmes automatizmit.

Përfundim

A është e zakonshme? Të bëjmë përfundime të shkurtra nën çdo artikull?

Kështu ne zgjodhëm rrjetin me tre nivele Kloza brenda DC, pasi presim shumë trafik East-West dhe duam ECMP.

E ndamë rrjetin në fizik (underlay) dhe virtual (overlay). Në këtë mënyrë overlay fillon nga mikpritësi — duke thjeshtuar kështu kërkesat për antherlay.

Zgjodhëm BGP si protokollin e ruterizimit të rrjeteve të nënndërtimeve për shkak të shkallëzueshmërisë së tij dhe fleksibilitetit të politikave.

Do të kemi node të ndara për organizimin e DCI — Edge-leaf.
Në autostradë do të jetë OSPF+LDP.
DCI do të realizohet mbi bazën e MPLS L3VPN.
Për lidhjet P2P ne do të llogarisim adresat IP algoritmikisht mbi bazën e emrave të pajisjeve.
Loopback-ët do t'i caktojmë sipas rolit të pajisjeve dhe vendndodhjes së tyre një pas një.
Prefikset nënndërtesë — vetëm në switch-ët Leaf në mënyrë sekuenciale në bazë të vendndodhjes së tyre.

Supozoni se tani për tani nuk kemi ende pajisjet e instaluara.
Prandaj hapat tanë të ardhshëm do të jenë — t'i regjistrojmë ato në sistemet (IPAM, inventar), të organizojmë aksesin, të gjenerojmë konfigurimin dhe ta deploy-ojmë atë.

Në artikullin e ardhshëm do të shqyrtojmë Netbox — sistemin e inventarizimit dhe menaxhimit të hapësirës IP në DC.

Faleminderit

• Andrey Glazkov aka @glazgoo për rishikimin dhe redaktimet
• Aleksandër Klimenko aka @v00lk për rishikimin dhe redaktimet
• Artem Chernobay për KDPV

Burimi: habr.com