Fórum Root.cz
Hlavní témata => Server => Téma založeno: AltarSK 20. 05. 2025, 14:01:01
-
Ahojte.
Filozofická otázka.
Už je to nejaký čas čo som naposledy inštaloval server.
Dostal sa mi do rúk PowerEdge R660xs s 6x SSD diskami a ja silno premýšľam či na ňom spraviť RAID5 (prípadne RAID10) pole na radiči od servera alebo kvôli SSDčkám radšej spraviť RAID na ZFS v OS (Proxmoxe).
Neviem nikde nájsť info či raid na tomto serveri podporuje TRIM a potom mám obavy že v nakonfigurovanom "hw" raide neuvidím skutočný stav (Wear level) diskov.
Doteraz som mal vždy klasické hdd a raid som robil na radiči od servera. Ale teraz fakt neviem.
Máte nejaké odporúčania alebo užitočné myšlienky v tomto smere?
-
jsem v podobné situaci. Z toho co jsem zatím zjistil:
- ZFS NESMÍ běžet nad HW RAIDem
- do serveru je nutno dát řadič bez RAID, nebo do některých řadičů prý lze nahrát firmware bez RAIDu
Zatím jsem to taky nedořešil, rád si nechám poradit od někoho kdo už to dělal nebo se v tom vyzná
-
Borci a nechcete sem třeba napsat co to je přesně za řadič aby (když se to nechce vám) jsme si dohledali datasheet a zjistili co umí/neumí a pak adekvátně poradili?
Alternativně ServiceTag serveru.
-
Kristova noho...
Zfs stejne jako kazdej FS nad HW polem samozrejme bezet uplne normalne muze. Jen tak proste prijdes o nejaky ty ficury ktery to pripadne ma, kdyz si to pole ridi samo. Jinak to nema vubec sanci zjistit ze tam nejaky pole je.
Stejne tak prijdes o ficury toho radice, kdyz ho treba prepnes/preflashujes (pokud lze) do HBA rezimu.
Totez plati o btrfs.
ZFS je ovsem fs vyvijeny staromilci, a proto se to bude chovat dost podobne, jako kdybys k tomu HW radici pripojil misto disku dalsi HW radic s dalsim polem. Jinak receno, muze to mit pomerne flagrantni vykonovy dusledky.
A vzhledem tomu, ze to zjevne mas na hrani, tak si na tom udelej HWraid a neres kravoviny.
-
U 6 disku je to zcela jedno a pokud HW raid ma moznost pracovat se SSD (umi TRIM) tak pouzivej HW raid. Jinak radeji sw raid.. nez se ucit nejaky custom frikulinsky hw raid tool / klikatko.
Pokud bys mel disku 60, tak se oplati premyslet o ZFS.
Pro 600 disku je pak ZFS spise jedina moznost.
-
Kristova noho...
Zfs stejne jako kazdej FS nad HW polem samozrejme bezet uplne normalne muze. Jen tak proste prijdes o nejaky ty ficury ktery to pripadne ma, kdyz si to pole ridi samo. Jinak to nema vubec sanci zjistit ze tam nejaky pole je.
...
Přímo v dokumentaci od Proxmoxu (https://pve.proxmox.com/wiki/ZFS_on_Linux) se píše (zvýrazněno vykřičníkem):
Do not use ZFS on top of a hardware RAID controller which has its own cache management. ZFS needs to communicate directly with the disks. An HBA adapter or something like an LSI controller flashed in “IT” mode is more appropriate.
-
Borci a nechcete sem třeba napsat co to je přesně za řadič aby (když se to nechce vám) jsme si dohledali datasheet a zjistili co umí/neumí a pak adekvátně poradili?
Alternativně ServiceTag serveru.
U mě je to řadič 405-12091 : PERC H710 Adapter RAID Controller, 512MB NV Cache
Původně na tom běžel VMware ESXi, ale pro Proxmox je zřejmě tento řadič nevhodný.
-
Ahojte.
Filozofická otázka.
Už je to nejaký čas čo som naposledy inštaloval server.
Dostal sa mi do rúk PowerEdge R660xs s 6x SSD diskami a ja silno premýšľam či na ňom spraviť RAID5 (prípadne RAID10) pole na radiči od servera alebo kvôli SSDčkám radšej spraviť RAID na ZFS v OS (Proxmoxe).
Neviem nikde nájsť info či raid na tomto serveri podporuje TRIM a potom mám obavy že v nakonfigurovanom "hw" raide neuvidím skutočný stav (Wear level) diskov.
Doteraz som mal vždy klasické hdd a raid som robil na radiči od servera. Ale teraz fakt neviem.
Máte nejaké odporúčania alebo užitočné myšlienky v tomto smere?
Nevím, jestli následující myšlenky budou užitečné, ale zkusím to.
Oba přístupy jak HW RAID, tak ZFS jsou zcela validní, jen bych to důrazně nedoručoval kombinovat (ZFS nad HW RAIDem).
Každý má své klady i zápory.
HW RAID je typicky jednodušší na nastavení a ovládání, má vcelku predikovatelné charakteristiky. Při určitých workloadech může mít citelně rychlejší zápisy. Ale dost to záleží na kontroléru, jeho případných vnitřních optimalizacích, kolik má cache, jestli je pod baterkou/supercapem atp.
Nevýhody už tu byly nadhozené. Valná většina z nich nepodporuje TRIM/UNMAP, pokud nejsou v nějakém specifickém non-RAID (pass-trhough) režimu. Také je tam s RAIDem často mizerný přístup k servisním datům o disku, takže je člověk odkázaný jen na diagnostiku, kterou provádí firmware kontroléru. Byť určité kontroléry se SAS/SATA mají podporu ve smartmontools (např. u LSI/Broadcom smartctl -d megaraid,1 ..). Ale třeba s NVMe je to většinou en-bloc špatné, a pokud se člověku hodí při provozu nějaká telemetrie, přístupy i do vendor logů, je to docela velká nevýhoda.
Na stranu druhou v praxi to nemusí být tak špatné, jak to na první pohled vypadá. Sice znám lidi/situace, kdy ta absence trimování vedla časem opravdu k výkonovým problémům, ale hodně záleží na workloadu i konkrétních discích. A naopak zas situace, kde to už léta běží bez znatelných problémů.
Např. máme jeden menší server, kde běží libvirt/qemu na RedHatu, středně vytížený (takový mix, vývoj, testování deploymentu, postgresy atp.), je tam OEM Trimode LSI/Broadcom RAID se supercapem, 4 serverová NVMe SSD v RAID 10. Standardní XFS, qcow s externími snapshoty (některé image jsou pre-alokované). A po cca třech letech se to chová pořád velmi dobře.
U toho ZFS přeskočím tu klasickou omáčku okolo (výhody CoW, integrovaný volume manager, snapshoty, checksumy atp).
Řekněme, že kontrolér bude v nějakém pass-trhu režimu, nebo se vymění za standardní SAS model. Bude přímý přístup do všech zařízení včetně trimování (a vlastnost ZFS je, že to nedělá ihned, ale bere ohled i na ostatní I/O operace).
Může to být pro čtení v určitých workloadech rychlejší, ARC může být velká a má typicky velmi dobrý hit-rate, takže se spousta souběžných operací u rychle se měnících dat "vyřídí" z cache.
Čímž se dostávám k možným stinným stránkám. Tou první je případná komplexita nastavení a tweakování. Můžete mít třeba dilema, jestli dát víc RAM tomu ARC nebo nechat samotným virtuálům. Testovat a případně si hrát s desítkami parametrů.
Při větší náročnosti na zápisy (IOPSy, latence) je nutná optimalizace, jak kvůli rychlosti samotné, tak i zbytečným zápisům. Je důležité si uvědomit, že jakmile aplikace pošle fsync() data se zároveň zapisují i do ZILu. A pokud tam běží virtuály, co mají thin provisioned disky na ZVOLech, tak "přes" ZIL běží ve výchozím stavu všechny zápisy. Tohle je pak přesně obecná situace, kdy se opravdu využije SLOG (dvě mirrorovaná SSD dedikovaná pro ZIL) a dává většinou smysl.
Nejsou potřeba úplně velké disky (stačí klidně 64 nebo 128 GB), ale měly by mít velkou výdrž (ideální na to byly onehdá serverové Optany, které nepotřebovaly žádný trim, GC jako normální NAND SSD).
Ještě se vrátím k tomu ZFS nad HW RAIDem. Opravdu ta doporučení nejsou zbůhdarma, několikrát jsem viděl přesně vzorec - recykluju starý HW RAID z práce, naperu tam ZFS, přijdu o data při nějakém výpadku, všude vyprávím - ZFS je na <'> :)
ZFS je od začátku vyvíjeno do prostředí s přímým přístupem do jednotlivých vdevů (zařízení), počítá s tím, že I/O operace projdou do HW přes blokovou vrstvu v daném pořadí bez toho, aby hardware dělal další reordering. Tohle je důležité i pro správné seskupování do jeho transakcí (TXG). Spoléhá na to, že když danému zařízení pošle flush (FUA), opravdu to, co doteď zapsal, bude persistentní.
Což sice automaticky neznamená, že tohle bude se všemi HW RAIDy problém, ale minimálně to nikdo netestuje.
Podobně tam můžou nastat problémy, když ZFS se svou proměnlivou velikost bloků nemůže být principiálně pořád zarovnané s RAID 5/6 stripem, takže to chodí blbě, dělá to víc I/O operací než musí atp.
U točivých disků zvlášť pak spolu také můžou hezky "bojovat" optimalizace na úrovni kontroléru a ZFS.
-
To vypadá, že by se mohlo jednat skutečně o MegaRAID.
Našel jsem návod (https://fohdeesha.com/docs/perc.html) na cross-flash IT firmwaru pro celou rodinu a k tomu vlákno na fóru (https://forums.servethehome.com/index.php?threads/guide-flashing-h310-h710-h810-mini-full-size-to-it-mode.27459/), které obsahuje zajímavé komentáře na okraj, "když se nedaří" apod. Jenom jsem letmo líznul první asi dvě strany, a byl tam tip např. po/při cross-flashi odpojit baterku, jinak zůstanou v cache stará data RAIDového firmwaru což při bootu mate IT firmware...
-
IMO HW raid a ZFS řeší různé věci. Navíc ZFS umí většinu feature HW raidu, navíc nad nimi máš kontrolu.
Osobně bych zvolil ZFS nad SATA SSD v HBA režimu, protože mimo základních raidových funkcí poskytuje služby, které jsou velice užitečné. Snapshotování historie (používám sanoid) a zálohování send/receive (syncoid) je naprosto super. Možnost namontovat snapshot jako R/W klon, zkopírovat si z něj nechtěně smazaný/poškozený soubor/adresář - využívám bohužel dost často. Různé podadresáře mohou mít různé parametry (jako zfs filesystémy namontované na příslušné místo). I LZ4 komprese (v mém případě průměrně 2x více místa) je hodně užitečná a CPU výkonu je obvykle dostatek. SSDčka ocení, že nebudou moc zaplněná.
Disky mám v raid10. Mám ZFS i na pracovním kompu s jedním NVMe, pro vývojáře, který potřebuje šíbovat s mnohasetgigabajtovými databázemi pro lokální development, je snapshot DB slave -> clone + obfuskace pro devel velice užitečné, kdykoliv za pár sekund k dispozici aktuální data. Ale to samozřejmě není server use case.
Pokud by ten HW-raidový řadič nešel přepnout do HBA, pak za pár stovek koupit obyč JBOD LSI bez paměti se stejnými konektory, je jich plný ebay, i nové z Číny. Koupil jsem jich spoustu, nikdy žádný problém.
Samozřejmě výměna disku není tak pohodlná, jako přehodit disk v šuplíku, ale hot swap zůstane a těch pár příkazů při výměně disku mi nevadí, aspoň vím úplně přesně, co se děje. Navíc SSD je stejně potřeba měnit preventivně včas a nečekat, až se ušoupe k smrti v HW raidu, protože se pak hodně zpomaluje.
-
U mě je to řadič 405-12091 : PERC H710 Adapter RAID Controller, 512MB NV Cache
Původně na tom běžel VMware ESXi, ale pro Proxmox je zřejmě tento řadič nevhodný.
Tento řadič nepodporuje transparentní TRIM na SSD do operačního systému. HBA to také není.
Alternativní možnost je jak psal F.Ryšánek to zkusit reflashnout na IT firmware - na vlastní riziko.
Nebo tam prostě udělat klasický HW RAID a použít megacli. Řadič si životnost těch disků ohlídá (zvlášť pokud jsou to "originál Dell") a k informacím se dostaneš, jen jinak...
Pokud se nedoporučuje používat ZFS nad HW RAIDem tak bych se toho držel a použil jiný filesystem pro hosta.
-
Ako pise "hungarec", daj Service Tag alebo napis aky radic tam mas (PERC H965i, PERC H755, PERC H755N, PERC H355, HBA355i, HBA465) ...
-
Osobně bych zvolil ZFS nad SATA SSD v HBA režimu, protože mimo základních raidových funkcí poskytuje služby, které jsou velice užitečné. Snapshotování historie (používám sanoid) a zálohování send/receive (syncoid) je naprosto super. Možnost namontovat snapshot jako R/W klon, zkopírovat si z něj nechtěně smazaný/poškozený soubor/adresář - využívám bohužel dost často. Různé podadresáře mohou mít různé parametry (jako zfs filesystémy namontované na příslušné místo). I LZ4 komprese (v mém případě průměrně 2x více místa) je hodně užitečná a CPU výkonu je obvykle dostatek. SSDčka ocení, že nebudou moc zaplněná.
...
Pokud by ten HW-raidový řadič nešel přepnout do HBA, pak za pár stovek koupit obyč JBOD LSI bez paměti se stejnými konektory, je jich plný ebay, i nové z Číny. Koupil jsem jich spoustu, nikdy žádný problém.
Zatím ještě nevíme, co má přesně tazatel za ty kontroléry a disky v Dell serveru. Jak už tu bylo zmíněné, v těchhle řadách šly asi čtyři modely z 11. a 12. generace PERCu. Používá to povětšinou OEM modely tri-modových LSI, SSD můžou být jak SAS, tak NVMe (pak nemusí být úplně snadné sehnat alternativní HBA za pár stovek).
Nehledal jsem u tohohle konkrétního modelu, ale jsou také dva základní formáty karet s kontroléry - normální low-profile PCIe a pak interní "front" modely, které nemají standardní konektory. Karta je kratší a pro připojení do základní desky se používá kabel s konektorem, co vypadá jako slim-sas, na druhé straně jsou pak konektory na zapojení do backplane.
A stran toho použití ZFS, ty zmíněné praktické výhody jsou vcelku zřejmé, zvlášť když se to používá přímo na ukládání do datasetů. Na druhou stranu pokud na serveru běží hypervizor a QEMU, tak ty čistě praktické rozdíly mezi ZFS a "normálním" filesystémem nemusí být tak markantní. Protože snapshoty, šifrování (přes image s LUKS), kompresi, trackování změn přes bitmapy na zálohování atp. umí i QEMU samo o sobě.
Samozřejmě můžeme zabřednout do technických detailů, co je rychlejší, jak snadné je používání (IMHO úplně nemusí, ale neznám Proxmox, je možné, že spousty těch složitostí to schová třeba při používání jejich Proxmox Backup).
-
HW Raid skryje před ZFS cenná data o chování disků a přidává falešné flushe, tj. zvyšuje se riziko ztráty dat.
Připojuji se k ostatním, raději koupit levnou JBOD kartu, pokud současná nebá podporu třeba pro HBA.
Qemu a jeho qcow sice poskytuje podobné funkce pokud jde o snapshoty, ale jeho stabilita a rychlost jsou naprosto tristní.
-
Pujdu proti proudu.
Pokud mam takovou konfiguraci a hw raid mi to podporuje pak nevidim jediny duvod proc se morit se ZFS. Udelal bych raid 5 plus mirror (pokud bych nechtel spare), lvm + fs dle meho vyberu a jdu dom. Snapshoty si resim na kvm/proxmoxu. ZFS je fajn pokud nemam slusny raid. Znackovej raid karty nejsou vubec zle, napriklad hpeckova smart array maji genezi snad 30 let jeste z dob compaqu a jsou to spolehlive karty, s vicemene stejnymi tooly a filosofii. Dell na tom bude imo podobne (nemam zkusenost) - zkus pohledat po forech.
-
Zatím ještě nevíme, co má přesně tazatel za ty kontroléry a disky v Dell serveru. Jak už tu bylo zmíněné, v těchhle řadách šly asi čtyři modely z 11. a 12. generace PERCu. Používá to povětšinou OEM modely tri-modových LSI, SSD můžou být jak SAS, tak NVMe (pak nemusí být úplně snadné sehnat alternativní HBA za pár stovek).
Tak píše PERC H710, to je staré SAS2/SATA3. V těch klecích (Dell i HP) jsem používal SATA (i SATA SSD) - nakonec není problém, aby to tazatel vyzkoušel.
Pokud to má standardní SAS2 SFF-8087 konektory, s vysokou pravděpodobností tam bude fungovat jakýkoliv SAS řadič (mám vyzkoušené SAS9208-8i IT firmware). Zda to z něj bude i bootovat nevím, ale je dost pravděpodobné, že jo.
-
Bez ZFS nebo Ceph nefunguji snapshoty(qcow2 nepocitam) a ty potrebujete na replikace a inkrementalni zalohovani. Ja mam ZFS nad IBM FlashSystem 5200 pripojenem pres FC k jednotlivym serverum. ZFS nejde pridat pres web, takze jsem musel: zpool create -f .... /dev/mapper/mpatha
FlashSystem mam dva radice ktere si kopiruji cache a samozrejme baterku, takze co jednou zapise do cache se vzdy dostane na disk.
Preci nevyhodim 240TB NVMe jen proto ze si vyvojari ZFS predpokladaji ze raid = swraid integrovany na MB ;)
-
Pujdu proti proudu.
Pokud mam takovou konfiguraci a hw raid mi to podporuje pak nevidim jediny duvod proc se morit se ZFS. Udelal bych raid 5 plus mirror (pokud bych nechtel spare), lvm + fs dle meho vyberu a jdu dom. Snapshoty si resim na kvm/proxmoxu. ZFS je fajn pokud nemam slusny raid. Znackovej raid karty nejsou vubec zle, napriklad hpeckova smart array maji genezi snad 30 let jeste z dob compaqu a jsou to spolehlive karty, s vicemene stejnymi tooly a filosofii. Dell na tom bude imo podobne (nemam zkusenost) - zkus pohledat po forech.
on je rozdíl v provozu, pokud mám raid 5+0 (ať už SW nebo HW), tak největší problém je používání v degraded stavu, prostě to musím nejprve obnovit a obnova u 5 trvá snad ze všech možností nejdéle.
Skvělé na zfs je schopnost ověřit stav na disku a případně chyby opravit, to u jiných řešení není tak běžné.
Pokud jde o řešení uložiště, hlavní rozhodování by mělo být podle toho, jak se to chová v případě problémů a ne když vše funguje jak má, pak není skoro co porovnávat, že?
Také spravuji servery, které 20+ let fungují nad jediným diskem a běží stabilně, ale přece na základě toho nebudu říkat, že raid je k ničemu. Stejně tak mám pod rukama clustery s tisíci disky, kde každý týden se nějaký disk mění, z toho ale také nemohu vyvozovat, že disky jsou k ničemu a bez raidu si ani nevrznu.
-
Zatím ještě nevíme, co má přesně tazatel za ty kontroléry a disky v Dell serveru...
Tak píše PERC H710, to je staré SAS2/SATA3...
Tazatel (AltarSK) zatím opravdu neuvedl.
PERC H710 uvedl Libor, kterej se přidal že řeší podobný problém.
-
Pujdu proti proudu.
Pokud mam takovou konfiguraci a hw raid mi to podporuje pak nevidim jediny duvod proc se morit se ZFS. Udelal bych raid 5 plus mirror (pokud bych nechtel spare), lvm + fs dle meho vyberu a jdu dom. Snapshoty si resim na kvm/proxmoxu. ZFS je fajn pokud nemam slusny raid. Znackovej raid karty nejsou vubec zle, napriklad hpeckova smart array maji genezi snad 30 let jeste z dob compaqu a jsou to spolehlive karty, s vicemene stejnymi tooly a filosofii. Dell na tom bude imo podobne (nemam zkusenost) - zkus pohledat po forech.
on je rozdíl v provozu, pokud mám raid 5+0 (ať už SW nebo HW), tak největší problém je používání v degraded stavu, prostě to musím nejprve obnovit a obnova u 5 trvá snad ze všech možností nejdéle.
Skvělé na zfs je schopnost ověřit stav na disku a případně chyby opravit, to u jiných řešení není tak běžné.
Pokud jde o řešení uložiště, hlavní rozhodování by mělo být podle toho, jak se to chová v případě problémů a ne když vše funguje jak má, pak není skoro co porovnávat, že?
Také spravuji servery, které 20+ let fungují nad jediným diskem a běží stabilně, ale přece na základě toho nebudu říkat, že raid je k ničemu. Stejně tak mám pod rukama clustery s tisíci disky, kde každý týden se nějaký disk mění, z toho ale také nemohu vyvozovat, že disky jsou k ničemu a bez raidu si ani nevrznu.
1) nepsal sem raid 50. Psal sem RAID5 + RAID1 - uzivatel ma 6 disku a ma to na lab - za me naprosto idealni setup Chovani v degraded stavu muzete ovlivnit nastavenim radice, kdy muzete prioritizovat rebuild nad i/o a obracene. Souhlasim s tim ze vice disku v raidu/logical volumu => vetsi moznost ze nejaky selze. Ncimene jak se s tim to ci ono pole popasuje zalezi na name. Meli jsme to treba HPE Evu ktera delala diskgroupy po 12 discich a nikomu to nevadilo. Meli jsme tu treba ibm storvize, kde byl aktivni cely rack a taky to nikomu nevadilo.
2) Na server raid radicich zase ocenuji prediktive failure, kdy casto dostane hlasku o tom "ze se neco deje", ncimene disk funguje dal a pole neni v degraded stavu. Vendori takova disky uzvanvaji jako vadne a automaticky je meni (ne ze by pro lab to bylo smerodate), ale mate imo vetsi cas tim neco udelat.
HW Raid skryje před ZFS cenná data o chování disků a přidává falešné flushe, tj. zvyšuje se riziko ztráty dat.
Jak ? Prosim rozvest
Qemu a jeho qcow sice poskytuje podobné funkce pokud jde o snapshoty, ale jeho stabilita a rychlost jsou naprosto tristní.
Takovou zkusenost tedy opravdu nemam. Rychlost a stabilita je naprosto bezna s podobnout operaci treba ve vshpere
Obecne: bylo by fajn se taky podivat do historie proc a kdy zfs vzniklo. Zatimco jedni vendori (ibm, hp, dell apod) sli cestou hw raidu, Sun sel cestou zfs sw raidu. Obe reseni se v praxi ukazala jako zivotaschopna a maji sva pro a proti. Prijde mi ze uzivatele a vyvojari zfs spatne chapou jak server like/enterprise controllery (ne fakt se nebavime o pseudo desktop raidech) funguji. Byl tu zminen napr. "reordering" - wtf ? Nejspis je minen reordering v ramci raidu ale to je pro zfs cokoliv naprosto irelevantni, v podostaten neexistuje scenar ze byste nedostali data, ktera byla potvrzena. Pokud by to byla pravda pak Vam nebou fungovat ani relacni db. Je otazka proc pak zfs nad takovy raid nasazovat kdyz obe veci delaji vicemene to stejne, Kdyz to shrnu tak:
Hw raid + legacy fs bych nasadil v pripade ze:
- Mam slusnej kontroler/kartu/pole
- Mam obecne v raidech mensi pocet disku, pripadne je umim delit
- Nepotrebuji resit snapshoty na baremetalu, pripadne nemam technologie ktere je podporuji (fs/db/virtualizaci)
- umim s prislusnou technologii
ZFS bych nasadil v pripade ze:
- mam jbod disky a chci raid
- mam nejake specificke pozadavky na vykon/dostupnost/io - napriklad pokud stavim nejake kriticke centralni uloziste a potrebuju versatilitu
- umim se zfs :)
Slusnej standartni hw raid typu p420 kterej se rve do kazdyho proliantu je imo naprosto dostacujici pro 90% entry/midrange prostredi
-
Zdravím.
Nebol som od včera online tak som nemohol reagovať skôr ale vidím, že diskusia sa rozprúdila.
Server je ešte zabalený a jediné info ktoré o ňom mám je to na krabici:
- Intel Xeon Silver 4410T
- 32 GB RDIMM, 5600 MT/s Dual Rank
- 480GB SSD Sata Read intensive 6Gbps 512 2.5in Hot-plu AG Drive
- ...
- Front PERC H755 Front Load
- Broadcom Dual Port 1Gb
- ...
Takže radič je viac-menej jasný.
Tých 6 diskov je originál od DELLu.
Takže keď som tu otázku pokladal, nepremýšľal som nad variantou, že ZFS pod HW raidom ale radič prepnutý na nejaký priamy prístup k diskom a len ZFS na proxmoxe.
Ale keďže aj tie disky sú od DELLu tak by som sa možno nebál ani toho riešenia na strane radiča.
Ešte si idem prečítať čo ste popísali.
-
Zatím ještě nevíme, co má přesně tazatel za ty kontroléry a disky v Dell serveru...
Tak píše PERC H710, to je staré SAS2/SATA3...
Tazatel (AltarSK) zatím opravdu neuvedl.
PERC H710 uvedl Libor, kterej se přidal že řeší podobný problém.
Tak to se omlouvám
-
PERC H755 podpora RAID 0, 1, 5, 6, 10, 50, 60 alebo aj Non-RAID, 8 GB DDR4 cache, Write back, write through, no read ahead, and read ahead, hot swap podporovany, dedicated and global hot spare :
https://shorturl.at/gOvCt
Stav fyzickych diskov, stav virtualnych RAID vies manazovat/monitorovat cez iDRAC 9 :
https://shorturl.at/pB2NY
https://shorturl.at/hW2Mb
https://shorturl.at/YT5fo
Skoda, ze si nenapisal Service Tag.
-
- Front PERC H755 Front Load
Tento řadič podporuje TRIM a umí non-RAID disky (v systému se disk tváří jako iSCSI), takže by to jít i mohlo.
Pokud můžeš, rozbal, nastav, nainstaluj, vyzkoušej a dej vědět i pro ostatní.
-
1) nepsal sem raid 50. Psal sem RAID5 + RAID1 - uzivatel ma 6 disku a ma to na lab - za me naprosto idealni setup Chovani v degraded stavu muzete ovlivnit nastavenim radice, kdy muzete prioritizovat rebuild nad i/o a obracene. Souhlasim s tim ze vice disku v raidu/logical volumu => vetsi moznost ze nejaky selze. Ncimene jak se s tim to ci ono pole popasuje zalezi na name. Meli jsme to treba HPE Evu ktera delala diskgroupy po 12 discich a nikomu to nevadilo. Meli jsme tu treba ibm storvize, kde byl aktivni cely rack a taky to nikomu nevadilo.
Moje chyba, psal jsi raid 5 + mirror, pochopil jsem to jako 50. Prioritizovat rebuild, ano, pokud máš spare disky, může to být background proces, to je asi nejvhodnější řešení při použití pětky.
2) Na server raid radicich zase ocenuji prediktive failure, kdy casto dostane hlasku o tom "ze se neco deje", ncimene disk funguje dal a pole neni v degraded stavu. Vendori takova disky uzvanvaji jako vadne a automaticky je meni (ne ze by pro lab to bylo smerodate), ale mate imo vetsi cas tim neco udelat.
HW Raid skryje před ZFS cenná data o chování disků a přidává falešné flushe, tj. zvyšuje se riziko ztráty dat.
Jak ? Prosim rozvest
Jj, tak to i běžně měníme jak na běžícím pásu a pro reklamaci se poskytuje jen report z řadiče.
ZFS má vlastní mechanismus jak detekuje vadný disk a případně ho nahrazuje za spare, pokud ale vidí virtuální blokové zařízení, jeho metriky neodpovídají stavu fyzického disku (to je v případě třeba vytvoření raid 0 s jedním diskem jako simulace JBODu/HBA, když to řadič neumí). Raid zpravidla zápisy strká do cache a reportuje jako zapsané do OS (narozdíl od HBA), opakované čtení čte data z cache, ikdyž se na pozadí ještě nemuselo podařit je zapsat fyzicky na disk, zfs se pak chybně může domnívat, že jsou data persistovaná.
Samozřejmě, když tyhle omezení znám, není to překážka, není velký problém data z disků do zfs reportovat jinou cestou nebo vlastním daemonem aktivovat spare disky. Stejně tak není problém mít agresivnější a častější self healing. U datových serverů s velkým provozem cache v řadič zpravidla není schopná držet moc dat, takže problémy se záhy ukážou. Jde s tím žít, ale musíš se podle toho zařídit.
Qemu a jeho qcow sice poskytuje podobné funkce pokud jde o snapshoty, ale jeho stabilita a rychlost jsou naprosto tristní.
Takovou zkusenost tedy opravdu nemam. Rychlost a stabilita je naprosto bezna s podobnout operaci treba ve vshpere
Pokud máš takovou zkušenost, tak je to vlastně super :). QCOW2 výkon padá s počtem snapshotů, propad proti rawu bez jediného snapshotu je ze zkušenosti při čtení asi 20 - 30 % (ano s qcow3 se to zlepšilo, ale nebyl jsem schopný pozorovat skoro nulový rozdíl proti raw, jak avizují v dokumentaci), to není málo. Ano pokud to porovnáváš v single thread, rozdíl je nicotný, pokud ale nad tím máš VM s více fyzickými cpu a konkurenčně čteš/zapisuješ, problém je na světě. Přímé porovnávní proti vsphere jsem nikdy nedělal. QCOW2 při růstu zůstává na jednom blokové zařízení a velmi špatně se rozděluje na více fyzických disků (musíš použít raid), režije při hodně snapshotech a velikosti je značná, to s vspere jsem nepozoroval. Šachování s linkem a vlastní shardering je prostě už příliš komplexní na nějakou údržbu.
QCOW2 má důležitá data v hlavičce souboru, kde se často přepisují, některé věci ti umí qemu-img check -r opravit, ale některé ne. Poškozenou hlavičku jsem viděl už několikrát při chybě disku při zápisu, kupodivu poslední dobou s ssd disky to je častější než kdy dříve. Pak je to na velkém laborování s hlavičkou a dát se ručně nějak rekonstruovat, zejména pokud víš, že k chybě došlo v posledních zápisech. Nějaká kontrola integrity zapsaných dat se s qcow2 moc neděje, zabudované šifrování tomu ale velmi pomáhá.
Slusnej standartni hw raid typu p420 kterej se rve do kazdyho proliantu je imo naprosto dostacujici pro 90% entry/midrange prostredi
To s tebou souhlasím, pokud se někdo musí ptát na zfs, nejspíš to není systém pro něj a obyčejný ext/btrfs nad hw raidem mu poslouží daleko lépe.
-
U RAID pole je úplně nejdůležitější umět z něho obnovit data po výpadku jednoho nebo dvou disků.
Dále umět s tím polem pracovat na takové úrovni že umím přidat další disk do stávajícího, ev. je postupnou výměnou vyměnit za větší, a zvětšit pole.
Proto je nejvhodnější, alespoň z mého pohledu, hardwarový RAID.
Netvrdím že softwarový RAID je špatný, ale málokdo ho umí vybudovat tak aby byl spolehlivě bezpečný.
Microsoft, ale i další služby tyto softwarové RAID nejspíše používají, ale jejich použití je že mají tři (3) zrcadlený pole/servery které v rámci služby nabízí.
Takže softwarové uložiště s kapacitou 30 disků, znamená fyzický 90 disků. Mohou si to dovolit ceny disků které dostávají jsou řádově jinde než na běžném trhu.
-
To s tebou souhlasím, pokud se někdo musí ptát na zfs, nejspíš to není systém pro něj a obyčejný ext/btrfs nad hw raidem mu poslouží daleko lépe.
Tady jenom podotek, Btrfs ve výchozím stavu je opravdu velmi pomalý pro přepisy s krátkými bloky, časem se také výrazně zvyšuje fragmentace souboru.
To je bohužel problém pro některá nasazení databází a ukládání image od virtuálních disků. Dá se to obejít jen tak, že se selektivně vypne COW (chattr +C /dir), než se vytvoří nebo nakopírují soubory.
Což je i standardní nastavení třeba v OpenSUSE (i Fedoře) pro adresář na QEMU image od libvirtd, nebo datové adresáře od databází ze systémových balíčků.
Takže pak to přepisuje původní sektory (in-place), nedělají se checksumy atp.
Ale jakmile by se vytvořil snapshot toho subvolume, kde to je (třeba pro zálohu nějakým externím programem, rychlý revert nebo btrfs send), tak se implicitně zas zapne COW pro všechny další zapsané nebo změněné extenty - a postupně jste zas zpátky. Jinak by to nemohlo fungovat.
Takže když už se Btrfs v téhle situaci používá a smíříte se s tím, že přijdete o COW, je si potřeba dát pozor na to, aby ty adresáře nebyly součástí snapshotů. Pokud je to samostatný disk, partišna s jedním root subvolume, je to v pohodě. Pakliže je to třeba v dohromady se systémem, kde můžou být periodické snapshoty, tak je třeba udělat na ty konkrétní adreáře samostatný subvolume.
https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/FAQ.html#Can_copy-on-write_be_turned_off_for_data_blocks.3F
https://www.percona.com/blog/taking-a-look-at-btrfs-for-mysql/#comment-10973474
Jinak to samozřejmě neznamená, že je to vždy problém. Na nějaké blbnutí nebo relativně nevytížený virtuál na normálním počítači, kde je třeba celé SSD na Btrfs, to asi může být jedno. Ale na serveru, kde je většinou na data samostatný oddíl (nebo LUN z RAIDu) na virtuály bych to opravdu řešil a upřímně než Btrfs bez COW, snapshotů bych tam dal rovnou XFS (příp. ext4, pokud k tomu je nějaký speciální důvod).
-
mimochodem, jaké máš zkušenosti s obnovou HW raidů? Já jsem z toho segmentu trochu rozporuplný, těch kontaktů s podporou daného výrobce jsem zažil asi už příliš, ty hromady ručně nahrávaných firmwarů, která support háže jak na běžícím pásu (segment 1U - 4U standalone serverů nikoliv diskových polí). S ZFS to je poměrně lahoda a ani si nepamatuji, kdy jsem nebyl schopný vadný disk za rozumnou dobu obnovit. Naopak provoz ZFS už taková lahoda není, chce to trochu studování.
Mně u HW raidů prostě vadí jak strašný to je blackbox, jak extrémně málo interních informací ti výrobce poskytne, jak to je plné různých bugů a problémů, které se prostě řeší dny na podpoře. Naštěstí dnes prakticky všude už žádná důležitá data na lokálních discích nemáme a raději celý server obnovujeme, když odejde OS disk.
Pomalu se kloním k variantě, kdy je lepší asi raději ty raidy nepoužívat vůbec a data rovnou replikovat na jiný server. Je to jednoduší, transparentní, lze to rozšířit snadněji o plnohodnotné zálohání, není potřeba taková fůra znalostí kolem toho všeho. Není nic horšího než čekat na seniora, který zrovna je někde v loji a bez něj nejsi schopný server obnovit, protož tam je vždy nějaké "ale" a každá chyba může vést ke ztrátě dat.
-
mimochodem, jaké máš zkušenosti s obnovou HW raidů? Já jsem z toho segmentu trochu rozporuplný, těch kontaktů s podporou daného výrobce jsem zažil asi už příliš, ty hromady ručně nahrávaných firmwarů, která support háže jak na běžícím pásu (segment 1U - 4U standalone serverů nikoliv diskových polí). S ZFS to je poměrně lahoda a ani si nepamatuji, kdy jsem nebyl schopný vadný disk za rozumnou dobu obnovit. Naopak provoz ZFS už taková lahoda není, chce to trochu studování.
Nijak extra širokou zkušenost nemám, v podstatě pár kousků za ta léta. Většinou když už se ke mě dostalo něco na obnovu, bylo to typicky Synology, QNAP, kde je normální mdraid (pokud nepočítám ty nejdnovější modely s ZFS).
U těch klasických serverových RAID adaptérů (LSI, Areca, Adaptec.. a nějaké OEM varianty) to bylo v podstatě zřídkakdy, byly tam třeba problémy, kdy prostě odcházela ta karta a skončilo to třeba poškozeným obsahem NVRAM. Vyměnit kartu, naimportovat svazek a v pohodě.
Nebo to byla taková ta klasika, kdy je RAID-5 s disky na konci životnosti, dáš rebuild ze spare a v tu chvíli to vykopne další disk a celé se to zastaví. Ale při troše štěstí jeden z těch odešlých disků nemusí být úplně kaput, a třeba ho přes ddrescue zkopíruješ po více průchodech na čerstvý disk (100% sektorů), vyresetuješ kontrolér a naimportuješ celý RAID podle signatur na discích. Tohle se mi třeba povedlo dvakrát, jednou s LSI (OEM Dell), ale fakt to beru jako kliku.
Blbý je, když se to překopíruje s chybami, to už je pak na to seskládat to v nějakém programu a ani to nemá smysl zkoušet v tom původním kontroléru, protože se to typicky stejně zastaví a rozpadne. V tomhle případě to může komplikovat zjištění layoutu (offset, typ rotace parity). Dneska už poměrně hodně recovery programů má nějakou autodetekci a zná obvyklé nastavení od spousty výrobců (např. Hetman). Já když jsem to před lety dělal tak jsem si vzal kostičkovaný papír a iteroval několik hodin, než jsem se někde dobral, že ten HP RAID má delayed parity.. a slavnostně přečetl slovo EFI na offsetu 0x200 :) Oproti tomu RAID 5 z Arecy byl pak třeba úplně v pohodě.
Ale stejně, já to dělám v podstatě ze zájmu, nebo pro své účely, známé. Takže mám relativně omezené možnosti, co s tím můžu udělat, nemám třeba rovnou k dispozici velkou SAS/SATA bednu (max. 8 slotů, plus něco na kabely uvnitř). Pokud fakt odejde disk a nejde z něj číst, tak mám známé profíky, co mají hromady náhradních dílů, speciální nářadí, přístroje, komerční i svůj software a hlavně také platí těm výrobcům disků, aby se dostali do servisních oblastí, dovedli ty disky třeba rekalibrovat atp. Stejně jako když jde o něco složitého (třeba částečně přepsané věci), nebo za hodně peněz, tak je posílám rovnou za nimi.
Ale fakt, když to vezmu celkově tak to nebylo zdaleka tak problematické a chovalo se to víceméně očekávávaně. Paradoxně jsem zažil víc problémů, byť ne třeba data ohrožujících, s těmi dedikovanými a řádově dražšími FC/iSCSI externími poli - i v takové té nižší střední třídě. Přesně kritické updaty firmware, rozbité failovery s redundantními kontroléry, ztrácení dat z NVRAMek (RAID signatura a data zůstane na discích, ale vymázne to mapování LUNů, přístupová práva), vykopávání zdravých disků. Oproti tomu ty karty byly vlastně v tom množství docela v pohodě.
Mně u HW raidů prostě vadí jak strašný to je blackbox, jak extrémně málo interních informací ti výrobce poskytne, jak to je plné různých bugů a problémů, které se prostě řeší dny na podpoře. Naštěstí dnes prakticky všude už žádná důležitá data na lokálních discích nemáme a raději celý server obnovujeme, když odejde OS disk.
Jak se to vezme, na jednu stranu to je sice blackbox, ale pokud fakt dojde na lámání chleba, tak když u toho klasického HW RAIDu trefíš zmíněné parametry (byť je to blackbox), tak je to pořád "hratelný", byť i to se v poslední době pěkně komplikuje (declustered RAID atp). Kdybych měl nějakou kritickou chybu média bez další redundance s částečným obnovením a poškozené struktury třeba u ZFS, tak jsem úplně v pytli. Člověk, co to dá do kupy, tak je pro mě Čáryfuk.. (proměnlivá velikost bloku, komprese, bez pevného pravidelného prokladu, téměř bez šance se chytit se relativně jednoduše nějakých patternů v souborech). Asi by to někdo dal, ale pro mě je to na úrovni šifrování i když tam žádné nutně není :)
Pomalu se kloním k variantě, kdy je lepší asi raději ty raidy nepoužívat vůbec a data rovnou replikovat na jiný server. Je to jednoduší, transparentní, lze to rozšířit snadněji o plnohodnotné zálohání, není potřeba taková fůra znalostí kolem toho všeho. Není nic horšího než čekat na seniora, který zrovna je někde v loji a bez něj nejsi schopný server obnovit, protož tam je vždy nějaké "ale" a každá chyba může vést ke ztrátě dat.
Nevím, fakt bych to obecně neviděl tak problematicky. To jestli to jde bez RAIDu strašně záleží na situaci, beru to primárně pro zvýšení dostupnosti, kdy to jeden nebo dva vadné disky nepoloží. Klasická záloha je samozřejmě super, ale stejně to znamená výpadek, výměnu, restore a typicky i díru v datech od poslední zálohy.
Replikace s failoverem není vždy dobře realizovatelná (třeba kvůli výkonu nebo množství dat) a hotové úložné systémy, co to umí dobře, a od začátku s tím počítají, jsou pekelně drahé. Nebo je to relativně dost komplexní záležitost (Ceph). Ale chápu, že v určitých aplikacích i třeba nějaké jednodušší řešení s DRBD může dávat smysl.