Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
software:ceph-storage-cluster [2018/07/18 20:40] – [ceph storage cluster] st | software:ceph-storage-cluster [2023/01/16 21:07] – [OSD entfernen] st | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== ceph storage cluster ====== | ||
+ | Ceph ist eine in "die Breite" | ||
+ | |||
+ | * **librados**: | ||
+ | * **RadosGW**: | ||
+ | * **RDB**: " | ||
+ | * **Ceph FS**: Posix-kompatibles Dateisystem (FUSE) für Multisystemzugriff, | ||
+ | |||
+ | :!: Diese Doku basiert auf Ceph 16.x (pacific) (siehe [[https:// | ||
+ | |||
+ | Produkte wie **[[software: | ||
+ | |||
+ | |||
+ | ===== Links ===== | ||
+ | |||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | |||
+ | ===== Deploymethoden ===== | ||
+ | |||
+ | * cephadm: docker/ | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * ceph-deploy: | ||
+ | |||
+ | ===== Begriffe ===== | ||
+ | |||
+ | https:// | ||
+ | |||
+ | * **CRUSH-Algorithmus**: | ||
+ | * class: welcher Typ des storage soll auf einem OSD benutzt werden (z.B. hdd, ssd, nvme) | ||
+ | * failure-domain: | ||
+ | * **Placement Group (PG)**: logische Gruppierung von Objekten, die jeweils auf dem gleichen Satz von physikalischen Geräten gespeichert werden. Bei aktuellen Versionen (mindestens 16.x/ | ||
+ | * **Pools**: Standardpool namens „data“, eine Art mointpoint zur logischen Gliederung. erlauben individuelle Einstellungen u.a. bei der Redundanz (von striping bis x-faches mirroring) | ||
+ | * Mirroring: Anzahl der Kopien im Cluster (Ausfallsicherheit, | ||
+ | * Replikation: | ||
+ | * **striping**: | ||
+ | * **Stripe Units**: Größe der Daten | ||
+ | * **Objektgröße**: | ||
+ | * Stripe-Anzahl: | ||
+ | * **cluster map** (verwaltet vom MON): Liste bestehend aus Monitors, OSD, PG, Crush, MDS | ||
+ | * **Erasure coding**: Redundanz kann " | ||
+ | |||
+ | ===== Komponenten ===== | ||
+ | |||
+ | * **Node**: Server/ | ||
+ | * **Ceph OSD**: | ||
+ | * Überwachung der Verfügbarkeit des von ihm betreuten OSD (wenn nötig recovery und rebalancing) | ||
+ | * Management der Netzwerkkommunikation mit Ceph-Clients und anderen OSD Daemons. | ||
+ | * Integritätschecks (" | ||
+ | * Überwachung/ | ||
+ | * **manager daemon mgr** (ceph luminous+ builds >= v12.x): monitoring-Module und zusätzliche Schnittstellen für externe Systeme | ||
+ | * **Ceph-Monitor** (MON): mind. 1 besser 2+ | ||
+ | * erstellt Cluster-Map (=Gesamtbeschreibung des Clusterzustands) | ||
+ | * Status und Adressen aller OSD Daemons, Monitore und Metadata-Server | ||
+ | * Paxos-Algorithmus votet nodes raus Clients kontaktieren den Monitor für die Cluster-Map | ||
+ | * **Ceph Metadata Server (MDS)** | ||
+ | * speichert die Metadaten für CephFS | ||
+ | * Object storage und RBD benötigen keinen MDS | ||
+ | |||
+ | ===== Leistungsanforderungen ===== | ||
+ | |||
+ | **Was man allgemein wissen muss**: | ||
+ | * Lesezugriffe werden auf dem primär (per CRUSH MAP) zuständigen OSD durchgeführt, | ||
+ | * 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), | ||
+ | * scrubbing führt zu Leistungseinbrüchen, | ||
+ | # 1 day: 86400 | ||
+ | # 1 week: 604800 | ||
+ | # 30days: 2592000 | ||
+ | osd scrub load threshold = 0.5 | ||
+ | osd scrub min interval = 86400 | ||
+ | osd scrub max interval = 604800 | ||
+ | osd deep scrub interval = 2592000 | ||
+ | osd scrub during recovery = false | ||
+ | # only between hours 1 and 8: | ||
+ | osd scrub begin hour = 1 | ||
+ | osd scrub end hour = 8 | ||
+ | </ | ||
+ | * kleine Cluster (wenige Node, wenige Datenträger -> OSDs) sind etwas ungünstig in manchen Szenarien (man landet schneller bei " | ||
+ | * Geo-/ | ||
+ | * es gibt keine asynchrone Replikation (mit Ausnahme von [[http:// | ||
+ | * [[http:// | ||
+ | * über CRUSH-Rules kann die geforderte örtliche Verteilung (Datenzentren, | ||
+ | |||
+ | **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 | ||
+ | |||
+ | '' | ||
+ | |||
+ | nativ lokal möglich: | ||
+ | * NVMe + SSD (lokal): ~0,25ms | ||
+ | * disk 7200rpm (lokal): 4,17ms | ||
+ | * disk 5400rpm (lokal): 5,56ms | ||
+ | |||
+ | siehe auch: | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | |||
+ | **Anforderungen allgemein**: | ||
+ | * CPU (spezieller bei erasure-coding) so gut wie es noch sinnvoll und bezahlbar ist | ||
+ | * mind. 2x 1Gbit sind (idealerweise mehr, insbesondere für das interne Netzwerk) da Client das eine und der Cluster ein anderes (privates) Netzwerk) unterschiedliche Geräte für das Betriebssystem und den Komponenten jeweils auch | ||
+ | * passenderer Linux I/ | ||
+ | |||
+ | **Komponenten**: | ||
+ | * das Betriebssystem und die Komponenten sollte auf extra physikalischen Geräten platziert werden. Mindestens OSDs. | ||
+ | * OSD (1+, ungerade Anzahl!) | ||
+ | * Normalbetrieb: | ||
+ | * ~1GB Speicher für das Journal (SSD!) - Schreibgeschwindigkeit > 1Gbit/s (d.h. ~125MB/s) | ||
+ | * mds: | ||
+ | * 1 GB RAM per daemon | ||
+ | * Mon | ||
+ | * 1 GB RAM per daemon | ||
+ | * ruhig auf extra Hardware oder maximal mit client drauf, die Ressourcen-Anforderungen sind moderat/ | ||
+ | * extra device bzw. nicht device mit OSD teilen da fsyncs OSDs negativ beeinflussen können | ||
+ | * RBD Client: Kernel 4.5+ für CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING | ||
+ | * Journale (unnötig bei bluestore) | ||
+ | * SSD (NVMe?) | ||
+ | * hohe IOPs bei zufälligen und massiv parallelen kleinen Schreibvorgängen | ||
+ | * SSDs: hohe write endurance (TBW) | ||
+ | |||
+ | Links: | ||
+ | * http:// | ||
+ | * https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | ==== Hyperconverged setup ==== | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | Vorteile: | ||
+ | - einfacheres setup | ||
+ | - weniger hardware nötig | ||
+ | |||
+ | Nachteile: | ||
+ | - rebalance frisst RAM und CPU | ||
+ | - keine Trennung zwischen Storage und Virtualisierung | ||
+ | ==== Benchmarks ==== | ||
+ | |||
+ | rados bench: Installation aus Paketquelle: | ||
+ | |||
+ | <code bash> | ||
+ | rados bench -p scbench 10 write --no-cleanup | ||
+ | rados bench -p scbench 10 seq | ||
+ | rados bench -p scbench 10 rand | ||
+ | rados -p scbench cleanup | ||
+ | </ | ||
+ | |||
+ | http:// | ||
+ | |||
+ | ===== Administrative Tätigkeiten ===== | ||
+ | |||
+ | ==== wichtige OSD Befehle ==== | ||
+ | |||
+ | Bei geplante Wartungen (reboots, upgrades, ...) hat Ceph vielfältige Optionen. | ||
+ | |||
+ | ^ ceph osd set/unset ... ^ Bedeutung ^ | ||
+ | | nobackfill | backfill wird ausgesetzt | | ||
+ | | nodeep-scrub | (deep-) scrubbing temporär deaktivieren | | ||
+ | | nodown | OSD-Fehler werden ignoriert (keine Markierung als down) | | ||
+ | | noin | OSDs die vorher " | ||
+ | | **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, | ||
+ | |||
+ | ==== Dienste verwalten ==== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | <code bash> | ||
+ | sudo systemctl start ceph.target | ||
+ | |||
+ | # nach Typ: | ||
+ | sudo systemctl restart ceph-osd.target | ||
+ | sudo systemctl restart ceph-mon.target | ||
+ | sudo systemctl restart ceph-mds.target | ||
+ | </ | ||
+ | |||
+ | ==== iSCSI Zugriff ==== | ||
+ | |||
+ | http:// | ||
+ | |||
+ | ==== Ceph pg Reparatur ==== | ||
+ | |||
+ | manuelle Reparatur: | ||
+ | <code bash> | ||
+ | |||
+ | < | ||
+ | HEALTH_ERR 1 pgs inconsistent; | ||
+ | pg 1.4ac is active+clean+inconsistent, | ||
+ | 1 scrub errors | ||
+ | HEALTH_ERR 1 pgs inconsistent; | ||
+ | </ | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | Für Rados: | ||
+ | <code bash> | ||
+ | rados lspools | ||
+ | rados list-inconsistent-pg {POOL} | ||
+ | rados list-inconsistent-obj {placement-group-ID} --format=json-pretty | ||
+ | </ | ||
+ | ===== Monitoring ===== | ||
+ | |||
+ | * ceph osd stat | ||
+ | * ceph mon stat | ||
+ | * ceph osd df | ||
+ | * ceph osd pool stats | ||
+ | * iostat -x <list of / | ||
+ | |||
+ | ==== ceph exporter ==== | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Zabbix-Integration | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | Konfiguration (gilt global und wird vom MGR ausgeführt): | ||
+ | |||
+ | < | ||
+ | ceph mgr module enable zabbix | ||
+ | # statt 60s alle 10s Daten senden: | ||
+ | ceph zabbix config-set interval 10 | ||
+ | ceph zabbix config-set identifier HOSTNAME-VON-CEPH-IN-ZABBIX | ||
+ | ceph zabbix config-set zabbix_host IP-ODER-FQDN-VOM-ZABBIX-SERVER | ||
+ | </ | ||
+ | |||
+ | Testen: <code bash> | ||
+ | Logs: <code bash> | ||
+ | |||
+ | ==== Nagios/ | ||
+ | |||
+ | [[http:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | |||
+ | ===== Backup ===== | ||
+ | |||
+ | Grundsätzlich: | ||
+ | - rbd-mirror | ||
+ | - asynchrones Replizieren (einzelne images, ganze pools) Standsind sind 30s (" | ||
+ | - via rbd features: journaling (+ exclusive lock) | ||
+ | - benutzt rbd-daemons der **beide** cluster erreich können muss (via internem Netzwerk) | ||
+ | - s3 multisite (live-Replikation von Objekten wenn rados Gw benutzt wird, muss unterstützt werden | ||
+ | - Eine Verbindung radosgw zu radosgw | ||
+ | - können RBD-Snapshots benutzt werden (snapshot verwalten): | ||
+ | - rbd snap create .. | ||
+ | - rbd export-diff .. | ssh rbd import-diff .. | ||
+ | - rbd export-diff --from-snap .. | ssh rbd import-diff .. | ||
+ | |||
+ | |||
+ | |||
+ | ==== object-backup ==== | ||
+ | |||
+ | **Methode 1: rados cppool** (readonly-Zugriff für Client notwendig): | ||
+ | |||
+ | <code bash> | ||
+ | rados cppool $pool $pool.new | ||
+ | ceph osd pool rename $pool $pool.old | ||
+ | ceph osd pool rename $pool.new $pool | ||
+ | </ | ||
+ | |||
+ | **Methode 2: Rados Export/ | ||
+ | |||
+ | <code bash> | ||
+ | <code bash> | ||
+ | |||
+ | <code bash> | ||
+ | # Stop All IO | ||
+ | # And redo a sync of modified objects | ||
+ | rados export --workers 5 testpool tmp_dir | ||
+ | rados import --workers 5 tmp_dir newpool | ||
+ | </ | ||
+ | |||
+ | **Methode 3: [[https:// | ||
+ | |||
+ | ==== export/ | ||
+ | |||
+ | * http:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * transfer deltas between snapshots on different clusters: https:// | ||
+ | * geo replica (drbd / pacemaker) http:// | ||
+ | |||
+ | siehe auch: | ||
+ | * rbd Snapshots: http:// | ||
+ | * fsfreeze | ||
+ | |||
+ | |||
+ | ===== manuelle Installation unter pacific ===== | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Paketquellen einbinden ==== | ||
+ | |||
+ | <code bash> | ||
+ | apt install software-properties-common | ||
+ | wget -q -O- ' | ||
+ | echo deb https:// | ||
+ | apt update | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Mon installieren ==== | ||
+ | |||
+ | <code bash>apt install -y ceph-mon</ | ||
+ | |||
+ | initale Ceph-Config: | ||
+ | < | ||
+ | [global] | ||
+ | # uuidgen: | ||
+ | fsid = 63de7229-8af1-4f8e-8fb8-2f827087d4cf | ||
+ | mon initial members = node1, node2 | ||
+ | mon host = 1.2.3.4 | ||
+ | public network = 1.2.3.0/24 | ||
+ | cluster network = 3.4.5.6/24 | ||
+ | auth cluster required = cephx | ||
+ | auth service required = cephx | ||
+ | auth client required = cephx | ||
+ | osd journal size = 1024 | ||
+ | # write an object n times: | ||
+ | osd pool default size = 3 | ||
+ | # allow writing n copies in a degraded state: | ||
+ | osd pool default min size = 2 | ||
+ | osd pool default pg num = 333 | ||
+ | osd pool default pgp num = 333 | ||
+ | osd crush chooseleaf type = 1 | ||
+ | |||
+ | # 1 day: 86400 | ||
+ | # 1 week: 604800 | ||
+ | # 30days: 2592000 | ||
+ | osd scrub load threshold = 0.5 | ||
+ | osd scrub min interval = 86400 | ||
+ | osd scrub max interval = 604800 | ||
+ | osd deep scrub interval = 2592000 | ||
+ | osd scrub during recovery = false | ||
+ | # only between hours 1 and 8: | ||
+ | osd scrub begin hour = 1 | ||
+ | osd scrub end hour = 8 | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== ersten MON bootstrappen ==== | ||
+ | |||
+ | <code bash> | ||
+ | ceph-authtool --create-keyring / | ||
+ | -> creating / | ||
+ | |||
+ | sudo ceph-authtool --create-keyring / | ||
+ | -> creating / | ||
+ | |||
+ | sudo ceph-authtool --create-keyring / | ||
+ | -> creating / | ||
+ | |||
+ | sudo ceph-authtool / | ||
+ | -> importing contents of / | ||
+ | |||
+ | sudo ceph-authtool / | ||
+ | -> importing contents of / | ||
+ | |||
+ | sudo chown ceph:ceph / | ||
+ | |||
+ | monmaptool --create --add node1 1.2.3.4 --fsid 63de7229-8af1-4f8e-8fb8-2f827087d4cf /tmp/monmap | ||
+ | -> monmaptool: monmap file /tmp/monmap | ||
+ | -> monmaptool: set fsid to 63de7229-8af1-4f8e-8fb8-2f827087d4cf | ||
+ | -> monmaptool: writing epoch 0 to /tmp/monmap (1 monitors) | ||
+ | |||
+ | sudo -u ceph mkdir / | ||
+ | |||
+ | sudo -u ceph ceph-mon --mkfs -i node1 --monmap /tmp/monmap --keyring / | ||
+ | |||
+ | systemctl start ceph-mon@node1 | ||
+ | systemctl enable ceph-mon@node1 | ||
+ | </ | ||
+ | |||
+ | Erfolg kontrollieren: | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== weitere MON hinzufügen ==== | ||
+ | |||
+ | https:// | ||
+ | |||
+ | die folgenden Schritte müssen für alle nodes durchgeführt werden, dabei muss node1 zu node2 usw. (plus die IP) entsprechend hochgezählt werden. | ||
+ | |||
+ | Beispiel node2 | ||
+ | <code bash> | ||
+ | ssh node2 | ||
+ | |||
+ | apt install -y ceph-mon | ||
+ | |||
+ | # nur auf hosts mit OSDs | ||
+ | apt install -y ceph-osd | ||
+ | |||
+ | cat <<EOF >> /etc/hosts | ||
+ | 1.2.3.4 | ||
+ | 1.2.3.5 | ||
+ | 1.2.3.6 | ||
+ | EOF | ||
+ | |||
+ | # sudo mkdir / | ||
+ | mkdir / | ||
+ | chown ceph.ceph / | ||
+ | |||
+ | #scp ceph/ | ||
+ | #ssh node2.mydomain.tld 'chmod 644 / | ||
+ | #scp ceph/ | ||
+ | scp -r node1.mydomain.tld:/ | ||
+ | mv ceph/ | ||
+ | mv ceph/ | ||
+ | |||
+ | mkdir /tmp/tmp | ||
+ | |||
+ | # mon.keyring: | ||
+ | #scp node1.inwx.net:/ | ||
+ | #scp ceph.mon.keyring node2.mydomain.tld:/ | ||
+ | scp node1.mydomain.tld:/ | ||
+ | |||
+ | # ceph auth get mon. -o {tmp}/ | ||
+ | ceph auth get mon. -o / | ||
+ | -> exported keyring for mon. | ||
+ | |||
+ | # ceph mon getmap -o {tmp}/ | ||
+ | ceph mon getmap -o / | ||
+ | -> got monmap epoch 2 | ||
+ | |||
+ | chown ceph /tmp/tmp/* | ||
+ | |||
+ | sudo -u ceph ceph-mon -i `hostname --short` --mkfs --monmap / | ||
+ | # -> / | ||
+ | |||
+ | # ceph-mon -i {mon-id} --public-addr {ip:port} | ||
+ | # alternativ könnte man auch das passende Netzwerk angeben: --public-network {network} | ||
+ | # sudo -u ceph ceph-mon -i `hostname --short` --public-addr 1.2.3.5 | ||
+ | sudo -u ceph ceph-mon -i `hostname --short` --public-network 1.2.3.0/24 | ||
+ | |||
+ | systemctl enable --now ceph-mon@`hostname --short` | ||
+ | |||
+ | # Neustart schließt die ganze Sache sauber ab | ||
+ | systemctl reboot | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== MGR installieren ==== | ||
+ | |||
+ | "The Ceph Manager daemon (ceph-mgr) runs alongside monitor daemons, to provide additional monitoring and interfaces to external monitoring and management systems. | ||
+ | Since the 12.x (luminous) Ceph release, the ceph-mgr daemon is required for normal operations. The ceph-mgr daemon is an optional component in the 11.x (kraken) Ceph release. | ||
+ | |||
+ | By default, the manager daemon requires no additional configuration, | ||
+ | |||
+ | Use your normal deployment tools, such as ceph-ansible or cephadm, to set up ceph-mgr daemons on each of your mon nodes. It is not mandatory to place mgr daemons on the same nodes as mons, but it is almost always sensible." | ||
+ | |||
+ | <code bash> | ||
+ | apt install -y ceph-mgr | ||
+ | |||
+ | mkdir / | ||
+ | chown ceph / | ||
+ | |||
+ | ceph auth get-or-create mgr.`hostname --short` mon 'allow profile mgr' osd 'allow *' mds 'allow *' > / | ||
+ | |||
+ | chown ceph / | ||
+ | chmod 600 / | ||
+ | |||
+ | systemctl enable --now ceph-mgr@`hostname --short` | ||
+ | </ | ||
+ | |||
+ | ==== MGR Einstellungen ==== | ||
+ | |||
+ | <code bash> | ||
+ | # setting is clusterwide: | ||
+ | ceph mgr module enable selftest | ||
+ | ceph mgr self-test run | ||
+ | </ | ||
+ | |||
+ | mgr module anzeigen | ||
+ | <code bash> | ||
+ | ceph mgr module ls | ||
+ | </ | ||
+ | |||
+ | ==== OSD Installieren ==== | ||
+ | |||
+ | Eine neue Platte ins Ceph zu bringen (wird dann automatisch je danach auf welchem Host die Platte ist korrekt in die Brandabschnitte und die Crush Map eingefügt): | ||
+ | |||
+ | |||
+ | Beispiel für / | ||
+ | <code bash> | ||
+ | # existiert / | ||
+ | |||
+ | parted -s / | ||
+ | parted --align optimal -s / | ||
+ | |||
+ | ceph-volume lvm create --data / | ||
+ | |||
+ | Informationen anzeigen: | ||
+ | systemctl status ceph-osd@0 | ||
+ | ceph-volume lvm list | ||
+ | </ | ||
+ | |||
+ | ==== OSD entfernen ==== | ||
+ | |||
+ | ! Warnung: Datenkopien werden entfernt und müssen woanders wiederhergestellt werden! | ||
+ | |||
+ | |||
+ | Festplate aus Ceph entfernen (komplett, das mit der Crush Map ist kein Problem) | ||
+ | |||
+ | |||
+ | Beispiel OSD.0 entfernen: | ||
+ | <code bash> | ||
+ | ceph osd down 10 | ||
+ | systemctl stop ceph-osd@10 | ||
+ | ceph osd purge 0 --yes-i-really-mean-it | ||
+ | # nicht mehr nötig: | ||
+ | # ceph osd crush remove osd.0 | ||
+ | # ceph auth del osd.0 | ||
+ | # " | ||
+ | # oder: | ||
+ | # " | ||
+ | </ | ||
+ | |||
+ | wenn das Gerät dann immer noch busy ist: | ||
+ | |||
+ | <code bash> | ||
+ | ls / | ||
+ | partprobe $DISK | ||
+ | sgdisk --zap-all $DISK | ||
+ | </ | ||
+ | [[https:// | ||
+ | ==== Cluster Einstellungen ==== | ||
+ | |||
+ | |||
+ | health: HEALTH_WARN: | ||
+ | <code bash> | ||
+ | |||
+ | health: HEALTH_WARN: | ||
+ | <code bash> | ||
+ | |||
+ | |||
+ | === Ceph Brandabschnitte === | ||
+ | |||
+ | ceph osd tree | ||
+ | |||
+ | Die DC-Zonen erstellen: | ||
+ | <code bash> | ||
+ | ceph osd crush add-bucket dc1 datacenter | ||
+ | ceph osd crush add-bucket dc2 datacenter | ||
+ | </ | ||
+ | |||
+ | DCs in "root default" | ||
+ | <code bash> | ||
+ | ceph osd crush move dc1 root=default | ||
+ | ceph osd crush move dc2 root=default | ||
+ | </ | ||
+ | |||
+ | Ceph-Nodes zu jeweiligen DC anordnen: | ||
+ | <code bash> | ||
+ | ceph osd crush move node1 datacenter=dc1 | ||
+ | ceph osd crush move node2 datacenter=dc1 | ||
+ | ceph osd crush move node3 datacenter=dc2 | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | :!: 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 | ||
+ | </ | ||
+ | Ä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 | ||
+ | </ | ||
+ | |||
+ | default-Regel: | ||
+ | < | ||
+ | rule replicated_rule { | ||
+ | id 0 | ||
+ | type replicated | ||
+ | min_size 1 | ||
+ | max_size 10 | ||
+ | step take default | ||
+ | step chooseleaf firstn 0 type host | ||
+ | step emit | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Hier ein komplexes Beispiel mit zwei datacentern und 4,3,2-fache Replikation (min_size setzt die [[https:// | ||
+ | |||
+ | < | ||
+ | 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 | ||
+ | } | ||
+ | </ | ||
+ | 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 ===== | ||
+ | |||
+ | ==== keyring authentifizierungsprobleme ==== | ||
+ | |||
+ | < | ||
+ | stderr: 2021-05-24T17: | ||
+ | stderr: [errno 13] RADOS permission denied (error connecting to the cluster) | ||
+ | </ | ||
+ | -> keyring abgleichen mit der Ausgabe von '' | ||
+ | |||
+ | |||
+ | Aus Sicherheitsgrüngen muss Ceph-Cluster auf mehrere Datacentren verteilt werden. | ||
+ | |||
+ | |||
+ | ==== ceph status meldet " | ||
+ | |||
+ | Wenn OSDs abschmieren (z.B. weil die Platte die sie verwalten kaputt geht), dann bekommt Ceph das mit und speichert Informationen darüber in einer Art Mailbox (also es funktioniert ähnlich wie dieses "you have unread mail" wenn man sich auf Systemen mit einem entsprechend konfigurierten Mail-Subsystem einloggt). | ||
+ | |||
+ | So ist damit umzugehen: | ||
+ | |||
+ | Die aufgezeichneten Crashes (mit ihrer ID) auflisten: | ||
+ | <code bash> | ||
+ | |||
+ | Einzelnen Crash anzeigen lassen: | ||
+ | <code bash> | ||
+ | |||
+ | Einzelnen Crash archivieren: | ||
+ | <code bash> | ||
+ | |||
+ | Alle neuen Crashes archivieren: | ||
+ | <code bash> | ||
+ | |||
+ | |||
+ | |||
+ | Ceph Brandabschnitte | ||
+ | |||
+ | |||
+ | ===== manuelle Installation unter luminous (veraltet!!!) ===== | ||
+ | |||
+ | Die händisch auszuführenden Schritte sind im folgenden aufgeführt. | ||
+ | |||
+ | ==== Netzwerksetup und Firewall-Freigaben ==== | ||
+ | |||
+ | * Ceph Client → public network | ||
+ | * **public network** (eigene Netzwerkkarte empfohlen): | ||
+ | Description: | ||
+ | < | ||
+ | public network = ip-address}/ | ||
+ | </ | ||
+ | * Monitors: | ||
+ | * (altes) v1-Protokoll: | ||
+ | * v2-Protokoll: | ||
+ | * OSDs Kummunikation: | ||
+ | * **cluster netzwerk** (eigene Netzwerkkarte empfohlen; sollte nicht vom public network oder Internet erreichbar sein)< | ||
+ | cluster network = ip-address}/ | ||
+ | </ | ||
+ | |||
+ | siehe auch: [[http:// | ||
+ | |||
+ | Releases: http:// | ||
+ | Get Packages: http:// | ||
+ | |||
+ | |||
+ | ==== Destroy Cluster ==== | ||
+ | |||
+ | <code bash> | ||
+ | ceph-deploy purge node1 node2 node3 | ||
+ | ceph-deploy purgedata node1 node2 node3 | ||
+ | ceph-deploy forgetkeys | ||
+ | rm ceph.* | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Hosts vorbereiten ==== | ||
+ | |||
+ | ceph-deploy braucht einen Benutzer auf dem System der | ||
+ | * via [[netzwerke: | ||
+ | * nicht gleichlautend mit dem ceph-System-Benutzer ist | ||
+ | * per sudo root-Rechte erreichen kann (ohne Passwortabfrage) | ||
+ | |||
+ | Hier im Beispiel wird | ||
+ | <code bash> | ||
+ | useradd -d / | ||
+ | # Zufallspasswort setzen | ||
+ | passwd cephdeploy | ||
+ | |||
+ | echo " | ||
+ | |||
+ | mkdir / | ||
+ | # pubkey hinterlegen: | ||
+ | vi / | ||
+ | chown cephdeploy / | ||
+ | chown cephdeploy / | ||
+ | chmod 700 / | ||
+ | chmod 600 / | ||
+ | </ | ||
+ | |||
+ | Alle beteiligten Nodes sollten per ''/ | ||
+ | < | ||
+ | node1 | ||
+ | node2 | ||
+ | node3 | ||
+ | </ | ||
+ | |||
+ | Für die Ceph-Nodes eine SSH-Config hinterlegen ('' | ||
+ | < | ||
+ | # ======== CEPH============= | ||
+ | |||
+ | Host node1 | ||
+ | | ||
+ | User cephdeploy | ||
+ | |||
+ | Host node2 | ||
+ | | ||
+ | User cephdeploy | ||
+ | |||
+ | Host node3 | ||
+ | | ||
+ | User cephdeploy | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Ceph Installation auf admin-Rechnern und Nodes ==== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | (debian) minimal-system: | ||
+ | * ca-certificates vorher installieren) | ||
+ | * <code bash> | ||
+ | |||
+ | benötigte Pakete: | ||
+ | * Debian Jessie+: <code bash> | ||
+ | * Debian Wheezy und vorher: <code bash> | ||
+ | * Debian stretch: <code bash> | ||
+ | * Ubuntu 16.04: <code bash> | ||
+ | deb http:// | ||
+ | # deb-src http:// | ||
+ | deb http:// | ||
+ | # deb-src http:// | ||
+ | deb http:// | ||
+ | # deb-src http:// | ||
+ | deb https:// | ||
+ | # deb-src https:// | ||
+ | </ | ||
+ | * Ubuntu 18.04: <code bash> | ||
+ | # deb-src http:// | ||
+ | deb http:// | ||
+ | # deb-src http:// | ||
+ | deb http:// | ||
+ | # deb-src http:// | ||
+ | deb http:// | ||
+ | # deb-src http:// | ||
+ | deb https:// | ||
+ | # deb-src https:// | ||
+ | </ | ||
+ | |||
+ | "Ceph on ARM processors requires Google’s memory profiling tools (google-perftools). The Ceph repository should have a copy at https:// | ||
+ | |||
+ | * Repository hinzufügen:< | ||
+ | |||
+ | |||
+ | Allgemein: wget -q https:// | ||
+ | |||
+ | * Ubuntu Xenial: wget -q https:// | ||
+ | * Debian stretch: wget -q https:// | ||
+ | |||
+ | **ceph installieren**: | ||
+ | |||
+ | ==== Cluster erstellen (Admin-Rechner) ==== | ||
+ | |||
+ | ceph-deploy installieren: | ||
+ | |||
+ | |||
+ | === Projektdirectory anlegen === | ||
+ | |||
+ | <code bash> | ||
+ | mkdir ceph-cluster1 | ||
+ | cd ceph-cluster1 | ||
+ | </ | ||
+ | |||
+ | <code bash> | ||
+ | (keine passphrase) | ||
+ | |||
+ | den sshkey für ceph-deploy zu den Nodes übertragen: | ||
+ | <code bash> | ||
+ | ssh-copy-id -i sshkey.pub cephdeploy@node1 | ||
+ | ssh-copy-id -i sshkey.pub cephdeploy@node2 | ||
+ | ssh-copy-id -i sshkey.pub cephdeploy@node3 | ||
+ | </ | ||
+ | |||
+ | === Nodes erzeugen === | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | === ersten Mon erstellen (besser gleich 3) === | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | lokales Projektverzeichnis enthält nun: | ||
+ | < | ||
+ | ceph.client.admin.keyring | ||
+ | ceph.bootstrap-mgr.keyring | ||
+ | ceph.bootstrap-osd.keyring | ||
+ | ceph.bootstrap-mds.keyring | ||
+ | ceph.bootstrap-rgw.keyring | ||
+ | ceph.bootstrap-rbd.keyring | ||
+ | </ | ||
+ | |||
+ | === admin nodes erzeugen(Verwaltung)=== | ||
+ | |||
+ | # config für cli-tools (administration) auf hosts verteilen ( wenn das so gewünscht ist; diese müssen vorbereitet sein + mind. ceph-common installiert haben): | ||
+ | <code bash> | ||
+ | |||
+ | :!: auf admin-Instanzen kann "ceph health" | ||
+ | |||
+ | === manager daemon === | ||
+ | |||
+ | **manager daemon** (ab " | ||
+ | <code bash> | ||
+ | |||
+ | === OSDs erzeugen === | ||
+ | http:// | ||
+ | |||
+ | :!: auf jedem node muss mindestens ein Blockdevice frei sein. Das sollten einfache/ | ||
+ | Wenn kein bluestore benutzt wird dann sollte zusätzlich pro Node ein Gerät (SSD) für die journale der OSDs partitioniert werden, da dort die Daten zuerst geschrieben werden. | ||
+ | |||
+ | == Variante 1: Test mit loop-devices == | ||
+ | |||
+ | Besonderheit: | ||
+ | |||
+ | <code bash> | ||
+ | dd if=/ | ||
+ | losetup /dev/loop0 / | ||
+ | </ | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | == Variante 2: filestore == | ||
+ | |||
+ | Reale devices per / | ||
+ | |||
+ | [[linux: | ||
+ | * in der Volume-group " | ||
+ | * in der Volume-group | ||
+ | |||
+ | **Erster Schritt: [[linux: | ||
+ | |||
+ | <code bash> | ||
+ | In einem realen Setup bevorzuge ich den Namen aus Festplattenmodell und Seriennummer zu bilden (vg_osd_$Modell_$Seriennumer)((abrufbar mit <code bash> | ||
+ | |||
+ | In der Ausgabe von ceph-osd findet sich sowohl die neue osd.$ID als auch die osd-uuid (" | ||
+ | <code bash> | ||
+ | < | ||
+ | |||
+ | **Zweiter Schritt: OSD Aktivieren** (Schema: '' | ||
+ | <code bash> | ||
+ | |||
+ | Die alternativ beschriebene 1-step-Methode mit ceph-deploy funktioniert nicht zuverlässig((Stand 02/2018 Luminous v12.2)): | ||
+ | <code bash> | ||
+ | |||
+ | == Variante 3: bluestore == | ||
+ | |||
+ | bluestore ist ab luminous möglich und empfohlen: | ||
+ | |||
+ | Beispiel: leere Festplatte /dev/sdd | ||
+ | |||
+ | <code bash> | ||
+ | < | ||
+ | Partition name? []? | ||
+ | File system type? [ext2]? | ||
+ | Start? 2048s | ||
+ | End? -1s | ||
+ | Warning: You requested a partition from 1049kB to 4001GB (sectors 2048..7814037167). | ||
+ | The closest location we can manage is 1049kB to 4001GB (sectors 2048..7814037134). | ||
+ | Is this still acceptable to you? | ||
+ | Yes/No? y | ||
+ | (parted) set 1 lvm on | ||
+ | (parted) quit | ||
+ | </ | ||
+ | |||
+ | |||
+ | <code bash> | ||
+ | |||
+ | |||
+ | manuell auf Host: <code bash> | ||
+ | |||
+ | |||
+ | [[https:// | ||
+ | |||
+ | |||
+ | === OSD entfernen === | ||
+ | |||
+ | Die Entfernung von OSDs ist in " | ||
+ | |||
+ | :!: der Cluster soll nicht " | ||
+ | |||
+ | In kleineren Clustern können PGs im Status " | ||
+ | <code bash> | ||
+ | oder gleich richtig aus: | ||
+ | <code bash> | ||
+ | |||
+ | Folgen: | ||
+ | * rebalance startet: status active+clean -> active | ||
+ | * wenn fertig: status active -> active+clean | ||
+ | |||
+ | Stoppen:< | ||
+ | Löschen:< | ||
+ | |||
+ | === zusätzliche mgr erzeugen === | ||
+ | |||
+ | node2 + node3 zum mgr machen: <code bash> | ||
+ | |||
+ | ceph -s zeigt nun: | ||
+ | < | ||
+ | |||
+ | |||
+ | === Optional: Ceph Object Gateway === | ||
+ | |||
+ | FIXME Testen | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | < | ||
+ | # port 7480 ändern: | ||
+ | [client] | ||
+ | rgw frontends = civetweb port=80 | ||
+ | </ | ||
+ | |||
+ | === Optional: mehr mon hinzufügen (Anzahl ungerade!) | ||
+ | FIXME | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | Möglichweise tritt die folgende Fehlermeldung auf: | ||
+ | < | ||
+ | [ceph3][WARNIN] node2 is not defined in `mon initial members` | ||
+ | [ceph3][WARNIN] monitor node2 does not exist in monmap | ||
+ | mon not present in monmap or ceph.conf | ||
+ | </ | ||
+ | |||
+ | |||
+ | Lösung: | ||
+ | * network config muss existieren http:// | ||
+ | auch: http:// | ||
+ | |||
+ | |||
+ | ===== Daten speichern ===== | ||
+ | |||
+ | |||
+ | ==== zuerst pool erstellen ==== | ||
+ | |||
+ | http:// | ||
+ | |||
+ | <code bash> | ||
+ | oder | ||
+ | <code bash> | ||
+ | |||
+ | 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 | ||
+ | </ | ||
+ | |||
+ | **List pools**: <code bash> | ||
+ | < | ||
+ | device_health_metrics | ||
+ | pool1 | ||
+ | </ | ||
+ | |||
+ | === Replikation einstellen === | ||
+ | |||
+ | < | ||
+ | # size: The {num-replicas} includes the object itself. If you want the object and two copies of the object for a total of three instances of the object, specify 3. | ||
+ | # min_size: This ensures that no object in the data pool will receive I/O with fewer than min_size replicas. | ||
+ | ceph osd pool set proxmox_4repl size 4 | ||
+ | ceph osd pool set proxmox_4repl min_size 3 | ||
+ | </ | ||
+ | |||
+ | === pool einer Anwendung zuweisen === | ||
+ | |||
+ | In aktuellen ceph-Versionen muss ein pool einer Anwendung zugewiesen werden: | ||
+ | |||
+ | - pool-name: pool1 | ||
+ | - application-name: | ||
+ | |||
+ | Hier Zuweisung auf cephfs: <code bash> | ||
+ | |||
+ | |||
+ | ==== Pool löschen ==== | ||
+ | |||
+ | Zum löschen eines Pools muss der Namen 2x hintereinander geschrieben werden, gefolgt von "'' | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | Seit der Version " | ||
+ | < | ||
+ | |||
+ | Entweder man setzt die Option global | ||
+ | < | ||
+ | [global] | ||
+ | ... | ||
+ | mon_allow_pool_delete = true</ | ||
+ | oder auf mon-Ebene: | ||
+ | |||
+ | < | ||
+ | [mon.1] | ||
+ | ... | ||
+ | mon_allow_pool_delete = true</ | ||
+ | |||
+ | Anschließend müssen die OSDs neu gestartet werden: <code bash> | ||
+ | |||
+ | Einzelne Pools sollten gegen versehentliches löschen geschützt werden: | ||
+ | <code bash> | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | ==== Pool umbenennen ==== | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | ==== Pool Statistics | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | <code bash> | ||
+ | < | ||
+ | |||
+ | |||
+ | ==== Pool Snapshot ==== | ||
+ | |||
+ | * anlegen: <code bash> | ||
+ | * löschen: <code bash> | ||
+ | |||
+ | |||
+ | FIXME Snapshot benutzen? | ||
+ | |||
+ | |||
+ | ==== Pool Quota ==== | ||
+ | |||
+ | <code bash> | ||
+ | # 1 Gigabyte: | ||
+ | <code bash> | ||
+ | |||
+ | Quota anzeigen: <code bash> | ||
+ | |||
+ | |||
+ | |||
+ | ===== RBD ==== | ||
+ | |||
+ | |||
+ | ==== einen pool für rbd nutzbar machen ==== | ||
+ | |||
+ | **Zuweisung eines pools** (" | ||
+ | |||
+ | **Initialisieren** (auf admin-node: | ||
+ | |||
+ | :!: Benutzerverwaltung Block-device: | ||
+ | |||
+ | |||
+ | ==== rbd Image anlegen ==== | ||
+ | |||
+ | zum speichern muss der client | ||
+ | - pool | ||
+ | - object namen | ||
+ | angeben. | ||
+ | |||
+ | Siehe auch [[http:// | ||
+ | |||
+ | |||
+ | Schema: < | ||
+ | |||
+ | <code bash>rbd create --size 2048 pool1/ | ||
+ | |||
+ | |||
+ | ==== Image Aktionen ==== | ||
+ | |||
+ | **Images eines pools** (pool1) **anzeigen** (Ergebnis: image1): <code bash>rbd ls pool1</ | ||
+ | < | ||
+ | |||
+ | **Informationen anzeigen**:< | ||
+ | < | ||
+ | "rbd image ' | ||
+ | size 2048 MB in 512 objects | ||
+ | order 22 (4096 kB objects) | ||
+ | block_name_prefix: | ||
+ | format: 2 | ||
+ | features: layering, exclusive-lock, | ||
+ | flags: | ||
+ | create_timestamp: | ||
+ | </ | ||
+ | |||
+ | **resize**: | ||
+ | * mehr (3072 MB): <code bash>rbd resize --size 3072 pool1/ | ||
+ | * weniger (1024 MB): <code bash>rbd resize --size 1024 pool1/ | ||
+ | **löschen**: | ||
+ | * sofort: <code bash>rbd rm pool1/ | ||
+ | * löschen (Papierkorb): | ||
+ | * Wiederherstellen: | ||
+ | |||
+ | **weitere Befehle**: http:// | ||
+ | |||
+ | |||
+ | ==== rbd und erasure coding ==== | ||
+ | |||
+ | Erasure-coding verspricht einen geringeren overhead auf Kosten von CPU-Zeit beim recovery. | ||
+ | |||
+ | Im Zusammenhang von rbd (und cephfs) gibt es aber mehrere Vorraussetzungen: | ||
+ | * das luminous v12.2.x eingesetzt wird | ||
+ | * das ein **pool " | ||
+ | * **die OSDs müssen mit bluestore** eingerichtet worden sein. Mit filestore geht das nicht: < | ||
+ | * die omap-property wird nicht unterstützt ((" | ||
+ | * aus den release-Notes [[https:// | ||
+ | ((v12.2.0 Luminous)) | ||
+ | * *Erasure coded* pools now have `full support for overwrites | ||
+ | < | ||
+ | allowing them to be used with RBD and CephFS. | ||
+ | |||
+ | * rbd and cephfs can use erasure coding with bluestore. This may be | ||
+ | enabled by setting ``allow_ec_overwrites`` to ``true`` for a pool. Since | ||
+ | this relies on bluestore' | ||
+ | enabling this on a pool stored on filestore is not allowed. | ||
+ | </ | ||
+ | |||
+ | Wenn alle diese Vorraussetzungen erfüllt sind, zeigt [[https:// | ||
+ | |||
+ | Hier abgewandelt ein minimal redundantes setup (profil ec-31-profile, | ||
+ | |||
+ | <code bash> | ||
+ | ceph osd erasure-code-profile set ec-31-profile k=3 m=1 crush-failure-domain=host | ||
+ | ceph osd pool create $poolname 128 erasure ec-31-profile | ||
+ | ceph osd pool set $poolname allow_ec_overwrites true | ||
+ | ceph osd pool $poolname enable rbd ec-31-profile | ||
+ | rbd create $poolname/ | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== rbd-kernel-module ==== | ||
+ | |||
+ | http:// | ||
+ | |||
+ | <code bash>rbd map share --pool pool1</ | ||
+ | |||
+ | Möglicherweise müssen features abgeschaltet werden, die der Client nicht unterstützt: | ||
+ | < | ||
+ | |||
+ | (hier deep-flatten/ | ||
+ | |||
+ | < | ||
+ | --image-feature feature-name | ||
+ | |||
+ | Specifies which RBD format 2 feature should be enabled when creating an image. Multiple features can be enabled by repeating this option multiple times. The following features are supported: | ||
+ | |||
+ | layering: layering support | ||
+ | striping: striping v2 support | ||
+ | exclusive-lock: | ||
+ | object-map: object map support (requires exclusive-lock) | ||
+ | fast-diff: fast diff calculations (requires object-map) | ||
+ | deep-flatten: | ||
+ | journaling: journaled IO support (requires exclusive-lock) | ||
+ | </ | ||
+ | |||
+ | U.U geht das nicht im laufenden Betrieb: | ||
+ | |||
+ | < | ||
+ | |||
+ | daher neu anlegen: | ||
+ | |||
+ | <code bash>rbd create pool1/test2 -s 1024 --image-format 2 --image-feature exclusive-lock</ | ||
+ | |||
+ | <code bash>rbd info pool1/ | ||
+ | < | ||
+ | size 1024 MB in 256 objects | ||
+ | order 22 (4096 kB objects) | ||
+ | block_name_prefix: | ||
+ | format: 2 | ||
+ | features: exclusive-lock | ||
+ | flags: | ||
+ | </ | ||
+ | |||
+ | <code bash>rbd feature disable pool1/test2 exclusive-lock</ | ||
+ | |||
+ | === image mounten/ | ||
+ | |||
+ | **gemountete image anzeigen**: <code bash>rbd showmapped</ | ||
+ | < | ||
+ | 0 pool1 test2 - /dev/rbd0 </ | ||
+ | |||
+ | **mounten**: | ||
+ | das benutzte device wird von rbd zurückgemeldet: | ||
+ | |||
+ | **unmounten**: | ||
+ | |||
+ | |||
+ | === Client zu alt === | ||
+ | |||
+ | < | ||
+ | [So Feb 18 22:02:28 2018] libceph: mon0 1.2.3.4: | ||
+ | [So Feb 18 22:02:28 2018] libceph: mon0 1.2.3.4: | ||
+ | </ | ||
+ | |||
+ | '' | ||
+ | |||
+ | **Lösung**: | ||
+ | - Client mit höherer Kernel-version einsetzen | ||
+ | - rbd-fuse benutzen (Leistungsverlust) | ||
+ | - die crush-tuneables auf eine alte Versionen zurückschalten (Auswirkungen siehe http:// | ||
+ | |||
+ | |||
+ | ==== rbd trim ==== | ||
+ | |||
+ | Rbd bildet Blockdevices auf Ceph-Objekten ab. Gelöschte Dateien führen daher nicht dazu das die ceph-Objekte freigegeben werden sondern diese bestehen weiter und werden wiederverwendet. | ||
+ | Bei vielen kleinen Dateien kann dies aber deutlich bei der Arbeitsgeschwindigkeit merkbar sein, in diesem Fall ist eine fallweise Ausführung (z.B. täglich) sinnvoller. | ||
+ | |||
+ | <code bash> | ||
+ | mount -o discard /dev/rbd0 /media/rbd0 | ||
+ | fstrim /media/rbd0 | ||
+ | </ | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | |||
+ | ==== rbd-fuse ==== | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | " | ||
+ | |||
+ | <code bash> | ||
+ | # mkdir /media/rdb | ||
+ | # chown ich.gruppe | ||
+ | rbd-fuse -c / | ||
+ | </ | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | |||
+ | ==== RGW (S3) ==== | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | |||
+ | |||
+ | ===== Sicherheitskonzept ===== | ||
+ | |||
+ | Aktuell ist ceph nicht für den Betrieb im " | ||
+ | |||
+ | < | ||
+ | At the moment, none of the Ceph authentication protocols provide secrecy for messages in transit. Thus, an eavesdropper on the wire can hear and understand all data sent between clients and servers in Ceph, even if it cannot create or alter them. Further, Ceph does not include options to encrypt user data in the object store. Users can hand-encrypt and store their own data in the Ceph object store, of course, but Ceph provides no features to perform object encryption itself. Those storing sensitive data in Ceph should consider encrypting their data before providing it to the Ceph system.</ | ||
+ | Quelle: http:// | ||
+ | |||
+ | auth_cluster_required = cephx | ||
+ | auth_service_required = cephx | ||
+ | auth_client_required = cephx | ||
+ | |||
+ | |||
+ | Darüber hinaus können wenigstens [[http:// | ||
+ | < | ||
+ | # http:// | ||
+ | cephx require signatures = true | ||
+ | # -> this needs: Kernel 3.19 AND ceph Version at least v0.54 (Argonaut is too old) | ||
+ | cephx cluster require signatures = true | ||
+ | cephx service require signatures = true | ||
+ | </ | ||
+ | ==== Client Rechte beschränken ==== | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === server seite === | ||
+ | |||
+ | Client " | ||
+ | <code bash> | ||
+ | (ob mds 'allow r' nötig ist muss ich noch testen) | ||
+ | |||
+ | Beispiel für eine sichere RDB-ACL (Quelle: http:// | ||
+ | <code bash> | ||
+ | |||
+ | === client seite === | ||
+ | |||
+ | Erstens ceph installiert sein und eine config vorhanden sein ''/ | ||
+ | < | ||
+ | [global] | ||
+ | fsid = f8ebdabe-2170-2562-97f2-85bb62efcbfd | ||
+ | mon_host = node1, node2, node3 | ||
+ | auth_cluster_required = cephx | ||
+ | auth_service_required = cephx | ||
+ | auth_client_required = cephx | ||
+ | </ | ||
+ | Dann muss ein keyring für den Zugriff angelegt worden sein: | ||
+ | <code bash> | ||
+ | |||
+ | **Client | ||
+ | |||
+ | <code bash>rbd map TESTPOOL/ | ||
+ | |||
+ | < | ||
+ | |||
+ | <code bash> | ||
+ | CEPH_ARGS=" | ||
+ | export CEPH_ARGS | ||
+ | echo $CEPH_ARGS | ||
+ | </ | ||
+ | |||
+ | === Rechte verändern === | ||
+ | |||
+ | Rechte müssen (absolut) neu gesetzt werden: | ||
+ | <code bash> | ||
+ | Bei Erfolg Meldung " |