SAN/NAS szerver kerestetik

Hálózati eszközök

Hali!

Workgroup kornyezetbe keresek SAN/NAS szervert, elso sorban virtualizaciohoz.
Ami must have:
- iSCSI/NFS
- 1G ethernet
- dedupe, snaphots
- SATA es SAS disk support
- SSD support
- StorageLink es vSphere Storage API support
- dual controller, dual tap
- korekt gari, support (next day replacement a min.)
Ami nice to have:
- SMB/CIFS
- gyari backup plugin
- tiered storage
- upgrade lehetoseg (replication, HA/DR, 10G ethernet etc)
Diskek nelkul a max. 2 millas kategoriaban gondolkozom.

Ami erdekelne, az altalanos jotanacsokon/otleteken kivul, ha van valakinek hands-on tapasztalata hasonlo vasakkal. Privibe akar arajanlatok is johetnek :-)
Ami most nem jatszik, az a rakd ossze/telepitsd fel/SOHO kategoria.

Elore is koszonom!

PS: amiket eddig neztem az a Fujitsu Eternus DX80 es a NetApp FAS2000 sorozat

  • 4149 megtekintés

( mauzi v | 2012. 02. 02., cs – 18:58 )

A leírás alapján tényleg nem SOHO eszközt keresel, de akkor meg mit keres a leírásban az NAS, főleg az SMB?

Ha kell SMB, akkor úgyis kell Windows Server...

( n.balazs v | 2012. 02. 02., cs – 19:18 )

Tapasztalatom alapján az EMC termékeit tudom javasolni. Kellően konfigurálhatóak(FC és iSCSI alapkiépítésben), platformfüggetlenek, bővíthetőség. IBM se rossz, de itt külön licencet kell venni minden storage-ra csatlakozó géphez. Továbbá IBM szereti az EMC-nél alapfunkciónak számító tulajdonságokat külön pénzért adni. Szóba jöhet még Netapp, bár náluk a NAS funkciók az erősebbek - régi információ, biztos javultak már SAN-ban is.
Privátban küldtem is elérhetőséget.

( asm v | 2012. 02. 02., cs – 19:42 )

Szerintem 10G ethernetes, dedupos NAS aligha kaphato 2 milla alatt.

( zwei | 2012. 02. 02., cs – 21:02 )

"elso sorban virtualizaciohoz .... iSCSI/NFS/SMB"

Most virtualizáció, vagy SMB?
SMB-t az ún. hibrid storage-ok tudnak, amikben valamilyen file rendszer szokott lenni.
Ez esetben figyelni kell, mert van olyan termék, ami deduposnak hirdeti magát, valójában a dedup benne file szintű, vagyis blokkdeviceként (iscsi) nem tud dedupot.
Ha első sorban virtualizálásra kell blokk storage-nek (iscsi), akkor sztem. tartsd magad távol a SMB/CIFS megoldásoktól. (Ha NFS-en vagy CIFS-en akarod tárolni a vdi-ket, az más tészta.)
A dedup ebben az árkategóriában (ha egyáltalán van), az offline, vagyis az adatok eltárolása után egy automata, vagy kézzel indított job végzi (és ilyenkor leesik a teljesítmény) .PL NEtapp FAS2000-as széria
Ha nincs dedupra időablak, akkor nem sokat érsz vele.
A Sun unified storage cuccok (most nem tudom milyen néven, milyen árban futnak), asszem ZFS alapúak, és tudnak online dedupot

"- 1G/10G ethernet"

Nem biztos,hogy akarsz 10G Ethernetet. Sok esetben még 1Gbe-n sem lehet kifektetni egy ilyen kategóriás storage-ot.
MEg kell nézni a csatolandó szerverek jellegzetes IO mintáit.
Adatbázis, mail szervereknél a random IO dominál 8k blokkméret környékén.
Egy 1Gbe linken 9000-es MTU-val (jumbo frame) jó esetben 14 000 iops-ot lehet küldeni.
Egy duál aktív/aktív kontrollert 2x1Gb-n meg tudsz tolni majdnem 25k+ iops-al. (~240 MB/sec 8k/s random IO esetén)
Ezt a teljesítményt durván 135 darab15000RPM-es SAS diszk tudja folyamatos terhelés mellett szolgáltatni. (És ezt is csak akkor, ha read io, write esetén még nem beszéltünk a mindenféle raid tipusoknál fellépő write penaltyról.)

"tiered storage"
Ha automatikus storage tieringre gondolsz ( a háttérben magától pakolássza az adatokat a különféle diszktipusok között), akkor asszem pl. az EMC VNX -e ebbe a kategóriában van, és tud ilyet.

Koszi az infot.
SMB/CIFS-rol irtam feljebb.
Dedupe blokk szintu kellene legyen, de mivel elso sorban a VM-ekre kellene, nem igazan problema ha offline. Viszont a FAS2000-nel ha jol ertettem a doksit snaphotokat nem dedupe-olja, ami azert problemas lehet.
SUN cuccok nem igazan ez az arkategoria sajnos :-(

"SMB/CIFS-rol irtam feljebb"

A válaszom eleje és vége között eltelt egy vacsora. :) Utólag láttam, hogy módosítottál, de már nem akartam törölni.

FAS2000-es széria elég jó.
Viszont tényleg nézd meg a host IO-kat, és aszerint méretezd a diszkeket bele, mert abból elég nagy szívás tud lenni, hogy kitömi valaki 12x1T 7200rpm SATA-val a storage-ot, aztán meg csak pislog, mikor túró teljesítmény sincs mögötte. (konkértan láttam 1-2 napja valami fórumban emiatt nyafogni valakit.)

A snapshotokat szerintem nem érdemes túl sokáig tárolgatni (snapshot != biztonsági mentés vagy archivum) , leginkább patchelések idején érdemes használni. Ha túl sokat változik a VM, akkor elég gyorsan fogyasztják a helyet a snapshotok.

Sehogy, elcsesztem, 135 diszk még ennyit sem tud:

Egyébként:

1 darab 15Krpm SAS diszk kb. 185 IOPS-ot tud.
Ez 8k-s blokkméret esetén: 1480Kb/sec
135 diszk raid0 (stripe) esetén ez: kb 195MB/sec (teljesen random IO esetén, write ordering meg minden trükk nélkül kb. nyers elméleti iops - valós életben max. csak az egyes jbod konfigok összehasonlítására jó.)

Eredetileg 9k-val számoltam, ami jumbo frame esetén jó közelítéssel 8k host io+overhead. Így kijön a 220mb.

Viszont a storage diszkeken nem jelentkezik mind a 9k, csak durván 8k.

A konkrét számoknak valós élethez csak annyi köze van, hogy gbit-es iSCSI esetén az olyan környezetekben, ahol kiss blokkméretű random IO teljesítmény számít, nem biztos, hogy az iSCSI vonal lesz a szűk keresztmetszet, hanem inkább a storage processzor és a diszkek.

Nagy blokkméretű szekvenciális io esetén az iscsi 1 Gbit-en valóban gyér.

A 185 IOPS érték megítélését annyiban módosítanám, hogy, ez egy méretezési érték. Tehát az említett diszk szélsőségesen random esetben maximum ennyit tud teljesíteni, ezért ezzel illik méretezni, ha fontos a válaszidő.

De a valós életben ha kaphat ettől ideálisabb terhelést is akkor ennél jobban teljesít.

pontosan.
És mivel próbálok write iops-ra optimalizálni, ezért az egyes storage-okban használt raid implemetáció worst-case -ét próbálom alapul venni az összehasonlításkor.

Ami nem a legjobb megközelítés, mert a FAS2040-ben a jó teljesítmény nem (csak) a diszkeken múlik, hanem főleg az elég nagy kontroller cache-en és az optimalizálási algoritmusain.
Innentől kezdve az én megközelítésem a FAS2040 12x SATA, vs Emc AX4 12x SAS probléma körben használhatatlan. :)

Az abszolute megalapozott döntéshez vagy mérni kéne vagy feldobni egy pénzérmét. :)

( kisauto | 2012. 02. 02., cs – 21:17 )

megin leirom hogy a FAS2000 jo.. aztan valaki ugyis megin jon egy TPLink + Pentium1 + USB vinyo es Ubuntuval :)

oh, rá lehet kattani rendesen.

nem tetszik: az éppen akciós FAS2000 sorozat kivételével drága
nem tetszik: raid group limitek (max 28 diszk)
nem tetszik: kis kiépítés esetén nyügvenyelős a diszkek kiosztása, ugyanis minden kontrollerhez kötelezően tartozik legalább egy raid, tehát a kicsike (12 diszkes) kiszerelést is ketté kell szabni. Mondjuk ez egy nagy rendszernél nem érezhető hátrány.
tetszik: minden más ;)

Ha neked van egy fileszervered, (cifs) és néhány VM-ed, amiket iscsi-vel táplálnál, akkor elég unikális megoldásokat tud.
Kedvencem, hogy a CIFS shere-ben a gyökér '.snapshot' könyvtárában ott figyel (ha akarod) a tegnapi, tegnapelötti, egy órás, stb állapot, a bolond user magának tudja visszaemelni a véletlen törlés áldozatát.

pár ilyet üzemeltetek, pár ilyet üzemeltetnek a kollégáim, ha FAS-t veszel, ingyen adunk hozzá munin grafikonrajzoló scripteket :-)

Hmm...
Szóval javíts ki ha tévedek, de ezek szerint a kicsike (12 diszkes) kiszerelés esetén 4 diszknyi kapacitás ugrik? Ha jól tudom a netapp RAID-DP -je 2 paritás diszket használ tömbönként, így 2 tömb esetén 4 diszk kapacitása megy a levesbe(paritásba)?

Ja igen, az már elég régóta érdekel, hogy mi igaz abból, hogy a RAID-DP write-penalty-ja a 2-eshez közelít? Valóban tudja ezt tartós terhelés esetén is?

Igen, a kicsike diszk-vesztesége elég idegesítő.
Viszont árban, teljesítményben rendben van.
Nagyjából 60% kapacitást lehet belőle kiszedni, nagyjából akkora performanciával, mint egy buta eszközben ugyanennyi diszk RAID10 -ben lenne. Szóval ár/kapacitás ár/teljesítmény arányban jó.

nem tudom, mi az a "write-penalty-ja 2-es". A DataOnTap -ben a raid layer és a LVM layer és a filesystem layer egy; emiatt nem lehet önmagában a raid_dp -ről beszélni, hanem inkább a 'raid_dp+wafl' teljesítményéről lehet beszélni.
Ha betartod a bűvös "10% hely maradjon mindíg üresen" szabályt, akkor hosszú távon is kiválló a random írási teljesítménye. Olvasásra az n diszkes raid_dp az (n-2)*egydiszk teljesíményt ad, random írásra a FAS minden mért esetben gyorsabb! mint random olvasásra. Ez azért sokkal-sokkal több, mint egy szokásosabb raid6 implementáció random írási tudása.

"write-penalty-ja 2-es"

Write penalty: 1 host írási IO művelet a storage backenden hány io művelettel jár. Asszem szokták még raid overheadként is emlegetni, mert az adott raid implementáció függvénye.

Pl:
Raid 10 írási iops: egydiszk*n/2 vagyis egy host IO egyszerre két diszkre íródik, így az írási iops teljesítmény pont a fele mintha raid 0 (stripe) lenne.

Raid 5 írás iops: egdiszk*n/4 = write penalty 4
Vagis egy host írási io: 1 adat és egy paritás beolvasása, majd 1 adat és 1 paritás írása. Így a raid0-hoz képest 4-szer lasabb a raid 5 írás.

Ezek ugye tisztán elméleti számok, mindenféle optimalizálásokkal a normálisabb storage-ok szoktak trükközni, hogy minnél kisebb legyen az írási bünti....

"random írásra a FAS minden mért esetben gyorsabb! mint random olvasásra"

Ok, erre voltam kiváncsi.
Gondolom azért, mert viszonylag nagy a controller cache-e, így valós felhasználási esetekben elég jó hatásfokkal lehet mindenféle write orderinget csinálni, meg teljes stripe-okat írni, így a backenden már szekvenciálisabb jelleget mutat a random host io.

Teljesen random olvasáskor meg a read-ahead nem működik, marad a valós "nyers" random diszk io teljesítmény.

a raid-dp az egy opcio, de lehet akar raid1 -is.
attol fugg, neked mennyire fontos az adat :)

a write-penaltynak utanna nezek ( erdekel... ) de azert az OnTap felepitese ennel 'bonyolultabb'.
Szoval a bejovo iras muvelet eloszor belemegy egy nvramba ( wafl ), es majd utanna a lemezekre. A "felhasznaloi elmeny" pedig nem veszi eszre, hogy most raid1, es 2 lemezre ir, vagy raid4dp es 4 lemez teker.
A masik, ami mondjuk 2000-el nem lehetseges, de felette igen, a remote replikacio. Azaz hatul osszedrotozod uveggel egy masik hasonloval es ( metro clusterkent ) replikalnak. Ugye itt sem veszed eszre, hogy nem 4, hanem mar 8 lemezt ir, 2 raid groupban, 2 plexen, usw...

csak azért kérdeztem a write penalty dolgot, mert a netapp nagyon marketingeli, hogy a RAID-DP a kétparitásos felépítés ellenére RAID10-el közel egyező írási IOPs-ra képes.

Mivel gőzöm sincs, hogy pontosan mi a RAID-DP algoritmusa azt valószínűsítem, hogy a controller cache és a hozzáadott inteligencia miatt a backenden már erősen szekvenciális a host oldali random io, emiatt tényleg jól tudja nyelni az adatot.

Egészen addig, amíg órákig tolják full random IO-val, ami a csövön csak befér. Vagy nem. Ezért kérdeztem, hogy a valóságban is tudja -e azt, amit a netappos marketingesek hajtogatnak.

"azert az OnTap felepitese ennel 'bonyolultabb'"
Ontap vagy flareos, vagy.... . Ezek a storage cuccok pont azért tudnak kicsit többet egy jbod-nál mert van bennük egy kis plusz. :)
Pont az érdekel, hogy a Netapp-ban a "plusz" mennyire tudja kihozni a diszkekből a maximumot.

A legtöbbet egy EMC által írt összehasonlító tesztből tanultam.
Kiválló munkát végeztek az EMC mérnökei, mire megtalálták azt a környezeti rendszert, amiben belezavarhato a dataontap az write-reorderingbe, és a belső fragmentáció megeszi a teljesítményt.

Tanulság:
Hagyj 10% üres helyet, és akkor nem fragmentál be, és gyors marad.

Abban a tesztben abszolult 100%-ban kitömték az összes nettó helyet, és a példa exchange szerver nonstop teljes terheléssel ment, nehogy a dataontap ráérő idejében defregmentálni tudja magat. Így is beletelt 3 nap, mire az ugyanannyi diszkes calriion teljesítménye alá esett a FAS. (ezek ~100 diszkes rendszerek voltak)

Mérhető teljesíményvesztés, a frissen készített raid group (aggregate) nyers rnd wr teljesíménye 3%-4% -ot esik viszonylag hamar masszív terhelésél. De, ha van 10% szabad hely rajta, akkor igazából nem romlik tovább, végig megmarad nagyon jónak.

Van még egykét trükk, pl. a degraded raid írási teljesíménye nem esik le; az ugyanannyi adatdiszkes raid4 teljesítménye megegyezik a raid_dp teljesítményével, az online raid bővítés azonnali, a spare beillesztés disk-szekvencális-írási sebességgel megy (marha gyorsan), a raid készítése azonnali (ha van hozzá nullázott diszk), a dirty diszkek kinullázása párhuzamos = gyors.
Bírja az "5 percenkénti snapshot, legutolsó 10 megtartása" című játékot, lényegi teljesíményvesztés nélkül.

Alapvetően nem engedi hot-spare nélkül, de be lehet állítani CLI-ből, RAID-DP esetén bevállalható.

Igény függő, hogy miként osztod meg a vezérlők között a lemezeket. Szükség előtt javasolt nem felhasználni, mert utána a tömbből nem tudod kivenni, ha mégis másik tömbbe kellett volna.

Jól sejted, hogy a cache-ből (itt NVRAM-nak hívják) mindig full stripe írása történik, ezt pedig a WAFL (Write Anywhere File Layout) fájlrendszer teszi lehetővé. Ezért kerüli el így a RAID6 (és RAIl5-re) is jellemző írás büntetést. Nyilván részleteket nem árulnak el, persze a marketingesek nyilván szeretnek szépíteni túlozni.

Abban a kérdésben, hogy mennyire működik jól szerintem mutatja, hogy a NetApp sikeres és fejleszt, valamint van jónéhány nagy ügyfelük ahol biztosan jó terhelést kapnak.

csatlakozom.
ami az ontap -ot illeti en szeretem. (a gx -et pl. nem... ) mindent meg tudsz online csinalni, habar vannak limitaciok.
Valoban nem a legolcsobb, de megvan az az elonye, hogy megy. ha pedig nem megy, akkor rendes garanciad van ra. Nem ilyen irj egy levelet, hanem van magyar disztributor akinel dolgoznak olyanok is, akik ertenek hozza :)

A snapshot beallithato, es hamar itt tartunk, akkor a snapshot valoban utos, leven a storage maga intezi a snapshotot es ha windows kliensed van, ami cifs -en mountolja, akkor (adott esetben snapvault nelkul ) millio featuret csak egy jobbklikkre tud.
A restore lehet reszleges, a .snapshot borzolhato.

Node, ez enterprise storage :)

( egeresz | 2012. 02. 02., cs – 21:40 )

Valamit mindenképpen fizetni fogsz valamivel, és nem biztos, hogy az neked jó lesz. Nem csak pénzzel kell néhány funkcióért fizetni, hanem teljesítménynel is.

dedup: kényszerűen csökkenti a teljesítményt, pl a seq read részt, bármilyen is a dedup megoldás.
snapshot: sok snapshot kényszerűen csökkenti a teljesítményt, még a NetAPP FAS esetén is, pedig az aztán tud snapshotolni. Mondjuk 1-2 még nem észrevehető annál.

SSD support: minek? Értem én, hogy nagyon jó lenne, szerintem is.
Azonban ma, ebben az árkategóriában irreális. Veszel 1 darabot bele? 6-ot? (nem ez az ár) vagy 2-őt, és maradékban sok SATA diszket? egy pool (group, raid, stb) vagy több? Vagy auto storage tiering?

Rakhatod a virtualizált környezetedet NFS-re, rakhatod iSCSI-re, végül is mindkettőnek van előnye/hátránya, lehet a cucc tisztán NAS, tisztán iSCSI is, a feladatot meg lehet mindennel oldani.

Hajjaj.

( egeresz | 2012. 02. 02., cs – 21:56 )

Virtualizációs megoldást keresel.
Már meg van határozva, hogy VMWare ESX vagy ESXi.

Vannak szolgáltatásaid, amiket biztosítanod kell.
- file (cifs)
- levelezés
- AD
- esetleg valami vekonykliens-megoldás (citrix mondjuk)
- rendszeres mentés

Ezekhez kapcsolódik kapacitás igény
- valahány GB
- valamekkora IO/sec igény
- mentés naponta/hetente, szalgra, diszkre, archiválás
- mentési ablak X perc minden nap

Az egészet megfejeli egy rendelkezésreállás-igény
- munkanapi csere, 4 órás csere, hotswap
- 1 telephely, 2 telephely, 'geocluster' online-replika etc

Van egy környezet, amin nem lehet változtatni:
- a rendszergazdának max heti 1/2/40 órájába kerülhet
- ne zúgjon/10A alatt egyen/max 2U a rackben/víz alatt is menjen...

Ilyen rendszerek méretezését szoktam elvégezni, azon az elven, hogy az igényeket kielégítő legolcsóbb rendszer a jó.

A méretezés első lépése a szolgáltatáslista.
Második lépése az igények, főleg a kapacitás, sebesség.
Általában ez utóbbit nem tudják korrektűl megadni, segítünk, lemérjük.

