In die eerste twee artikels het ek die kwessie van outomatisering geopper en die raamwerk daarvan uiteengesit, in die tweede het ek 'n afwyking na netwerkvirtualisering gemaak, as die eerste benadering tot die outomatisering van dienskonfigurasie.
En nou is dit tyd om 'n diagram van die fisiese netwerk te teken.

As jy nie op 'n kort voet is met die organisasie van datasentrumnetwerke nie, beveel ek sterk aan om met die organisasie te begin artikels oor hulle.

Alle vrystellings:

• 0. ADSM. Deel Zero. Beplanning
• 1. ADSM. Deel een (wat na nul is). Netwerkvirtualisering
• 2. ADSM. Deel twee. Netwerk ontwerp

Die praktyke wat in hierdie reeks beskryf word, moet van toepassing wees op enige tipe netwerk, enige skaal en enige verskeidenheid verskaffers (nee). Dit is egter onmoontlik om 'n universele voorbeeld van die toepassing van hierdie benaderings te beskryf. Daarom sal ek fokus op die moderne argitektuur van die DC-netwerk: Kloz fabriek.
Ons sal DCI op MPLS L3VPN doen.

Bo en behalwe die fisiese netwerk is daar 'n Overlay-netwerk vanaf die gasheer (dit kan OpenStack se VXLAN of Tungsten Fabric wees, of enigiets anders wat slegs basiese IP-konneksie van die netwerk vereis).

In hierdie geval kry ons 'n relatief eenvoudige scenario vir outomatisering, want ons het baie toerusting wat op dieselfde manier gekonfigureer is.

Ons sal 'n sferiese GS in vakuum kies:

• Een ontwerp weergawe oral.
• Twee verskaffers wat twee netwerkvlakke vorm.
• Een DC is soos 'n ander soos twee druppels water.

inhoud

• Fisiese topologie
• Roetering
• IP-plan
• Laba
• Gevolgtrekking
• nuttige skakels

Laat ons diensverskaffer LAN_DC byvoorbeeld opleidingsvideo's aanbied oor hoe hysbakke wat vasgesteek is, oorleef.

In megastede is dit baie gewild, so jy het baie fisiese masjiene nodig.

Eerstens sal ek die netwerk ongeveer beskryf soos ek dit graag wil sien. En dan sal ek vereenvoudig vir die laboratorium.

Fisiese topologie

Plekke

LAN_DC sal 6 GS hê:

• Rusland (RU):
  • Moskou (MSK)
  • Kazan (kzn)

• Spanje (SP):
  • Barcelona (BCN)
  • Malaga (MLG)

• Sjina (CN):
  • Sjanghai (sha)
  • Xi'an (sia)

Binne die DC (Intra-DC)

Alle GS'e het identiese interne verbindingsnetwerke gebaseer op die Klose-topologie.
Wat is Kloz-netwerke en hoekom presies dit is - in 'n aparte Artikel.

Elke DC het 10 rakke met motors, hulle sal as genommer word A, B, C En so aan.

Daar is 30 masjiene in elke rak. Hulle sal ons nie interesseer nie.

Ook in elke rek is daar 'n skakelaar waaraan alle masjiene gekoppel is - dit is Bo-aan die rek-skakelaar - ToR of andersins, in terme van die Klose-fabriek, sal ons dit noem Leaf.

Algemene skema van die fabriek.

Ons sal hulle noem XXX-blaarYWaar XXX - drie-letter afkorting DC, en Y - reeksnommer. Byvoorbeeld, kzn-blaar11.

In my artikels sal ek myself toelaat om die terme Leaf en ToR eerder ligsinnig as sinonieme te gebruik. Daar moet egter onthou word dat dit nie die geval is nie.
ToR is 'n rek-gemonteerde skakelaar waarmee masjiene koppel.
Blaar is die rol van 'n toestel in 'n fisiese netwerk of 'n eerstevlakskakelaar in terme van die Klose-topologie.
Dit wil sê Blaar != ToR.
So 'n Leaf kan byvoorbeeld 'n EndofRaw-skakelaar wees.
Binne die raamwerk van hierdie artikel sal ons hulle egter steeds as sinonieme hanteer.

Elke ToR-skakelaar is op sy beurt gekoppel aan vier hoër samevoegingskakelaars - Spine. Onder Spine's word een rek in die DC toegewys. Ons sal dit so noem: XXX-ruggraatY.

In dieselfde rak sal daar netwerktoerusting wees vir konnektiwiteit tussen DC's - 2 routers met MPLS aan boord. Maar oor die algemeen is dit dieselfde Tors. Dit wil sê, uit die oogpunt van Spine-skakelaars maak dit nie saak die gewone ToR met gekoppelde masjiene of 'n router vir DCI nie - een verdomde ding.

Sulke spesiale ToR's word genoem Rand-blaar. Ons sal hulle noem XXX-randY.

Dit sal so lyk.

In die diagram hierbo het ek regtig rand en blaar op dieselfde vlak geplaas. Klassieke drie-laag netwerke het ons geleer om uplink (in werklikheid, dus die term) as skakels te beskou. En hier blyk dit dat die DCI "uplink" teruggaan, wat die gewone logika vir sommige 'n bietjie breek. In die geval van groot netwerke, wanneer datasentrums in selfs kleiner eenhede verdeel word - PODse (Afleweringspunt), ken individu toe Edge-POD's vir DCI en toegang tot eksterne netwerke.

Vir gemak van persepsie in die toekoms, sal ek steeds Edge over Spine teken, terwyl ons in gedagte sal hou dat daar geen intelligensie op Spine is nie en daar is geen verskille wanneer daar met gewone Leaf en met Edge-leaf gewerk word nie (alhoewel daar nuanses kan wees , maar in die algemeen is dit waar).

Fabrieksdiagram met Edge-blare.

Die drie-eenheid Leaf, Spine en Edge vorm 'n Onderlaag netwerk of fabriek.

Die taak van die netwerkfabriek (lees Onderlaag), soos ons reeds gedefinieer het in laaste uitgawe, baie, baie eenvoudig - om IP-konneksie te verskaf tussen masjiene binne dieselfde GS en tussen hulle.
Daarom word die netwerk 'n fabriek genoem, net soos byvoorbeeld 'n skakelfabriek binne modulêre netwerkbokse, waaroor jy meer kan lees in SDSM14.

Oor die algemeen word so 'n topologie 'n fabriek genoem, want stof in vertaling is 'n stof. En dit is moeilik om te verskil:

Die fabriek is heeltemal L3. Geen VLAN's, geen uitsending - dit is die wonderlike programmeerders wat ons in LAN_DC het, hulle kan toepassings skryf wat in die L3-paradigma leef, en virtuele masjiene benodig nie Live Migration met die stoor van die IP-adres nie.

En weereens: die antwoord op die vraag waarom die fabriek en hoekom L3 in 'n aparte is Artikel.

DCI - Data Sentrum Interconnect (Inter-DC)

DCI sal georganiseer word met die hulp van Edge-Leaf, dit wil sê, hulle is ons uitgangspunt na die snelweg.
Vir eenvoud neem ons aan dat GS'e onderling verbind is deur direkte skakels.
Laat ons die eksterne verband van oorweging uitsluit.

Ek is bewus daarvan dat elke keer as ek 'n komponent verwyder, ek die netwerk aansienlik vereenvoudig. En wanneer ons abstrakte netwerk outomatiseer, sal alles goed wees, maar krukke sal op die regte een verskyn.
Dit is waar. En tog is die doel van hierdie reeks om te dink en te werk aan benaderings, en nie om fiktiewe probleme heldhaftig op te los nie.

Op Edge-Leafs word die onderlaag in die VPN geplaas en deur die MPLS-ruggraat (dieselfde direkte skakel) versend.

Hier is so 'n topvlakskema verkry.

Roetering

Vir roetering binne die DC, sal ons BGP gebruik.
Op die OSPF+LDP MPLS-ruggraat.
Vir DCI, dit wil sê, die organisasie van konnektiwiteit in die onderlaag - BGP L3VPN oor MPLS.

Algemene roete-skema

Daar is geen OSPF en ISIS by die fabriek nie (roeteringprotokol verbied in die Russiese Federasie).

En dit beteken dat daar geen outo-ontdekking en berekening van die kortste paaie sal wees nie - slegs handmatige (eintlik outomaties - ons praat hier van outomatisering) protokol, buurt en beleidinstellings.

BGP-roeteringskema binne DC

Hoekom BGP?

Daar is hele RFC vernoem na Facebook en Arista, wat vertel hoe om te bou baie groot datasentrumnetwerke wat BGP gebruik. Dit lees amper soos 'n fiksie, ek beveel dit sterk aan vir 'n trae aand.

Daar is ook 'n hele afdeling in my artikel wat hieraan gewy is. Waarheen kan ek jou neem en stuur.

Maar tog, kortliks, geen IGP is geskik vir netwerke van groot datasentrums, waar die aantal netwerktoestelle in die duisende gaan nie.

Daarbenewens sal die gebruik van BGP oral jou toelaat om nie ondersteuning vir verskeie verskillende protokolle en sinchronisasie tussen hulle te spuit nie.

Hand op die hart, in ons fabriek, wat heel waarskynlik nie vinnig sal groei nie, sal OSPF genoeg wees vir ons oë. Dit is eintlik die probleem van mega scalers en wolk titans. Maar kom ons fantaseer vir net 'n paar kwessies dat ons dit nodig het, en ons sal BGP gebruik, soos Peter Lapukhov bemaak het.

Roeteringsbeleide

Op Leaf-skakelaars voer ons voorvoegsels vanaf Onderlaag-netwerkkoppelvlakke in BGP in.
Ons sal 'n BGP sessie hê tussen elke 'n paar Leaf-Spine, waarin hierdie Onderlaag-voorvoegsels hier en daar oor die netwerk aangekondig sal word.

Binne een datasentrum sal ons die besonderhede wat ons na Tor ingevoer het, versprei. Op Edge-Leafs sal ons dit saamvoeg en dit aan afgeleë DC's aankondig en dit na Tors stuur. Dit wil sê, elke Tor sal presies weet hoe om by 'n ander Tor in dieselfde DC uit te kom en waar is die toegangspunt om by die Tor in 'n ander DC te kom.

In DCI sal roetes as VPNv4 versend word. Om dit te doen, op die Edge-Leaf, sal die koppelvlak na die fabriek in die VRF geplaas word, kom ons noem dit UNDERLAY, en die buurt met die Spine on the Edge-Leaf sal binne-in die VRF, en tussen die Edge-Leafs styg. in die VPNv4-familie.

Ons sal ook die heraankondiging van roetes wat van stekels ontvang word, na hulle verbied.

Op Leaf and Spine sal ons nie Loopbacks invoer nie. Ons sal hulle net nodig hê om die router-ID te bepaal.

Maar op Edge-Leafs voer ons dit in Global BGP in. Tussen Loopback-adresse sal Edge-Leafs 'n BGP-sessie in 'n IPv4 VPN-familie met mekaar vestig.

Tussen EDGE-toestelle sal ons 'n romp tot OSPF + LDP gestrek hê. Alles in een sone. Uiters eenvoudige konfigurasie.

Hier is 'n foto met roetering.

BGP ASN

Randblaar ASN

Op Edge-Leafs sal daar een ASN in alle DC's wees. Dit is belangrik dat daar iBGP tussen die Edge-Leafs is, en ons loop nie die nuanses van eBGP raak nie. Laat dit 65535 wees. In werklikheid kan dit 'n publieke AS-nommer wees.

Ruggraat ASN

Op Spine sal ons een ASN per DC hê. Kom ons begin hier vanaf die heel eerste nommer uit die reeks private AS - 64512, 64513 En so aan.

Hoekom ASN op DC?

Kom ons ontbind hierdie vraag in twee:

• Hoekom dieselfde ASN op alle stekels van een DC?
• Hoekom verskil hulle in verskillende DC's?

Hoekom dieselfde ASN op alle stekels van een DC

Dit is hoe die AS-pad van die onderlaagroete op die randblaar sal lyk:
[leafX_ASN, spine_ASN, edge_ASN]
Wanneer jy probeer om dit terug aan Spine aan te kondig, sal dit verwerp word omdat sy AS (Spine_AS) reeds op die lys is.

Binne die DC is ons egter heeltemal tevrede dat die Onderlaag-roetes wat tot by die Edge gestyg het, nie sal kan daal nie. Alle kommunikasie tussen gashere binne die DC moet binne die vlak van stekels plaasvind.

Terselfdertyd sal die saamgevoegde roetes van ander DC's in elk geval vrylik die Tors bereik - hul AS-Pad sal slegs ASN 65535 bevat - die aantal AS Edge-Leafs, want dit was op hulle wat hulle geskep is.

Hoekom verskil in verskillende DC's

Teoreties moet ons dalk Loopback en sommige diens virtuele masjiene tussen DC's sleep.

Byvoorbeeld, op die gasheer sal ons Route Reflector of dieselfde VNGW (Virtual Network Gateway), wat homself met Tor sal sluit via BGP en sy terugvoering aankondig, wat by alle DC's beskikbaar behoort te wees.

So dit is hoe sy AS-pad sal lyk:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

En daar moet nêrens herhaalde ASN'e wees nie.

Dit wil sê, Spine_DC1 en Spine_DC2 moet anders wees, net soos leafX_DC1 en leafY_DC2, wat presies is wat ons nader.

Soos u waarskynlik weet, is daar hacks wat u toelaat om roetes met duplikaat ASN'e te aanvaar ten spyte van die lusvoorkomingsmeganisme (allowas-in op Cisco). En dit het selfs wettige gebruike. Maar dit is 'n potensiële gat in die stabiliteit van die netwerk. En ek persoonlik het 'n paar keer daarin geval.

En as ons die geleentheid het om nie gevaarlike goed te gebruik nie, sal ons dit gebruik.

Blaar ASN

Ons sal 'n individuele ASN op elke Leaf-skakelaar binne die hele netwerk hê.
Ons doen dit om die redes hierbo gegee: AS-Pad sonder lusse, BGP-konfigurasie sonder boekmerke.

Vir roetes tussen Leafs om glad te slaag, behoort AS-Path so te lyk:
[leafX_ASN, spine_ASN, leafY_ASN]
waar leafX_ASN en leafY_ASN lekker sal wees om anders te wees.

Dit word ook vereis vir die situasie met die aankondiging van die VNF-lusterug tussen DK'e:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Ons sal 'n 4-grepe ASN gebruik en dit genereer op grond van die ASN van die ruggraat en die nommer van die blaarskakelaar, naamlik soos volg: Spine_ASN.0000X.

Hier is so 'n foto met ASN.

IP-plan

Basies moet ons adresse toeken vir die volgende verbindings:

1. Onderlê netwerkadresse tussen ToR en masjien. Hulle moet uniek wees binne die hele netwerk sodat enige masjien met enige ander kan kommunikeer. Puik pasvorm 10/8. Vir elke rek / 26 met 'n kantlyn. Ons sal /19 per DC en /17 per streek toeken.
2. Skakel adresse tussen Leaf/Tor en Spine.

   Ek wil hulle algoritmies toewys, dit wil sê, bereken uit die name van die toestelle wat gekoppel moet word.

   Laat dit wees ... 169.254.0.0/16.
   naamlik, 169.254.00X.Y/31Waar X - Rugnommer, Y — P2P-netwerk /31.
   Dit sal jou toelaat om tot 128 rakke te hardloop, en tot 10 Spine in die DC. Skakeladresse kan (en sal) van DC na DC herhaal word.

3. Joint Spine - Edge-Leaf organiseer op subnette 169.254.10X.Y/31, waar presies dieselfde X - Rugnommer, Y — P2P-netwerk /31.
4. Koppel adresse van Edge-Leaf na MPLS-ruggraat. Hier is die situasie ietwat anders - die aansluiting van al die stukke in een pastei, so jy sal nie dieselfde adresse kan hergebruik nie - jy moet die volgende gratis subnet kies. Daarom neem ons as basis 192.168.0.0/16 en ons sal vry daaruit hark.
5. Loopback-adresse. Kom ons gee hulle die hele reeks 172.16.0.0/12.
   • Blaar - /25 elk by die DC - dieselfde 128 rakke. Ken /23 per streek toe.
   • Spine - by /28 op die DC - tot 16 Spine. Ken /26 per streek toe.
   • Edge-Leaf - /29 by DC - tot 8 bokse. Ken /27 per streek toe.

As ons nie genoeg toegewese reekse in die DC het nie (en ons sal dit nie hê nie - ons gee voor dat ons hiperskaaler is), kies ons eenvoudig die volgende blok.

Hier is 'n foto met IP-adressering.

Loopbacks:

voorvoegsel
Die rol van die toestel
streek
ДЦ

172.16.0.0/23
rand
 
 

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
ruggraat
 
 

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
blaar
 
 

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

Onderlaag:

voorvoegsel
streek
ДЦ

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

Laba

Twee verkopers. Een netwerk. ADSM.

Juniper + Arista. Ubuntu. Goeie ou Eva.

Die hoeveelheid hulpbronne op ons virtuele masjien in Miran is steeds beperk, so vir oefening sal ons so 'n vereenvoudigde netwerk tot die uiterste gebruik.

Twee datasentrums: Kazan en Barcelona.

• Twee draaie elk: Juniper en Arista.
• Een torus (Blaar) in elk - Juniper en Arista, met een gekoppelde gasheer (kom ons neem 'n liggewig Cisco IOL hiervoor).
• Een Edge-Leaf node elk (slegs Juniper tot dusver).
• Een Cisco-skakelaar om hulle almal te regeer.
• Benewens netwerkbokse, is 'n virtuele masjienbestuurder bekendgestel. Onder Ubuntu.
  Dit het toegang tot alle toestelle, dit sal IPAM / DCIM-stelsels laat loop, 'n klomp Python-skrifte, ansible en enigiets anders wat ons dalk nodig het.

Volledige konfigurasie alle netwerktoestelle, wat ons met outomatisering sal probeer reproduseer.

Gevolgtrekking

Word dit ook aanvaar? Onder elke artikel 'n kort gevolgtrekking te maak?

So ons het gekies drie-vlak Kloz-netwerk binne die DC, want ons verwag baie Oos-Wes-verkeer en wil ECMP hê.

Ons het die netwerk in fisies (onderlaag) en virtuele (oorleg) verdeel. Terselfdertyd begin die oorleg vanaf die gasheer - waardeur die vereistes vir die onderlaag vereenvoudig word.

Het BGP as die router-roeteringprotokol gekies vir sy skaalbaarheid en beleidsbuigsaamheid.

Ons sal aparte nodusse hê om DCI - Edge-leaf te organiseer.
Daar sal OSPF+LDP op die ruggraat wees.
DCI sal geïmplementeer word op grond van MPLS L3VPN.
Vir P2P-skakels, sal ons IP-adresse algoritmies bereken op grond van toestelname.
Loopbacks sal opeenvolgend toegewys word volgens die rol van toestelle en hul ligging.
Onderlaagvoorvoegsels - slegs op blaarskakelaars in serie gebaseer op hul ligging.

Kom ons neem aan dat ons geen toerusting op die oomblik geïnstalleer het nie.
Daarom sal ons volgende stappe wees om hulle in stelsels te kry (IPAM, voorraad), toegang te organiseer, 'n konfigurasie te genereer en dit te ontplooi.

In die volgende artikel gaan ons handel oor Netbox, 'n voorraad- en bestuurstelsel vir IP-ruimte in 'n DC.

Dankie

• Andrey Glazkov aka @glazgoo vir proeflees en redigering
• Alexandru Klimenko aka @v00lk vir proeflees en redigering
• Artyom Chernobay vir KDPV

Bron: will.com