SAN/iSCSI - használat/tapasztalatok/vélemények

Merevlemezek, vezérlők

üdv.!

első sorban azokhoz intéznék itt kérdéseket -meg gondolom majd mások is-, akik menedzselnek ilyen eszközöket.
részemről rögtön a sűrűjébe is vágok:

kipróbáltam amolyan hobbi projekt szintjén, hogy AOE protokoll segítségével hogyan működik egy Windows XP rendszerindítása, illetve ezen keresztüli használata.
ugyanolyan rugalmasnak tűnt a virtuális lemezről használni, mint fizikai hdd-ről. kérdés persze, hogy ha terhelve is volna a belső hálózat -ami nem gigabites-, vagy a szerverben lévő merevlemez, akkor hogy viselkedne...

gondolom ezen technikák inkább a biztonsági mentésekre vannak kihegyezve, de ha már egyszer lehetőség is van a képfájlból való rendszerindításra, akkor ugye miért ne kísérletezzen vele az ember :)

valahogy olyan érzésem van, hogy az egyszerű pc-ből fabrikált szerver, amiben sata lemezek vannak, kevésbé adhat jó teljesítményt akkor, ha 2-3-4 munkaállomás is szeretne egyidőben írni/olvasni a neki kiosztott képfájlban/ból.

arra volnék kíváncsi, hogy van-e értelme szoftveres alapokon kivitelezett SAN eszközről éles irodai rendszert működtetni (mondjuk legfeljebb 20 munkaállomás esetében), mely esetben nem kell merevlemez a munkaállomásokba, illetve ha van, akkor mi alapján tervezhető egy ilyen infrastruktúra, hogy aztán használható is legyen az egyszerű irodai munkavégzésre?

üdv.: bth

  • 2556 megtekintés

( willy v | 2011. 04. 15., p – 15:58 )

Milyen a nem szoftveres SAN amit irodai környezetbe szánnak? Hogy legyen értelme is hogy hozzászóltam: a tárológép méretezésén múlik az egész, a hálózat méretezhető elég szépen, a diszkalrendszernek abban a gépben amely megvalósítja a SAN-t kell jónak lenni. A kérdés az, kijön e a SAN előnye irodai környezetben. A jövő mindenképp a centralizált adattárolás irányába mutat. A bootolás meg természetes dolog, Ez is csak egy block eszköz, lehet nagyobb IOPS-t kapsz mint ha lokális diszk tenné ugyanezt.

mivel még kopasz vagyok a témában, ezért próbáltam így különbséget tenni a két megoldás között:
-olcsó hobbi projekt részemről
-drága céleszközök a piacon

szerintem irodai környezetben a következő előnyök jöhetnek ki, bár inkább fillérezésnek tűnik:
-nem marad/nincs adat a munkaállomáson
-nincs hdd benne, r-go egy hibalehetőséggel kevesebb, egy biztonsági mentés rumlijával kevesebb
-némi energiatakarékosság, éves szinten észrevehető talán
-akár csendesebb munkaállomások

hátrányok:
-ha megdöglik a munkaállomás alaplapja, ígyis úgyis telepíthetjük újra az egészet, ehhez pedig kell egy fizikai lemez
-ha nem figyelünk oda a szerver raid köteteire, lemezeinek állapotára, hamar borulhat az egész
-ha a szerver -mert egyedül van- megáll, megáll az iroda is
-mit nem soroltam fel?

--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző

a centralizált megoldásoknál a központi kiszolgálók és a hálózat redundanciájára jobban kell figyelni. (Ahogy írtad is, ha megáll a szerver vagy hálózat, akkor senki nem dolgozik.)

Ha nem csak tisztán hobbiprojektről van szó, hanem felmerült gyakorlati alkalmazási lehetőség is, akkor nézz szét desktop virtualizációs témakörben is. (Mostanában ez a trendi irányzat. :) )
Mondjuk egy 20 munkaállomásos környezet kb. a határeset legalja a desktop virtualizálásnál .

Az ehhez hasonló megoldásokat nagyobb munkaállomás számnál szokták alkalmazni, mert a központi infrastruktúra jóval többe kerül mint a "hagyományos" topológia, és kliensenként pedig relatíve viszonylag kicsi a megtakarítás.

jelenleg hobbiprojekt, az év vége felé szeretném bevetni egy kis gépszámú irodában. feltéve hogy:
-a jelenlegi cat5 vagy cat5e kábel -nem én húztam be a padló alá- viseli a gigabitet
-cseréljük a switchet és néhány hálókártyát gigabitesre
-a munkaállomások ugyanolyan, vagy hasonló teljesítménnyel fognak üzemelni mint jelenleg
-hobbiprojekt kísérletek olyan eredménnyel zárulnak, mely alapján bátran állítom át az irodát

a kis gépszám jelenleg 5 asztali gép és két laptop az adott helyen, ahova ezt szánnám, bár nem tudom, mennyi értelme és haszna lenne átállni "vékonykliens" üzemmódra. még vacilálok rajta.

a virtualizálással az a nyűgöm, hogy a jelenlegi történetet csak windows szerver közreműködésével lehetne kivitelezni, ahhoz pedig nem fűlik se a fogam, se pedig a gazda pénze.
a jelenlegi működés pont azért lett így tervezve/kivitelezve hogy alacsonyabb költségvetésből hozzuk ki a legtöbbet.

--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző

Egyébként mit vársz ettől a megoldástól? Milyen előnyt fog nyújtani a jelenlegihez képest?

nem, nem fog kevesebb áramot fogyasztani, nem lesz halkabb, ugyanannyi adatot kell továbbra is menteni (igaz, azt egy szerverről), viszont ha nem lesz jól megcsinálva (ami sanszos, mert kicsi a költségvetés) akkor bejön egy ordas nagy single point hibalehetőség a rendszeredbe.

Ahogy én látom ez inkább csak műszaki érdekesség és egy jó projekt a részedre, de pénzügyi megtérülését nem látom. Vagy esetleg vannak konkrét megtérülési számításaid?

Mindenesetre sok sikert, írhatnál majd róla, ha beüzemelted, mert projektnek egyébként érdekes.

mit is várok ettől a megoldástól?
túl sok áramot nem takarítunk meg, szóval ez nem ütőkártya mellette.
én inkább pontosan ettől félek, ha beleugranék, hogy bekövetkezik az "ordas nagy single point". ezért inkább, ha már ezen töröm a fejemet, redundánsként oldanám meg...
műszaki érdekesség számomra ez tény.
konkrét megtérülési számításaim nincsenek, mert egyrészt nem ismerem a kimondottan céleszközök árait, illetve még csak azt kalkuláltam, hogy kb mit esznek a gépek a helyen az áramból, illetve ehhez képest mibe kerül a fejlesztés.
véleményem szerint azon a helyen két-háromszorosa lenne a beruházás költsége, mint amennyit a beruházás utáni egy év alatt megspórolnék.

mindenképpen postolok róla valamit, csak még elő kell kukáznom 5-6 asztali gépet, hogy lássam, mikor mit művel ez a történet egy 100 megabites hálózatban, egy pc alapú szerverrel.

--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző

Szerintem ez jó pár évig nem lenne kifizetödő, főleg ilyen kis cégnek, ( meg mire kifizetödő lenne addigra már rég elavulnak ezek az eszközök), mivel így a storage és a hálózatot teljesen redundansá kéne tenned, hogy ne legyen single point of failure.Nem tudom mik az elvárások de nem hiszem, hogy örülnének, ha a storage vagy a hálózat lehalása miatt az egész cég megállna. Hobby kisérletnek nagyon jó. Hobbyként akár virtuális gépekkel is összeállíthatod ezt a környezetet, viszont ott nem fogod tudni letesztelni a teljesítményt, de már fogod tudni hogy állísd össze a környezetet, amikor majd a teljesítmény mérése lesz a fő cél és nem kell a 10 "összekukázott" gép elhelyezésével és áramfelvételével szívnod.

Oké de akkor meg ne nyavajogjon ha pl a switch elhalása miatt megáll az egész cég :)

Egy saját kérdés, mapth szakiknak:

xxxxxx (3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) xx-xxx xxx,xxxx
[=xxxxG][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=200][active]
\_ 1:0:13:4 sdbc 67:96 [active][ready]
\_ 2:0:0:4 sdbk 67:224 [active][ready]
\_ 0:0:0:4 sdc 8:32 [active][ready]
\_ 3:0:13:4 sddk 71:32 [active][ready]
\_ round-robin 0 [prio=40][enabled]
\_ 1:0:10:4 sday 67:32 [active][ready]
\_ 2:0:1:4 sdbo 68:32 [active][ready]
\_ 3:0:10:4 sddg 70:224 [active][ready]
\_ 0:0:1:4 sdg 8:96 [active][ready]

Ezt én így értelmezem:
4 porton, 2 controlleren és 1 fabric-en keresztül látom a diszket.
A kérdés ha a felét látom ennek:

xxxxxx (3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) xx-xxx xxx,xxxx
[=xxxxG][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=200][active]
\_ 1:0:13:4 sdbc 67:96 [active][ready]
\_ 2:0:0:4 sdbk 67:224 [active][ready]
\_ 0:0:0:4 sdc 8:32 [active][ready]
\_ 3:0:13:4 sddk 71:32 [active][ready]

Akkor az azt jelentí, hogy a csak 1 controlleren át látom a diszket?
És controller upgrade estén nem fogom látni a diszket tehát kiesésem lesz.
Mert a storage-os kollégával nem teljesen értjük meg egymást, és ez lehet az én hibám :)

Válaszokat előre is köszönöm.

Attól, hogy egy tárterületet (gondolom LUN-okat osztasz meg, nem lemezeket egyenként) egy vezérlőn át látsz, még nem jelenti azt, hogy nem lenne redundáns a rendszer: frissítés esetén illik átkapcsolni a vezérlőknek egymás között, hasonlóan például egy alaplapi hiba esetéhez.
A kérdésedre a választ leginkább a tároló rendszer specifikációja tudja megmondani.

Tehát akkor jól gondoltam, hogy csak 1 controllerről látom a diszket.
Az meg, hogy a storage hogy adja át egymás közt controller kiesés esetén a vezérlést nem tudom (nem az én dolgom ezt tudni), nekem az kell, hogy egy 7x24-es rendszernél ne legyen kiesésem, mert nem a storage-ost fogják emiatt keresni hanem engem (SLA vesztés miatt is engem fognak elővenni). De ha 2 különböző controllerről is látom a diszket akkor tuti nem lesz kiesésem. Következő kérdésem nekik miben fáj az ha 2 controllerről is látom a diszkemet ?

aktív/aktív és aktív/paszív multipath között redundanciában nincs különbség.
Amennyivel az aktív/aktív jobb lehet, az a teljesítmény: kisebb a valószínűsége, hogy a HBA lesz a bottleneck.

Egyébként meg storage függő, hogy támogatja -e az aktív/aktív felállást.

Akkor félreérteted az útvonalat, amire gondoltam :) A szerverben 4 portnyi HBA van, ezért a diszket 2 controller esetén, 8 úton látom, mint ahogy a példámban van. Ezt aktív/passzív esetén szintén 8 úton kéne láton mpath-al, csak akkor 4 lenne aktív ready-ben 4 meg passzív readyben, vagy esetleg rosszul gondolom?

Ezt nem tudom megmondani: sem a tároló nem ismert, sem a topológia.

Ha a tároló vezérlőin 2-2 HBA van (illene legalább ennyi), a szerveren összesen 4, akkor elvileg 16 útvonal is lehetne.

Linux multipath-t nem ismerem, a

\_ 1:0:13:4 sdbc 67:96 [active][ready]
\_ 2:0:0:4 sdbk 67:224 [active][ready]
\_ 0:0:0:4 sdc 8:32 [active][ready]
\_ 3:0:13:4 sddk 71:32 [active][ready]

alapján én az látnám, hogy 2db szerver HBA (1, 3) a 13 "target"-en (tároló HBA vagy vezérlő) keresztül éri el a 4-es LUN-t, a 2 és 0 szerver HBA port pedig a 0-s "target"-en keresztül.

Akár jó is lehet a konfiguráció, a SAN admin valószínűleg úgy zónáz, hogy ne tudjatok minden útvonalat vezérlőt telepakolni adatokkal.

HBA number, channel ID, SCSI ID, LUN number
Troubleshooting and dynamic (no rescan) update of multipath disk needs
A the host bus adapter (HBA) number
B the channel id on the HBA
C the SCSI ID of the new device
D the LUN of the new device

"multipath -ll" shows this, eg below A=3, B=0, C=0, D=0
\_ 3:0:0:0 sdd 8:48 [active][undef]

Hirtelen ezt találtam mint leírást, de eszerint az a scsi id amit te vezérlőnek mondtál. Ezt valaki tudja mi akar lenni vagy ez tényleg a vezérlő id -ja ?

Mind az FC, mind az iSCSI alapvetően SCSI, csak egy hordozó közeget tesznek alá. Az SCSI ID annak az eszköznek az azonosítója lesz, ami prezentálja számodra az adott számú LUN-t.
Az is lehet, hogy nem a vezérlő azonosítója, hanem a vezérlő HBA-jának az azonosítója, de jelen esetben majdnem mindegy.
A vezérlőt "storage processor"-nak, "controller"-nek szokták nevezni angolul.

A legjobban akkor járnál, ha a SAN admintól kérnél egy leírást, hogy a 4 HBA-d pontosan mire csatlakozik és hogyan.

Például EMC esetén nem nekik, hanem Neked fáj jónéhány milliónyiért az aktív-aktív, bár a VNX már aktív-aktív tudtommal.

Konkrétan bonyolultabb megvalósítani azt, hogy egy erőforrást két agy tudja úgy matatni egyszerre, hogy konzisztencia ne sérüljön. Mivel bonyolult dologról van szó, valószínűleg a megvalósítás módja sem mindegy.

Vagy elhiszed a tárolós kollégának a dolgot, vagy nem. Kérjél írásbeli igazolást, hogy igen, redundáns a rendszer és a failover idejénél hosszabb kiesés nem lehet, rendszeresen ellenőrzik és monitorozzák a tárolót. (volt már arra példa, hogy mindenki azt hitte, hogy minden jó, közben egy switchben volt egy elkonfigurálás és a látszólag ártalmatlan firmware frissítés levágta a fél SAN-t)

pontosan ettől tartok én is, hogy hiába ölnék bele időt/energiát/pénzt, nem lenne kifizetődő.
a redundáns megoldások így is jelen vannak annyira, hogy a jelenlegi állapot ne kerüljön veszélybe.
(túlbiztosított szünetmentes, túlméretezett megosztás, paranoiás backupok, stb)

a virtuális gépek pedig a jelenlegi szervernél nagyobb erőforrásokat igényelnek -szerintem-

--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző

Teljesen a felállást sem értem (SAN boot a PC-knek? iSCSI-vel vagy AoE-vel? iSCSI nekem eleve reménytelennek tűnik már a HBA ára miatt is).

Ha SAN boot, akkor nem igazán látom a fantáziát: ahelyett, hogy a munkaállomásod egy komponenshez lenne kötve (PC), kettőhöz lesz: a PC a meghajtók miatt, a szerver a tár miatt. Adatközpontban uniform kiszolgálókkal/pengékkel ez működőképes, de egy alacsony költségvetésű irodában nagyon távolinak tűnik.
Ezzel a megoldással leginkább a PC és vékony kliens technológiák hátrányait ötvözöd: lehet egyenként tutujgatni a PC-ket, valamint figyelhetsz a központi erőforrás minőségére/rendelkezésre állására. Előnyét nem igazán látom.

Virtualizálás: ingyenes hipervizoron futtatsz Windows XP/7-eket és RDP-vel csatlakoztok rájuk. Ennek lenne előnye, de olcsósága nem borítékolható, főleg a Windows licencek miatt.

Üdv & köszi. :-)

Ennek az architektúra talán két ponton van alacsonyabb költségvonzata egy VDI felállással szemben:
- Windows licencek
- Ha a számítási kapacitás (CPU + RAM) rendelkezésre áll a PC-kben, akkor nem kell a szerverbe is megvenni.

A tároló redundanciájára akár hideg tartalékot (akár alkatrész szinten) is érdemes meggondolni, illetve "márkás" szerver 4 órás helyszíni garanciával.

a 4órás garanciáról annyit, hogy (igaz gépfüggő) de tapasztalatom szerint nagyon extra szerver kivételével olcsóbban (vagy ugyanott) jársz, ha veszel egy, az eredeti géppel (esetleg majdnem) azonos tartalékot. (nyilván több gép esetén mégolcsóbb a tartalékképzés)

a 4órás garancia nem jelent négyórás megoldást szerintem, max 4 órán belüli megjelenést. ilyenkor ritka, hogy a megjelenő mérnök egyből egy komplett tartalék gépet hozzon...

ha valakinek más tapasztalata van, kérem ossza meg!

Hasonló tapasztalat van nekünk is, nagyon extra gépeknél előfordult, hogy a support-nál nem is volt raktáron alkatrész, ezért kijöttek megnézni mi lehet a baj, majd másnap szereztek hozzá anyagot, addig meg a szolgáltatásunk ment tovább a tartalék lábon. Viszont az "sima" szervereknél már úgy jöttek ki, hogy hoztak új alkatrészeket és a hibásat cserélték is.

Nekünk az a tapasztalatunk, hogy működik szerverek esetén a 4 óra, speckóbb eszköz esetén nem. De az nem is igényelt 4 órán belüli megoldást.
Szerver esetén praktikusan azért van rá esély, hogy jól behatárolható a probléma és egyértelmű, mit kell cserélni, de kivétel nyilván ez esetben is előfordulhat/fordult elő.

A tartalék felhasználásához szakértelem is kell, ez kisebb iroda esetén nem feltétlenül garantálható (például rendszergazda elment szabira). Ez nyilván nem feltétlenül gond (főleg ha a rendszergazda nem egy fő), de ezt is figyelembe kell venni.

( egeresz | 2011. 04. 15., p – 23:40 )

minden SAN eszkoz szoftveres, ugy nez ki, hogy van egy doboz, benne memoria es CPU, fut benne valami szoftver, es hajtja a diszkeket.
Ja, es altalaban van benne NVram. A kulonbseg, hogy van-e 200 mernok, aki azon izmul, hogy 5 evig pisszenes nelkul menjen, vagy nincs 200 mernok.

Linuxbol osszehozni egy ilyet elmeletileg lehet, neha gyakorlatilag is mukodik, hajra, probald ki.

a SATA diszk nem szar, a SAS diszk nem uber.
7200 RPM -es diszk 130 IO/sec -et tud, 10K RPM -es diszk 200-at, 15K RPM diszk 270-et... nagyjabol. egy N darab diszkes RAID 5 az N* ennyit tud read uzemmodban, 0.5* ennyit tud write uzemmodban.

ha tobb gep hajtja meg a diszktombot, akkor az IO/sec sokkal erdekesebb lesz szamodra, mint a Byte/sec. Sokkal sokkal erdekesebb.

lehet gyorsabb, mint a lokalis diszk: a SAN eszkozben levo memoria write cache-kent mukodve gyorsithat. De, persze, lehet lassabb.

Igen, erdemes eles irodai kornyezetet hazilag osszeberhelt storage-vel inditani.
Neked mindenkepp, a cegnek nem feltetlenul.

Ja, egyetlen jo tanacs:
vegyel/vetess egy jobbfajta (30e) gigabites switchet dedikaltan a storage szamara. Meghalalja.

nincs és nem is lesz 200 mérnök erre a célra ;)

"Igen, erdemes eles irodai kornyezetet hazilag osszeberhelt storage-vel inditani.
Neked mindenkepp, a cegnek nem feltetlenul."

a házilag összeberhelt storage itthon kísérletezni first class, egészen addig, amíg nem akarnék komolyabb vizekre evezni a kísérletekben, tesztekben.

a beszerzéshez adott tanácsodat köszönöm, ha az elhatározás megszületik, mert mondjuk látom gyakorlati hasznát is, akkor mindenképpen ezen a vonalon indulok el.

alapvetően azon agyaltam, hogy egy ilyen kicsi hálózatban mennyire volna gazdaságos a thinclient üzemmód.

--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző

thinclientnek azt nevezzuk, amikor az alkalmazas a szerveren fut, es a megjelenites marad a munkaallomason.

termeszetesen a thinclientben nem szokott lenni diszk sem.

igy aztan megkulonboztetunk "diskless workstation" -t, ahol az alkalmazas lokalisan fut (sok memoria, eros cpu), es thinclientet (gyenge cpu), ahol az alkalmazas nem fut lokalisan.

thinclientre jo megoldas, ha egy szerverre rdesktoppal jarnak be a userek.

ettol fuggetlen a munkaallomas-virtualizacio vagy a szerver virtualizacio, nem kerevem ide.

( dap | 2011. 04. 16., szo – 16:28 )

A teljesítményhez:

Az AOE Linux targetek problémásak. A Gombás Gábor féle ggaoed AIO-t használ, ami elvben jó, de gyakorlatban nem a Linux erőssége, a multithread-es qaoed fejlesztése halott. A [k]vblade nem párhuzamosítja az IO-t.

Inkább az iSCSI felé menj szerintem, ott erősebbek a szoftveres targetek. Ezen a területen épp izgalmas váltás zajlik a Linuxban, jön a LIO.

Elvben a "szoftveres" iSCSI lehet olyan gyors I/O-ban mint egy SAN (CPU idő kárára), de a gyakorlatban van néhány bukató (pl. az "incast problem"), illetve a redundanciát neked kell összelőni (drbd, bonding, stb) míg SAN-nál adja magát. A döntés esszenciája: fizetsz vagy szoptanulsz.