Ein Schwank aus dem Maschinenraum

OpenStack Magnum – Container Orchestration

Container und darauf aufbauende Microservices, also Dienste, die verteilt auf verschiedene Server in Containern laufen und von einer Container Orchestration Engine verwaltet werden, sind heutzutage genauso wenig aus der Informationstechnik wegzudenken wie die Cloud.

Container-Orchestrierung mit Magnum

OpenStack Magnum verbindet diese beiden Konzepte miteinander, indem es Container-Orchestrierung auf OpenStack verfügbar macht. Dabei werden beim Aufbau eines Clusters Virtuelle Maschinen oder Baremetal-Server sowie Netzwerkressourcen erstellt und auf diesen eine Container Orchestration Engine wie zum Beispiel Kubernetes installiert.

Magnum bietet also zum Beispiel die Möglichkeit, einen Kubernetes-Cluster auf OpenStack-VMs bequem zu betreiben und zu verwalten.

Aufbau von Magnum

Magnum verwendet sogenannte Cluster-Treiber, um Cluster zu erstellen und zu verwalten. Ein Cluster-Treiber ist dabei jeweils für eine Kombination aus Basis-Image, COE und Servertyp zuständig. Es kann zum Beispiel einen Cluster-Treiber für Docker Swarm auf Fedora Atomic auf virtuellen Maschinen geben und einen anderen Cluster-Treiber für Kubernetes auf Fedora auf Baremetal-Servern.

Ein Cluster-Treiber besteht aus Python-Code, Heat Orchestration Templates und Shellskripten. Der Kern sind hierbei die HOTs, welche beschreiben, welche OpenStack-Ressourcen für einen Cluster erstellt werden und welche Shell-Skripte auf welchem Node in welcher Reihenfolge ausgeführt werden.

Viele der benötigten Parameter werden nicht erst beim Erstellen jedes Clusters angegeben, sondern in sogenannten Cluster-Templates gespeichert. Man erstellt also Cluster-Templates als Vorlagen, um später mit wenigen zusätzlichen Parametern die eigentlichen Cluster zu erstellen.

Weitere Informationen

OpenStack Wiki:
https://wiki.openstack.org/wiki/Magnum

OpenStack Git:
https://git.openstack.org/cgit/openstack/magnum

Dokumentation:
https://docs.openstack.org/magnum/latest/

IRC-Channel:
#openstack-containers auf freenode.org

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

Role Based Access Control in OpenStack – Berechtigungen einschränken

OpenStack verwendet eine auf Policies aufbauende Rollenbasierte Zugriffskontrolle, wie ich im Artikel Role Based Access Control in OpenStack – Einführung näher beschrieben habe.

Rollen mit gegenüber normalen Nutzern eingeschränkten Berechtigungen umzusetzen, erfordert in OpenStack besonderes Fingerspitzengefühl. Obwohl es für normale Nutzer gewöhnlich die Rolle _member_ oder Member gibt, sind die meisten Policy-Rules nicht an diese Rollen gebunden, sondern allgemein gehalten, sodass sie für jeden angemeldeten Nutzer erfüllt sind. In der Glance-Policy gibt es zum Beispiel viele Regeln wie die folgende:

Diese Regel erlaubt es jedem Nutzer, in seinem Projekt Images hochzuladen, unabhängig davon welche Rolle er in diesem Projekt hat. Möchte man nun zum Beispiel eine Rolle erstellen, die explizit nur lesend auf Ressourcen zugreifen darf, muss man für alle schreibenden Berechtigungen definieren, dass diese nicht gewährt werden.

Als weitere Schwierigkeit kommt hinzu, dass nicht nur die Policy für eine OpenStack-Komponente angepasst werden muss, sondern für alle Komponenten, in denen die Rolle weniger als die Berechtigungen eines normalen Projekt-Members gewähren soll.

Will man eigene Rollen in OpenStack einbauen, sollte man sich also immer zuerst überlegen, was ein normaler Nutzer darf und an welchen Stellen die eigene Rolle explizit davon abweichen soll.

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

Role Based Access Control in OpenStack – Einführung

OpenStack RBAC

OpenStack verwendet Role Based Access Control (RBAC) als Autorisierungsmodell. Das bedeutet, dass Berechtigungen nicht direkt für einzelne Benutzer oder Gruppen von Benutzern gewährt werden. Berechtigungen werden stattdessen über einen Satz von Regeln (Rules) Rollen zugeordnet, die dann wiederum Nutzern oder Gruppen von Nutzern zugeordnet werden.

