Sheepdog

Z DCEwiki
Skočit na navigaci Skočit na vyhledávání

Sheepdog je škálovatelný systém, který poskytuje virtuálním strojům distribuovaná bloková zařízení. Za jeho vývojem, který začal v r. 2009, stojí vývojáři japonské firmy Nippon Telegraph and Telephone Corporation. Sheepdog je opensource aplikace s GPL2 licencí. Zatím poslední verzi 0.9.3, vydanou v listopadu 2015, by měla následovat verze 1.0 použitelná i pro komerční nasazení[1].

Jen pro zajímavost, první verzi (0.1.0) vývojáři vydali v srpnu 2010 - v téže době byla zahrnuta podpora sheepdogu i do hlavní vývojové větve QEMU. První testy sheepdogu jsem dělal v listopadu 2011[2] a z hlediska výkonu I/O operací nebyly výsledky vůbec špatné. Ovšem tehdy měl ještě systém Sheepdog problém s opětovným připojením odpadlého nodu. Tento problém byl pravděpodobně záhy odstraněn, neboť vývoj aplikace je poměrně živý, ale mezi tím jsem použil jiné řešení.


Vlastnosti

Jak funguje Sheepdog je velice srozumintelně popsáno v publikované prezentaci[1], proto se omezím pouze na stručný přehled.

Je škálovatelný
Datový prostor lze za běhu libovolně navyšovat jak na úrovni nodů, tím že se zvětšuje jejich datová kapacit, tak i jejich počtem. Čím větší počet nodů, tím vyšší I/O výkon VDI
Je jednoduchý
Na rozdíl od jiných systému jakým je kupř. CEPH, Sheepdog nepracuje přímo se souborovým systémem, ale s bloky dat o fixní velikosti, tudíž nepotřebuje mít separátní démony pro údržbu metadat. Veškerá správa se provádí prostřednictvím jednoho nástroje dog, který komunikuje přímo s ovečkami (sheep)
Počítá s výpadkem nodu
Každé VDI je tvořeno právě těmito bloky (objektů), které se současně replikují přes několik nodů, takže pokud některý z nich vypadne jsou data stále dostupná, a objekty se místo nodu který vypadnul začnou replikovat na jiný nod.
Podporuje snapshoty na úrovni blokového zařízení
Snapshotování u Sheepdogu funguje podobně jako u Btrfs. Bloky snapshotovaného VDI zůstávají zachovány a nová data se zapisují do nových bloků.

Problematické mohou být za určitých okolností tyto vlastnosti:

Sheepdog nemá SPOF
Pokud se používá VDI jako blokové zařízení prostřednictvím QEMU, tak může nastat problém v případě, že bude současně namapované na více míst. Tomu by mohl zabránit SPOF[3], který ovšem Sheepdog nemá. U novější verze Sheepdogu však lze VDI uzamknout tak, aby na něj nemohlo být víc připojení než jedno.
Životní cyklus datových objektů
Objekty VDI, lze odstranit teprve tehdy, až jsou odstraněny všechny klony a snapshoty, které na ně také nějakým způsobem odkazují. Je to stejné chování, jako má kupř. Btrfs. K uvolnění místa na úložišti tak nemusí odstranění již nepoužívaných snapshotů stačit.

Sestavení ze zdrojových kódů

Upozornění Sheepdog se stará primárně o distribuci dat. Pokud jde o vzájemnou komunikaci mezi nody, předpokládá, že ji zajistí nějaký komunikační démon[4]. I kdy se při sestavení zdrojového kódu vytvoří i komunikační démon shepherd, jeho vývoj zatím nepřekročil testovací stadium. A domnívám se, že pravděpodobně bude časem z kódu ostraněn, protože věci které měl původně řešit byly přesunuty do administrační utility dog. Sheepdog tak předpokládá, že komunikace nodů už je zajištěna jiným způsobem.

Primárně má podporu pro komunikaci prostřednictvím corosyncu, který používá i Pacemaker. Ovšem může být sestaven i podporou komunikace přes zookeeper, který je naprogramován v javě. Podle autorů Sheepdogu je prý i lepší, pravděpodobně proto, že má srozumitelnější a jednodušší konfiguraci nodů, ale skripty pro sestavení instalačního balíku pro Debian s ním nepočítají.

