Select Page

NETWAYS Blog

Ceph auf Raspberry Pi als Bastelstorage

Ceph auf Raspberry Pi als Bastelstorage ist eine (relativ) einfache Möglichkeit, eine Technologie wie Ceph auszuprobieren, ohne gleich Racks voller Server anschaffen zu müssen. Ceph hat mich schon sehr lange gereizt, es mal intensiver ansehen zu können, aber mich hat immer der doch nicht unerhebliche Hardware-Aufwand abgeschreckt. Nach etwas Recherche habe ich aber herausgefunden, dass man, mit einigen Kompromissen, durchaus ein taugliches System auch mit einfacher Hardware zum Laufen bekommen kann.

Da ich oft höre, dass ich zu viele Worte mache, dachte ich, ich lass den technischen Teil diesmal großteils weg und verlinke dafür auf die Anleitung, die ich selber benutzt habe. Doch eine Warnung vorweg: Das, was man sich damit bastelt, ist sicherlich nicht das, was man “Best Practices” oder auch nur “stabil für Produktion” nennen würde. Meiner Erfahrung nach reicht es aber auf jeden Fall für’s Home Lab, als Storage für einen Proxmox mit diversen Services für Home Automation (z.B. Homeassistant und Grafana mit InfluxDB) und als Ablöse für eine 10 Jahre alte Qnap (mit entsprechendem Backup jedenfalls).

Was ich verändert habe, zu der Anleitung ist folgendes

  • Statt PoE werden meine Raspis direkt mit Strom versorgt
  • Ich habe nur 3 Raspberry Pi, dafür weitere Knoten (siehe unten)
  • Statt der mikrigen USB Sticks, die hauptsächlich für Tests taugen, hab’ ich jedem Raspi eine 8TB USB Platte verpasst (Muhahaha!)

Durch die insgesamt 24TB Storage, die sich bei mir ergeben haben, habe ich, trotz ausreichender Redundanz tatsächlich genug Platz, meine VMs und eben den Inhalt der Qnap dorthin übernehmen zu können. Da meine Raspberry Pi jeweils nur 4GB Ram haben, bin ich schon sehr weit von “Best Practices” entfernt. Aber was soll ich sagen: Es funktioniert doch erstaunlich gut. Aber, es hat sich auf jeden Fall bewährt, einige der Ceph-internen Dienste auf andere Hosts auszulagern. Im nächsten Abschnitt erkläre ich kurz, wie.

Das Ceph nutze ich als Storage Backend für 3 Proxmox Hosts, wofür die drei Raspberry Pi gerade noch ausreichend sind. Spätestens wenn man aber Ceph-FS (also das Filesystem, das man direkt einbinden kann) möchte, braucht man noch weitere Dienste. Das geht sich auf den Raspberry Pis dann insgesamt nicht mehr aus. Nach der Anleitung erhält man über das Ceph Dashboard eine Möglichkeit, Dienste auf Knoten im Cluster zu verschieben. Ein “Dienst” In diesem Zusammenhang ist dann “unter der Haube” ein Docker Container, der auf dem angegebenen Host gestartet wird. Dabei sucht sich Ceph per Default einfach Knoten aus, auf denen die Container gestartet werden – meist mehrere für Redundanz. Wenn man das steuern will, kann man den Knoten Tags verpassen und Services an Tags binden. Um jetzt die Last von den Raspberry Pi zu bekommen, habe ich nochmal drei Knoten mit Fedora Server hochgezogen, diesmal aber in Proxmox. Um kein Henne-Ei Problem zu erschaffen liegt deren Storage auf den lokalen SSDs der Proxmox Hypervisor. Damit beantwortet sich auch die Frage, ob man in Ceph verschiedene Architekturen mischen kann: Ja. Im Endeffekt sind jetzt die “OSD”, also die Dienste, die sich ums Storage Management kümmern, auf den Raspis und alles andere auf den VMs auf dem Proxmox.

Ceph-Dashboard

Screenshot meines Ceph Dashboard

Wie geht’s weiter

Das schöne an Ceph ist, dass man beim Ausbau so flexibel ist. Wenn ich bei der Qnap mehr Speicher möchte, müsste ich aktuell eine neue Qnap kaufen und alle Platten ersetzen. Dagegen kann ich bei Ceph einfach noch einen Raspi mit einer weiteren Platte dazu stellen. Damit hätte ich nicht nur mehr Speicher, sondern auch mehr Durchsatz, mehr Ram, mehr CPU und vor allem mehr Redundanz.

Wenn’s mal zu langsam wird, könnte ich auch NUCs oder ähnliches Gerät mit anbinden und Dienste, die besonders viel Geschwindigkeit brauchen, dort laufen lassen.

Was waren die Probleme?

Am meisten geärgert hat mich, dass ich nicht kapiert hatte, dass die Ceph Container nur auf 64 bit Systemen laufen. Das heisst, man braucht erstens einen Raspberry Pi 4 (oder einen bestimmten 3er) und ein 64bit OS. Die Anleitung zeigt hier nur auf die Fedora Installationen. Die 64bit Variante muss man sich erst noch raus suchen. Bevor ich das kapiert hatte, musste ich meine Raspi ein paar mal neu aufsetzen.

Die 8TB Platten wurden mir lange nicht angezeigt. Man kann Platten in der Version des Dashboards, das mir installiert wurde, wohl nicht für die Verwendung vorbereiten. Dafür gibt’s dann folgenden Befehl, der die cephadm CLI in einem eigenen Container startet.

./cephadm ceph-volume lvm zap /dev/sda

Der Befehl plättet dann die Platte /dev/sda und stellt sie als ganzes für Ceph bereit.

Fazit

Sonderlich lange läuft meine Ceph Installation noch nicht, weshalb ich noch keine Langzeiterfahrungen damit anführen kann. Bisher lässt sie sich aber gut an, um Ceph mal kennen zu lernen und auch ausreichend Platz für zuhause bereitstellen zu können. Ich bin froh, dass ich es probiert habe und werde das System wohl langsam und nach Bedarf ausbauen.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Ceph OSDs mit BlueStore erstellen

BlueStore ist das neue Speicher-Backend für Ceph ab Luminous. v12.2.x. Es wird standardmäßig verwendet, wenn neue OSDs durch ceph-disk, ceph-deploy oder ceph-volume erzeugt werden.

Es bietet einen großen Vorteil in Bezug auf Leistung, Robustheit und Funktionalität gegenüber dem bisherigen Ansatz.

Bei einer SSD erzeugt man die OSD mit BlueStore zusammen mit dem Journal (DB/WAL). Ist die Festplatte allerdings eine HDD, dann ist man gut damit beraten wenn man das Journal auf eine extra SSD packt. Für den BlueStore-Cache sollte man 1 GB für Festplatten-gestützte OSDs und 4 GB für SSD-gestützte OSDs an RAM einplanen.

Beispiel1: Festplatte ist eine SSD und wurde als sdh erkannt.

[bash]:~# ceph-deploy osd create –data /dev/sdh[/bash]

Eine andere Möglichkeit ist manuell auf dem Node selbst.

[bash]:~# ceph-volume lvm create –data /dev/sdh[/bash]

[bash]
:~# dmesg

–> ceph-volume lvm activate successful for osd ID: 10
–> ceph-volume lvm create successful for: /dev/sdh
[/bash]

 

Beispiel2: Festplatte ist eine HDD und wurde als sdh erkannt. Die SSD für das Journal wurde als sdb erkannt.

Wir erzeugen auf der SSD eine Volume Group, die wir z.B. ceph-wal nennen. Diese kann dann auch für alle weiteren Journals verwendet werden.

[bash]:~# vgcreate ceph-wal /dev/sdb[/bash]

Dann erzeugen wir eine Volume Group mit einem Logical Volume auf der HDD.

[bash]
:~# vgcreate ceph-block-h /dev/sdh
:~# lvcreate -l 100%FREE -n block-h ceph-block-h
[/bash]

Nun erzeugen wir ein Logical Volume mit einer Größe von z.B. 10GB

[bash]:~# lvcreate -L 10GB -n wal-b ceph-wal[/bash]

Nun erzeugen wir die OSD mit dem dazugehörigen WAL Device.

[bash]:~# ceph-volume lvm create –bluestore –data ceph-block-h/block-h –block.wal ceph-wal/wal-b[/bash]

[bash]
:~# dmesg

Running command: /bin/systemctl start ceph-osd@10
–> ceph-volume lvm activate successful for osd ID: 10
–> ceph-volume lvm create successful for: ceph-block-h/block-h
[/bash]

Martin Schuster
Martin Schuster
Senior Systems Engineer

Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren oder zieht einfach um und fängt von vorne an.

Storage Wars – Using Ceph since Firefly | OSDC 2019

This entry is part 5 of 6 in the series OSDC 2019 | Recap

YouTube player

 

Achim Ledermüller ist Lead Senior Systems Engineer bei NETWAYS und kennt sich aus in Sachen Storage. 2019 hat er seinen Talk “Storage Wars – Using Ceph since Firefly” auf der Open Source Data Center Conference (OSDC) in Berlin gehalten. Wer den Talk verpasst hat, bekommt nun die Möglichkeit, Achims Vortrag noch einmal zu sehen und zu lesen (siehe weiter unten).

Die OSDC wird 2020 erstmalig unter neuem Namen stackconf veranstaltet. Mit den Veränderungen in der modernen IT hat sich in den vergangenen Jahren zunehmend auch der Fokus der Konferenz verlagert: Von einem hauptsächlich auf statische Infrastrukturen zielenden Ansatz zu einem breiteren Spektrum, das agile Methoden, Continuous Integration, Container-, Hybrid- und Cloud-Lösungen umfasst. Dieser Entwicklung soll mit der Namensänderung der Konferenz Rechnung getragen und das Themenfeld für weitere Innovationen geöffnet werden.

Aufgrund der Bedenken rund am das Coronavirus (COVID-19) wurde die Entscheidung getroffen, die stackconf 2020 als Online-Konferenz stattfinden zu lassen. Das Online-Event findet nun vom 16. bis 18. Juni 2020 statt. Live dabei sein lohnt sich! Jetzt Ticket sichern unter: stackconf.eu/ticket/


Storage Wars – Using Ceph since Firefly

Wenn es um Storage geht, ist die Erwartungshaltung klar definiert. Storage muss immer verfügbar, skalierbar, redundant, katastrophensicher, schnell und vor allem billig sein. Mit dem Unified Storage Ceph kann man zumindest die meisten Erwartungen ohne Abstriche erfüllen. Durch das Prinzip, wie Ceph Daten zerlegt, speichert und repliziert, ist die Verfügbarkeit, Skalierbarkeit und Redundanz gewährleistet und auch eine katastrophensichere Spiegelung eines Clusters ist ohne Probleme möglich.

Neben den angebotenen Features ist aber auch ein reibungsloser unterbrechungsfreier Betrieb wichtig. Während des fast siebenjährigen Betriebs unseres Clusters änderten sich fast alle Komponenten. Betriebsysteme, Kernel und Init-Systeme wurden ausgewechselt. Alte Netzwerkkarten wurden durch 10GE- und 40GE-Schnittstellen abgelöst und vervierzigfachten ihren Durchsatz. Layer 2 wird wegen Routing on the Host immer unwichtiger, Festplatten sind plötzlich dank moderner SSDs und NVMe nicht mehr das Bottleneck und natürlich gab es auch immer wieder neue Versionen von Ceph selbst. Zwischen all diesen Neuerungen in den letzten Jahren ist natürlich genügend Platz für kleine und große Katastrophen. Umso wichtiger ist es, dass man von Anfang an ein paar grundlegende Dinge richtig macht:

Limitiere IO-intensive Jobs

Im normalen Betrieb laufen verschiedene Aufgaben im Hintergrund, um einen gesunden Zustand des Clusters zu garantieren. Scrubbing Jobs prüfen die Integrität aller gespeicherten Daten einmal pro Woche, Platten- und andere Hardwarefehler veranlassen Ceph, die Anzahl der Replika automatisch wieder herzustellen und auch das Löschen von Snaphosts bringt die Festplatten zum Glühen. Für jedes dieser kleinen Probleme bietet Ceph Konfigurationsmöglichkeiten, um größere Auswirkungen auf Latenzen und Durchsatz der Clients zu verhindern.

Neben dem Datenmanagement durch Ceph selbst wird das Cluster natürlich auch von vielen Clients beansprucht. In unserem Fall wollen virtuelle Maschinen aus OpenStack und OpenNebula an ihre Daten, verschiedenste WebClients wie GitLab, Nextcloud, Glance und andere senden Swift- und S3-Anfragen und ein zentrales NFS-Storage will natürlich auch Tag und Nacht bedient werden. Auch hier kann eine Begrenzung der Requests durch libvirtd, rate-limiting oder andere Mechanismen sinnvoll sein.

