🥇Zkušenosti s provozem CEPH

Když dat je víc, než se vejde na jeden disk, je čas začít přemýšlet o RAID. V dětství jsem často slýchával od starších: „Jednou RAID zmizí do historie, objektová úložiště zaplní svět, a ty ani nebudeš vědět, co je CEPH,“ – a proto se prvním krokem v samostatném životě stalo vytvoření vlastního clusteru. Cílem experimentu bylo seznámit se s vnitřními mechanismy CEPH a pochopit jeho využití. Jak je opodstatněná implementace CEPH ve středním podnikání a v malém? Po několika letech provozu a několika neohrabatelných ztrátách dat se objevilo pochopení nuancí, že ne všechno je tak jednoznačné. Vlastnosti CEPH přinášejí překážky jeho širokému rozšíření a kvůli nim experimenty uvízly na mrtvém bodě. Níže je uveden popis všech absolvovaných kroků, dosažených výsledků a provedených závěrů. Budu vděčný, pokud znající lidé sdílí své zkušenosti a objasní některé momenty.

Poznámka: komentátoři poukázali na závažné chyby v některých předpokladech, které vyžadují přehodnocení celého článku.

Strategie CEPH

Cluster CEPH spojuje libovolný počet K disků libovolné velikosti a ukládá na ně data, přičemž každý kus (4 MB podle defaultu) duplikuje Nkrát.

Zvažme nejjednodušší případ se dvěma stejnými disky. Z nich lze sestavit buď RAID 1, nebo klastr s N=2 — výsledek bude stejný. Pokud jsou disky tři a různých velikostí, pak je snadné sestavit klastr s N=2: část dat bude na discích 1 a 2, část — na 1 a 3, a část — na 2 a 3, zatímco RAID — ne (takový RAID je sice možné vytvořit, ale bylo by to zkreslením). Pokud je disků ještě více, pak je možné vytvořit RAID 5, u CEPH existuje analog — erasure_code, který odporuje dřívějším konceptům vývojářů, a proto se nezvažuje. RAID 5 předpokládá, že je k dispozici malé množství disků, a všechny jsou v dobrém stavu. Při selhání jednoho z nich, ostatní by měly vydržet, dokud nebude disk vyměněn a data na něj obnovena. CEPH však, při N>=3, podporuje používání starých disků, zejména pokud se uchovává několik kvalitních disků pro uchování jedné kopie dat, zatímco zbývající dvě nebo tři kopie jsou uchovávány na velkém množství starých disků, pak bude informace v bezpečí, protože dokud jsou nové disky v provozu — nejsou žádné problémy, a pokud některý z nich selže, je simultánní selhání tří disků se životností delší než pět let, ideálně z různých serverů — situace vysoce nepravděpodobná.

V distribuci kopií je určité specifikum. Výchozí nastavení předpokládá, že data jsou rozdělena do většího počtu (~po 100 na disk) skupin distribuce PG, z nichž každá je duplikována na určitých discích. Řekněme, že K=6, N=2, pak při selhání dvou libovolných disků nezbytně dojde ke ztrátě dat, protože podle teorie pravděpodobnosti se najde alespoň jedna PG, která se bude nacházet právě na těchto dvou discích. Ztráta jedné skupiny činí všechny údaje v poolu nedostupnými. Pokud však disky rozdělíme na tři páry a povolíme ukládat data pouze na discích v rámci jednoho páru, pak je taková distribuce také odolná proti selhání libovolného disku, ale při selhání dvou disků je pravděpodobnost ztráty dat ne 100 %, ale pouze 3/15, a dokonce při selhání tří disků – pouze 12/20. Odtud plyne, že entropy v distribuci dat nepřispívá k odolnosti vůči selhání. Také si povšimneme, že pro souborový server volná operační paměť značně zvyšuje rychlost odezvy. Čím více paměti je v každém uzlu a čím více paměti ve všech uzlech – tím rychleji to bude. To je nepochybně výhoda clusteru před samostatným serverem a tím více, když se porovná s hardwarovým NAS, do kterého se instaluje velmi malé množství paměti.

Odtud vyplývá, že CEPH je dobrý způsob, jak s minimálními investicemi z zastaralého vybavení vytvořit spolehlivý systém ukládání dat desítek TB s možností škálování (zde jsou samozřejmě vyžadovány náklady, ale malé ve srovnání s komerčními SÉB).

Implementace clusteru

Pro experiment vezmeme vyřazený počítač Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Čtyři disky po 2 TB uspořádáme do podoby RAID10, po úspěšném testu přidáme druhý uzel a dalších tolik disků.

Instalujeme Linux. Distribuce by měla mít možnost přizpůsobení a stabilitu. Pro tyto požadavky jsou vhodné Debian a Suse. Suse má flexibilnější instalátor, který umožňuje vypnout jakýkoli balíček; bohužel jsem nebyl schopen zjistit, které lze odstranit bez újmy na systému. Instalujeme Debian přes debootstrap buster. Možnost min-base instaluje nefunkční systém, ve kterém chybí ovladače. Rozdíl v velikosti oproti plné verzi není tak velký, abychom se tím zatěžovali. Protože práce probíhá na fyzickém stroji, chtělo by to dělat snapshoty, jako na virtuálních strojích. Tuto možnost poskytuje buď LVM, nebo btrfs (nebo xfs, nebo zfs — rozdíl není velký). Snapshoty nejsou silnou stránkou LVM. Instalujeme btrfs. A zavaděč — do MBR. Není smysl zaplňovat disk 50 MB oddílem s FAT, když ho můžeme vměstnat do 1 MB oblasti tabulky oddílů a celé místo vyhradit pro systém. Zabralo to na disku 700 MB. Kolik zabírá základní instalace SUSE — nepamatuji si, zdá se, že kolem 1.1 nebo 1.4 GB.

Instalujeme CEPH. Ignorujeme verzi 12 v repozitáři debian a připojujeme přímo ze stránek 15.2.3. Řídíme se pokyny z části „instalujeme CEPH ručně“ s následujícími upřesněními:

Před připojením repozitáře je nutné nainstalovat gnupg wget ca-certificates
Po připojení repozitáře, ale před instalací clusteru byla vynecháno nainstalování balíčků: apt -y —no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr

V okamžiku instalace CEPH se z nepochopitelných důvodů pokusí nainstalovat lvm2. V zásadě to nevadí, ale instalace končí chybou, takže CEPH se také nenainstaluje.

Pomohl tento patch:

cat <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF

Přehled clusteru

ceph-osd — zodpovídá za ukládání dat na disku. Pro každý disk se spouští síťová služba, která přijímá a vykonává požadavky na čtení nebo zápis do objektů. Na disku se vytvářejí dvě oddíly. Jeden z nich obsahuje informace o rámci, číslo disku a také klíče od rámce. Tyto informace o objemu 1KB se jednou vytvářejí při přidání disku a pak se nezmění. Druhý oddíl nemá žádný souborový systém a ukládají se zde binární data CEPH. Automatická instalace v předchozích verzích vytvářela xfs oddíl o velikosti 100MB pro administrativní informace. Disk jsem převedl na MBR a vyčlenil pouze 16MB — služba si nestěžuje. Myslím, že xfs by mohlo být bez problémů nahrazeno ext. Tento oddíl se připojuje do /var/lib/…, kde služba čte informace o OSD a také nachází odkaz na blokové zařízení, kde se ukládají binární data. Teoreticky je možné umístit pomocné soubory okamžitě do /var/lib/…, a celý disk vyčlenit pouze pro data. Při vytváření OSD pomocí ceph-deploy se automaticky vytváří pravidlo pro připojení oddílu do /var/lib/…, a také se nastavují práva uživateli ceph ke čtení potřebného blokového zařízení. Při ruční instalaci to musíte udělat sami, v dokumentaci se o tom nezmiňuje. Také je žádoucí nastavit parametr osd memory target, aby bylo dostatek fyzické paměti.

ceph-mds. Na nízké úrovni je CEPH — objektové úložiště. Možnost blokového ukládání se omezuje na ukládání každého bloku 4MB jako objektu. Na stejném principu funguje i souborové úložiště. Vytváří se dva bazény: jeden pro metadata, druhý — pro data. Ty se spojují do souborového systému. V tuto chvíli se vytváří jakýsi záznam, proto pokud odstraníte souborový systém, ale oba bazény si necháte, nebude možné jej obnovit. Existuje procedura pro extrakci souborů po blocích, netestoval jsem. Zároveň za přístup k souborovému systému zodpovídá služba ceph-mds. Pro každý souborový systém je nezbytný samostatný exemplář služby. Existuje možnost „index“, která umožňuje vytvořit podobu několika souborových systémů v jednom — také netestováno.

