Ervaring met CEPH

Als er meer gegevens zijn dan er op één schijf passen, is het tijd om na te denken over RAID. Als kind hoorde ik vaak van mijn ouders: "op een dag zal RAID tot het verleden behoren, de opslag van objecten zal de wereld vullen, en je weet niet eens wat CEPH is", dus het eerste in mijn onafhankelijke leven was om mijn eigen cluster te creëren. Het doel van het experiment was om kennis te maken met de interne structuur van cef en de reikwijdte van de toepassing ervan te begrijpen. Hoe gerechtvaardigd is de implementatie van cef in middelgrote en kleine bedrijven? Na enkele jaren gebruik en een paar onomkeerbare gegevensverliezen ontstond het inzicht in de complexiteiten dat niet alles zo eenvoudig is. De eigenaardigheden van CEPH vormen een belemmering voor de wijdverbreide toepassing ervan, en als gevolg daarvan zijn experimenten op een dood spoor beland. Hieronder volgt een beschrijving van alle genomen stappen, het verkregen resultaat en de getrokken conclusies. Als deskundige mensen hun ervaringen delen en enkele punten toelichten, zal ik dankbaar zijn.

Opmerking: Commentatoren hebben ernstige fouten ontdekt in sommige aannames die een herziening van het hele artikel vereisen.

CEPH-strategie

Het CEPH-cluster combineert een willekeurig aantal K schijven van willekeurige grootte en slaat er gegevens op, waarbij elk stuk (standaard 4 MB) een bepaald aantal N keer wordt gedupliceerd.

