Keď je dát viac, než sa zmestí na jeden disk, je čas zamyslieť sa nad RAID. V detstve som často počul od starších: „raz RAID zmizne do histórie, objektové úložiská ovládnu svet a ty ani nebudeš vedieť, čo je CEPH,“ - preto prvým krokom v samostatnom živote bolo vytvorenie vlastného klastrového systému. Cieľom experimentu bolo oboznámiť sa s vnútornou štruktúrou ceph a pochopiť možnosti jeho aplikácie. Aké opodstatnené je zavádzanie ceph do stredného a malého podnikania? Po niekoľkých rokoch prevádzky a niekoľkých nezvratných stratách dát sa objavili nuansy, ktoré ukázali, že to nie je tak jednoznačné. Vlastnosti CEPH stavajú prekážky jeho širokému rozšíreniu a kvôli nim experimenty uviazli. Nižšie je uvedený popis všetkých vykonaných krokov, dosiahnutých výsledkov a vyvodených záverov. Ak sa znalí ľudia podelia o skúsenosti a objasnia niektoré aspekty - budem vďačný.
Poznámka: komentátori poukázali na vážne chyby v niektorých predpokladoch, ktoré si vyžadujú revíziu celého článku.
Stratégia CEPH
Klastr CEPH spája ľubovoľný počet K diskov ľubovoľnej veľkosti a uchováva na nich dáta, pričom každý kus duplikuje (4 MB ako predvolené) určitý počet N krát.
Zvážime najjednoduchší prípad s dvoma rovnakými diskami. Môžeme z nich buď vytvoriť RAID 1, alebo klaster s N=2 — výsledok bude rovnaký. Ak sú disky tri a majú rôzne veľkosti, klaster s N=2 sa jednoducho zloží: časť údajov bude na diskoch 1 a 2, časť na disku 1 a 3 a časť na disku 2 a 3, zatiaľ čo RAID nie. (Taký RAID je síce možné zostaviť, ale bude to skreslené.) Ak je diskov ešte viac, je možné vytvoriť RAID 5, u CEPH existuje analóg — erasure_code, ktorý je v rozpore s ranými konceptmi vývojárov, a preto nie je zvažovaný. RAID 5 predpokladá, že je k dispozícii malé množstvo diskov a všetky sú v dobrom stave. Pri zlyhaní jedného by mali ostatné vydržať, kým sa disk nevymení a údaje sa naň neobnovia. CEPH však pri N≥3 podporuje použitie starých diskov, konkrétne ak máte niekoľko dobrých diskov na uloženie jednej kópie údajov a zvyšné dve až tri kópie sú uložené na veľkom množstve starých diskov, informácie budú zabezpečené, pretože kým sú nové disky funkčné — nie sú žiadne problémy, a ak niektorý z nich zlyhá, súčasné zlyhanie troch diskov s dobou životnosti viac ako päť rokov, ideálne z rôznych serverov — je veľmi nepravdepodobné.
Pri distribúcii kópií existuje jemnosť. Predpokladá sa, že údaje sú rozdelené do väčšieho množstva (~ okolo 100 na disk) skupín distribúcie PG, z ktorých každá je zdvojená na určitých diskoch. Predpokladajme, že K=6, N=2, potom pri zlyhaní dvoch akýchkoľvek diskov sa zaručene stratia údaje, pretože podľa teórie pravdepodobnosti sa nájde aspoň jedna PG, ktorá bude umiestnená práve na týchto dvoch diskoch. A strata jednej skupiny robí nedostupnými všetky údaje v poole. Ak by sme však disky rozdelili na tri páry a povolili uchovávanie údajov len na diskoch v rámci jedného páru, takéto rozdelenie je tiež odolné voči zlyhaniu akéhokoľvek disku, ale pri zlyhaní dvoch je pravdepodobnosť straty údajov nie 100 %, ale iba 3/15, a dokonca pri zlyhaní troch diskov — len 12/20. Odtiaľ vyplýva, že entropia v distribúcii údajov neprispieva k odolnosti voči zlyhaniu. Taktiež si všimneme, že pre súborový server voľná operačná pamäť výrazne zvyšuje rýchlosť odozvy. Čím viac pamäte je v každom uzle a čím viac pamäte je vo všetkých uzloch — tým rýchlejšie to bude. To je nepochybne výhoda klastru pred jednotlivým serverom a ešte viac pred hardvérovým NAS, do ktorého sa inštaluje veľmi malé množstvo pamäte.
Odtiaľ vyplýva, že CEPH je dobrý spôsob, ako s minimálnymi investíciami z zastaraného hardvéru vytvoriť spoľahlivý systém ukladania údajov na desiatky TB s možnosťou škálovania (tu samozrejme budú potrebné náklady, ale malé v porovnaní s komerčnými STHD).
Realizácia klastru
Na experiment vezmeme vyradený počítač Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Štyri disky po 2 TB zorganizujeme do podoby RAID10, po úspešnom testovaní pridáme druhý uzol a ešte toľko diskov.
Inštalujeme Linux. Od distribúcie sa vyžaduje prispôsobiteľnosť a stabilita. Na tieto požiadavky vyhovujú Debian a Suse. Suse má flexibilnejší inštalátor, ktorý umožňuje deaktivovať akýkoľvek balík; bohužiaľ, nedokázal som pochopiť, ktoré môžem odstrániť bez poškodenia systému. Nainštalujeme Debian pomocou debootstrap buster. Možnosť min-base nainštaluje nefunkčný systém, ktorému chýbajú ovládače. Rozdiel vo veľkosti v porovnaní s plnou verziou nie je taký veľký, aby to stálo za zamyslenie. Pretože práca prebieha na fyzickej mašine, chceli by sme robiť snapshoty, ako na virtuálnych strojoch. Takúto možnosť poskytuje buď LVM, alebo btrfs (prípadne xfs alebo zfs — rozdiel nie je veľký). Snapshots v LVM nie sú silnou stránkou. Nainštalujeme btrfs. A zavádzač — do MBR. Nemá zmysel zbytočne zapĺňať disk 50 MB oddielom FAT, keď ho môžeme vmestiť do 1 MB oblasti tabuľky oddielov a celé miesto vyhradiť pre systém. Zaberá to na disku 700 MB. Koľko zaberá základná inštalácia SUSE — nepamätám si, zdá sa, že okolo 1.1 alebo 1.4 GB.
Inštalujeme CEPH. Ignorujeme verziu 12 v repozitári debian a pripojíme priamo zo stránky 15.2.3. Postupujeme podľa pokynov v sekcii „inštalujeme CEPH ručne“ s nasledujúcimi upozorneniami:
- Pred pripojením repozitára je potrebné nainštalovať gnupg wget ca-certificates.
- Po pripojení repozitára, ale pred inštaláciou klastrov, je opomenutá inštalácia balíkov: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
- V okamihu inštalácie CEPH sa z neznámych dôvodov pokúša nainštalovať lvm2. V podstate mi to nevadí, ale inštalácia sa končí chybou, preto CEPH tiež nebude nainštalovaný.
Pomohol 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
Prehľad klastrov
ceph-osd — zodpovedá za ukladanie dát na disku. Pre každý disk sa spúšťa sieťová služba, ktorá prijíma a vykonáva požiadavky na čítanie alebo zápis do objektov. Na disku sa vytvárajú dva oddiely. Jeden z nich obsahuje informácie o klastri, čísle disku a kľúče od klastru. Tieto informácie s objemom 1KB sa raz vytvoria pri pridávaní disku a nikdy sa nezmenia. Na druhom oddiele nie je súborový systém a uchovávajú sa binárne dáta CEPH. Automatická inštalácia v predchádzajúcich verziách vytvorila xfs oddiel s veľkosťou 100MB pre servisné informácie. Disk som konvertoval na MBR a vyčlenil len 16MB — služba si nesťažuje. Myslím, že by sa xfs dalo bez problémov nahradiť aj ext. Tento oddiel sa montuje do \/var\lib\…, kde služba číta informácie o OSD, ako aj nachádza odkaz na blokové zariadenie, kde sú uložené binárne dáta. Teoreticky je možné uložiť pomocné údaje priamo do \/var\lib\…, a celý disk vyčleniť na dáta. Pri vytváraní OSD cez ceph-deploy sa automaticky vytvorí pravidlo pre montovanie oddielu do \/var\lib\…, ako aj sa pridelia práva používateľovi ceph na čítanie potrebného blokového zariadenia. Pri manuálnej inštalácii je to potrebné spraviť ručne, v dokumentácii o tom nie je zmienka. Tiež je žiaduce uviesť parameter osd memory target, aby bolo dostatok fyzickej pamäte.
ceph-mds. Na nízkej úrovni je CEPH objektové úložisko. Možnosť blokového ukladania sa znižuje na uchovávanie každého bloku 4MB vo forme objektu. Podľa rovnakého princípu funguje aj súborové ukladanie. Vytvárajú sa dva pooly: jeden pre metadát, druhý — pre dáta. Tieto sa zlúčia do súborového systému. V tomto momente sa vytvorí akýsi záznam, takže ak odstránite súborový systém, ale zachováte oba pooly, nebude možné ho obnoviť. Existuje postup na extrakciu súborov po blokoch, ale to som netestoval. Za prístup k súborovému systému zodpovedá služba ceph-mds. Pre každý súborový systém je potrebný samostatný inštanc služby. Existuje voľba „index“, ktorá umožňuje vytvoriť niečo podobné viacerým súborovým systémom v jednom — to tiež nebolo testované.
ceph-mon — táto služba uchováva mapu klastera. Obsahuje informácie o všetkých OSD, algoritmus distribúcie PG v OSD a, čo je najdôležitejšie, informácie o všetkých objektoch (detaily tohto mechanizmu nie sú pre mňa jasné: existuje katalóg /var/lib/ceph/mon/.../store.db, v ktorom je veľký súbor — 26MB, a v klastri je 105K objektov, vychádza to na niečo málo cez 256 bajtov na objekt, - myslím, že monitor uchováva zoznam všetkých objektov a PG, v ktorých sa nachádzajú). Poškodenie tohto katalógu vedie k strate všetkých údajov v klastri. Odtiaľ vyplýva, že CRUSH ukazuje, ako sú PG rozložené po OSD a ako sú objekty rozložené po PG — centrálne sa uchovávajú v databáze, nech už sa vývojári snažia tomuto slovu vyhnúť. Ako dôsledok, po prvé, nemôžeme nainštalovať systém na USB v režime RO, pretože do databázy sa vykonáva neustále zapisovanie, potrebný je ďalší disk pre tieto (s najväčšou pravdepodobnosťou viac ako 1 GB), po druhé, je potrebné mať v reálnom čase kópiu tejto databázy. Ak je monitorov viac, redundancia je zabezpečená automaticky, ale v našom prípade je monitor jeden, maximálne — dva. Existuje teoretický postup na obnovenie monitora na základe údajov OSD, raz som k nemu siahol zo z rôznych dôvodov a trikrát žiadne chybové hlásenia, ako ani údaje. Bohužiaľ, tento mechanizmus nefunguje. Buď prevádzkujeme miniatúrnu partition na OSD a skladujeme RAID pre uchovávanie databázy, čo určite veľmi zlý dopad na výkon, alebo vyčleníme aspoň dva spoľahlivé fyzické nosiče, ideálne USB, aby sme nevyužívali porty.
rados-gw — exportuje objektové úložisko cez protokol S3 a podobné. Vytvára množstvo poolov, nejasne prečo. Osobitne som neexperimentoval.
ceph-mgr — pri inštalácii tejto služby sa spúšťajú niektoré moduly. Jedným z nich je nezastaviteľné autoscale. Snaží sa udržiavať správny počet PG/OSD. Ak sa chcete ručne riadiť pomerom, môžete zakázať škálovanie pre každý pool, ale v takom prípade modul spadne pri delení na 0 a stav klastra sa stane ERROR. Modul je napísaný v Pythone, a ak zakomentujete potrebný riadok, vedie to k jeho vypnutiu. Detaily si nechcem pamätať.
Zoznam použitých zdrojov:
Zoznamy skriptov:
Inštalácia systému cez 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 6Vytvorenie klastera
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@rbd1Pridanie OSD (časť)
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@$osdnumZhrnutie
Hlavným marketingovým prínosom CEPH je CRUSH — algoritmus výpočtu umiestnenia dát. Monitory sprístupňujú tento algoritmus zákazníkom, po čom zákazníci priamo žiadajú o konkrétny uzol a konkrétny OSD. CRUSH zabezpečuje absenciu centralizácie. Predstavuje si to ako malý súbor, ktorý môžete dokonca vytlačiť a zavesiť na stenu. Prax ukázala, že CRUSH nie je vyčerpávajúca mapa. Ak zničíte a znovu vytvoríte monitory, pričom si zachováte všetky OSD a CRUSH, nebude to stačiť na obnovenie klastra. Odtiaľ vyplýva, že na každom monitore sú uložené niektoré metadáta o celom klastri. Nezanedbateľný objem týchto metadát nekladie obmedzenia na veľkosť klastra, ale vyžaduje zabezpečiť ich ochranu, čo vylučuje úsporu disku tým, že systém nainštalujete na flash disk, a vylučuje klastre s menej ako tromi uzlami. Agresívna politika vývojára vo vzťahu k voliteľným funkciám. Ďaleko od minimalizmu. Dokumentácia na úrovni: „za to, čo je, - už ďakujeme, ale veľmi, veľmi chudobné“. Možnosť interakcie so službami na nízkej úrovni je predpokladaná, ale dokumentácia sa tejto téme zaoberá príliš povrchne, takže skôr nie, ako áno. Takmer žiadne šance na obnovenie dát z mimoštátnej situácie.
Možnosti ďalších akcií: vzdať sa CEPH a využiť banálny viacdiskový btrfs (alebo xfs, zfs), získať nové informácie o CEPH, ktoré umožnia jeho prevádzku v uvedených podmienkach, pokúsiť sa zvýšiť kvalifikáciu napísaním vlastného úložiska.
Zdroj: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish