SDSM sa skončilo, no nekontrolovateľná túžba písať zostáva.

Náš brat mnoho rokov trpel rutinnou prácou, prekračoval si prsty pred spáchaním a mal nedostatok spánku kvôli nočným návratom.
Ale temné časy sa končia.

Týmto článkom začnem sériu o tom, ako na to ma je vidieť automatizáciu.
Na ceste pochopíme fázy automatizácie, ukladanie premenných, formalizáciu dizajnu, RestAPI, NETCONF, YANG, YDK a urobíme veľa programovania.
Mňa znamená, že a) to nie je objektívna pravda, b) nie je to bezpodmienečne najlepší prístup, c) môj názor sa aj počas pohybu od prvého k poslednému článku môže zmeniť – úprimne povedané, od štádia návrhu až po publikáciu, všetko som prepisoval úplne dvakrát.

Obsah

1. ciele
   1. Sieť je ako jeden organizmus
   2. Testovanie konfigurácie
   3. Verziovanie
   4. Monitoring a self-healing služieb

2. Fondy
   1. Systém zásob
   2. Systém správy IP priestoru
   3. Systém popisu sieťových služieb
   4. Mechanizmus inicializácie zariadenia
   5. Konfiguračný model nezávislý od dodávateľa
   6. Rozhranie ovládača špecifické pre dodávateľa
   7. Mechanizmus na doručenie konfigurácie do zariadenia
   8. CI / CD
   9. Mechanizmus zálohovania a vyhľadávania odchýlok
   10. Monitorovací systém

3. Záver

Pokúsim sa vykonať ADSM vo formáte mierne odlišnom od SDSM. Naďalej budú pribúdať veľké, podrobné, číslované články a medzi nimi budem zverejňovať drobné poznámky z každodennej skúsenosti. Pokúsim sa tu bojovať s perfekcionizmom a nelízať každého z nich.

Aké zábavné je, že druhýkrát musíte prejsť tou istou cestou.

Najprv som musel písať články o sieťach sám kvôli tomu, že neboli na RuNet.

Teraz sa mi nepodarilo nájsť komplexný dokument, ktorý by systematizoval prístupy k automatizácii a analyzoval vyššie uvedené technológie na jednoduchých praktických príkladoch.

Možno sa mýlim, preto uveďte odkazy na užitočné zdroje. To však nič nezmení na mojom odhodlaní písať, pretože hlavným cieľom je sám sa niečo naučiť a uľahčenie života iným je príjemným bonusom, ktorý pohladí gén pre zdieľanie skúseností.

Pokúsime sa zobrať stredne veľké dátové centrum LAN DC a vypracovať celú schému automatizácie.
Niektoré veci budem s vami robiť takmer prvýkrát.

Nebudem originálny v tu popísaných nápadoch a nástrojoch. Dmitrij Figol má výbornú kanál so streammi na túto tému.
Články sa s nimi budú v mnohých aspektoch prekrývať.

LAN DC má 4 DC, asi 250 prepínačov, pol tucta smerovačov a pár firewallov.
Nie Facebook, ale dosť na to, aby ste sa hlboko zamysleli nad automatizáciou.
Existuje však názor, že ak máte viac ako 1 zariadenie, automatizácia je už potrebná.
V skutočnosti je ťažké si predstaviť, že niekto môže teraz žiť bez aspoň balíka scenárov pre kolená.
Aj keď som počul, že existujú kancelárie, kde sú IP adresy vedené v Exceli a každé z tisícok sieťových zariadení je nakonfigurované manuálne a má svoju jedinečnú konfiguráciu. To sa, samozrejme, dá vydávať za moderné umenie, ale pocity inžiniera budú určite urazené.

ciele

Teraz si stanovíme tie najabstraktnejšie ciele:

• Sieť je ako jeden organizmus
• Testovanie konfigurácie
• Verzia stavu siete
• Monitoring a self-healing služieb

Ďalej v tomto článku sa pozrieme na to, aké prostriedky použijeme a v nasledujúcom sa podrobne pozrieme na ciele a prostriedky.

Sieť je ako jeden organizmus

Definujúca fráza série, aj keď sa na prvý pohľad nemusí zdať taká významná: budeme konfigurovať sieť, nie jednotlivé zariadenia.
V posledných rokoch sme zaznamenali posun v dôraze na zaobchádzanie so sieťou ako s jednou entitou, a preto Softvér definovaný sieť, Siete riadené zámerom и Autonómne siete.
Veď čo potrebujú aplikácie globálne od siete: konektivitu medzi bodmi A a B (dobre, niekedy +B-Z) a izoláciu od ostatných aplikácií a používateľov.

A taká je naša úloha v tejto sérii vybudovať systémso zachovaním aktuálnej konfigurácie celú sieť, ktorý je už rozložený do skutočnej konfigurácie na každom zariadení v súlade s jeho úlohou a umiestnením.
Systém zo správy siete vyplýva, že aby sme vykonali zmeny, kontaktujeme ho a ono zase vypočíta požadovaný stav pre každé zariadenie a nakonfiguruje ho.
Týmto spôsobom minimalizujeme manuálny prístup do CLI takmer na nulu – akékoľvek zmeny v nastaveniach zariadenia alebo návrhu siete musia byť formalizované a zdokumentované – a až potom nasadené na potrebné sieťové prvky.

To znamená, že ak by sme sa napríklad rozhodli, že odteraz by mali rackové prepínače v Kazani oznamovať dve siete namiesto jednej, my

1. Najprv zdokumentujeme zmeny v systémoch
2. Generovanie cieľovej konfigurácie všetkých sieťových zariadení
3. Spustíme program na aktualizáciu konfigurácie siete, ktorý vypočíta, čo je potrebné na každom uzle odstrániť, čo pridať a uzly uviesť do požadovaného stavu.

Zmeny zároveň robíme ručne len v prvom kroku.

Testovanie konfigurácie

Je známeže 80% problémov sa vyskytuje pri zmenách konfigurácie - nepriamym dôkazom toho je, že počas novoročných sviatkov je zvyčajne všetko pokojné.
Osobne som bol svedkom desiatok globálnych výpadkov v dôsledku ľudskej chyby: nesprávny príkaz, konfigurácia bola vykonaná v nesprávnej vetve, komunita zabudla, MPLS bolo globálne zničené na smerovači, bolo nakonfigurovaných päť kusov hardvéru, ale chyba nebola všimol si šiesty, boli spáchané staré zmeny vykonané inou osobou . Existuje veľa scenárov.

Automatizácia nám umožní robiť menej chýb, no vo väčšom rozsahu. Takto môžete murovať nielen jedno zariadenie, ale celú sieť naraz.

Naši starí otcovia od nepamäti bystrým okom kontrolovali správnosť vykonaných zmien, guľôčky z ocele a funkčnosť siete po ich vyvalení.
Tí dedovia, ktorých práca viedla k prestojom a katastrofálnym stratám, zanechali menej potomkov a mali by časom vymrieť, no evolúcia je pomalý proces, a preto nie každý stále testuje zmeny najskôr v laboratóriu.
V čele pokroku sú však tí, ktorí zautomatizovali proces testovania konfigurácie a jej ďalšej aplikácie do siete. Inými slovami, požičal som si procedúru CI/CD (Priebežná integrácia, nepretržité nasadzovanie) od vývojárov.
V jednej z častí sa pozrieme na to, ako to implementovať pomocou systému na správu verzií, pravdepodobne Github.

Keď si zvyknete na myšlienku sieťového CI/CD, metóda kontroly konfigurácie jej aplikáciou na produkčnú sieť vám bude cez noc pripadať ako ranostredoveká ignorancia. Niečo ako udierať kladivom do hlavice.

Organické pokračovanie myšlienok o systém Správa siete a CI/CD sa stanú úplnou verziou konfigurácie.

Verziovanie

Budeme predpokladať, že pri akýchkoľvek zmenách, aj tých najmenších, aj na jednom nepostrehnuteľnom zariadení, sa celá sieť presúva z jedného stavu do druhého.
A vždy nevykonávame príkaz na zariadení, ale meníme stav siete.
Nazvime teda tieto stavy verziami?

Povedzme, že aktuálna verzia je 1.0.0.
Zmenila sa IP adresa rozhrania Loopback na jednom z ToR? Toto je vedľajšia verzia a bude mať číslo 1.0.1.
Revidovali sme zásady pre import trás do BGP – trochu vážnejšie – už vo verzii 1.1.0
Rozhodli sme sa zbaviť IGP a prejsť iba na BGP – toto je už radikálna zmena dizajnu – 2.0.0.

Zároveň môžu mať rôzne DC rôzne verzie – sieť sa vyvíja, inštaluje sa nové vybavenie, niekde sa pridávajú nové úrovne spinov, v iných nie atď.

o sémantické verzovanie si povieme v samostatnom článku.

Opakujem - akákoľvek zmena (okrem príkazov na ladenie) je aktualizáciou verzie. Správcovia musia byť upozornení na akékoľvek odchýlky od aktuálnej verzie.

To isté platí pre vrátenie zmien – nejde o zrušenie posledných príkazov, nejde o vrátenie pomocou operačného systému zariadenia – ide o uvedenie celej siete na novú (starú) verziu.

Monitoring a self-healing služieb

Táto samozrejmá úloha dosiahla v moderných sieťach novú úroveň.
Veľkí poskytovatelia služieb často používajú prístup, že neúspešnú službu treba veľmi rýchlo opraviť a vytvoriť novú, namiesto toho, aby zisťovali, čo sa stalo.
„Veľmi“ znamená, že musíte byť zo všetkých strán veľkoryso pokrytí monitorovaním, ktoré v priebehu niekoľkých sekúnd odhalí najmenšie odchýlky od normy.
A tu už bežné metriky, ako je načítanie rozhrania alebo dostupnosť uzlov, nestačia. Nestačí ani ich ručné sledovanie zo strany strážcu.
Na veľa vecí by tam malo byť Samoliečenie — monitorovacie svetlá sa rozsvietili na červeno a my sme si išli aplikovali plantain sami tam, kde to bolelo.

A tu tiež sledujeme nielen jednotlivé zariadenia, ale aj zdravie celej siete, a to ako whitebox, čo je pomerne pochopiteľné, tak aj blackbox, ktorý je komplikovanejší.

Čo budeme potrebovať na realizáciu takýchto ambicióznych plánov?

• Majte zoznam všetkých zariadení v sieti, ich umiestnenie, roly, modely, verzie softvéru.
  kazan-leaf-1.lmu.net, Kazan, list, Juniper QFX 5120, R18.3.
• Mať systém na popis sieťových služieb.
  IGP, BGP, L2/3VPN, politika, ACL, NTP, SSH.
• Byť schopný inicializovať zariadenie.
  Názov hostiteľa, Mgmt IP, Mgmt Route, Používatelia, RSA-Keys, LLDP, NETCONF
• Nakonfigurujte zariadenie a preveďte konfiguráciu na požadovanú (vrátane starej) verzie.
• Testovacia konfigurácia
• Pravidelne kontrolujte stav všetkých zariadení na odchýlky od súčasných a nahláste, komu by to malo byť.
  Cez noc niekto potichu pridal pravidlo do ACL.
• Monitorujte výkon.

Fondy

Znie to dosť komplikovane na to, aby ste začali projekt rozkladať na komponenty.

A bude ich desať:

1. Systém zásob
2. Systém správy IP priestoru
3. Systém popisu sieťových služieb
4. Mechanizmus inicializácie zariadenia
5. Konfiguračný model nezávislý od dodávateľa
6. Rozhranie ovládača špecifické pre dodávateľa
7. Mechanizmus na doručenie konfigurácie do zariadenia
8. CI / CD
9. Mechanizmus zálohovania a vyhľadávania odchýlok
10. Monitorovací systém

Toto je mimochodom príklad toho, ako sa zmenil pohľad na ciele cyklu – v drafte boli 4 komponenty.

Na obrázku som znázornil všetky komponenty a samotné zariadenie.
Pretínajúce sa komponenty sa navzájom ovplyvňujú.
Čím väčší je blok, tým viac pozornosti je potrebné venovať tomuto komponentu.

Komponent 1: Systém zásob