ceph-mon — tato služba ukládá mapu clusteru. Obsahuje informace o všech OSD, algoritmu rozložení PG v OSD a, co je nejdůležitější, informace o všech objektech (detaily tohoto mechanismu jsou mi nejasné: existuje katalog /var/lib/ceph/mon/.../store.db, ve kterém je velký soubor — 26MB, a v clusteru je 105K objektů, což vychází na něco málo přes 256 bytů na objekt; myslím, že monitor uchovává seznam všech objektů a PG, ve kterých se nacházejí). Poškození tohoto katalogu vede ke ztrátě všech dat v clusteru. Odtud vyplývá závěr, že CRUSH ukazuje, jak jsou PG rozloženy mezi OSD, a jak jsou objekty rozloženy mezi PG — jsou centralizovaně uloženy v databázi, ať už se tomu vývojáři vyhýbají. V důsledku toho, za prvé, nemůžeme nainstalovat systém na flashdisk v režimu RO, protože se do databáze neustále zapisuje, potřebujeme další disk pro toto (nepravděpodobně více než 1 GB), za druhé, je nutné mít v reálném čase kopii této databáze. Pokud je více monitorů, zajišťuje se odolnost proti poruchám automaticky, ale v našem případě je monitor jeden, maximálně dva. Existuje teoretický postup pro obnovu monitoru na základě dat OSD, třikrát jsem ho použil z různých důvodů, a třikrát žádné chybové zprávy ani data. Bohužel, tento mechanismus nefunguje. Buď využíváme miniaturní oddíl na OSD a vytváříme RAID pro ukládání databáze, což pravděpodobně velmi negativně ovlivní výkon, nebo si rezervujeme alespoň dvě spolehlivé fyzické nosiče, ideálně USB, abychom nezabírali porty.

rados-gw — exportuje objektové úložiště prostřednictvím protokolu S3 a podobně. Vytváří množství bazénů, k čemuž, upřímně, netuším proč. Příliš jsem neexperimentoval.

ceph-mgr — při instalaci této služby se spouští několik modulů. Jeden z nich je nezakázatelný autoscale. Ten se snaží udržovat správný počet PG/OSD. Pokud chcete ručně řídit poměr, můžete zakázat škálování pro každý bazén, ale v takovém případě modul selže s dělením nulou a stav clusteru se stává ERROR. Modul je napsán v Pythonu, a pokud v něm zakomentujete potřebný řádek, dojde k jeho deaktivaci. Detaily si raději nepamatuji.

Seznam použitých zdrojů:

Instalace CEPH
Obnova při úplném selhání monitoru

Výpisy skriptů:

Instalace systému pomocí debootstrap

blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/

chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d '"' -f 2`
cat < /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install

Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF

exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

Vytvoření clusteru

apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon

echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat < /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
#osd memory target = 2147483648
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF

ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status

# dashboard

apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1

Přidání OSD (část)

apt install ceph-osd

osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02 block
ceph-osd -i $osdnum --mkfs
#chown ceph:ceph /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnum

Shrnutí

Hlavní marketingovou výhodou CEPH je CRUSH – algoritmus pro výpočet umístění dat. Monitory tento algoritmus sdílejí s klienty, kteří pak přímo žádají o potřebný uzel a potřebný OSD. CRUSH zajišťuje absenci centralizace. Představuje si jako malý soubor, který si můžete klidně vytisknout a pověsit na zeď. Praxe ukázala, že CRUSH není vyčerpávající mapou. Pokud jsou monitory zničeny a znovu vytvořeny, přičemž všechny OSD a CRUSH zůstávají, není to dostatečné pro obnovení clusteru. Odtud vyplývá, že na každém monitoru jsou uchovávány určité metadata o celém clusteru. Malý objem těchto metadat neomezuje velikost clusteru, ale vyžaduje, aby byla zachována, což vylučuje úsporu na disku pomocí instalace systému na flashku a vylučuje clustery s méně než třemi uzly. Agresivní politika vývojáře vůči volitelným funkcím. Daleko k minimalismu. Dokumentace na úrovni: „za to, co je, – už dík, ale velmi, velmi skromné“. Možnost interakce se službami na nízké úrovni je plánována, ale dokumentace tuto tematiku příliš povrchně pokrývá, takže spíše ne, než ano. Prakticky žádné šance na obnovu dat z mimořádné situace.

Možnosti dalšího postupu: vzdát se CEPH a využít obyčejné vícediskové btrfs (nebo xfs, zfs), zjistit nové informace o CEPH, které umožní jeho provoz v uvedených podmínkách, nebo se pokusit jako zvyšování kvalifikace napsat vlastní úložiště.

Zdroj: habr.com