====== ceph storage cluster ====== 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. * **librados**: Direktzugriff für Anwendungen, Binding for div. Sprachen. * **RadosGW**: bucket-basiertes REST-Gateway, S3 und Swift-kompatibel. Die [[http://docs.ceph.com/docs/giant/radosgw/s3/|meisten Amazon S3 features werden unterstützt]] -> [[http://docs.ceph.com/docs/master/radosgw/s3/|unterstützte S3 Operationen]], die fehlende S3 Bucket Notification lässt sich mit ggf. mit [[https://github.com/spreadshirt/s3gw-haproxy|s3gw-haproxy]] nachrüsten * **RDB**: "verteiltes" Blockgerät (Linux-Kernelmodul ab 2.6.39 möglich und/oder Quemu/KVM-Treiber) zum Exklusivmount von Clients, oder mit extra Aufwand (NFS, Clusterfähiges FS, [[https://docs.ceph.com/docs/luminous/rbd/iscsi-overview/|iSCSI]] bei nicht *nix-Betriebssystemen wie Windows oder [[https://docs.ceph.com/docs/luminous/rbd/iscsi-initiator-esx/|Vmware]]) multi-userfähig * **Ceph FS**: Posix-kompatibles Dateisystem (FUSE) für Multisystemzugriff, langsamer bei FUSE :!: 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 **[[software:proxmox#ceph|Proxmox]]** bieten eine Integration von Ceph (Server und Client). ===== Links ===== * https://public.centerdevice.de/d72fea90-0d1f-4f7d-8cf2-404603a94032 * https://www.heinlein-support.de/blog/howto/ceph-cluster-auf-unseren-linux-desktops/ * https://www.virtualtothecore.com/en/adventures-ceph-storage-part-1-introduction/ * [[https://www.heise.de/select/ix/2018/2/1517701858523828|Performance-Tuning für Ceph (M. Loschwitz)]] * [[https://github.com/cernceph/ceph-scripts|ceph-scripts]] - ein paar Skript vom Cern für Ceph ===== Deploymethoden ===== * cephadm: docker/podman-basiertes tool * [[https://docs.ceph.com/projects/ceph-ansible/en/latest/|ceph-ansible]]: * [[https://docs.ceph.com/en/pacific/install/index_manual/#install-manual|manuell]] plus [[https://docs.ceph.com/en/pacific/mgr/dashboard/|dashboard]] * ceph-deploy: veraltet, nur bis nautilus benutzbar! ===== Begriffe ===== https://docs.ceph.com/en/latest/glossary/ * **CRUSH-Algorithmus**: Algorithmus zur Bestimmung des Ablageortes eines Objektes (macht eine Abfrage an einen Indexdienst überflüssig) * class: welcher Typ des storage soll auf einem OSD benutzt werden (z.B. hdd, ssd, nvme) * failure-domain: anhand welcher Grenze sollen die Replikas aufgeteilt/separiert werden? Das wäre die Einheit die bei einem Ausfall zusammen betrachtet wird (z.B. host, rack) * **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/Octopus) werden diese automatisch angepasst, siehe auch ''ceph osd pool autoscale-status'' und https://docs.ceph.com/en/latest/rados/operations/placement-groups/ . * **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, Erhöhung der Lesegeschwindigkeit). Redundanz von 2 heißt: 2 Kopien im Cluster * Replikation: Faktor der Redundanz multipliziert linear den Speicherbedarf. * **striping**: * **Stripe Units**: Größe der Daten * **Objektgröße**: ganzzahliges Vielfaches der Stripe-Unit-Größe. Legt fest wann die maximale Objektgröße erreicht ist und eine neue Objektgruppe angefangen wird. * Stripe-Anzahl: bei 1 wird ein Objekt bis zur maximalen Objektgröße benutzt und dann ein neues Objekt angelegt. D.h. es findet keine Verbesserung der (Schreib-) Geschwindigkeit statt bei Werten größer 1 werden x Objekte (auf unterschiedlichen OSDs) erzeugt und nacheinander (in der Größe Stripe Units) befüllt. * **cluster map** (verwaltet vom MON): Liste bestehend aus Monitors, OSD, PG, Crush, MDS * **Erasure coding**: Redundanz kann "errechnet" werden - auf Kosten von Geschwindigkeit (Durchsatz) und CPU-Belastung. Daher vorrangig für selten benutzte Daten sinnvoll (cold storage, Archivdaten). ===== Komponenten ===== * **Node**: Server/Node/Host: einzelne Maschine * **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 ("Scrubbing") * Überwachung/Sicherstellung Objektredundanz (erster angesprochener OSD übermitteln Daten weiter und meldet Erfolg) * **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, 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/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]]:[global] # 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 "full", besonders wenn die Kapazitäten ungleich verteilt sind) * Geo-/Multisite-Replikation: * es gibt keine asynchrone Replikation (mit Ausnahme von [[http://docs.ceph.com/docs/jewel/rbd/rbd-mirroring/|rbd-mirroring]]), d.h. erst die Daten es in der geforderten Replikation in den Journalen angekommen sind, wird die I/O-Aktion erfolgreich * [[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**: * 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/O-Scheduler (wie deadline statt cfq) **Komponenten**: * das Betriebssystem und die Komponenten sollte auf extra physikalischen Geräten platziert werden. Mindestens OSDs. * OSD (1+, ungerade Anzahl!) * Normalbetrieb: 500M per daemon, aber bei recovery/rebalancing: ~1GB RAM pro 1TB storage! * ~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/gering * 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://docs.ceph.com/docs/luminous/start/hardware-recommendations/ * https://ceph.com/geen-categorie/zero-to-hero-guide-for-ceph-cluster-planning/ * [[https://blog.flyingcircus.io/2016/05/27/ceph-performance-learnings-long-read/|Ceph performance learnings (long read)]] * [[https://ceph.com/pgcalc/|Ceph PGs per Pool Calculator]] * [[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/ ceph osd pool create scbench 100 100 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://tracker.ceph.com/projects/ceph/wiki/Benchmark_Ceph_Cluster_Performance ===== 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 "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 ==== [[http://docs.ceph.com/docs/master/rados/operations/operating/|Operating a Cluster - Running Ceph with systemd]] 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://knowledgebase.45drives.com/kb/iscsi-gateway-configuration/ ==== Ceph pg Reparatur ==== manuelle Reparatur: ceph health detail HEALTH_ERR 1 pgs inconsistent; 1 scrub errors pg 1.4ac is active+clean+inconsistent, acting [18,9,52,45] 1 scrub errors HEALTH_ERR 1 pgs inconsistent; 1 scrub errors ceph pg repair 1.4ac Für Rados: 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 1 ==== ceph exporter ==== [[https://github.com/digitalocean/ceph_exporter|ceph exporter]] exportiert Metriken z.B. nach Prometheus. ==== 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): 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: ceph zabbix send Logs: grep -i zabbix /var/log/ceph/ceph-mgr.ceph1.log ==== Nagios/Icinga ==== [[http://crapworks.de/post/ceph-monitoring/|Blogpost mit Überlegungen zum ceph-Monitoring und Vorstellung der eigenen Tools]]: * [[https://github.com/Crapworks/ceph-dash|ceph-dash - a free ceph dashboard / monitoring api]] * [[https://github.com/Crapworks/check_ceph_dash|]] [[https://github.com/ceph/ceph-nagios-plugins|Nagios plugins for Ceph - A collection of nagios plugins to monitor a Ceph cluster.]] [[https://github.com/khrpcek/check_ceph|check_ceph.py]] ===== Backup ===== Grundsätzlich: - rbd-mirror - asynchrones Replizieren (einzelne images, ganze pools) Standsind sind 30s ("rbd_mirror_sync_point_update_age") - 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): rados cppool $pool $pool.new ceph osd pool rename $pool $pool.old ceph osd pool rename $pool.new $pool **Methode 2: Rados Export/Import** rados export --create testpool tmp_dir rados import tmp_dir newpool # 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://ceph.com/geen-categorie/ceph-pool-migration/|Cache Tier drüberlegen und Objekte in neuen pool migrieren]]** ==== export/import rados images ==== * http://backy2.com/ * https://github.com/bvera/ceph-backup * https://github.com/teralytics/ceph-backup * https://github.com/magusnebula/ceph_backup_script Beschreibung: https://ceph.com/planet/rbd-ceph-backup/ * https://www.wogri.com/scripts/ceph-vm-backup/ * https://github.com/valeech/proxmox_ceph_backups * transfer deltas between snapshots on different clusters: https://ceph.com/dev-notes/incremental-snapshots-with-rbd/ http://permalink.gmane.org/gmane.comp.file-systems.ceph.devel/12238 * geo replica (drbd / pacemaker) http://www.sebastien-han.fr/blog/2013/01/28/ceph-geo-replication-sort-of/| siehe auch: * rbd Snapshots: http://docs.ceph.com/docs/luminous/rbd/rbd-snapshot/ * fsfreeze ===== manuelle Installation unter pacific ===== [[https://docs.ceph.com/en/pacific/install/manual-deployment/|manual deployment]] ==== Paketquellen einbinden ==== apt install software-properties-common wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add - echo deb https://download.ceph.com/debian-pacific/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list apt update ==== Mon installieren ==== 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 # me 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 ==== ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *' -> creating /tmp/ceph.mon.keyring sudo ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *' -> creating /etc/ceph/ceph.client.admin.keyring sudo ceph-authtool --create-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r' -> creating /var/lib/ceph/bootstrap-osd/ceph.keyring sudo ceph-authtool /tmp/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring -> importing contents of /etc/ceph/ceph.client.admin.keyring into /tmp/ceph.mon.keyring sudo ceph-authtool /tmp/ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -> importing contents of /var/lib/ceph/bootstrap-osd/ceph.keyring into /tmp/ceph.mon.keyring sudo chown ceph:ceph /tmp/ceph.mon.keyring 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 /var/lib/ceph/mon/node1 sudo -u ceph ceph-mon --mkfs -i node1 --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring systemctl start ceph-mon@node1 systemctl enable ceph-mon@node1 Erfolg kontrollieren: ceph mon stat ==== weitere MON hinzufügen ==== https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/ 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 ssh node2 apt install -y ceph-mon # nur auf hosts mit OSDs apt install -y ceph-osd cat <> /etc/hosts 1.2.3.4 node1.mydomain.tld node1 1.2.3.5 node2.mydomain.tld node2 1.2.3.6 node3.mydomain.tld node3 EOF # sudo mkdir /var/lib/ceph/mon/ceph-{mon-id} mkdir /var/lib/ceph/mon/ceph-`hostname --short` chown ceph.ceph /var/lib/ceph/mon/ceph-`hostname --short` #scp ceph/ceph.conf node2.mydomain.tld:/etc/ceph/ #ssh node2.mydomain.tld 'chmod 644 /etc/ceph/ceph.conf' #scp ceph/ceph.client.admin.keyring node2.mydomain.tld:/etc/ceph/ scp -r node1.mydomain.tld:/etc/ceph . mv ceph/ceph.conf /etc/ceph/ mv ceph/ceph.client.admin.keyring /etc/ceph/ mkdir /tmp/tmp # mon.keyring: #scp node1.inwx.net:/tmp/ceph.mon.keyring . #scp ceph.mon.keyring node2.mydomain.tld:/tmp/ scp node1.mydomain.tld:/root/ceph.mon.keyring /tmp/tmp/ # ceph auth get mon. -o {tmp}/{key-filename} ceph auth get mon. -o /tmp/tmp/key-filename -> exported keyring for mon. # ceph mon getmap -o {tmp}/{map-filename} ceph mon getmap -o /tmp/tmp/map-filename -> got monmap epoch 2 chown ceph /tmp/tmp/* sudo -u ceph ceph-mon -i `hostname --short` --mkfs --monmap /tmp/tmp/map-filename --keyring /tmp/tmp/key-filename # -> /var/lib/ceph/mon/ceph-node2 -> keyring, kv_backend, store.db # 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, beyond ensuring it is running. If there is no mgr daemon running, you will see a health warning to that effect, and some of the other information in the output of ceph status will be missing or stale until a mgr is started. 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." apt install -y ceph-mgr mkdir /var/lib/ceph/mgr/ceph-`hostname --short` chown ceph /var/lib/ceph/mgr/ceph-`hostname --short` ceph auth get-or-create mgr.`hostname --short` mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-`hostname --short`/keyring chown ceph /var/lib/ceph/mgr/ceph-`hostname --short`/keyring chmod 600 /var/lib/ceph/mgr/ceph-`hostname --short`/keyring systemctl enable --now ceph-mgr@`hostname --short` ==== MGR Einstellungen ==== # setting is clusterwide: ceph mgr module enable selftest ceph mgr self-test run mgr module anzeigen 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 /dev/disk/by-id/scsi-350000397d8221f44 (mit einer Partition): # existiert /var/lib/ceph/bootstrap-osd/ceph.keyring ? parted -s /dev/disk/by-id/scsi-350000397d8221f44 mklabel gpt parted --align optimal -s /dev/disk/by-id/scsi-350000397d8221f44 mkpart osd-device-data 0% 100% ceph-volume lvm create --data /dev/disk/by-id/scsi-350000397d8221f44-part1 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: 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 # "updated" # oder: # "entity osd.0 does not exist" wenn das Gerät dann immer noch busy ist: ls /dev/mapper/ceph-* | xargs -I% -- dmsetup remove % partprobe $DISK sgdisk --zap-all $DISK [[https://github.com/rook/rook/issues/9764|Quelle]] ==== Cluster Einstellungen ==== health: HEALTH_WARN: insecure_global_id_reclaim ceph config set mon auth_allow_insecure_global_id_reclaim false health: HEALTH_WARN: 1 monitors have not enabled msgr2 https://docs.ceph.com/en/latest/rados/operations/health-checks/ ceph mon enable-msgr2 === Ceph Brandabschnitte === ceph osd tree Die DC-Zonen erstellen: ceph osd crush add-bucket dc1 datacenter ceph osd crush add-bucket dc2 datacenter DCs in "root default" schieben: ceph osd crush move dc1 root=default ceph osd crush move dc2 root=default Ceph-Nodes zu jeweiligen DC anordnen: 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**: 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... 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://docs.ceph.com/en/latest/rados/operations/pools/#set-the-number-of-object-replicas|minimal nötige Replika-Anzahl um Schreiben zu können]].) 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:47:08.268+0100 7fcfa1a70700 -1 monclient(hunting): handle_auth_bad_method server allowed_methods [2] but i only support [2] stderr: [errno 13] RADOS permission denied (error connecting to the cluster) -> keyring abgleichen mit der Ausgabe von ''ceph auth list'' (aufgetreten beim OSD-deployment via /var/lib/ceph/bootstrap-osd/ceph.keyring). Aus Sicherheitsgrüngen muss Ceph-Cluster auf mehrere Datacentren verteilt werden. ==== ceph status meldet "daemons have recently crashed" ==== 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: ceph crash ls Einzelnen Crash anzeigen lassen: ceph crash info Einzelnen Crash archivieren: ceph crash archive Alle neuen Crashes archivieren: ceph crash archive-all 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: The IP address and netmask of the public (front-side) network (e.g., 192.168.0.0/24). Set in . You may specify comma-delimited subnets. [global] public network = ip-address}/{netmask} [, {ip-address}/{netmask}] * Monitors: * (altes) v1-Protokoll: 6789 TCP * v2-Protokoll: 3300 TCP * OSDs Kummunikation: range 6800:7300 TCP * **cluster netzwerk** (eigene Netzwerkkarte empfohlen; sollte nicht vom public network oder Internet erreichbar sein)[global] cluster network = ip-address}/{netmask} [, {ip-address}/{netmask}] siehe auch: [[http://docs.ceph.com/docs/luminous/rados/configuration/network-config-ref/|Ceph Networking details]] Releases: http://docs.ceph.com/docs/master/releases/ Get Packages: http://docs.ceph.com/docs/master/install/get-packages/ ==== Destroy Cluster ==== 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:SSH]] pubkey-Zugriff (Passwort reicht nicht) erreichbar ist * nicht gleichlautend mit dem ceph-System-Benutzer ist * per sudo root-Rechte erreichen kann (ohne Passwortabfrage) Hier im Beispiel wird useradd -d /home/cephdeploy -m cephdeploy # Zufallspasswort setzen passwd cephdeploy echo "cephdeploy ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/cephdeploy mkdir /home/cephdeploy/.ssh # pubkey hinterlegen: ssh-copy-id -i ~/.ssh/id_dsa.pub cephdeploy@CEPH-HOST vi /home/cephdeploy/.ssh/authorized_keys chown cephdeploy /home/cephdeploy/.ssh chown cephdeploy /home/cephdeploy/.ssh/authorized_keys chmod 700 /home/cephdeploy/.ssh chmod 600 /home/cephdeploy/.ssh/authorized_keys Alle beteiligten Nodes sollten per ''/etc/hosts'' die IPs fest hinterlegt haben um DNS-Problemen vorzubeugen. node1 1.2.3.4 node2 1.2.3.5 node3 1.2.3.6 Für die Ceph-Nodes eine SSH-Config hinterlegen (''.ssh/config''): # ======== CEPH============= Host node1 Hostname node1.domain.tld User cephdeploy Host node2 Hostname node2.domain.tld User cephdeploy Host node3 Hostname node3.domain.tld User cephdeploy ==== Ceph Installation auf admin-Rechnern und Nodes ==== [[http://docs.ceph.com/docs/master/install/get-packages/|Ceph packages]] wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add - (debian) minimal-system: * ca-certificates vorher installieren) * sudo apt-get install apt-transport-https sonst "''method driver /usr/lib/apt/methods/https could not be found''") benötigte Pakete: * Debian Jessie+: sudo apt-get install software-properties-common * Debian Wheezy und vorher: sudo apt-get install python-software-properties * Debian stretch: sudo apt-add-repository 'deb https://download.ceph.com/debian-luminous/ stretch main' * Ubuntu 16.04: sudo apt-add-repository 'deb https://download.ceph.com/debian-luminous/ xenial main' Das resultiert auf xenial in: deb http://security.ubuntu.com/ubuntu xenial-security main restricted # deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted deb http://security.ubuntu.com/ubuntu xenial-security universe # deb-src http://security.ubuntu.com/ubuntu xenial-security universe deb http://security.ubuntu.com/ubuntu xenial-security multiverse # deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse deb https://download.ceph.com/debian-luminous/ xenial main # deb-src https://download.ceph.com/debian-luminous/ xenial main * Ubuntu 18.04: sudo apt-add-repository 'deb https://download.ceph.com/debian-luminous/ bionic main' Das resultiert auf bionic in: deb http://security.ubuntu.com/ubuntu bionic-security main restricted # deb-src http://security.ubuntu.com/ubuntu bionic-security main restricted deb http://security.ubuntu.com/ubuntu bionic-security universe # deb-src http://security.ubuntu.com/ubuntu bionic-security universe deb http://security.ubuntu.com/ubuntu bionic-security multiverse # deb-src http://security.ubuntu.com/ubuntu bionic-security multiverse deb http://archive.canonical.com/ bionic partner # deb-src http://archive.canonical.com/ bionic partner deb https://download.ceph.com/debian-luminous/ bionic main # deb-src https://download.ceph.com/debian-luminous/ bionic main "Ceph on ARM processors requires Google’s memory profiling tools (google-perftools). The Ceph repository should have a copy at https://download.ceph.com/packages/google-perftools/debian. * Repository hinzufügen:echo deb https://download.ceph.com/packages/google-perftools/debian $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/google-perftools.list" Allgemein: wget -q https://download.ceph.com/debian-{release}/pool/main/c/ceph/ceph_{version}{distro}_{arch}.deb * Ubuntu Xenial: wget -q https://download.ceph.com/debian-luminous/pool/main/c/ceph/ceph_12.2.2-1xenial_amd64.deb * Debian stretch: wget -q https://download.ceph.com/debian-luminous/pool/main/c/ceph/ceph_12.2.2-1strech_amd64.deb **ceph installieren**: sudo apt install ceph ==== Cluster erstellen (Admin-Rechner) ==== ceph-deploy installieren: sudo apt install ceph-deploy === Projektdirectory anlegen === mkdir ceph-cluster1 cd ceph-cluster1 ssh-keygen -f ./sshkey -b 3072 (keine passphrase) den sshkey für ceph-deploy zu den Nodes übertragen: 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 === ceph-deploy new node1 node2 node3 ceph-deploy install node1 node2 node3 === ersten Mon erstellen (besser gleich 3) === ceph-deploy mon create-initial 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): ceph-deploy admin node1 node2 node3 :!: auf admin-Instanzen kann "ceph health" (kurz) oder "ceph -s" (ausführlich) ausgeführt werden. === manager daemon === **manager daemon** (ab "luminous" nötig) erstellen: ceph-deploy mgr create node1 === OSDs erzeugen === http://docs.ceph.com/docs/luminous/rados/operations/add-or-rm-osds :!: auf jedem node muss mindestens ein Blockdevice frei sein. Das sollten einfache/unabhängige Festplatten sein (kein remote-storage oder raid!) 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: überleben den reboot nicht, hier kein journal (daher NICHT für produktiv-Cluster benutzen, eher für einen ersten Test in vServern). dd if=/dev/zero bs=1024000 count=10240 >> /ceph-osd.img losetup /dev/loop0 /ceph-osd.img ceph-deploy osd create node1:loop0 node2:loop0 node3:loop0 == Variante 2: filestore == Reale devices per /dev/by-uuid oder lvm volumes (empfohlen) einbinden, siehe auch: http://docs.ceph.com/docs/master/ceph-volume/#migrating . [[linux:LVM]]-Beispiel: * in der Volume-group "vg_OSDs" das logical volume "lv_OSD_A" angelegt (...B, ...C), * in der Volume-group "vg_journal" jeweils ein logical Volume für das journal "lv_journal_A" (...B, ...C) **Erster Schritt: [[linux:LVM]]-Geräte müssen per [[http://docs.ceph.com/docs/master/ceph-volume/lvm/prepare/#ceph-volume-lvm-prepare|prepare]] vorbereitet werden** (xfs-Formatierung): ceph-volume lvm prepare --filestore --data vg_OSDs/lv_OSD_A --journal vg_journal/lv_journal_A In einem realen Setup bevorzuge ich den Namen aus Festplattenmodell und Seriennummer zu bilden (vg_osd_$Modell_$Seriennumer)((abrufbar mit smartctl -i /dev/$GERÄT)). Das erleichtert den Austausch bei Defekten. In der Ausgabe von ceph-osd findet sich sowohl die neue osd.$ID als auch die osd-uuid ("--osd-uuid"). Alternativ sucht man sich einfach den neuen Namen aus dem ''ceph osd tree'' heraus und fragt die uuid ab (hier ist der neue OSD der osd.4): ceph-osd -i 4 --get-osd-fsid 6b0e9607-82d8-4c7f-99f6-89a4235225d4 **Zweiter Schritt: OSD Aktivieren** (Schema: ''ceph-volume lvm activate --filestore $ID $OSD-FSID''): ceph-volume lvm activate --filestore 4 6b0e9607-82d8-4c7f-99f6-89a4235225d4 Die alternativ beschriebene 1-step-Methode mit ceph-deploy funktioniert nicht zuverlässig((Stand 02/2018 Luminous v12.2)): ceph-deploy osd create node1:vg_OSDs/lv_OSD_A:vg_journal/lv_journal_A == Variante 3: bluestore == bluestore ist ab luminous möglich und empfohlen: Beispiel: leere Festplatte /dev/sdd parted /dev/sdd (parted) mkpart 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 ceph-deploy osd create --data /dev/sdd1 node1 manuell auf Host: ceph-volume lvm create --bluestore --data /dev/sdd1 [[https://github.com/HeinleinSupport/ceph/blob/master/filestore_to_bluestore/migrate_to_bluestore.sh|Skript zur Migration von OSDs]] === OSD entfernen === Die Entfernung von OSDs ist in "luminous" leider noch ein manueller Vorgang: http://docs.ceph.com/docs/luminous/rados/operations/add-or-rm-osds/#removing-osds-manual :!: der Cluster soll nicht "full" sein, es könnte nicht mehr genug Platz verfügbar sein. In kleineren Clustern können PGs im Status "active+remapped" stecken bleiben. Daher kann es besser sein, dem zu entfernenden OSD per reweight rauszunehmen: ceph osd crush reweight osd.3 0 oder gleich richtig aus: ceph osd out osd.3 Folgen: * rebalance startet: status active+clean -> active * wenn fertig: status active -> active+clean Stoppen:systemctl stop ceph-osd@osd.3 Löschen:ceph osd purge osd.3 --yes-i-really-mean-it === zusätzliche mgr erzeugen === node2 + node3 zum mgr machen: ceph-deploy mgr create node3 ceph -s zeigt nun: mgr: node1(active), standbys: node2, node3 === Optional: Ceph Object Gateway === FIXME Testen ceph-deploy rgw create node1 ... # port 7480 ändern: [client] rgw frontends = civetweb port=80 === Optional: mehr mon hinzufügen (Anzahl ungerade!) === FIXME ceph-deploy mon add node2 node3 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://docs.ceph.com/docs/master/rados/configuration/network-config-ref siehe a auch: http://tracker.ceph.com/issues/5195 ===== Daten speichern ===== ==== zuerst pool erstellen ==== http://docs.ceph.com/docs/master/rados/operations/pools/ ceph osd pool create pool1 replicated oder ceph osd pool create pool1 erasure Für ceph-fs: ceph osd pool create cephfs_data ceph osd pool create cephfs_metadata ceph fs new $pool1 cephfs_metadata cephfs_data **List pools**: ceph osd pool ls 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: cephfs, rbd, rgw, freie Eingabe Hier Zuweisung auf cephfs: ceph osd pool application enable pool1 cephfs ==== Pool löschen ==== Zum löschen eines Pools muss der Namen 2x hintereinander geschrieben werden, gefolgt von "''--yes-i-really-really-mean-it''". ceph osd pool delete pool1 pool1 --yes-i-really-really-mean-it Seit der Version "hammer" funktioniert dies nicht mehr direkt, die folgende Fehlermeldung erscheint Error EPERM: pool deletion is disabled; you must first set the mon_allow_pool_delete config option to true before you can destroy a pool 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: systemctl restart ceph-mon.target Einzelne Pools sollten gegen versehentliches löschen geschützt werden: ceph osd pool set $pool nodelete true [[https://blog.widodh.nl/2015/04/protecting-your-ceph-pools-against-removal-or-property-changes/|Hintergrund der Änderung]] ==== Pool umbenennen ==== ceph osd pool rename pool-alt pool-neu ==== Pool Statistics ==== rados df ceph osd dump | grep 'replicated size' pool 1 'pool1' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 100 pgp_num 100 last_change 17 flags hashpspool stripe_width 0 application rbd ==== Pool Snapshot ==== * anlegen: ceph osd pool mksnap {pool-name} {snap-name} * löschen: ceph osd pool rmsnap {pool-name} {snap-name} FIXME Snapshot benutzen? ==== Pool Quota ==== ceph osd pool set-quota data max_objects 10000 # 1 Gigabyte: ceph osd pool set-quota data max_bytes 1073741824 Quota anzeigen: ceph osd pool get-quota data ===== RBD ==== ==== einen pool für rbd nutzbar machen ==== **Zuweisung eines pools** ("pool1") **an rbd**: ceph osd pool application enable pool1 rbd **Initialisieren** (auf admin-node:) rbd pool init pool1 :!: Benutzerverwaltung Block-device: Standard ist "admin" -> sollte feiner angelegt werden! http://docs.ceph.com/docs/master/rbd/rados-rbd-cmds/#create-a-block-device-user ==== rbd Image anlegen ==== zum speichern muss der client - pool - object namen angeben. Siehe auch [[http://docs.ceph.com/docs/master/start/quick-ceph-deploy/#storing-retrieving-object-data|Objekte abspeichern]] Schema: rbd create --size {megabytes} {pool-name}/{image-name} rbd create --size 2048 pool1/image1 --image-feature fast-diff ==== Image Aktionen ==== **Images eines pools** (pool1) **anzeigen** (Ergebnis: image1): rbd ls pool1 image1 **Informationen anzeigen**:rbd info pool1/image1 "rbd image 'image1': size 2048 MB in 512 objects order 22 (4096 kB objects) block_name_prefix: rbd_data.104b74b0dc51 format: 2 features: layering, exclusive-lock, object-map, fast-diff, deep-flatten flags: create_timestamp: Fri Feb 9 00:56:19 2018" **resize**: * mehr (3072 MB): rbd resize --size 3072 pool1/image1 * weniger (1024 MB): rbd resize --size 1024 pool1/image1 --allow-shrink **löschen**: * sofort: rbd rm pool1/image1 * löschen (Papierkorb): rbd trash mv pool1/image1 * Wiederherstellen: rbd trash restore pool1/image1 **weitere Befehle**: http://docs.ceph.com/docs/master/man/8/rbd/ ==== 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 "overwrite support"** hat librbd::image::CreateRequest: 0x55e60878a6f0 handle_validate_overwrite: pool missing required overwrite support Dies ist standardmäßig nicht der Fall und muss daher explizit aktiviert werden: ceph osd pool set mein_erasure_pool allow_ec_overwrites true * **die OSDs müssen mit bluestore** eingerichtet worden sein. Mit filestore geht das nicht: Error EINVAL: pool must only be stored on bluestore for scrubbing to work: osd.2 uses filestore * die omap-property wird nicht unterstützt (("which allows you to store arbitrary key/value data inside each object")) Deswegen gibt es die spezielle "data pool" property. * aus den release-Notes [[https://raw.githubusercontent.com/ceph/ceph/master/doc/release-notes.rst|release Notes]]: ((v12.2.0 Luminous)) * *Erasure coded* pools now have `full support for overwrites <../rados/operations/erasure-code/#erasure-coding-with-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's checksumming to do deep scrubbing, enabling this on a pool stored on filestore is not allowed. Wenn alle diese Vorraussetzungen erfüllt sind, zeigt [[https://ceph.com/community/new-luminous-erasure-coding-rbd-cephfs/|diese Anleitung wie es geht]]. Hier abgewandelt ein minimal redundantes setup (profil ec-31-profile, zu profilen siehe [[http://docs.ceph.com/docs/master/rados/operations/erasure-code/|Erasure code profiles]]): 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/$imagename --size 1T --data-pool $poolname ==== rbd-kernel-module ==== http://docs.ceph.com/docs/luminous/rbd/rbd-ko/ rbd map share --pool pool1 Möglicherweise müssen features abgeschaltet werden, die der Client nicht unterstützt: rbd: image share: image uses unsupported features: 0x38 (hier deep-flatten/layering, siehe rbd info): rbd feature disable pool1/rbd1 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: exclusive locking support object-map: object map support (requires exclusive-lock) fast-diff: fast diff calculations (requires object-map) deep-flatten: snapshot flatten support journaling: journaled IO support (requires exclusive-lock) U.U geht das nicht im laufenden Betrieb: rbd: failed to update image features: 2018-02-18 22:01:59.941776 7fa8d9ae70c0 -1 librbd::Operations: cannot update immutable features daher neu anlegen: rbd create pool1/test2 -s 1024 --image-format 2 --image-feature exclusive-lock rbd info pool1/test2 rbd image 'test2': size 1024 MB in 256 objects order 22 (4096 kB objects) block_name_prefix: rbd_data.107c2ae8944a format: 2 features: exclusive-lock flags: rbd feature disable pool1/test2 exclusive-lock === image mounten/unmounten/anzeigen === **gemountete image anzeigen**: rbd showmapped id pool image snap device 0 pool1 test2 - /dev/rbd0 **mounten**: rbd map pool1/test2 das benutzte device wird von rbd zurückgemeldet: /dev/rbd0 **unmounten**: rbd unmap pool1/test2 === Client zu alt === [So Feb 18 22:02:28 2018] libceph: mon0 1.2.3.4:6789 feature set mismatch, my 106b84a842a42 < server's 40106b84a842a42, missing 400000000000000 [So Feb 18 22:02:28 2018] libceph: mon0 1.2.3.4:6789 missing required protocol features ''CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING'' braucht Kernel 4.5+ - Ubuntu 16.04 hat Linux 4.4 ! -> Codes siehe http://cephnotes.ksperis.com/blog/2014/01/21/feature-set-mismatch-error-on-ceph-kernel-client (aktuelle Tabelle siehe kernel sources in features.h). **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://docs.ceph.com/docs/master/rados/operations/crush-map/#tunables)ceph osd crush tunables hammer ==== 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. mount -o discard /dev/rbd0 /media/rbd0 fstrim /media/rbd0 * [[https://ceph.com/geen-categorie/use-discard-with-krbd-client-since-kernel-3-18/|Use Trim/discard With Rbd Kernel Client (Since Kernel 3.18)]] * [[https://dev.opennebula.org/issues/3060|trim/discard for Ceph RBD]] ==== rbd-fuse ==== sudo aptitude install rbd-fuse "rbd-fuse is a FUSE (File system in USErspace) client for RADOS block device (rbd) images. Given a pool containing rbd images, it will mount a userspace filesystem allowing access to those images as regular files at mountpoint." # mkdir /media/rdb # chown ich.gruppe /media/rdb rbd-fuse -c /pfad/zu/projektverzeichnis/ceph.conf -p pool1 /media/rdb fusermount -u /media/rdb ==== RGW (S3) ==== [[https://docs.ceph.com/en/latest/man/8/radosgw-admin/|radosgw-admin (man page)]] ===== Sicherheitskonzept ===== Aktuell ist ceph nicht für den Betrieb im "freien" Internet geeignet, es müssen Maßnahmen getroffen werden um ceph abzusichern: 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://docs.ceph.com/docs/mimic/rados/operations/user-management/ auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx Darüber hinaus können wenigstens [[http://docs.ceph.com/docs/luminous/rados/configuration/auth-config-ref/#signatures|Signaturen]] aktiviert werden: # http://docs.ceph.com/docs/luminous/rados/configuration/auth-config-ref/#signatures 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 "CLIENT1" anlegen und Rechte vergeben: ceph auth get-or-create client.CLIENT1 mds 'allow r' mon 'allow r' osd 'allow rw pool=TESTPOOL' (ob mds 'allow r' nötig ist muss ich noch testen) Beispiel für eine sichere RDB-ACL (Quelle: http://tracker.ceph.com/issues/9733): ceph auth caps client.CLIENT1 mon 'allow r' osd 'allow x pool=TESTPOOL object_prefix rbd_children, allow rwx pool=TESTPOOL object_prefix rbd_header., allow rwx pool=TESTPOOL object_prefix rbd_id., allow rw pool=TESTPOOL object_prefix rbd_data.' === client seite === Erstens ceph installiert sein und eine config vorhanden sein ''/etc/ceph/ceph.conf'': [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: ceph auth print-key client.CLIENT1 > /etc/ceph/client.CLIENT1.keyring **Client Connect** (hier mit RBD): rbd map TESTPOOL/image1 --id CLIENT1 --keyfile /etc/ceph/client.CLIENT1.keyring --id und --keyfile können auch in eine Umgebungsvariable CEPH_ARGS exportiert werden: CEPH_ARGS="--id CLIENT1 --keyfile /etc/ceph/client.CLIENT1.keyring" export CEPH_ARGS echo $CEPH_ARGS === Rechte verändern === Rechte müssen (absolut) neu gesetzt werden: ceph auth caps client.CLIENT1 mds 'allow r' mon 'allow r' osd 'allow rw pool=TESTPOOL' Bei Erfolg Meldung "updated caps for client.CLIENT1".