Ugrás a fő tartalomra

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

SDx architektúrák

Tudásunk naprakészen tartása során vagy egy gyártói bemutatón és/vagy partneri rendezvényen biztosan belefutottunk valamilyen Softver Defined technológiába, ahol lelkesen magyarázták, hogy OPEX/ CAPEX csökkentés, meg hogy single pane of glass és hasonló marketing BULL…..etpointokat.

A címválasztás nem véletlen, ugyanis szerintem helyre kell tenni az SDN alapú technológiák körüli túlmisztifikált marketing pontokat és nem csak egy aspektusból vizsgálni ezt a kérdéskört. Így hát nézzük meg milyen lehetőségek, adottak a sötét oldalon.

Definícióm szerint az SDx esetében az x gyakorlatilag bármilyen ASCII karaktert felvehet, attól függően, hogy egy-két gyártó Marketing osztálya mit talált ki. Tehát mára a SDN egy lassan kiüresedő marketing eszközzé, brand-é vált? Az attól függ, mennyire mélyen ismerjük az eredeti SDN koncepciókat, és egyes SD-Brand-ek közül mik azok, amik az eredeti architektúrára leginkább hasonlítanak és melyek azok amik csak megkapták a címkét, mert így eladhatóbb a termék.
Bejegyzéseim során igyekszem olyan SDx technológiákat áttekinteni, amelyek valóban adhatnak választ az alábbi üzleti és technikai elvárásokra:

  •  Skálázhatóság
  •  Programozhatóság/Automatizáció
  • Központi menedzselhetőség
  •  Rugalmasság/Megbízhatóság/Robusztusság

Na de mi lehet az x?
SDx ahol az x:
  •  x1=N mint Network
  • x2=W mint WAN
  •  x3=DC mint DataCenter
  •  x4=A mint Access
  •  x5=S mint Storage
 Ahhoz, hogy fentieket részletesebben tárgyalni tudjuk a gyártói megoldásoknál, meg kell ismernünk az SDN koncepciót, amiből ez a brand kifejlődött.

Kis történeti áttekintés:
A Softver Defined Network vagy röviden SDN koncepció 1995-ben kezdődött, amikor a SUN Microsystems megjelentette a JAVA-t mint programozási nyelvet. Az AT&T-nél dolgozták ki az első hasonló koncepciót a GeoPlex projekt kertében. A cél, egy olyan architektúra megalkotása volt, ahol JAVA-n keresztül az alkalmazás rétegből lehetett a hálózatot programozni, konfigurálni, ezzel biztosítva egy egyszerűbb provisioning rendszert. Segítségével egy felületen keresztül, egységesen lehetett az eszközöket konfigurálni.

1998-ban Mark Medovich a Sun Microsystems vezető kutató mérnöke tovább fejlesztette a GeoPlex elgondolását és JAVA alapokon elkészítette a WebSprocket soft switch-et, aminek új hálózati operációs rendszert és objektum orientált struktúrát adott. Ezzel képes volt az interfészek, protokollok beállításait módosítani absztrakciós réteget használva. A WebSprocket-eten keresztül JAVA alapú alkalmazások képesek voltak a hálózat konfigurációját dinamikusan módosítani.
A telekommunikációs iparág 2001 óta foglalkozik SDN koncepcióval első gyártóként az Ericson soft-switch fejlesztésbe kezdett.
Igazi áttörést a területen a közösségi portálok elterjedése, és hozzájuk kapcsolódó Content Delivery hálózatok hozták el, innentől az SDN koncepcióban történő fejlesztés igazi üzletté vált. Open Networking Foundation 2011-ben mutatta be OpenFlow alapú SDN koncepciót, ami white-box switching megoldásra épült, ám ezt a gyártók végül nem abban a formában implementálták.
Jelenleg három SDN koncepció létezik egymással szorosan karöltve, kiegészítve egymást.

  •  SDN OpenFlow white-box switching (külön Control Plane, külön Data Plane )
  •  SDN API architektúra (Kontroller + API)
  •  SDN Overlay hálózatokkal

Nah de mitől SDN az SDN?
Az SDN architektúra alapvetően 3 különböző réteget definiál számunkra:
1.     Infrastruktúra réteg
  • Az infrastruktúra rétegbe tartoznak azok az eszközök, protokollok, amelyek az adatok továbbításáért felelnek.
2.     Kontroll réteg
  • Kontroll réteg, amely meghatározza az infrastruktúra számára a továbbítás mechanizmusát.
3.     Alkalmazás réteg
  •  Alkalmazás rétegbe tartoznak azok a programok, felhasználók, ügyfelek (Tenant-ok), amelyek a hálózatot igénybe veszik, mint erőforrást.
A három réteg közti kommunikáció API interfészek biztosítják.
Ha a kontroll réteget tekintjük az architektúra referencia középpontjának, akkor azok az API-k, amik felette helyezkednek el az észak-irányú (northbound) API-k, és amik alatta találhatók, azok a déli-irányú API-k.
DE! mi a célunk ezzel az egésszel, és hogyan kapcsolódunk a hálózat-virtualizációhoz?
A SDN illetve SDx technológiák jól megválasztott célja, hogy absztrakt módon prezentálja a felhasználó vagy alkalmazás felé a hálózatot azért, hogy dinamikus erőforrásként tekintsünk rá, és ha szükséges, akkor dinamikusan változtassunk rajta, tehát virtualizáljuk (a fizikai korlátokon belül).

Akkor mi ez sok SD-Brand?

Ellentétben az eredeti SDN koncepcióval minden gyártó megpróbál bezárkózni a saját megoldásába, és csomagolt termékként szolgálja a saját Software Defined megoldását, viszont ennek ellenére is jól automatizálható megoldást nyújthatnak a hagyományos hálózati megoldásokkal szemben.
A teljesség igénye nélkül vizsgáljuk meg az alábbi SDx architektúrákat:


SD-WAN
Az SD-WAN koncepciója a WAN kapcsolataink redundanciájának növelése, illetve a WAN kapcsolataink közti loadbalancing megoldása. Tapasztalt hálózati szakértők ilyenkor röhögnek fel teljes joggal, hogy ezt már egy policy-based routing-gal 20 éve megvalósították, és igazuk van, egészen addig, még fel nem vetjük azt az igényt, hogy a policy-t dinamikusan változtatva szeretnénk útvonalat módosítani a WAN kapcsolataink felé. Ebben az esetben a hagyományos policy-based routing alapú megoldások már nem skálázhatók annyira jól, mint egy kontroller modult is tartalmazó SD-WAN architektúra. SD-WAN-nal nem csak dinamikus policy-routing-ot valósíthatunk meg, hanem a szolgáltatói vonalak redundanciáját is felválthatjuk vagy kiegészíthetjük n+2-es redundáns Internet feletti overlay tunneling-gel.

SD-DC
Sofware Defined DataCenter koncepció alapvetően két szempontból közelíthető meg:

  • Hardver alapú szolgáltatás
  • Szoftver alapú szolgáltatás
Hardver alapú szolgáltatás esetén, a hálózat működése, a hálózati rendszerrel együtt implementált kontroll rétegeben definiálható.
Szoftver alapú szolgáltatás esetében, a hálózat csupán egy átviteli eszköz, és minden hálózati funkciót a virtualizációs rendszerrel együtt implementált kontroll rétegben definiálunk.
Mindkét megközelítéshez szükséges a hálózat, mint hardver és szoftver erőforrás absztrakciója. Ehhez jó eséllyel valamilyen transzport független overlay technológiát fogunk alkalmazni.

SD-Access
Az SDA mint ötlet/koncepció, egyenesen következik az SD-DC-ben már megvalósított és működő overlay + kontroll megoldásból, a különbség, hogy itt hangsúlyosabb talán a szolgáltatások automatizálása, mint skálázási problémák kezelése. Továbbá a hálózat automatikus és automatikusan frissülő dokumentáltsága. Az integrálhatóságnak köszönhetően, ki tudunk alakítani akár full stack security megoldást, ahol a antivírus védelmen felül viselkedés alapú analízissel, a veszélyesnek ítélt végpontokat akár fizikailag is kizárhatjuk a hálózatból.
SDS

Sofware Defined Storage…. Hát mivel ez NEM kapcsolódik most szorosan a hálózat-virtualizációhoz, ezért javaslom olvasgassátok Neumann Péter kollégám által vezetett newman.cloud-ot, ha 3 betűs rövidítés feloldásánál többet szeretnétek tudni erről a témáról. ;) Sorry.

Application Programming Interface (API)

Magyarul alkalmazás programozói interfész, e-nélkül nem lenne túl sok értelme az SDN technológiáknak hálózat-virtualizációs szempontból, ugyanis az API-k, amik biztosítják az absztrakt hozzáférést a hálózathoz, mint erőforráshoz.
Miért akarunk absztrakt réteget a hálózat felé?

Mi hálózati szakértők nem szeretnénk, viszont a programozók és alkalmazás fejlesztők nem feltétlen értik a hálózatokat működtető protokollokat, ezért ha olyan alkalmazásokat szeretnénk az IT infrastruktúránkba, amik automatizált módon dinamikusan férnek hozzá a hálózathoz, akkor biztosítani kell számukra egy egységes felületet, amin keresztül vezérelhetik (!!!nah ezt csak megfelelően ellenőrzött környezet mellet!!!) a hálózatot.
Sok minden lehet észak-irányú, absztrakciót biztosító API, de nagyon úgy fest, hogy régóta ismert és használt REST API lesz a befutó programozói interfész, mondhatni „egységesen”.
Déli-irányban…

Inkább szemléltetném az alábbi ábrával:

Tehát bármi lehet API, ami hálózati eszközt vagy hálózati forgalmat képes távolról befolyásolni.

Összefoglalva:

A SDx architektúrák segítik a hálózat-virtualizáció egyik fontos elemét, méghozzá a dinamikus erőforrás kihasználást, valamint lehetővé teszik az integrált megoldások kialakítását. Fontos, hogy felmérjük, és felismerjük azokat a pontokat az infrastruktúrában, ahol ezek a technológiák megkönnyítik a munkánkat és nem visznek be túlzott komplexitást.

A következő bejegyzést A Network Function Virtualization-nak (NFV) és ETSI MANO architektúrának szánom.