Automatikus adatrétegezés az IBM Storwize V7000-ben: bemutatkozik az Easy Tier (x)

Címkék

Aki ésszel használja ki a flash memóriachipekből álló meghajtók, azaz az SSD-k képességeit, úgy többszörözheti meg adattárolójának I/O teljesítményét, hogy közben nem költ feleslegesen.

Felesleges mindent SSD-n tárolni

Unalomig ismert közhely, hogy az adatfeldolgozás sebessége régóta jóval gyorsabb ütemben fejlődik az adattárolásénál, magyarán szólva a processzorok egységnyi idő alatt többet gyorsulnak a merevlemezeknél. Ennek eredményeképp a sok adattárolási művelettel járó feladatok alatt a számítógépek távolról sem ideális hatásfokkal dolgoznak: míg az adattároló folyamatosan “izzad”, hogy teljesítse a kéréseket, a processzorok az adatok betöltődésére várnak. Az I/O-intenzív alkalmazások mint például az online tranzakciófeldolgozás alatt az adatbetöltődés késleltetése akár a futási idő felét is kiteheti.

Kézenfekvő megoldás a gyorsabb tárolók beszerzése, azonban a legújabb technológiák mindig drágák. Az informatika eddigi fejlődése során a felhasználók általában nem gyorsabb, hanem nagyobb tárolókat szerettek volna látni, az ipar pedig készséggel teljesítette ezt az igényt, mivel az adatrögzítéshez használt mágneses technológia könnyen továbbfejleszthető volt az iparágban felhalmozódott óriási know-how révén. A pörgő tányérok helyett flash memóriachipeket alkalmazó SSD-k azonban átírták az adattárolás szabályait, a kapacitás helyett a teljesítmény növelésére terelve a figyelmet -- I/O sebesség és késleltetés terén nagyságrendi ugrást képviselnek, diszkekhez képest, de az egységnyi kapacitásra vetített költségük akár több tízszerese is lehet egy merevlemezzel összehasonlítva.

Egy vállalati felhasználásra alkalmas, több tíz vagy több száz terabájtos, kizárólag SSD-kből álló tároló ma gyakorlatilag megfizethetetlen -- és a legtöbb esetben felesleges is. A gyakorlati tapasztalat azt mutatja, hogy egy tipikus „open system” környezetben az adatblokkok (”extent”) viszonylag kicsiny hányadán (5%-15%) keletkezik az I/O terhelés nagy része és ez a terhelés-eloszlás az idő múlásával sem változik túlzottan. Egy ilyen tipikus környezetet szemléltet a következő ábra:

Storwize V7000

Az I/O terhelés ezen tulajdonságát nevezi a szaknyelv „skew”-nak, a fenti ábra egy „heavy skewed” rendszert mutat, ahol az I/O műveletek az adatok kis részére koncentrálódnak.

Rétegezés automatikusan

Az adatok hozzáférési gyakoriságtól függő osztályozása és tárolása egyáltalán nem újdonság, a legtöbb szervezet már ma is alkalmazza: az éles adatok a legnagyobb teljesítményű tárolókon vannak, a ritkábban szükséges backup adatok lassabb rendszereken, míg az archív állományok szalagos mentések formájában állnak rendelkezésre mert a tárolásuk hosszú távon itt a legolcsóbb, cserébe a visszaállításuk akár órákat is igénybe vehet.

A modern vállalati tárolók az elmúlt évek technológiai fejlesztéseinek többféle kapacitású és sebességű meghajtót képesek fogadni és egyszerre kezelni, így a rétegezést végre lehet hajtani már az éles adatokon is. A legsűrűbben elért adatok kerülhetnek egy tárolón belül a leggyorsabb meghajtókra, például SSD-kre, a ritkábban írt vagy olvasott adatok pedig maradhatnak a lassabb diszkeken. A korábban már említett „skew” görbe meredekségétől függően lehet meghatározni a megfelelő rétegezést. Egy „heavy skewed” típusú terheléssel bíró rendszernél viszonylag kevés számú SSD eszközre történő adatmozgatással is jelentős teljesítménynövekedést lehet elérni. Leírni ezt könnyű, megvalósítani azonban nehéz -- storage adminisztrátor legyen a talpán, aki előre tudja, melyik adatra lesz sűrűn szükség!

Az IBM DS8000 high-end tárolórendszerekhez kifejlesztett Easy Tier technológia a középkategóriájú Storwize V7000 tárolóban is rendelkezésre áll, méghozzá ingyenesen. Az Easy Tier automatizálja a rétegezést és gondoskodik arról, hogy mindig a legsűrűbben elért adatok kerüljenek a leggyorsabb tárolóra -- anélkül, hogy a storage adminisztrátornak külön be kellene avatkoznia. A tároló grafikus felhasználói felületén vagy akár a parancssori interfészen elegendő engedélyezni az Easy Tiert, a többit az algoritmusok elvégzik.

A Storage Performance Council iparági szervezet online tranzakciókezelést modellező SPC-1 tesztje szerint már a teljes adatterület 5 százalékát elég lehet SSD-kre mozgatni az Easy Tierrel ahhoz, hogy háromszoros I/O sebességnövekedés legyen a jutalmunk és az SSD-kre essen az I/O műveletek majdnem 80 százaléka. Az IBM mérései szerint így 96 darab 1 terabájtos SATA merevlemez és 16 SSD kombinációjával akkora I/O teljesítményt lehet elérni, amelyhez egyébként 92 darab FC HDD lenne szükséges.

Az Easy Tier az adatok elérésének sűrűségét egy 12 fokozatú skálán tartja nyilván, ahol 0 jelenti a leghidegebb, legritkábban elért extentet, a 11 pedig a legforróbbat, amelyre a legtöbb művelet érkezik. Az Easy Tier optimalizációs ciklusa 24 órás. Ez idő alatt szinte folyamatos mintavételezéssel feltérképezi az terhelés eloszlását és a keletkezett ”skew”-ból javaslatokat tesz a legforróbb extentek gyorsabb tárolóra történő áthelyezésére. A javaslatokat a terhelés függvényében elbírálja, hogy az egységek mozgatása ne okozzon teljesítmény visszaesést az áthelyezés idejére. A ciklus végére az Easy Tier a legforróbb adatokat automatikusan a leggyorsabb meghajtókra (pl. SSD) mozgatja. Az öntanuló algoritmus folyamatosan figyeli az extentek “forróságát” és ha van olyan extent a lassabb tárolókon, amely forróbb lett a magasabb teljesítményű meghajtókon található leghidegebbnél, azt átmozgatja, a kihűlt adat pedig a lassabb rétegbe kerül.

Az Easy Tier fokozatosan mozgatja az adatokat egyik rétegről a másikra annak érdekében, hogy a művelet ne befolyásolja a Storwize V7000 tárolón futó éles feladatok sebességét, késleltetését. A folyamatos adatmozgásokkal járó terhelés nincs mérhető hatással a teljes rendszer teljesítményére, ezért a storage adminisztrátoroknak nem szükséges azt külön beütemezni. A Storwize V7000-en az Easy Tier beállítástól függően 16MB- 8GB darabokban (“extent”) képes mozgatni az adatokat az eltérő sebességű tárolók között -- a granularitás ilyen határok közötti változtatása lehetőséget teremt az adatmozgatással járó felesleges többletterhelés minimalizálására.

Storwize V7000

Az IBM mellékel egy Storage Tier Advisor Tool nevű segédprogramot is a Storwize V7000 tárolóhoz, amely előzetesen feltérképezi az adatelérési mintázatokat és javaslatot tesz arra nézve, mekkora kapacitású rétegeket érdemes létrehozni, magyarán szólva mennyi SSD-t szükséges vásárolni a kívánt teljesítményhez. Így sok felesleges kiadás takarítható meg.

