SoftRaid vs HwRaid? melyik biztonságosabb?

Merevlemezek, vezérlők

a mai világban már teljesen általánosak a 2 vagy 4 magos, igen gyorc CPUk. felmerül a régi kérdés szoftveres RAID vagy hardveres RAID? melyik a biztonságosabb megoldás?
és ha beüt a katasztrófa, melyiket egyszerűbb helyreállítani? én ma már a SoftRaid megoldásra szavaznék, ha egyébként bőven rendelkezésre áll elégséges processzor számítási kapacitás.
áramkimaradás esetén, melyik esetben kisebb az adatvesztés esélye?

  • 11861 megtekintés

( janoszen v | 2010. 01. 28., cs – 18:23 )

Az olcsó hw raidnél jobb a szoftraid, annál meg jobb a drága (és jó minőségű) hwraid. Félreértés ne essék, a hwraidből van ami drága és szar, a softraid is jobban vagy rosszabbul működik némely vezérlővel, ki kell tesztelni a konkrét pénzügyi keret mellett. Ezen felül az alkalmazás-szintű redundanciát és a backupot úgyse helyettesíti semmi.

( mauzi v | 2010. 01. 28., cs – 18:41 )

ha olyan RAID levelt használsz, ami biztosít valamilyen szintű redundanciát/paritást, akkor a megengedett hibahatárig biztonságban kell lenned, a hibahatáron túl pedig indulj ki abból, hogy az adatoknak lőttek. nevezzük ezt üzemszerű működésnek.

ilyen szempontból tök mindegy, hogy az adott megvalósítás szoftveres vagy hardveres.

értsd: ha mondjuk RAID5-öt használsz, a hibahatár az 1 komponens hibája. ha az egyik komponens elmegy, a RAID5 kutya kötelessége továbbra is jól működni (degradált módban), 2 komponens hibája esetén pedig dobd ki az egészet.

ha ezt valamilyen RAID implementáció nem teljesíti, kerüld el, ha pedig nincs lehetőséged a hibahatáron belül maradni (mert pl. a második komponens előbb elmegy, mint ahogy az elsőt pótolnád) akkor az nem tekinthető a RAID implementáció hibájának.

a hardveres implementáció olyan tulajdonságokkal rendelkezik, amelyeket egy szoftveres sohasem fog tudni.
(szoftver/oprendszerfüggetlenség, boot ROM támogatás, dedikált IO processzor és belső adatbusz, stb.)

mondjuk ezt nem értem:
Egy raid1 vezérlőnek nem annyi lenne a dolga, hogy ő egy darab diszkként mutatja magát az os-felé, és minden a virtuális lemezre írt szektort kiírjon a rálógatott két valódi diszkre, olvasáskor pedig valamilyen - a vezérlő bios-ából, vagy userspace toolal állítható - stratégiával visszadja a kért szektort (amit igazából mindegy melyik fizikai lemezről olvas) például olvashat mindkettőről, és ellenőrizheti az egyezést, vagy csak az egyik lemezről (pl olvasásra optimalizált ssd) olvasson, esetleg naponta váltani, hogy melyikről, így elosztva a terhelést, stb?

( ssa2 v | 2010. 01. 28., cs – 18:44 )

Évek óta használok szoftveres RAID-et (desktop célokra), különféle inteles alaplapokkal. Soha nem volt vele problémám. Már a P4-es korszakban se okozott észrevehető processzor terhelést a softraid, a mostani processzorokkal pedig végképp nem okozhat problémát.

konkretice

raid0/3/4/5/6 tipusok eseten az irasi sorrend garanciat csak journalllal, vagy nvram tamogatassal lehet megoldnani. Ezek kozul egyikkel sem rendelkezik a linux sw raid. Igy nem allithato tokeletesseggel, hogy a linux sw raid megtartja az irasi sorrendet, hogy megtartja a barriert, tehat nem tekintheto ekzaktul megmaradonak az erre epito funkciok, pl a filesystem journal koherencia. Igy kenytelen vagyok azt mondani, hogy a linux sw raid eseten, aramszunet eseten az adatkonzisztenica nem garantalt. Eles tranzakcios rendszerben (pl banki utalasoknal) nem is javasolnam onmagaban (picit lehet okositani a dolgot tobb szerverrel, tobb ups-sel, amig elfogadhato lesz)
Egy nem tul vacak HW raidben van nvram. Ezt neha ugy hivjak, hogy battery backed up cache (BBU cache). A solaris/zfs meg szereti a 'write ssd' nevu celhardvert. Ezek az eszkozok elvileg garantaljak a barrier helyes kezeleset. Normal helyzetben ezt az elvi garanciat leszarom, mert gyakorlatilag hibasak a firmwarek, es megpedig hibasabbak, mint a linux sw raid, es az aramszunet eseten torteno inkonzisztencia valoszinusege eleg pici. Talan kisebb, mint egy hw raid adatinkonzisztenciat okozo fw bug aramszunet/terheles miatti megjelenese.

A HW raid kártyák kikapcsolják a winyók writeback cache -ét? (nemtudom)

Ha igen: csökken az élettartam és a teljesítmény.
Ha nem: semmit nem ér az nvram.

Van rajta sapka vagy nincs? :)

Egyébként 2.6.32 környékén commitolta NeilBrown a raid[56] barrier támogatást, bár még experimental, hamarosan úgy tekinthetjük, hogy van. Mondjuk az állandó WB cache flush nagy performance penalty, szóval még mindig az UPS+redundáns táp+ecc ram a nyerő sztem, akár szoftver raid -el (ha nem kell HA).

A HW raid kártyák kikapcsolják a winyók writeback cache -ét? (nemtudom)
Igen kikapcsolják. Saját cache-t használnak, amit nem engednek writeback módba kapcsolni, ha nincs telepítve a battery backing unit. Legalábbis az IBM Serverraid kártyák ilyenek, azokból láttam sokat.
---
Internet Memetikai Tanszék

OFF
Amit en akarok itt mondani, hogy a c2d -d az SSSE3 nelkul ugyanazokat az utasitasokat kepes vegrehajtani mint egy P4.
Ha meg nincsennek ugy forgatva a dolgok, hogy ki tudjak hasznalni az SSSE3-at, akkor a c2d kutyu igazabol nem tobb mint egy P4 proci.
A tobb mag, virtualizacio, kisebb fogyasztas stb. az mar csak ilyen "varazslat" :)
ON

áramkimaradás esetén, melyik esetben kisebb az adatvesztés esélye?

Jobb hw raid kartyakon altalaban van egy akkumulator ami aramkimaradas eseten megtartja a kartya cache-eben levo adatot. Indulaskor kiirja.

"OFF
Amit en akarok itt mondani, hogy a c2d -d az SSSE3 nelkul ugyanazokat az utasitasokat kepes vegrehajtani mint egy P4.
Ha meg nincsennek ugy forgatva a dolgok, hogy ki tudjak hasznalni az SSSE3-at, akkor a c2d kutyu igazabol nem tobb mint egy P4 proci.
A tobb mag, virtualizacio, kisebb fogyasztas stb. az mar csak ilyen "varazslat" :)
ON"

LOOOOOOOOOOOOOOOOL!!!!!!!!!!!!!!!!!!!

Utasitaskeszletrol beszeltem, de mind1 :P
Amit en akarok itt mondani, hogy a c2d -d az SSSE3 nelkul ugyanazokat az utasitasokat kepes vegrehajtani mint egy P4.
De igaz, rosszul fogalmaztam, lentebb mar kitargyaltuk.

Meg amugy is legyunk mar elnezoek, te meg nem voltal kibasz*ttul "fogalom nelkul" ? :D

De attól, hogy ugyan azt az utasításkészletet használod, még teljesen más a processzor, meg gyorsabb is (mások a pipelinek, mások a cache-k, másog az algoritmusok, mások az elégazás-előrejelzők, meg úgy ánblokk kompletten minden más.
Pl. a mov utasítást híába hívják mov -nak a p4-en meg a c2d -n is, telesen más az alatta levő microkód, meg teljesen máshogy hajtja végra a processzor.

"Meg amugy is legyunk mar elnezoek, te meg nem voltal kibasz*ttul "fogalom nelkul" ? :D"
De, de egyrészt nem oltottalak le, csak egy "LOOOOOL"-t mondtam, másrészt ha valamit nem tudtam, utánakérdeztem, nem pedig terjesztettem az alaptalan tévképzeteimet kijelentő módban. ;) :)

ugyan miért élnénk P4 korszakot?
a P4 azaz netburst architectura, finoman szólva nem tudott már középtávon sem megfelelni az elvárásoknak. úgy 10Ghz körül elvben már megmutatkoztak volna az előnyei, de mint tudjuk ebből nem lett semmi. ezért az Intel szépen visszatért a jó öreg P3 architecturához, ami a jó öreg PPro vonalon alapszik. a P4 fogyasztása miatt sohasem vált ideális notebook cpuvá, már vele párhuzamosan elkészült a továbbfejlesztett Pentium3 PentiumM néven. mivel világossá vált, hogy a Pentium4 további erőltetése elegáns bukáshoz fog vezetni, az átmenetinek szánt PentiM pedig már akkor túltett a P4en, az Intel szépen átállította, azaz pontosabban visszaállította a mainstream termékvonalát PentiumM/P3/PPro vonalra. ezen alapul a Core, majd Core2, Core i7 és a többi mostani Nehalem processzor is.
imho az Intel izraeli laborja kicsit nagy mellényt vett fel a Core sikere után. úgy tetszelegtek, mintha az teljesen az ő munkájuk gyümölcse lett volna. pedig ők csak egy másodlagos Intel labor a sok közül, akik általában olyan kiegészítő munkákkal foglalkoznak, amikkel a fő amerikai laborok már nem akarnak foglalkozni. mivel a fő procvonal zsákutcába ment, és az Intel megengedhette magának, hogy az egyébként nagyszerű PPro architecturát náluk még életben tartassa, ezért hirtelen tőlük jött ki az új "ász" processzor.
az AMD megspórolta magának ezt a vargabetűt. ők helyesen sohasem hagyták el a P3/PPro vonallal versenyző Athlon architecturájukat. a fejlesztéseiket hasznosabb irányba terelték, mint integrált memóriavezérlő, vagy hypertransport. ezek csak most jelentek meg az Intel processzoroknál. ha az AMDnek legalább egy olyan jó fabja lenne mint az Intelnek, feltehetően megtartotta volna a vezető pozícióját a P4 utáni időkben is.

( egeresz | 2010. 01. 28., cs – 18:49 )

egyik helyen hw raidet ajanlok, mas helyen sw raidet, van ertelme hw raid kartyan raid1 -eket sw raid0-val osszefuzni, minden az adott kornyezettol fugg.

a biztonsag is sok jelentesu, hol az sw raid lesz elonyosebb, hol a hw raid.

( handler | 2010. 01. 28., cs – 19:14 )

Attol fugg, hogy definialod a "biztonsagot", "katasztrofat"...

( ppenta | 2010. 01. 28., cs – 19:39 )

Már bocs, hogy bepofátlankodok másnak a témájába, de szerintem ehez a témához is szorosan hozzátartozik, hogy egy mezei raiddel meddig mennétek el?
Értem ezalatt, hogy mondjuk raid6 ba szerveztek diszkeket akkor mondjuk mekkora lenne az a diszk szám amire még az mondható, hogy nagy biztonsággal egyszerre két meghajtónál több nem megy tönkre. 8,10,20 vagy több?

Attól függ.
hot-spare nélkül már egy 5+1-es raid5 is necces.
ha van hot-spare, akkor mondjuk egy 8+1-es sem gáz, de egy 10-15 +2-es raid6-tól sem félnék. már persze biztonságilag.

De a raid[56] nem a performanciáról szól, ahhoz tessék raid1-et használni.

Igazad van, de itt a tárkapacitás mérete illetve a bővíthetősége az elsődleges szempont. Ez tulajdonképpen egy digitális archivum lesz. Maga a gép nem is fontos, hogy folyamatosan működjön, hanem mondjuk havonta 1-2 órát amíg ráírjuk az adatokat. Aztán mehet offba. Illetve ha esetleg kell róla valami akkor on. Ennyit azért ki kellene bírnia raid6+spare megoldásban sima wd green power vinyóknak is.

a vacak diszkkel nem az a problema, hogy potyognak, hanem azt, hogy egy rebuild alatt a diszkvezerlo megnyuzza rendesen a tombot, na es erre a terhelesre potyognak. Tehat addig minden jo, amig be nem rakod (vagy hotspare be nem rakja) a cseret.
Van olyan kollega, aki ilyen olcso cuccnal direkt nem rak hotsparet (de van unused diszk a polcban) es degraded statusz eseten panikszeruen lementi az adatokat, es csak utana rebuildeli a tombot. Meg tudom erteni.

Kicsit körülnéztem, az elérhető árú diszkek között, és ezt találtam szerintem a legmegfelelőbbnek: http://www.wdc.com/en/products/products.asp?driveid=610
ezeket a gyártó kifejezetten 24/7-es felhasználásra ajánlja illetve szerintük ez már "Enterprise-class SATA drives". Ebből raknék 8-at+2spare+dvdrom mentés. Vajon ezekkel meddig húzhatom ki viszonylag biztonságosan?

márminthogy egy, már meglevő raid6 tömbbe szeretnél menet közben diszket hozzáadni, a már rajta levő adatok lementése és visszatöltése nélkül?

ezt a műveletet (fél)napokban mérik, és a teljes diszkterület végigolvasása és újraírása benne van.

ja, és nézd meg a vezérlő leírását, hogy egyáltalán tud-e ilyet.
és ha tud, és kipróbálod, izgalmas kérdés lehet, hogy pl. mi van, ha a művelet közben
- elmegy az áram
- kifingik 1-2 diszk
- elcrashel a vezérlőn levő sw

vajon utána meglesznek-e még az adatok...

RAID-DP is a Double Parity RAID 6 implementation

Amikor a NetApp kihozta a raid_dp -t, akkor nem nevezhette raid6 -nak, mert az akkori raid6 definicio szerint az disztributalt parity blockkokat hasznal (mig a raid_dp dedikalt paritasdiszkeket). Azonban ahogy telt es mult az ido, es egyre hangosabb lett a 'raid6' marketingje, ugy a NetAppnak sikerult elernie, hogy hivhassa a sajatjat is raid6 -nak. Es ez igy van jol, mert a raid4 a fejekben 1 diszk hiba elleni vedelmet jelent, a raid6 pedig 2 diszk hiba elleni vedelmet.

Ezek ismereteben tehat nem csak tanitasi szempontbol volt megfelelo amit irtam (hogy minel konnyebben megertheto legyen) hanem egzakt (a benne szereplo kifejezesek a definiciojuknak megfelelo jelentesben).

De a RAID szintek nem csak azt ejelntik, hogy hány lemezhiba ellen véd....
Ha a RAID6 azt jelenti, hogy disztributált paritásblokkokat használ, és duplán, akkor az olyan megvalósítás, ami nem disztributált paritásblokkokat használ, hanem dedikált diszkeket, akkor az nem RAID6.
Hiába véd mindkét megvalósítás két lemezhiba ellen.

barmennyi hot-spare lehet (elvileg, az algoritmus szerint) barmilyen vdelemmel rendelkezo raid eseten.
Neha meg ertelme is van jo sok hotsparet berakni.

Inkabb ugy szamolom, hogy mennyi az uj (csere) diszk beszerzesenek varhato ideje. Ha 2 het, akkor tobb spare diszk kell, mintha 4 ora.

Van egy entry-level enterprise FC storage, ahol a raid50 rebuild 3 nap, a raid10 rebuild 4 ora.
Ha raid10 spare nelkul, es (enterprise) szerzodes szerint masnap hozzak a diszket, akkor a raid10 no spare magasabb rendelkezesreallast (kissebb rebuild time) jelent, mint a raid50 w hotspare.

En (next business day part delivery) szokasos szerzodes mellett a raid6 -hoz nem rakok sparet, kiveve ha hardver/ugyfel miatt muszaj. Raid5-hoz rakok. Ha tud az eszkoz raid5-ot is es raid6 -ot is, akkor inkabb raid6 w/out spare, mintsem raid5 w/ spare. A raid6 lassabb random irasra, mint a raid5, de ahol ez szamit, oda raid10 kerul, vagy raid50 ha nagyon csoringerek.

De a raid[56] nem a performanciáról szól, ahhoz tessék raid1-et használni.

a raid5, raid6 szekvencialis es random olvasasban hozza a raid0 teljesitmenyet. szekvencialis irasban maga a diszktomb hozza az n-1, n-2 diszkes raid0 teljesitmenyet (plusz cpu felhasznalassal) csak random irasban vacak.

Hogy ertsd, peldaul seed servernel tulnyomoreszt random olvasas van, raid5 oda kivallo.

igen, létezik olyan felhasználás, ahol nem gáz a raid5 performanciailag.
de ez a kivétel, az általános helyzet nem ez.

másrészt pedig a felhasználók döntő többségének nem is annyira fontos a performancia. különben nem vennének notebookokat ezerrel, fika teljesítményű diszkekkel felszerelve.

szokasos ertekek:

raid3, raid4, raid5 max 8 diszk
raid6, raid_dp max 30 diszk.

Azt hiszem, a raid6 eseteben a szokasos 28-30 hatar az inkabb a konkret diszkvezerlok konkret mas belso limitacioi.

A mogottes valszamot nem tudom kiszamolni, igazabol orulnek neki, ha valaki adna kepletet/indoklast.


A diszkeket veletlen meghibasodonak tekintjuk. Valamennyi ido alatt valamekkore valoszinuseggel megy tonkre. Mondjuk egy diszk X idoszak alatti meghibasodasanak valoszinusege legyen p. A kerdes az, ha egy N kotetes raid tomb M diszk egyuttes hibajat eli tul, de M+1 diszk hibajat mar nem, akkor mekkora az eselye egy N,M,p eseten, hogy X ido alatt a kotet meghal.

lehet így, elméletileg kezelni a problémát, de ez csak egy elméleti maximumot ad, a valós életben vannak olyan esetek, amiket ez a modell kizár, mégis érdemes rá felkészülni:

az egyik ilyen a többes meghibásodás (aka szériahiba). ezzel azért nem szoktak számolni, mert nem kiszámítható egyáltalán, viszont a valószínűségi modellt felborítja.

a másik ilyen probléma a hot-spare-ek hiánya (pár diszkes raid5-nél nem jellemző, hogy hot-spare-t használnának): ilyenkor az X nem tervezhető értelmesen, mert nem lehet tudni, hogy 1 órán belül lesz cserediszk, vagy 1 hét múlva.

( lacika v | 2010. 01. 28., cs – 19:56 )

Azért egy értelmes hw raid vezérlőn a cache sem egy elhanyagolható, utolsó szempont (természetesen BBU-val!) és az sem, hogy az I/O múveleteket a vezérlő számolgatja nem a CPU. Desktop rendszerre (ha az elvégezendő munka nem követeli meg) nem szükséges a hw vezérlő szerintem. Meg az sem mindegy, hogy milyen sw raid megoldást használsz. Az md kicsit be tud fáradni pl. 48 lemez esetén, de a ZFS egész jól elboldogul velük. Egy disz csere egy 16 TB-s tömbben (RAIDZ) a silveringgel együtt volt vagy másfél perc, ezt az md már nem tudná így. Biztonságot meg a backup ad (persze a restore időszakos tesztelésével együtt!).

--
http://laszlo.co.hu/

Igen, de az md akkor sem lenne ilyen "fürge".
Na meg mikor össze-vissza kötözgettem menet közben a külső sas dobozkákat (2xJ4200) a szerverben lévő 2 sas ext. hba között, az sem viselte meg a ZFSt nagyon, ott is egy-két perc és magára talált (persze a zpool statusban az eszköznevek kicsit megváltoztak), de neked ezt nem kell, hogy magyarázzam szerintem :)
--
http://laszlo.co.hu/

az altalad leirt tapasztalat nem a linux md lustasagat vagy vacaksagat mutatja, igazabol nem is a ZFS uber mivoltat, hanem azt, hogy megeri egy layerben implementalni a raid, volume manager, filesystem funkciokat. Rohadtul megeri, mert egy csomo nagyon jopofa trukkot lehet megoldani vele. Pl garantalt ideju rebuildet, azonnali diszktomb novelest (uj diszkkel), unlimited snapshotolast, stb.

biztonsagi mentes (backup) az eles szervertol izolalt hardveren tortenik. Ez az izolacio tortenhet szallaggal, egyszer irhato mediaval (dvd, cd) vagy kiemelheto diszkkel, vagy masik szerverrel.

kevesbe szabalyzasszeruen mondva, backup az, amit a gepre bejutott tamado nem tud letorolni ;-)

kezd elterjedni a d2d backup (disk to disk): egy masik gepen levo diszkre megy ki a mentes. Olcso. Gyors. nem archivalas (20 ev) hanem backup (1 het)

a hosszú távú adattárolásról szóló forumban voltak akik már feleslegesnek találták az ezzel való bajlódást. úgy látszik ez a modern szemlélet:) a HD.DVD bukásával sajnos nincs utóda a megbízható DVDram formátumnak, BluRayen egyelőre nincs megfelelője. a streamer nem mindenütt megoldás az ára miatt, de az legalább még lépést tart a növekvő méretű merevlemezekkel. a kikapcsolt winchester, mint archiválási eszköz imho azért nem jó, mert nincs garancia arra, hogy X idő után be is lehet kapcsolni:)

garancia semmire sincs, de még ott a legjobbak az esélyek, illetve DVD.RAM csak annak a mérete ma már kicsi. minden más esetben, ahol zárt vezérlő elektronikán keresztül lehet csak hozzáférni az adatokhoz, mint a winchester, usbflash/memóriakártya, SSD egy nagyságrenddel romlanak az esélyek sok idő elteltével.
a turbo nélkül mentett Commodore kazetták még ma is olvashatóak:)

sajnos még azonos típusnál is lényeges különbségek vannak távolabbi szériaszámok között. hiába lenne nyílt a vezérlőelektronikák összes változata, újragyártatásuk rengetegbe kerülne. akkor már egyszerűbb elmenni a Kürthöz. archiválásra azok az adathordozók ideálisak, amelyekhez biztosított a közvetlen fizikai hozzáférés. az összes DVD BluRay stb ilyen, de az írható formátumok időtállósága sajnos kérdéses. egyedül a DVD.Ram megbízható, de 9.4Gb ma már nem túl sok, és egy nagyobb mentésnél gyakran kellene lemezt cserélgetni. a két fejes catridges DVD író egyébként ritka, mint a fehér holló. de még talán így is a DVDram a legjobb archiválási adathordozó.
a memóriakártyák közül egyedül az XD kártyánál van közvetlen hozzáférés. a flash memória időállósága egyébként kérdéses, de legalább XDnél nincs elektronika, ami kidőlhetne.
a 3ik adathordozó, ahol biztosított a közvetlen hozzáférés, a streamer. ideális archiválásra, csak igen drága.

( uid_6201 v | 2010. 01. 28., cs – 19:59 )

sw raid Linux esetén biztonságos - sokat teszteltem (letépkedtem diszkeket).
mdadm segítségével a meghibásodott diszk helyett tényleg hozzá tudod adni az újat, csonka állapotban is látod az adatokat. raid1..6-ig mindent kezel, SSE3 utasításkészlettel több GB/sec-re képes a proci, közben egy diszk csak 50 MB/sec-re.

A /proc/mdstat fájl kulturált státuszt ad.
Továbbá bármilyen diszkvezérlő esetén, amely a natív diszket adja, csereszabatos a dolog, azaz egy másik gépbe rakva szintén összeáll a raid.

hwraid: kártyára válogatja. Ha maga a raid kártya fekszik meg, az a puding próbája. Addig minden okésnak látszik vele is.
Többen szívtunk már alaplapi raid vezérlőkkel a vezérlő meghibásodása kapcsán. Továbbá a már nem kapható márkás raid vezérlők meghibásodása okán is az adatok visszaszerzésével.

az alaplapi úgy nevezett hw raidek általában szoftveres megoldások valójában. sőt a kódminőség általában jóval gyengébb, mint a pl a linux saját softraid megoldása. az alaplap kipurcanása nagyon kellemetlen lehet. Adaptec vagy 3ware kártyáknál általában legalább van felülről kompatibilitás, ha tönkremenne egy raid kártya van mire cserélni.
csak linuxos softraidre gondoltam. áramszünet miatti leállással voltak tapasztalataid?

Pl az Intel "matrix storage hardware raid" vagy miaszösz linux alatti drivere úgy van megcsinálva, hogy csak a tömb metaadatait olvassa ki a hardverből, a tömb tényleges kezelése már a közönséges linuxos mdraid driverrel megy, mintha sima szoftveres raid lenne. Konkrétan csak az Intelt néztem meg forráskód szintjén, de amennyire én tudom a legtöbb ilyen "kvázi hardveres" raid vezérlő linuxos driver ugyanígy működik.
---
Internet Memetikai Tanszék

( Arbiter | 2010. 01. 28., cs – 20:06 )

Attól függ. :)

A hw raid vezérlő saját dedikált cache-el rendelkezik, lehet saját battery-je, ami véd az áramkimaradások ellen, saját CPU-ja van, ami ott lesz érdekes, ha van egy RAID-5 tömböd, nagyon sok I/O megy át rajta és a CPU-k is le vannak terhelve.

Az sw-hw közötti döntés belső vinyók esetében érdekes, illetve ha iSCSI SAN-t, vagy egy NAS-t szögelsz össze egy mezei PC-ből.

Egy sw RAID nem fog megvédeni egy áramkimaradás okozta adatvesztésből, vagy ha valamiért lerohad a szünetmentesed. Nincs rá garancia, hogy az alaplapi lemezvezérlőddel, illetve a diszkjeiddel hiba nélkül tud majd együttműködni. Emiatt az sw RAID-ért felelős driver/kernelmodul, userspace programok frissítése mindig körültekintést igényel. Természetesen, ha az oprendszer gyártója valahova leírta, hogy az ő sw raid megoldása tesztelve volt az adott chipkészlettel, diszkekkel és állítja, hogy működik...hát...lelke rajta.
Mi történik, ha valamilyen okból csúnyán megrohad az oprendszer a gépen? Mi garantálja, hogy a lemezvezérlő szoftver rendben ki tudott írni minden adatot a vinyókra és nem rogyott meg a tömb?

Nem véletlenül és nem a vásárlók előre megfontolt gonosz lehúzása miatt találták ki a hw RAID vezérlőket és adják el a mai napig.

Egy komoly storage esetén a 2, fail-over-be kötött RAID vezérlő szavatolja a vezérlők szintjén a biztonságot.

Néhány külső storage, illetve PCI-os HW RAID vezérlő tud lemezeket titkosítani. Ilyenkor a titkosítást/visszafejtést szintén a vezérlő processzora végzi.

A lényeg az, hogy ha nagy a terhelés a szerver processzorain és emellett fontos az egyenletes diszk I/O, illetve igényt tartasz a fenti nyalánkságok közül valamire, akkor érdemes hw RAID vezérlőt vásárolni.

saját CPU-ja van, ami ott lesz érdekes, ha van egy RAID-5 tömböd, nagyon sok I/O megy át rajta és a CPU-k is le vannak terhelve

ne hagyjuk mar ki mindenhonnan a penzt. Ez egy penzzel gazdalkodo iparag, nem elmeleti bolcselet, mint a matematika.

a kerdes az, hogy hogyan jarsz jobban, ha a zsetont szetosztodd altalanos cpu-ra es raid-ra dedikalt cpu-ra, vagy ha a zsetonbol csak altalanos cpu-t veszel. Igy mar mindjart maskepp nez ki: (otthoni serverecske eseten) a low-end raid kartya 10e forintja helyett inkabb erosebb cpu-t veszel, varhatoan sokkal jobban josz ki teljesitmenyugyileg. Vagy egy komolyabb szervernel a raid kartya 100e forintja helyett egy erosebb cpu-t veszel, nos, ott is inkabb ekkor jarsz jol.

Ez a 'hw raid kartya segit a cpu-nak' technikailag igaz, de a '400e forintos szerver benne hw raid kartya' mar nem jobb, mint a '400e forintos szerver benne erosebb cpu'. Amikor meg a nagygepeknel a cpu mai viszonyokhoz kepest irrealisan draga volt, akkor megerte penzugyileg is minel okosabb hardvert kesziteni. Most mar ez inkabb csak aktualitas nelkul megmaradt gondolat.

A kerdes sajnalatosan leginkabb a home/low-end piacon jelentkezik, ugyanis a windows alkalmatlan komoly sw raidra, igy a komolyabb (ertsd brand=dragabb) sokdiszkes hardverek mind-mind hw raid-dal jarnak. Ha supportalt sokdiszkes hardvert akarsz venni, akkor muszaj hw raidet venni.

És a végén mit csinálsz? Két sokdiszkes hardware-raid tornyot host (sw) mirroral kötsz össze :-)
A hw cuccok sok jót ad(hat)nak, de ha szar van a palacsintában, csak az ima és a backup segít. Sw raid adataihoz hiba után egy dvd-ről boot-olva hozzáférsz, jó eséllyel összerakod, azt megy. Hw raid esetén ha a kártya elég intelligens, összerakja. Ha nem, IJ (legtöbbször még az algoritmusa sem publikus mit hogyan hova rak). Van ahol nem vagyok a hw raid ellensége, de az ész nélküli terjedésének ott fekszem keresztbe ahol csak tudok :-)

Üdv,
BaZso

Elektronikahibás diszk csinál ilyet, de ezt a hw raid is beszopja. A lényeg hogy az ide/scsi busz lefogható rossz elektronikával (az utóbbi esetben gyakori scsi reset-tel is), ezalatt a jó diszk sem válaszol, ha ő volt a terheltebb, ő esik ki.
FC-nél dual loop esetén ennek a valószínűsége gyakorlatilag nulla. A többinél viszont láttam már ilyet.

Üdv,
BaZso

( bambano | 2010. 01. 29., p – 01:00 )

ha jól olvastam, digitális archívumot akarsz.
akkor "biztonságosabb megoldás" szempontjából sem hw, sem sw raid, hanem tisztességes márkás szalagos mentés. A raid0 oké arra, hogy ne keljen piszlicsáré másfél terás diszkekkel szmötyizni, de csak erre jó.

Adatbiztonságot a szalag ad.

a szalagos megoldás valóban jó archiválásra. de az ára miatt nem minden helyen megfizethető.
archiválásról inkább itt beszéltünk, de a mostani témánál is felmerült.
elsődlegesen ebben a forumban a softraid előnyeire és hátrányaira vagyok kíváncsi hw megoldásokkal szemben. a biztonság RAID esetében alapból kényes kérdés.

Jelenleg a legolcsóbb adattárolás a sata diszk. Nem véletlenül tenyészik a VTL. A szalag drága (kivéve ha jó kedvezményes helyről sikerül szerezni), a fej pláne. Otthonra, de még kis céghez sem vetetnék egy LTO fejet 1-2 milláért.
Kell egy "backup-storage-server" raid5/6 spare diskekkel, és arra tolni a mentéseket. Szigorúan mentés, nem replika, mert azt könnyebben fejbeveri egy logikai hiba.

Üdv,
BaZso

Backup-hoz tényleg jó egy távoli gépben lévő tükrözött/raid5/raid6 tömbben lévő diszk, de archiválásra (offline tárolás) alkalmatlan. Tudom, jön a kérdés, hogy miért kell a backup-nak raid tömb... A backup megbízhatósága legalább olyan legyen, mint a mentett szerveré - nem jó dolog, ha a mentés elvesztése okán azon kell izgulni, hogy a következő teljes mentésig nehogy beüssön valami crach az éles rendszerben, és felhasználói igény se legyen egy korábbi állapot visszaállítására.

( deli | 2010. 01. 29., p – 01:24 )

ext3, sw raid5 es aramszunettel milyen tapasztalatok vannak?

Konkretan az erdekel mi lesz ha
1, MySQL db-be epp iras muvelet tortenik es kozbe aramszunet
2, nagyobb fajl iras kozbe aramszunet

Eddig 1db winyo ext3-al soha semmi gond nem volt aramszunet utan, gondolkozok raid5-be csak kivancsi vagyok, mi lesz aramszunet eseten, elofordulhat hogy szethal a raid?

nem, inkabb annak van elvi pici eselye, hogy serul az ext3 journal esvagy a mysql journal (tenyleg, mostansag a mysql csinal ilyen journal alapu szinkron tranzakciokezelest, mintha igazi adatbaziskezelo lenne?)

Egyforma, kisszamu (4) diszk eseten ez az elvi esely meg nem jott elo a kornyezetemben. sok diszk sw raid eseten inkabb a raid10-et ajanlom, kulonben is sokkal jobban viselkedik adatbaziskornyezetben, mint a raid5.

eredetileg az archiválás kívül volt a témán, de már többen szóba hozták. valóban sokan vannak akik szerint a filmgyűjtemény legmegfelelőbb helye egy Raid szerveren van. nyilván lesznek páran akik a jövőben ezt a szemléletet át fogják vinni a cégekhez, és alkalmazni fogják az ottani adatok "archiválásához".

( kisg v | 2010. 01. 29., p – 09:48 )

Ha már előjött a topic: a HW RAID minősége nagyon erősen függ a vezérlő minőségétől.

A postgresql-performance listán legutóbb most decemberben jött elő a téma. Ott a következő kártyákat kedvelték (természetesen csak a drágább, 100kHUF-tól induló kategória játszott):
- Areca (az újabb modellek -- van amelyiknek saját ethernet menedzsment portja van, így nem kell OS driver a menet közbeni volume kezeléshez.)
- 3ware 9690SA -- ez állítólag egy teljesen más (jobb?) design mint a 9650 vagy a 9550, egy felvásárlás nyomán jutottak hozzá
- HP P800 - jónak tartják, de alapvetően csak HP géphez lehet beszerezni (és ha jól láttam, ez teljes méretű kártya, így 1U szerverbe pl. nem is fér be.)

Amiket nem szerettek:
- HP P4xx
- Dell PERC*
- Promise (rémtörténetek tömege)
- Adaptec (itt nem egyértelmű, mert volt aki azt mondta, hogy lassú, de legalább stabil)

Egy érdekes megfigyelést tettek, hogy ugyanazok a kártyák FreeBSD alatt sokszor gyorsabbak voltak, mint Linux alatt.

Illetve a fentebb már említett OS driver gondok is előjöttek: az egy dolog, hogy a rendszer működik egy kártyával (kernel driver van hozzá), de több esetben azt írták, hogy a menedzsment toolok már nem elérhetők, tehát újra kell bootolni, és csak a kártya BIOS-ban lehet kezelni a tömböket.

A kérdésem a szakértő kollégákhoz az lenne, hogy kinek mi a tapasztalata a fenti, vagy egyéb (IBM, Sun) kártyákkal, akármilyen téren (megbízhatóság, sebesség, menedzselhetőség).

Egy másik kérdés, hogy mekkora cache méretnek van értelme (256MB elég, vagy 512MB alatt nem érdemes kezdeni)?

A cachenek nyilván védettnek kell lennie áramszünet ellen. Itt két változat van a battery-backed, és a flash-backed (egy szuperkapacitással megtámogatva, hogy át tudja másolni a cache RAM-ból az adatokat, ha elmegy az áram). Kinek milyen tapasztalata van az utóbbival? Nekem szimpatikusabb lenne, mert bármilyen hosszú ideig képes megtartani az adatokat.

És a végére még egy kérdés: SW RAID esetén ki milyen vezérlőkártyát javasol? Az alaplapi vezérlők megfelelők? Vagy érdemes egy külön (nem RAID) PCI-Express vezérlőbe beruházni? Ez a kérdés vonatkozik a belépőszintű brand szerverekre is.

Üdv,
Gergely

UI: Lehet, hogy hasznos lenne a múltkori Virtualization Day mintájára egy "Server Day"-t szervezni, ahol sokféle hardveren lehetne benchmarkolni / tesztelni a különböző megoldásokat. Lehetne nagy csatákat rendezni:
- SW RAID vs. HW RAID
- dzsunka szerver vs. whitebox szerver vs. brand szerver (nyilván összehasonlítható konfigurációk esetén van értelme)

p800-at még nem néztem, de e200-at és p400-at igen.
(sőt vannak régebbi, SA 5i,6i, 5300, 6400 scsi vezérlőim is)

A p400 jelentősen gyorsabb mint e200 (pl utóbbi nem tud sata ncq-t).
A HP kártyák simán mennek mezei pc-ben (ugye informer,kovjan ?), de gondolom HP kifejezetten sajátjait ajánlja. E200,P400bóé létezik lowprofile verzió is (és rég nem full hosszú) így 1U gépben sem okoz gondot. Ha már ilyenen gondolkozol, miért nem nézel mondjuk 1 olyan HP 1U vasat, ami onboard adja a hw raidet? :-)

A cciss driver (hp univerzális) ill a linux kernel kapcsolatában jelentős változások voltak 2.6.28 körül. nem sikerült kideríteni, h milyen paraméterek, és hogy lehet változatni, de 2.6.28 ill. előttiek jóval gyorsabban működnek. (2-3x különbség).

"Lehet, hogy hasznos lenne a múltkori Virtualization Day mintájára egy "Server Day"-t szervezni, ahol sokféle hardveren lehetne benchmarkolni / tesztelni a különböző megoldásokat"

Van az IBM-nek egy "Innovation Center"-e ahol mindezt kultúrált körülmények között megteheted.
Csak halkan mondom, ha jelzed az IBM-es "jófej" srácoknak ezen igényedet, és kellőszámú érdeklődés is van, akkor talán meg is szervezik au eseményt A-tól Z-ig. (És már csak nagyon halkan jegyzem meg, lehet hogy még svédasztalra futja a költségvetésükből.)
Szerintem keresd meg őket az ötleteddel.

Ennek a rendezvénynek a célja az lenne, hogy a különböző gyártók termékeit lehessen egymás mellett végigpróbálgatni. (IBM, Sun, FuSi, Dell, HP, illetve whitebox Intel / AMD szerverek ... stb.)

De köszi az infót az IBM-ről, mindenképpen hasznos. Tudnál esetleg kontaktot javasolni hozzájuk, hogy kit érdemes keresni (akár magánban)?

Üdv,
Gergely

Az elérhetőség itt van:

http://www-05.ibm.com/hu/ibmincenter/

Nekik gyakorlatilag meg van minden ami IBM-nél elérhető (kicsi szervertől géptől a nagy gépig minden: storage, SSD, balde center stb.), és csak azért tartják üzemben, hogy bárki aki akarja bemegy hozzájuk, és kipróbál azt amit akar. A team-et Rada Feri vezeti, elérhetősége a fenti linken. IBM szoftvereket is tudtok tesztelni, pl. WebSphere, és tudtok szimulálni és mérni valódi terheléseket pl webkiszolgálóra, vagy adatbázisra. Az IBM sw-n kívűl azt telepíthettek fel, amit akartok.

Mi egyszer egy portál motort teszteltünk, úgy hogy több milliós látogatói forgalmat generáltunk valós látogatói szokások alapján. Nagyon igyekezteünk, de nem tudtuk kiakasztani a bladecentert. :)

A kérdésem a szakértő kollégákhoz az lenne, hogy kinek mi a tapasztalata a fenti, vagy egyéb (IBM, Sun) kártyákkal

A Sunnak nincs saját raid kártyája.

A jelenleg árult x86-os gépekben LSI Logic mpt alapú kártyák vannak (általában opcionális, de melegen javallott a PC-k BIOS-a miatt), kb. olyan, mint bármilyen más hasonló PC-s kártya, a SPARC-os gépekben pedig jelenleg nincs, és egy-két kivételtől eltekintve sosem volt (az UE450-be lehetett opcionálisan kérni valami Symbios/LSI kártyát, szinte senki nem vett ilyet, lehet kb. 3 db Magyarországon belőle; a V440-nek volt valami az alaplapjára integrálva, de én nem ismerek olyat, aki használta volna), mivel a sw raid1 teljesen jól használható boot diszkre Solaris alatt, mást úgysem javasolnék, az OBP meg nagyrészt jól kezeli a hibás boot diszket, tehát simán be fog bootolni a másik tükörről.

Lehetne nagy csatákat rendezni:
- SW RAID vs. HW RAID

Nézd, rendes ügyfelek szervereiben max. a boot diszkre tudsz HW raid kártyát használni, mert minden adat közös, külső tárolón van, amihez redundáns cluster kapcsolódik. Ezen a ponton a szerverben nem használhatsz semmilyen HW raid kártyát, hiszen a cluster párnak is látnia kell ugyanazt a raid konfigot, ezt pedig csak SW raiddel, vagy intelligens tárolódobozzal tudod megcsinálni.

A single szerveres, HW raid kártyás megoldások a kkv-kra jellemző, akiknek a 200 ezer forintos szerver már nem elég jó, de clusterra meg shared storage-ra viszont nincs több milliójuk.

ahol sokféle hardveren lehetne benchmarkolni / tesztelni a különböző megoldásokat.
- dzsunka szerver vs. whitebox szerver vs. brand szerver

A megbízhatóságot meg a supportot hogyan benchmarkolod / teszteled? Mert arról ne álmodjál, hogy ugyanaz az Intel CPU gyorsabb lesz egy brand szerverben...

LSI Logic mpt alapú kártyák vannak
Ehhez annyit fűznék hozzá, hogy ez a család általában 1db RAID-1 tömböt szokott tudni kezelni. Nem tudom, hogy a Sun gépeiben ez kihasználható-e vagy sem.

A single szerveres, HW raid kártyás megoldások a kkv-kra jellemző,
Vagy pont a shared storage-ot adó gépben található. Bár ez mondjuk nem feltétlen mond ellent az állításodnak, mert az igazán nagy helyeken úgyis valamilyen készre gyártott storage boxot raknak be és nem kézzel telepítgetnek általános célú szerverre iscsi targetet, meg hasonlókat. Aztán, hogy a storage boxban mi van, az más kérdés...

Mert arról ne álmodjál, hogy ugyanaz az Intel CPU gyorsabb lesz egy brand szerverben...
Sőt általában kicsit még lassabb is szokott lenni, mert a BIOS-ban konzervatívabb módon bánnak a cpu/chipset teljesítménynövelő feature-jeivel. Megjegyzem néha sajnos okkal...
---
Internet Memetikai Tanszék

