© ginasanders, 123RF

Nach der Vorstellung der wichtigsten Komponenten von Open Stack geht es nun darum, erste praktische Erfahrung zu sammeln. Juju, Maas und Autopilot von Ubuntu bilden das Fundament.

Wer sich zum ersten Mal mit Open Stack beschäftigt, fühlt sich von der Menge der Komponenten und ihrem Zusammenspiel schnell erschlagen. Vermutlich hat deshalb der erste Teil des Open-Stack-Workshops für manchen Leser neue Fragen aufgeworfen. Es ist eine Sache, die wichtigsten Open-Stack-Komponenten zu kennen und von den Konzepten, die ihnen zugrunde liegen, schon mal gehört zu haben. Etwas anderes ist es, ganz praktisch eine Open-Stack-Umgebung aufzusetzen – und sei es nur, um eigene Erfahrungen mit der freien Cloud-Computing-Umgebung zu sammeln.

Der zweite Teil des Linux-Magazin-Workshops beschäftigt sich deshalb ganz konkret mit den ersten praktischen Schritten auf dem Weg zum Open-Stack-Admin. Das Ziel besteht in einer Basisinstallation, die in virtuellen Maschinen läuft und sich so mit handelsüblichen VMs ohne Probleme nachbauen lässt. In Sachen Deployment fiel die Wahl der Redaktion auf Ubuntu, Metal as a Service (Maas), Juju und Autopilot. Mit diesem Werkzeugmix gelangt auch der Anfänger schnell zu einer lauffähigen Open-Stack-Umgebung.

Bevor es jedoch auf die Baustelle geht, stehen ein paar Hausaufgaben auf dem Programm. Zwar nimmt das Canonical-Framework angehenden Open-Stack-Admins die Mehrzahl der Aufgaben ab, doch sollte trotzdem grundsätzlich klar sein, was bei Maas, Juju und Autopilot im Hintergrund passiert. Denn nur so ist es dem Admin später möglich, Rückschlüsse auf die Funktionsweise von Open Stack zu ziehen und das Setup unter realen Bedingungen und auf echtem Blech zu reproduzieren.

Blick unter die Haube

Canonicals Deployment-Konzept für Open Stack ist deshalb durchaus bemerkenswert, weil es in seiner heutigen Form so ursprünglich nicht gedacht war. Maas ist dafür ein gutes Beispiel: Ursprünglich wollte Canonical mit Maas Konkurrenzprodukten wie Red Hats Satellite entgegentreten. Erklärtes Ziel war es, den kompletten Lebenszyklus eines Servers zu begleiten – von dem Moment, an dem ihn der Admin ins Rack einbaut, bis zum Zeitpunkt, an dem er ihn wieder ausbaut und verschrottet.

Um das Ziel zu erreichen, tritt Maas heute meist im Gespann mit Landscape auf. Maas implementiert alle Teile des Setups, die für die Erfassung und das Steuern von Hardwareknoten zuständig sind: Ein neuer Rechner bekommt etwa von einem Maas-Server eine Antwort, wenn er beim ersten Starten über seine Netzwerkschnittstellen einen PXE-Request sendet. Der Maas-Server betreibt obendrein einen DHCP-Daemon, der alle Rechner mit IP-Adressen versorgt. Auf Wunsch konfiguriert Maas zudem die Out-of-Band-Schnittstellen der Systeme und stößt die Betriebssystem-Installation an, sodass nach einigen Minuten aus einem nackten Server ein laufendes LTS-Ubuntu werden kann.

Um danach auf den Hosts Wartungsaufgaben auszuführen, ergänzt Canonical Maas und Landscape um Juju. Dem Service Modeling Tool liegen dieselben Ideen zugrunde wie schon bei Puppet, Chef oder Ansible. Anders als jene ist Juju aber den Ruf nie losgeworden, ausschließlich für Ubuntu geeignet zu sein. Während die anderen Automatisierer sich auf verschiedenen Betriebssystemen finden, sind Juju-Setups praktisch immer Ubuntu-basiert. Über die Qualität von Juju sagt das aber nichts: Es rollt wie vergleichbare Lösungen Dienste zuverlässig auf Servern aus.

Weder Maas noch Landscape oder Juju sind in irgendeiner Weise spezifisch für Open Stack. Die drei Werkzeuge ermöglichen das Ausrollen eines Web- oder Mailservers oder eben von Open Stack. Weil aber mehrere Lösungen am Markt existieren, die Open Stack automatisch ausrollen und dabei mehrere Komponenten kombinieren, wollte offenbar auch Canonical nicht nachstehen.

Das Resultat ist Autopilot. Im Wesentlichen handelt es sich dabei um eine Sammlung von Juju-Charms, die in Landscape unter einer einheitlichen Oberfläche integriert sind und helfen Open-Stack-Dienste auszurollen. Die Kombination aus Maas, Landscape, Juju und dem auf Juju aufbauenden Autopilot bietet einen konkurrenzfähigen Funktionsumfang: Frische Server werden in Minuten zu einer fertigen Open-Stack-Installation.

Vorsicht, Falle!

Der Vollständigkeit halber sei darauf hingewiesen, dass das Gespann aus Landscape, Maas, Juju und Autopilot nicht uneingeschränkt begeistert. Unschön ist etwa das Lizenzmodell: Ohne gültige Lizenz verwaltet Landscape nur zehn Knoten. Für eine produktive Open-Stack-Cloud reicht das nicht aus.

Allerdings zwiebeln auch Suse und Red Hat die potenzielle Kundschaft in vergleichbarer Art und Weise. Im Rahmen dieses Workshops hätte sich also keine bessere Situation ergeben, käme statt Ubuntu Red Hat oder Suse zum Einsatz. Der Admin sollte jedoch im Hinterkopf haben, dass später zusätzliche Kosten auf ihn zukommen können.

Vorbereitungen

Für ein Open-Stack-Setup mit Maas und Autopilot sind fünf Server nötig. Der erste Server ist der Maas-Knoten: Dieser betreibt DHCP- und TFTP-Server und antwortet auf eingehende PXE-Anfragen. Die zweite Maschine kümmert sich um alle Aufgaben, die im Rahmen von Autopilot anfallen. Die übrigen Server kommen in der Open-Stack-Installation selbst zum Einsatz: ein Controller, ein Netzwerkknoten sowie ein Compute-Server.

An diese Server stellt Open Stack spezielle Ausstattungs-Anforderungen: Der Server, der als Netzwerkknoten dient, braucht mindestens zwei Netzwerkkarten. Und weil bei Autopilot gleich auch Ceph als All-inclusive-Paket für Storage-Dienste an Bord ist, sollten alle drei Open-Stack-Knoten mit mindestens zwei Festplatten ausgestattet sein.

Grundsätzlich spricht nichts dagegen, die Server für die erste eigene Cloud in Form virtueller Maschinen zu realisieren. Die können durchaus in einer Public Cloud, etwa bei Amazon oder Google, laufen, solange die beschriebenen Details gegeben sind. Ein solches Setup eignet sich bereits, um erste Gehversuche zu unternehmen. Die Rückschlüsse, die sich aus einer solchen Cloud auf echte Setups ziehen lassen, sind aber beschränkt.

Ein Problem ist etwa, dass öffentliche Clouds geschachtelte Virtualisierung meist nicht unterstützen. Der Compute-Knoten kann dann zwar virtuelle Maschinen per Qemu starten, aber diese sind voll virtualisiert und kommen ohne Support für die verschiedenen Features der Host-CPU daher. Etwas mehr Spielraum hat, wer etwa auf dem eigenen Desktop entsprechende VMs betreiben kann. Denn bei VMware & Co. gehört geschachtelte Virtualisierung mittlerweile zum Repertoire.

Weil zumindest die drei Open-Stack-Knoten aber auch mit ordentlich Dampf unter der Haube ausgestattet sein sollten, ergibt dieses Setup nur bei Workstations mit wirklich guter Hardware-Ausstattung Sinn. Das gilt auch im Hinblick auf die genutzten Storage Devices: Weil Autopilot im Setup des Beispiels auch einen ausgewachsenen Ceph-Cluster ausrollt, ruft es auf dem Blockgerät des Hosts einige Last hervor. Mit einer normalen Festplatte macht das definitiv keinen Spaß, eine schnelle SSD sollte es deshalb schon sein.

Am schönsten lässt sich Open Stack natürlich auf echtem Blech erkunden. Wer also ein paar ältere Server übrig hat und sich im eigenen RZ eine passende Umgebung bauen kann, sollte das auch tun. Wichtig: Das Management-Netzwerk, das Maas verwaltet, darf keinen weiteren DHCP- oder TFTP-Server enthalten, weil sich dieser und Maas sonst ins Gehege kämen. Die Anforderungen an das Netz bei mindestens zwei Open-Stack-Knoten und die Plattenbedürfnisse von Ceph sind in einem solchen Konstrukt natürlich ebenso zu beachten.

Im Folgenden geht das Beispiel davon aus, dass fünf virtuelle Maschinen in einer privaten Virtualisierungsumgebung bereitstehen. Die Knoten für Maas und Autopilot haben eine Netzwerkschnittstelle.

Die drei Open-Stack-Knoten haben neben der Platte für ihr System jeweils eine zusätzliche Platte für Ceph. Sie verfügen über vier CPU-Kerne und 16 GByte virtuellen Speicher. Alle drei hängen mit einer Netzwerkkarte im selben virtuellen Netz wie die Knoten für Maas und Autopilot. Der designierte Netzwerkknoten, der eine zweite NIC hat, ist mit dieser ebenfalls mit demselben Netzwerk verbunden.

Netzwerk-Topologien

Maas unterstützt ab Werk zwei Methoden, um das Netzwerk in Open Stack zu konfigurieren. Grundsätzlich unterscheiden Admins in Clouds zwischen dem privaten und dem öffentlichen Netzwerk. Ersteres sorgt bei Maas & Co. vorrangig für die Kommunikation zwischen den physischen Hosts. Letzteres liefert die öffentlichen IP-Adressen, über die sich VMs in Open Stack mit der Außenwelt verbinden.

Der hier vorgestellte Weg geht davon aus, dass das einzige physische Netzwerk sowohl für die Kommunikation zwischen den Hosts der Cloud als auch für die Außenanbindung der Open-Stack-Server zur Verfügung steht. Das ist vor allem der Tatsache geschuldet, dass das im Workshop vorgestellte Setup so einfach wie möglich sein soll. Maas unterstützt durchaus auch das Einrichten eines zweiten physischen Netzwerks, das bedingt jedoch deutlich mehr Konfigurationsarbeit.

Schritt 1: Der Maas-Server

Für ein Ubuntu-Setup mit Maas, Landscape und Autopilot ist Maas de facto die Keimzelle (Abbildung 1). Der Knoten, der die zu Maas gehörenden Dienste bereitstellt, ist als einziger durch den Admin zumindest zum Teil händisch zu installieren. Etwas befremdlich wirkt, dass Canonical für den Maas-Knoten aktuell Ubuntu 14.04 noch immer zwingend voraussetzt – zumindest laut Dokumentation. Diese Version hat schließlich fast drei Jahre auf dem Buckel.

Abbildung 1: Sobald der Maas-Server grundsätzlich konfiguriert ist, lassen sich andere Knoten per PXE-Boot automatisch zum Setup hinzufügen.

Immerhin: Wer das Setup auf echtem Blech mit aktuellen Servern nachstellen möchte, bekommt für Ubuntu 14.04 bis heute aktuelle Kernel, mit denen sich auch neuere Hardware betreiben lässt. Der erste Schritt aus Admin-Sicht besteht darin, auf dem designierten Maas-Knoten Ubuntu 14.04 zu installieren und alle vorhandenen Updates einzuspielen.

Sobald die grundlegende Installation des Betriebssystems abgeschlossen ist, folgt die Maas-Installation. Canonical stellt die benötigten Pakete in einem eigenen Repository bereit:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:cloud-installer/stable
sudo apt-get update

Danach ist das Maas-Repository auf dem System aktiv. Per »sudo apt-get install maas« stößt der Admin die Maas-Installation an. Das Herunterladen und Ausrollen der entsprechenden Pakete kann einige Zeit in Anspruch nehmen. Danach ist die Installation fast komplett.

