Seite wählen

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.

Monthly Snap February 2020

Start with a laugh!

In the beginning of the month Nicole asked some of us what we found the most annoying aspect of working in an office. Not at all surprising was the most common answer: the printers! Yes, sometimes they seemingly do as they please! Read Nicole`s humorous blog on aggression at work! [Eine nicht ganz ernste] Betrachtung von Aggression am Arbeitsplatz.

 

Christians news

What`s new in Graylog`s latest release? Christian filled us in in Graylog 3.2 – Jetzt verfügbar. What else was Christian up to? Well, as a matter of fact, he developed Icinga Monitoring for Windows! Read all about it in Icinga for Windows 1.0 – Eine neue Ära.

 

The Shops` corner

Isabel let us know that STARFACE has expanded their product-range for smaller companies in STARFACE erweitert den Compact Bereich. Why is this SMSEagle so popular? Nicole gave us several reasons in Wieder verfügbar! SMSEagle MHD-8100 – 8 Modems für parallelen SMS Versand. She also gave us loads of information about the SMSEagle, including a video of the unboxing! Unboxing a Beauty – SMSEagle MHD-8100.

 

Techie tipps…

Dirk attended the Configmgmt Camp for the fifth time in a row. What was new in Gent this year? Config Management Camp Ghent 2020 – Recap. Thilo shared some insider tricks in Ansible – should I use omit filter? Blerim gave us tips on photo sizes and meta tags for social media in Quick Tip: Vorschaubilder in sozialen Medien.

 

Upcoming events

Julia shared some news in Deploy Peanutbutter:Jelly or: First stackconf speakers online! And Julia also let us in on why it is perfect to Sponsor stackconf 2020.  Join us in Amsterdam in June! But first: listen to Julia and Get your Early Bird Tickets for IcingaConf! And then listen to her some more: The call for papers for the OSCamp on Bareos is still open! OSCamp on Bareos: Let’s talk about backups!

#lifeatnetways

NETWAYS goes Business Cup 2020! Niko is looking forward to taking part with the NETWAYS-team and informs about this and other sports- events we will attend this year! Read about Aleksander in our blog-series NETWAYS stellt sich vor, where new members of the NETWAYS-family share a bit about themselves. How much can a company do for the environment? A group of colleagues worked on the subject and Catharina concluded with Umweltschutz a la NETWAYS.

 

Exclusion of NPD and AfD supporters from our events

The most important blog of the month was written by our very own CEO Bernd. He has changed our code of conduct to puplicly announce that we do not tolerate racism and that therefore no members or sympathizers of the AFD or NPD are welcome to any of our events. He informed the NETWAYS team in our annual meeting, and immediately got a roaring applause

Catharina Celikel
Catharina Celikel
Office Manager

Catharina unterstützt seit März 2016 unsere Abteilung Finance & Administration. Die gebürtige Norwegerin ist Fremdsprachenkorrespondentin für Englisch. Als Office Manager kümmert sie sich deshalb nicht nur um das Tagesgeschäft sondern übernimmt nebenbei zusätzlich einen Großteil der Übersetzungen. Privat ist der bekennende Bücherwurm am liebsten mit dem Fahrrad unterwegs.

OSCamp on Bareos: Let’s talk about backups!

Heterogeneous server landscapes are more the rule than the exception in many companies today. The technical requirements for software systems for data backup, archiving and recovery are increasing accordingly. What are the challenges coming with these changes? Let’s talk about it!

Let’s talk about backups at OSCamp!

CFP until end of march

The Call for Papers for the Open Source Camp (OSCamp) on Bareos is still open. Until March 31, 2020 you got the chance to submit your paper. Ideally you give a comprehensive technical insight into Bareos and offer administrators new impulses for data backup, archiving and recovery. Each presentation is scheduled for 45 minutes, including a 5 to 10-minute Q&A session. All software presented must be freely available for download and therefore meet open source standards such as GPL.

OSCamp – the series

The OSCamp on Bareos is where the community, users and developers meet – it’s an opportunity to talk to like-minded people and share expertise – as a speaker on stage, or as attendee during discussions and breaks.

Open Source Camp is a conference format dedicated to different Open Source projects and products and of course their communities. Get in touch with the Open Source enthusiasts behind the presented project. Learn new features and techniques, benefit from their extensive know-how and get up-dated on the latest developments. Backup your seat!

Join stackconf too

OSCamp #5 on Bareos takes place directly after stackconf, on June 19, 2020 in Berlin. Conference and camp venue is the same. More about stackconf at stackconf.eu! This is your chance to join two outstanding Open Source events in one week!

More info and tickets at opensourcecamp.de.