Wenn die Datenmenge größer wird als der Speicherplatz auf einer Festplatte, wird es Zeit, über RAID nachzudenken. In meiner Kindheit hörte ich oft von älteren: "Eines Tages wird RAID der Vergangenheit angehören, Objekt-Speicher werden die Welt überfluten, und du weißt nicht einmal, was CEPH ist." Daher war das erste, was ich in meiner Selbstständigkeit tat, die Erstellung meines eigenen Clusters. Ziel des Experiments war es, das Innenleben von Ceph kennenzulernen und den Rahmen seines Einsatzes zu verstehen. Wie sinnvoll ist die Implementierung von Ceph im Mittelstand und im Kleinunternehmen? Nach mehreren Jahren Betrieb und einigen irreversiblen Datenverlusten entstand ein Verständnis für die Feinheiten — es ist nicht alles so eindeutig. Die Besonderheiten von CEPH erschweren seine breite Verbreitung, und aufgrund dieser sind die Experimente in eine Sackgasse geraten. Im Folgenden wird die Beschreibung aller durchgeführten Schritte, das erzielte Ergebnis und die getroffenen Schlussfolgerungen dargelegt. Ich wäre dankbar, wenn erfahrene Personen ihre Erfahrungen teilen und einige Punkte erläutern würden.
Hinweis: Kommentatoren wiesen auf schwerwiegende Fehler in einigen Annahmen hin, die eine Überarbeitung des gesamten Artikels erfordern.
CEPH-Strategie
Der CEPH-Cluster kombiniert beliebig viele K-Disketten 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 man entweder einen RAID 1 oder ein Cluster mit N=2 erstellen — das Ergebnis ist dasselbe. Wenn es drei Festplatten gibt und sie unterschiedliche Größen haben, ist es einfach, ein Cluster mit N=2 zu bilden: Ein Teil der Daten wird auf den Festplatten 1 und 2 gespeichert, ein anderer Teil auf 1 und 3, und ein weiterer Teil auf 2 und 3. Bei RAID ist dies jedoch nicht möglich (man kann ein solches RAID erstellen, aber das wäre eine Verfälschung). Wenn es noch mehr Festplatten gibt, ist die Erstellung eines RAID 5 möglich. CEPH hat ein Äquivalent — erasure_code, das den früheren Konzepten der Entwickler widerspricht und daher nicht berücksichtigt wird. RAID 5 setzt voraus, dass eine kleine Anzahl von Festplatten vorhanden ist und dass alle in gutem Zustand sind. Bei einem Ausfall einer Festplatte sollten die anderen so lange durchhalten, bis die defekte Festplatte ersetzt wird und die Daten darauf wiederhergestellt werden. CEPH hingegen, bei N>=3, fördert die Verwendung alter Festplatten. Insbesondere wenn man mehrere gute Festplatten für die Speicherung einer Kopie von Daten hält und die verbleibenden zwei bis drei Kopien auf einer großen Menge alter Festplatten lagert, wird die Information sicher sein. Solange die neuen Festplatten intakt sind, gibt es keine Probleme. Und falls eine von ihnen ausfällt, ist ein gleichzeitiger Ausfall von drei Festplatten mit einer Lebensdauer von mehr als fünf Jahren, idealerweise aus verschiedenen Servern, ein äußerst unwahrscheinliches Ereignis.
Bei der Verteilung von Kopien gibt es eine Nuance. Standardmäßig wird angenommen, dass die Daten auf eine größere Anzahl von Verteilungseinheiten (~100 pro Disk) aufgeteilt werden, wobei jede Einheit auf einigen Festplatten dupliziert wird. Nehmen wir an, K=6, N=2: Wenn zwei beliebige Festplatten ausfallen, gehen die Daten garantiert verloren, da nach der Wahrscheinlichkeitstheorie mindestens eine Einheit auf genau diesen beiden Festplatten liegen wird. Der Verlust einer Einheit macht alle Daten im Pool unzugänglich. Wenn die Festplatten jedoch in drei Paare unterteilt und das Speichern von Daten nur auf Festplatten innerhalb eines Paares erlaubt wird, ist eine solche Verteilung auch gegen den Ausfall einer beliebigen Festplatte stabil. Bei einem Ausfall von zwei Festplatten beträgt die Wahrscheinlichkeit eines Datenverlustes jedoch nicht 100 %, sondern nur 3/15, und selbst bei einem Ausfall von drei Festplatten nur 12/20. Daraus ergibt sich, dass die Entropie in der Datenverteilung nicht zur Ausfallsicherheit beiträgt. Auch ist zu beachten, dass für einen Datei-Server der verfügbare Arbeitsspeicher die Reaktionsgeschwindigkeit erheblich erhöht. Je mehr Speicher in jedem Knoten und je mehr Speicher in allen Knoten vorhanden ist, desto schneller wird es. Dies ist zweifellos ein Vorteil des Clusters gegenüber einem einzelnen Server und erst recht gegenüber einem Hardware-NAS, in das sehr wenig Speicher integriert wird.
Daraus folgt, dass CEPH eine gute Möglichkeit ist, mit minimalen Investitionen aus veralteter Hardware ein zuverlässiges Speichersystem mit mehreren Terabyte und Skalierbarkeit zu schaffen (hier sind natürlich Kosten erforderlich, aber sie sind gering im Vergleich zu kommerziellen Storage-Systemen).
Implementierung des Clusters
Für das Experiment nehmen wir einen ausgemusterten Computer Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Vier Platten mit jeweils 2 TB richten wir in einem RAID10-ähnlichen System ein, nach dem erfolgreichen Test fügen wir einen zweiten Knoten und ebenso viele Festplatten hinzu.
Wir installieren Linux. Die Distribution sollte anpassbar und stabil sein. Debian und Suse erfüllen diese Anforderungen. Suse hat einen flexibleren Installer, der es ermöglicht, Pakete abzuwählen; leider konnte ich nicht herausfinden, welche ohne Auswirkungen auf das System entfernt werden können. Wir installieren Debian über debootstrap buster. Die Option min-base installiert ein nicht funktionsfähiges System, dem die Treiber fehlen. Der Größenunterschied zur Vollversion ist nicht so groß, dass es sich lohnt, sich zu kümmern. Da die Arbeit auf einer physischen Maschine erfolgt, möchte ich Snapshots erstellen, wie es bei virtuellen Maschinen der Fall ist. Diese Möglichkeit bietet entweder LVM oder btrfs (oder xfs oder zfs — der Unterschied ist nicht groß). Bei LVM sind Snapshots nicht die Stärke. Wir verwenden btrfs. Und der Bootloader wird in MBR installiert. Es gibt keinen Sinn darin, die Festplatte mit einem 50 MB FAT-Partition zu belasten, wenn man es in die 1 MB große Partitionsübersicht quetschen kann und den gesamten Platz für das System nutzen kann. Auf der Festplatte belegte es 700 MB. Wie viel die Grundinstallation von SUSE benötigt, habe ich nicht behalten, es waren ungefähr 1,1 oder 1,4 GB.
Wir installieren CEPH. Wir ignorieren die Version 12 im Debian-Repository und nehmen direkt die Version 15.2.3 von der Webseite. Wir folgen der Anleitung im Abschnitt „CEPH manuell installieren“ mit den folgenden Einschränkungen:
- Vor der Verbindung mit dem Repository müssen gnupg, wget und ca-certificates installiert werden.
- Nach der Verbindung mit dem Repository, 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.
- Bei der Installation von CEPH wird aus unerklärlichen Gründen versucht, lvm2 zu installieren. Das ist grundsätzlich kein Problem, aber die Installation schlägt fehl, sodass auch CEPH 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 an Objekte entgegennimmt und ausführt. Auf der Festplatte werden zwei Partitionen erstellt. Eine davon enthält Informationen über den Cluster, die Festplattennummer sowie die Schlüssel für den Cluster. Diese Informationen mit einem Umfang von 1 KB werden einmal bei der Hinzufügung der Festplatte erstellt und verändern sich später in der Regel nicht. Die zweite Partition hat kein Dateisystem und speichert binäre CEPH-Daten. 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 gibt keinen Anlass zur Klage. Ich denke, dass man die xfs-Partition problemlos auch durch ext ersetzen könnte. Diese Partition wird in /var/lib/… gemountet, wo der Dienst Informationen über OSD liest und auch den Verweis auf das Blockgerät findet, auf dem die binären Daten gespeichert sind. Theoretisch könnten die Hilfsanwendungen sofort in /var/lib/… untergebracht werden, während die gesamte Festplatte für Daten verwendet wird. Bei der Erstellung von OSD über ceph-deploy wird automatisch eine Regel für die Montage der Partition in /var/lib/… erstellt, und die Rechte für den Benutzer ceph zum Lesen des erforderlichen Blockgeräts werden zugewiesen. Bei einer manuellen Installation muss dies selbst durchgeführt werden, in der Dokumentation wird nichts dazu gesagt. Es ist auch empfehlenswert, den Parameter osd memory target anzugeben, damit ausreichend physischer Speicher vorhanden ist.
ceph-mds. Auf niedriger Ebene ist CEPH ein objektbasiertes Speichersystem. Die Funktionalität der Blockspeicherung reduziert sich auf die Speicherung jedes Blocks von 4 MB als Objekt. Das Dateispeichersystem funktioniert nach dem gleichen Prinzip. Es werden zwei Pools erstellt: einer für Metadaten und der andere für Daten. Diese werden in einem Dateisystem zusammengefasst. In diesem Moment wird ein gewisser Eintrag erstellt, sodass, wenn das Dateisystem gelöscht wird, aber beide Pools erhalten bleiben, es nicht möglich ist, es wiederherzustellen. Es gibt ein Verfahren zum Abrufen von Dateien blockweise, das ich jedoch nicht getestet habe. Der Zugriff auf das Dateisystem wird durch den Dienst ceph-mds geregelt. Für jedes Dateisystem ist eine separate Instanz des Dienstes erforderlich. Es gibt die Option "Index", die es erlaubt, eine Art von mehreren Dateisystemen in einem zu erstellen – auch dies wurde nicht getestet.
ceph-mon — dieser Dienst speichert die Clusterkarte. Er enthält Informationen über alle OSD, den Algorithmus zur Verteilung von PG in OSD und, am wichtigsten, Informationen über alle Objekte (die Einzelheiten 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 105 K Objekte, was etwas mehr als 256 Bytes pro Objekt ergibt; ich denke, dass der Monitor eine Liste aller Objekte und PG speichert, in denen sie sich befinden). Eine Beschädigung dieses Verzeichnisses führt zum Verlust aller Daten im Cluster. Daraus ergibt sich die Schlussfolgerung, dass CRUSH zeigt, wie PG auf OSD verteilt sind, während die Anordnung der Objekte in PG zentral in der Datenbank gespeichert wird, egal wie sehr die Entwickler versuchen, dieses Wort zu vermeiden. Folglich können wir erstens das System nicht im RO-Modus auf einem USB-Stick installieren, da ständig in die Datenbank geschrieben wird; es ist eine zusätzliche Festplatte für diese notwendig (vermutlich nicht mehr als 1 GB), und zweitens müssen wir in Echtzeit eine Kopie dieser Datenbank haben. Wenn mehrere Monitore vorhanden sind, wird die Redundanz automatisch gewährleistet, aber in unserem Fall gibt es nur einen Monitor, maximal zwei. Es gibt ein theoretisches Verfahren zur Wiederherstellung des Monitors auf Grundlage der OSD-Daten, das ich aus verschiedenen Gründen dreimal versucht habe, und dreimal gab es keine Fehlermeldungen und keine Daten. Leider funktioniert dieser Mechanismus nicht. Entweder wir nutzen ein minimales Verzeichnis auf OSD und erstellen ein RAID zur Speicherung der Datenbank, was sich sicherlich sehr negativ auf die Leistung auswirken wird, oder wir stellen mindestens zwei zuverlässige physische Speichermedien bereit, vorzugsweise USB, um die Ports nicht zu blockieren.
rados-gw — exportiert Objektspeicher über das S3-Protokoll und ähnliche. Es erstellt viele Pools, ohne dass ganz klar ist, warum. Ich habe nicht besonders experimentiert.
ceph-mgr — bei der Installation dieses Dienstes werden mehrere Module gestartet. Eines davon ist das nicht ausschaltbare Autoscaling. Es versucht, die richtige Anzahl an PG/OSD aufrechtzuerhalten. Wenn man das Verhältnis manuell steuern möchte, kann das Skalieren für jeden Pool verboten werden, doch in diesem Fall stürzt das Modul mit einer Division durch 0 ab, und der Clusterstatus wird zu ERROR. Das Modul ist in Python geschrieben, und wenn man die entsprechende Zeile auskommentiert, führt das zu seiner Deaktivierung. Ich erinnere mich nicht mehr an die Details.
Verwendete Quellen:
Skripte auflisten:
Installation des Systems ü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 6Erstellung eines Clusters
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@rbd1Hinfügung 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@$osdnumZusammenfassung
Das Hauptmarketingmerkmal von CEPH ist CRUSH – ein Algorithmus zur Berechnung der Datenplatzierung. Die Monitore verbreiten diesen Algorithmus an die Kunden, die dann direkt das benötigte Knoten- und OSD anfragen. CRUSH sorgt dafür, dass es keine Zentralisierung gibt. 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 Monitore zerstört und neu erstellt werden, während alle OSD und CRUSH beibehalten werden, reicht das nicht aus, um das Cluster wiederherzustellen. Daraus folgt, dass auf jedem Monitor einige Metadaten über das gesamte Cluster gespeichert sind. Ein geringes Volumen dieser Metadaten schränkt die Clustergröße nicht ein, verlangt jedoch, dass ihre Integrität gewährleistet wird, was den Einsatz von Flash-Laufwerken zur Installation des Systems und Cluster mit weniger als drei Knoten ausschließt. Eine aggressive Politik des Entwicklers in Bezug auf optionale Funktionen. Sehr weit entfernt vom Minimalismus. Die Dokumentation ist auf dem Niveau: „Danke für das, was es gibt, aber es ist sehr, sehr spärlich.“ Es gibt die Möglichkeit, auf niedrigem Niveau mit den Diensten zu interagieren, aber die Dokumentation behandelt dieses Thema nur sehr oberflächlich, sodass es eher ein Nein als ein Ja gibt. Praktisch keine Chancen auf Datenwiederherstellung aus einer Notfallsituation.
Mögliche weitere Schritte: CEPH ablehnen und auf das einfache Multi-Disksystem btrfs (oder xfs, zfs) umsteigen, neue Informationen über CEPH einholen, die es ermöglichen, es unter den angegebenen Bedingungen zu betreiben, oder zur Weiterbildung ein eigenes Speicher-System schreiben.
Quelle: habr.com
