A SDSM has ended, but the uncontrollable desire to write remains.

For many years, our brother suffered from routine work, crossing his fingers before each commit and losing sleep due to nightly rollbacks.
But dark times come to an end.

With this article, I will start a series on how tudasd velem. Remélem, hogy ez a cikk segített nektek a dolgaikban. Szeretném hinni, hogy miután elolvastátok, annyit tanultatok, mint én, miközben minden olyan dologgal foglalkoztam, amiről beszéltem benne. automation is perceived.
Along the way, we will discuss automation stages, variable storage, design formalization, RestAPI, NETCONF, YANG, YDK, and we will be doing a lot of programming.
For me it means that a) this is not an objective truth, b) it is not an unequivocally better approach, c) my view may change even from the first to the last article — to be honest, from the draft stage to publication, I rewrote everything completely twice.

Tartalom

1. Célok
   1. The network is like a single organism
   2. Configuration testing
   3. Verziókezelés
   4. Monitoring and self-healing of services

2. Tools
   1. Inventory system
   2. IP space management system
   3. Network service description system
   4. Device initialization mechanism
   5. Vendor-agnostic configuration model
   6. Vendor-specific driver interface
   7. Configuration delivery mechanism to the device
   8. CI/CD
   9. Backup mechanism and anomaly detection
   10. Monitoring system

3. Zárás

I will try to lead the ADSM format a bit differently from SDSM. There will still be substantial numbered articles appearing, and between them, I will publish brief notes from daily experiences. I will try to battle my perfectionism here and not polish each of them too much.

How funny it is to have to walk the same path a second time.

Initially, I had to write articles about networks myself because there weren't any on the Russian-speaking internet.

Now I couldn't find a comprehensive document that systematized approaches to automation and examined the aforementioned technologies through simple practical examples.

I might be wrong, so feel free to throw links to useful resources. However, this won't change my determination to write, because the main goal is still to learn something myself, and making life easier for others is a nice bonus that enhances the spread of knowledge.

We will attempt to take a medium-sized data center, LAN DC, and work through the entire automation scheme.
I will do some things almost for the first time together with you.

A leírásban szereplő ötletekben és eszközökben nem leszek eredeti. Dmitrij Figolj számára kiváló csatornája van a témában folytatott közvetítésekhez..
A cikkek sok szempontból metszik egymást.

A LAN DC 4 adatközponttal, körülbelül 250 switch-csel, fél tucat routerrel és pár tűzfallal rendelkezik.
Nem Facebook, de elegendő ahhoz, hogy mélyen elgondolkodjunk az automatizálásról.
Az a vélemény terjedt el, hogy ha több mint 1 eszközöd van, már szükséges az automatizálás.
Valójában nehéz elképzelni, hogy valaki mostanában élhet anélkül, hogy legalább egy csomag scriptet ne használjon.
Bár hallottam olyan cégekről, ahol az IP-címek nyilvántartása Excelben történik, és az ezer hálózati eszköz mindegyikét manuálisan állítják be, különálló konfigurációkkal. Ezt persze modern művészetként lehetne előadni, de egy mérnök érzései biztosan megsértődnének.

Célok

Most maximálisan absztrakt célokat fogunk kitűzni:

• The network is like a single organism
• Configuration testing
• A hálózat állapotának verziózása
• Monitoring and self-healing of services

Később ebben a cikkben kielemezzük, hogy milyen eszközöket fogunk használni, a következő cikkekben pedig a célokat és az eszközöket részletesen.

The network is like a single organism

A ciklus meghatározó mondata, habár első pillantásra nem tűnik jelentősnek: mi a hálózatot állítjuk be, nem pedig egyes eszközöket..
Az utolsó években azt tapasztaljuk, hogy a hangsúly a hálózat egyetlen entitásként való kezelésére helyeződött át, és így jönnek be az életünkbe Szoftver Definiált Hálózatok, Intencionális Hálózatok és Autonóm Hálózatok.
Hiszen ami globálisan szükséges az alkalmazások számára a hálózattól: kapcsolódás A és B pontok között (néha +B-Y) és izoláció a többi alkalmazástól és felhasználótól.