Ha ezek megvannak, akkor kiesik belőle, hogy melyik storage a jó.
Pl, írtad, hogy kell dedup. Biztos? és ha az X gyártó 4M ft-ért 3x akkora rendszert ad dedup nélkül, mint az Y gyártó deduppal? ennyit nem nyersz a dedupon. írtad, hogy kell SSD support. Biztos? és ha az SSD support (tehát nem az SSD maga, csak a lehetőség megléte) annyiba kerül, mint más gyártónál egy teli polc 15k rpm SAS disk?
Ami ad neked mondjuk 4000 IO/s -et, és a jelenlegi igényed pont a tizede.

Aztán az is lehet, hogy szemrevételezve az ESX node-okat, a pénz elköltésének helyes módja nem az erős storage, hanem még memória a gépekbe és még és még.

Szóval, ugyan lehetne válaszolni a kérdésedre magára, megnézheted a dell equalllogic, ibm ds3xxx rendszereket is. Várhatóan jól össze is raksz egy működő rendszert, már a kérdésfeltevés is alapos embert feltételez. Azonban mégsem ez a jó út. A szolgáltatások és az igények felől közelíteni a problémához a jó út.

Amit irsz, az nagyon korekt, egy optimalis vilagban en is igy csinalnam.
De a realitas viszont az, hogy egy heterogen, lokalisan optimalizalt megoldascsomagot kell kivaltani abszolut minimal budzsebol, anelkul hogy a lokalisan optimalizalt pontok elvessznenek, viszont hoszabb tavon a rendszer upgradelheto legyen tobb iranyba is.

Mar tobben kerdeztek az SSD igenyt ill. a storage tiereket:
Jelenleg az adatbazisok SSD RAID-eken vannak, a VM-ek iSCSI-n keresztul SAS RAID tombokon, a backup cuccok ill. az altalanos file storage SATA tombokon. Ez igy mukodik, es kapacitas/iops igenyt kielegiti, tehat megtartanam, viszont egy csomo hoszabb tavon szukseges feature nincs (HA, dedupe, egyszeru snapshotok, storagelink, etc).

Ez esetben egy olyan storage, ami automatikus storage tieringet is tud, jól jöhet neked.
Az adatbázisoknál álltalában az adatok jó részére alig van IO. A VM-eken az oprendszer fájljaira szintén alig van olvasás.
Egy auto storage tieringgel jóval kevesebb SSD, és SAS diszkkel ki lehet szolgálni ugyanazt az IO igényt, mert a rendszer a kevésbé használt blokkokat a lasabb storage-ra migrálja idővel, a nagyobb IO igényűeket pedig magasabbra. És mindezt automatikusan az aktuális teljesítmények elemzése alapján.

Így amit nyersz a kevesebb SSD-vel, azt költheted controllerre, meg feature-re.

megközelítem máshonnan;-)

ha nekem kell managelni, akkor jelenleg dell equallogic, netapp fas sorozaton kívül mást nem választanék. Lehet árat kérni.

Viszont, a 3 év mulvai bővítés nem tervezhető most. Ha tényleg szorit a büdzsé, akkor a jelen problémákat oldjuk meg.

Nézd a facebook hetente betol a képek kiszolgálására egy giganagy FAS egységet (FAS tud http protokolt is direktbe).
Te meg, ha van 4M forintod, abból vehetsz 2 polcnyi rendszert bármi entry-levelből, vagy 1 polcnyi olyat, mai később bővíthető jól.

ok.
Csak hasonló cipőben járok, kicsit más specifikációkkal és igényekkel,
és FAS2040 és AX4 között örlődöm, erősen korlátozott költségvetéssel.
Storage-ekhez úgy álltalában és Emc-hez konkrétan némileg értek , a netappról mélyebb infókat elég nehéz volt összeszedni.
Netappból a storage link support, és a dedup ami tetszik, viszont nem a musthave. Elsődleges szempont az iops, főleg az írási. (Elég memóriával a host oldalon minimalizálható az olvasási io.)

Megtudtam 1-2 új infót a netappról a kommentjeidből, köszi.
Egyrészt segített eloszlatni az írási teljesítményével kapcsolatos félelmeimet, másrészt kicsit sziven ütött, hogy a 12 diszkes konfigból 4 diszk kapásból kiesik. (2 tálcányi diszkre meg nincs szükségem.)

Az AX4 egy viszonylag buta tároló. Két érdekes dolgot tud, amit a NetApp nem: Virtual LUN technológia (LUN-t tudsz mozgatni RAID tömbök között úgy, hogy közben elérhető), proaktív hot-spare. Illetve RAID5, RAID10, de ezek annyira nem lényegesek. Ellenben az iSCSI változat nem tud replikálni, teljesítményben megvannak a korlátai (átbocsátásban 50MBps-nél többet ne várj).
Technikailag jó, hogy keverhető a lemez polcon belül. Viszont roppant lassú a szállítás.
Pénzügyileg előnye, hogy akár 5 lemezzel is van egy dobozod, ami versenytársakhoz képest nevetségesen olcsó tud lenni (néha van kapacitás duplázós akció).

A FAS2040 ellenben sok mindent tud: pillanatképek, replikáció stb stb, teljesítményben is sokkal jobb.
Pénzügyileg hátránya, hogy praktikus csak tele polccal érdemes venni.
Lemez típust nem tudsz polcon belül keverni.

Ha ki lehet sírni elég pénzt, én a FAS2040-et választanám általánosságban.

Köszi, de az emc-vel elég jól képben vagyok. (korábban clariion suportban is dolgoztam.)
Az Ax4 annyiban "buta" a Netapphoz képest, hogy az egy valódi blokkszintű tároló,a FAS2000 pedig nem. (Abban ugye van egy fájlrendszer, és pl. az iscsi-t targetet valójában nagy fájlokon valósítja meg.) A fájlrendszer miatt meg ugye lényegesen több feature-re képes, mint egy blokk tároló.

Amire konkrétan pénz van, az egy FAS2040 12x1T 7200rpm sata, vagy AX4 12x15000rpm SAS . (mindkettő iSCSI)
Szerintem teljesítményben a kettő közül az AX még raid5-ben is jobb.

Pillanatképek, replikáció, snapshot és dedup nice to have, de nem kell.

Úgy jött ki a korábbi megjegyzéseidből, hogy az AX4-et nem ismered (csak nagyobb EMC-t), bocs. Tudom jól, melyik mit tud és mit nem.

"teljesítményben a kettő közül az AX még raid5-ben is jobb" - mi alapján, milyen terhelés esetén? :-)
Ezekben a kis tárolókban a CPU elég erőteljes korlát sajnos, a 2040-ben már elég erős van, a GbE-t ki tudja nyomni (AX4-ről nem mondható el - átbocsátást nézve -, az IOPS másik kérdés, de ott is számít a CPU, illetve 2040-et is lehet 15k SAS lemezzel venni).

Az AX4-ben is igaz az, ami a nagyobb EMC-kben: a rendszer alaplemezeinek (itt 4darab) kisebb a teljesítménye (mérések alapján kb 10%-ot von le az elérhető sebességből az, hogy az OS azokon fut). Én alapvetően ezeket nem is szeretem RAID tömbön belül keverni a többivel (adatot ettől függetlenül lehet rá tenni), tehát 12db lemezed összefüggően nem is igazán tud lenni.

Van ügyfelünk, aki AX4-et választott költséghatékonyság miatt, de fél év múlva rájött, hogy replikáció is kellene, de hát sajnos nincsen hozzá ilyen lehetőség. Olyan ügyfelünk is van, aki AX4-et választott költséghatékonyság miatt, és azóta is boldog vele. :-)

"AX4-et nem ismered"
Ok, konktrétan vele kevés tapasztalatom van, viszont jelentősen nem külömbözik szerintem a cx sorozattól (ha meg mégis, akkor bocs, szivesen veszem az okítást.)

"teljesítményben a kettő közül az AX még raid5-ben is jobb -mi alapján, milyen terhelés esetén?"

random read-ben egyértelműen jobb.
Mivel viszont főleg web, mail és adatbázis szerver virtualizálás a feladat a random write a fő szempont (kb 20/80 lehet a read/write ráta átlag), és emiatt vagyok kicsit gondban, mert ebben meg a FAS széria elég erős. Nem tudom kompenzálja -e ez a tulajdonsága a kisebb iops-al rendelkező sata diszkeket.

Az AX4 konfgját úgy gondoltam, hogy vault drive-ok: raid 10 tömb, a többi pedig 7 diszk raid5, + egy hot spare.

A FAS sorozatnál bonyolítja a dolgot, hogy duál kontroller esetén mindkét kontrollernek kell 1-1 raid tömböt allokálni (külön tömbökről bootol?), és ez egy csóró 12 diszkes kiosztásnál egyrészt fájó kapacitás vesztés, de még fájóbb iops vesztés.

A fenti read/write ráta tekintetében nem tudom eldönteni, hogy melyik konfig az optimálisabb a feladatra. Kapacitásban mindkettő megfelel.
A harangok és csellentyűk (dedup, snap, clone, stb) belátható időn belül tuti nem kell.

"illetve 2040-et is lehet 15k SAS lemezzel venni"

Pénzért bármit, de esetemben max a SATA fér bele :)

Azt meg tudod csinálni, hogy NetApp esetén egyik vezérlő kap 9 lemezt (7 adat + 2 paritás), a másik hármat (nincs hot-spare, de RAID-DP van). A RAID5 IOPS büntije 4, a RAID-DP-t nem tudom, valahol 1 és 2 között lehet (kvázi RAID0 paritás lemezekkel, pontos értéket sajnos nem tudok). Tehát lehet, hogy kb uazt a teljesítményt kapod fele olyan gyors lemezzel írás esetén (olvasásnál nyilván nem).

A két vezérlő igen, külön tömbről bootol (egyébként sem megoldott - kivéve a vezérlő failover esetét - hogy a vezérlők egymás tömbjeihez hozzáférjenek).

Most min fut a cucc?

"Tehát lehet, hogy kb uazt a teljesítményt kapod fele olyan gyors lemezzel írás esetén "

Igen. Kb ez a gyanúm nekem is...

"Most min fut a cucc?"

Két szerver lokál diszkekkel, szerverenként 4 diszkes sata raid10 (bbwc-s raid vezérlőkkel).
Ami baromira nem mérvadó, mert be akarok vonni +1 szervert, és bővíteni a kapacitást kb 3 szorosára, és pár másik vasról konszolidálva lesz rá ez-az.
Ezért kéne valami shared storage.

Ami az egész sztoriból becsülhető, az a read/write arány, és nagyondurvándetényleg az iops igény (ami kb. a jelenlegi triplája, és a jelenlegivel nincs teljesítmény gond, de túl sok plusz sincs már benne).
Ami fix, az meg a költségvetés. :)

Konkrét ajánlatom mindkettőre van.
Már nem az ár játszik, hanem az amiről eddig beszélgettünk.

VNXe nagyon nem játszik. (Nem érzem úgy, hogy ebbe a környezetbe való. Gyakorlatilag a Celerához hasonló konstrukció, asszem ugyanaz a DART is van benne. Irodai fájlszerverek mellé kiváló, virtualizációhoz szerintem kevésbé)
Ha már hibrid, akkor Netapp. :)

Korábban olvastam egy nagyon jó leírást Equallogicról üzemeltetési szempontból. Talán 2009-es volt az információ, 3 év tapasztalatát ölelte fel körülbelül. Az illető hatalmas reményekkel futott neki, de hát összeségében csalódás volt számára, sok bosszantó problémája volt. A linkeket jól megőriztem, de a tartalom már eltűnt sajnos.

Én alaposan utánanéznék.

A kérdés az, hogy az igényeid és a pénzügyi keret milyen viszonyban vannak egymással, ennek összevetésére pedig a kolléga által javasoltat lehet+kell csinálni. Ezenkívül prioritásokat kell felállítani és jövőre vonatkozóan gondolkodni. Azaz tervezni a paraméterek alapján :-)