A hálózati automatizálással kapcsolatos, általam megosztott kapcsolódó cikkeket a „NetDevOps from Scratch” katalógusban találja.
Az elmúlt években a globális számítási felhő terület folyamatos fejlődésével és az üzletág folyamatos növekedésével a hálózati technológia is tovább fejlődött, és megjelent az SDN technológia. A továbbítás és a vezérlés Openflow-n alapuló szétválasztásának eredeti alapgondolatából az emberek tovább terjeszkednek Az SDN kiterjesztésében az emberek jelenleg konszenzusra juthatnak, hogy az Openflow már nem szükséges feltétel (de a továbbítás és a vezérlés szétválasztása továbbra is alapvető feltétel), és a hálózati programozhatóság lassan az SDN architektúra mérésének egyik fontos kritériumává vált.
A hagyományos hálózati berendezések programozható műveletei általában CLI és SNMP protokollokon alapulnak. Legyen szó szkriptekről vagy hálózatkezelő szoftverekről, mindegyiket ezen az alapon fejlesztették ki, hogy elérjék azt a széles körű hálózati programozhatóságot, amelyről ma beszélni fogunk. képességeket, ezáltal megvalósítva számos forgatókönyv automatizálását. Egyes eszközök támogatják bizonyos webes felületek konfigurálását és a teljes konfiguráció lecserélését az xml-n keresztül. Ezek nagyon ritkák, és ebben a cikkben nem ismertetjük részletesen.
CLI
A CLI (Command-line Interface) a parancssoron keresztül valósítja meg az ember-számítógép interakciót. Ez elengedhetetlen készség a hálózati dolgozók számára. Az emberek minden nap megnyitják az SSH vagy Telnet szoftvert az eszközön, majd beillesztenek egy konfigurációt, elmentik és életbe lépnek. Egy nap az emberek belefáradtak az efféle ismétlésbe, és egy program segítségével automatikusan generálták a konfigurációs szkripteket, kötegelt bejelentkeztek az eszközre, és kiadták a hatályba lépő konfigurációkat, megvalósítva az automatizálást. Ez egy hálózati programozható módszer. Beszéljünk az előnyökről, amelyek nagyon összhangban vannak az emberek gondolkodásával, elképzeléseivel és a meglévő technikai rendszerekkel. De végső soron ez a megközelítés előnyben részesíti az embereket a hálózati eszközökkel szemben. Ennek a következő hátrányai vannak:
-A parancskészletekben óriási különbségek vannak a gyártók között. Nemcsak a gyártók, hanem egyazon modell különböző szoftververziói is nagyon eltérőek lehetnek.
- A fejlesztőknek ismerniük kell a parancskészletet és annak használatát. A konfiguráció szintjén vannak biztonsági kockázatok. Például egy kézmozdulattal az a port, amelyet ki akartam nyitni, a port bezárására vált…
-Nincsenek kötelező követelmények az átviteli protokollokra (SSH és Telnet), és vannak gyártásbiztonsági kockázatok.
- A konfigurációk elemzése és generálása rendkívül bonyolult. Sok esetben a felírt szabályos szabályok csak végtelenül közel lehetnek az „igazsághoz”, de nem a teljes „igazsághoz”.
- Nincs tranzakció, és előfordulhat, hogy egy konfiguráció részben életbe lép, részben pedig nem.
-Nincs automatizált ellenőrzési mechanizmus, és teljes mértékben az emberektől függ. Például szeretném tesztelni, hogy a generált szkript helyes-e. Van rá mód, de nagyon nehéz és gyakran nehéz könnyen megvalósítani.
- Fogalmam sincs az adatmodellezésről
A CLI mindig az ember-számítógép interakció egyik módja. Programokon keresztül bizonyos programozhatósági lehetőségeket tud adni a hálózatnak, de végül is ez nem egy eleve hálózaton programozható módszer. A felhőalapú számítástechnika és az SDN jelenlegi hulláma alatt nem alkalmas nagyarányú automatizált hálózati telepítésre, programozhatósága korlátozott. A kívülállók nehezen értik meg a fejlődés nehézségét.
SNMP
Az SNMP (SNMP, Simple Network Management Protocol), ez a protokoll támogatja a hálózatfelügyeleti rendszereket annak ellenőrzésére, hogy a hálózathoz csatlakoztatott eszközökben van-e olyan helyzet, amely a menedzsment figyelmét felkelti. Hálózatkezelési szabványok készletéből áll, beleértve az alkalmazási réteg protokollt, az adatbázissémát és az adatobjektumok készletét.
A Wikipédia egy része esetében kiemeljük a hálózatkezelést, a megfigyelést és az adatobjektumokat. A hálózat menedzselésére szolgál, konfigurálható és gyűjthető, főként monitorozásra szolgál. Adatmodellezéssel rendelkezik a hálózati berendezések egyes moduljainak, jellemzőinek és állapotadatainak felépítéséhez. Főleg hálózatfelügyeleti rendszerekhez (többnyire monitorozáshoz) használják. Akkor beszéljünk a hiányosságairól:
- Rossz olvashatóság. Előnyben részesíti a "gépet" az ember-gépben. Használat közben nem olvasható, és a modellezési adatok sem olvashatók. Az ASN.1 szuperkészletét használja.
- A biztonság korlátozott. Három verzió létezik: v1, v2c és v3, és a biztonság folyamatosan javul. A leggyakoribb azonban a v2c, amely korlátozott biztonsággal rendelkezik. A v3-as verzió tervezésénél fogva nagyon biztonságos, de nem univerzális. . .
-Nincs biztonsági mentési, helyreállítási vagy visszaállítási mechanizmus. A parancssor biztonsági mentésére a show run és más módszerek is rendelkezésre állnak, de az snmp. . .
- Nagyon kevesen írnak. Olvass sokat, írj keveset, többnyire figyelésre használjuk.
- A gyűjthető adatelemek korlátozottak, a teljes eszköz konfigurációja nem szerezhető be. Sokszor azt tapasztaljuk, hogy a cli-vel tudjuk gyűjteni, de az snmp-vel nem.
- Van egy szűk keresztmetszet a teljesítményben. Az összegyűjtött adatok felső határa 64 KB, és a gyűjtés részletessége túl nagy. Nagy és összetett hálózatokban ez percekig vagy tovább is tarthat. Ez is rávilágít a fontos pontra. A részletességre vonatkozó követelményeink is nagyon szigorúak. Sokszor reméljük, hogy néhány másodpercenként összegyűjtjük a kikötői forgalmat. A nagy hálózatokban szerintem a hagyományos hálózatkezelő szoftver... Hogy még egy mondatot kibővítsek, a jelenlegi módszer a telemetria (például a gRPC), amely mikroszekundumos szintet tud elérni, és néhányhoz szoftver és hardver kombinációja szükséges. Még nem népszerű, de a jövőben biztosan trend lesz. Hogy ez mikor jön el a jövőben…
- Megszületése óta az SNMP-t nagymértékben használták a hálózatfigyelés területén a megfigyeléshez szükséges adatok beszerzésére. A konfigurációs képességek hiánya és összetettsége miatt kevéssé használják a hálózati konfigurációban. Csak olvasható hálózati programozható.
Netconf protokoll és YANG modell
A hálózatok következő generációjával szemben milyen hálózatkezelési protokollokra van szükségünk a hálózati programozhatóság jobb megvalósításához és az automatizálás szintjének javításához?
Az IETF 2002-ben az RFC3535-ben a következő ötleteket javasolta (valójában 33 db van belőlük. Az online információk és a szerző ismeretei alapján a következő ötleteket írtam):
1. Van egy programozható interfész a hálózati konfigurációhoz
2. Ugyanaz a konfiguráció több gyártó és modell is használható
3. Egységesíteni kell egy jó olvashatósággal rendelkező modellező nyelvet
4. Végezze el a hibaellenőrzési és helyreállítási funkciókat
5. Tranzakciós
Ha van ötleted, csak valósítsd meg. 2006-ban az IETF javasolta a Netconf protokollt, amely megoldotta az RFC3535 által felvetett problémákat. A kezdeti Netconf csak az alapvető keretrendszert és a protokoll működését írta elő, és olyan megoldásokat határozott meg, amelyek figyelembe vették az RFC3535 néhány problémáját. Nem írt elő egységes modellezési nyelvet. Ezért egyes korai gyártók berendezései csak a Netconf néhány alapvető műveletét támogatták, és nem használtak egységes alsó réteget. Adatmodellező nyelv.
Az RFC6020 2010-ben jelent meg, és a YANG Model modellezési nyelvet és a NETCONF-fel való kombinálásának módszerét javasolta. Az egyik definíció egy adatmodellező nyelv, amely egyesíti a mögöttes erőforrás-logikát a gyártók között, a másik definíció pedig egy egységes parancskészlet az egyes gyártók konfigurációs adatokon és állapotadatokon végzett műveleteihez. A YANG modell által létrehozott adatpéldányok a Netconf protokollba vannak csomagolva. Átvitel, a kettőt egymással kombinálva új, univerzális hálózati programozható interfész-készletet építenek fel az új korszakhoz a YANG modell alapján, és a Netconf protokoll vezérli.
2016 után a Netconf protokoll szorosan integrálódott a YANG modellbe, és népszerűvé vált. Eddig, ha megvizsgálunk néhány SDN architektúra szoftver szempontot, többé-kevésbé hallottuk ezt a két kifejezést.
A YANG és a Netconf, az egyik statikus, a másik dinamikus, akárcsak a jin és jang. Ők ketten levezették a következő korszak hálózati programozható világát. (Ha megnézzük a YANG raktárt a githubon, azt is látni fogjuk, hogy az ikonja a Tai Chi, és a neve és a "Yang" közötti kapcsolat némileg elárulja az eredeti tervező tervezési elképzeléseit).
Ezután röviden beszélünk a YANG modellről és a Netconf protokollról. Először beszéljünk a YANG adatmodellező nyelvről, hogy lássuk, hogyan írja le a hálózati világ digitális ikertestvérét.
YANG modell
Az RFC6020 dokumentumban a nyitó fejezet egyértelműen kimondja: YANG, A Data Modeling Language for the Network Configuration Protocol. Ez a Yet Another Next Generation (Yang) adatmodellező nyelv rövidítése. Ez egy modellező nyelv, amelyet a hálózati fogalmak leírására használnak.
Támogatja a listák, szótárak és még összetettebb adatstruktúrák meghatározását, támogatja a megszorításokat, a felsorolásokat, a hivatkozások importálását, a verziókezelést és a névtereket. A helyhiány miatt rövid magyarázatot adunk. Részletes információkért tekintse meg:
Nagyon egyszerűen le tudja írni ezt a hálózati eszközt egy strukturált nyelven. Például a port meghatározásához:
Professzionális kezelőként és karbantartóként, egy kis hálózati alapismeretekkel és egy kis programozási alapismeretekkel viszonylag világosan megértheti a port definícióját. Ez egy listastruktúra, és több is lehet. Egyik attribútuma az interface-name (egyben kulcs). , egyedi, nem megismételhető), valamint a speed attribútum és a duplex attribútum, mindkettő karakterlánc.
A YANG-modell a hálózati eszközök számos jellemzőjét írja le, beleértve a konfigurációs állapotot és a működési állapotot.
Ily módon a YANG-modell strukturált nyelven írja le az online világot. Akit érdekel, elolvashatja a fenti internetes blogbejegyzést, aminek nagyon alapos leírása van.
Nagyon jól konvertálható XML adatokká, és a Netconf protokollba csomagolható az átvitelhez (később elmagyarázzuk):
Ugyanakkor a gyártók közötti különbségek kiegyenlítése érdekében a Google vezette Openconfig szabványosította az adatmodellt. A hivatalos weboldalon a „Vendor-semleges, felhasználók által tervezett, modellvezérelt hálózatkezelés” szlogent látjuk, amelyet a felhasználók és a többplatformos terveztek. Szállítók által elterjedt, modellvezérelt hálózati programozás (először fordítsuk le így). Leegyszerűsítve azt jelenti, hogy a különböző gyártók közötti modellezést egyformán kell elvégezni, hogy bizonyos adatok konfigurálásakor ne kelljen egyenként átnézni az egyes gyártók privát yang modelljeit. De az internetnek mindig vannak privát protokolljai, és a különböző gyártók mindig új és jobb privát protokollokat készítenek a "jobb felhasználói élmény" és "jobb üzleti stratégia" érdekében (ez valóban a hálózatgyártók eredendő bűne). A képen néhány gyakrabban használt openconfig yang modell implementáció látható.
A képből ítélve szerintem elég sok van belőlük, és az általánosan használt konfigurációk is viszonylag komplettek. De a gyakorlatban ez attól függ, hogy a gyártó támogatja-e ezeket a yang modelleket is. Egy bizonyos tárgyhoz tartozó egyes magasabb verziójú eszközök alapvetően támogatottak. A hazaiakat még nem néztem meg közelebbről.
A hálózatok nem lehetnek teljesen egyformák. Egy hálózatüzemeltetéssel, karbantartással foglalkozó mérnök számára áldás, ha ugyanazt a célt érheti el!
Az openconfig a következő helyen található: https://github.com/openconfig/public/tree/master/release/models
Különféle hivatalos weboldalakon találhat privát yang modelleket.
Netconf protokoll
Miután beszéltünk a yang modellről, beszéljünk a Netconf protokollról. A yang modell a hálózati világ digitális leírását, a Netconf pedig az adatok beszerzését (get) és beállítását (config) határozza meg.
A Netconf a yang modell által leírt világ adatait tömöríti a hálózati világ kezelésének megvalósításához.
A Yang-adatokat xml-be foglalják, majd a Netconf protokollon keresztül kezelik. Ez egy nagyszerű többrétegű ötlettel rendelkező protokoll, amely hierarchikusan írja le a protokoll egyes részleteit. Nézzük a fenti képet.
- Átvitel: A Netconf az SSH protokollon keresztül történik, kapcsolat-orientált, és biztonsági garanciákkal rendelkezik.
-Üzenet: Távoli hívás kezdeményezése a hálózati eszközhöz az RPC-n keresztül, a hálózatkezelő RPC-kérést ad ki, és a hálózati eszköz folytatja az rpc-replyt.
-Működés: Ez a Netconf lelke. Támogatja a get (konfigurációs és futó adatok), get-config (konfigurációs adatok lekérése, és egy eszköznek több konfigurációs adata lehet, egy fut, egy indítás, több jelölt), edit -config (hálózati eszköz paramétereinek konfigurálása, támogatja a kiegészítést, törlés és módosítás), delete-config, copy-config (a konfiguráció másolása a rendeltetési helyre, a cél lehet ftp, fájl vagy futó konfiguráció stb.), lock\unlock (a konfiguráció zárolása, hogy megelőzze a konfigurációs ütközéseket vagy hibákat, amelyeket többfolyamatos műveletek) és így tovább.
-Adat: az adatok xml-be csomagolt yang adatok. A fent leírt porthoz hasonlóan a strukturált adatok könnyen programozhatók. A konfigurálandó, törölni vagy megszerezni kívánt adatok leírására szolgál.
Ez a Netconf négy rétege. A vezérlővég és a hálózati eszköz a Netconf-on keresztül kommunikál, a hagyományos ssh protokollon keresztül, a Netconf alrendszer használatával, és az alapértelmezett port a 830. Az alábbiak szerint:
Ez az ábra a nyers ssh-t használó interakciót mutatja be, de valójában ezt a folyamatot programozással valósítjuk meg. A programozási megvalósítási módot később mutatom be Önnek.
A Netconf konfigurálja a hálózati eszközöket. Az interakciós folyamat nagyjából a következő:
Ez a kép olyan alacsony, hogy azt is láthatod, hogy én rajzoltam… A Netconf-ot a fentiek szerint értelmezem. Azt hiszem, sok kép van az interneten, ami nem megfelelő, és a szerverügynök számos viselkedése nem megfelelő. Ezt intuitív módon érzem, amikor bejelentkezek az eszközre, és természetesen ez egy az egyben megfelel a hivatalos dokumentációnak.
Nézzünk néhány Netconf példát:
Szia, építs linket.
Számos kulcsszót láttunk, Netconf verzió, támogatott YANG modell, munkamenet azonosító. Ugyanakkor a hello jelzi, hogy milyen névtérben dolgozunk. Ebben az esetben ez a Netconf megfelelő verziója.
Szerezze be a konfigurációt
A get-cofig egyik paramétere a forrás, ahonnan a konfigurációs adatok származnak (futás, indítás vagy egyéb). Egy másik paraméter a filter, vagyis az, hogy melyik yang modell által leírt adatmodellből melyik adat származik. Ez megfelel a hálózati eszköz által eredetileg küldött képességnek. Siker esetén a megfelelő konfigurációs adatok visszaküldésre kerülnek.
Szerezzen be konfigurációs vagy futó adatokat
Hasonló a get-config-hoz, de amit kapunk, az a futó konfiguráció (személyes megértés) vagy a futó adatok. A szűrő megadható.
Konfiguráció másolása
A másolási műveletnek két paramétere van, a forrás és a cél. A sikeres válasz az ok címkével érkezik.
Szerkessze a konfigurációt
A konfiguráció szerkesztésekor adja meg a szerkeszteni kívánt adatelemet, a képesség névterét és a hozzá tartozó címkét. Például ez a dhcp konfigurálása, amelyet a yang modell ír le: http://tail-f.com/ns/example/dhcp.
Finoman zárja be a munkamenetet
Ez a fajta üzenet az ssh-ban oda-vissza továbbítva. Csak kivonjuk az üzenet egy részét, hogy mindenki megértse.
Ezután egyszerűen adjon hozzá néhány tartalmat referenciaként.
- A Netconf munkameneten alapul, és minden sikernek megvan a munkamenet-azonosítója.
-Minden kérésnek van üzenetazonosítója, mindaddig, amíg az fokozatosan nagyobb lesz
- Az adatkonfiguráció zárolható, kizárólagos és zárral működtethető.
- A Netconf tranzakciós, és a műveletek mindegyike megvalósul, vagy nincs. Ugyanakkor a hivatalos weboldal dokumentációja szerint ez a tranzakció N hálózati eszköz konfigurálására vonatkozik, vagyis az egyszeri konfigurációs polimorfizmus támogathatja a tranzakciókat. De még nem csináltam…
- A Netconf támogatja az előfizetést. Az eszköz teljesítményét tekintve a nagyságrend körülbelül 5 munkamenet. Előfizethetek egy bizonyos adatelemre, és a készülék értesít, ha változik.
- Képesség, én ezt így értem. A hálózati eszköz a Netconf és a YANG Model verzióját, a vezérlőterminál pedig a Netconf verzióját küldi el. Csak akkor folytathatjuk, ha a Netconf verzió megegyezik a kettővel. Ez az én intuitív érzésem. Bármilyen tanácsot szívesen fogadunk.
- Az olyan műveletek, mint például a get edit, meghatározzák a módosítandó adatokat, amelyek szűrővel szűrhetők.
A -copy-config támogatja a konfigurációk teljes készletének másolását valahonnan valahova. A valahol lehet egy FTP-fájl, amely fut, indul és lehetséges konfigurációk az eszközön.
A Netconf a konfiguráció ellenőrzését is támogatja a validate művelettel.
Ez a cikk továbbra is a tudomány népszerűsítését reméli, és nem megyek bele a részletekbe. Elolvashatja az RFC vonatkozó protokolljait, ami valójában nem túl hosszú.
A gyakorlatban egyes nyílt forráskódú szoftverek, például a python ncclient alapján könnyen beállíthatjuk a hálózati eszközöket automatikusan, és elérhetjük a hálózati programozhatóságot. Ez a Netconf és a YANG Model küldetése.
A hálózati személyzet elolvassa a jól formázott YANG-modell definíciókat, és a megfelelő programozási nyelveket használja a hálózati eszközökön a Netconf által meghatározott műveletek alapján programozható műveletek végrehajtásához. Ily módon a hálózati programozhatósághoz vezető út megkovácsolódik.
Bővítsük ki és képzeljük el, hogy a YANG Modell meghatározta a hálózati eszköz adatszerkezetét. Netconf-on keresztül tudjuk működtetni. Működtethető más protokollokon keresztül is?
A válasz igen. Valójában sok más protokoll is származott a Netconf-ból, például a RESTConf. Az alábbiak szerint
A YANG Model (nyilvános és natív) határozza meg az adatstruktúrát, amely fölött új hálózatkezelési protokollok, Netconf, RESTCon, gRPC stb. eszközöket az SSH alapú Netconf-on keresztül, vagy a hálózati eszközöket HTTP2 alapú gRPC-n keresztül működtethetjük.0. Mindegyik a YANG-n alapul, jó adatszerkezettel. Modellezze, írja be a megfelelő adatokat, és csomagolja be xml-be vagy json-ba a hálózati eszközök programozásához. Ez a hálózati programozhatóság jövője. Pontosabban: Model Driven Program, modell alapú hálózati programozhatóság. A hálózati mérnökök a parancskészlet helyett fokozatosan az eszköz paramétereire összpontosítanak, és a megfelelő adatmodell beolvasásával konfigurálják a hálózati paramétereket.
A végén leírom, hogy miért kell megnyitnom ezt a nyilvános fiókot. Iskola koromban számítástechnikát és technikát tanultam. Munkahelyre lépésem után hálózatüzemeltetési és karbantartási munkákkal foglalkoztam. Ha belegondolok, az lehet az oka, hogy csapatokra osztottak, mert a Hálózati Technológiai Kutatóintézet végzős hallgatója voltam (vicces kézikönyv). Kezdettől fogva hálózati üzemeltetéssel foglalkoztam. Az üzemeltetés és karbantartás későbbi szakaszában a munka egyszerűsítésére és a hatékonyság növelésére szolgáló eszközöket alkalmaztak a CLI alapján. Később az eszközöket fokozatosan BS-strukturált webalkalmazásokká fejlesztették. Folyamatosan ki voltak téve az új technológiáknak, és folyamatosan új funkciókat gazdagítottak.
Szerencsére utolérték a nyílt forráskódú technológia és az SDN fejlődését, és fokozatosan áttértem a NetDevOps munkára, és programozási készségeimmel javítottam a csapat működési és karbantartási képességeit. Ezt a kódsort is élveztem megírni. Az írás előrehaladtával fokozatosan kiderül, hogy a NetDevOps-nak olyan készségnek kell lennie, amellyel a jövőben minden hálózati mérnöknek rendelkeznie kell (mindenki önt olajat a tűzre), hogy magas szintű tervezést és gyors megvalósítást tudjon elérni. Visszatekintve néhány internetes információra, őszintén szólva Kínában nagyon kevés van, és a hazai légkör sem túl erős. Sok hazai szoftver a régi CLI-re és snmp-re épül, és továbbra is mindenki szöveges és SSH-eszközöket használ a munkához. Szóval remélem, hogy énmegtaníthatok másokat horgászni, megoszthatom tapasztalataimat (gödrök) és készségeimet több hálózatüzemeltető és karbantartó mérnökkel, és mindent megteszek. Xiao Chu elmondta, hogy meg lehet tanulni valamit a munkaterhelés csökkentése érdekében, és a távoli jövőre koncentrálva a hazai hálózatok üzemeltetése és karbantartása valóban az automatizálás irányába fejlődhet.
A jövőben felveszek néhány videót és írok néhány cikket. Nagyon megerőltető érzés dokumentumot írni. Szeretettel várunk feliratkozni, gyűjteni, like-olni és nézni.
függelék: Netconf közös műveletek
DWDM OTN megoldás tervezése és költségajánlat, kérem, kapcsolódjon velem, Taylor Huang
