Když je více dat, než se vejde na jeden disk, je čas přemýšlet o RAID. Jako dítě jsem často od svých starších slýchal: „jednoho dne se RAID stane minulostí, úložiště předmětů zaplaví svět a vy ani nevíte, co je CEPH,“ takže první věc v nezávislém životě vytvářel svůj vlastní cluster. Účelem experimentu bylo seznámit se s vnitřní strukturou cephu a pochopit rozsah jeho aplikace. Jak oprávněné je zavedení ceph ve středním podniku, ale v malém? Po několika letech provozu a několika nevratných ztrátách dat došlo k pochopení jemností, že ne všechno je tak jednoduché. Vlastnosti CEPH vytvářejí překážky pro jeho širokou distribuci a kvůli nim se experimenty zastavily. Níže je uveden popis všech provedených kroků, dosaženého výsledku a vyvozených závěrů. Pokud se znalí lidé podělí o své zkušenosti a vysvětlí některé body, budu vděčný.
Poznámka: Komentátoři poukázali na závažné chyby v některých předpokladech, které si vyžádaly revizi celého článku.
strategie CEPH
Cluster CEPH kombinuje libovolný počet K disků libovolné velikosti a ukládá na ně data, přičemž každý kus (standardně 4 MB) duplikuje daný počet Nkrát.
Zvažte nejjednodušší případ se dvěma stejnými disky. Buď z nich sestavíte RAID 1 nebo cluster s N=2 – výsledek bude stejný. Pokud existují tři disky a mají různé velikosti, je snadné sestavit cluster s N=2: některá data budou na discích 1 a 2, některá na discích 1 a 3 a některá na 2 a 3 , kdežto RAID není (můžete takový RAID sbírat, ale byla by to zvrácenost). Pokud je disků ještě více, pak je možné vytvořit RAID 5, CEPH má analog - erasure_code, který je v rozporu s ranými koncepty vývojářů, a proto se neuvažuje. RAID 5 předpokládá, že existuje malý počet disků a všechny jsou v dobrém stavu. Pokud jeden selže, zbytek musí vydržet, dokud nebude disk vyměněn a data na něm obnovena. CEPH s N>=3 podporuje používání starých disků, zejména pokud si ponecháte několik dobrých disků pro uložení jedné kopie dat a zbývající dvě nebo tři kopie uložíte na velký počet starých disků, pak informace bude v bezpečí, protože zatím jsou nové disky naživu - nejsou žádné problémy, a pokud se jeden z nich rozbije, pak je současná porucha tří disků s životností delší než pět let, nejlépe z různých serverů, extrémně nepravděpodobná událost.
V distribuci kopií je jemnost. Ve výchozím nastavení se předpokládá, že data jsou rozdělena do více (~100 na disk) distribučních skupin PG, z nichž každá je na některých discích duplikována. Předpokládejme, že K=6, N=2, pak pokud selžou kterékoli dva disky, je zaručena ztráta dat, protože podle teorie pravděpodobnosti bude na těchto dvou discích umístěn alespoň jeden PG. A ztráta jedné skupiny znepřístupní všechna data ve fondu. Pokud jsou disky rozděleny do tří párů a je povoleno ukládat data pouze na disky v rámci jednoho páru, pak je takové rozložení odolné i proti selhání kteréhokoli jednoho disku, ale pokud dva selžou, pravděpodobnost ztráty dat není 100% ale pouze 3/15, a to i v případě poruchy tři kotouče - pouze 12/20. Entropie v distribuci dat tedy nepřispívá k odolnosti proti chybám. Všimněte si také, že u souborového serveru volná RAM výrazně zvyšuje odezvu. Čím více paměti v každém uzlu a čím více paměti ve všech uzlech, tím rychlejší bude. To je nepochybně výhoda clusteru oproti jedinému serveru a navíc hardwarového NAS, kde je zabudováno velmi malé množství paměti.
Z toho plyne, že CEPH je dobrý způsob, jak vytvořit spolehlivý úložný systém pro desítky TB s možností škálování s minimálními investicemi ze zastaralého zařízení (zde samozřejmě náklady budou vyžadovány, ale oproti komerčním úložným systémům malé).
Implementace klastrů
Pro experiment si vezměme vyřazený počítač Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Čtyři 2TB disky organizujeme do něčeho jako RAID10, po úspěšném testu přidáme druhý uzel a stejný počet disků.
Nainstalujte Linux. Distribuce musí být přizpůsobitelná a stabilní. Debian a Suse splňují požadavky. Suse má flexibilnější instalační program, který vám umožňuje zakázat jakýkoli balíček; bohužel jsem nepochopil, které z nich lze vyhodit bez poškození systému. Nainstalujte Debian přes debootstrap buster. Možnost min-base nainstaluje nefunkční systém, který postrádá ovladače. Rozdíl ve velikosti oproti plné verzi není tak velký, aby obtěžoval. Protože se práce provádí na fyzickém počítači, chci pořizovat snímky, stejně jako na virtuálních strojích. Buď LVM nebo btrfs (nebo xfs, nebo zfs - rozdíl není velký) takovou příležitost poskytuje. Snímky nejsou silnou stránkou LVM. Nainstalujte btrfs. A bootloader je v MBR. Nemá smysl ucpávat 50 MB disk oddílem FAT, když jej můžete nasunout do oblasti tabulky oddílů o velikosti 1 MB a alokovat veškerý prostor pro systém. Na disku to zabralo 700 MB. Kolik má základní instalace SUSE - nepamatuji si, zdá se, asi 1.1 nebo 1.4 GB.
Nainstalujte CEPH. Verzi 12 v úložišti debian ignorujeme a připojujeme se přímo ze stránky 15.2.3. Postupujeme podle pokynů v části „Manuální instalace CEPH“ s následujícími upozorněními:
- Před připojením úložiště musíte nainstalovat gnupg wget ca-certificates
- Po připojení úložiště, ale před instalací clusteru, je instalace balíčku vynechána: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- V době instalace CEPH se z neznámých důvodů pokusí nainstalovat lvm2. V zásadě to není škoda, ale instalace se nezdaří, takže nenainstaluje ani CEPH.
Tento patch pomohl:
cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <[email protected]> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Přehled clusteru
ceph-osd - zodpovědný za ukládání dat na disk. Pro každý disk je spuštěna síťová služba, která přijímá a provádí požadavky na čtení nebo zápis do objektů. Na disku jsou vytvořeny dva oddíly. Jeden z nich obsahuje informace o clusteru, čísle disku a klíčích clusteru. Tyto informace o velikosti 1 kB jsou vytvořeny jednou při přidávání disku a nikdy si nevšimneme, že by se znovu změnily. Druhý oddíl nemá systém souborů a ukládá binární data CEPH. Automatická instalace v předchozích verzích vytvořila 100 MB xfs oddíl pro servisní informace. Disk jsem převedl na MBR a přidělil pouze 16MB - služba si nestěžuje. Myslím, že bez problémů lze xfs nahradit ext. Tento oddíl je připojen do /var/lib/…, kde služba čte informace o OSD a také najde odkaz na blokové zařízení, kde jsou uložena binární data. Teoreticky můžete okamžitě umístit pomocné do / var / lib / ... a alokovat celý disk pro data. Při vytváření OSD pomocí ceph-deploy se automaticky vytvoří pravidlo pro připojení oddílu do /var/lib/… a uživateli ceph jsou přidělena práva ke čtení požadovaného blokového zařízení. U ruční instalace to musíte udělat sami, v dokumentaci se o tom nepíše. Je také vhodné zadat cílový parametr paměti osd, aby bylo k dispozici dostatek fyzické paměti.
ceph-mds. Na nízké úrovni je CEPH objektové úložiště. Kapacita blokového úložiště se scvrkává na uložení každého 4MB bloku jako objektu. Na stejném principu funguje ukládání souborů. Jsou vytvořeny dva fondy: jeden pro metadata, druhý pro data. Jsou spojeny do souborového systému. V tuto chvíli je vytvořen nějaký záznam, takže pokud smažete souborový systém, ale uložíte oba fondy, nebudete jej moci obnovit. Existuje postup na extrahování souborů po blocích, nemám to vyzkoušeno. Služba ceph-mds je zodpovědná za přístup k systému souborů. Každý souborový systém vyžaduje samostatnou instanci služby. Existuje možnost "index", která vám umožňuje vytvořit zdání několika souborových systémů v jednom - také netestováno.
ceph-mon - Tato služba uchovává mapu clusteru. Zahrnuje informace o všech OSD, algoritmu distribuce PG v OSD, a co je nejdůležitější, informace o všech objektech (podrobnosti tohoto mechanismu mi nejsou jasné: existuje /var/lib/ceph/mon/…/ store.db adresář, obsahuje velký soubor má 26MB a ve shluku 105K objektů to vychází něco málo přes 256 bajtů na objekt - myslím, že si monitor vede seznam všech objektů a PG, ve kterém oni lžou). Poškození tohoto adresáře má za následek ztrátu všech dat v clusteru. Odtud bylo vyvozeno, že CRUSH ukazuje, jak jsou PG umístěny podle OSD a jak jsou umístěny objekty podle PG - jsou centrálně uloženy v databázi, bez ohledu na to, jak se vývojáři tomuto slovu vyhýbají. V důsledku toho za prvé nemůžeme nainstalovat systém na flash disk v režimu RO, protože databáze je neustále zapisována, je pro ně potřeba další disk (sotva více než 1 GB), a za druhé je nutné mít kopii této základny v reálném čase. Pokud existuje několik monitorů, je odolnost proti poruchám poskytována automaticky, ale v našem případě je pouze jeden monitor, maximálně dva. Existuje teoretický postup pro obnovu monitoru na základě dat OSD, uchýlil jsem se k němu třikrát z různých důvodů a třikrát žádné chybové hlášení, stejně jako data. Bohužel tento mechanismus nefunguje. Buď zprovozníme miniaturní OSD oddíl a sestavíme RAID pro uložení databáze, což bude mít pravděpodobně velmi špatný vliv na výkon, nebo alokujeme alespoň dvě spolehlivá fyzická média, nejlépe USB, aby nezabíraly porty.
rados-gw - exportuje úložiště objektů pomocí protokolu S3 a podobně. Vytváří spoustu bazénů, není jasné proč. Opravdu neexperimentoval.
ceph-mgr - Instalace této služby spustí několik modulů. Jedním z nich je nedeaktivované automatické škálování. Snaží se udržovat správný počet PG/OSD. Pokud chcete poměr ovládat ručně, můžete zakázat škálování pro každý fond, ale v tomto případě modul spadá s dělením 0 a stav clusteru se změní na CHYBNÝ. Modul je napsán v pythonu a pokud v něm zakomentujete potřebný řádek, vede to k jeho vypnutí. Příliš líný pamatovat si detaily.
Seznam použitých zdrojů:
Seznam skriptů:
Instalace systému přes 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 << EOF > /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 << EOF >> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
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 <[email protected]>
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 6Vytvořte shluk
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 << EOF > /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@rbd1Př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@$osdnumShrnutí
Hlavní marketingovou výhodou CEPH je CRUSH, algoritmus pro výpočet umístění dat. Monitory šíří tento algoritmus klientům, načež klienti přímo požadují požadovaný uzel a požadované OSD. CRUSH neposkytuje žádnou centralizaci. Je to malý soubor, který si můžete dokonce vytisknout a pověsit na zeď. Praxe ukázala, že CRUSH není vyčerpávající mapa. Zničení a opětovné vytvoření monitorů při zachování všech OSD a CRUSH k obnovení clusteru nestačí. Z toho lze usoudit, že každý monitor ukládá nějaká metadata o celém clusteru. Nevýznamné množství těchto metadat neklade omezení na velikost clusteru, vyžaduje však jejich bezpečnost, což eliminuje úsporu disku díky instalaci systému na flash disk a vylučuje clustery s méně než třemi uzly. Agresivní zásady pro vývojáře týkající se volitelných funkcí. Daleko od minimalismu. Dokumentace na úrovni: „děkuji za to, co to je, ale velmi, velmi skromně“. Možnost interakce se službami na nízké úrovni je poskytována, ale dokumentace je na toto téma příliš povrchní, takže spíše ne než ano. Prakticky žádná šance na obnovu dat z nouzové situace.
Možnosti dalšího postupu: opustit CEPH a použít banální vícediskové btrfs (nebo xfs, zfs), dozvědět se nové informace o CEPH, které vám umožní provozovat jej v určených podmínkách, zkusit si napsat vlastní úložiště jako pokročilé školení .
Zdroj: www.habr.com