Når det er mer data enn det som får plass på én disk, er det på tide å tenke på RAID. Som barn hørte jeg ofte fra mine eldste: "en dag vil RAID være en ting fra fortiden, gjenstandslagring vil fylle verden, og du vet ikke engang hva CEPH er," så det første i mitt uavhengige liv var å lage min egen klynge. Hensikten med eksperimentet var å bli kjent med den interne strukturen til ceph og forstå omfanget av dens anvendelse. Hvor berettiget er implementeringen av ceph i mellomstore bedrifter og i små bedrifter? Etter flere års drift og et par irreversible datatap oppsto en forståelse av forviklingene om at ikke alt er så enkelt. Det særegne ved CEPH utgjør hindringer for dens utbredte adopsjon, og på grunn av dem har eksperimenter nådd en blindvei. Nedenfor er en beskrivelse av alle trinnene som er tatt, resultatet som er oppnådd og konklusjonene som er trukket. Hvis kunnskapsrike folk deler sine erfaringer og forklarer noen punkter, vil jeg være takknemlig.
Merk: Kommentatorer har identifisert alvorlige feil i noen av forutsetningene som krever revisjon av hele artikkelen.
CEPH-strategi
CEPH-klyngen kombinerer et vilkårlig antall K med disker av vilkårlig størrelse og lagrer data på dem, og dupliserer hvert stykke (4 MB som standard) et gitt antall N ganger.
La oss vurdere det enkleste tilfellet med to identiske disker. Fra dem kan du enten sette sammen RAID 1 eller en klynge med N=2 - resultatet blir det samme. Hvis det er tre disker og de er av forskjellige størrelser, er det enkelt å sette sammen en klynge med N=2: noen av dataene vil være på disk 1 og 2, noen vil være på disk 1 og 3, og noen vil være på 2 og 3, mens RAID ikke vil (du kan sette sammen en slik RAID, men det ville være en perversjon). Hvis det er enda flere disker, er det mulig å lage RAID 5; CEPH har en analog - erasure_code, som motsier de tidlige konseptene til utviklerne, og derfor ikke vurderes. RAID 5 antar at det er et lite antall stasjoner, som alle er i god stand. Hvis en feiler, må de andre holde ut til disken er skiftet ut og dataene er gjenopprettet til den. CEPH, med N>=3, oppfordrer til bruk av gamle disker, spesielt hvis du har flere gode disker for å lagre én kopi av data, og lagrer de resterende to eller tre kopiene på et stort antall gamle disker, vil informasjonen vil være trygt, siden nye disker er i live - det er ingen problemer, og hvis en av dem går i stykker, er det ekstremt usannsynlig at tre disker med en levetid på mer enn fem år, helst fra forskjellige servere, samtidig feiler. begivenhet.
Det er en subtilitet ved distribusjonen av kopier. Som standard antas det at dataene er delt inn i flere (~100 per disk) PG-distribusjonsgrupper, som hver er duplisert på noen disker. La oss si K=6, N=2, så hvis noen av to disker feiler, vil data garantert gå tapt, siden det ifølge sannsynlighetsteorien vil være minst én PG som vil være plassert på disse to diskene. Og tapet av én gruppe gjør alle dataene i bassenget utilgjengelige. Hvis diskene er delt inn i tre par og data kun tillates lagret på disker innenfor ett par, er en slik distribusjon også motstandsdyktig mot feil på en disk, men hvis to disker feiler, er sannsynligheten for tap av data ikke. 100%, men bare 3/15, og selv i tilfelle feil tre disker - bare 12/20. Derfor bidrar ikke entropi i datadistribusjon til feiltoleranse. Vær også oppmerksom på at for en filserver øker ledig RAM responshastigheten betydelig. Jo mer minne i hver node, og jo mer minne i alle noder, jo raskere vil det være. Dette er utvilsomt en fordel med en klynge fremfor en enkelt server, og enda mer, en maskinvare-NAS, hvor en svært liten mengde minne er innebygd.
Det følger at CEPH er en god måte å lage et pålitelig datalagringssystem for titalls TB med mulighet til å skalere med minimal investering fra utdatert utstyr (her vil det selvfølgelig kreves kostnader, men små sammenlignet med kommersielle lagringssystemer).
Klyngeimplementering
For eksperimentet, la oss ta en utrangert datamaskin Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Vi vil organisere fire 2 TB disker i noe som RAID10, etter en vellykket test vil vi legge til en ny node og samme antall disker.
Installerer Linux. Distribusjonen krever evne til å tilpasse og være stabil. Debian og Suse oppfyller kravene. Suse har et mer fleksibelt installasjonsprogram som lar deg deaktivere enhver pakke; Dessverre kunne jeg ikke finne ut hvilke som kunne kastes uten å skade systemet. Installer Debian ved å bruke debootstrap buster. Alternativet min-base installerer et ødelagt system som mangler drivere. Forskjellen i størrelse sammenlignet med fullversjonen er ikke så stor at den plager. Siden arbeidet utføres på en fysisk maskin, ønsker jeg å ta øyeblikksbilder, som på virtuelle maskiner. Dette alternativet leveres av enten LVM eller btrfs (eller xfs eller zfs - forskjellen er ikke stor). LVM-øyeblikksbilder er ikke en sterk side. Installer btrfs. Og bootloaderen er i MBR. Det er ingen vits i å rote en 50 MB disk med en FAT-partisjon når du kan skyve den inn i et 1 MB partisjonstabellområde og allokere all plass til systemet. Tok opp 700 MB på disken. Jeg husker ikke hvor mye den grunnleggende SUSE-installasjonen har, jeg tror det er omtrent 1.1 eller 1.4 GB.
Installer CEPH. Vi ignorerer versjon 12 i debian-depotet og kobler oss direkte fra 15.2.3-siden. Vi følger instruksjonene fra avsnittet "Installer CEPH manuelt" med følgende forbehold:
- Før du kobler til depotet, må du installere gnupg wget ca-sertifikater
- Etter tilkobling av depotet, men før du installerer klyngen, utelates installasjonspakker: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Når du installerer CEPH, av ukjente årsaker, vil den prøve å installere lvm2. I prinsippet er det ikke synd, men installasjonen feiler, så CEPH vil heller ikke installere.
Denne patchen 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
Klyngeoversikt
ceph-osd - er ansvarlig for å lagre data på disk. For hver disk lanseres en nettverkstjeneste som aksepterer og utfører forespørsler om å lese eller skrive til objekter. To partisjoner er opprettet på disken. En av dem inneholder informasjon om klyngen, disknummeret og nøklene til klyngen. Denne 1KB-informasjonen opprettes én gang når du legger til en disk og har aldri blitt lagt merke til å endre seg. Den andre partisjonen har ikke noe filsystem og lagrer binære CEPH-data. Automatisk installasjon i tidligere versjoner opprettet en 100MB xfs-partisjon for tjenesteinformasjon. Jeg konverterte disken til MBR og tildelte bare 16MB - tjenesten klager ikke. Jeg tror xfs kan erstattes med ext uten problemer. Denne partisjonen er montert i /var/lib/…, der tjenesten leser informasjon om OSD-en og også finner en referanse til blokkenheten der de binære dataene er lagret. Teoretisk sett kan du umiddelbart plassere hjelpefiler i /var/lib/…, og allokere hele disken for data. Når du oppretter en OSD via ceph-deploy, opprettes det automatisk en regel for å montere partisjonen i /var/lib/…, og ceph-brukeren tildeles også rettigheter til å lese ønsket blokkenhet. Hvis du installerer manuelt, må du gjøre dette selv, dokumentasjonen sier ikke dette. Det er også tilrådelig å spesifisere osd minnemålparameteren slik at det er nok fysisk minne.
ceph-mds. På et lavt nivå er CEPH objektlagring. Blokklagringskapasitet koker ned til å lagre hver 4MB blokk som et objekt. Fillagring fungerer etter samme prinsipp. To bassenger opprettes: en for metadata, den andre for data. De er kombinert til et filsystem. I dette øyeblikket opprettes en slags post, så hvis du sletter filsystemet, men beholder begge bassengene, vil du ikke kunne gjenopprette det. Det er en prosedyre for å pakke ut filer etter blokker, jeg har ikke testet den. Tjenesten ceph-mds er ansvarlig for tilgang til filsystemet. Hvert filsystem krever en separat forekomst av tjenesten. Det er et "indeks" -alternativ, som lar deg lage utseendet til flere filsystemer i ett - heller ikke testet.
Ceph-mon - Denne tjenesten lagrer et kart over klyngen. Den inkluderer informasjon om alle OSD-er, en algoritme for å distribuere PG-er i OSD-er og, viktigst av alt, informasjon om alle objekter (detaljene i denne mekanismen er ikke klare for meg: det er en katalog /var/lib/ceph/mon/…/ store.db, den inneholder en stor fil er 26MB, og i en klynge på 105K objekter viser det seg å være litt over 256 byte per objekt - jeg tror at monitoren lagrer en liste over alle objekter og PG-ene som de er plassert). Skade på denne katalogen resulterer i tap av alle data i klyngen. Derfor ble konklusjonen trukket at CRUSH viser hvordan PG-er er plassert på OSD-en, og hvordan objekter er plassert på PG-er - de er sentralt lagret i databasen, uansett hvor mye utviklerne unngår dette ordet. Som et resultat kan vi for det første ikke installere systemet på en flash-stasjon i RO-modus, siden databasen stadig blir registrert, er det nødvendig med en ekstra disk for disse (neppe mer enn 1 GB), for det andre er det nødvendig å ha en kopier denne basen i sanntid. Hvis det er flere skjermer, sikres feiltoleranse automatisk, men i vårt tilfelle er det kun én skjerm, maksimalt to. Det er en teoretisk prosedyre for å gjenopprette en skjerm basert på OSD-data, jeg brukte den tre ganger av forskjellige grunner, og tre ganger var det ingen feilmeldinger, så vel som ingen data. Dessverre fungerer ikke denne mekanismen. Enten opererer vi en miniatyrpartisjon på OSD-en og setter sammen en RAID for å lagre databasen, noe som helt sikkert vil ha en veldig dårlig effekt på ytelsen, eller så tildeler vi minst to pålitelige fysiske medier, helst USB, for ikke å okkupere porter.
rados-gw - eksporterer objektlagring via S3-protokollen og lignende. Skaper mange bassenger, det er uklart hvorfor. Jeg eksperimenterte ikke mye.
ceph-mgr - Når du installerer denne tjenesten, lanseres flere moduler. En av dem er autoskalering som ikke kan deaktiveres. Den streber etter å opprettholde riktig mengde PG/OSD. Hvis du vil kontrollere forholdet manuelt, kan du deaktivere skalering for hver pool, men i dette tilfellet krasjer modulen med en divisjon på 0, og klyngestatusen blir FEIL. Modulen er skrevet i Python, og hvis du kommenterer den nødvendige linjen i den, fører dette til at den deaktiveres. For lat til å huske detaljene.
Liste over kilder som er brukt:
Skriptoppføringer:
Installere 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 6Lag 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@rbd1Legger til 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@$osdnumOppsummering
Den viktigste markedsføringsfordelen med CEPH er CRUSH - en algoritme for å beregne plasseringen av data. Monitorer distribuerer denne algoritmen til klienter, hvoretter klienter direkte ber om ønsket node og ønsket OSD. CRUSH sikrer ingen sentralisering. Det er en liten fil som du til og med kan skrive ut og henge på veggen. Praksis har vist at CRUSH ikke er et omfattende kart. Hvis du ødelegger og gjenskaper monitorene, mens alle OSD og CRUSH beholdes, er ikke dette nok til å gjenopprette klyngen. Fra dette konkluderes det at hver monitor lagrer noen metadata om hele klyngen. Den lille mengden av disse metadataene pålegger ikke begrensninger på størrelsen på klyngen, men krever at sikkerheten deres sikres, noe som eliminerer diskbesparelser ved å installere systemet på en flash-stasjon og ekskluderer klynger med mindre enn tre noder. Utviklerens aggressive policy angående valgfrie funksjoner. Langt fra minimalisme. Dokumentasjonen er på nivået "takk for det vi har, men det er veldig, veldig mager." Muligheten til å samhandle med tjenester på et lavt nivå er gitt, men dokumentasjonen berører dette emnet for overfladisk, så det er mer sannsynlig et nei enn et ja. Det er praktisk talt ingen sjanse for å gjenopprette data fra en nødsituasjon.
Alternativer for ytterligere handling: forlat CEPH og bruk de banale multi-disk btrfs (eller xfs, zfs), finn ut ny informasjon om CEPH, som lar deg betjene den under de angitte forholdene, prøv å skrive din egen lagring som en avansert opplæring.
Kilde: www.habr.com