Kahdessa ensimmäisessä artikkelissa otin esiin automaation ja hahmottelin sen puitteet, toisessa vetäydyin verkon virtualisointiin, ensimmäisenä lähestymistapana palveluiden konfiguroinnin automatisoimiseen.
Nyt on aika piirtää kaavio fyysisestä verkosta.

Jos et ole perehtynyt datakeskusverkkojen asettamiseen, suosittelen vahvasti aloittamista artikkeleita niistä.

Kaikki ongelmat:

• 0. ADSM. Osa nolla. Suunnittelu
• 1. ADSM. Ensimmäinen osa (joka on nollan jälkeen). Verkon virtualisointi
• 2. ADSM. Osa kaksi. Verkon suunnittelu

Tässä sarjassa kuvattuja käytäntöjä tulisi soveltaa kaikentyyppisiin verkkoihin, minkä kokoisiin tahansa ja kaikenlaisiin toimittajiin (ei). On kuitenkin mahdotonta kuvata universaalia esimerkkiä näiden lähestymistapojen soveltamisesta. Siksi keskityn DC-verkon moderniin arkkitehtuuriin: Klozin tehdas.
Teemme DCI:n MPLS L3VPN:lle.

Overlay-verkko toimii fyysisen verkon päällä isännästä (tämä voi olla OpenStackin VXLAN tai Tungsten Fabric tai mikä tahansa muu, joka vaatii vain perus-IP-yhteyden verkosta).

Tässä tapauksessa saamme suhteellisen yksinkertaisen skenaarion automaatiolle, koska meillä on paljon laitteita, jotka on konfiguroitu samalla tavalla.

Valitsemme pallomaisen DC:n tyhjiössä:

• Yksi suunnitteluversio kaikkialla.
• Kaksi toimittajaa muodostavat kaksi verkkotasoa.
• Yksi DC on kuin toinen kuin kaksi hernettä palossa.

Pitoisuus

• Fyysinen topologia
• Reititys
• IP-suunnitelma
• Laba
• Johtopäätös
• Hyödyllisiä linkkejä

Anna palveluntarjoajamme LAN_DC esimerkiksi isännöidä koulutusvideoita jumiutuneista hisseistä selviytymisestä.

Megakaupungeissa tämä on erittäin suosittua, joten tarvitset paljon fyysisiä koneita.

Ensin kuvailen verkkoa suunnilleen sellaisena kuin haluaisin sen olevan. Ja sitten yksinkertaistan sen labraa varten.

Fyysinen topologia

Sijainnit

LAN_DC:ssä on 6 DC:tä:

• Venäjä (RU):
  • Moskova (MSK)
  • Kazan (kzn)

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

• Kiina (CN):
  • Shanghai (sha)
  • Xi'an (molemmat)

Inside DC (Intra-DC)

Kaikilla DC:illä on identtiset sisäiset liitäntäverkot, jotka perustuvat Clos-topologiaan.
Millaisia ​​Clos-verkot ne ovat ja miksi ne ovat erillään статье.

Jokaisessa DC:ssä on 10 telinettä koneineen, ne numeroidaan seuraavasti A, B, C Ja niin edelleen.

Jokaisessa telineessä on 30 konetta. He eivät kiinnosta meitä.

Myös jokaisessa telineessä on kytkin, johon kaikki koneet on kytketty - tämä on Telinekytkimen yläosa - ToR tai muuten, Closin tehtaan kannalta, kutsumme sitä Lehtiä.

Tehtaan yleinen kaavio.

Soitamme heille XXX-puun lehtiYMissä XXX - kolmikirjaiminen lyhenne DC ja Y - sarjanumero. Esimerkiksi, kzn-lehti11.

Artikkeleissani sallin itseni käyttää termejä Leaf ja ToR melko kevyesti synonyymeinä. Meidän on kuitenkin muistettava, että näin ei ole.
ToR on telineeseen asennettu kytkin, johon koneet liitetään.
Leaf on laitteen rooli fyysisessä verkossa tai ensimmäisen tason kytkimen Cloes-topologian kannalta.
Eli Leaf != ToR.
Joten Leaf voi olla esimerkiksi EndofRaw-kytkin.
Kuitenkin tämän artikkelin puitteissa käsittelemme niitä edelleen synonyymeinä.

Jokainen ToR-kytkin on vuorostaan ​​kytketty neljään korkeamman tason aggregaatiokytkimeen - Selkä. Yksi teline DC:ssä on varattu Spinesille. Nimeämme sen samalla tavalla: XXX-selkäY.

Sama teline sisältää verkkolaitteita DC - 2 -reitittimien väliseen liitäntään, jossa on MPLS. Mutta yleisesti ottaen nämä ovat samoja ToR:ita. Toisin sanoen Spine-kytkimien kannalta tavallisella ToR-liitännöillä tai DCI:n reitittimellä ei ole väliä - vain edelleenlähetys.

Tällaisia ​​erityisiä ToR:ita kutsutaan Reuna-lehti. Soitamme heille XXX-reunaY.

Se näyttää tältä.

Yllä olevassa kaaviossa asetin itse asiassa reunan ja lehden samalle tasolle. Klassiset kolmikerroksiset verkot He opettivat meidät pitämään uplinkiä (tästä termiä) ylöslinkkeinä. Ja tässä käy ilmi, että DCI:n "uplink" menee takaisin alas, mikä joillekin rikkoo hieman tavallista logiikkaa. Suurten verkkojen tapauksessa, kun datakeskukset jaetaan vielä pienempiin yksiköihin - POD's (Point Of Delivery), korosta henkilö Edge-POD's DCI:lle ja pääsylle ulkoisiin verkkoihin.

Havainnoinnin helpottamiseksi tulevaisuudessa piirrän edelleen Edge over Spinen, mutta pidämme mielessä, että Spinen ei sisällä älykkyyttä eikä eroja työskenneltäessä tavallisen Leafin ja Edge-leafin kanssa (vaikka tässä saattaa olla vivahteita , mutta yleisesti ottaen Tämä on totta).

Kaavio tehtaasta reunalehdillä.

Kolminaisuus Leaf, Spine ja Edge muodostavat Underlay-verkoston tai tehtaan.

Verkkotehtaan tehtävä (lue Underlay), kuten olemme jo määrittäneet viimeinen numero, erittäin, hyvin yksinkertainen - tarjota IP-yhteys koneiden välillä sekä samassa DC:ssä että niiden välillä.
Tästä syystä verkkoa kutsutaan tehtaaksi, kuten esimerkiksi modulaaristen verkkolaatikoiden sisällä olevaa kytkentätehdasta, josta voit lukea lisää SDSM14.

Yleensä tällaista topologiaa kutsutaan tehtaaksi, koska kangas käännöksessä tarkoittaa kangasta. Ja on vaikea olla eri mieltä:

Tehdas on täysin L3. Ei VLAN:ia, ei Broadcastia – meillä on niin upeita ohjelmoijia LAN_DC:ssä, he osaavat kirjoittaa sovelluksia, jotka elävät L3-paradigmassa, eivätkä virtuaalikoneet tarvitse live-siirtoa IP-osoitteen säilyttämisellä.

Ja vielä kerran: vastaus kysymykseen miksi tehdas ja miksi L3 on erillisessä статье.

DCI - Data Center Interconnect (Inter-DC)

DCI järjestetään Edge-Leafillä, eli ne ovat lähtöpisteemme moottoritielle.
Yksinkertaisuuden vuoksi oletetaan, että DC:t on kytketty toisiinsa suorilla linkeillä.
Jätetään ulkoinen liitettävyys huomiotta.

Tiedän, että joka kerta kun poistan komponentin, yksinkertaistan verkkoa merkittävästi. Ja kun automatisoimme abstraktin verkkomme, kaikki on hyvin, mutta todellisessa on kainalosauvat.
Tämä on totta. Tämän sarjan tarkoitus on kuitenkin ajatella ja työstää lähestymistapoja, ei sankarillisesti ratkaista kuvitteellisia ongelmia.

Edge-Leafsissä aluskate sijoitetaan VPN:ään ja lähetetään MPLS-runkoverkon kautta (sama suora linkki).

Tämä on huipputason kaavio, jonka saamme.

Reititys

Reititykseen DC:n sisällä käytämme BGP:tä.
MPLS-rungossa OSPF+LDP.
DCI:lle eli yhteyden järjestämiselle maanalaisessa - BGP L3VPN MPLS:n kautta.

Yleinen reitityskaavio

Tehtaalla ei ole OSPF- tai ISIS-protokollaa (Venäjän federaatiossa kielletty reititysprotokolla).

Tämä tarkoittaa, että automaattista etsintää tai lyhimpien polkujen laskemista ei tapahdu - vain manuaalinen (itse asiassa automaattinen - tässä puhumme automatisoinnista) protokollan, naapuruston ja käytäntöjen määrittäminen.

BGP-reititysjärjestelmä DC:ssä

Miksi BGP?

Tästä aiheesta on koko RFC Facebookin ja Aristan mukaan nimetty, joka kertoo kuinka rakentaa hyvin suuri tietokeskusverkot käyttämällä BGP:tä. Se lukee melkein kuin fiktiota, suosittelen sitä rauhoittavaan iltaan.

Ja artikkelissani on myös kokonainen osio, joka on omistettu tälle. Minne vien sinut ja Minä lähetän.

Mutta silti lyhyesti sanottuna mikään IGP ei sovellu suurten datakeskusten verkkoihin, joissa verkkolaitteita on tuhansia.

Lisäksi BGP:n käyttö kaikkialla mahdollistaa sen, että et tuhlaa aikaa useiden eri protokollien tukemiseen ja niiden väliseen synkronointiin.

Käsi sydämellä, tehtaallamme, joka suurella todennäköisyydellä ei kasva nopeasti, OSPF riittäisi silmille. Nämä ovat itse asiassa megaskaalaajien ja pilvititaanien ongelmia. Mutta kuvitellaan vain muutaman julkaisun osalta, että tarvitsemme sitä, ja käytämme BGP:tä, kuten Pjotr ​​Lapukhov testamentaa.

Reitityskäytännöt

Leaf-kytkimissä tuomme etuliitteet Underlay-verkkoliitännöistä BGP:hen.
Pidämme välillä BGP-istunnon kukin Leaf-Spine-pari, jossa nämä Underlay-etuliitteet ilmoitetaan verkossa siellä täällä.

Yhdessä palvelinkeskuksessa jaamme ToReen tuomamme tekniset tiedot. Edge-Leafsissä kokoamme ne yhteen ja ilmoitamme ne etätasayksiköille ja lähetämme ne alas TOR:ille. Tämä tarkoittaa, että jokainen ToR tietää tarkalleen, kuinka päästä toiseen ToR:ään samassa DC:ssä ja missä sisääntulopiste on päästä toR:iin toisessa DC:ssä.

DCI:ssä reitit lähetetään VPNv4:nä. Tätä varten Edge-Leafissä rajapinta tehtaalle sijoitetaan VRF:ään, kutsutaan sitä ALUSLAYKSiksi, ja Spine on Edge-Leaf -naapuruus nousee VRF:n sisällä ja Edge-Leafs-välinen VPNv4-. perhe.

Kiellämme myös spineiltä saatujen reittien uudelleenilmoittamisen takaisin niihin.

Leaf- ja Spine-sivustoilla emme tuo loopbackeja. Tarvitsemme niitä vain reitittimen tunnuksen määrittämiseen.

Mutta Edge-Leafsissä tuomme sen Global BGP:hen. Loopback-osoitteiden välillä Edge-Leafs muodostaa BGP-istunnon IPv4 VPN-perheeseen keskenään.

Meillä on OSPF+LDP-runkoverkko EDGE-laitteiden välillä. Kaikki on yhdellä vyöhykkeellä. Erittäin yksinkertainen kokoonpano.

Tämä on kuva reitityksellä.

BGP ASN

Edge-Leaf ASN

Edge-Leafsissä on yksi ASN kaikissa DC:issä. On tärkeää, että Edge-Leafsin välissä on iBGP, emmekä joudu eBGP:n vivahteisiin. Olkoon se 65535. Todellisuudessa tämä voi olla julkisen AS:n numero.

Selkä ASN

Spinellä meillä on yksi ASN per DC. Aloitetaan tästä ensimmäisestä numerosta yksityisten AS-numeroiden välillä - 64512, 64513 ja niin edelleen.

Miksi ASN DC:ssä?

Jaetaan tämä kysymys kahteen osaan:

• Miksi ASN:t ovat samat yhden DC:n kaikissa piikkeissä?
• Miksi ne eroavat eri DC:issä?

Miksi samat ASN:t ovat yhden DC:n kaikissa piikeissä?