Laten we het eenvoudigste geval bekijken met twee identieke schijven. Hieruit kunt u RAID 1 of een cluster met N=2 samenstellen - het resultaat zal hetzelfde zijn. Als er drie schijven zijn en deze hebben een verschillende grootte, dan is het eenvoudig om een ​​cluster samen te stellen met N=2: een deel van de gegevens zal op schijf 1 en 2 staan, een deel zal op schijf 1 en 3 staan, en een deel zal op schijf 2 en 3 staan. op 5 en 5, terwijl RAID dat niet doet (je kunt zo'n RAID samenstellen, maar dat zou een perversie zijn). Als er nog meer schijven zijn, is het mogelijk om RAID 3 te maken; CEPH heeft een analoge erure_code, die in tegenspraak is met de vroege concepten van de ontwikkelaars, en daarom niet wordt overwogen. RAID XNUMX gaat ervan uit dat er een klein aantal schijven is, die allemaal in goede staat verkeren. Als er één faalt, moeten de anderen het volhouden totdat de schijf is vervangen en de gegevens erop zijn hersteld. CEPH moedigt met N>=XNUMX het gebruik van oude schijven aan, in het bijzonder als u meerdere goede schijven bewaart om één kopie van de gegevens op te slaan, en de overige twee of drie kopieën op een groot aantal oude schijven opslaat, dan wordt de informatie zal veilig zijn, aangezien er voorlopig nieuwe schijven in leven zijn - er zijn geen problemen, en als een van hen kapot gaat, is het gelijktijdig falen van drie schijven met een levensduur van meer dan vijf jaar, bij voorkeur van verschillende servers, uiterst onwaarschijnlijk evenement.

Er zit een subtiliteit in de verspreiding van kopieën. Standaard wordt aangenomen dat de gegevens zijn verdeeld in meer (~100 per schijf) PG-distributiegroepen, die elk op sommige schijven worden gedupliceerd. Laten we zeggen K=6, N=2, en als er twee schijven uitvallen, gaan er gegarandeerd gegevens verloren, omdat er volgens de waarschijnlijkheidstheorie minstens één PG op deze twee schijven zal staan. En door het verlies van één groep zijn alle gegevens in de pool niet meer beschikbaar. Als de schijven in drie paren zijn verdeeld en gegevens alleen op schijven binnen één paar mogen worden opgeslagen, dan is een dergelijke verdeling ook bestand tegen het falen van één schijf, maar als twee schijven uitvallen, is de kans op gegevensverlies niet groter. 100%, maar slechts 3/15, en zelfs in geval van een storing drie schijven - slechts 12/20. Daarom draagt ​​​​entropie in de gegevensdistributie niet bij aan fouttolerantie. Houd er ook rekening mee dat voor een bestandsserver vrij RAM-geheugen de reactiesnelheid aanzienlijk verhoogt. Hoe meer geheugen in elk knooppunt, en hoe meer geheugen in alle knooppunten, hoe sneller het zal zijn. Dit is ongetwijfeld een voordeel van een cluster ten opzichte van een enkele server en nog meer een hardware-NAS, waar een zeer kleine hoeveelheid geheugen is ingebouwd.

Hieruit volgt dat CEPH een goede manier is om een ​​betrouwbaar gegevensopslagsysteem voor tientallen TB te creëren met de mogelijkheid om op te schalen met minimale investeringen uit verouderde apparatuur (hier zullen uiteraard kosten aan verbonden zijn, maar deze zijn klein in vergelijking met commerciële opslagsystemen).

Clusterimplementatie

Laten we voor het experiment een buiten gebruik gestelde computer nemen Intel DQ57TM + Intel core i3 540 + 16 GB RAM. We zullen vier schijven van 2 TB indelen in zoiets als RAID10, na een succesvolle test zullen we een tweede knooppunt en hetzelfde aantal schijven toevoegen.

Linux installeren. De distributie vereist de mogelijkheid om aan te passen en stabiel te zijn. Debian en Suse voldoen aan de eisen. Suse heeft een flexibeler installatieprogramma waarmee u elk pakket kunt uitschakelen; Helaas kon ik er niet achter komen welke weggegooid konden worden zonder het systeem te beschadigen. Installeer Debian met behulp van debootstrap buster. De min-base-optie installeert een kapot systeem zonder stuurprogramma's. Het verschil in grootte ten opzichte van de volledige versie is niet zo groot dat het hinderlijk is. Omdat het werk op een fysieke machine wordt uitgevoerd, wil ik snapshots maken, zoals op virtuele machines. Deze optie wordt geboden door LVM of btrfs (of xfs of zfs - het verschil is niet groot). LVM-snapshots zijn geen sterk punt. Installeer btrfs. En de bootloader bevindt zich in de MBR. Het heeft geen zin om een ​​schijf van 50 MB vol te proppen met een FAT-partitie als je deze in een partitietabelgebied van 1 MB kunt plaatsen en alle ruimte voor het systeem kunt toewijzen. Heeft 700 MB schijfruimte in beslag genomen. Ik weet niet meer hoeveel de standaard SUSE-installatie heeft, ik denk dat het ongeveer 1.1 of 1.4 GB is.

CEPH installeren. We negeren versie 12 in de debian-repository en maken rechtstreeks verbinding vanaf de 15.2.3-site. We volgen de instructies uit de sectie “CEPH handmatig installeren” met de volgende kanttekeningen:

• Voordat u de repository aansluit, moet u gnupg wget ca-certificaten installeren
• Na het verbinden van de repository, maar voordat het cluster wordt geïnstalleerd, wordt het installeren van pakketten weggelaten: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• Bij het installeren van CEPH zal het om onbekende redenen proberen lvm2 te installeren. In principe is het niet jammer, maar de installatie mislukt, dus CEPH zal ook niet installeren.

  Deze patch heeft geholpen:

  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
  

Clusteroverzicht

ceph-osd - is verantwoordelijk voor het opslaan van gegevens op schijf. Voor elke schijf wordt een netwerkservice gelanceerd die verzoeken om objecten te lezen of te schrijven accepteert en uitvoert. Er worden twee partities op de schijf gemaakt. Een daarvan bevat informatie over het cluster, het schijfnummer en de sleutels van het cluster. Deze informatie van 1 KB wordt één keer aangemaakt bij het toevoegen van een schijf en er is nooit opgemerkt dat deze verandert. De tweede partitie heeft geen bestandssysteem en slaat binaire CEPH-gegevens op. Automatische installatie in eerdere versies creëerde een xfs-partitie van 100 MB voor service-informatie. Ik heb de schijf geconverteerd naar MBR en heb slechts 16 MB toegewezen - de service klaagt niet. Ik denk dat xfs zonder problemen kan worden vervangen door ext. Deze partitie is aangekoppeld in /var/lib/…, waar de service informatie over de OSD leest en ook een verwijzing vindt naar het blokapparaat waar de binaire gegevens zijn opgeslagen. Theoretisch kun je onmiddellijk hulpbestanden in /var/lib/… plaatsen en de hele schijf toewijzen aan gegevens. Bij het aanmaken van een OSD via ceph-deploy wordt er automatisch een regel aangemaakt om de partitie in /var/lib/… te mounten, en krijgt de ceph-gebruiker ook rechten toegewezen om het gewenste blokapparaat te lezen. Als u handmatig installeert, moet u dit zelf doen; de documentatie vermeldt dit niet. Het is ook raadzaam om de doelparameter van het osd-geheugen te specificeren, zodat er voldoende fysiek geheugen is.

ceph-mds. Op een laag niveau is CEPH objectopslag. De blokopslagcapaciteit komt neer op het opslaan van elk blok van 4 MB als een object. Bestandsopslag werkt volgens hetzelfde principe. Er worden twee pools gemaakt: één voor metadata, de andere voor data. Ze worden gecombineerd in een bestandssysteem. Op dit moment wordt er een soort record aangemaakt, dus als u het bestandssysteem verwijdert maar beide pools behoudt, kunt u het niet herstellen. Er is een procedure voor het extraheren van bestanden in blokken, ik heb deze niet getest. De ceph-mds-service is verantwoordelijk voor de toegang tot het bestandssysteem. Voor elk bestandssysteem is een afzonderlijk exemplaar van de service vereist. Er is een "index" -optie waarmee u de schijn van verschillende bestandssystemen in één kunt creëren - ook niet getest.

Ceph-mon - Deze service slaat een kaart van het cluster op. Het bevat informatie over alle OSD's, een algoritme voor het distribueren van PG's in OSD's en, belangrijker nog, informatie over alle objecten (de details van dit mechanisme zijn mij niet duidelijk: er is een directory /var/lib/ceph/mon/…/ store.db, het bevat een groot bestand van 26 MB, en in een cluster van 105K objecten blijkt het iets meer dan 256 bytes per object te zijn - ik denk dat de monitor een lijst opslaat van alle objecten en de PG's waarin ze bevinden zich). Schade aan deze map resulteert in het verlies van alle gegevens in het cluster. Daarom werd de conclusie getrokken dat CRUSH laat zien hoe PG's zich op het OSD bevinden, en hoe objecten zich op PG's bevinden - ze worden centraal opgeslagen in de database, hoezeer de ontwikkelaars dit woord ook vermijden. Als gevolg hiervan kunnen we ten eerste het systeem niet op een flashdrive in RO-modus installeren, omdat de database voortdurend wordt opgenomen, hiervoor is een extra schijf nodig (nauwelijks meer dan 1 GB), ten tweede is het noodzakelijk om een kopieer deze basis in realtime. Als er meerdere monitoren zijn, wordt de fouttolerantie automatisch gewaarborgd, maar in ons geval is er slechts één monitor, maximaal twee. Er is een theoretische procedure voor het herstellen van een monitor op basis van OSD-gegevens. Ik heb er om verschillende redenen drie keer mijn toevlucht tot genomen, en drie keer waren er geen foutmeldingen en ook geen gegevens. Helaas werkt dit mechanisme niet. Ofwel gebruiken we een miniatuurpartitie op de OSD en stellen we een RAID samen om de database op te slaan, wat zeker een zeer slecht effect op de prestaties zal hebben, ofwel wijzen we ten minste twee betrouwbare fysieke media toe, bij voorkeur USB, om geen poorten in beslag te nemen.

rados-gw - exporteert objectopslag via het S3-protocol en dergelijke. Creëert veel pools, het is onduidelijk waarom. Ik heb niet veel geëxperimenteerd.

ceph-mgr - Bij het installeren van deze service worden verschillende modules gestart. Een daarvan is automatisch schalen, dat niet kan worden uitgeschakeld. Het streeft ernaar de juiste hoeveelheid PG/OSD te behouden. Als u de verhouding handmatig wilt beheren, kunt u het schalen voor elke pool uitschakelen, maar in dit geval crasht de module met een deling door 0 en wordt de clusterstatus ERROR. De module is geschreven in Python, en als je de benodigde regel erin commentaar geeft, leidt dit tot de uitschakeling ervan. Te lui om de details te onthouden.

Lijst met gebruikte bronnen:

Installatie van CEPH
Herstel van een volledige monitorstoring

Scriptvermeldingen:

Het systeem installeren 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

Maak een cluster

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

OSD toevoegen (deel)

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

Beknopt

Het belangrijkste marketingvoordeel van CEPH is CRUSH - een algoritme voor het berekenen van de locatie van gegevens. Monitoren distribueren dit algoritme naar clients, waarna clients direct het gewenste knooppunt en de gewenste OSD opvragen. CRUSH garandeert geen centralisatie. Het is een klein bestand dat je zelfs kunt afdrukken en aan de muur kunt hangen. De praktijk leert dat CRUSH geen uitputtende kaart is. Als u de monitoren vernietigt en opnieuw maakt en alle OSD en CRUSH behoudt, is dit niet voldoende om het cluster te herstellen. Hieruit wordt geconcludeerd dat elke monitor een aantal metadata over het gehele cluster opslaat. De kleine hoeveelheid van deze metadata legt geen beperkingen op aan de grootte van het cluster, maar vereist het waarborgen van de veiligheid ervan, waardoor schijfbesparingen worden geëlimineerd door het systeem op een flashstation te installeren en clusters met minder dan drie knooppunten worden uitgesloten. Het agressieve beleid van de ontwikkelaar met betrekking tot optionele functies. Verre van minimalisme. De documentatie is op het niveau van “bedankt voor wat we hebben, maar het is heel erg mager.” Er wordt voorzien in de mogelijkheid om op een laag niveau met diensten te communiceren, maar de documentatie behandelt dit onderwerp te oppervlakkig, dus het is waarschijnlijker een nee dan een ja. Er is vrijwel geen kans om gegevens uit een noodsituatie te herstellen.

Opties voor verdere actie: verlaat CEPH en gebruik de banale btrfs met meerdere schijven (of xfs, zfs), ontdek nieuwe informatie over CEPH, waarmee u het onder de gespecificeerde omstandigheden kunt gebruiken, probeer uw eigen opslag te schrijven als een geavanceerde opleiding.

Bron: www.habr.com