Kui andmeid on rohkem, kui ühele kettale mahub, on aeg mõelda RAID-ile. Lapsena kuulsin sageli oma vanematelt: "Ühel päeval on RAID minevik, objektide ladustamine täidab maailma ja te ei tea isegi, mis on CEPH", nii et esimene asi minu iseseisvas elus oli luua oma klast. Katse eesmärk oli tutvuda tsefi sisemise struktuuriga ja mõista selle rakendusala. Kui õigustatud on tsefi rakendamine keskmise suurusega ettevõtetes ja väikestes ettevõtetes? Pärast mitut aastat töötamist ja paari pöördumatut andmekadu tekkis arusaamine keerukusest, et kõik pole nii lihtne. CEPH iseärasused takistavad selle laialdast kasutuselevõttu ja nende tõttu on katsed jõudnud ummikusse. Allpool kirjeldatakse kõiki tehtud samme, saadud tulemust ja tehtud järeldusi. Kui teadlikud inimesed jagavad oma kogemusi ja selgitavad mõnda punkti, olen tänulik.
Märkus. Kommentaatorid on tuvastanud mõnedes eeldustes tõsiseid vigu, mis nõuavad kogu artikli ülevaatamist.
CEPH strateegia
CEPH-klaster ühendab suvalise arvu K suvalise suurusega kettaid ja salvestab neile andmed, dubleerides iga tükki (vaikimisi 4 MB) etteantud arvu N korda.
Vaatleme kõige lihtsamat juhtumit kahe identse kettaga. Nendest saab kokku panna kas RAID 1 või klastri N=2 - tulemus on sama. Kui kettaid on kolm ja need on erineva suurusega, siis on lihtne koostada klastri N=2: osa andmetest on kettadel 1 ja 2, osa kettadel 1 ja 3 ning osa andmetest 2 ja 3 peal, samas kui RAID mitte (saate sellise RAID-i kokku panna, aga see oleks perverssus). Kui kettaid on veelgi rohkem, siis on võimalik luua RAID 5; CEPH-l on analoog - erasure_code, mis on vastuolus arendajate varajaste kontseptsioonidega ja seetõttu ei arvestata. RAID 5 eeldab, et draive on vähe, mis kõik on heas seisukorras. Kui üks ebaõnnestub, peavad teised vastu pidama, kuni ketas vahetatakse ja sellele andmed taastatakse. CEPH, mille N>=3, julgustab kasutama vanu kettaid, eriti kui hoiate mitu head ketast ühe andmete koopia salvestamiseks ja ülejäänud kaks või kolm koopiat suurele hulgale vanadele ketastele, siis on ohutu, kuna praegu on uued kettad elus - probleeme pole ja kui üks neist puruneb, on kolme ketta samaaegne rike, mille kasutusiga on üle viie aasta, eelistatavalt erinevatest serveritest, äärmiselt ebatõenäoline. sündmus.
Koopiate levitamisel on peensus. Vaikimisi eeldatakse, et andmed on jagatud rohkemateks (~100 ketta kohta) PG jaotusrühmadeks, millest igaüks on mõnel kettal dubleeritud. Oletame, et K=6, N=2, siis kui suvaline kaks ketast ebaõnnestuvad, on andmete kadumine garanteeritud, kuna tõenäosusteooria järgi on neil kahel kettal vähemalt üks PG. Ja ühe rühma kaotamine muudab kõik kogumis olevad andmed kättesaamatuks. Kui kettad on jagatud kolmeks paariks ja andmeid on lubatud salvestada ainult ühe paari sees olevatele ketastele, siis on selline jaotus vastupidav ka ühe ketta rikkele, kuid kahe ketta rikke korral pole andmete kadumise tõenäosus suurem. 100%, kuid ainult 3/15 ja isegi tõrke korral kolm ketast - ainult 12/20. Seega ei aita andmete jaotamise entroopia kaasa tõrketaluvusele. Pange tähele ka seda, et failiserveri puhul suurendab vaba RAM oluliselt reageerimiskiirust. Mida rohkem mälu igas sõlmes ja mida rohkem mälu kõigis sõlmedes, seda kiirem see on. See on kahtlemata klastri eelis ühe serveri ja veelgi enam riistvaralise NAS-i ees, kuhu on sisse ehitatud väga väike kogus mälu.
Sellest järeldub, et CEPH on hea viis kümnete TB jaoks usaldusväärse andmesalvestussüsteemi loomiseks, mida on võimalik vananenud seadmetest minimaalsete investeeringutega skaleerida (siin on muidugi vaja kulusid, kuid kaubanduslike salvestussüsteemidega võrreldes väikesed).
Klastri juurutamine
Eksperimendi jaoks võtame kasutusest kõrvaldatud arvuti Intel DQ57TM + Intel core i3 540 + 16 GB muutmälu. Korraldame neli 2 TB ketast millekski nagu RAID10, pärast edukat testi lisame teise sõlme ja sama palju kettaid.
Linuxi installimine. Jaotamine eeldab kohandamisvõimet ja stabiilsust. Debian ja Suse vastavad nõuetele. Susel on paindlikum installer, mis võimaldab mis tahes paketi keelata; Kahjuks ei saanud ma aru, milliseid neist saaks ilma süsteemi kahjustamata ära visata. Installige Debian, kasutades debootstrap Busterit. Min-base valik installib katkise süsteemi, millel puuduvad draiverid. Suuruse erinevus täisversiooniga võrreldes pole nii suur, et häirida. Kuna tööd tehakse füüsilises masinas, tahan teha hetktõmmiseid, nagu virtuaalmasinatel. Seda võimalust pakuvad kas LVM või btrfs (või xfs või zfs – vahe pole suur). LVM-i hetktõmmised pole tugevad küljed. Installige btrfs. Ja alglaadur on MBR-is. Pole mõtet 50 MB ketast FAT-partitsiooniga segamini ajada, kui saate selle lükata 1 MB partitsioonitabeli alale ja eraldada kogu ruumi süsteemi jaoks. Võttis kettal 700 MB. Ma ei mäleta, kui palju SUSE põhiinstallatsioonil on, arvan, et see on umbes 1.1 või 1.4 GB.
Installige CEPH. Me ignoreerime versiooni 12 debiani hoidlas ja ühendame otse saidilt 15.2.3. Järgime jaotises "CEPH käsitsi installimine" toodud juhiseid järgmiste hoiatustega:
- Enne hoidla ühendamist peate installima gnupg wget ca-sertifikaadid
- Pärast hoidla ühendamist, kuid enne klastri installimist jäetakse pakettide installimine välja: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- CEPH-i installimisel proovib see teadmata põhjustel installida lvm2. Põhimõtteliselt pole sellest kahju, kuid installimine ebaõnnestub, nii et ka CEPH ei installi.
See plaaster aitas:
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
Klastrite ülevaade
ceph-osd - vastutab andmete kettale salvestamise eest. Iga ketta jaoks käivitatakse võrguteenus, mis võtab vastu ja täidab taotlusi objektide lugemiseks või kirjutamiseks. Kettale luuakse kaks partitsiooni. Üks neist sisaldab teavet klastri, ketta numbri ja klastri võtmete kohta. See 1KB teave luuakse üks kord ketta lisamisel ja pole kunagi märgatud muutumist. Teisel partitsioonil pole failisüsteemi ja see salvestab CEPH-i kahendandmed. Automaatne installimine eelmistes versioonides lõi teenindusteabe jaoks 100 MB xfs-i partitsiooni. Teisendasin ketta MBR-iks ja eraldasin ainult 16 MB - teenus ei kurda. Ma arvan, et xfs-i saaks ilma probleemideta asendada extiga. See partitsioon on ühendatud kausta /var/lib/…, kus teenus loeb teavet OSD kohta ja leiab ka viite plokkseadmele, kus binaarandmed on salvestatud. Teoreetiliselt saate kohe paigutada lisafailid kausta /var/lib/… ja eraldada kogu ketta andmete jaoks. OSD loomisel ceph-deploy kaudu luuakse automaatselt reegel partitsiooni ühendamiseks kaustas /var/lib/… ja ceph-kasutajale määratakse ka õigused soovitud plokkseadme lugemiseks. Kui installite käsitsi, peate seda ise tegema; dokumentatsioon seda ei ütle. Samuti on soovitatav määrata osd-mälu sihtparameetri parameeter, et oleks piisavalt füüsilist mälu.
ceph-mds. Madalal tasemel on CEPH objektide salvestamine. Võimalus salvestusruumi blokeerida taandub iga 4 MB ploki salvestamisele objektina. Failide salvestamine töötab samal põhimõttel. Luuakse kaks kogumit: üks metaandmete jaoks, teine andmete jaoks. Need on ühendatud failisüsteemiks. Praegu luuakse mingi kirje, nii et kui kustutate failisüsteemi, kuid jätate mõlemad kogumid alles, ei saa te seda taastada. Plokkide kaupa failide ekstraheerimiseks on olemas protseduur, ma pole seda testinud. Failisüsteemile juurdepääsu eest vastutab teenus ceph-mds. Iga failisüsteem nõuab teenuse eraldi eksemplari. Seal on suvand "indeks", mis võimaldab teil luua mitme failisüsteemi sarnasusi ühes - samuti pole testitud.
Ceph-mon – see teenus salvestab klastri kaardi. See sisaldab teavet kõigi OSD-de kohta, PG-de jaotamise algoritmi OSD-des ja, mis kõige tähtsam, teavet kõigi objektide kohta (selle mehhanismi üksikasjad pole mulle selged: seal on kataloog /var/lib/ceph/mon/…/ store.db, see sisaldab suurt faili suurust 26 MB ja 105 256 objektist koosnevas klastris on see veidi üle 1 baiti objekti kohta - ma arvan, et monitor salvestab loendi kõigist objektidest ja PG-dest, milles nad asuvad). Selle kataloogi kahjustamise tagajärjel kaovad kõik klastris olevad andmed. Sellest järeldati, et CRUSH näitab, kuidas PG-d OSD-l asuvad ja objektid PG-del - need on andmebaasi keskselt salvestatud, hoolimata sellest, kui palju arendajad seda sõna väldivad. Selle tulemusena ei saa me esiteks süsteemi RO-režiimis mälupulgale installida, kuna andmebaasi salvestatakse pidevalt, nende jaoks on vaja täiendavat ketast (vaevalt rohkem kui XNUMX GB), teiseks on vaja omada kopeerige see baas reaalajas. Kui monitore on mitu, siis veataluvus on tagatud automaatselt, aga meie puhul on ainult üks monitor, maksimaalselt kaks. Monitori taastamiseks OSD andmete põhjal on olemas teoreetiline protseduur, kasutasin seda erinevatel põhjustel kolm korda ja kolm korda ei olnud veateateid ega ka andmeid. Kahjuks see mehhanism ei tööta. Kas kasutame OSD-l miniatuurset partitsiooni ja koostame andmebaasi salvestamiseks RAID-i, millel on jõudlusele kindlasti väga halb mõju, või eraldame vähemalt kaks usaldusväärset füüsilist andmekandjat, eelistatavalt USB, et mitte porte hõivata.
rados-gw - ekspordib objektide salvestusruumi S3 protokolli jms kaudu. Loob palju basseine, pole selge, miks. Ma ei katsetanud palju.
ceph-mgr – selle teenuse installimisel käivitatakse mitu moodulit. Üks neist on automaatskaala, mida ei saa keelata. See püüab säilitada õiget PG/OSD kogust. Kui soovite suhet käsitsi juhtida, saate iga kogumi skaleerimise keelata, kuid sel juhul jookseb moodul kokku nulliga jagades ja klastri olek muutub olekuks ERROR. Moodul on kirjutatud Pythonis ja kui sa selles vajaliku rea välja kommenteerid, viib see selle keelamiseni. Liiga laisk, et detaile meeles pidada.
Kasutatud allikate loetelu:
Skriptide loendid:
Süsteemi installimine debootstrapi 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 <[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 6Looge klaster
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@rbd1OSD lisamine (osaline)
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@$osdnumKokkuvõte
CEPH peamine turunduseelis on CRUSH – andmete asukoha arvutamise algoritm. Monitorid jagavad selle algoritmi klientidele, misjärel kliendid küsivad otse soovitud sõlme ja soovitud OSD-d. CRUSH ei taga tsentraliseerimist. See on väike fail, mille saate isegi välja printida ja seinale riputada. Praktika on näidanud, et CRUSH ei ole ammendav kaart. Kui hävitate ja loote monitorid uuesti, säilitades kogu OSD ja CRUSH, siis sellest ei piisa klastri taastamiseks. Sellest järeldatakse, et iga monitor salvestab teatud metaandmeid kogu klastri kohta. Nende metaandmete väike hulk ei sea piiranguid klastri suurusele, kuid nõuab nende ohutuse tagamist, mis välistab ketta säästmise süsteemi installimisel välkmäluseadmele ja välistab vähem kui kolme sõlmega klastrid. Arendaja agressiivne poliitika valikuliste funktsioonide osas. Kaugel minimalismist. Dokumentatsioon on tasemel "tänan teid selle eest, mis meil on, kuid see on väga-väga napp". Võimalus suhelda teenustega madalal tasemel on tagatud, kuid dokumentatsioon puudutab seda teemat liiga pealiskaudselt, seega on tõenäolisem ei kui jah. Andmete taastamiseks hädaolukorrast praktiliselt puudub võimalus.
Edasise tegevuse võimalused: loobuge CEPH-st ja kasutage banaalset mitmekettalist btrf-i (või xfs-i, zfs-i), otsige uut teavet CEPH-i kohta, mis võimaldab teil seda kindlaksmääratud tingimustel kasutada, proovige kirjutada oma salvestusruum edasijõudnutena koolitust.
Allikas: www.habr.com