Erfahrungen mit der Nutzung von CEPH

Wenn die Menge an Daten größer wird als das, was auf eine einzelne Festplatte passt, ist es höchste Zeit, über RAID nachzudenken. In meiner Kindheit hörte ich oft von älteren Menschen: "Eines Tages werden RAIDs der Vergangenheit angehören, Objektspeicher werden die Welt erobern, und du weißt nicht einmal, was CEPH ist." Daher war es das Erste, was ich in meinem eigenen Leben tat, einen Cluster zu schaffen. Ziel des Experiments war es, das Innenleben von Ceph kennenzulernen und den Rahmen seiner Anwendung zu verstehen. Wie gerechtfertigt ist der Einsatz von Ceph im Mittelstand und im Kleingewerbe? Nach mehreren Jahren der Nutzung und ein paar irreversiblen Datenverlusten entstand ein Verständnis für die Feinheiten, dass nicht alles so eindeutig ist. Die Besonderheiten von CEPH erschweren seine breite Verbreitung, und aufgrund dieser Hindernisse geraten die Experimente in eine Sackgasse. Im Folgenden wird eine Beschreibung aller durchgeführten Schritte, das erhaltene Ergebnis und die getroffenen Schlussfolgerungen präsentiert. Wenn erfahrene Personen ihre Erfahrungen teilen und einige Punkte erläutern könnten, wäre ich dankbar.

Hinweis: Kommentatoren haben auf schwerwiegende Fehler in einigen Annahmen hingewiesen, die eine Überarbeitung des gesamten Artikels erfordern.

CEPH-Strategie

Der CEPH-Cluster vereint eine beliebige Anzahl von K Festplatten beliebiger Größe und speichert Daten auf ihnen, indem er jedes Stück (standardmäßig 4 MB) N-mal dupliziert.

Betrachten wir den einfachsten Fall mit zwei identischen Festplatten. Daraus kann entweder ein RAID 1 oder ein Cluster mit N=2 gebildet werden — das Ergebnis wird dasselbe sein. Wenn es drei Festplatten gibt und diese unterschiedliche Größen haben, ist es einfach, ein Cluster mit N=2 zu erstellen: Ein Teil der Daten wird auf den Festplatten 1 und 2, ein Teil auf 1 und 3 und ein Teil auf 2 und 3 gespeichert, während RAID nicht möglich ist (man kann zwar ein solches RAID einrichten, aber das wäre eine Ungereimtheit). Bei noch mehr Festplatten ist die Erstellung von RAID 5 möglich, während CEPH eine ähnliche Funktion bietet — erasure_code, die den ursprünglichen Konzepten der Entwickler widerspricht und daher nicht in Betracht gezogen wird. RAID 5 geht davon aus, dass es eine geringe Anzahl von Festplatten gibt, und dass alle in gutem Zustand sind. Bei einem Ausfall einer Festplatte müssen die anderen bis zur Ersetzung der Festplatte und der Wiederherstellung der Daten darauf bestehen bleiben. CEPH hingegen ermutigt bei N>=3 zur Verwendung alter Festplatten; insbesondere wenn man mehrere zuverlässige Festplatten zur Speicherung einer Kopie der Daten hat, während die verbleibenden zwei bis drei Kopien auf einer großen Anzahl alter Festplatten gespeichert werden, dann sind die Informationen sicher, da solange die neuen Festplatten intakt sind, keine Probleme bestehen, und falls eine von ihnen ausfällt, ist ein gleichzeitiger Ausfall von drei Festplatten mit einer Lebensdauer von über fünf Jahren, vorzugsweise aus verschiedenen Servern — ein extrem unwahrscheinliches Ereignis.

