Top nejčastějších chyb při volbě storage na serveru

Úvod

Dnes se podíváme na srovnání různých řešení, které umožňují výstavbu storage a nejčastější chyby, se kterými se lze setkat.

Obecně se budeme zabývat rozdílnostmi mezi aktuálně populárními poli se zaměřením na jejich komparaci pak volně přejdeme k materiálům z tohoto odkazu, především sekce Storage types.
Mezi pole, na které se zaměříme více a to spíše z pohledu solution architektury a budou dnešním hlavním tématem patří:

• HW RAID
• ZFS
• CEPH

Budeme přihlížet k tomu, aby se jednalo o problematiku aplikovanou na virtualizaci Proxmoxu, ale z obecného hlediska to bude více stejně o světě Linuxu.

HW RAID

Samotná technologie vyrůstala v období, kdy disky neměly takové kapacity, potřeba po redundanci byla vysoká a svět softwarového vývoje nebyl tak rozsáhlý. Tento produkt starší doby s sebou nese několik problémů dané doby.
Mezi ty hlavní problémy patří:

1. Vendor lock/kompatibilita
2. Náročnost definice, co je to HW RAID
3. Problematická výměna komponent v případě havárie
4. Vysoká cena
5. SPoF
6. Limitace

Vendor lock

V dnešní době už se příliš nevyskytuje, ale byly doby, kdy zakoupením HW RAID od určitého výrobce bylo možno provést obnovu jen a pouze na stejném HW od stejného výrobce. Naštěstí, tento jev již odpadl v důsledku snižující se poptávky po serverech s RAID. I tak se občas se vyskytuje a je to vždy náročná problematika k řešení. Ideálním řešením u rozumných firem je prevence. Mít zkrátka další RAID či stejný server skladem.

Náročnost definice, co je to HW RAID

Existují různí výrobci a mají různé obchodní metody dodávky produktů. A na trhu naleznete mnoho způsobů, jak vyjít vstříc cenou zákazníkovi. Abychom si rozuměli, HW RAID musí mít dedikovanou kartu. V podstatě dedikovaný stroj v serveru. Tím, že HW RAID byly a jsou stále drahé, výrobci hledali cesty jak ušetřit tím, že tuto technologii začali různě modifikovat, aby vyšli vstříc nižší ceně koncovým zákazníkům. Takže lze např. nalézt HW RAID, které v podstatě simulují SW RAID. Ale jsou levné. A podobných specifik lze najít více. Proto je pojem HW RAID celkem neurčitý a vždy je u něj potřeba dívat se na okolnosti použití v praxi.

Problematická výměna komponent

V případě havárie HW RAID je často problém nalézt tu stejnou komponentu nebo někoho kdo ji stále distribuuje. Jedná se o přirozený stav v tržním prostředí, který krystalizuje v průběhu času.

Vysoká cena

Pro doplnění, často kvalitní HW RAID je vyvážen vysokou cenou. Je-li cena serveru nízká, pravděpodobně kvalitní RAID není jeho součástí.

SPoF

Hovoříme o jedné dedikované kartě, tedy jedná se SPoF celého serveru.

Fyzikální limitace

Z dnešního pohledu jsou další nevýhodou fyzické limitace RAID. Tedy jaké maximální kapacity unesou. O tomto bodu můžeme polemizovat, ale shodneme se že pole s několika PB už nebude pro HW RAID to pravé ořechové.

K dnešnímu dni SW řešení významným způsobem ve všech ohledech překonaly veškeré nevýhody HW RAID, ale i tak se stále ve společnostech HW RAID nachází. Důvody proč jsou různé. Často jsou to administrátoři, kteří se kdysi před několika lety ve škole učili o HW RAID a považují za standard jej mít. Mnohem více však je to v důsledku nákupu nějakého serveru, který v sobě má RAID a moc se neřeší, jaký, protože samotná faktura s výslednou cenou je zkrátka důležitější než produkt, na kterém má být celá společnost závislá. Proto se pojďme podívat, jak se k problematice růstu kapacit postavil svět softwarových řešení.

ZFS

ZFS, čili Zettabyte File System je souborový systém. Řečeno jednou větou:

Souborový systém, který se umí sám opravovat, umí snapshoty, je zaměřen na práci s velkými objemy dat, a proto podporuje kapacity do výše zettabajtů.

ZFS z pohledu administrátorů umožňuje takřka v běžné praxi nedosažitelné kapacity. Volně ukradeno z wikipedie:

Some theoretical limits in ZFS are:

• 16 exbibytes (264 bytes): maximum size of a single file
• 248: number of entries in any individual directory[45]
• 16 exbibytes: maximum size of any attribute
• 256: number of attributes of a file (actually constrained to 248 for the number of files in a directory)
• 256 quadrillion zebibytes (2128 bytes): maximum size of any zpool
• 264: number of devices in any zpool
• 264: number of file systems in a zpool
• 264: number of zpools in a system

Z pohledu administrátorů je management ZFS velmi snadný. ZFS navíc umožňuje práci s částmi, které dokáží zvýšit efektivitu práce (máme možnosti jako je SLOG, L2ARC, SPECIAL). ZFS též umožňuje analogii redundance disků, jen v trochu jiné formě názvosloví, než jak je tomu ve světě RAID zvykem.

Mezi obecné nevýhody ZFS patří:

• Nižší rychlost, která je vyvážena možností použití cache devices a benefitem pole je zajištěním lepší integrity dat.
• Potřebou mít stejné kapacity disků v poli (v ideálním případě), mohou být větší, nesmí být menší.
• RAM. Pokud se ptáte kolik RAM je potřeba na ZFS, odpověď je: VŠECHNA RAM.
• Pool lze navyšovat snadno, smršťování poolu je vždy problém.

Krásné srovnání HW RAID, SW RAID a ZFS je dostupné pod tímto odkazem.

CEPH

Když zkusím ještě lépe připodobnit co je to CEPH, tak to ukáži na analogii. Představte si RAID6 pole. Je odolné vůči výpadku dvou disků. A nyní si představte něco jako RAID6 mezi servery. Prostě padnou dva servery a celá infrastruktura funguje.

CEPH je software definovaný storage. Veškerá abstrakce běží na softwarové úrovni a komunikuje s hardwarem, který může být levný, komoditní a variabilní. Tato technologie má své zaměření na výstavbu vysokokapacitních polí a to s limitou, která je v podstatě neomezená.

Síla CEPH tkví v několika bodech, třeba:

• v univerzálnosti (můžeme ho nasadit na libovolný hardware)
• vysoké redundanci (odolnost proti výpadku n serverů)
• selfmanagementu (CEPH se sám řídí)
• sebeopravě (CEPH se sám opravuje)
• distributovatelností dat (data se distribuuji pseudonáhodně po všech strojích v CEPH – pomocí CRUSH mapy)
• mohutné rychlosti (s trochou aproximace se dá říct, že s počtem serverů roste i rychlost celého CEPH lineárně)

Ale na CEPH nelze psát jen chvalozpěvy. Často se setkáváme s tím, že ve společnosti si přejí mít CEPH, ale neví jak jej administrovat. Administrace může být snadná, ale může být také těžká. Za normálních okolností CEPH na Proxmoxu „prostě běží“ a je to pole jako každé jiné, ale v případě různých atypických situací, které většinou vychází z absence znalosti této technologie, se může výhoda snadno otočit v nevýhodu. Ukážeme si jeden příklad v malém rozměru, který demonstruje, jak je CEPH odlišný od běžných RAIDů.

Příklad:

Mám 4 servery a každý server má 4 sloty na disky o velikosti 2,5. Každý server má 2 dedikované disky na kterých běží Proxmox. Do každého serveru umístím 1TB SSD. Budu mít tak celkem 16 TB SSD na 4 servrech.

Otázky:

1. Jaká bude výsledná kapacita CEPH storage?
2. A jaká bude efektivní pracovní kapacita CEPH storage?
3. A jaká bude minimální použitelná kapacita CEPH storage?

Výše uvedený zdánlivý příklad přesně ukazuje, jak je důležité si s daným poolem rozumět. Proto mezi obecnou nevýhodu CEPH patří jeho komplexita a vyšší nároky na odbornost. Do celé této problematiky se dostává náročněji. Posuďte sami z tohoto videa:

https://youtu.be/7I9uxoEhUdY

Nejčastější chyby

Konečně se dostáváme k nečastějším chybám, které se v praxi u výše uvedených řešení nacházejí. Výčet není konečný, ale jedná se o TOP chyby, které se opakují stále dokola, a proto vznikl i tento článek s prosbou, aby se dané jevy minimalizovaly.

Chyba 1: HW RAID nad ZFS

Mám-li storage na HW RAID, nemá smysl nad tímto polem stavět ZFS. Bude to fungovat, ale je to špatně. Jedná se o nejčastější chybu vůbec. Ptáme-li se proč, je to zkrátka proto, že HW RAID může nalhávat některé instrukce nebo informace o poli. ZFS je zvyklé mít jako podklad čistý disk, se kterým umí sám pracovat, sám si posílá potřebné informace o jeho stavu, životnosti a především při práci s checksumy. Může se lehce stát, že na ZFS, který má pod sebou RAID ZFS začne počítat checksum, RAID mu nalže chybnou informaci, ZFS identifikuje, že nějaký blok je vadný i přesto, že není vadný a problém je na světě. Na internetu najdete odvážlivce, co pod RAID dali ZFS a ono jim to funguje a ano, opravdu to bude fungovat do prvního problému.

Hardware RAID controllers should not be used with ZFS. While ZFS will likely be more reliable than other filesystems on Hardware RAID, it will not be as reliable as it would be on its own

Zde jsou některé další materiály z internetu o dané problematice, často odpovídající na to proč HW RAID nepoužívat na ZFS:

• serverfault
• Proxmox forum
• Polemika ZFS na HW RAID
• Oficiální dokumentace

Chyba 2: HW RAID nad CEPH

HW RAID nad CEPH není doporučován. Lze to ovšem provést, pokud daná RAID karta umí IT mod, ale i tak to není dobře. Zde je úryvek z dokumentace

Disk controllers (HBAs) can have a significant impact on write throughput. Carefully consider your selection of HBAs to ensure that they do not create a performance bottleneck. Notably, RAID-mode (IR) HBAs may exhibit higher latency than simpler “JBOD” (IT) mode HBAs. The RAID SoC, write cache, and battery backup can substantially increase hardware and maintenance costs. Some RAID HBAs can be configured with an IT-mode “personality”.

Pokud je navíc použit HW RAID pole nad CEPH, jedná se o redundanci nad redundancí.

Yes, a RAID controller takes care of redundancy with a handful of disks in one chassis. But that’s cost and complexity when you run already redundant, multi node distributed storage solutions like Ceph. Why bother mirroring a physical disk when Ceph already has multiple copies of it?

Nedává to architektonicky smysl, ale občas se to vyskytuje. Výskyt není ani tak v důsledku neznalosti, ale proto, že se CEPh staví na špatném hardwaru, což je další bod, na který se hned vrhneme.

Chyba 3: Špatně zvolený hardware, na který se nasazuje ZFS/CEPH

Mezi zásadní problém v infrastrukturách patří použití nevhodného hardwaru na CEPH či ZFS. V případě řešení postaveném na CEPH jej lze provozovat na komoditním hardwaru a sám CEPH se takto prezentuje:

A Ceph Node leverages commodity hardware and intelligent daemons, and a Ceph Storage Cluster accommodates large numbers of nodes, which communicate with each other to replicate and redistribute data dynamically.

A právě tuto pasáž s komoditním hardwarem si různí lidé vysvětlují různé. Třeba tak, že na CEPH mohu nasadit cokoliv, co najdu ve skladě či na zemi a očekávají, že to bude fungovat. A zde nám vzniká další z nejčastější problémů ve volbě hardwaru. Na skladě máme nějaký starý HP server, tak ho dáme do clusteru. A o pár měsíců později se hledá někdo, kdo umí CEPH a pomohl by s opravou CEPH clusteru, který nefunguje a nikdo neví proč. Jsou určité minimální požadavky pro CEPH a poté požadavky doporučené. V případě CEPH je potřeba vždy volit doporučené požadavky pro produkci. Minimální požadavky jsou vhodné pro laboratorní podmínky a ke studiu. Z naší praxe doporučujeme následující doporučené minimum k dodržení pro stavbu CEPH clusteru:

1. 2x10G síťovky a poté alespoň 4x1G porty.
2. Všechnu RAM, co jde. Čím víc server unese, tím lépe.
3. 16 a více jader, hyperthreading je vítán.
4. Žádný HW RAID
5. NVMe disky (v případě low-cost řešení SSD disky)
6. 4 node v jednom clusteru.
7. Záložní řešení – Třeba PBS

Pokud výše uvedené není dodrženo, je CEPH náročnější na výstavbu a přirozeným důsledkem budou možné komplikace při jeho provozu.

Chyba 4: Nepochopení dokumentace CEPH

Mezi další takové časté problematické body patří nepochopení dokumentace. CEPH funguje tak, že čím více je serverů v clusteru, tím víc Adidas. Jeho rychlost pole roste s trochou nadsázky lineárně, zvyšuje se redundance. V dokumentaci je uvedeno, že doporučené minimální množství serverů jsou čtyři, minimální funkční jsou tři servery. Takřka vždy ve firmách zkonvergují k tomu, že tři servery stačí, protože cena je cena. Ztrácí se tím drobné benefity CEPH i přesto, že 3 node cluster také funguje. Také je to důsledek dřívějších dob, kdy minimum node v clusteru bylo vždy číslo tři.

Tímto jsme si prošli top chyby a pojďme se podívat na jednu zajímavost přidruženou k storage engineeringu v Proxmoxu, která se často řeší při tvorbě architektury.

Typy storage v Proxmox a jejich možnosti

Podívejme se na tuto přejatou tabulku:

Description	PVE type	Level	Shared	Snapshots	Stable
ZFS (local)	zfspool	file	no	yes	yes
Directory	dir	file	no	no1	yes
BTRFS	btrfs	file	no	yes	technology preview
NFS	nfs	file	yes	no1	yes
CIFS	cifs	file	yes	no1	yes
Proxmox Backup	pbs	both	yes	n/a	yes
GlusterFS	glusterfs	file	yes	no1	yes
CephFS	cephfs	file	yes	yes	yes
LVM	lvm	block	no2	no	yes
LVM-thin	lvmthin	block	no	yes	yes
iSCSI/kernel	iscsi	block	yes	no	yes
iSCSI/libiscsi	iscsidirect	block	yes	no	yes
Ceph/RBD	rbd	block	yes	yes	yes
ZFS over iSCSI	zfs	block	yes	yes	yes

1: On file based storages, snapshots are possible with the qcow2 format.

2: It is possible to use LVM on top of an iSCSI or FC-based storage. That way you get a shared LVM storage.

Projektování infrastruktury

Když projektujeme infrastrukturu na Proxmoxu a můžeme si vybírat hardware, je to výhra. Můžeme pak vybírat svobodně storage a přizpůsobit mu hardware. Často se ale ve firmách konvertí servery z nějaké struktury (VMWare/Hyper-V) na Proxmox a hledá se nejlepší forma utilizace pole.

Pro potřebu tohoto článku nezvažujeme pouze jeden node, ale cluster a proto se zaměříme na sekci shared storage. Domníváme se, že pro naše čtenáře je toto téma zajímavější.

Příklad z praxe:

Zde máme jeden konkrétní příklad z praxe se vstupy:

1. Je nežádoucí mít na HW RAID na CEPH/ZFS.
2. Je potřeba mít shared storage.
3. Jsou dostupné pouze připojení přes Fibre channel (dále FC)
4. Je potřeba snapshotingu.
5. Na serverech je HW RAID a není v módu passtrought.

Odpověď a možné řešení:

Sdílená pole, které umí snapshoty jsou:

• NFS
• CIFS
• GlusterFS
• CephFS
• LVM (za podmínky užití FC)
• iSCSI varianty
• RBD

Tím, že je připojení pomocí FC, odpadají tyto možnosti:

• NFS
• CIFS
• iSCSI

(Samozřejmě když by námi modelové SAN pole umělo NFS/CIFS/iSCSI, máme vyhráno, ale v modelovém příkladu to neumí.)

Tím, že je pole na HW řadiči, odpadá možnost CEPH i ZFS. V tomto případě je kvalita lepší než kvantita.

Dostáváme se ke dvěma možnostem polí, se kterými můžeme pracovat:

• LVM
• GlusterFS

LVM můžeme nasadit, ale neumí snapshoty. GlusterFS má možnost snapshotingu, resp. za určitého dodržení podmínek:

On file based storages, snapshots are possible with the qcow2 format.

Takže správné řešení, jak lze zákazníkovi vyhovět, je použít GlusterFS.