Når dataene bliver mere, end hvad der kan være på én disk, er det tid til at overveje RAID. I min barndom hørte jeg ofte de ældre sige: "Engang vil RAID gå i glemmebogen, object storage vil tage over verden, og du ved ikke engang, hvad CEPH er," - derfor blev det første, jeg gjorde i mit selvstændige liv, at skabe mit eget cluster. Målet med eksperimentet var at forstå de interne mekanismer i Ceph og finde ud af rammerne for dets anvendelse. Hvor berettiget er implementeringen af Ceph i mellemstore virksomheder, og i små? Efter flere års drift og et par uoprettelige datatab kom forståelsen af nuancerne, at ikke alt er så entydigt. Egenskaberne ved CEPH skaber hindringer for dets brede udbredelse, og på grund af dem er eksperimenterne gået i stå. Nedenfor beskrives alle de gennemgåede trin, de opnåede resultater og de konklusioner, der er draget. Hvis kyndige personer deler deres erfaring og forklarer nogle punkter - ville jeg være taknemmelig.
Bemærk: Kommentatorer har påpeget alvorlige fejl i nogle af antagelserne, som kræver, at hele artiklen bliver genovervejet.
CEPH-strategi
CEPH-clusteret samler et vilkårligt antal K diske af vilkårlig størrelse og opbevarer data på dem ved at duplikere hver bid (4 MB som standard) et bestemt antal N gange.
Lad os overveje det enkleste tilfælde med to identiske diske. Man kan enten assemble en RAID 1 eller en klynge med N=2 - resultatet vil være det samme. Hvis der er tre diske, og de er af forskellig størrelse, er det nemt at lave en klynge med N=2: en del data vil være på disk 1 og 2, en del vil være på 1 og 3, og en del vil være på 2 og 3, mens RAID ikke vil kunne håndtere det (det er muligt at sammensætte sådan en RAID, men det ville være en underlig løsning). Hvis der er endnu flere diske, kan man oprette RAID 5, og CEPH har en tilsvarende funktion - erasure_code, som modsiger de tidlige koncepter udviklerne havde, og derfor bliver det ikke betragtet. RAID 5 forudsætter, at der er et lille antal diske, og at alle er i god stand. Ved en fejl skal de øvrige holde indtil den defekte disk bliver udskiftet, og dataene kan genoprettes på den. CEPH, derimod, med N>=3, tilskynder brugen af gamle diske, især hvis man har flere gode diske til opbevaring af én kopi af dataene, mens de to-tre resterende kopier opbevares på mange gamle diske, så informationerne forbliver sikre, da så længe de nye diske fungerer - der er ikke noget problem, og hvis en af dem går i stykker, så er samtidig svigt af tre diske med en levetid på over fem år, helst fra forskellige servere - en ekstremt usandsynlig hændelse.
Der er en nuance i distributionen af kopier. Som standard antages det, at data deles i et større antal (~100 pr. disk) distributionsgrupper i PG, hver af hvilke duplicaeres på nogle diske. Antag, at K=6, N=2, så ved nedbrud af to vilkårlige diske garanteret der tabes data, da der ifølge sandsynlighedsteori vil være mindst én PG, der vil ligge på disse to diske. Og tabet af en gruppe gør alle data i puljen utilgængelige. Hvis diske opdeles i tre par og tillades at gemme data kun på diske inden for et enkelt par, vil denne distribution også være modstandsdygtig over for nedbrud af en hvilken som helst disk, mens sandsynligheden for datatab ved nedbrud af to vil kun være 3/15, og selv ved nedbrud af tre diske — kun 12/20. Heraf kan vi konkludere, at entropien i datafordelingen ikke bidrager til fejltolerance. Vi skal også bemærke, at for en filserver øger fri RAM-hukommelse betydeligt responstiden. Jo mere hukommelse der er i hver node, og jo mere hukommelse der er i alle noder — jo hurtigere vil det være. Dette er uden tvivl en fordel ved et cluster i forhold til en enkelt server, og endnu mere i forhold til en hardware NAS, der indeholder en meget lille mængde hukommelse.
Heraf følger det, at CEPH er en god måde at skabe et pålideligt datalagringssystem på tiere TB med minimal investering af forældet udstyr med skaleringsmuligheder (der vil selvfølgelig være omkostninger her, men de vil være små sammenlignet med kommercielle SAN'er).
Implementering af kluster
Til eksperimentet tager vi en kasseret computer Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Vi organiserer fire diske på 2 TB i en lignende RAID10, og efter en vellykket test tilføjer vi den anden node og lige så mange diske til.
Installer Linux. Distributionen skal have muligheder for tilpasning og stabilitet. Debian og Suse opfylder kravene. Suse har en mere fleksibel installationsprogram, som tillader at deaktiverer eventuelle pakker; desværre kunne jeg ikke finde ud af, hvilke der kunne udelades uden at skade systemet. Vi installerer Debian via debootstrap buster. Indstillingen min-base installerer et ikke-fungerende system, hvor der mangler drivere. Forskellen i størrelse i forhold til den fulde version er ikke så stor, at det er værd at bekymre sig. Da arbejdet udføres på en fysisk maskine, ønsker man at lave snapshots, som på virtuelle maskiner. Denne mulighed tilbydes enten af LVM eller btrfs (eller xfs, eller zfs — forskellen er ikke stor). LVM's snapshots er ikke en stærk side. Vi vælger btrfs. Og bootloaderen — i MBR. Der er ingen grund til at fylde disken op med en 50 MB partition med FAT, når den kan presses ind i et 1 MB område af partitionstabellen, og hele pladsen kan tildeles systemet. Det tog 700 MB på disken. Hvor meget en grundinstallation af SUSE fylder — husker jeg ikke, det var omkring 1.1 eller 1.4 GB.
Installerer CEPH. Ignorer version 12 i debian-repositoriet og tilslut direkte fra hjemmesiden 15.2.3. Følg instruktionerne i afsnittet "installér CEPH manuelt" med følgende bemærkninger:
- Før tilslutning af repositoriet skal gnupg wget ca-certificates installeres.
- Efter tilslutningen af repositoriet, men før installation af klyngen, er installationspakkerne udeladt: apt -y —no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
- Ved installationen af CEPH vil lvm2 af ukendte årsager forsøge at installere. I princippet er det ikke et problem, men installationen mislykkes, så CEPH kan heller ikke installeres.
Denne patch hjalp:
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
Oversigt over klyngen
ceph-osd ansvarer for datalagring på disken. For hver disk startes en netværkstjeneste, der modtager og udfører anmodninger om læsning eller skrivning til objekter. Der oprettes to partitioner på disken. En af dem indeholder information om klyngen, disknummeret samt nøgler til klyngen. Denne information på 1 KB oprettes én gang, når disken tilføjes, og jeg har aldrig bemærket, at den ændres. På den anden partition er der ikke noget filsystem, og der opbevares binære data fra CEPH. Den automatiske installation i tidligere versioner oprettede en xfs-partition på 100 MB til serviceinformation. Jeg har konverteret disken til MBR og tildelt kun 16 MB – tjenesten klager ikke. Jeg tænker, at xfs også kunne erstattes med ext uden problemer. Denne partition monteres i /var/lib/…, hvor tjenesten læser oplysninger om OSD, og finder også henvisningen til blokenheden, hvor de binære data opbevares. Teoretisk set kunne de straks placeres i /var/lib/…, og disken helt og holdent tildeles til data. Når OSD oprettes via ceph-deploy, oprettes der automatisk en regel for montering af partitionen i /var/lib/…, og der tildeles læserettigheder til brugeren ceph for den nødvendige blokenhed. Under manuel installation skal dette gøres selv, det står ikke i dokumentationen. Det er også ønskeligt at angive parameteren osd memory target, så der er nok fysisk hukommelse.
ceph-mds. På et lavt niveau er CEPH et objektholdingssystem. Muligheden for bloklagring reduceres til at gemme hver 4 MB blok som et objekt. Filopbevaring fungerer på samme måde. Der oprettes to puljer: en til metadata og en til data. De kombineres i et filsystem. I dette øjeblik oprettes en eller anden post, så hvis du sletter filsystemet, men bevarer begge puljer, kan det ikke genskabes. Der er en procedure til at udtrække filer efter blokke, som jeg ikke har testet. Tjenesten ceph-mds er ansvarlig for adgangen til filsystemet. Der kræves en separat instans af tjenesten for hvert filsystem. Der er en
ceph-mon er denne tjeneste, der opbevarer kortet over klyngen. Det indeholder oplysninger om alle OSD'er, algoritmen til distribution af PG i OSD'er og, vigtigst af alt, oplysninger om alle objekter (detaljerne i denne mekanisme er uklare for mig: der er et katalog /var/lib/ceph/mon/.../store.db, hvor der ligger en stor fil — 26 MB, og der er 105.000 objekter i klyngen, hvilket giver lidt over 256 byte pr. objekt — jeg tror, at monitoren gemmer listen over alle objekter og de PG'er, de ligger i). Beskadigelse af dette katalog fører til tab af alle data i klyngen. Heraf følger, at CRUSH viser, hvordan PG'er er fordelt på OSD'er, mens objekter er centralt gemt inden for databasen, uanset hvor meget udviklerne forsøger at undgå dette ord. Som følge heraf kan vi for det første ikke installere systemet på en USB-nøgle i RO-tilstand, da der konstant skrives til databasen; der kræves en ekstra disk til disse (sandsynligvis ikke mere end 1 GB). For det andet er det nødvendigt at have en kopi af denne database i realtid. Hvis der er flere monitorer, så sikres fejltolerance automatisk, men i vores tilfælde er der kun én monitor, maksimum to. Der er en teoretisk procedure for at genskabe monitoren på baggrund af OSD-data; jeg har benyttet mig af den tre gange af forskellige årsager, og der har ikke været nogen fejlmeddelelser, ligesom der heller ikke har været nogen data. Desværre fungerer denne mekanisme ikke. Enten udnytter vi et mini-partition på OSD og opbygger RAID til opbevaring af databasen, hvilket helt sikkert vil påvirke ydeevnen negativt, eller også allokerer vi mindst to pålidelige fysiske medier, helst USB, for ikke at optage porter.
rados-gw eksporterer objektlagring via S3-protokollen og lignende. Det opretter mange puljer, men jeg forstår ikke helt hvorfor. Jeg har ikke eksperimenteret meget.
ceph-mgr aktiverer flere moduler ved installation af denne tjeneste. Et af dem er autoscale, som ikke kan deaktiveres. Det stræber efter at opretholde det korrekte antal PG'er/OSD'er. Hvis man ønsker at styre forholdet manuelt, kan man forhindre skalering for hver pulje, men så vil modulet crashe med division med nul, og klyngens status bliver ERROR. Modulet er skrevet i Python, og hvis man kommenterer den nødvendige linje ud i det, vil det medføre, at det deaktiveres. Detaljerne gider jeg ikke huske.
Liste over anvendte kilder:
Script-uddrag:
Installation af systemet via 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 6Oprettelse af klynge
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@rbd1Tilføjelse af OSD (del)
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@$osdnumCV
Den vigtigste markedsføringsfordel ved CEPH er CRUSH — algoritmen til dataplacering. Monitorer distribuerer denne algoritme til kunderne, hvorefter kunderne direkte anmoder om den ønskede knude og den ønskede OSD. CRUSH sikrer fraværet af centralisering. Det er en lille fil, som man endda kan printe og hænge op på væggen. Praksis har vist, at CRUSH ikke er et udtømmende kort. Hvis man ødelægger og genskaber monitorerne, mens man bevarer alle OSD'er og CRUSH, er det ikke tilstrækkeligt til at genskabe klyngen. Heraf kan vi konkludere, at der på hver monitor opbevares nogle metadata om hele klyngen. Den lille mængde metadata lægger ikke begrænsninger på klyngens størrelse, men kræver, at de opbevares sikkert, hvilket udelukker at spare plads ved at installere systemet på et USB-drev og udelukker klynger med færre end tre knuder. En aggressiv politik fra udviklerens side vedrørende valgfri funktioner. Langt fra minimalisme. Dokumentationen er på niveauet: 'tak for det, der er, men det er meget, meget sparsomt'. Muligheden for at interagere med lavniveau-tjenester er til stede, men dokumentationen berører alt for overfladisk dette emne, så det er mere sandsynligt, at svaret er nej end ja. Næsten ingen chancer for at genskabe data fra nødsituationer.
Muligheder for videre handling: at opgive CEPH og benytte et banalt multiskiver btrfs (eller xfs, zfs), at finde ny information om CEPH, som gør det muligt at udnytte det under de givne forhold, eller at forsøge at skrive sit eget lager som en kompetenceudvikling.
Kilde: habr.com
