I de to første artiklene tok jeg opp spørsmålet om automatisering og skisserte rammeverket, i den andre tok jeg et tilfluktssted til nettverksvirtualisering, som den første tilnærmingen til å automatisere konfigurasjonen av tjenester.
Nå er det på tide å tegne et diagram over det fysiske nettverket.

Hvis du ikke er kjent med å sette opp datasenternettverk, anbefaler jeg på det sterkeste å starte med artikler om dem.

Alle problemer:

• 0. ADSM. Del null. Planlegger
• 1. ADSM. Del én (som er etter null). Nettverksvirtualisering
• 2. ADSM. Andre del. Nettverksdesign

Fremgangsmåten beskrevet i denne serien bør gjelde for alle typer nettverk, uansett størrelse, med en rekke leverandører (ikke). Det er imidlertid umulig å beskrive et universelt eksempel på anvendelsen av disse tilnærmingene. Derfor vil jeg fokusere på den moderne arkitekturen til DC-nettverket: Kloz fabrikk.
Vi vil gjøre DCI på MPLS L3VPN.

Et overleggsnettverk kjører på toppen av det fysiske nettverket fra verten (dette kan være OpenStacks VXLAN eller Tungsten Fabric eller noe annet som krever bare grunnleggende IP-tilkobling fra nettverket).

I dette tilfellet får vi et relativt enkelt scenario for automatisering, fordi vi har mye utstyr som er konfigurert på samme måte.

Vi vil velge en sfærisk DC i et vakuum:

• Én designversjon overalt.
• To leverandører som danner to nettverksplaner.
• En DC er som en annen som to erter i en belg.

Innhold

• Fysisk topologi
• Ruting
• IP-plan
• Laba
• Konklusjon
• Nyttige lenker

La vår tjenesteleverandør LAN_DC, for eksempel, være vert for opplæringsvideoer om å overleve i fastkjørte heiser.

I megabyer er dette veldig populært, så du trenger mange fysiske maskiner.

Først vil jeg beskrive nettverket omtrent slik jeg ønsker det skal være. Og så skal jeg forenkle det for laboratoriet.

Fysisk topologi

Steder

LAN_DC vil ha 6 DC-er:

• Russland (RU):
  • Moskva (msk)
  • Kazan (kzn)

• Spania (SP):
  • Barcelona (bcn)
  • Malaga (MLG)

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

Inside DC (Intra-DC)

Alle DC-er har identiske interne tilkoblingsnettverk basert på Clos-topologi.
Hva slags Clos-nettverk er de og hvorfor er de i et separat artikkel.

Hver DC har 10 stativer med maskiner, de vil bli nummerert som A, B, C Og så videre.

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

Også i hvert stativ er det en bryter som alle maskiner er koblet til - dette er Toppen av stativbryteren - ToR eller på annen måte, når det gjelder Clos-fabrikken, vil vi kalle det Blad.

Generelt diagram over fabrikken.

Vi vil ringe dem XXX-bladYDer XXX - tre-bokstavs forkortelse DC, og Y - serienummer. For eksempel, kzn-blad11.

I artiklene mine vil jeg tillate meg å bruke begrepene Leaf og ToR ganske useriøst som synonymer. Vi må imidlertid huske at dette ikke er tilfelle.
ToR er en bryter installert i et stativ som maskiner er koblet til.
Leaf er rollen til en enhet i et fysisk nettverk eller en førstenivåsvitsj når det gjelder Cloes-topologi.
Det vil si Leaf != ToR.
Så Leaf kan for eksempel være en EndofRaw-bryter.
Men innenfor rammen av denne artikkelen vil vi fortsatt behandle dem som synonymer.

Hver ToR-svitsj er igjen koblet til fire aggregeringsbrytere på høyere nivå - Spine. Ett stativ i DC er tildelt for Spines. Vi vil navngi det på samme måte: XXX-ryggradY.

Det samme racket vil inneholde nettverksutstyr for tilkobling mellom DC - 2-ruterne med MPLS ombord. Men stort sett er dette de samme ToR-ene. Det vil si at fra synspunktet til Spine-brytere spiller den vanlige ToR-en med tilkoblede maskiner eller en ruter for DCI ingen rolle i det hele tatt - bare videresending.

Slike spesielle ToR-er kalles Kant-blad. Vi vil ringe dem XXX-kantY.

Det vil se slik ut.

I diagrammet ovenfor plasserte jeg faktisk kant og blad på samme nivå. Klassiske trelags nettverk De lærte oss å vurdere uplinking (derav begrepet) som uplinks. Og her viser det seg at DCI "uplink" går ned igjen, noe som for noen bryter litt med den vanlige logikken. Når det gjelder store nettverk, når datasentre er delt inn i enda mindre enheter - POD's (Point Of Delivery), fremhev individ Edge-POD's for DCI og tilgang til eksterne nettverk.

For å lette oppfatningen i fremtiden vil jeg fortsatt tegne Edge over Spine, mens vi vil huske på at det ikke er noen intelligens på Spine og det er ingen forskjeller når man arbeider med vanlig Leaf og Edge-leaf (selv om det kan være nyanser her , men generelt er dette sant).

Opplegg av en fabrikk med kantblader.

Treenigheten av Leaf, Spine og Edge danner et underlagsnettverk eller fabrikk.

Oppgaven til en nettverksfabrikk (les Underlag), som vi allerede har definert i siste nummer, veldig, veldig enkelt - å gi IP-tilkobling mellom maskiner både innenfor samme DC og mellom dem.
Derfor kalles nettverket en fabrikk, akkurat som for eksempel en koblingsfabrikk inne i modulære nettverksbokser, som du kan lese mer om i SDSM14.

Generelt kalles en slik topologi en fabrikk, fordi stoff i oversettelse betyr stoff. Og det er vanskelig å være uenig:

Fabrikken er helt L3. Ingen VLAN, ingen kringkasting - vi har så fantastiske programmerere på LAN_DC, de vet hvordan de skal skrive applikasjoner som lever i L3-paradigmet, og virtuelle maskiner krever ikke Live Migration med bevaring av IP-adressen.

Og nok en gang: svaret på spørsmålet hvorfor fabrikken og hvorfor L3 er i en separat artikkel.

DCI - Data Center Interconnect (Inter-DC)

DCI vil bli organisert ved hjelp av Edge-Leaf, det vil si at de er vårt utgangspunkt til motorveien.
For enkelhets skyld antar vi at DC-ene er koblet til hverandre med direkte lenker.
La oss utelukke ekstern tilkobling fra vurdering.

Jeg er klar over at hver gang jeg fjerner en komponent, forenkler jeg nettverket betydelig. Og når vi automatiserer det abstrakte nettverket vårt, vil alt være bra, men på det ekte vil det være krykker.
Dette er sant. Likevel er poenget med denne serien å tenke og jobbe med tilnærminger, ikke å heroisk løse imaginære problemer.

På Edge-Leafs plasseres underlaget i VPN og overføres gjennom MPLS-ryggraden (samme direkte lenke).

Dette er toppnivådiagrammet vi får.

Ruting

For ruting innenfor DC vil vi bruke BGP.
På MPLS-stammen OSPF+LDP.
For DCI, det vil si organisering av tilkobling i undergrunnen - BGP L3VPN over MPLS.

Generell ruteordning

Det er ingen OSPF eller ISIS (ruteprotokoll forbudt i den russiske føderasjonen) på fabrikken.

Dette betyr at det ikke vil være noen automatisk oppdagelse eller beregning av korteste veier - bare manuell (faktisk automatisk - vi snakker om automatisering her) oppsett av protokoll, nabolag og retningslinjer.

BGP-ruteskjema innen DC

Hvorfor BGP?

Om dette emnet er det hele RFC oppkalt etter Facebook og Arista, som forteller hvordan man bygger veldig stor datasenternettverk som bruker BGP. Den leser nesten som fiksjon, jeg anbefaler den på det varmeste for en sløv kveld.

Og det er også en hel del i artikkelen min dedikert til dette. Hvor tar jeg deg og jeg sender.

Men likevel, kort sagt, er ingen IGP egnet for nettverk av store datasentre, hvor antall nettverksenheter går i tusenvis.

I tillegg vil bruk av BGP overalt tillate deg å ikke kaste bort tid på å støtte flere forskjellige protokoller og synkronisering mellom dem.

Hånden på hjertet, i vår fabrikk, som med høy grad av sannsynlighet ikke vil vokse raskt, vil OSPF være nok for øynene. Dette er faktisk problemene til megaskalere og sky-titaner. Men la oss forestille oss bare for noen få utgivelser at vi trenger det, og vi vil bruke BGP, som Pyotr Lapukhov testamenterte.

Rutingpolicyer

På Leaf-svitsjer importerer vi prefikser fra Underlay-nettverksgrensesnitt til BGP.
Vi vil ha en BGP økt mellom kl hver et Leaf-Spine-par, der disse Underlay-prefiksene vil bli annonsert over nettverket frem og tilbake.

