HW RAID HDD-vel vagy SW RAID SSD-vel

Merevlemezek, vezérlők

Ezek közül kellene választanom:
HW RAID10 6db HDD-vel vagy SW RAID10 6db SSD-vel.
Melyikkel járok jobban teljesítményben? LAMP szerver, sok olvasás, kevesebb írási művelet.

A HW RAID esetén ez a kártya lenne:
Intel RAID Controller RMS25PB080 (LSI2208 ROC) Data Transfer Rate 6 Gbps 1GB DDR 3 RAM

  • 4650 megtekintés

( r2d2joda | 2016. 01. 06., sze – 10:10 )

Akinek egyszer "megégette" a kezét a HW RAID, az csak szoftvereset használ, magamból kiindulva.

Nem lehet ezt egyértelműen kijelenteni szerintem. Használok ezt is, azt is, amazt is.

  • hw RAID vezérlős RAID - pl. HP Smart Array
  • gagyi "szoftver RAID" aka. hostRAID (a CPU + driver végez minden funkciót) (gagyiszerverek tartozéka általában)
  • mdadm szoftverraid
  • hw RAID kontrollerpárok (brand storage - pl. Fujitus DX, HP MSA stb.)

Mindegyiknek vannak vannak előnyei és hátrányai. Egyetlen egyet kerülök ezekből, az a hostRAID.

--
trey @ gépház

+1. Bár nekem pont hw raid okozott örömteli éjszakákat, de rövid időn belül kiderült, hogy a költséghatékony SSD és Intel RAID kártya párosítás a probléma oka - amikor kihajítottuk a gépből a desktop kategóriába tervezett meghajtókat, megszűnt a 2-3 hetenkénti "áramtalanítós reboot,vagy kidobálom az összes diszket a tömbből" probléma.

( Proci85 v | 2016. 01. 06., sze – 11:20 )

A HW RAID vs. SW RAID témához ahogy én látom, de nyugodtan javítsatok ki:

A HW RAID nem a szerver CPU-t terheli, szemben az SW RAID-del, viszont ma már bőven van CPU kapacitás, tehát mehet SW RAID.

HW RAID esetén 1 /dev/sdX eszközfájlt látsz, amire hivatkozhatsz, emiatt megbízhatóbb. SW RAID-nél több /dev/sdX van, olykor más nevet kaphat, más sorrendben stb. Régen ebből gond volt, de ha raid autodetect a partíció típusa, könnyen megtalálják egymást + a sorrend változásra már rég kitalálták az UUID-ot. Tehát mehet SW RAID.

HW RAID-től nagyobb teljesítményt várnak, de nálam gyakorlatban mindig az ellenkezője bizonyosodott be. SW RAID ugyanolyan vagy nagyobb teljesítményt nyújtott. Így volt 2006-ban, így volt 2015-ben is és a köztes időkben bármikor is néztem. Legyen az RAID5, RAID6, RAID10 6db-16db diszkkel vizsgálva. Tehát mehet SW RAID.

Jobb HW RAID kártyákra tudsz SSD cachet kötni. Újabban már -ahogy te is- rögtön SSD-t használnak, így ez sem szempont. Tehát mehet SW RAID. Egyébként SW RAID-ben lévő HDD esetén LVM-et használva is van LVM SSD cache trükk.

Futottam már bele bugos Adaptec HW RAID kártyákba. Konkrétan menet közben széthullott a RAID10, korruptálódtak az adatok, a kis buta meg reboot után ugyanúgy összeállt, miközben használhatatlan volt az egész tömb.

Van 3ware HW RAID kártyám, több is, 8 vinyó van rajta. 5 év alatt 3x állt meg csontra a vezérlője. Reboot után helyrejött. Sokadig firmware update után talán megjavult..sokára tudom meg, 1-2 évente jön elő mindig.

Ha SW RAID alatt menet közben húzgálod ki a vinyókat csere céljából és rosszat húzól ki, borul a tömb. Ezt SW RAID alatt soha nem sikerült visszacsinálnom, hiába toltam vissza a jó vinyót. Pl. RAID5-ből 2 vinyót kiveszel majd 1-et vissza, menet közben.
HW RAID-nél még nem csináltam ilyet. Aki csinált, tapasztalat? Ok, nyílván leállítva _célszerű_.

HW RAID nálam Citrix XenServer virtualizációnál jön számításba, ahol a rendszer alapból nem kezeli az SW RAID-et.
Egyébként nagyon stabilan mentek az SW RAID-jeim az elmúlt ~10 évben.
Van egy 7+2 vinyóból álló backup "szerver". Alaplapi csatlakozó híján SIL chipsetes PCI kártyákkal is bővítettem. Évek óta megy rá a heti backup, nem rikán 500-900Mbit/s sebességgel, olykor párhuzamosan kapja a backupot és bírja. Régi Core2Quad Q6600-as CPU-t ~20%-ra hajta ki max...de ez ugye hol van a mai szerver processzorokhoz képest :)

Én ezt használom (dm-cache). Fontos tudni, hogy a szekvenciális hozzáférést nem gyorsítja, azaz dd-vel tesztelve nem lesz gyorsabb a verkli. Érdemes a konkrét alkalmazással tesztelni :D
Mai ésszel inkább nagyobb SSD-t vettem volna, de ennyit mertem megkockáztatni (128G m.2): 


------------------------------------
LVM Cache report of /dev/vmvg/vm_lv
------------------------------------
- Cache Usage: 100.0% - Metadata Usage: 10.0%
- Read Hit Rate: 71.7% - Write Hit Rate: 95.8%
- Demotions/Promotions/Dirty: 54172/54172/1
- Features in use: writeback

RAID0: szeletenként DMA alegység játszótere, CPU-t nem zabálja
RAID1: DMA alegység elviszi a melót, CPU-t nem zabálja
RAID10: lásd fent

RAID5: xor ... SSE4 és AVX célhardver ezt gyorsan elvégzi. A többi szintén DMA alegység.
RAID6: SSE4 és AVX célhardver ezt is gyorsan elviszi. A többi szintén DMA alegység.

Kérdés számomra inkább, hogy ha kell a háttértár tempó, akkor valójában melyik hogyan viselkedik sok párhuzamos szálas terhelésre?

- SATA 7k
- SAS 15k --- vigyázz az ál-SAS HDD-kkel.

- SATA SSD
- SAS SSD
- PCIe SSD kártya SAS vagy SATA felülettel
- PCIe SSD kártya NVMe felülettel

Azert kell cpu is nem csak dma.
A dma-t fel kell programozni, raadasul mondjuk egy 6 lemezes raid10 tombre 6-szor minden egyes muveletre.
Mig hw rais eseteben egy irasi muvelet a hw kartyanak, s az megoldja a tobbit.
Meg persze nyilvan nem ilyen egyszeru, valamint a mai cpuknak, memoriaknak abszolut nem terheles az sw raid.
Bar dual xeon E5-2620 eseteben egy 8 ssd-s zfs stripe azert majdnem a procikapacitas 40%-at megette, dd if=/z/teszfile of=/dev/null bs=1m eseteben.
Jo, volt is troughput rendesen. :)
Meg ez nyilvan nem normal use case.
Az eles rendszeren dual xeon E5-2620 procival es 8 darab 15krpm SAS lemezzel, zfs "raid10"-val alig erezheto a terheles. Egy esxi van rajta 10gbe iscsi-n, az istgt porog 15-20%-on, zfs related processzek olyan 2-5% kozott vannak. Meg se kottyan a gepnek, pedig az esxi iranyabol azert rangatva van. Ja, es geli is van raadasul a zfs alatt.

Szoval vegso soron egyetertunk, de azert az sw raid eszik cpu-t is, nem csak a dma vezerlo dolgozik. :)

Sas ssd (van ilyen?) es sata ssd kozti kulonbsegre en is kivancsi vagyok, bar szerintem nincs kulonbseg, ha a sata ssd egy nornalis vezerlore van dugva, nem pedig az alaplapi szutyokra.

Igaz, hogy fel kell konfigolni a DMA kontrollert, de elenyésző az időigénye nagy blokkoknál (lásd: chunk size).

DMA kontroller:

- mely memóriáról
- mennyi adatot
- hova
- egy-két sallang paraméter kell még

Azaz beírunk a DMA kontrollerbe 4..5 db 32 bites szót és utána repül magától például 65536 byte a diszkre. Így elenyésző a konfigurálás terhelése a DMA kontroller által átmozgatott 1..2 GByte/másodperchez képest.

Persze más lenne a helyzet, ha 512 byte-onként vagy még kisebb egységenként kellene DMA kontrollert konfigurálni. Ekkor már érezhető lenne a DMA kontroller konfigurálás hatása.

Persze ettől erőforráspazarló megközelítéssel is meg lehet írni szoftvereket. Például DMA-ra nincs esélyed ha fuse felett userspace-ből mozgatsz innen oda adatot, stb.
De kernelprogramozás során is elkövetheted azt a hibát, hogy bár van több DMA kontrollered, mégis for() ciklussal másolsz sok-sok kilobyte-os blokkokat.

( freeoli v | 2016. 01. 06., sze – 12:15 )

SSD HW raid vezérlővel. Behozza az árát, főleg, hogy pénzkeresésre lesz használva. Nem éri meg mókolni, meg kell venni a tisztességes eszközt a munkához és kész.

A fentiekből kiindulva KKV vagy.

- sosem vittünk ki KKV ügyfélhez olyan rendszert, amihez nincs raktáron kompatibilis cold spare vasunk, akár komplett gép/hálózati eszköz formájában, ami darab-darab percek alatt átcserélhető
- cégen belül van 24 órás supportunk, szerver- és hálózati hardverhez is

Ha nagyvállalatról van szó, akkor persze más a tészta, mert többtízmilliós vasakhoz gyakran az egész kontinensen nincs senkinél cold spare DE(!) ott viszont olyan redundanciát csinál az ember, hogy egy-két node kiesése ne okozzon meglepetést.

Akkor nevezzük pikk-pakknak, úgy jobb?

Ha fontos a rendelkezésre állás, akkor úgyis megfelelő mértékű redundanciát kell megvalósítani. Ha nem volt fontos, nincs redundancia, és letérdel valami, akkor úgyis üzemidő kiesés van.

Szerintem az átlag KKV elégedetten csettint, amikor a havi pártízezer forintos szolgáltatási díj mellett az ügyelet átlagosan 1-1,5 órán belül a helyszínen van, és mondjuk további 10-30 perc közötti időben kilapátolja a szart a szekrényből, majd minden megy tovább.

Ez az ügyfél telephelyére vonatkozik. Ha az ügyfél gépe az adatközpontban lakik, ahol napi 24 órában helyben van az ügyeletes, ott riasztástól számított 10-30 percen belül ketyeghet az új vas.

És igen, az informatikában mindig benne van a szopás lehetősége, de a fentiek a tipikus idők a tapasztalatok alapján.

virtuálsi iroda mondjuk.
havi pár10 ezer ft, és nincs szükség saját szreverre, hanem kap tárhyelyet, meg mellé VDI gépeket.
neki meg bármiylen dzsunka gépe lehet, ami vpn-t és remote desktopot/pcoip -it tud futtatni, az mr megfelel.
ADSL-en remekül elketyegnek az ilyenek. nyomtatás meg megy lokalba automatikusan az rdp/pcoip printer redirect miatt.
minden mast meg a VDI vm-en hasznal.
backupolva is van az egesz cucc.

kar, hogy a magyar KKV nem erti, hogy mi si ez es miert job neki mint megvenni milliokert a szervert meg tobbszaz ezrekert erosebb kliensgepeket es szopni allandoan mindennel.

Ebben a kategóriában rossz szervert vagy rossz gyártótól vásároltatok. Nem végtelen horror a 7 év 4 órás on-site garancia ha az kell, ha a kieső üzleti vesztesség hozzámérhető, de egyébként 1-2 nap az alap a vásárolt on-site évekre, amiben az induló 5 év.

Nem tudom milyen brandet és kitől vettél, de a HP-nál, Dell-nél (ha megvetted ezt a garit) akár 4/2 órán belül viszik a csere cuccot. Ettől függetlenül hozzá kell tenni, hogy nem láttam még p4xx-et vagy perc-et tönkremenni, pedig vannak itt még 400-asok is.

Szóval ez így elég kevés info.

ez a vasnak hanyad része?
Jól gondolom, hogy itt is érdemes elgondolkodni azon pl, hogy az 1 "loaded" szerver helyett veszel kettőt, összepakolod amit lehet (CPU, RAM, disk) és a másik házat/lapot elrakod polcra? Ill. kettő szerver + support helyett kéred a harmadik szervert...

A fenti szervernél kb. az alapkiépítés árával egyezik meg.

Ha a saját szerverparkunkban levő 7X0-s szervereket nézem, ott az átlagos bekerülési érték olyan 1.5 - 2 millió Forint, 4.700 - 5.500 EUR körül van.
Szóval, olyan 40% körül lehet.
Persze, ez nem reprezentatív.

( LMoon | 2016. 01. 06., sze – 13:08 )

Ha van legalább 1 CPU és szabad RAM kapacitás és a vas korrekt szerver, akkor soft RAID.

( nikin v | 2016. 01. 06., sze – 14:35 )

Én LAMP felhasználásra az esetek nagy részében SW raidet választanék. De nagyon függ attól, hogy mi is fog futni azon a LAMP szerveren :) Nekem az adatbázisok meghálálták az SSD-t, és a mai CPU kkal SW raid nem terhelés.
Valódi jó választ csak a valódi feladat ismeretében lehet adni. Ha a sok olvasnivaló befér a RAM-ba ahogy van. Akkor úgyis cache-ben köt ki majdnem minden.
Alap válasz SoftRAID SSD. Érdemes viszont figyelembe venni, hogy azonos gyártó termékei sacc azonos időben fogják beadni a kulcsot. Lehet érdemes keverni a dolgokat, még ha így ugye a lasabb sebesség is lesz a szűk keresztmetszet.
Jut eszembe.. Miért RAID10 ha SSD? Mármint, ha reális opció A HDD sebesség is?

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Ha emlékezetem nem csak a H330 az egy LSI 3008 sas/sata controller (cache meg minden nélkül), ami azért messze van az enterprise raid kártyátől.

Hardveres raid kártyánál nincs is értelme a TRIM-nek, mert a trim egy adott eszköznek szól, de a linux nem tudhatja, hogy mi van a raid kártya mögött. Ilyenkor a raid kártya maga intézi az ilyen dolgokat a háttérben.

A 330 amúgy supportálja az SSD-ket: http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Docume… persze kérdés, hogy branddel vagy nem branddel próbáltad.
A 730 is supportálja rendesen az SSD-ket: http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Docume…

"Hardveres raid kártyánál nincs is értelme a TRIM-nek, mert a trim egy adott eszköznek szól, de a linux nem tudhatja, hogy mi van a raid kártya mögött. Ilyenkor a raid kártya maga intézi az ilyen dolgokat a háttérben."

és ha a linux nem tudja kiadni a TRIM parancsot annak a device-nak amit lát, akkor mégis honnan a túróból tudja a zenterprájz raid kontroller, hogy melyik file van letörölve és melyik nem? Mert az a taknyolás, hogy x százalékát a device-nak ne particionáljuk meg az ugye közelről sem fog olyan egyenletes wear leveling-et eredményezni, mint egy SW RAID esetén.

Jellemzően az OS-nek mind1, hogy a hwraid mögött mi van. Sok kártya a smartot általában átereszti vmi spec módon, de szintén sok kártya eleve jó infót ad a mögötte lévő hw-ről.

Másrészt ezek arra készülnek, hogy ott a garis szerződés és ha pirossá válik a diszkfault led, akkor szónélkül pattintják be a másikat és a hibásnak jelzett diszk megy gariba.

( NagyZ v | 2016. 01. 07., cs – 00:15 )

4k-s r/w terhelesnel nagyon gyors SSD-kkel a HW RAID bottleneck lesz, az SW RAID nem. csak FYI.

A Samsung SM863-akkal eddig nincs baja a P410-nek (ami egy 3+ éves kártya ha jól emlékszem, még a G6-os szériával jött) és a P410 akkor szereti az SSD-t ha új a firmware és csodalátos HP kivitel. Természetesen nem hajlobogtató a sebessége, de még mindíg komoly upgrade. A másik, hogy a P420 alatti HP vezérlőknél vagy nem is volt, vagy még csak szárnybontogatás volt az SSD. A lényeg jóval inkább az, hogy most már igény esetén könnyen beszerezhető SSD-t támogató sőt szerető HW raid kártya.

Egy 2013 decemberi doksi a P410-ről: http://www8.hp.com/h20195/v2/GetPDF.aspx/c04111713.pdf

régebbi intel SSD-vel (120G - talán 520as?) a 410-es 90/250mbyte-ot adott raid1-ben, uez 420-assal 150/450mbyte (write/read)

