Erfarenhet av CEPH

När det finns mer data än vad som får plats på en disk är det dags att tänka på RAID. Som barn hörde jag ofta från mina äldre: "en dag kommer RAID att bli ett minne blott, objektlagring kommer att översvämma världen, och du vet inte ens vad CEPH är", så det första i ett självständigt liv skapade ditt eget kluster. Syftet med experimentet var att bekanta sig med den interna strukturen hos ceph och förstå omfattningen av dess tillämpning. Hur motiverat är införandet av ceph i ett medelstort företag, men i ett litet? Efter flera års drift och ett par oåterkalleliga dataförluster uppstod en förståelse för subtiliteterna att allt inte är så enkelt. Funktioner hos CEPH skapar hinder för dess breda spridning, och på grund av dem har experimenten stannat. Nedan följer en beskrivning av alla vidtagna steg, det erhållna resultatet och de slutsatser som dragits. Om kunniga personer kommer att dela med sig av sina erfarenheter och förklara några punkter är jag tacksam.

Notera: Kommentatorer har påpekat allvarliga fel i några av antagandena, vilket kräver en revidering av hela artikeln.

CEPH strategi

CEPH-klustret kombinerar ett godtyckligt antal K diskar av godtycklig storlek och lagrar data på dem, och duplicerar varje del (4 MB som standard) ett givet antal N gånger.

Tänk på det enklaste fallet med två identiska diskar. Du kan antingen bygga en RAID 1 eller ett kluster med N=2 från dem - resultatet blir detsamma. Om det finns tre diskar, och de är av olika storlek, är det lätt att sätta ihop ett kluster med N=2: en del av data kommer att finnas på diskarna 1 och 2, några på 1 och 3, och några på 2 och 3 , medan RAID inte är det (du kan samla in en sådan RAID, men det skulle vara en perversion). Om det finns ännu fler diskar är det möjligt att skapa RAID 5, CEPH har en analog - erasure_code, som motsäger utvecklarnas tidiga koncept och därför inte beaktas. RAID 5 antar att det finns ett litet antal diskar, och alla är i gott skick. Om en misslyckas måste resten hålla ut tills disken byts ut och data återställs till den. CEPH, med N>=3, uppmuntrar användningen av gamla diskar, i synnerhet om du har flera bra diskar för att lagra en kopia av data, och lagrar de återstående två eller tre kopiorna på ett stort antal gamla diskar, kommer informationen kommer att vara säkert, för för närvarande är nya diskar vid liv - det finns inga problem, och om en av dem går sönder, är det extremt osannolikt att tre diskar med en livslängd på mer än fem år samtidigt misslyckas, helst från olika servrar. händelse.

Det finns en subtilitet i distributionen av kopior. Som standard antas det att data är uppdelade i fler (~100 per disk) PG-distributionsgrupper, som var och en dupliceras på vissa diskar. Antag att K=6, N=2, då om två diskar misslyckas kommer data garanterat att gå förlorade, eftersom det enligt sannolikhetsteorin kommer att finnas åtminstone en PG som kommer att finnas på dessa två diskar. Och förlusten av en grupp gör all data i poolen otillgänglig. Om diskarna är uppdelade i tre par och tillåts lagra data endast på diskar inom ett par, är en sådan distribution också resistent mot fel på en disk, men om två misslyckas är sannolikheten för dataförlust inte 100%, men bara 3/15, och även vid fel tre skivor - bara 12/20. Entropi i datadistribution bidrar därför inte till feltolerans. Observera också att för en filserver ökar fritt RAM-minne avsevärt responsen. Ju mer minne i varje nod, och ju mer minne i alla noder, desto snabbare blir det. Detta är utan tvekan fördelen med ett kluster framför en enda server och dessutom en hårdvaru-NAS, där en mycket liten mängd minne är inbyggt.

Av detta följer att CEPH är ett bra sätt att skapa ett tillförlitligt lagringssystem för tiotals TB med möjlighet att skala med minimal investering från föråldrad utrustning (här kommer det naturligtvis att krävas kostnader, men små jämfört med kommersiella lagringssystem).

Klusterimplementering

För experimentet, låt oss ta en avvecklad dator Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Vi organiserar fyra 2 TB-diskar till något som RAID10, efter ett lyckat test kommer vi att lägga till en andra nod och samma antal diskar.

Installera Linux. Distributionen måste vara anpassningsbar och stabil. Debian och Suse uppfyller kraven. Suse har ett mer flexibelt installationsprogram som låter dig inaktivera vilket paket som helst; tyvärr kunde jag inte förstå vilka som kan slängas ut utan att skada systemet. Installera Debian via debootstrap buster. Alternativet min-bas installerar ett icke-fungerande system som saknar drivrutiner. Skillnaden i storlek jämfört med fullversionen är inte så stor att den stör. Eftersom arbetet görs på en fysisk maskin vill jag ta ögonblicksbilder, precis som på virtuella maskiner. Antingen LVM eller btrfs (eller xfs eller zfs - skillnaden är inte stor) ger en sådan möjlighet. Ögonblicksbilder är inte LVM:s starka sida. Installera btrfs. Och starthanteraren finns i MBR. Det är ingen mening att täppa till en 50 MB disk med en FAT-partition när du kan trycka in den i ett 1 MB partitionstabellområde och allokera allt utrymme för systemet. Det tog 700 MB på disken. Hur mycket basinstallationen av SUSE har - jag minns inte, det verkar, ungefär 1.1 eller 1.4 GB.

Installera CEPH. Vi ignorerar version 12 i debianförvaret och ansluter direkt från webbplatsen 15.2.3. Vi följer instruktionerna från avsnittet "Installera CEPH manuellt" med följande varningar:

  • Innan du ansluter arkivet måste du installera gnupg wget ca-certifikat
  • Efter anslutning av förvaret, men innan du installerar klustret, utelämnas paketinstallationen: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
  • Vid tidpunkten för installationen av CEPH, av okända anledningar, kommer den att försöka installera lvm2. I princip är det inte synd, men installationen misslyckas, så CEPH kommer inte heller att installera.

    Denna patch hjälpte:

    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
    

Klusteröversikt

ceph-osd - ansvarig för att lagra data på disk. För varje disk startas en nätverkstjänst som accepterar och utför förfrågningar om att läsa eller skriva till objekt. Två partitioner skapas på disken. En av dem innehåller information om klustret, disknummer och klusternycklar. Denna 1KB-information skapas en gång när du lägger till en disk och märkte aldrig att den ändrades igen. Den andra partitionen har inget filsystem och lagrar binära CEPH-data. Automatisk installation i tidigare versioner skapade en 100MB xfs-partition för serviceinformation. Jag konverterade disken till MBR och tilldelade endast 16MB - tjänsten klagar inte. Jag tror att xfs hade kunnat ersättas med ext utan problem. Den här partitionen är monterad i /var/lib/… där tjänsten läser information om OSD och även hittar en länk till blockenheten där binära data lagras. Teoretiskt kan du omedelbart placera extra i / var / lib / ... och allokera hela disken för data. När du skapar en OSD via ceph-deploy skapas en regel automatiskt för att montera en partition i /var/lib/…, och rättigheterna till ceph-användaren tilldelas att läsa den önskade blockenheten. Med en manuell installation måste du göra detta själv, dokumentationen säger inte om det. Det är också tillrådligt att specificera osd-minnets målparameter så att det finns tillräckligt med fysiskt minne.

ceph-mds. På en låg nivå är CEPH objektlagring. Blocklagringsförmågan går ut på att spara varje 4MB block som ett objekt. Fillagring fungerar på samma princip. Två pooler skapas: en för metadata, den andra för data. De kombineras till ett filsystem. För närvarande skapas någon sorts post, så om du tar bort filsystemet, men sparar båda poolerna, kommer du inte att kunna återställa det. Det finns en procedur för att extrahera filer i block, jag har inte testat det. Tjänsten ceph-mds ansvarar för åtkomst till filsystemet. Varje filsystem kräver en separat instans av tjänsten. Det finns ett "index"-alternativ som låter dig skapa en sken av flera filsystem i ett - inte heller testat.

