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:
Na de mi lehet az x?
SDx ahol az x:
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.
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
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
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:
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.
- Kontroll réteg, amely meghatározza az infrastruktúra számára a továbbítás mechanizmusát.
- 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.
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
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.
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.
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.
