Storage tapasztalatok: MSA 2300, DS3500 vagy egyenértékű

Flame

A $subjectben jelzett tároló családról mindenféle tapasztalatra lennék kiváncsi. A handbookokat, manualokat már átnyálaztam és nekem személy szerint az IBM szimpatikusabb. Az a problémám, hogy elfogadható review-t, tapasztalat leírást csak minimálisat találtam neten ezekről és nem szeretnék "csukott szemmel" rábökni az egyikre, hogy "naakkorazjólesz".

A "nehasználj iscsi-t", "ez fos" stb. oldalt is már körüljártuk és ez tűnik a megfelelően flexibilis és finanszírozható útnak nekünk. Egy direkt SAS vagy FC konfigból nyilván erősebb sebesség kihozható, cserébe vehetnénk egy rakás HBA-t, szóval már több ilyen körön túlvagyunk.

Természetesen ha valaki FC vagy SAS porttal használja, akkor is érdekel a tapasztalata kezelhetőség, megbízhatóság és sebesség szinten.

HP vonalról az MSA 2312i típust néztük ki és IBM-ből pedig a DS3512-eset. Mindkettő dual-controller és iSCSI opcióval szerelve jönne.

Amire használnánk...

X darab HP szerver (DL3xx) kiszolgálása és persze virtuális gépek alá adná a storage-et a nyertes doboz. Az extrém überhiper sebesség nem a legfőbb szempont, hanem legyen megbízható és főleg rendesen kompatibilis. Operációs rendszer szinten Windows 2k8 R2 (mint host és guest) és 2k3 (mint guest), valamint Xen-es Linux (Debian/Ubuntu mint host) és Debian/Ubuntu (mint guest) fordulhat elő. Az IBM-nél különösen érdekes kérdés, a partició upgrade, hogy ez a gyakorlatban mit jelent, mert nekem a doksikból az jött le, hogy ez gyakorlatilag a storage-re tehető gépek számát adja meg és nem a logical volume-ok számát.

Ami nekem személy tetszik az IBM-ben, hogy kb. minden gépünkhöz tudunk csinálni 1-1 redundáns 2x1Gbit-es kapcsolatot és nem "csak" 2x2 port van a target oldalon. Az IBM gui-ja (már ami lejött a képekről) is szimpibb és összeszedettebnek tűnik.

Később előfordulhat, hogy a megfelelő EXP vagy MSA expansion dobozokkal bővítjük, tehát akinek ilyesmi konfiggal van tapasztalata az se tartsa magában. (Mennyire egyszerű beállítani a bővítő dobozt, mennyire hisztis a dolog, stb.)

Hálózat...

Mindenképp redundáns MPIO-s setupban gondolkodunk (az ezzel való tapasztalatra különösen kiváncsiak vagyunk), szóval a két darab 24 portos gigás L2 managed switch az meglesz és a 2x1Gbit-es port is a szerverekben. Perpill switch szinten HP E2510-24G-t néztünk, amikről szintén jöhetnek tapasztalatok. A Cisco 2960S szériája nem fér bele a költségvetésbe, de akinek van összehasonlítása alapja az előzővel azt szívesen veszem.

Aki árul ilyesmit...

Már kértünk be ajánlatot és tisztán látszik, hogy EUR-ra, USD-re kb. ugyanazt adja mindenki, mert nem éri el a HP vagy IBM "központi ingerküszöbét" ez még. Ettől függetlenül aki úgy érzi, hogy tud valami jót ajánlani az privátban megteheti. Garancia szinten minimum 3 éves helyszini kell. Diszk szinten 15k RPM 600GB SAS az elvárás és mindenképp 3,5"-os modellben gondolkodunk, ami redundás táppal szerelt.
Kb. 10k EUR környéke a plafon amit az egész "csomagra" szánhatunk.

Aki szerint más dobozt kellene venni...

Erre is nyitottak vagyunk, nincs még semmi sem eldöntve. A fenti két típusra kaptunk normális árat és a konfigjuk szerint jónak tűnnek. A fentivel egyertékűre és küldhet árat aki úgy érzi, hogy érdemes.

szerk:
- 3,5"-os modell + redundáns táp
- budget

  • 5348 megtekintés

( trey | 2011. 03. 24., cs – 10:33 )

A HP-ból van ügyfeleknél itt-ott, de nem VMware alatt.

A fent részletezetthez hasonló felhasználásra több Fujitsu Eternus DX-et használunk. A kezem alatt közvetlenül Eternus DX 80 van. iSCSI-n vSphere 4. Egyelőre 1 VC, 3 ESX host, Windows, Linux virtuális gépek (fájl-, SQL szerverek főként vegyesen). Teszi a dolgát és árban jó volt. Ha nincs brand megkötés, akkor esetleg érdemes megnézni a Fujitsu-t is.

Azt lehet tudni, hogy milyen árat kaptatok? Akár privátban is.

--
trey @ gépház

a cucc az, hogy FAS3070 -ek tarolnak es Hyper-V pedig ezeket iscsi -val eleri.
Onmagaban mukodnik rendben... bar erdekes, hogy tortennek komikus es megmagyarazhatatlan dolgok.

target ott van, csak epp valaszol, viszont nem megy semmi.
gyarto szerint kliens ujrainditas.. es ez tenyleg megoldja, csak nem elegans :)

az EVA szemelyes preferencia, EVA12K -val egesz jo dolgokat lehetett regebben muvelni :)
Jo, nem sir a szam, a TagmaStore ok sem rosszak ( ua. hitachi :))

Az itt felsorolt cuccok és az EVA közt árban van egy min. 6x szorzó. Az is vicces, hogy az MSA-k (fibre) képesek ráverni teljesítményben a kisebb EVA-kra, ha azokban kevés diszk van. Az EVA-k is akkor kezdenek el gyorsulni ha megfelelő számú diszkkel (vagy inkább tömött diszkdobozzal) gazdálkodhatnak.

Egy EVA-t 8 diszknél kevesebbel nem lehet inicializálni, minimum 8 kell a default disk group-ba (vagy 6 SSD). Ahhoz, hogy dolgozzon is, jócskán a pénztárcába kell nyúlni. A dual portos fiber HDD-k nem olcsó mulatságok. OK, hogy EVA, de azért nem érdemes ágyúval lőni állandóan verébre.

--
trey @ gépház

NetApp-ot (az a bizonyos FAS :) mi VMware és natív Linux környezetben használunk (régebben iSCSI, most NFS) és nincs vele problémánk.

A storage választáshoz azt javaslom, hogy amit tudsz, próbáld ki magad (ha te fogod utána használni). Azt tudom, hogy NetApp-éknál van olyan lehetőség, hogy megigényelsz egy rendszert (storage, oprendszer), amit összeállítanak neked és tesztelgetheted x napig (természetesen távoli eléréssel). Lehet, hogy más gyártóknál is van ilyenre lehetőség, majd a többiek megmondják.

NetApp-ot tudok neked élőben is mutatni, ha érdekel, illetve ha van kérdésed, szívesen válaszolok.

Akciós árakat NetApp-hoz itt találsz: http://www.storage-akcio.info/ , illetve konkrét rendszerre is szívesen kérek neked.

( kisauto | 2011. 03. 24., cs – 13:12 )

szóóóval, nemtudom

hogy "olcsósítsunk" és ha már XEN ről is beszélünk, lehet NetApp -ot raknék be és a kernel kivételével a root -ot nfs -re tenném, ami nyilván a storageról jönne. Ilyet cisnál XEN is, nem? Szal nem zavarja, ezt nem tudom - bár gondolom miért ne mountolna, az is csak linux...

Illetve, IBM -et nem ismerem nagyon :(

( p2pking | 2011. 03. 24., cs – 13:22 )

Trey amit irt erossen megfontolando, ez volt az elso ami nekem is beugrott.
IBM particios trukk nagyon odafigyelos, zsebbenyulos lehet.

HP switch az tapasztalatom szerint agyonverhetetlen, nagyon stabil, es jol teljesit, tehat csinalja amit kell.
Forgalom szintjen nemtudom mi szamit nagynak, de 500Mbit koruli terheles eszrevehetetlen neki.

Storage particíó. Röviden: Veszel mondjuk 4-et (asszem az az alap amit adnak a kütyüvel), ez azt jelenti h. annyi host groupot tudsz létrehozni a dobozban. Ha többet akarsz később akkor venni kell ilyen csacskaságot h. "storage partition upgrade 4,8,16,etc." amiből a 8-as mondjuk majd' egy misi.

( djsmiley v | 2011. 03. 24., cs – 16:57 )

Egzotikusként tudom még mondani a Hitachi AMS-t, tudja amire szükséged van és Active-Active redundáns a kontroller. Sas1 diszkekkel, vagy akár SATA-val. Egy kört megér, nálunk az IBM 35xx-at "ütötte".

http://www.storage-valaszto.hu/

Üdv,
Zoli

Hello,

Röviden megpróbálom összeszedni a főbb érveimet, ami miatt nálunk a Hitachi jobban bejött az IBM-el szemben. (DS35xx vs. AMS2100)
1. Nincs "management program", vagyis van, de weben éred el, java-s, bárhonnan tudod managelni a storage-et, IBM-nél telepíteni kell a gépedre, stb.
2. Hitachiba lehet rakni SSD-t, Entry level DS-be nem.
3. A kontrollerek redundanciája, a failover események kezelése, a belső terheléselosztás (ilyet eddig szinte csak a Hitachiban láttam, konkrétan bemész az 1-es kontroller A portján a gépeddel, de mégis a kettes kontroller dolgozik) nagyságrendekkel jobb és gyorsabb a Hitachiban.
4. Cache particionálás és blokkméret szabályozás (különböző LUNokhoz, különböző cache blokkméret a jobb allokáció érdekében)
5. Cache residency - kis méretű, nagy io igényű LUN-t be tudsz tolni 1-1-ben a controller cache-be
6. Cache méret (IBM max. 2G, Hitachi 4G)
7. Upgrade: DS35xx-nél nincsen lehetőséged fejlődni a kontroller oldalon. Hitachi AMS2100 kontroller cserével bővíthető AMS2300-ra (8G cache, stb.)
8. SAS backplane felépítése elvileg jobb a Hitachiban (de ez kicsit marketing duma szerintem)
Végül egy ellenérv (én ezt az egyet találtam amikor hasonlítgattunk őket): Hitachi SAS, IBM pedig SAS2.

Azt tudom még mondani, hogy a cég aki foglalkozik a Hitachival nagyon korrekt, jó a support, ugranak, intézik. A fenti weboldalon is díszeleg a logojuk, csak hogy ne csináljak nagyon direkt reklámot. (M-el kezdődik :))

Üdv,
Zoli

Annyit tennek hozza meg, hogy mostanaban volt firmware upgrade az Ams-eken, van olyan hosztom ami csak az A controllerre van radugva 1 tyukbellel. Termeszetesen eszre sem vette h. a storage eppen rebootolja az A ccontrollert, ment szepen az IO rola, mintha semmi sem tortent volna. Ezt egy entry level IBM tuti h. nem tudja, de meg lehet a midrange sem.

( hackac | 2011. 03. 24., cs – 21:09 )

1. Mi HP LeftHandeket használunk, csak a deduplikációt hiányolom belőle. Listaárból rendesen lehet alkudni, és feature szinten is korrekt. A dobozok között is tudsz RAID-et csinálni, így a rendelkezésre állás sem gond. Ha előrekonfigolt pl. xx starter editiont veszel, akkor eleve 2 node jön, és 2 port/node van. 10GB/sec-es kártyával is bővíthető. Node bővítésnél a teljesítményed közel lineárisan skálázódik. Tud MPIO-t, de VmWare alá nem kell MPIO driver (meg ehhez vmwareből az enterprise liszensz, mert a kisebbek nem esznek küldő modulokat), mert tudja a teljes SAN magát 1 IP-n prezentálni, vmware oldalról meg a beépített driverrel tudsz multipathot csinálni. Funkcionalitása meglehetősen széles. HP-t tudok szállítani, LeftHandnél konfigot is vállalok.

2. Ha nem ragaszkodsz az iSCSIhoz, akkor nézd meg a Coraidot. AOE-t használ (ATA over Ethernet). Mivel ez sokkal vékonyabb protokoll,iszonyat sebességet tud kitolni magából. A drivere olyan, hogy a LUN-t blokk eszközként tudod felcsatolni szinte bármilyen oprendszer alá. Korábban míg garázscég voltak áruk is baromi jó volt, de most is versenyképes. Tudok kontaktot adni ehhez ha kell.

3. Ha nem kell enterspájz megoldás (nam ragaszkodtok nagy szállítóhoz), akkor egy 12 diszkes szerver, NL SAS vagy SAS diszkek, és Openfiler. Nem nyilatkoztál hogy SAN oldalról mit kell még tudnia azon kívül hogy prezentál egy LUN-t. Stabil, jól működik. Csak arra vigyázz, hogy ha advanced 4k-sdiszkeket tolsz bele, akkor alignolni kell a partíciót, különben lőttek a teljesítménynek. Meg a bővítés lehet problémás, ha 1 nagy LUN kell valamiért.

Uff, én beszéltem :)

Ott valami gond lehet akkor, rossz helyen kopogtatsz vagy hasonlo. Listaaron senki nem vesz semmit, az csak azert van, hogy legyen.
Ha elhiszik neked, hogy tenylegesen vevo vagy, akkor teteltol fuggoen a listaar fele, 60% a is lehet a vegso vetelar.
Gyarto annyiert adja a termeket amennyiert akarja, ha lat benne fantaziat, akkor 1Ft ert is odaadja, mert esetleg mas reszrol ez neki csilliardszor megterul.

Kiktol kertel be ajanlatot ?

Ha HP termek melett dontesz, akkor tudok adni a ket harom legnagyobb partnercegnel kontaktot.

Azert jo, mert ha tudjak, hogy egymas ellen kell menni a szart is kiverik engedmeny szinten a gyartobol, csak toluk vedd es nekik is legyen nemi penzuk...
Gondolom ertekesitesi darabszam miatt is jo nekik.

Ha gondolod PM.

( andrej_ v | 2011. 03. 31., cs – 09:45 )

Helyzet értékelés

Mindenek előtt szeretném megköszönni az ajánlatokat és különösen a tippeket, tanácsokat, amiket 1-1 beszélgetés alkalmával kaptam. Továbbra is kiváncsi vagyok mindenféle a topikban szereplővel (nagyjából) egy kategóriában levővel kapcsolatos tapasztalatra, mert az ajánlatok jelentős túlsúlyban voltak. :)

A hálózati oldalon a managed switchet elhagyjuk és helyett 2 darab rendes Gbit-es lesz. Ezzel rögtön egy olyan 1000EUR-t lehet átcsoportosítani a storage oldalra.

Storage oldalon a NetApp és Hitachi doboz bőven kívül van a költségvetésen így ezek kiestek, bár tudásban elég impresszívek (a tervezésbeli különbségek más). A jelenlegi listavezető a Fujitsu Eternus DX 80-as doboza, mert lehetőség van demóra és az ajánlat is kedvező. A demó nagyon sokat számít, mert értelem szerűen így nem egy "vak" vásárlás.

Már nyúzzuk. :) Miután jó iqn-t adtam meg a kliensen rögtön ment jól Lucid alól is. :)

Most az MPIO-val küzdök, de a két vezérlőt az active-active módra nem nagyon sikerült rávenni.

Egyébként az első benyomás az, hogy igen masszív darab és a szimpla gigás iSCSI linket még 1500-as MTU-val is könnyedén kitömte.

"Már nyúzzuk. :) Miután jó iqn-t adtam meg a kliensen rögtön ment jól Lucid alól is. :)"

Akkor ez ezek szerint megoldódott. Éppen válaszolni akartam a leveledre, hogy én élesben csak VMware-rel nyomatom, de ment szépen Linux-szal is.

"Egyébként az első benyomás az, hogy igen masszív darab és a szimpla gigás iSCSI linket még 1500-as MTU-val is könnyedén kitömte."

Jónéhány virtuális gép (fájl, SQL, web, stb. vegyesen) fut nálam róla, alig néhány IOPS terhelés látszik alapjáraton. Mentéskor is alig megy fel. Most éppen egy 500GB-s virtuális gép mentését csinálja a VDR. A read IOPS 116, a write 4. A diszkek foglaltsága eközben 3-4%.

--
trey @ gépház

Bocs, hogy belekotyogok. :-)
Alacsony IOPS és/vagy lemezterhelés két dolgot jelenthet:

1) nincs teljesítmény igény

2) alacsony IOPS igényt tud kiszolgálni a rendszer

A kettő lehetőség közül a választ a tároló CPU és/vagy uplink terheltsége tudja megadni.

A VDR tapasztalat szerint nem jó I/O terhelhetőség megállapítására, mert a VMDK-hoz kapcsolatos I/O műveleteken kívül rengeteg egyéb tevékenység tud belassítani (például a céltárhely sebessége, deduplikáció, több VM-mel kapcsolatos adminisztráció, cbt elemzése...).

Szia!
Leírnád, hogy néz ki ez az architektúra?
Ami nagyon érdekelne, hogy hyper-v -ben hogy oldottad meg az etherchannel-t/bonding-ot, windows-ban asszem Teamingnek nevezik (bár tudtommal ez csak failover-t csinál, load balanceingot nem, de cáfoljatok meg, ezzel sose foglalkoztam).
És ami még érdekelne, hogy a storage-on az iscsi portokat, hogy kötöd etherchannelbe vagy itt nem használtok redundancyt?

Nincs bonding vagy etherchannel. Egyszerűen az MPIO-val oldjuk meg, legalábbis próbáljuk. Amikor még a 0-dik fázisban voltam a projekttel fejvesztve kerestem bonding-ot támogató dobozt, de csak a Promise-ban láttam, hogy supportált.

Esetünkben minden portnak külön IP-je van és így összesen 4 path mehet egy volumue-hoz.

Akkor visszatérnék az eredeti kérdés másik részéhez :)
A klienst azaz a hyper-v -t gondolom etherchannelbe rakod a switch portjain keresztül, mert jó hogy a diszkeket az mpath hibatűrővé teszi, viszont a hálózatot nem. Gondolom ez is kritérium, ez érdekelne, hogy windows alatt, hogy megy, virtual interface-ket felhúzol erre a teaming-re és különböző vlan-okba berakod őket? A teaming tudtommal csak failover-t tud, loadbalance-ot nem, viszont a teaming-hez meg nem kell etherchannel-es switch ez tényleg így van ?
Itt is lehet controller-enként firmware upgrade-t csinálni vagy ezek az eszközök még nem képesek erre?

Értettem pedig elsőre is. :) Multipath-al kis odafigyeléssel a hálózat is hibatűrő lesz, sőt mi rögtön két switchet fogunk használni. :)

(A és B portok a 0-ás ctrl-en, C és D portok az 1-es ctrl-en. A és B portok az Alma switchen keresztül mennek, míg C és D portok a Körte switchen át. Minden szerver egyik "lába" az Alma, másik "lába" pedig a Körte switchbe lóg. A multipath-ból kifolyólag ha A vagy B vagy Alma switch vagy a 0-ás ctrl "elköszön", akkor a Körte switchen át megy tovább az élet. Még ha csökken is a maximális kraft, akkor sem száll el egyben az egész. A terv az, hogy minimum 2Gbit-es sávon legyen alaphelyzetben elérhető egy gép számára a storage doboz. Ezen még természetesen finomítunk, gondolkodunk, de én alapvetően ilyesmit álmodtam meg.)

Ez így oké storage szinten, én szerintem félreértettem ott a dolgot, hogy azt hittem összesen 2x1 port van a kliensnek és ezen osztozik a storage és a public vlan is és hogy ez is HA-sitva legyen.
Amúgy miért az A és B port megy az alma switch-en ? miért nem az A és D ha már etherchannel-t nem tudsz csinálni storage szinten, akkor így switch és ctrl együttes elhalása ellen is védve lennél, bár ennek elég kicsi a valószínűsége :)

Ezért írtam az előző hszem :)
Mert ha A és B megy alma switchbe C és D meg a körtébe, ahogy előtte írtad. Ha elhasal az alma switched és nem vetted észre de neked firwware upgrade kell mindenképp, C és D ctrl-ed mikor upgradeled akkor úgye leállítod, és máris ott a kiesés :) Mert hiába van rákötve a másik működő ctrl-ed az alma switchre ami valamilyen hiba miatt nem működik :)

Tehát a DX 80 nyúzás alatt van és az EMC is úgy néz ki rámozdult a tesztre.

Azt halkan jegyzem meg, hogy több esetben rögtön előkerült a teszt lehetőség, amint említésre került, hogy már kapunk tesztre dobozt... Nem lehetne rögtön azzal kezdeni, hogy komoly érdeklődés esetén van? Tudom, hogy ez alapvetően gyártói hozzáállás kérdése is, de azért...

( meroksz | 2011. 04. 12., k – 11:47 )

Szia

Nem túl régen mi is storage vásárlásba fogtunk. DS3500-ös egy DX80 volt a két kiválasztott, aztán hirtelen képbe jött a NetApp2020A.
Ds3500-őt elég hamar kiejtettük, elmondták hogy ne is álmodjunk arról hogy kifogjuk hajtani a max-ot, de még csak tetszetős értéket sem. IBM-et nem teszteltük.
Dx80-ból egy SAS 15K diszkekkel megrakott cuccot kaptunk tesztelésre (hála hála hála!!!) Ez volt szembe a FAS2020A-val amibe SATA diszkek voltak.

iozone volt a tesztelő alkalmazás, nem voltunk túl kíméletesek 23+ órás volt egy teszt. Eredmény az hogy a szekvenciális írás terén a DX80 azért verte a 2020A-t, viszont a random I/O esetben teljesen meglepő módon a 2020A tartotta a lépés, nem egyszer le is hagyta a DX80-at.
NetApp mellet szólank bizonyos funkciók. Pl adat deduplikáció, amire nagyon építenek, pl a snapshot-olással ami zseniáliasn megy pont azért mert nem COW modon történik....kvázi nincs lassulás sok snapshot esetén sem. A DX80 egy egyszerűbb eszköz, pont ezért egyszerűbb konfolni is a NetApp DataOnTap oprendszeren azért tud bonyolodni.

Virtuális gépeket fogunk rajta futtatni, jó csomó szolgáltatással nekünk a random I/O a minden :). Tudom nem erről kértél tapasztalatot egy alternatívakét gondolj a dologra.

És +1 mert az mindig jó. Nagyon jó a support, vettünk egy 4 órás csomagot, és működik. Nem volt triviális a gondunk de jött minden hardware ami kell és jött is a mérnök aki nekifogott és megcsinálta.

Bocs, a kési válaszért.

Tényleg nem írtam bele, mi a NetApp FAS2020A mellet döntöttünk, a random I/O teljesítménye illetve azért mert NAS (NFS-t használunk user home , ráadásul a snapshot-ot automatán vissza tudja NFS ki ajánláson csatolni) és SAN (iSCSI VM-ek számra) képességeket egyszerre biztosítja.

Üdv

Nem vagyok nagy szakértő, de szerintem a adatdeduplikáció a megoldása.
Csinálsz egy spanshot-ot egy Vol-ról. Mikor abban változás történik akkor nem az lesz hogy az orig adatot elmozgatja, egyszerűen csak az újat kitesz egy helyre. És azzal játszik hogy melyik adatot honnan ""linkeli""

11111111 alap adat erről készül snapshot, ""linkelve"".
első bitet invertálni kell!
a snapshot nem változik az összes ""link"" marad ugyan arra a adatra
a változást kiteszi a diszkre
majd az eredeti adatsort első bitjének a ""link""-jét az uj adatra állítja.

Ezzel ugye a snapshot tranzitívan nem írodik felül mert nem file szintű a dedu, hanem block szintű.
Persze ez auért a NetApp saját kis titkai között szerepel hogy pontosan mit csinál. Ami nekem egyértelmüen lejött hogy a nagy fícsör gazdagság abból jön hogy adat dedup jár minden eszközükhöz, saját RAID-DP architektúra, .....

Ára az valóban nem az amit a piacon kifizet az ember. a mi eszközünkket akcióba vettük, 3M föltött volt telepakolva 1T diszkekkel, dupla node (storage processor) a HA miatt. Most is van akciójuk : http://www.storage-akcio.info/

Legvégére FIXME ha marhaságot beszélnék

A deduplikáció egyetlen fícsör a sok között, a NetApp tárolók erejét/alapját nem ez, hanem a WAFL adja, főleg a pillanatkép funkció, erre épül számos szoftveres szolgáltatás.
Főleg FAS2020 esetén azért a deduplikációt érdemes tervezni, mert van erőforrás igénye, illetve korlátai is. Ha SATA lemezes tárolótok vannak, akkor vigyázzatok azzal, hogy mekkora köteteket hoztok létre és miként, nehogy túlcsorduljon valami.

A pillanatkép NetApp esetén úgy történik, hogy a tárolásban van egy köztes mutató réteg, amihez az adatelérés fordul. A mutató pedig effektíven a szükséges adatterületre mutat.
Pillanatkép esetén íráskor létrejön egy új adatterület és a pillanatképhez tartozó mutató átáll az új adatterületre.

"Mennyi pénzért": nem 10x-es az ár, ez minden NetAppban alapból benne van. Ha olyan az üzleti környezet, hogy tesztrendszereket kell generálni vagy hasonló funkcionalitás, akkor nagyon-nagyon hasznos. Pillanatok alatt létrejön egy teljes klónod a teljes adattartalmadról úgy, hogy teljesítmény vesztésed sincs. Ezt nem sok tároló gyártó tudja produkálni.
Tény, hogy a NetApp nem a legolcsóbb, de tárolót manapság már nem úgy kell/célszerű venni, hogy x TB adat. Fel kell mérni az üzleti igényeket (nehéz, mert sok esetben nem is gondolná az ember, hogy mi mindenben segíthet egy tároló), és összeadni a megvalósítás összegét. A szumma *lehet* az, hogy a drágább tároló összeségében olcsóbb.

Ezt leirnad magyarul? A mumagyarral nem boldogulok:)

Nem akarlak megserteni, de a marketing szovegre nincs szuksegem. Had tudjam, hogy erdemes kivalasztanom az eszkozt:O)

Mindenesetre koszi, tenyleg erdekel, hogy mukodik, mert vhol kell csalnia, hogy ketszeres legyen az adat, nem?

udv,

t

Szerintem eléggé magyarul írtam le, de akkor döntsük el, hogy angolul vagy magyarul kommunikálunk, az öszvértől a hideg tud kirázni :-)

Ha valaki felhoz 10x-es költséget, akkor arra nem lehet másként reagálni, mint "üzleti igények" (nagyon igyekeztem olyan dolgokat említeni, amiknek valós hátterét is látom, a deduplikáció kapcsán például lásd kicsit korábbi hozzászólásomat; konkrétan amiatt nem érdemes NetAppot venni, de ha van NetAppja, akkor érdemes lehet használni felmérve a korlátokat és buktatókat).

Szívesen segítek mélyebb technikai kérdésekben is tudásom határáig (sőt, akár mélyítem is tudásomat, ha olyan merülne fel). Néhány támpont a témával kapcsolatban:

- http://media.netapp.com/documents/wp_3002.pdf (itt NFS-ről és fájlrendszeről van szó, de mivel NetApp alatt a LUN-ok is fájlok, ezért arra is igaz)

- http://everest.natur.cuni.cz/konference/2010/sponzori/storyflex/prezent… (12. oldal - angolul van, szép ábrával)

- http://www.ess-direct.com/pdf/whitepapers/storevault/WP_Snapshot_062606…

Csak hogy meglegyen itt is, masok is lassak, itt a lenyeg (nagyon gaz, hogy a pdf nem valodi hasabokkal keszult...:)

"It is important to understand the limitations of non-NetApp
mplementations of Snapshot technology. Competitive offerings
typically read and then write the old data to a new location before
writing out the new data. This is often explained as a feature called
“copy on write.” But this “feature” adds dramatically to the system
overhead: for each block of data changed in the copy on write
process, there is a read and two writes, compared to a single write
for NetApp. By using NetApp Snapshot technology, you benefit
from faster backup of data and reduced backup window time."

t

( andrej_ v | 2011. 09. 11., v – 19:09 )

Nemrég lezárult a fenti storage beszerzése és már a telepítésén/beüzemelésén is túl vagyunk. A nyertes a Fujitsu DX80-as lett, ami trey-ektől érkezett a sikeres teszt üzeme után. A modell egy 2x2 iSCSI portos darab, aminek a sebességét a nekünk szükséges felhasználásra jónak tartjuk. A "doboz" webes gui-jának használhatósága is jó és szerencsére nem ilyen hipermodern csoda. Az round-robin active-active multipath-t kis bénázás után Win 2008R2 alatt szépen sikerült beállítani és jól láthatóan eloszlik a terhelés.

Mindenkinek köszönjük a segítséget, amit itt, emailben vagy akár telefonon kaptunk. Nagyon sok hasznos infót kaptam, amik alapján szerintem a jó irányba tudtunk elindulni.

Számomra nagyon tanulságos volt, mert ahogy a nyitó hozzászólásban írtam, eddig a gépekbe integrált RAID-ek világában éltünk. A külső storage egy teljesen más megközelítést kíván. Erre egy lapáttal rátesz, hogy ahány gyártó annyiféle megközelítést kell a saját igényekre ráhúzni vagy jobb esetben megtalálni azt ami lefedi az igényeket.