Când există mai multe date decât încap pe un disc, este timpul să ne gândim la RAID. În copilărie, am auzit adesea de la bătrânii mei: „Într-o zi RAID-ul va deveni un lucru al trecutului, stocarea obiectelor va inunda lumea și nici măcar nu știi ce este CEPH”, deci primul lucru într-o viață independentă. v-ați creat propriul cluster. Scopul experimentului a fost de a se familiariza cu structura internă a ceph și de a înțelege domeniul de aplicare al acestuia. Cât de justificată este introducerea ceph într-o afacere medie, dar într-una mică? După câțiva ani de funcționare și câteva pierderi ireversibile de date, a apărut o înțelegere a subtilităților că nu totul este atât de simplu. Caracteristicile CEPH creează obstacole în calea distribuției sale pe scară largă și, din cauza lor, experimentele au încetat. Mai jos este o descriere a tuturor pașilor parcurși, rezultatul obținut și concluziile trase. Dacă oamenii cunoscători își vor împărtăși experiența și vor explica unele puncte, le voi fi recunoscător.
Notă: comentatorii au subliniat erori grave în unele dintre ipoteze, necesitând o revizuire a întregului articol.
strategia CEPH
Clusterul CEPH combină un număr arbitrar K de discuri de dimensiuni arbitrare și stochează date pe acestea, duplicând fiecare bucată (4 MB în mod implicit) de un număr dat de N ori.
Luați în considerare cel mai simplu caz cu două discuri identice. Puteți asambla fie un RAID 1, fie un cluster cu N=2 din ele - rezultatul va fi același. Dacă există trei discuri și sunt de dimensiuni diferite, atunci este ușor să asamblați un cluster cu N=2: unele dintre date vor fi pe discurile 1 și 2, altele pe 1 și 3 și altele pe 2 și 3 , în timp ce RAID nu este (puteți colecta un astfel de RAID, dar ar fi o perversiune). Dacă există și mai multe discuri, atunci este posibil să se creeze RAID 5, CEPH are un analog - erasure_code, care contrazice conceptele timpurii ale dezvoltatorilor și, prin urmare, nu este luat în considerare. RAID 5 presupune că există un număr mic de discuri și toate sunt în stare bună. Dacă unul eșuează, restul trebuie să reziste până când discul este înlocuit și datele sunt restaurate pe acesta. CEPH, cu N>=3, încurajează utilizarea de discuri vechi, în special, dacă păstrați mai multe discuri bune pentru a stoca o copie a datelor și stocați celelalte două sau trei copii pe un număr mare de discuri vechi, atunci informațiile va fi în siguranță, deoarece deocamdată discuri noi sunt în viață - nu există probleme, iar dacă unul dintre ele se rupe, atunci defecțiunea simultană a trei discuri cu o durată de viață mai mare de cinci ani, de preferință de la servere diferite, este extrem de puțin probabilă. eveniment.
Există o subtilitate în distribuirea copiilor. În mod implicit, se presupune că datele sunt împărțite în mai multe (~100 pe disc) grupuri de distribuție PG, fiecare dintre acestea fiind duplicat pe unele discuri. Să presupunem că K=6, N=2, atunci dacă oricare două discuri eșuează, se garantează pierderea datelor, deoarece, conform teoriei probabilității, va exista cel puțin un PG care va fi localizat pe aceste două discuri. Și pierderea unui grup face ca toate datele din pool să fie inaccesibile. Dacă discurile sunt împărțite în trei perechi și li se permite să stocheze date numai pe discuri dintr-o pereche, atunci o astfel de distribuție este, de asemenea, rezistentă la eșecul oricărui disc, dar dacă două eșuează, probabilitatea de pierdere a datelor nu este de 100%, dar doar 3/15, și chiar și în caz de defecțiune trei discuri - doar 12/20. Prin urmare, entropia în distribuția datelor nu contribuie la toleranța la erori. De asemenea, rețineți că pentru un server de fișiere, memoria RAM liberă crește foarte mult capacitatea de răspuns. Cu cât este mai multă memorie în fiecare nod și cu cât mai multă memorie în toate nodurile, cu atât va fi mai rapidă. Acesta este, fără îndoială, avantajul unui cluster față de un singur server și, în plus, al unui NAS hardware, în care este încorporată o cantitate foarte mică de memorie.
Rezultă că CEPH este o modalitate bună de a crea un sistem de stocare fiabil pentru zeci de TB cu posibilitatea de scalare cu investiții minime din echipamente învechite (aici, desigur, vor fi necesare costuri, dar mici în comparație cu sistemele de stocare comerciale).
Implementarea clusterului
Pentru experiment, să luăm un computer dezafectat Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Organizam patru discuri de 2 TB in ceva de genul RAID10, dupa un test reusit vom adauga un al doilea nod si acelasi numar de discuri.
Instalați Linux. Distribuția trebuie să fie personalizabilă și stabilă. Debian și Suse se potrivesc cerințelor. Suse are un program de instalare mai flexibil care vă permite să dezactivați orice pachet; din păcate, nu am putut înțelege care dintre ele pot fi aruncate fără a deteriora sistemul. Instalați Debian prin debootstrap buster. Opțiunea min-base instalează un sistem care nu funcționează, care nu are drivere. Diferența de dimensiune față de versiunea completă nu este atât de mare încât să deranjeze. Deoarece munca se face pe o mașină fizică, vreau să fac instantanee, la fel ca pe mașinile virtuale. Fie LVM, fie btrfs (sau xfs, sau zfs - diferența nu este mare) oferă o astfel de oportunitate. Instantaneele nu sunt punctul forte al LVM. Instalați btrfs. Și bootloader-ul este în MBR. Nu are sens să înfundați un disc de 50 MB cu o partiție FAT când îl puteți împinge într-o zonă de tabel de partiții de 1 MB și alocați tot spațiul pentru sistem. A fost nevoie de 700 MB pe disc. Cât de mult are instalarea de bază a SUSE - nu îmi amintesc, se pare, aproximativ 1.1 sau 1.4 GB.
Instalați CEPH. Ignorăm versiunea 12 din depozitul debian și ne conectăm direct de pe site-ul 15.2.3. Urmăm instrucțiunile din secțiunea „Instalarea manuală a CEPH” cu următoarele avertismente:
- Înainte de a conecta depozitul, trebuie să instalați gnupg wget ca-certificates
- După conectarea depozitului, dar înainte de instalarea clusterului, instalarea pachetului este omisă: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- La momentul instalării CEPH, din motive necunoscute, va încerca să instaleze lvm2. În principiu, nu e păcat, dar instalarea eșuează, așa că nici CEPH nu se va instala.
Acest patch a ajutat:
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
Prezentare generală a clusterului
ceph-osd - responsabil pentru stocarea datelor pe disc. Pentru fiecare disc, este pornit un serviciu de rețea care acceptă și execută cereri de citire sau scriere pe obiecte. Două partiții sunt create pe disc. Una dintre ele conține informații despre cluster, numărul discului și cheile clusterului. Această informație de 1 KB este creată o dată când adăugați un disc și nu a fost observată niciodată să se schimbe din nou. A doua partiție nu are sistem de fișiere și stochează date binare CEPH. Instalarea automată în versiunile anterioare a creat o partiție xfs de 100 MB pentru informații despre service. Am convertit discul în MBR și am alocat doar 16MB - serviciul nu se plânge. Cred că, fără probleme, xfs ar putea fi înlocuit cu ext. Această partiție este montată în /var/lib/... unde serviciul citește informații despre OSD și găsește, de asemenea, un link către dispozitivul bloc unde sunt stocate datele binare. Teoretic, puteți plasa imediat cele auxiliare în / var / lib / ... și alocați întregul disc pentru date. Când se creează un OSD prin ceph-deploy, se creează automat o regulă pentru a monta o partiție în /var/lib/…, iar drepturile utilizatorului ceph sunt atribuite pentru a citi dispozitivul bloc dorit. Cu o instalare manuală, trebuie să faceți acest lucru singur, documentația nu spune despre asta. De asemenea, este recomandabil să specificați parametrul țintă a memoriei osd, astfel încât să existe suficientă memorie fizică.
ceph-mds. La un nivel scăzut, CEPH este stocarea obiectelor. Capacitatea de stocare a blocurilor se rezumă la salvarea fiecărui bloc de 4 MB ca obiect. Stocarea fișierelor funcționează pe același principiu. Sunt create două pool-uri: unul pentru metadate, celălalt pentru date. Ele sunt combinate într-un sistem de fișiere. În acest moment, se creează un fel de înregistrare, așa că dacă ștergeți sistemul de fișiere, dar salvați ambele pool-uri, atunci nu o veți putea restaura. Există o procedură pentru extragerea fișierelor în blocuri, nu am testat-o. Serviciul ceph-mds este responsabil pentru accesarea sistemului de fișiere. Fiecare sistem de fișiere necesită o instanță separată a serviciului. Există o opțiune „index” care vă permite să creați o aparență a mai multor sisteme de fișiere într-unul singur - de asemenea, netestat.
ceph-mon - Acest serviciu păstrează o hartă a clusterului. Include informații despre toate OSD-urile, algoritmul de distribuție PG în OSD și, cel mai important, informații despre toate obiectele (detaliile acestui mecanism nu sunt clare pentru mine: există un /var/lib/ceph/mon/…/ directorul store.db, conține un fișier mare de 26 MB, iar într-un cluster de 105K obiecte, rezultă puțin mai mult de 256 de octeți per obiect - cred că monitorul păstrează o listă cu toate obiectele și PG-ul în care ei mint). Deteriorarea acestui director duce la pierderea tuturor datelor din cluster. De aici s-a ajuns la concluzia că CRUSH arată cum sunt localizate PG-urile conform OSD și cum sunt localizate obiectele conform PG - ele sunt stocate central în baza de date, indiferent de modul în care dezvoltatorii evită acest cuvânt. Ca urmare, în primul rând, nu putem instala sistemul pe o unitate flash în modul RO, deoarece baza de date este scrisă în mod constant, este nevoie de un disc suplimentar pentru acestea (abia dacă mai mult de 1 GB) și, în al doilea rând, este necesar să aveți o copie în timp real a acestei baze. Dacă există mai multe monitoare, atunci toleranța la erori este furnizată automat, dar în cazul nostru există un singur monitor, maxim două. Există o procedură teoretică pentru restaurarea unui monitor pe baza datelor OSD, am apelat la el de trei ori din diverse motive și de trei ori fără mesaje de eroare, precum și date. Din păcate, acest mecanism nu funcționează. Fie operăm o partiție OSD în miniatură și asamblam un RAID pentru a stoca baza de date, ceea ce probabil va avea un efect foarte rău asupra performanței, fie alocam cel puțin două medii fizice fiabile, de preferință USB, astfel încât porturile să nu ocupe.
rados-gw - exportă stocarea obiectelor folosind protocolul S3 și altele asemenea. Creează o mulțime de piscine, nu este clar de ce. Nu am experimentat cu adevărat.
ceph-mgr - Instalarea acestui serviciu pornește mai multe module. Unul dintre ele este scalarea automată nedezactivată. Se străduiește să mențină numărul corect de PG/OSD-uri. Dacă doriți să controlați manual raportul, puteți dezactiva scalarea pentru fiecare pool, dar în acest caz modulul scade cu o împărțire cu 0, iar starea clusterului devine EROARE. Modulul este scris în python și, dacă comentați linia necesară din el, aceasta duce la oprirea acestuia. Prea lene să-ți amintești detaliile.
Lista surselor folosite:
Liste de scripturi:
Instalarea sistemului prin 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 6Creați un cluster
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@rbd1Adăugarea OSD (parte)
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@$osdnumRezumat
Principalul avantaj de marketing al CEPH este CRUSH, un algoritm pentru calcularea locației datelor. Monitoarele propagă acest algoritm către clienți, după care clienții solicită direct nodul dorit și OSD-ul dorit. CRUSH nu oferă centralizare. Este un fișier mic pe care îl puteți imprima și agăța pe perete. Practica a arătat că CRUSH nu este o hartă exhaustivă. Distrugerea și recrearea monitoarelor păstrând toate OSD-urile și CRUSH nu este suficientă pentru a restabili clusterul. Din aceasta se concluzionează că fiecare monitor stochează câteva metadate despre întregul cluster. Cantitatea nesemnificativă a acestor metadate nu impune restricții asupra dimensiunii clusterului, dar necesită siguranța acestora, ceea ce elimină economiile de disc datorate instalării sistemului pe o unitate flash și exclude clusterele cu mai puțin de trei noduri. Politică agresivă pentru dezvoltatori cu privire la funcțiile opționale. Departe de minimalism. Documentare la nivel: „mulțumesc pentru ceea ce este, dar foarte, foarte slab.” Este oferită capacitatea de a interacționa cu serviciile la un nivel scăzut, dar documentația este prea superficială pe această temă, deci mai probabil nu decât da. Practic, nicio șansă de a recupera date dintr-o situație de urgență.
Opțiuni pentru acțiuni ulterioare: abandonați CEPH și utilizați banalul multi-disc btrfs (sau xfs, zfs), aflați informații noi despre CEPH, care vă vor permite să-l operați în condițiile specificate, încercați să vă scrieți propriul stocare ca un antrenament avansat .
Sursa: www.habr.com