Související články sdílené mnou o automatizaci sítě naleznete v katalogu „NetDevOps od nuly“
V posledních letech, s neustálým rozvojem globálního cloud computingu a neustálým růstem podnikání, se dále rozvíjely také síťové technologie a objevila se technologie SDN. Od původní základní myšlenky oddělení předávání a řízení založeného na Openflow se lidé nadále rozšiřují V rozšíření SDN mohou lidé v současné době dosáhnout konsensu, že Openflow již není nezbytnou podmínkou (ale oddělení předávání a kontroly je stále základní podmínkou) a programovatelnost sítě se pomalu stala jedním z důležitých kritérií pro měření architektury SDN.
Programovatelné operace tradičních síťových zařízení jsou obecně založeny na protokolech CLI a SNMP. Ať už jde o skripty nebo software pro správu sítě, všechny jsou vyvíjeny na tomto základě, aby bylo dosaženo široké škály programovatelnosti sítě, o které dnes budeme hovořit. schopnosti, a tím realizovat automatizaci mnoha scénářů. Některá zařízení podporují konfiguraci některých webových rozhraní a náhradu celkové konfigurace pomocí xml. Jsou velmi vzácné a v tomto článku nebudou podrobně popsány.
CLI
CLI (Command-line Interface) realizuje interakci člověka s počítačem prostřednictvím příkazového řádku. Je to nezbytná dovednost pro síťové pracovníky. Lidé každý den otevřou software SSH nebo Telnet na zařízení, poté vloží konfiguraci, uloží ji a projeví se. Jednoho dne byli lidé unaveni tímto druhem opakování a použili program k automatickému generování konfiguračních skriptů, přihlašování k zařízení v dávkách a vydávání konfigurací, aby se projevily, čímž došlo k automatizaci. Jedná se o síťově programovatelnou metodu. Pojďme se bavit o výhodách, které jsou velmi v souladu s myšlením lidí, představami a stávajícími technickými systémy. Ale nakonec tento přístup upřednostňuje lidi před síťovými zařízeními. Má následující nevýhody:
-Mezi výrobci existují obrovské rozdíly v sadách příkazů. Nejen výrobci, ale i různé verze softwaru stejného modelu se mohou velmi lišit.
-Vývojáři musí být obeznámeni se sadou příkazů a s tím, jak ji používat. Existují bezpečnostní rizika na úrovni konfigurace. Například pohybem ruky se port, který jsem chtěl otevřít, změnil v uzavření portu…
-Neexistují žádné povinné požadavky na přenosové protokoly (SSH a Telnet) a existují bezpečnostní rizika výroby.
-Proces analýzy a generování konfigurací je extrémně komplikovaný. V mnoha případech mohou být napsaná pravidelná pravidla jen nekonečně blízko „pravdě“, ale ne celé „pravdě“.
-Neexistuje žádná transakce a konfigurace se může částečně projevit a část se neprojeví.
-Neexistuje žádný automatický kontrolní mechanismus a je zcela závislý na lidech. Chci například vyzkoušet, zda je vygenerovaný skript správný. Cesta existuje, ale je velmi obtížná a často obtížně proveditelná.
-Nemám představu o datovém modelování
CLI je vždy způsob interakce člověka s počítačem. Může dát síti určité možnosti programování prostřednictvím programů, ale koneckonců to není metoda, která je ze své podstaty síťově programovatelná. Při současné vlně cloud computingu a SDN není vhodný pro rozsáhlé automatizované nasazení v síti a jeho programovatelnost je omezená. Pro lidi zvenčí je obtížné pochopit obtížnost vývoje.
SNMP
SNMP (SNMP, Simple Network Management Protocol), tento protokol může podporovat systémy správy sítě pro sledování, zda zařízení připojená k síti mají nějakou situaci, která způsobuje pozornost managementu. Skládá se ze sady standardů správy sítě, včetně protokolu aplikační vrstvy, schématu databáze a sady datových objektů.
U části obsahu na Wikipedii zdůrazňujeme správu sítě, monitorování a datové objekty. Používá se ke správě sítě, lze jej konfigurovat a shromažďovat a používá se hlavně pro monitorování. Má datové modelování pro strukturování některých modulů, charakteristik a stavových dat síťových zařízení. Používá se především pro systémy správy sítě (většinou monitorování). Pak si promluvme o jeho nedostatcích:
-Špatná čitelnost. Upřednostňuje "stroj" v člověk-stroj. Při použití není čitelný a data modelování také nejsou čitelná. Používá nadmnožinu ASN.1.
-Bezpečnost je omezená. Existují tři verze: v1, v2c a v3 a zabezpečení se postupně zlepšuje. Nejběžnější je však v2c, která má omezené zabezpečení. Verze v3 je designově velmi bezpečná, ale není univerzální. . .
-Neexistuje žádný mechanismus zálohování, obnovy nebo vrácení zpět. Máme také show run a další metody pro zálohování příkazového řádku, ale snmp. . .
- Velmi málo píše. Hodně čtěte, málo pište, většinou se používá pro sledování.
-Datové položky, které lze shromažďovat, jsou omezené a nelze získat konfiguraci celého zařízení. Mnohokrát zjistíme, že můžeme použít cli k jeho sběru, ale nemůžeme použít snmp k jeho sběru.
-Existuje úzké hrdlo výkonu. Horní limit shromážděných dat je 64 kB a granularita kolekce je příliš velká. Ve velkých a složitých sítích to může trvat minuty nebo déle. To také zdůrazňuje důležitý bod. Naše požadavky na granularitu jsou také velmi přísné. Mnohokrát doufáme, že každých pár sekund budeme shromažďovat provoz portů. Ve velkých sítích si myslím, že tradiční software pro správu sítě je… Abychom rozšířili ještě jednu větu, aktuální metodou je telemetrie (jako je gRPC), která může dosáhnout úrovně mikrosekund a některé vyžadují kombinaci softwaru a hardwaru. Zatím to není populární, ale v budoucnu to musí být trend. Pokud jde o to, kdy to v budoucnu přijde…
-Od svého zrodu byl SNMP široce používán v oblasti monitorování sítě pro získávání dat pro monitorování. Nedostatek a složitost možností konfigurace vedly k jejich malému využití v konfiguraci sítě. Síťová programovatelná pouze pro čtení.
Protokol Netconf a model YANG
Jaký druh protokolů pro správu sítě potřebujeme, abychom mohli lépe realizovat programovatelnost sítě a zlepšit úroveň automatizace, tváří v tvář nové generaci sítí?
IETF navrhla v RFC3535 v roce 2002 následující myšlenky (ve skutečnosti jich je 33. Na základě online informací a znalostí autora jsem napsal následující myšlenky):
1. K dispozici je programovatelné rozhraní pro konfiguraci sítě
2. Stejnou konfiguraci lze použít u všech výrobců a modelů
3. Potřeba sjednotit modelovací jazyk s dobrou čitelností
4. Dokončete funkce kontroly chyb a obnovy
5. Transakční
Pokud máte nápad, stačí ho realizovat. V roce 2006 IETF navrhla protokol Netconf, který vyřešil problémy vyvolané RFC3535. Počáteční Netconf pouze stanovil základní rámec a operace protokolu a definoval řešení, která zohledňovala některé problémy RFC3535. Nestanovil jednotný modelovací jazyk. Zařízení některých prvních výrobců proto podporovalo pouze některé základní operace Netconfu a nepoužívalo jednotnou spodní vrstvu. Jazyk datového modelování.
RFC6020 byl vydán v roce 2010 a navrhuje modelovací jazyk YANG Model a metodu jeho kombinace s NETCONF. Jedna definice je jazyk datového modelování, který sjednocuje základní logiku prostředků mezi výrobci, a druhá definice je jednotná sada příkazů pro operace každého výrobce s konfiguračními daty a stavovými daty. Datové instance vytvořené modelem YANG jsou zabaleny do protokolu Netconf. Přenos, oba jsou vzájemně kombinovány, aby vytvořily novou sadu univerzálních síťových programovatelných rozhraní pro novou éru založenou na modelu YANG a řízená protokolem Netconf.
Po roce 2016 byl protokol Netconf úzce integrován s modelem YANG a stal se populárním. Dosud, když se podíváme na některé aspekty softwaru architektury SDN, jsme tyto dva termíny víceméně slyšeli.
YANG a Netconf, jeden je statický a druhý dynamický, stejně jako jin a jang. Ti dva odvodili síťový programovatelný svět příští éry. (Když se podíváme na sklad YANG na githubu, zjistíme také, že jeho ikonou je Tai Chi a spojení mezi jeho názvem a „Yang“ poněkud prozrazuje designové nápady původního designéra).
Dále si krátce povíme o modelu YANG a protokolu Netconf. Pojďme si nejprve promluvit o datovém modelovacím jazyce YANG, abychom viděli, jak popisuje digitální dvojče tohoto síťového světa.
Model YANG
V dokumentu RFC6020 úvodní kapitola jasně uvádí, YANG, A Data Modeling Language for the Network Configuration Protocol. Je to zkratka z Yet Another Next Generation (Yang) Data Modeling Language. Je to modelovací jazyk používaný k popisu síťových konceptů.
Podporuje definici seznamů, slovníků a ještě složitějších datových struktur, podporuje omezení, výčty, import odkazů, správu verzí a jmenné prostory. Z prostorových důvodů podáme stručný výklad. Podrobné informace naleznete na adrese:
Dokáže popsat toto síťové zařízení velmi jednoduše ve strukturovaném jazyce. Například pro definici portu:
Jako profesionální personál provozu a údržby, s trochou základů sítě a trochou základů programování, rozumíte definici portu poměrně jasně. Je to struktura seznamu a může jich být více. Jedním z jeho atributů je interface-name (také klíč). , jedinečný, neopakovatelný), stejně jako atribut speed a atribut duplex, což jsou oba řetězce.
Model YANG popisuje mnoho atributů síťového zařízení, včetně stavu konfigurace a provozního stavu.
Tímto způsobem model YANG popisuje online svět pomocí strukturovaného jazyka. Pokud vás to zajímá, můžete si přečíst výše uvedený příspěvek na internetovém blogu, který má velmi obsáhlý popis.
Dá se velmi dobře převést do XML dat a zabalit do protokolu Netconf pro přenos (vysvětlíme si to později):
Zároveň, aby se vyrovnaly rozdíly mezi prodejci, Openconfig v čele s Googlem standardizoval datový model. Z oficiálních stránek vidíme slogan „Vendor-neutral, model-driven network management navržený uživateli“, který je navržen uživateli a napříč platformami. Běžné, modelem řízené síťové programování dodavatelem (nejprve si to přeložme takto). Zjednodušeně řečeno jde o to, aby modelování mezi různými výrobci bylo stejné, takže když nakonfigurujete určitá data, nemusíte si prohlížet soukromý jangový model každého výrobce jeden po druhém. Internet má ale vždy soukromé protokoly a různí výrobci budou vždy vytvářet nové a lepší soukromé protokoly pro „lepší uživatelskou zkušenost“ a „lepší obchodní strategii“ (to je skutečně prvotní hřích výrobců sítí). Obrázek ukazuje některé z běžněji používaných implementací modelu openconfig yang.
Soudě podle obrázku si myslím, že jich je poměrně hodně a běžně používané konfigurace jsou relativně kompletní. V praxi ale záleží na tom, zda výrobce podporuje i tyto jangové modely. Některé vyšší verze zařízení určitého subjektu jsou v zásadě podporovány. Na ty domácí jsem se zatím blíže nepodíval.
Sítě nemohou být úplně stejné. Pro inženýra, který se zabývá vývojem provozu a údržby sítě, je požehnáním dosáhnout stejného cíle!
openconfig najdete na https://github.com/openconfig/public/tree/master/release/models
Soukromé jangové modely najdete na různých oficiálních stránkách.
protokol Netconf
Poté, co si povíme o modelu jang, pojďme mluvit o protokolu Netconf. Model yang definuje digitální popis světa sítě a Netconf definuje získávání (get) a úpravu (config) dat.
Netconf zapouzdřuje data světa popsaná modelem yang, aby realizovala správu světa sítě.
Data Yang jsou zapouzdřena v xml a poté spravována prostřednictvím protokolu Netconf. Jedná se o protokol se skvělou vrstvenou myšlenkou, popisující některé detaily protokolu hierarchickým způsobem. Podívejme se na obrázek výše.
-Přenos: Netconf se přenáší prostřednictvím protokolu SSH, je orientován na spojení a má záruky zabezpečení.
- Zpráva: Proveďte vzdálené volání na síťové zařízení prostřednictvím RPC, správce sítě vydá požadavek RPC a síťové zařízení obnoví RPC-reply.
-Provoz: Toto je duše Netconf. Podporuje get (konfigurační a provozní data), get-config (získání konfiguračních dat a zařízení může mít více konfiguračních dat, jedno spuštění, jedno spuštění, více kandidátů), edit -config (konfigurace parametrů síťového zařízení, podporuje přidání, odstranění a úprava), delete-config, copy-config (zkopírujte konfiguraci do cíle, cílem může být ftp, soubor nebo spuštěná konfigurace atd.), lock\unlock (uzamkněte konfiguraci, abyste předešli konfliktům nebo selháním konfigurace způsobeným víceprocesové operace) a tak dále.
-Data: data jsou jangová data zabalená do xml. Stejně jako port, který jsme popsali výše, lze strukturovaná data snadno programovat. Používá se k popisu dat, která mají být konfigurována nebo odstraněna nebo získána.
Toto jsou čtyři vrstvy Netconfu. Řídicí jednotka a síťové zařízení komunikují prostřednictvím Netconf, tradičním protokolem ssh, pomocí subsystému Netconf a výchozí port je 830. Jak je uvedeno níže:
Tento obrázek ukazuje interakci pomocí raw ssh, ale ve skutečnosti tento proces implementujeme pomocí programování. Způsob implementace programování vám předvedu později.
Netconf konfiguruje síťová zařízení. Proces interakce je zhruba následující:
Tento obrázek je tak nízký, že je také vidět, že jsem ho nakreslil já… Mé chápání Netconfu je stejné jako výše. Myslím, že na internetu je mnoho obrázků, které nejsou správné, a mnoho chování serverového agenta není správné. To je to, co intuitivně cítím, když se přihlásím do zařízení, a samozřejmě to koresponduje jedna ku jedné s oficiální dokumentací.
Můžeme se podívat na několik příkladů Netconf:
Dobrý den, vytvořte odkaz.
Viděli jsme několik klíčových slov, verzi Netconf, podporovaný model YANG, ID relace. Hello zároveň označuje, v jakém jmenném prostoru pracujeme. V tomto případě se jedná o odpovídající verzi Netconfu.
Získejte konfiguraci
Jedním parametrem get-cofig je source, což je místo, kde se získávají konfigurační data (spuštění, spuštění nebo jiné). Dalším parametrem je filtr, tedy jaká data se získávají z datového modelu popsaného kterým jangovým modelem. To odpovídá schopnosti původně zaslané síťovým zařízením. V případě úspěchu budou vrácena odpovídající konfigurační data.
Získejte konfigurační nebo provozní data
Podobně jako get-config, ale získá se spuštění konfigurace (osobní porozumění) nebo spuštění dat. Filtr lze specifikovat.
Zkopírujte konfiguraci
Operace kopírování má dva parametry, zdroj a cíl. Úspěšná odpověď je se značkou ok.
Upravit konfiguraci
Při úpravě konfigurace zadejte datovou položku, která se má upravit, jmenný prostor schopnosti a odpovídající štítek. Jedná se například o konfiguraci dhcp, která je popsána modelem yang http://tail-f.com/ns/example/dhcp.
Uzavřete relaci elegantně
Právě tento druh zpráv se přenáší tam a zpět v ssh. Pouze vyjmeme část zprávy, abychom všem usnadnili porozumění.
Pak jednoduše přidejte nějaký obsah pro referenci.
-Netconf je založen na relaci a každý úspěch bude mít ID relace.
-Každý požadavek má ID zprávy, pokud se postupně zvětšuje
-Konfiguraci dat lze uzamknout, exkluzivně a ovládat prostřednictvím zámku.
-Netconf je transakční a operace jsou buď implementovány všechny, nebo žádné. Zároveň podle oficiální dokumentace webu je tato transakčnost pro konfiguraci N síťových zařízení, to znamená, že jednorázový konfigurační polymorfismus může podporovat transakční schopnost. Ale ještě jsem to neudělal…
-Netconf podporuje předplatné. Pokud jde o výkon zařízení, řádově je to asi 5 relací. Mohu si předplatit určitou datovou položku a zařízení mě upozorní, když se změní.
-Schopnost, takhle tomu rozumím. Síťové zařízení odešle verzi Netconf a YANG Model a řídicí terminál odešle verzi Netconf. Teprve když verze Netconf odpovídá oběma, můžeme pokračovat. To je můj intuitivní pocit. Každá rada je vítána.
-Operace, jako je získat úpravy, určí data, která mají být změněna, která lze filtrovat pomocí filtru.
-copy-config podporuje kopírování kompletní sady konfigurací odněkud někam. Někde může být soubor FTP, spuštění, spuštění a konfigurace kandidátů na zařízení.
-Netconf také podporuje ověření konfigurace pomocí operace validate.
Tento článek stále doufá v popularizaci vědy a nebudu zabíhat do podrobností. Můžete si přečíst příslušné protokoly RFC, které ve skutečnosti nejsou příliš dlouhé.
V praxi, na základě nějakého open source softwaru, jako je ncclient pythonu, můžeme snadno automaticky konfigurovat síťová zařízení a dosáhnout programovatelnosti sítě. To je posláním Netconf a YANG Model.
Pracovníci sítě čtou dobře naformátované definice modelu YANG a používají příslušné programovací jazyky k provádění programovatelných operací na síťových zařízeních na základě operací definovaných Netconfem. Tímto způsobem je vytvořena cesta k programovatelnosti sítě.
Rozbalme si to a představme si, že model YANG definoval datovou strukturu síťového zařízení. Můžeme jej provozovat přes Netconf. Lze to provozovat i přes jiné protokoly?
Odpověď je ano. Ve skutečnosti bylo z Netconf odvozeno mnoho dalších protokolů, jako je RESTConf. Jak je ukázáno níže,
YANG Model (veřejný a nativní) definuje datovou strukturu, nad kterou jsou nové protokoly pro správu sítě, Netconf, RESTCon, gRPC atd. Tímto způsobem můžeme provozovat síťová zařízení přes RESTConf na bázi HTTP RESTful API, můžeme provozovat i síť zařízení prostřednictvím Netconf založeného na SSH, nebo můžeme provozovat síťová zařízení prostřednictvím gRPC založeného na HTTP2.0. Všechny jsou založeny na YANG s dobrou datovou strukturou. Modelujte, zapište odpovídající data, zapouzdřte je do xml nebo json pro programování síťových zařízení. To je budoucnost programovatelnosti sítě. Abych byl přesný, je to Model Driven Program, programovatelnost sítě založená na modelu. Síťoví inženýři se místo sady příkazů postupně zaměřují na parametry zařízení a konfigurují parametry sítě čtením odpovídajícího datového modelu.
Na konci píšu, proč bych si měl zakládat tento veřejný účet. Když jsem byl na škole, studoval jsem informatiku a techniku. Po nástupu na pracoviště jsem se věnoval provozu sítě a údržbě. Když o tom přemýšlím, důvod, proč jsem byl rozdělen do týmů, může být ten, že jsem byl postgraduálním studentem na Výzkumném institutu síťových technologií (vtipný manuál). Od samého začátku jsem byl zapojen do síťového provozu. V pozdější fázi provozu a údržby byly použity nástroje pro zjednodušení práce a zvýšení efektivity založené na CLI. Později byly nástroje postupně rozvíjeny do BS-strukturovaných webových aplikací. Neustále byly vystavovány novým technologiím a nadále obohacovaly nové funkce.
Naštěstí dohnali vývoj open source technologie a SDN a postupně jsem přešel do NetDevOps práce a využil své programátorské schopnosti ke zlepšení provozu a možností údržby týmu. Také mě bavilo psát tento řádek kódu. Jak psaní postupuje, postupně se zjišťuje, že NetDevOps by měla být dovednost, kterou by měl mít v budoucnu každý síťový inženýr (každý přilévá olej do ohně), aby mohl dosáhnout jak plánování na vysoké úrovni, tak rychlé implementace. Když se podívám zpět na některé informace na internetu, upřímně řečeno, v Číně je toho velmi málo a domácí atmosféra není příliš silná. Mnoho domácích softwarů je založeno na starém CLI a snmp a každý stále používá pro práci textové nástroje a nástroje SSH. Tak doufám, že jámohu naučit ostatní, jak rybařit, podělit se o své zkušenosti (jámy) a dovednosti s dalšími inženýry provozu a údržby sítěa udělám to nejlepší. Xiao Chu řekl, že se můžete naučit něco, jak snížit svou pracovní zátěž, a když se zaměříte na vzdálenou budoucnost, může se provoz a údržba domácí sítě skutečně vyvinout směrem k automatizaci.
V budoucnu natočím nějaká videa a napíšu nějaké články. Psát dokument je opravdu namáhavé. Můžete se přihlásit k odběru, sbírat, klikat na lajk a sledovat.
příloha: Běžné operace Netconfu
Návrh řešení DWDM OTN a cenová nabídka, spojte se prosím se mnou, Taylor Huang
