Når der er flere data, end der er plads til på én disk, er det tid til at tænke på RAID. Som barn hørte jeg ofte fra mine ældre: "en dag vil RAID blive en saga blot, objektopbevaring vil oversvømme verden, og du ved ikke engang, hvad CEPH er," så det første i et selvstændigt liv oprettede din egen klynge. Formålet med eksperimentet var at stifte bekendtskab med den indre struktur af ceph og forstå rækkevidden af dens anvendelse. Hvor berettiget er indførelsen af ceph i en mellemstor virksomhed, men i en lille? Efter flere års drift og et par irreversible datatab opstod en forståelse for finesserne, at ikke alt er så simpelt. Egenskaber ved CEPH skaber hindringer for dens brede udbredelse, og på grund af dem er eksperimenter gået i stå. Nedenfor er en beskrivelse af alle de trin, der er taget, det opnåede resultat og de dragede konklusioner. Hvis kyndige mennesker vil dele deres erfaringer og forklare nogle punkter, vil jeg være taknemmelig.
Bemærk: Kommentatorer har påpeget alvorlige fejl i nogle af antagelserne, hvilket kræver en revision af hele artiklen.
CEPH strategi
CEPH-klyngen kombinerer et vilkårligt antal K af diske af vilkårlig størrelse og gemmer data på dem, og duplikerer hvert stykke (4 MB som standard) et givet antal N gange.
Overvej det enkleste tilfælde med to identiske diske. Du kan enten samle en RAID 1 eller en klynge med N=2 fra dem - resultatet bliver det samme. Hvis der er tre diske, og de er af forskellig størrelse, så er det nemt at samle en klynge med N=2: nogle af dataene vil være på diske 1 og 2, nogle på 1 og 3, og nogle på 2 og 3 , mens RAID ikke er det (du kan samle sådan et RAID, men det ville være en perversion). Hvis der er endnu flere diske, så er det muligt at oprette RAID 5, CEPH har en analog - erasure_code, som modsiger udviklernes tidlige koncepter, og derfor ikke overvejes. RAID 5 antager, at der er et lille antal diske, og alle er i god stand. Hvis en fejler, skal resten holde ud, indtil disken er udskiftet, og data er gendannet til den. CEPH, med N>=3, opfordrer til brug af gamle diske, især hvis du beholder flere gode diske til at gemme en kopi af data, og gemmer de resterende to eller tre kopier på et stort antal gamle diske, så vil være sikkert, for nu er nye diske i live - der er ingen problemer, og hvis en af dem går i stykker, er det ekstremt usandsynligt, at tre diske med en levetid på mere end fem år, helst fra forskellige servere, går i stykker samtidigt. begivenhed.
Der er en subtilitet i distributionen af kopier. Som standard antages det, at dataene er opdelt i flere (~100 pr. disk) PG-distributionsgrupper, som hver er duplikeret på nogle diske. Antag at K=6, N=2, så hvis to diske fejler, er data garanteret tabt, da der ifølge sandsynlighedsteorien vil være mindst én PG, der vil være placeret på disse to diske. Og tabet af én gruppe gør alle data i puljen utilgængelige. Hvis diskene er opdelt i tre par og kun får lov til at lagre data på diske inden for et par, så er en sådan fordeling også modstandsdygtig over for fejl på en disk, men hvis to fejler, er sandsynligheden for datatab ikke 100 %, men kun 3/15, og selv i tilfælde af fejl tre diske - kun 12/20. Derfor bidrager entropi i datadistribution ikke til fejltolerance. Bemærk også, at for en filserver øger fri RAM i høj grad reaktionsevnen. Jo mere hukommelse i hver node, og jo mere hukommelse i alle noder, jo hurtigere vil den være. Dette er uden tvivl fordelen ved en klynge frem for en enkelt server og desuden en hardware NAS, hvor der er indbygget en meget lille mængde hukommelse.
Det følger heraf, at CEPH er en god måde at skabe et pålideligt lagringssystem til snesevis af TB med mulighed for skalering med minimal investering fra forældet udstyr (her vil der naturligvis være behov for omkostninger, men små sammenlignet med kommercielle lagringssystemer).
Klyngeimplementering
Til eksperimentet, lad os tage en nedlagt computer Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Vi organiserer fire 2 TB diske i noget som RAID10, efter en vellykket test vil vi tilføje en anden node og det samme antal diske.
Installer Linux. Distributionen skal være tilpasselig og stabil. Debian og Suse opfylder kravene. Suse har et mere fleksibelt installationsprogram, der giver dig mulighed for at deaktivere enhver pakke; Desværre kunne jeg ikke forstå hvilke der kan smides ud uden skader på systemet. Installer Debian via debootstrap buster. Min-base-indstillingen installerer et ikke-fungerende system, der mangler drivere. Forskellen i størrelse i forhold til den fulde version er ikke så stor, at den generer. Da arbejdet foregår på en fysisk maskine, vil jeg gerne tage snapshots, ligesom på virtuelle maskiner. Enten LVM eller btrfs (eller xfs eller zfs - forskellen er ikke stor) giver en sådan mulighed. Snapshots er ikke LVM's stærke side. Installer btrfs. Og bootloaderen er i MBR. Det giver ingen mening at tilstoppe en 50 MB disk med en FAT-partition, når du kan skubbe den ind i et 1 MB partitionstabelområde og allokere al pladsen til systemet. Det tog 700 MB på disken. Hvor meget basisinstallationen af SUSE har - jeg kan ikke huske, det ser ud til, omkring 1.1 eller 1.4 GB.
Installer CEPH. Vi ignorerer version 12 i debian-depotet og opretter forbindelse direkte fra webstedet 15.2.3. Vi følger instruktionerne fra afsnittet "Manuel installation af CEPH" med følgende forbehold:
- Før du forbinder depotet, skal du installere gnupg wget ca-certifikater
- Efter tilslutning af repository, men før installation af klyngen, udelades pakkeinstallation: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- På tidspunktet for installationen af CEPH vil den af ukendte årsager forsøge at installere lvm2. I princippet er det ikke ærgerligt, men installationen fejler, så CEPH vil heller ikke installere.
Denne patch hjalp:
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
Klyngeoversigt
ceph-osd - ansvarlig for lagring af data på disk. For hver disk startes en netværkstjeneste, der accepterer og udfører anmodninger om at læse eller skrive til objekter. Der oprettes to partitioner på disken. En af dem indeholder oplysninger om klyngen, disknummeret og klyngenøgler. Denne 1KB-information oprettes én gang, når du tilføjer en disk, og har aldrig bemærket, at den ændrer sig igen. Den anden partition har intet filsystem og gemmer binære CEPH-data. Automatisk installation i tidligere versioner oprettede en 100MB xfs-partition til serviceoplysninger. Jeg konverterede disken til MBR og tildelte kun 16MB - tjenesten klager ikke. Jeg tror, uden problemer, xfs kunne erstattes med ext. Denne partition er monteret i /var/lib/…, hvor tjenesten læser information om OSD'en og også finder et link til blokenheden, hvor de binære data er gemt. Teoretisk set kan du med det samme placere hjælpeprogrammer i / var / lib / ... og allokere hele disken til data. Når du opretter en OSD via ceph-deploy, oprettes der automatisk en regel for at montere en partition i /var/lib/…, og rettighederne til ceph-brugeren tildeles til at læse den ønskede blokenhed. Med en manuel installation skal du gøre dette selv, dokumentationen siger ikke om det. Det er også tilrådeligt at specificere osd-hukommelsesmålparameteren, så der er tilstrækkelig fysisk hukommelse.
ceph-mds. På et lavt niveau er CEPH objektopbevaring. Bloklagringskapaciteten koger ned til at gemme hver 4MB blok som et objekt. Fillagring fungerer efter samme princip. Der oprettes to puljer: en til metadata, den anden til data. De er kombineret til et filsystem. I dette øjeblik oprettes en form for post, så hvis du sletter filsystemet, men gemmer begge puljer, vil du ikke være i stand til at gendanne det. Der er en procedure til at udpakke filer i blokke, jeg har ikke testet den. ceph-mds-tjenesten er ansvarlig for at få adgang til filsystemet. Hvert filsystem kræver en separat forekomst af tjenesten. Der er en "indeks" mulighed, der giver dig mulighed for at skabe et udseende af flere filsystemer i ét - heller ikke testet.
ceph-mon - Denne service holder et kort over klyngen. Det inkluderer information om alle OSD'er, PG-distributionsalgoritmen i OSD'en og, vigtigst af alt, information om alle objekter (detaljerne i denne mekanisme er ikke klare for mig: der er en /var/lib/ceph/mon/…/ store.db-biblioteket, det indeholder en stor fil er 26MB, og i en klynge på 105K objekter viser det sig lidt mere end 256 bytes pr. objekt - jeg tror, at skærmen fører en liste over alle objekter og den PG, de lyver). Beskadigelse af denne mappe resulterer i tab af alle data i klyngen. Herfra blev det konkluderet, at CRUSH viser, hvordan PG'er er placeret ifølge OSD, og hvordan objekter er placeret ifølge PG - de er centralt gemt inde i databasen, uanset hvordan udviklerne undgår dette ord. Som et resultat kan vi for det første ikke installere systemet på et flashdrev i RO-tilstand, da databasen konstant skrives til, en ekstra disk er nødvendig til disse (næppe mere end 1 GB), og for det andet er det nødvendigt at have en realtidskopi af denne base. Hvis der er flere skærme, leveres fejltolerance automatisk, men i vores tilfælde er der kun én skærm, maksimalt to. Der er en teoretisk procedure til at gendanne en skærm baseret på OSD-data, jeg tyede til det tre gange af forskellige årsager, og tre gange ingen fejlmeddelelser, såvel som data. Desværre virker denne mekanisme ikke. Enten betjener vi en miniature OSD-partition og samler et RAID til at gemme databasen, hvilket sandsynligvis vil have en meget dårlig effekt på ydeevnen, eller også allokerer vi mindst to pålidelige fysiske medier, gerne USB, så portene ikke fylder.
rados-gw - eksporterer objektlager ved hjælp af S3-protokollen og lignende. Skaber en masse pools, det er ikke klart hvorfor. Eksperimenterede ikke rigtig.
ceph-mgr - Installation af denne service starter flere moduler. En af dem er den ikke-deaktiverede autoskalering. Den stræber efter at opretholde det korrekte antal PG/OSD'er. Hvis du vil styre forholdet manuelt, kan du deaktivere skalering for hver pulje, men i dette tilfælde falder modulet med en division med 0, og klyngestatus bliver FEJL. Modulet er skrevet i python, og hvis du kommenterer den nødvendige linje i det, fører dette til dets nedlukning. For doven til at huske detaljerne.
Liste over anvendte kilder:
Script lister:
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 << 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 6Opret en 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 << 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@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@$osdnumResumé
Den største markedsføringsfordel ved CEPH er CRUSH, en algoritme til at beregne placeringen af data. Monitorer udbreder denne algoritme til klienter, hvorefter klienter direkte anmoder om den ønskede node og den ønskede OSD. CRUSH giver ingen centralisering. Det er en lille fil, som du selv kan printe og hænge på væggen. Praksis har vist, at CRUSH ikke er et udtømmende kort. At ødelægge og genskabe skærme, mens alle OSD'er og CRUSH bevares, er ikke nok til at genoprette klyngen. Ud fra dette konkluderes det, at hver monitor gemmer nogle metadata om hele klyngen. Den ubetydelige mængde af disse metadata pålægger ikke begrænsninger for klyngens størrelse, men det kræver deres sikkerhed, hvilket eliminerer diskbesparelser på grund af installation af systemet på et flashdrev og udelukker klynger med mindre end tre noder. Aggressiv udviklerpolitik vedrørende valgfrie funktioner. Langt fra minimalisme. Dokumentation på niveauet: "tak for hvad det er, men meget, meget sølle." Muligheden for at interagere med tjenester på et lavt niveau er givet, men dokumentationen er for overfladisk om dette emne, så mere sandsynligt nej end ja. Stort set ingen chance for at gendanne data fra en nødsituation.
Muligheder for yderligere handling: forlad CEPH og brug de banale multi-disk btrfs (eller xfs, zfs), lær ny information om CEPH, som giver dig mulighed for at betjene den under de specificerede forhold, prøv at skrive din egen lagring som en avanceret træning .
Kilde: www.habr.com