In de eerste twee artikelen heb ik het onderwerp automatisering ter sprake gebracht en het raamwerk ervan geschetst, in het tweede artikel heb ik mij teruggetrokken in netwerkvirtualisatie, als de eerste benadering voor het automatiseren van de configuratie van services.
Nu is het tijd om een ​​diagram van het fysieke netwerk te tekenen.

Als u niet bekend bent met het opzetten van datacenternetwerken, raad ik u ten zeerste aan om hiermee te beginnen artikelen over hen.

Alle problemen:

• 0. ADSM. Deel nul. Planning
• 1. ADSM. Deel één (dat na nul is). Netwerkvirtualisatie
• 2. ADSM. Deel twee. Netwerk ontwerp

De praktijken die in deze serie worden beschreven, zouden toepasbaar moeten zijn op elk type netwerk, elke omvang, met elke variëteit aan leveranciers (niet). Het is echter onmogelijk om een ​​universeel voorbeeld te beschrijven van de toepassing van deze benaderingen. Daarom zal ik me concentreren op de moderne architectuur van het DC-netwerk: Kloz-fabriek.
We zullen DCI doen op MPLS L3VPN.

Een Overlay-netwerk draait bovenop het fysieke netwerk van de host (dit kan OpenStack's VXLAN of Tungsten Fabric zijn of iets anders dat alleen basis IP-connectiviteit van het netwerk vereist).

In dit geval krijgen we een relatief eenvoudig scenario voor automatisering, omdat we veel apparatuur hebben die op dezelfde manier is geconfigureerd.

We kiezen een bolvormige DC in een vacuüm:

• Overal één designversie.
• Twee leveranciers die twee netwerkvlakken vormen.
• De ene DC is als de andere als twee druppels water.

Inhoud

• Fysieke topologie
• Routering
• IP-abonnement
• Laba
• Conclusie
• Nuttige links

Laat onze serviceprovider LAN_DC bijvoorbeeld trainingsvideo's hosten over overleven in vastzittende liften.

In megasteden is dit enorm populair, dus je hebt veel fysieke machines nodig.

Eerst zal ik het netwerk ongeveer beschrijven zoals ik het zou willen hebben. En dan vereenvoudig ik het voor het lab.

Fysieke topologie

Locaties

LAN_DC zal 6 DC's hebben:

• Rusland (RU):
  • Moskou (msk)
  • Kazan (KZN)

• Spanje (SP):
  • Barcelona (bcn)
  • Málaga (MLG)

• China (CN):
  • Sjanghai (sha)
  • Xi'an (is)

Binnen DC (Intra-DC)

Alle DC's hebben identieke interne connectiviteitsnetwerken op basis van Clos-topologie.
Wat voor soort Clos-netwerken zijn het en waarom bevinden ze zich in een aparte статье.

Elk DC heeft 10 rekken met machines, deze worden genummerd als A, B, C En ga zo maar door.

In elk rack staan ​​30 machines. Ze zullen ons niet interesseren.

Ook bevindt zich in elk rack een schakelaar waarop alle machines zijn aangesloten - dit is het Top of the Rack-schakelaar - ToR of anders, in termen van de Clos-fabriek, zullen we het noemen Bladeren.

Algemeen diagram van de fabriek.

Wij zullen ze bellen XXX-bladYWaar XXX - drieletterige afkorting DC, en Y - serienummer. Bijvoorbeeld, kzn-blad11.

In mijn artikelen zal ik mezelf toestaan ​​de termen Leaf en ToR nogal frivool als synoniemen te gebruiken. We moeten echter niet vergeten dat dit niet het geval is.
ToR is een switch die in een rack wordt geïnstalleerd en waarop machines zijn aangesloten.
Leaf is de rol van een apparaat in een fysiek netwerk of een switch op het eerste niveau in termen van Cloes-topologie.
Dat wil zeggen, Blad != ToR.
Leaf kan dus bijvoorbeeld een EndofRaw-switch zijn.
In het kader van dit artikel zullen we ze echter nog steeds als synoniemen behandelen.

Elke ToR-schakelaar is op zijn beurt verbonden met vier aggregatieschakelaars op een hoger niveau: Wervelkolom. Eén rack in het DC is gereserveerd voor Spines. We zullen het op dezelfde manier noemen: XXX-ruggengraatY.

Hetzelfde rack zal netwerkapparatuur bevatten voor connectiviteit tussen de DC-2-routers met MPLS aan boord. Maar over het algemeen zijn dit dezelfde ToR's. Dat wil zeggen, vanuit het oogpunt van Spine-switches doet de gebruikelijke ToR met aangesloten machines of een router voor DCI er helemaal niet toe - alleen maar doorsturen.

Dergelijke speciale ToR's worden genoemd Randblad. Wij zullen ze bellen XXX-randY.

Het zal er zo uitzien.

In het bovenstaande diagram heb ik de rand en het blad feitelijk op hetzelfde niveau geplaatst. Klassieke drielaagse netwerken Ze leerden ons om uplinking (vandaar de term) als uplinks te beschouwen. En hier blijkt dat de DCI “uplink” weer naar beneden gaat, wat voor sommigen de gebruikelijke logica enigszins doorbreekt. In het geval van grote netwerken, wanneer datacenters in nog kleinere eenheden zijn verdeeld - POD's (Point Of Delivery), markeer individueel Edge-POD's voor DCI en toegang tot externe netwerken.

Voor het gemak van waarneming in de toekomst zal ik Edge nog steeds over Spine tekenen, terwijl we in gedachten zullen houden dat er geen intelligentie op Spine zit en dat er geen verschillen zijn bij het werken met gewoon Leaf- en Edge-leaf (hoewel er hier nuances kunnen zijn , maar in het algemeen is dit waar).

Schema van een fabriek met Edge-leafs.

De drie-eenheid Leaf, Spine en Edge vormen een Underlay-netwerk of fabriek.

De taak van een netwerkfabriek (lees Underlay), zoals we al hebben gedefinieerd in laatste nummer, heel, heel eenvoudig - om IP-connectiviteit te bieden tussen machines, zowel binnen dezelfde DC als daartussen.
Daarom wordt het netwerk een fabriek genoemd, net zoals bijvoorbeeld een schakelfabriek in modulaire netwerkboxen, waarover je meer kunt lezen in SDSM14.

Over het algemeen wordt een dergelijke topologie een fabriek genoemd, omdat stof in vertaling stof betekent. En het is moeilijk om het er niet mee eens te zijn:

De fabriek is volledig L3. Geen VLAN, geen uitzending - we hebben zulke geweldige programmeurs bij LAN_DC, ze weten hoe ze applicaties moeten schrijven die in het L3-paradigma leven, en virtuele machines vereisen geen Live Migratie met behoud van het IP-adres.

En nogmaals: het antwoord op de vraag waarom de fabriek en waarom de L3 in een aparte ruimte staat статье.

DCI - Datacenter-interconnect (Inter-DC)

DCI wordt georganiseerd met behulp van Edge-Leaf, dat wil zeggen dat zij ons uitgangspunt naar de snelweg zijn.
Voor de eenvoud gaan we ervan uit dat de DC's via directe verbindingen met elkaar zijn verbonden.
Laten we externe connectiviteit buiten beschouwing laten.

Ik ben me ervan bewust dat elke keer dat ik een component verwijder, ik het netwerk aanzienlijk vereenvoudig. En als we ons abstracte netwerk automatiseren, komt alles goed, maar op het echte netwerk zullen er krukken zijn.
Dit is waar. Toch is het doel van deze serie om na te denken en te werken aan benaderingen, en niet om denkbeeldige problemen heldhaftig op te lossen.

Bij Edge-Leafs wordt de onderlaag in de VPN geplaatst en verzonden via de MPLS-backbone (dezelfde directe link).

Dit is het diagram op het hoogste niveau dat we krijgen.

Routering

Voor routering binnen het DC gebruiken we BGP.
Op de MPLS-trunk OSPF+LDP.
Voor DCI betekent dat het organiseren van connectiviteit in de metro - BGP L3VPN via MPLS.

Algemeen routeringsschema

Er is geen OSPF of ISIS (routeringsprotocol verboden in de Russische Federatie) in de fabriek.

Dit betekent dat er geen automatische detectie of berekening van de kortste paden zal plaatsvinden - alleen handmatig (eigenlijk automatisch - we hebben het hier over automatisering) voor het instellen van het protocol, de buurt en het beleid.

BGP-routeringsschema binnen de DC

Waarom BGP?

Over dit onderwerp is er hele RFC vernoemd naar Facebook en Arista, dat vertelt hoe je moet bouwen erg groot datacenternetwerken die gebruik maken van BGP. Het leest bijna als fictie, ik raad het ten zeerste aan voor een lome avond.

En er is ook een hele sectie in mijn artikel aan gewijd. Waar breng ik je heen en ik ben aan het sturen.

Maar kortom: geen enkele IGP is geschikt voor netwerken van grote datacenters, waar het aantal netwerkapparaten in de duizenden loopt.

Bovendien zorgt het overal gebruiken van BGP ervoor dat u geen tijd verspilt aan het ondersteunen van verschillende protocollen en de synchronisatie daartussen.

Hand op hart: in onze fabriek, die met grote waarschijnlijkheid niet snel zal groeien, zou OSPF genoeg zijn voor de ogen. Dit zijn eigenlijk de problemen van megascalers en cloudtitanen. Maar laten we ons voorstellen dat we het voor een paar releases nodig hebben, en we zullen BGP gebruiken, zoals Pjotr ​​Lapoechov heeft nagelaten.

Routeringsbeleid

Op Leaf-switches importeren we voorvoegsels van Underlay-netwerkinterfaces in BGP.
Tussendoor houden we een BGP-sessie elk een Leaf-Spine-paar, waarin deze Underlay-voorvoegsels hier en daar via het netwerk worden aangekondigd.

Binnen één datacenter distribueren wij de specificaties die wij in ToRe hebben geïmporteerd. Op Edge-Leafs zullen we ze samenvoegen en aankondigen aan externe DC's en ze naar TOR's sturen. Dat wil zeggen dat elke ToR precies weet hoe hij bij een andere ToR in hetzelfde DC kan komen en waar het startpunt is om bij de ToR in een ander DC te komen.

In DCI worden routes verzonden als VPNv4. Om dit te doen, zal op Edge-Leaf de interface naar de fabriek in een VRF worden geplaatst, laten we het UNDERLAY noemen, en de buurt met Spine op Edge-Leaf zal stijgen binnen de VRF, en tussen Edge-Leafs in de VPNv4- familie.

We zullen ook de heraankondiging van routes die zijn ontvangen van stekels naar hen verbieden.

Op Leaf en Spine importeren we geen Loopbacks. We hebben ze alleen nodig om de router-ID te bepalen.

Maar op Edge-Leafs importeren we het in Global BGP. Tussen Loopback-adressen zal Edge-Leafs met elkaar een BGP-sessie in de IPv4 VPN-familie tot stand brengen.

We zullen een OSPF+LDP-backbone hebben tussen EDGE-apparaten. Alles bevindt zich in één zone. Uiterst eenvoudige configuratie.

Dit is de foto met routing.

BGP ASN

Randblad ASN

Op Edge-Leafs zal er één ASN zijn in alle DC's. Het is belangrijk dat er iBGP is tussen Edge-Leafs, en we raken niet verstrikt in de nuances van eBGP. Laat het 65535 zijn. In werkelijkheid zou dit het nummer van een openbare AS kunnen zijn.

Ruggengraat ASN

Op Spine hebben we één ASN per DC. Laten we hier beginnen met het allereerste nummer uit het assortiment particuliere AS - 64512, 64513 enzovoort.

Waarom ASN op DC?

Laten we deze vraag in tweeën splitsen:

• Waarom zijn de ASN's hetzelfde op alle stekels van één DC?
• Waarom zijn ze verschillend in verschillende DC's?

Waarom zijn dezelfde ASN's op alle stekels van één DC?

Zo ziet het AS-Path van de Underlay-route op Edge-Leaf eruit:
[leafX_ASN, spine_ASN, edge_ASN]
Wanneer u probeert het terug te adverteren naar Spine, wordt het weggegooid omdat de AS (Spine_AS) al in de lijst staat.

Binnen het DC zijn we echter volkomen tevreden dat de Underlay-routes die naar de Edge stijgen niet naar beneden kunnen. Alle communicatie tussen hosts binnen de DC moet plaatsvinden op wervelkolomniveau.

In dit geval zullen de geaggregeerde routes van andere DC's in ieder geval gemakkelijk de ToR's bereiken - hun AS-Path zal alleen ASN 65535 hebben - het aantal AS Edge-Leafs, omdat ze daar zijn gemaakt.

Waarom zijn ze verschillend in verschillende DC's?

Theoretisch gezien moeten we Loopback en sommige virtuele servicemachines mogelijk tussen DC's slepen.

Op de host zullen we bijvoorbeeld Route Reflector of dezelfde VNGW (Virtual Network Gateway), die via BGP met TopR wordt vergrendeld en de loopback aankondigt, die toegankelijk moet zijn vanaf alle DC's.

Dit is dus hoe het AS-Path er uit zal zien:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

En er mogen nergens dubbele ASN's voorkomen.

Dat wil zeggen dat Spine_DC1 en Spine_DC2 verschillend moeten zijn, net als leafX_DC1 en leafY_DC2, en dat is precies wat we benaderen.

Zoals u waarschijnlijk weet, zijn er hacks waarmee u routes met dubbele ASN's kunt accepteren, ondanks het luspreventiemechanisme (allowas-in op Cisco). En het heeft zelfs legitieme toepassingen. Maar dit is een potentieel gat in de stabiliteit van het netwerk. En ik ben er persoonlijk een paar keer in verzeild geraakt.

En als we de mogelijkheid hebben om geen gevaarlijke dingen te gebruiken, zullen we daarvan profiteren.

Blad ASN

We zullen een individuele ASN hebben op elke Leaf-switch in het hele netwerk.
We doen dit om de hierboven gegeven redenen: AS-Path zonder lussen, BGP-configuratie zonder bladwijzers.

Om routes tussen Leafs soepel te laten verlopen, moet het AS-Path er als volgt uitzien:
[leafX_ASN, spine_ASN, leafY_ASN]
waarbij leafX_ASN en leafY_ASN leuk zouden zijn om verschillend te zijn.

Dit is ook nodig voor de situatie met de aankondiging van een VNF-loopback tussen DC's:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

We zullen een 4-byte ASN gebruiken en deze genereren op basis van de Spine's ASN en het Leaf-schakelaarnummer, namelijk als volgt: Rug_ASN.0000X.

Dit is de foto met ASN.

IP-abonnement

In principe moeten we adressen toewijzen voor de volgende verbindingen:

1. Onderleg netwerkadressen tussen ToR en machine. Ze moeten uniek zijn binnen het hele netwerk, zodat elke machine met elke andere machine kan communiceren. Geweldige pasvorm 10/8. Voor elk rek zijn er /26 met een reserve. We wijzen /19 per DC en /17 per regio toe.
2. Koppel adressen tussen Leaf/Tor en Spine.

   Ik zou ze algoritmisch willen toewijzen, dat wil zeggen ze berekenen op basis van de namen van de apparaten die moeten worden verbonden.

   Laat het zijn... 169.254.0.0/16.
   Namelijk 169.254.00X.Y/31Waar X - Rugnummer, Y — P2P-netwerk /31.
   Hiermee kun je maximaal 128 racks en maximaal 10 Spines in de DC lanceren. Linkadressen kunnen (en zullen) worden herhaald van DC naar DC.

3. We organiseren het Spine-Edge-Leaf-knooppunt op subnetten 169.254.10X.Y/31, waar precies hetzelfde is X - Rugnummer, Y — P2P-netwerk /31.
4. Koppel adressen van Edge-Leaf naar MPLS-backbone. Hier is de situatie enigszins anders: de plaats waar alle stukken in één taart zijn verbonden, dus het hergebruiken van dezelfde adressen zal niet werken - je moet het volgende vrije subnet selecteren. Laten we daarom als basis nemen 192.168.0.0/16 en wij zullen de vrijen eruit harken.
5. Loopback-adressen. Wij geven het hele assortiment voor hen 172.16.0.0/12.
   • Leaf - /25 per DC - dezelfde 128 racks. We wijzen /23 per regio toe.
   • Ruggengraat - /28 per DC - maximaal 16 ruggengraat. Laten we /26 per regio toewijzen.
   • Edge-Leaf - /29 per DC - maximaal 8 dozen. Laten we /27 per regio toewijzen.

Als we niet genoeg toegewezen bereiken in de DC hebben (en die zullen er ook niet zijn – we beweren hyperscalers te zijn), selecteren we eenvoudigweg het volgende blok.

Dit is de afbeelding met IP-adressering.

Loopbacks:

voorvoegsel
Apparaatrol
Regio
ДЦ

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
is

172.16.2.0/23
wervelkolom
 
 

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
is

172.16.8.0/21
blad
 
 

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
is

Onderlaag:

voorvoegsel
Regio
ДЦ

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
is

Laba

Twee verkopers. Eén netwerk. ADSM.

Jeneverbes + Arista. Ubuntu. Goede oude Eva.

De hoeveelheid bronnen op onze virtuele server in Mirana is nog steeds beperkt, dus voor de praktijk zullen we een netwerk gebruiken dat tot het uiterste is vereenvoudigd.

Twee datacenters: Kazan en Barcelona.

• Elk twee stekels: Juniper en Arista.
• Eén torus (Leaf) in elk - Juniper en Arista, met één verbonden host (laten we hiervoor een lichtgewicht Cisco IOL nemen).
• Elk één Edge-Leaf-knooppunt (voor nu alleen Juniper).
• Eén Cisco-switch om ze allemaal te besturen.
• Naast de netwerkboxen draait er een virtuele besturingsmachine. Ubuntu uitvoeren.
  Het heeft toegang tot alle apparaten, het kan IPAM/DCIM-systemen draaien, een heleboel Python-scripts, Ansible en al het andere dat we nodig hebben.

Volledige configuratie van alle netwerkapparaten, die we zullen proberen te reproduceren met behulp van automatisering.

Conclusie

Wordt dat ook geaccepteerd? Moet ik onder elk artikel een korte conclusie schrijven?

Dus wij kozen drie niveaus Sluit het netwerk binnen het DC af, omdat we veel Oost-West-verkeer verwachten en ECMP willen.

Het netwerk werd opgedeeld in fysiek (underlay) en virtueel (overlay). Tegelijkertijd begint de overlay bij de host, waardoor de vereisten voor de ondervloer worden vereenvoudigd.

We hebben BGP gekozen als routeringsprotocol voor netwerknetwerken vanwege de schaalbaarheid en beleidsflexibiliteit.

We zullen aparte knooppunten hebben voor het organiseren van DCI - Edge-leaf.
De backbone zal OSPF+LDP hebben.
DCI zal worden geïmplementeerd op basis van MPLS L3VPN.
Voor P2P-koppelingen berekenen we IP-adressen algoritmisch op basis van apparaatnamen.
We zullen loopbacks toewijzen op basis van de rol van de apparaten en hun locatie.
Onderlaagvoorvoegsels - alleen op Leaf-schakelaars, opeenvolgend op basis van hun locatie.

Laten we aannemen dat we de apparatuur op dit moment nog niet hebben geïnstalleerd.
Onze volgende stappen zullen daarom zijn om ze aan de systemen toe te voegen (IPAM, inventaris), de toegang te organiseren, een configuratie te genereren en deze in te zetten.

In het volgende artikel zullen we ingaan op Netbox - een inventarisatie- en beheersysteem voor IP-ruimte in een DC.

Bedankt

• Andrey Glazkov oftewel @glazgoo voor proeflezen en correcties
• Alexander Klimenko oftewel @v00lk voor proeflezen en bewerken
• Artjom Chernobay voor KDPV

Bron: www.habr.com