Így tehát a célunk ennek a sorozatnak az lesz, hogy kiépítsünk egy rendszert, amely fenntartja az aktuális konfigurációt az egész hálózatra, amely már lebontásra kerül az aktuális konfigurációra minden eszköznél az adott szerepe és elhelyezkedése szerint.
Rendszer A hálózatkezelés azt jelenti, hogy a változtatások végrehajtásához oda fordulunk, és ő számítja ki az egyes eszközök szükséges állapotát, és konfigurálja azokat.
Így minimalizáljuk a CLI kézi használatát szinte nullára — bármilyen eszközbeállítási vagy hálózatdesign változást formálisan dokumentálni kell — és csak ezután lehet bevezetni a szükséges hálózati elemekbe.

Például, ha úgy döntöttünk, hogy ettől a pillanattól kezdve a kazanyi rácsos switcheknek két hálózatot kell hirdetniük egy helyett, akkor

1. Először dokumentáljuk a változásokat a rendszerekben
2. Generáljuk a hálózat összes eszközének célkonfigurációját
3. Elindítjuk a hálózati konfiguráció frissítő programját, amely kiszámítja, hogy mit kell eltávolítani minden csomóponton, mit kell hozzáadni, és az állapotokat a szükséges állapotba hozza.

Kézi beavatkozással csak az első lépésben végezzük el a módosításokat.

Configuration testing

Ismert,, hogy a problémák 80%-a a konfiguráció megváltoztatásának időszakában lép fel - ennek közvetett bizonyítéka, hogy az év végi ünnepek alatt általában minden nyugodt.
Személyesen tanúja voltam tucatnyi globális leállásnak emberi hiba miatt: hibás parancs, nem a megfelelő konfigurációs ágon hajtották végre, elfelejtették a közösséget, globálisan törölték az MPLS-t az útválasztón, öt berendezést beállítottak, de a hatodikat nem vették észre, és a másik személy által végzett régebbi módosításokat becommitálták. Számtalan forgatókönyv létezik.

A automatizálás lehetővé teszi, hogy kevesebb hibát kövessünk el, de nagyobb méretekben. Így nemcsak egy eszközt, hanem egy egész hálózatot is megdönthetünk.

Örök idők óta őseink látásával, acélos bátorságukkal és a hálózat működőképességének ellenőrzésével biztosították a változások helyességét.
Azok az őseink, akiknek munkái leállásokhoz és katasztrofális veszteségekhez vezettek, 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 ellenőrzi előre a változásokat a laborban.
A fejlődés élvonalában azonban azok állnak, akik automatizálták a konfiguráció tesztelésének folyamatát, és annak további alkalmazását a hálózaton. Más szóval — átvették a CI/CD eljárást (Folyamatos integráció, folyamatos telepítés) a fejlesztőktől.
Egy részben áttekintjük, hogyan valósítható meg ez verziókezelő rendszer segítségével, valószínűleg a GitHubon.

Amint elfogadja a hálózati CI/CD gondolatát, a konfiguráció alkalmazásának módszere a működő hálózatra hirtelen középkori tudatlanságnak fog tűnni. Körülbelül úgy, mint ha kalapáccsal ütögetnénk egy nukleáris fegyver fegyverének törzsén.

Az ötletek természetes folytatásaként a rendszerre hálózatkezelés és CI/CD teljes verziózásává válik a konfigurációnak.

Verziókezelés

Feltételezzük, hogy bármilyen változás, még a legkisebb, még egy szinte láthatatlan eszközön is, az egész hálózatot átviszi egy másik állapotba.
Mindig úgy cselekszünk, hogy nem a készüléken végrehajtani a parancsot, hanem megváltoztatjuk a hálózat állapotát.
Akkor ezeket az állapotokat nevezzük verzióknak?

Tegyük fel, hogy a jelenlegi verzió – 1.0.0.
Megváltozott a Loopback interfész IP-címe az egyik ToR-nál? Ez egy kis verzióváltás – 1.0.1-es számot kap.
Felülvizsgáltuk a BGP-ben a route import politikákat – ez már komolyabb változás – 1.1.0.
Ha úgy döntünk, hogy megszabadulunk az IGP-től és csak BGP-re váltunk – ez már egy radikális dizájnváltozás – 2.0.0.

Eközben különböző DC-k eltérő verzióval rendelkezhetnek – a hálózat fejlesztése, új berendezések telepítése, néhány helyen új spine szintek hozzáadása, máshol nem, stb.

A szemantikus verziókezelés Erről külön cikkben beszélünk.

Ismétlem – bármilyen változtatás (kivéve a debug parancsokat) – verziófrissítést jelent. Az aktuális verziótól való eltérésekről értesíteni kell az adminisztrátorokat.

Ugyanez vonatkozik a változtatások visszagörgetésére – ez nem az utolsó parancsok törlése, nem a rollback az eszköz operációs rendszerének erejével – ez az egész hálózatot új (régi) verzióba állítja.

Monitoring and self-healing of services

Ez egy nyilvánvaló feladat a modern hálózatok számára, ami új szintre lép.
Gyakran a nagy szolgáltatók gyakorolnak egy megközelítést, miszerint a leállt szolgáltatást nagyon gyorsan meg kell ölni és újraindítani, ahelyett, hogy kiderítenék, mi történt.
A „nagyon” azt jelenti, hogy minden oldalról bőségesen fel kell készülni a monitorozásra, amelyek másodpercek alatt észlelik a legkisebb eltéréseket a normától.
Itt már nem elég a megszokott metrikák, mint az interfész terheltsége vagy a csomópont elérhetősége. A manual monitoring sem elegendő.
Sok esetben valóban szükség van Öngyógyító – a monitorozások piros lámpákat jeleztek, és maguktól cselekedtek, ahol a probléma jelentkezik.

Itt nem csak a különböző eszközöket figyeljük, hanem az egész hálózat egészségét is, mind fehér dobozban, ami viszonylag világos, mind fekete dobozban, ami már bonyolultabb.

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

• Meg kell lennie a hálózat összes eszközének listájának, azok elhelyezkedésével, szerepével, modelljeivel, szoftververzióival.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Meg kell lennie egy hálózati szolgáltatások leírási rendszerének.
  IGP, BGP, L2/3VPN, Politika, ACL, NTP, SSH.
• Képessé válni az eszköz inicializálására.
  Hostname, Mgmt IP, Mgmt Route, Felhasználók, RSA-Kulcsok, LLDP, NETCONF
• Az eszköz konfigurálása és a konfiguráció szükséges (beleértve a régi) verzióra állítása.
• A konfiguráció tesztelése
• Időszakonként ellenőrizni kell az összes eszköz állapotát a tényleges állapot eltérésével kapcsolatban, és értesíteni az illetékeseket.
  Éjjel valaki csendben hozzáadott egy szabályt az ACL-hez.
• Figyelni a működést.

Tools

Jónak tűnik eléggé bonyolultnak ahhoz, hogy elkezdjük a projekt komponensekre bontását.

És ez tíz lesz:

1. Inventory system
2. IP space management system
3. Network service description system
4. Device initialization mechanism
5. Vendor-agnostic configuration model
6. Vendor-specific driver interface
7. Configuration delivery mechanism to the device
8. CI/CD
9. Backup mechanism and anomaly detection
10. Monitoring system

Ez egy példa arra, hogyan változott a ciklus céljaira vonatkozó nézőpont — a komponens vázlatában 4 szerepelt.

A képen minden komponenst és magát az eszközt ábrázoltam.
A metsző komponensek kölcsönhatásban állnak egymással.
Minél nagyobb a blokk, annál több figyelmet kell fordítani ennek a komponensnek.

1. komponens. Leltározási rendszer

Nyilvánvaló, hogy tudni szeretnénk, hogy milyen berendezés, hol van, mivel csatlakozik.
A leltározási rendszer elengedhetetlen része bármely vállalkozásnak.
Leggyakrabban a hálózati eszközök esetében a vállalat külön leltározási rendszert alkalmaz, amely specifikusabb feladatokat lát el.
A cikkciklus során ezt DCIM-nek – Data Center Infrastructure Management – fogjuk nevezni. Bár magának a DCIM-nek a kifejezése szigorúan véve sokkal többet jelent.

A feladatainkhoz ebben a rendszerben a következő információkat fogjuk tárolni az eszközről:

• Leltári szám
• Név/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 (regió, város, adatközpont, rack, egység)
• Interkonnekciók az eszközök között
• A hálózat topológiája

Tisztán látható, hogy magunk is mindezt tudni szeretnénk.
De segítene ez az automatizálás céljaira?
Mindenképpen.
Például tudjuk, hogy ebben az adatközpontban, ha Huawei Leaf kapcsolókról van szó, az ACL-t a bizonyos forgalom szűrésére a VLAN-on kell alkalmazni, ha pedig Juniper – akkor a unit 0 fizikai interfészen.
Vagy telepíteni kell egy új Syslog szervert az összes regionális borderre.

Itt fogjuk tárolni a virtuális hálózati eszközöket, például virtuális routereket vagy route-reflectoreket. Beszámíthatunk DNS szervereket, NTP-t, Syslogot és minden olyan dolgot, ami valamilyen módon a hálózathoz kapcsolódik.

2. komponens. IP-címkezelő rendszer

Igen, napjainkban is vannak emberekből álló csoportok, akik Excel-fájlban tartják nyilván a prefixek és IP-címek listáját. De a modern megközelítés egy adatbázis, nginx vagy apache frontenddel, API-val és széleskörű IP-cím- és hálózatkezelési funkciókkal, VRF-re bontva.
IPAM - IP Címkezelés.

A mi feladatunkhoz a következő információkat fogjuk tárolni benne:

• VLAN
• VRF
• Hálózatok / Alműveletek
• IP address
• Címek hozzárendelése eszközökhöz, hálózatok lokalizálásához és VLAN számokhoz

Ismét világos, hogy biztosak akarunk lenni abban, hogy amikor új IP-címet rendelünk a ToR hurokhoz, nem fogunk véletlenül ráakadni, hogy azt már valakinek kiosztották. Vagy hogy ugyanazt a prefixet kétszer használtuk különböző hálózatok végén.
De hogyan segít ez az automatizálásban?
Könnyen.
A rendszerből megkeressük a Loopbacks szerepével rendelkező prefixet, amelyhez IP-címek állnak rendelkezésre - ha találunk, kiosztjuk a címet, ha nem, kérjük egy új prefix létrehozását.
Vagy amikor eszköz konfigurációt hozunk létre, a rendszerből megtudhatjuk, hogy melyik VRF-ben kell lennie a felületnek.
Amikor új szervert indítunk, a szkript megkeresi a rendszert, hogy megtudja, melyik szerverkapcsolón, melyik porton és milyen alhálózat van hozzárendelve a felülethez - ebből fogjuk kiosztani a szerver címét.

Feltűnik az igény, hogy a DCIM-et és az IPAM-ot egy rendszerbe egyesítsük, hogy elkerüljük a funkciók duplikálását és ne kelljen két hasonló entitást kezelni.
Így is fogunk tenni.

3. komponens: Hálózati szolgáltatások leíró rendszere

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

• Infrastruktúrák
• Kliensek.

Az elsődleges céljuk a alapvető kapcsolatok biztosítása és az eszközkezelés. Ilyenek például a VTY, SNMP, NTP, Syslog, AAA, útválasztási protokollok, CoPP, stb.
A másodlagos szolgáltatások az ügyfél számára szerveznek meg egy szolgáltatást: MPLS L2 / L3VPN, GRE, VXLAN, VLAN, L2TP stb.
Természetesen vannak határvonalas esetek - hová soroljuk az MPLS LDP-t, BGP-t? Az útválasztási protokollok is alkalmazhatók az ügyfelek számára. De ez nem lényeges.

Mindkét típusú szolgáltatás konfigurálási primitívekre bontható:

• fizikai és logikai interfészek (cím / tag, mtu)
• IP-címek és VRF (IP, IPv6, VRF)
• ACL-ek és forgalomkezelési szabályok
• Protokollok (IGP, BGP, MPLS)
• Útválasztási politikák (prefix listák, közösségek, ASN szűrők).
• Szolgáltatási szolgáltatások (SSH, NTP, LLDP, Syslog…)
• És így tovább.

Hogyan is fogjuk ezt megvalósítani, arra még nem tudom a választ. Külön cikkben körüljárjuk.

Ha egy kicsit közelebb állunk a valósághoz, leírhatnánk, hogy
A Leaf switch-nek BGP session-öket kell létesítenie az összes csatlakoztatott Spine switch-el, importálnia kell a csatlakoztatott hálózatokat a folyamatba, és a Spine switch-ektől csak meghatározott prefixből érkező hálózatokat kell elfogadnia. A CoPP IPv6 ND-t korlátozni kell 10 pps-re, és így tovább.
A Spine switch-ek pedig session-öket tartanak fenn az összes csatlakoztatott Leaf switch-el, mint route reflector-ké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. Az eszköz inicializálási mechanizmusa

Ezen a címen sok olyan tevékenységet fogok össze, amelyeknek meg kell történnie ahhoz, hogy az eszköz láthatóvá váljon, és távolról elérhető legyen.

1. Az eszköz nyilvántartási rendszerbe való bevitele.
2. Irányító IP-cím kiadása.
3. Alapvető hozzáférés beállítása:
   Hostname, irányító IP-cím, átjáró a kezelőhálózathoz, felhasználók, SSH kulcsok, protokollok — telnet/SSH/NETCONF

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

• Teljesen kézi. Az eszközt elhozzák a standra, ahol egy hagyományos ember beviszi a rendszerekbe, csatlakozik a konzolhoz és beállítja. Kisebb statikus hálózatokban működhet.
• ZTP — Zero Touch Provisioning. A hardver megérkezett, beállt, DHCP-n kapott címet, és elment egy speciális szerverre, majd önállóan konfigurálta magát.
• Konzol szerver infrastruktúra, ahol az első beállítás automatikusan történik a konzol porton keresztül.

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

5. komponens. Szolgáltatófüggetlen konfigurációs modell

Eddig minden rendszer különálló, szigetszerű részekből állt, amelyek változókat és deklaratív leírást adnak arról, amit a hálózaton látni szeretnénk. De előbb-utóbb konkrétumokkal is foglalkoznunk kell.
Ezen a szakaszon minden egyes konkrét eszköz esetében az primitívek, szolgáltatások és változók kombinálódnak egy konfigurációs modellben, amely a konkrét eszköz teljes konfigurációját ténylegesen leírja, mindezt szolgáltatófüggetlen módon.
Mit ad ez a lépés? Miért ne formáljuk meg az eszköz konfigurációját azonnal, amelyet egyszerűen feltölthetünk?
Valójában ez három feladat megoldására ad lehetőséget:

1. Ne alkalmazkodj a különböző eszközinterfészekhez. Legyen az CLI, NETCONF, RESTCONF, SNMP — a modell ugyanaz marad.
2. Ne tartsd a sablonok/scriptok számát a hálózaton lévő beszállítók számához. A dizájnváltozások esetén ne kelljen többször is ugyanazt módosítani.
3. Töltsd le a konfigurációt az eszközről (biztonsági mentés), bontsd le ugyanolyan modellé, és közvetlenül hasonlítsd össze a célnak megfelelő konfigurációt a meglévővel, hogy kiszámold a különbséget és elkészítsd a konfigurációs javítást, amely csak azokat a részeket változtatja meg, amelyek szükségesek vagy a eltérések azonosítása érdekében.

Ennek az etapnak az eredményeként független konfigurációt kapunk a beszállítóktól.

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

Ne reménykedj abban, hogy a jövőben a ciscót pontosan úgy tudod majd konfigurálni, mint a junipert, ha egyszerűen csak ugyanazokat a hívásokat küldöd el. Annak ellenére, hogy a whiteboxok népszerűsége növekszik, és megszületett a NETCONF, RESTCONF, OpenConfig támogatása, az ezekkel a protokollokkal átadott konkrét tartalom beszállítónként eltérő, és ez az egyik versenyelőnyük, amelyet nem fognak könnyen feladni.
Ez körülbelül olyan, mint az OpenContrail és az OpenStack, amelyek RestAPI-t használnak és teljesen különböző hívásokat várnak el.

Tehát az ötödik lépésben a beszállítók független modelljének azt a formát kell felvennie, amely készen áll a hardverre történő telepítésre.
Itt aztán minden eszköz használható (nem): CLI, NETCONF, RESTCONF, SNMP egyszerűen.

