© hxdyl / 123RF.com

Betreiber einer OpenStack-Umgebung sollten erkennen, ob sie funktioniert, und Probleme schnell lokalisieren können. Wir bieten einen Überblick zu den Grundlagen der OpenStack-Überwachung im Sovereign Cloud Stack.

Das Projekt Sovereign Cloud Stack (SCS) der Open Source Business Alliance (OSBA) wurde 2019 ins Leben gerufen, um föderierbare Cloud-Umgebungen zu ermöglichen. In enger Zusammenarbeit zwischen Community und dem SCS-Team der OSBA stellt das Projekt in agiler Arbeitsweise die entsprechenden Standards und auch eine Referenzimplementierung bereit. SCS [1] ist somit eine offene, föderierbare und modulare Cloud- und Container-Plattform auf Basis von Open-Source-Software. Sie baut in der Referenzimplementierung auf bewährte Open-Source-Komponenten wie OpenStack und Kubernetes auf (Abbildung 1). Als Plattform bietet SCS die Basis, um Angebote zu erstellen, die volle digitale Souveränität bieten.

Abbildung 1: Visualisierung der Zusammenhänge der Komponenten des Sovereign Cloud Stack.

SCS-Community

Die Community besteht aus verschiedensten Cloud-Service-Providern (CSPs) und deren Mitarbeitern, Personen aus der OpenStack-Community und Firmen, die an den Vergabepaketen arbeiten. Pakete werden über Ausschreibungen an Firmen vergeben, die sich auf diese Pakete bewerben können.

Durch die Zusammenarbeit der verschiedenen Provider entsteht ein Level an Kooperation, das es sonst selten gibt. Gemeinsam arbeiten verschiedene Teams und Special Interest Groups (SIGs) an den Themen, wobei sie Standards und Anforderungen inhaltlich aufeinander abstimmen. Oberstes Ziel von SCS ist es, in den jeweiligen Upstream-Projekten aktiv zu sein, sich inhaltlich dort einzubringen und keine Parallelwelt entstehen zu lassen.

Dabei hat sich als erste solche Gruppe aus dem Team Operations & Identity and Access Management heraus die SIG Monitoring gebildet, die sich in wöchentlichem Rhythmus dem Themenkomplex Monitoring und Observability widmet.

Observability

Observability beschreibt hierbei nicht nur die reine Zustandsanalyse, also die Information, ob ein Dienstmerkmal zur Verfügung steht. Zum Monitoring, wie es heutzutage Standard ist, gehören ebenso das Einsammeln, Speichern und Visualisieren von Metriken sowie das Aggregieren von Log-Nachrichten. Das Gesamtsystem versetzt den Operator in die Lage, sich schnell ein umfassendes Bild seiner Anlage zu machen, um Probleme sowie deren Quellen und Ursachen schnell zu lokalisieren.

Im Umfeld der CSPs besteht zusätzlich die Anforderungen, anfallende Daten nach entsprechenden Vorgaben zu löschen. Hinzu kommt aus Gründen der Compliance die Notwendigkeit, bestimmte Systemnachrichten zu protokollieren oder aus den anfallenden Metriken Abrechnungsdaten zu generieren.

Architekturgedanken

Als die SIG vor einem Jahr startete, sammelte sie zunächst die Anforderungen der beteiligten CSPs und stellte sie dem gegenüber, was in der Referenzimplementierung bereits einzelne Komponenten abdeckten.

Um zu vermeiden, sich schon anfangs in reine Tool-Diskussion zu verlieren – und gerade über Werkzeuge lässt sich trefflich diskutieren – wurde in einem ersten Schritt Werkzeug-agnostisch auf die Architektur gesehen. Abbildung 2 zeigt die avisierte Architektur. Zu Beginn wurden die verschiedenen Rollen definiert. Der Anlagenbetreiber (etwa der CSP) ist der SCS Operator, während man als SCS Integrator Firmen bezeichnet, die den Operator gegebenenfalls beim Aufbau und der Inbetriebnahme der Anlage unterstützen.

Abbildung 2: Das Werkzeug-agnostische Architekturdiagramm des SCS.

Aus mehreren Gründen hat man bewusst die Container-Layer im ersten Schritt aus der Betrachtung genommen und stattdessen auf die Infrastructure-as-a-Service-Schicht (IaaS) fokussiert. Zum einen reduzierte das die Komplexität und die Anzahl der Entscheidungen. Des Weiteren ist die Betrachtung der Observability Bestandteil eines Vergabepakets, das erst für 2022 eingeplant war. Auf der IaaS-Ebene steht OpenStack mit seinen diversen Komponenten im Fokus (Abbildung 3).

Abbildung 3: Die IaaS-Monitoring-Komponenten des SCS.

Komponenten und Werkzeuge

SCS setzt auf den Open Source Infrastructure and Service Manager (OSISM [2]) als Werkzeug für das Deployment und Day-2-Operations für OpenStack auf. OSISM selbst baut stark auf Kolla-Ansible [3] auf, wie OpenStack-Ansible eine Sammlung von Ansible-Playbooks für das Deployment von OpenStack. Einer der Schwerpunkte von OSISM ist es, den Betrieb von OpenStack-basierten Anlagen und insbesondere auch die Upgrades von einer OpenStack-Version zur nächsten zu vereinfachen. Ziel ist es, jederzeit Updates auf eine Anlage spielen zu können.

Kolla-Ansible bringt von Haus aus einen auf Prometheus [4] basierenden Monitoring Stack mit. Das deckte sich sehr gut damit, dass in der SIG Monitoring von Anfang an ein OpenMetrics-basierter Ansatz favorisiert wurde. Initial gab es die Überlegung, für Zustandsüberwachungen von Diensten eine traditionelle Monitoring-Software wie etwa Zabbix oder Icinga einzusetzen. Relativ schnell wurde in den Diskussionen jedoch klar, dass sich diese Szenarien ebenso gut durch den Blackbox-Exporter von Prometheus abdecken lassen. Somit ist es im Sinn einer Komplexitätsreduktion sinnvoll, auf den Blackbox-Exporter statt auf eine komplette weitere Softwarelösung zu setzen. Diese Änderungen flossen entsprechend in OSISM ein, das bisher darin enthaltene Zabbix entfiel.

In einem ersten Schritt wurden weitere Dashboards für das mitgelieferte Grafana (Abbildung 4) bereitgestellt und in das Kolla-Ansible-Projekt integriert. Zudem gibt es verschiedene Exporter für Prometheus, die aktuell noch nicht aus Kolla-Ansible herausfallen, jedoch mitgeliefert werden sollen.

Abbildung 4: Das Grafana-Dashboard des OpenStack Health Monitor.

Alerting

Eine wichtige Komponente in jedem Monitoring-Setup stellt eine entsprechende Alarmierung dar. Schnell war in der SIG Monitoring klar, dass eigentlich jeder CSP, der nicht gerade erst anfängt, eine entsprechende Umgebung in Betrieb zu nehmen, bereits ein Alarmierungssystem in Betrieb hat. Idealerweise dockt das mit SCS gelieferte Monitoring daran an.

Daher wurde entschieden, auf den bereits in Kolla-Ansible integrierten Alert-Manager von Prometheus zu setzen und entsprechende Best Practices [5] zur Anbindung an externe Alarmierungssysteme zu dokumentieren. Eine Alternative zur Aggregation von auftretenden Alarmierungen bietet an dieser Stelle die Open Source Software Alerta [6]. Zunächst kam die Überlegung auf, sie direkt zu integrieren; fürs Erste wurde jedoch der Alert-Manager als ausreichend erachtet.

Ein wichtiger Bestandteil des Prometheus-Monitoring sind die passenden Alert Rules. Um hier einen guten Startpunkt zu schaffen, wurden verschiedene Regelsätze aus dem Projekt Awesome Alert Rules [7] übernommen, die jetzt auch ihren Weg nach Kolla-Ansible finden.

Monitoring ist nicht gleich Monitoring

