CEPH-i kasutuskogemus

Kui andmete hulk ületab ühe ketta mahu, on õige aeg mõelda RAID-i peale. Lapsena kuulsin tihti vanematelt: "Kord jääb RAID minevikku, objektipõhised salvestused vallutavad maailma, aga sina ei tea isegi, mis on CEPH," - seega oli esimene samm iseseisvas elus oma klaster luua. Eksperimendi eesmärk oli tutvuda ceph'i sisemise struktuuriga ja mõista selle rakendamise piire. Kui põhjendatud on ceph'i rakendamine keskmises ja väikestes ettevõtetes? Pärast mitmeid aastaid kasutamist ja mõningaid pöördumatuid andmete kaotusi tekkis arusaam nüanssidest, et kõik ei ole nii üheselt mõistetav. CEPH-i omadused loovad takistusi selle ulatuslikule levikule ning seetõttu on eksperimendid jõudnud ummikusse. Allpool on välja toodud kõik läbitud sammud, saadud tulemused ja tehtud järeldused. Kui targad inimesed jagavad oma kogemusi ja selgitavad teatud punkte, olen tänulik.

Märkus: kommentaatorid osutasid tõsistele vigadele mõnedes eeldustes, mis nõuavad kogu artikli ülevaatamist.

CEPH-i strateegia

CEPH-i klaster ühendab suvalise arvu K ketast suvalise suurusega ja salvestab andmed neile, dubleerides iga tükki (4 MB vaikesuurus) määratud arvu N kordi.

Vaatame lihtsamat juhtumit, kus on kaks sama suurusega ketast. Neist saab koostada kas RAID 1 või klastriga N=2 — tulemus on sama. Kui kettaid on kolm ja need on erineva suurusega, siis klastriga N=2 on lihtne luua: osa andmeid on ketastel 1 ja 2, osa on ketastel 1 ja 3, ning osa on ketastel 2 ja 3, kuid RAID-i puhul ei saa seda teha (kuigi sellist RAID-i saab luua, oleks see aga keeruline lahendus). Kui kettaid on veel rohkem, on võimalik luua RAID 5, millele CEPH-l on analoog — erasure_code, mis on vastuolus arendajate varasemate kontseptsioonidega, ja seetõttu ei käsitleta seda. RAID 5 eeldab, et on väike arv kettaid, ja kõik need on heas seisukorras. Ühe ketta rikke korral peavad ülejäänud vastu pidama kuni ketta vahetamiseni ja andmete taastamiseni sellele. CEPH, kui N>=3, soosib vanade ketaste kasutamist, eriti kui hoida mitut head ketast ühe andmekoopiana, samas kui ülejäänud kaks-kolm koopiat hoida suure hulga vanade ketaste peal, siis on informatsioon turvaline, sest nii kaua kui uued kettad on elujõulised — probleeme ei ole, ja kui üks neist katkub, siis kolme üle viie aasta vanuse ketta samal ajal rike, soovitatavalt erinevatelt serveritelt — on äärmiselt ebatõenäoline.

Kopeerimise jaotuses on nüanss. Vaikimisi arvatakse, et andmed jagatakse suuremale hulgale (~100 kettale) PG jaotamisgruppidele, millest igaüht dubleeritakse mõnel kettal. Oletame, et K=6, N=2, siis kahe mis tahes ketta rikke korral kaotatakse andmed kindlalt, kuna tõenäosusteooria kohaselt leiab aset vähemalt üks PG, mis asub just nendel kahel kettal. Ühe grupi kadumine muudab kõik andmed puulis kättesaamatuks. Kui aga kettad jagada kolme paari ja lubada andmete salvestamist ainult ühe paari ketaste vahel, siis selline jaotus on samuti ühe ketta rikke suhtes stabiilne, kuid kahe ketta rikke korral ei ole andmete kaotuse tõenäosus 100%, vaid vaid 3/15, ja isegi kolme ketta rikke korral on see ainult 12/20. Seega ei soodusta andmete jaotus andmete talitlushäirete suhtes usaldusväärsust. Samuti märkime, et failiserveri puhul suurendab vabade operatiivmälu maht oluliselt reageerimise kiirus. Mida rohkem mälu igas sõlmes ja mida rohkem mälu kõigis sõlmedes - seda kiiremini see toimib. See on kindlasti klastrite eelis üksikute serverite ja eriti riistvaraliste NAS-seadmete ees, kuhu on integreeritud väga väike mälu maht.

Seega järeldub, et CEPH on hea viis minimaalse investeeringuga vanemast riistvarast luua usaldusväärne andmesalvestussüsteem kümnete TB-de ulatuses, milles on skaleerimisvõime (siin on muidugi vaja kulutusi, kuid need on võrreldes kommertsalustega suhteliselt väikesed).

Klastri rakendamine

Katses võtame kasutusest väljas oleva arvuti Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Organiseerime neli 2 TB ketast RAID10 sarnaseks, pärast eduka katsetamist lisame teise sõlme ja veel sama palju kettaid.

Installime Linuxi. Jaotises nõutakse kohandatavust ja stabiilsust. Vastavad nõuetele Debian ja Suse. Suse'l on paindlikum installija, mis võimaldab välja lülitada igasuguseid pakette; kahjuks ei suutnud ma välja selgitada, millised võib eemaldada ilma süsteemile kahju tekitamata. Installime Debian'i debootstrap buster'i kaudu. Valik min-base installib mittefunktsionaalse süsteemi, mida iseloomustab draiverite puudumine. Erinevus täisversiooni suuruses ei ole piisavalt suur, et selle üle vaeva näha. Kuna töö toimub füüsilisel masinal, soovin teha snapshot'e nagu virtuaalmasinates. Selle võimaluse pakub kas LVM või btrfs (või xfs, või zfs — erinevus ei ole suur). LVM'i puhul ei ole snapshot'id tugev külg. Installime btrfs. Ja käivituslaadur — MBR-s. Ei ole mõtet ummistada ketast 50 MB FAT-partitsiooniga, kui seda saab suruda 1 MB partitsioonitabeli alasse ja kogu ruumi eraldada süsteemile. Ketas võttis 700 MB. Kui palju on SUSE bainstallis — ei mäleta, tundub, et umbes 1.1 või 1.4 GB.

Installime CEPH'i. Ignoreerime versiooni 12 debiani hoidlas ja võtame otse veebisaidilt 15.2.3. Järgime "installime CEPH käsitsi" jaotise juhiseid järgmiste eranditega:

• Enne hoidla ühendamist on vaja installida gnupg wget ca-certificates.
• Pärast hoidla ühendamist, kuid enne klastrite alustamist on unustatud paigaldada paketid: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
• CEPH'i installimise hetkel üritab lvm2 mõistetamatutel põhjustel paigalduda. Põhimõtteliselt ei ole kahju, aga installimine lõppeb tõrke tõttu, mistõttu CEPH samuti ei paigalduda.

  Aitas see 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
  

Klastri ülevaade

ceph-osd vastutab andmete salvestamise eest kettale. Iga ketta jaoks käivitatakse võrguteenuse, mis aktsepteerib ja täidab päringuid objektide lugemiseks või kirjutamiseks. Kettale luuakse kaks jaotust. Üks neist sisaldab teavet klastrist, ketta numbrist ning ka võtmeid klastrile. See 1KB ulatuses teave luuakse üks kord ketta lisamisel ja enam ei muutu. Teisel jaotusel ei ole failisüsteemi ja seal hoitakse binaardata CEPH. Eelmiste versioonide automaatne seadistus lõi 100MB suuruse xfs jaotuse teenuste teabe jaoks. Minu, konverteeritud ketas MBR formaati ja eraldasin kokku vaid 16MB — teenus ei kaeba. Arvan, et xfs-iga ei tohiks probleeme olla, kui asendada see ext-ga. See jaotus mountitakse /var/lib/... , kus teenus loeb OSD teavet ja leiab viite plokiseadmest, kus binaardata hoitakse. Teoreetiliselt on võimalik kohe abijooned paigutada /var/lib/... , kusjuures kogu ketas on eraldatud andmete jaoks. OSD loomisel läbi ceph-deploy luuakse automaatselt reegel jaotuse mountimiseks /var/lib/... , ning määratakse õigused kasutajale ceph, et lugeda vajalikku plokiseadet. Käesoleva käsitsi seadistamise korral tuleb see ise teha, dokumentatsioonis ei öelda. Samuti on soovitatav määrata parameeter osd memory target, et füüsilisest mälust piisaks.

ceph-mds. Madalal tasemel on CEPH objektipõhine salvestamine. Blokeerimise salvestamise võimalus seisneb iga 4MB ploki salvestamises objektina. Sama põhimõtte kohaselt töötab ka failisüsteem. Loodud on kaks basseini: üks metaandmete jaoks, teine — andmete jaoks. Need ühendatakse failisüsteemaks. Sel hetkel luuakse mingi salvestus, seega kui failisüsteem kustutada, kuid mõlemad basseini säilitada, ei saa seda taastada. On olemas protseduur failide välja tõmbamiseks plokkide kaupa, pole testitud. Failisüsteemi juurdepääsu eest vastutab teenus ceph-mds. Iga failisüsteemi jaoks on vajalik eraldi teenuse eksemplar. On olemas valik "indeks", mis võimaldab luua sarnaseid mitmeid failisüsteeme ühes — seda samuti ei ole testitud.

ceph-mon — see teenus hoiab klastrikaarti. Selle alla kuulub teave kõigi OSD-de, PG jaotuse algoritmi OSD-s ning mis kõige tähtsam, teave kõigi objektide kohta (selle mehhanismi üksikasjad pole mulle selged: on kataloog /var/lib/ceph/mon/.../store.db, kus on suur fail — 26MB, ja klastris on 105K objekti, seega umbes 256 bitti objekti kohta; arvan, et monitor hoiab kõigi objektide ja PG-de nimekirja, milles need asuvad). Selle katalooge kahjustamine toob kaasa andmete kaotuse klastris. Seega tuleneb järeldus, et CRUSH näitab, kuidas PG-d on OSD-de vahel jaotatud, kui objektid on PG-de osas — need on tsentraliseeritult hoitud andmebaasis, hoolimata sellest, kuidas arendajad seda sõna vältida üritaksid. Seetõttu, esiteks, ei saa me süsteemi RO-režiimis mälupulgale installida, kuna andmebaasi tehakse pidevat kirjutamist; vajalik on täiendav ketas nende jaoks (ilmselt mitte rohkem kui 1 GB). Teiseks on vajalik reaalaegne koopia sellest andmebaasist. Kui monitoore on mitu, tagatakse tõrkekindlus automaatselt, kuid meie puhul on monitor üks, maksimaalselt kaks. On teoreetiline protseduur monitori taastamiseks OSD-de andmete põhjal; olen seda mingitel põhjustel kolm korda proovinud, ja kolmel korral ei ole mingeid veateateid, samuti andmeid. Kahjuks ei tööta see mehhanism. Kas me kasutame miniatuurselt OSD-lahtrit ja kogume RAID-i andmebaasi hoidmiseks, mis kindlasti mõjutab jõudlust väga halvasti, või eraldame vähemalt kaks usaldusväärset füüsilist andmekandjat, eelistatult USB, et porte mitte hõivata.

rados-gw — ekspordib objektihoidla S3 protokolli ja sarnaste kaudu. Loob palju puule, mille eesmärk pole selge. Pole palju katsetanud.

ceph-mgr — selle teenuse installimisel käivitatakse mitu moodulit. Üks neist on mitteväljaaadatav autoscale. See püüab säilitada õige PG/OSD arv. Kui soovite suhetest käsitsi hallata, saate iga puu jaoks skaleerimise keelata, kuid sellisel juhul kukub moodul jagamise tõttu 0-ga ja klastri staatuseks muutub ERROR. Moodul on kirjutatud Pythonis ja kui seal vajaliku rea kommenteerite, toob see kaasa selle keelamise. Üksikasju on tüdimus meenutada.

Kasutatud allikate loetelu:

CEPH-i installimine
Monitori täieliku rikke taastamine

Käsuread skriptide jaoks:

Süsteemi installimine debootstrap'i kaudu

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

Klasteri loomine

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/
anceph-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

OSD lisamine (osa)

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

Elulookirjeldus

CEPHi peamine turunduslik eelis on CRUSH — andmete asukoha arvutamise algoritm. Monitorid jagavad klientidele selle algoritmi, pärast mida kliendid küsivad otse vajaliku sõlme ja vajaliku OSD kohta. CRUSH tagab keskset juhtimist välistava ülesande. See on väike fail, mille saab vabalt välja printida ja seinale riputada. Praktika on näidanud, et CRUSH ei ole ammendav kaart. Kui monitorid hävitatakse ja luuakse uuesti, säilitades kõik OSD-d ja CRUSH-i, ei piisa sellest klastri taastamiseks. Seetõttu järeldatakse, et igas monitoris hoitakse teatud metaandmeid kogu klastri kohta. Need metaandmed on väheses mahus, mistõttu need ei pane klasse suuruse piiranguid, kuid nõuavad nende säilitamist, mis välistab odava ketta kasutamise süsteemi jaoks mälupulgana ning välistab klastrid, millel on vähem kui kolm sõlme. Arendaja agressiivne poliitika valikuliste funktsioonide osas. Minimalismist on veel kaugel. Dokumentatsioon on tasemel: „selle eest, mis olemas, — juba aitäh, kuid väga, väga napp“. Madala taseme teenustega suhtlemise võimalus on ette nähtud, kuid dokumentatsioon käsitleb seda teemat liiga pinnapealselt, seetõttu on pigem ei, kui jaa. Praktiliselt pole üldse võimalusi andmete taastamiseks ebanormaalsest olukorrast.

Edasised tegevusvõimalused: loobuda CEPH-ist ja kasutada tavalist mitme ketta btrfs (või xfs, zfs), uurida uusi teadmisi CEPH-i kohta, mis võimaldaks seda nimetatud tingimustes kasutada, proovida oma salvestust kirjutada kui oskuste tõstmist.

Allikas: habr.com