Maas organisiert sich intern anhand von Regionen. So stellt Canonical sicher, dass sich auch die Server in unterschiedlichen Rechenzentren über eine zentrale Maas-Instanz verwalten lassen. Die Maas-Pakete legen selbst auch eine Standardregion an, setzen in dieser für den Admin-Nutzer aber kein Passwort. Das korrigiert der Admin per »sudo maas-region-admin createadmin« auf der Kommandozeile des Maas-Servers. Danach steht der Login-Bildschirm von Maas unter »http://IP/MAAS/« zur Verfügung – »IP« ist dabei durch die Maas-IP-Adresse zu ersetzen.

Maas einrichten

Für den reibungslosen Einsatz von Maas in Open-Stack-Umgebungen sind nach der Maas-Installation ein paar Parameter der Maas-Konfiguration anzupassen. Im »Settings«-Tab muss die Download-URL bei »Boot Images« anstelle des voreingestellten Werts als »http://images.maas.io/ephemeral-v2/daily/« definiert sein. Falls der Maas-Server hinter einer Firewall steht, muss zudem sichergestellt sein, dass er die genannte URL erreichen kann. Ebenfalls in »Settings« ist ein DNS-Server einzutragen, den die Open-Stack-Knoten später nutzen sollen.

Im »Images«-Tabulator importiert der Admin dann per Mausklick Images für Ubuntu 14.04 LTS und 16.04 LTS. In seinen Account-Einstellungen hinterlegt er schließlich einen gültigen SSH-Schlüssel. Diesen packt Maas später automatisch auf die ausgerollten Knoten, sodass der Admin sich dort per SSH problemlos anmelden kann. Das Menü ist über den Button in der oberen rechten Ecke des Maas-GUI erreichbar.

Der eigene Cluster

Mit dem Begriff Cluster meinen die Maas-Entwickler nicht unbedingt das, was Admins üblicherweise darunter verstehen. Gemeint ist nicht etwa ein Cluster aus mehreren Maas-Knoten, sondern alle Hardwareknoten, die zu einem Maas-Setup gehören – die der jeweilige Maas-Server also verwaltet. Damit später Maas Open Stack ausrollen kann, legt der Admin im folgenden Arbeitsschritt die grundlegenden Eigenschaften des Maas-Servers für diesen Maas-Cluster fest. Dazu gehören insbesondere seine Netzwerkkonfiguration und das Aktivieren von DHCP und DNS.

Per Klick auf den »Clusters«-Tab gelangt man in das entsprechende Menü. Ein Klick auf »Cluster Master« führt direkt zur passenden Konfiguration des Maas-Servers. Hat der Maas-Server wie hier im Beispiel nur eine NIC, wird nur diese angezeigt. Bewegt man den Mauszeiger nun über diese Zeile, erscheint ein Symbol, das das Editieren des Eintrags möglich macht. Dabei ist der Maas-Server so zu konfigurieren, dass er DHCP für das private Netzwerk liefert und dabei auch DNS-Einträge verschickt. Zudem ist beim Feld »Router IP« das Default-Gateway einzutragen, über das Maas und die einzelnen Cloudserver das Internet erreichen können.

Weiter unten ist außerdem das IP-Netz zu konfigurieren, das Maas nutzt, um Hardwareknoten IP-Adressen zuzuteilen. Drei logische Bereiche sollte der Admin dabei beachten (Abbildung 2):

Abbildung 2: Beim Einrichten des Cluster-Masters ist es sinnvoll, von Anfang an die IP-Bereiche für statische, dynamische und Floating-IPs festzulegen.

• Der Bereich »Dynamic Range« dient Maas als Pool von IPs, die neue Knoten bei der ersten Inventarisierung dynamisch zugewiesen erhalten. Hier sollten bei einem neuen Setup mindestens 60 Adressen nebst der Anzahl der insgesamt von Anfang an vorhandenen Knoten reserviert sein.
• Der Bereich »Static Range« bezeichnet die Range von IP-Adressen, die Knoten nach ihrer Installation dauerhaft zugeteilt bekommen. Die Dokumentation empfiehlt hier mindestens 20 IP-Adressen anzugeben, auch wenn das für das konkrete Beispiel etwas überdimensioniert ist.
• Der Bereich »Floating IP Range« ist kein Maas-Parameter; er sollte dennoch angegeben werden: Aus dieser Range bezieht Maas später die IP-Adressen, die es in Open Stack als öffentliche IP-Adressen nutzt. Indem der Admin sie an dieser Stelle festlegt, stellt er sicher, dass sie nicht als Teil einer der beiden anderen Pools versehentlich bei der Knotenverwaltung genutzt werden.

Ein abschließender Klick auf »Save« sichert die Einstellungen. Ist der Download der Ubuntu-Images (Tab »Images«) abgeschlossen, ist Maas einsatzbereit.

Vorstellungsrunde

Im nächsten Schritt macht der Admin seine übrigen Rechner mit der nun konfigurierten Maas-Instanz bekannt. Jeder Knoten mit Ausnahme von Maas selbst sollte so konfiguriert sein, dass er automatisch per PXE bootet (Abbildung 3). Wenn das sichergestellt ist, startet der Admin die Knoten einzeln – im Beispiel also die anderen VMs. Nach und nach booten diese dann in ein von Maas eigens angebotenes Inventarisierungs-Image und erscheinen danach in der Knoten-Liste von Maas (Tab »Nodes«).

Abbildung 3: Je nach Beschaffenheit der einzelnen Maas-Knoten hinterlegt der Admin in Maas die Info, wie diese aus der Ferne zu steuern sind.

Für die vier dort nun gelisteten Server legt der Admin im Anschluss einzeln fest, um welche Art von System es sich handelt. Diese Information braucht Maas, um die Kontrolle über die Server zu übernehmen, also um sie beispielsweise per IPMI neu zu starten.

Das Menü »Power type« für jeden einzelnen Server ermöglicht diese Konfiguration. Je nach dort ausgewähltem Wert erscheinen unterhalb des Dropdown-Menüs Felder für verschiedene Parameter, die der Admin pro Server ebenfalls ausfüllen muss. Im konkreten Beispiel, bei dem die Maas-Server als VMs auf einem Linux-System liegen und Virsh sie verwaltet, wäre der Power-Typ »Virsh (Virtual systems)« der passende.

In dem Feld »Power Address« könnte dann der Eintrag »qemu+ssh://ubuntu @10.42.0.2/system« stehen, beim Feld »Power-ID« der Wert »openstack01« und bei »Password« das Passwort des Nutzers »ubuntu« auf dem Virtualisierungshost. Kommen statt virtueller Maschinen echte Systeme zum Einsatz, verrät der Admin Maas hier, wie es an deren Out-of-Band-Management-Schnittstellen andockt (Abbildung 3).

Zurück im »Nodes«-Tab wählt der Admin im nächsten Schritt alle dort gelisteten Knoten aus und klickt beim Dropdown-Menü »Take Action« auf »Commission«. Wenn alle Maschinen den Status »Ready« haben, steht Fleißarbeit auf dem Programm: Für jeden Knoten prüft der Admin dann nämlich, ob die Netzwerkkonfiguration des Systems passt. Die jeweils erste NIC des Servers sollte auf der »Details«-Seite des Knotens mit dem privaten Netz verbunden sein und beim »IP address«-Feld den Wert »Auto assign« haben. Das System mit zwei NICs müsste die zweite NIC ebenfalls als mit dem privaten Netz verbunden anzeigen, der Eintrag bei »IP address« sollte jedoch auf »unconfigured« stehen.

Den Autopiloten starten

Der nächste Arbeitsschritt führt den Admin zurück auf die Kommandozeile des Maas-Servers. Die Befehle »sudo apt-get install openstack« sowie »sudo JUJU_BOOTSTRAP_TO=Autopilot-Host openstack-install« holen die benötigten Pakete für Open Stack auf den Maas-Server und sorgen dafür, dass der Open-Stack-Autopilot auf dem dafür vorgesehenen Host automatisch ausgerollt wird. »Autopilot-Host« ist dafür entsprechend den Gegebenheiten anzupassen.

Während des Setups fragt »openstack-install«, welchen Modus es für die Open-Stack-Installation nutzen soll. »Landscape Open Stack Autopilot« ist hier die richtige Antwort. Die weiteren Fragen des Installers sind auf Basis der lokalen Vorgaben zu beantworten. Am Ende fragt das Programm auch nach der IP-Adresse des Maas-Servers sowie dem benutzerspezifischen API-Key für Maas – dieser findet sich in den Benutzereinstellungen, die über den Button in Maas oben rechts zu erreichen sind.

Sobald der Vorgang erfolgreich abgeschlossen ist, zeigt »openstack-install« einen Link an: Dieser ist anschließend im Browser zu öffnen, wo der Admin zum ersten Mal ein fertiges Landscape mit integriertem Open Stack zu Gesicht bekommt (Abbildung 4).

Abbildung 4: Sobald Maas und Autopilot eingerichtet sind, steht dem Admin Landscape zur Verfügung – Open Stack per Mausklick.

Open Stack installieren

So seltsam es klingt: Der Rest der Open-Stack-Installation geht ab hier inklusive Ceph sehr schmerzlos von der Hand. Denn das im Beispiel gezeigte Setup ist der typische Showcase für Canonicals Autopilot, also das nach aktuellem Stand kleinstmögliche Standard-Setup. Auf der Landscape-Website klickt der Admin zunächst auf »Setup«. Für »Compute« wählt er hier »KVM« aus, für »Network«»Open vSwitch« und für »Object Storage« sowie für »Block Storage«»Ceph«.

Ein Klick auf »Configure & Install« führt zur Auswahl der Knoten, die für das neue Open-Stack-Setup herhalten. Nach der Auswahl der drei Open-Stack-Server sorgt »Automatic Placement« (Abbildung 5) dafür, dass der Autopilot die Open-Stack-Dienste optimal auf die verfügbaren Knoten verteilt – die Installation geht los. Am Ende des Vorgangs bietet Autopilot die Möglichkeit, einen Open-Stack-Nutzer anzulegen, mit dem danach der Zugriff auf das Open-Stack-Dashboard möglich ist. Sobald dieser Punkt erreicht ist, sind Glückwünsche angebracht: Der Admin hat sich bis zur ersten eigenen Open-Stack-Installation durchgeschlagen.

Abbildung 5: Im letzten Schritt des Deployment weist der Admin die Knoten des Setups der Autopilot-Wolke zu. Den Rest erledigt Autopilot vollkommen automatisch.

Entdecke die Möglichkeiten

Am Ende des Autopilot-Setups steht eine Open-Stack-Cloud, in der alle im ersten Workshop-Teil vorgestellten Dienste bereitstehen. Die IP, über die der Admin am Ende der Autopilot-Installation das Dashboard aufruft, ist zugleich auch die IP, unter der die Authentifizierungs-Komponente Keystone erreichbar ist. Horizon bietet über den Menüpunkt »Access & Security« eine »openrc«-Datei an, die sich auf der Kommandozeile direkt in die dortige Umgebung per »source«-Kommando integrieren lässt.

Danach ist es möglich, sämtliche Open-Stack-Kommandozeilen-Clients analog zum Dashboard zu nutzen. Wer sich stattdessen erst mal mit dem Dashboard vertraut machen möchte, kann in diesem virtuelle Netze anlegen und VMs starten, anhalten und entfernen.

Es spricht übrigens nichts dagegen, sich auf den einzelnen Hosts des Setups umzuschauen: Die Konfigurationsdateien der Dienste liegen stets in einem nach dem jeweiligen Dienst benannten Ordner unterhalb von »/etc«. Wer sich bisher noch nicht mit Ceph beschäftigt hat, kann das bei diesem Setup gleich nachholen: Neben Open Stack hat Autopilot nämlich ein komplettes Ceph ausgerollt und gleich so konfiguriert, dass Open Stack darauf zugreift und es für den Image-Dienst Glance und den Volume-Dienst Cinder nutzt.

Das Setup erweitern

Im Rahmen der bereits erwähnten Beschränkung auf zehn Hosts lässt sich das Setup übrigens durchaus noch erweitern. Wer nach den ersten Gehversuchen mit Open Stack also Freude an der Lösung gefunden hat, kann zusätzliche Knoten per Maas erst kommissionieren und danach mittels Autopilot einer Aufgabe im Open-Stack-Verbund zuweisen.

Ausblick

Eine mit Autopilot aufgesetzte Open-Stack-Cloud ist für erste Gehversuche gut geeignet. Wer Open Stack produktiv im Rechenzentrum nutzen möchte, muss jedoch mehr Hirnschmalz investieren: Verschiedene Abhängigkeiten und diverse Herausforderungen – erwähnt seien die Themen HA oder Security – machen sorgfältige Planung notwendig. Im dritten Teil des Workshops geht es deshalb um diese Bausteine.