Fujitsu DX200 S3 – középvállalati tárolóbajnok (x)

 ( hup | 2015. október 21., szerda - 13:56 )

A japán cég megoldása a teljesítmény, adatbiztonság és megfizethetőség egyedi kombinációját nyújtja. A tervezés során nem az egyedi hardveres kialakítás, hanem a standard felépítés mellett elérhető legmagasabb funkcionalitás volt a fő vezérelv.

A Fujitsu az ETERNUS DX S3 sorozatú, hibrid (flash és hagyományos lemezes meghajtókat kombináló) tárolókat tavaly év végén mutatta be. A kínálatban a hivatalosan kis-és középvállalatoknak szánt DX200 S3 az egyik legjobb ár/érték arányú modell. A cég ezt úgy érte el, hogy egyedi architektúra helyett nagyteljesítményű, de standard felépítés mellett döntött, így alacsonyan tudta tartani az árakat, miközben a sebességen és az üzemeltetés egyszerűségén nem esett csorba.

A teljesítményadatok a japán mérnököket igazolták, a tárológyártók által életre hívott Storage Performance Council szervezet SPC-1 benchmarkjában a DX200 S3 all-flash kiépítésben (28 db 400 gigabájtos meghajtót használva) 200 ezer IOPS felett teljesített az eszköz - pár éve ezt a teljesítményszintet a csúcskategóriás diszkes tárolók hozták csak. A cég a berendezést elsősorban a nagy IO-igényű alkalmazások alá ajánlja - tipikusan ilyenek a virtualizált környezetek, a nagymennyiségű adaton végzett analitika, illetve a klasszikus értelemben vett vállalati informatikán kívül a mérnöki-tudományos feladatok.

A tároló minden alkatrésze redundáns, üzem közben cserélhető (kontrollerek, tápegységek, ventilátorok, stb). A DX200 S3 legfeljebb 264 meghajtóig bővíthető (és mindegyik lehet SSD), a fiókok egyenként 24 meghajtót képesek fogadni, a maximális tárolókapacitás 1584 terabájt lehet. A tároló egy vagy két kontrolleres kiépítésben is rendelhető, és természetesen utólag is bővíthető a kétvezérlős opcióra. Az eszköz 12 Gbps SAS interfész segítségével próbálja meg elérni, hogy ne legyen a belső adatutakon "forgalmi dugó", a külső csatlakozás pedig 16 Gbps FC, 10 Gbps FCoE vagy 10 Gb Ethernet lehet.

Mivel a modellben szabadon keverhetőek a flash és merevlemezes tárolók, értelemszerűen lehetőség van a tieringre is, ami lehet manuális vagy akár automata is. A storage tiering, vagy tárolórétegzés logikája egyszerű, de hatékony: egy modern tárolóban változatos sebességű, kapacitású, késleltetésű, árú egységek vannak, ezek közül a szoftver választja ki, hogy milyen adat milyen meghajtóra kerül. Így más rétegre kerülnek a biztonsági mentések, a céges dokumentumok és az adatbázisok, attól függően, azokra milyen gyakran és/vagy milyen céllal van szükség.

Az ETERNUS DX200 S3 fontos jellemzője, hogy a többi ETERNUS DX-sorozatú tárolóval azonos felépítésű és a szoftverezettsége is azonos, így az üzemeltetőknek nem szükséges semmit újratanulni, új felületeket vagy felügyeleti rendszerek kezelését elsajátítani. Támogatott a thin provisioning (vagyis a tényleges kapacitás logikai túlfoglalása), a beérkező adatok on-the-fly, a szerverek számára teljesen transzparens módon történő titkosítása (AES-128 vagy AES-256 használatával), a konszolidált adatközponti szemléletben nélkülözhetetlen alkalmazáspriorizálást (QoS, Quality of Service). A DX200 S3 SAN-ként (Storage Area Network) és SAN NAS-ként (Network Attached Storage) is használható - utóbbi opcionális, de utólag is kérhető.

Klaszterezés az adatbiztonságért

Van, amikor a "szimpla" biztonsági mentés nem elég, és az üzleti kritikus folyamatok az elsődleges tároló kiesése (például hardveres meghibásodás vagy áramszünet miatt) esetén sem állhatnak le a hiba elhárításáig. Az ETERNUS DX200 S3 erre a tárolóklaszterezés (storage clustering) által nyújt megoldást.

Így egy második tároló és egy klasztervezérlő beiktatásával valós idejű adattükrözés valósítható meg úgy, hogy az adattükrözés során megmaradnak a beállított szolgáltatási szintek (QoS, quality of service) és tárolórétegek (storage tiering). A szükség esetén automatikusan végrehajtott failover (feladatátvétel) az alkalmazások számára teljesen transzparens módon történik, utólagos manuális beállításmódosításra (például elérési útvonalak) egyáltalán nincs szükség az elsődleges tároló helyreállása esetén a failback hasonló módon megy végbe. Természetesen ezeket a folyamatokat manuálisan is el lehet indítani (például tesztelés vagy karbantartás miatt).

A valós idejű tükrözésre legfeljebb 10 ms válaszidő (RTT) mellett van lehetőség, efelett aszinkron, késleltetett tükrözés valósítható meg, automata failover nélkül. Ha a költséghatékonyság fontos, a klaszterkontroller virtuális gépként, dedikált hardver nélkül is üzemeltethető.

(A Fujitsu Technology Solutions Kft. megbízásából készített anyag.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Remek-remek...

A kontrollerek milyen blokkméret mellet mennyi IOPS terhelést bírnak, mikor válnak szűk keresztmetszetté? Csak mert az oké, hogy 28 db SSD-ből kihoznak 200 ezer IOPS-ot és ezt még elviszik a kontrollerek, de ha berakok 264 db SSD-t a szerkentyűbe, az már majd' 2 millió IOPS, ami nem sok kontrollernek megy a piacon.

Továbbá mi a bővítés "alapegysége", ami még értelmesen használható? Ha teszek bele +1 db hagyományos HDD-t, akkor azt használatba tudom venni? "Elkeni" rá az adatot az eszköz, hogy jól ki lehessen használni a még egy tengelyből származó előnyöket? Vagy mindenképpen polcnyi bővítéseket kell csinálni, ahol a polcon belüli diszkeket RAID5-be kell tenni és soha többé nem lehet változtatni majd a tömbben lévő diszkek számát?

Nekem még első generációs DX80-am van a kezeim között. A beszerzésnél fontos szempont volt, hogy akár 1-1 diszkkel is lehessen bővíteni és ő tudja. Természetesen adott RAID leveltől is nagyban függ, hogy mennyi diszkkel lehet minimálisan bővíteni. :)

Remélem ezen a remek tulajdonságuk még megvan.

A DX200 azért egy marhára izmos cucc (árban is). Nézd meg a DX100-at úgy indulásképp szerintem. :)

Három DX80-asom van, abból az egyik olyan mint a tiéd (ha jól emlékszem iSCSI-t vettél tőlünk), van egy iSCSI DX80 S2-m, illetve egy FC-s DX80 S2-m.

A legrégebbi 5 éves, eddig összesen 1 diszk pusztult el a 3-ban. Én szeretem ezeket a storage-okat.

--
trey @ gépház

Bizony, ájszkázis. :) Itt voltak a 600-as diszkekből (12db fut) kiesők, talán 2db, de mivel garis meg kopóalkatrész ezért nem tartom problémásnak.

Nekem az a jön benne, hogy ilyen justworks. Remekül túlélte az árvízes áramszünetet, aggregátorról járatást meg mindent. :)

Elég stabil OS van benne:

trey@alderaan:/tmp$ strings no1_V10L60-0000.bin | grep VxWorks
VxWorks SNMPv1/v2c Agent
VxWorks
VxWorks 6.7
[...]

--
trey @ gépház

Ja, nem kell nekem ilyen storage :-)

Tavaly év vége felé tesztelgettem két DX200-at és működött normálisan, de úgy tűnt, hogy egy generációval butább, mint a többiek, nincs koncepciója pl. a chinkletekről meg ilyenek. A menedzsmentje egy borzalom volt a többiekhez képest, az IBM és a HP is alaposan verte egyszerűségben.

Cserébe kicsit nagyobb teljesítményt lehetett kihozni belőle, mint a többiekből, elsősorban azért, mert 15k RPM-es lemezek voltak benne, a többiekében pedig inkább 10k RPM-esek. De nem tudom, hogy hol van a skálázódás vége, mert csak valami 100 diszkem volt, az meg kevés volt ahhoz, hogy kiüsse a kontrollereket...

Mik voltak az összehasonlítási alapok IBM és HP oldalon?

--
trey @ gépház

Kérdésekből ítélve 3Par és StoreWize.

V7000 és 3PAR.

A storwize következő verziója a gui-n már az emoji konfig paramétereket is támogatni fogja :D International Bug Machine, sajnos a gui-t látják sokan, nem a lényeget.

Utána olvastam és az chunklet. Cikk: http://www.vology.com/blog/technology-categories/storage/whats-a-chunklet-the-tech-behind-hps-storeserv-storage-suite/

A magam részéről így elsőre ezt nemnagyon látom, hogy a valós felhasználásban ez hogy segít. Ok lesz csillió ilyen 1GB-os darabom, de mégiscsak sokkal véges számú diszken fognak elterülni.

Az IBM XIV is igy mukodik. (Ezt ismerem, ez alapjan irom a tovabbiakat)
Sok elonye van:
- egy LUN letrehozasakor random modon valasztodnak ki a chunkletek, igy lenyegeben minden LUN az osszes diszkre stripe-olodik
- ujabb diszkpolcok hozzaadasaval(/elvetelevel) automatikusan ujrarendezodnek a chunkletek, hogy mindenhol egyenletes legyen a foglaltsag/terheles -> nem alakulnak ki hotspotok, minden komponens reszt vesz a magas teljesitmeny eleresehez
- nincsennek spare diszkek, hanem minden diszken fenntart annyi helyet, hogy akar egy diszkpolc kiesesekor is legyen hova potolni az elveszett chunkletek mirror parjait
- diszk kieses eseten nagyon gyors a "rebuilding", mivel sok diszkrol masolodik adat szinten sok diszkre. Telitettsegtol fuggoen akar 10-20-30 perc alatt is vegezhet.
Lenyegeben egy hatranya van:
- minden chunkletnek van egy mirrorozott parja, igy az osszkapacitasnak csak a fele hasznosithato (mint RAID10-nel).

A 3PAR esetében nem feltétlenül van minden chunkletnek mirrorozott párja. Ha mondjuk 3 adat + 1 paritás konfigurációjú RAID5-öt használsz, akkor az 4 chunklet, aminél annyi a plusz megkötés, hogy 4 különböző diszken (vagy polc redundancia biztosítása esetén 4 különböző polcon) legyen tárolva a 4 adat. Így is lehet. A hátrány nyilván az, hogy a rebuild több olvasást igényel.

Tulajdonképpen nem vagyok benne biztos, hogy ezzel a megoldással jó dolog továbbra is a "hagyományos" RAID szintekben gondolkodni - értelmesebbnek tartanám azt, hogy meg lehessen mondani, hogy hány példányban akarod tárolni az adatot és hány paritást akarsz hozzá, valamint milyen "egyszerre elromló elemekre" (diszk, polc) akarsz készülni.

EMC Isilon pont igy mukodik, bar az csak NAS-t tud... (marmint, hogy megmondhatod akar fileonkent is, hogy hany peldany, mennyi paritas, hany elem - diszk, node - romolhat el egyszerre)

Ok, rendben így már világos. Hazai viszonylatban szerintem nagyon kevesek kerülnek érdemben ekkora léptékhez közel... :)

A HP EVA-k (Enterprise Virtual Array) már 10 éve is tudtak ilyesmit. EVA meg elég sok helyen volt annak idején. Viszont szerintem a DX200 nem az erre a szintre van pozicionálva.

--
trey @ gépház

Tudom, hogy chunklet, de mire észrevettem, hogy chinkletet írtam, már válaszolt valaki a kommentre. :-(

Amiben segít a dolog, az a rugalmasság.

Ha előre tudod, hogy 2 polc diszkre lesz szükséged, az egyikre RAID1-ben, a másikra RAID5-ben, készen vagy, a következő 123 évben nem kell hozzányúlni, akkor ez felesleges bonyolítás, és még 1-2% teljesítményt is veszthetsz rajta, ördögtől való a dolog, jajj.

De ha nem ennyire határozottak az igények, ha 30 alkalmazás alá 50-féle konfigurációban kell diszket adnod, ha menet közben 13x meg kell gondolnod magad, hogy a sebesség miatt RAID1-ben vagy a hely miatt RAID5-be akarod kiosztani a tárterületet, akkor előnyös, hogy ezeket nagyon könnyen tudod egymásba alakítgatni.

Egy kis ízelítő a tesztből.
http://www.storageperformance.org/benchmark_results_files/SPC-1/Fujitsu/A00139_Fujitsu_DX200-S3/a00139_Fujitsu_DX200-S3_SPC-1_executive-summary.pdf
A részletek a full disclosure reportban vannak.
Az szerintem biztos, hogy 264 darab SSD nonszensz, mivel valahol valami szűk keresztmetszet lesz, ez egy belépő szintű storage. Annak persze jó lehet.

Az SSD tesztről, a tesztelt konfig 154k USD, ami nem kevés, pláne nem belépő szint. Ebben 29 db SSD meghajtó szerepel.
Ez 11600GB kapacitás, amiből a teszt során használtak 3280GB-ot (28,28%). A védelem mirror volt.
Ennél azért már előbbre tartanak a korszerű flash tárolók RAID5 vagy valamilyen paritásos védelem mellett tudnak ilyen teljesítményt felmutatni, a védelem miatt
nagyobb elérhető netto kapacitással. Esetleg még tömörítés és deduplikáció is segíti a flash jobb kihasználását.

Szerintem az egy érdekes koncepció, mindenképpen érdekes a sztori. Kompetitív anyagokban erről is le tudják szedni a keresztvizet, mert mindennek ára van.
Tudom, hogy kicsit mást írok, de nem tudok alma-alma összehasonlítást adni.
A Chunkletnél nem akarod megkapni azt a kompromisszumot, hogy ezeket most R10-be, azokat R5-be szerveztem. Vsz ezt azért teszed, hogy tudj valami jó IOPS-ot adni.
A DX-ekben van az automatikus tiering, ami 242MB-os blokkokkal dolgozik. Ha csinálsz egy tiering képes volume-ot, akkor hasonló célt tudsz elérni. Beledobálsz diszkeket egy poolba és arra rakod rá a volume-ot, egyik része így van védve, másik úgy. Még 1x: nem pont ugyanaz, de a végeredmény hasonló lesz.

---

Pulai András, Consultant, Fujitsu

A "chunklet"-es felépítés és az autotiering nem zárja ki egymást, lásd 3PAR.
Azért az autotiering attól függően jelent megoldást, hogy az optimalizáló algoritmus a valós produktív felhasználásnak megfelelően pakolja a blokkokat.

A tiering arról szól, hogy a különböző LUN darabok "chunklet" a nekik megfelelő tier-en vannak. A kontroller statisztika alapján figyeli melyiknek hol a helye és átrakja, vagy valós időben, vagy ütemezetten egy arra kijelölt időszakban. Aminek nagy IO igénye van az SSD, a kisebb igényű SAS (10,15k), a legalacsonyabb pedig az NL-SAS(7,2k). A teljesítményigény és az eltérő diszkek miatt az egyes tier-ek védelme eltérő. Pl. SSD RAID5, SAS réteg RAID5 vagy RAID10, NL-SAS RAID6 (szigorúan). Így valóban előáll az a helyzet, hogy a LUN egyik darabja RAID6 a másik RAID10 a harmadik pedig RAID5 védelem alatt áll. Az adott védelem azonban az adott szintnek megfelelő.

Szia Zizi!
A bővítés tényleg akár 1 diszkkel is történhet és tényleg bármely pozícióba tehetsz SSD-t.
Hogy mennyi IOPS-ot bír el az változó, erre van egy méretező eszközünk. A blokk mérettel az írási és olvasási cache arányának állításával, a diszk darabszámmal, az addicionális szolgáltatások ki bekapcsolásával kell játszani.
Persze a legtöbb IOPS 4KB-os blokkokkal jön össze, itt is lehet játszani az elvárt válaszidővel. Ha nagyobbra veszem még feljebb kúszik az IOPS. Az SPC Bencmarkokban a DX200-asról publikált eredményeknél 0,63 válaszidőt mértek 200.000 IOPS mellett. Itt nagyon fontos, hogy a magas IOPS mellett teljesen alacsony maradt a válaszidő.
Ha meg nagyobb blokkokkal kezdek el dolgozni, akkor a MB/s értékeket tudom „növelni”.
Szerintem a DX200-nak kb itt 200.000 IOPS körül van a vége. Érdekes az is, hogy itthon a 200.000 IOPS akár egy nagyvállalatnak is elég.

---

Pulai András, Fujitsu

Sziasztok, Pulai András vagyok a Fujitsutól, igyekszem a felmerült kérdésekre válaszolni.

Szia!

Fentebb tettem néhány észrevételt a tesztel kapcsolatban.
11600GB kapacitásból, 3280GB volt használt a teszt során. Ennek okáról tudsz valamit mondani?
Volt olyan teszt ahol a kiosztott kapacitás megközelítette a teljes kapacitást?
Volt paritásos védelemmel végzett teszt? Pl. RAID5 a jobb helykihasználás miatt?
A Full Disclosure report nyilvánosan elérhető, mert csak a linkelt kivonatot találtam.