ceph-mon - Denna tjänst håller en karta över klustret. Den innehåller information om alla OSD, PG-distributionsalgoritmen i OSD och, viktigast av allt, information om alla objekt (detaljerna i denna mekanism är inte tydliga för mig: det finns en /var/lib/ceph/mon/…/ store.db-katalogen, den innehåller en stor fil är 26MB, och i ett kluster av 105K objekt visar det sig lite mer än 256 byte per objekt - jag tror att monitorn håller en lista över alla objekt och PG där de ljuger). Skador på den här katalogen leder till att all data i klustret går förlorad. Härifrån drogs slutsatsen att CRUSH visar hur PG:er är placerade enligt OSD, och hur objekt är lokaliserade enligt PG - de lagras centralt inuti databasen, oavsett hur utvecklarna undviker detta ord. Som ett resultat kan vi för det första inte installera systemet på en flashenhet i RO-läge, eftersom databasen ständigt skrivs till, en extra disk behövs för dessa (knappast mer än 1 GB), och för det andra är det nödvändigt att ha en realtidskopiering av denna bas. Om det finns flera monitorer, så tillhandahålls feltolerans automatiskt, men i vårt fall finns det bara en monitor, max två. Det finns en teoretisk procedur för att återställa en bildskärm baserad på OSD-data, jag tog till det tre gånger av olika anledningar, och tre gånger inga felmeddelanden, liksom data också. Tyvärr fungerar inte denna mekanism. Antingen driver vi en miniatyr OSD-partition och sätter ihop en RAID för att lagra databasen, vilket förmodligen kommer att ha väldigt dålig effekt på prestandan, eller så allokerar vi minst två pålitliga fysiska medier, helst USB, så att portarna inte tar upp.

rados-gw - exporterar objektlagring med S3-protokollet och liknande. Skapar många pooler, det är inte klart varför. Experimenterade inte riktigt.

ceph-mgr - Att installera den här tjänsten startar flera moduler. En av dem är den icke-inaktiverade autoskalningen. Den strävar efter att behålla det korrekta antalet PG/OSD:er. Om du vill styra förhållandet manuellt kan du inaktivera skalning för varje pool, men i detta fall faller modulen med en division med 0, och klusterstatusen blir ERROR. Modulen är skriven i python, och om du kommenterar den nödvändiga raden i den leder detta till att den stängs av. För lat för att komma ihåg detaljerna.

Lista över använda källor:

CEPH installation
Återställning från ett fullständigt monitorfel

Skriptlistor:

Installera 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 6

Skapa ett kluster

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@rbd1

Lägger till 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@$osdnum

Sammanfattning

Den främsta marknadsföringsfördelen med CEPH är CRUSH, en algoritm för att beräkna platsen för data. Övervakare sprider denna algoritm till klienter, varefter klienter direkt begär den önskade noden och önskad OSD. CRUSH ger ingen centralisering. Det är en liten fil som du till och med kan skriva ut och hänga på väggen. Övning har visat att CRUSH inte är en uttömmande karta. Att förstöra och återskapa bildskärmarna samtidigt som alla OSD:er och CRUSH behålls är inte tillräckligt för att återställa klustret. Av detta dras slutsatsen att varje monitor lagrar viss metadata om hela klustret. Den obetydliga mängden av denna metadata sätter inga begränsningar för klustrets storlek, men det kräver deras säkerhet, vilket eliminerar diskbesparingar på grund av installation av systemet på en flashenhet och utesluter kluster med mindre än tre noder. Aggressiv utvecklarpolicy för valfria funktioner. Långt ifrån minimalism. Dokumentation på nivån: "tack för vad det är, men väldigt, väldigt magert." Möjligheten att interagera med tjänster på en låg nivå tillhandahålls, men dokumentationen är för ytlig i detta ämne, så mer troligt nej än ja. Praktiskt taget ingen chans att återställa data från en nödsituation.

Alternativ för ytterligare åtgärder: överge CEPH och använd de banala multi-disk btrfs (eller xfs, zfs), lär dig ny information om CEPH, vilket gör att du kan använda den under de angivna förhållandena, försök att skriva din egen lagring som en avancerad utbildning .

Källa: will.com

Lägg en kommentar