Az SDSM-nek vége, de a fékezhetetlen írásvágy megmarad.

Testvérünk sok éven át szenvedett a rutinmunkától, összekulcsolta az ujjait, mielőtt elkötelezte magát, és az éjszakai visszahúzások miatt nem aludt.
De a sötét idők a végéhez közelednek.

Ezzel a cikkel kezdek egy sorozatot arról, hogyan nekem automatizálás látható.
Útközben megismerjük az automatizálás szakaszait, a változók tárolását, a tervezés formalizálását, a RestAPI-t, a NETCONF-ot, a YANG-t, az YDK-t és rengeteg programozást fogunk végezni.
Nekem azt jelenti, hogy a) ez nem objektív igazság, b) nem a feltétel nélkül a legjobb megközelítés, c) véleményem még az elsőtől az utolsó cikkig terjedő mozgás során is változhat - őszintén szólva, a tervezet szakaszától a kiadványt, kétszer teljesen átírtam mindent.

Tartalom

1. célok
   1. A hálózat olyan, mint egyetlen organizmus
   2. Konfiguráció tesztelése
   3. Verziószámítás
   4. A szolgáltatások monitorozása, öngyógyítása

2. alapok
   1. Leltári rendszer
   2. IP területkezelő rendszer
   3. Hálózati szolgáltatásleíró rendszer
   4. Az eszköz inicializálási mechanizmusa
   5. Szállító-agnosztikus konfigurációs modell
   6. Szállító-specifikus illesztőprogram-interfész
   7. A konfiguráció eszközhöz való eljuttatásának mechanizmusa
   8. CI / CD
   9. A biztonsági mentés és az eltérések keresésének mechanizmusa
   10. Megfigyelő-rendszer

3. Következtetés

Megpróbálom az ADSM-et az SDSM-től kissé eltérő formátumban lefolytatni. Továbbra is megjelennek a nagyméretű, részletes, számozott cikkek, amelyek között a mindennapi tapasztalatokból származó kis jegyzeteket közlöm. Megpróbálok itt küzdeni a perfekcionizmus ellen, és nem nyalni mindegyiket.

Milyen vicces, hogy másodszor is ugyanazt az utat kell végigjárnod.

Eleinte magamnak kellett cikkeket írnom a hálózatokról, mivel azok nem voltak a RuNeten.

Most nem találtam olyan átfogó dokumentumot, amely rendszerezné az automatizálási megközelítéseket, és egyszerű gyakorlati példákon keresztül elemezte volna a fenti technológiákat.

Lehet, hogy tévedek, ezért kérjük, adjon meg linkeket a hasznos forrásokhoz. Ez azonban nem változtat az írás iránti elhatározásomon, mert a fő cél az, hogy magam is tanuljak valamit, mások életének megkönnyítése pedig kellemes bónusz, ami megsimogatja a tapasztalatmegosztás génjét.

Megpróbálunk egy közepes méretű LAN DC adatközpontot venni, és kidolgozni a teljes automatizálási sémát.
Néhány dolgot szinte először fogok veled csinálni.

Nem leszek eredeti az itt leírt ötletekben és eszközökben. Dmitrij Figolnak kiváló csatorna streamekkel ebben a témában.
A cikkek sok szempontból átfedésben lesznek velük.

A LAN DC-ben 4 DC, körülbelül 250 switch, fél tucat router és pár tűzfal található.
Nem Facebook, de elég ahhoz, hogy mélyen elgondolkodtassunk az automatizáláson.
Van azonban olyan vélemény, hogy ha egynél több eszközzel rendelkezik, akkor már automatizálásra van szükség.
Valójában nehéz elképzelni, hogy ma már bárki élhet legalább egy csomag térdforgatókönyv nélkül.
Bár azt hallottam, hogy vannak irodák, ahol az IP-címeket Excelben tárolják, és a több ezer hálózati eszköz mindegyike manuálisan van konfigurálva, és saját egyedi konfigurációval rendelkezik. Ez természetesen modern művészetként is átadható, de a mérnök érzései biztosan megsértődnek.

