Az első két cikkben felvetettem az automatizálás kérdését és felvázoltam annak kereteit, a másodikban pedig a hálózati virtualizációba vonultam vissza, mint a szolgáltatások konfigurációjának automatizálásának első megközelítésére.
Most itt az ideje megrajzolni a fizikai hálózat diagramját.

Ha nem jártas az adatközponti hálózatok beállításában, akkor erősen ajánlom, hogy kezdje ezzel cikkek róluk.

Minden probléma:

• 0. ADSM. Nulladik rész. Tervezés
• 1. ADSM. Első rész (ami a nulla után van). Hálózati virtualizáció
• 2. ADSM. Második rész. Hálózat tervezés

Az ebben a sorozatban ismertetett gyakorlatoknak minden típusú hálózatra, bármilyen méretűre, bármilyen szállítóval (nem) alkalmazhatónak kell lenniük. Azonban lehetetlen egyetemes példát leírni e megközelítések alkalmazására. Ezért az egyenáramú hálózat modern architektúrájára fogok összpontosítani: Klozi gyár.
DCI-t fogunk csinálni MPLS L3VPN-en.

Az Overlay hálózat a fizikai hálózaton fut a gazdagéptől (ez lehet az OpenStack VXLAN vagy Tungsten Fabric, vagy bármi más, amely csak alapvető IP-kapcsolatot igényel a hálózattól).

Ebben az esetben egy viszonylag egyszerű forgatókönyvet kapunk az automatizáláshoz, mert sok olyan berendezésünk van, amely ugyanúgy van konfigurálva.

Egy gömb alakú egyenáramot választunk vákuumban:

• Egy tervezési változat mindenhol.
• Két szállító, amely két hálózati síkot alkot.
• Az egyik DC olyan, mint a másik, mint két borsó egy hüvelyben.

Tartalom

• Fizikai topológia
• útvonalválasztás
• IP terv
• Laba
• Következtetés
• Hasznos Linkek

Például a LAN_DC szolgáltatónk készítsen oktatóvideókat az elakadt liftekben való túlélésről.

A nagyvárosokban ez nagyon népszerű, ezért sok fizikai gépre van szükség.

Először is leírom a hálózatot körülbelül olyannak, amilyennek szeretném. És akkor leegyszerűsítem a labor számára.

Fizikai topológia

Helyszínek

A LAN_DC 6 DC-vel rendelkezik:

• Oroszország (RU):
  • Moszkva (MSK)
  • Kazan (kzn)

• Spanyolország (SP):
  • Barcelona (bcn)
  • Malaga (mlg)

• Kína (CN):
  • Shanghai (sha)
  • Xi'an (sia)

Belső DC (Intra-DC)

Minden DC azonos belső csatlakozási hálózattal rendelkezik Clos topológián alapulóan.
Milyen Clos hálózatok ezek és miért vannak külön cikk.

Minden DC-n 10 állvány található gépekkel, ezek számozása így lesz A, B, C És így tovább.

Minden állványon 30 gép található. Nem fognak minket érdekelni.

Szintén minden rackben van egy kapcsoló, amelyhez az összes gép csatlakoztatva van - ez van A Rack kapcsoló teteje - ToR vagy másképp a Clos gyár szempontjából nevezzük Levél növényen.

A gyár általános diagramja.

Felhívjuk őket XXX-levél növényenYAhol XXX - hárombetűs DC rövidítés, és Y - sorozatszám. Például, kzn-levél11.

Cikkeimben megengedem magamnak, hogy a Leaf és a ToR kifejezéseket meglehetősen komolytalanul használom szinonimákként. Nem szabad azonban elfelejtenünk, hogy ez nem így van.
A ToR egy rackbe szerelt kapcsoló, amelyhez gépek csatlakoznak.
A Leaf egy eszköz szerepe egy fizikai hálózatban vagy egy első szintű kapcsoló a Cloes topológiája szempontjából.
Vagyis Leaf != ToR.
Tehát a Leaf lehet például EndofRaw kapcsoló.
A cikk keretein belül azonban továbbra is szinonimákként kezeljük őket.

Minden ToR kapcsoló négy magasabb szintű aggregációs kapcsolóhoz csatlakozik - Gerinc. A DC-ben egy rack van kijelölve a Spines számára. Hasonlóan fogjuk elnevezni: XXX-gerincY.

Ugyanez a rack tartalmaz majd hálózati berendezéseket a DC - 2 útválasztók közötti csatlakozáshoz, MPLS-sel. De nagyjából ezek ugyanazok a ToR-ok. Vagyis a Spine switchek szempontjából a szokásos ToR csatlakoztatott gépekkel vagy DCI routerrel egyáltalán nem számít - csak továbbítás.

Az ilyen speciális ToR-okat hívják Szél-levél. Felhívjuk őket XXX-élY.

Így fog kinézni.

A fenti ábrán valójában egy szintre helyeztem az élt és a levelet. Klasszikus háromrétegű hálózatok Megtanítottak minket arra, hogy a felfelé irányuló linket (innen a kifejezést) uplinknek tekintsük. És itt kiderül, hogy a DCI „uplink” visszamegy, ami egyesek számára kissé megtöri a megszokott logikát. Nagy hálózatok esetén, amikor az adatközpontokat még kisebb egységekre osztják - POD's (Point Of Delivery), jelölje ki külön Edge-PODA DCI-hez és a külső hálózatokhoz való hozzáféréshez.

A jövőben a könnyebb érzékelhetőség kedvéért továbbra is az Edge-t a Spine fölé fogom rajzolni, miközben észben tartjuk, hogy a Spine-en nincs intelligencia, és nincs különbség a normál Leaff-el és Edge-leaff-el való munka során (bár itt lehetnek árnyalatok , de általában Ez igaz).

A gyár vázlata éllevelekkel.

A Leaf, Spine és Edge hármassága egy Underlay hálózatot vagy gyárat alkot.

Egy hálózati gyár (lásd Underlay) feladata, ahogyan azt már ben meghatároztuk utolsó szám, nagyon-nagyon egyszerű - IP-kapcsolat biztosítása ugyanazon a DC-n belüli gépek között és közöttük egyaránt.
Ezért hívják a hálózatot gyárnak, akárcsak például a moduláris hálózati dobozokon belüli kapcsológyárat, amelyről bővebben itt olvashat. SDSM14.

Általában az ilyen topológiát gyárnak nevezik, mivel a textil fordításban szövetet jelent. És nehéz nem érteni:

A gyár teljesen L3. Nincs VLAN, nincs Broadcast – olyan csodálatos programozóink vannak a LAN_DC-nél, tudnak olyan alkalmazásokat írni, amelyek az L3 paradigmában élnek, és a virtuális gépek nem igényelnek Live Migrációt az IP-cím megőrzésével.

És még egyszer: a válasz arra a kérdésre, hogy miért a gyár és miért az L3 külön cikk.

DCI – Data Center Interconnect (Inter-DC)

A DCI az Edge-Leaf segítségével lesz megszervezve, vagyis ezek jelentik a kijáratunkat az autópályára.
Az egyszerűség kedvéért feltételezzük, hogy a DC-k közvetlen kapcsolatokon keresztül kapcsolódnak egymáshoz.
A külső kapcsolatot zárjuk ki a számításból.

Tisztában vagyok vele, hogy minden alkalommal, amikor eltávolítok egy összetevőt, jelentősen leegyszerűsítem a hálózatot. És ha automatizáljuk az absztrakt hálózatunkat, minden rendben lesz, de az igaziban mankók lesznek.
Ez igaz. Ennek a sorozatnak mégis az a lényege, hogy a megközelítéseken gondolkodjunk és dolgozzunk, nem pedig a képzeletbeli problémák hősies megoldása.

Az Edge-Leafeken az alátétet a VPN-be helyezik, és az MPLS gerinchálózaton keresztül továbbítják (ugyanaz a közvetlen kapcsolat).

Ez a legfelső szintű diagram, amit kapunk.

útvonalválasztás

A DC-n belüli útválasztáshoz BGP-t fogunk használni.
Az MPLS törzsön OSPF+LDP.
A DCI-hez, azaz a földalatti kapcsolat megszervezéséhez - BGP L3VPN MPLS-en keresztül.

Általános útválasztási séma

A gyárban nincs OSPF vagy ISIS (az Orosz Föderációban tiltott útválasztási protokoll).

Ez azt jelenti, hogy nem lesz automatikus felderítés vagy a legrövidebb utak kiszámítása - csak manuális (valójában automatikus - itt automatizálásról beszélünk) a protokoll, a szomszédság és a házirendek beállítása.

BGP-útválasztási séma a DC-n belül

Miért a BGP?

Ebben a témában van teljes RFC a Facebookról és az Aristáról elnevezett, ami megmondja, hogyan kell építeni nagyon nagy adatközponti hálózatok BGP használatával. Szinte szépirodalmat olvas, bágyadt estékre nagyon ajánlom.

És a cikkemben egy teljes rész is van ennek szentelve. Hová vigyem és küldöm.

Röviden azonban egyetlen IGP sem alkalmas nagy adatközpontok hálózataira, ahol a hálózati eszközök száma több ezerre rúg.

Ezenkívül a BGP mindenhol használata lehetővé teszi, hogy ne veszítsen időt több különböző protokoll támogatására és a köztük lévő szinkronizálásra.

Kéz a szívre, üzemünkben, amely nagy valószínűséggel nem fog gyorsan növekedni, az OSPF is elég lenne a szemnek. Ezek valójában a megascalerek és a felhőtitánok problémái. De képzeljük el, hogy csak néhány kiadásra van szükségünk, és a BGP-t fogjuk használni, ahogy Pjotr ​​Lapukhov hagyta.

Útválasztási szabályzatok

A Leaf kapcsolókon az előtagokat az Underlay hálózati interfészekről importáljuk a BGP-be.
között BGP ülést tartunk minden egy Leaf-Spine pár, amelyben ezeket az Underlay előtagokat a hálózaton keresztül oda-vissza bejelentik.

Egy adatközponton belül terjesztjük a ToRe-be importált specifikációkat. Az Edge-Leaf-eken összesítjük és bejelentjük őket a távoli DC-knek, majd elküldjük a TOR-oknak. Ez azt jelenti, hogy minden ToR pontosan tudni fogja, hogyan juthat el egy másik ToR-hoz ugyanabban a DC-ben, és hol van a belépési pont egy másik DC-ben lévő ToR-hoz.

A DCI-ben az útvonalak VPNv4-ként kerülnek továbbításra. Ehhez az Edge-Leaf-en a gyár felé eső interfész egy VRF-be kerül, nevezzük ALÁTÉTnek, és a Spine on Edge-Leaf környéke emelkedik a VRF-en belül, az Edge-Leaf-ek között pedig a VPNv4-ben. család.

A tüskékről visszaérkező útvonalak újbóli meghirdetését is megtiltjuk.

A Leaf és Spine esetében nem importálunk visszahurkolásokat. Csak az útválasztó azonosítójának meghatározásához van szükségünk rájuk.

De az Edge-Leafeken a Global BGP-be importáljuk. A Loopback címek között az Edge-Leafs BGP-munkamenetet hoz létre egymással az IPv4 VPN-családban.

OSPF+LDP gerinchálózatunk lesz az EDGE eszközök között. Minden egy zónában van. Rendkívül egyszerű konfiguráció.

Ez a kép az útválasztással.

BGP ASN

Edge-Leaf ASN

Az Edge-Leafeknek egy ASN lesz az összes DC-ben. Fontos, hogy az Edge-Leafs között legyen iBGP, és ne ragadjunk le az eBGP árnyalataiban. Legyen 65535. A valóságban ez lehet egy nyilvános AS száma.

Gerinc ASN

A Spine-n egy ASN-ünk lesz DC-nként. Kezdjük itt a privát AS tartomány legelső számával – 64512, 64513 és így tovább.

Miért ASN DC-n?

Bontsuk ezt a kérdést két részre:

• Miért ugyanazok az ASN-ek egy DC minden gerincén?
• Miért különböznek a különböző DC-kben?

Miért vannak ugyanazok az ASN-k egy DC minden gerincén?

