milyen All Flash Arrayt?

Szerverek

kivancsi vagyok, hogy ki, mekkorat, es miert hasznal - mar ha van barki es lesz egy komment is akar :-)

az egyik jovo evi terv a belso felhore egy kicsit felturbozni a flash storaget, es 50-200TB hasznalhato kozottit berakni, de meg nem dontottem veglegesen (nyilvan az IBM FlashSystem V9000R baromi jol nez ki)

Pure, Nimble es IBM kozott fog eldolni a dolog, valoszinuleg, de a 3PAR is eleg szexy :)

  • 3066 megtekintés

( hnsz2002 v | 2016. 12. 19., h – 09:56 )

27%-osat.
--
"Sose a gép a hülye."

Rákattintottam a linkre, és rá is kerestem. De még így sem lett egyértelmű, mert sehol nem volt leírva: AFA=All Flash Array.

Egyébként meg elolvasom azt is amit nem értek, épp azért hogy legalább tudjam az aktuális buzzwordoket. Ezért kérdeztem rá. Most már ezt is tudom, továbbállok. Köszi! :-)

( OxY | 2016. 12. 19., h – 19:31 )

Hitachi miért esett ki (már, ha kiesett)?

( AiRLAC v | 2016. 12. 20., k – 06:38 )

NetApp A700 vagy Solidfire :)

Szerk.: mi e kettő közül fogunk választani (vagy mindkettő, több projekt is van), most egy AFF8040 van általános használatra/QA-ra.

( freeoli v | 2016. 12. 20., k – 09:24 )

Felhasználástól függ. Ha csak a párhuzamos adat io magas száma a lényeg akkor akármilyen storage ssd-vel kitömve és meglepődsz. Még egy Dell MD is hihetetlen sebességekre képes.

EMC-t javaslok mindenképp.

Az IBM esetében sok rosszat tapasztaltam.
A 3PAR korlátozott supporttal rendelkezik.
A többinek Magyarországon korlátozott mindene.

SVC és Storwize esetében négymennyiségű bug jött elő de legfőképpen verzióátásások esetében és ráadásul már javított hibák is visszaköszöntek. Igaz az IBM megoldott mindent mindig még gari alatt vagy utána support keretében. Az IBM drága, nem a legjobb de amit vállalnak azt garantálják.

Nem tudom az EMC all-flash megoldásai milyenek. A sima VNX szériás SAN-okból kiindulva félek, hogy ezeknél is nagyon gyengére lehet szabva a kontroller (5400-nál 3 initiator már CPU-ban telíteni tud egy SP-t).
Viszont a stabilitására valóban nincs panasz.
---
Régóta vágyok én, az androidok mezonkincsére már!

( vavhab v | 2016. 12. 20., k – 15:47 )

Nalunk PURE van rendszeresitve, osszkapacitas ~500TB kornyeken.
Ugytudom elegedettek vagyunk vele, de mivel nem vagyok storage-es nem tudok storyzni tul sokat rola.

( szekelyk | 2016. 12. 20., k – 20:24 )

Dell EMC-től ezek vannak:
Unity F(ull Fash)-sorozat (300,400,500,600) hagyományos midrange kettő kontroller és fiókok
XtremIO Scale-Out 10,20,40TB méretű XBrick egységekből állhat. Egy Xbrick az kettő kontroller és egy fiók benne 25db SSD (400,800,1600GB), XBrick-ből max. 8 kapcsolható össze 80,160,320TB, a kapcsolódás Infinibanden történik
DDSD D5 na ez valami új állatfaj, Flash van benne de nem drive formátumban mint az előzőekben és az első kettőnél gyorsabb, de saját PCIe adapter kártyával direktben csatlakoznak rá a szerverek. Háromféle módon érhető el a tartalom, blokk üzemmód, Flood Direct Memory API, Plug-In ebből egy van Hadoophoz.

NAS-ból sem csak Manci néninek való van. A Dell EMC Isilon 50+PB-ig skálázható, scale-out az összeköttetés Infinibanden megy, és 2017 elején jön belőle a Full Flash. Protokollban SMB, NFS, Hadoop-ot beszél.

( asm v | 2016. 12. 20., k – 22:28 )

Ti nem belsos arral veszitek az IBM termekeket? Hiszen ugy mar annyira "olcsonak" kellene lennie, hogy fel sem merulhet a kulsos beszerzes.
Masreszt tobb okbol is furcsallnam, ha engednek egyaltalan. Mar irtad anno, hogy nalatok nagy a dontesi szabadsag, de ezuttal storage-rol van szo, ahol az IBM erosen nyomul (piacvezeto? flagship termekek?). Az esetleges kulsos beszerzesnek rendkivul negativ marketing uzenete lenne, ha kiderul (de hat megosztod blogon). A kivalasztott vendor salesesei ezt kemenyen kihasznalnak (ha nem is nyiltan, de csak az ugyfelnek megsugva, hogy "meg az IBM Research is a termekeinket vette, ahelyett hogy a sajat szarjaikkal bibelodnenek"). Szoval erted.