célok

Most a legelvontabb célokat tűzzük ki:

• A hálózat olyan, mint egyetlen organizmus
• Konfiguráció tesztelése
• Hálózati állapot verziószámítás
• A szolgáltatások monitorozása, öngyógyítása

A későbbiekben ebben a cikkben megnézzük, milyen eszközöket fogunk használni, a következőkben pedig a célokat és eszközöket nézzük meg részletesen.

A hálózat olyan, mint egyetlen organizmus

A sorozat meghatározó mondata, bár első pillantásra talán nem tűnik olyan jelentőségteljesnek: a hálózatot fogjuk konfigurálni, nem az egyes eszközöket.
Az elmúlt években hangsúlyeltolódást tapasztaltunk a hálózat egyetlen egységként való kezelése felé, ezért a Szoftver által meghatározott hálózatépítés, Szándékvezérelt hálózatok и Autonóm hálózatok.
Végül is mire van szükségük az alkalmazásoknak globálisan a hálózattól: az A és B pontok közötti kapcsolatra (jó, néha +B-Z) és a többi alkalmazástól és felhasználóktól való elszigetelésre.

Így a mi feladatunk ebben a sorozatban rendszert építeni, megtartva a jelenlegi konfigurációt a teljes hálózatot, amely már minden eszközön a tényleges konfigurációra bontva, szerepének és helyének megfelelően.
Rendszer A hálózatkezelés azt jelenti, hogy a változtatások végrehajtásához felvesszük vele a kapcsolatot, és ez minden egyes eszköz számára kiszámítja a kívánt állapotot és konfigurálja azt.
Ily módon szinte nullára minimalizáljuk a CLI-hez való manuális hozzáférést – az eszközbeállításokban vagy a hálózat kialakításában bekövetkező bármilyen változást formalizálni és dokumentálni kell –, és csak ezután terjesztjük ki a szükséges hálózati elemekre.

Például, ha úgy döntünk, hogy mostantól a kazanyi rack-kapcsolóknak két hálózatot kell bejelenteniük egy helyett,

1. Először dokumentáljuk a rendszerek változásait
2. Az összes hálózati eszköz célkonfigurációjának generálása
3. Elindítjuk a hálózati konfiguráció frissítő programot, amely minden csomóponton kiszámítja, hogy mit kell eltávolítani, mit kell hozzáadni, és a csomópontokat a kívánt állapotba hozza.

Ugyanakkor manuálisan csak az első lépésben hajtjuk végre a változtatásokat.

Konfiguráció tesztelése

Ismerthogy a problémák 80%-a konfigurációváltáskor jelentkezik – ennek közvetett bizonyítéka, hogy az újévi ünnepek alatt általában minden nyugodt.
Személyesen szemtanúja voltam emberi hiba miatti globális leállások tucatjainak: rossz parancs, rossz ágon hajtották végre a konfigurációt, a közösség elfelejtette, az MPLS globálisan le lett bontva a routeren, öt hardvert konfiguráltak, de a hiba nem hatodikán észrevették, más személy által végrehajtott régi változtatásokat követték el. Rengeteg forgatókönyv létezik.

Az automatizálás lehetővé teszi, hogy kevesebb hibát kövessünk el, de nagyobb léptékben. Így nem csak egy eszközt, hanem a teljes hálózatot is leblokkolhatja egyszerre.

Nagyapáink ősidők óta éles szemmel, acélgömbökkel és a hálózat működőképességével ellenőrizték az elvégzett változtatások helyességét azok kiépítése után.
Azok a nagypapák, akiknek munkája leálláshoz és katasztrofális veszteségekhez vezetett, kevesebb utódot hagytak maguk után, és idővel ki kell halniuk, de az evolúció lassú folyamat, ezért még mindig nem mindenki teszteli először a változásokat a laboratóriumban.
A haladás élén azonban azok állnak, akik automatizálták a konfiguráció tesztelésének folyamatát és a hálózaton való további alkalmazását. Más szóval, kölcsönkértem a CI/CD eljárást (Folyamatos integráció, folyamatos telepítés) a fejlesztőktől.
Az egyik részben megvizsgáljuk, hogyan lehet ezt megvalósítani egy verziókezelő rendszerrel, valószínűleg Github-al.

Miután megszokta a hálózati CI/CD gondolatát, egyik napról a másikra kora középkori tudatlanságnak fog tűnni a konfiguráció ellenőrzésének módszere a termelési hálózaton történő alkalmazással. Olyan, mintha kalapáccsal ütnének el egy robbanófejet.

Az eszmék szerves folytatása arról rendszer A hálózatkezelés és a CI/CD a konfiguráció teljes verziójává válik.

Verziószámítás

Feltételezzük, hogy bármilyen apró változtatással, még egy észrevehetetlen eszközön is, a teljes hálózat egyik állapotból a másikba kerül.
És mindig nem parancsot hajtunk végre az eszközön, hanem megváltoztatjuk a hálózat állapotát.
Tehát nevezzük ezeket az állapotokat verzióknak?

Tegyük fel, hogy a jelenlegi verzió 1.0.0.
Megváltozott a Loopback interfész IP-címe az egyik ToR-on? Ez egy kisebb verzió, és 1.0.1 lesz a sorszáma.
Felülvizsgáltuk az útvonalak BGP-be történő importálására vonatkozó irányelveket - kicsit komolyabban - már 1.1.0
Úgy döntöttünk, hogy megszabadulunk az IGP-től, és csak a BGP-re váltunk - ez már radikális tervezési változás - 2.0.0.

Ugyanakkor a különböző DC-k különböző verziókkal rendelkezhetnek - a hálózat fejlődik, új berendezéseket telepítenek, valahol új szinteket adnak hozzá, másokban nem stb.

Про szemantikai verziószámítás külön cikkben fogunk beszélni.

Ismétlem - minden változtatás (kivéve a hibakereső parancsokat) verziófrissítés. A rendszergazdákat értesíteni kell az aktuális verziótól való bármilyen eltérésről.

Ugyanez vonatkozik a változtatások visszaállítására is - ez nem az utolsó parancsok törlése, ez nem az eszköz operációs rendszerének visszaállítása - ez a teljes hálózat új (régi) verzióra hozása.

A szolgáltatások monitorozása, öngyógyítása

Ez a magától értetődő feladat új szintre lépett a modern hálózatokban.
A nagy szolgáltatók gyakran azt a megközelítést alkalmazzák, hogy egy meghibásodott szolgáltatást nagyon gyorsan meg kell javítani, és újat kell létrehozni, ahelyett, hogy kitalálnák, mi történt.
A „nagyon” azt jelenti, hogy minden oldalról nagyvonalúan be kell vonni a felügyeletet, amely másodperceken belül észleli a legkisebb eltérést a normától.
És itt már nem elegendőek a szokásos mérőszámok, mint például az interfész betöltése vagy a csomópontok elérhetősége. Ezeknek az ügyeletes általi kézi felügyelete sem elegendő.
Sok mindenhez kellene Öngyógyító — pirosra váltak a felügyeleti lámpák, és mi magunk mentünk be és alkalmaztuk az útifűszert, ahol fájt.

És itt nem csak az egyes eszközöket figyeljük, hanem a teljes hálózat állapotát is, mind a whitebox, ami viszonylag érthető, mind a blackbox, ami bonyolultabb.

Mire lesz szükségünk az ilyen ambiciózus tervek megvalósításához?

• Legyen egy listája a hálózaton lévő összes eszközről, azok helyéről, szerepeiről, modelljeiről és szoftververzióiról.
  kazan-leaf-1.lmu.net, Kazan, levél, Juniper QFX 5120, R18.3.
• Legyen rendszere a hálózati szolgáltatások leírására.
  IGP, BGP, L2/3VPN, Házirend, ACL, NTP, SSH.
• Legyen képes inicializálni az eszközt.
  Gazdanév, Mgmt IP, Mgmt útvonal, Felhasználók, RSA-kulcsok, LLDP, NETCONF
• Konfigurálja az eszközt, és állítsa be a konfigurációt a kívánt (beleértve a régi) verziót is.
• Tesztkonfiguráció
• Rendszeresen ellenőrizze az összes eszköz állapotát, hogy eltér-e a jelenlegitől, és jelentse, kinek kell lennie.
  Egyik napról a másikra valaki csendben hozzáadott egy szabályt az ACL-hez.
• Monitor teljesítmény.

alapok

Elég bonyolultnak hangzik ahhoz, hogy elkezdjük a projekt komponensekre bontását.

És lesz belőle tíz:

1. Leltári rendszer
2. IP területkezelő rendszer
3. Hálózati szolgáltatásleíró rendszer
4. Az eszköz inicializálási mechanizmusa
5. Szállító-agnosztikus konfigurációs modell
6. Szállító-specifikus illesztőprogram-interfész
7. A konfiguráció eszközhöz való eljuttatásának mechanizmusa
8. CI / CD
9. A biztonsági mentés és az eltérések keresésének mechanizmusa
10. Megfigyelő-rendszer

Ez egyébként egy példa arra, hogyan változott a ciklus céljairól alkotott nézet – a tervezetben 4 komponens szerepelt.

Az ábrán az összes alkatrészt és magát a készüléket ábrázoltam.
Az egymást metsző komponensek kölcsönhatásba lépnek egymással.
Minél nagyobb a blokk, annál nagyobb figyelmet kell fordítani erre az összetevőre.

1. komponens: Leltári rendszer

Nyilván azt szeretnénk tudni, hogy milyen berendezések hol találhatók, mire csatlakoznak.
A készletezési rendszer minden vállalkozás szerves része.
Leggyakrabban egy vállalat külön leltári rendszerrel rendelkezik a hálózati eszközök számára, amely speciálisabb problémákat old meg.
A cikksorozat részeként DCIM - Data Center Infrastructure Management néven fogjuk nevezni. Bár maga a DCIM kifejezés szigorúan véve sokkal többet foglal magában.

Céljaink érdekében a készülékről a következő információkat tároljuk benne:

• Készletszám
• Cím/Leírás
• Modell (Huawei CE12800, Juniper QFX5120 stb.)
• Jellemző paraméterek (táblák, interfészek stb.)
• Szerep (Leaf, Spine, Border Router stb.)
• Helyszín (régió, város, adatközpont, állvány, egység)
• Eszközök közötti kapcsolatok
• Hálózati topológia

Teljesen világos, hogy mi magunk akarjuk mindezt tudni.
De vajon segít ez az automatizálási célokra?
Természetesen.
Például tudjuk, hogy egy adott adatközpontban a Leaf switcheken, ha az Huawei, akkor bizonyos forgalom szűrésére ACL-eket kell alkalmazni a VLAN-on, ha pedig Juniper, akkor a fizikai interfész 0-ás egységén.
Vagy egy új Syslog-kiszolgálót kell kihelyeznie a régió összes határára.

Ebben virtuális hálózati eszközöket fogunk tárolni, például virtuális útválasztókat vagy gyökérreflektorokat. Hozzáadhatunk DNS-kiszolgálókat, NTP-t, Syslog-ot és általában mindent, ami valamilyen módon a hálózathoz kapcsolódik.

2. komponens: IP-terület-kezelő rendszer

Igen, és manapság vannak olyan emberek, akik nyomon követik az előtagokat és az IP-címeket egy Excel-fájlban. A modern megközelítés azonban továbbra is egy adatbázis, nginx/apache előtérrel, API-val és kiterjedt funkciókkal az IP-címek és a VRF-ekre osztott hálózatok rögzítésére.
IPAM – IP-címkezelés.

Céljaink érdekében a következő információkat tároljuk benne:

• VLAN
• VRF
• Hálózatok/alhálózatok
• IP-címek
• Címek kötése eszközökhöz, hálózatok helyekhez és VLAN-számokhoz

