NÄr dataene overstiger kapasiteten til en enkelt disk, er det pÄ tide Ä vurdere RAID. Jeg hÞrte ofte fra de eldre i barndommen: «En dag vil RAID gÄ ut pÄ dato, objektlagring vil fylle verden, og du vet ikke engang hva CEPH er,» sÄ det fÞrste jeg gjorde i mitt voksne liv var Ä opprette min egen klynge. MÄlet med eksperimentet var Ä bli kjent med den interne strukturen i ceph og forstÄ omfanget av bruken. I hvilken grad er implementeringen av ceph berettiget i mellomstor virksomhet, og i smÄ? Etter flere Ärs drift og et par uopprettelige datatap, fikk jeg en forstÄelse av nyansene; ikke alt er sÄ entydig. Egenskaper ved CEPH skaper hindringer for bred distribusjon, og pÄ grunn av dem har eksperimentene stagnert. Nedenfor er en beskrivelse av alle gjennomgÄtte trinn, de oppnÄdde resultatene og konklusjonene. Hvis erfarne personer deler sine erfaringer og forklarer noen punkter, ville jeg vÊrt takknemlig.
Merk: Kommentatorer har pÄpekt alvorlige feil i noen antagelser som krever en revidering av hele artikkelen.
CEPH-strategi
CEPH-klyngen samler et vilkÄrlig antall K disker av vilkÄrlig stÞrrelse og lagrer data pÄ dem, mens hvert stykke (4 MB som standard) dupliseres N ganger.
La oss se pĂ„ det enkleste tilfellet med to identiske disker. Fra disse kan man enten sette sammen RAID 1, eller en klynge med N=2 â resultatet blir det samme. Hvis det er tre disker, og de har ulik stĂžrrelse, er det lett Ă„ lage en klynge med N=2: en del av dataene vil vĂŠre pĂ„ disker 1 og 2, en del pĂ„ 1 og 3, og en del pĂ„ 2 og 3, mens RAID ikke kan oppnĂ„s pĂ„ samme mĂ„te (man kan lage en slik RAID, men det vil vĂŠre en forvrengning). Hvis det er enda flere disker, er det mulig Ă„ lage RAID 5; CEPH har et tilsvarende konsept â erasure_code, som strider mot de tidlige konseptene fra utviklerne, og derfor ikke vurderes. RAID 5 forutsetter at man har et lite antall disker, og at alle er i god stand. Ved svikt av Ă©n disk, mĂ„ de andre holde ut til man fĂ„r byttet ut disken og gjenopprettet dataene pĂ„ den. CEPH, derimot, oppmuntrer ved N>=3 bruken av eldre disker, spesielt dersom man oppbevarer flere gode disker for lagring av Ă©n kopi av dataene, mens de to til tre andre kopiene lagres pĂ„ et stort antall eldre disker, vil informasjonen vĂŠre trygg, sĂ„ lenge de nye diskene fungerer â det er ingen problemer, og hvis Ă©n av dem bryter sammen, er samtidig svikt av tre disker med en levetid pĂ„ mer enn fem Ă„r, helst fra forskjellige servere â en ekstremt usannsynlig hendelse.
I distribusjonen av kopier er det en nyanse. Som standard antas det at dataene deles i flere grupper av distribusjon PG (ca. 100 per disk), som hver dupliseres pĂ„ noen disker. La oss si at K=6, N=2, sĂ„ nĂ„r to tilfeller av disker svikter, gĂ„r dataene tapt, ettersom det ifĂžlge sannsynlighetsteorien vil finnes minst Ă©n PG som er plassert pĂ„ nettopp de to diskene. Taps av Ă©n gruppe gjĂžr alle data i puljen utilgjengelige. Hvis vi derimot deler diskene i tre par og tillater Ă„ lagre data kun pĂ„ diskene innenfor ett par, vil en slik distribusjon ogsĂ„ vĂŠre motstandsdyktig mot svikt av en hvilken som helst disk, men ved svikt av to disker er sannsynligheten for datatap ikke 100%, men kun 3/15, og selv ved svikt av tre disker â bare 12/20. Herav fĂžlger det at entropien i datadistribusjonen ikke bidrar til feiltoleranse. Vi mĂ„ ogsĂ„ merke oss at for en filserver Ăžker fri RAM betydelig responstiden. Jo mer minne i hver node, og jo mer minne i alle noder â desto raskere vil det vĂŠre. Dette er uten tvil en fordel med klyngen over en enkelt server og, enda mer, en maskinvare NAS, hvor det bygges inn en svĂŠrt liten mengde minne.
Herav fÞlger det at CEPH er en god mÄte med minimale investeringer av utdaterte maskinvare Ä lage et pÄlitelig lagringssystem pÄ titalls TB med mulighet for skalering (her vil det selvfÞlgelig kreves kostnader, men disse er smÄ sammenlignet med kommersielle lagringssystemer).
Implementering av klyngen
For eksperimentet tar vi en skrotet PC Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Fire disker pÄ 2 TB organiseres i en form for RAID10; etter vellykket testing vil vi legge til en annen node og like mange disker til.
Installerer Linux. Distribusjonen mĂ„ ha tilpasningsmuligheter og stabilitet. Debian og Suse passer til kravene. Suse har en mer fleksibel installasjonsprosess som lar deg deaktivere hvilken som helst pakke; dessverre klarte jeg ikke Ă„ forstĂ„ hvilke som kunne fjernes uten Ă„ skade systemet. Vi installerer Debian via debootstrap buster. Alternativet min-base installerer et ikke-fungerende system som mangler drivere. Forskjellen i stĂžrrelse sammenlignet med fullversjonen er ikke sĂ„ stor at det er verdt bryderiet. Siden arbeidet skjer pĂ„ en fysisk maskin, Ăžnsker jeg Ă„ ta snapshots som pĂ„ virtuelle maskiner. Dette kan enten tilbys av LVM eller btrfs (eller xfs, eller zfs â forskjellen er ikke stor). LVM har ikke sterke sider nĂ„r det gjelder snapshots. Vi velger btrfs. Og lasteseksjonen â i MBR. Det er ikke noe poeng i Ă„ fylle opp disken med et 50 MB FAT-partisjon nĂ„r man kan presse det inn i et 1 MB omrĂ„de av partisjonstabellen og tildele alt plassen til systemet. Det tok opp 700 MB pĂ„ disken. Hvor mye grunninstallasjonen av SUSE tar â husker jeg ikke, tror det er rundt 1.1 eller 1.4 GB.
Installerer CEPH. Ignorerer versjon 12 i Debian-repositoriet og kobler til direkte fra nettstedet 15.2.3. FĂžlger instruksjonen i delen "installerer CEPH manuelt" med fĂžlgende forbehold:
- FÞr du kobler til repositoriet, mÄ du installere gnupg wget ca-certificates
- Etter tilkobling av repositoriet, men fĂžr installasjonen av klyngen, utelates installasjonen av pakkene: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Under installasjonen av CEPH vil det av uklare Ärsaker forsÞke Ä installere lvm2. I prinsippet er det ikke noe problem, men installasjonen mislykkes, sÄ CEPH vil heller ikke bli installert.
Denne patchen 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
Klyngeoversikt
ceph-osd â ansvarar för datalagring pĂ„ disken. För varje disk startas en nĂ€tverkstjĂ€nst som tar emot och utför förfrĂ„gningar om att lĂ€sa eller skriva till objekt. PĂ„ disken skapas det tvĂ„ partitioner. Den ena innehĂ„ller information om klustret, diskens nummer samt nycklar till klustret. Denna information, som Ă€r 1 KB, skapas en gĂ„ng nĂ€r disken lĂ€ggs till och har aldrig observerats att Ă€ndras efterĂ„t. PĂ„ den andra partitionen finns ingen filsystem och lagrar binĂ€ra data frĂ„n CEPH. Den automatiska installationen i tidigare versioner skapade en xfs-partition pĂ„ 100 MB för tjĂ€nstens informationslagring. Jag konverterade disken till MBR och avsatte endast 16 MB â tjĂ€nsten klagar inte. Jag tror att xfs skulle kunna bytas ut mot ext utan problem. Denna partition monteras i /var/lib/âŠ, dĂ€r tjĂ€nsten lĂ€ser information om OSD och ocksĂ„ hittar referensen till blockenheten dĂ€r de binĂ€ra data lagras. Teoretiskt sett kan man placera den hjĂ€lpande informationen direkt i /var/lib/âŠ, och hela disken avsĂ€ttas för data. Vid skapandet av OSD via ceph-deploy skapas automatiskt en regel för att montera partitionen i /var/lib/âŠ, och rĂ€ttigheter tilldelas anvĂ€ndaren ceph för att lĂ€sa den nödvĂ€ndiga blockenheten. Vid manuell installation mĂ„ste detta göras sjĂ€lv, vilket inte nĂ€mns i dokumentationen. Det Ă€r ocksĂ„ önskvĂ€rt att specificera parametrarna osd memory target, sĂ„ att det finns tillrĂ€ckligt med fysisk minne.
ceph-mds. PĂ„ en lĂ„g nivĂ„ Ă€r CEPH ett objektlagringssystem. Möjligheten för blocklagring handlar om att spara varje block pĂ„ 4 MB som ett objekt. Filsystemet fungerar enligt samma princip. TvĂ„ pooler skapas: en för metadata och en för data. Dessa förenas i ett filsystem. I detta ögonblick skapas en viss post, sĂ„ om man tar bort filsystemet men behĂ„ller bĂ„da poolerna, gĂ„r det inte att Ă„terstĂ€lla det. Det finns en procedur för att extrahera filer per block, men jag har inte testat det. TjĂ€nsten ceph-mds ansvarar för Ă„tkomst till filsystemet. För varje filsystem krĂ€vs en separat instans av tjĂ€nsten. Det finns en 'index'-funktion som gör det möjligt att skapa liknande fĂ€llande av flera filsystem i ett â vilket ocksĂ„ inte har testats.
ceph-mon â denne tjenesten lagrer kartet til klyngen. Den inneholder informasjon om alle OSD, algoritmen for fordeling av PG i OSD, og viktigst av alt, informasjon om alle objekter (detaljene av denne mekanismen er uklare for meg: det finnes en katalog /var/lib/ceph/mon/âŠ/store.db, som inneholder en stor fil â 26MB, og klyngen har 105K objekter, noe som gir litt over 256 byte per objekt - jeg antar at monitoren lagrer en liste over alle objekter og PG-ene de ligger i). Skader pĂ„ denne katalogen fĂžrer til tap av alle data i klyngen. Herfra kan man konkludere at CRUSH viser hvordan PG er plassert over OSD, mens objektene er sentralt lagret i databasen, uansett hvor mye utviklerne prĂžver Ă„ unngĂ„ dette ordet. FĂžlgelig kan vi, for det fĂžrste, ikke installere systemet pĂ„ en USB-stasjon i RO-modus, da det hele tiden skrives til databasen, noe som krever en ekstra disk for dette (snart ikke mer enn 1 GB), og for det andre, mĂ„ vi i sanntid ha en kopi av denne databasen. Hvis det finnes flere monitorer, blir redundansen automatisk ivaretatt, men i vĂ„rt tilfelle er det bare Ă©n monitor, maks to. Det finnes en teoretisk prosedyre for Ă„ gjenopprette monitoren basert pĂ„ OSD-data, jeg har vĂŠrt tre ganger i denne situasjonen av forskjellige grunner, og tre ganger fikk jeg ingen feilmeldinger, akkurat som ingen data. Dessverre fungerer ikke denne mekanismen. Enten utnytter vi et minimalt partisjon pĂ„ OSD og bygger RAID for lagring av databasen, noe som garantert vil ha en svĂŠrt dĂ„rlig pĂ„virkning pĂ„ ytelsen, eller vi allokerer minst to pĂ„litelige fysiske medier, helst USB, slik at vi ikke tar opp porter.
rados-gw â eksporterer objektlagring via S3-protokollen og lignende. Lager mange puljer, uforstĂ„elig hvorfor. Har ikke eksperimentert mye.
ceph-mgr â nĂ„r denne tjenesten installeres, startes flere moduler. En av dem er en ikke-deaktiverbar autoscale. Den prĂžver Ă„ opprettholde riktig antall PG/OSD. Hvis man Ăžnsker Ă„ styre forholdet manuelt, kan man forby skaleringsalternativet for hver pulje, men i sĂ„ fall krasjer modulen med en deling pĂ„ 0, og klynge-statusen blir ERROR. Modulen er skrevet i Python, og hvis man kommenterer ut en nĂždvendighet i den, fĂžrer det til at den deaktiveres. Detaljene er jeg for lat til Ă„ huske.
Liste over brukte kilder:
Liste over skript:
Installering av 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 6Opprettelse av 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@rbd1Legg 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@$osdnumSammendrag
Det viktigste markedsfĂžringsfortrinnet med CEPH er CRUSH â en algoritme for beregning av datalagring. Monitorene distribuerer denne algoritmen til kundene, som deretter direkte forespĂžr den nĂždvendige noden og den nĂždvendige OSD-en. CRUSH sikrer fravĂŠr av sentralisering. Det er en liten fil som man kan skrive ut og henge pĂ„ veggen. Praksis har vist at CRUSH ikke er et uttĂžmmende kart. Ă Ăždelegge og deretter gjenopprette monitorene, mens man bevarer alle OSD-er og CRUSH, er ikke tilstrekkelig for Ă„ gjenopprette klyngen. Dermed konkluderes det med at pĂ„ hver monitor lagres det visse metadata om hele klyngen. Den lille mengden metadata setter ikke begrensninger for stĂžrrelsen pĂ„ klyngen, men krever at de opprettholdes, noe som utelukker kostnadsbesparelser ved Ă„ installere systemet pĂ„ en USB-minnepinne og utelukker klynger med mindre enn tre noder. Utviklerens aggressive politikk angĂ„ende valgfrie funksjoner. Langt fra minimalisme. Dokumentasjonen er pĂ„ nivĂ„et: «for det som finnes, takk, men veldig, veldig sparsommelig». Muligheten for interaksjon med tjenester pĂ„ lavt nivĂ„ er tilgjengelig, men dokumentasjonen berĂžrer dette emnet for overfladisk, sĂ„ det er mer usannsynlig enn sannsynlig. Nesten ingen sjanser for Ă„ gjenopprette data fra en uventet situasjon.
Alternativer for videre handling: Ă„ gi opp CEPH og bruke en vanlig fler-disks btrfs (eller xfs, zfs), finne ut ny informasjon om CEPH som gjĂžr det mulig Ă„ bruke det under de angitte forholdene, prĂžve Ă„ skrive et eget lagringssystem som en del av kvalifiseringen.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish