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.
28 Odpovědí
29708 Zhlédnutí