Súvisiace články zdieľané mnou o automatizácii siete nájdete v katalógu „NetDevOps od nuly“
V posledných rokoch s neustálym rozvojom globálnej oblasti cloud computingu a neustálym rastom podnikania sa ďalej rozvíjali aj sieťové technológie a objavila sa technológia SDN. Od pôvodnej základnej myšlienky oddelenia preposielania a riadenia na základe Openflow sa ľudia naďalej rozširujú Pri rozširovaní SDN môžu ľudia v súčasnosti dosiahnuť konsenzus, že Openflow už nie je nevyhnutnou podmienkou (ale oddelenie preposielania a kontroly je stále základnou podmienkou) a programovateľnosť siete sa pomaly stala jedným z dôležitých kritérií merania architektúry SDN.
Programovateľné operácie tradičných sieťových zariadení sú vo všeobecnosti založené na protokoloch CLI a SNMP. Či už ide o skripty alebo softvér na správu siete, všetky sú vyvinuté na tomto základe, aby sa dosiahol široký rozsah programovateľnosti siete, o ktorom dnes budeme hovoriť. schopnosti, čím sa realizuje automatizácia mnohých scenárov. Niektoré zariadenia podporujú konfiguráciu niektorých webových rozhraní a nahradenie celkovej konfigurácie cez xml. Sú veľmi zriedkavé a v tomto článku nebudú podrobne popísané.
CLI
CLI (Command-line Interface) realizuje interakciu medzi človekom a počítačom cez príkazový riadok. Je to nevyhnutná zručnosť pre sieťových pracovníkov. Ľudia každý deň otvoria softvér SSH alebo Telnet v zariadení, potom prilepia konfiguráciu, uložia ju a prejavia sa. Jedného dňa boli ľudia unavení z tohto druhu opakovania a použili program na automatické generovanie konfiguračných skriptov, prihlásenie sa do zariadenia v dávkach a vydanie konfigurácií, aby sa prejavili, čím sa realizovala automatizácia. Ide o sieťovo programovateľnú metódu. Povedzme si o výhodách, ktoré sú veľmi v súlade s myslením ľudí, predstavami a existujúcimi technickými systémami. V konečnom dôsledku však tento prístup uprednostňuje ľudí pred sieťovými zariadeniami. Má nasledujúce nevýhody:
-Medzi výrobcami sú obrovské rozdiely v súboroch príkazov. Nielen výrobcovia, ale aj rôzne verzie softvéru toho istého modelu môžu mať veľmi odlišné rozdiely.
-Vývojári musia byť oboznámení so sadou príkazov a ako ju používať. Existujú bezpečnostné riziká na úrovni konfigurácie. Napríklad pohybom ruky sa port, ktorý som chcel otvoriť, zmenil na zatvorenie portu...
-Neexistujú žiadne povinné požiadavky na prenosové protokoly (SSH a Telnet) a existujú bezpečnostné riziká výroby.
-Proces analýzy a generovania konfigurácií je mimoriadne komplikovaný. V mnohých prípadoch môžu byť napísané pravidelné pravidlá len nekonečne blízko „pravde“, ale nie celej „pravde“.
-Neexistuje žiadna transakcia a konfigurácia môže čiastočne nadobudnúť účinnosť a časť nie.
-Neexistuje žiadny automatizovaný kontrolný mechanizmus a je úplne závislý od ľudí. Napríklad chcem otestovať, či je vygenerovaný skript správny. Existuje spôsob, ale je veľmi ťažký a často ťažko realizovateľný.
-Nemám predstavu o dátovom modelovaní
CLI je vždy spôsob interakcie človeka s počítačom. Môže dať sieti určité možnosti programovania prostredníctvom programov, ale koniec koncov to nie je metóda, ktorá je vo svojej podstate sieťovo programovateľná. Pri súčasnej vlne cloud computingu a SDN nie je vhodný na rozsiahle automatizované nasadenie v sieti a jeho programovateľnosť je obmedzená. Pre cudzincov je ťažké pochopiť náročnosť vývoja.
SNMP
SNMP (SNMP, Simple Network Management Protocol), tento protokol môže podporovať systémy správy siete na monitorovanie toho, či sa na zariadeniach pripojených k sieti nevyskytuje nejaká situácia, ktorá spôsobuje pozornosť manažmentu. Pozostáva zo sady štandardov správy siete, vrátane protokolu aplikačnej vrstvy, schémy databázy a sady dátových objektov.
Pri časti obsahu vo Wikipédii vyzdvihujeme správu siete, monitorovanie a dátové objekty. Používa sa na správu siete, dá sa konfigurovať a zhromažďovať a používa sa hlavne na monitorovanie. Má dátové modelovanie na štruktúrovanie niektorých modulov, charakteristík a stavových údajov sieťových zariadení. Používa sa hlavne pre systémy riadenia siete (väčšinou monitoring). Potom si povedzme o jeho nedostatkoch:
-Zlá čitateľnosť. Uprednostňuje "stroj" v človeku-stroji. Pri použití nie je čitateľný a údaje o modelovaní tiež nie sú čitateľné. Používa nadmnožinu ASN.1.
-Bezpečnosť je obmedzená. Existujú tri verzie: v1, v2c a v3 a zabezpečenie sa postupne zlepšuje. Najbežnejší je však v2c, ktorý má obmedzenú bezpečnosť. Verzia v3 je dizajnovo veľmi bezpečná, no nie je univerzálna. . .
-Neexistuje žiadny mechanizmus zálohovania, obnovy alebo vrátenia. Máme tiež show run a ďalšie metódy na zálohovanie príkazového riadku, ale snmp. . .
- Veľmi málo píše. Veľa čítať, málo písať, väčšinou sa používa na monitorovanie.
-Položky údajov, ktoré je možné zhromaždiť, sú obmedzené a nie je možné získať konfiguráciu celého zariadenia. Mnohokrát zistíme, že môžeme použiť cli na jeho zber, ale nemôžeme použiť snmp na jeho zber.
-Existuje prekážka výkonu. Horná hranica zhromaždených údajov je 64 kB a podrobnosť zhromažďovania je príliš veľká. Vo veľkých a zložitých sieťach to môže trvať minúty alebo dlhšie. To tiež zdôrazňuje dôležitý bod. Naše požiadavky na zrnitosť sú tiež veľmi prísne. Mnohokrát dúfame, že každých pár sekúnd zhromažďujeme návštevnosť portov. Vo veľkých sieťach si myslím, že tradičný softvér na správu siete je... Aby som rozšíril ešte jednu vetu, súčasnou metódou je telemetria (napríklad gRPC), ktorá môže dosiahnuť úroveň mikrosekúnd a niektoré vyžadujú kombináciu softvéru a hardvéru. Zatiaľ to nie je populárne, ale v budúcnosti to musí byť trend. Čo sa týka toho, kedy to v budúcnosti príde...
-Od svojho zrodu sa SNMP vo veľkej miere používa v oblasti monitorovania siete na získavanie údajov na monitorovanie. Nedostatok a zložitosť konfiguračných možností viedli k ich malému využívaniu v konfigurácii siete. Sieťové programovanie len na čítanie.
Protokol Netconf a model YANG
Aké protokoly na správu siete potrebujeme, aby sme mohli lepšie realizovať programovateľnosť siete a zlepšiť úroveň automatizácie, keď čelíme ďalšej generácii sietí?
IETF navrhla v RFC3535 v roku 2002 nasledujúce nápady (v skutočnosti ich je 33. Na základe online informácií a poznatkov autora som napísal tieto myšlienky):
1. K dispozícii je programovateľné rozhranie na konfiguráciu siete
2. Rovnakú konfiguráciu možno použiť u všetkých výrobcov a modelov
3. Potreba zjednotiť modelovací jazyk s dobrou čitateľnosťou
4. Dokončite funkcie kontroly chýb a obnovy
5. Transakčné
Ak máte nápad, jednoducho ho zrealizujte. V roku 2006 IETF navrhla protokol Netconf, ktorý vyriešil problémy vyvolané RFC3535. Počiatočný Netconf stanovil iba základný rámec a operácie protokolu a definoval riešenia, ktoré zohľadnili niektoré problémy RFC3535. Nestanovil jednotný modelovací jazyk. Preto zariadenia niektorých prvých výrobcov podporovali iba niektoré základné operácie Netconfu a nepoužívali jednotnú spodnú vrstvu. Jazyk dátového modelovania.
RFC6020 bol vydaný v roku 2010 a ponúka modelovací jazyk YANG Model a metódu jeho kombinácie s NETCONF. Jedna definícia je jazyk na modelovanie údajov, ktorý zjednocuje základnú logiku zdrojov medzi výrobcami, a druhá definícia je jednotná sada príkazov pre operácie každého výrobcu s konfiguračnými údajmi a stavovými údajmi. Inštancie údajov vytvorené modelom YANG sú zabalené do protokolu Netconf. Prenos, tieto dva sa navzájom kombinujú, aby vytvorili novú sadu univerzálnych sieťových programovateľných rozhraní pre novú éru založenú na modeli YANG a riadená protokolom Netconf.
Po roku 2016 bol protokol Netconf úzko integrovaný s modelom YANG a stal sa populárnym. Zatiaľ, keď sa pozrieme na niektoré aspekty softvéru architektúry SDN, tieto dva pojmy sme viac-menej počuli.
YANG a Netconf, jeden je statický a druhý dynamický, rovnako ako jin a jang. Tieto dva odvodili sieťový programovateľný svet ďalšej éry. (Keď sa pozrieme na sklad YANG na githube, zistíme aj to, že jeho ikonou je Tai Chi a spojenie medzi jeho názvom a „Yang“ trochu prezrádza pôvodné dizajnérske nápady na dizajn).
Ďalej si stručne povieme o modeli YANG a protokole Netconf. Poďme sa najprv porozprávať o jazyku YANG na modelovanie údajov, aby sme videli, ako popisuje digitálne dvojča tohto sieťového sveta.
Model YANG
V dokumente RFC6020 je v úvodnej kapitole jasne uvedené, YANG, Data Modeling Language for the Network Configuration Protocol. Je to skratka z Yet Another Next Generation (Yang) Data Modeling Language. Je to modelovací jazyk používaný na opis sieťových konceptov.
Podporuje definíciu zoznamov, slovníkov a ešte zložitejších dátových štruktúr, podporuje obmedzenia, enumerácie, import odkazov, správu verzií a menné priestory. Z priestorových dôvodov poskytneme krátke vysvetlenie. Podrobné informácie nájdete na:
Dokáže popísať toto sieťové zariadenie veľmi jednoducho v štruktúrovanom jazyku. Napríklad pre definíciu portu:
Ako profesionálny personál prevádzky a údržby, s trochou základov siete a trochou základov programovania, chápete definíciu portu pomerne jasne. Je to štruktúra zoznamu a môže ich byť viacero. Jedným z jeho atribútov je názov rozhrania (tiež kľúč). , jedinečný, neopakovateľný), ako aj atribút rýchlosť a atribút duplex, pričom oba sú reťazce.
Model YANG popisuje mnohé atribúty sieťového zariadenia, vrátane stavu konfigurácie a prevádzkového stavu.
Model YANG týmto spôsobom opisuje online svet pomocou štruktúrovaného jazyka. Ak máte záujem, môžete si prečítať vyššie uvedený internetový blogový príspevok, ktorý má veľmi podrobný popis.
Dá sa veľmi dobre previesť na XML dáta a na prenos zabaliť do protokolu Netconf (vysvetlíme si to neskôr):
Zároveň, aby sa vyrovnali rozdiely medzi dodávateľmi, Openconfig pod vedením Google štandardizoval dátový model. Z oficiálnej stránky vidíme slogan „Vendor-neutral, model-driven network management design by users“, ktorý je navrhnutý používateľmi a medzi platformami. Bežné sieťové programovanie riadené predajcom (preložme si to najskôr takto). Zjednodušene povedané, je to urobiť modelovanie medzi rôznymi výrobcami rovnaké, aby ste pri konfigurácii určitých údajov nemuseli prezerať súkromný jangový model každého výrobcu jeden po druhom. Ale internet má vždy súkromné protokoly a rôzni výrobcovia budú vždy vytvárať nové a lepšie súkromné protokoly pre „lepšiu používateľskú skúsenosť“ a „lepšiu obchodnú stratégiu“ (toto je naozaj prvotný hriech výrobcov sietí). Obrázok ukazuje niektoré z bežnejšie používaných implementácií modelu openconfig yang.
Súdiac podľa obrázku si myslím, že ich je pomerne veľa a bežne používané konfigurácie sú relatívne kompletné. V praxi ale záleží na tom, či výrobca podporuje aj tieto jangové modely. Niektoré vyššie verzie zariadení určitého subjektu sú v zásade podporované. Na tie domáce som sa zatiaľ bližšie nepozrel.
Siete nemôžu byť úplne rovnaké. Pre inžiniera, ktorý sa zaoberá vývojom prevádzky a údržby siete, je požehnaním dosiahnuť rovnaký cieľ!
openconfig nájdete na https://github.com/openconfig/public/tree/master/release/models
Súkromné jangové modely nájdete na rôznych oficiálnych stránkach.
Protokol Netconf
Po rozhovore o jangovom modeli si povedzme niečo o protokole Netconf. Model yang definuje digitálny popis sveta siete a Netconf definuje získavanie (get) a úpravu (config) údajov.
Netconf zapuzdruje údaje sveta opísané modelom yang, aby sa realizovalo riadenie sveta siete.
Údaje Yang sú zapuzdrené v xml a následne spravované prostredníctvom protokolu Netconf. Ide o protokol so skvelou vrstvenou myšlienkou, ktorý popisuje niektoré detaily protokolu hierarchickým spôsobom. Pozrime sa na obrázok vyššie.
-Prenos: Netconf sa prenáša cez protokol SSH, je orientovaný na pripojenie a má bezpečnostné záruky.
-Správa: Uskutočnite vzdialený hovor na sieťové zariadenie cez RPC, správca siete vydá požiadavku RPC a sieťové zariadenie obnoví RPC-reply.
-Prevádzka: Toto je duša Netconfu. Podporuje get (konfigurácia a prevádzkové údaje), get-config (získanie konfiguračných údajov a zariadenie môže mať viacero konfiguračných údajov, jedno spustenie, jedno spustenie, viacero kandidátov), edit -config (konfigurácia parametrov sieťového zariadenia, podporuje pridávanie, vymazanie a úprava), delete-config, copy-config (skopírujte konfiguráciu do cieľa, cieľom môže byť ftp, súbor alebo spustená konfigurácia atď.), lock\unlock (uzamknutie konfigurácie, aby sa predišlo konfliktom v konfigurácii alebo zlyhaniam spôsobeným viacprocesové operácie) atď.
-Údaje: údaje sú jangové údaje zabalené v xml. Podobne ako port, ktorý sme opísali vyššie, aj štruktúrované dáta sa dajú jednoducho naprogramovať. Používa sa na popis údajov, ktoré sa majú nakonfigurovať, odstrániť alebo získať.
Toto sú štyri vrstvy Netconfu. Riadiaci koniec a sieťové zariadenie komunikujú cez Netconf, cez tradičný protokol ssh, s použitím podsystému Netconf a predvolený port je 830. Ako je uvedené nižšie:
Tento obrázok ukazuje interakciu pomocou surového ssh, ale v skutočnosti tento proces implementujeme prostredníctvom programovania. Spôsob implementácie programovania vám predvediem neskôr.
Netconf konfiguruje sieťové zariadenia. Interakčný proces je približne nasledovný:
Tento obrázok je taký nízky, že môžete vidieť, že som ho nakreslil ja... Moje chápanie Netconfu je také, ako je uvedené vyššie. Myslím si, že na internete je veľa obrázkov, ktoré nie sú správne, a mnohé správanie serverového agenta nie je správne. To je to, čo intuitívne cítim, keď sa prihlásim do zariadenia, a samozrejme to korešponduje s oficiálnou dokumentáciou.
Môžeme sa pozrieť na niekoľko príkladov Netconf:
Dobrý deň, vytvorte odkaz.
Videli sme niekoľko kľúčových slov, verziu Netconf, podporovaný model YANG, ID relácie. Hello zároveň označuje, v akom mennom priestore pracujeme. V tomto prípade ide o zodpovedajúcu verziu Netconfu.
Získajte konfiguráciu
Jedným parametrom get-cofig je zdroj, čo je miesto, kde sa získavajú konfiguračné údaje (spustenie, spustenie alebo iné). Ďalším parametrom je filter, teda ktoré údaje sa získavajú z dátového modelu opísaného ktorým jangovým modelom. To zodpovedá schopnosti pôvodne odoslanej sieťovým zariadením. V prípade úspechu sa vrátia príslušné konfiguračné údaje.
Získajte údaje o konfigurácii alebo prevádzke
Podobne ako get-config, ale získa sa spustenie konfigurácie (osobné pochopenie) alebo spustenie údajov. Filter je možné špecifikovať.
Kopírovať konfiguráciu
Operácia kopírovania má dva parametre, zdroj a cieľ. Úspešná odpoveď je so značkou ok.
Upraviť konfiguráciu
Pri úprave konfigurácie zadajte údajovú položku, ktorá sa má upraviť, priestor názvov schopnosti a zodpovedajúce označenie. Ide napríklad o konfiguráciu dhcp, ktorú popisuje model jang http://tail-f.com/ns/example/dhcp.
Zatvorte reláciu elegantne
Práve tento druh správ sa prenáša tam a späť v ssh. Vybrali sme len časť správy, aby sme uľahčili pochopenie všetkým.
Potom jednoducho pridajte nejaký obsah pre referenciu.
-Netconf je založený na relácii a každý úspech bude mať ID relácie.
-Každá žiadosť má ID správy, pokiaľ sa postupne zväčšuje
-Konfigurácia údajov môže byť uzamknutá, exkluzívna a ovládaná zámkom.
-Netconf je transakčný a operácie sú buď všetky implementované, alebo žiadne. Zároveň podľa dokumentácie oficiálnej webovej stránky je táto transakcia určená pre konfiguráciu sieťových zariadení N, to znamená, že jednorazový konfiguračný polymorfizmus môže podporovať transakciu. Ale ešte som to neurobil…
-Netconf podporuje predplatné. Čo sa týka výkonu zariadenia, rádovo je to asi 5 relácií. Môžem si predplatiť určitú dátovú položku a zariadenie ma upozorní, keď sa zmení.
-Schopnosť, takto to chápem. Sieťové zariadenie odošle verziu Netconf a YANG Model a riadiaci terminál pošle verziu Netconf. Až keď sa verzia Netconf zhoduje s týmito dvoma, môžeme pokračovať. Toto je môj intuitívny pocit. Každá rada je vítaná.
-Operácie, ako je získať úpravu, určia údaje, ktoré sa majú zmeniť, ktoré možno filtrovať pomocou filtra.
-copy-config podporuje kopírovanie kompletnej sady konfigurácií odniekiaľ niekam. Niekde môže byť súbor FTP, spustenie, spustenie a konfigurácie kandidátov na zariadení.
-Netconf tiež podporuje overenie konfigurácie pomocou operácie validate.
Tento článok stále dúfa v popularizáciu vedy a nebudem zachádzať do podrobností. Môžete si prečítať príslušné protokoly RFC, ktoré v skutočnosti nie sú príliš dlhé.
V praxi, na základe nejakého softvéru s otvoreným zdrojovým kódom, ako je napríklad ncclient pythonu, môžeme ľahko automaticky nakonfigurovať sieťové zariadenia a dosiahnuť programovateľnosť siete. To je poslaním Netconf a YANG Model.
Pracovníci siete čítajú dobre naformátované definície modelu YANG a používajú príslušné programovacie jazyky na vykonávanie programovateľných operácií na sieťových zariadeniach na základe operácií definovaných Netconf. Týmto spôsobom sa vytvára cesta k programovateľnosti siete.
Rozvinieme a predstavme si, že model YANG definoval dátovú štruktúru sieťového zariadenia. Môžeme ho prevádzkovať cez Netconf. Dá sa to prevádzkovať aj cez iné protokoly?
Odpoveď je áno. V skutočnosti bolo z Netconf odvodených mnoho ďalších protokolov, ako napríklad RESTConf. Ako je ukázané nižšie,
Model YANG (verejný a natívny) definuje dátovú štruktúru, nad ktorou sú nové protokoly pre správu siete, Netconf, RESTCon, gRPC atď. Týmto spôsobom môžeme prevádzkovať sieťové zariadenia cez RESTConf na báze HTTP RESTful API, môžeme prevádzkovať aj sieť zariadenia cez Netconf na báze SSH, alebo môžeme prevádzkovať sieťové zariadenia cez gRPC na HTTP2.0. Všetky sú založené na YANG s dobrou dátovou štruktúrou. Modelujte, zapíšte zodpovedajúce údaje, zapuzdrejte ich do xml alebo json na programovanie sieťových zariadení. Toto je budúcnosť sieťovej programovateľnosti. Presnejšie povedané, je to Model Driven Program, sieťová programovateľnosť založená na modeli. Sieťoví inžinieri sa postupne zameriavajú na parametre zariadenia namiesto sady príkazov a konfigurujú parametre siete čítaním príslušného dátového modelu.
Na konci píšem, prečo by som si mal otvárať tento verejný účet. V škole som študoval informatiku a techniku. Po nástupe na pracovisko som sa venoval prevádzke a údržbe siete. Keď o tom premýšľam, dôvod, prečo som bol rozdelený do tímov, môže byť ten, že som bol postgraduálnym študentom na Výskumnom ústave sieťových technológií (vtipný manuál). Od začiatku som sa venoval sieťovým operáciám. V neskoršej fáze prevádzky a údržby boli použité nástroje na zjednodušenie práce a zvýšenie efektivity založené na CLI. Neskôr sa nástroje postupne vyvinuli do BS-štruktúrovaných webových aplikácií. Neustále boli vystavené novým technológiám a naďalej obohacovali nové funkcie.
Našťastie zastihli vývoj open source technológie a SDN a postupne som prešiel na prácu NetDevOps a využil svoje programátorské schopnosti na zlepšenie prevádzky a možností údržby tímu. Tiež som si užil písanie tohto riadku kódu. Ako písanie postupuje, postupne sa zisťuje, že NetDevOps by mala byť zručnosť, ktorú by mal mať v budúcnosti každý sieťový inžinier (každý prilieva olej do ohňa), aby mohol dosiahnuť plánovanie na vysokej úrovni aj rýchlu implementáciu. Keď sa spätne pozriem na niektoré informácie na internete, úprimne povedané, v Číne je toho veľmi málo a domáca atmosféra nie je príliš silná. Mnoho domácich softvérov je založených na starom CLI a snmp a každý stále používa na prácu textové nástroje a nástroje SSH. Tak dúfam, že jamôžem naučiť ostatných, ako loviť ryby, podeliť sa o svoje skúsenosti (jamy) a zručnosti s viacerými technikmi prevádzky a údržby sietí, a robím to najlepšie. Xiao Chu povedal, že sa môžete niečo naučiť, aby ste znížili svoju pracovnú záťaž, a ak sa zameriate na vzdialenú budúcnosť, prevádzka a údržba domácej siete sa môže skutočne vyvinúť smerom k automatizácii.
V budúcnosti natočím nejaké videá a napíšem nejaké články. Je to naozaj namáhavé písať dokument. Môžete sa prihlásiť na odber, zbierať, klikať na lajk a pozerať.
príloha: Bežné operácie Netconfu
Návrh riešenia DWDM OTN a cenová ponuka, prosím, spojte sa so mnou, Taylor Huang
