Takže chcete postavit cluster Ceph?

Jsem velkým fanouškem Ceph, open-source, masivně škálovatelného softwarově definovaného úložiště. Jeho schopnost samoobnovy a zvládání jinak traumatických událostí v clusteru (aha, přišli jste o uzel? žádný problém!) v kombinaci s absencí jednotlivých bodů selhání z něj dělá můj oblíbený produkt.

Níže jsou uvedeny tři jednoduché zásady, které mohou pomoci při návrhu velkých nebo malých clusterů.

Foto: imgix on Unsplash

Pokud se zaměřujete hlavně na dolary za megabajt úložiště, pak přirozeně můžete tíhnout k serverům, které pojmou co největší počet disků a co největší disky, které můžete získat.

Tady buďte opatrní. U „úzkých a hlubokých“ clusterů existuje několik úvah:

  1. Každý uzel obsahuje větší procento dat vašeho clusteru. Příklad: V clusteru se třemi uzly obsahuje každý uzel 33 % vašich dat. V clusteru s deseti uzly je to pouze 10 % na uzel. Ztráta jediného uzlu v malém clusteru bude mít za následek podstatně větší migraci dat, zejména když se cluster začne plnit, a potenciálně i výpadek, pokud jste správně nenakonfigurovali poměry plného a téměř plného clusteru.
  2. Vynucení většího síťového provozu v menším počtu uzlů. Ceph je síťový úložný systém, takže s menším počtem uzlů nutíte velké množství klientského provozu přes menší počet síťových karet. To se zhoršuje s rostoucím počtem disků na uzel, protože máte více OSD, které soutěží o omezenou šířku pásma. Ještě horší je, že během událostí obnovy váš provoz obnovy soutěží s klientskými vstupy a výstupy po síti, což dále ovlivňuje uživatelský komfort.
  3. Při vysokém počtu disků na uzel může být diskový řadič úzkým hrdlem, pokud nemá dostatečnou šířku pásma pro přenos všech disků plnou rychlostí.
  4. Zvyšuje se doba obnovy a léčení při ztrátě celého uzlu, protože je třeba replikovat a obnovit více dat.

S rostoucím počtem uzlů se výkon clusteru velmi dobře škáluje. Zde najdete srovnání 3uzlového a 5uzlového clusteru s BlueStore.

Pokud usilujete o velký cluster, odolejte pokušení nacpat všechny disky do co nejmenšího počtu uzlů.

Shrnutí:

  • Ceph se velmi dobře škáluje s rostoucím počtem uzlů.
  • Příliš malý počet uzlů v clusteru umisťuje více dat clusteru na každý uzel, čímž se prodlužuje doba I/O a obnovení.
  • Můžete začít s pouhými třemi uzly, ale pokud si můžete dovolit rozložit disky do více uzlů, je lepší to udělat.

Buďte velkorysí se sítí

Nemá smysl dávat do serveru rychlá média a pak je ochromovat síťovým připojením 1GbE. Při výrobě se zaměřte minimálně na 10GbE a ještě lépe se poohlédněte po více 10Gb rozhraních propojených protokolem LACP (Link Aggregation Control Protocol), abyste zvýšili šířku pásma. Ceph je systém úložiště založený na síti, takže jedna věc, která by clusteru neměla chybět, je šířka pásma sítě.

Vždy oddělte veřejnou síť od vnitřní sítě clusteru. Veřejná síť bude přenášet provoz klientů, zatímco interní síť bude přenášet provoz heartbeat, replikace a obnovení mezi jednotkami OSD. Pokud můžete ušetřit síťové karty, přenášejte tyto dvě sítě přes oddělená rozhraní. Jejich oddělení zlepšuje odezvu klientů během událostí obnovení a pomáhá události obnovení dokončit rychleji, protože vstupy a výstupy obnovení nesoutěží s klientskými vstupy a výstupy na stejné síťové kartě.

Pamatujte také, že vnitřní síť přenáší provoz replikace, takže každý zápis ve veřejné síti způsobí (n-1) zápisů ve vnitřní síti, kde n je počet replik. Ceph potvrdí zápis klientovi pouze tehdy, když byl zapsán do žurnálu/WAL všech replik – nechcete tedy, aby zápisy replikace byly v síti zahlceny. Pokud hojně využíváte replikační pooly, zvažte dimenzování sítě clusteru tak, aby byla n-1krát větší než veřejná síť.

Nakonec kvůli redundanci zajistěte, aby byly uzly připojeny k redundantním přepínačům v horní části racku. Nechcete přece přijít o celý uzel – nebo sadu uzlů – kvůli selhání jediného přepínače!“

Abychom to shrnuli:

  • Minimálně 10Gbit Ethernet pro produkci.
  • Oddělte veřejnou síť a síť clusteru, ideálně na různé síťové karty, ale přinejmenším do různých VLAN/podsítí.
  • Pamatujte na pravidlo (n-1) pro replikovaná data – zvažte dimenzování vnitřní sítě tak, aby byla n-1krát větší než veřejná.
  • Nezapomeňte na kabeláž pro redundanci a na správné vytvoření vazeb na úrovni operačního systému.
  • A ještě něco navíc: nezapomeňte na jumbo rámce na rozhraních!

Flash média pro metadata BlueStore.

Ceph potvrdí zápis klientovi až po zapsání dat do protokolu WAL (write-ahead log) primárního OSD a do WAL všech replik. Čím rychlejší je tedy zápis do WAL, tím rychleji Ceph potvrdí zápis a tím lepší je zápis IOPS pro klienta.

Vaše WAL a ideálně i metadata BlueStore RocksDB by měly být na nejrychlejším médiu, které můžete získat – minimálně SSD a pokud možno NVMe. Pokud budujete cluster s plnou kapacitou HDD, důrazně zvažte, zda si nepřiplatit za uzel a nepřidat alespoň dvě rychlá mediální zařízení pro metadata a WAL.

Abyste se vyhnuli úzkým místům na rychlém mediálním zařízení, zvažte trvalou rychlost zápisu vašich datových disků a porovnejte ji s trvalým zápisem vašeho rychlého zařízení. Pokud váš pevný disk zvládne trvalý zápis rychlostí 100 MB/s a váš SSD disk zvládne trvalý zápis rychlostí 500 MB/s, pak stačí více než 4-5 OSD disků na SSD disk a SSD disk vás při zápisu zahltí. NVMe je pro tento případ použití ideální, protože jejich rychlost trvalého zápisu může dosahovat až gigabajtů za sekundu.

Nakonec, vždy mějte více než jedno zařízení SSD/NVMe na uzel pro metadata/WAL, abyste zajistili, že v případě selhání zařízení pro metadata nepřijdete o všechny disky OSD v uzlu.

Shrnuto:

  • Ceph potvrdí zápis klientovi, pokud byl zapsán do WAL primárního OSD a WAL všech replik. Dělá to proto, aby byla zachována integrita dat.
  • WAL a RocksDB by měly být na nejrychlejším médiu, které můžete sehnat – ideálně NVMe – abyste získali odpověď pro klienta co nejrychleji.
  • Nepřepisujte svá rychlá zařízení pro WAL/RocksDB. Pokud to uděláte, jen přesunete úzké hrdlo na své rychlé zařízení.
  • Mějte více než jedno rychlé zařízení, abyste se vyhnuli ztrátě všech OSD v uzlu, pokud vaše zařízení WAL selže.

Shrnutí

Ceph je síťový softwarově definovaný úložný systém, který se mimořádně dobře horizontálně škáluje. Výše je uvedeno jen několik zásad, které vám pomohou sestavit vysoce výkonný systém – nezacházejte příliš úzce ani hluboko, udržujte cluster v dostatečné šířce pásma a používejte rychlá média pro metadata a WAL.

.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.