Így fog kinézni az alapréteg AS-útvonala az Edge-Leaf-en:
[leafX_ASN, spine_ASN, edge_ASN]
Amikor megpróbálja visszahirdetni a Spine-nek, az elveti, mert az AS (Spine_AS) már szerepel a listán.

A DC-n belül azonban teljesen meg vagyunk elégedve azzal, hogy az Edge-ig felmenő Underlay útvonalak nem tudnak lemenni. A DC-n belüli hosztok közötti minden kommunikációnak a gerinc szintjén kell történnie.

Ugyanakkor a többi DC-k összesített útvonalai mindenesetre könnyen elérik a ToR-okat - az AS-útvonaluk csak ASN 65535 lesz - az AS Edge-Leaf-ek száma, mert ott jöttek létre.

Miért különböznek a különböző DC-kben?

Elméletileg előfordulhat, hogy a Loopbacket és néhány szolgáltatási virtuális gépet át kell húznunk a DC-k között.

Például a gazdagépen a Route Reflector ill ugyanaz a VNGW (Virtual Network Gateway), amely a TopR-rel záródik BGP-n keresztül, és bejelenti a visszacsatolását, amely minden DC-ről elérhető lesz.

Tehát így fog kinézni az AS-Path:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

És ne legyenek sehol duplikált ASN-ek.

Vagyis a Spine_DC1-nek és a Spine_DC2-nek különböznie kell, akárcsak a leafX_DC1-nek és a leafY_DC2-nek, amihez közeledünk.

Amint azt valószínűleg Ön is tudja, vannak olyan feltörések, amelyek lehetővé teszik az útvonalak duplikált ASN-jeivel történő elfogadását a hurokmegelőzési mechanizmus ellenére (a Cisco-ban engedélyezve van). És még törvényes felhasználása is van. Ez azonban potenciális hiányosság a hálózat stabilitásában. És én személy szerint párszor beleestem.

És ha van lehetőségünk arra, hogy ne használjunk veszélyes dolgokat, akkor ezt kihasználjuk.

Leaf ASN

A hálózat minden Leaf kapcsolóján külön ASN lesz.
Ezt a fenti okok miatt tesszük: AS-Path hurkok nélkül, BGP konfiguráció könyvjelzők nélkül.

Ahhoz, hogy a Leafs közötti útvonalak zökkenőmentesen haladjanak át, az AS-Path így néz ki:
[leafX_ASN, spine_ASN, leafY_ASN]
ahol a leafX_ASN és a leafY_ASN jó lenne, ha különböznének.

Erre a DC-k közötti VNF visszacsatolás bejelentése esetén is szükség van:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

4 bájtos ASN-t fogunk használni, és a Spine ASN-je és a Leaf kapcsoló száma alapján generáljuk, mégpedig így: Spine_ASN.0000X.

Ez a kép az ASN-nel.

IP terv

Alapvetően a következő kapcsolatokhoz kell címeket kiosztanunk:

1. Hálózati címek elhelyezése a ToR és a gép között. Ezeknek egyedinek kell lenniük a teljes hálózaton belül, hogy bármely gép kommunikálhasson bármely másik géppel. Remek illeszkedés 10/8. Minden rackhez /26 van tartalékkal. DC-nként /19-et és régiónként /17-et osztunk ki.
2. Kapcsolja össze a címeket a Leaf/Tor és a Spine között.

   Ezeket szeretném algoritmikusan hozzárendelni, vagyis a csatlakoztatni kívánt eszközök nevéből kiszámolni.

   Legyen... 169.254.0.0/16.
   Ugyanis 169.254.00X.Y/31Ahol X - gerinc szám, Y — P2P hálózat /31.
   Ez lehetővé teszi akár 128 rack és akár 10 Spine indítását a DC-ben. A linkcímek megismételhetők (és lesznek is) DC-ről DC-re.

3. A gerinc-él-levél csomópontot alhálózatokon szervezzük 169.254.10X.Y/31, ahol pontosan ugyanaz X - gerinc szám, Y — P2P hálózat /31.
4. Kapcsolja össze a címeket az Edge-Leaf és az MPLS gerinchálózat között. Itt a helyzet némileg más - az a hely, ahol az összes darab egy körbe kapcsolódik, így ugyanazon címek újrafelhasználása nem fog működni - ki kell választani a következő szabad alhálózatot. Ezért vegyük alapul 192.168.0.0/16 és kigereblyézzük belőle a szabadokat.
5. Loopback címek. A teljes választékot átadjuk nekik 172.16.0.0/12.
   • Leaf - /25 per DC - ugyanaz a 128 rack. Régiónként /23-at osztunk ki.
   • Gerinc - /28 DC - 16-ig Gerinc. Régiónként jelöljünk ki /26-ot.
   • Edge-Leaf - /29 per DC - 8 dobozig. Régiónként osztjunk ki /27-et.

Ha nincs elég lefoglalt tartományunk a DC-ben (és nem is lesz – azt állítjuk, hogy hiperskálázók vagyunk), egyszerűen kiválasztjuk a következő blokkot.

Ez a kép IP-címmel.

Visszahurkolások:

Előtag
Eszköz szerepkör
Vidék
DC

172.16.0.0/23
él
 
 

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
gerinc
 
 

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
levél
 
 

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

Alátét:

Előtag
Vidék
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

Két eladó. Egy hálózat. ADSM.

Boróka + Arista. Ubuntu. A jó öreg Éva.

A Miranában található virtuális szerverünkön az erőforrások mennyisége továbbra is korlátozott, így a gyakorláshoz a végletekig leegyszerűsített hálózatot fogjuk használni.

Két adatközpont: Kazany és Barcelona.

• Két-két tüske: Boróka és Arista.
• Mindegyikben egy tórusz (Leaf) - Juniper és Arista, egy csatlakoztatott gazdagéppel (vegyünk ehhez egy könnyű Cisco IOL-t).
• Egy-egy Edge-Leaf csomópont (egyelőre csak a Juniper).
• Egy Cisco kapcsoló vezérli mindegyiket.
• A hálózati dobozokon kívül egy virtuális vezérlőgép is fut. Ubuntu futtatása.
  Minden eszközhöz hozzáfér, IPAM/DCIM rendszereket, egy csomó Python szkriptet, Ansible-t és bármi mást, amire szükségünk lehet.

Teljes konfiguráció az összes hálózati eszköz közül, amelyeket automatizálással igyekszünk reprodukálni.

Következtetés

Ezt is elfogadják? Minden cikk alá írjak egy rövid következtetést?

Így hát választottunk háromszintű Zárt hálózat a DC-n belül, mivel nagy kelet-nyugati forgalomra számítunk és ECMP-t akarunk.

A hálózatot fizikai (underlay) és virtuális (overlay) részekre osztották. Ugyanakkor az átfedés a gazdagéptől indul – ezzel leegyszerűsítve az alátétre vonatkozó követelményeket.

A BGP-t választottuk a hálózati hálózatok útválasztási protokolljaként a méretezhetőség és a házirend rugalmassága miatt.

Külön csomópontjaink lesznek a DCI - Edge-leaf szervezéséhez.
A gerinc OSPF+LDP lesz.
A DCI az MPLS L3VPN alapján kerül megvalósításra.
A P2P hivatkozások esetében az IP-címeket algoritmikusan számítjuk ki az eszköznevek alapján.
A visszahurkolásokat az eszközök szerepe és elhelyezkedése szerint sorrendben fogjuk hozzárendelni.
Underlay előtagok – csak a Leaf kapcsolókon, sorrendben a helyük alapján.

Tételezzük fel, hogy jelenleg még nincs telepítve a berendezés.
Ezért a következő lépésünk az lesz, hogy hozzáadjuk őket a rendszerekhez (IPAM, leltár), megszervezzük a hozzáférést, létrehozunk egy konfigurációt és telepítjük azt.

A következő cikkben a Netbox-szal fogunk foglalkozni – a DC-ben lévő IP-terület leltár- és felügyeleti rendszerével.

Köszönöm

• Andrey Glazkov aka @glazgoo a lektorálásért és a javításokért
• Alexander Klimenko aka @v00lk lektorálásért és szerkesztésért
• Artyom Chernobay a KDPV-nek

Forrás: will.com