Când cantitatea de date depășește capacitatea unui singur disc, este momentul să te gândești la RAID. În copilărie, am auzit adesea de la mai în vârstă: „odată RAID-urile vor dispărea, stocarea obiectelor va umple lumea, iar tu nu știi chiar ce este CEPH” - așa că primul lucru pe care l-am făcut în viața mea independentă a fost să îmi creez propriul cluster. Scopul experimentului a fost să mă familiarizez cu structura internă a ceph și să înțeleg limitele utilizării sale. Cât de justificată este implementarea ceph în afacerea medie și în cea mică? După câțiva ani de exploatare și câteva pierderi irreversibile de date, am ajuns să înțeleg nuanțele, că nu totul este atât de simplu. Caracteristicile CEPH creează obstacole în răspândirea sa pe scară largă, iar din cauza lor, experimentele au ajuns într-un impas. Mai jos este o descriere a tuturor pașilor parcurși, rezultatul obținut și concluziile trase. Dacă persoane cunoscătoare ar putea împărtăși experiența și lămuri anumite aspecte, le-aș fi recunoscător.
Notă: comentatorii au semnalat erori grave în unele premise, care necesită revizuirea întregii articole.
Strategia CEPH
Clusterul CEPH reunește un număr arbitrar de K discuri de dimensiuni arbitrare și stochează datele pe acestea, duplicând fiecare bucățică (4 MB în mod implicit) de N ori.
Să considerăm cel mai simplu caz cu două hard disk-uri identice. Din ele se poate construi fie RAID 1, fie un cluster cu N=2 — rezultatul va fi același. Dacă există trei hard disk-uri, iar acestea sunt de dimensiuni diferite, atunci este ușor să construiești un cluster cu N=2: o parte din date va fi pe hard disk-urile 1 și 2, o parte pe 1 și 3, iar o parte pe 2 și 3, în timp ce RAID — nu (se poate construi un astfel de RAID, dar ar fi o exagerare). Dacă există și mai multe hard disk-uri, atunci este posibilă crearea RAID 5, iar CEPH are un echivalent — erasure_code, care contrazice conceptele anterioare ale dezvoltatorilor și, prin urmare, nu este luat în considerare. RAID 5 presupune că există un număr mic de hard disk-uri, și toate sunt într-o stare bună. În cazul unui defect, celelalte trebuie să reziste până când discul este înlocuit și datele sunt restaurate pe acesta. Pe de altă parte, CEPH, pentru N>=3, încurajează utilizarea hard disk-urilor mai vechi, în special, dacă păstrezi câteva hard disk-uri bune pentru stocarea unei copii a datelor, iar cele două-trei copii rămase sunt stocate pe un număr mare de hard disk-uri vechi, informațiile vor fi în siguranță, deoarece atâta timp cât hard disk-urile noi funcționează — nu există probleme, iar dacă unul dintre ele se defectează, atunci defectarea simultană a trei hard disk-uri cu o vechime de peste cinci ani, preferabil din diferite servere — este un eveniment extrem de improbabil.
În distribuția copiilor există o subtilitate. Implicit, se presupune că datele sunt împărțite în mai multe grupuri de distribuție PG (aproximativ 100 pe disc), fiecare dintre acestea fiind duplicată pe anumite discuri. Să presupunem că K=6, N=2, atunci dacă se defectează două discuri oricare, datele sunt garantat pierdute, deoarece conform teoriei probabilităților, se va găsi cel puțin o PG, care se va găsi exact pe aceste două discuri. Iar pierderea unei grupe face toate datele din pool inaccesibile. Dacă însă discurile sunt împărțite în trei perechi și se permite stocarea datelor doar pe discurile dintr-o singură pereche, atunci această distribuție este de asemenea rezistentă la defectarea unui disc oricărui, dar în cazul defectării a două, probabilitatea pierderii datelor nu este de 100%, ci doar 3/15, și chiar și în cazul defectării a trei discuri — doar 12/20. Așadar, entropia în distribuția datelor nu contribuie la rezistența la defecțiuni. De asemenea, observăm că pentru serverul de fișiere, memoria RAM liberă crește semnificativ viteza de răspuns. Cu cât există mai multă memorie în fiecare nod și cu cât există mai multă memorie în toate nodurile — cu atât va fi mai rapid. Acesta este cu siguranță un avantaj al clusterului față de un singur server și, cu atât mai mult, față de un NAS hardware, care încorporează un volum foarte mic de memorie.
Așadar, reiese că CEPH este o metodă bună de a crea un sistem de stocare a datelor fiabil pe zeci de TB cu investiții minime din echipamente depășite (aici, desigur, vor fi necesare costuri, dar mai mici comparativ cu sistemele comerciale de stocare).
Implementarea clusterului
Pentru experiment, vom lua un computer ieșit din uz Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Patru discuri de câte 2 TB vor fi organizate asemănător unui RAID10, după testarea cu succes, vom adăuga un al doilea nod și încă atât de multe discuri.
Instalăm Linux. Dintre distribuții, este necesară personalizarea și stabilitatea. Debian și Suse se potrivesc cerințelor. Suse are un installer mai flexibil, permițându-ți să dezactivezi orice pachet; din păcate, nu am reușit să înțeleg ce pot elimina fără a afecta sistemul. Instalăm Debian prin debootstrap buster. Opțiunea min-base instalează un sistem nefuncțional, în care lipsesc driverii. Diferența de dimensiune față de versiunea completă nu este atât de mare încât să fie o problemă. Deoarece lucrăm pe o mașină fizică, dorim să facem snapshot-uri, ca pe mașinile virtuale. Această posibilitate este oferită fie de LVM, fie de btrfs (sau xfs, sau zfs — diferența nu este semnificativă). La LVM, snapshot-urile nu sunt punctul forte. Instalăm btrfs. Iar bootloader-ul — în MBR. Nu are rost să aglomerăm discurile cu un partaj FAT de 50 MB, când putem să-l introducem într-o zonă de 1 MB a tabelului de partiții și să alocăm tot spațiul pentru sistem. A ocupat pe disk 700 MB. Cât ocupa o instalare de bază SUSE — nu am reținut, cred că în jur de 1.1 sau 1.4 GB.
Instalăm CEPH. Ignorăm versiunea 12 din repository-ul debian și o conectăm direct de pe site la versiunea 15.2.3. Urmăm instrucțiunile din secțiunea „instalăm CEPH manual” cu următoarele precizări:
- Înainte de a conecta repository-ul, este necesar să instalăm gnupg wget ca-certificates
- După conectarea repository-ului, dar înainte de instalarea cluster-ului, s-a omis instalarea pachetelor: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- În momentul instalării CEPH, din motive necunoscute, va încerca să instaleze lvm2. În principiu, nu este o problemă, dar instalarea se finalizează cu eșec, deci CEPH nu se va instala nici el.
A ajutat acest 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
Revizuirea cluster-ului
ceph-osd — este responsabil pentru stocarea datelor pe disc. Pentru fiecare disc se lansează un serviciu de rețea, care primește și execută solicitările de citire sau scriere în obiecte. Pe disc sunt create două partiții. Una dintre ele conține informații despre cluster, numărul disk-ului, precum și cheile clusterului. Aceste informații, cu un volum de 1KB, sunt create o singură dată atunci când discuri sunt adăugate și nu am observat că se modifică vreodată. Pe a doua partiție nu există un sistem de fișiere și sunt stocate datele binare CEPH. Instalarea automată în versiunile anterioare crea o partiție xfs de 100MB pentru informații de serviciu. 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 și cu ext. Această partiție este montată în /var/lib/…, unde serviciul citește informațiile despre OSD, precum și găsește un link către dispozitivul de bloc, unde sunt stocate datele binare. Teoretic, se poate localiza imediat auxiliarele în /var/lib/…, iar discul poate fi complet alocat pentru date. Atunci când se creează OSD prin ceph-deploy, se creează automat o regulă pentru montarea partiției în /var/lib/…, iar permisiunile sunt atribuite utilizatorului ceph pentru citirea dispozitivului de bloc necesar. La instalarea manuală, acest lucru trebuie realizat manual, documentația nu menționează acest lucru. De asemenea, este recomandabil să specifici parametrul osd memory target, pentru a avea suficientă memorie fizică.
ceph-mds. La un nivel inferior, CEPH este un sistem de stocare obiect. Capacitatea de stocare pe blocuri se reduce la salvarea fiecărui bloc de 4MB ca obiect. Funcționează pe același principiu și stocarea pe fișiere. Sunt create două pool-uri: unul pentru metadate, altul pentru date. Acestea sunt combinate într-un sistem de fișiere. În acest moment, se creează o anumită înregistrare, așa că dacă ștergi sistemul de fișiere, dar păstrezi ambele pool-uri, nu îl poți restaura. Există o procedură pentru extragerea fișierelor pe blocuri, nu am testat. Accesul la sistemul de fișiere este responsabilitatea serviciului ceph-mds. Fiecare sistem de fișiere necesită o instanță separată a serviciului. Există o opțiune de „index”, care permite crearea unei asemănări a mai multor sisteme de fișiere într-unul — de asemenea, nu a fost testată.
ceph-mon — acest serviciu stochează harta cluster-ului. Acesta include informații despre toate OSD-urile, algoritmul de distribuire a PG în OSD-uri și, cel mai important, informații despre toate obiectele (detaliile acestui mecanism îmi sunt neclare: există un catalog /var/lib/ceph/mon/.../store.db, în care se află un fișier mare — 26MB, iar în cluster sunt 105K obiecte, rezultând puțin peste 256 de byte pe obiect - cred că monitorul stochează o listă a tuturor obiectelor și PG-urilor în care se află acestea). Coruperea acestui catalog duce la pierderea tuturor datelor din cluster. De aici se deduce că CRUSH arată cum sunt dispuse PG-urile pe OSD-uri, iar obiectele sunt centralizat stocate în baza de date, oricât de mult ar încerca dezvoltatorii să evite acest cuvânt. Ca o consecință, pe de o parte, nu putem instala sistemul pe un USB în modul RO, deoarece în baza de date are loc o scriere constantă, este necesar un disc suplimentar pentru acestea (probabil nu mai mult de 1 GB), pe de altă parte, este necesar să avem o copie a acestei baze în timp real. Dacă există mai multe monitoare, redundanța este asigurată automat, dar în cazul nostru monitorul este unul, maxim — două. Există o procedură teoretică de recuperare a monitorului pe baza datelor OSD, am apelat la ea de trei ori din diferite motive, și de trei ori nu am primit mesaje de eroare, la fel ca și datele. Din păcate, acest mecanism nu funcționează. Fie exploatăm o partiție mică pe OSD și construim un RAID pentru stocarea bazei de date, ceea ce cu siguranță va afecta performanța, fie alocăm cel puțin două suporturi fizice de încredere, de preferință USB, pentru a nu ocupa porturile.
rados-gw — exportă stocarea obiectelor prin protocolul S3 și similar. Creează multe pule, fără un motiv clar. Nu am experimentat prea mult.
ceph-mgr — la instalarea acestui serviciu se activează mai multe module. Unul dintre acestea — autoscale-ul, care nu poate fi dezactivat. Acesta își propune să mențină numărul corect de PG/OSD. Dacă doriți să gestionați proporția manual, puteți interzice scalarea pentru fiecare pulă, dar în acest caz modulul se prăbușește cu o diviziune la 0, iar starea cluster-ului devine ERROR. Modulul este scris în Python, și dacă comentăm acea linie necesară, aceasta duce la dezactivarea lui. Detaliile îmi sunt greu de amintit.
Lista surselor utilizate:
Lista 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 < /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 6Crearea clusterului
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@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
Avantajul de marketing principal al CEPH constă în CRUSH – algoritmul de calcul al locației datelor. Monitorii distribuie acest algoritm clienților, care apoi cer direct nodul dorit și OSD-ul necesar. CRUSH asigură absența centralizării. Este un fișier mic, pe care poți chiar să-l tipărești și să-l agăți pe perete. Practica a arătat că CRUSH nu este o hartă exhaustivă. Dacă distrugi și recreezi monitorii, păstrând toate OSD-urile și CRUSH-ul, acest lucru nu este suficient pentru a restabili clusterul. De aici se concluzionează că fiecare monitor stochează unele metadate despre întregul cluster. Volumul neglijabil al acestor metadate nu impune limite asupra dimensiunii clusterului, dar necesită o asigurare a păstrării lor, ceea ce exclude economisirea de spațiu pe disc prin instalarea sistemului pe o memorie flash și exclude clusterele cu mai puțin de trei noduri. Politica agresivă a dezvoltatorului în ceea ce privește caracteristicile opționale. Departe de minimalism. Documentația este la nivelul: „pentru ceea ce există, mulțumim, dar este foarte, foarte sărăcăcios”. Posibilitatea de interacțiune cu serviciile la un nivel inferior este prevăzută, dar documentația abordează acest subiect prea superficial, așa că mai degrabă este un nu decât un da. Practic, nu există șanse pentru recuperarea datelor dintr-o situație neașteptată.
Opțiuni pentru pașii următori: a renunța la CEPH și a utiliza un banat disco multăr btrfs (sau xfs, zfs), a obține noi informații despre CEPH care să permită exploatarea acestuia în condițiile date, a încerca să scrii un stocare proprie pentru a-ți îmbunătăți abilitățile.
Sursa: habr.com
