Sheepdog

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í.

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 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, 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, 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.

Komunikační démon

Sheepdog je ve srovnání s řešením jako Ceph nebo GlusterFS směšně minimalistický. Je to dáno tím, že se nesnaží řešit všechno sám a v maximální míře využívá toho co mu nabízí systém ve kterém běží.

Na oplátku zase poskytuje blokové zařízení, které lze používat úplně stejně jako fyzický disk, softwarový raid, atp.

Sám se stará pouze o distribuci datových objektů mezi nody, na kterých běží.

Při tom však pracuje s informacemi, které mu dodává komunikační démon - klíčová komponenta, bez které Sheepdog fungovat nebude.

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é nody v rámci jeho lokality aktuálně žijí.

corosync

Primárně Sheepdog předpokládá, že nody budou vzájemně komunikovat prostřednictvím corosyncu. Ten zvládá max. do 64 nodů - i když teoreticky by jich měl být schopen obsloužit víc. Jeho použití je optimální u menších clusterů do 16 nodů.

Výhodné je, že corosync využívá také Pacemaker, takže není nutné instalovat nic dalšího.

Instalace corosyncu na Debianu

Corosync je součástí distribučních repozitářů a jeho instalace je jednoduchá:

$ apt-get install corosync libcorosync-common4

zookeeper

Vývojáři Sheepdogu pro větší clustery doporučují zookeeper. Ten je naprogramován v javě - to je ta piha na kráse. Ale podle jeho vývojářů byl s jeho využitím sestaveno a otestováno testovací úložiště Sheepdogu o 1000 nodech.

Instalace zookeeperu na Debianu

$ apt-get install zookeeper zookeeperd

Spuštění démona..

$ /usr/share/zookeeper/bin/zkServer.sh start

Výchozím portem na kterém zookeeper komunikuje je port číslo 2181

Spuštění sheepdogu s podporou zookeeperu:

$ sheep -c zookeeper:IP1:PORT1,IP2:PORT2,IP3:PORT3 ...other...option...

Bonusem zookeeperu tedy je, že má i srozumitelnější a jednodušší konfiguraci nodů pro Sheepdog, ovšem problém spočívá v tom, že s ním skripty pro sestavení instalačního balíku u Debianu nepočítají.

Sheepdog s podporou pro zookeeper je tedy nutné sestavit ze zdrojových kódů. I když nemohu vyloučit, že v současné době již může být situace jiná.

Konfigurace démona sheep

Nod se stává součástí Sheepdogu v okamžiku, kdy je na něm spuštěn správce objektů - démon sheep. Ten se vždy spouští ve dvou instancích:

1. První instance běží jako síťová brána (Gateway), která přijímá I/O požadavky od klientů (např. ovladače blokového zařízení v QEMU), vypočítává cílové nody a mezi nimi předává požadavky k dalšímu zpracování. Takže má otevřeno velké množství síťových připojení.
2. Druhá pracuje jako lokální správce uložených objektů (Object manager)

Konfigurační parametry démona sheep lze předat na příkazové řádce při jeho spouštění. Pokud žádné nejsou, použije výchozí hodnoty - na což je třeba dát pozor:

Číslo portu

Není-li řečeno jinak, spouští se démon sheep na portu 7000

Cesta do úložiště

Není-li řečeno jinak, používá sheep adresář /var/lib/sheepdog a VDI objekty jsou ukládány v rámci jeho podadresáře obj.

Teoreticky nic nebrání tomu, aby na jednom nodu běželo více instancí démona sheep - základní podmínkou je, aby každá z nich používala své číslo portu a vlastní úložiště. Ovšem prakticky rozhoduje IP adresa nodu. Každá spuštěná instance démona sheep - byť spuštěná na jiném portu, se automaticky připojí k již existujícímu clusteru! Důležitá informace je, že číslo portu je součástí konfigurace VDI kontejneru. To je nutné vědět, pokud chcete změnit konfiguraci démona sheep, aby běžel na jiném portu, u již existujícího clusteru. Protože pokud by došlo ke spuštění instance démona sheep s jiným číslem portu, ale stejnou cestou do úložiště objektů - mohlo by dojít ke ztrátě informací o existujících VDI kontejnerech.

Démon sheep jako brána

Na strojích, které nemají k dispozici datový prostor k uložení VDI objektů, lze démona sheep spustit čistě v režimu brány, s parametrem -G.

V takovém případě nebude při distribuci VDI objektů vůbec počítat s lokálním úložištěm a data se budou rovnou distribuovat na ostatní nody.

Démon sheep jako správce objektů

Druhá spuštěná instance, která běží jako lokální správce objektů přijímá I/O požadavky od instance, která běží jako brána a realizuje r/w operace do lokálního úložiště objektů (Object storage)

Úložiště objektů

Výchozím úložištěm VDI objektů je u Sheepdogu adresář /var/lib/sheepdog/obj, který si po svém spuštění založí démon sheep jako součást své adresářové struktury v rámci výchozí cesty k úložišti.

Pokud chceme mít VDI objekty uloženy jinde, je třeba předat při spuštění cestu jinou, která může vést kupř. do přípojného bodu jiného blokového zařízení:

sheep ... /cesta_do_přípojného_bodu

Těchto cest může být předáno i více. Novější verze Sheepdogu totiž podporuje tzv. multi-device - technologii, která dovoluje v případě nutnosti dynamicky zvětšovat kapacitu úložiště, aniž by bylo nutné Sheepdog restartovat. Rozšíření datové kapacity pak funguje podobně jako u Btrfs.

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

Další úložiště lze dodatečně přidávat (ale i odebírat) 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.

Technologie multi-device vyžaduje podporu rozšířených atributů na straně souborového systému, což u moderních souborových systémů, jako jen např. btrfs nebo ext4 problém není. Ale některé starší souborové systémy, jako např. reiserfs, nebo ext2) jejich podporu nemají. Pokud tedy chceme použít pro ukládání objektů souborový systém, který podporu rozšířených atributů nemá, musíme Sheepdog zkompilovat bez podpory multi-device.

Typ úložiště - plain versus tree

Při formátování clusteru se nastavuje, mimo jiné, také typ úložiště (backend storage). Nastavit lze buď typ plain, nebo tree. U typu plain pak bude vypadat adresářová struktura takto:

|
|- obj
|    |- <id epochy>
|    |          |-<identifikátor objektu>
|    |          |-<identifikátor objektu>
|    |          |-<identifikátor objektu>
|    |          |- ...
|    |- <id další epochy>
|    | ...
|- config [identifikátor]
|- epoch
|    |- <epocha file>
|    |- <epocha file>
|    |- ...
|- journal
\- sheep.log [log]

Všechny VDI objekty v rámci adresáře obj se pak budou sypat do podadresáře, jehož jméno bude vycházet z identifikátoru aktuální epochy. Tzn. že pro každou epochu se budou ukládat příslušné VDI objekty zvlášť. V rámci jedné epochy se ale může v rámci jednoho adresáře objevit velký počet VDI objektů, který pak bude zpomalovat přístup k souborům. Proto je možné zvolit druhou variantu, kterou je úložiště typu tree:

|- obj
|    |- aa
|    |   |-<identifikátor objektu>
|    |   |-<identifikátor objektu>
|    |   |-<identifikátor objektu>
|    |   |- ...
|    |- ab
|    | ...
|    |- meta
|    |    |- <metadatový soubor>
|    |    |- ...
|    |- 0a
|    | ...
|- config [identifikátor]
|- epoch
|    |- <epocha file>
|    |- <epocha file>
|    |- ...
\- sheep.log [log]

U tohoto typu úložiště si démon sheep ihned po spuštění vytvoří v adresáři obj sadu 256 podadresářů s názvy 0a, ..., 99 do kterých pak rozhazuje objekty na základě posledních dvou znaků VDI id, které je unikátní nejenom pro každý VDI kontejner, ale také jeho snapshoty či klony.

Jména VDI objektů

Až začne Sheepdog do VDI kontejneru ukládat data, začnou se v datovém úložišti obj objevovat datové soubory, které budou mít své jméno složené z několika prvků:

../obj/8f/00e8b18f00000005
          ^^

První dva znaky odlišují typ objektu. Datové objekty začínají 00... a metadatové (které ale mohou být uloženy v jiném adresáři) 80...

../obj/8f/00e8b18f00000005
            ^^^^^^        

Pak následuje identifikátor VDI. Ten je unikátní nejenom pro každý kontejner, ale také jeho snapshot či klon.

../obj/8f/00e8b18f00000005
       ^^       ^^

Poslední dvě čísla identifikátoru VDI určují - v případě úložiště typu tree - do jakého podadresáře objekt patří.

../obj/8f/00e8b18f00000005
                  ^^^^^^^^

A za identifikátorem VDI kontejneru následuje v hexadecimálním tvaru pořadové číslo objektu v rámci VDI kontejneru.

Epocha

Do podadresáře epoch se ukládají binární seznamy objektů, které náleží do příslušné epochy. Číslo epochy se navyšuje při každé změně clusteru - když se přidá, nebo naopak odstraní nějaký nod. Každá taková změna odstartuje recovery proces, během kterého se na nodech překontroluje aktuální stav lokálních objektů, po kterém následuje navýšení epochy.

Jak optimálně zvolit úložiště VDI objektů

Dostupná kapacita úložiště vychází volné datové kapacity nodu. Prostor, jaký sheep obsadí vždy vychází z toho, kolik místa má v rámci blokového zařízení kam se ukládají VDI objekty k dispozici.

Velikost VDI kontejneru je pouze virtuální údaj, který nijak nesouvisí s tím kolik místa obsadí vytvořené VDI objekty ve skutečnosti. Podstatné je vědět, jak Sheepdog zachází s datovým prostorem v rámci clusteru:

Sheepdog se vždy snaží ukládat data rovnoměrně mezi všechny stroje příslušné epochy.

To znamená, že pokud některý z nodů vypadne, změní se epocha a Sheepdog okamžitě začně v rámci recovery procesu rovnoměrně vytvářet chybějící VDI objekty na zbylých nodech, tak aby tuto ztrátu nahradil.

Obdobná situace nastane, pokud naopak nový nod přibude. Sheepdog začne - opět v rámci recovery procesu - rovnoměrně přesouvat VDI objekty z ostatních nodů do jeho úložiště, tak aby procentuální zaplnění datového prostoru nodů bylo pokud možno vyrovnané. Následujícím příkazem můžete získat globální přehled o tom, jak je aktuálně obsazený datový prostor na vašich nodech:

nod1 ~ # collie node md info -A
Id      Size    Used    Avail   Use%    Path
Node 0:
 0      1.1 TB  391 GB  720 GB   35%    /local/sheepdog-data/obj
Node 1:
 0      702 GB  394 GB  307 GB   56%    /local/sheepdog-data/obj
Node 2:
 0      794 GB  430 GB  364 GB   54%    /local/sheepdog-data/obj
Node 3:
 0      1.6 TB  376 GB  1.2 TB   22%    /local/sheepdog-data/obj
Node 4:
 0      1.2 TB  401 GB  838 GB   32%    /local/sheepdog-data/obj
Node 5:
 0      1.5 TB  370 GB  1.1 TB   24%    /local/sheepdog-data/obj
Node 6:
 0      1.6 TB  388 GB  1.2 TB   23%    /local/sheepdog-data/obj

I/O výkon

Je třeba hned zkraje říct, že Sheepdog funguje jinak než Ceph a má jinak nastavené priority.

Pro Ceph je při rozkládání datových objektů rozhodující "váha" OSD zařízení, kde hraje roli jak výkon blokového zařízení, tak konektivita na hostitele a rychlost odezvy.

Jestli pracuje s něčím podobným také Sheepdogu, nevím. Snad. Pro něj jsou na prvním místě data. Výkon z hlediska I/O operací je druhotný. Pochopitelně s větším množstvím výkonných nodů se jeho I/O výkon může zlepšovat, ale vždy závisí na konkrétní stuaci.

Přidal jsem do Sheepdogu nový nod, s daty uloženými na rotačním 2TB SATA II disku. Maximální rychlost zápisu na tento disk je kolem 80M/s. Ve skutečnosti ale značně kolísá, protože SATA disky neumí číst a zapisovat současně. Nejprve se průměrná rychlost zápisu dat z VDI na tento disk pohybovala kolem 20~30M/s, protože se kromě dat z VDI na něj replikovalo také 392G dat objektů VDI kontejneru v rámci recovery procesu. To trvalo 6,5 hodiny. Pak už kolísala rychlost zápisu mezi 40~55M/s. Je zcela evidentní, že v tomto případě byla rychlost zápisu limitována I/O výkonem lokálního blokového zařízení.

V případě Sheepdogu platí následující: "Čím více VDI objektů bude na rychlých nodech s rychlým připojením. Tím bude vyšší I/O výkon."

Protože přesuny VDI objektů probíhají na pozadí, znamená v jeho případě "smrt rychlého nodu" zpomalení replikace datových objektů - což se teprve při práci většími objemy dat projeví jako pokles I/O výkonu VDI kontejneru.

Obsazený prostor

Při rozmísťování datových objektů je pro démona sheep rozhodující objem volného místa. Mechanismus se zdá být jednoduchý. Démon sheep přes který probíhá datová komunikace s VDI kontejnerem čas od času zjistí, jaký je poměr volného a obsazeného místa nodů, který setřídí. Další data pak distribuuje na nody s nejnižším procentuálním poměrem využití.

Pokud mezi nimi převažují nody, na které se rychle zapisuje, bude rychlý také I/O zápis do VDI kontejneru. Protože čím rychleji se I/O operace VDI kontejneru vyřídí, tím dříve může démon sheep přistoupit na další operaci.

Důležitý je fakt, že u Sheepdogu nehrozí situace, kdy by došlo k úplnému zaplácnutí místa na některém z nodů. V případě, že se poměr využití na některém nodu výrazně zhorší, totiž začne démon sheep přesouvat jeho datové objekty jinam.

Sheepdog funguje podobně jako Btrfs - zabírá jen skutečně zabrané místo. Takže lze vytvořit VDI kontejner o virtuální velikosti 1TB, který ve skutečnosti zabere jen tolik, kolik je v něm uložených dat. Z tohoto úhlu pohledu je žádoucí ve VDI kontejnerech používat takové formáty virtuálních disků a souborových systémů, které po sobě umí dobře uklízet.

Spuštění clusteru

Zatím co zastavení všech nodů lze provést najednou, nody najednou spustit nelze!!! Nody by měly být spouštěny postupně. Počínaje nodem, který byl v seznamu nodů uveden jako první.

VDI

Je u Sheepdogu obecná zkratka pro označení virtuálního disku, nikoliv jeho specifický formát. 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.

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.

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.

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:

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ý.

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:

root@nod1 :~# collie vdi read disk1 > /backups/soubor.raw

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.

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..

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

Obnova VDI z inkrementální zálohy

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...

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..")

root@nod1 :~# collie vdi write disk1 < /backups/soubor.raw

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

root@nod1 :~# qemu-img convert -f file -O qcow2 -o redundancy=2:1 ./disk_ukladany_do_vdi sheepdog:localhost:8000:disk

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ě.

root@nod1 :~# collie vdi check disk1

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 ...

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.

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 ...

---

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