ProHoster > Blog > Administrim > Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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:

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).

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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)

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit
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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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).

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit
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:
Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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ë.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit
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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit
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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.
Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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.

Automatizimi për të voglit. Pjesa e Dytë. Dizajni i rrjetit

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

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster