Milyen legyen a storage?

Üdv.

Építenem kell egy rendszert, amiben a gépek egy storage-re kapcsolódnak.
A gépek amik rá lesznek kötve (ezek már rendelkezésre állnak):
3db IBM x3550 M4
alábbi paraméterekkel:
processzor: 2x Intel Xeon E5-2680 8C
memória: 128 GB
hdd: -

csatlakozás fibre channelen a storage-hoz SAN switch-en keresztül lesz, de egyelőre a switch típusa is kérdéses.
egyelőre ezt néztük ki:
IBM Storwize V3700 SFF Dual Control
10x600GB 10,000 rpm 6Gb SAS 2.5” HDD
14x1TB 7,200 rpm 6Gb SAS NL 2.5” HDD
8GB Cache Upgrade

Jelenleg csak azért néztünk IBM-et, mert az összes szerver a cégnél IBM, de másra is nyitottak vagyunk.

A szervereken virtuális gépek futnának, amiken általában DNS, levelezés, php és MySQL alapú weboldalak futnának.

Szóval az lenne e kérdésem, hogy milyen storage-t válasszunk? Akinek van tapasztalata storageel kapcsolatban, az ossza meg kérem.

Hozzászólások

A Storwize az jó cucc.
De hogy érdemben ajánlani tudjunk vmit, ahhoz kellene egy becsült workload, hogy ez a konfig bírja-e.
VMware-t használtok virtualizációra?

OK. Megpróbáltam a megadott adatokból becsülni egy átlagos válaszidőt. De a dolog nehézsége az, hogy sok helyen durván általánosítottam, a való életben ennél biztosan változékonyabb a workload (nappal magasabb DB használat, éjjel több backup job, stb.).

Így számoltam/becsültem:
- 160kB transfer size (ami tök sok DB esetén, de hát ennyi jön ki abból amit megadtál)
- 85% read, 15% write
- legyen 50% sequential, 50% random
- array-ek:
SAS diszkek -> 1x RAID6 -> erre megy rá 1000 IOPS
NLSAS diszkek -> 2x RAID6 -> erre megy rá 500 IOPS
- duplázásnál az IOPS-et dupláztam, de a SAS-nál már le kellett csökkentenem 100kB-ra a transfer size-ot.
- a cache hit arányról nem nyilatkoztál, ezért azt végigfuttattam 100%-tól 0%-ig

Ezt dobta a becslő program:


cache hit ratio [%]:				 100	  90	  80	  70	  60	  50	  40	  30	  20	  10	   0
avg resp. time [ms] (1000+500 IOPS):		0.68	1.62	2.64	3.74	4.97	6.35	8.05	10.1	12.67	16.04	20.8
avg resp. time [ms] (2000+1000 IOPS):		0.55	1.47	2.57	4.01	6.27	11.73					

A duplázott esetben 50% alatti cache hitnél a hdd utilization 100%-on koppan.

Ha bármelyik adatot pontosítani tudod, akkor küldd el nekem és újraszámolom a becslést.
Egyébként most milyen storage-ot használtok, és ott mennyi a cache hit rate?

Hogy egy kicsit ontopik legyek :-)

Én inkább azt javasolnám, hogy nagyobb különbséget képezz a két tier között: pl. 15k hdd és 7k hdd (ha az ssd semmiképp nem jöhet szóba az ára miatt). Mert akkor a gyors raid rebuild miatt vállalható a raid5 is, aminek jobb az írás teljesítménye.

Ha alapvetően elégedettek vagytok vele akkor vegyétek meg.
Ha mást is nézni akartok (és teljesen összezavarodni) :) akkor
NetApp FAS2220, FAS2240 www.storage-akcio.hu
EMC VNX5100, 5300 www.vnx.hu
ők független storage gyártók, aztán minden szerver gyártónak van már storage rendszere is.
HP, DELL.
Mindegyiknek más az erőssége gyengéje. Ha "csak" egy egyszerű FC storage-ot akartok akkor szvsz bármelyik jó ami a piacon van.
NetApp és EMC témában szívesen adunk akár ajánlatot is ha érdekel.

Igy nehez barmit is mondani, hogy nincs definialva egy teljesitmenyszukseglet.
Ha abbol indulunk ki, ami konfigot leirtal, akkor egy hasrautes szeru valasztas is jo lesz.
IBM ragaszkodas eseten brandel brocade fc switcheket sajat nev alatt is a nagy kek. b24 valami a tipusa.

Boot tervezett megoldasa mi lesz ? Szerintem kar storagerol bootolni, de kinek izlese szerint.

http://karikasostor.hu - Az autentikus zajforrás.

3db szerver mellé még nem feltétlen kell FC switch.
A v3700 kontrollerenként 4 FC porttal rendelkezik, tehát 4 szerver még direktbe hozzáköthető redundánsan.

Egyébként meg: mérni, mérni, mérni! Mérések nélkül nem csinálunk storage beruházást.

DNS/PHP/mysql jellemzően nem generál nagy IO-t. Ha elég memória van a guestekben, akkor leginkább az írási IO dominál a rendszerben, amit ez a konfig jó eséllyel elvisz.

Ha nagy IO terhelés van, akkor esetleg 2db SSD is bele mehet (valamelyik 2 diszk helyébe), mert tud storage tieringet (vagy ennek az IBM-es megfelelőjét.)

Mondjuk a 2db SSD a Storewize-ba kb. annyiba kerül mint az összes többi része. :)

az FC switcht azért szeretnénk megvenni, mert vélhetően pár hónapon belül jönnek még hozzá szerverek.

"Ha nagy IO terhelés van, akkor esetleg 2db SSD is bele mehet (valamelyik 2 diszk helyébe), mert tud storage tieringet (vagy ennek az IBM-es megfelelőjét.)"
Ezért szeretnék infót kérni arról is, hogy minden storagebe saját márkás SSD-t lehet csak rakni? Sajnos a 400GB-os IBM SSD $10k+ darabja.

Csak sajat SSD mehet bele minden gyartonal. De szvsz csak akkor van ertelme ha van tiering is, az meg fizetos opcio mindenhol. Igy hirtelen nem jut eszembe gyarto aki ingyen adna ezt a funkciot.

FC swithc-bol meg teljesen jo a Brocade 300, ezt altalaban szoktak arulni a gyartok sajat logoval. Ha 16G FC-re van szukseg akkor csak a Brocade johet szoba, itt a Cisco szokas szerint egy kisse le van maradva.

Talán a Coraid-nél van/volt olyan lehetőség, hogy te töltheted fel diszkekkel. De az Etherneten megy, nem FC. Másnál nem láttam ilyen lehetőséget. Gondolom ebben a saját firmware is erősen bejátszik, mivel akkor csak ahhoz kell tesztelni a cuccot, és abban minden úgy van ahogy a gyártó szeretné. Ezen kívül a diszkek is olyanok amiket a gyártó tesztelt, pl. a SATA drive-ok nem a PC boltban (consumer) kapható termékcsaládból kerülnek ki, hanem a vállalati felhasználásra szántból, nagyobb cache, jobb minőségellenőrzés.

A "normális" storage esetén a storage-ban levő mikrokód/oprendszer együttműködik a diszk firmware-el.
Oprendszer upgrade esetén időnként a diszkek firmware-ét is frissítik.

Nem feltétlen a diszkek "jobb" minősége az indok, bár tény, hogy a minőség ellenőrzése szigorúbb.
A storage garancia értelem szerűen a diszkekre is kiterjed.
Ha support szerződésed is van, a support olyankor is cserél diszket (EMC esetén tuti), amikor még nem volt meghibásodás de pl. valami széria hiba miatt a gyártó cserét rendel el.

Szerintem egy ekkora kiadásnál érdemes jobban körüljárni a dolgot:
-mekkora terhelés várható?
-milyen virtualizáció?
-milyen guestek?
-mennyire akarjátok reszelni, vagy amit alapból tud a technika, az jó úgy...?

Én egy új Hp Dl350p g8-al játszottam az elmúlt napokban, és látványosan lehet tuningolni az IO teljesítményt, csak rá kell szánni az időt.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

érdekes a kérdésed.

Itt a HUP-on vagyunk jónéhányan, akik storage szaktudásból élünk. Fentebb hozzászólok között is több az ismerős, mint az ismeretlen. én is storage szaktudásból élek.

A feltett konfig az a millió forintok tucatjai inkább, mint darabjai. Ekkora tételnél az alábbi esetekkel találkoztam idáig:

- a cég pénzügyi szintjén dől el, hogy mit vesznek. A konfigot a szállító ajánlja, a helyi rendszergazdának kizárólak bólogatási joga van
- egy műszaki integrátor cég szakemberei felmérik a helyzetet, válaszolnak az összes technikai kérdésre és ezek alapján javasolnak egy konfigot. A műszaki integrátor cég igénybevétele a teljes projectköltség 5% -a. Miután egy hibás döntéssel simán lehet bukni 30%-ot, emiatt általában megéri.

Konkrét válasz:
a szóba jöhető FC csaatolós enterprise storage-ből szinte bármelyik jó, csak éppen a kialakítások különbözősége miatt ugyanazt az igényelt teljesítményt más és más diszk-konfigurációban nyújtják. És más és más áron.

Konkrétan van tapasztalatom
- HP EVA
- HP MSA
- Fujitsu Eternus
- IBM DS3xxx
- IBm DS4xxx
- IBM Nseries (vagyis netapp)
- Netapp FAS (vagyis IBM Nseries)

rendszerekkel. Ezen kívül jelentős még a
- EMC clariion
- IBM XIV
- IBM Storwize
- DELL bármi

FC switch tekintetében brocade és qlogic switch tapasztalatom van, mindkettő elǵ jó.

Kicsi konkretizálás:
Netapp (IBM Nseries) esetén raid_dp a javasolt raid kialakítás, számolj a bruttó diszkterület 62% -val nettónak.
EMC clariion, HP MSA, Fujitsu eternus, IBM DS4xxx, DS3xxx esetén RAID10 a javasolt kialakítás adatbázis (mailszerver) jellegű terhelésnél, számolj 47%-kal nettónak.
EVA eseten vraid1. EVA eseten hasznalj max 30 darab diszket egy groupba, ne te legyel a kovetkezo, aki adatvesztessel a hirekbe kerul. (las pl a pecsi egyetem eva -ja). Okosan hasznalva az EVA is eleg stabi.

Ha a szolgáltatás folytonosságának az értéke jóval meghaladja a storage beszerzési értéket, akkor kiesnek a kicsik, amik nem tudnak redundáns backend diszk-összeköttetést. (kiesik az eternus, az msa, ds3xxx stb).

10k rpm diszk eseten szamolj 200 IO/s -sel diszkenkent, 7,2 rpm diszk eseten szamolj 130 IO/s -sel.
A diszkek savszelessege nem szokott a szuk keresztmetszet lenni, azzal ne foglalkozz.

Alap bölcsesség: ekkora beruházásnál házon belül meg kell határozni az elvárásokat, aztán meghívni pár gyártót, hogy mit ajánlanak.
(Mondjuk az az 1500 IOPS igény szerintem a midrange alja.... )

Esetleg a specifikáció megírására igénybe lehet venni egy független rendszerintegrátor segítségét.

Amit a gyártók ajánlanak, az álltalában megfelel a kiadott specifikációnak, illetve ha jó a specifikáció, akkor a valóságban is jól fog teljesíteni a cucc.

Innentől kezdve a döntés leginkább pénzügyi.

Az egyes hardware komponensek összeválogatásánál pedig melegen ajánlott a support mátrixok böngészése.

Nem biztos, hogy egy tároló esetén csak a "teljesítmény tudást" kell nézni, az sem mellékes, hogy milyen egyéb igények vannak.

Például a NetApp FlexClone-jához hasonló van máshol?

És még lehetne sorolni a mindenféle funkciót, amik lényegesek lehetnek, azaz ez nem feltétlneül csak "technikai" kérdés, hanem ott kezdődik a procedúra, hogy meg kell ismerni a cég üzleti követelményeit (ami jelentősen több, mint néhány teljesítmény mérőszám).

Hmmm, ilyesmi érdekelne engem is, szeretnék még véleményeket megismerni.

5 éves távlatban gondolkodva kellene nettó 300 TB környékén tárterület, hozzávetőlegesen 15000 IOPS-szal. 8 Gbites SAN hálózat van adottságként, ezt kéne használni, 16 Gbites SAN majd inkább csak ha ez a storage már kifut. A felhasználás kizárólag VMware-en futtatott adatbázisokból (60%), applikációs szerverekből (10%), valamint virtualizált desktop környezetekből és fájlszerverekből (30%) áll össze. Napközben inkább a filszerverek, éjjel inkább az adatbázisok vannak hajtva (tehát jól jönne valami autotiering megoldás). Olvasás/írás arány meglepő módon 50%/50%, nincs eltolva az olvasás felé. Nagy burst van reggel a desktop környezetek indulásakor, de azt egy RamSAN sem szolgálná ki, nem kell 150000 IOPS-ra optimalizálni.

Nézegettem sokmindent, a legszimpatikusabb megoldások (és hogy miért nem tetszenek):

- néhány darab EVA (egyben ekkora EVA nincs), ellenben az EVA kifutó termék a HP-nál, 5 év múlva szerintem drága lesz és SSD-ket nem túl hasznos beletenni értelmes tiering hiányában
- 3PAR, de a HP színű 3PAR-ral még nem lehet senkinek tapasztalata, lévén valamikor novemberben jelent meg
- Fujitsu, de a Fu-Si időkből rossz emlékeim vannak
- EMC és IBM sokkal drágábbak, mint ezek.

Mit vennétek és miért? Mit nem és miért nem?

Kb. bármelyik enterprise storage-ot, esetleg valamilyen storage virtualizációs megoldással megbolondított kombót.
EMC és IBM drágább, de okkal.
Ekkora méretben már szoktak lenni igények is. Pl. DR site, amire tükrözni kell az adatokat, vagy helyi dinamikus tükrözéses megoldások (BCV/Flash copy/ shadow copy), esetleg LAN-free backup, stb.
EMC és IBM ezekben a szolgáltatásokban elég jó tud lenni.

A 15000IOPS elég kevésnek tűnik nekem ebben a méretben. Nem maradt le egy 0 a végéről? :)

szerk. Nem biztos, hogy egy tipusban gondolkodnék. Elképzelhetőnek tartom midrange és enterprise storage-ok keverését ebben a szituban.

Az enterprise storage-ok drágák és elsősorban a tényleg alacsony IOPS igény miatt erre szerintem nem indokoltak. DR site kell, adottak hozzá a feltételek is - de ezt már mindrange-ben is tudja az összes valamirevaló storage, többnyire ingyen vagy olcsón (persze relatív az olcsó, de néhány millió Ft itt belefér simán).

NetApp :-)

Miért? Mert nagyon széles a technológiai tárháza. Például "tiering" jellegű igényre több változata is van (http://www.netapp.com/us/technology/flash-storage/index.aspx), ezenkívül nagyon gazdag a szoftver palettája (VDI esetén FlexClone és NFS hasznos lehet).
Általánosságban nehéz többet leírni szokásos marketing rizsa nélkül, konkrétan meg kellene ismerni a környezetet és végigmenni, hogy milyen igényre a NetApp mint tud kínálni, ugyanis jóval többet tud nyújtani annál, minthogy blokk szinten tárolja az adatokat.

Itt érdemes kezdened az ismerkedést technikai ember lévén: http://www.netapp.com/us/products/platform-os/data-ontap-8/ vagy http://www.netapp.com/us/technology/index.aspx, utána pedig le kell ülni "beszélgetni" :-) annak érdekében, hogy személyre szabott válaszokat kaphassál.

Pl. alapvetően ezek nem blokk storage-nak lettek tervezve, a WAFL ba csak utólag került bele ez a funkció (pl. iSCSI, FC target.), és ez látszik is rajta.
Nem tudom, hogy mindegyik esetén ilyen -e, de pl. FAS2020 esetén az a mód, ahogy a redundáns kontrollereket külön kell konfigurálni, nagyon gáz. Van egy olyan érzése az embernek, mintha egy linux/bsd dzsunka clustert faragna. Még egy középkategóriás EMC clariion-al összehasonlítva is ég és föld.
Gyanítom a nagyobb cuccokban ugyanaz a WAFL/Ontap van, éppen ezért nem hinném, hogy az Enterprise-kategóriának kikiáltott termékvonal túlságosan eltérne architektúrában a FAS2020-tól.

Nem tudom, hogy nagyobb kiszerelésben hogy teljesít, a saját FAS2020-ommal elégedett vagyok, de az nem enterprise feladatokra van használva.

Elég komoly cégek üzemelnek/üzemeltetnek NetAppon (például T-Systems), úgyhogy nagyon nagy gáz nem lehet vele, már régen kidobták volna...

Igen, látszik, hogy nem blokk tároló volt a kezdetekben, és furcsa lehet, hogy a két vezérlőt külön kell konfigurálni, de ekkora erővel az IBM DS-ek felügyeletével kapcsolatos problémákat is lehetne sorolni (szerintem összeségében mindent egybe vetve elég gáz). És a többiét is.

"Faragás": így is lehet fogalmazni, de más megközelítésből úgyis lehet fogalmazni, hogy nagyobb teret ad. Ugyanakkor van egy GUI, amivel a fontos dolgokat meg lehet csinálni.

A FAS2020-nál azért jelentősen bővebb a NetApp portfóliója, ráadásul az is igaz, hogy ami tudást annál megszereztél, az 99%-ban alkalmazható nagyobb tárolók esetén is, mert ugyanaz az OS fut rajta.

Egyébként nem FAS2040-ed van? :-)

(az IBM is NetAppozik, tehát önmaga is egy lapon említi magát vele, de hogy még furább legyen az egész, az IBM DS-ek valójában LSI-k, ami egy ideje szintén NetApp, mert felvásárolta)

"Egyébként nem FAS2040-ed van?"
Ja, de , tényleg. :) :) :)

"Elég komoly cégek üzemelnek/üzemeltetnek NetAppon (például T-Systems), úgyhogy nagyon nagy gáz nem lehet vele, már régen kidobták volna"

Az ilyen példák azért sántítanak, mert nagy cégeknél előfordul, hogy évekig üzemel valami szar, ami egyébként kegyetlen nagy bukás volt, csak kimondani nem merik, mert ugye a vezetők bonusa/állása forog kockán.
Ne érts félre, nem a Netapp-ra gondolok, mert alapjába véve jó kis cucc az.

Ja, igen, T-ben most nagy a szerelem a Netapp felé, még oda is azt erőltetnék, ahova nem biztos, hogy kéne.... :)

ezek nem blokk storage-nak lettek tervezve, a WAFL ba csak utólag került bele ez a funkció

Ez IBM marketing szoveg, ugyanis ezzel magyarazzak, hogy miert vegyel IBM DSxxxx termeket Nseries (ami netapp OEM) helyett. Ezt tanitjak a gyorstalpalon az mernok presales supportosoknak is.

valoban, egy intelligens layerrel tobb van a netapp FAS-ban, mint mondjuk az IBM DS4xxx -ben, vagy a HP EVA-ban. de ugyanugy hozzatesz egy intelligens layert az IBM SVC is a rendszerhez, az IBM megse domboritja ezt a tulajdonsagat ki :-)

De nem szamit. Rengeteg funkciot meg lehet csinalni rengeteg modon. Az altalad emlitett 300T belefer egy netapp FAS32xxx rendszerbe, de belefer sok masba is.

Amiben a netapp unikalis, az a jo random write teljesitmenyu raid6 implementacio. Ha cachemeret feletti adatmennyisegnel kell jo random write, akkor vagy netapp raid6, vagy barmi mas raid10. De a barmimas raid10 is jo! a netapp konnyen snapshotol, es ez baromi jo benne, de igazabol jol megvan enelkul egy vmware kornyezet, ugyanis a vmware is tud snapshotolni (meg ha nem is annyira jol).

Az IBM SVC peldaul tud 3 tagu clustert. Imadom az ilyet. Ez ad elvi lehetoseget automatikus DR atallasra. Mondom elvi. Egy kezi inditasu DR atallasi lehetoseg implementalasa is akkora munka, hogy altalaban nem szokott sikerulni.

Virtuális gép és tároló szintű pillanatkép másra való, még ha valamilyen szinten hasonlítanak is egymásra.

Fontos technikai különbség, hogy NetApp esetén nem gond, ha vannak pillanatképeid (más tárolóról ez nem mondható el), ellenben VMware alatt lehetőség szerint inkább ne legyen, vagy ha van, akkor pontosan tudni kell, hogy miért és mennyi ideig. És néha nem árt meggyőződni arról, hogy csak azok vannak, amikről hisszük, hogy vannak :-)

Nyilván megvan egy VMware környezet NetApp pillanatkép nélkül, hiszen VMware virtualizáció nélkül is megvolt néhány évtizedig a szakma, de most már milyen jó, hogy van VMware, hiszen relatív alacsonyabb költséggel mennyi minden megvalósítható. Ugyanez mondható el a NetApp pillanatképről is: bizonyos igényeket sokkal egyszerűbb megvalósítani vele, mint nélküle (például 3 óránkénti visszaállítási pont a teljes infrastruktúráról).

"Fontos technikai különbség, hogy NetApp esetén nem gond, ha vannak pillanatképeid (más tárolóról ez nem mondható el)"

A copy-on-write jellegű snapshotokat használó eszközökben sehol sem gond, ha vannak snapshotok. (Pl. ZFS alapú Oracle unified storage tárolók). Ezekben max. a helyet zabálják fel s snapshotok, ahogy folyamatosan híznak. (Ez alól a Netapp sem kivétel - számomra kellemetlen meglepetés volt, hogy napról napra látványosan fogyott a hely a dobozban, mire megtaláltam, hogy by default benne van a 3-4 óránkénti snapshot, amire egyébként semmi szükségem.)

Pedig pont a copy-on-write snapshot eszi a teljesítményt, ezért a saját snap megoldás határozott előnye "volt" a NetApp-nak. Náluk rengeteg szolgáltatás épül a snapshotra. Lehet, hogy ZFS esetén is COW-nak hívják de a linkelt cikk együtt említi a NetApp-al hatékonyság szempontjából.
http://www.eigenmagic.com/2009/10/17/why-netapp-snapshots-are-awesome/
Persze a versenytársak sem voltak tétlenek és az EMC VNX-ben is elérhető már NetApp féle snapshot (sok és teljesítmény vesztés nélkül), a régi SnapView Snapshot.
http://www.emc.com/collateral/software/white-papers/h10858-vnx-snapshot…
EMC Isilon NAS is sok snapshotot tud.

Ok, lehet, hogy én használom rosszul a fogalmakat, de tudtommal a COW az, aminek nincs szüksége dedikált (dirty region) volume-ra.
A ZFS dokuk legalábbis következetesen azt hangsúlyozzák, hogy a tranzakcionális copy-on-write mód miatt olyan hatékony a snapshot mint amilyen. (Wikipedia: "An advantage of copy-on-write is that when ZFS writes new data, the blocks containing the old data can be retained, allowing a snapshot version of the file system to be maintained.")

Az álltalad említett snapview-nek szüksége van egy dedikált volume-ra, amin a régi blokkokat tárolja, és valóban lassabb a ZFS féle megoldásnál, és ráadásul menedzselhetősége sem jó. (Lévén dedikált volume kell neki, amit vagy túlméretez az ember és akkor pazarol, vagy alulméretez, és akkor kifut a helyből és bukja a snapshotot.) Egyébként a linuxos LVM snapshot is ezen az elven működik.

"Persze a versenytársak sem voltak tétlenek és az EMC VNX..."

Érdekesség, hogy az EMC VNX sem tisztán blokkszintű tároló, abban is egy file rendszerben vannak az adatok.

szerk.: Most hogy jobban utána olvasok, úhgy tűnik sok helyen keverik az egyes fogalmakat -valószínűleg én is.
A lényeg viszont, hogy a "régebbi" snapshot megoldások úgy működnek, hogy a felülírt blokkokat először dedikált snap területre másolja. Ez lassú, és nem túl stabil megoldás.
Az "újabb" megoldások (amiket eddig következetesen COW-nak neveztem) a felül írandó blokkokat a helyükön hagyják, a felülírás helyett egy új blokk készül, és meta adatokkal/pointerekkel oldja meg az egyes snapshotok elérhetőségét. Ez utóbbi gyakorlatilag semmilyen overheadet nem jelent a snapshotok tárolásánál, az egyetlen korlát a rendelkezésre álló szabad adatterület.

Szvsz. egyről beszélünk. Igen a régi külön területtel és nagy overhead-del (lehet ez inkább COFW copy-on-first-write), a másik implementáció pedig másik helyre ír és pointerekkel operál.

Ezt mire érted:
Érdekesség, hogy az EMC VNX sem tisztán blokkszintű tároló, abban is egy file rendszerben vannak az adatok.
Mert a VNX tud kutya közönséges block storage lenni, ahogy egy Clariion raid-groupok azon LUN-ok, van aztán a pool szolgáltatása amikor egy nagy kupac diszken hozod létre - persze ezen belül automatikusan több raid-group jön létre - a köteteket , és tud NAS-t is.

Ez így téves. A blokk storage rész ugyanaz mint a Clariion, a NAS rész pedig a blokk részt használja és ott tényleg létrehoz fájlrendszert. Ami esetleg zavaró lehet még a storage pool, ami a blokk részen több raid groupból álló massza, amin a lun-ok 1GB méretű darbokból állnak. Ráadásul poolon valósul meg a tiering is, ha többféle típusú lemezből rakod össze. (SSD, SAS, NL-SAS)

Szerintem mindkét féle snapshot technikának van előnye és hátránya:

COW:
- a blockok (első) felülírásakor lassabb, mivel +1 olvasás és írás igénye van
+ viszont a snapshot source volume a helyén marad, azaz később ugyanúgy viselkedik random és sequential olvasás esetén, mivel nem fragmentálódik szét
+ snapshotok olvashatóak és írhatóak is, azaz be lehet őket mountolni r/w és azon tesztelni vmit

NetApp féle pointerezgetősdi (bár ezt nem ismerem különösebben, csak a fenti link alapján írom):
+ a módosított block egy másik területre íródik, tehát nem kell felolvasni az eredeti adatot (de a pointer táblázatot is le kell írni vhova, úgyhogy szerintem ez is generál időnként metadata írást, csak ezt nyilván nem teszi meg minden block írás esetén)
- a fenti linkelt oldal szerint a snapshot volume csak olvasható
- mindkét volume (snapshot source és target) egyaránt fragmentálódik (megnézném milyen folytonos olvasásra lenne képes egy 4kB-okra fragmentálódott volume)

Úgyhogy szerintem nem azért használ COW-ot az IBM DS tárólói, mert "buták", hanem a fejlesztők mérlegelték a különböző megvalósítások előnyeit/hátrányait és aszerint döntöttek úgy.

A NetApp esetén külön opció az írhatóság FlexClone.
Szerintem sem a "butaság" az ok amiért az egyik vagy másik snap technológiát válsztják. Biztos vagyok benne, hogy a mérlegelés mellett a technikai megvalósíthatóság is szerepet játszik. Elképzelhető, hogy a storage belső működése miatt nem lehet vagy nem optimális megvalósítani a NetApp féle snap-et.
Szerencsére mindegyik működik és együtt lehet élni velük.

Barhol, ahol az ido kritikus, valamint a visszareplikalodas ideje es a snapshotbol visszaallas ideje kozul nem az elobbi nyer.

Ugyanis orokervenyu szabaly, hogy baj eseten a leggyorsabb ES legbiztonsagosabb uton kell visszaallni a legfrissebb mentesre. Egy snapshot restore + replikacio adott esetben gyorsabb lehet, mint egy akarhany teras adatcsomag visszareplikacioja.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Olyan pillanatképet nyilván nem fog készíteni, aminek nincs értelme, mert úgyse fogja használni, nem? :-)

a) aszinkron replikáció: készülhet és tárolódhat pillanatkép arról az állapotról, amiről replikáció történik

b) szinkron replikáció: eleve nagy sebességű kapcsolat van, tehát feltehetően nem jelent gondot azt használni. Ettől függetlenül lehet értelme pillanatképet készíteni, mert 2 óra múlva jön rá valaki, hogy nagy gubanc történt.

> Az ui-ra inkább nem reagálnék.

Minden rosszindulat nelkul, joszandekbol irtam.

> Kérlek így értsd a mondatomat:

Ettol fuggetlenul meg mindig csak egy kicsit eroltetve talalom ennek a funkcionak a a valos felhasznalasi lehetoseget. Toled is es mastol is lattam mar mint hajdejo feature es tenyleg nem igazan talalom a helyet terkepen.
Ezert kerdeztem.

tompos

Ez két dolog miatt is sántít:
- ha az adat korruptálódik a primary storage-on, akkor azt a replikáció is átviszi a DR site-ra, úgyhogy akkor csakis a snapshot visszaállítása jöhet szóba, akármilyen régi is.
- ha a primary storage hal le, akkor nincs hova visszaállítani a snapshotot (vagy eleve a snapshot is elérhetetlen), muszáj a productiont átvinni a DR site-ra. De ez még a jobbik eset, mert ott legalább úgy-ahogy friss az adat.

En azt hittem, hogy a snapshot egy viszonylag fuggetlen valami.

Amire en gondoltam:
- Lehal a primary site
- A visszaallasig atallunk a DR site-ra, viszont ez altalaban valamiert hatranyos lesz (lassabban lehet elerni, nem helyben van, stb), tehat kivanatos minel elobb visszaallni a primaryra
- Feljon a primary site, mondjuk kicsereltek az eszkozt, nulla adat van rajta
- Es ide jon amit mondok. Szerintem a replikacio - mivel egy ketiranyu dolgot jelent - lassabban zajlhat, mint egy direkt snapshot restore, amikor kerdes nelkul mondjuk ki a snapshotot iranyadonak. Ez alapjan feltetelezem - persze lehet ok nelkul - hogy gyorsabb lehet a snapshot + replikacio, mint megvarni, mire minden ater.

Illetve hat - nem ertek hozza. Ahogy en ezt elkepzeltem, ugy a snapshot valahol helyben tarolodik, de a storage-tol fuggetlenul - egyfajta backupkent. A DR site meg - felepitestol fuggoen - akarhol is lehet, akar nem is helyben.

Legalabbis - igy lenne logikus. Aztan lehet, hogy a snapshot total mast jelent a storageknel, mint amit en megszoktam a szo jelentese moge - most majd biztos jon NagyZ es jol elhord mindenfele kezdonek. Szerencsere nem uzemeltetek storageket - igy senki nem latja karat az ostobasagomnak.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A snapshot adata szintén a storage-on belül található, hiszen többnyire csak a különbözet tárolódik el, azt meg a storage tudja csak, hogy mi változott és azt hova írta le. Ha az eredeti volume sérül (mondjuk a raid megborul alatta), akkor a különbözeti adattal se jutunk sokra, tehát a snapshot is elveszik egyúttal.