Ismét egyértelmű, hogy szeretnénk megbizonyosodni arról, hogy amikor új IP-címet osztunk ki a ToR visszacsatoláshoz, ne botljunk bele a ténybe, hogy az már hozzá van rendelve valakihez. Vagy kétszer használtuk ugyanazt az előtagot a hálózat különböző végein.
De hogyan segít ez az automatizálásban?
Könnyen.
Kérünk a rendszerben egy előtagot Loopback szerepkörrel, amely a kiosztásra rendelkezésre álló IP címeket tartalmazza - ha megtaláljuk, kiosztjuk a címet, ha nem, akkor új előtag létrehozását kérjük.
Illetve egy eszközkonfiguráció elkészítésekor ugyanabból a rendszerből megtudhatjuk, hogy melyik VRF-ben kell az interfésznek elhelyezkednie.
Új szerver indításakor pedig a script bejelentkezik a rendszerbe, megtudja, hogy melyik kapcsolóban van a szerver, melyik port és melyik alhálózat van hozzárendelve az interfészhez - és ebből osztja ki a szerver címét.

Ez azt sugallja, hogy a DCIM-et és az IPAM-ot egy rendszerbe kívánják egyesíteni, hogy ne duplikáljanak a funkciókat, és ne szolgáljanak ki két hasonló entitást.
Ezt fogjuk tenni.

3. komponens. A hálózati szolgáltatások leírására szolgáló rendszer

Ha az első két rendszer olyan változókat tárol, amelyeket valahogy még használni kell, akkor a harmadik minden eszközszerepkörhöz leírja, hogyan kell azt konfigurálni.
Érdemes megkülönböztetni két különböző típusú hálózati szolgáltatást:

• Infrastruktúra
• Ügyfél.

Az előbbiek alapvető csatlakoztathatóságot és eszközvezérlést biztosítanak. Ezek közé tartozik a VTY, SNMP, NTP, Syslog, AAA, útválasztási protokollok, CoPP stb.
Utóbbiak szervezik a szolgáltatást a kliens számára: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP stb.
Persze vannak határesetek is – hova kell beleírni az MPLS LDP-t, BGP-t? Igen, és az útválasztási protokollok használhatók az ügyfelek számára. De ez nem fontos.

Mindkét típusú szolgáltatás konfigurációs primitívekre van bontva:

• fizikai és logikai interfészek (tag/anteg, mtu)
• IP-címek és VRF-ek (IP, IPv6, VRF)
• ACL-ek és forgalomfeldolgozási szabályzatok
• Protokollok (IGP, BGP, MPLS)
• Útválasztási házirendek (előtaglisták, közösségek, ASN-szűrők).
• Közüzemi szolgáltatások (SSH, NTP, LLDP, Syslog...)
• Stb.

Hogy pontosan hogyan fogjuk ezt megtenni, még fogalmam sincs. Ezt egy külön cikkben fogjuk megvizsgálni.

Ha egy kicsit közelebb áll az élethez, akkor ezt leírhatnánk
A Leaf kapcsolónak rendelkeznie kell BGP-munkamenetekkel az összes csatlakoztatott Spine-kapcsolóval, importálnia kell a csatlakoztatott hálózatokat a folyamatba, és csak egy bizonyos előtagból származó hálózatokat kell elfogadnia a Spine switch-ekből. A CoPP IPv6 ND korlátozása 10 pps-ra stb.
A tüskék viszont az összes csatlakoztatott vezetékkel tartanak üléseket, amelyek gyökérreflektorként működnek, és csak bizonyos hosszúságú és meghatározott közösséggel rendelkező útvonalakat fogadnak el tőlük.

4. komponens: Eszköz inicializálási mechanizmus

Ez alatt a címszó alatt számos olyan műveletet egyesítek, amelyeknek meg kell történniük ahhoz, hogy egy eszköz megjelenjen a radaron, és távolról elérhető legyen.

