Storage LUN és egyéb adatok értelmezése

Merevlemezek, vezérlők

Hi!

Nézegetek egy EMC VNXe3150 Dual Storage-t. Virtuális gépek (Xen) snapshot-jait tárolnám rajta, illetve Win 2008-nak ajánlanám ki iSCSI-n (vagy CIFS-en).
Sajnos eddig sem storage-al, sem iSCSI-vel nem volt dolgom így lenne pár kérdésem a hozzáértőkhöz.
Specifikáció szerint:
   Supported LUNs Up to 256
   Maximum LUN Size 2TB
   Maximum FS Size 16TB

Jól gondolom, hogy a LUN az, amit a win-nek ki tudok ajánlani és majd azon partícionálni tudok? (Illetve linuxnak is odaadhatnám, sőt ott LVM-be is foghatnám?)
Az tiszta, hogy MBR esetén 2TB a korlát GPT esetén ez 16 Exabytes, de itt akkor a LUN miatt egyben "csak" 2TB-ot tudok majd odaadni?

A 16TB-os FS Size limit arra vonatkozik, ha magán a storage-n készítem el a filerendszert és ezt majd pl. CIFS-en osztom meg a win-nel?

Előre is köszönöm a felvilágosítást!

  • 8993 megtekintés

( szekelyk | 2013. 09. 27., p – 16:28 )

Így van a LUN a blokk storage amit SCSI diszknek lát a szervered. Az FS limit pedig a NAS részre vonatkozik amit CIFS protokollal megosztásként (share) látsz.
Szerver oldalon összefoghatsz több 2TB méretű LUN-t.

Tegyuk hozza, hogy manapsag mar az LVM is tud mirrorozni. Nem mondom, hogy ajanlanam, egyszeruen mert sosem hasznaltam, de van ilyen feature.

Viszont az eredeti kerdest nem nagyon ertem. Pontosabban a kerdest igen, de az okat nem. Miert csinalnal tobb LUN-t az EMC-n ha aztan meg Linuxon ossz akarod vonni oket?

Az LVM nagyon régóta tud mirrort, ha jól emlékszem, valamilyen szinten egyéb RAID funkciókat is.
Csak nem a linuxos port. Abba tényleg nemrég(viszonylagos) került bele. Cserébe k. lassúnak érzem.
Igaz, virtuális környezetben próbálgattam, de a hagyományos (mdadm...) tükrözés mellett iszonyatosan lassúnak tűnt.

Vagy csak képzelődtem. :)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ez elgondolkodtatott.... ugyanis rendes, fizikai HDD esetén LVM-et hogy is csinálok? Az egyszerűség kedvéért veszek 4db HDD-t, RAID1-be teszem 1,2(md0) ; 3,4(md1) majd ezeket fogom LVM-be.

Storage esetén viszont maga az eszköz gondoskodik a rendelkezésreállásról raid5,6 stb. formájában. Mivel van egy "hálózati réteg" mint hibalehetőség, így az LVM előtt csak kellene valami raid. Tehát - ha jól gondolom - akkor ez esetben a storage által kiajánlott LUN-okat a storage-ban nem kellene raid-be tenni, mert azt a szerveren - az iSCSI-n felolvasott LUN-okat - az LVM előtt úgyis raid-be kell tenni.

Jól gondolom, vagy valamit jól benéztem/félreértettem?

Vagy ez már nagyon elvetemült? (egyenlőre elvi síkon ismerkedem a storage-val)

A VNXe rendszerrel ezt nem fogod tudni megtenni mivel RAID 10,5,6 típust ismer. Tehát ezek valamelyikébe kell szervezned benne a fizikai diszkeket.
http://www.emc.com/collateral/hardware/specification-sheet/h8515-vnxe-s…
A VNXe az EMC termékpalettán kisvállalati storage körbe tartozik, ennek megfelelő limitált konfigurációs lehetőségekkel.
A dokumentációhoz, regisztráció után a support.emc.com oldalon keresztül férhetsz hozzá.

Storage rendszereken az általad leírt megoldás nem szokásos eljárás. Még korábban a VNX sorozatot megelőző Clariion modellekben elvileg ki lehetett osztani fizikai diszket szervernek. Ezzel a gyakorlatban nem találkoztam, nem is próbáltam. Ilyet még tudtommal a Coraid tárolók tudnak, ahol fizikai diszke(ke)t adhatsz szervernek és ott tetszőleges RAID védelmet beállíthatsz.

Ok. ;
Első körben elegendő a 2TB, viszont ha már tervezünk, akkor szeretek úgy tervezni, hogy 1 év múlva, amikor elérjük a határt, ne akkor keljen kitalálni a "hogyan tovább"-ot.

Mondjuk az igazsághoz hozzátartozik, hogy magam sem tudom eldönteni, hogy az iSCSI vagy a CIFS kiajánlása lenne a jobb win2008-nak? A 2TB-os "nehézség" miatt a CIFS felé hajlik az ügy.

Igazából az a kérdés, hogy úgy általában mit szeretnél. Redundáns tárolót tipikusan azért vesz az ember, hogy ne legyen SPF a rendszerben (ez még önmagában nem elegendő, de szükséges feltétel). Ha iSCSI-n kipublikálsz egy területet, amire Windows-on belül teszel NTFS-t, és ezt publikálod CIFS-sel, akkor lehet, hogy olcsóbb egy jobb minőségű szervert venned: ha az a szerver elpukkan, akkor nincs szolgáltatás, hiába dolgozik szépen a tároló a háttérben. (ha virtualizált a Windows, akkor az megint egy másik kérdés, ott van-e valamilyen redundancia, de akkor már inkább VMDK legyen vagy hasonló legyen az NTFS alatt, ha mindenképpen Windows-ból szeretnéd a megosztást).

Ha eléred a 2TB-ot, akkor dinamikus kötetet tudsz csinálni, így újabb LUN-t hozzá tudsz fűzni az egészhez. A növelés nem jár leállással. De azt is lehet, hogy másik tárolót választasz, ha zavar a 2TB-os limit (például BitLockert szeretnél futtatni és 2008r2-nél újabb Windows-ról van szó) :-)

Van egy megbízhatónak nevezhető Dell R510-es szerver, rajta Win2008 R2. Erre menne egy vállalatirányítási rendszer, aminek 7x24-ben kellene futni.
Az SQL adatbázis mérete még elhanyagolható lenne, néhány GB, viszont mindenféle "mellékes" adatot is becsatolnak majd, ami már nem az SQL-be kerül letárolásra, hanem file szintjén (.pdf, .jpg, .xls, .doc, stb.).
Másik telephellyel folyamatos szinkron lesz, így az adatbiztonság is meglesz, de egy szerver megállás esetén tartósan oda nem tudnak dolgozni a sávszélesség miatt, tehát mielőbb újra kell majd éleszteni az elhalt rendszert.

És akkor itt jön a kérdés, hogy a szervert "túrbózzuk fel", vagy storage-t vegyünk az adatok alá?

Storage mellett szól, hogy a virtuális gépeink snapshot-jait is ki tudnám rá kényelmesen tolni, egy bővítés is viszonylag egyszerűbbnek tűnik, sőt az újabb virtuális gépeket már eleve a storage-ra tenném.

Erősen a storage felé hajlom... amennyiben CIFS-ként csatolom a storage-t és arra teszem a "mellékes" adatokat, úgy egy szerver halál esetén akár egy "kommersz" gépre felhúzott win-hez felcsatolva máris mehet tovább a meló (SQL meg leszinkronizál a távoli szerverről).

Átgondolva most számomra ez tűnik jó megoldásnak. Természetesen minden építő, javító kritikát szívesen veszek.

Ezúton köszönöm meg bognarattila-nak az építő és elgondolkodtató hozzászólásait - na meg a többieknek is az észrevételeket!
Köszönöm!

Ezalatt mit értesz? "virtuális gépeink snapshot-jait is ki tudnám rá kényelmesen tolni" Valamilyen virtuális gép mentés?

Nyilván sok minden ismeretlen számomra ebben a rendszerben, de egy redundáns tároló hosszú távon mindenképpen jól tud jönni, főleg virtualizációval karöltve (és megfelelő infrastruktúrával körbebástyázva), a rendelkezésre állás nagyon jól megnövelhető.
A másik telephellyel való szinkronizáció miként valósul meg?

Annyi, hogy a jelenlegi felállás szerint nem látom, hogy hol használnád ki a tároló redundáns mivoltát ("mellékes" adatok vannak rajta és mentések, ehhez elegendő lenne valami olcsóbb eszköz is).

Én azt csinálnám, hogy a tárolót megvásárolod, az R510-en futó Windows-t bevirtualizálod és a tárolóról futtatod, majd mikor legközelebb lesz pénz, akkor veszel egy második szervert (ami a tartalék erőforrásod) és kiegészítő eszközöket (switch is redundáns legyen kiszolgáló oldalon).
Persze azt is figyelembe kell venni, hogy most az R510-en milyen lemez terhelés van, hogy a megvásárolt tároló ezt ki tudja-e szolgálni (lemezek minőségében és számában, illetve a transzport protokoll vonatkozásában), illetve az R510 RAM és CPU ügyileg is milyen terhelés van, esetleg kell-e RAM bővítés (CPU nem várható).

Xen alatt több win és linux virtuális gép fut LVM-en, erről készítenék snapshotokat (backup).

A másik telephely szinkronja SQL szintű.

A "mellékes" adat inkább mellérendeltet jelent. SQL-ben szerződés adatai, de ehhez a rekordhoz csatolva ott lesz a ténylegesen aláírt szerződés színes scannelt példánya.

Köszönöm az ötleteket, sok mindent figyelembe kell venni és átgondolni, hogy hosszútávon hogy is lenne jó.

Nem, szeritnem nem jol gondolod.

A RAID megved teged a diskek hibajatol, ezt elintezi neked a storage-od. Ha a halozati hibaktol akarod magad vedeni, akkor nem a diskeket kell raidbe rakni (host oldalon), hanem a halozatot... Azaz redundas halozat kell a storage meg a host koze. Az EMC-ben ez eleve megoldott, tobb kimenete van (ugye?), az kell hogy a hostban is tobb kartya legyen es kulonbozo utvonalakon erje el a storage-ot. Ha a storage-ra nem kozvetlenul csatlakozik, akkor persze a koztes halozatnak is redundansnak kell lennie -> tobb switch.