Dobrý den, nedávno jsem narazil na zajímavý problém: nastavení úložiště pro zálohování velkého množství blokových zařízení.
Každý týden zálohujeme všechny virtuální stroje v našem cloudu, takže musíme být schopni udržovat tisíce záloh a dělat to co nejrychleji a nejefektivněji.
Bohužel standardní konfigurace RAID5, RAID6 v tomto případě nám to nebude umožněno, protože proces obnovy na tak velkých discích, jako je ten náš, bude bolestivě dlouhý a pravděpodobně nikdy neskončí.
Podívejme se, jaké alternativy existují:
— Podobné jako RAID5, RAID6, ale s konfigurovatelnou úrovní parity. Rezervace se v tomto případě neprovádí blok po bloku, ale pro každý objekt zvlášť. Nejjednodušší způsob, jak vyzkoušet kódování výmazu, je rozšířit .
je aktuálně nevydaná funkce ZFS. Na rozdíl od RAIDZ má DRAID distribuovaný paritní blok a během obnovy využívá všechny disky pole najednou, díky čemuž lépe přežije selhání disku a rychleji se po selhání obnoví.
Server k dispozici Fujitsu Primegy RX300 S7 s procesorem Procesor Intel Xeon E5-2650L 0 @ 1.80 GHz, devět pamětí RAM Samsung DDR3-1333 8Gb PC3L-10600R registrovaný ECC (M393B1K70DH0-YH9), police na disky Supermicro SuperChassis 847E26-RJBOD1, připojeno přes Duální LSI SAS2X36 Expander a 45 disků Seagage ST6000NM0115-1YZ110 na 6TB všichni.
Než se pro něco rozhodneme, musíme vše nejprve pořádně otestovat.
K tomu jsem připravil a otestoval různé konfigurace. K tomu jsem použil minio, které fungovalo jako backend S3 a spouštělo jej v různých režimech s různým počtem cílů.
V podstatě bylo pouzdro minio testováno v erasure coding vs softwarový raid se stejným počtem disků a paritou disků, a to jsou: RAID6, RAIDZ2 a DRAID2.
Pro informaci: když spustíte minio pouze s jedním cílem, minio pracuje v režimu brány S3 a poskytuje váš místní souborový systém ve formě úložiště S3. Pokud spustíte minio se specifikováním několika cílů, automaticky se zapne režim Erasure Coding, který rozloží data mezi vaše cíle a zároveň zajistí odolnost proti chybám.
Ve výchozím nastavení minio rozděluje cíle do skupin po 16 discích se 2 paritami na skupinu. Tito. Dva disky mohou selhat současně bez ztráty dat.
Pro testování výkonu jsem použil 16 disků po 6TB a napsal na ně malé objekty o velikosti 1 MB, to nejpřesněji popisovalo naši budoucí zátěž, protože všechny moderní zálohovací nástroje rozdělují data do bloků o velikosti několika megabajtů a zapisují je tímto způsobem.
K provedení benchmarku jsme použili utilitu s3bench, spuštěnou na vzdáleném serveru a posílající desítky tisíc takových objektů do minia ve stovkách vláken. Poté jsem se o ně pokusil stejným způsobem požádat zpět.
Výsledky benchmarku jsou uvedeny v následující tabulce:
Jak vidíme, minio ve svém vlastním režimu kódování pro vymazání má výrazně horší výsledky při zápisu než minio běžící nad softwarovými RAID6, RAIDZ2 a DRAID2 ve stejné konfiguraci.
Samostatně já otestujte minio na ext4 vs XFS. Překvapivě se pro můj typ zátěže ukázalo, že XFS je výrazně pomalejší než ext4.
V první várce testů Mdadm prokázal převahu nad ZFS, ale později že můžete zlepšit výkon ZFS nastavením následujících možností:
xattr=sa atime=off recordsize=1Ma poté byly testy se ZFS mnohem lepší.
Můžete také poznamenat, že DRAID neposkytuje oproti RAIDZ velké zvýšení výkonu, ale teoreticky by měl být mnohem bezpečnější.
V posledních dvou testech jsem také zkoušel přenést metadata (speciální) a ZIL (log) do mirroru z SSD. Odstranění metadat však nepřineslo velký zisk v rychlosti záznamu a při odstraňování ZIL jsem měl narazil na strop při 100% využití, takže tento test považuji za neúspěšný. Nevylučuji, že kdybych měl rychlejší SSD disky, možná by to mohlo výrazně zlepšit mé výsledky, ale bohužel jsem je neměl.
Nakonec jsem se rozhodl použít DRAID a i přes svůj beta status je to v našem případě nejrychlejší a nejefektivnější řešení úložiště.
Vytvořil jsem jednoduchý DRAID2 v konfiguraci se třemi skupinami a dvěma distribuovanými náhradními díly:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsDobře, vyřešili jsme úložiště, teď si promluvme o tom, co budeme zálohovat. Zde bych chtěl okamžitě mluvit o třech řešeních, která se mi podařilo vyzkoušet, a to jsou:
- Vidlička , specializované řešení pro zálohování blokových zařízení, má úzkou integraci s Ceph. Dokáže pořizovat rozdíly mezi snímky a vytvářet z nich přírůstkovou zálohu. Podporuje velké množství backendů úložiště, včetně lokálních a S3. Vyžaduje samostatnou databázi pro uložení deduplikační hashovací tabulky. Nevýhody: psáno v pythonu, má mírně nereagující cli.
- Vidlička , dlouho známý a osvědčený zálohovací nástroj, umí zálohovat data a dobře je deduplikovat. Schopnost ukládat zálohy lokálně i na vzdálený server přes scp. Může zálohovat blokovat zařízení, pokud jsou spuštěna s příznakem --special, jedno z mínusů: při vytváření zálohy je úložiště zcela zablokováno, proto se doporučuje vytvořit pro každý virtuální stroj samostatné úložiště, v zásadě to není problém, naštěstí se vytvářejí velmi snadno.
je aktivně se vyvíjející projekt, napsaný za běhu, poměrně rychlý a podporuje velké množství backendů úložiště, včetně místního úložiště, scp, S3 a mnoha dalších. Samostatně bych chtěl poznamenat, že existuje speciálně vytvořený for restic, který umožňuje rychle exportovat úložiště pro použití na dálku. Ze všech výše jmenovaných se mi to líbilo nejvíc. Lze zálohovat ze stdin. Nemá téměř žádné znatelné nevýhody, ale existuje několik funkcí:
-
Nejprve jsem to zkusil použít v režimu obecného úložiště pro všechny virtuální stroje (jako Benji) a dokonce to fungovalo docela dobře, ale operace obnovy trvaly velmi dlouho, protože... Pokaždé před obnovením se Restic pokusí přečíst metadata všech záloh. Tento problém byl snadno vyřešen, stejně jako u borg, vytvořením samostatného úložiště pro každý virtuální stroj. Tento přístup se ukázal jako velmi účinný i pro správu záloh. Samostatná úložiště mohou mít samostatné heslo pro přístup k datům a také se nemusíme bát, že by se globální repo nějak zlomilo. Můžete vytvářet nová úložiště stejně snadno jako v borgském zálohování.
V každém případě se deduplikace provádí pouze vzhledem k předchozí verzi zálohy, předchozí záloha je určena cestou pro zadanou zálohu, takže pokud zálohujete různé objekty ze stdin do společného úložiště, nezapomeňte zadat volba
--stdin-filenamenebo pokaždé explicitně specifikujte možnost--parent.
-
Za druhé, obnova do stdout trvá mnohem déle než obnova do souborového systému kvůli jeho paralelní povaze. V budoucnu plánujeme přidat bližší podporu zálohování pro bloková zařízení.
-
Za třetí, v současné době se doporučuje používat , protože verze 0.9.6 má chybu s dlouhou obnovou velkých souborů.
Abych otestoval efektivitu zálohování a rychlost zápisu/obnovy ze zálohy, vytvořil jsem samostatné úložiště a zkusil jsem zálohovat malý obraz virtuálního stroje (21 GB). Dvě zálohy byly provedeny beze změny originálu, pomocí každého z uvedených řešení bylo zkontrolováno, jak rychleji/pomaleji byla deduplikovaná data zkopírována.
Jak vidíme, Borg Backup má nejlepší poměr počáteční účinnosti zálohování, ale je horší z hlediska rychlosti zápisu i obnovy.
Ukázalo se, že Restic je rychlejší než Benji Backup, ale obnovení na stdout trvá déle a bohužel ještě neumí zapisovat přímo na blokové zařízení.
Po zvážení všech pro a proti jsem se rozhodl usadit zbytkový с odpočinkový server jako nejpohodlnější a nejslibnější řešení zálohování.
Na tomto screencastu můžete vidět, jak je 10gigabitový kanál plně využit během několika operací zálohování současně. Za zmínku stojí, že recyklace disků nestoupá nad 30 %.
Byl jsem více než spokojen s řešením, které jsem obdržel!
Zdroj: www.habr.com