Samozrejme, chceme vedieť, aké zariadenie sa kde nachádza, na čo je pripojené.
Inventarizačný systém je neoddeliteľnou súčasťou každého podniku.
Podnik má najčastejšie samostatný inventárny systém pre sieťové zariadenia, ktorý rieši konkrétnejšie problémy.
V rámci tejto série článkov to nazveme DCIM – Data Center Infrastructure Management. Hoci samotný pojem DCIM, prísne vzaté, zahŕňa oveľa viac.

Pre naše účely v ňom uložíme nasledujúce informácie o zariadení:

• Inventárne číslo
• Názov/Popis
• Model (Huawei CE12800, Juniper QFX5120 atď.)
• Charakteristické parametre (dosky, rozhrania atď.)
• Rola (Leaf, Spine, Border Router atď.)
• Miesto (región, mesto, dátové centrum, stojan, jednotka)
• Prepojenie medzi zariadeniami
• Topológia siete

Je úplne jasné, že toto všetko chceme vedieť aj my sami.
Pomôže to však na účely automatizácie?
Iste.
Napríklad vieme, že v danom dátovom centre na prepínačoch Leaf, ak ide o Huawei, by sa mali ACL na filtrovanie určitej prevádzky aplikovať na VLAN, a ak ide o Juniper, tak na jednotku 0 fyzického rozhrania.
Alebo potrebujete zaviesť nový server Syslog na všetky hranice v regióne.

V ňom budeme ukladať virtuálne sieťové zariadenia, napríklad virtuálne smerovače alebo koreňové reflektory. Môžeme pridať DNS servery, NTP, Syslog a všeobecne všetko, čo sa tak či onak týka siete.

Komponent 2: Systém správy priestoru IP

Áno, a v súčasnosti existujú tímy ľudí, ktorí sledujú prefixy a IP adresy v súbore Excel. Ale moderný prístup je stále databáza, s front-endom na nginx/apache, API a rozsiahlymi funkciami na zaznamenávanie IP adries a sietí rozdelených do VRF.
IPAM - Správa IP adries.

Pre naše účely v ňom budeme uchovávať nasledujúce informácie:

• VLAN
• VRF
• Siete/Podsiete
• IP adresy
• Väzba adries na zariadenia, siete na miesta a čísla VLAN

Opäť je jasné, že sa chceme uistiť, že keď pridelíme novú IP adresu pre ToR loopback, nezakopneme o to, že už bola niekomu pridelená. Alebo že sme použili rovnakú predponu dvakrát na rôznych koncoch siete.
Ale ako to pomôže pri automatizácii?
Ľahko.
V systéme požadujeme prefix s rolou Loopbacks, ktorý obsahuje IP adresy dostupné na pridelenie - ak sa nájde, pridelíme adresu, ak nie, požadujeme vytvorenie nového prefixu.
Alebo pri vytváraní konfigurácie zariadenia vieme z rovnakého systému zistiť, v ktorom VRF má byť rozhranie umiestnené.
A pri spustení nového servera sa skript prihlási do systému, zistí, na ktorom prepínači je server, ktorý port a ktorá podsieť je priradená k rozhraniu - a z toho pridelí adresu servera.

To naznačuje túžbu spojiť DCIM a IPAM do jedného systému, aby sa neduplikovali funkcie a neslúžili dvom podobným entitám.
To je to, čo urobíme.

Komponent 3. Systém na popis sieťových služieb

Ak prvé dva systémy ukladajú premenné, ktoré je ešte potrebné nejako použiť, potom tretí popisuje pre každú rolu zariadenia, ako by sa mala nakonfigurovať.
Stojí za to rozlišovať dva rôzne typy sieťových služieb:

• Infraštruktúra
• Zákazník.

Prvé sú navrhnuté tak, aby poskytovali základnú konektivitu a ovládanie zariadenia. Patria sem VTY, SNMP, NTP, Syslog, AAA, smerovacie protokoly, CoPP atď.
Títo organizujú službu pre klienta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP atď.
Samozrejme, sú aj hraničné prípady – kam zaradiť MPLS LDP, BGP? Áno, a pre klientov je možné použiť smerovacie protokoly. Ale to nie je dôležité.

Oba typy služieb sú rozložené na primitíva konfigurácie:

• fyzické a logické rozhrania (tag/anteg, mtu)
• IP adresy a VRF (IP, IPv6, VRF)
• ACL a pravidlá spracovania prevádzky
• Protokoly (IGP, BGP, MPLS)
• Smerovacie politiky (prefixové zoznamy, komunity, ASN filtre).
• Úžitkové služby (SSH, NTP, LLDP, Syslog...)
• Atď.

Ako presne to urobíme, zatiaľ netuším. Na to sa pozrieme v samostatnom článku.

Ak trochu bližšie k životu, tak by sme to mohli opísať
Prepínač Leaf musí mať relácie BGP so všetkými pripojenými prepínačmi Spine, importovať pripojené siete do procesu a z prepínačov Spine akceptovať iba siete od určitej predpony. Obmedzte CoPP IPv6 ND na 10 pps atď.
Chrbtica zasa uskutočňujú sedenia so všetkými pripojenými zvodmi, pôsobiacimi ako koreňové reflektory a prijímajú z nich iba trasy určitej dĺžky a s určitou komunitou.

Komponent 4: Mechanizmus inicializácie zariadenia

Pod týmto názvom kombinujem mnohé z akcií, ktoré sa musia uskutočniť, aby sa zariadenie objavilo na radare a bolo k nemu vzdialený prístup.

1. Zadajte zariadenie do inventárneho systému.
2. Vyberte adresu IP správy.
3. Nastavte si k nemu základný prístup:
   Názov hostiteľa, IP adresa správy, cesta do siete pre správu, používatelia, kľúče SSH, protokoly - telnet/SSH/NETCONF

Existujú tri prístupy:

• Všetko je úplne manuálne. Zariadenie sa privezie na stojan, kde ho bežný organický človek zadá do systémov, pripojí sa ku konzole a nakonfiguruje. Môže pracovať na malých statických sieťach.
• ZTP - Zero Touch Provisioning. Hardvér prišiel, postavil sa, dostal adresu cez DHCP, prešiel na špeciálny server a nakonfiguroval sa.
• Infraštruktúra konzolových serverov, kde počiatočná konfigurácia prebieha cez konzolový port v automatickom režime.

O všetkých troch si povieme v samostatnom článku.

Komponent 5: Konfiguračný model nezávislý od dodávateľa

Doteraz boli všetky systémy nesúrodými záplatami, ktoré poskytujú premenné a deklaratívny popis toho, čo by sme chceli v sieti vidieť. Ale skôr či neskôr sa budete musieť vysporiadať so špecifikami.
V tejto fáze sa pre každé konkrétne zariadenie kombinujú primitíva, služby a premenné do modelu konfigurácie, ktorý v skutočnosti popisuje kompletnú konfiguráciu konkrétneho zariadenia, a to len spôsobom neutrálnym voči predajcovi.
Čo robí tento krok? Prečo hneď nevytvoríte konfiguráciu zariadenia, ktorú môžete jednoducho nahrať?
V skutočnosti to rieši tri problémy:

1. Neprispôsobujte sa špecifickému rozhraniu na interakciu so zariadením. Či už ide o CLI, NETCONF, RESTCONF, SNMP - model bude rovnaký.
2. Počet šablón/skriptov nedodržiavajte podľa počtu predajcov na sieti a ak sa zmení dizajn, zmeňte na viacerých miestach to isté.
3. Načítajte konfiguráciu zo zariadenia (zálohu), vložte ju do presne rovnakého modelu a priamo porovnajte cieľovú konfiguráciu s existujúcou, aby ste vypočítali deltu a pripravili konfiguračnú záplatu, ktorá zmení len tie časti, ktoré sú nevyhnutné alebo identifikuje odchýlky.

V dôsledku tejto fázy získame konfiguráciu nezávislú od dodávateľa.

Komponent 6. Rozhranie ovládača špecifické pre dodávateľa

Nemali by ste si lichotiť nádejami, že jedného dňa bude možné nakonfigurovať ciska úplne rovnakým spôsobom ako Juniper, jednoducho tak, že im pošlete presne tie isté hovory. Napriek rastúcej popularite whiteboxov a objaveniu sa podpory pre NETCONF, RESTCONF, OpenConfig sa špecifický obsah, ktorý tieto protokoly dodávajú, líši od dodávateľa k predajcovi, a to je jeden z ich konkurenčných rozdielov, ktorých sa len tak ľahko nevzdajú.
To je zhruba to isté, ako OpenContrail a OpenStack, ktoré majú RestAPI ako rozhranie NorthBound, očakávajú úplne iné volania.

Takže v piatom kroku musí model nezávislý od dodávateľa nadobudnúť podobu, v akej pôjde do hardvéru.
A tu sú všetky prostriedky dobré (nie): CLI, NETCONF, RESTCONF, SNMP jednoducho.

Preto budeme potrebovať ovládač, ktorý prenesie výsledok predchádzajúceho kroku do požadovaného formátu konkrétneho dodávateľa: sadu príkazov CLI, štruktúru XML.

Komponent 7. Mechanizmus na dodanie konfigurácie do zariadenia

Vygenerovali sme konfiguráciu, ale stále ju treba doručiť do zariadení – a samozrejme nie ručne.
Po prvé, stojíme pred otázkou, akú dopravu použijeme? A dnes už výber nie je malý:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (hoci je to odľahlé, pretože je to spôsob, ako dodať FIB, nie nastavenia)

Urobme to t. CLI je dedičstvo. SNMP... kašeľ kašeľ.
RESTCONF je zatiaľ neznáme zviera, REST API nepodporuje takmer nikto. Preto sa v sérii zameriame na NETCONF.

V skutočnosti, ako už čitateľ pochopil, v tomto bode sme sa už rozhodli pre rozhranie - výsledok predchádzajúceho kroku je už prezentovaný vo formáte rozhrania, ktoré bolo zvolené.

Za druhéa akými nástrojmi to urobíme?
Tu je tiež veľký výber:

• Vlastnoručne napísaný skript alebo platforma. Vyzbrojme sa ncclientom a asyncIO a robme všetko sami. Koľko nás stojí vytvorenie systému nasadenia od nuly?
• Ansible so svojou bohatou knižnicou sieťových modulov.
• Soľ so svojou mizernou prácou so sieťou a spojením s Napalmom.
• Vlastne Napalm, ktorý pozná pár predajcov a to je všetko, zbohom.
• Nornir je ďalšie zviera, ktoré budeme v budúcnosti pitvať.

Tu obľúbený ešte nebol vybraný - budeme hľadať.

Čo je tu ešte dôležité? Dôsledky aplikácie konfigurácie.
Úspešné alebo nie. Je stále prístup k hardvéru alebo nie?
Zdá sa, že commit tu pomôže s potvrdením a validáciou toho, čo bolo stiahnuté do zariadenia.
To v kombinácii so správnou implementáciou NETCONF výrazne zužuje rozsah vhodných zariadení - nie veľa výrobcov podporuje normálne commity. Ale to je len jeden z predpokladov RFP. Nakoniec sa nikto neobáva, že ani jeden ruský predajca nebude spĺňať podmienku rozhrania 32*100GE. Alebo má obavy?

Komponent 8. CI/CD

V tomto momente už máme pripravenú konfiguráciu pre všetky sieťové zariadenia.
Píšem „pre všetko“, pretože hovoríme o verzovaní stavu siete. A aj keď potrebujete zmeniť nastavenia iba jedného prepínača, zmeny sa vypočítajú pre celú sieť. Je zrejmé, že pre väčšinu uzlov môžu byť nulové.

Ale, ako už bolo povedané vyššie, nie sme žiadni barbari, ktorí chcú všetko prevalcovať rovno do výroby.
Vygenerovaná konfigurácia musí najskôr prejsť cez Pipeline CI/CD.

CI/CD znamená Continuous Integration, Continuous Deployment. Ide o prístup, pri ktorom tím nielen vydáva každých šesť mesiacov nové hlavné vydanie, ktoré úplne nahradí staré, ale pravidelne postupne implementuje (nasadenie) nové funkcie v malých častiach, z ktorých každá je komplexne testovaná na kompatibilitu, bezpečnosť a výkon (Integrácia).

Na to máme systém na kontrolu verzií, ktorý monitoruje zmeny konfigurácie, laboratórium, ktoré kontroluje, či je klientska služba nefunkčná, monitorovací systém, ktorý túto skutočnosť kontroluje a posledným krokom je nasadenie zmien do produkčnej siete.

S výnimkou príkazov na ladenie musia absolútne všetky zmeny v sieti prejsť cez CI/CD Pipeline – to je naša záruka pokojného života a dlhej šťastnej kariéry.

Komponent 9. Systém zálohovania a detekcie anomálií

Nie je potrebné znova hovoriť o zálohovaní.
Jednoducho ich vložíme do git podľa koruny alebo na základe zmeny konfigurácie.

Druhá časť je však zaujímavejšia - niekto by mal tieto zálohy sledovať. A v niektorých prípadoch musí tento niekto ísť a všetko otočiť tak, ako to bolo, a v iných zamňaukať, že niečo nie je v poriadku.
Napríklad, ak sa objavil nový používateľ, ktorý nie je zaregistrovaný v premenných, musíte ho odstrániť z hacku. A ak je lepšie nedotýkať sa nového pravidla brány firewall, možno niekto práve zapol ladenie, alebo možno nová služba, bungler, nebola zaregistrovaná podľa predpisov, ale ľudia sa už k nej pridali.

Napriek akýmkoľvek automatizačným systémom a tvrdej ruke manažmentu stále neunikneme malej delte v rozsahu celej siete. Na odladenie problémov aj tak nikto nepridá konfiguráciu do systémov. Navyše nemusia byť zahrnuté ani v konfiguračnom modeli.

Napríklad pravidlo brány firewall na počítanie počtu paketov na konkrétnu adresu IP na lokalizáciu problému je úplne obyčajná dočasná konfigurácia.

Komponent 10. Monitorovací systém

Najprv som sa nechcel venovať téme monitoringu – je to stále objemná, kontroverzná a zložitá téma. Postupom času sa však ukázalo, že ide o neoddeliteľnú súčasť automatizácie. A je nemožné to obísť, dokonca aj bez praxe.

Evolving Thought je organickou súčasťou procesu CI/CD. Po zavedení konfigurácie do siete musíme byť schopní zistiť, či je s ňou teraz všetko v poriadku.
A to nehovoríme len a nie tak o plánoch používania rozhrania alebo dostupnosti uzlov, ale o jemnejších veciach - prítomnosť potrebných trás, atribútov na nich, počtu relácií BGP, susedov OSPF, výkonu End-to-End nadradených služieb.
Prestali sa pridávať syslogy na externý server alebo sa pokazil agent SFlow, alebo sa začali zväčšovať poklesy vo frontoch, alebo sa prerušila konektivita medzi niektorými pármi prefixov?

Budeme sa nad tým zamýšľať v samostatnom článku.

Záver

Ako základ som zvolil jeden z moderných návrhov siete dátových centier – L3 Clos Fabric s BGP ako smerovacím protokolom.
Tentokrát sieť postavíme na Juniper, pretože rozhranie JunOs je teraz vanlove.

Skomplikujme si život používaním iba nástrojov Open Source a siete viacerých predajcov – takže okrem Juniper vyberiem ešte jedného šťastlivca.

Plán pripravovaných publikácií je asi takýto:
Najprv budem hovoriť o virtuálnych sieťach. Po prvé preto, že chcem, a po druhé preto, že bez toho nebude návrh siete infraštruktúry veľmi jasný.
Potom o samotnom návrhu siete: topológia, smerovanie, politiky.
Zostavíme laboratórny stojan.
Zamyslime sa a možno si precvičíme inicializáciu zariadenia v sieti.
A potom o každom komponente v intímnom detaile.

A áno, nesľubujem, že tento cyklus s gráciou ukončím hotovým riešením. 🙂

Užitočné odkazy

• Predtým, ako sa ponoríte do série, stojí za to prečítať si knihu Natasha Samoilenko Python pre sieťových inžinierov. A možno prejsť kurz.
• Bude tiež užitočné čítať RFC o dizajne tovární na dátové centrá od Facebooku od Petra Lapukhova.
• Dokumentácia architektúry vám poskytne predstavu o tom, ako funguje Overlay SDN. Volfrámová tkanina (predtým Open Contrail).

Ďakujem

Rímska roklina. Pre komentáre a úpravy.
Arťom Černobaj. Pre KDPV.

Zdroj: hab.com