Kur të dhënat bëhen më shumë se çfarë mund të ruhet në një disk, është koha të mendohet për RAID. Në fëmijëri kam dëgjuar shpesh nga të rriturit: «një ditë RAID do të shkojnë në të kaluarën, magazinat objektive do të pushtojnë botën, dhe ti as nuk di se çfarë është CEPH» — prandaj hapi i parë në jetën time të pavarur ishte krijimi i klasterit tim. Qëllimi i eksperimentit ishte të njihesha me strukturën e brendshme të ceph dhe të kuptoja kufijtë e aplikimit të tij. Sa e justifikuar është integrimi i ceph në biznesin e mesëm, dhe në atë të vogël? Pasi kalova disa vite në përdorim dhe pas disa humbjeve të pakthyeshme të të dhënave, fillova të kuptoja nuancat që nuk janë të gjitha aq të qarta. Karakteristikat e CEPH krijojnë pengesa ndaj përhapjes së tij të gjerë, dhe për shkak të tyre eksperimentet arritën në një rrugë pa dalje. Më poshtë do të gjeni përshkrimin e të gjitha hapave të ndjekur, rezultatin e arritur dhe përfundimet e nxjerra. Nëse persona të njohur do të ndajnë përvoja dhe të sqarojnë disa momente — do të isha mirënjohës.
Shënim: komentuesit theksuan gabime të mëdha në disa supozime, që kërkojnë rishikimin e tërë artikullit.
Strategjia CEPH
Klastri CEPH bashkon një numër të mëtejmë K diskësh me madhësi të ndryshme dhe ruan të dhënat mbi to, duke kopjuar secilën pjesë (4 MB si standard) një numër të caktuar N herë.
Le të shqyrtojmë rastin më të thjeshtë me dy disqe të njëjta. Nga këto, mund të ndërtojmë ose RAID 1, ose një klaster me N=2 - rezultati do të jetë i njëjtë. Nëse diskët janë tre dhe të një sërë të ndryshme, atëherë ndërtimi i një klasteri me N=2 është i thjeshtë: një pjesë e të dhënave do të jetë në diskët 1 dhe 2, një pjesë në 1 dhe 3, dhe një pjesë në 2 dhe 3, ndërsa RAID - jo (mund të krijohet një RAID të tillë, por kjo do të ishte një devijim). Nëse janë më shumë disqe, atëherë është e mundur të krijohet RAID 5; CEPH ka një analogji - erasure_code, e cila është në përputhje me konceptet e hershme të zhvilluesve dhe prandaj nuk shqyrtohet. RAID 5 parasheh që të ketë një numër të vogël disqesh, dhe të gjithë ata të jenë në gjendje të mirë. Në rast se njëri dështoi, të tjerët duhet të mbajnë deri në momentin kur të zëvendësohet disku dhe të rikuperohen të dhënat mbi të. Ndërsa CEPH, kur N>=3, nxit përdorimin e disqeve të vjetra; në veçanti, nëse mbani disa disqe të mirë për të ruajtur një kopje të të dhënave dhe dy-tre kopje të mbetura në një numër të madh disqesh të vjetra, atëherë informacioni do të jetë i sigurt, pasi për sa kohë që disqet e reja janë funksionale - nuk ka probleme, dhe nëse njëri prej tyre dështon, dështimi i njëkohshëm i tre disqeve me një jetëgjatësi prej më shumë se pesë vitesh, preferohet nga serverë të ndryshëm - është një ngjarje jashtëzakonisht e pamundur.
Ka shpërndarja e kopjave ka një nuancë. Së pari, supozohet që të dhënat ndahen në një numër më të madh (~rreth 100 për disk) grupesh shpërndarjeje PG, secila prej të cilave kopjohet në disa disqe. Supozojmë se K=6, N=2, atëherë në rast të dështimit të dy disqeve të çfarëdo, të dhënat humbasin me siguri, pasi sipas teorisë së probabilitetit, do të gjendet të paktën një PG që do të vendoset pikërisht në këto dy disqe. Dhe humbja e një grupi e bën të paaccessueshme të dhënat në grup. Nëse disqet ndahen në tri çiftë dhe lejohet që të dhënat të ruhen vetëm në disqet brenda një çifti, atëherë kjo shpërndarje gjithashtu është e qëndrueshme ndaj dështimit të një disku të çfarëdo, megjithatë në rastin e dështimit të dy, probabiliteti i humbjes së të dhënave nuk është 100%, por vetëm 3/15, dhe madje në rastin e dështimit të tre disqeve — vetëm 12/20. Prandaj, entropia në shpërndarjen e të dhënave nuk kontribuon në qëndrueshmërinë ndaj dështimeve. Gjithashtu, vërejmë se për serverin e skedarëve, memoria e lirë operative rrit ndjeshëm shpejtësinë e përgjigjes. Sa më shumë memorie të jetë në çdo nyje, dhe sa më shumë memorie të jetë në të gjitha nyjet — aq më shpejt do të jetë. Kjo padyshim është një avantazh i klasterit përballë një serveri të vetëm dhe, më shumë, një NAS-it hardueror, ku integrohen një sasi shumë e vogël memorie.
Prandaj, CEPH është një mënyrë e mirë për të krijuar një sistem të besueshëm të ruajtjes së të dhënave deri në dhjetëra TB me investime minimale nga pajisje të vjetra (sigurisht, do të kërkohen disa shpenzime, por të vogla në krahasim me sistemet komerciale të ruajtjes).
Implementimi i klastra
Për eksperimentin, do të përdorim një kompjuter të shkarkuar Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Katër disqe me kapacitet 2 TB do të organizohen si RAID10, dhe pas një testi të suksesshëm, do të shtojmë një nyje të dytë dhe aq disqe të tjera.
Instalojmë Linux. Distribucioni duhet të ketë mundësi për personalizim dhe stabilitet. Debian dhe Suse i përmbushin këto kërkesa. Suse ka një instalues më fleksibël, i cili lejon çaktivizimin e çdo pakete; fatkeqësisht, nuk arrita të kuptoj se cilat mund të hiqen pa dëmtuar sistemin. Instalojmë Debian përmes debootstrap buster. Opsioni min-base instalon një sistem jo-funksional, i cili ka mungesë driverrash. Ndryshimi në madhësi krahasuar me versionin e plotë nuk është aq i madh sa të shqetësohemi. Duke qenë se puna po kryhet në një makinë fizike, dua të bëj snapshot-e, siç bëj në makinat virtuale. Kjo mundësi ofrohet ose nga LVM, ose nga btrfs (ose xfs, ose zfs — diferenca nuk është e madhe). Snapshots në LVM nuk janë pika e fortë. Zgjedhim btrfs. Dhe boot loader-in — në MBR. Nuk ka kuptim të mbushim diskun me 50 MB hapësirë me një pjesë FAT, kur mund ta zhvendosim atë në një zonë prej 1 MB të tabelës së pjesëve dhe të dedikojmë gjithë hapësirën për sistemin. Zuri 700 MB në disk. Sa ishte instalimi bazë i SUSE — nuk e mbaj mend, mendoj se ishte rreth 1.1 ose 1.4 GB.
Instalojmë CEPH. Injorojmë versionin 12 në depot debian dhe lidhemi direkt nga faqja 15.2.3. Ndjekim udhëzimet nga seksioni 'instalojmë CEPH manualisht' me këto sqarime:
- Para se të lidhemi me depot, nevojitet të instalojmë gnupg wget ca-certificates.
- Pas lidhjes me depot, por para instalimit të klasterit, është lënë jashtë instalimi i pakove: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
- Në momentin e instalimit të CEPH, për arsye të paqartë, do të përpiqet të instalohet lvm2. Në parim, nuk është problem, por instalimi përfundon me dështim, kështu që CEPH gjithashtu nuk do të instalohet.
Ky patch ndihmoi:
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
Përmbledhja e klasterit
ceph-osd — merret për ruajtjen e të dhënave në disk. Për çdo disk aktivizohet një shërbim rrjeti që pranon dhe ekzekuton kërkesa për lexim ose shkruaj në objekte. Në disk krijohen dy partitë. Njëra përmban informacion mbi klasterin, numrin e diskut, si dhe çelësat për klasterin. Ky informacion prej 1KB krijohet një herë kur diskut i shtohet klasterit dhe nuk kam parë të ndryshojë kurrë. Në partinë e dytë nuk ka sistem skedari dhe ruhen të dhëna binarë të CEPH. Instalimi automatik në versionet e mëparshme krijonte një parti xfs me madhësi 100MB për informacionin ndihmës. Unë e kam konvertuar disku në MBR dhe kam alokuar vetëm 16MB — shërbimi nuk ankohet. Mendoj se xfs mund të zëvendësohet lehtësisht me ext. Kjo parti montohet në /var/lib/…, ku shërbimi lexon informacionin mbi OSD, si dhe gjen referencën për pajisjen bllokuese, ku ruhen të dhënat binarë. Teoriçtikisht, mund të vendosen ndihmësit menjëherë në /var/lib/…, ndërsa disku të alokuar plotësisht për të dhënat. Kur krijohet OSD përmes ceph-deploy, automatikisht krijohet një rregull për montimin e partis në /var/lib/…, si dhe caktohen të drejtat për përdoruesin ceph për të lexuar pajisjen bllokuese të nevojshme. Kur instalohet manualisht, kjo duhet bërë vetë, dokumentacioni nuk përmend diçka për këtë. Gjithashtu, është e dëshirueshme të përcaktohet parametri osd memory target, në mënyrë që të mjaftojë memorie fizike.
ceph-mds. Në nivelin e ulët, CEPH është një depo objektesh. Mundësia për ruajtjen me bllok përfundon në ruajtjen e secilit bllok prej 4MB si një objekt. E njëjta parim zbatohet për ruajtjen e skedarëve. Krijohen dy rezervuarë: një për metadatën dhe tjetri për të dhënat. Ata kombinohen në një sistem skedarësh. Në këtë moment krijohet një regjistrim, kështu që nëse fshin sistemin e skedarëve, por ruan të dy rezervuarët, atëherë nuk do të jetë e mundur ta rikthesh. Ekziston një procedurë për nxjerrjen e skedarëve sipas blloqeve, e cila nuk është testuar. Shërbimi ceph-mds është përgjegjës për qasjen në sistemin e skedarëve. Për çdo sistem skedarësh nevojitet një instancë e veçantë e shërbimit. Ka një opsion "indeks", i cili lejon krijimin e një versioni të disa sistemeve skedarësh në një — gjithashtu nuk është testuar.
сeph-mon — kyç i shërbimeve që ruan hartën e klasterit. Ajo përfshin informacion mbi të gjitha OSD-të, algoritmin e shpërndarjes PG në OSD dhe, më e rëndësishmja, informacion mbi të gjitha objektet (detajet e këtij mekanizmi nuk më janë të qarta: ka një katalog /var/lib/ceph/mon/.../store.db, ku ndodhet një skedar i madh — 26MB, dhe në klaster janë 105K objekte, duke dalë pak më shumë se 256 byte për objekt; mendoj se monitori ruan një listë të të gjitha objekteve dhe PG-ve në të cilat ato ndodhen). Dëmtimi i këtij katalogu çon në humbjen e të dhënave në të gjithë klasterin. Nga këtu, del që CRUSH tregon si janë pozicionuar PG-të në OSD, dhe si janë objektet pozicionuar në PG — ruhet në mënyrë qendrore brenda bazës së të dhënave, pavarësisht se si zhvilluesit tentojnë ta shmangin këtë fjalë. Si pasojë, në radhë të parë, nuk mund ta instalojmë sistemin në një USB në modalitetin RO, pasi në bazën e të dhënave ka regjistrime të vazhdueshme, kërkohet një disk shtesë për këto (me siguri jo më shumë se 1 GB); në radhë të dytë, është e nevojshme të kemi një kopje të kësaj baze në kohë reale. Nëse ka disa monitore, atëherë qëndrueshmëria sigurohet automatikisht, por në rastin tonë monitori është një, maksimumi — dy. Ka një procedurë teorike për rikuperimin e monitorit bazuar në të dhënat OSD, kam apeluar tri herë ndaj saj për arsye të ndryshme, dhe tri herë nuk kam marrë asnjë mesazh gabimi, ashtu si dhe të dhëna. Fatkeqësisht, ky mekanizëm nuk funksionon. Ose ne shfrytëzojmë një pjesë të vogël në OSD dhe krejt RAIDs për ruajtjen e bazës së të dhënave, çka padyshim do të ndikojë shumë negativisht në performancë, ose ndarim të paktën dy media fizike të sigurta, preferohet USB, për të mos bllokuar portet.
rados-gw — eksporton obiektive të ruajtjes përmes protokollit S3 dhe të ngjashëm. Krijon shumë grupe, pa ndonjë arsye të qartë. Nuk kam eksperimentuar shumë.
ceph-mgr — kur instalohet ky shërbim, aktivizohen disa module. Një prej tyre është autoscale-i, i cili nuk mund të ç’mungojë. Ai përpiqet të mbajë numrin e duhur të PG/OSD. Nëse dëshiron të menaxhosh proporcioni manualisht, mund të ndalosh përmasimin për çdo grup, por në këtë rast moduli dështojnë për shkak të ndarjes me 0 dhe statusi i klasterit bëhet ERROR. Moduli është shkruar në Python, dhe nëse e komentosh linjën e duhur, kjo çon në çaktivizimin e tij. Detajet më nuk kam dëshirë t’i kujtoj.
Lista e burimeve të përdorura:
Listinget e skriptave:
Instalimi i sistemit përmes debootstrap
blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
për i në {@,@var,@home}; bëj btrfs subvolume create $i; bërë
mkdir snapshot @/{var,home}
për i në {var,home}; bëj mount -o bind @${i} @/$i; bërë
debootstrap buster @ http://deb.debian.org/debian; echo $?
për i në {dev,proc,sys}; bëj mount -o bind /$i @/$i; bërë
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 6Krijimi i klasterit
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@rbd1Shtimi i OSD (pjesa)
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@$osdnumCurriculum Vitae
Avantazhi kryesor tregtar i CEPH është CRUSH - algoritmi për llogaritjen e vendndodhjes së të dhënave. Monitorët e shpërndajnë këtë algoritëm te klientët, pas së cilës klientët kërkojnë drejtpërdrejt nodin e nevojshëm dhe OSD-në përkatëse. CRUSH siguron mungesën e centralizimit. Ai përbëhet nga një skedar i vogël, i cili mund të printohet dhe të vishet në mur. Praktika ka treguar se CRUSH nuk është një hartë përfundimtare. Nëse shkatërrohen dhe riparohen monitorët, duke ruajtur të gjitha OSD-të dhe CRUSH-in, kjo nuk është e mjaftueshme për rikthimin e klasterit. Nga këtu, del se çdo monitor ruan disa metadata mbi të gjithë klasterin. Sasia e vogël e këtyre metadata-ve nuk vendos kufizime mbi madhësinë e klasterit, por kërkon të sigurojë ruajtjen e tyre, gjë që përjashton kursimin e hapësirës duke instaluar sistemin në një flash dhe përjashton klasterët me më pak se tre node. Politika agresive e zhvilluesit në lidhje me karakteristikat opsionale. Shumë larg minimalizmit. Dokumentacioni është në nivelin: "për atë që është, - faleminderit, por shumë, shumë skantë". Mundësia për të ndërvepruar me shërbimet në nivel të ulët është e parashikuar, por dokumentacioni e trajton këtë temë shumë sipërfaqësisht, prandaj është më shumë "jo" sesa "po". Praktikisht asnjë shans për rikuperimin e të dhënave nga një situatë jashtëzakonshme.
Opcioni të mëtejshëm: të heqim dorë nga CEPH dhe të përdorim një btrfs (ose xfs, zfs) të zakonshëm me disa disqe, të mësojmë informacione të reja rreth CEPH që do të lejonin përdorimin e tij në kushtet e caktuara, ose të praktikojmë duke shkruar një ruajtës të dhënash pas stërvitjes.
Burimi: habr.com