Bei der Verteilung von Kopien gibt es eine Feinheit. Standardmäßig wird davon ausgegangen, dass Daten auf eine größere Anzahl (ca. 100 pro Festplatte) von PG-Verteilungsgruppen verteilt werden, von denen jede auf bestimmten Festplatten dupliziert wird. Angenommen, K=6, N=2, dann gehen beim Ausfall zweier beliebiger Festplatten garantiert Daten verloren, da nach der Wahrscheinlichkeitstheorie mindestens eine PG auf genau diesen beiden Festplatten liegt. Der Verlust einer Gruppe macht alle Daten im Pool unzugänglich. Wenn man die Festplatten jedoch in drei Paare aufteilt und das Speichern von Daten nur auf Festplatten innerhalb eines Paares erlaubt, dann ist diese Verteilung ebenfalls gegenüber dem Ausfall einer beliebigen Festplatte resilient. Bei dem Ausfall zweier Festplatten beträgt die Wahrscheinlichkeit eines Datenverlustes jedoch nicht 100 %, sondern nur 3/15, und selbst beim Ausfall dreier Festplatten nur 12/20. Daraus folgt, dass die Entropie in der Datenverteilung nicht zur Ausfallsicherheit beiträgt. Darüber hinaus bemerken wir, dass für einen Dateiserver der freie Arbeitsspeicher die Reaktionsgeschwindigkeit erheblich erhöht. Je mehr Speicher in jedem Knoten vorhanden ist und je mehr Speicher in allen Knoten vorhanden ist, desto schneller wird es sein. Dies ist zweifellos ein Vorteil eines Clusters gegenüber einem einzelnen Server und erst recht gegenüber einem Hardware-NAS, in das nur eine sehr geringe Menge an Speicher integriert ist.

Daraus folgt, dass CEPH eine gute Möglichkeit ist, mit minimalen Investitionen aus veralteter Hardware ein zuverlässiges Datenspeichersystem von mehreren TB mit Skalierungsmöglichkeiten zu schaffen (hier sind natürlich Investitionen erforderlich, jedoch gering im Vergleich zu kommerziellen SANs).

Einsatz eines Clusters

Für das Experiment nehmen wir einen außer Betrieb genommenen Computer: Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Vier Festplatten mit 2 TB werden zu einer RAID10-ähnlichen Konfiguration organisiert, nach erfolgreicher Prüfung fügen wir einen zweiten Knoten und ebenso viele Festplatten hinzu.

Installation von Linux. Der Distributor sollte anpassbar und stabil sein. Debian und Suse erfüllen diese Anforderungen. Suse verfügt über einen flexibleren Installer, der es ermöglicht, jedes Paket abzuwählen; leider konnte ich nicht herausfinden, welche ich ohne negative Auswirkungen auf das System entfernen kann. Wir installieren Debian über debootstrap buster. Die Option min-base installiert ein nicht funktionierendes System, dem die Treiber fehlen. Der Größenunterschied zur Vollversion ist nicht so groß, dass es sich lohnt, sich damit zu beschäftigen. Da die Arbeit auf einer physischen Maschine erfolgt, würden wir gerne Snapshots machen, wie auf VMs. Diese Möglichkeit bieten entweder LVM oder btrfs (oder xfs oder zfs – der Unterschied ist nicht groß). Snapshots sind nicht die Stärke von LVM. Wir installieren btrfs. Der Bootloader wird im MBR installiert. Es macht keinen Sinn, die Festplatte mit 50 MB für eine FAT-Partition zu verstopfen, wenn wir sie in einen 1 MB Bereich der Partitionstabelle quetschen und den gesamten Platz dem System zuweisen können. Es hat 700 MB auf der Festplatte eingenommen. Ich habe nicht gemerkt, wie viel die Grundinstallation von SUSE benötigt – ich denke, es waren etwa 1,1 oder 1,4 GB.

Installation von CEPH. Wir ignorieren Version 12 im Debian-Repository und verbinden uns direkt von der Website 15.2.3. Wir folgen den Anweisungen im Abschnitt „Installation von CEPH manuell“ mit den folgenden Vorbehalten:

• Vor dem Hinzufügen des Repositories müssen gnupg wget ca-certificates installiert werden.
• Nach dem Hinzufügen des Repositories, aber vor der Installation des Clusters wurde die Installation der Pakete weggelassen: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
• Zum Zeitpunkt der Installation von CEPH wird aus unerklärlichen Gründen versucht, lvm2 zu installieren. Im Grunde genommen ist es nicht schade, aber die Installation schlägt fehl, sodass CEPH auch nicht installiert werden kann.

  Dieser Patch hat geholfen:

  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
  

Clusterübersicht

ceph-osd — verantwortlich für die Speicherung von Daten auf der Festplatte. Für jede Festplatte wird ein Netzwerkdienst gestartet, der Lese- oder Schreibanfragen für Objekte entgegennimmt und ausführt. Auf der Festplatte werden zwei Partitionen erstellt. Eine davon enthält Informationen über den Cluster, die Festplattennummer sowie Schlüssel für den Cluster. Diese Informationen, die 1 KB umfassen, werden einmalig bei der Hinzufügung der Festplatte erstellt und haben sich danach nie geändert. Auf der zweiten Partition befindet sich kein Dateisystem, sondern es werden binäre CEPH-Daten gespeichert. Die automatische Installation in früheren Versionen erstellte eine xfs-Partition mit einer Größe von 100 MB für Verwaltungsinformationen. Ich habe die Festplatte in MBR konvertiert und nur 16 MB zugewiesen — der Dienst beschwert sich nicht. Ich denke, dass xfs sicherlich auch durch ext ersetzt werden könnte. Diese Partition wird in /var/lib/... gemountet, wo der Dienst Informationen über OSD liest und außerdem den Link zu dem blockbasierten Gerät findet, auf dem die binären Daten gespeichert sind. Theoretisch könnten die Hilfsdaten direkt in /var/lib/... platziert werden, während die gesamte Festplatte für Daten reserviert bleibt. Bei der Erstellung von OSD über ceph-deploy wird automatisch eine Regel zum Mounten der Partition in /var/lib/... erstellt, und dem Benutzer ceph werden Lese-Rechte für das benötigte blockbasierte Gerät zugewiesen. Bei einer manuellen Installation muss dies selbst durchgeführt werden, in der Dokumentation steht dazu nichts. Es ist auch ratsam, den Parameter osd memory target anzugeben, damit genügend physischer Speicher zur Verfügung steht.

ceph-mds. Auf niedriger Ebene ist CEPH — ein objektspeicher. Die Möglichkeit des blockbasierten Speicherns beschränkt sich auf die Speicherung jedes 4 MB großen Blocks als Objekt. Das Dateispeicher funktioniert nach dem gleichen Prinzip. Es werden zwei Pools erstellt: einer für Metadaten, der andere für Daten. Diese werden in einem Dateisystem zusammengefasst. In diesem Moment wird ein gewisser Eintrag erstellt, deshalb kann die Dateisystem nicht wiederhergestellt werden, wenn es gelöscht wird, aber beide Pools bleiben erhalten. Es gibt ein Verfahren zur Extraktion von Dateien in Blöcken, das ich nicht getestet habe. Für den Zugriff auf das Dateisystem ist der Dienst ceph-mds verantwortlich. Jede Dateisystem benötigt ein separates Exemplar des Dienstes. Es gibt die Option „Index“, die es ermöglicht, eine Art von mehreren Dateisystemen in einer zu erstellen — das wurde ebenfalls nicht getestet.

ceph-mon — dieser Dienst speichert die Clusterkarte. Er enthält Informationen über alle OSDs, den Algorithmus zur Verteilung von PGs auf OSDs und, was am wichtigsten ist, Informationen über alle Objekte (die Details dieses Mechanismus sind mir unklar: es gibt ein Verzeichnis /var/lib/ceph/mon/.../store.db, in dem sich eine große Datei – 26 MB – befindet, und im Cluster sind es 105k Objekte, was etwas mehr als 256 Byte pro Objekt ergibt. Ich denke, dass der Monitor eine Liste aller Objekte und PGs, in denen sie sich befinden, speichert). Eine Beschädigung dieses Verzeichnisses führt zum Verlust aller Daten im Cluster. Daraus ergibt sich der Schluss, dass CRUSH zeigt, wie PGs auf OSDs verteilt sind, während die Objekte zentral in einer Datenbank gespeichert sind, egal wie sehr die Entwickler dieses Wort zu vermeiden versuchen. Folglich können wir erstens das System nicht im RO-Modus auf einem Flash-Laufwerk installieren, da in die Datenbank ständig geschrieben wird; es ist eine zusätzliche Festplatte erforderlich (vermutlich nicht mehr als 1 GB). Zweitens ist es notwendig, in Echtzeit eine Kopie dieser Datenbank zu haben. Wenn es mehrere Monitore gibt, wird die Ausfallsicherheit automatisch gewährleistet. In unserem Fall gibt es jedoch nur einen Monitor, maximal zwei. Es gibt ein theoretisches Verfahren zur Wiederherstellung des Monitors auf der Grundlage von OSD-Daten, das ich aus verschiedenen Gründen dreimal angewendet habe und dreimal keine Fehlermeldungen oder Daten erhalten habe. Leider funktioniert dieser Mechanismus nicht. Entweder nutzen wir einen winzigen Abschnitt auf dem OSD und erstellen ein RAID zur Speicherung der Datenbank, was sich sicher sehr negativ auf die Leistung auswirken wird, oder wir stellen mindestens zwei zuverlässige physische Speichergeräte bereit, vorzugsweise USB, um die Ports nicht zu blockieren.

rados-gw — exportiert das Objektspeicher über das S3-Protokoll und ähnliche. Es erstellt viele Pools, was unklar ist. Ich habe nicht besonders experimentiert.

ceph-mgr — bei der Installation dieses Dienstes werden mehrere Module gestartet. Eines davon ist das nicht abschaltbare Autoscale. Es versucht, die richtige Anzahl von PGs/OSDs aufrechtzuerhalten. Wenn man möchte, kann man die Skalierung für jeden Pool unterbinden, aber in diesem Fall stürzt das Modul mit Division durch 0 ab, und der Clusterstatus wird ERROR. Das Modul ist in Python geschrieben, und wenn man die entsprechende Zeile auskommentiert, führt das zu seiner Deaktivierung. Die Einzelheiten sind mir zu faul, mir wieder ins Gedächtnis zu rufen.

Liste der verwendeten Quellen:

Installation von CEPH
Wiederherstellung bei vollständigem Ausfall des Monitors

Skripte Auflistungen:

Systeminstallation über 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 6

Cluster erstellen

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

Hinzufügen von OSD (Teil)

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

Zusammenfassung

Der Hauptvorteil von CEPH ist CRUSH, ein Algorithmus zur Berechnung der Datenplatzierung. Monitore verbreiten diesen Algorithmus an die Kunden, wonach die Kunden direkt den benötigten Knoten und den gewünschten OSD anfragen. CRUSH gewährleistet die Dezentralisierung. Es handelt sich um eine kleine Datei, die man sogar ausdrucken und an die Wand hängen kann. Die Praxis hat gezeigt, dass CRUSH keine vollständige Karte ist. Wenn man die Monitore löscht und neu erstellt, während alle OSD und CRUSH beibehalten werden, reicht das nicht aus, um den Cluster wiederherzustellen. Daraus ergibt sich, dass auf jedem Monitor einige Metadaten über den gesamten Cluster gespeichert werden. Das geringe Volumen dieser Metadaten hat keine Einschränkungen für die Clustergröße zur Folge, erfordert jedoch deren Sicherheit, was eine Speicherersparnis durch die Installation des Systems auf einem USB-Stick ausschließt und Cluster mit weniger als drei Knoten ausschließt. Eine aggressive Haltung des Entwicklers gegenüber optionalen Features. Weit entfernt von Minimalismus. Die Dokumentation ist auf dem Niveau: „Danke für das, was vorhanden ist, aber es ist sehr, sehr spärlich.“ Die Möglichkeit zur Interaktion mit Diensten auf niedriger Ebene ist gegeben, aber die Dokumentation behandelt dieses Thema zu oberflächlich, weshalb es eher ein Nein als ein Ja gibt. Praktisch keine Chancen auf Datenwiederherstellung aus einer Notlage.

Möglichkeiten für das weitere Vorgehen: von CEPH absehen und ein einfaches Multi-Disks btrfs (oder xfs, zfs) verwenden, neue Informationen über CEPH sammeln, die die Nutzung unter den angegebenen Bedingungen ermöglichen, oder zur Weiterbildung ein eigenes Speichersystem schreiben.

Quelle: habr.com