Innenfor ett datasenter vil vi distribuere spesifikasjonene som vi importerte til ToRe. På Edge-Leafs vil vi samle dem og kunngjøre dem til eksterne DC-er og sende dem ned til TOR-er. Det vil si at hver ToR vil vite nøyaktig hvordan man kommer til en annen ToR i samme DC og hvor inngangspunktet er å komme til ToR i en annen DC.

I DCI vil ruter bli overført som VPNv4. For å gjøre dette, på Edge-Leaf, vil grensesnittet mot fabrikken bli plassert i en VRF, la oss kalle det UNDERLAY, og nabolaget med Spine on Edge-Leaf vil stige innenfor VRF, og mellom Edge-Leafs i VPNv4- familie.

Vi vil også forby re-kunngjøring av ruter mottatt fra spines tilbake til dem.

På Leaf and Spine vil vi ikke importere Loopbacks. Vi trenger dem bare for å finne ruter-IDen.

Men på Edge-Leafs importerer vi det til Global BGP. Mellom Loopback-adresser vil Edge-Leafs etablere en BGP-økt i IPv4 VPN-familien med hverandre.

Vi vil ha en OSPF+LDP-ryggrad mellom EDGE-enheter. Alt er i én sone. Ekstremt enkel konfigurasjon.

Dette er bildet med ruting.

BGP ASN

Edge-Leaf ASN

Edge-Leafs vil ha ett ASN i alle DC-er. Det er viktig at det er iBGP mellom Edge-Leafs, og vi blir ikke fanget opp i nyansene til eBGP. La det være 65535. I realiteten kan dette være nummeret til et offentlig AS.

Ryggraden ASN

På Spine vil vi ha ett ASN per DC. La oss starte her med det aller første nummeret fra utvalget til private AS - 64512, 64513 Og så videre.

Hvorfor ASN på DC?

La oss dele dette spørsmålet ned i to:

• Hvorfor er ASN-ene de samme på alle spines på en DC?
• Hvorfor er de forskjellige i forskjellige DC-er?

Hvorfor er de samme ASN-ene på alle ryggradene til en DC?

Slik vil AS-Path of the Underlay-ruten på Edge-Leaf se ut:
[leafX_ASN, spine_ASN, edge_ASN]
Når du prøver å annonsere den tilbake til Spine, vil den forkaste den fordi AS (Spine_AS) allerede er på listen.

Innenfor DC er vi imidlertid helt fornøyd med at Underlay-rutene som går opp til Edge ikke vil kunne gå ned. All kommunikasjon mellom verter i DC må skje innenfor ryggraden.

Samtidig vil de aggregerte rutene til andre DC-er uansett lett nå ToR-ene - deres AS-Path vil kun ha ASN 65535 - antallet AS Edge-Leafs, fordi det er der de ble opprettet.

Hvorfor er de forskjellige i forskjellige DC-er?

Teoretisk sett kan det hende vi må dra Loopback og noen virtuelle tjenester mellom DC-er.

For eksempel vil vi på verten kjøre Route Reflector eller samme VNGW (Virtual Network Gateway), som vil låse med TopR via BGP og kunngjøre sin loopback, som skal være tilgjengelig fra alle DC-er.

Så dette er hvordan AS-banen vil se ut:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Og det skal ikke være dupliserte ASN-er noe sted.

Det vil si at Spine_DC1 og Spine_DC2 må være forskjellige, akkurat som leafX_DC1 og leafY_DC2, som er akkurat det vi nærmer oss.

Som du sikkert vet, finnes det hacks som lar deg akseptere ruter med dupliserte ASN-er til tross for løkkeforebyggende mekanisme (allowas-in på Cisco). Og det har til og med legitime bruksområder. Men dette er et potensielt gap i nettverkets stabilitet. Og jeg personlig falt i det et par ganger.

Og hvis vi har muligheten til å ikke bruke farlige ting, vil vi utnytte det.

Blad ASN

Vi vil ha et individuelt ASN på hver Leaf-svitsj i hele nettverket.
Vi gjør dette av grunnene gitt ovenfor: AS-Path uten løkker, BGP-konfigurasjon uten bokmerker.

For at ruter mellom Leafs skal passere jevnt, bør AS-stien se slik ut:
[leafX_ASN, spine_ASN, leafY_ASN]
der leafX_ASN og leafY_ASN ville vært fint å være forskjellige.

Dette er også nødvendig for situasjonen med kunngjøringen av en VNF loopback mellom DC:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Vi vil bruke en 4-byte ASN og generere den basert på Spines ASN og Leaf-bryternummeret, nemlig slik: Spine_ASN.0000X.

Dette er bildet med ASN.

IP-plan

I utgangspunktet må vi tildele adresser for følgende tilkoblinger:

1. Underlegg nettverksadresser mellom ToR og maskin. De må være unike i hele nettverket slik at enhver maskin kan kommunisere med hvilken som helst annen. Flott passform 10/8. For hvert stativ er det /26 med reserve. Vi vil tildele /19 per DC og /17 per region.
2. Link adresser mellom Leaf/Tor og Spine.

   Jeg vil gjerne tildele dem algoritmisk, det vil si å beregne dem fra navnene på enhetene som må kobles til.

   La det være... 169.254.0.0/16.
   nemlig 169.254.00X.Y/31Der X - ryggradsnummer, Y — P2P-nettverk /31.
   Dette lar deg starte opptil 128 stativer og opptil 10 Spines i DC. Linkadresser kan (og vil) gjentas fra DC til DC.

3. Vi organiserer Spine-Edge-Leaf-krysset på subnett 169.254.10X.Y/31, hvor akkurat det samme X - ryggradsnummer, Y — P2P-nettverk /31.
4. Koble adresser fra Edge-Leaf til MPLS-ryggrad. Her er situasjonen noe annerledes - stedet hvor alle brikkene er koblet sammen til en kake, så gjenbruk av de samme adressene vil ikke fungere - du må velge neste ledige subnett. La oss derfor ta utgangspunkt i 192.168.0.0/16 og vi vil rake ut de gratis fra den.
5. Loopback-adresser. Vi vil gi hele utvalget for dem 172.16.0.0/12.
   • Blad - /25 pr DC - samme 128 stativer. Vi vil tildele /23 per region.
   • Spine - /28 per DC - opptil 16 Spine. La oss tildele /26 per region.
   • Edge-Leaf - /29 per DC - opptil 8 bokser. La oss tildele /27 per region.

Hvis vi ikke har nok tildelte områder i DC (og det vil ikke være noen - vi hevder å være hyperskalere), velger vi bare neste blokk.

Dette er bildet med IP-adressering.

Loopbacks:

prefiks
Enhetsrolle
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
ryggraden
 
 

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:

prefiks
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 leverandører. Ett nettverk. ADSM.

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

Ressursmengden på vår virtuelle server i Mirana er fortsatt begrenset, så for praksis vil vi bruke et nettverk som er forenklet til det ytterste.

To datasentre: Kazan og Barcelona.

• To pigger hver: Juniper og Arista.
• En torus (Leaf) i hver - Juniper og Arista, med en tilkoblet vert (la oss ta en lett Cisco IOL for dette).
• Én Edge-Leaf-node hver (foreløpig kun Juniper).
• Én Cisco-svitsj for å styre dem alle.
• I tillegg til nettverksboksene kjører en virtuell kontrollmaskin. Kjører Ubuntu.
  Den har tilgang til alle enheter, den vil kjøre IPAM/DCIM-systemer, en haug med Python-skript, Ansible og alt annet vi måtte trenge.

Full konfigurasjon av alle nettverksenheter, som vi vil prøve å reprodusere ved hjelp av automatisering.

Konklusjon

Er det også akseptert? Bør jeg skrive en kort konklusjon under hver artikkel?

Så vi valgte tre-nivå Kloz-nettverket inne i DC, siden vi forventer mye øst-vest-trafikk og ønsker ECMP.

Nettverket ble delt inn i fysisk (underlag) og virtuelt (overlegg). Samtidig starter overlegget fra verten - og forenkler dermed kravene til underlaget.

Vi valgte BGP som rutingprotokoll for nettverksnettverk på grunn av dens skalerbarhet og policyfleksibilitet.

Vi vil ha separate noder for organisering av DCI - Edge-leaf.
Ryggraden vil ha OSPF+LDP.
DCI vil bli implementert basert på MPLS L3VPN.
For P2P-koblinger vil vi beregne IP-adresser algoritmisk basert på enhetsnavn.
Vi vil tildele loopbacks i henhold til rollen til enhetene og deres plassering sekvensielt.
Underlagsprefikser - bare på Leaf-brytere sekvensielt basert på deres plassering.

La oss anta at vi ikke har utstyret installert akkurat nå.
Derfor vil våre neste trinn være å legge dem til systemene (IPAM, inventar), organisere tilgang, generere en konfigurasjon og distribuere den.

I neste artikkel skal vi ta for oss Netbox - et inventar- og styringssystem for IP-plass i en DC.

Takk skal du ha

• Andrey Glazkov aka @glazgoo for korrekturlesing og rettelser
• Alexander Klimenko aka @v00lk for korrekturlesing og redigeringer
• Artyom Chernobay for KDPV

Kilde: www.habr.com