Erfarenhet av CEPH-drift

När datan överstiger vad som får plats på en enskild disk, är det dags att börja tänka på RAID. Som barn hörde jag ofta äldre säga: "En dag kommer RAID att försvinna, objektlagring kommer att fylla världen, och du vet knappt vad CEPH är" - så det första jag gjorde när jag blev självständig var att skapa min egen kluster. Målet med experimentet var att bekanta sig med den interna strukturen i Ceph och förstå ramen för dess användning. Hur berättigat är det att införa Ceph i medelstora företag, och i små? Efter flera års användning och några oåterkalleliga dataförluster har insikter om nyanserna vuxit fram, vilket gör att läget inte är så entydigt. Egenskaperna hos CEPH skapar hinder för dess breda spridning, och på grund av dem har experimenten kört fast. Nedan följer en beskrivning av alla genomförda steg, det erhållna resultatet och de dragna slutsatserna. Om kunniga personer delar med sig av sina erfarenheter och förklarar vissa punkter - skulle jag vara tacksam.

Anmärkning: Kommentatorerna har påpekat allvarliga fel i vissa antaganden som kräver en översyn av hela artikeln.

CEPH-strategi

CEPH-klustret sammanför ett godtyckligt antal K-diskar av godtycklig storlek och lagrar data på dem genom att duplicera varje bit (4 MB som standard) ett angivet antal N gånger.

Låt oss överväga det enklaste fallet med två identiska diskar. Av dessa kan man antingen bygga en RAID 1 eller en kluster med N=2 — resultatet blir detsamma. Om det finns tre diskar av olika storlek, är det lätt att skapa en kluster med N=2: en del av data kommer att finnas på diskar 1 och 2, en del — på 1 och 3, och en del — på 2 och 3, vilket inte är möjligt med RAID (man kan konstruera en sådan RAID, men det skulle vara en avvikelse). Om det finns ännu fler diskar, är det möjligt att skapa RAID 5, och CEPH har en motsvarighet — erasure_code, vilket strider mot utvecklarnas tidigare koncept, och därför inte beaktas. RAID 5 förutsätter att det finns ett litet antal diskar, och att alla är i gott skick. Vid ett misslyckande av en, måste de andra hålla ut tills diskbytet och återställningen av data är slutfört. Å andra sidan, med CEPH, när N>=3, uppmuntras användningen av gamla diskar, särskilt om man har flera fungerande diskar för att lagra en kopia av datan, medan de återstående två-tre kopiorna lagras på ett stort antal gamla diskar. Då kommer informationen att vara säker, eftersom så länge de nya diskarna fungerar finns det inga problem, och om en av dem går sönder, är det extremt osannolikt att tre diskar med en livslängd på över fem år — helst från olika servrar — skulle gå sönder samtidigt.

I distributionen av kopior finns det en subtilitet. Som standard antas det att data delas upp på fler grupper (~100 per disk) av PG-distribution, där varje grupp dupliceras på vissa diskar. Anta att K=6, N=2, så om två valfria diskar går sönder, förloras data garanterat, eftersom sannolikhetsteorin visar att det kommer att finnas åtminstone en PG som ligger på just dessa två diskar. Och förlusten av en grupp gör all data i poolen otillgänglig. Om diskarna istället delas upp i tre par och lagring av data endast tillåts på diskar inom samma par, så är denna distribution fortfarande motståndskraftig mot ett diskfel, men vid två fel är sannolikheten för dataförlust inte 100%, utan endast 3/15, och även vid tre diskar som går sönder är den bara 12/20. Därför bidrar entropin i datadistributionen inte till felresilience. Vi noterar också att för en filserver ökar den lediga RAM-minnet avsevärt svarstiden. Ju mer minne varje nod har, och ju mer minne hela klustret har, desto snabbare blir det. Detta är utan tvekan en fördel för klustret jämfört med en ensam server och, ännu mer, en hårdvaru-NAS, som har en mycket liten mängd minne.

Detta innebär att CEPH är ett bra sätt att med minimiinvesteringar av föråldrad utrustning skapa ett pålitligt datalagringssystem på tiotals TB med skalbarhet (här krävs givetvis kostnader, men de är små jämfört med kommersiella lagringslösningar).

Implementering av klustret

För experimentet tar vi en utrangerad dator Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Vi organiserar fyra diskar på 2 TB i likhet med RAID10, efter lyckad testning lägger vi till en andra nod och lika många diskar till.

Installerar Linux. Distributionen måste vara anpassningsbar och stabil. Debian och Suse uppfyller kraven. Suse har en mer flexibel installationsprocess som tillåter att avaktivera vilket paket som helst; tyvärr kunde jag inte lista ut vilka som kan tas bort utan att skada systemet. Vi installerar Debian via debootstrap buster. Alternativet min-base installerar ett icke-fungerande system som saknar drivrutiner. Skillnaden i storlek jämfört med fullversionen är inte så stor att det är värt besväret. Eftersom arbetet utförs på en fysisk maskin, vill man kunna göra snapshots, som på virtuella maskiner. Denna möjlighet erbjuds av antingen LVM eller btrfs (eller xfs, eller zfs — skillnaden är inte stor). LVM:s snaps är inte dess starka sida. Vi väljer btrfs. Och bootloadern — i MBR. Det finns ingen mening med att fylla disken med 50 MB partition med FAT när man kan trycka in det i 1 MB-området av partititionstabellen och all plats dedikera till systemet. Det tog 700 MB på disken. Hur mycket standardinstallationen av SUSE tar — minns jag inte, verkar vara runt 1.1 eller 1.4 GB.

Installerar CEPH. Vi ignorerar version 12 i debian-förvaret och ansluter direkt från webbplatsen version 15.2.3. Följ instruktionerna i avsnittet "installerar CEPH manuellt" med följande förbehåll:

• Innan du ansluter förvaret, måste du installera gnupg wget ca-certificates
• Efter att ha anslutit förvaret, men före installationen av klustret, utelämnas paketinstallationen: apt -y —no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• Vid installationstillfället av CEPH kommer lvm2 att försöka installeras av oklara skäl. I princip är det inget problem, men installationen misslyckas, vilket också hindrar installationen av CEPH.

  Den här patchen hjälpte:

  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
  

Översikt över klustret

ceph-osd — ansvarar för datalagring på disken. För varje disk körs en nätverksservice som tar emot och utför begärningar om läsning eller skrivning av objekt. På disken skapas två partitioner. En av dem innehåller information om klustret, disknumret och nycklarna till klustret. Denna information på 1 KB skapas en gång vid tillägg av disken och har aldrig förändrats efter det. Den andra partitionen har ingen filsystem och lagrar binära data för CEPH. Automatisk installation i tidigare versioner skapade en xfs-partition på 100 MB för tjänsteinformation. Jag konverterade disken till MBR och avsatte bara 16 MB — tjänsten klagar inte. Jag tror att xfs skulle kunna ersättas med ext utan problem. Denna partition monteras i /var/lib/…, där tjänsten läser information om OSD och även hittar en länk till blockenhet där binära data lagras. Teoretiskt sett går det att direkt placera hjälpfiler i /var/lib/…, och helt avsätta disken för data. Vid skapandet av OSD med ceph-deploy skapas automatiskt en regel för montering av 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, detta nämns inte i dokumentationen. Det är också önskvärt att ange parametern osd memory target, så att det finns tillräckligt med fysisk minne.

ceph-mds. På låg nivå är CEPH — en objektlagring. Möjligheten för blocklagring reduceras till att lagra varje block på 4 MB som ett objekt. Det fungerar på samma sätt som filsystemlagring. Två pooler skapas: en för metadata, och en för data. Dessa förenas i ett filsystem. Vid detta tillfälle skapas en slags 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 i block, har inte testat det. Tjänsten ceph-mds ansvarar för åtkomsten till filsystemet. För varje filsystem krävs en separat instans av tjänsten. Det finns en funktion "index" som gör det möjligt att skapa en liknande struktur av flera filsystem i ett — det har inte heller testats.

ceph-mon — den här tjänsten lagrar klusterkartan. Den innehåller information om alla OSD, algoritmen för distribution av PG i OSD och, viktigast av allt, information om alla objekt (detaljerna i denna mekanism är oklara för mig: det finns en katalog /var/lib/ceph/mon/…/store.db, där en stor fil på 26 MB finns, och i klustret finns det 105K objekt, vilket ger drygt 256 byte per objekt, - jag tror att monitorn lagrar en lista över alla objekt och PG där de ligger). Skada på denna katalog leder till förlust av all data i klustret. Därav slutsatsen att CRUSH visar hur PG är fördelade över OSD, och hur objekt är fördelade över PG — dessa lagras centraliserat i databasen, oavsett hur utvecklarna försöker undvika detta ord. Som en följd kan vi för det första inte installera systemet på en flash-enhet i RO-läge, eftersom databasen kräver ständig skrivning, ytterligare en disk behövs för detta (sannolikt inte mer än 1 GB), för det andra är det nödvändigt att ha en kopia av denna databas i realtid. Om det finns flera monitorer sker redundansen automatiskt, men i vårt fall finns det en monitor, högst två. Det finns en teoretisk procedur för att återställa monitorn baserat på OSD-data, jag har använt den tre gånger av olika skäl, och vid varje tillfälle har det inte kommit några felmeddelanden, liksom ingen data heller. Tyvärr fungerar denna mekanism inte. Antingen måste vi använda ett minimalt partition på OSD och sätta ihop en RAID för att lagra databasen, vilket säkert kommer att påverka prestandan negativt, eller så måste vi avsätta åtminstone två pålitliga fysiska medier, helst USB, så att vi inte tar upp portar.

rados-gw — exporterar objektlagring via S3-protokollet och liknande. Skapar många pooler, oklart varför. Jag har inte experimenterat mycket.

ceph-mgr — vid installationen av denna tjänst startas flera moduler. En av dem är den oavstängda autoscale. Den försöker upprätthålla rätt antal PG/OSD. Om man vill styra förhållandet manuellt kan man förbjuda skalning för varje pool, men i så fall kraschar modulen med division med 0, och klusterstatus blir ERROR. Modulen är skriven i Python, och om man kommenterar bort rätt rad leder det till att den stängs av. Detaljerna har jag inte lust att minnas.

Lista över använda källor:

Installation av CEPH
Återställning vid fullständig 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 @\/.\n\nchroot \/mnt\/@ \/bin\/bash
echo rbd1 > \/etc\/hostname
passwd
uuid=\`blkid | grep $blkdev | cut -d """ -f 2\`\ncat < \/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
\nPackage: 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
\nexit\ngrub-install --boot-directory=@\/boot\/ \/dev\/$blkdev
init 6\n\napt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh  smartmontools ntfs-3g net-tools man
exit\ngrub-install --boot-directory=@\/boot\/ \/dev\/$blkdev
init 6

Skapa en 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 < /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ägg 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 största marknadsföringsfördelen med CEPH är CRUSH - algoritmen för datalagring. Övervakningarna distribuerar denna algoritm till kunderna, varefter kunderna direkt begär den nödvändiga noden och den nödvändiga OSD:n. CRUSH säkerställer avsaknad av centralisering. Det är en liten fil som till och med kan skrivas ut och hängas på väggen. Praktiken har visat att CRUSH inte är en uttömmande karta. Om man förstör och återskapar övervakningarna, med alla OSD:er och CRUSH kvar, är det inte tillräckligt för att återställa klustret. Därmed dras slutsatsen att vissa metadata om hela klustret lagras på varje övervakning. Den obetydliga mängden metadata lägger inga begränsningar på klustrets storlek, men kräver att deras bevarande säkerställs, vilket utesluter att spara disk genom att installera systemet på ett USB-minne och utesluter kluster med mindre än tre noder. Utvecklarens aggressiva politik angående valfria funktioner. Långt från minimalism. Dokumentationen är på nivå: "för det som finns, tack, men väldigt, väldigt knapert". Möjligheten att interagera med tjänster på låg nivå finns, men dokumentationen berör detta ämne för ytligt, så det är mer sannolikt att det är nej än ja. Nästan inga chanser till dataräddning från en nödsituation.

Alternativa handlingsplaner: överge CEPH och använda den banala flerdiskbtrfs (eller xfs, zfs), ta reda på ny information om CEPH som gör det möjligt att använda det under angivna förhållanden, eller försöka skriva ett eget lagringssystem som en kompetenshöjning.

Källa: habr.com