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