Hat ein Nutzer beispielsweise in seinem Projekt die Member-Rolle, sind damit im Hintergrund diverse Berechtigungen verknüpft, wie für das Hochladen von Images oder Starten virtueller Maschinen. Obwohl Rollen gewöhnlich bezüglich eines Projekts oder einer Domain vergeben werden, sind einige der Berechtigungen – insbesondere für Admins – global gültig.

policy.json

Der Regelsatz, mit dem einer Rolle Berechtigungen zugewiesen werden, wird Policy genannt. Standardmäßig sind diese Policies für jede Komponente in einer JSON-Datei hinterlegt, die policy.json heißt. Der Trend geht jedoch in OpenStack dahin, die Standarpolicy im Quelltext statt einer policy.json auszuliefern.

Es gibt zwei Arten von Regeln in einer policy.json-Datei: Regeln, die direkt einem API-Call entsprechen, und Regeln, die aus Übersichtsgründen definiert werden, um sie innerhalb der policy.json wiederzuverwenden.

Beispiele

Die folgenden Zeilen sind aus einer policy.json von Keystone.

In der ersten Zeile wird eine Regeln admin_required definiert, die erfüllt ist, wenn der Nutzer die Rolle admin hat.

Die nächste Zeile erlaubt jedem, der die Regel admin_required erfüllt, list_services-API-Calls auszuführen. Mit dem OpenStackClient würde das dem Kommando openstack service list entsprechen.

Es lassen sich ebenfalls Regeln definieren, die immer erfüllt sind. Die meisten Komponenten haben weitere Prüfungen im Quelltext eingebaut, die Zugriffe nur Admins und Usern erlauben, die im richtigen Projekt eingeloggt sind.

Außer der Rolle, die ein User innehat, können viele andere Werte abgefragt und zur Definition von Regeln verwendet werden. Zum Beispiel kann überprüft werden, ob die Domain der angefragten Ressource der Domain des Users entspricht.

 

Weitere Informationen

Weitere Informationen zu OpenStack Policies finden sich in der offiziellen Dokumentation:
https://docs.openstack.org/security-guide/identity/policies.html
https://docs.openstack.org/oslo.policy/latest/index.html

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

OpenStack Freezer – Backup und Restore

Backups sind ein integraler Bestandteil jeder IT-Strategie. In einer komplexen Infrastruktur wie OpenStack ist es nicht immer leicht den Überblick über zu sichernde Komponenten zu behalten. Sollte wirklich einmal ein größerer Ausfall eintreten, ist es wichtig, Daten schnell und möglichst ohne Verluste wiederherstellen zu können.

Backup und Restore mit Freezer

OpenStack bietet für die Durchführung von Backups und Restores die Komponente Freezer an. Mit Freezer können sowohl Datenbanken, einzelne Verzeichnisse als auch OpenStack-Ressourcen wie virtuelle Maschinen oder Volumes gesichert und wiederhergestellt werden.

Als Backup-Ziel stehen zurzeit lokale Ordner (und damit auch über NFS eingehängte Verzeichnisse), ein entfernter Host über SSH, sowie Storage, der über eine Swift-API oder S3-API erreichbar ist, zur Verfügung. Dabei können verschiedene Backup-Ziele beliebig kombiniert werden. Es ist zum Beispiel möglich, Backups lokal zu speichern und gleichzeitig in Swift hochzuladen.

Aufbau von Freezer

Kern von Freezer ist freezer-agent, ein Dienst um die eigentlichen Backups und das Wiederherstellen der Backups durchzuführen. Der Dienst ist auf den einzelnen Nodes der Control Plane installiert und kann auch manuell als Kommandozeilentool verwendet werden.

Die API von Freezer dient dazu, sogenannte Jobs zu spezifizieren. In diesen Jobs, die im JSON-Format übergeben werden, werden verschiedene Aktionen definiert und wann und wie oft sie ausgeführt werden sollen. Dabei können verschiedene Backup-Aktionen – auch auf unterschiedlichen Nodes – parallel ausgeführt werden, um möglichst konsistente Daten zu erhalten.

Diese Jobdefinitionen fragt der Dienst freezer-scheduler von der API ab und startet den freezer-agent mit entsprechenden Parametern, um die Aktionen durchzuführen.

Daneben gibt es das Plugin freezer-web-ui für das OpenStack Dashboard Horizon.

Momentan wird noch an dem unabhängigen Service freezer-dr gearbeitet, der für Disaster Recovery bei Ausfall eines oder mehrerer Compute-Nodes zuständig ist.

Weitere Informationen

OpenStack Wiki:
https://wiki.openstack.org/wiki/Freezer

OpenStack Git:
https://git.openstack.org/cgit/openstack/freezer/
https://git.openstack.org/cgit/openstack/freezer-api/
https://git.openstack.org/cgit/openstack/freezer-dr/
https://git.openstack.org/cgit/openstack/freezer-web-ui/

Dokumentation:
https://docs.openstack.org/freezer/latest/index.html

IRC-Channel:
#openstack-freezer auf freenode.org

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

OpenStack Masakari – Virtual Machine High Availability

Während Applikationen in der Cloud im Idealfall so aufgebaut sind, dass der Ausfall einer virtuellen Maschine durch das Starten einer anderen virtuellen Maschine aufgefangen werden kann (Cattle-Model), sind in der Praxis noch häufig virtuelle Maschinen anzutreffen, deren Ausfall nur durch das Wiederherstellen genau dieser virtuellen Maschine aufgefangen werden kann (Pet-Model).

Aber selbst wenn man nur mit cloud-nativen Applikationen arbeitet, wo ein Ausfall durch das Starten einer neuen virtuellen Maschine behoben werden kann, will man gegebenenfalls das Wiederherstellen virtueller Maschinen automatisieren.

Hochverfügbare VMs (VMHA) mit Masakari

Dieses automatische Wiederherstellen bezeichnet man als Virtual Machine High Availability (VMHA). Der Begriff „Hochverfügbarkeit“  wird in diesem Fall eher weit ausgelegt: Nicht die unterbrechungsfreie Verfügbarkeit steht im Mittelpunkt, sondern die automatische Wiederherstellung.

In OpenStack stellt die Komponente Masakari genau diese Funktionalität bereit. 2015 vom japanischen Telekommunikationsunternehmen NTT gestartet, gehört Masakari seit 2016 offiziell zu OpenStack.

Aufbau von Masakari

Masakari besteht grob aus drei Komponenten: Einer API, mit deren Hilfe sich Failover-Segmente definieren lassen; Monitor-Diensten, die jeweils den Host, den Virtual Machine Manager und die virtuelle Maschine selbst überwachen; und einer Engine, die im Fehlerfall mit anderen OpenStack-APIs kommuniziert, um einen Failover einzuleiten.

Um auch den Ausfall eines kompletten Hypervisors abfangen zu können, sollten die virtuellen Maschinen auf einem Shared Storage liegen. Um einen Ausfall dieser Art erkennen zu können, setzt Masakari auf Pacemaker in Verbindung mit seinem Hostmonitor, während der Processmonitor und der Instancemonitor jeweils direkt nova-compute und libvirtd überwachen.

Weitere Informationen

Einen weiterführenden Überblick gibt die Vorstellung von Masakari auf dem OpenStack Summit in Tokyo 2015.

OpenStack Wiki:
https://wiki.openstack.org/wiki/Masakari

OpenStack Git:
https://git.openstack.org/cgit/openstack/masakari/
https://git.openstack.org/cgit/openstack/masakari-monitors/
https://git.openstack.org/cgit/openstack/python-masakariclient/

Dokumentation:
https://docs.openstack.org/masakari/latest/index.html

IRC-Channel:
#openstack-masakari auf freenode.org

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

Font Awesome in Sphinx nutzen

Um Font Awesome in Sphinx nutzen zu können wird die Erweiterung sphinx_fontawesome benötigt.

Diese zunächst mit pip install sphinx_fontawesome installieren und anschliessend die Erweiterung in der conf.py hinzufügen (extensions = ['sphinx_fontawesome']).

Nun können die Icon mittels .. fa:: check oder |check| genutzt werden. Ein Beispiel dazu kann man sich in unserer Dokumentation ansehen.

Repositories einer GitHub Organisation anzeigen

Mit PyGitHub ist es möglich auf die GitHub API v3 via Python zuzugreifen. Mit pip install PyGitHub kann die Library installiert werden.

Open vSwitch Provider Bridge einer Kolla Umgebung hinzufügen

Um auf einem bereits laufendem Open vSwitch (OVS) in einer Kolla Umgebung die Provider Bridge br-bond2 zu erstellen und dieser das physikalische Device bond2 hinzuzufügen wird das folgende Kommando ausgeführt.

Mit dem Kommando ovs-vsctl show kann die neu erstellte Provider Bridge geprüft werden.

In der Konfiguration von Kolla wird die neue Provider Bridge dem Parameter neutron_bridge_name hinzugefügt. Das physikalische Device dem Parameter neutron_external_interface. Eine anschliessende Rekonfiguration des Neutron Dienstes ist dann erforderlich.

Die oben beschriebene manuelle Erstellung der Provider Bridge ist nur erforderlich wenn man einer bereits ausgerollten Kolla Umgebung eine neue Provider Bridge hinzufügt. Die Erstellung muss auf allen Knoten durchgeführt werden auf dem die Provider Bridge später genutzt werden soll.