Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- software:ceph-storage-cluster [2021/10/14 19:53] – [MGR Einstellungen] st
+++ software:ceph-storage-cluster [2024/03/11 23:25] (aktuell) – [Benchmarks] st
@@ Zeile 1: / Zeile 1: @@
 ====== ceph storage cluster ======
-Ceph ist eine in "die Breite" skalierende software-basierte Storagelösung. Es können Einzelfestplatten in handelsüblichen Computern zu einem ausfallsicheren Cluster vereint werden.
+Ceph ist eine in "die Breite" skalierende software-basierte Storagelösung mit Fokus auf Ausfallsicherheit. Es können Einzelfestplatten in handelsüblichen Computern zu einem ausfallsicheren Cluster vereint werden. Alle folgenden Zugriffsmethoden werden intern auf Objekte abgebildet.
-Alle folgenden Zugriffsmethoden werden intern auf Objekte abgebildet.
   * **librados**: Direktzugriff für Anwendungen, Binding for div. Sprachen.
@@ Zeile 11: / Zeile 10: @@
 :!: Diese Doku basiert auf Ceph 16.x (pacific) (siehe [[https://docs.ceph.com/en/latest/releases/index.html|Versionsübersicht]]), einige Abschnitte basieren auf 12.x luminous und sind noch nicht in 16.x getestet (ggf. andere Syntax, Ausgaben etc.).
-Produkte wie [[Proxmox]] bieten eine Integration von Ceph (Server und Client).
+Produkte wie **[[software:proxmox#ceph|Proxmox]]** bieten eine Integration von Ceph (Server und Client).
@@ Zeile 69: / Zeile 68: @@
 **Was man allgemein wissen muss**:
   * Lesezugriffe werden auf dem primär (per CRUSH MAP) zuständigen OSD durchgeführt, nicht parallel auf auf allen OSD die Kopien haben
-  * nur wenn kein bluestore benutzt wird: journaling führt zur Halbierung der I/O wenn dafür kein extra Gerät gewählt wurde (zuerst wird sogar mit O_DIRECT and O_DSYNC geschrieben), hier sind dedizierte SSDs die erste Wahl.
+  * nur wenn kein bluestore benutzt wird: journaling führt zur Halbierung der I/O wenn dafür kein extra Gerät gewählt wurde (zuerst wird sogar mit O_DIRECT and O_DSYNC geschrieben), hier sind dedizierte SSDs/NVMe die erste Wahl.
   * scrubbing führt zu Leistungseinbrüchen, die [[http://docs.ceph.com/docs/master/rados/configuration/osd-config-ref/|Intervalle sollten angepasst werden]]:<file>[global]
 # 1 day: 86400
@@ Zeile 88: / Zeile 87: @@
     * [[http://docs.ceph.com/docs/jewel/radosgw/multisite/|RGW Multisite]]: Master-Master-Setup
     * über CRUSH-Rules kann die geforderte örtliche Verteilung (Datenzentren, Brandabschnitte) eingestellt werden, dazu müssen die Verbindungen performant genug sein (niedrige Latenz, Bandbreite)
+**Latenz**: Da die Daten über Netzwerk, CPU, RAM des lokalen und entfernter Rechner geschleust werden müssen, ist die Leistung nicht mit lokalen Datenträgern vergleichbar. Insbesondere die Latenz steigt deutlich an was für bestimmte Zeitkritische Applikationen (z.B. Datenbanken) problematisch sein kann. Insbesondere die Ausreißer nach oben können problematisch sein.
+Möglicherweise sind
+''ceph osd perf'' zeigt die aktuell performance der OSDs an.
+nativ lokal möglich:
+  * NVMe + SSD (lokal): ~0,25ms
+  * disk 7200rpm (lokal): 4,17ms
+  * disk 5400rpm (lokal): 5,56ms
+siehe auch:
+  * [[https://www.proxmox.com/en/downloads/item/proxmox-ve-ceph-benchmark-2020-09|Ceph Benchmark 2020/09 rev.2]].
+  * [[https://www.heise.de/select/ix/2018/2/1517701858523828|Performance-Tuning für Ceph]] (2018)
 **Anforderungen allgemein**:
@@ Zeile 118: / Zeile 132: @@
   * [[https://www.youtube.com/watch?v=OopRMUYiY5E|Ceph at CERN: A Year in the Life of a Petabyte-Scale Block Storage Service]]
+==== Hyperconverged setup ====
+[[https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_hyper_converged_infrastructure|Hyperconverged setup]] bedeutet: Storage und Virtualisierungsnodes sind die gleichen Maschinen.
+Vorteile:
+  - einfacheres setup
+  - weniger hardware nötig
+Nachteile:
+  - rebalance frisst RAM und CPU
+  - keine Trennung zwischen Storage und Virtualisierung
 ==== Benchmarks ====
+[[https://www.thomas-krenn.com/de/wiki/Ceph_Perfomance_Guide_-_Sizing_%26_Testing|Ceph Perfomance Guide - Sizing & Testing]]
 rados bench: Installation aus Paketquelle: https://download.ceph.com/
@@ Zeile 133: / Zeile 160: @@
 ===== Administrative Tätigkeiten =====
-==== Wartungsmodus ====
+==== wichtige OSD Befehle ====
-Bei geplante Wartungen (reboots, ...) kann der Cluster in einen "Wartungsmodus" geschaltet werden, der verhindert das Reparaturaktionen wie rebalancing von alleine starten:
+Bei geplante Wartungen (reboots, upgrades, ...) hat Ceph vielfältige Optionen.
-**Anschalten**:
+^ ceph osd set/unset ... ^ Bedeutung ^
-<code bash>ceph osd set noout</code>
+| nobackfill | backfill wird ausgesetzt |
-**Ausschalten**:
+| nodeep-scrub | (deep-) scrubbing temporär deaktivieren |
-<code bash>ceph osd unset noout</code>
+| nodown | OSD-Fehler werden ignoriert (keine Markierung als down) |
+| noin | OSDs die vorher "out" waren, werden nicht wieder aufgenommen wenn sie starten |
+| **noout** | nodes werden nicht aus dem Cluster entfernt (z.B. für reboots) |
+| **norebalance** | rebalance der Daten findet nicht statt (z.B. für Wartung) |
+| norecover |  |
+| noscrub | scrubbing temporär deaktivieren |
+| notieragent | cache tiering wird ausgesetzt |
+| noup | OSD können nicht mehr gestartet werden (werden nicht in den pool aufgenommen) |
+| pause | I/O-Zugriff wird pausiert, kein Lese- und Schreibzugriff, client bleiben im blocked-Status hängen |
 ==== Dienste verwalten ====
@@ Zeile 154: / Zeile 189: @@
 sudo systemctl restart ceph-mds.target
 </code>
-==== scrubbing temporär deaktivieren ====
-An:
-<code bash>
-ceph osd set noscrub
-ceph osd set nodeep-scrub
-</code>
-Aus:
-<code bash>
-ceph osd unset noscrub
-ceph osd unset nodeep-scrub
-</code>
 ==== iSCSI Zugriff ====
@@ Zeile 190: / Zeile 208: @@
 <code bash>ceph pg repair 1.4ac</code>
+Für Rados:
+<code bash>
+rados lspools
+rados list-inconsistent-pg {POOL}
+rados list-inconsistent-obj {placement-group-ID} --format=json-pretty
+</code>
 ===== Monitoring =====
@@ Zeile 204: / Zeile 227: @@
 ==== Zabbix-Integration  ====
+[[https://raw.githubusercontent.com/ceph/ceph/master/src/pybind/mgr/zabbix/zabbix_template.xml|Template]]
 Konfiguration (gilt global und wird vom MGR ausgeführt):
@@ Zeile 505: / Zeile 530: @@
 Beispiel OSD.0 entfernen:
 <code bash>
+ceph osd down 10
+systemctl stop ceph-osd@10
 ceph osd purge 0 --yes-i-really-mean-it
-ceph osd crush remove osd.0
+# nicht mehr nötig:
-ceph auth del osd.0
+# ceph osd crush remove osd.0
+# ceph auth del osd.0
 # "updated"
 # oder:
@@ Zeile 513: / Zeile 541: @@
 </code>
+wenn das Gerät dann immer noch busy ist:
+<code bash>
+ls /dev/mapper/ceph-* | xargs -I% -- dmsetup remove %
+partprobe $DISK
+sgdisk --zap-all $DISK
+</code>
+[[https://github.com/rook/rook/issues/9764|Quelle]]
 ==== Cluster Einstellungen ====
@@ Zeile 548: / Zeile 583: @@
 </code>
+:!: Achtung: Standardmäßig achtet ceph nur darauf das die Repliken auf unterschiedlichen Hosts sind. Wenn die Replikate der Placement Groups dann zufällig im gleichen datacenter landen und das wegfällt ... sind die Daten auch weg!
+=== Crush-Regeln Anpassen ===
+**Vorgehensweise**:
+<code bash>
+ceph osd getcrushmap > crush.map.lng.bin # CRUSH-Map extrahieren
+crushtool -d crush.map.lng.bin -o crush.map.txt # CRUSH-Map dekompilieren
+</code>
+Änderungen machen...
+<code bash>
+crushtool -c crush.map.txt -o crush.map.new.bin # CRUSH-Map kompilieren
+ceph osd setcrushmap -i crush.map.new.bin # CRUSH-Map wieder einfügen
+</code>
+default-Regel:
+<file>
+rule replicated_rule {
+        id 0
+        type replicated
+        min_size 1
+        max_size 10
+        step take default
+        step chooseleaf firstn 0 type host
+        step emit
+}
+</file>
+Hier ein komplexes Beispiel mit zwei datacentern und 4,3,2-fache Replikation (min_size setzt die [[https://docs.ceph.com/en/latest/rados/operations/pools/#set-the-number-of-object-replicas|minimal nötige Replika-Anzahl um Schreiben zu können]].)
+<file>
+rule dc1_dc2_4repl_rule {
+        id 1
+        type replicated
+        min_size 1
+        max_size 4
+        step take default
+        step choose firstn 2 type datacenter
+        step chooseleaf firstn 2 type host
+        step emit
+}
+rule dc1_dc2_3repl_rule {
+        id 2
+        type replicated
+        min_size 1
+        max_size 3
+        step take default
+        step choose firstn 2 type datacenter
+        step chooseleaf firstn 2 type host
+        step emit
+}
+rule dc1_dc2_2repl_rule {
+        id 3
+        type replicated
+        min_size 1
+        max_size 2
+        step take default
+        step chooseleaf firstn 2 type datacenter
+        step emit
+}
+</file>
+Die Zeile "step chooseleaf firstn 2 type host" ist bei zwei DC (und ungeraden Replikationen) nötig damit er nicht mehrfach auf dem selben host landet.
+Fehlerhafte Crush rules erkennt man am dauerhaften unclean-Status von PGs.
 ===== Problembehandlung =====
@@ Zeile 913: / Zeile 1008: @@
 <code bash>ceph osd pool create pool1 erasure</code>
-List pools: <code bash>ceph osd pool ls</code>
+Für ceph-fs:
+<code bash>
+ceph osd pool create cephfs_data
+ceph osd pool create cephfs_metadata
+ceph fs new $pool1 cephfs_metadata cephfs_data
+</code>
+**List pools**: <code bash>ceph osd pool ls</code>
 <file>
 device_health_metrics
@@ Zeile 1187: / Zeile 1289: @@
 <code bash>fusermount -u /media/rdb</code>
+==== RGW (S3) ====
+[[https://docs.ceph.com/en/latest/man/8/radosgw-admin/|radosgw-admin (man page)]]