Ezért szükségünk lesz egy illesztőprogramra, amely a korábbi lépés eredményét konkrét beszállítói formátumba helyezi át: CLI parancsok sorozata, XML struktúra.

7. komponens. A konfiguráció eszközre juttatásának mechanizmusa

A konfigurációt már generáltuk, de azt még el is kell juttatni az eszközökre — nyilvánvalóan nem manuálisan.
Először is, felmerül a kérdés, hogy milyen szállítóeszközt fogunk használni? A választék ma már nem kicsi:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (bár ez a listából kissé kilóg, mivel ez a FIB küldésének módja, nem a beállításoké)

Nézzük, rendet kellene tenni. A CLI az örökség. Az SNMP... khöm-khöm.
A RESTCONF — még mindig ismeretlen állat, a REST API-t szinte senki sem támogatja. Ezért a ciklus során a NETCONF-ra fogunk összpontosítani.

Valójában, ahogy az olvasó már rájött, az interfészt a fentebbi pillanatban már meghatároztuk — a korábbi lépés eredménye már a választott interfész formátumában van prezentálva.

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

• Saját írású szkript vagy platform. Felszerelkezünk ncclient-tel és asyncIO-val, és megcsináljuk magunk. Miért ne építhetnénk meg a telepítési rendszert a nulláról?
• Ansible a gazdag hálózati modul könyvtárával.
• Salt a szegényes hálózati munkájával és Napalm összekapcsolódásával.
• Tulajdonképpen a Napalm, ami ismer néhány gyártót, és ennyi, viszlát.
• Nornir — egy másik állat, amelyet a jövőben elemezni fogunk.

Itt még nem választották ki a kedvencet — tapogatózunk.

Mi még fontos itt? A konfiguráció alkalmazásának következményei.
Sikeres vagy sem. Megmaradt-e a hozzáférés a hardverhez vagy sem.
Úgy tűnik, itt segíthet a commit megerősítése és érvényesítése, hogy mi került az eszközbe.
Ez a NETCONF helyes megvalósításával együtt jelentősen szűkíti a megfelelő eszközök körét — a normális commitok nem sok gyártót támogatnak. De ez csak egy kötelező feltétel az RFP. Végül is senki sem aggódik, hogy egy orosz gyártó sem felel meg a 32*100GE interfész feltételeinek. Vagy aggódik?

8. komponens. CI/CD

Erre a pontra már készen áll a konfiguráció az összes hálózati eszköz számára.
Azt írom, hogy «az összes», mert a hálózat állapotának verziókezeléséről beszélünk. És még ha csak egy switch beállításait kell is megváltoztatni, a változtatásokat az egész hálózatra kiszámítják. Nyilvánvaló, hogy ez a legtöbb csomópont esetén nulla lehet.

De, ahogy már korábban említettem, nem vagyunk barbárok, hogy mindent egyszerre toljunk a produktív rendszerbe.
A generált konfigurációnak először át kell mennie egy CI/CD Pipeline-on.

A CI/CD a Folyamatos Integrációt, Folyamatos Telepítést jelenti. Ez egy megközelítés, amelyben a csapat nem fél évben egyszer dobja piacra az új főverziót, teljesen felváltva a régit, hanem rendszeresen, fokozatosan telepíti (Deployment) az új funkciót kis részekben, amelyeket alaposan tesztelnek a kompatibilitás, biztonság és működőképesség szempontjából (Integration).

Ehhez van egy verziókezelő rendszerünk, amely nyomon követi a konfigurációs változásokat, van egy laboratory, ahol ellenőrizzük, hogy a kliensszolgáltatás ne romoljon el, van egy monitorkezelő rendszer, amely ezt ellenőrzi, és az utolsó lépés - a változások kiadása a működő hálózatba.

A hibakereső parancsokat kivéve, a hálózaton végrehajtott összes változásnak át kell mennie a CI/CD Pipeline-on - ez a nyugodt életünk és a hosszú, boldog karrierünk záloga.

9. komponens. Biztonsági mentési és eltérések keresési rendszer.

A biztonsági másolatokról nem árt egyszerűen beszélni.
Csak a cron vagy a konfiguráció gitben való tényleges megváltoztatása alapján fogjuk őket tárolni.

