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.)
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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?
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Mik voltak az összehasonlítási alapok IBM és HP oldalon?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Kérdésekből ítélve 3Par és StoreWize.
- A hozzászóláshoz be kell jelentkezni
V7000 és 3PAR.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Utána olvastam és az chunklet. Cikk: http://www.vology.com/blog/technology-categories/storage/whats-a-chunkl…
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Ok, rendben így már világos. Hazai viszonylatban szerintem nagyon kevesek kerülnek érdemben ekkora léptékhez közel... :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egy kis ízelítő a tesztből.
http://www.storageperformance.org/benchmark_results_files/SPC-1/Fujitsu…
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Sziasztok, Pulai András vagyok a Fujitsutól, igyekszem a felmerült kérdésekre válaszolni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni