Szerver virtualizócióhoz storage kérdések

Red Hat, Fedora, CentOS

Ha szerver virtualizációt szeretnék használni és a virtuális gép image-okat külső tárolón, storagen akarom tárolni, akkor a fizikai szerverek és a storage között milyen gyors kapcsolatot célszerű kiépíteni.
Mert nézegettem a technológiákat.
- Fibre Chanel ami akár 4GBites sőt 8GBites, de úgy tudom elég drága
- iSCSI etherneten, Az ethernet pedig vagy 1GBites akár több összefűzve, vagy 10GBites adapteren.

Ezen kívül van más más lehetőség?
Illetve kinek mivel van tapasztalata. Ár-érték arány hogy alakul, aki esetleg ismer több megoldást is.
Egy storage és két fizikai szerver lenne most. De a bővítésre is figyelnénk, ha az most nem jelent irreálisan magasabb költséget.

  • 12107 megtekintés

( sj | 2012. 07. 05., cs – 09:34 )

Ezen kívül van más más lehetőség?

teherauto megrakva dvd-kkel :-)

milyen gyorsat erdemes? Nagyon gyorsat, mert a latency nem a baratod. De hogy most fc vagy iscsi, az izles, penztarca kerdese, ill. hogy melyiket ismered jobban. En 10G-s iscsi-ra szavaznek...

Miert kell nekem sajnalnom a Klubradiot?

( STP | 2012. 07. 05., cs – 09:43 )

4G-s FC-k már xarért-h..ért vannak.
1db 4G-s FC csatorna kb 5db 1G-s Ethernet sebességét hozza.
És akkor a failover és egyéb dolgokról még nem is beszéltünk.

( asm v | 2012. 07. 05., cs – 10:11 )

10G FCoE is létezik már, de úgy tippelem hogy drágább, mint a 8G FC.

( denke v | 2012. 07. 05., cs – 10:38 )

Szia!

Minden attol fugg...

a kerdes most az hogy milyen storageot akarsz, mekkora a maximalis adatatbiteli sebessege a vinyoknak az altalad valasztott kiepitesben.

2db hddre eleg egyetlen gigabites link is boven, ha pedig rackszekrenekeyt raksz osze storagebol, akkor ertelem szeruen **kicsit nagyobb adatatvitelre lesz szukseged.

Mi a cegnel ket sun 7000 sorozatu storage solutiont hasznalunk, sokezer ugyfel weboldal kiszolgalasahoz a webserek max 150Mbit et forgalmaznak a kozponti storage fele, jo mindjuk a webserverekben is van egy halom ram.

Tehat ha sok kis random io-d lesz, akkor eleg gyengebb kapcsolat is, ha hosszu szekvencialis muveleteid lesznek, akkor nagyobb adatatvitel szukseges

( n.balazs v | 2012. 07. 05., cs – 12:22 )

Már előttem is leírták, hogy nem egészen pontos a leírásod.
Ha csak a számokat nézzük, akkor 10 Gb > 4 vagy 8 Gb. Viszont ezt még ezernyi körülmény módosíthatja.
Csak néhány nyitott kérdés:
- Hány virtuális gépet akarsz a tárolón tárolni?
- Mekkora ezen gépek IO terhelése?
- Milyen jelenlegi eszközeid vannak FC vagy iSCSI irányban?
- Mekkora átviteli késedelmet(latency) engedsz meg a rendszerben?
- iSCSI esetén tudod-e fizikailag is szeparálni a forgalmat?
- A tárolót hány fizikai szerver akarja elérni? Ezen szerverek a storage mellett vagy másik helyiségben/épületben/távol vannak?
- Mekkora üzembiztonságot/redundanciát szeretnél elérni?
- Milyen fejlődési irányok jellemzik a rendszert? Tervezhetsz-e előre?
- Mekkora fizikai kapacitást szeretnél a tárolóban? Ehhez hány lemez kell?
- Legfontosabb manapság: mennyi pénzed van rá?

Ha 2 fizikai géped, 6-10 db virtuális géped, alacsony-közepes(0-200 io/s/fizikai gép), nincs semmilyen eszközöd, a latency nem érdekel, csak menjen, esetleg megoldható az iSCSI forgalom fizikai szeparálása, a tároló a szerverek mellett van(max. 5-10 méter), nincs kereted redundanciára, nem tudsz semmit se előre és 50e Ft alatt akarod megúszni(nem számolva a storage árát) az egészet, akkor iSCSI a neked való. Akár az 1 Gb-es is elég.
Mihelyst vmotiont, HA/Failover működést, garantált késleltetést, redundanciát, időnként magas io terhelést akarsz kiszolgálni, akkor egyértelműen FC. Abból is 4 vagy 8 Gb-es.

Ne higgy annak a fórumnak...
Az a lényeg, hogy ne failover, hanem aktív-aktív legyen a konfig. FC-nél erre általában csak a storage gyártó saját, legtöbbször drága szoftvere képes (pl powerpath), ethernetnél a normálisabb driverek tudják. Viszont ez leginkább csak egy switch-en belül műk (bár vannak technikák az ellenkezőjére).

Itt van egy jó leírás keresztkábelre mérésekkel:
http://serverfault.com/questions/287475/why-does-my-gigabit-bond-not-de…

Ha switch esetén nem jön ki ez a sebesség, akkor a switch konfig, vagy a switch hátlap nem jó (attól hogy van rajta 48db 1Gb port, még lehet hogy a hátlap szumma teljesítménye is 1Gb, ez főleg az olcsó eszközöknél simán előfordul).

Egyetértek az általad írottakkal. Viszont azért írtam neki azt a választ, mert valószínűleg nincs sok pénze komoly eszközökre komoly szoftverekkel. Powerpath pedig EMC-hez van és fizetős. Az apróbetűs részbe nem akartam bevinni. Ráadásul ha olcsó eszközökből építkezik, akkor sokkal hamarabb belefut az általad is írt backplane korlátba.

Az egészre az adta az ötletet, hogy van egy ilyen termék, most promóciós áron. S6BS
Aki kattint látja. :-)
És akkor már nézzük meg, hogy ki mit kínál a piacon kb. ezen vagy ehhez hasonló áron!
Elkezdtem "túrni a netet", mert az első kérdés ami megfogalmazódott bennem, hogy két szerver egy storage felállás esetében a szerverek és a storage között az 1GBites Ethernek sovány kapcsolat lehet.
Az FC-t és az iSCSI-t találtam meg mint lehetőségeket, de általánosságban.
Ezek után tettem fel a topik indítóban a kérdést.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Haladunk a konkrétumok felé :) Ez jó jel.
Érdemes mindenképp átgondolni, hogy milyen irányban fejlődsz/fejlődhetsz. Ez alapján érdemes gyártót és modellt választani. Pl: a SAS lemez jó, de drágább, mint a SATA. Viszont nagyobb tárterület kell, akkor olcsóbb a SATA. Továbbá ellensúlyozni lehet a SATA teljesítményhiányát a RAID tömbben lévő lemezek számának növelésével. Vagy mondjuk az IBM DS3200-nál ha 8 gépnél többet akarsz rákötni a storage-ra, akkor kiegészítő licencet kell venni. EMC/Netapp gyártóknál nincs ilyen limit, ellenben van más.
Az mindenképp jó döntés, hogy telepakolod a keretet. Az S6BS modellt skálázhatod, így elvileg megteheted később, hogy 1 keret SAS, 1 keret SATA stb. SSD még szerintem nincs bele. Így később szépen eloszthatod a gépeket kevésbé/nagyon io igényesekre.
EMC Clariion(új nevén: VNX) sorozat tagjainál megtehetted, hogy egyszerre volt FC és iSCSI csatoló is az eszközben. Így eleinte használhatsz iSCSI-t, majd ha tényleg óriási teljesítmény kell, akkor áttehetsz 1-2 gépet FC-re. Opció lehet még a SAS csatlakozás is. Így nem kell storage-ot cserélned. Netappnál nem ismerem a helyzetet, de szerintem ők is kínálják ezt a lehetőséget.
Ha érdekel 1-2 részlet, akár árakkal együtt, akkor keress nyugodtan privátban.

A 2040 nagyon az alja. Mint a BMW 316 fapad. Kicsi, nem megy, kurblis a hátsó ablak, de ha csak hirtelen ránéz valaki, irigykedik rád :-)
A netapp baromi jó funkcionalitásban, de ebben a kategóriában ezt fizeted meg, azaz komoly teljesítményt és komoly redundanciát ne várj. Ha azt is beleteszed, elszalad az ára :-)
Bár az az igazság, hogy egyelőre 2 szerverrel fogod hajtani, amire vsz ez is jó. Még többre is.

FAS2040-em van, 2-3 fizikai vassal és Citrix Xenserverrel.
A storage 3x1GB iscsi-val lóg a switchen (valójában duál kontrolleres duáls switches, 2x3x1Gbit, de ne bonyolítsuk. :) )
A szerverek 2x1Gbit active-active multipath.

Kb. 20 vpst szolgálnak ki, szokásos LAMP vackok, 1-2 windows szerver, és még egy ora adatbázis.

Semmi panasz nincs rá, az átlag latency 5-15ms körül van.
A tapasztalat az, hogy kis méretű (~8k) random io esetén baromi jó az iscsi, mert jumbo frame esetén ez kb. a csomagmérettel megegyező io méret. (A LAMP, és mail szerverek általában ilyen IO pattern-el mennek.)

A FAS2040-ben elég nagy controller cache van, ami aztán a backend-re már optimalizálva szépen ki tudja tolni az io-t. Hála a linux hígfos multipath megoldásának, egy szerverrel nem tudtam kiterhelni (tesztre meg nem volt több), de ettől függetlenül 1Gbit iscsi-n 9-10k Iops-ot is rá lehet tolni, és bírja.

Más kérdés, hogy a nagy IO méretű alkalmazások esetén (pl. file szerver nagy fájlokkal) relative lassúnak tűnhet a cucc.

Ezen nem veszünk össze :-)
Jó kis cucc, ha elég . Ahhoz viszont nagyon ismerned kell az I/O profilodat, hogy ezt látatlanban eldöntsd. Nálunk egy régi 2050 lakott anno, vmware alatt hamar besokallt a random I/O miatt. De jól tette a dolgát évekig. Csak komótosan :-)
Amúgy egy géppel kihajtani nem feltétlen a linux miatt nem tudtad, akadtam már fenn alaplap sávszélességen. Nagyjából ezért nem vagyok x86 párti, bár az ára miatt nagyrészt én is azzal tolom.

"Ahhoz viszont nagyon ismerned kell az I/O profilodat, hogy ezt látatlanban eldöntsd"

Mivel meglévő cuccot kellett rátolni, pár napig mértem, mielőtt döntöttem, hogy jó lesz -e az iscsi....

"úgy egy géppel kihajtani nem feltétlen a linux miatt nem tudtad"

De. A Linux iscsi multipath (legalábbis ami a Citrix xenserver6 alatt van) egy 2x1Gbit aktív-aktív linket csak max 1Gbitre tud kitekerni (~120MB/sec -et sikerült fél nap tuning után kihúzni belőle).
(szerk: és tuti aktív-aktív volt, mert mindkét switchporton kb fél-fél Gbit forgalmat mértem egyszerre)

Ha szétszedtem a multipath-ot és külön-külön olvastam a két linket, akkor linkenként megvolt a 120-120MB.....

Nem hiszem, hogy egy DellR510-nek alaplapi problémája lenne, úgy, hogy két külön NIC-en volt a két link.

nem.
Egy linuxxal is rá tudtam tolni 2Gbit-et, de csak akkor, ha külön-külön húztam az egyes path-okat.
Ha ugyanaz multipath-ban volt, akkor a multipathon keresztül csak 1 gbit ment.
Ráadásul a két útvonal két külön switchen megy. (A switchek relative használható HP Procurve-ok)

Azért ott még van pár paraméter amit lehet állítani :) kétségkivül azok már nem a LB-t szolgálják.
Sose csináltam még aktiv-aktiv ISCSI-t, de gondolom ott is bonding van (LACP). A bondingnál meg tudtommal 1 ip címről csak 1 interface-nyi sebességet lehet elérni (1 Gbit), nem lehet hogy ezért nem tudsz többet elérni? Bár nem irtad, de a PP sem hozhatott akkor nagyobb eredményt.

Nem tudom, hogy meglehet e csinálni, de ha van időd és lehetőséged próbáld ki. A bonding-ra felhúzol még 1 virtuális ip-t, a LUN-okat ezen is láttatod majd az mpath-t finomhangolod. (ne 1000-en legyen a rr_min_io, storage gyártói beállítások beállítása,stb).
A te esetedbe nem a multipath-t gondolom problémásnak hanem a bondingot, ugyanez a conf HBA-kkal csont nélkül menne.

"Sose csináltam még aktiv-aktiv ISCSI-t, de gondolom ott is bonding van (LACP). "

Nem lacp.
A szerveren két külön iSCSI-ra dedikált port van, 2 (külön IP hálózatban levő) ip-vel, 2 switchbe dugva, storage oldalon szintén 2 interfész, a két switchbe 2 IP-vel.

Ha szerver oldalon a két útvonalat külön-külön dd-vel olvasom (azonos időben) akkor mindkettőt kiterheli a drótsebességig.
Ha a multipath álltal létrehozott eszközt olvasom akkor csak 1 Gbit (mindkét switchen az adott portokon 50%-os forgalommal). Tuti, hogy a multipath a szűk keresztmetszet, és hasonló problémákról olvastam is mindenfelé a neten, de megoldást sehol nem láttam.

Mivel Citrix Xen servert használok, ami ugye -most hirtelen nem ugrik be melyik- linuxból építkezik, ezért ez nem opció sajnos. :)
Egyébként teljesítmény problémát nem jelent a dolog, a redundancia sokkal fontosabb, az meg megvan. (Legalább is ellenált minden tönkretételi kísérletnek a tesztek alatt:) )

"Bar 4/8G FC eseteben mar nagy jelentosege nincs"
Ezt hogy érted? Már hogy lenne mind1, hogy 2x4Gbit-es kártyából csak 4Gbit-et vagy 8-at húzol ki.

4x4Gbit-es kártyából ezt húzatom ki egy DB alatt, nativ mpath-al, és itt már a kártyákat érzem szűk keresztmetszetnek:

read kbyte/s
1197535.07
1152126.53
1317793.47
1216466.13

Ugy ertettem, hogy 4/8Gbps eseten tobbnyire mar mas szokott lenni a szuk keresztmetszet.
Persze szintetikus tesztekkel (tipikusan soros olvasassal, mint pl. dd) lehet feszegetni a hatarokat, de egy reallife DB eseteben mar aligha. Eleg csak azt kiszamolni, hogy 2x4Gbps link es 4kB transfer size eseten ~250kIOps jon ki, amihez mar high-end es/vagy sok SSDs storage kell, amit meg tipikusan nem csak egy gep hasznal.

Szoval csak azt akartam irni, hogy 1G-s iscsi eseteben sokkal fajobb a path kihasznaltsag mikentje, mint 4/8G-s FC-nel.

Ok akkor én értettem félre. Viszont egy valamire való adatbázis read-nél nem 1 blokkot olvas fel hanem sekvenciálisan a következő X db-ot (beállítás kérdése), így már nem 4k-nként kell I/O-zni, amugy manapság még használnak 4k-s blokk méretű DBket ? :)
Amit írtam az reallife DB terhelés (napi betöltés) és nem szintetikus teszt, a határt vagy a kártyák adják vagy a switch oldali portgroup de tuti nem a storage a kevés, sajnos SSD-nélküli a storage, de pár hónap múlva fogok egy 9 modulos XIV-t tesztelni amiben lesz már 3 TB-nyi SSD, igaz csak cache-re, na arra leszek kiváncsi, hogy ott mit produkálunk :) Viszont ezt az iscsi problémát még mindig nem tudom megemészteni.

Úgy emlékszem próbáltam párhuzamosan 2 dd-vel is olvasni, de már nincsenek meg a tesztfeljegyzéseim.

Szerintem egy szállal sem kéne szűk keresztmetszetnek lennie. Ráadásul arra nincs befolyásom, hogy a
guestek hogyan olvassák a multipath dev-et.

FC multipath nem tudom mennyiben más. Elvileg nem, gyakorlatilag a multipath és iSCSI együttesen is okozhatják a tüneteket.

köszi, átfutottam anno azt a thread-et, de nem nagyon figyeltem rá, most újra elolvasva van benne 1-2 érdekes dolog.
1 LUN volt a tesztek alatt, azóta több van, majd méregetek kicsit ennek fényében.
Nagyon nem kritikus a dolog, mert 2-3 hónapja élesben megy a cucc, és elég jó a teljesítmény még így is.

Óriási +1.
Még azt is megkérdezheti, hogy vázolják fel neki az esetleges fejlesztési lehetőségeket, hogyan és mennyiért tud feljebb lépni a kategóriákban(belépő->közepes->high end), megoldható-e vezérlőcserével a feljebb lépés vagy komplett új tárolót kell venni.

Bővíteni a kapacitást tekintve lehet, külső 12 HDD-t fogadni képes "tálcákkal" ha jól emlékszem a kifejezésre.
Most ebben a promóciós konfigban van 12x600GB HDD, amivel 4TB körüli hasznos tárterületet biztosít.
Inkább az lenne még a kérdés, hogy ha eleve van benne két FC csatoló, akkor a két szerverbe elég egy-egy FC csatoló és közvetlenül mehet a Staragera mind a kettő, vagy kell még közé valami? Pl. FC-elosztó, vagy FC-Switch, vagy valami hasonló, mint Ethernet esetében a Switch.
Közben ezt a leírást találtam: http://netappsky.com/wp-content/uploads/2010/12/fc_iscsi_config_guide_8…
Eszerint megoldható, hogy egy 2 FC portal rendelkező Storage, egy-egy FC-prorttal csatlakozik egy-egy összesen két szerverhez. A 2db FC port egyenként 4GBites.
Most már az lenne a kérdés, hogy a szerverbe milyen FC kártya kell és azt támogatja-e a RedHat 6.xx Linux? Mert ugye akkor a CentOS is. Illetve a Debian Linux, mert akkor a Proxmox is.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Jól látod a helyzetet.
Switch nem kell ebben az esetben. Viszont ha lesz 2 vezérlőd vagy több géped, akkor nem úszod meg a switch betételét és az FC hálózat teljes konfigolását.
FC kártyából Qlogicot használtam, nem volt vele gond. Qlogic OEM partnere is több gyártónak.

Kb. reális a 4T, amit ír.

Ezt kb így lehet kihozni FAS2040 esetén:
Ha két controller van, akkor a max. hasznos területet úgy lehet kihozni, hogy az egyik controllert csak failoverre használjuk. Ekkor neki kell 2 diszk raid4-be, amiről bootolni tud. (spare nem kell neki.)
A maradák controller 10 diszkjéből elvesz egyet a spare, kettőt a RaidDP paritás diszkjei.
Marad 7 diszk adatra.
A 600GB-s diszkből effektíve kb. 580GB használható, 7x580 = 4060GB, tehát kb. 4T körül lesz a hasznos terület.

szerk:
A konfig controller és diszk szinten redundáns, az adatkapcsolat 1-1 FC esetén nem lesz az.
Az adatok/futó szolgáltatások kritikusságának függvényében ennyi kockázat még talán beleférhet.
(A rendelkezésre állást egy plusz FC kártya raktáron tartásával lehet javítani, ha megpusztul a szerverben, akkor egy gyors csere, és megy minden tovább.)

Rhel5 alatt még nagyon nem így volt, mióta van ez így? Ugye beszélni kéne hozzá a storage nyelvét, az meg nem fizetős driver esetén nehéz, bár nem lehetetlen. Anno raktam össze hp c blade qlogic mezzanine kártyához kísérleti qlogic driverrel forrásból, behazudott disztró verzióval, mert asszem 5.2 alá akkor még nem volt hp driver, az alkalmazásnak meg minimum ez kellett, powerpath meg kilógott a büdzséből. Clariion cx700 még AP módban sem komázta a sima multipathd próbálkozásait...
Kevés dologgal szívtam ennyit, mondjuk az egyik büszkeségem is. 3 hétig játszottak vele az üzemeltetők, utána projekthatáridő előtt egy nappal megkértek, ami a szabim előestéje volt. Reggelre kész volt :-)

UI:persze pár héttel később kijött a hp driver :-)

Rhel5 alatt teszteltem IBM XIV-t DS8000-et és DMX-4-et is és mindet tudta csont nélkül a nativ mpath. Sőt olyan szitut is csináltam, hogy 2 különböző gyártó (EMC és IBM) storage-ából kaptam a LUN-okat és mind2-re más config-ot állítottam, mert ezt tudja a nativ mpath még a PP nem.(PP-be sehol nem találtam erre lehetőséget). Továbbá a PP-nek előjött egy nagy hibája, hogy 1024 device fölött meghülyült, és a kblockd process az összes CPU-t 100%-on pörgette emiatt, még a nativ mpath 3000 device-ot is simán kezelt hiba nélkül.
Viszont abban teljesen igazad van, hogy az mpath-al is lehet szopni. Az EMC storage-nál pl 1 hétig szívtunk egy rohadt mpath bug miatt, mert a hivatalos doksi amiből néztük a beállításokat a vendort máshogy írta mint ahogy kellett és emiatt nem vette fel a beállításainkat sőt a defaultot se, amit az mpath elején létrehozol, hanem egy totál idióta beállítást ami miatt a teljesítmény iszonyú szar volt (70%-al rosszabb). A storage oldalról, meg azt láttuk, hogy X percig az 1ik FC van 100%-on még a másik X percbe meg egy teljesen másik. A mpath-nál ajánlom a -v3 vagy nagyobb opciót ilyen esetekbe mert én is csak ott vettem észre, hogy totál más beállításai vannak a LUN-oknak mint amit én beírtam a configba.

Egy kis részlet a mérésekből:

PP-vel a napi betöltésből egy kis szelet:

Read kbyte/sec

516176.67
598996.67
558183.33

Ugynaz a betöltés nativ mpath-al jól bekonfigurálva:

Read kbyte/sec

775961.13
877051.82
877388.60

Összesített időben a betöltés:
nativ mpath: ~9,5 óra
PP: ~ 11 óra

( bazso | 2012. 07. 05., cs – 14:04 )

Storage-od van, vagy most akarsz venni? Gyakorlatilag a storage tudása dönt el mindent :-)

Hány nullában lehet gondolkodni, és mekkora bővülést terveztek?
Ha jól tippelek, akkor alsó kategóriára fogsz lőni, ez esetben minél butább legyen a storage, hogy az adott árban ne a funkciót, hanem a vas teljesítményét fizesd ki.
Nullák száma:
5: pécé hákolás (erre én egy zfs klasztert tennék kis ssd-vel megtámogatva buta DAS(ok) elé iSCSI vagy NFS megoldással, az utóbbit amúgy eléggé tolják a virt vendorok, azaz nem lehet annyira rossz)
6: noname NAS/SAN megoldások (el vagyok kényeztetve, ebben nem tudok segíteni)
6,5: Fujitsu/HP belépő szintű, de meglepően használható SAN cuccai
7: Bármelyik neves storage gyártó alsó közép kategóriás cucca. Itt alapvetően SAN-ra lőnék, de ennyiért már jó NAS is van.
... (igen, van tovább :-) )

( Akela | 2012. 07. 05., cs – 23:02 )

InfiniBand-et is megnézheted, de nem lesz olcsó

( p2pking | 2012. 07. 06., p – 00:29 )

Milyen IO igeny van ?
Redundancia
Tarhely igeny netto
Ezek sebessege

es legfokeppen

Mennyit lehet ra kolteni ?

Ez meghataroz mindent.

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

( PunishR v | 2012. 07. 06., p – 07:44 )

És mi van akkor, ha bejön a képbe egy 2. lokáció disaster recovery céllal? Milyen eszközök tudnak szinkront tartani a két lokáció között?

InMage scout. Oemben több storage gyártó pl Hds és Oracle erre épít
San traffic replikátorok. Appliance megoldása több gyártónak is van.
Veritas
Netapp V series
...

Igényfüggő. Milyen vonalad van, kell e cdp, San v. Nas, oprendszer bevonható e vagy natív storage szolgáltatás kell, alkalmazás üzleti konzisztenciát kell e tartani, stb.

( STP | 2012. 07. 06., p – 08:29 )

Fusit itt -korábban- többen dicsérték (talán trey, andrej?), és leírás szerint is jónak tűnt, csak azok a f@sz öltönyösök baszták el, hogy vegyünk is olyat. De egy kört megérhet.

Több helyen is használunk élesben Fujitsu DX60-at, DX80, DX90-et 1Gbit/s iSCSI kontrollerpárokkal VMware-rel. VMotion, Storage VMotion, lop, szop, bakot ugrik. Teljesítménye SMB-re kielégítő.

Andrej tőlem vette. Eddig nem panaszkodott. Vagy nem mert :D

Ezekben a vasakban el lehet indulni akár 6/3 Gbit/s SAS vagy 1Gbit/s iSCSI host interface-ekkel, amik később igény szerint cserélhetők 10Gbit/s iSCSI-re, 8/4/2 Gbit/s FC-re vagy 10Gbit/s FCoE-re. A doboz ugyanaz marad. Viszonylag kis befektetéssel indítható a projekt, majd ha lesz még lóvé, akkor lehet bővülni.

--
trey @ gépház

Az itt nem fordul elő, hogy nem merünk panaszkodni. :) Hyper-V-vel is remekül megy a live migration. Még azt is kipróbáltuk hogy a VoIP-os (Asterisk, semmi extra) VPS beszélgetés közben mit szól a live migrationhoz. Egy fél szó maradt csak ki, az is a switchport/mac változás miatt valszin. :) Ez mondjuk nem pont a storage érdeme, de jó volt.

A sima DX80-as nagyon pöpecul megy valóban, de azóta már van DX80S2 is. A DX80-on 2x2 1Gbit-es iSCSI port van rajta és mi 4 Win2k8r2-re pakoltuk rá, amiken Hyper-V van. Megy az iSCSI active-active felállás is a két vezérlőre és elcsoszog. Itt nincs különösebb IO igény, hanem a stabilitás az ami számít. A DX80-at bekapcsoltuk, megy és amit ráírtak azt szépen hozza.

Azóta egy másik projektnél/cégnél egy Infortrend 8G-s FC dobozt is megnéztünk és az is szépen hasított, bár a webes admin felület messze elmarad a Fujitsu-tól. Az Infortrend előnye, hogy 2x4 FC vagy iSCSI portot tud, illetve nekik is van hibrid cuccuk. További előnye, hogy nincs diszk hisztéria sem, bár ez erősen ízlés kérdése. Én inkább szavazok "sima" SAS diszkes megoldásra, úgy hogy a polcra teszünk N darab tartalékot, az X órán belüli érkezőssel szemben. (Szerverteremben lesz a pakk, ezért nélkülünk úgysem fér hozzá a szupportos.) Erről már volt N darab thread itt, ne kezdjünk újat. :)

Jahh a teszthez kaptunk vinyókat is és érdekelne hogy az alábbi együttállást hogy sikerült összehozni:
- Dell Enterprise diszkek
- WD (igen, western digital) antisztatikus zacskóban
- A diszkek típusa ST..., tehát a Seagate 600GB/15kRPM-es volt...