Hálózat-virtualizáció EPISODE IV

Network Function Virtualization 

Ezt a bejegyzést rövidítésjegyzékkel kezdem, hogy bátran spórolhassak a karakterekkel, ugyanis nem másra kell felkészülnünk mint, hogy az ETSI által szabványosított NFV architektúrát körvonalazzuk az alábbi sorokat követően. Joggal merül fel a kérdés, mi különbség hálózat-virtualizáció és a hálózati funkciók virtualizálása között… A másik kérdés az, hogy milyen igények mentén jutottunk oda, hogy kidobjuk a vasat, és szoftverből valósítsunk meg hálózati eszközökhöz szorosan kapcsolódó feladatokat?
Hogy fenti kérdéseket megválaszoljuk, és a még több kérdés tudjunk feltenni ebben a témában, ezért tekintsünk át alapoktól az NFV architektúrát.
Rövidítésjegyzék
NFV – Network Function virtualization
ETSI – Europian Telecomunication Standard Institute
VM – virtual machine
VNF – Virtual Network Function
PoP – Point of Presence

Virtualizáció

 A virtualizációt mint fogalom már bevezettük (!!!absztrakció!!!), így most mint technológia fogom bemutatni, hogy mi a kapcsolat a virtualizáció és a hálózati funkciók virtualizálása között.
A virtualizáció mint technológia, nagyjából egyidős a mainframe számítógépekkel, célja a hardver erőforrások hatékony kihasználása. A technológia sokat fejlődött azóta, és több virtualizációs architektúra fejlődött ki napjainkra. Alapjaiban véve három különböző architektúrát különböztetünk meg egymástól, attól függően, hogy a virtuális erőforrásokat kiosztó és felügyelő hypervisor hol helyezkedik el:

• 1-es típusú
• 2-es típusú
• Konténer

Az 2-es típusú architektúra Desktop Virtualization, ahol a hypervisor az operációs rendszeren fut mint egy alkalmazás, és felette futnak a Guest VM-ek. A host, a hardver erőforrásokhoz alapvetően a host-OS driver-ken keresztül fér hozzá, a hardver erőforrásokért a host-OS-en futó egyéb alkalmazásokkal versenyezik.
1-es típusú virtualizáció (Server Virtualization) esetén a hypervisor réteg közvetlen a hardver réteg felett helyezkedik el, így közvetlenül tudja felosztani a VM-ek között a meglévő előforráskészletet. Ebben az esetben hypervisor tartalmazza a hardver erőforráshoz szükséges illesztő szoftvereket. Ezt a típust szoktuk szerver virtualizációnak is nevezni, és enterprise, SP és DC környezetben ezt alkalmazzuk IT alkalmazásokat futtató környezetek virtualizálására is.
Konténer virtualizáció esetén az a különböző alkalmazások nem rendelkeznek saját operációs rendszerrel, hanem ugyanazon operációs rendszer erőforrásait használják fel egymástól függetlenül.
A virtualizációs technológiákat hardver kihasználás szempontjából az alábbi kategóriákra oszthatjuk:

•  Monolitikus
• Mikrokernelizált

Monolitikus esetben a hardver erőforrás kezelését és elosztását a VM-ek számára a hypervisor végzi. Ebből az következik, hogy mindegyik VM számára biztosítani kell a virtualizált hardver erőforrást, amihez a vendég operációs rendszernek virtuális driver-en keresztül hozzá kell férni.
Mikrokernelizált esetben a hardver erőforrást minden VM saját maga oldja meg, nem kell minden vendég operációs rendszernek különböző virtuális hardver-t biztosítani, így közvetlenebbül férnek hozzá a hardver réteghez. Ebben az esetben a parent VM végzi VM-ek számára a hozzáférést a tároló egységekhez, valamint a hálózathoz, a hypervisor pedig a memóriát és a CPU-t kezeli.
NFV architektúra egyik fontos eleme, a virtualizációt biztosító platform, viszont ennek megválasztása, konfigurációja, üzemeltetése különbözik a jelenlegi IT virtualizációtól, ugyanis, míg hagyományos VM szervereknek csúcs kiszolgálást kell végezniük, addig a VNF-eknek folyamatos terhelés mellett kell biztosítani a megfelelő rendelkezésre állást.
Az ETSI által szabványosított NFV architektúra egyik célja többek között szabványos keretet adni arra vonatkozólag, hogy milyen virtualizációs platformon, milyen beállítások mellett, hogyan futtasson a hálózati funkciókat biztosító VM-ket.

ETSI NFV architektúra

Amikor ilyen architektúra ábrát mutatunk az IT vezetők felé, akkor megráncolják a szemöldöküket, és kérdőn tekintenek ránk, hogy ebből, hogy következik az, hogy CAPEX/OPEX…. Miért is kell ilyen bonyolult rendszert építenünk?
A kérdés persze nem ilyen egyszerű, ugyanis először fel kell mérni azt az infrastruktúrát, amit kiváltunk NFV-vel, és az egyik legfontosabb kontextus, hogy kell-e a célhardver a funkció ellátásához. A következő pedig, hogy lehet a hálózati szolgáltatás létesítését/konfigurálását automatizálni, azzal, hogy virtualizáltuk.
Vizsgáljuk meg a feni ábrát, milyen elemek is tartalmaz, mi az, amit ebből ismerünk, és hol kell komolyabb fejlesztést bevinnünk a jelenlegi infrastruktúra működésébe.
Kezdjük a technikailag legfontosabb elemmel az NFVI-vel, ami gyakorlatban azokat a platformokat fedi le, amin a virtualizációt megvalósítjuk. AZ NFVI 3 rétegre bondható:

• Hardver réteg

Aminek eleme a

•   Compute
•   Network
•   Storage

• Virtualization réteg (hypervisor)
• Virtuális erőforrás réteg

Eddig semmi extra igaz? Akik használtak/ismernek valamilyen virtualizációs platformot azoknak a fenti elemeken nincs semmi meglepő.
A virtuális erőforrás réteg felett helyezkednek el a VNF-ek, vagyis a virtuális hálózati funkciók, és itt most nem a vmware standard vagy distributed vswitchre gondolok, hanem azokra a VM-ekre, melyek képesek ugyanazt a szolgáltatást nyújtani mint egy Cisco/HP/Juniper… router vagy Cisco/Fortinet/Checkpoint... tűzfal vagy F5 loadbalancer… vagy bármilyen hálózati funkciót ellátó berendezés.
Eddig egyszerű, mert fogom a Vrouter.ova-t, deploy vcenter-ben és hagy szóljon routing/switching hálózati eszközök nélkül…
Annyira azért ez még sem egyszerű és erről gondoskodtak az ETSI-nél is, ahol a szabványban a lefektették azt is, hogy VNF-ket EMS-sel (Element Manager System) kiegészítve központilag kell/lehet majd menedzselni és az NFVI-n kívül még az alábbi architektúra elemeket is definiálták:

• VIM (Virtualised Infrastructure Manager)
• NFVI-t paramétereket lehet meghatározni, központilag
• VNF Manager
• VNF virtuális és hálózati konfigurációit lehet meghatározni, központilag
• NFV Orchestrator
• Az architektúra paramétereit lehet meghatározni, központilag

A lényeg, platform függetlenül kell a fenti elemeknek megvalósulnia….
Továbbá az egésznek illeszthetőnek kell lenni a vállalat OSS/BSS rendszerével….
Sok sikert hozzá!

Egyszerűsített NFV

