28.08.2013 - Fachbeitrag

Ein Ceph-Cluster auf unseren Linux-Desktops

Mitte August besuchte uns in Berlin Loïc Dachary, ein fanzösischer Ceph-Entwickler. Mit ihm hatten wir zwei interessante Gespräche über Ceph, die Nutzungsmöglichkeiten und die zukünftige Entwicklung. Während Loïc einen sehr interessanten Ansatz verfolgt eine Art "Raid-5" im Ceph einzuführen, fand Loïc den Umstand interessant, daß wir in unserem Büronetzwerk große Datenspeicher in Ceph tatsächlich praktisch nutzen.

Loïc veröffentlichte in seinem Blogeintrag die nachfolgende Dokumentation über unser Netzwerk, wir veröffentlichen hier die deutsche Übersetzung des englischen Artikels unseres charmanten Franzosen über unser eigenes Büro...

Große Datenspeicher mit Ceph -- ohne extra Hardware

Anfang Juli 2013 haben wir bei Heinlein Support auf sieben Desktop-Rechnern einen Ceph Cuttlefish Cluster aufgesetzt. Dazu wurde ein Teil der bereits vorhandenen großen Festplatten für je ein OSD reserviert. Die Knoten sind mit 1Gb/s bzw. teilweise nur mit 100Mb/s verbunden, insgesamt ist eine Kapazität von 4TB für ein Ceph-Filesystem vorhanden:

ceph-office$ df -h .

Filesystem                 Size  Used Avail Use% Mounted on

x.x.x.x,y.y.y.y,z.z.z.z:/  4,0T  2,0T  2,1T  49% /mnt/ceph-office

Das CephFS nutzen wir als temporären Platz, um Dateien zwischenzuspeichern und auszutauschen. An einem typischen Arbeitstag wird immer mal wieder ein Desktop-Rechner ausgeschaltet oder neu gestartet. Der Cluster hat sich seit der Installation dabei immer wieder selber „geheilt”. Es musste bislang nur einmal eine Placement Group mittels pg repair repariert werden, weil sie in einem unsauberen Zustand hängengeblieben war.

So wird Ceph gemountet

Jeder Mitarbeiter kann das Ceph-Filesystem nutzen, indem die folgende Zeile in die /etc/fstab eingetragen wird:

mon01,mon02,mon03:/ /mnt/ceph-office ceph \

    noatime,dirstat,name=office,secret=SECRET_IN_BASE64 0 0

Dann wird der Mountpoint erzeugt und eingebunden:

mkdir /mnt/ceph-office

mount /mnt/ceph-office

Danach hat jeder Zugriff auf das gemeinsam nutzbare Dateisystem. Wir vertrauen uns und setzen hier keine besonderen Zugriffsrechte. Manche legen z.B. auch temporär git-Repositories dort ab.

'ceph-deploy' installiert einen Ceph-Knoten

Die Knoten des Clusters wurden mit <a
href="https://github.com/ceph/ceph-deploy">ceph-deploy</a> nach der Dokumentation
installiert. Es gibt drei Monitore, zwei davon auf den beteiligten Desktop-Maschinen und einer in einer kleinen VM, die für diesen Zweck erstellt wurde. Auf dieser VM läuft auch der aktive MDS, ein Standby dafür läuft auf einem der Desktops.

Den aktuellen Zustand des Clusters zeigt ceph -s:

$ ceph -s

   health HEALTH_OK

   monmap e7: 3 mons at {mon01=192.168.100.x:6789/0,\

                                      mon02=192.168.100.y:6789/0,\

                                      mon03=192.168.100.z:6789/0}, \

   election epoch 124, quorum 0,1,2 mon01,mon02,mon03

   osdmap e2497: 7 osds: 7 up, 7 in

    pgmap v329003: 464 pgs: 464 active+clean; 124 GB data, \

                1934 GB used, \

                2102 GB / 4059 GB avail; 614B/s wr, 0op/s

   mdsmap e31488: 1/1/1 up {0=192.168.100.a=up:active}, 1 up:standby

Die Erstellung von OSDs

Auf vielen Maschinen konnte noch eine „einfache” Partition für den OSD verwendet werden, um dort Daten und Journal zu speichern. Andere waren bereits mit LVM ausgestattet, so daß hier ein logical Volume erzeugt werden konnte. Dieses wurde mit XFS formatiert und nach /mnt/lvm/ceph gemountet. Dann konnte mit ceph-deploy das Verzeichnis als solches für den OSD eingebunden werden. Dabei wird ein symbolischer Link erzeugt:

/var/lib/ceph/osd$ ls -l

total 0

lrwxrwxrwx 1 root root 13 Jul  4 11:21 ceph-1 -> /mnt/lvm/ceph/

Obwohl das Volume eigentlich genauso wie eine ganze Festplatte oder eine Partition genutzt werden können sollte, würde man dazu Tricks wie kpartx brauchen, ohne daß man wirklich etwas gewinnen würde.

Wir haben auch versucht, das Filesystem für die OSD-Daten in einer großen, loopback gemounteten Datei unterzubringen. Das hätte auf den bereits eingerichteten Rechnern eine Neupartitionierung oder eine Änderung der vorhandenen Volumes verhindert. Aber aus nicht näher untersuchten Gründen führte das zu hohen I/O-waits und zu einem praktisch unbrauchbaren Desktop-Rechner.

Alle Knoten benutzen XFS als Dateisystem für den OSD und SATA-Festplatten.

Die Crushmap verteilt Daten redundant in zwei Brandschutzzonen

Die Desktop-Rechner verteilen sich auf 2 Etagen und mehrere Büroräume. Die Crushmap orientiert sich daran und verteilt über die Pool-Regeln zwei Replicas auf zwei verschiedene Büros, egal auf welcher Etage. Der Baum (ceph osd tree) sieht so aus:

# id	weight	type name	up/down	reweight

-1	3.08	root default

-12	0.35		floor three

-7	0.21			office 304

-5	0.21				host node01

3	0.21					osd.3	up	1

-8	0.06999			office 305

-6	0.06999				host node02

4	0.06999					osd.4	up	1

-9	0.06999			office 307

-2	0.06999				host node03

7	0.06999					osd.7	up	1

-13	2.73		floor four

-10	0.49			office 403

-3	0.24				host node04

1	0.24					osd.1	up	1

-14	0.25				host node05

5	0.25					osd.5	up	1

-11	0.24			office 404

-4	0.24				host node06

0	0.24					osd.0	up	1

-16	2			office 405

-15	2				host node07

6	2					osd.6	up	1

Die wichtigen Regelzeilen aus der Crushmap sind:

rule data {

	ruleset 0

	type replicated

	min_size 1

	max_size 10

	step take default

	step chooseleaf firstn 0 type office

	step emit

}

rule metadata {

	ruleset 1

	type replicated

	min_size 1

	max_size 10

	step take default

	step chooseleaf firstn 0 type office

	step emit

}

Das war eine Übersetzung des Originalartikels von Loïc Dachary.

Für Fragen und Projekte rund um Ceph / Rados steht das Team von Heinlein Support gerne zur Verfügung...