Inhaltsverzeichnis

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.

:!: Diese Doku basiert auf Ceph 16.x (pacific) (siehe 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).

Deploymethoden

Begriffe

https://docs.ceph.com/en/latest/glossary/

Komponenten

Leistungsanforderungen

Was man allgemein wissen muss:

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:

siehe auch:

Anforderungen allgemein:

Komponenten:

Links:

Hyperconverged setup

Hyperconverged setup bedeutet: Storage und Virtualisierungsnodes sind die gleichen Maschinen.

Vorteile:

  1. einfacheres setup
  2. weniger hardware nötig

Nachteile:

  1. rebalance frisst RAM und CPU
  2. keine Trennung zwischen Storage und Virtualisierung

Benchmarks

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

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 exporter

ceph exporter exportiert Metriken z.B. nach Prometheus.

Zabbix-Integration

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

Blogpost mit Überlegungen zum ceph-Monitoring und Vorstellung der eigenen Tools:

Nagios plugins for Ceph - A collection of nagios plugins to monitor a Ceph cluster.

check_ceph.py

Backup

Grundsätzlich:

  1. rbd-mirror
    1. asynchrones Replizieren (einzelne images, ganze pools) Standsind sind 30s („rbd_mirror_sync_point_update_age“)
    2. via rbd features: journaling (+ exclusive lock)
    3. benutzt rbd-daemons der beide cluster erreich können muss (via internem Netzwerk)
  2. s3 multisite (live-Replikation von Objekten wenn rados Gw benutzt wird, muss unterstützt werden
    1. Eine Verbindung radosgw zu radosgw
  3. können RBD-Snapshots benutzt werden (snapshot verwalten):
    1. rbd snap create ..
    2. rbd export-diff .. | ssh rbd import-diff ..
    3. 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: Cache Tier drüberlegen und Objekte in neuen pool migrieren

export/import rados images

siehe auch:

manuelle Installation unter pacific

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 <<EOF >> /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

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 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 <id>

Einzelnen Crash archivieren: 

ceph crash archive <id>

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

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}]

siehe auch: 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

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

Ceph packages 

wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -

(debian) minimal-system:

benötigte Pakete:

„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.

Allgemein: wget -q https://download.ceph.com/debian-{release}/pool/main/c/ceph/ceph_{version}{distro}_{arch}.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 .

LVM-Beispiel:

Erster Schritt: LVM-Geräte müssen per 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)1). 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ässig2): 

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

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:

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:

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:

  1. pool-name: pool1
  2. 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

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

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

  1. pool
  2. object namen

angeben.

Siehe auch 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:

löschen:

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:

Wenn alle diese Vorraussetzungen erfüllt sind, zeigt diese Anleitung wie es geht.

Hier abgewandelt ein minimal redundantes setup (profil ec-31-profile, zu profilen siehe 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:

  1. Client mit höherer Kernel-version einsetzen
  2. rbd-fuse benutzen (Leistungsverlust)
  3. 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

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)

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 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“.

1)
abrufbar mit 
smartctl -i /dev/$GERÄT
2)
Stand 02/2018 Luminous v12.2
3)
„which allows you to store arbitrary key/value data inside each object“