Spricht man von Monitoring, fängt das bei einer simplen Prozessüberwachung an: Gibt es den Prozess Foo, und antwortet der Service Bar auf Port 42? Häufig bietet es sich an, statt einer einfachen Überprüfung, ob ein Dienst auf einem Port reagiert, Testszenarien zu verwenden, die eine tatsächliche Funktionsüberprüfung des Diensts vornehmen.

In einer Umgebung wie OpenStack beispielsweise ist es zwar hilfreich zu wissen, ob das Webfrontend Horizon korrekt an den Browser ausgeliefert wird, oder mittels einer API zu prüfen, ob VMs gestartet werden können. Eine Komponente im Netzwerkbereich wie etwa Open Virtual Network (OVN) auf korrekte Funktionalität zu überprüfen gestaltet sich allerdings schnell komplex.

Um OVN effizient zu überwachen, arbeitet die SIG aktuell an der Upstream-Integration des OVN Exporter [8]. Er stellt diverse Metriken des Open Virtual Network für Prometheus bereit. Die Abbildung 5 verdeutlicht, an welchen Stellen der Exporter platziert werden muss, um die Daten der redundanten Komponenten zu erfassen und so entsprechende Ausfälle zu erkennen.

Abbildung 5: Der Aufbau des Open Virtual Network mit den Prometheus-Exportern.

Vom Health Monitor zu CloudMon

Eine wichtige Komponente für das SCS-Projekt ist der OpenStack Health Monitor. Das Programm bildet über die OpenStack-API verschiedene Szenarien programmatisch ab, um die Funktionsfähigkeit einer OpenStack-Cloud aus Kundensicht zu beurteilen.

Der OpenStack Health Monitor installiert in regelmäßigen Intervallen virtuelle Maschinen, erstellt Load Balancer und prüft die Erreichbarkeit dieser Komponenten. Dabei protokolliert er auch die Laufzeiten, sodass sich Veränderungen wie ein verzögertes Bereitstellen virtueller Maschinen nachvollziehen lassen. Das ist insbesondere bei Veränderungen an der Systemumgebung hilfreich, etwa nach einer Aktualisierung der OpenStack-Komponenten, um Probleme schnell zu identifizieren – idealerweise noch bevor die Endkunden diese feststellen.

Seinen Ursprung hatte der OpenStack Health Monitor vor mehr als vier Jahren bei der Open Telekom Cloud (OTC). Dort wurde das Projekt seinerzeit von Kurt Garloff ins Leben gerufen, dem jetzigen technischen Leiter des SCS-Projekts. Die Kollegen von der OTC haben den OpenStack Health Monitor seitdem für ihre Umgebung weiterentwickelt und das resultierende Projekt APImon auf dem OpenInfra Summit 2020 vorgestellt [9].

Im Zug des OpenInfra Summit 2022 trafen sich die Entwickler von APImon mit Mitgliedern der SCS-Community, um zu überlegen, wie man gemeinsam an der nächsten Iteration arbeiten kann. Das Nachfolgeprojekt CloudMon soll dann als eigenständiges Projekt entwickelt und gepflegt werden und als Referenz für Behaviour-driven Monitoring dienen.

Ausblick

Einer der nächsten Schwerpunkte der Arbeit in der SIG Monitoring wird auf dem Ausbau des Log-Managements liegen. Kolla-Ansible stellt aktuell für das Log Shipping ein Fluentd samt ElasticSearch bereit. Insbesondere in Bezug auf Compliance-Anforderungen im CSP-Umfeld – Stichwort: Audit Logging – bringt eine installierte SCS-Umgebung idealerweise bereits entsprechende Grundlagen mit. Sie sollte den SCS-Operatoren Best Practices für das Aggregieren von relevanten Log-Nachrichten anbieten, etwa betreffs Anmeldeversuchen, die durch Keycloak bearbeitet wurden.

Mittels des OSISM Testbed [10] lässt sich die Referenzimplementation des Sovereign Cloud Stack einfach ausprobieren und bietet auch einen guten Einstieg in das Projekt. Alle Meetings rund um SCS können Sie auf der Webseite des Projekts unter Zum SCS beitragen einsehen  [11]. Derzeit sucht SCS nach Entwicklern, die der Community beitreten wollen.