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.



Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

Cisco SD-WAN első rész Bevezető Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén. Eredetileg ez a sorozat Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát: Kib@#&0tul hosszú lenne. Az SD-WAN témakör önmagában megér egy post sorozatot. A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek: SD-BRANCH (ENCS platform) Meraki SD-WAN IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt )

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate

SD-WAN vagy SD-NINCS I. rész Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra: SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható. SD-LESZ megoldás - valahol a kettő között... Fortigate SD-WAN Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy közbe

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs