Tyhle věci dnes už stavím jen nad ceph, teda pokud nejsou peníze (a potřeba) na nějaký enterprise level storage. Ač ceph vyžaduje nějaké znalosti v počátku, poskytuje spousty výhod, dobře se škáluje a řeší data placement, poskytuje checksum a pousty vychytávek. Kontrolky disků lze u velké části serverů ovládat z venku, takže když se SW detekuje špatný disk, můžeš ho rozvítit, což je tak nebo tak lepší než když ti technik vytáhne špatný disk. Důvodů proč se mění disk je v praxi daleko více, než které detekují řadiče.
K tomu jestli raid1 (mirroring) stačí, tak zpravidla to je dobré tak na domácí hraní, při výpadku primárního disku je ten druhý poměrně dlouho plně zatížen replikací a podstatně spadne jeho provoz, zejména pokud se bavíme o plotnách. Raid1 je tak akorát dobrý na to, abych mohl za provozu vyměnit OS disk a ne, abych to měl jako jediné uložiště pro data.
Ono se to blbě navrhuje, když ty výpadky jsou tak nějak hodně vyjímečné a pokaždé lehce jiné. Teď nám třeba díky malému požáru v jednom DC se spustil požární systém v sále, ten vysál kyslík, udělal se tam podtlak a 1/3 plotnových dísků bez helia odešla, spousta serverů s 15k OS enterprise disky v raid1 přišla o oba, zlatá datová helia, která přežila všechna. Jindy nám zase náhlý výpadek napájení v celém sále odrovna ssd/nvme disky (poškozený fs, hlavičky), odpadly jak hrušky.
Ceph umožňuje dynamicky řídit repliky a reagovat na situaci na síti. Dá se začít pár malými servery a postupně přidávat silnější jak budou peníze a to celé je možné průběžně správně balancovat, tak aby se ideálně saturovaly disky/síť. Dají se z toho vytáhnout veškerá provozní data a udělat velice podrobný reporting, svázat konkrétní datasety s jejich disky a reportobat to vertiálně (běžně získám z řadiče data z SNMP, ale už je nejsem schopný svázat s konkrétní operací a daty, které jsou na daném disku).
33 Odpovědí
6047 Zhlédnutí