1. Írja be a készüléket a leltári rendszerbe.
2. Válasszon ki egy felügyeleti IP-címet.
3. Állítsa be az alapvető hozzáférést:
   Gazdanév, felügyeleti IP-cím, útvonal a felügyeleti hálózathoz, felhasználók, SSH-kulcsok, protokollok - telnet/SSH/NETCONF

Három megközelítés létezik:

• Minden teljesen manuális. Az eszközt az állványra viszik, ahol egy hétköznapi organikus ember beviszi a rendszerekbe, csatlakozik a konzolhoz és konfigurálja. Működhet kis statikus hálózatokon.
• ZTP – Zero Touch Provisioning. Megérkezett a hardver, felállt, DHCP-n keresztül címet kapott, egy speciális szerverre ment, és beállította magát.
• A konzolkiszolgálók infrastruktúrája, ahol a kezdeti konfiguráció a konzolporton keresztül történik automatikus módban.

Mindháromról külön cikkben fogunk beszélni.

5. komponens: Szállító-agnosztikus konfigurációs modell

Eddig minden rendszer különböző folt volt, amelyek változókat és deklaratív leírást adnak arról, hogy mit szeretnénk látni a hálózaton. De előbb-utóbb meg kell küzdenie a konkrétumokkal.
Ebben a szakaszban minden egyes eszköz esetében a primitívek, a szolgáltatások és a változók összeállnak egy konfigurációs modellben, amely ténylegesen leírja egy adott eszköz teljes konfigurációját, csak a gyártótól független módon.
Mit csinál ez a lépés? Miért nem hoz létre azonnal egy eszközkonfigurációt, amelyet egyszerűen feltölthet?
Valójában ez három problémát old meg:

1. Ne alkalmazkodjon egy adott interfészhez az eszközzel való interakcióhoz. Legyen szó CLI, NETCONF, RESTCONF, SNMP - a modell ugyanaz lesz.
2. Ne tartsa meg a sablonok/szkriptek számát a hálózaton lévő szállítók számának megfelelően, és ha a kialakítás megváltozik, változtassa meg ugyanazt több helyen.
3. Töltse be a konfigurációt az eszközről (mentés), helyezze be pontosan ugyanabba a modellbe, és közvetlenül hasonlítsa össze a célkonfigurációt a meglévővel, hogy kiszámítsa a delta értéket, és készítsen egy konfigurációs javítást, amely csak azokat a részeket módosítja, amelyek szükségesek, vagy az eltérések azonosításához.

Ennek a szakasznak az eredményeként szállítófüggetlen konfigurációt kapunk.

6. komponens. Szállító-specifikus illesztőprogram-interfész

Nem szabad azzal a reményekkel hízelegnie, hogy egy napon pontosan úgy lehet majd beállítani egy ciskát, mint egy Borókát, pusztán úgy, hogy pontosan ugyanazokat a hívásokat küldi nekik. A whiteboxok növekvő népszerűsége, valamint a NETCONF, RESTCONF, OpenConfig támogatásának megjelenése ellenére a konkrét tartalom, amelyet ezek a protokollok szállítanak, gyártónként eltérőek, és ez az egyik versenybeli különbség, amelyet nem adnak fel olyan könnyen.
Ez nagyjából ugyanaz, mint az OpenContrail és az OpenStack, amelyeknek a NorthBound felülete a RestAPI, teljesen más hívásokra számítanak.

Tehát az ötödik lépésben a gyártó-független modellnek olyan formát kell vennie, amelyben hardverre kerül.
És itt minden eszköz jó (nem): CLI, NETCONF, RESTCONF, SNMP egyszerűen.

Ezért szükségünk lesz egy illesztőprogramra, amely az előző lépés eredményét átviszi egy adott gyártó szükséges formátumába: CLI-parancsok halmaza, XML-struktúra.

7. komponens. A konfiguráció eszközhöz való eljuttatásának mechanizmusa

A konfigurációt elkészítettük, de azt még ki kell juttatni a készülékekre – és nyilván nem kézzel.
Először, azzal a kérdéssel állunk szemben, hogy milyen közlekedési eszközt fogunk használni? És ma már nem kicsi a választék:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (bár ez egy kiugró érték, mert ez egy módja a FIB szállításának, nem a beállításoknak)