További információkért látogasson el weboldalunkra.

(Az IBM megbízásából készített anyag)

Hozzászólások

Sziasztok !
Benyovszky Balázs (BBenyovszky) és Grósz Attila (agrosz) vagyunk az IBM Magyarországi Kft. képviseletében.
Minden a cikkel kapcsolatos kérdésre, kommentre szívesen reagálunk.
...és a lehetőségeinkhez mérten megpróbáljuk ezt időben tenni...

helló!

jelentkezem, kérdeznék: aki egy ilyen storage megoldással kísérletezik, annak miért nem megfelelő tisztán ssd alapon dolgoznia, az említett optimalizációs folyamatokat kihagyva? magyarán egyszerűbb és teljesen stabilan nagy teljesítményű tárolóm lesz csak ssd-ből. a "megfizethetetlen" jelző annyiból tűnik erősnek, hogy a., akinek ilyen teljesítményoptimalizációra van szüksége egy IBM tárolóban, az nem biztos, hogy rá van erre szorulva (egyéb tárolókba szánt effektíve kis kapacitású "hagyományos" merevlemezek ára is veri a 100k-t nagyon sokszor, most kissé kibővítve gondolkodom más márkákat és akár _sokkal alacsonyabb_ osztályú eszközöket is képbe véve); b., az ssd-k ára nyilván nem lesz ilyen ár/érték arányon tartva a végtelenségig a diszkekkel szemben. javítsatok ki, ha tévedek.

egyébként az ötlet személy szerint tetszik, mármint az automatika (ha elég hatékony). ha lenne ilyenem, elsőre azért megpróbálnám kézzel szortírozni az adatok egy részét. nyilván nem TB méretről beszélek, de egy tesztre csak megpróbálkoznék vele még ha napokba is telne a rendszerezés. nyilván nem lennék szuperhatékony, de eredményt talán ?tudnék? elérni.

ui a leírt, 5%-on meghatározott adatmennyiség átmozgatása elsőre nekem hihetetlenül kevésnek tűnik. de próbálom elfogadni, úgyhogy most egy "tapasztalattal" talán vastagabb lettem. második bekezdést ez alapján írtam / kérdeztem.

köszönöm szépen, hali, kzs

--
Vége a dalnak, háború lesz...

Szia Kovi !

