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

Szakterületemből kifolyólag – ahol folyamatosan fejlődő és változó technológiákkal találkozom nap mint nap – sok technológiával ismerkedtem meg viszonylag fiatalon, ami az iskolai oktatásnak, és a munkámhoz kapcsolódó ismeretek megszerzésének is köszönhető. Eddig tapasztalataimat összegezve úgy gondolom, bizonyos technológiák halálra vannak ítélve, bizonyosak tovább fejlődnek, és vannak olyanok, amik meghatározzák a következő 10-20 év Enterprise, DataCenter, és Service Provider hálózatait. A célom ezzel a bejegyzéssel, hogy bemutassam azokat a technológiákat és megoldásokat, amik hosszútávon meg fogják határozni a telekommunikációs és informatikai hálózatokat. Az egyik ilyen fogalom a hálózat-virtualizáció.

Remélem az olvasónak nem vettem el a kedvét, és témát illetően és nem sírnak fel fájdalmukban a hálózati rendszermérnökök, szakértők és architektek.
Főként azért, mert a hálózat-virtualizáció egy olyan fogalom, amely nagyjából 30 éve ismert a szakmában, és ilyen-olyan formában jelen van/volt a megoldásaink tárházában, csak nem így neveztük, nem volt nyilvánvaló, hogy virtualizált megoldást építünk, illetve nem volt köztudott, hogy az adott technológia szolgálhat a virtualizáció eszközeként.
Mivel a hálózat-virtualizáció elég tág fogalom, ezért tapasztalataim, és megszerzett ismereteim alapján megpróbálom a fogalmakat rendbe tenni, illetve gyakorlati nyelvre lefordítani, hogy ez mit is jelenthet napjaink hálózataiban.
A kérdéskört két részre bontanám, tradicionális és absztrakciós virtualizációra.

Tradicionális virtuális hálózatok
Attól függően, hogy adott hálózati architektúrát  milyen szemszögből tekintjük, a hálózat-virtualizáció jelenthet:
VLAN-t, VRF-t, VDC, context-et, VPN-t, VSS-t, vDS-t stb. …

Tehát minden olyan technológia, ami azt a célt szolgálja, hogy forgalmat szeparáljunk el valamilyen logika mentén egymástól – nem úgy mint a fenti képen látható úriember -  egy közös átviteli közegen és berendezésen, a tradicionális hálózat-virtualizáció eszköze lehet. Ezekkel a technikákkal csak egy probléma van, mégpedig hogy statikus beállítások, konfigurációk, amik megváltoztatása időigényes, és üzemeltetési szempontból kritikus. Hányszor is fordult elő hogy az alábbi TAC mérnök segített?

Eddig!

Absztrakciós virtuális hálózatok
Minden olyan technológia, ami absztrahálja a fizikai hálózat felépítését, és dinamikus hozzáférést biztosít a hálózati erőforrásokhoz  absztrakt hálózat virtualizációnak tekinthető.
Ilyen például:
 NFV architektúra, vagy az SDN mint architektúra, amiknek lehet része valamilyen Overlay technológia, amelyekről bővebben fogok majd beszélni a későbbi bejegyzésekben
Ebben a blogbejegyzés sorozatban az absztrakt hálózat-virtualizációhoz kapcsolódó fogalmakról, valamint megvalósításhoz kapcsolódó tervezési  megfontolásokról lesz szó, ugyanis az itt felmerülő tervezési, implementálási, és üzemeltetési feladatok nagy kihívást jelentenek a jelen és jövő mérnökeinek számára. Ezek a technológiák azok, melyek jó eséllyel meghatározzák a jelen és az elkövetkezendő 10 év hálózati megoldásait.
Mivel a hálózat egy elosztott  rendszer, ezért  virtualizálása nehezen megoldható feladat, ugyanis a hálózat mint  rendszer, nehezen képezhető le egy virtuális funkcióra, vagy virtuális funkciók összességére.
Amikor egy hálózat virtualizálását tervezzük, mindig ki kell választani egy funkciót, vagy hálózati szolgáltatást, amit virtuális erőforrásként fognak igénybe venni a hálózathoz hozzáférő rendszerek/user-ek.
A blog-sorozat első néhány bejegyzésének célja az lesz, hogy rendezzük sorainkat, egy nyelvet beszéljünk mindannyian, és minden fogalom a helyére kerüljön.
Fúúú aki most idáig eljutott az úgy érzi, hogy már megint valami SDN-ről lesz szó...

Mindenkit megnyugtatok, ez nem csak az SDN/NFV témakör lesz, így szerintem minden érdeklődő talál magának hasznos ismereteket. Szóval kezdjünk is bele...

EPISODE I

Központi és elosztott hálózat virtualizáció

Központi hálózat-virtualizáció
Központi hálózat-virtualizáció alatt értjük, azt, amikor egy adott virtuális hálózati funkciót, egy adott útvonalon keresztül, egy logikai/fizikai helyen érünk el.
Alkalmazási terület igen széles körben változhat, tipikusan akkor szükséges alkalmazni, amikor valamilyen koncentrálást szeretnénk végezni a hálózaton, de nem hardver erőforrás igénybevételével.
A központi hálózat-virtualizáció esetén az absztrakció csak a hálózati szolgáltatás terminálása esetén értendő, ugyanis maga az útvonal felépítése történhet tradicionális hálózatokkal.
Professzionális IT infrastruktúrában előfordulhat olyan berendezés, aminek csak az feladata, hogy internet felett távoli végpontokat kössön össze titkosított csatornán. Ilyen berendezések voltak régen a VPN-koncentrátorok, de ma ezt a cél szolgálhatja a tűzfal és a router is. Ezekkel a probléma sokszor az, hogy véges szupport idejük, körülményes szoftver upgrade-jük, és felesleges áramot fogyasztanak, amennyiben csak egy funkcióra használjuk . Általában a hálózati design-ban kitüntetett szerepük van és e-miatt sok mindent kell a tervekben hozzájuk igazítani.
Nézzünk meg egy konkrét példát:

A fenti ábrán egy általános IT infrastruktúra vázlatos tervét rajzoltam fel, ahol az Internet hozzáféréssel rendelkező távoli felhasználók szeretnék elérni az infrastruktúrába kötött host-okat, valamint az infrastruktúrában szerepel egy távoli telephely, ami site-to-site összeköttetéssel éri el ezt a központot.
Általában hálózati és biztonsági szempontból javasolt ezeket a funkciókat elválasztani egymástól (ezzel csökkentve akár a single-point of failure eseteket). A tűzfalat egy ilyen infrastruktúrában úgy kell méretezni, hogy produktív forgalom mellett az internet irányban is megfelelő performanciát biztosítson, mind a helyi, mind a távoli host-ok számára. Ügyelni kell a megfelelő redundanciára is ugyanis, ha a tűzfal kiesik, vagy az internet kapcsolat megszakad, akkor a távoli elérések sem fognak működni. Viszont ez megnöveli a tűzfal beszerzési árát, és olyan nélkülözhetetlen szerepet, kap az infrastruktúrában, ami gátolhatja a további infrastruktúrafejlesztést.
Ha az remote-access-t és IPSec-et le akarjuk választani, a hagyományos FW feladatoktól, akkor az két újabb hardver beszerzését jelentheti, ami megnövelheti a beruházás mértékét, a jövőbeli áramfogyasztást, a rack hely igényt is. Abban az esetben, ha a virtualizáció mint technológia elérhető az infrastruktúrában (márpedig Enterprise, SP, és DC környezetben manapság alap, hogy rendelkezésre áll), akkor megkímélhetjük magunkat a hardver beszerzéstől és a fizikai infrastruktúra megváltoztatásától.

A fenti ábrán a remote-access tunnel-ek terminálására egy virtual tűzfal appliance létesíthetünk, a site-to-site tunnel létrehozásához pedig használhatunk virtual router-t security licence-el. Ennek többek között az az előnye, hogy így szétválasztottuk a funkciókat anélkül, hogy az alap infrastruktúrán változtattunk volna.

Elosztott hálózat-virtualizáció
Elosztott hálózat virtualizáció alatt értjük azt, amikor a hálózati funkciót biztosító entitásunk nem egy adott helyen érhető csak el, hanem mindenütt ahol az IT infrastruktúránkban szükség van rá, ugyanazokkal a paraméterekkel. A könnyebb megértéshez tekintsünk meg az esetet:

A fenti ábrán egy általános IT infrastruktúra nagyon vázlatos képét rajzoltam fel ahol A (Aladár) szeretne kommunikálni B-vel… ja nem most rendhagyó módon E (Elemér)-vel. Aladár a FW-n (tűzfalon) keresztül tud minden esetben Elemérrel kommunikálni, mert különböző switch-en, különböző VLAN-okaban, különböző tűzfal lábakon lógnak. Ezt a forgalmat így ebben a felállásban mindig valami route-olja a L3 subnet-ek között, de az is előfordulhat, hogy NAT-olja. Nos, ha sűrűn alakul így a kommunikáció iránya, akkor lehetne az infrastruktúrát optimalizálni, hogy ezek a forgalmak ne okozzanak terheléses problémát. Mit értünk terhelés alatt NOS:
1.     A kommunikáció alatt fellépő adatátviteli sebesség igényt (laikusok kedvéért: sávszélesség)
2.     SW1 SW2 TCAM bejegyzések miatt fellépő switch memória igény
3.     SW1 SW2 routing/switching process miatt fellépő CPU igény
4.     FW ARP tábla miatt fellépő memória igény
5.     FW route/nat process miatt fellépő CPU és memória igény
Ha elosztott hálózat-virtualizációt alkalmaznánk, akkor fentiekből legalább két ponton lehet csökkenteni:
SW1 SW2 TCAM bejegyzések miatt fellépő switch memória igény
FW ARP tábla miatt fellépő memória igény
Amikor nagy méretű IT infrastruktúrát kell kiszolgálni valamilyen hálózati megoldással, akkor leginkább ezek, azok a paraméterek, amik mentén skálázhatóságot mérjük.
Az elosztott hálózat-virtualizáció lényege, hogy a magasabb szintű hálózati funkciókat (mint pl: routing/nat) nem egy központi helyen érjük el, hanem közel a host-hoz/host-on belül, függetlenül attól, hogy az adott host melyik pod-ban, melyik switch port-on csatlakozik. Joggal hördülnek fel a hálózattal foglakozó mérnökök, hogy de hát a disztribúciós rétegbe letolt routing MLS switch-ekkel ezt a kérdést megoldja… igen és nem… sajnos akkor disztribúciós rétegbe kell erősebb vasakat tenni, amik elegendő ARP/MAC bejegyzést tudnak kezelni, továbbá mi van ha a két host-nak azonos Layer2 szegmensben kell lenni a rajta futó alkalmazások miatt? Több ezres nagyságrendben ez komoly problémát okoz, továbbá ne felejtsük el, hogy manapság már nem az alkalmazásnak vagy a user-nek kell alkalmazkodnia a hálózathoz, hanem hálózatnak kell kiszolgálni az előbbieket.
Elosztott hálózat-virtualizációnak több eszköze lehet mint pl.
·       Overlay alkalmazása
·       SDN alkalmazása
·       NFV alkalmazása
 Ezek a eszközök külön-külön kombinálva, de együttesen is biztosíthatnak elosztott hálózat-virtualizációt. Ezekről a technológiákról a további bejegyzésekben részletesen fogok írni majd.
Térjünk vissza az előző példához:

Aladár és Elemér ugyanúgy szeretne egymással kommunikálni, mint korábban, Aladárnak és Elemérnek mint user vagy alkalmazás, nem fontos, hogy adatokat router-ek/switch-ek/postgalambok/manócskák viszik át. Nekik az információ a fontos, amivel dolgoznak, vagy dolgozni fognak. Így tehát biztosítanunk kell nekik egy robusztus hálózatot, amiben hibák ellenére is átmennek az adatok.
Jelenleg a legnagyobb logikai útvonal redundanciát az L3 hálózatok biztosítanak, ugyanis itt nem kell tartanunk a Spanning-tree okozta útvonal blokkolásoktól, persze lehet különféle L2 MLAG (Multi-chassis Link Aggregation) technikákkal csökkenteni a STP blokkolt port-ok számát, de lássuk be, hogy egy ilyen Control-Plane összeolvasztásból és egyéb virtuális Port-channel trükkökből kialakított hálózaton hamar belefuthatunk szoftver/hardver bug-okba, amik megkeseríthetik az életünket, tehát marad az L3.

Innentől fogva két hálózatról beszélünk párhuzamosan:
 Fizikai infrastruktúra hálózat – aminek eleme
o  Fizikai berendezések, portok-ok, összekötések
o  Köztük lévő adatkapcsolat
o  Rajtuk futó routing protokoll
o  Kialakítható útvonalak
 Logikai virtuális hálózat– aminek eleme
o  Virtuális SW funkció
o  Virtuális router funkció
o  Virtuális tűzfal funkció
o  Virtuális stb..
 Elosztott hálózat-virtualizáció esetén ezek a logikai elemek nem külön entitásként szerepelnek a hálózatban, hanem a teljes infrastruktúrában elérhető funkciók, aminek hardver és szoftver komponensei elosztva vannak jelen a rendszerben.
 Ezt az alábbi ábrával lehet jól szemléltetni:

A fenti ábrában a fizikai hálózat felett kialakított virtuális hálózatban, egyaránt elérhető a switch funkcionalitás ami Layer2 összeköttetést biztosít a host-ok között, az L3 routing funkció, amely a különböző subnet-ben lévő host-ok közti kommunikációt biztosítja, és végül a tűzfal funkció amely L4+ feltételek mentén biztosítja a kommunikációt az egyes host-ok között.
Az elosztott virtuális hálózati funkciók megvalósítása technikailag sokféle lehet, bizonyos gyártók esetében a host oldali virtualizációs rétegben biztosított funkciók érhetőek el, de van olyan megoldás is ahol az operációs rendszer kernel modulja biztosítja logikai funkciót, illetve léteznek hardver gyorsítással támogatott megoldások is. Ahhoz, hogy ezeket a funkciókat értelmesen tudjuk kezelni mindenképp valamilyen controller-re vagy manager-re lesz majd szükségünk hálózatunkban.

Kedves Olvasó, ha most elsőre nem is volt minden egyértelmű, kérlek olvasd tovább a blogomat, hogy kérdéseidre választ találj a későbbiekben:
A következő bejegyzés az Overlay és Underlay technológiákról fog szólni.

Maradjatok velem és megmutatom milyen mély a nyúl ürege.