Kenne deine Anforderungen

Die Anforderungen der Clients an die Latenz und den Durchsatz des Storage-Systems können sehr unterschiedlich sein. Features wie Replikation und Verfügbarkeit werden mit erhöhten Latenzen erkauft. Große Festplatten mit Spindeln drücken die Kosten, allerdings sind auch nur noch wenige Benutzer und Anwendungen mit wenigen IOPs, höheren Latenzen und dem geringen Durchsatz zufrieden. Was für Archivdaten kein Problem ist, sorgt bei Datenbanken oft für unglückliche Benutzer. Schnellere Festplatten und eine geringe Latenz im Netzwerk verbessern die Situation erheblich, erhöhen aber auch die Kosten. Zudem ändern sich die Bedürfnisse der Clients auch im Laufe der Zeit. Dank Crush kann Ceph den unterschiedlichen Ansprüchen gerecht werden. Ein schneller SSD-Pool kann ohne Probleme parallel zu einem Datengrab auf langsamen großen Spindeln betrieben werden und auch eine Umschichtung der Daten ist jederzeit flexibel möglich.

Plane im Voraus

Neben eines Datenverlusts ist ein volles Cluster wohl eines der schlimmeren Szenarios. Um eine Beschädigung der Daten zu verhindern, werden bei 95% Füllstand keine weiteren Daten mehr angenommen. In den meisten Fällen macht dies den Storage unbenutzbar. Zu diesem Zeitpunkt hat man eigentlich nur zwei Möglichkeiten: Man kann versuchen, nicht mehr benötigte Daten zu entfernen, z.B. in Form von alten, nicht mehr benötigten Snapshots, oder man vergrößert den Cluster rechtzeitig. Hierbei sollte man bedenken, dass die Beschaffung und der Einbau der Hardware schnell mal 7 bis 14 Tage in Anspruch nehmen kann. Genügend Zeit zum Handeln sichert man sich durch verschiedene Thresholds, so dass der Cluster z.B. ab einem Füllstand von 80% warnt.

Ceph kann die klaren Erwartungen an ein modernes Storage-System in den meisten Fällen erfüllen. Die gegebene Flexibilität und die ständige Weiterentwicklung sichert eine einfache Anpassung an neue Anforderungen und ein sich ständig änderndes Umfeld. Somit ist mit etwas Planung, Monitoring und Liebe ❤ ein reibungsloser und stressfreies Betreiben über viele Jahre möglich.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Ceph Mimic | Using loop devices as OSD

For quite some time we have been using ceph-deploy to deploy OSD in folders during the Ceph trainings held by Netways. This worked perfectly with jewel, but newer versions don’t allow this behaviour anymore.
There are several reasons for this, however, as we have a quite regulated setup for our training notebooks, we had to come up with some kind of workaround. This approach is, while working fine in our training setup, not recommended for production!
The following steps apply to a current CentOS 7 system.
As stated before, we will deploy an OSD on a block device. Though you could use a separate partition for this, we will use a loop device. For this, the first step is to create a file:
For this, create an OSD directory
 
[bash]$ mkdir -p /home/training/my-cluster/osd-$HOSTNAME
$ cd /home/training/my-cluster/osd-$HOSTNAME/[/bash]
in this folder, create a file for later use
[bash]
$ fallocate -l 30G 30GB.img[/bash]
test it
[bash]
# losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"
# wipefs -a /dev/loop1
# lsblk
[/bash]
This should then display your new loopdevice.
As loop devices are not reboot safe, you need to go some steps further. If you like to use rc.local for this, you’re free to do so.
We’re going to create a service, which will essentially execute the prior mentioned losetup command. For this, we need a script with the command and a .service file, which will execute the script:
[bash]
rebloop.sh
#!/bin/bash
sudo losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"
[/bash]
and the service file:
[bash]
rebloop.service
[Unit]
Description=Reattach loop device after reboot
[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/rebloop.sh
[Install]
WantedBy=multi-user.target
[/bash]
These files have to be executable and be copied to the correct folders. Afterwards, the service must be enabled and can be started.
[bash]
# chmod +x rebloop.*
# cp rebloop.sh /usr/bin/rebloop.sh
# cp rebloop.service /etc/systemd/system
# systemctl enable rebloop.service
# systemctl start rebloop.service
[/bash]
Ceph, however, will still not want to create an OSD on this device, instead give you following error message:
[bash]
–> RuntimeError: Cannot use device (/dev/mapper/<name>). A vg/lv path or an existing device is needed [/bash]
You have to make changes to /usr/lib/python2.7/site-packages/ceph_volume/util/disk.py on the OSD host:
in line 201, add “or TYPE==’loop'”:
[python]# use lsblk first, fall back to using stat
TYPE = lsblk(dev).get(‘TYPE’)
if TYPE:
return TYPE == ‘disk’ or TYPE == ‘loop'[/python]
and in line 286, change the “skip_loop” switch from “True” to “False”:
[python] def get_block_devs(sys_block_path="/sys/block", skip_loop=False): [/python]
For testing purposes, simply reboot your system and verify if the loop device gets reattached correctly.
If yes, you can deploy an OSD. We’re using ceph-deploy here:
[bash]$ ceph-deploy osd create –data /dev/loop1 $HOSTNAME[/bash]
When the command was successfully executed on your hosts, you can create your first pool
[bash]# ceph osd pool create rbd 100 100 replicated[/bash]
examine ceph status
[bash]# ceph status[/bash]
tag the pool with an application
[bash]# ceph osd pool application enable rbd rbd[/bash]
As you can see, there are quite some changes to be made, and each of it is failure-prone.
Best practice is to simply use a real block device and for production you really should stick to this.
If, however, there are certain needs to be fulfilled, ceph can be convinced to comply.
 
Sources:
http://tracker.ceph.com/issues/36603
https://tracker.ceph.com/issues/23337
https://github.com/NETWAYS/ceph-training
 
 
 

Tim Albert
Tim Albert
Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Gnocchi und Archiv Policies

Gnocchi ist eine time series database die aus dem OpenStack Projekt hervorgegangen ist. Da Gnocchi erst 2014 entstanden ist, wurde versucht die Schwächen vorhandener Lösungen zu umgehen. Im Vergleich fallen mir vor allem folgenden Features auf:

  • Mandantenfähigkeit
  • Skalierbarkeit
  • Hochverfügbarkeit
  • REST Interface (HTTP)
  • Unterstützung moderner Backends wie Ceph (librbd), Swift und S3
  • OpenSource

Ein weiters Feature ist die Unterstützung von archive policies. Diese legen fest wie lange und in welcher Granularität Metriken vorgehalten werden. Zusätzlich kann auch die Art der Aggregation definiert werden. Sendet man den unten stehenden json Text per HTTP an /v1/archive_policy wird z.B. eine Policy angelegt die Metriken mit einer Granularität von 5 Minuten für 62 Tage speichert und dafür 17856 Punkte benötigt (12 Metriken je Stunde * 24 Stunden * 62 Tage = 17856). Zusätzlich werden die Metriken in aggregierter From  für 365 und 3650 Tage gespeichert.
 

{
  "name": "router-metriken",
  "back_window" : 0,
  "definition" : [
    {
      "points" : 17856,
      "granularity" : "00:05:00",
      "timespan" : "62 days, 0:00:00"
    },
    {
      "points" : 8760,
      "granularity" : "1:00:00",
      "timespan" : "365 days, 0:00:00"
    },
    {
      "points" : 3650,
      "granularity" : "24:00:00",
      "timespan" : "3650 days, 0:00:00"
    }
  ],
  "aggregation_methods" : [
    "min",
    "max",
    "mean",
    "sum"
  ]
}

 
Welche archive policy für einzelne Metriken angewendet wird kann über rules bestimmt werden. Neue Metriken werden per Regex geprüft und ggf. einer Policy zugewiesen. Treffen mehrer Regeln greift der längste Regex. Mit der folgenden Regel werden alle Metriken die mit router beginnen zu der oben definierten Policy hinzugefügt.
 

{
  "archive_policy_name": "router-metriken",
  "metric_pattern": "router.*",
  "name": "router-metriken"
}

 
Mein erster Eindruck von Gnocchi ist durchaus positiv und mit den genannten Features kann sich die OpenStack Lösung von der Konkurrenz abheben. Aktuell ist Gnocchi wohl am besten für die Bedürfnisse von OpenStack ausgelegt. Es gibt aber auch Integrationen zu collectd, statsd, Icinga und Grafana.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.