Mellékleteink: HUP | Gamekapocs
Keres
Komoly security line-up az idei SYSADMINDAY-en: FPS játékok hackelésétől a hálózati szemfényvesztésen át a COM-Object Hijackingig!

Tárolópiaci stratégiák: az IBM dilemmája a túl jó termékkel

Fehér Valter, 2012. augusztus 14. 09:47
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

Az IBM tárolópiaci szereplését ugyanaz a hagyományos kettősség jellemezi, mi az egész cég üzletpolitikáján megfigyelhető: fókusz a nagyvállalatokon, a csúcskategóriás, komplex megoldások szállításán, miközben az alsóbb kategóriákat a vállalat mintegy kiegészítésként, gyakran külső beszállítók segítségével fedi le.

DS8000 mind felett

A DS8000 család révén, amelyet egyébként Magyarországon, Vácon szerel össze az IBM és onnan szállítja az egész világra, a vállalat tagja a csúcskategóriát uraló triumvirátusnak az EMC és a Hitachi mellett. A DS8000 domináns pozíciókkal bír a mainframe adattárolás területén, köszönhetően annak, hogy az IBM mainframe rendszerek toronymagasan uralják a piacot.

Mint minden, üzletileg kritikus igényeket kiszolgáló rendszer, a DS8000 a legmagasabb rendelkezésre állási, megbízhatósági és adatvédelmi funkciókat vonultatja fel, aminek az alapja a kapacitás és teljesítmény skálázódása, az adatintegritás és titkosítás biztosítása, valamint a kifinomult és nagyteljesítményű távoli replikációs képesség. Az IBM DS8000 egy igazi klasszikus csúcskategóriás rendszer, amely a frissítéseknek köszönhetően lépést tartott az adattárolásban megjelenő új technológiákkal, mint a thin provisioning, a dinamikus tárolórétegezés és SSD-k támogatása, valamint a kevert SAS és NL-SAS konfiguráció.

Az IBM nevével kombinálva a DS8000 rendkívül sikeres a csúcskategóriában, csak Európában több ezer telepítés található éles üzemben, ami a 250 ezer dollár feletti átlagos eladási ár figyelembe vételével nem kis teljesítmény. Az IBM tárolóüzletág hardverforgalmának mintegy 40 százalékát adja a DS8000, amely arány az ilyen termékeket körülvevő jelentős szoftver- és szolgáltatástartalom révén összességében ennél is jóval magasabb, nem beszélve a nyereségességről.

Színre lép az XIV

Az IBM-nél minden tárolótömb, amely a DS8000 alatt volt, másodlagosnak számított. Egészen 2008-ig, amikor a cég felvásárolta az EMC volt főtervezőjének új alkotását, az XIV-t. Az XIV már egy új generációhoz tartozik, amelynek célja pontosan a nagy öregek által hordozott komplexitás és korlátok áttörése. Az ilyen hagyományos korlátok közé tartozik a RAID redundancia és csoportok alkalmazása, a rendszer menedzsmentje, különös tekintettel a rendszer kiegyensúlyozására és a LUN-ok elhelyezésére.

Az XIV architektúrája szoftveresen vezérelt redundanciával és a LUN-ok egész rendszerre kiterjedő szétterítésével váltja ki a RAID-et, vagyis az összes merevlemez folyamatosan szolgálja ki az összes LUN-t, megszüntetve ezzel a terheléselosztás és kiegyensúlyozás problémáit. Azzal, hogy egy-egy LUN alatt akár 180 diszk is lehet, az XIV megengedheti magának, hogy kizárólag lassabb és olcsóbb, de nagy kapacitású NL-SAS (lényegében SATA) diszkeket használjon. Igaz, a moduláris architektúra az adatvédelem és a teljesítmény maximalizációja érekében minden adatot áttükröz egy másik csomópont (vezérlő és diszktömb) lemezére, amivel megfelezi a hasznos kapacitást, de még így is költséghatékonyabb tud lenni, mint a klasszikus, 10 és 15 ezres Fibre Channel és SAS lemezeket használó tömbök.

Megalkotói az XIV-t egy igazán nagy teljesítményű tárolótömbnek szánták (ez magyarázza a középkategóriában hatalmasnak számító RAM cache-t is), amelyet példátlanul könnyű telepíteni és üzemeltetni. A folyamatos szoftveres és hardveres fejlesztések révén az XIV idővel még gyorsabb és még inkább a nagyvállalati igényeknek megfelelő lett, a tárolórétegezés helyett megjelentek a szoftveresen vezérelt QoS szintek a LUN-okhoz, az olvasási SSD cache a még alacsonyabb átlagos késleltetések érdekében.

Az IBM-be olvadást követően az XIV eladási látványos növekedésnek indultak, és 2009-ről 2010-re több mint megduplázódtak Európában, a Nagy Kék tárolóhardver-eladásainak 15 százalékát hasítva ki. Gyors telepíthetősége, minimális konfigurációs és menedzsment-igénye, valamint magas és stabil teljesítménye rendkívül vonzó lett a kritikus alkalmazásaikat és szervervirtualizációs projektjeiket gyorsítani kívánó cégek számára.

2011-re  azonban elfogyott a lendület, az XIV pedig egy növekvő piacon és növekvő IBM-en belül csökkenést produkált Európában, ami 2012 első negyedévében már inkább mélyrepüléssé fajult. Nyilvánvalóvá vált, hogy az IBM-en belül is zavaros az XIV pozicionálása és filozófiájának beillesztése a portfólióba, mivel semelyik más termékhez nem hasonlít. Az XIV ráadásul, miközben mérnökileg rendkívül elegáns, valójában semmilyen irányban nem skálázódik eléggé: sem olcsó és kicsi nem tud lenni a középkategória jobb lefedése érdekében, sem pedig elég naggyá nem tud nőni, hogy versenyezzen a 3PAR-ral, vagy az EMC és Hitachi nagyvállalati tárolóival. Az XIV architektúrája gyönyörűen megoldja a problémákat, ha azok a problémák a teljesítményről szólnak és nem nagyobbak 160 TB-nál - és lehetőleg nem kisebbek 40-nél.

V7000: ez miért nem előbb jutott eszükbe?

Az XIV-nak azonban időközben lett egy sokkal nagyobb problémája is, ezt a problémát pedig V7000-nek hívják. A középkategóriás StorWize V7000 tömb, szakítva az IBM korábbi gyakorlatával, nem egy külső beszállító platformjára épül, hanem a vállalat SAN Volume Controller, azaz az SVC tárolóvirtualizációs szoftver kódbázisára - a V7000 alapjaiban tehát egy SVC belső diszktömbbel. Ez pedig minden jel szerint olyasvalami, amire a vevők nagyon harapnak. A V7000 tömbök eladásai egy év alatt nulláról százmillió dolláros nagyságrendre gyorsultak, és minden jel arra mutat, hogy ez a lendület még jó ideig kitart. A termék máris a második legnagyobb forgalmat generáló tárolótömb a portfólión belül a DS8000 mögött, és magabiztosan felülmúlja az XIV által generált árbevételt.

A V7000 ugyanis, bár belső adatszervezési architektúrája talán mérnöki szemmel nem olyan elegáns, sokkal lényegesebb és nagyobb problémákat old meg, mint az XIV, és valójában sokkal funkciógazdagabb is. A V7000 fürtözéssel rendkívül magas rendelkezésre állást és akár petabájtos kapacitást képes elérni, ami alkalmassá teszi a vállalati szintű tárolókonszolidációra,  sőt mi több, az SVC kódbázis révén kiforrott tárolóvirtualizáció technológiát hordoz, amellyel a cégnél lévő, már elavult tömbök is bevonhatók a V7000 menedzsmentje alá, azokról a LUN-ok tetszés szerint leállás nélkül átmigrálhatók, rengeteg időt és pénzt spórolva az üzemeltetésen.

Az SVC és a tárolórendszerek virtualizációja ugyan nem új koncepció, ám  a legtöbb vállalat még mindig nem vezette be, főleg nem az egész infrastruktúrjáára kiterjedően. Ez valószínűleg üzemgazdaságossági és rugalmassági okokból is elkerülhetetlen lesz a jövőben, így a V7000  kulcsfontosságú képességgel rendelkezik, ráadásul igencsak versenyképes licencelési politikával megtámogatva. A konszolidációs szerepkört erősíti a Fibre Channel és iSCSI protokollok mellett a CIFS/NFS egységesített támogatása is, amivel már az SVC-n is túlmutat a V7000, nemhogy az XIV-n.

A V7000 ráadásul sokkal közelebb is áll az adminisztrátorok kialakult gondolkodásmódjához azzal, hogy teljesítményrétegeket és különböző RAID-csoportokat enged létrehozni, megfeleltetve azokat az egyes üzleti alkalmazások igényeinek. Mindezt ráadásul egy, az XIV által ihletett modern felületen keresztül is megtehetik az adminok, magas fokú automatizációval megtámogatva. Ilyen például a teljesen dinamikus tárolórétegezés, így a V7000 egészen nagy, akár több száz terabájtosra rúgó konfigurációkban is képes keverni a költséghatékonyságot a nagy teljesítménnyel.