Szerencsére sok esetben a megvalósításnál nem a teljes ETSI standard a cél, hanem valamilyen hybrid architektúrát kell megvalósítani NFV appliance-ekkel és platformokkal. Tavaly és tavalyelőtt volt szerencsém jó projektek keretében mélyebben is megismerni NFV-re szánt platformokat és VNF appliance-ket, így sikerült mélyebben is megérteni, hogy mi az architektúra célja.
Techtoriálon is adtunk elő a témában, ahol a közönséget is sokkoltam a az eredeti architektúrával, de a kifejtésben egyszerűen el tudtuk magyarázni a lényeget, amit most karakter spórolás céljából a lenti animációval helyettesítek:

Szóval fentiekben kifejtett architektúra elemek integrálva vannak egy-két platformba, akkor igencsak le tud egyszerűsödni az életünk, mert megvalósításhoz szükséges lesz egy NFV platform (NVI és VNFM) és egy NFV orkesztrátor,és ezt már könnyebben tudjuk illeszteni a a vállalati rendszerünkhöz (OSS/BSS) szabványos API-k segítségével.

Service Function Chaining (SFC)

Ahhoz, hogy a NFV platformon futtatott VNF-kből hálózat alakuljon ki, VNF-ket belülről is és kívülről is össze kell kötnöm egymással, a fizikai hálózattal, és a felhasználókkal. Szolgáltatások láncolására, használhatunk hagyományos technológiákat is mint pl: vSwitch, VLAN, EoMPLS, VPLS, GRE, IPSec…, de ha szeretnénk igazán dinamikus, jól skálázható rendszert kialakítani, akkor érdemes az Overlay technológiák felé fordulnunk.

Overlay technológákról az alábbi linken olvashattok:

https://telecommer.blogspot.com/2019/08/halozat-virtualizacio-episode-iii.html

SDN és NFV viszonya

SDN és NFV két jó barát, együtt harcol, s biztosít dinamikusan kialakítható hálózati szolgáltatásokat a felhasználók számára. SDN kontroller lehet egy VNF, de NFV orkesztrátor is egyben, ezt az integrálás során magunk definiáljuk, hogy amit építünk egy SDN megoldással integrált NFV, vagy egy NFV architektúrába illeszkedő SDN megoldás. Egy bizonyos, hogy érdemes megvizsgálni elsősorban az OpenSource integrációs lehetőségeket, ugyanis ha már OpenNFV és OpenSDN megoldások integrálhatók egymással, akkor előbb utóbb a gyártók is beépítik megoldásaik tárházába ezt a lehetőséget és külső partner által támogatott rendszert is tudunk építeni.

Hálózat-virtualizáció és Hálózati Funkciók Virtualizálása

A hálózat-virtualizáció egy központi fogalom, amibe többek között a hálózati funkciók virtualizálása is beletartozik. Így tehát, ha elkezdünk NFV-vel foglalkozni, előbb utóbb belefutunk az Overlay és SDN fogalmakba is, mert ezek együtt és külön is képesek valamilyen szintű hálózat-virtualizációt biztosítani. Önmagában a NFV-vel egyfajta központi virtualizációt, erőforrás kezelést tudunk megvalósítani a hálózaton, így jellemzően adatközpontban, vagy PoP-kban (PL: CSP) fordul elő nagy rendszerek esetén, de Branch in the BOX (Pl: Cisco ENCS) jellegű megoldások is elérhetők.

Összefoglaló

NFV architektúra kialakítása nem egyszerű feladat, de bizonyos elemeket, már használunk Enterprise, DC és SP környezetben. Munkáim során már több helyen is találkoztam azzal, hogy VNF-et használnak ügyfelek a hagyományos virtualizációs környezetükben, így hát sokkal előrébb járunk a technológia használatban mint azt sokan gondolják. Most már egy-egy funkció bevezetésénél nem kérdés, hanem elvárás, hogy legyen virtuális verziója, mert az hatékonyabban üzemeltethető/tesztelhető/fejleszthető/menthető mint fizikai társaik. Persze ne legyenek illúzióink, a hardver alapú megoldások kora nem járt le, csak ennek következtében átalakulóban van.