Parancsoljuk ide a t-t. A CLI örökölt. SNMP... köhögés köhögés.
A RESTCONF még mindig ismeretlen állat, a REST API-t szinte senki sem támogatja. Ezért a sorozatban a NETCONF-ra fogunk összpontosítani.

Valójában, ahogy az olvasó már megértette, ekkor már döntöttünk a felületről - az előző lépés eredménye már a kiválasztott felület formátumában jelenik meg.

Másodszor, és milyen eszközökkel fogjuk ezt megtenni?
Itt is nagy a választék:

• Ön által írt forgatókönyv vagy platform. Vegyük fel magunkat az ncclient és asyncIO segítségével, és csináljunk meg mindent magunk. Mennyibe kerül egy üzembe helyezési rendszer felépítése a semmiből?
• Lehetséges a hálózati modulok gazdag könyvtárával.
• Só a hálózattal való csekély munkával és a Napalmmal való kapcsolattal.
• Tulajdonképpen a Napalm, ami ismer pár eladót és ennyi, viszlát.
• A nornir egy másik állat, amelyet a jövőben boncolgatunk.

Itt még nem választották ki a kedvencet - keresni fogunk.

Mi más fontos itt? A konfiguráció alkalmazásának következményei.
Sikeres vagy sem. Van még hozzáférés a hardverhez vagy sem?
Úgy tűnik, hogy a commit itt segít az eszközre letöltött adatok megerősítésében és érvényesítésében.
Ez a NETCONF helyes megvalósításával együtt jelentősen leszűkíti a megfelelő eszközök körét – nem sok gyártó támogatja a normál véglegesítést. De ez csak az egyik előfeltétele RFP. A végén senki sem aggódik amiatt, hogy egyetlen orosz gyártó sem felel meg a 32*100GE interfész feltételnek. Vagy aggódik?

8. komponens. CI/CD

Ezen a ponton már készen áll a konfiguráció minden hálózati eszközhöz.
„Mindenre” írok, mert a hálózati állapot verziószámításáról beszélünk. És még akkor is, ha csak egy kapcsoló beállításait kell módosítania, a változtatásokat a rendszer a teljes hálózatra számítja ki. Nyilvánvalóan a legtöbb csomópontnál nullák lehetnek.

De ahogy fentebb már elhangzott, nem vagyunk valami barbárok, akik mindent egyenesen a termelésbe akarnak forgatni.
Az előállított konfigurációnak először át kell mennie a Pipeline CI/CD-n.

A CI/CD a Continuous Integration, Continuous Deployment rövidítése. Ez egy olyan megközelítés, amelyben a csapat nem csak félévente ad ki egy új fő kiadást, amely teljesen lecseréli a régit, hanem rendszeresen, fokozatosan, kis részletekben új funkciókat vezet be (telepítés), amelyek mindegyikét átfogóan tesztelik a kompatibilitás, a biztonság és a biztonság szempontjából. teljesítmény (Integráció).

Ehhez van egy verzió-ellenőrző rendszerünk, amely figyeli a konfigurációs változásokat, egy laboratórium, amely ellenőrzi, hogy az ügyfélszolgálat megszakadt-e, egy felügyeleti rendszerünk, amely ellenőrzi ezt a tényt, és az utolsó lépés a változtatások bevezetése a termelési hálózatba.

A hibakeresési parancsok kivételével a hálózaton végbemenő összes változtatásnak a CI/CD Pipeline-on kell keresztülmennie – ez a mi garanciánk a nyugodt életre és a hosszú, boldog karrierre.

9. komponens. Biztonsági és anomália-érzékelő rendszer

Nos, nem kell ismét a biztonsági mentésekről beszélni.
Egyszerűen git-be helyezzük őket a koronának megfelelően, vagy konfigurációváltás ténye alapján.

