pixel
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
Lead Systems Engineer

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

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

If used in complex or heterogene environments it is necessary to test the code to reduce time to fix code in production. To test Ansible code it is suggested to use Molecule.

Molecule is a useful tool to run automated tests on Ansible roles or collections. It helps with unit tests to ensure properly working code on different systems. Whether using the role internally or provide it to the public, it is useful to test many cases your role can be used. In addition Molecule is easily integrated into known CI/CD tools, like Github Actions or Gitlab CI/CD.

In this short introduction I’ll try get your first Molecule tests configured and running!

Please make sure you installed Molecule beforehand. On most distributions it’s easily installed via PIP.
The fastest and most common way to test roles would be in container. Due to a version problem with systemd currently it’s not possible to start services over systemd in containers. For this reason you can easily start with a vagrant instance and later migrate to docker or podman easily.


pip install molecule molecule-vagrant

If you have a role you can change into the role directory and create a default scenario.


cd ~/Documents/netways/git/thilo.my_config/
molecule init scenario -r thilo.my_config default
INFO     Initializing new scenario default...
INFO     Initialized scenario in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default successfully.

Below the molecule folder all scenarios are listed. Edit the default/molecule.yml to add the vagrant options.

Add a dependency file with your collections as with newer Ansible versions only the core is available. If needed you can add sudo privileges to your tests.

molecule/default/molecule.yml


---
dependency:
  name: galaxy
  options:
    requirements-file: collections.yml
driver:
  name: vagrant
platforms:
  - name: instance
    box: bento/centos-7
provisioner:
  name: ansible
verifier:
  name: testinfra
  options:
    sudo: true

The converge.yml is basically the playbook to run on your instance. In the playbook you define which variables should be used or if some pre-tasks should be run.

molecule/default/converge.yml


---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include thilo.my_config"
      include_role:
        name: "thilo.my_config"

Now you can run your playbook with molecule. If you want to deploy and not delete your instance use converge. Otherwise you can use test, then the instance will be created, tested and destroyed afterwards.


python3 -m molecule converge -s default
or 
python3 -m molecule test -s default

Finally we can define some tests, the right tool is testinfra. Testinfra provides different modules to gather informations and check them if they have specific attributes.

Your scenario creates a tests folder with the following file: molecule/default/tests/test_default.py

In this example I’ll test the resources my role should create.


"""Role testing files using testinfra."""


def test_user(host):
    """Validate created user"""
    u = host.user("thilo")

    assert u.exists

def test_authorized_keys(host):
    """Validate pub key deployment"""
    f = host.file("/home/thilo/.ssh/authorized_keys")

    assert f.exists
    assert f.content_string == "ssh-rsa AAAA[...] \n"

And if we already converged our instance, we can verify these definitions against our deployment.


python3 -m molecule verify
INFO     default scenario test matrix: verify
INFO     Performing prerun with role_name_check=0...
[...]
INFO     Running default > verify
INFO     Executing Testinfra tests found in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default/tests/...
============================= test session starts ==============================
platform darwin -- Python 3.9.12, pytest-6.2.5, py-1.11.0, pluggy-0.13.1
rootdir: /
plugins: testinfra-6.4.0
collected 2 items

molecule/default/tests/test_default.py ..                                [100%]

============================== 2 passed in 1.79s ===============================
INFO     Verifier completed successfully.

With those easy steps you can easily test your roles for any scenario and your deployments can run without any hassle or at least you will be more relaxed during it 😉

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Kibana: Frontend des Elastic Stacks

Was nutzt das beste Log Management, wenn man sich das Ganze nicht auch ansehen kann? Für den Elastic Stack kann man hier auf Kibana setzen – ein mächtiges Tool, das neben höchster Funktionalität auch noch sehr schick aussieht.

Kibana – was ist das? Die wichtigsten Fakten!

  • Benutzeroberfläche: offen und kostenlos
  • Visualisierung der Elasticsearch-Daten mit folgenden Anzeigeoptionen:
    • Histogramme
    • Liniendiagramme
    • Kreisdiagramme
    • Ringdiagramme und vieles mehr
  • Elastic Maps bietet die Möglichkeit, Topographien und Ebenen zu erstellen – perfekt geeignet für Eure Standortanalysen!
  • Darstellung mithilfe von Graphen und Netzwerken erlaubt das Aufzeigen von bisher unerkannten Zusammenhängen
  • Navigieren im Elastic Stack
  • Suchfunktion und Filter über alle Dokumente hinweg – Abfragen, Transformationen und Visualisierungen werden durch unkomplizierte Ausdrücke erstellt
  • Analyse Eurer Daten anhand von Zeitreihen
  • Erkennen von Anomalien: durch ein selbstständiges Machine Learning kann analysiert werden, wodurch Anomalien auftreten und beeinflusst werden
  • Alarmierung im Falle des Falles! Stellt selbst Eure Schwellenwerte ein, egal ob index- oder metrikbasiert und lasst Euch benachrichtigen über:
  • Alle Alarmierungen können auch als Verlauf angezeigt werden!

Oder wie Elastic es so schön nennt: “Das Fenster in den Elastic Stack.”

Hier noch ein Screenshot, damit man sich auch ein Bild von den Möglichkeiten machen kann:

Quelle: https://www.elastic.co/de/kibana/

Wir haben Euer Interesse an Kibana und dem Elastic Stack geweckt? Ihr wollt vielleicht wissen, ob die Tools als Lösung für Eure Use Cases in Frage kommen? Dann kommt einfach auf uns zu! Wir sind erreichbar unter sales@netways.de oder über unser Kontaktformular.

Auch könnt Ihr über unsere Website direkt Schulungen buchen für Elastic, aber auch für viele andere Produkte wie Graylog oder Icinga 2. Solltet Ihr Euch unsicher sein oder weitere Infos benötigen, dann kontaktiert einfach unsere Kollegen über events@netways.de.

Wer kurzfristig etwas lernen möchte, dem empfehle ich unsere Webinare. Hier findet hier auf unserer Website die bereits gehaltenen Webinare sowie Ankündigungen für neue. Insbesondere haben wir kürzlich Webinare zum Thema Elastic hinzugefügt.

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist:
Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten Daten von einem System sammelt und als ZIP verpackt. Das ZIP kann in Support Fällen an uns geschickt werden, damit wir uns einen Überblick über das System machen können.

Letzte Woche konnte mit Verzögerungen die Version 0.7.0 veröffentlich werden, welche nun auch Daten über die IcingaDB und Redis sammelt. Von Versionen bis hin zur Konfiguration und Service Status wird alles mit gesammelt.

Im Rahmen dieses Blogposts möchte ich euch einen kleinen Ausblick geben, welche möglichen Erweiterungen wir mit dem Support Collector noch abbilden möchten.

Systemweiter Datensammler

Zum aktuellen Stand sammelt der Support Collector Daten ein, speichert sie in eine Datei und verpackt dass alles zu einem großem ZIP. Das ganze passiert aber nur auf dem System auf welchen das Tool ausgeführt wird. Jetzt stehen wir natürlich vor dem “Problem” dass Icinga 2 Umgebungen über mehrere Systeme verteilt sein können. So kann es sein dass einfach nur die Datenbank auf einem anderen Host läuft oder dass sich irgendwo noch ein zweiter Master bzw. Satelliten befindet. Aus Sicht des Supports wäre es natürlich schön auch diese Daten mit abzufragen.
Die Umsetzung des eben beschriebenen Vorhabens ist noch nicht ganz klar, da es hier neben vielen Kleinigkeiten vor allem die Security zu beachten gilt. Da wir uns auch vorstellen können, dass nicht ein jeder es gut findet, wenn wir komplette Systeme scannen, wird diese Funktion auch nur optional. Unser Augenmerk liegt darauf, dass der Benutzer frei entscheiden kann, was er gesammelt haben möchte.

Statistiken

Mit den gesammelten Daten lassen Sich natürlich auch aussagekräftige Statistiken erstellen. Anhand von diesen Daten könnten wir von den einfachsten Statistiken wie “Welche Versionen werden wie oft genutzt”, bis hin zu komplexen Themen wie “Durchschnittliche Größe eines Systems” oder “Welche Hardware Specs für welche Icinga 2 Größe” erstellen. Allerdings ist auch hier noch nicht zu eindeutig wie die Umsetzung aussehen soll, da hier ebenfalls die Security und Anonymität eine große und wichtige Rolle spielen.

Mit den zwei Punkten welche ich hier angesprochen habe, konnte ich euch nur einen kleinen Einblick gegeben, was an Feature Ideen noch in Planung sind. Sollte euch etwas einfallen, was aus eurer Sicht sinnvoll wäre umzusetzen, könnt ihr gerne ein Feature Request im Git Repository eröffnen.

Tobias Bauriedel
Tobias Bauriedel
Systems Engineer

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.

Elasticsearch: Herzstück des Elastic Stack

Nachdem wir uns im letzten Blogpost den Elastic Stack im Allgemeinen angesehen haben, wollen wir uns heute auf den Teil Elasticsearch konzentrieren. Gerade zum Thema Elasticsearch gibt es aufgrund der Mächtigkeit des Tools eine Vielzahl an Fakten und Features.

Wie im Titel schon erwähnt, ist Elasticsearch das Herzstück des Elastic Stack. Elasticsearch ist eine Such- und Analytics-Engine, die als Kernaufgabe die Speicherung der (Log-)Daten übernimmt. Im Vordergrund stehen hier die hohe Performanz, die Relevanz von Daten kann granular geregelt werden und ein Elasticsearch Cluster kann problemlos skaliert werden.

 

Features von Elasticsearch

  • Suchanfragen sind kombinierbar – egal, ob strukturiert oder unstrukturiert. Suchparameter können selbst gesetzt werden, als Beispiel Metriken oder Geodaten. Hier kann aber indviduell angepasst werden.
  • Volltextsuche und Verstehen von Tippfehlern
  • Ranking von Suchergebnissen – nach individueller Definition können Suchergebnisse sortiert werden, z. B. nach Datum, Beliebtheit, Häufigkeit des Auftretens von Begriffen. Die Einstellungen für diese Rankings können auch per Funktion definiert werden.
  • Analysieren von Milliarden von Logfiles – mit Hilfe von Aggregationen kann mehr als nur eine Facette dargestellt werden. Die Analyse ermöglich das Erkennen von Zusammenhängen, Mustern und Trends sowie einen regelmäßigen Überblick.
  • Hohe Performance – jedes Log File wird mit einem Index versehen. Daten werden automatisch auf den Nodes verteilt, um ein perfektes Balancing zu erreichen.
  • Skalierbarkeit – vom One-Node-Setup im Testumfeld hin zur Produktivumgebung. Hier muss nichts neu aufgesetzt werden, sondern es wird skaliert durch das Hinzufügen von Nodes. Konfigurationen werden im Cluster automatisch verteilt. (Elastic empfiehlt für Produktivumgebungen mindestens drei Nodes)
  • Cluster-übergereifende Replikation – hier wird in einer verteilten Umgebung gearbeitet, so dass der Cluster und die darin enthaltenen Daten auch bei Hardware- oder Netzwerkausfall verfügbar sind. Auch kann jederzeit ein Hot Backup einspringen.
  • Elasticsearch Node weg? Der Cluster erkennt dies und erstetzt den verschwundenen Knoten mit einer Replika.

 

Ein sehr interessanter Aspekt ist auch, dass das Alternativprodukt Graylog auch auf Elasticsearch aufbaut. Das heißt, wer sich mit Elasticsearch auskennt, kann gleich zweimal punkten! Woher Ihr das Wissen bekommt? Natürlich von uns!

Über unsere Website könnt Ihr direkt Schulungen buchen für Elastic, aber auch für viele andere Produkte wie Graylog oder Icinga 2. Solltet Ihr Euch unsicher sein oder weitere Infos benötigen, dann kontaktiert einfach unsere Kollegen über events@netways.de.

Wer kurzfristig was lernen möchte, dem empfehle ich unsere Webinare. Hier findet hier auf unserer Website die bereits gehaltenen Webinare sowie Ankündigungen für neue. Insbesondere haben wir kürzlich Webinare zum Thema Elastic hinzugefügt.

Wir haben Euer Interesse an Elasticsearch und dem Elastic Stack geweckt? Ihr wollt vielleicht wissen, ob die Tools als Lösung für Eure Use Cases in Frage kommen? Dann kommt einfach auf uns zu! Wir sind erreichbar unter sales@netways.de oder über unser Kontaktformular.

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.