Edge-Leafin Underlay-reitin AS-polku näyttää tältä:
[leafX_ASN, spine_ASN, edge_ASN]
Kun yrität mainostaa sitä takaisin Spinelle, se hylkää sen, koska sen AS (Spine_AS) on jo luettelossa.

DC:n sisällä olemme kuitenkin täysin tyytyväisiä siihen, että reunalle nousevat Underlay-reitit eivät voi mennä alas. Kaiken tiedonsiirron isäntien välillä DC:ssä on tapahduttava selkärangan tasolla.

Tässä tapauksessa muiden DC:iden aggregoidut reitit saavuttavat joka tapauksessa helposti ToR:t - niiden AS-polulla on vain ASN 65535 - AS Edge-Leafs -määrä, koska siellä ne luotiin.

Miksi ne eroavat eri DC:issä?

Teoriassa saatamme joutua vetämään Loopbackia ja joitain palvelun virtuaalikoneita DC:iden välillä.

Esimerkiksi isännässä käytämme Route Reflectoria tai sama VNGW (Virtual Network Gateway), joka lukittuu TopR:n kanssa BGP:n kautta ja ilmoittaa takaisinkytkentänsä, jonka pitäisi olla käytettävissä kaikista DC:istä.

Joten tältä sen AS-Path näyttää:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Ja missään ei pitäisi olla päällekkäisiä ASN-numeroita.

Eli Spine_DC1:n ja Spine_DC2:n on oltava erilaisia, aivan kuten leafX_DC1 ja leafY_DC2, joita olemme juuri lähestymässä.

Kuten luultavasti tiedät, on hakkereita, joiden avulla voit hyväksyä reittejä, joissa on päällekkäisiä ASN-numeroita silmukan estomekanismista huolimatta (allowas-in Ciscossa). Ja sillä on jopa laillisia käyttötarkoituksia. Mutta tämä on mahdollinen aukko verkon vakaudessa. Ja itsekin törmäsin siihen pari kertaa.

Ja jos meillä on mahdollisuus olla käyttämättä vaarallisia asioita, hyödynnämme sitä.

Lehti ASN

Meillä on oma ASN jokaisessa Leaf-kytkimessä koko verkossa.
Teemme tämän yllä mainituista syistä: AS-Path ilman silmukoita, BGP-konfiguraatio ilman kirjanmerkkejä.

Jotta Leafsin väliset reitit kulkevat sujuvasti, AS-polun tulisi näyttää tältä:
[leafX_ASN, spine_ASN, leafY_ASN]
jossa leafX_ASN ja leafY_ASN olisi mukavaa olla erilaisia.

Tätä tarvitaan myös tilanteessa, jossa DC:iden välillä on ilmoitettu VNF-silmukasta:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Käytämme 4-tavuista ASN:ää ja luomme sen Spinen ASN:n ja Leaf-kytkinnumeron perusteella, nimittäin näin: Spine_ASN.0000X.

Tässä kuvassa ASN.

IP-suunnitelma

Pohjimmiltaan meidän on allokoitava osoitteet seuraaville yhteyksille:

1. Aseta verkko-osoitteet ToR:n ja koneen välille. Niiden on oltava ainutlaatuisia koko verkossa, jotta mikä tahansa kone voi kommunikoida muiden kanssa. Hieno istuvuus 10/8. Jokaiselle telineelle on /26 varauksella. Jaamme /19 DC:tä kohti ja /17 aluetta kohti.
2. Linkitä osoitteet Leaf/Tor- ja Spinen välillä.

   Haluaisin määrittää ne algoritmisesti, eli laskea ne yhdistettävien laitteiden nimistä.

   Olkoon... 169.254.0.0/16.
   nimittäin, 169.254.00X.Y/31Missä X - Selkärangan numero, Y — P2P-verkko /31.
   Tämän avulla voit käynnistää jopa 128 telinettä ja jopa 10 piikkiä DC:ssä. Linkkiosoitteet voidaan (ja tullaan) toistamaan DC:stä DC:hen.

3. Järjestämme Spine-Edge-Leaf-risteyksen aliverkoissa 169.254.10X.Y/31, missä täsmälleen sama X - Selkärangan numero, Y — P2P-verkko /31.
4. Linkitä osoitteet Edge-Leafista MPLS-runkoverkkoon. Täällä tilanne on hieman erilainen - paikka, jossa kaikki palat on yhdistetty yhdeksi piirakkaksi, joten samojen osoitteiden uudelleenkäyttö ei toimi - sinun on valittava seuraava ilmainen aliverkko. Otetaan siis pohjaksi 192.168.0.0/16 ja haravoimme sieltä pois vapaat.
5. Loopback-osoitteet. Annamme heille koko valikoiman 172.16.0.0/12.
   • Lehti - /25 per DC - samat 128 telineet. Jaamme /23 aluetta kohden.
   • Selkä - /28 per DC - jopa 16 Selkä. Jaetaan /26 aluetta kohden.
   • Edge-Leaf - /29 per DC - jopa 8 laatikkoa. Jaetaan /27 aluetta kohden.

Jos meillä ei ole tarpeeksi allokoituja alueita DC:ssä (eikä niitä tule olemaan - väitämme olevansa hyperskaalaajia), valitsemme vain seuraavan lohkon.

Tässä kuvassa on IP-osoite.

Silmukat:

etuliite
Laitteen rooli
Alue
ДЦ

172.16.0.0/23
reuna
 
 

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
molemmat

172.16.2.0/23
selkä
 
 

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
molemmat

172.16.8.0/21
lehti
 
 

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
molemmat

Aluskate:

etuliite
Alue
ДЦ

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
molemmat

Laba

Kaksi myyjää. Yksi verkko. ADSM.

Kataja + Arista. Ubuntu. Vanha hyvä Eeva.

Resurssien määrä Miranan virtuaalipalvelimellamme on edelleen rajallinen, joten harjoituksissa käytämme äärimmäisen yksinkertaistettua verkkoa.

Kaksi datakeskusta: Kazan ja Barcelona.

• Kummassakin kaksi piikkiä: Juniper ja Arista.
• Kummassakin yksi torus (Leaf) - Juniper ja Arista, yksi kytketty isäntä (otetaanpa kevyt Cisco IOL tätä varten).
• Yksi Edge-Leaf-solmu (toistaiseksi vain Juniper).
• Yksi Cisco-kytkin hallitsee niitä kaikkia.
• Verkkolaatikoiden lisäksi käynnissä on virtuaalinen ohjauskone. Ubuntu käynnissä.
  Sillä on pääsy kaikkiin laitteisiin, se käyttää IPAM/DCIM-järjestelmiä, joukon Python-skriptejä, Ansiblea ja kaikkea muuta, mitä voimme tarvita.

Täysi kokoonpano kaikista verkkolaitteista, jotka yritämme toistaa automaatiolla.

Johtopäätös

Onko sekin hyväksytty? Pitäisikö minun kirjoittaa lyhyt johtopäätös jokaisen artikkelin alle?

Joten valitsimme kolmitasoinen Kloz-verkko DC:n sisällä, koska odotamme paljon itä-länsi-liikennettä ja haluamme ECMP:n.

Verkko jaettiin fyysiseen (underlay) ja virtuaaliseen (overlay). Samaan aikaan peittokuva alkaa isännästä, mikä yksinkertaistaa aluskatteen vaatimuksia.

Valitsimme BGP:n verkkoverkkojen reititysprotokollaksi sen skaalautuvuuden ja politiikan joustavuuden vuoksi.

Meillä on erilliset solmut DCI:n järjestämiseen - Edge-leaf.
Rungossa on OSPF+LDP.
DCI toteutetaan MPLS L3VPN:n perusteella.
P2P-linkeille laskemme IP-osoitteet algoritmisesti laitenimien perusteella.
Annamme silmukat laitteiden roolin ja niiden sijainnin mukaan peräkkäin.
Aluskatteen etuliitteet - vain Leaf-kytkimissä peräkkäin niiden sijainnin perusteella.

Oletetaan, että laitteita ei ole vielä asennettu.
Siksi seuraavat vaiheemme on lisätä ne järjestelmiin (IPAM, inventaario), järjestää pääsy, luoda kokoonpano ja ottaa se käyttöön.

Seuraavassa artikkelissa käsittelemme Netboxia - DC:n IP-tilan inventointi- ja hallintajärjestelmää.

Kiitos

• Andrey Glazkov eli @glazgoo oikolukemisesta ja korjauksista
• Alexander Klimenko eli @v00lk oikolukemisesta ja muokkauksista
• Artyom Chernobay KDPV:lle

Lähde: will.com