A probléma régóta ismert: az adatközpontban a modern, automatizált-virtualizált paradigma szerint felépülő szerveres környezetet a hagyományos hálózati megoldások már nem képesek kiszolgálni. Ennek egyszerű oka van, a hálózat konfigurációja nem szakadt el a fizikai alapoktól, emiatt lassan, sokszor manuálisan, rudimentáris eszközökkel folyik a munkavégzés.
A problémára az elvi választ az SDN adja, az akadémiai gyökerekkel rendelkező megközelítés mára kísérleti projektből komoly, nagyvállalati szinten is bevethető megoldássá fejlődött a HP szárnyai alatt. Az SDN-paradigmát támogató hálózaton a fizikai és a logikai (vezérlő) réteg elszakad egymástól, a hálózati architektúra ezzel kívülről, API-kon (programozási interfészeken keresztül) absztrakt módon programozhatóvá és automatizálhatóvá válik. Ez azt jelenti, hogy a szerveroldali automatizációs és virtualizációs eszközök az API-k révén immár a hálózat funkcióihoz is hozzáférnek, azt szabadon újraprogramozhatják, a céges alkalmazások aktuális igényeinek megfelelően.
Automatizált környezet
Az automatizálás előnyeiről már sokszor beszéltünk, a két legfontosabb talán az emberi hiba lehetőségének csökkentése és a gyorsaság. A folyamatosan manuális konfigurálásnál komoly probléma a tévedés kockázata, amely jobb esetben csak meghosszabbítja a tevékenység végrehajtását, súlyosabb esetben akár komolyabb leállást is okozhat. A tesztelt, ellenőrzött automatizációs eszközök használatával a repetitív folyamatokból ezek a hibák kizárhatóak. A szakértelmet ez nem pótolja, a figyelmetlenségből eredő károkat azonban segít minimalizálni.
(kattintásra nagy méretben nyílik)
A másik fontos szempont a manuális munkavégzés felgyorsítása. A már említett repetitív feladatokat automatikusan lefutó scriptekkel jelentősen fel lehet gyorsítani. Ez nem csak annyit jelent, hogy a konfigurációt végző rendszermérnök végre foglalkozhat fontosabb feladatokkal, hanem azt is, hogy a hálózat rendkívül gyorsan képes lekövetni a változó igényeket, a korábban hetekig tartó folyamatok órák alatt, az órákig tartóak pedig másodpercek alatt lezongorázhatóak - egy új szabályrendszer például gyorsan bevezethető. Az ilyen szintű reakcióképesség már üzleti oldalon is értelmezhető előnyökkel jár.
SDN App Store a programozható hálózathoz
A HP víziója azonban ennél teljesebb, a vállalat teljes ökoszisztémává szeretné fejleszteni SDN-platformját, ennek érdekében SDN App Store néven boltot is nyitott a hálózati alkalmazások számára, a fejlesztők pedig az SDN Developer Kit segítségével készíthetnek szoftvereket. Ezek az appok a HP VAN-on, a Virtual Application Networks hálózati kontrollereken futnak, a hálózati eszközöket pedig a fent említett API-okon keresztül tudják konfigurálni. A HP SDN platform egyébként nyílt, arra nem csak a cég legközelebbi partnerei, hanem független fejlesztők is készíthetnek saját alkalmazásokat. Az alkalmazásboltból komplex, előre elkészített megoldások érhetőek el, amelyek lehetővé teszik a hálózat, a virtualizációs megoldás és a futó alkalmazások szoros együttműködését.
Az SDN nem csak az adatközpontban, hanem a teljes céges hálózaton képes új képességeket biztosítani. A HP által a Microsoft Lync-hez kínált Network Optimizer app segítségével például átkonfigurálható a belső hálózat úgy, hogy a Microsoft kommunikációs platformjának igényeihez igazodjon, a hangos és videohívások számára mindig megfelelő sávszélesség és alacsony késleltetés álljon rendelkezésre. Egy másik példa a Network Protector app, amellyel a hálózat biztonsági szempontból is felkészíthető a BYOD-problémára. A fejlett szoftver kombinálja a hagyományos biztonsági megoldásokat az SDN által lehetővé tett funkciókkal - például a hálózati eszközökkel való kétirányú kommunikáció révén figyeli a hálózati forgalom mintázatát és gyanús mozgás esetén lépni is tud.
Érdemes megjegyezni, hogy az SDN-képes eszközök hibrid működésre képesek, vagyis nem képeznek szigetet a vállalati infrastruktúrában, hanem azzal a megszokott módon együtt tudnak működni, az SDN-funkciók nyomán pedig ezen felül extra képességekkel rendelkeznek. A HP elkötelezett a szabványos megoldások mentén, ennek megfelelően a cég termékei OpenFlow protokoll segítségével tudnak dolgozni akár heterogén környezetben is.
További részletekért látogasson el a HP Innovatív hálózatok oldalára.
(A HP Magyarország megbízásából készített anyag)
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Sziasztok, Szávai Gyula vagyok, a HP Magyarország hálózatokért felelős szakértője. A HP networking csapat nevében hálózatos problémákkal kapcsolatban várjuk a bejegyzéseiteket a következő hetekben, kérdéseitekre örömmel válaszolunk és a HP innovatív hálózati szakértelmére alapozva nyújtunk megoldást nektek.
Üdv, Gyula
- A hozzászóláshoz be kell jelentkezni
Hello, üdvözlünk Magyarország elsőszámú IT-Troll portálján.
Kérdéseim:
* Mi az, hogy "rudimentáris"?
* Felteszem transzparens, TCP/IP alatti forgalomirányítás és throttling-ot lehet ezzel csinálni. Mi alapján történik a routing? Gipsz Jakab ír egy appot, ami eldönti, hogy a bejövő csomagok közül melyik fontosabb?
* Most eltekintek attól, hogy ez egy irdatlan méretű vendor lock-in próbálkozásnak látszik, csak az érdekel, hogy ezt hogyan lehet integrálni egy meglevő hálózatba? Minden nem HP eszköz kuka?
* "(...)és gyanús mozgás esetén lépni is tud." Mit?
* Hogyan fog ehhez egy meglevő cluster (hyper-v, vcenter, egyéb) csatlakozni? HP-nek van saját, SDN-képes hypervisor-ja?
- A hozzászóláshoz be kell jelentkezni
Szia!
Disclaimer: Semmi közöm a HP-hez :)
* Most eltekintek attól, hogy ez egy irdatlan méretű vendor lock-in próbálkozásnak látszik, csak az érdekel, hogy ezt hogyan lehet integrálni egy meglevő hálózatba? Minden nem HP eszköz kuka?
A VAN SDN Controller nevu "doboz" valoban az, de elso blikkre gyakorlatilag ez es a felette levo SDK a hozzaadott ertek ebben az egeszben. Egy idealis vilagban barmilyen eszkoz lehet az infrastrukturaban, ami beszeli az OpenFlow protokollt. (Nyilvan a valosagban ilyen nem lesz, mert ugyanez az API szepen mukodhetne akar SNMP v. NETCONF felett is, de ahany gyarto, annyifele speci eset, igy nyilvan az a legjobb eset, ha az interop kerdes fel sem merul...)
HP-nek van saját, SDN-képes hypervisor-ja?
Nem ismerem a termekeiket, de ha van egy kis eszuk, akkor OpenStack alapokon biztos keszul (vagy mar keszen is van) a megoldasuk.
"(...)és gyanús mozgás esetén lépni is tud." Mit?
Itt talan arra gondolhat a reklamszoveg iroja, hogy IDS jellegu usecasekre is hasznalhato egy ilyen VAN SDN controller? (Az OpenFlow eszkoz is beszelhet a controllerhez) Mar kerdes, hogy mennyire hatekony egy ilyen megoldas.
En a controllerben sokkal nagyobb fantaziat latok, mint ezek a reklamozott usecasek, de nyilvan nem fogok egy forumon otleteket adni a HP-nek. :)
- A hozzászóláshoz be kell jelentkezni
Én attól tartok, hogy ez is csak egy olyan platform mint az ibm lotus domino, hogy jól hangzik, de üzemeltetni, és használni(!!) rosszabb mint szopóálarcban színpadon ugrálni, de a nagy cégek imádják, mert a marketingje jó.
Az alapkérdés persze marad, hogy: de miért jobb ez, mint a meglevő állapot? (bullshit nélkül)
Én nem akarom, hogy a Stephen Blood Jr. Co. Ltd. által írt app töcskölje a lync meg az erp rendszer egymáshoz viszonyított prioritását, mert nem az ő dolga ezt eldönteni.
- A hozzászóláshoz be kell jelentkezni
Az SDN is meg pl. az OpenStack is olyan, hogy tök jók, de gyökeresen más megközelítést igényelnek, mint a "hagyományos" eszközök. Annyira mást, hogy az üzemeltetők részéről teljesen más habitust igényelnek, így tapasztalataim szerint másik emberek jók a "régi" és az új rendszerek üzemeltetésére. Az új megoldásokat csak olyan helyeken láttam még hatékonyan használni, ahol hajlandóak voltak lecserélni az embergárdát...
Úgyhogy HP hálózati eszköz meg SDN helyett a konzervatívabb helyeken marad a Cisco meg a kézzel konfiguralas...
- A hozzászóláshoz be kell jelentkezni
"Úgyhogy HP hálózati eszköz meg SDN helyett a konzervatívabb helyeken marad a Cisco meg a kézzel konfiguralas..."
Az SDN soha nem váltja ki a Cisco (vagy HP ;-) vagy más) hálózati eszközöket, csak a hálózati eszközök szokásos napi rutin konfigurálgatását.
- A hozzászóláshoz be kell jelentkezni
Szerintem mindkettő igaz: a konzervatívabb helyeken a HP nem váltja ki a Cisco eszközöket ÉS konzervatívabb helyeken az SDN nem váltja ki a kézzel konfigurálást. Elnézést, hogy pontatlanul fogalmaztam.
(Megjegyzem én szívesen játszanék mindkettővel és elég nagy Cisco-utáló vagyok, de ez mindegy.)
- A hozzászóláshoz be kell jelentkezni
:-)
Én csak arra akartam utalni hogy a szervereket azért mindenféleképpen be kell kötni valami Layer2 switchbe, és azt 1x fel kell konfigurálni.
- A hozzászóláshoz be kell jelentkezni
Ebben teljesen igazad van.
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Ígéretemhez híven igyekszem válaszolni a kérdéseitekre.
A rudimentális szóra a legjobb válasz talán http://www.e-nyelv.hu/2012-08-07/rudimentalis-familiaris/ oldalon érhető el. A rudimentális jelzővel azt szerettük volna kifejezni, hogy jelenleg az esetek túlnyomó többségében a hálózati aktív elemeket kézzel és egyesével konfiguráljuk, mely a kor követelményeit tekintve nem minden esetben optimális.
A hagyományos értelmű routing jelentősen megváltozik, hiszen a control plane funkció a központi SDN kontrollerbe kerül, így az egyes csomagok továbbításhoz tartozó döntési mechanizmusok többé már nem egyesével az aktív eszközökben dőlnek el. Ezzel a jelenlegi routing protokollok okozta kötöttségek megszűnnek. Gipsz Jakab írhat magának a saját hálózatához egy alkalmazást, attól függően hogy számára mi a leginkább hiányzó hálózati funkció, vagy az App Store-ból a neves gyártók által publikáltak és validáltak közül le is töltheti azt.
A HP Networking évek óta a szabványos megoldások híve és támogatója. Az SDN rendszer alapja az Open Flow protokoll mely felett az ONF őrködik (https://www.opennetworking.org/index.php ). Ahogy már az „Open” is jelzi a megnevezésben - ez egy gyártó független megoldás. A HP OpenFlow képes eszközei más SDN kontroller által is vezérelhetőek, illetve a HP SDN kontrollere más gyártók OpenFlow képes eszközeit képes vezérelni. Ha valamihez hasonlítanom kellene a megoldást, akkor talán a SIP protokollt tudnám említeni.
Hála a Hibrid működési lehetőségnek és a szabványos OpenFlow-nak, heterogén környezetbe is integrálható a megoldás.
A Network Protektor megoldás segítségével, a hálózat peremén (pl.: az adott switchporton) van lehetőségünk beavatkozni. A beavatkozás sok féle lehet, a teljes forgalom tiltása, bizonyos forgalom szűrése, tükrözése, stb…, minden olyan lehetőségünk megvan ami most is elérhető ott ülve az eszköz előtt, csak mindezt automatikusan képes kezelni a rendszer.
A virtualizációval kapcsolatban akár az OpenStack vagy más IAAS PAAS Cloud megoldásoknak lehetőségük van az említett API-n keresztül a szolgáltatáshoz szükséges hálózatot provizionálni.
Ehhez kapcsolódóan érdemes megnézni: http://www8.hp.com/us/en/cloud/hphelion-openstack-community.html
Amit véleményem szerint fontos kiemelni, hogy a hálózat kezelése továbbra is a hálózati mérnökök kezében marad, a megoldás csak segíti őket újabb funkciók könnyebb hozzáadásának lehetőségével.
Üdv,
Gyula
- A hozzászóláshoz be kell jelentkezni
Elnézést hogy kicsit offtopic vagyok, de nagyon böki az oldalam.
Nem annyira szakmai jellegű lenne a kérdésem, inkább általános kíváncsiskodás.
Volt Magyarországon bárkinek is olyan szerencséje, hogy részese legyen a projekt fejlesztésének ?
Folytak magyarországi HP "laborban" fejlesztések ?
Nagyon élvezném az ilyen projekteket, de sajnos a multis tapasztalat azt mutatja, hogy általában az ilyen fejlesztéseket nem engedik ki a leánylávalatokhoz. Persze értem én hogy miért, pedig jó lenne itt is közel kerülni a tűzhöz, és elmondani, hogy Igen benne voltam :)
- A hozzászóláshoz be kell jelentkezni
Ericsson érdekel-e?
Itt vmi ilyesmiről van szó, ha jól sejtem (vhol láttam utalást OpenFlowra).
- A hozzászóláshoz be kell jelentkezni
+1, az Ericssonnal vannak ilyen jellegu allasok, de ne a researcher allasra jelentkezzen, mert oda inkabb elmeleti szakik kellenek.
- A hozzászóláshoz be kell jelentkezni