South-bound APIs 2
YANG alapú leírónyelvek és API-k
YANG adatstruktúra egy leíró modell arra, hogy milyen követelményeket támasztunk a API lekérdezés vagy operáció formáját tekintve, továbbá definiáljuk a konfigurációs paraméterek struktúráját. Bizonyos szempontból nézve az SNMP OID-ok is megfelelnek ennek az adatstruktúrának, így joggal merül fel a kérdés, hogy minek vesződünk mással? A koncepció egy NET/RESTCONF kapcsán az, hogy az egyszeri - speciális hálózati szaktudással nem rendelkező - programozó is tudjon kódot írni, ugyanis a programozók otthonosabban mozognak a XML, JSON vagy YALM formátumú konfigurációkban mint az SNMP OID-ban, vagy CLI-ban.
JSON formátumú konfiguráció leírást már előző postomban mutattam. Így most nem térnék ki külön a formátumra.
A JSON formátumon kívül, amik még különböző automatizációs és SDN rendszerek esetén népszerűek, az XML és YALM formátum.
Akit érdekelnek a különböző formátumok részletes leírása annak az alábbi forrásokat javasolnám:
https://yaml.org/spec/1.2/spec.html
https://www.w3schools.com/xml/xml_whatis.asp
Alapvetően, ha megértjük a YANG modell struktúráját, akkor a különböző leíró nyelvek közt könnyen el tudjuk navigálni magunkat, csak az aktuális formátumra kell odafigyelnünk.
A JSON formátumon kívül, amik még különböző automatizációs és SDN rendszerek esetén népszerűek, az XML és YALM formátum.
Akit érdekelnek a különböző formátumok részletes leírása annak az alábbi forrásokat javasolnám:
https://yaml.org/spec/1.2/spec.html
https://www.w3schools.com/xml/xml_whatis.asp
Alapvetően, ha megértjük a YANG modell struktúráját, akkor a különböző leíró nyelvek közt könnyen el tudjuk navigálni magunkat, csak az aktuális formátumra kell odafigyelnünk.
OpenFlow
OpenFlow protokoll fejlesztői alapjaiban szerették volna megváltoztatni a hálózatok működését, úgy, hogy minden ControlPlane funkcionalitást egy központi kontrollerben valósítanak meg, az infrastruktúra eszközök pedig "buta" switch-ek, melyek csak DataPlane forwarding-ot valósítanak meg. A kontroller és switch közti kontroll kommunikáció pedig az Openflow protokollon keresztül valósul meg. Az OpenFlow-t nem csak kommunikációs sztenderdnek szánták, hanem konkrét leíró nyelvet is készítettek hozzá, amelyben definiáltak működéshez szükséges utasítás készletet is.
Az OpenFlow koncepció alapvetően ötletes, néhány architekturális hibát leszámítva (kontroll és infrastruktúra közti folyamatos kommunikáció), viszont nem lett nagy üzlet a gyártók számára, továbbá a végfelhasználói oldalon is ellenérzéseket váltott ki, így az ötlet produktív környezetben már nem olyan formában valósult meg, mint ahogyan OpenFlow-t kitalálták.
NETCONF (RFC6241, RFC4741)
Gyártók az OpenFlow megjelenése előtt is dolgoztak olyan protokollon, amely a hagyományos SNMP alapú hálózati menedzsment rendszereket felválthatja. Network Configuration Protocol első verziója 2006-ban jelent meg, viszont igazi gyártói fókuszt csak 2010 tájékán kapott amikor az SDN mint üzlet robbanni látszott. NETCONF leginkább Cisco és Juniper eszközökben került bevezetésre, de a HPE Comware switchek-ben is elérhető a protokoll. SNMP-vel alapvető probléma, hogy a hálózati eszközök CPU-ból dolgozzák fel az operációt, és ugyanaz a CPU viszi a Control és egyéb management plane feladatokat is, így a rosszul beállított SNMP-vel leDoS-olhattuk a hálózatot és hálózat management-et egyaránt. További probléma, hogy az SNMP alapvetően nem biztosnágos protokoll, a kontroll és infrastruktúra között nincs titkosítva a kommunikáció.NETCONF esetében a viszont már CLI management esetén is jól bevált SSH-t alkalmazunk Transport protokollként, így hasonlóan biztonságos módon érjük el a hálózatot a kontroll alkalmazásból. További előnye a NETCONF-nak az SNMP-vel szemben, hogy bizonyos gyártók ASIC-ből támogatják a kommunikációt és operációt, így egy folyamatos lekérdezéssel nem terhelik a CPU-t.
A NETCONF struktúráját tekintve, több rétegű megoldást kínál az infrastruktúra absztrakciójára.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<some-method>
<!-- method parameters here... -->
</some-method>
</rpc>
NETCONF kapcsolatok kialakítása nem túl bonyolult, viszont sok-sok időt el lehet vele tölteni, ha formátumra nem figyelünk oda.
Egy oktatás alkalmával amit nekünk kellett tartani, igen sok időm ment el mire megtaláltam IOS-XRv-khez tartozó azt az XML formátumot, amivel Opendaylight-ba csatlakoztattam őket.
Persze egy vendor specifikus kontrollernél ez leegyszerűsödik ennyire:
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-netconf-connector</type>
<name>$devicename/name>
<address xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf"
>$ipaddress</address>
<port xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">$netconfport</port>
<username xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">$username</username>
<password xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">$password</password>
<tcp-only xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</tcp-only>
<yang-module-capabilities xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<override>true</override>
<capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
</capability>
<capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
http://cisco.com/ns/yang/ned/ios?module=ned&revision=2016-10-24
</capability>
<capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
http://tail-f.com/yang/common-monitoring?module=tailf-common&revision=2016-05-04
</capability>
<capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
http://tail-f.com/yang/common-monitoring?module=tailf-meta-extensions&revision=2013-11-07
</capability>
<capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
http://tail-f.com/yang/common-monitoring?module=tailf-cli-extensions&revision=2016-05-04
</capability>
<capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15
</capability>
</yang-module-capabilities>
<event-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-executor</type>
<name>global-event-executor</name>
</event-executor>
<binding-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
<name>binding-osgi-broker</name>
</binding-registry>
<dom-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-osgi-registry</type>
<name>dom-broker</name>
</dom-registry>
<client-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-client-dispatcher</type>
<name>global-netconf-dispatcher</name>
</client-dispatcher>
<processing-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</type>
<name>global-netconf-processing-executor</name>
</processing-executor>
<keepalive-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:scheduled-threadpool</type>
<name>global-netconf-ssh-scheduled-executor</name>
</keepalive-executor>
</module>
Szóval, ha magunk gyártunk NETCONF alalpú SDN kontrollert, akkor készüljünk fel hogy meg kell tanulnunk XML formátumot, illetve a gyártó/kontroller specifikus encoding kötöttségeit. Viszont így elég nagy szabadságunk van arra vonatkozólag, hogy az infrastruktúra rétegben mivel építkezünk.
Telemetria
" A telemetria adatokból arra következtetünk kapitány, hogy gravimetrikus sugárzás következtében az Enterprise csillaghajó..."
Science Fiction-nek hangzuk mi? Pedig a telemetria sem új igény a hálózatok terén, korábban az SNMP alapú hálózatmonitorozó rendszerek is mindenféle adatot gyűjtöttek az infrastruktúra működéséről. Ez most miben lenne más?
A koncepció nem más, a felhasznált protokollok és feldolgozó egységek változtak, illetve az adatok kiértékelése, és átvitele közel real-time történik. A NETCONF-nál már írtam, hogy a kontroll és infrastruktúra között folyamatos kapcoslat van, ami lehetővé tesz az infrastruktúra számára a folyamatos reporting-ot a kontroll réteg felé. Természetesen nem csak, vagy éppen nem a NETCONF az egyetlken ilyen protokoll aminek a segítségével adatokat küldhetünk egy telemetria collector felé. A jelenleg éppen elérhető (dcloud) labor példákban GPB és gRPC protokollt alkalmaznak az adatok továbbítására. Telemetria adatok feldolgozására nem feltétlen kell valami csillivili csártói megoldás, léteznek olyan opensource tool-ok, amik viszonlag egyszerűen megvalósítják nekünk az beérkező információból a szükséges dashboard-okat.
Pl: ELK stack, KIBANA, Grafana
RESTCONF (RFC8040, RFC8257)
Mi az alapvető különbség a RESTCONF és NETCONF között? A transport layer! Míg a NETCONF esetén speciális port-on ssh transport-ot alkalmazunk, ami speciális kliens alkalmazást és folyamatos kapcoslat fenntartást igényel, addig a RESTCONF-al http/https protokollal is elérhetjük a infrastruktúrát az alkalmazásból. Be kell látnunk, hogy ezt az API-t tényleg az egyszeri webprogramozók számára találták ki akik otthonosabban mozognak HTTP/HTTPS üzenetekben. Továbbá webalkalmazások fejlesztéséhez, sokkal több kész modul áll rendelkezésre már, mint NETCONF esetén.
Traditional Network management APIs
Sok-sok SDN és automatizációs megközelítés létezik, egységes gyártók feletti standardok ebben a témában nem igazán léteznek, így vannak olyan gyártók is (follower-ek), akik a hagyományos SNMP alapú monitorozó rendszerüket is SDN kontrollernek állítják be, és alapvetően igazuk is van, hiszen, ha azt vesszük alalpul, hogy nem csak a kontroll réteg teljes elvétele a hálózattól az SDN, hanem úgy vesszük, hogy a kontroll réteg inteligensebbé tétele valamilyen külső központi megoldással, akkor SNMP alapú monitorozó/menedzselő rendszerekkel meg is érkeztünk SDN világba. Ezek rendszerek az SNMP-t déli írányú API-nak használják, hogy az infrastruktúrát elérjék és programozzák. Fontos viszont, hogy alapvetően az ilyen SNMP alapú kontorollerek, valóban nyújtsanak egyéb észak-írányú integrációs lehetőséget, mert ha nincs REST API hozzájuk, akkor valóban csak egy zárt hálózat monitorozó/menedzselő szoftverről beszélhetünk.Mit tehetünk, ha az SNMP alapvetően nem biztonságos?
Használjunk SNMPv3-et az olyan rendszereknél ahol az API készletünk ebben merül ki. Az SNMPv3-ban már elérhető 3A, továbbá a kommunikációt is lehet titkosítani, így biztonságosabbnak tekinthető a korábbi verzióknál.
Other SDN Southbound plugins
A hálózat-virtualizáció és SDN világában semmmi sem az aminek látszik, és minden mindenre is használható. Úgy gondolom, hogy ha a tradíciónális protokollokat másképp használjuk a megszokottól.Például útvonalat akarunk módodítani OSFP, vagy BGP segítségével úgy hogy közben nem nyúlunk router konfigurációhoz, akkor az is lehet SDN megoldás, amennyiben ezt egy külső szoftver alaklamzásból tesszük meg.
Ez alapján elmondhatjuk, hogy vannak olyan SDN déli írányú plug-in-ek, amik nem közvetlenül módosítják infrastruktrúra működését, hanem közvetve a hálózati protokollok működéséből kényszerülnek ki a különböző opciókat.
BGP-LS
A BGP Link State protokoll kíválló példa arra, hogy nem csak API szolgáltathat információt a hálózatról. A BGP-LS alapvetően arra szolgál, hogy az OSFP vagy ISIS protokollokból származó link-state információt továttsítsuk BGP hálózaton. A link-state információkra a szolgáltatói, vagy kellően nagyvállalati hálózatok esetén szükség lehet, hogy traffic engineering segítségével, módosítsuk a hálózati forgalom útvonalát (pl: terhelés optamilizálás). Ahhoz, hogy a útvonalat optimalizálni lehessen, szükség van a hálózatunkban lévő link-ek állapotismeretére, egy központi helyen történő feldologozásárára, melyet a BGP-LS szolgáltathat a lenti ábra alapján.
Összefoglalva
Az eddigiek alapján elmondhatjuk, hogy az SDN megoldások, elég nagy komplexitást tudnak vinni a rendszereinkbe, cserébe a könnyebb gyorsabb egyszerűbb üzemeltethetősgért. Van egy mondás amit nagyon kedves barátomtól tanultam ez pedig az hogy:"Nincs ingyen ebéd, valakinek mindig fizetnie kell"
Amit kapunk pluszban időt az SDN megoldásoktól az üzemeltetési oldalon, azt elveszíthetjük a fejlesztések vagy a bevezetés során. A kérdés csupán annyi, hogy hosszabb távon mi a kifizetődő számunkra.
A hálózati infrastruktúrára felépülő üzleti alkalmazás igények csak nőni fognak, mint számosságban és teljesítmény igényben, tehát a hálózatokat mindig kell majd fejleszteni és üzemeltetni, kérdés az hogy, mit tudunk és mit érdemes ebből automatizálni és integrálhatóvá tenni?
Ezzel post-al el is értem a hálózat-virtualizációval kapcsolatos elméleti sorozatom végére, Továbbiakban gyakorlati példákra fogok rátérni. Kezdésnek néhány post erejéig a SDA fabric-ot mint hálózat-virtualizációs és SDN megoldás fogom boncolgatni.
Üdv,
Makesz