De nem feltétlenül kell a V7000-nek mindenben megvernie az XIV-t ahhoz, hogy bebizonyítsa felsőbbrendűségét: ha például  egy szerver- vagy desktopvirtalizációs projekt miatt nagyszámú VM kiszolgálásához az XIV (vagy másmilyen) tárolóarchitektúra az alkalmasabb, azt a V7000 mögé lehet kötni virtualizálva, hiszen az XIV legnagyobb értéke, a magas terhelhetőség az akár 180 egyszerre dolgozó diszk és a nagy RAM cache révén, nem vész el. Ez nem csak teória, az Európában telepített XIV-k 10-15 százaléka SVC mögött üzemel már most is, mivel a skálázódási korlátai miatt vannak ügyfelek, akik többet vesznek és SVC-vel fogják őket össze vagy illesztik be a nagyobb tárolóinfrastruktúrába.

Látva a V7000 sokoldalúságát, skálázódási képességeit és eladásinak gyors felfutását, nem lehet nem arra gondolni, hogy az XIV problémáit nagyban a V7000 is okozza, nemcsak az IBM értékesítési korlátai vagy a konkurencia ereje. Ezt a teóriát erősíti az is, hogy nem csak a V7000 fölé pozicionált XIV, hanem az alatta lévő DS5000 (amely LSI Engenio platform, vagyis mára NetApp E-Series) is rohamosan szorul vissza az eladásokban, ami arra utal, hogy a nagyon széles skálán versenyképes V7000 foglalja el a teret az IBM portfóliójában.

A V7000 és az XIV közti szakadék pedig, legalábbis egyelőre, nem szűkül, hanem tágulni látszik. A V7000 és az SVC ugyanis nemrég megkapták a StorWize felvásárlásával megszerzett valósidejű tömörítési technológiát, amely drasztikus lökést fog adni ezek versenyképességének. A nagyteljesítményű tömörítési rengeteg adattípus esetében hatásos, így például adatbázis és e-mail szervereknél is felére-ötödére lehet tömöríteni az adatok méretét. A tömörítés valós időben zajlik a vezérlőben, és már az adatcache-be is tömörített állapotban kerülnek az adatok, ami alapjaiban különbözik az EMC VNX és NetApp FAS rendszerek által felkínált utólagos tömörítéstől, amelyet csak alacsony aktivitású LUN-okon tudnak bevetni. Így valójában teljesítménynövekedés várható a legtöbb esetben, hiszen effektíve magasabb találati arányt tud a cache produkálni, de a diszkeknek is kevesebb adatot kell átmozgatniuk.

Választás előtt az IBM

Hogy mi lesz az XIV-vel, amely azok után sem talált magára, hogy már lassan egy éve kapott egy sokkal erősebb hardverváltozatot belső InfiniBand-összeköttetéssel, megnövelt cache-sel és továbbfejlesztett szoftverrel, sokkal kevésbé érdekes, minthogy mikor ismeri be az IBM maga és a világ előtt, hogy az SVC kódbázisra alapuló tömbök kell hogy jelentsék a cég tárolótechnológiájának alapjait, és hogy egyetlen adatmenedzsment-platformot kellene lefejlesztenie a DS8000, az XIV és az SVC/V7000 funkcióinak és kódjainak egyesítésével. Ha erre nincs elég idő vagy erőforrás, akkor egyértelműen az utóbbinak kell átvennie a vezető szerepet, ha az IBM a jövőben is tényező akar maradni a tárolórendszerek területén. Szintén ez a felismerés kell ahhoz, hogy a V7000 igazán ki tudja futni magát, jelenleg ugyanis látványosan korlátozottak a vezérlők hardveres erőforrásai, különösen a RAM cache maximális mérete.

Az XIV kínlódása és a csúcskategóriás DS8000 eladásainak morzsolódása kiváló lehetőséget teremtett az IBM számára, hogy újragondolja portfólióját és piaci lehetőségeit. Talán semmi sem jobb érv erre, minthogy az IBM belső IT-je is immár SVC-k mögé szervezi az összes tárolótömböt, beleértve a DS8000-eket, XIV-ket és V7000-eket is, ahogyan azt már egy korábbi cikkünkben is említettük. Hogyan is képviselhetne bármi mást hitelesen az IBM, mint amit maga is tesz, és egy IBM ügyfél mitől is cselekedne másképpen, látva, hogy az IBM saját IT szakemberei SVC-kre és tárolók közti dinamikus adatmigrációra alapozzák a teljes tárolóinfrastruktúrát?

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
FPS játékok hackelésétől a hálózati szemfényvesztésen át a COM-Object Hijackingig: Veres-Szentkirályi András (Silent Signal), Balázs Zoli (MRG Effitas), Marosi-Bauer Attila (Hacktivity) és sokan mások. A standupot Felméri tolja.