Amiről Te írsz, az a szimpla backup. Ahol akár block szinten, akár filerendszer szinten átmásoljuk az adatokat egy másik storage-ra. Azzal az a baj, hogy ha a primary storage kicserélődik, és oda vissza van húzva az adat backupból (mert mondjuk az gyorsabb mint visszaszinkronizálni DR site-ról), akkor a storage nem tudja, hogy mi a különbség az új storage adata és a DR között, tehát a DR-ről visszaállás mindenképp teljes sync-et jelent. Ergó tök fölösleges a backuppal bajlódni a primary site-on. Ha borulás van, akkor site-ot kell váltani, nincs mese.

És mi ez a "lehetőség"? Létezik olyasmi program mint az rsync, csak block szinten? Akármi is legyen, végig kell nyalnia a volume-okat összehasonlítandó, hogy mi változott és mi nem, ami biztos hogy nem egy gyors folyamat.

Vagy a 3-site mirrorra gondolsz? Ahol: A -sync-> B -async-> C
De itt most backupról van szó, ez meg már replikáció.

Azt, hogy mit csinalja, nem tudom, nem is lenyeges. Csinalhatja az termek sajat toolja, de mehet a standard backup programmal is.

Csak elmeletileg vetettem fel, minthogy kikovetkeztetheto, nem valoszinu, h valaha is ilyet tennek. Ertelmesebb az, amit az elejen irt Zizi, azaz uj gepet felhuzni ujra, configot deploy-olni es az adatot raszinkronizalni.
Valos esetben ugyis van helyben is egy masolat, ha meg a remote site-ra at kell allni, akkor mar az a legkevesbe erdekes, hogy mennyit ide vagy oda, mas a fejfajas okozoja..

tompos

Meseld mar el kerlek, hogy hol osztottam az eszt. Leirtam, hogy nem ertek hozza, inkabb csak tippelek/erdeklodok, mintsem eszt osztok. Nem is volt kioktato a hangnem - szerintem.

Es az, hogy en jelenleg milyen rendszerek kozelebe szagolok, annak nincs koze ahhoz, hogy engem mi erdekel.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

"a netapp konnyen snapshotol, es ez baromi jo benne, de igazabol jol megvan enelkul egy vmware kornyezet, ugyanis a vmware is tud snapshotolni (meg ha nem is annyira jol)."

csak sajat velemeny: nekem szimptaikusabb a vmwarebol valo snapshotolas, mivel az a memoriat is snapshotolja, s igy futo vm-rol is ertelmes snapshotok keszulnek, amire gombnyomasra visszaterhetek es megnyomom a resume gombot s minden megy is tovabb a snapshotolt allapotbol, mig fs vagy block-device szinten snapshotolva lenyegeben csak a vm-ek filerendszere lesz snapshotolva. mar jartam ugy, hogy zfs-sel keszult snapshot futo vm-rol, ami rollback utan fsck-val inditott nyilvan, es ez annyira nem szimptaikus....
az meg szinten nem tetszik, hogy allitsuk le a vm-et, snapshotoljunk, s inditsuk ujra a vm-et.
ezert szamomra jobb megoldas az esxi-bol snapshotolni, akar futo vm-eket is.

A megoldás a kettő vegyítése:
- VMware pillanatkép létrehozása (memóriás, elcsendesítéses vagy egyik sem)
- NetApp pillanatkép létrehozása
- VMware pillanatkép törlése

Eredmény: csak rövid ideig van VMware pillanatképed, de van egy stabil (olyan konzisztens, amilyet akarsz) tároló szintű pillanatképed.

VMware pillanatképet "hosszú" távon nyitva tartani nagyon nem javasolt 1-2 kivételtől eltekintve, mikor technológiai követelmény (például VDI esetén "linked" klónok, nyilván itt is tudni kell a velejárókat).

A szoftveres megoldásnak mindig nagyobb az overheadje, mint egy hardveres snapshotnak. Egy izmos storage akár 10-20-30 db snapshotot is képes kezelni egy volume-ról (mondjuk óránként snapshotol és egy napnál régebbit törli), míg ugyanez a művelet jelentősen belassíthatja a hosztokat. De ez nyilván terhelés és igény függő...

"szoftveres vs hardveres": a tárolók ezen funkcionalitása inkább szoftveres, mint hardveres :-) (nyilván nehéz meghatározni, hogy hol a határ a kettő között akkor, amikor mindenben firmware van, ami frissíthető)

Egyébként tároló függő, hogy mit mennyire és mennyi ideig lassít be egy pillanatkép elkészítése (és annak fenntartása). NetApp esetén tipikusan nem jelent gondot, mint feljebb kolléga megemlítette: "csak győzze hellyel".

Az esxi nem snapshotol olyan szepen.

Ugye a szepseg kevesbe definit fogalom.
Nagy meretu snapshotnal, tobb snapshotnal, snapshot felszabaditasnal kellemetlen teljesitmenyproblemakat tapasztalhatsz.

A VMFS3-nal mindig, illetve VMFS5-nel, ha storage alrendszer nem tudja a 'VAAI primitive ATS' funkciot, akkor kenytelen a filesystem 'scsi permanent reservation' -t jatszani minden vmfs metaadat update eseten. A snapshot update, thin disk grow, VM stop/start es egyebek vmfs metadat updatevel jarnak. Nagyobb cluster eseten ha egy datastore-n tobb snapshot is van egyszerre, akkor egeszen kellemetlen mertekben zavarhatjak egymast. Emiatt vmfs-en snapshotot nem orizgetunk: amilyen gyorsan lehet, letoroljuk. Ezzel szemben egy jobbafajta storage oldali snapshot nem teljesitmenybefolyasolo tenyezo.

na. most minek megyek ennyire bele.

Nem feltétlenül kell vegyíteni (tény, hogy macerásabb)), attól függ, hogy mi a célod. Ha például annyit akarsz csinálni, hogy éppen telepítesz egy Service Pack-et, akkor van értelme előtte csak VM szintű pillanatképet csinálni, és ha minden ok, akkor le is törlöd (ilyen esetben nem feltétlenül kell tároló szintű pillanatkép). De ha az a célod, hogy legyen egy állapotod 3 óránként 24 órára visszamenőleg, akkor az már orosz rulett kategória VM szintű pillanatképekkel.