A második rész azonban érdekesebb - ezekért a biztonsági másolatokért valakinek figyelnie kell. Egyes esetekben ennek a valakinek vissza kell állítania mindent, ahogy volt, míg más esetekben szólnia kell valakinek, hogy probléma van.
Például, ha megjelenik egy új felhasználó, aki nincs beírva a változók közé, azt messze kell távolítani a hacktől. Ha pedig egy új tűzfal-szabály lép életbe - jobb, ha nem nyúlkálunk, lehet, hogy valaki csak bekapcsolta a hibakeresést, vagy lehet, hogy az új szolgáltatás, a rest, nem a szabályzat szerint lett felvezetve, de már használják.

Egy bizonyos kis delta a teljes hálózat szempontjából úgyis elkerülhetetlen, bármilyen automatizáló rendszer és acélkezű irányítás mellett. A problémák hibakeresése érdekében senki sem fogja a konfigurációt a rendszerekbe bevinni. Ráadásul a konfigurációs modell talán még nem is teszi lehetővé azokat.

Például, egy tűzfal-szabály a bizonyos IP-címekre érkező csomagok számának megszámolására, a probléma lokalizálására - teljesen rutinszerű ideiglenes konfiguráció.

10. komponens. Ellenőrző rendszer.

Eleinte nem akartam a monitoring témáját feldolgozni - végül is ezt a kérdést átbulizni nehéz, vitatott és bonyolult dolog. De a folyamatok során kiderült, hogy ez az automatizálás elengedhetetlen része. És még csak gyakorlat nélkül sem lehet elkerülni.

A gondolat továbbfejlesztve - ez a CI/CD folyamat organikus része. A konfiguráció kivetítése után a hálózatra képeseknek kell lennünk meghatározni, hogy most minden rendben van-e vele.
És nem csak az interfészek használatának grafikonjaival vagy a csomópontok elérhetőségével, hanem finomabb dolgokkal is - a szükséges útvonalak meglétét, az azokhoz tartozó attribútumokat, a BGP-sessionök, OSPF-szomszédok számát, a kiemelt szolgáltatások End-to-End működőképességét.
Nem álltak le a syslogok külső szerverre való írása, nem mondott csődöt az SFlow-ügynök, nem nőtt-e meg a sorokban a csepp, és nem sérült-e meg a kapcsolat valamilyen prefix pár között?

Egy külön cikkben fogunk erről is elmélkedni.

Zárás

Alapként az egyik modern adatközponti hálózati dizájnt választottam — L3 Clos Fabric BGP routing protokollal.
Ezúttal Juniper alapú hálózatot építünk, mert most a JunOs interfész valóban egyerő.

Megnehezítjük a dolgunkat, csak Open Source eszközöket és multi-vendor hálózatot használva — ezért a Juniper mellett egy másik szerencsés kiválasztottra is szükség lesz.

A közeljövő publikációs tervei körülbelül a következőképpen alakulnak:
Először a virtuális hálózatokról fogok mesélni. Először is, mert ezt szeretném, másodszor meg azért, mert enélkül az infrastruktúra hálózati dizájnja nem lesz túl érthető.
Aztán a hálózati dizájnról: topológia, routing, politikák.
Összeállítunk egy laboratóriumi standot.
Elmélkedünk és talán gyakorolni fogunk az eszköz inicializálásában a hálózatban.
A következőkben pedig minden komponensről intim részletekben fogok beszélni.

Igen, nem ígérem, hogy elegánsan fogom befejezni ezt a ciklust egy kész megoldással. 🙂

Hasznos linkek

• Mielőtt belemerülnénk a sorozatba, érdemes elolvasni Natalia Samoylenko könyvét Python a hálózati mérnökök számára. Talán érdemes lenne elvégezni kurzus.
• Hasznos lenne továbbá elolvasni RFC a Facebook adatközponti gyárak dizájnjáról, Lapukhova Péter szerzőjétől.
• Arról, hogy az Overlay SDN hogyan működik, a dokumentáció ad képet az architektúráról Tungsten Fabric (korábban Open Contrail).

Köszönöm

Roman Gorge. Köszönet a megjegyzésekért és a javításokért.
Artem Chernbay. Köszönet a KDPV-ért.

Forrás: habr.com