Ehhez annyit fűznék hozzá, hogy ez a család általában 1db RAID-1 tömböt szokott tudni kezelni. Nem tudom, hogy a Sun gépeiben ez kihasználható-e vagy sem.

Jelenleg minden valamirevaló x86-os gépbe sok (értsd: min. 8 db) diszk dugható. Ezen tud a kártya egynél több tömböt is csinálni, és nem csak raid1-et.
Azoknál a régi gépeknél, ahol csak 2 diszk fért el bent (pl. v20z), ott nyilván másnak nemigen van értelme, mint 1db raid1.

Aztán, hogy a storage boxban mi van, az más kérdés...

Hát, ha redundáns, akkor nem fogsz benne PC-be dugható HW raid kártyát találni. Igazából másmilyen raid kártyát sem, mivel a kontrollere maga a raid vezérlő. A számítógép szemszögéből nézve HW raid az eszköz, az eszköz szemszögéből nézve SW raid (hiszen valamilyen oprendszer fut benne, és az alatt bizony SW raidként dolgozik).

Ezen tud a kártya egynél több tömböt is csinálni, és nem csak raid1-et.
Én arra a változatra gondoltam, amit sima SCSI vagy SAS vezérlőként szoktak az alaplapokra rakni a gépekben. LSI 53c1030, 53c1060. Ezek tudnak csak 1 tömböt kezelni. Persze ZCR kártyával felpótolhatók. De szerintem ez azért egy okos gondolat, mert a legtöbb esetben a gépre rakott host OS-nek kell a RAID1, a többi nagy store meg hálózatról jön.

Igazából másmilyen raid kártyát sem, mivel a kontrollere maga a raid vezérlő.
Amennyire én tudom ez Sun cuccaira biztosan igaz, ott konkrétan Xeon-okat használnak. Az IBM storage dobozaiban viszont valami komplikáltabb architektúra van. Nem rendes ServerRAID kártya, de több (talán PPC) CPU-ból és LSI kontrollerből összerakott rendszer. A DS5xxx fejegységek némelyikére lehet EXP dobozokat kötögetni, azokban is van valami külön processzor. Elosztott tömbkezelést emlegetnek, egyszer láttam valami felületes leírást, de sajnos nem tudok részletesebb infót róla, mindenesetre ez arra utal, hogy valahogy mégiscsak hasonlíthat a felépítése egy CPU + HWRAID megoldásra.
---
Internet Memetikai Tanszék

"Nézd, rendes ügyfelek szervereiben max. a boot diszkre tudsz HW raid kártyát használni, mert minden adat közös, külső tárolón van, amihez redundáns cluster kapcsolódik. Ezen a ponton a szerverben nem használhatsz semmilyen HW raid kártyát, hiszen a cluster párnak is látnia kell ugyanazt a raid konfigot, ezt pedig csak SW raiddel, vagy intelligens tárolódobozzal tudod megcsinálni.

A single szerveres, HW raid kártyás megoldások a kkv-kra jellemző, akiknek a 200 ezer forintos szerver már nem elég jó, de clusterra meg shared storage-ra viszont nincs több milliójuk."

"Rendes ügyfelek" már vagy valamelyik brand gyártót használják, vagy egyszerűen egy megkeresésükre a nagy gyártók leraknak egy-egy tesztrendszert a szerverterem négy sarkába, hogy próbálják ki -- nyilván ez túlzás, de a lényeg, hogy sokkal több lehetőségük van megtalálni az ideális megoldást, már csak amiatt is, mert ilyen beruházásoknál van idő arra, hogy rendesen kiteszteljék a lehetőségeket.

A valóban kisvállalati szegmensben 500.000 Ft körül van az első lélektani határ (hümmögés), 1.000.000 Ft-nál a második (hanyattesés), 2.000.000 Ft-os keretnél már a szakember nagyon örül -- amig meg nem hallja az irreális elvárásokat.

Szerintem a piac nem elhanyagolható szegmensét képezi ez a "nem rendes" ügyfelekből álló rész. Konkrétan erre a szegmensre gondoltam akiket érdekelhetne ez a "Server Day".

"A megbízhatóságot meg a supportot hogyan benchmarkolod / teszteled? Mert arról ne álmodjál, hogy ugyanaz az Intel CPU gyorsabb lesz egy brand szerverben..."

Megbízhatóságot nem egyszerű tesztelni, mivel valószínűségekkel dolgozol:
- a gyártó által megadott MTBF adatokkal (már ha vannak).
- ha van sok hasonló szervered, akkor a saját tapasztalatokból
- "iparági tapasztalatokból" (Google keresés :) )

A supportot úgy hasonlíthatod össze, hogy csinálsz egy kérdőívet, amin rákérdezel pl. a 7x24x2 vagy 4 órás support részleteire. Meg persze itt is hagyatkozhatsz az "iparági tapasztalatokra"...

Ezeket egy rendezvény keretében esetleg a gyártók / kiállítók által tartott előadásokkal lehet bemutatni, esetleg a fent említett kérdőívet minden kiállító kitölthetné, és elérhetővé tehetnénk a rendezvény honlapján.

Ugyanazok a komponensek önmagukban nem fognak különbözni. De az egyes rendszerek más-más komponenseket tartalmaznak (pl. a RAID vezérlő mindegyik márkánál különbözik).

Tehát rendszerszintű benchmarkokkal (adatbáziskezelés-teljesítmény, webkiszolgálás-teljesítmény ... stb.) már össze lehet a különböző megoldásokat hasonlítani.

Üdv,
Gergely

a lényeg, hogy sokkal több lehetőségük van megtalálni az ideális megoldást, már csak amiatt is, mert ilyen beruházásoknál van idő arra, hogy rendesen kiteszteljék a lehetőségeket.

melyik bolygón élsz? :)

egyrészt a "rendes" ügyfelek döntően durván időzavarban vannak, nemhogy a lehetőségeket nincs idejük kitesztelni a döntés előtt, de sokszor még az elkészült rendszert se nagyon, hanem "gyere cipó, hamm bekaplak"

olyan "rendes" ügyfél meg szerencsére nagyon ritkán akad, aki az "ideális megoldást" szeretné megtalálni - ebből nagyon ritkán lesz a gyártónak bevétel, "valahogy" sosem jut el a projekt oda, hogy tényleg vegyenek is valamit.

Szerintem a piac nem elhanyagolható szegmensét képezi ez a "nem rendes" ügyfelekből álló rész.

hát, ezt meséld majd el larrynek, nemrég mondta, hogy nem akar a low-margin bizniszben tevékenykedni, márpedig egy 500.000 forintos szerveren olyan baromi sok margin nem tud lenni. szerintem az x2200-as szeriának ezért nincs túl sok jövője.

Konkrétan erre a szegmensre gondoltam akiket érdekelhetne ez a "Server Day".

igen, szerintem is kb. őket érdekelné, kérdés, hogy a gyártók látnak-e bennük ehhez elég fantáziát.

- a gyártó által megadott MTBF adatokkal (már ha vannak).
- ha van sok hasonló szervered, akkor a saját tapasztalatokból
- "iparági tapasztalatokból" (Google keresés :) )

ja, most ehhez vedd hozzá, hogy 2 évnél lassan nem lesz több egy szervercsalád hasznos élethossza. ebből azok tudnak igazán profitálni, akik pár évvel a megjelenés után veszik - másodkézből - a szervereiket, mert addigra kiderülnek a nyűgök.

Tehát rendszerszintű benchmarkokkal (adatbáziskezelés-teljesítmény, webkiszolgálás-teljesítmény ... stb.) már össze lehet a különböző megoldásokat hasonlítani.

ezt tényleg nem értem, hogyan képzeled el.

ki csinálna benchmarkot, és az miért lesz jóskabácsinak releváns? adatbázis és adatbázis között hatalmas különbségek vannak, még ha a sw ugyanaz is, pláne, ha még a sw is változhat.

- Szerintem a piac nem elhanyagolható szegmensét képezi ez a "nem rendes" ügyfelekből álló rész.

- hát, ezt meséld majd el larrynek, nemrég mondta, hogy nem akar a low-margin bizniszben tevékenykedni, márpedig egy 500.000 forintos szerveren olyan baromi sok margin nem tud lenni. szerintem az x2200-as szeriának ezért nincs túl sok jövője.

Ne keverd a szezont a fazonnal, Larry bácsi nem azért hátrál ki az x86 piacról, mert az low-margin biznisz hanem azért, mert az nekik (a Sunnak) low-margin bizniszre sikerült. Ugye érzed a különbséget? Attól még az a piac aranybánya jónéhány másik játékosnak. Larry azt mondta, kihátrál, és talán ez volt a legegyszerübb kifogás.

( talisker | 2010. 01. 29., p – 09:52 )

subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( wladek1 | 2011. 06. 11., szo – 16:31 )

Engem az érdekelne inkább, hogy miért nem lehet ezekhez a hw controllerekhez valami egységes API -t irni, aminek a kimenete pl valami hasonlo, mint az /proc/mdstat, illetve kb hasonlo modon kezelhető os alól, mint az mdadm? Így ultraszopás monitorozni pl nagiossal...

( goodbyte v | 2011. 06. 12., v – 01:03 )

subs.

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( EdgarPE | 2012. 09. 07., p – 14:14 )

Én abszolute a softraid-et favorizalom, főleg a rugalmassága miatt. Ha gond van, könnyebben értesülsz róla és könnyebb belenyúlni tömbbe. Volt 3ware raid kártyám, nem szerettem.

A HW raid egyetlen előnyének egyedül a battery backed up cache-t tartom. De egyrészt szerver nem létezik UPS nélkül, másrészt azt nem bírom felfogni hogy komolyabb szerver vagy akár desktop pc házakat miért nem gyártanak beépített UPS-el, ami akár csak 2-3 percig életben tartja a gépet, hogy lehessen egy clean shutdown-t végrehajtani...

Abszolúte jogos felvetés!
Ezen mi is meditáltunk a kollégákkal kissé.

Ugye elenyésző kivételtől eltekintve a gépek 12V és 5V egyenfeszültséget igényelnek, amit a 230V-os váltóról csinál nekik a kapcsolóüzemű tápegységük. (transzformáció+egyenirányítás)
Az UPS-ek pedig 12V-os egyenfeszültséget biztosító akkumulátorokon tárolt energiát szaggatnak meg és transzformálnak 230V-os váltóárammá... Azután a 230V AC-ről egyenirányított töltőárammal töltik újra fel őket.
De méééért? Nem lenne egyszerűbb egyszer csinálni 12V-ot a hálózatról, aztán arról hajtani mindent? Akkor egy átalakítás elég lenne a három helyett.
Tudom, hogy egyenfeszültségnél, és főleg kisebb feszültségnél nagyobb a fajlagos veszteség, de szerintem bőven megérné nagyobb keresztmetszetű vezetőket beépíteni arra a pár méterre, ami mondjuk egy szerverterembe kell.

Valami oka biztos van, hogy nincsenek ilyen rendszerek (vagy én még nem találkoztam vele).
Legalább annyi, mint a qwerty billentyűzet használatának. (Írom ezt egy Dvorák-ról.)

Ott tényleg nem terjedt el, a PC általános célú eszközként indult, aztán "költözött be" a géptermekbe, mint kiszolgáló, és vitte magával a tápegységét is. Ráadásul 48V-on közel ötször akkora áram folyik azonos teljesítményfelvétel esetén, mint 230V-os betápnál, amihez az elektromos hálózat vezetékeinek a keresztmetszetét kéne jelentősen nagyobbra választani, és itt is előjön az egyenáramú táplálás valamennyi nyűgje...

Picit jobbak, de nem sokkal :-) Egy tele szekrénynél szerintem ~10kW-tal simán számolhatunk, ez meg 15V-on 6-700A, ha jól számoltam, ami emlékeim szerint 400, de inkább 500mm2 keresztmetszetű réz vezetéket igényel. Most mindegy, hogy középre rakva elég lenne fele ekkora keresztmetszet (fele fölfelé, fele meg le)... Ráadásul a redundanciát is meg kéne a tápnál valahogy oldani, amit ekkora méretben 3+1-ben tudok elképzelni, hogy még úgy, ahogy kezelhető legyen egy egység - ahogy a blade kereteknél is van.

Az ok nagyon egyszerű: az UPS általános célú eszköz, szabványos kimenettel. Pár kW-nyi teljesítményt 5 vagy 15V-on úgy továbbítani, hogy a feszültségesés minimális legyen csak nagyon-nagyon izmos tömör vezetősín használatával lehet - láttam szétkapva -talán- Siemens nagygépet: abban kb. 12cm2 keresztmetszetű sineken szaladozott a tápfeszültség - szekrényen belül. Ráadásul egy ilyen nagyáramú (Saccold meg, mennyi egy átlagosan pakolt 42U-s szekrény teljesítményfelvétele, aztán számold vissza, hogy 5, ill. 15V-on az hány Ampert jelent...) sín le/visszakapcsolása sem triviális, pláne, hogy egyenáramról van szó, ahol az ívoltás pirinyót trükkösebb (ha egyáltalán megoldható), mint a váltakozóáram esetén.

Volt egy HP 9000es vasunk egy helyen, az ilyen volt, gyakorlatilag egy becsomagolt rack, benne szerver, lemezes tároló, szallagos tároló, ups. Ha jobban atgondolod az ügyet, ahová a kiszolgalokat tervezik ott már ezt megoldották központilag hatékonyabban két körön, így érdektelen az úgy. Ha meg nem olyqn helyre teszed, ott több gond lenne vele mint nélküle, kulsovel. Egy példa, ki kell pakolni a szervert a házból, mert el kell vinni felujittatni az upst :) na az lol.

nem bírom felfogni hogy komolyabb szerver vagy akár desktop pc házakat miért nem gyártanak beépített UPS-el, ami akár csak 2-3 percig életben tartja a gépet, hogy lehessen egy clean shutdown-t végrehajtani...

A Thecus N4200-asban pl van egy beepitett akkumulator ilyen cellal. A linkelt oldal 5-ik keretezett kepen (hatulrol a 2-ik) jol lathato.