A zárolással kapcsolatos problémát leírták, de ezenkívül egyéb problémák is vannak. Például az, hogy egy pillanatkép ugyanakkorára tud "dagadni", mint a VMDK, ennek káros hatása nyilvánvaló: egy elszabadult művelettel simán betelhet az egész VMFS. Ha sok pillanatképes VM-ed van, akkor egyik sem fog tudni hova írni, hatványozottan előjön a probléma.

Ezenkívül a pillanatképek a virtuális infrastruktúra egyik Achilles-ina. Az utóbbi időben kevesebb velük a gond, de jellemzően azért el tudnak néha-néha pukkanni dolgok.

"Például az, hogy egy pillanatkép ugyanakkorára tud "dagadni", mint a VMDK"

Ez a storage szintű snapshotoknál is probléma...illetve teljesen természetes dolog, nyilván minden változás amit meg kell őrizni, csökkenti a szabad helyet.
Storage oldalon tömörítéssel, deduplikációval még lehet játszani, de a hely akkor is annál gyorsabban fogy, minnél több snapshotod van.

Csak nem mind1, h a snapshot elol fogy el a hely vagy a futo szolgaltatas alol:)
Masreszt az ESX snapshotkezelese valoban remes. Lattam mar olyat is, h korrupt lett tole a master image, meg olyat is, h letoroltek a snapshotot, aztan megsem, a support meg napokig javitgatta, mondvan h migralni kell nagyobb teruletre az image-eket:)

tompos

Ez igy ebben a formaban igaz:)

Viszont ahogy Attila irta, joval egyszerubb menedzselni. Pl. vegso esetben akar az is megoldhato veszhelyzetre eseten a, h helyfogyas eseten pusztitsa el a snapshotot a monitorozasbol kiindulva. Na persze mas kerdes, h ha ennyire fogy a hely, valoszinuleg akkor annyit er ez, mint kandisznonak a csocs.

t

NetApp esetén van lehetőség automatikusan töröltetni pillanatképet, ha a kötet megtelne. (VMware esetén nincs ilyen opció)

Ez egy olyan dolog, hogy inkább a visszaállási adat vesszen, mint az éles rendszer álljon le, pech akkor van, ha pont akkor kellene tudni visszaállni, mikor hirtelen felduzzadás miatt törölni kellett. Ha "kellően" van méretezve a rendszer, akkor a "túl sok" tárhely fogyasztásnak statisztikailag kis valószínűsége van, azaz mindenki elfogadja azt, hogy belefér egy ilyen szerencsétlen együtt állás (ha nem elfogadható, akkor több lemezt kell vásárolni - vagy más megoldást keresni, bár valószínűleg nem lesz olcsóbb).

" IBM marketing szoveg, ugyanis ezzel magyarazzak, hogy miert vegyel IBM DSxxxx termeket Nseries ....Ezt tanitjak a gyorstalpalon az mernok presales supportosoknak is."

Semmi közöm az IBM-hez. Ezt az infót mellesleg egy Netapp fejlesztő blogjában olvastam.

"de ugyanugy hozzatesz egy intelligens layert az IBM SVC is a rendszerhez, az IBM megse domboritja ezt a tulajdonsagat ki "

Az IBM SVC utolsó infóm szerint egy storage virtualizációs eszköz. (Mondjuk valami 4-5 éve láttam utoljára, lehet, hogy azóta storage-ot csináltak belőle. :)

"Egy kezi inditasu DR atallasi lehetoseg implementalasa is akkora munka, hogy altalaban nem szokott sikerulni."

Hmm... nem tudom mire gondolsz, többféle módon is meg lehet csinálni egy site szintű DR megoldást, és ha jól számolom eddig 3 félét csináltam is (pontosabban részt vettem benne). Tapasztalatom szerint az ilyet a storage rétegben a legmacerásabb megoldani - de ott sem lehetetlen.

A Fujitsu storage-eket ne keverd a fusival, totál más vállalat. Előre bocsátom, hogy csak kisebb storage-ekkel volt/van eddig dolgom.

Nem biztos, hogy egy giga monolitikus cuccban gondolkodnék, hanem lehet szétszedném kicsit, persze ha lehet. A másik ami itt rögtön meredek kérdésként jön az a backup. Tudom, lehet a storage-ek között mindenféle szinkronizációt csinálni, de azt inkább rendelkezésre állás növelőnek érzem.

Ha jól akarod csinálni, akkor iszonyat időt rá kell szánni. Anno egy sima "egydobozos" storage-re kiválasztása is hónapokban volt mérhető (igaz előtte csak ködös elképzeléseim voltak a témáról) az olvasgatások, tesztek, telefonok és végül a teszt eszközök próbálgatásával. Mindenképp kérjél tesztet minnél több gyártó eszközéből és a mindenféle feature-öket tedd egymás mellé fizetős/nemfizetős stb. szinten.

Az auto tiering nem tudom mennyire játszik, ha napon belül változik az IO igény, mert odavissza mozgatni az adatokat lehet problémásabb, mint helyben hagyni.

A szétszedés felmerült, az EVA kapcsán írtam is és semmi akadálya a dolognak. Backup a storage nagy részéről nem kell - a stratégia az, hogy minimális adatmennyiségből újra tudjuk építeni az adatok jórészét (pl. ha megdöglik egy operációs rendszer, akkor azt nem backup-ból töltjük vissza, hanem újratelepítjük nulláról és rátoljuk a kb. 3MB-nyi konfigot, ami rajta van, ez gyorsabb és helytakarékosabb).

Tudsz mondani (akár magábnan) olyan helyeket, ahol Fujitsu-t használnak eredményesen? Az egyik bajom, hogy nem nagyon találtam ilyen "ismerősöket".

Egy DX80-as (nem S2 és nem is 2,5"-os) ketyeg itt és remekül. A 9 diszkből (a rommá hájpolt saját fw-es ultraszigorú 15k SAS szériából...) egy halt meg 1 év után és jöttek és cserélték szónélkül. Különösebbet nem tudok róla mondani, a webes kezelője jól használható és ez egy iSCSI modell, mert az elég itt és megy. Nyilván örülnénk egy gyorsabb cuccnak, de az FC szolúció nem fért bele a keretbe. Rommá nincs hajtva, de 24/7-ben van terhelés rajta.

Van ráció a szétszedésben, de nagyon meg kell gondolni, mert elég gyorsan nagy nyűg/drága lesz a sok kicsi üzemeltetése (egyrészt munkában, másrészt mindenféle velejárót tekintve, például ilyen-olyan licencek). Arról beszélve, hogy a tárhely kihasználás is sokkal kevésbé lesz gazdaságos.

Egyébként a NetAppnak van a Cluster-Mode-ja, amikor több tárolót egy kalap alatt lehet kezelni, közöttük transzparensen migrálni az adatokat.

Ha már van valamilyen infrastruktúra, NetApp esetén a V-Series is jó lehet, mert nem kell kidobni a meglévő vasakat.

Egy normális tárolót, ami kellően van méretezve azért elég sokrétűen lehet használni.

Tapasztalatom szerint már a 2 is "sok", a 3 "nagyon sok" :-)

Külön tároló akkor szükséges, ha konkrét oka van és meglévő tárolóval nem oldható meg. Ilyen igény lehet: biztonsági mentés, redundancia, teljesen más felhasználási terület (például külső szolgáltatások, tesztrendszerek - de ez utóbbiak esetén erőteljesen "attól függ, hogy" tényező is van ), ...

Ha kicsi egy meglévő tároló, akkor célszerűbb növelni, nem újabbat venni mellé. Persze itt is számtalan tényező befolyásolja a döntést, de a tárolók alapelve egyik alapelve eleve a konszolidáció.

"Tapasztalatom szerint már a 2 is "sok", a 3 "nagyon sok" :-)"
Nagyobb üzemekben 5-6-10...+ storage van használatban.
Pár éve volt olyan gépterem, amibe 1 éven belül csak én telepítettem 3 midrange dobozt, és még pár más storage-os kolléga is betolt oda ezt-azt.
Ahol site szintű DR követelmény (kb. minden valamire való pénzügyi vagy telco cég), ott legalább 2 storage van - de inkább több.

A storage-ok ára és tudása nyilván fejlődik, egyre gyakrabban találkozni velük kisebb helyeken is, ahol tényleg egy darab dobozon van minden - de ez szerintem üzemméret függő dolog, mintsem technológiai.

Sok esetben a költség az oka - senki nem tárol irodai adatokat, mentéseket, arany árban adott enterprise storage-okon a SAP adatbázis mellett, még akkor sem, ha SATA diszket raksz bele.

Ezt írtam én is, de az üzemméret (= adatmennyiség?) pont nem határozza meg elsődlegesen a szükséges tárolók számát, sokkal inkább az üzleti követelmények és technikai/költség okok (legfeljebb velejárója egy nagyobb cégnek, hogy komplexebb követelmények és körülmények vannak).

Technikai ok lehet: van sok telephely, akkor lehet, hogy mindenhova célszerű rakni 1-1 tárolót, mert nem megfelelően építhető ki gazdaságos adatkapcsolat a központi tároló és telephelyi szerver között.
Vagy nem kapni akkora tárolót, ami elbírja az adatokat (vagy egyértelműen túlságosan drága egy nagyobb, mint két kisebb és szerep szerint elkülöníthető, illetve a meglévő nem bővíthető tovább, de luxus kidobni stb-stb).

Üzleti követelmény:
- DR oldal
- valamilyen tárolón levő rendszernek mentés kell (azaz nem azért nem kerül "drága" tárolóra mentés, mert "drága", hanem mert mentést minél függetlenebb környezetbe célszerű tenni, aminek adott esetben alacsonyabb árfekvésű vagy speciális kialakítási eszköz jobban megfelel)
- redundancia
- teszt- és fejlesztői rendszer elkülönítése élestől
- két részleg nem tud megegyezni és inkább mindegyik a saját pénzét költi saját tárolóra
stb.

Ezekhez az igényekhez még FC se kell, iSCSI is lazán elviszi. HP LeftHand (illetve most már átnevezték) is jó lehet. Most bagóért utánad dobják.

Ha meg igazán perverz vagy (és nem fog bizonyos határon túlnőni nőni ez a környezet), olyan szervereket veszel, amelyek meg vannak tömve lokál HDD-vel. Storvirtual VSA liszenszek beszerzése (vagy más VSA, de ez király), és a lokáldiszkekből megcsinálod a redundáns storage-d. Akár 2 normális switchen (szeparált VLANban) elmehet az iSCSI és a "normál" IP forgalom.

Ez így nagyon olcsó tud lenni, és a teljesítménye sem rossz. Persze nem üt meg egy v7000-et vagy 3PAR-t, de azok alapján amit írtál nem is kell.

A lowend storage-okban viszonylag kevés a cache, és mivel nem különösebben extrém a topiknyitó igénye, valószínű egy ilyen storage elbírja akár iSCSI-n keresztül is. Csak a nagy különbség az, hogy mondjuk ezzel kap átlagosan 10-15ms-es válaszidőt, míg egy Storwize esetében ez akár 2-3ms is lehet. Van akinél ez számít, főleg olyan virtualizált környezetben, ahol adatbázisok is dolgoznak.

Ezért nem szeretem a storage-os szakmában az "elbírja", "lazán viszi" és hasonló kifejezéseket. Mindenkinél mást jelent.

Sziasztok!

* Nem vagyok egy spiler a témában *

Az én kérdésem/felvetésem az IBM XIV-ra miért nem gondoltatok/javasoltátok ?
A megadott IOPS-t / kapacitást nyilván tudja, a feature set - a leirások alapján - tudja amire szükség van.

Előre is kösz.

Köszönöm a válaszokat.
Úgy nézki ez lesz a konfig:
IBM Storvize V3700 Dual control
2 db 400 GB SSD
10 db 600 GB 10K SAS HDD
12 db 1 TB 7.2K NL SAS HDD
8 Gb FC csatlakozás

Switchből is az IBM-et választottuk:
2xIBM System Storage SAN24B-4

A V3700-ból lesz még egy backupnak.

Remélem 1-2 hónap múlva már működni fog minden és kioszthatunk pár virtuális gépet ezekről.

V3700/7000 "csak" 2 rétegű automatikus teeringet tud, SAS és SSD között. Tehát az NL-SAS-t gyakorlatilag külön poolban fogod kezelni, ha nem akarod a SAS/SSD pool teljesítményét megfogni. Ergo oda csak kis I/O terhelést, inkább szekvenciális jellegű terhelést tervezhetsz.