Ugrás a fő tartalomra

Bejegyzések

#sdn címkéjű bejegyzések megjelenítése

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

Hálózat-virtualizáció EPISODE V - PART II South-bound APIs 2

South-bound APIs 2   YANG alapú leírónyelvek és API-k YANG adatstruktúra egy leíró modell arra, hogy milyen követelményeket támasztunk a API lekérdezés vagy operáció formáját tekintve, továbbá definiáljuk a konfigurációs paraméterek struktúráját. Bizonyos szempontból nézve az SNMP OID-ok is megfelelnek ennek az adatstruktúrának, így joggal merül fel a kérdés, hogy minek vesződünk mással? A koncepció egy NET/RESTCONF kapcsán az, hogy az egyszeri - speciális hálózati szaktudással nem rendelkező - programozó is tudjon kódot írni, ugyanis a programozók otthonosabban mozognak a XML, JSON vagy YALM formátumú konfigurációkban mint az SNMP OID-ban, vagy CLI-ban. JSON formátumú konfiguráció leírást már előző postomban mutattam. Így most nem térnék ki külön a formátumra. A JSON formátumon kívül, amik még különböző automatizációs és SDN rendszerek esetén népszerűek, az XML és YALM formátum. Akit érdekelnek a különböző formátumok részletes leírása annak az alábbi forrásokat javas

Hálózat-virtualizáció EPISODE V - PART II South-bound APIs

South-bound APIs Déli-irányú API-k esetén nem olyan "egyszerű" a helyzet mint északi-irányban. Ugyanis még nincs - és talán sosem lesz - olyan egységes, kvázi sztenderdizált protokoll mint a REST API. Hogy miért? Hát kérdezzük meg a gyártókat! Miért nem a NETCONF, vagy a SNMPv3, vagy az OpenFlow mellett tették le a voksukat egységesen. Mint a korábbi bejegyzésemben írtam már, a gyártók az SDN megoldásaikat sokkal inkább csomagolt termékként kínálják, mint egymással együtt működő standardoknak megfelelő részegységeket. Ezért van az, hogy a déli-irányú SDN integrációt nem lehet, egy protokollal megvalósítani egy heterogén rendszerben. Déli-irányban, így gyakorlatilag bármi lehet API, amit az SDN kontroller és a hálózati eszköz is támogat... Azért próbáljunk meg néhány protokollt kiemelni, mert azokban megvan minden olyan funkcionalitás, ami alkalmassá teszi az orkesztráció megvalósítására.   YANG adatmodell RFC6020 - Yet Another Next Generation... A fenti k

Hálózat-virtualizáció EPISODE V - PART I North-bound APIs

Application Programming Interfaces - APIs API-król az SDx bejegyzések során már röviden beszéltem, de most tegyük nagyító alá a témát, és nézzük meg az egyes API-k működését, hogyan kapcsolódnak az egyes orkesztrációs szintekhez (kontrollerekhez). Tehát mindenkinek megvan, hogy az SDN architektúra referencia középpontja maga az SDN kontroller. Ez alapján azok az API-k amik a kontrollert alkalmazás oldalról érik el (tipikusan REST-API), észak-irányú API-nak - North-bound - amikkel pedig a kontrollerrel érjük el az infrastruktúrát azokat pedig déli-irányú API-nak - South-bound - szoktuk nevezni. A fentiek alapján, és felhasználásuk szempontjából megpróbálom leírni ezeket a protokollokat, annyi extra csavarral, hogy bevezetem az integration-API fogalmát, ami bizonyos szempontból észak-irányú API-nak is tekinthető, de szerintem ez inkább külön kategória, mert ez kontroller, vagy kontroller jellegű alkalmazások összekötését teszi lehetővé. North-bound API REST

SD-BRANCH WS in Brussel Diegem

 SD-BRANCH WS in Brussel Diegem Olyan tengersok ideje van az embernek, hogy nem tudjon mit is kezdjen vele… Ha látok ilyet, akkor majd szólok, most viszont sebtében (még a kobakomban van), innen a reptérről megírom a tapasztalataimat, az HPE által szervezett partnerek szóló 2 és fél napos Aruba SD-Branch workshop-ról. Ahhoz, hogy mindenki értse miről is beszélek, indítsuk onnan, hogy az Aruba (vagy HPE) Brand-estített SDN megoldás mi célt szolgálhat az életünkben. Alapvetően jár a piros pont az Arubának azért, hogy ezt a meglévő termékportfóliójára építette fel és nem akviráltak már egy befutott SD-WAN megoldással rendelkező gyártót (pl Riverbed). Igen az Aruba SD-Branch célja, hogy Branch-ek és az adatközpont (DC) és vagy a HQ között SD-WAN hálózatot építsünk fel. A HPE TSS kapcsán, amit írtam a SD-Branch-ről az így a 2,5 nap fényében már nem állja meg a helyét. Ugyanis eltérő módban kell használni az Aruba Mobility Controllereket, és nem Wireless c

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óg

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 megk