Most hogy jonnek (vagy mar itt vannak?) a 16TB-os SSD-k, egyre kisebb storage merettel elerheto a kivant kapacitas. A meglevo storage-ban nem tudod kicserelni nagyobbra a kis SSD-ket? Mar azzal tobbszorozheted a kapacitast, kerdes, hogy a kontrollerek mennyit birnak meg (nyilvan annak atlagos terheltseget meg tudod nezni)...

Egyebkent nem hyper-converged modban toljatok?

az arakrol abszolut semmit nem szandekozom nyilatkozni, sorry :) viszont mint minden Researchnek, a dolgom az, hogy megnezzem hol tart most az iparag; _ha_ (ami egy eleg nagy ha) van jobb a piacon, mint a mienk, akkor miert ne vennem azt, hogy aztan tanulhassunk a hibainkbol? :)

lentebb irta valaki az EMC DSSt, itt vicces, hogy egy nagyon hasonlo szabadalmat adtam be ra majdnem masfel eve, ami szinte teljesen hasonlo rendszert ir le (PCI-express kapcsolat halozat helyett, direkt attached flash a halozaton, RDMA, ...).

ennek ellenere egyre biztosabb, hogy IBM DeepFlash ESS lesz, ez 360TB netto tarterulet, Spectrum Scale + Sandisk InfinishFlash OEM lenyegeben, multhet pentektol lett GA.

a mostani storage Ceph, errol sokat bloggoltam, illetve ismernek a RedHatnel is, nem titok; illetve az sem titok, hogy vannak olyan IBM felho szolgaltatasink, ahol Ceph van a hatterben, es az en csapatom tervezte (meg neha nyujt L4 supportot). igy igazabol amin most megy a belso gondolkozas, hogy mi lenne ha a mostani clustert bovitenenk NVMe SSD-kkel, a halozatot meg vegre atraknank 100GbE-re (mar a kartyak bent vannak a storage gepekben, az optika a switchig is ki van huzva, csak egy ifup + IP cim valtozas kerdese, csak nem volt idonk megcsinalni...).

a fo problema nem a helykihasznalas, hanem van egy nagyon uj belso projektunk, aminek iszonyat rendszerigenye van (~400 mag elment csak DB2 ala ~4TB memoria melle), viszont egyelore nulla hasznalati grafikon, mert teljesen uj dolog, most epitjuk. igy hiaba raknek be nagyobb SSDket, ha kicsi az IO, vagy ha elfogy a hely... :)

a belso felho nem hyperconverged, viszont ha NVMeket veszunk, azok a computeokba mennenek (van egy x16 PCI-e slot szabadon, meg 1 NVMe/box elfogadhato CPU terheles lenne [100% IOhoz kb 10 mag kell])

Simán van benne ráció: kiderül valamilyen jópofaság a konkurenciánál, amit be kell nyomni a sajátba. Ehhez nyilván a saját terméket is kell ismerni (korlátaival együtt). Esetleg a saját értékesítőknek el lehet mondani, hogy miről kellene inkább hallgatni adott konkurencia esetén... (olcsóbb lehet, mint a fejlesztés :-) )

Ugyanakkor nyilván saját termék megtapasztalása révén is derülhetnek ki "fejlesztési lehetőségek".

Mi alapján lövitek be, mekkora tárolót vesztek, ha nem ismert a grafikon? Megveszitek a legerősebbet az adott családból? All-Flash tapasztalatom nincsen, de "hagyományos" tárolók között is hihetetlen különbségek vannak, marketing brosúrák és bemondás alapján lehetetlenség tisztán látni: nyúzni kell terhelés/funkcionalitás szempontból (ha nincs idő, ez nyilván nem opció), aztán prioritás alapján dönteni.

Ha jól értem kétféle architektúrán vagytok, a belső felhőn miért nem tértek át hyperconvergedre? Hyperconverged esetén mik a tapasztalatok a skálázódással, bővítéssel?

Hyperconverged architektúra nem jelent kisebb kockázatot teljesítmény korlát szempontjából? (azaz kisebb tárolót nem tudsz bővíteni, csak "kidobni", nagyobbat venni drágán, HC esetén pedig "csak" pakolsz mellé)

Bar nem nekem irod, de azert leirom a velemenyem.

