:

Szerző: Gálffy Csaba

2013. november 6. 17:37

Cisco ACI: automatizálható fizikai hálózat

A fizikai hálózat szintjén kínál automatizálható kereteket a Cisco új infrastruktúrája. A gyökeresen új paradigmát hozó Application Centric Infrastructure fejlesztését kiemelte a cég egy startupba, az Insieme-et most visszavette az anyacég. Új Nexusok és új kontroller a bejelentésben.

Végre elkészült a Cisco automatizálható adatközponti hálózati infrastruktúrája. Az Application Centric Infrastructure (ACI) a gyártó szerint a következő 5-7 év legnagyobb bejelentése, amely immár megfelelő választ kínál az egyre érettebb alternatív hálózati architektúráknak. Az ACI kontroller-alapú infrastruktúra, amely a hálózati eszközök és a vezérlő közötti hatékony és mély együttműködésre épít a nyílt szabványokon alapuló OpenFlow-val és a hálózatvirtualizációval szemben.

Igény az volna rá

A hálózati piac szereplői, élükön a Ciscóval hosszú ideig fekete dobozként értékesítették eszközeiket, amelyeket jellemzően manuálisan és csak a gyártó szoftvereivel lehetett menedzselni. A kiszolgálókat meghódító virtualizáció, majd automatizáció hulláma így fennakadt a merev hálózaton, ami gátat szabott az adatközpont-szintű, teljeskörű automatizációs megoldások terjedésének. Az elmúlt években egyre erősödő piaci igényekre megjelentek az alternatívák, a hálózatvirtualizáció, amely virtuális hálózati eszközöket használ a fizikaiak fölött és az OpenFlow, amely különválasztja a vezérlő síkot a switchektők.

Ami a két alternatív megközelítésben közös: a komplex hálózati funkciók és azok vezérlése már nem a hálózati eszköz szintjén valósul meg, hanem egy másik síkon (virtuális switch illetve OpenFlow kontroller). Ennek egyenes következménye, hogy az ilyen adatközpontban nincs szükség nagy tudású switchekre, megbízható, de "buta" egységek is teljesíthetnek szolgálatot. Az új irány nyilván érzékenyen érintette a Ciscót: ha a hálózatokat a jövőben a szoftver határozza meg, akkor a Cisco mint gyártó árban kényszerül versenyezni az azonos tudású hálózati eszközöket gyártó más cégekkel és beleszürkül a mezőnybe.

A gyártó számára mostanra sürgetővé vált a megújulás, az alternatívák ugyanis mára veszélyesen éretté és bevethetővé váltak. A VMware augusztusban bemutatott NSX hálózatvirtualizációs megoldása rendkívül jó, és ami még ennél is fontosabb, egységes megoldássá érett. Az NSX ugyan nem olcsó, de a nagyvállalati környezetben mára elvárt automatizációs feladatokat magas szinten oldja meg. Az OpenFlow pedig szintén gyors ütemben érik, néhány fejlesztési ciklus múlva "komoly" helyeken is bevethető lesz az iparági összefogás eredménye.

De mi az az ACI?

Az Application Centric Infrastructure felépítését tekintve nagyon hasonló az OpenFlow modellhez, a switchek beállításait egy célgép, az APIC (Application Policy Infrastructure Controller) vezérli, ennek megfelelő programozásával a teljes hálózat automatizáltan irányítható. A megközelítés előnye, hogy új adatközponti alkalmazás telepítésekor vagy a meglévő alkalmazások módosításakor a hálózat könnyedén adaptálható, nincs szükség időigényes és hibaforrásként jelentkező manuális beállításokra. További fontos szempont, hogy a vezérlő egységes programozási felületet kínálhat, amely a hálózatot, szervereket és tárolókat egyben kezelő megoldások számára könnyű belépési pontot jelent a hálózat irányába - ezzel pedig elhárul a "felhő", vagyis a magas szinten automatizált adatközpont létrehozása útjából az akadály.

A vezérlő és a switchek közötti kommunikáció a Cisco architektúrájában nem szabványos, az OpenFlowtól eltérően igen korlátozott a nyitottságról az ACI rendszerén belül - mondták el a gyártó képviselői a HWSW kérdésére. Ez azt jelenti, hogy az APIC nem képes más gyártók kapcsolóit vezérelni, és más cégek sem készíthetnek a Cisco switcheihez ilyen vezérlőt. Részleges horizontális nyitottság azért van, az ACI-ba integrálható más gyártó tűzfal- és terheléselosztó (load balancer) célgépe is. A zártság mellett szól a Cisco szerint, hogy az egy gyártótól származó, egymás specifikumait jól ismerő, együtt tesztelt, összehangolt vezérlő és eszközök sokkal mélyebb együttműködésre képesek, mint amit ma a nyílt szabványok lehetővé tesznek. Egy példa az alkalmazások "egészségi állapotának" monitorozása, a hálózat szintjén követhető az adott alkalmazáshoz tartozó kapcsolat épsége, az elvesztett csomagok aránya, és szükség esetén ugyanerről a felületről indítható az alkalmazást futtató virtuális gépek mozgatása is a fizikai gépek között - erre egy OpenFlow szabványú hálózat ma nem képes.

Ez már magában hordozza, hogy az ACI felfelé, a menedzsment felé és lefelé, az alkalmazás felé valóban teljesen nyitott. Az ACI megfelelő beépülő modulokon keresztül együttműködik az OpenStack vagy Open Daylight rendszerével, illetve népszerű automatizációs eszközökkel is (Puppet, Chef, CFEngine, Python scriptek). Lefelé az ACI együtt tud működni a Microsoft Hyper-V, Red Hat KVM és VMware vSphere hypervisorokkal és virtuális switchekkel, így a legtöbb elterjedt adatközponti megoldásba problémamentesen beilleszthető. Az allkalmazások oldalán az ACI teljesen agnosztikus, azonban egyes szoftverházakkal (például SAP, Microsoft) együttműködik a Cisco annak érdekében, hogy könnyen újrahasznosítható sablonok készüljenek az alkalmazások hálózati implementációhoz.

Új Nexus 9000-ak

Az ACI hardveres megvalósítása jelenleg az új Nexus 9000-es sorozatú switchekből és az APIC modulból áll. Ez utóbbi egy appliance (célgép), amely a teljes hálózat vezérlését végzi és egységes belépési pontot kínál az eszközök beállításainak módosításához, valamint felügyeli a rendszert. Az APIC skálázódó, fürtözött rendszer, magas rendelkezésreállással, egy ilyen modulra egymillió végpont (IP-cím) kezelése bízható. A Cisco szerint az SDN-kontrollerekkel ellentétben a hálózat autonóm módon képes működni az APIC hiányában is, ilyenkor "klasszikus", a mai működésnek megfelelő üzemmódban dolgoznak a hálózati eszközök.

Cisco Nexus 9508 - lesz még nagyobb is.

Machine recruiting: nem biztos, hogy szeretni fogod

Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

A Nexus 9000-es család mától három taggal bővül. A Nexus 9508 egy 8 kártyahellyel rendelkező, 13U magas switch, amely magas portsűrűséget és 10/40 gigabites átviteli sebességet nyújtó adatközponti eszköz, érdekessége, hogy nincs benne mid- és backpane, ami jóval hatékonyabb hűtést tesz lehetővé. A top-of-rack felhasználásra a 9300-as sorozat két új tagja készült, a Nexus 9396PX összesen 48 darab fix 10 gigabites SFP+ és 12 darab QSFP+ portot kapott, a Nexus 93128TX összesen 96 darab 1/10 gigabites BASE-T és 8 darab 40 gigabites QSFP+ portot kínál. A gyártó ígérete szerint az ACI-kompatibilis hálózati eszközök családja a következő hónapokban gyorsan bővül majd, a 9500-as családban lesz 4 és 16 kártyás modell is, valamint további top-of-rack termékek is érkeznek.

Az új Nexusok visszafelé teljes kompatibilitással rendelkeznek, vagyis képesek működni "klasszikus" módban, ami a korábbi Nexusok normális működésének felel meg. Az újdonság az új "fabric" mód, ami a kontrollerhez való csatlakozást követően kapcsol be és a már említett ACI aktiválását jelenti. A Cisco érdekes módon külső gyártó, a Broadcom hálózati lapkáit használja az új Nexusokban az alapszintű (L2-L3) hálózati funkciók megvalósításához, az ACI működéséhez azonban már bekapcsolnak a saját fejlesztésű alkalmazásspecifikus processzorok (ASIC).

Az Insieme-történet

Az új Cisco termékek fejlesztéséhez is érdekes történet kapcsolódik. Az ACI mögött álló hardveres és szoftveres technológiák kifejlesztését ugyanis a Cisco nem házon belül végezte, hanem "kiszervezte", a legjobb ciscós mérnökökből és menedzserekből, valamint néhány külső alkalmazottból egy startupot hozott létre, amelynek feladata az új Nexus 9000-es sorozat, az APIC és a szoftverek fejlesztése volt. A cég az Insieme (olaszul: közösen) nevet kapta, kizárólag Cisco-tőkével indult, azonban részesedést kaptak az ott dolgozók is. Az Insieme projekt kulcsa volt, hogy sikerüljön a nagyvállalati munkakultúráról leszakadni és valódi startupként működni, akár délutánonként és hétvégén is dolgozni, a termék elkészítésének minden egyebet alárendelni.

A projektet teljes siker koronázta, a Cisco bejelentése szerint a céget névleg 863 millió dollárért vásárolja fel a vállalat. Mivel az eredeti többségi tulajdonos is a Cisco volt, ennek az összegnek csak mintegy 15 százaléka valódi kiadás, ez 130 millió dollárnak felel meg, ennyit kapnak az Insieme-ben tulajdonrésszel rendelkező felső- és középvezetők, valamint mérnökök. Ha ehhez hozzávesszük az eredeti 100 millió dolláros befektetést, valamint a további 35 millió dolláros második körös, szintén a Cisco által finanszírozott második körös tőkebevonást, akkor a teljes Insieme-projekt mintegy 265 millió dollárba került a gyártónak, ami a tétet tekintve aprópénz.

A Cisco egyébként nem először ülteti gyakorlatba a "spin-out spin-in" módszert, a fejlesztés leválasztását majd felvásárlását már korábban a Nexus és a Catalyst termékek esetén is roppant sikeresen alkalmazták. A módszert a vállalat most azután húzta megint elő, hogy a belső kutatás-fejlesztés évek hosszú során sem volt képes előállni a valódi programozható hálózati infrastruktúrával. Az Insieme létezése során természetesen teljes hozzáférést kapott a Cisco belsős dokumentációihoz és zárt rendszereihez, a két cég közötti "fal" az információ áramlását nem akadályozta.

November 25-26-án 6 alkalmas K8s security és 10 alkalmas, a Go és a cloud native szoftverfejlesztés alapjaiba bevezető képzéseket indítunk. Az élő képzések órái utólag is visszanézhetők, és munkaidő végén kezdődnek.

a címlapról