Az első két cikkemben az automatizálás kérdését vetettem fel, és felvázoltam annak keretrendszerét, a másodikban pedig kitértem a hálózati virtualizációra, mint az automatizálás első megközelítésére a szolgáltatások konfigurálásában.
Most elérkezett az idő, hogy megrajzoljuk a fizikai hálózat vázlatát.
Ha nem állsz közel a adatközponti hálózati eszközök világához, akkor javaslom, hogy kezdd a .
Összes kiadás:
A sorozatban bemutatott gyakorlatokat bármilyen típusú, bármilyen méretű és bármilyen gyártó sokféleségét magába foglaló hálózatra alkalmazni kellene (de nem lehet). Azonban univerzális példa ezeknek a megközelítéseknek a alkalmazására nem írható le. Ezért a modern DC hálózati architektúrára fogok összpontosítani: .
A DCI MPLS L3VPN-en lesz.
A fizikai hálózaton egy overlay-hálózat működik hosztról (ez lehet az OpenStack VXLAN vagy a Tungsten Fabric, vagy bármi más, ami csak alapvető IP-kapcsolatot igényel a hálózattól).
Ebben az esetben viszonylag egyszerű forgatókönyvet kapunk az automatizálásra, mivel sokféle eszköz van, amelyek azonos módon konfigurálódnak.
Mi egy gömb alakú DC-t választunk az űrben:
- Mindenhol egy verzió a dizájnból.
- Két gyártó, amelyek két síkot alkotnak a hálózatban.
- Egy DC hasonlít a másikra, mint két tojás.
Tartalom
- Fizikai topológia
- Routing
- IP-terv
- Labor
- Zárás
- Hasznos linkek
Tegyük fel, hogy a Szolgáltató LAN_DC például oktatóvideókat fog tárolni a liftben való túlélésről.
A nagyvárosokban ez őrült népszerűségnek örvend, ezért sok fizikális gépre van szükség.
Először leírom a hálózatot, körülbelül úgy, ahogyan azt szeretném látni. Aztán leegyszerűsítem a laborhoz.
Fizikai topológia
Helyszínek
A LAN_DC-nak 6 DC-je lesz:
- Oroszország (RU):
- Moszkva (msk)
- Kazan (kzn)
- Spanyolország (SP):
- Barcelona (bcn)
- Málaga (mlg)
- Kína (CN):
- Sanghaj (sha)
- Xi'an (sia)
Intra-DC
Minden DC azonos belső kapcsolati hálózatokkal rendelkezik, amelyek a Clos topológián alapulnak.
Mik ezek a Clos hálózatok, és miért éppen ezek — külön cikkben. .
Minden DC-ben 10 állvány van gépekkel, ezeket úgy fogjuk számozni, mint A, B, C Mindezek mellett.
Minden állványon 30 gép található. Ezek most nem érdekelnek minket.
Minden állványban van egy switch, amelyhez az összes gép csatlakozik — ez a Top of the Rack switch — ToR vagy a Clos gyár kifejezéseivel hívhatjuk ezt a Leaf-nek..
A gyár általános vázlata.
Őket így fogjuk nevezni XXX-leafY, ahol XXX — hárombetűs rövidítés DC, és Y — sorszám. Például, kzn-leaf11.
A cikkekben elég szabadon fogok hivatkozni a Leaf és ToR kifejezésekre, mint szinonimákra. Azonban emlékeznünk kell arra, hogy ez nem így van.
A ToR egy rackbe szerelt switchet jelent, amelyhez gépek csatlakoznak.
A Leaf pedig az eszköz szerepét jelenti a fizikai hálózatban, vagy az első szintű switch a Clos topológiában.
Tehát Leaf != ToR.
Így Leaf-ként szerepelhet egy EndofRaw switch is például.
Azonban ebben a cikkben mégis úgy fogunk rájuk hivatkozni, mint szinonimákra.
Minden ToR switchet viszont négy felső aggregáló switchhez kapcsolnak — Spine. A Spine-ek számára egy racket különítettek el a DC-ben. Az elnevezés hasonló lesz: XXX-spineY.
Ugyanabban a rackben lesz a hálózati berendezés a DC közötti kapcsolatra — 2 útválasztó MPLS-szel a fedélzeten. De lényegében ezek ugyanazok a ToR-ok. Tehát a Spine switchek szempontjából teljesen mindegy, hogy a csatlakoztatott gépekkel ellátott szokásos ToR-ról vagy a DCI-hoz tartozó útválasztóról van szó — egy és ugyanaz az előrehaladás szempontjából.
Az ilyen speciális ToR-kat nevezik Edge-leaf. Mi őket XXX-edgeY.
formában fogjuk említeni.
Ez így fog kinézni. A klasszikus háromszintes hálózatok PODarra tanítottak minket, hogy az uplink (tulajdonképpen ezért a kifejezés) felfelé vezető linkekként szerepel. Itt viszont úgy tűnik, hogy a DCI uplink visszafelé halad lefelé, ami némileg megzavarja a megszokott logikát. Nagyobb hálózatok esetén, amikor az adatközpontokat még kisebb egységekre bontják — ‘k (Point Of Delivery), elkülönítik a különállóEdge-POD
‘k a DCI és a külső hálózatok felé.
A továbbiakban a könnyebb megértés érdekében a Spine fölött fogom ábrázolni az Edge-t, emlékezve arra, hogy a Spine-en nincs intelligencia, és nincs különbség a szokásos Leaf és az Edge-leaf működése között (bár itt lehetnek finomságok, de általánosságban így van).
Az Edge-leaf-ekkel rendelkező gyár diagramja.
A Leaf, Spine és Edge trió alkotja az Underlay-hálózatot vagy gyárat. A hálózati gyár célja (azaz az Underlay), ahogyan azt már az előbb meghatároztuk, nagyon egyszerű — biztosítani az IP-kapcsolatot a gépek között, akár egy DC-n belül, akár azok között.
Ezért hívják a hálózatot gyárnak, hasonlóan például a moduláris hálózati dobozok belső kapcsolási gyárához, amiről többet olvashatunk a .
Valójában ezt a topológiát gyárnak hívják, mert a 'fabric' fordításban szövetet jelent. És nehéz nem egyetérteni vele:
A gyár teljesen L3. Nincs VLAN, nincs Broadcast — ilyen csodálatos fejlesztőink vannak a LAN_DC-ben, akik képesek olyan alkalmazásokat írni, amelyek L3 paradigmában működnek, és a virtuális gépeknek nincs szükségük Live Migration-re az IP-cím megőrzésével.
Még egyszer: a válasz arra a kérdésre, hogy miért gyár és miért L3 — egy külön. .
DCI — Data Center Interconnect (Inter-DC)
A DCI Edge-Leaf segítségével lesz megszervezve, vagyis ők a kijáratunk a gerinc felé.
Egyszerűség kedvéért tegyük fel, hogy a DC-k közvetlen linkekkel vannak összekapcsolva.
Hagyjuk figyelmen kívül a külső összekapcsolhatóságot.
Tudomásul veszem, hogy minden alkalommal, amikor eltávolítok egy komponenst, jelentősen egyszerűsítem a hálózatot. És az elvont hálózatunk automatizálása jól fog működni, de a valóságban problémák merülnek fel.
Ez így van. De a sorozat feladata nem az, hogy hősiesen megoldjunk kitalált problémákat, hanem hogy gondolkodjunk és dolgozzunk a megközelítéseken.
Az Edge-Leaf-eken az underlay VPN-be kerül, és MPLS-gerincen keresztül továbbítják (az a közvetlen link).
Ilyen felsőbb szintű ábra készül.
Routing
A DC-n belüli irányításhoz BGP-t fogunk használni.
Az MPLS-gerincen OSPF+LDP.
A DCI-hez, vagyis az összekapcsolhatóság szervezéséhez az underlay-ban — BGP L3VPN MPLS-en.
Áttekintő irányítási séma
A gyárban nincs OSPF és ISIS (a Orosz Föderációban betiltott irányítási protokoll).
Ez azt jelenti, hogy nem lesz Automatikus felfedezés és a legrövidebb utak kiszámítása — csak manuális (valójában automatikus — hiszen itt az automatizálásról van szó) a protokoll, szomszédság és politikák beállítása.
A BGP irányítási séma a DC-n belül
Miért BGP?
Ezzel kapcsolatban van a Facebook és Arista nevével, amely arról szól, hogyan építsünk nagyon nagy adatközponti hálózatokat BGP használatával. Szinte művészi olvasmány, nagyon ajánlom a mélázó estékre.
Van egy egész fejezet a cikkemben, amely ennek szentelt. Azt, amit .
De ha mégis röviden, semmilyen IGP nem alkalmas a nagy adatközponti hálózatok számára, ahol az eszközök száma ezreket számlál.
Ezenkívül a BGP széles körű alkalmazása lehetővé teszi, hogy ne szóródjunk el több különböző protokoll támogatásában és az azok közötti szinkronizálásban.
Kéz a szívre, a gyárunkban, amely valószínűleg nem fog gyorsan növekedni, elegendő lenne az OSPF. Ezek valóban a megaszkálók és felhőóriások problémái. De képzeljük el, hogy szükségünk van erre néhány kiadás erejéig, és használni fogjuk a BGP-t, ahogyan azt Péter Lapuhov megfogalmazta.
Útválasztási politikák
A Leaf-switch-eken importáljuk a BGP-be a prefixeket az Underlay interfészekről a hálózatokkal.
BGP kapcsolatunk lesz minden páronként Leaf-Spine között, ahol ezek az Underlay prefixek a hálózaton belül hirdetve lesznek.
Egy adatközponton belül terjeszteni fogjuk a specifikációkat, amelyeket az ToR-on importáltunk. Az Edge-Leaf-eken aggregáljuk őket, és hirdetjük a távoli DC-k felé, valamint leviszünk őket az ToR-okra. Tehát minden ToR pontosan tudni fogja, hogyan juthat el a másik ToR-hoz ebben az adatközpontban, és hol a belépési pont, hogy elérje a ToR-t egy másik DC-ben.
A DCI útvonalak VPNv4-ként lesznek átadva. Ehhez az Edge-Leaf interfész, amely a gyár felé megy, VRF-be kerül, nevezzük UNDERLAY-nak, és a Spine-nel az Edge-Leaf-en belül VRF-en belül keletkezik szomszédság, míg az Edge-Leaf-ek között a VPNv4-családban.
Ezenkívül tilos lesz a Spine-ktől kapott útvonalakat újra hirdetni vissza rájuk.
A Leaf-en és Spine-on nem fogjuk importálni a Loopback-eket. Csak arra lesz szükségünk, hogy meghatározzuk a Router ID-t.
Viszont az Edge-Leaf-eken importálni fogjuk azt a Global BGP-be. Az Edge-Leaf loopback címei között BGP kapcsolatot létesítenek IPv4 VPN-family-ben egymással.
Az EDGE eszközök között OSPF+LDP-ra kiterjedt gerincünk lesz. Minden egy zónában. Maximálisan egyszerű konfiguráció.
Ilyen a képe a routolásnak.
BGP ASN
Edge-Leaf ASN
Az Edge-Leaf-eken egy ASN lesz minden DC-ben. Ez fontos, hogy az Edge-Leaf-ek között iBGP legyen, és ne bukjunk el az eBGP árnyalataiban. Legyen ez 65535. Valójában ez lehetne egy nyilvános AS száma.
Spine ASN
A Spine-on csak egy ASN lesz a DC-hez. Kezdjük itt a privát AS tartomány első számával — 64512, 64513 és így tovább.
Miért ASN a DC-n?
Bontsuk le ezt a kérdést kettőre:
- Miért azonos ASN minden Spine-nál egy DC-ben?
- Miért különböznek más DC-kben?
Miért azonos ASN minden Spine-nál egy DC-ben
Így fog kinézni az AS-Path az Underlay útvonalán az Edge-Leaf-en:
[leafX_ASN, spine_ASN, edge_ASN]
Amikor megpróbáljuk újra hirdetni a Spine-ra, az visszautasítja, mert az AS-e (Spine_AS) már szerepel a listán.
Mindazonáltal a DC-n belül teljesen elfogadható számunkra, hogy az Underlay útvonalak, amelyek felemelkednek az Edge-hez, nem tudnak visszaereszkedni. Minden kommunikációnak a DC-n belül a spine szintjének határain kell zajlania a gazdagépek között.
Ekkor a másik DC-kből aggregált útvonalak minden esetben akadálytalanul elérik a ToR-okat — az AS-Path-jükben csak az ASN 65535 szerepel — az Edge-Leaf-ök AS száma, mivel ezekre létrehozták őket.
Miért különböznek a különböző DC-kben?
Elméletileg szükségünk lehet Loopback-ek áthúzására valamilyen szolgáltató virtuális gépek között a DC-k között.
Például a gazdagépen elindul egy Route Reflector vagy (Virtual Network Gateway), amely BGP-n keresztül kapcsolódik a ToR-hoz és bejelenti a Loopback-jét, amelynek elérhetőnek kell lennie az összes DC-ből.
Így fog kinézni az AS-Path-ja:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
És itt nem lehetnek megismétlődő ASN-ek.
Ezért a Spine_DC1 és Spine_DC2 különbözőnek kell lennie, akárcsak a leafX_DC1 és leafY_DC2, amire éppen rátérünk.
Ahogy valószínűleg tudjátok, léteznek hackek, amelyek lehetővé teszik a megismétlődő ASN-ek elfogadását a hurkok megelőzésére szolgáló mechanizmus ellenére (allowas-in a Cisco-n). Ennek vannak egészen törvényes alkalmazásai. De ez potenciális rés a hálózat stabilitásában. Én személy szerint párszor belefutottam.
Ha van lehetőségünk elkerülni a veszélyes dolgokat, akkor élni fogunk vele.
Leaf ASN
Minden Leaf kapcsolónak egyedi ASN-je lesz az egész hálózaton belül.
Ezt az előzőleg említett szempontok miatt tesszük: AS-Path hurkok nélkül, BGP konfigurálás nélkül hátrányos helyzet nélkül.
Annak érdekében, hogy az útvonalak akadálytalanul átmenjenek a Leaf-ek között, az AS-Path-nak így kell kinéznie:
[leafX_ASN, spine_ASN, leafY_ASN]
ahol a leafX_ASN és leafY_ASN lehetőség szerint különbözzön.
Ez szükséges a VNF Loopback bejelentésének helyzetére a DC-k között:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]
4-bájt ASN-t fogunk használni, amelyet a Spine ASN és a Leaf kapcsoló számának alapján generálunk, mégpedig így: Spine_ASN.0000X.
Ez a kép a ASN-ról.
IP-terv
Elvben címet kell biztosítani a következő kapcsolatokhoz:
- Az Underlay hálózat címei a ToR és a gép között. Ezeknek egyedieknek kell lenniük az egész hálózaton belül, hogy bármelyik gép kapcsolatba léphessen bármelyik másikkal. Tökéletesen alkalmas 10/8. Minden rackhez /26 a tartalékkal. Kiosztunk /19-et a DC-nek és /17-et a régiónak.
- Kapcsolati címek a Leaf/Tor és a Spine között.
Ezeket algoritmikusan szeretnénk kiosztani, azaz a csatlakoztatni szükséges eszközök neveiből számítani ki.
Legyen ez… 169.254.0.0/16.
Nevezetesen 169.254.00X.Y/31, ahol X — Spine szám, Y — P2P-hálózat /31.
Ez lehetővé teszi legfeljebb 128 állvány és 10 Spine elindítását az adatközpontban. A link címek megismétlődhetnek (és meg is fognak) adatközpontról adatközpontra. - A Spine – Edge-Leaf csatlakozást a következő hálózatok szervezésével végezzük: 169.254.10X.Y/31, ahol pontosan így X — Spine szám, Y — P2P-hálózat /31.
- Linkcímek az Edge-Leaf-től az MPLS gerincvonalig. Itt a helyzet egy kicsit más — a darabok összekapcsolásának helye egy tortában, ezért nem tudjuk újra felhasználni ugyanazokat a címeket — a következő szabad alhálózatot kell választani. Ezért vegyük alapul 192.168.0.0/16 és abból fogjuk kinyerni a szabadakat.
- Loopback cívek. Esetükben az egész tartományt adjuk meg 172.16.0.0/12.
- Leaf — /25 az adatközpontban — szintén 128 állvány. /23-at biztosítunk a régiónak.
- Spine — /28 az adatközpontban — legfeljebb 16 Spine. /26-ot biztosítunk a régiónak.
- Edge-Leaf — /29 az adatközpontban — legfeljebb 8 doboz. /27-et biztosítunk a régiónak.
Ha az adatközpontban nem lesz elegendő kibocsátott tartomány (ami nem lesz így — hiszen hiperskálerséget igénylünk), egyszerűen kiválasztunk egy következő blokkját.
Íme egy képet az IP címzésről.
Loopback-ek:
Prefix
Az eszköz szerepe
Régió
adatközpont
172.16.0.0/23
edge
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
spine
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
leaf
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
Underlay:
Prefix
Régió
adatközpont
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
Labor
Két beszállító. Egy hálózat. ADLM.
Juniper + Arista. Ubuntu. A régi jó Éva.
A Mirage virtuális gépünk erőforrásai végesek, ezért a gyakorlathoz egy ilyen maximálisan leegyszerűsített hálózatot fogunk használni.
Két adatközpont: Kazany és Barcelona.
- Mindegyikben két spine: Juniper és Arista.
- Mindegyikben egy torony (Leaf) — Juniper és Arista, egy csatlakoztatott hosttal (ehhez használjunk egy könnyű Cisco IOL-t).
- Egy Edge-Leaf node (egyelőre csak Juniper).
- One Cisco switch to rule them all.
- A hálózati dobozok mellett fut egy virtuális kezelőgép. Ubuntu alatt.
Hozzáférése van minden eszközhöz, rajta futnak majd az IPAM/DCIM rendszerek, egy csokor Python script, Ansible és bármi más, amire szükségünk lehet.
minden hálózati eszközhöz, amelyet automatizálás segítségével fogunk próbálni reprodukálni.
Zárás
Így szokás ezt? Minden cikk alatt rövid összefoglalót készíteni?
Tehát választottuk Kloza hálózatát az adatközpontban, mivel sok East-West forgalomra számítunk és ECMP-t szeretnénk.
A hálózatot fizikai (underlay) és virtuális (overlay) részeire osztottuk. Az overlay a hosttól kezdődik — ezzel egyszerűsítettük az underlay-ra vonatkozó követelményeket.
A BGP-t választottuk az anedrális hálózatok adatforgalmi protokolljának, mivel rugalmas és skálázható politikákat kínál.
Külön csomópontokat fogunk létrehozni a DCI megszervezéséhez – Edge-leaf.
A gerinccsatornán OSPF+LDP fog működni.
A DCI MPLS L3VPN alapú megvalósításon fog alapulni.
A P2P kapcsolataink IP-címeit algoritmikusan fogjuk kiszámítani az eszközök neve alapján.
A loopback-eket a berendezések szerepe és elhelyezkedése alapján fogjuk kijelölni.
Az anedrális prefixek csak a Leaf switch-ekre vonatkoznak, amelyek elhelyezkedésük alapján vannak sorrendben.
Tegyük fel, hogy jelenleg még nem áll rendelkezésünkre a berendezés.
Ezért a következő lépések a berendezések rögzítése a rendszerekben (IPAM, leltár), a hozzáférés megszervezése, a konfiguráció generálása és annak telepítése lesz.
A következő cikkben a Netbox-ról lesz szó – az adatbázis-kezelő és IP-tervező rendszerről a DC-ben.
Köszönöm
- Andrej Glazkovnak aka @glazgoo a korrektúráért és a módosításokért
- Alexander Klimenkónak aka @v00lk a korrektúráért és a módosításokért
- Artyom Csernobajnak a KDPV-ért
Forrás: habr.com