Sok szempontbol mas a HC es kulso storage. HC-t en akkor alkalmaznek, ha (a belathato workloadhoz kepest) boseges az infra (magok szama, halozati savszel), ezaltal sporolni lehet vele. Mig kulso storage akar dedikalt fabricon mehet (pl. FC vagy masik eth), nagyobb workloadot is elbir, nyilvan joval dragabban. A ket use-case van annyira eltero, hogy aligha lehet csak ugy migralni az egyikrol a masikra. Egyebkent is ha mar egyszer beruhaztak kulso storage-ra, akkor az mar ugy veszett.

> "Hyperconverged architektúra nem jelent kisebb kockázatot teljesítmény korlát szempontjából?"
En pont a HC eseten erzem ezt problemanak. Ha kezd elfogyni a hely, akkor mi tevok legyunk?
- tegyunk tovabbi compute node-okat a clusterba? tovabbi magokra nincs szukseg, raadasul a license is draga lehet (VSAN esetben pl.)
- tegyunk diszkeket meglevo compute node-okba? ha csak nehanyba teszunk, akkor asszimetrikus lesz (ami nem feltetlen baj, de nem javallott), ha minden compute-ot egyforman bovitunk, akkor pedig nagy a lepcso
- Ceph limitjeivel nem vagyok tisztaban, de pl. VSAN eseteben max. 64 hosztbol allhat. Ha a compute-okba keves diszk megy, akkor aligha jon ossze nagy haznalhato kapacitas
Mig kulso storage eseteben csak beteszunk mondjuk +8 diszket es kesz. Mondjuk az a +8 diszk mocsok draga szokott lenni :/

A kérdésemnek előzménye egy korábbi rövid diskurzus, amikben kb pont ugyanezeket vetettem fel, ezért is kérdeztem rá, mert a leírtak alapján lehet mindkettővel tapasztalata. Nyilván nem "csakúgy" gondoltam migrálni, de ha valami jó, akkor egyszer el kell kezdeni kitűzve egy távolabbi célt. Ha beruháztak és kifutott (kinőtték, garancia/támogatottság), akkor másik kell, ezen kár keseregni.

Érdekes az az adata is, miszerint számításaik szerint 1 NVMe 10 magot leköt 100% I/O-hoz.
- 10 mag nyilván nem egy szerver vége manapság, de nekem arányaiban soknak tűnik, arányos-e ezzel terhelni a szervert? (és lekötni licenceket, nemcsak vSAN-ra gondolva, bár nagy méretekben a licencelés is másként zajlik)
- Ha egy lemezhez valóban ennyi mag kell, akkor jól meg kell nézni a tárolót, van-e benne elég szufla akár csak ~24 NVMe szolgáltatásához
- Miért kell 10 mag 100% I/O-hoz? Az oké, hogy gyors az NVMe, de milyen szoftver rétegen keresztül? Nem lehet, hogy lenne optimálisabb?

egyetertek, jo lenne nyilvan nyuzni kulonbozo vendorok cuccait, viszont ido, az nincs :) mit ertesz ketfajta architectura alatt? leirtam, hogy Ceph-en van a storage, kulon storage dobozokban. mi lenne a masodik?

a hyperconverged esetben a legnagyobb bajom, hogy a Ceph rendkivul CPU igenyes foleg ha NVMerol van szo (de akar sima SSD-kkel is), igy elenne a VMek elol a CPUt :(

barmilyen storage is lesz, mindenkepp kell scale-out, ez nem kerdes - sima, egydobozost (mindegy, hogy aktiv-aktiv a kontroller) semmit nem veszek mar.

( lberes (nem ellenőrzött) | 2016. 12. 21., sze – 10:13 )

3PAR-t nem ajanlom. Nekunk van par 8200-as, a support, illetve az engineering tragedia, osszevissza beszelnek (pl. javasoltak, hogy a linuxos XFS-eink blokkmeretet allitsuk 16 kB-ra).

Deduplikacio alig mukodik, HPE konkretan adott nekunk ajandekba disk shelfet, hogy meglegyen a szukseges kapacitas.

Egy helyen peer persistence van beallitva. Kertunk a supporttol egy step-by-step leirast, hogyan kell switchover/failover szituaciokat kezelni. Kaptunk egy hivatalos doksit, amit kovetve adatvesztesunk lett a tesztrendszeren.

--
L

nem opensource... Spectrum Scale fut rajta. de termeszetesen amint megjon, lesz pr0n - szerintem csinalok egy kicsomagolos YouTube videot, nem gondolom, hogy surun latnanak az emberek ilyet eloben

mellesleg a nagyteso a ketto kozul (512TB raw flash) lesz az altalam valaha kezelt legdragabb eszkoz.