Důvodem proč si sestavit Sheepdog ze zdrojových kódů je fakt, že v oficiálním repozitáři Debianu je v současné době víc jak rok a půl stará verze 0.8.3 ze srpna 2014, ale vývojáři pro komerční nasazení doporučují verzi 0.9.1 a vyšší.

Zdrojový kód v repozitáři Sheepdogu, má podporu pro sestavení .deb balíku.

Úložiště pro Sheepdog

Výchozí úložiště Sheepdog hledá v adresáři /var/lib/sheepdog/obj. Který po spuštění vytvoří démon sheep v rámci své adresářové struktury. Ovšem tu použije pouze tehdy, pokud se mu při spuštění nepředá cesta jiná, která může vést do přípojného bodu jiného blokového zařízení:

sheep ... /cesta_do_přípojného_bodu

Těch cest může být předáno i více. Novější verze totiž podporuje tzv. multi-device, což dovoluje v případě nutnosti dynamicky zvětšovat kapacitu úložiště, aniž by bylo nutné Sheepdog restartovat. Funguje to podobně jako u Btrfs.

sheep ... /cesta_do_A,/cesta_do_B,/cesta_do_C

Úložiště lze přidávat (a odebírat) i dodatečně přes dog node md

...

Funkcionalita, kterou nabízí multi-device je výhodná především tam, kde to souborový systém úložiště nepodporuje "by design" (jako např. Btrfs, nebo ZFS). Obecně se dá říct, že volba souborového systému pro úložiště pro objektů, jeho vlastnosti, parametry a nastavení, může významně ovlivnit IO výkon souborového systému virtuálního stroje.

Btrfs

Btrfs je COW souborový systém, který z principu významně snižuje pravděpodobnost, že dojde k poškození datového objektu chybou fyzického blokového zařízení.

Na druhou stranu významně zvyšuje režii IO tím, že pro každý modifikovaný objekt dělá jeho kopii. To však může být i výhodné, protože objekty mají nominálně stejnou velikost, ale jejich obsah lze více či méně komprimovat, takže zabírají méně místa. A pokud dojde ke změně jejich obsahu, tak stejně následuje nová komprese a uložení do extentu, kterým se nahradí ten původní.

Tím ztrácí význam parametry:

autodefrag - Extenty s objekty jsou tak malé, že u nik ke fragmentaci prakticky snad ani dojít nemůže

Protože při změně obsahu objektu stejně při založení nového objektu následuje nová komprese

i nocow - protože se v rámci souborového systému pracuje s celými soubory (objekty) a ne s jejich obsahem - jako je tomu např. u blokového přístupu přes GlusterFS

Výhodou Btrfs je, že integruje řadu věcí, které u jednodušších FS pak musí suplovat Sheepdog.

  • Zachovává konzistenci datových objektů, takže znižuje pravděpodobnost, že by se vyskytnul na některém z nodů poškozený objekt, který by bylo nutné obnovit z kopie
  • Podporuje multidevice, takže lze prostor pro datové objekty dynamicky zvětšovat, ba dokonce za běhu přesouvat na zcela jiná bloková zařízení, aniž by bylo nutné restaurovat objekty z jiných nodů

Tím samozřejmě snižuje tím počet nezbytných operací při obnovení připojení nodu, který byl odpojen a po restartu znovu zapojen do Sheepdogu

Ext2

Pokud chceme místo Btrfs použít nějaký jiný FS, tak je asi nejlepší použít ext2, který používá fixní tabulku inodů. Žurnálování, které používá ext3 a ext4 je v tomto případě kontraproduktivní.

Je-li umístění inodu fixní, tak Sheepdog při změně obsahu objektu pouze nahradí obsah příslušného inodu. Významně se tím ovšem snižuje počet IO operací spojených se zápisem.

Při poškození fyzického inodu sice půjdou do kopru i data objektu, ale díky tomu, že má Sheepdog kopie objektu na jiných nodech, je schopen takový poškozený objekt při operaci dog vdi check snadno nahradit.

Nevýhodou ext2 ovšem je, že takový souborový systém nelze dynamicky zvětšovat o další bloková zařízení - to může do určité míry suplovat operace 'dog vdi md, která umožňuje rozložit objekty jednoho VDI zařízení přes více fyzických blokových zařízení.

Spuštění clusteru

VDI

Je u Sheepdogu obecná zkratka pro označení virtuálního disku, nikoliv jeho specifický formát[5]. Je to v podstatě virtuální box s přihrádkami o fixní velikosti, do kterých pak bude Sheepdog umisťovat data, která bude posílat klient.

Vytvoření VDI

Než vytvoříme, nebo naimportujeme první VDI je třeba naformátovat cluster. Při formátování clusteru se nastaví parametry, které se pak budou uplatňovat jako výchozí při založení každého dalšího VDI.

Poznámka Ukázkový příklad, který demonstruje vytvoření nového VDI s názvem disk1 o velikosti 1GB
root@nod1 :~# collie vdi create disk1 1G
root@nod1 :~# collie vdi list
  Name        Id    Size    Used  Shared    Creation time   VDI id  Copies  Tag   Block Size Shift
  disk1        0  1.0 GB  0.0 MB  0.0 MB 2015-12-04 14:07   e8b18f      2                22
Id
Identifikátor VDI
Size
Velikost VDI, která však nemusí být ihned obsazena (prealokována).
Je-li obsahem VDI soubor v přírůstkovém formátu (qcow2 a pod.) vytvořený prostřednictvím 'qemu-img convert, nebude tento údaj odpovídat velikosti virtuálního disku, ale bude průběžně narůstat.
Used
Informuje o tom, kolik prostoru datové objekty VDI aktuálně zabírají.
VDI, u kterého nebyly alokovány datové objekty při vytvoření, nezabírá nic, protože pro ně ještě neexistuje žádný objekt s daty.
Shared
Objem datových objektů, které jsou sdíleny s jiným VDI
Creation time
Čas založení VDI
Block size
Velikost datového objektu VDI Pozor! Není uvedena v MB, ale jako hodnota mocniny dvou bajtů.
Starší verze používaly výhradně objekty o fixní velikosti 4MB. V současné době již VDI může mít objekty větší. Pro VDI běžného virtuálního stroje se mi jeví jako optimální velikost objektu 64MB (26).
Výchozí velikost 22 (4MB) je zároveň i minimální. Méně nelze nastavit. Čím menší je velikost objektu, tím větší je počet souborů se kterými musí Sheepdog v rámci VDI pracovat. A práce se soubory není z hlediska IO levná záležitost. Režie spojená velkým množstvím malých souborů dokáže obzvláště u pomalých SATA řadičů vést k razantní degradaci rychlosti čtení i zápisu.
Maximální velikost objektů kterou lze použít je 31 (2GB). To může být výhodné, pokud se do VDI budou sekvenčně ukládat větší objemy statických dat - např. zálohy.
VDI id
Identifikátor VDI. Až začne Sheepdog do VDI ukládat data, začnou se v datovém úložišti (ve výchozím stavu /var/lib/sheepdog/obj objevovat soubory, které budou mít tento identifikátor v názvu.
../obj/57/00e8b18f00000005
            ^^^^^^       ^

Co obsahuje VDI?

Obsahem VDI jsou data. Jde o distribuované blokové zařízení, takže Sheepdog neřeší jestli to jsou data užitečná, nebo smetí. Z tohoto pohledu vypadá VDI podobně jako logický disk u LVM. Prealokované VDI odpovídá klasickému LV oddílu s vymezeným rozsahem, kdežto VDI přírustkové se podobá Thin LV oddílu vytvořenému v rámci poolu (viz LVM (thin_provisioning)) - ovšem s tím rozdílem, že datové extenty (objekty) nejsou uložené přes lokální bloková zařízení, ale rozházeny mezi nody.

Upozornění Formát VDI pak v této analogii funguje jako souborový systém. Některý si obsazuje vyhrazené extenty (objekty) postupně, jiný si je namapuje jako svoje inody a pak do nich posílá data přímo. Nevhodná kombinace souborového systému úložiště nodů, formátu VDI a vnitřního souborového systému může vést k výrazné degradaci I/O výkonu.

Jak získat informace o VDI

Nejrychlejší způsob, jak zjistit bližší informace o formátu VDI nabízí qemu-img info:

Poznámka
root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk1
image: sheepdog:localhost:8000:test2
file format: qcow2
virtual size: 12G (12884901888 bytes)
disk size: 4.0G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Z ukázkového výpisu lze vyčíst, že disk1 je má nominální velikost 12G. Aktuálně ale zabírá jen 4G. Protože je ve formátu qcow2, je zřejmé že byl vytvořen jako přírůstkový.

Poznámka
root@nod1 :~# collie vdi list
 Name        Id    Size    Used  Shared    Creation time   VDI id  Copies  Tag   Block Size Shift
 disk2        0  4.0 GB  4.0 GB  0.0 MB 2015-12-04 16:07   825dc1      2                31
root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk2
image: sheepdog:localhost:8000:disk2
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 4.0G
root@nod1 :~# find /datastore/obj/ | grep 825dc1
/datastore/obj/meta/80825dc100000000
/datastore/obj/c1/00825dc100000000
/datastore/obj/c1/00825dc100000001

V tomto případě byl disk2 vytvořen jako předem alokované VDI o velikost 4GB v raw formátu, s velikostí bloku 2GB, které skutečně obsadilo pouze dva objekty o velikosti 2GB

Export VDI do souboru

Celý obsah VDI lze exportovat ze Sheepdogu několika způsoby. Asi nejrychlejší je použít přímo dog read. Příkaz je zlehka matoucí, ale zjednodušeně znamená: "Načítej obsah VDI a posílej ho na STDOUT..", který lze přesměrovat do souboru:

Poznámka
root@nod1 :~# collie vdi read disk1 > /backups/soubor.raw
Poznámka Pokud má VDI mít 10G, ale je zabráno pouze 2G, bude mít exportovaný soubor plných 10GB.

Při této operaci se obsah VDI nemění, takže pokud je obsahem VDI kupř. virtuální disk v komprimovaném qcow2 formátu, lze ho rovnou použít přes

.. -drive file=file:/disk1_exportovany_z_vdi,..,format=qcow2 ..

Další možnost, jak dostat obsah VDI do souboru je použít qemu-img convert. Není to sice tak rychlé, ale umožňuje to konverzi VDI do jiného formátu s využitím dalších konfiguračního parametrů příslušného formátu virtuálního disku.

Poznámka
root@nod1 :~# qemu-img convert -f qcow2 -O file -o preallocation=full,nocow=on sheepdog:localhost:8000:disk1 /disk1_exportovany_z_vdi

Inkrementální zálohy

Vytvoření inkrementální zálohy

Snapshot první Snapshot druhý Záloha..

Poznámka
root@nod1 :~# collie vdi backup test -F snap1 -s snap2 /backups/soubor_diff

Obnova VDI z inkrementální zálohy

Poznámka
root@nod1 :~# collie vdi restore test -s snap1 /tmp/backup
  restoring /tmp/backup... done

Poznámka: Při importu inkrementální zálohy VDI musí pochopitelně existovat snapshot vůči kterému byla záloha učiněna.

Kontrola pomocí čtení počátečního obsahu testovacího image...
Poznámka
root@nod1 :~# collie vdi read test 0 512 -s 3

Import VDI ze souboru

Import již existujícího virtuálního disku ve formě souboru na lokálním FS lze provést podobně jako export. Ovšem s tím rozdílem, že se použije dog write ("Čti data ze STDIN a zapisuj je do VDI souboru..")

Poznámka
root@nod1 :~# collie vdi write disk1 < /backups/soubor.raw
Upozornění  
  • Pomocí operace write lze importovat obsah pouze do již existujícího VDI.
  • Importované VDI zabere vždy VÍCE místa než původní soubor a to z toho důvodu, že datové bloky ze který je sestaveno VDI obsahují data spojená s jejich mapováním

Pokud VDI neexistuje, a nevíme kolik bude virtuální disk vyžadovat místa, můžeme pro import opět využít utilitu qemu-img convert

Poznámka
root@nod1 :~# qemu-img convert -f file -O qcow2 -o redundancy=2:1 ./disk_ukladany_do_vdi sheepdog:localhost:8000:disk
Poznámka I když lze v rámci VDI používat přírůstkové formáty, jako je qcow2, qed a jiné. Je z hlediska výkonu IO lepší budou-li datové bloky předem alokovány.

Doporučuji to také z toho důvodu, že pak nebude mít u takového svazku Sheepdog problém s kontrolou integrity VDI.

http://www.sheepdog-project.org/doc/vdi_read_and_write.html

Verifikace vdi

Při kontrole integrity VDI se ověří zda-li jsou dostupné datové bloky v pořádku a na svém místě.

Poznámka
root@nod1 :~# collie vdi check disk1
Upozornění Nespouštějte verifikaci vdi zařízení, pokud ho používá nějaký virtuál. U novější verze sheepdogu už to nelze, protože již používá zamykání. Nicméně se to chová nějak divně, protože při každé opakované kontrole znovu a znovu opravuje nějaké nekonzistentní bloky.

NOTES: we used ‘dog node kill’ to remove the node from the cluster, but you my simply shut it down or remove the ethernet cable, manually kill the sheep process etc. If it was not your intention to remove the node form the cluster (say you moved the ethernet cable), try to insert it back as soon as possible and re-run sheep daemon. This will stop rebuilding data on the other nodes and will fast restore the last changed data on the node.

IO výkon VDI

IO výkon VDI je závislý na mnoha faktorech. Především na výkonu řadiče a vlastnostech použitých blokových zařízení. Čím pomalejší řadiče a disky na nodech, tím horší IO výkon VDI zařízení.

Ve výchozím stavu totiž Sheepdog jede v SYNC režimu, který nepoužívá žádné kešování. Každá IO operace, která nepoužívá kešování VFS přichází na řadu teprve v okamžiku, až jádro dostane signál od blokového zařízení, že výsledek předchozí operace byl úspěšně uložen.

V případě virtuálu, který používá VDI přes Sheepdog je to teprve tehdy, až přijde informace o uložení všech kopií objektu na fyzická zařízení nodů. Tato operace ale může být u nodů s pomalými řadiči a disky velice zdlouhavá. Proto nabízí Sheepdog několik možností jak výkon VDI zařízení významně vylepšit.

Využití kešování VFS nodů

Nejjednodušším krokem pro zlepšení IO výkonu VDI je - spuštět na nodech démona sheep s parametrem -n. Ten pak bude vracet SYNC, ne až budou data skutečně zapsána na blokové zařízení, ale již v okamžiku kdy je předá ke zpracování VFS nodu. Hrozí zde ovšem potenciální riziko, že pokud je VFS nestihne uložit, a dojde k výpadku nodu, budou ztraceny!

Ve většině případů však nejde o zásadní problém. Ten by mohl nastat pouze tam, kde se provozují virtuální stroje co ukládají průběžně rychle velké množství důležitých dat - jako mohou být stroje, které zpracovávají např. finanční operace.

sheep -n ...
Poznámka I ve výchozím stavu používá Sheepdog kešování - před uložení si ukládá objekty do paměti. To lze pro změnu vypnout parametrem -D

Objektová keš

Další možností jak zlepšit IO výkon je objektová keš. Démon sheep pak nebude na nodu, přes které je VDI připojeno, zapisovat objekty rovnou na distribuované úložiště, ale blokové zařízení, které má rychlé IO operace - typicky SSD disk. Virtuální stroj, který s VDI pracuje, tak nemusí čekat až mu přijde SYNC z ostatních nodů. Distribuce objektů a jejich uložení na ostatní nody se pak realizuje s určitým zpožděním.

Má to ale jeden velký háček, pokud se má toto VDI používat přes více nodů - což je ovšem typické použití distribuovaného VDI v clusterovém prostředí. Objekty, které se nestihly ještě rozdistribuovat, jsou totiž dostupné pouze na tom nodu, přes který bylo VDI původně připojené.

sheep -w size=20000,directio,dir=/dir ...
size
Objem keše
directio
Při uvedení tohoto parametru sheep nezapisuje data do RAM, ale rovnou je sype na disk. Je to doporučená volba při použití SSD
dir
Cesta do přípojného bodu blokového zařízení, které má fungovat jako objektová keš

Stav objektové keše, lze zjišťovat (a řídit) přes dog.

Upozornění Pokud dojde k připojení VDI, které používalo objektovou keš z jiného nodu, aniž by předtím byl na ně aplikován příkaz dog vdi cache flush, může dojík k nevratnému poškození VDI!

Žurnál

Lepším řešením je využít žurnálování. Při této operaci nody nezapisují data rovnou do VDI objektů, ani nespoléhají na VFS kde běží - ale zapisují data určená pro zápis do VDI do nově vytvořeného žurnálovací souboru (/store_dir/journal/[epoch]/[vdi_object_id]), který se pak po jejich přepsání dat do VDI zruší.

Zvýšení IO výkonu při zápisu žurnálováním plyne z toho, že zápis do objektů neprobíhá náhodně (cik, cak), ale sekvenčně (postupně).

Kromě toho Sheepdog umožňuje udržovat žurnálovací soubory mimo souborový systém úložiště VDI objektů, což může být podobně jako u objektové keše kupř. SSD disk. Pokud dojde k selhání nodu, dřív než se data stihnou přepsat do VDI objektu na pomalejším úložišti, tak se nic neděje, protože je lze přepsat dodatečně a na rozdíl od objektové keše žurnál není vázán na nod, ze kterého bylo VDI připojené.

Žurnálování lze aktivovat prostřednictvím parametru démona sheep a může mít různou podobu - v každém případě však musí být uvedena velikost žurnálovacího souboru

$ sheep -j size=256M ...

Pokud nebyla uvedena cesta do úložiště žurnálů, tak se budou žurnály VDI objektů ukládat do stejného úložiště jako datové objekty. Žurnálování ovšem ovlivňuje výkon při IO operacích, proto je výhodné - je-li to možné - ho ukládat na blokové zařízení s lepším IO výkonem:

$ sheep -j dir=/dir,size=256M ...

Přičemž parametr dir= neudává cestu k blokovému zařízení, ale přípojnému bodu, kam je toto rychlé blokové zařízení připojeno. Nemusí to tedy nutně jedno blokové zařízení, ale klidně i SW RAID z mnoha rychlých SSD disků.

Poznámka: Po restartu nodu se sheep v prvé řadě pokouší zapsat data, která zůstala uložená v žurnálu. To ovšem není nezbytně nutné, proto můžeme použít parametr skip, který tomu zabrání.

$ sheep -j dir=/dir,size=256M,skip ...



  1. 1,0 1,1 Viz informace v závěru prezentace z června 2015 http://events.linuxfoundation.jp/sites/events/files/slides/COJ2015_Sheepdog_20150604.pdf
  2. http://www.abclinuxu.cz/blog/kenyho_stesky/2011/11/sheepdog-hrajeme-si-v-hampejzu
  3. SPOF (Single point of failure) zabezpečení zajišťuje, že se na jedno blokové zařízení může připojit právě jen jeden ověřený klient, ke kterému patří. Podporu pro SPOF mají VDI, pokud jsou exportované jako iSCSI zažízení přes tgtd
  4. Komunikační démon - nezajišťuje vlastní výměnu dat mezi nody. O to se stará démon sheep. Jeho prostřednictvím démon sheep pouze zjišťuje, které z nich v rámci jeho lokality aktuálně žijí.
  5. O formátech virtuálních disků - mimo jiné i vdi - se píše na stránce QEMU_(bloková_zařízení)

Odkazy

https://github.com/collie/sheepdog/wiki - wiki, která je součástí repozitáře se zdrojovými kódy
http://www.osrg.net/sheepdog/ - stránky projektu na webu Nippon Telegraph and Telephone Corporation
http://www.sheepdog-project.org/doc/index.html - Administrátorská příručka pro Sheepdog verze 0.8.0; autorem je Valerio Pachera
http://www.admin-magazine.com/Archive/2014/23/Distributed-storage-with-Sheepdog - Článek Udo Seidela o nasazení Sheepdogu, publikovaný ve 23. čísle magazínu Admin z října 2014