Egy teljes SSD –s storage rendszert csak nagyon Extrém esetben épít az ember (http://www.memristor.org/electronics/flash-storage/29/ibm-quicksilver-s… ; http://www.youtube.com/watch?v=2ykmZC-KG8M ) mivel önmagában nem tudja még lefedni egy gazdasági szervezet minden igényét.
Ebből természetesen csak az egyik tényező az, hogy az ilyen kategóriájú SSD lemezek ára kb. 30 szorosa egy hagyományos diszknek. Fontos információ az is, hogy az SSD eszközök csak bizonyos számú újraírást képesek elviselni (ez függ a típustól)

http://www.hwupgrade.it/articoli/storage/2531/ecc_grafico.gif

Ahogy az ábrából látható egy SLC típusú eszköz kb. 100.000 szer, a többi már csak kevesebbszer írható felül és a megbízhatósághoz is nagyobb hibajavítás szükséges.
A harmadik tényező pedig, hogy tipikusan a random, kis méretű, olvasási I/O műveletek futnak JELENTŐSEN jobban az SSD eszközökön.
Mindezek alapján jelenleg azok a megoldások terjedtek(nek) el a piacon, amelyek a fontos I/O műveletek válaszidejének csökkentésére és/vagy sebességnövelésére részben használnak SSD –ket. (ez minimum 3 db ilyen eszközt jelent a RAID védelem és a hotspare miatt – rendelkezésre állás miatt !)

Az árra vonatkozó jóslatod nagyon valószínűsíthető főleg ha az eddigi trendeket vesszük figyelembe. Természetesen tudni kell azt is, hogy egy nagy csomó kísérleti-szinten működő memória van letezik már, amelyek megbíhatóvá fejlesztése és tömeggyártása jelentősen megváltoztathatja ezt a képet. ( http://en.wikipedia.org/wiki/Non-volatile_memory )

A „kézi” és „gépi” adatmozgatás szembeállítása nekem mindíg a autó hasonlatot juttatja eszembe... ahol biztos, hogy egy tuning csapat ismerve az összes csavart jobban tudja hangolni a kocsit (gyújtásszög, szelepek stb.) mint a gyári „allround” beállítás, de a legtöbb eseben egészen jól muzsikál az is jobb kategóriás autóban. 

Hasonlatokat félretéve természetesen van lehetőség a manuális adatelosztásra a DS8000 –ben vagy a V7000 –ben is az automatikus ILM elhagyásával vagy amellett. Fontos megjegyezni viszont, hogy amíg a rendszergazda Logikai Volume –okat mozgat SSD –k és HDD-k között, addig az Easy Tier blokkokkal teszi ugyanezt. Tehát egy volume –on belül képes erre.

agrosz

"Fontos megjegyezni viszont, hogy amíg a rendszergazda Logikai Volume –okat mozgat SSD –k és HDD-k között, addig az Easy Tier blokkokkal teszi ugyanezt. Tehát egy volume –on belül képes erre."

Itt a kulcsa az egésznek, amitől baromi jó ez a technológia. Ha megnézünk pl. egy oracle adatbázist, ott egy-egy nagy méretű (16-32GB) adatbázis fájlon, vagy raw device-on belül csak az adatblokkok egy kis részére esik nagy IO, és az a bizonyos 5-10% -nyi forró blokk szépen eloszlik a pár terányi adatfájlon belül. Ezeknek az átmozgatását csak a storage rétegen belül lehet hatékonyan megoldani az operációs rendszer hatáskörén kívül.

A tároló eszközök fejlődésével elképzelhető, hogy a mostani méregdrága SSD-k idővel annyiba kerülnek mint most a jó minőségű SATA diszkek. Ekkor viszont az aktuális leggyorsabb eszközök szintén veszett drágák lesznek, és az igény továbbra is fennmarad a rétegzett tárolásra. (Mert ugye nyilván a felhasználási igények is nőnek mindíg is kell majd az elérhető leggyorsabb technológia.)

Egyébként a többrétegű tárolás nem újkeletű dolog (csak egyre jobb lesz), ha jól emlékszem 6-8 éve már tuti volt az IBM-nek a TSM-hez egy HSM (hierarchikus storage management) nevű kiterjesztése, ami fájl szinten mozgatott adatokat automatikusan másik storage-ra illetve szalagos tárakra. ( ugyan nem io terhelés függvényében, és sok megkötéssel és komprumisszummal, de az alapelv ugyanaz)

"Egyébként a többrétegű tárolás nem újkeletű dolog (csak egyre jobb lesz), ha jól emlékszem 6-8 éve már tuti volt az IBM-nek a TSM-hez egy HSM (hierarchikus storage management) nevű kiterjesztése, ami fájl szinten mozgatott adatokat automatikusan másik storage-ra illetve szalagos tárakra. ( ugyan nem io terhelés függvényében, és sok megkötéssel és komprumisszummal, de az alapelv ugyanaz)"

A felvetés nagyon is helyénvaló.
Ha az ILM vagy HSM szükségességét nézzük akkor az alapelv vagy az igény évek óta valóban nem változott.
Például az IBM AS/400 (iOS) eszközök már régóta egyben kezelik a diszket és a memóriát amelyek között már meglévő algoritmusok "lapozzák" az adatokat. Tehát van hová nyúlni a technológia storage implementációját illetően.

A Tivoli HSM (vagy Tivoli for Space Management) alapvetően egy különálló szoftver termék amely meglévő filesystem -ből tudja átmozgatni az adatokat szalagos eszközre (tape library) úgy, hogy csak egy pár KB -os "stub" marad bejegyzésként a könyvtárstruktúrában.

"Fontos információ az is, hogy az SSD eszközök csak bizonyos számú újraírást képesek elviselni"
-Nálam ez két év alatt 1%-ot "esett". (Tehát még 99 van..:). A tömb aktív használata mellett. Nincs szeparált temp, cache áthelyezés, etc..minden "innen" ment. A mostani új SSD-k esetében éppen ezért is emelték meg (némely gyártók) öt év minimumra a garanciális időt. Egyébként a technológia, ahogy itt már említették is (Az IBM technológia, nem az általam említett SSD) rendkívül vonzónak tűnik.

"elsőre azért megpróbálnám kézzel szortírozni az adatok egy részét."

Az ilyen storage-tiering technológiákat első sorban főleg a random IO esetén jó alkalmazni, leginkább OLTP adatbázisoknál.
Ezeknek a sajátossága, hogy az adatbázis IO mintázat szempontjából átmeneti jellegű, általában a legfrisebb adatok a "legforróbbak" (ezekre esik a legtöbb IO).
Vagyis az idő múlásával változik, hogy melyik blokkokat célszerű a gyorsabb háttértárra rakni.

Ha nincs automatizálva a mérés és mozgatás, akkor az adatbázis jellegétől függően akár 1-2 nap múlva is hatását vesztheti a tuning. Nyilván vannak ökölszabályok (pl. gyakori elérésű indexeket rakni az SSD-re), de az automatizálás biztosítja, hogy a lehető legoptimálisabban legyenek kihasználva az egyes tárolási rétegek.

Ráadásul pl. SSD, FC, SATA és egyéb diszk technológiák kombinálásával több rétegű storage is kialakítható, amivel a még optimálisabb ár/teljesítmény/tárolókapacitás is elérhető - ezt manuális adatrendezéssel szerintem lehetetlen megvalósítani.

"a leírt, 5%-on meghatározott adatmennyiség átmozgatása elsőre nekem hihetetlenül kevésnek tűnik. "

Ez erősen alkalmazás függő, de semmiképpen nem irreális. Más gyártók tesztjei alapján ez a bizonyos 5% valójában a "laboratóriumi adatbázisokban" 10-40% között változik, a valós alkalmazások esetében ez az érték inkább a tartomány elején van 10% körül. De természetesen itt is játszik az a dolog, hogy az adatbázisok IO mintázata időben változó képet mutat.

""megfizethetetlen" jelző annyiból tűnik erősnek, hogy a., akinek ilyen teljesítményoptimalizációra van szüksége egy IBM tárolóban, az nem biztos, hogy rá van erre szorulva"

Nagy adatmennyiséggel rendelkező cégek esetén az adattárolási költségek brutálisak (akár több 100 millió Ft is lehet egy egy nagyobb storage-projekt költségvetése. Ez, még egy kétszeres szorzó esetén is irreális lehet még a legnagyobb cég számára is.

DS 3xxx és DS4xxx tapasztalatunk van, a legkülönfélébb helyzetekben és kiépítésben. vélhetően az okozza a félreértést, hogy nem a legnagyobb volumenben gondolkozom: hiszen egy ilyen projekt full kiépítésben (teljes redundanciával, lemezekkel megtömve) is 10m alatt marad(t), amikor szállítottuk őket. anno azt hiszem pont Attiláéknál voltunk fejtágításon ezügyben.

--
Vége a dalnak, háború lesz...

zwei -nek tökéletesen igaza van az Enterprise projektek méretével és az SSD eszközök "pozícionálásával" kapcsolatban.

A DS3000 -es kategória a belépőszintet képviseli, amely nem mérhető össze rendelkezésre-állás, teljesítmény, skálázhatóság tekintetében egy nagyobb, összetettebb rendszer képességeivel és árával sem. (pl. DS8800 cluster) Természetesen nem minden helyzetben van erre szükség így jóval több esetben már egy kisebb kategóriás storage is elég az általad említett ár környékén.

Viszont ha már SSD akkor tudni kell azt is, hogy ilyen eszközök viszonylag nagy sávszélesség igényt támasztanak a storage -on belül, ezért jobbára csak midrange kategóriától felfelé lehet velük találkozni. Pl. a DS3000 -es kategóriában nincs is. Ott viszont ahol van egyáltalán nem mindegy, hogy MLC, E-MLC vagy netán SLC eszközökkel van dolgunk ugyanis tudásban és árban is jelentős különbség mutatkozik közöttük.

értem, de nem volt szó MLC/SLC különbségekről, én személy szerint spec egy egyszerű notiba se tennék MLC-t. az más kérdés, hogy az ára alapján nyilván van, aki kéri [mondjuk ezt úgy is fogalmazhattam volna, hogy kb mindenki]. tisztában vagyok az árbeli és technikai különbségekkel egyaránt, de a többször 100m nagyon soknak hallatja magát. de ha ti mondjátok elhiszem.

--
Vége a dalnak, háború lesz...

- Mi a helyzet az ún. deduplikációval? Van-e ilyen irányú tervezés?
- Esetleg az adatok röptömörítése is hasznos lenne. Várható-e ilyen funkció ebben az eszközben?
- Lesz-e 3 rétegű adatelosztás? (pl. SSD - gyors diszk - lassú diszk)
- Diszk-diszk között a gyakorlatban működik-e a "rétegzés" funkció? Ez miért nem támogatott?
- Működik-e az eszköz más gyártó SSD-jével?

    Deduplikáció:

jelenleg az IBM három különböző termékében jelenik meg a deduplikáció. Ezek: Tivoli Storage Manager (offline), nSeries (offline), Protectier (online). Az utóbbi a dedikált VTL megoldásunk, ahol szabadalommal védett algoritmus végzi az online deduplikációt. (hypervisor)
A technológiai megoldást tekintve tipikusan szekvenciális adatfolyamok helyigényének csökkentésére pocícionált ez az eljárás mint például az adatmentés (backup).

    Tömörítés:

Az IBM akvizíció során a tavalyi évben megvásárolt egy céget, amely a piacon egyedülálló tömörítési megoldással rendelkezett. Ezt jelenleg Real Time Compression Engine néven lehet elérni és az adatok "röptében" történő tömörítését oldja meg. A V7000 -eseben nincs implementálva jelenleg ez a funkció.... Viszont a kérdésre a válasz: igen. Tehát várható az eljárás megjelenése a diszkes megoldásainkban is.

    3 rétegű adatelosztás:

Három rétegű adatelosztás van. Jelenleg az IBM DS8000 legújabb kóddal ellátott rendszerei rendelkeznek ezzel a képességgel. (várhatóan az SVC ill. V7000 is örökli ezt a tulajdonságot)

    Diszk-Diszk rétegzés:

lásd. előző válasz. A rétegzés a I/O workload osztályozásával kezdődik és a használandó diszkek tulajdonságaihoz való illesztést kell megoldani az eljárás során. (pl. NL-SAS) Ezzel a résszel rendelkezik a DS8000 -ben futó kód, ám az SVC ill. V7000 implementáció még nem.

    Más gyártó SSD -je:

Röviden: nem. Csak az IBM által forgalmazott diszkek ill. SSD eszközöket támogatott használni bármelyik eszközünkben. Itt jegyezném meg azonban, hogy a diszkeket és az SSD eszközöket sem az IBM gyárja közvetlenül. Az SSD -k sok esetben például STEC termékek.