De a második rész érdekesebb – valakinek figyelnie kell ezeket a biztonsági másolatokat. És bizonyos esetekben ennek a valakinek el kell mennie, és mindent úgy kell fordítania, ahogy volt, máskor pedig nyávog valakinek, hogy valami nincs rendben.
Például, ha egy új felhasználó jelent meg, aki nincs regisztrálva a változókban, akkor el kell távolítania a feltöréstől. És ha jobb, ha nem nyúlunk hozzá egy új tűzfalszabályhoz, akkor lehet, hogy valaki most bekapcsolta a hibakeresést, vagy az új szolgáltatás, a bungler nem volt regisztrálva a szabályok szerint, de már csatlakoztak hozzá.

Az automatizálási rendszerek és a menedzsment acélos keze ellenére továbbra sem kerülünk el egy kis delta a teljes hálózat léptékében. A hibakereséshez senki sem fog konfigurációt hozzáadni a rendszerekhez. Sőt, előfordulhat, hogy nem is szerepelnek a konfigurációs modellben.

Például egy tűzfalszabály, amely egy adott IP-címenkénti csomagok számát számolja a probléma lokalizálásához, egy teljesen közönséges ideiglenes konfiguráció.

10. komponens. Monitoring rendszer

Először nem foglalkoztam a monitorozás témájával – ez még mindig terjedelmes, vitatott és összetett téma. A dolgok előrehaladtával azonban kiderült, hogy ez az automatizálás szerves része. És lehetetlen megkerülni, még gyakorlás nélkül is.

Az Evolving Thought a CI/CD folyamat szerves része. A konfiguráció hálózatra terjesztése után meg kell tudnunk állapítani, hogy most minden rendben van-e vele.
És nem csak és nem annyira az interfész használati ütemezéséről vagy a csomópontok elérhetőségéről beszélünk, hanem sokkal finomabb dolgokról - a szükséges útvonalak meglétéről, a rajtuk lévő attribútumokról, a BGP-munkamenetek számáról, az OSPF szomszédokról, a végpontok közötti teljesítményről. a felülmúló szolgáltatásokról.
A külső kiszolgálón lévő rendszernaplók nem gyűlnek össze, vagy az SFlow ügynök tönkrement, vagy a sorok csökkenése elkezdett nőni, vagy megromlott a kapcsolat néhány előtagpár között?

Erről egy külön cikkben fogunk reflektálni.

Következtetés

Alapnak a modern adatközponti hálózatok egyikét választottam - az L3 Clos Fabricot BGP-vel, mint útválasztási protokollt.
Ezúttal a Juniperre építjük a hálózatot, mert a JunOs interfész most egy vanlove.

Nehezítsük meg az életünket azzal, hogy kizárólag nyílt forráskódú eszközöket és több gyártós hálózatot használunk – így a Juniper mellett még egy szerencsés személyt választok az úton.

A következő kiadványok terve a következő:
Először a virtuális hálózatokról beszélek. Először is azért, mert szeretném, másodszor pedig azért, mert e nélkül nem lesz túl egyértelmű az infrastruktúra-hálózat kialakítása.
Aztán magáról a hálózattervezésről: topológia, útválasztás, házirendek.
Szereljünk össze egy laboratóriumi állványt.
Gondoljunk bele, és gyakoroljuk az eszköz inicializálását a hálózaton.
És akkor az egyes összetevőkről intim részletességgel.

És igen, nem ígérem, hogy kecsesen lezárom ezt a ciklust egy kész megoldással. 🙂

Hasznos Linkek

• Mielőtt belemerülnénk a sorozatba, érdemes elolvasni Natasha Samoilenko könyvét Python hálózati mérnökök számára. És talán elmúlik tanfolyam.
• Hasznos lesz elolvasni is RFC az adatközponti gyárak tervezéséről a Facebookról, Peter Lapukhovtól.
• Az architektúra dokumentációja képet ad az Overlay SDN működéséről. Volfrám szövet (korábban Open Contrail).

Köszönöm

Római szurdok. Megjegyzésekhez és szerkesztésekhez.
Artyom Csernobay. A KDPV számára.

Forrás: will.com