I de to første artikler rejste jeg spørgsmålet om automatisering og skitserede dens rammer, i den anden foretog jeg en digression til netværksvirtualisering, som den første tilgang til automatisering af tjenestekonfiguration.
Og nu er det tid til at tegne et diagram over det fysiske netværk.

Hvis du ikke er på kort fod med organiseringen af ​​datacenternetværk, så anbefaler jeg kraftigt at starte med artikler om dem.

Alle udgivelser:

• 0. ADSM. Del nul. Planlægning
• 1. ADSM. Del et (som er efter nul). Netværksvirtualisering
• 2. ADSM. Del to. Netværksdesign

Den praksis, der er beskrevet i denne serie, bør kunne anvendes på enhver type netværk, enhver skala og enhver række leverandører (nej). Det er imidlertid umuligt at beskrive et universelt eksempel på anvendelsen af ​​disse tilgange. Derfor vil jeg fokusere på DC-netværkets moderne arkitektur: Kloz fabrik.
Vi vil lave DCI på MPLS L3VPN.

Oven i det fysiske netværk er der et Overlay-netværk fra værten (dette kan være OpenStacks VXLAN eller Tungsten Fabric eller andet, der kun kræver grundlæggende IP-forbindelse fra netværket).

I dette tilfælde får vi et relativt simpelt scenarie for automatisering, fordi vi har meget udstyr konfigureret på samme måde.

Vi vælger en sfærisk DC i vakuum:

• Én designversion overalt.
• To leverandører, der danner to netværksplaner.
• En DC er som en anden som to dråber vand.

Indhold

• Fysisk topologi
• Routing
• IP-plan
• Laba
• Konklusion
• Nyttige links

Lad vores serviceudbyder LAN_DC for eksempel være vært for træningsvideoer om overlevende fastlåste elevatorer.

I megabyer er dette vildt populært, så du har brug for mange fysiske maskiner.

Først vil jeg beskrive netværket omtrent som jeg gerne vil se det. Og så vil jeg forenkle for laboratoriet.

Fysisk topologi

Placeringer

LAN_DC vil have 6 DC'er:

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

• Spanien (SP):
  • Barcelona (bcn)
  • Malaga (mlg)

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

Inde i DC (Intra-DC)

Alle DC'er har identiske interne tilslutningsnetværk baseret på Klose-topologien.
Hvad er Kloz-netværk, og hvorfor præcist er de - i en separat artiklen.

Hver DC har 10 stativer med biler, de vil blive nummereret som A, B, C Og så videre.

Hvert stativ har 30 maskiner. De vil ikke interessere os.

Også i hvert rack er der en kontakt, som alle maskiner er tilsluttet - dette er Top of the Rack switch - ToR eller på anden måde, hvad angår Klose-fabrikken, vil vi kalde det Leaf.

Generel ordning af fabrikken.

Vi vil navngive dem XXX-bladYHvor XXX - tre bogstaver forkortelse DC, og Y - serienummer. For eksempel, kzn-blad11.

I mine artikler vil jeg tillade mig at bruge begreberne Leaf og ToR ret useriøst som synonymer. Det skal dog huskes, at dette ikke er tilfældet.
ToR er en rackmonteret switch, som maskiner tilsluttes.
Leaf er rollen som en enhed i et fysisk netværk eller en switch på første niveau i forhold til Klose-topologien.
Altså Blad != ToR.
Så en Leaf kan for eksempel være en EndofRaw-switch.
Inden for rammerne af denne artikel vil vi dog stadig behandle dem som synonymer.

Hver ToR-switch er igen forbundet med fire højere aggregeringsafbrydere - Rygrad. Under Spine's er der tildelt et rack i DC. Vi vil navngive det sådan: XXX-rygradY.

I samme rack vil der være netværksudstyr til tilslutning mellem DC'ere - 2 routere med MPLS ombord. Men i det store og hele er det de samme Tors. Det vil sige, set fra Spine switches synspunkt er det ligegyldigt den sædvanlige ToR med tilsluttede maskiner eller en router til DCI - en forbandet ting.

Sådanne specielle ToR'er kaldes Kant-blad. Vi vil navngive dem XXX-kantY.

Det vil se sådan ud.

I diagrammet ovenfor placerede jeg virkelig kant og blad på samme niveau. Klassiske tre-lags netværk lærte os at betragte uplink (faktisk, deraf udtrykket) som links up. Og her viser det sig, at DCI "uplink" går ned igen, hvilket bryder den sædvanlige logik lidt for nogle. I tilfælde af store netværk, når datacentre er opdelt i endnu mindre enheder - POD's (Point Of Delivery), alloker individuelle Edge-POD's til DCI og adgang til eksterne netværk.

For at lette opfattelsen i fremtiden vil jeg stadig tegne Edge over Spine, mens vi vil huske på, at der ikke er nogen intelligens på Spine, og der er ingen forskelle, når man arbejder med almindelige Leaf og med Edge-leaf (selvom der kan være nuancer , men generelt er dette sandt).

Fabriksdiagram med kantblade.

Treenigheden Leaf, Spine og Edge danner et Underlay-netværk eller en fabrik.

Netværksfabrikkens opgave (læs Underlay), som vi allerede har defineret i sidste nummer, meget, meget enkelt - at give IP-forbindelse mellem maskiner både inden for samme DC og mellem dem.
Derfor kaldes netværket for en fabrik ligesom for eksempel en koblingsfabrik inde i modulære netværksbokse, som du kan læse mere om i SDSM14.

Generelt kaldes en sådan topologi en fabrik, fordi stof i oversættelse er et stof. Og det er svært at være uenig:

Fabrikken er helt L3. Ingen VLAN'er, ingen Broadcast - det er de vidunderlige programmører, vi har i LAN_DC, de kan skrive applikationer, der lever i L3-paradigmet, og virtuelle maskiner kræver ikke Live Migration med at gemme IP-adressen.

Og endnu en gang: svaret på spørgsmålet, hvorfor fabrikken og hvorfor L3 er i en separat artiklen.

DCI - Data Center Interconnect (Inter-DC)

DCI vil blive organiseret med hjælp fra Edge-Leaf, det vil sige, at de er vores udgangssted til motorvejen.
For nemheds skyld antager vi, at DC'er er forbundet med direkte forbindelser.
Lad os udelukke den eksterne forbindelse fra overvejelse.

Jeg er klar over, at hver gang jeg fjerner en komponent, forenkler jeg netværket i høj grad. Og når vi automatiserer vores abstrakte netværk, vil alt være fint, men krykker vil dukke op på den rigtige.
Det er rigtigt. Og alligevel er formålet med denne serie at tænke og arbejde på tilgange, og ikke at heroisk løse fiktive problemer.

På Edge-Leafs placeres underlaget i VPN'en og transmitteres gennem MPLS-rygraden (det samme direkte link).

Her er sådan en ordning på topniveau opnået.

Routing

Til routing inde i DC vil vi bruge BGP.
På OSPF+LDP MPLS-rygraden.
For DCI, det vil sige organiseringen af ​​tilslutning i underlaget - BGP L3VPN over MPLS.

Generel ruteplan

Der er ingen OSPF og ISIS på fabrikken (routingprotokol forbudt i Den Russiske Føderation).

Og det betyder, at der ikke vil være nogen automatisk opdagelse og beregning af de korteste veje - kun manuelle (faktisk automatisk - vi taler om automatisering her) protokol, naboskab og politikindstillinger.

BGP-routingskema inde i DC

Hvorfor BGP?

Der er hele RFC opkaldt efter Facebook og Arista, som fortæller, hvordan man bygger meget store datacenternetværk ved hjælp af BGP. Den lyder næsten som en fiktion, jeg kan varmt anbefale den til en sløv aften.

Der er også et helt afsnit i min artikel om dette. Hvor kan jeg tage dig hen og sende.

Men alligevel, kort sagt, er ingen IGP egnet til netværk af store datacentre, hvor antallet af netværksenheder går i tusindvis.

Derudover vil brugen af ​​BGP overalt give dig mulighed for ikke at sprøjte på understøttelse af flere forskellige protokoller og synkronisering mellem dem.

Hånden på hjertet, i vores fabrik, som højst sandsynligt ikke vil vokse hurtigt, vil OSPF være nok for vores øjne. Dette er faktisk problemet med mega scalers og cloud-titaner. Men lad os fantasere for nogle få problemer, at vi har brug for det, og vi vil bruge BGP, som Peter Lapukhov testamenterede.

Rutepolitikker

På Leaf-switches importerer vi præfikser fra Underlay-netværksgrænseflader til BGP.
Vi holder en BGP session mellem kl hver et par Leaf-Spine, hvor disse Underlay-præfikser vil blive annonceret over netværket hist og her.

Inde i ét datacenter vil vi distribuere de detaljer, som vi importerede til Tor. På Edge-Leafs vil vi samle dem og annoncere dem til fjerntliggende DC'er og sende dem ned til Tors. Det vil sige, at hver Tor ved nøjagtigt, hvordan man kommer til en anden Tor i samme DC, og hvor er indgangspunktet for at komme til Tor i en anden DC.

