CEPHi kasutuskogemus

Kui andmete hulk ületab ühe ketta mahutavust, on aeg mõelda RAIDile. Lapsena kuulsin suurte käest tihti: "Ühel päeval kaovad RAID minevikku, objektide salvestuslahendused vallutavad maailma, ja sina ei tea isegi, mis on CEPH," - seega oli minu esimene tegevus iseseisvas elus oma klaster luua. Katse eesmärk oli tutvuda cephi sisemise struktuuriga ja mõista selle rakendamise piire. Kuidas on mõistlik CEPH'i juurutada keskmisesse äri ja väikeseesse? Pärast mitme aasta kasutust ja mõnda pöördumatut andmekadu sai selgeks, et asjad pole sugugi lihtsad. CEPH'i eripärad teevad selle laialdase leviku keeruliseks, ja seetõttu on katsetused ummikusse jõudnud. Allpool on toodud kõik läbitud etapid, saadud tulemused ja tehtud järeldused. Olen tänulik, kui teadlikud inimesed jagavad kogemusi ja selgitavad mõningaid aspekte.

Märkus: kommenteerijad on viidanud tõsistele vigadele mõnedes eeldustes, mis vajavad kogu artikli läbivaatamist.

CEPHi strateegia

CEPH klaster ühendab suvalise arvu K suvalise suurusega kettaid ja salvestab neile andmeid, dubleerides iga tükki (vaikimisi 4 MB) määratud N korda.

Vaatame kõige lihtsamat juhtumit kahe identse ketta puhul. Nendest saab ehitada kas RAID 1 või klusterdada N=2 — tulemus jääb samaks. Kui kettaid on kolm ja need on erineva suurusega, siis klusterdamine N=2 on lihtne: osa andmeid on ketastel 1 ja 2, osa — ketastel 1 ja 3, ning osa — ketastel 2 ja 3; RAID-i puhul ei ole see võimalik (kuigi sellise RAID-i loomine on võimalik, oleks see väärkasutamine). Kui ketaste arv suureneb, siis on võimalik luua RAID 5; CEPH-l on sellele analoog — erasure_code, mis on vastuolus varasemate arendajate kontseptsioonidega ning seetõttu ei ole see teemaks. RAID 5 eeldab, et on olemas väike arv kettaid ja et kõik need on heas seisukorras. Ühe ketta rikke korral peavad ülejäänud kettaid piisama, kuni defekteeritud ketas vahetatakse ja andmed taastatakse. CEPH aga, kui N>=3, soodustab vanade ketaste kasutamist, eriti juhul, kui hoida mitut head ketast ühe andmekoopia salvestamiseks, samas kui ülejäänud kaks-kolm koopiat hoida suurtes vanades kettastes; siis on teave kaitstud, kuna seni, kuni uued kettad on terved — probleeme ei ole, ning kui üks neist puruneb, siis kolme üle viie aasta teeninduses oleva ketta samaaegne rike, soovitavalt erinevatelt serveritelt, on äärmiselt ebatõenäoline.

Kopeeritud andmete jaotamisel on nüanss. Vaikimisi eeldatakse, et andmed jagunevad suurema arvu (~100 plaadi kohta) PG jaotuste gruppide vahel, millest igaüks on dubleeritud mõnedes plaatides. Oletame, et K=6, N=2; siis kui kaks mõnda plaati ebaõnnestub, kaotatakse andmed kindlasti, kuna tõenäosusteooria kohaselt leidub vähemalt üks PG, mis asub just nende kahe plaadi peal. Ja ühe grupi kaotus muudab kõik andmed basseinist kättesaamatuks. Kui aga plaate jagada kolme paari ja lubada andmete salvestamist ainult ühe paari sees, siis on selline jaotus samuti vastupidav ühe plaadi ebaõnnestumisele, kuid kahe plaadi ebaõnnestumise korral ei ole andmete kaotamise tõenäosus 100%, vaid vaid 3/15, ja isegi kolme plaadi ebaõnnestumise korral on see vaid 12/20. Seetõttu ei soodusta andmete jaotuse entropia tõrketaluvust. Samuti tuleb märkida, et failiserveri puhul suurendab vabalt kasutatav mälu oluliselt reageerimisaega. Mida rohkem on mälu igas sõlmes ja mida rohkem on mälu kõigis sõlmedes, seda kiirem on süsteem. See on kindlasti klastrite eelis üksiku serveri ja veelgi enam riistvaralise NAS-i ees, kuhu paigaldatakse väga väike mälu.

Seega on CEPH hea võimalus kasutada vanade seadmete vähese investeeringuga usaldusväärse andmesalvestuse süsteemi loomiseks kümnetes TB-des, millel on skaleeritavus (muidugi on vajalikud kulutused, kuid need on väikesed võrreldes kommertsalustel).

Klastri rakendamine

Eksperimendiks võtame vananenud arvuti Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Organiseerime neli 2 TB ketast RAID10 sarnaseks, pärast edukat katset lisame teise sõlme ja veel sama palju kettaid.

Installime Linuxi. Jaotuse puhul on vajalik kohandamise ja stabiilsuse võimalus. Sobivad nõuetele Debian ja Suse. Susel on paindlikum installija, mis võimaldab alla laadida mistahes pakett; kahjuks ei suutnud ma aru saada, millised neist võib süsteemist välja jätta ilma kahju tekitamata. Installeerime Debiani debootstrap buster kaudu. Min-base valik installeerib mittetöötava süsteemi, millest puuduvad draiverid. Erinevus suuruses võrreldes täisversiooniga pole niivõrd suur, et sellega tegeleda. Kuna töö toimub füüsilisel masinal, on soov teha hetkepilte nagu virtuaalmasinatega. Sellist võimalust pakuvad kas LVM või btrfs (või xfs või zfs — erinevus pole suur). LVM-i hetkepildid pole tugev külg. Installeerime btrfs. Ja buutimise laadija — MBR. Pole mõtet täita distsipliini 50 MB FAT jaotusega, kui selle võib suruda 1 MB jaotustabeli piirkonda ja kogu ruumi eraldada süsteemile. See võttis kettale 700 MB. Kui palju on SUSE bainstalli suurus — ei mäleta, tundub, et umbes 1.1 või 1.4 GB.

Paigaldame CEPH. Ignorime debiani hoidla versiooni 12 ja ühendame otse veebisaidilt versiooni 15.2.3. Järgime jaotises "paigaldame CEPH käsitsi" antud juhiseid koos järgmiste täiendustega:

• Enne hoidla ühendamist tuleb installida gnupg wget ca-certificates
• Pärast hoidla ühendamist, kuid enne klastrite paigaldamist on vahele jäetud pakettide installimine: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• CEPHi installimise hetkel üritab kummalistel põhjustel paigalduda lvm2. Üldiselt pole kahetsusväärne, kuid installatsioon lõpeb tõrkega, mistõttu CEPH ei installi samuti.

  See patch aitas:

  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 võtab vastu ja täidab objektide lugemise või kirjutamise päringud. Kettale luuakse kaks jaotust. Üks neist sisaldab teavet klastrist, ketta numbrist ja samuti klastrivõtitest. See 1KB suurune teave luuakse korra, kui ketas lisatakse, ja ma ei ole kunagi märganud, et see muutuks. Teisel jaotusel ei ole failisüsteemi ja seal hoitakse CEPH-i binaardata. Automaatne installatsioon eelmistes versioonides lõi xfs jaotuse suurusega 100MB teenusteabe jaoks. Ma konverteerisin ketta MBR-iks ja eraldasin kokku ainult 16MB — teenus ei kurda. Arvan, et xfs võiks probleemideta asendada ka ext-ga. See jaotus monteeritakse /var/lib/…, kuhu teenus loeb OSD teavet ja leiab ühenduse sellele vastava plokiseadmest, kus hoitakse binaardata. Teoreetiliselt võiks abijõud asetada otse /var/lib/…, ja terve ketas eraldada ainult andmete jaoks. OSD loomisel läbi ceph-deploy luuakse automaatselt reegel jaotuse monteerimiseks /var/lib/… ja määratakse õigused ceph kasutajale soovitud plokiseadmest lugemiseks. Manuaalse installatsiooni korral on see vajalik ise teha, dokumentatsioonis seda ei öelda. Samuti on soovitatav määrata parameeter osd memory target, et füüsilist mälu jaguks.

ceph-mds. Madal tasemel on CEPH — objektipõhine salvestus. Blokeerimise salvestamise võimalus tähendab, et iga 4MB blokk salvestatakse objektina. Sama printsiibi järgi töötab ka failisüsteem. Loodud on kaks bassein: üks metaandmete jaoks ja teine andmete jaoks. Need koondatakse failisüsteemi. Sel hetkel luuakse mingi salvestus, seetõttu, kui faili süsteem kustutatakse, kuid mõlemad basseinid säilitatakse, siis ei ole selle taastamine võimalik. Tõkkede kaupa failide ekstraheerimiseks on olemas protseduur, mida ei ole testitud. Failisüsteemi juurde pääsemise 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 ühe sees — ka seda ei ole testitud.

ceph-mon — see teenus salvestab klastrikaarti. See sisaldab teavet kõigi OSD-de, PG jaotamise algoritmi OSD-des ning, mis kõige tähtsam, teavet kõigi objektide kohta (selle mehhanismi detailid on mulle ebaselged: on kataloog /var/lib/ceph/mon/.../store.db, kus on suur fail — 26MB, ja klastris 105K objekti, tähendab see veidi üle 256 baiti objekti kohta — arvan, et monitoor salvestab kõikide objektide ja PG-de loendi, kuhu nad kuuluvad). Selle katalooge kahjustamine toob kaasa andmete kaotuse klastris. Seetõttu on järeldatud, et CRUSH näitab, kuidas PG-d on OSD-des ja kuidas objektid asuvad PG-des — need on tsentraliseeritult salvestatud andmebaasi, ükskõik kui palju arendajad seda sõna vältida püüavad. Selle tagajärjeks on, et me ei saa süsteemi paigaldada mälupulgale RO-režiimis, kuna andmebaasi toimub pidev kirjutamine, on vaja lisadiski nende jaoks (ilmtingimata mitte rohkem kui 1 GB), ja teiseks on vajalik reaalajas selle andmebaasi koopia. Kui monitoore on mitu, siis tõrgeteta jätkamine tagatakse automaatselt, kuid meie puhul on monitoor üks, maksimum — kaks. On teoreetiline protseduur monitoori taastamiseks OSD andmete põhjal, olen sellele kolm korda pöördunud erinevatel põhjustel ning kolm korda pole mingit veateadet, samuti andmeid. Kahjuks see mehhanism ei tööta. Kas siis kasutame miniatuursed sektsioone OSD-l ja kogume RAID andmebaasi salvestamiseks, mis kindlasti halvendab jõudlust, või eraldame vähemalt kaks usaldusväärset füüsilist seadmeid, eelistatavalt USB-d, et porti mitte hõivata.

rados-gw — ekspordib objektide salvestamise S3 protokolli kaudu ja sarnastele. Loodud on palju puule, millel pole selget eesmärki. Ei ole eriti katsetanud.

ceph-mgr — selle teenuse käivitamisel aktiveeritakse mitu moodulit. Üks neist on kohustuslik autoscale. See püüab säilitada õige PG/OSD arvu. Kui soovite suhet käsitsi hallata, saate igas puulus skaleerimise keelata, kuid sel juhul langeb moodul jagamise tõttu nulli ja klastris on staatus ERROR. Moodul on kirjutatud Pythonis ja kui vajalik rida kommenteerida, toob see kaasa selle keelamise. Üksikasjad on meelest läinud.

Kasutatud allikate loetelu:

CEPHi paigaldamine
Monitori täieliku tõrke korral taastamine

Skriptiliste loendite:

Süsteemi paigaldamine 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 << 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 <adduser@packages.debian.org>
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 <adduser@packages.debian.org>
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

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

OSD (osa) lisamine

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

Kokkuvõte

CEPH peamine turunduslik eelis on CRUSH — andmete asukoha arvutusalgoritm. Monitoorid edastavad klientidele selle algoritmi, mille järel kliendid teevad otse päringud soovitud sõlme ja OSD poole. CRUSH tagab keskuse puudumise. See on väike fail, mille saab isegi välja printida ja seinale riputada. Praktika on näidanud, et CRUSH ei ole ammendav kaart. Kui monitoorid hävitada ja uuesti luua, säilitades kõik OSD-d ja CRUSH-i, on sellest ebapiisav klastrite taastamiseks. Seetõttu järeldatakse, et igas monitooris hoitakse teatud metaandmeid kogu klastrist. Need metaandmed ei piirata klastrite suurust, kuid nende kaitsmine on vajalik, mis välistab süsteemi paigaldamise flash-mälupulgale ning klastrid, kus on vähem kui kolm sõlme. Arendaja agressiivne poliitika valikuliste funktsioonide osas. Minimalismist on veel kaugel. Dokumentatsioon on tasemel: "selle eest, mis on, — aitäh, kuid väga, väga napilt". Madala taseme teenustega suhtlemise võimalus on olemas, kuid dokumentatsioon käsitleb seda teemat liiga pinnapealselt, seega on tõenäolisem ei kui jah. Peaaegu pole võimalusi andmete taastamiseks väljaspool tavapärast olukorda.

Edasi liikuda: loobuda CEPH-i kasutamisest ja kasutada tavalist mitmeketta btrfs (või xfs, zfs), uurida uut teavet CEPH-i kohta, mis võimaldab seda antud tingimustes kasutada, või proovida enda oskusi arendada, kirjutades oma salvestuslahenduse.

Allikas: habr.com