Ceph v naší infrastruktuře
Před půl rokem jsme se rozhodli podívat se na ceph jakožto storage technologii pro naší video CDN. Dnes už v něm máme uloženo téměř 2PB dat a v migraci dat dále pokračujeme.
Konfigurace serverů před cephem
V rámci naší video platformy uchováváme velké množství souborů, které taktéž generují nemalý síťový provoz.
Pro uchování souborů jsme používali ten nejjednodušší možný přístup. Každý server se choval naprosto autonomně. Z pohledu disků měl v sobě několik (3 nebo 9) RAID 5 (3+1) polí, na kterých byly jednotlivé soubory. Na serveru byl také nginx, který servíroval soubory směrem k uživatelům.
Hardwarové konfigurace serverů byly následující:
| Case | CPU | RAM | Síťová karta |
|---|---|---|---|
| 2U - 12 disků | 1x Xeon E3 | 16 GB | 10GbE |
| 4U - 36 disků | 1x Xeon E5 | 64 GB | 10GbE |
Běžné provozní problémy
Výše zmíněná infrastruktura sice fungovala, přinášela s sebou ale určité problémy.
Hardware, ačkoliv je dnes docela spolehlivý, tak přecijen stále není 100%. Pojďme se podívat na nejčastější komplikace s hardware, se kterými se setkáváme.
Dlouhodobě u supermicro serverů řešíme nestabilní napájecí zdroje. Monitoring (ipmi) sice hlásí, že oba zdroje jsou v pořádku. Občas se ale stane, že pokud jeden z nich vypadne, tak se objeví závada i na druhém. Dojde tak k výpadku celého serveru. V tomto ohledu máme paradoxně lepší zkušenosti se servery s jedním zdrojem.
Pevné disky nám také působí komplikace. Jednou za čas jeden z disků umře ošklivým způsobem a dojde k záseku celého řadiče. Tím dojde k zamrznutí všech diskových IO operací a výpadku celého serveru. V takovém případě většinou stačí server restartovat a při dalším bootu už disk v systému vůbec není vidět. V menším množství případů je nutné disk najít a ze serveru jej úplně vyjmout, protože na něj řadič stále čeká a nedokáže se přes poškozený disk dostat.
Takovým hodně vzácným případem, který se nám ale také stal, byla situace, kdy došlo k výbuchu jednoho z kondenzátorů na backplane. V tomto případě jsme museli měnit celý server za jiný kus.
Problém, který jsme již téměř vymýtili, ale přesto se ještě jednou za čas objeví, je svévolný restart serverů. Jednou za čas, obzvláště u větších storage, dojde ke kernel panicu, který vede k restartu serveru. Kdysi dávno za to mohly SAS1 supermicro backplane, ale ty už nikde nemáme. Nyní se to stává řádově jednou za půl roku.
Každý z výše zmíněných problémů vždy vedl k výpadku serveru a negativně tím ovlivnil uživatele.
A na závěr samozřejmě každá ůdržba serveru vedla k plánovaní během raních hodin, kdy je traffic nejmenší, aby se minimalizoval dopad na uživatele. Někteří však výpadek pocítili, protože na storage serverech vždy nějaký provoz byl.
Nasazení cephu
Pro testování cephu jsme se rozhodli hlavně na základě reference z CERNu, kteří jej využívají na ukládání dat ze svých měření. Ačkoliv existují alternativní opensource storage řešení, tak jsme přecijen zůstali u mainstreamu. Hlavním důvodem pro nás byl fakt, že v případě komplikací, které sami nedokážeme vyřešit, existuje velká skupina lidí, která je zkušenější a může případně pomoci.
Od začátku jsme věděli, že půjdeme cestou několika menších cephů místo jednoho velkého. Těch důvodů, které nás k tomuto vedly, bylo víc.
Architekturu jsme již měli postavenou tak, že soubory mohly být uloženy na desítkách nezávislých serverů. Přičemž soubory jsme mohli mezi servery přesouvat bez dopadu na uživatele.
Dále jsme chtěli eliminovat riziko, že výpadek jednoho velkého cephu povede k ovlivnění všech uživatelů. S více nezávislými cephy vypadek jednoho z nich znamená, že bude nedostupná jen část souborů a ovlivněna jen část uživatelů.
Konfigurace serverů pro ceph
Hardware
S hardware konfigurací jsme se snažili držet blízko tomu, co jsme používali a tím i tedy co jsme měli skladem. Dbali jsme ale na doporučení, která jsou uvedena v rámci dokumentace. Proto jsme zvolili pro začátek následující servery:
| Server | Počet kusů | Case | CPU | RAM | Síťová karta |
|---|---|---|---|---|---|
| OSD | 8 | 2U - 12 disků | 2x Xeon E5 | 64 GB | 10GbE |
| MON/MDS | vždy po 3 kusech | Virtuální server | 4 vCPU | 8 GB | 10GbE |
| Webservery | 1 až N (dle potřeby) | 1U | Xeon Silver (alespoň 10C/20T) | 128 GB | 10GbE |
Množství disků a počet serverů jsme zvolili kvůli omezené výšce racků - používáme 42U racky. Tato konfigurace zabírá v racku minimálně 17U (8x2U + 1U), což nám dává možnost umístit do jednoho racku 2 celé cephy (34U). Dále pak jeden nebo dva switche a zbyde trochu místa pro další webservery tam, kde jsou potřeba. V případě nutnosti jsme také schopni umístit další 2U OSD servery a zvětšit tím kapacitu jednotlivých cephů.
Máme připravený hardware pro další cephy, které již budou postavené na 4U serverech, kde bude v každém 36 disků. Při 8 kusech bude takový ceph zabírat 32U. V racku tak zůstane 10U volného místa na webservery, switche nebo 9. OSD server a další podpůrné servery.
Zvažovali jsme také variantu, kdy dáme každý OSD server do jiného racku nebo je budeme agregovat po 2, abychom rozložili jednotlivé OSD mezi různé páry jističů. Obzvláště při balancingu ale dojde k velkému zatížení sítě a museli bychom mít výrazně naddimenzované propoje mezi racky. V současné konfiguraci nám ze switchů proudí jen uživatelský provoz, jehož množství se lehce predikuje a vystačíme si zde s 10GbE a 40GbE uplinky. Interní traffic zůstane vždy jen v rámci jednoho racku.
Co se týče disků, tak jsme migraci využili k likvidaci 3TB disků, které se nám již nevyplatí používat. Jeden malý ceph máme postavený na 4TB discích. Jedná se o ceph, na kterém jsou sice produkční soubory, ale záměrně tam jsou soubory, které generují lehce přes 1Gbps provozu. I hardware je v tomto případě jiný - 8x 1U servery s Xeon E3 procesorem. Pro nás je to první produkční ceph, na který se jako první nasazují změny, po otestování na vývojovém cephu. Na ostatních cephech pak používáme 6TB a 8TB disky. S většími disky jsme v provozu měli problémy, takže je zatím nepoužíváme. Důležitější informací zde je, že v každém cephu používáme vždy jen jednu kapacitu disků. Ceph umí dobře pracovat s různými kapacitami. Naším důvodem je však jednodušší servisovatelnost. S jednotnou kapacitou disků víme, že do určitého cephu patří vždy jen určitá kapacita disků. Odstraňilo nám to problém s počítáním správné váhy serveru tak, aby byly všechny OSD servery vyváženy.
Software
Z pohledu softwarové konfigurace cephu jsme zvolili následující schéma. Na každém cephu je jeden pool na metadata (3x replikace) a jeden s pro data (erasure code 6+2). Webservery jsou k cephu připojené přes cephfs, díky kterému jsme v aplikaci nemuseli měnit ani jednu řádku kódu.
Postupné rozšiřování diskové kapacity
Protože jsme se chtěli vyhnout nákupu nových disků, tak jsme začali s 2TB disky, které jsme již v minulosti vyřadili kvůli jejich nízké efektivitě. Postupně jsme tak při migraci dat uvolňovali větší disky a nahrazovali jimi 2TB disky v cephu. Toto rozhodnutí teď nepovažujeme za úplně šťastné.
Výměna disků v cephu sice funguje výborně. Při výměně disků jsme nikdy nepřišli o žádná data, ani nedošlo k výpadku. Celou migraci jsme si tímto ale výrazně prodražili na lidské práci. Prodloužilo nám to také dobu migrace, protože jsme velmi často čekali než se data v cephu vybalancují, abychom tam mohli migrovat další soubory. Se současnými zkušenostmi bychom naplnili alespoń polovinu cephu novými disky a pak jednorázově doplnili druhou polovinu po uvolnění disků v existujících storage.
Problémy, které nám ceph vytvořil
V rámci provozních problémů nám zůstaly ty staré, které jsme již popisovali dříve. Snížil se jim však dopad na uživatele. V současném stavu můžeme ztratit až 2 celé servery a uživatelská data zůstanou stále dostupná. Tato konfigurace nám pomáhá i při údržbě, kdy i během špičky můžeme jeden z OSD serverů vypnout a vědět, že může spadnout ještě jeden a stále bude vše v pořádku.
Avšak, vznikly nám i nové problémy. Ten největší se týká provozních nákladů.
Elektrická energie
Ceph nám zvýšil spotřebu elektrické energie. Na tomto ale ještě zkusíme zapracovat. Místo původních 1 CPU serverů nyní používáme 2 CPU. Zkušenosti nám ale zatím ukazují, že je to zbytečné a stačí 1 CPU s větším množstvím jader. Pro 2U servery by bez problémů měl stačit 6C/12T procesor. Pro 36 diskové očekáváme, že bude stačit 12C/24T.
Paměť RAM
Potřebujeme výrazně více operační paměťi. V původních serverech jsme používali 16GB RAM. Nyní používáme jako minimum 64GB, přičemž už jsme museli u jednoho cephu zmenšit OSD cache. V dalších plánech máme upgrade na 96GB nebo na 128GB. Webové servery provozujeme se 128GB RAM, protože výkon cephfs je velmi závislý na dostupné kernel cache, kterou si systém drží v paměti.
Další služby
Vzniklo nám několik nových služeb, které jsme dříve nepotřebovali - konkrétně monitor a metadata servery. U nich se nám zatím ověřilo, že je stačí mít jen jako virtuální servery. Pokud by v budoucnu potřebovali fyzické servery, tak je dostanou. Nově máme také oddělené webové servery, který byl původně součástí storage.
Využítí místa na discích
Zásadní problém, na který jsme narazili je využítí místa na discích. V původních serverech jsme na jednotlivých polích nechávali 50GB volného místa a to jen jako buffer pro případ, kdy bychom nestihli rozšířit diskovou kapacitu. 50GB buffer na každém poli nám v součtu všech polí dával volné místo na 2-3 týdny, takže dostatek času na instalaci dalších disků. V současné situaci musíme cephu nechávat mnohem více volného místa, aby v případě výpadku disku měl kam automaticky přesouvat data. S tím souvisí také balancing dat mezi jednotlivými disky, který se nám ještě nepovedlo vyšperkovat. Aktuálně máme rozptyl zaplnění jednotlivých disků až 1,5%, kde také vznikají nemalé ztráty.
S místem také souvisí změna kapacity cephu. Když v jednom z cephů měníme disky, tak u něj preventivně vypínáme zápisy. Celkem často (hlavně při odebírání disků) se nám stává, že se výsledek hashovací funkce změní natolik, že při přesouvání jednotlivých bloků dat zaplní jeden z disků. To pak vede k omezení volného místa celého cephu - třeba až na 0 bajtů. A to i přestože je na ostatních discích dostatek volného místa. Situace se však po několika hodinách balancování uklidní.
Badblocky disků
Ve všech cephech máme zapnutý deepscrubbing, který periodicky kontroluje všechna data a případné nesrovnalosti reportuje. To se u nás velmi často stává kvůli vadným sektorům disků. Ceph je v tomto velmi striktní a tak v původní infrastruktuře velmi často došlo k automatické realokaci vadných sektorů, kdy jsme si toho většinou ani nevšimli. Ceph však tyto chyby poctivě hlásí a tak je potřeba ručně spouštět příkazy na opravu placement group. Bohužel je zde zásadní rozdíl mezi tím, co si ceph myslí, že je špatný disk a co si výrobce myslí, že je vadný disk. Občas tedy musíme nějaký disk vyjmout, prohnat jím badblocks, aby se realokovaly vadné sektory a vrátit jej zpět, protože disk ještě není dostatečně poškozený, aby byl přijat k reklamaci.
Výkon
Zatím jsme ve 2U cephu narazili na výkonostní limit 15Gbps (máme většinu trafficu čtení), přes který se zatím nedokážeme dostat. Z pohledu jednotlivých hardwarových komponent se zdá, že celý ceph má ještě výrazné rezervy. Očekáváme, že zde budeme muset udělat úpravu konfigurace softwarové části cephu. Avšak, tento limit nám zatím tolik nevadí, protože jsme schopni rozložit soubory mezi jednotlivé cephy tak, abychom se drželi pod tímto limitem. Zajímavý je zde fakt, že tento limit je stejný i v situaci, kdy je ceph degradovaný a běží na něm rebalancing dat. Oproti tomu v původní konfiguraci 8x 2U serverů jsme byli schopni vytlačit až 80Gbps.
S výkonem úzce souvisí i mazání dat z cephu. Mazání dat velmi zatěžuje pevné disky a v důsledku toho vzroste i io load na cpu. Pokaždé, když promazáváme větší množství dat (desítky TB), tak to musíme dělat postupně, abychom ceph nepřetížili.
Slabá dokumentace
Narazili jsme již na situaci, kdy se nám ceph povedlo dostat do desynchronizovaného stavu, ze kterého se nemohl dostat. Nakonec jsme řešení našli a pomocí několika "developers only" příkazů, které ceph uvedly do funkčního stavu. Tyto příkazy však nebyly pořádně popsané a museli jsme se dívat do zdrojových kódů, abychom si byli jisti, že tím situaci ještě nezhoršíme.
Musíme se zde cephu ale zastat, protože po celou dobu byl plně použitelný. Jen některá data byla degradovaná v konfiguraci 6+1 místo 6+2.
Závěr
Ceph sice není ideální, dokonce je schopný nám připravit i nepříjemná překvapení a těžké chvilky. A už vůbec není levný na provoz. Pomohl nám ale obejít a vstřebat většinu našich problémů s hardware a jeho nasazením se nám poradřilo bez složitého vývoje téměř zbavit všech výpadků, které nás trápily. Nyní můžeme provádět údržbu serverů i během špičky bez jakéhokoliv dopadu na uživatele.
V rámci testovacích scénářů se nám ceph povedlo dostat do úzkých. Ale testy, které jsme s ním dělali, byly mimo jeho limity. Navíc se nám jej povedlo vždy obnovit do funkčního stavu. Pominuli výkonostní limit, tak se nám ceph na produkci ještě nedostal do stavu, že by se z něj nedala číst data. Se zápisy je to už ale horší, protože při rebalancingu dat v něm občas dojde místo.
A jak vypadá jeden takový ceph si můžete prohlédnout na fotografii níže.