I DCI vil ruter blive transmitteret som VPNv4. For at gøre dette, på Edge-Leaf, vil grænsefladen mod fabrikken blive placeret i VRF, lad os kalde det UNDERLAY, og kvarteret med Spine on the Edge-Leaf vil rejse sig inde i VRF, og mellem Edge-Leafs i VPNv4-familien.

Vi vil også forbyde genannoncering af ruter modtaget fra spines tilbage til dem.

På Leaf and Spine importerer vi ikke Loopbacks. Vi har kun brug for dem til at bestemme router-id'et.

Men på Edge-Leafs importerer vi det til Global BGP. Mellem Loopback-adresser vil Edge-Leafs etablere en BGP-session i en IPv4 VPN-familie med hinanden.

Mellem EDGE-enheder vil vi have en kuffert strakt til OSPF + LDP. Alt i én zone. Ekstremt enkel konfiguration.

Her er et billede med routing.

BGP ASN

Edge Leaf ASN

På Edge-Leafs vil der være én ASN i alle DC'er. Det er vigtigt, at der er iBGP mellem Edge-Leafs, og vi løber ikke ind i nuancerne af eBGP. Lad det være 65535. I virkeligheden kunne det være et offentligt AS-nummer.

Rygsøjlen ASN

På Spine vil vi have én ASN pr. DC. Lad os starte her fra det allerførste nummer fra rækken af ​​private AS - 64512, 64513 Og så videre.

Hvorfor ASN på DC?

Lad os opdele dette spørgsmål i to:

• Hvorfor det samme ASN på alle spines af en DC?
• Hvorfor er de forskellige i forskellige DC'er?

Hvorfor det samme ASN på alle spines af en DC

Sådan kommer AS-stien til Underlay-ruten på Edge-Leaf til at se ud:
[leafX_ASN, spine_ASN, edge_ASN]
Når du forsøger at annoncere det tilbage til Spine, vil det blive afvist, fordi dets AS (Spine_AS) allerede er på listen.

Inden for DC er vi dog helt tilfredse med, at de Underlay-ruter, der er steget til Edge, ikke vil kunne gå ned. Al kommunikation mellem værter i DC skal foregå inden for rygsøjlens niveau.

Samtidig vil de aggregerede ruter fra andre DC'er under alle omstændigheder frit nå Tors - deres AS-Path vil kun indeholde ASN 65535 - antallet af AS Edge-Leafs, fordi det var på dem, de blev oprettet.

Hvorfor er forskellige i forskellige DC'er

Teoretisk set kan vi være nødt til at trække Loopback og nogle virtuelle servicemaskiner mellem DC'er.

For eksempel vil vi på værten køre Route Reflector eller samme VNGW (Virtual Network Gateway), som vil låse sig med Tor via BGP og annoncere sin loopback, som burde være tilgængelig fra alle DC'er.

Så dette er, hvordan dens AS-sti vil se ud:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Og der bør ikke være gentagne ASN'er nogen steder.

Det vil sige, at Spine_DC1 og Spine_DC2 skal være forskellige, ligesom leafX_DC1 og leafY_DC2, hvilket er præcis det, vi nærmer os.

Som du sikkert ved, er der hacks, der giver dig mulighed for at acceptere ruter med duplikerede ASN'er på trods af mekanismen til forebyggelse af sløjfe (allowas-in på Cisco). Og det har endda legitime anvendelser. Men dette er et potentielt hul i netværkets stabilitet. Og jeg faldt personligt ind i det et par gange.

Og hvis vi har mulighed for ikke at bruge farlige ting, vil vi bruge det.

Blad ASN

Vi vil have et individuelt ASN på hver Leaf-switch inden for hele netværket.
Vi gør dette af ovenstående grunde: AS-Path uden loops, BGP-konfiguration uden bogmærker.

For at ruterne mellem Leafs kan passere jævnt, bør AS-Path se sådan ud:
[leafX_ASN, spine_ASN, leafY_ASN]
hvor leafX_ASN og leafY_ASN ville være rart at være forskellige.

Dette er også nødvendigt for situationen med annonceringen af ​​en VNF loopback mellem DC'er:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Vi vil bruge en 4-byte ASN og generere den baseret på ASN for Spine og nummeret på Leaf switchen, nemlig sådan her: Spine_ASN.0000X.

Her er sådan et billede med ASN.

IP-plan

Grundlæggende skal vi tildele adresser til følgende forbindelser:

1. Underlag netværksadresser mellem ToR og maskine. De skal være unikke i hele netværket, så enhver maskine kan kommunikere med enhver anden. Fantastisk pasform 10/8. For hver stativ / 26 med en margen. Vi vil tildele /19 pr. DC og /17 pr. region.
2. Link adresser mellem Leaf/Tor og Spine.

   Jeg vil gerne tildele dem algoritmisk, det vil sige, beregne ud fra navnene på de enheder, der skal tilsluttes.

   Lad det være... 169.254.0.0/16.
   nemlig 169.254.00X.Y/31Hvor X - Rygsøjlenummer, Y — P2P-netværk /31.
   Dette giver dig mulighed for at køre op til 128 stativer og op til 10 Spine i DC. Linkadresser kan (og vil) blive gentaget fra DC til DC.

3. Joint Spine - Edge-Leaf organisere på undernet 169.254.10X.Y/31, hvor nøjagtig det samme X - Rygsøjlenummer, Y — P2P-netværk /31.
4. Link adresser fra Edge-Leaf til MPLS backbone. Her er situationen noget anderledes - samlingen af ​​alle stykkerne til én tærte, så du vil ikke kunne genbruge de samme adresser - du skal vælge det næste gratis undernet. Derfor tager vi udgangspunkt i 192.168.0.0/16 og vi vil rive fri ud af det.
5. Loopback-adresser. Lad os give dem hele rækken 172.16.0.0/12.
   • Blad - /25 hver ved DC - de samme 128 stativer. Tildel /23 pr. region.
   • Spine - med /28 på DC - op til 16 Spine. Tildel /26 pr. region.
   • Edge-Leaf - /29 ved DC - op til 8 kasser. Tildel /27 pr. region.

Hvis vi ikke har nok tildelte områder i DC (og vi vil ikke have dem - vi foregiver at være hyperskalere), vælger vi simpelthen den næste blok.

Her er et billede med IP-adressering.

Loopbacks:

præfiks
Enhedsrolle
Region
DC

172.16.0.0/23
kant
 
 

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
rygsøjlen
 
 

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
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
sia

Underlag:

præfiks
Region
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

Laba

To sælgere. Et netværk. ADSM.

Juniper + Arista. Ubuntu. Gode ​​gamle Eva.

Mængden af ​​ressourcer på vores virtuelle maskine i Miran er stadig begrænset, så til praksis vil vi bruge et sådant forenklet netværk til det yderste.

To datacentre: Kazan og Barcelona.

• To spin hver: Juniper og Arista.
• En torus (blad) i hver - Juniper og Arista, med en tilsluttet vært (lad os tage en letvægts Cisco IOL til dette).
• Én Edge-Leaf node hver (kun Juniper indtil videre).
• Én Cisco-switch til at styre dem alle.
• Ud over netværksbokse er der lanceret en virtuel maskine-manager. Under Ubuntu.
  Det har adgang til alle enheder, det vil køre IPAM / DCIM-systemer, en masse Python-scripts, ansible og alt andet, vi måtte have brug for.

Fuld konfiguration alle netværksenheder, som vi vil forsøge at reproducere ved hjælp af automatisering.

Konklusion

Er det også accepteret? Under hver artikel for at lave en kort konklusion?

Så vi har valgt tre-niveau Kloz netværk inde i DC, fordi vi forventer meget øst-vest trafik og ønsker ECMP.

Vi opdelte netværket i fysisk (underlay) og virtuelt (overlay). Samtidig starter overlægget fra værten - og forenkler derved kravene til underlaget.

Valgte BGP som routerens routingprotokol på grund af dens skalerbarhed og politikfleksibilitet.

Vi vil have separate noder til at organisere DCI - Edge-leaf.
Der vil være OSPF+LDP på ​​rygraden.
DCI vil blive implementeret baseret på MPLS L3VPN.
For P2P-links vil vi beregne IP-adresser algoritmisk baseret på enhedsnavne.
Loopbacks vil blive tildelt i overensstemmelse med enhedernes rolle og deres placering sekventielt.
Underlagspræfikser - kun på bladafbrydere i serie baseret på deres placering.

Lad os antage, at vi ikke har noget udstyr installeret lige nu.
Derfor vil vores næste skridt være at få dem ind i systemer (IPAM, inventar), organisere adgang, generere en konfiguration og implementere den.

I den næste artikel vil vi beskæftige os med Netbox, et lager- og administrationssystem til IP-plads i en DC.

Tak

• Andrey Glazkov aka @glazgoo til korrekturlæsning og redigering
• Alexandru Klimenko aka @v00lk til korrekturlæsning og redigering
• Artyom Chernobay til KDPV

Kilde: www.habr.com