V této kapitole se budeme zabývat následujícími tématy:
Přehled výkonnosti Ceph
Obecná analýza výkonu Ceph - úroveň hardwaru
Ladění výkonu Ceph - úroveň softwarové nástroje
Kódování odstranění Ceph
Vytvoření mezipaměti Ceph
Benchmarking Ceph s benchmarkem RADOS
Data a informace vždy udržují trend změn a růstu. Každá organizace, bez ohledu na to, jak je malá nebo velká, čelí v průběhu času problémům s růstem dat a většinou tyto problémy s růstem dat přinášejí také problémy s výkonem. V současném věku světa, který generuje obrovské množství dat, jsou organizace nuceny hledat řešení úložiště, která jsou vysoce škálovatelná, distribuovaná, extrémně spolehlivá a navíc mají dobrý výkon pro všechny jejich potřeby pracovní zátěže.
Jednou z největších výhod Ceph je to, že má škálovatelnou distribuovanou architekturu. Díky své distribuované povaze jsou všechny příchozí zátěže distribuovány a přiřazeny celému clusteru pro ukládání, což z Ceph činí systém úložiště s dobrým výkonem. Datové soubory v tradičních úložných systémech si můžete představit jako velmi omezenou škálovatelnost, s malou nebo žádnou distribucí a pouze s omezeným počtem úložných uzlů a disků. V tomto druhu tradičního nastavení mohou nastat problémy s výkonem, protože objemy dat rostou a požadavky uživatelů rostou.
V současné době, kdy aplikace obsluhují obrovské množství klientů, vyžadují ve svém jádru úložné systémy s lepším výkonem. Typická instalace Ceph obsahuje mnoho uzlů, přičemž každý uzel obsahuje několik OSD (zařízení pro ukládání objektů). Protože je Ceph distribuován, když data dorazí do úložiště, jsou distribuována mezi více uzlů a jejich OSD, čímž se shromažďuje výkon více uzlů. Kromě toho jsou tradiční systémy omezeny na určité metriky výkonu, když k nim přidáte další kapacitu, tzn. s rostoucí kapacitou nezískáte extra výkon. V některých případech výkon klesá s rostoucí kapacitou. V Cephu nikdy neuvidíte snížení výkonu, když se kapacita zvýší ( Poznámka k .: poněkud přímočaré tvrzení (ve vztahu k nikdy): ve skutečnosti existují omezení spojená se systémem propojení a vnitřních sběrnic uzlů, a to: celková šířka pásma kanálů, jejich latence a konkurence pro samotné komunikační kanály. Ve skutečnosti však lze tyto problémy vyřešit také škálováním). S rostoucí kapacitou úložného systému Ceph, tzn. když přidáte nové uzly naplněné OSD, výkon celého clusteru se lineárně zvýší, protože získáme více pracovních koní OSD a také přidáme procesory, RAM a síťové zdroje spolu s novými uzly. To dělá Ceph jedinečným a odlišuje jej od ostatních úložných systémů.
Pokud jde o výkon, důležitou roli hraje hardware, který používáte. Tradiční úložné systémy fungují velmi specifickým způsobem na svém vlastním značkovém hardwaru, přičemž uživatelé nemají žádnou flexibilitu při výběru základního hardwaru na základě svých potřeb a jedinečných požadavků na pracovní zátěž. Pro organizace, které investují do takových systémů uzamčených dodavatelem, je velmi obtížné překonat problémy, které zařízení vytváří, pokud náhle přestane splňovat výzvy, kterým čelí.
Na druhou stranu je Ceph zcela nezávislý na výrobci hardwaru; organizace již nejsou vázány na výrobce hardwaru a mohou volně používat jakýkoli hardware, který si vyberou, stejně jako požadavky na rozpočet a výkon. Mají plnou kontrolu nad svým vybavením a základní infrastrukturou.
Další výhodou Cephu je, že podporuje heterogenní hardware, tzn. Ceph může běžet na clusteru s hardwarem od mnoha dodavatelů. Uživatelé mohou při budování infrastruktury Ceph kombinovat značky. Například při nákupu hardwaru pro Ceph mohou uživatelé kombinovat hardware z různých výrobců, jako jsou HP, Dell, IBM, Fujitsu, Super Micro a dokonce i ne zcela standardní výbava. Zákazníci tak mohou dosáhnout obrovských úspor Peníze, získat potřebné vybavení, plnou kontrolu a rozhodovací práva. ( Poznámka k .: neslevujte z problémů Údržba a údržba systému; v rozsáhlém systému je porucha zařízení a kontakty s výrobcem na problémy s jeho výměnou běžnou situací; měli byste předem odhadnout rozdíl ve vašem čase a penězích vynaložených na kontakty s jedním dodavatelem/výrobcem a mnoha z nich}.
Výběr hardwaru hraje důležitou roli v celkovém výkonu úložného systému Ceph. Vzhledem k tomu, že si zákazníci mohou zvolit typ hardwaru pro Ceph, musí to být provedeno s maximální pečlivostí a odpovídajícím posouzením současného a budoucího zatížení.
Mějte však na paměti, že výběr hardwaru zcela závisí na pracovní zátěži, kterou hodláte na svém clusteru hostovat, prostředí a všech funkcích, které budete používat. V této části některé prozkoumáme hlavní pravidla při výběru hardwaru pro váš cluster Ceph. ( Poznámka trans.: Dodatečné informace Hardwarová doporučení můžete získat na stránce http://www.mdl.ru/Solutions/Put.htm?Nme=CephHW , což je autorův překlad Hardwarových doporučení z oficiálního webu Ceph Documentation.}
Některé komponenty Ceph nejsou náročné na procesory. Například démoni monitoru Ceph jsou lehkí, protože udržují kopie clusteru a neudržují klientská data. Ve většině případů tedy tuto práci zvládne procesor s jedním jádrem. Můžete také zvážit spuštění démona monitoru na jakémkoli jiném serveru v prostředí, které má volné prostředky. Ujistěte se, že máte tyto systémové prostředky protože RAM, síť a místo na disku jsou dostatečné pro démony monitoru.
Démony Ceph OSD mohou být náročné na CPU, protože obsluhují klientská data, a proto vyžadují určité zpracování dat. Pro OSD nody postačí dvoujádrový procesor. Z hlediska výkonu je důležité pochopit, jak budete OSD používat: v režimu replikace nebo odstranění kódu. Pokud používáte OSD v režimu dekódování, měli byste zvážit použití čtyřjádrového procesoru pro výpočetně náročné operace dekódování. V případě obnovy dat clusteru se výrazně zvýší spotřeba CPU démonů OSD.
Démoni MDS (Metadata Server) jsou ještě náročnější na CPU než MON a OSD. musí svou pracovní zátěž dynamicky přerozdělovat, což hodně klade centrální procesorové jednotky; měli byste zvážit použití čtyřjádrových procesorů pro Ceph MDS.
Démoni monitoru a metadat musí svá data obsluhovat rychle, takže k tomu musí mít dostatek paměti rychlá práce. Z hlediska výkonu stačí 2 GB nebo více na instanci démona pro metadata a monitor. OSD jsou zpravidla nenáročná na RAM. Pro zátěž střední úrovně by měl stačit 1 GB RAM na instanci démona OSD; z hlediska výkonu by však byly 2 GB na démona OSD lepší volbou. Pokyny předpokládají, že používáte jednoho OSD démona na fyzický disk.Pokud pro OSD používáte více než jeden fyzický disk, měly by se zvýšit i vaše požadavky na RAM. Obvykle je více RAM dobrá volba, protože spotřeba paměti se během operací obnovy výrazně zvyšuje.
Všechny uzly clusteru musí mít duální síťová rozhraní pro dvě různé sítě, konkrétně síť clusteru a síť klienta. Pro středně velký cluster s několika stovkami terabajtů by mělo stačit připojení k síti 1G. Pokud je však váš cluster velký a obsluhuje mnoho klientů, měli byste zvážit použití sítě s šířkou pásma 10G nebo více. Při obnově hraje důležitou roli síť. Pokud máte dobrý internetové připojení 10G nebo více, váš cluster se obnoví rychleji, jinak to může nějakou dobu trvat. Z hlediska výkonu by tedy byla dobrou volbou redundantní síť 10G nebo více. Dobře navržený cluster používá dvě fyzicky oddělené sítě, jednu pro síť clusteru (interní síť) a jednu pro klientskou síť (externí síť); obě tyto sítě musí být fyzicky odděleny na síťovém přepínači; konfigurace přístupového bodu vyžaduje redundantní duální síť, jak je znázorněno na obrázku níže:
Výběr diskového zařízení pro cluster úložiště Ceph má velký rozdíl v celkovém výkonu a celkových nákladech clusteru. Než učiníte konečné rozhodnutí o pohonu, musíte porozumět celkovému pracovnímu zatížení a potenciálním požadavkům na výkon. Ceph OSD (Object Storage Device) se skládá ze dvou různých částí: OSD log a OSD datové části. Každá operace zápisu je dvoukrokový proces.
Když OSD obdrží požadavky od klienta na uložení objektu, nejprve zapíše objekt do části protokolu a poté z protokolu zapíše stejný objekt do datové části a poté odešle klientovi potvrzení o potvrzení. Celý výkon clusteru se tedy točí kolem protokolu OSD a datového oddílu. U žurnálů se z hlediska výkonu doporučuje použití SSD. S SSD můžete dosáhnout výrazného zlepšení propustnosti snížením doby zápisu a latence čtení. Ve většině prostředí nejste zmateni extrémním výkonem. můžete se rozhodnout nastavit log a datový oddíl na stejném disku. Pokud však hledáte výrazné zlepšení výkonu pro váš cluster Ceph, vyplatí se investovat do SSD pro žurnálování.
Chcete-li použít SSD jako žurnál, vytvoříme logické oddíly na každém fyzickém SSD, které se budou používat pro žurnálování, tak, aby každý oddíl žurnálu odpovídal jednomu datovému oddílu OSD. Při tomto typu nastavení musíte mít na paměti limity SSD, abyste je nepřekročili přetížením spousty logů. Tím ovlivníte celkový výkon. Získat dobrý výkon z vašich SSD, neměli byste ukládat více než čtyři OSD na SSD.
Stinnou stránkou použití jednoho SSD pro více protokolů je, že ztráta vašeho SSD podporujícího více protokolů způsobí selhání všech OSD spojených s tímto SSD a vy můžete přijít o svá data. Tuto situaci však můžete překonat použitím RAID 1 pro protokoly, což však zvýší náklady na úložiště. Navíc cena jednoho SSD je asi 10x vyšší než cena HDD. Pokud tedy postavíte cluster s SSD, zvýší se tím náklady na gigabajt vašeho clusteru Ceph.
Výběr souborový systém je také jedním z aspektů výkonu klastru. Btrfs je modernější souborový systém schopný zapsat objekt v jediné operaci ve srovnání s XFS a EXT4, které vyžadují dvě fáze k zápisu objektu. Btrfs je souborový systém copy-on-write, tzn. když zapisuje objekt do žurnálu, může současně zapisovat stejný objekt do datové oblasti, což poskytuje významné zvýšení výkonu ( Poznámka. trans.: při změně nových dat se tato data nejprve zkopírují do nové oblasti ). Nicméně v době psaní tento manuál Btrfs nebyl připraven k produkčnímu použití. U Btrfs můžete narazit na problémy s nekonzistencí dat.
Výkon jakéhokoli systému se měří zátěží a testováním výkonu. Výsledky těchto testů nám pomohou rozhodnout, zda aktuální instalace vyžaduje přizpůsobení nebo ne. Ladění výkonu je proces nápravy úzkých míst výkonu zjištěných výkonnostními testy. Ladění výkonu je velmi široké téma, které vyžaduje hluboké studium všech komponent bez výjimky, bez ohledu na to, zda jsou pro Ceph interní nebo externí.
Doporučený přístup pro jemné doladění clusteru Ceph je začít s průzkumem od jedné strany nejmenších prvků až po úroveň koncových uživatelů, kteří využívají data služby úložiště. V této části probereme některé možnosti ladění výkonu z pohledu clusteru Ceph. Tato nastavení nadefinujeme v konfiguračním souboru clusteru Ceph, takže při každém spuštění démona Ceph musí tato nastavení dodržet. Nejprve se podíváme na ladící soubory Ceph a jejich různé sekce a poté se zaměříme na nastavení ladění výkonu.
Většina nastavení konfigurace pro celý cluster je definována v konfiguračním souboru clusteru Ceph. Pokud jste nezměnili název klastru a umístění konfiguračního souboru klastru, pak je výchozí název ceph.conf a cesta je /etc/ceph/ceph.conf . Tento konfigurační soubor má obecnou část a také několik částí pro každý typ služby. Kdykoli je spuštěn každý typ služby Ceph, tzn. MON (monitory), OSD (objektová úložiště) a MDS (metadatové servery), čtou nastavení definovaná v obecné části i v jejich specifické části.
Obecná sekce je sekce definovaná pomocí ; všechna nastavení v této sekci ovlivňují všechny démony v clusteru Ceph. Toto definuje všechna nastavení, která by měla být aplikována na celý cluster. Níže je uveden příklad nastavení v této části:
Veřejná síť = 192.168.0.0/24
Nastavení uvedená v této části platí pro všechny démony ceph-mon v daném clusteru Ceph. Nastavení definovaná v této části přepíše nastavení definovaná v této části. Níže je uveden příklad nastavení v této části:
Počáteční členové Mon = ceph-mon1
Nastavení specifikovaná v této části platí pro všechny démony ceph-osd v daném clusteru Ceph. Nastavení definovaná v této části přepíše nastavení definovaná v této části. Níže je uveden příklad nastavení v této části:
Typ Osd mkfs=xfs
Nastavení specifikovaná v této části platí pro všechny démony ceph-mds v daném clusteru Ceph. Nastavení definovaná v této části přepíše nastavení definovaná v této části. Níže je uveden příklad nastavení v této části:
Velikost mezipaměti Mds = 250 000
Nastavení uvedená v této části platí pro všechny klienty Ceph. Nastavení definovaná v této části přepíše nastavení definovaná v této části. Níže je uveden příklad nastavení v této části:
rdcache=true
Jak již bylo zmíněno, ladění výkonu je velmi specifické pro prostředí. Prostředí vaší organizace a hardwarová infrastruktura pro cluster Ceph se velmi liší od jiných organizací. Věci, které nakonfigurujete ve svém clusteru, mohou nebo nemusí fungovat stejným způsobem v jiných prostředích. V této části probereme některé obecné možnosti ladění výkonu, které můžete konkrétněji vyladit pro vaše prostředí.
Důrazně se doporučuje, abyste pro svůj cluster Ceph používali dvě fyzicky oddělené sítě. Každá z těchto sítí má svůj vlastní účel. V souladu s terminologií přijatou v Ceph se tyto sítě nazývají veřejná (veřejná) síť a klastrová síť (klastr):
Veřejná síť je také označována jako síť na straně klienta, která klientům umožňuje komunikovat s clustery Ceph a přistupovat ke clusteru pro svá data tam uložená. Tato síť je vyhrazena pouze pro klienty, a proto v této síti neprobíhají žádné interní klastrové interakce. Pro konfiguraci clusteru Ceph byste měli definovat veřejnou síť následovně:
Veřejná síť = (veřejná síť / maska sítě)
Veřejná síť = 192.168.100.0/24
Clusterová síť se také nazývá interní síť, což je vyhrazená síť pro všechny interní operace klastru mezi uzly Ceph. Z hlediska výkonu by tato síť měla mít slušný výkon 10Gb nebo 40Gb, protože tato síť je zodpovědná za operace clusteru s velkou šířkou pásma, jako je replikace dat, obnova, vyvažování a kontrola srdečního tepu. Clusterovou síť můžete definovat takto:
Síť clusteru = (síť clusteru / maska sítě)
Příklad takové definice je uveden níže:
síť clusteru=192.168.1.0/24
Pokud je toto nastavení na místě a cluster Ceph běží, nastavuje maximální počet definic otevřených souborů na úrovni operační systém. To pomáhá démonu OSD (object storage device) nevyčerpat limity deskriptorů souborů. Výchozí hodnota je 0 ; můžete jej nastavit na libovolné 64bitové celé číslo.
Podívejme se na příklad:
Maximální počet otevřených souborů = 131072
Možnosti uvedené v této části musí být definovány v sekci nastavení vašeho clusteru Ceph.
Maximální počet operací fronty úložiště souborů: Toto je maximální počet operací, které může systém souborů přijmout, než zablokuje nové operace, které mají být přidány do fronty. Podívejme se na následující příklad:
Maximální počet operací fronty úložiště souborů = 25 000
Maximální počet bajtů fronty úložiště souborů: Toto je maximální počet bajtů operací. Níže je uveden příklad:
Maximální počet bajtů fronty úložiště souborů = 10485760
Fronta úložiště souborů provádějící maximální počet operací: Toto je maximální počet operací, které může souborový systém provést. Příkladem je následující:
Fronta úložiště souborů provádějící maximální počet operací = 5000
Fronta úložiště souborů odevzdává max. bajtů: Toto je maximální počet bajtů, které může souborový systém potvrdit. Podívejte se na následující příklad:
Fronta úložiště souborů pro potvrzení max. bajtů = 10485760000
Operační vlákna úložiště souborů: Toto je počet vláken operací souborového systému, která mohou běžet souběžně. Níže je uveden příklad:
Operační vlákna úložiště souborů = 32
Maximální počet bajtů zápisu do žurnálu: Toto je maximální počet bajtů, které může žurnál zapsat najednou. Následuje příklad:
Maximální počet bajtů zápisu do deníku = 1073714824
Maximální počet zápisů do deníku: Toto je maximální hodnota položek, které může deník najednou zapisovat. Zde je příklad:
Maximální počet zápisů do deníku = 10 000
Max ops fronty žurnálu: Toto je maximální hodnota operací povolených ve frontě žurnálu v daném časovém okamžiku. Jeho příklad je:
Maximální počet operací ve frontě deníku = 50 000
Max bajtů fronty žurnálu: Toto je maximální počet bajtů povolený frontou žurnálu v daném časovém okamžiku. Podívejte se na následující příklad:
Maximální počet bajtů fronty žurnálu = 10485760000
Maximální velikost zápisu Osd: Toto je maximální velikost v megabajtech, kterou může OSD najednou zapisovat. Níže je uveden příklad:
Maximální velikost zápisu Osd = 512
Omezení velikosti zprávy klienta Osd: Toto je maximální velikost dat klienta v megabajtech, která je povolena v paměti RAM. Příkladem je toto:
Omezení velikosti zprávy klienta Osd = 2048
Osd deep scrub krok: Toto je velikost v bajtech přečtená OSD při provádění hlubokého čištění. Podívejte se na následující příklad:
Osd krok hlubokého drhnutí = 131072
Osd op vlákna: Toto je počet operačních vláken používaných démonem Ceph OSD. Například:
Osd op vlákna = 16
Disková vlákna Osd: Toto je počet diskových vláken pro provádění intenzivních operací OSD, jako je obnova a čištění. Níže je uveden příklad:
osd disková vlákna = 4
Velikost mezipaměti mapy Osd: Toto je velikost mezipaměti mapy OSD v megabajtech. Níže je uveden příklad:
Velikost mezipaměti mapy osd = 1024
Velikost mezipaměti mapy Osd: Toto je velikost mezipaměti mapy OSD v paměti v megabajtech. Příkladem je toto:
osd map cache velikost bl = 128
Možnosti připojení Osd xfs : Umožňuje nám podporovat možnosti připojení souborového systému xfs. Během připojení OSD se připojí s navrhovanými možnostmi připojení. Podívejme se na následující příklad:
možnosti připojení osd xfs = "rw,noatime,inode64,logbsize=256k,delaylog,allocsize=4M"
Osd recovery op priority : Toto je nastavení priority před operacemi obnovy. Čím nižší hodnota, tím vyšší priorita obnovy. Vyšší hodnoty priority obnovy mohou způsobit problémy se snížením výkonu, dokud nebude obnova dokončena. Níže je uveden příklad:
Priorita obnovy osd = 4
Osd recovery max active: Toto je maximální počet aktivních požadavků na obnovu. Čím vyšší hodnota, tím rychlejší je obnova, což může ovlivnit celkový výkon clusteru až do dokončení obnovy. Níže je uveden příklad:
Maximální aktivní obnova OSD = 10
Osd max backfills: Toto je maximální počet operací backfill povolený OSD. Čím vyšší hodnota, tím rychlejší je obnova, což může ovlivnit celkový výkon clusteru až do dokončení obnovy. Níže je uveden příklad:
Maximální počet zásypů Osd = 4
Rozšířené atributy : Jsou také známé jako XATTR, které jsou velmi užitečné pro ukládání metadat souborů. Některé systémy souborů poskytují omezenou sadu bajtů pro úložiště XATTR. V některých případech mohou systému souborů pomoci dobře definované rozšířené atributy. Pro dobrý výkon je nutné použít možnosti XATTR se systémem souborů EXT4. Níže je uveden příklad:
Filestore xattr použijte omap = true
Interval synchronizace systému souborů : K vytvoření konzistentního ukončovacího bodu musí souborový systém blokovat zápisy a také provádět synchronizaci, která synchronizuje data protokolu s datovým oddílem, a tím uvolňuje protokol. Častější provádění operací synchronizace snižuje množství dat uložených v protokolu. V tomto případě se protokol stane nedostatečným. Nastavení méně časté synchronizace umožňuje systému souborů lépe sloučit malé záznamy a můžeme dosáhnout zvýšení výkonu. Následující parametry definují minimální a maximální časové intervaly mezi dvěma synchronizacemi:
minimální interval synchronizace úložiště souborů = 10 maximální interval synchronizace úložiště souborů = 15
Fronta souborového systému : Následující nastavení poskytují omezení velikosti fronty souborového systému. Tato nastavení mohou mít minimální dopad na výkon:
Nastavení protokolu OSD : Démoni Ceph OSD podporují následující nastavení protokolování:
Nastavení konfigurace OSD : Démoni Ceph OSD podporují následující nastavení konfigurace OSD:
Nastavení obnovy OSD : Tato nastavení by měla být použita, pokud dáváte přednost výkonu před obnovením nebo naopak. Pokud je váš cluster Ceph mimo provoz a je ve stavu obnovy, nemusíte dosáhnout normálního výkonu, protože OSD budou zaneprázdněni obnovou. Pokud stále upřednostňujete výkon před obnovou, můžete snížit prioritu obnovy, aby byly OSD méně zaneprázdněné obnovou. Tyto hodnoty můžete také nastavit, pokud chcete rychle obnovit svůj cluster, aby se OSD obnovila rychleji.
Implementace uživatelského prostoru blokového zařízení Ceph nemůže využívat linuxové ukládání stránek do mezipaměti, takže Ceph 0.46 zavedl nový mechanismus ukládání do mezipaměti nazvaný ukládání do mezipaměti RDB (blokové zařízení RADOS). Ceph ve výchozím nastavení nepovoluje ukládání do mezipaměti RBD; Chcete-li tuto funkci povolit, měli byste aktualizovat sekci v konfiguračním souboru clusteru Ceph o následující možnosti:
Mezipaměť RBD = true : Povolí ukládání do mezipaměti RBD.
Velikost mezipaměti RBD = 268435456 : Nastaví velikost mezipaměti RBD v bajtech.
Rbd cache maxšpinavý = 134217728: Toto je změněný datový limit v bajtech; po takovém popisu limitu budou data uložena na úložný server. Pokud je tato hodnota nastavena na 0, Ceph použije metodu ukládání do mezipaměti. Pokud tato možnost není použita, výchozím mechanismem ukládání do mezipaměti je předávání do mezipaměti.
Maximální stáří mezipaměti Rbd = 5 : Toto je počet sekund, po který budou změněná data uchována v mezipaměti, než budou vyprázdněna na server úložiště.
V poslední části probereme různé možnosti konfigurace, které můžete definovat v konfiguračním souboru vašeho clusteru. Byly to tuningové tipy zcela založené na Cephu. V této části se naučíme některé obecné techniky ladění, které budou nakonfigurovány na úrovni operačního systému a na úrovni sítě pro vaši infrastrukturu.
Pid jádra max : Toto je nastavení linuxového jádra, které řídí maximální počet ID vláken a procesů. Většina linuxových jader má relativně malou hodnotu kernel.pid_max. Nastavení tohoto parametru na vyšší hodnotu na uzlech Ceph odkryje více OSD (zařízení pro ukládání objektů), například OSD > 20 může pomoci vytvořit více vláken pro rychlejší obnovu a opětovné vyvážení. Chcete-li použít toto nastavení, spusťte následující příkaz jako root:
# echo 4194303 > /proc/sys/kernel/pid_max
Jumbo rámy : Ethernetové rámce, které jsou delší než 1500 bajtů, se nazývají jumbo rámce. Povolení jumbo rámců pro všechna síťová rozhraní na uzlu clusteru Ceph by mělo zajistit lepší propustnost sítě a celkové zlepšení výkonu. Jumbo rámce jsou konfigurovatelné na úrovni operačního systému, ale síťové rozhraní a základní síťový přepínač musí podporovat jumbo rámce. Chcete-li povolit jumbo snímky, musíte nakonfigurovat rozhraní na straně přepínače tak, aby je akceptovala, a poté pokračovat v konfiguraci na úrovni operačního systému. Chcete-li například ze strany operačního systému povolit jumbo snímky na rozhraní eth0, spusťte následující příkaz:
# ifconfig eth0 mtu 9000
Limit je 9000 bajtů užitečného zatížení síťové rozhraní MTU; aby byly změny trvalé, měli byste také aktualizovat konfigurační soubor síťového rozhraní, /etc/sysconfig/network-script/ifcfg-eth0, na MTU=9000.
disk read_ahead : Parametr read_ahead urychluje operace čtení disku jejich přednačtením a načtením do paměti RAM. Nastavení read_ahead na relativně vysoké hodnoty bude přínosem pro klienty při provádění operací sekvenčního čtení. Aktuálně nastavenou hodnotu read_ahead můžete zkontrolovat pomocí následujícího příkazu:
# cat /sys/block/vda/queue/read_ahead_kb
Chcete-li nastavit read_ahead na větší hodnotu, použijte příkaz:
# echo "8192">/sys/block/vda/queue/read_ahead_kb
Nastavení read_ahead uživatelem obvykle používají klienti Ceph, kteří používají RBD. Musíte změnit read_ahead pro všechny RBD označené pro tohoto hostitele; také se ujistěte, že používáte správný název cesty k zařízení.
Technologie uchovávání a zálohování dat existují již desítky let. Jednou z nejpopulárnějších metod poskytování spolehlivosti dat je replikace . Metoda replikace zahrnuje ukládání stejných dat ve více instancích v různých fyzických umístěních. Tato metoda je dobrá, pokud jde o výkon a spolehlivost dat, ale zvyšuje celkové náklady na úložný systém. Celkové náklady na vlastnictví (TOC) při použití metody replikace jsou poměrně drahé.
Tato metoda vyžaduje dvojnásobný úložný prostor, aby byla zajištěna redundance. Pokud například plánujete řešení úložiště dat 1PB s replikačním faktorem jedna. potřebujete 2 PB fyzického úložného prostoru pro uložení 1 PB replikovaných dat. Cena za gigabajt replikovaných dat úložiště se tak výrazně zvyšuje. Náklady na úložiště v malých clusterech úložiště můžete ignorovat, ale zvažte, jak se náklady vyšplhají, pokud vytvoříte řešení úložiště s hyperškálováním kolem replikovaných serverů úložiště.
V takových situacích se používá metoda kódování výmazu ( Poznámka k překladu: Dopředná oprava chyb), přichází jako dárek. Jedná se o mechanismus používaný v úložišti pro ochranu dat i spolehlivost, který je zcela odlišný od metody replikace. Zaručuje integritu dat tím, že každý úložný objekt rozděluje na menší části zvané chunks, rozšiřuje je a kóduje je pomocí šifrovacích částí a nakonec všechny tyto části ukládá do různých chybových zón clusteru Ceph.
Funkce mazání kódování byla představena v edici Ceph Firefly a byla založena na matematické funkci pro dosažení bezpečnosti dat. ( Poznámka k .: Představena edice Hammer , která dále zvýšila efektivitu obnovy, obsazenost prostoru, variabilitu v povoleném počtu poruch a jejich přizpůsobení.), obecný koncept se točí kolem následující rovnice:
N=k+m
Následující odstavce vysvětlují tyto pojmy a jejich účel:
k : Toto je počet částí, které mají být rozděleny, nazývané také datové části.
m : Toto je dodatečný kód přidaný k datům, aby byla bezpečná, nazývaný také blok kódování. Pro snazší pochopení si to můžete představit jako úroveň spolehlivosti.
n : Toto je celkový počet částí vytvořených po procesu kódování výmazu.
Na základě předchozí rovnice bude každý objekt ve fondu kódování Ceph erasure uložen jako k+m chunks, přičemž každý chunk je uložen v OSD v platné sadě. Všechny části objektu jsou tedy rozmístěny po celém clusteru Ceph, což poskytuje vyšší stupeň spolehlivosti. Nyní si vyjasněme některé užitečné pojmy týkající se kódování výmazu:
Zotavení : Během zotavování Ceph potřebujeme nějaké k porce k dispozici nčásti pro obnovu dat
Úroveň spolehlivosti : Při přepisování kódování může Ceph tolerovat ztrátu až m porcí
Pořadí kódování (r) : Lze vypočítat ze vzorce r = k/n, kde r< 1
Požadovaný úložný prostor : Vypočteno jako 1/r
Uvažujme například fond Ceph s pěti OSD, který je vytvořen pomocí pravidla přepisování kódování (3,2). Každý objekt uložený v tomto fondu bude rozdělen do následujících částí dat a kódu:
N = k + m analogicky, 5 = 3 + 2, tedy n = 5, k = 3 a m = 2
Každý objekt tak bude rozdělen do 3 datových bloků a budou k němu přidány dva bloky kódování výmazu, což povede k celkem pěti dílům, které budou uloženy a distribuovány napříč pěti OSD fondu kódování výmazu v clusteru Ceph. V případě selhání sestavení původního souboru potřebujeme k jeho obnovení jakékoli tři části z pěti částí. Můžeme tedy přežít ztrátu jakýchkoli dvou OSD, protože data lze obnovit pomocí tří OSD.
Pořadí kódování (r) = 3 / 5 = 0,6
Řekněme, že máme 1GB soubor. Chcete-li uložit tento soubor na clusteru Ceph ve fondu kódování pro vymazání (3,5), potřebujete 1,6 GB úložného prostoru, což vašemu souboru poskytne dvě úložiště při selhání OSD.
Na rozdíl od metody replikace, pokud je stejný soubor uložen v replikovaném fondu, bude Ceph vyžadovat replikaci o velikosti 3, aby odolal dvěma selháním OSD, což nakonec bude vyžadovat 3 GB úložného prostoru pro spolehlivé uložení souboru o velikosti 1 GB. Při použití funkce kódování výmazu Ceph tedy ušetříte přibližně 40 procent nákladů na úložiště se stejnou spolehlivostí jako při replikaci.
Fondy s vymazáním kódování vyžadují méně úložiště metadat ve srovnání s replikovanými fondy; tyto úspory úložiště však přicházejí na úkor výkonu, protože každý proces kódování výmazu rozděluje každý objekt na více částí. menší a několik nových kódovaných bloků je smícháno s těmito datovými bloky. Nakonec jsou všechny tyto části uloženy v různých poruchových zónách shluku Ceph. Celý tento mechanismus vyžaduje o něco více výpočetního výkonu z uzlů OSD. Navíc v době obnovy vyžaduje dekódování chunků také značné výpočty. Můžete tedy očekávat, že mechanismus kódování výmazu bude poněkud pomalejší než mechanismus replikace. Metoda kódování výmazu je většinou závislá na případu použití a můžete maximálně využít kódování výmazu na základě vašich požadavků na data.
S vymazávacím kódováním můžete uložit více za méně peněz. Chladné úložiště může být dobrým případem použití pro kódování výmazu, protože umožňuje méně časté čtení a zápis; například velké datové sady, kde jsou data vzorů a genomů uložena po dlouhou dobu, aniž by byla čtena nebo zapisována, nebo některé typy archivních systémů, kde jsou data archivována a není k nim často přistupováno.
Obvykle jsou tyto levné fondy úložišť s vymazáním kódované ve vrstvách s rychlejšími replikačními fondy a pokud se data po určitou dobu (několik týdnů) nepoužívají, lze je přesunout do levnějšího fondu s kódováním pro vymazání, kde je výkon není hlavním kritériem.
Kódování smazání je implementováno vytvořením fondů Ceph s typem vymazání; každý takový fond je založen na souboru parametrů kódování výmazu, který definuje charakteristiky kódování výmazu. Nyní vytvoříme soubor parametrů přepisování kódování a na jeho základě fond přepisování kódování:
Vytvořte soubor parametrů přepisování kódování:
# sada ceph osd erasure-code-profile set EC-profile rulesetfailure-domain=osd k=3 m=2
Vypište soubor parametrů:
# ceph osd erasure-code-profile ls
# ceph osd erasure-code-profile získat EC-profile # ceph osd erasure-code-profile set EC-profile ruleset-failure-domain=osd k=3 m=2 # ceph osd erasure-code-profile ls EC-profile # ceph osd erasure-code-profile získat EC-profile directory=/usr/lib64/ceph/erasure-code k=3 m=2 plugin=jerasure ruleset-fai1ure-domain=osd technika=reed_sol_van #
Příkaz diskutovaný v této části vytvoří soubor parametrů kódování výmazu s názvem EC-profile s charakteristikami k=3 a m=2, což je počet dat a bloků kódování. Každý objekt, který má být uložen, bude tedy rozdělen na 3 (k) datových bloků a k nim budou přidány 2 (m) další kódovací bloky, což vede k 5 (k+m) blokům. Nakonec je těchto 5 (k+m) bloků rozmístěno v různých OSD zónách selhání.
Vytvořte pulz typu výmaz, který bude založen na souboru parametrů kódování výmazu, který jste vytvořili v kroku 1:
# ceph osd pool vytvoření EC-pool 16 16 vymazání EC-profilu
Zkontrolujte stav svého nově vytvořeného fondu; měli byste zjistit, že velikost vašeho bazénu je 5 ( k+m ), tzn. velikost přepsání 5. Data budou tedy zapsána do pěti různých OSD:
# ceph osd výpis | grep -i EC-pool # ceph osd pool vytvořit EC-pool 16 16 vymazání fondu EC profilu "EC-pool" vytvořen # # ceph osd dump | grep -i EC-pool pool 15 "EC-pool" velikost výmazu 5 min_size 1 crush_ruleset 3 object_hash rjenkins pg_num 16 pgp_num 16 last_change 975 vlastník 0 příznaků hashpspool stripe_width 4128 #
Nyní máme nový bazén Ceph, který má typ stírání. Nyní musíme do tohoto fondu vložit některá data vytvořením vzorového souboru s nějakým náhodným obsahem a vložit jej do nově vytvořeného fondu kódování Ceph:
# echo "Mona nyní testuje Ceph Erasure Coding" > filel.txt # cat filel.txt Mona nyní testuje Ceph Erasure Coding # rados -p EC-pool ls # rados put -p EC-pool object1 file1.txt # rados - pEC-pool ls object1 #
Zkontrolujte na mapě OSD EC-pool a objekt1. Výstup tohoto příkazu objasní podrobnosti zobrazením ID OSD, která obsahují části objektů. Jak je vysvětleno v kroku 1, objekt 1 je rozdělen do 3 (m) datových bloků a doplněn 2 (k) kódovanými bloky; v důsledku toho bylo v celém clusteru Ceph uloženo celkem pět kusů v různých OSD. V této ukázce byl objekt 1 uložen v pěti OSD, konkrétně osd.7, osd.6, osd.4, osd.8 a osd.5.
# ceph osd map EC-pool object1 osdmap e976 pool "EC-pool" (15) objekt "object1" -> pg 15.bac5debc (15.c) -> up (, p7) jednající (, p7) #
V tuto chvíli jsme dokončili instalaci fondu mazání na clusteru Ceph. Nyní se záměrně pokusíme zničit OSD, abychom viděli, jak se bude fond mazání chovat, když OSD nebudou k dispozici.
Jak bylo zmíněno v předchozím kroku, některé OSD pro fond mazání jsou osd.4 a osd.5; nyní otestujeme robustnost fondu mazání zničením těchto OSD jednoho po druhém.
Deaktivujte osd.4 a zkontrolujte mapu OSD pro EC-pool a object1. Měli byste si všimnout, že osd.4 je nahrazeno náhodným číslem 2147483647 , což znamená, že osd.4 již není pro tento fond k dispozici:
# ssh ceph-node2 service ceph stop osd.5 # ceph osd map EC-pool object1 # ssh ceph-node2 service ceph stop osd.4 === osd.4 === Zastavení Ceph osd.4 na ceph-node2.. .kill 4542...hotovo # ceph osd map EC-pool object1 osdmap e980 poo1 'EC-pool" (15) objekt "object1" -> pg 15.bac5debc (15.c) -> up (, p7) jednající ( , p7) #
Podobně deaktivujte další OSD, tzn. osd.5 a všimněte si OSD mapy pro EC-pool a object1. Měli byste si všimnout, že osd.5 je nahrazeno náhodným číslem 2147483647 , což znamená, že osd.5 již není pro tento fond k dispozici:
# služba ssh ceph-node2 ceph stop osd.5 === osd.5 === Zastavení Ceph osd.5 na ceph-node2...kill 5437...hotovo # # # ceph osd map EC-pool object1 osdmap e982 fond "EC-pool" (15) objekt "object1" -> pg 15.bac5debc (15.c) -> nahoru (, p7; jednání (, p7) #
Fond Ceph nyní běží na třech OSD, což je minimum požadované pro toto nastavení fondu mazání. Jak již bylo zmíněno, EC-pool bude potřebovat jakékoli tři z pěti bloků, aby mohl obsluhovat data. Nyní nám zbývají pouze tři kusy, konkrétně osd.7, osd.6 a osd.8, a stále máme k dispozici data.
# rados -p EC-pool ls object1 # rados get -p EC-pool object1 /tmp/file1 # cat /tmp/file1 Mona netestuje Ceph Erasure Coding
Kódování výmazu tedy poskytuje fondům Ceph spolehlivost a zároveň je pro spolehlivost vyžadováno méně úložného prostoru.
Funkce Erase Encoding poskytuje architektuře Ceph významné bezpečnostní výhody. Když Ceph zjistí, že některá z chybových zón je nedosažitelná, spustí základní operaci obnovy. Během operace opětovného sestavení se fondy mazání samy obnoví dekódováním neúspěšných bloků na nových OSD a poté automaticky zpřístupní všechny bloky.
V posledních dvou výše zmíněných krocích jsme záměrně zakázali osd.4 a osd.5. Po chvíli začne Ceph obnovovat a aktualizovat ztracené kousky na různých OSD. Po dokončení operací obnovy byste měli zkontrolovat fond EC a objekt1; budete překvapeni, když uvidíte nové identifikátory, jako jsou osd.1, osd.2 a osd.3, a tím se fond mazání stane životaschopným bez zásahu správce.
# ceph osd stat osdmap e1025: 9 osds: 7 up, 7 in # # ceph osd map EC-pool object1 osdmap e1025 pool "EC-pool" (15) object "object1" -> pg 15.bac5debc (15.c) -> nahoru (, p7) hraní (, p7) #
To je způsob, jakým Ceph a erasure kódování tvoří významnou kombinaci. Funkce kódování výmazu pro úložné systémy, jako je Ceph, které jsou škálovatelné na úroveň petabajtů a dále, poskytne nákladově efektivní a spolehlivý způsob ukládání dat na neurčito.
Stejně jako kódování pro vymazání byla v edici Ceph Firefly zavedena také funkce vrstveného ukládání do mezipaměti a byla jednou z nejvíce diskutovaných funkcí Ceph Firefly. Víceúrovňové ukládání do mezipaměti vytváří fond Ceph, který bude postaven na nejrychlejších discích, obvykle SSD. Takový fond mezipaměti musí být umístěn před běžný, replikovaný nebo vymazaný fond tak, aby všechny klientské I/O byly zpracovány jako první; data jsou poté vyprázdněna do existujících datových fondů.
Klienti si užívají vysokého výkonu mezipaměti, zatímco data jsou transparentně zapisována do běžných fondů.
Mezipaměť je obvykle postavena na dražších/rychlejších jednotkách SSD, což zákazníkům poskytuje lepší I/O výkon. Fond mezipaměti má pod sebou vrstvu úložiště, která běží na vřetenových discích typu replikace nebo vymazání. S tímto typem nastavení klienti zasílají I/O požadavky do mezipaměti a dostávají okamžité odpovědi na své požadavky, ať už se jedná o čtení nebo zápis; nejrychlejší vrstva mezipaměti obsluhuje požadavky klientů. Po chvíli vrstva mezipaměti vyprázdní všechna svá data do hlavní vrstvy úložiště, aby mohla ukládat nové požadavky od klientů do mezipaměti. Všechny přesuny dat mezi mezipamětí a úrovní úložiště jsou automatické a pro klienty transparentní. Víceúrovňové ukládání do mezipaměti lze konfigurovat ve dvou režimech.
Když je mezipaměťová vrstva Ceph nastavena na režim zpětného zápisu, klienti Ceph zapisují data do mezipaměti, tj. nejrychlejšího fondu, a proto obdrží okamžité potvrzení. Na základě zásady drop/resettlement, kterou nastavíte pro vaši vrstvenou mezipaměť, jsou data přesouvána mimo vrstvu mezipaměti agentem vrstvené mezipaměti. Během operací čtení klienta jsou data přesunuta z vrstvy úložiště do vrstvy mezipaměti agentem vrstvené mezipaměti a poté doručena klientovi. Data zůstávají na úrovni mezipaměti, dokud nebudou neaktivní nebo nevyprší.
Když je vrstva mezipaměti Ceph nastavena na režim pouze pro čtení, funguje pouze pro operace čtení klienta. Zápisy klienta nezahrnují vrstvené ukládání do mezipaměti, místo toho se všechny zápisy klientů provádějí na vrstvě úložiště. Během operací čtení klienta zkopíruje agent vrstvené mezipaměti požadovaná data z vrstvy úložiště do vrstvy mezipaměti. Na základě zásad, které jste nastavili pro své vrstvené ukládání do mezipaměti, jsou z něj odstraněny položky, jejichž platnost vypršela. Tento přístup je ideální, když mnoho klientů potřebuje číst velké množství podobných dat.
Vrstva mezipaměti je implementována na nejrychlejších fyzických discích, typicky SSD, což poskytuje rychlou mezipaměťovou vrstvu nad pomalejšími tradičními fondy běžícími na vřetenových discích. V této části vytvoříme dva samostatné fondy, fond mezipaměti a běžný fond, které budou použity jako vrstva mezipaměti a vrstva úložiště.
PROTI Kapitola 7. Provoz a údržba Ceph diskutovali jsme o procesu vytváření fondů Ceph nad určitými OSD (zařízeními pro ukládání objektů) úpravou map CRUSH (Controlled Replication Under Scalable Hash). Podobně vytvoříme cache pool založený na osd.0, osd.3 a osd.6. Vzhledem k tomu, že pro toto nastavení nemáme skutečné SSD, budeme předpokládat, že tyto OSD jsou SSD a vytvoříme nad nimi mezipaměť. Níže je uveden pokyn k vytvoření fondu mezipaměti na osd.0, osd.3 a osd.6.
Vytáhněte seznam fond mezipaměti pro obsah; protože je to nový fond, neměl by mít žádný obsah:
# rados -p cache-pool ls
Přidejte libovolný objekt do fond mezipaměti abyste se ujistili, že uloží objekty do správných OSD:
# rados -p cache-pool vložte objekt1 /etc/hosts
# rados -p cache-pool ls
Zkontrolujte OSD kartu fond mezipaměti a objekt1. Pokud správně nastavíte rámec CRUSH, objekt1 by měl být uložen v osd.0, osd.3 a osd.6, protože jeho velikost replikace je 3:
# ceph osd mapa cache-pool object1
Smazat objekt:
# rados -p cache-pool rm object1 # rados -p cache-pool ls # rados -p cache-pool put object1 /etc/hosts # rados -p cache-pool ls object1 # ceph osd map cache-pool object1 osdmap e1143 pool "cache-pool" (16) objekt "object1" -> pg 16.bac5debc (16.1c) -> nahoru (, p3) jednající (, p3) #
Získejte aktuální snímek CRUSH a dekompilujte jej:
# ceph osd getcrushmap -o crushmapdump # crushtool -d crushmapdump -o crushmapdump-decompiled
Upravte dekompilovaný soubor mapy CRUSH a přidejte následující oddíl za oddíl výchozí root :
# vim crushmapdump-decompiled root cache (id -5 alg straw hash 0 položka osd.0 váha 0,010 položka osd.3 váha 0,010 položka osd.6 váha 0,010 )
Vytvořte pravidlo CRUSH přidáním následující části za část pravidla, který se obvykle nachází na konci souboru. Nakonec uložte mapový soubor CRUSH a ukončete editor:
Mezipaměť pravidel (sada pravidel 4 typ replikován min_size 1 max_size 10 krok vzít krok mezipaměti selectleaf firstn 0 typ osd step emit )
Zkompilujte a nasaďte novou mapu CRUSH do clusteru Ceph:
# crushtool -c crushmapdump-decompiled -o crushmapdump-compiled # ceph osd setcrushmap -i crushmapdump-compiled
Protože byl použit cluster Ceph nová mapa CRUSH, měli byste zkontrolovat stav OSD, abyste viděli nové umístění OSD. Najdete nový segment kořenové mezipaměti:
# strom ceph osd # strom ceph osd # id název typu váhy nahoru/dolů změna váhy -5 0,02998 kořenová mezipaměť 0 0,009995 osd.0 nahoru 1 3 0,009995 osd.3 nahoru 1 6 0,009995 osd.6 -2 nahoru 1 - výchozí 0,03 hostitelský ceph-node1 1 0,009995 osd.1 až 1 2 0,009995 osd.2 až 1 0 0,009995 osd.O až 1 -3 ,4 až 1 -4 0,03 os hostitelský ceph-node3 099 6 7 nahoru 1 8 0,009995 osd.8 nahoru 1 #
Vytvořte nový fond a nastavte hodnotu crush_ruleset rovnat se 4 , proto bude nový fond vytvořen na discích SSD:
# ceph osd pool vytvořit cache-pool 32 32 # ceph osd pool set cache-pool crush_ruleset 4 # ceph osd pool set cache-pool crush_ruleset 4 set pool 16 crush_ruleset to 4 # ceph osd dump | grep -i cache-pool pool 16 "cache-pool" replikovaná velikost 3 min_size 1 crush_ruleset 4 object_hash rjenkins pg_num 32 pgp_num 32 last_change 1142 vlastník 0 příznaků hashpspool stripe_width 0 #
Ujistěte se, že je bazén správně vytvořen, tzn. měl by vždy uložit všechny své objekty na osd.0, osd.3 a osd.6:
V předchozí části jsme vytvořili fond založený na SSD; tento fond nyní použijeme jako vrstvenou mezipaměť pro fond kódování výmazu s názvem EC bazén, který jsme vytvořili dříve v této kapitole.
Následující pokyny vás provedou vytvořením vrstvené mezipaměti zpětného zápisu a nastavením překrytí na EC bazén :
Nastavte vrstvené ukládání do mezipaměti, abyste přidružili fondy úložiště k fondům mezipaměti. Syntaxe tohoto příkazu je: ceph osd tier přidat
# ceph osd tier přidat EC-pool cache-pool
Nastavte režim mezipaměti na zpětný zápis nebo pouze pro čtení. V tomto demu používáme zpětný zápis a jeho syntaxe by byla: ceph osd tier cachemode
# ceph osd úroveň cache-režim cache-pool zpětný zápis
Chcete-li přesměrovat všechny požadavky klientů ze standardního fondu do fondu mezipaměti, nastavte překrytí a syntaxi pro toto je následující ceph osd tier set overlay
# ceph osd tier set-overlay EC-pool cache-pool # ceph osd tier add EC-pool cache-pool pool "cache-pool" je nyní (nebo již byl) úrovní "EC-pool" # ceph osd tier cache -mode zpětný zápis cache-pool nastavit režim cache pro fond "cache-pool" na zpětný zápis # ceph osd tier set-overlay EC-pool cache-pool overlay pro "EC-pool" je nyní (nebo již byl) "cache-pool" "#
Při kontrole podrobností o bazénu si toho všimnete EC bazén má tier , read_tier a write_tier nastavené na 16 , což je ID fondu fond mezipaměti .
Podobně pro fond mezipaměti nastavení bude následující: tier_of je nastaven na 15 a cache_mode je nastaven na zpětný zápis ; všechna tato nastavení předpokládají, že je fond mezipaměti správně nakonfigurován:
# ceph osd výpis | egrep -i "EC-pool|cache-pool" # ceph osd dump | egrep -i "EC-pool|cache-pool" pool 15 "EC-pool" velikost výmazu 5 min_size 1 crush_ruleset 3 object_hash rjenkins pg_num 16 pgp_num 16 last_change 1181 vlastník 0 příznaků hashpspool tier 1616 16. vrstva pro čtení_12. -pool" replikovaná velikost 3 min_size 1 crush_ruleset 4 object_hash rjenkins pg_num 32 pg p_num 32 last_change 1181 vlastník 0 příznaků hashpspool tier_of 15 cache_mode zpětný zápis stripe_width 0 #
Víceúrovňové ukládání do mezipaměti má řadu možností přizpůsobení; měli byste nastavit víceúrovňové ukládání do mezipaměti, abyste pro něj nastavili zásady. V této části nakonfigurujeme zásady vrstveného ukládání do mezipaměti:
Povolit použití sledování sady přístupů pro fond mezipaměti; Vrstvená mezipaměť na produkční úrovni používá filtrování květů:
# ceph osd pool set cache-pool hit_set_type bloom
Zpřístupnit hit_set_count , což je počet požadavků v sadě, které se mají uložit do fondu mezipaměti:
# ceph osd pool set cache-pool hit_set_count 1
Zpřístupnit hit_set_period , což je doba trvání nastavené periody přístupu v sekundách pro fond uložený v mezipaměti:
# ceph osd pool set cache-pool hit_set_period 300
Zpřístupnit target_max_bytes , což je maximální počet bajtů, po kterém agent vrstvené mezipaměti začne vyplachovat/vylučovat objekty z fondu mezipaměti:
# ceph osd pool set cache-pool target_max_bytes 1000000 # ceph osd pool set cache-pool hit_set_type bloom set pool 16 hit_set_type to bloom # ceph osd pool set cache-pool hit_set_count 1 set pool 16 hit_set_count to 1 # set ceph osd pool hit_set_period 300 set pool 16 hit_set_period to 300 # ceph osd pool set cache-pool targetLjnax_bytes 10000000 set pool 16 target_max_bytes to 10000000 #
Zpřístupnění cache_min_flush_age a cache_min_evict_age , což je čas v sekundách, po kterém agent vrstvené mezipaměti začne splachovat zastaralé objekty z fondu mezipaměti do vrstvy úložiště:
# ceph osd pool set cache-pool target_max_objects 10000
Zpřístupnit target_max_objects , což je maximální počet objektů, po kterém agent vrstvené mezipaměti začne vyplachovat/vylučovat objekty z fondu mezipaměti:
# ceph osd pool set cache-pool cache_min_flush_age 300 # ceph osd pool set cache-pool cache_min_evict_age 300 # ceph osd pool set cache-pool target_max_objects 10000 set pool 16 target_max_objects to 10_shmin pool set_flush cache set_flush_pool 10000 pool 10000 ossh pool 160 na 300 # ceph osd pool set cache-pool cache_min_evict_age 300 set pool 16 cache_min_evict_age to 300 #
Zpřístupněte cache_target_dirty_ratio , což je procento „nečistých“ (upravených) objektů fondu mezipaměti, které agent vrstvené mezipaměti začne splachovat do vrstvy úložiště:
# ceph osd pool set cache-pool cache_target_dirty_ratio .01
Zpřístupněte cache_target_full_ratio , což je procento nezměněných objektů fondu mezipaměti, které obsahuje, a poté je agent vrstvené mezipaměti začne vyprázdnit do vrstvy úložiště:
# ceph osd pool set cache-pool cache_target_full_ratio .02
Vytvořte 500 MB dočasný soubor, do kterého budeme zapisovat EC bazén, a do kterého bude nakonec zapsáno fond mezipaměti :
# dd if=/dev/zero of=/tmp/file1 bs=1M počet=500
Následující snímek obrazovky zobrazuje předchozí příkazy v sekci:
# ceph osd pool set cache-pool cache_target_dirty_ratio .01 set pool 16 cache_target_dirty_ratio to .01 # ceph osd pool set cache-pool cache_targetL_full_ratio .02 set pool 16 cache_target_full_ratio if=// # devd= of/. soubor1 bs=1M počet=500 500+0 záznamů v 500+0 záznamech z 524288000 bajtů (524 MB) zkopírováno, 1,66712 s, 314 MB/s #
V současné době jsme vytvořili a nakonfigurovali víceúrovňové ukládání do mezipaměti. Dále to otestujeme. Jak bylo vysvětleno dříve, během operace zápisu klienta se zdá, že se data zapisují do běžného fondu, ale ve skutečnosti jsou nejprve zapsána do fondu mezipaměti, takže klienti těží z rychlého I/O. Na základě zásad vrstveného ukládání do mezipaměti se data transparentně přesouvají z fondu mezipaměti do fondu úložiště. V této části otestujeme naše nastavení vrstveného mezipaměti zápisem a pozorováním objektů ve vrstvách mezipaměti a úložiště:
V předchozí části jsme vytvořili 500 MB testovací soubor s názvem /tmp/file1 ; nyní vložíme tento soubor EC bazén :
# rados -p EC-pool vložte objekt1 /tmp/soubor1
Pokud EC bazén uložené v mezipaměti fond mezipaměti, do souboru1 se nesmí zapisovat EC bazén v prvním státě. Musí to být zaznamenáno v fond mezipaměti. Podívejme se na každý bazén, abychom získali názvy objektů. Ke sledování časů a změn použijte příkaz datum:
# rados -p EC-pool ls # rados -p cache-pool ls # date # rados -p EC-pool put object1 /tmp/file1 # rados -p EC-pool ls # rados -p cache-pool ls object1 # # datum Ne 14. září 02:14:58 EEST 2014 #
Po 300 sekundách (nakonfigurovali jsme cache_min_evict_age na 300 sekund) se agent vrstvené mezipaměti přesune objekt1 z fond mezipaměti proti EC bazén ; objekt1 bude odstraněn z fond mezipaměti :
# rados -p EC-pool ls # rados -p cache-pool ls # date # date Ne 14. září 02:27:41 EEST 2014 # rados -p EC-pool ls object1 # rados -p cache-pool Is #
Jak bylo vysvětleno v předchozím výstupu, data se přesouvají z fond mezipaměti proti EC bazén po určité době.
Ceph přichází s vestavěným srovnávacím programem s názvem Lavička RADOS , který se používá k měření výkonu úložiště objektů Ceph. V této části použijeme lavici RADOS k získání metrik výkonu pro náš cluster Ceph. Vzhledem k tomu, že jsme pro Ceph použili málo konfigurované virtuální uzly, neměli bychom v tomto demu očekávat dobré výkonové výsledky od RADOS bench. Dobré hodnoty výkonu však můžete získat s použitím doporučeného hardwaru při nasazení Ceph s laděním výkonu.
Syntaxe pro použití této sady nástrojů je: rados lavice -p
Platné možnosti pro lavičku Rados jsou následující:
P nebo --pool : Název skupiny
T : Toto je počet simultánních operací; výchozí hodnota 16
No-cleanup: Dočasná data zapsaná do datového fondu RADOS bench by se neměla čistit. Tato data budou použita pro operace čtení při použití se sekvenčním nebo náhodným čtením. Výchozí nastavení je vyčištění.
Pomocí výše uvedené syntaxe mv nyní spusťte několik testů RADOS:
10sekundový test zápisu do fondu dat vygeneruje následný výstup. Je důležité poznamenat, že výstupní propustnost (MB/s) RADOS bench , která je pro naše nastavení 13.412 , což je velmi málo, protože máme virtuální cluster Ceph. Další podrobnosti, které sledujeme, jsou celkový počet dokončených zápisů, zapsaný objem, průměrná latence a tak dále. Vzhledem k tomu, že jsme použili příznak --no-cleanup, data zapsaná do RADOS bench nebudou smazána a budou použita v RADOS bench sekvenčním a náhodném čtení operací:
# rados bench -p data 10 zápis --no-cleanup # rados bench -p data 10 zápis --no-cleanup Udržení 16 souběžných zápisů 4194304 bajtů po dobu až 10 sekund nebo 0 objektů Předpona objektu: benchmark_data_ceph-node1_26928 sec Cur ops 0 zahájeno dokončeno prům. MB/s kurs MB/s poslední šíř. prům. šíř. 0 16 16 0 0 0 - 0 1 16 16 0 0 0 - 0 2 15 18 3 4,88541 6 2,4189 2,12187 3 16 53,21 24 83 2.51728 5 16 29 13 9.48749 16 5.37976 3.26326 6 16 29 13 8.02065 0 - 3.26326 7 16 33 17 9.07075 8 5.23925 3.3801 8 16 35 19 8.9441 8 3.31397 8.59352 9 15 39 24 10.0899 20 2.52773 3.98084 20 2.52773 3.98084 10 16 40 24 9.12944 0 - 3.98084 11 15 41 26 9,03055 4 4,05948 4,23526 Celkový čas běhu: 12,227935 Celkový počet provedených zápisů: 41 Velikost zápisu: 4194304 Šířka pásma (MB/s): 13,412 Stddev Šířka pásma Min. šířka pásma/183 MB: 2.0 MB Max. 0 Průměrná latence: 4,61251 Stddev latence: 2,54733 Max. latence: 11,7108 Min. latence: 1,17417 #
Spusťte sekvenční test čtení benchmarku datového fondu:
# rados bench -p data 10 seq # rados bench -p data 10 seq sec Cur ops zahájena dokončena prům. MB/s cur MB/s poslední lat prům. lat 0 12 12 0 0 0 - 0 1 15 21 6 23,7445 24 0,3651783 0.3651786 0. 15 25 10 19,889 16 1,91165 0,947636 3 16 31 15 19,9216 20 0,832548 1,1234 4 16 36 20 19,8804 20 3,81842 1,623 5 16 41 25 19,9027 20 2,4696 1,94785 6 15 41 26 17,2372 4 1,4177 1,92746 Celková doba cyklu: 6,807863 Celková Čte Vyrobeno: 41 READ velikost: 4194304 Šířka pásma (MB/s): 24,090 Průměrná latence: 2,48104 Max. latence: 6,38046 Min. latence: 0,365323 #
Spusťte test náhodného čtení benchmarku datového fondu:
# rados bench -p data 10 rand # rados bench -p data 10 rand sec Cur ops zahájena dokončena průměr MB/s cur MB/s last lat avg lat 0 12 12 0 0 0 - 0 1 15 22 7 27.8596 28 0.30046823 0.30046823 0.30046823 0.30046823 16 27 11 21,8062 16 0,237253 0,635548 3 16 34 18 23,6913 28 1,52991 1,18525 4 15 36 21 20,7954 12 3,79887 1,53081 5 16 41 25 19,784 16 2,73283 1,91815 6 15 48 33 21,6187 32 1,68679 2,2017 7 16 58 42 23,6049 36 1,84635 2,31201 8 16 63 47 23.0549 20 4.173 2.33454 9 16 69 53 23.1574 24 2.31493 2.294 10 16 73 57 22.4116 16 2.45812 2.32087 11 4 73 69 24.7012 48 3.27041 2.3137 Celkový časový běh: 11.206381 Celkový počet znění: 73 Přečtěte velikost: 4194304 šířka pásma (MB / s): 26,057 Průměrná latence: 2,38341 Max. latence: 5,19721 Min. latence: 0,188254 #
Tímto způsobem můžete kreativně navrhnout testovací případy zápisu, čtení a náhodného čtení pro váš fond Ceph. RADOS bench je rychlý a lehký benchmarkingový nástroj a dobré na tom je, že je dodáván s Cephem.
Ladění výkonu a benchmarking udělají z vašeho clusteru Ceph cluster produkční třídy. Měli byste to udělat vždy doladění vašeho clusteru Ceph předtím, než půjde do výroby pomocí předprodukce, vývoje nebo testování. Ladění výkonu je rozsáhlé téma a v každém prostředí je vždy prostor pro ladění. K měření výkonu clusteru Ceph byste měli používat nástroje pro výkon a na základě těchto výsledků můžete podniknout kroky.
V této kapitole jsme pokryli většinu možností konfigurace pro váš cluster. Naučili jste se složitá témata, jako je ladění výkonu z hardwaru a software. Tato kapitola také obsahuje podrobné vysvětlení kódování mazání Ceph a funkci vrstveného ukládání do mezipaměti, po čemž následuje diskuse o vestavěné sadě nástrojů pro srovnávání Ceph, benchmarku RADOS.
Ceph cluster
Doporučuje se vytvořit cluster Ceph dle projektové dokumentace. Na této stránce poskytujeme pouze souhrnné informace o instalaci.
Cluster Ceph musí být umístěn odděleně od VMmanageru. Pojmy „uzly“ a „klastr“ nemají nic společného s „uzly clusteru“ VMmanageru.
Požadavky na systém
K vytvoření clusteru je potřeba následující:
- fyzické popř virtuální servery(minimum - 5): jeden server s daty ( OSD), jeden server pro metadata ( MDS), alespoň dva monitorovací servery a administrativní server (také znám jako první klient);
- Všechny servery by měly být umístěny co nejblíže k sobě. Přednostně v jednom racku a jednom segmentu sítě;
- Pro Ceph cluster je žádoucí použít vysokorychlostní internetové připojení, jak mezi uzly clusteru, tak s klientskými uzly;
- Na všech serverech musí být spuštěn stejný operační systém.
Příprava uzlu
Všechny uzly clusteru musí:
- Nainstalujte openssh;
- Vytvořit uživatelský ceph:
- Přidělte vytvořenému uživateli všechna oprávnění:
Poté musíte na administrativním serveru vytvořit ssh klíče, abyste měli přístup z administrativního serveru ke všem uzlům clusteru:
- Vytvořte adresář /ceph-client a přejděte do něj:
- Vytvořte ssh klíče:
- V případě, že uzly clusteru nelze vyřešit v DNS, musíte provést aktualizaci /etc/hosts. Správná šablona souboru vypadá takto:
- Je vhodné vytvořit proměnnou:
- Poté můžete zkopírovat klíče ssh do uzlů clusteru následovně:
- Upravte konfigurační soubor ~/.ssh/config. Správná šablona souboru vypadá takto:
Instalace softwaru a vytvoření clusteru
- Instalace ceph-deploy:
- Vytvoření clusteru: Chcete-li to provést, musíte inicializovat uzly „monitor“:
- Vezměte prosím na vědomí, že pokud chcete používat úložiště Ceph s jedním uzlem clusteru, musíte změnit výchozí parametr "osd crush selectleaf type" ("1") na "0" v konfiguračním souboru Ceph (ceph.conf):
- Instalace ceph do uzlů clusteru:
- Instalace softwaru pro clusterové monitory:
- Získání klíčů monitoru clusteru:
- Příprava úložiště (v příkladu mají storage nody prázdný disk /dev/sdb):
- Čištění /dev/sdb disků na úložištích. Všechna data na discích budou smazána :
- Příprava uzlu metadat:
Zajímavý příspěvek na Habré popisující zkušenosti webhostingu FirstVDS s jejich pokusy vytvořit cluster na ceph a upřímný popis všech podstatných částí problémů, kterých se při tom chopili. Užitečné a duši šetřící čtení pro každého, kdo uvažuje o ceph jako o podnikovém řešení.
Stručně, stručně o získaných lekcích:
* Proces „učení se lekcím“ dosud trval přibližně dva roky. První verze byla sestavena na podzim 2014.
* Ne všechny x86 servery jsou „stejně užitečné“. Servery zakoupené speciálně pro cluster se ukázaly jako chybné.
Abychom vyzkoušeli novou architekturu a zbavili se předchozích nedostatků, sestavili jsme testovací stolici. A pak se ukázala zajímavá věc - servery speciálně zakoupené pro montáž první verze se ukázaly jako „spálené“. Systémová sběrnice všech serverů byla pomalá. Výsledkem je, že všechna zařízení připojená k severu a jižní mosty- IB karty připojené přes PCI-E, disky, paměti - taky fungovaly pomalu. To vysvětlilo většinu problémů, se kterými jsme se setkali. Jako vzorek jsme vzali několik volných uzlů, na kterých obvykle provozujeme klientské VDS. Podle těch jejich vlastnosti byly téměř stejné. Sestavili jsme a spustili cluster na těchto strojích, začali jsme testovat. Všechno letí! …koupili nové servery založené na Xeonu 2630…
* Daleko od optimálního schématu obnovy redundance v ceph, vyžadující ruční nastavení.
Cluster si s úkoly poradil – pokud selhaly celé disky nebo uzly, fungoval dál. Nicméně každé vyvažování učinilo situaci kritickou. Při přidávání nového disku byla zátěžová špička vyrovnána pomocí závaží. Hmotnost je zodpovědná za míru využití konkrétního fyzického média. Nainstalujte nový disk, nastavte váhu na 0 - disk se nepoužívá. Poté váhu postupně zvyšujeme a k vyvažování dochází po malých porcích. Pokud disk selže, pak váhy nefungují: ~1 TB replik musí být okamžitě „rozprostřeno“ na zbývající disky a Ceph přejde na dlouhou dobu do režimu zápisu dat a zatěžuje disky „prázdnou“ prací.
* Přestavba ceph clusteru za chodu způsobuje značné zatížení serverů a ovlivňuje normální provoz aplikací
* K vybudování hyper-konvergovaného systému v jeho nejčistší podobě, kdy stejné servery jsou jak storage nody, tak virtualizační hostitelé, se ceph ukázalo jako málo použitelné.
S nárůstem počtu VDS začal cluster pracovat nestabilně a klientské stroje jsme přenesli do běžných uzlů. …
Po několika iteracích se ukázalo, že se situace zásadně nemění. Rozhodli jsme se převést klienty do běžných uzlů a cluster rozpustit.
První verze clusteru nesplnila očekávání. Zákazníci se setkali s kotoučovými brzdami a my jsme strávili příliš mnoho času technická podpora shluk.
* Nevyvážený systém s velkokapacitními SATA disky koupenými „za účelem úspory peněz“ se stal problémem, když se zátěž zvýšila.
* Síťově distribuovaný zápis do úložiště, bez datové lokality, při vysoké I/O zátěži clusteru je zlo.
* SSD v režimu mezipaměti v řadě specifických situací, jako je výměna vadného disku a následné vyvážení, nefunguje dobře.
Přibližně 5 měsíců systém fungoval pozoruhodně a potěšil nás i naše zákazníky. Tak tomu bylo, dokud počet zákazníků nedosáhl kritické hodnoty. Prostorné disky 4-8 TB se k nám stále plazily bokem. Když byl disk již z poloviny plný, změnil se v úzké hrdlo - na jednom se nacházelo velké množství souborů patřících různým VDS fyzická média a musel obsloužit velké množství zákazníků. Když se to nepovedlo, bylo obtížné i opětovné vyvážení – muselo se přerozdělit velké množství informací. SSD-cache v takových podmínkách dobře nezvládla své povinnosti. Dříve nebo později by se disk s mezipamětí zaplnil a dal signál - odteď už nic neukládám do mezipaměti, ale pouze zapisuji uložené informace na pomalý HDD. V tuto chvíli zažívá HDD dvojnásobné zatížení – zpracovává přímé přístupy, které přicházejí obcházením mezipaměti, a zapisuje data uložená v mezipaměti. Úložiště fungovalo dobře, dokud nedošlo ke změně konfigurace disku. Vypuštění disku nebo přidání nového značně zpomalilo celkovou propustnost úložiště.
* Nízká kvalita ceph kód může vést k vážným problémům se zničením datového úložiště.
Použijte LTS vydání Ceph. Nepočítejte s tím, že budete válet nová verze s každým vydáním. Aktualizace je pro úložiště potenciálně nebezpečná operace. Přechod na novou verzi bude vyžadovat změny v konfiguracích a není pravda, že úložiště bude po aktualizaci fungovat. Sledování oprav chyb – jsou vráceny z nových verzí na staré.
* Chyby mohou zničit jak provoz clusteru jako celku, tak i obsah úložiště.
18. února 2016 jsme narazili na kritickou chybu Ceph: v procesu vyprázdnění mezipaměti na disk nesprávné zadání datový blok. To vedlo k vypnutí procesů ceph-osd všech disků, kde byly uloženy repliky nešťastného bloku. Systém okamžitě ztratil tři disky, a tím i všechny soubory na nich umístěné. Proces rebalancování se spustil, ale nepodařilo se jej dokončit úplně – koneckonců ze systému zmizely všechny tři kopie alespoň jednoho datového bloku (a odpovídajícího souboru), který problém spustil. Konzistence úložiště byla ohrožena. Ručně jsme odstranili špatné bloky, restartovali procesy ceph-osd, ale to na dlouho nepomohlo. Chybný zápis se opakoval, znovu začalo balancování a trezor se zhroutil. …
Intenzivní hledání na internetu přineslo v té době uzavřenou chybu v nejnovější verzi Ceph Hammer. Naše úložiště běží dál předchozí verze- Světlušky.
Upozornili jsme zákazníky na nedostupnost serverů a pokračovali v upgradu. Přešli jsme na jiné úložiště, které je plné oprav chyb, provedli yum aktualizaci, restartovali procesy Ceph - nepomohlo to. Chyba se opakuje. Lokalizovali jsme zdroj problému – zápis z mezipaměti do hlavního úložiště – a ukládání do mezipaměti jsme úplně zakázali. Klientské servery začaly fungovat, ale každé vyvážení se změnilo v peklo. Disky nezvládaly údržbu vyvážení systému a klientské čtení a zápis.
Problém vyřešil radikálně - opustil SSD cache
* Pro plný provoz clusteru ceph je vyžadována konfigurace allflash.
nastavte SSD disky jako hlavní. Zde pomohly uzly s velkým počtem diskových košů, prozíravě zakoupené pro storage cluster. Vyměňovali ho postupně: nejprve přidali čtyři SSD do zbývajících prázdných košů na každém serveru a po vyvážení dat začali nahrazovat staré HDD SSD po jednom. Dělali to podle schématu: vyjmutí disku, instalace disku, vyvážení dat, mazání, instalace, vyvážení a tak dále v kruhu, dokud v uzlech nezůstaly pouze SSD. Nahrazeno horkým...
Použili jsme průmyslové disky Samsung 810 o velikosti 1 TB. Nepoužili větší SSD, aby nevznikla „úzká“ situace, kdy je mnoho dat umístěno na jednom fyzickém médiu, a má tedy velký počet přístupů.
Postupně jsme tak vyměnili všechny disky za SSD. A přišlo štěstí
Moje závěry (které se nemusí shodovat se závěry autorů původního příspěvku): ceph ve výrobě je zážitek pro lidi s železnými koulemi. Lakomec platí. A je dobře, když jen dvakrát. A o to víc dobré, i když jen peníze. Zapomeňte na dovolené s rodinou a na noc vypnutý telefon. Teď to není pro tebe.