az ezért jelentős, majdnem dupla sebesség.
Próbáltam a 410 alatt mindent, array caching enable/disable, etc, de semmi olyan opciót nem találtam, amivel nem az egész kártyát kapcsolom (hiszen volt rajta egy SAS raid10 is)

(gyengébbeknek: raid1-ben az írás egyszerre mindkettőre történik, olvasás párhuzamosan, elosztva, ezért a különbség a két irány között)

Az 520-as Intel SSD egyrészt SandForce-os, másrészt ha jól látom, akkor desktop kivitel. Azt is leírtam, hogy tuti nem lesz hajlobogtató sebesség, mert SATA diszket a P410 eleve csak 3Gbps-en lát, másrészt még a tervezésekor nem számoltak komoly SSD felhasználással. Harmadrészt a hivatalosan supportált HP SAS SSD-kkel tuti jól működött, csak győzzed fizetni. :)

( zrubi v | 2016. 01. 07., cs – 00:59 )

Melyikkel járok jobban teljesítményben? LAMP szerver, sok olvasás, kevesebb írási művelet.

Szerintem teljesen egyértelműen az SSD + SW raid fog (nagyságrendekkel!) nagyobb teljesítményt produkálni. (feltételezve, hogy nem valami gyagyi desktop alaplap adja a SATA interfészt)

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu

( wpeople v | 2016. 01. 07., cs – 11:29 )

én máshonnan közelíteném meg. SLA számít?
Az számít, hogy a gépet le kell állítani lemezcseréhez?

éppen azon gondolkodtam, hogy régebbi (értsd HP G6/G7) szerverekbe ilyet (v egyéb SSD-t) hogyan volna érdemes belerakni.

Van-e már vmilyen rendszer (pl LVM dm-cache) kellemesen használható?

Ugye a fenti vasakban még p410 vezérlő van, ami max ~200mbyte/s sebességgel tudja használni az SSD-t.
Az alábbi opciókat látom a kérdéses vas IO részét gyorsítani:
1) raid vezérlő csere (p420-430-440-re) és SSD-t rakni a drive cage-be
2) külön drive cage az SSD-knek, vmi nem túl gagyi raid vezérlővel (avagy egy másik p410 és mindent átengedni rajta, talán)
3) berakni valami ilyesmi kártyát és valami cache eljárást használni

esetleg 4) két ilyen kártyát berakni a gépbe és md-raid
a drive cage-ben jelenleg 300G 10K SFF van

Van PCIe átalakító és puff beleteszel egy SM951-es Samsungot (ami NVMe-s) és az menni fog bőszen. Az NVMe-vel nekem hotswap és management gondjaim voltak főleg.

Ami még érdekel, hogy a P420-ak mennyire mennek jól G7-es HP-kban. Különös tekintettel a LED kezelésre és ilyesmikre.

mármint milyen PCIe átalakítóra gondolsz?
ami a "PCIe Gen3 x4"-t alakítja át PCI-E-re? ha igen, akkor jól hangzik, főleg, ha van olyan, amibe 2-t lehetne beledugni :-)

P420 g7-ben, nem tudom, még nem próbáltam.
A LED kezelés meg minek? Ha elromlik a vinyó, azt úgyis látod HPACUCLI-ban,azt meg tudod, melyik fiók melyik. Esetleg disk-UID-t is tudsz villantani.

Hát mert szeretek csak odamenni és cserélni és puff a jót húzom ki. :) Ha nemmegy a ledezés, akkor a diszk uuid-t se biztos, hogy megvillantja.

Sajnos dupla átalakítót még nem láttam. A delock féle szimplát próbáltam ki, teljesen passzív cucc, csak át van drótozva M.2-re a normál PCIe.

Rendelhetőek gondolom, de jól nézd meg őket, mert cseleznek általában. Pl. az egyik PCIe a másik mSATA vagy mindkettő mSATA. Sokszor csak az áram jön PCIe-ről, de SATA kábel kell hozzá, nem opciós. Én annó nagyon körüljártam és a linkeltet találtam (meg más gyártónál az ezzel egyenértékűt), de persze azóta lehetett vmi okosság. Szerintem nem akarnak PCIe bridge-et feltenni, hogy mondjuk x4-ből 2db x2-t vagy x8-ból 2db x4-et csináljanak, mert nagyon kicsi lenne a piac.