Mit »OpenStack« können Administratoren eigene IaaS-Clouds nach dem Vorbild von Amazon aufbauen und betreiben. speicherguide.de erklärt in diesem Praxis-Workshop den Aufbau und die Konfiguration einer IaaS-Cloud-Testumgebung.

Zu den derzeit populärsten IaaS-Cloud-Lösungen zählt »OpenStack«, das 2010 vom US Internet-Provider Rackspace und der Nasa gemeinsam entwickelt wurde. Technologisch basiert Openstack auf dem Nasa-Projekt »Nebula« aus dem auch ein zweites Open-Source-Cloud-Projekt »OpenNebula« hervorging.

Modulares Miteinander

Openstack besteht aus einer Reihe eng verzahnter Module die auf einem System oder verteilt über mehrere Rechner laufen können:

Der Identity-Service »Keystone« verwaltet »Tenants« (Mandanten), Benutzer, Gruppen, Rechte und vergibt Authentisierungs-Tokens ähnlich wie »Kerberos«.

Die Compute Nodes und die darauf laufenden virtuellen Maschinen verwaltet »Nova«. Als Hypervisoren unterstützt Nova »KVM«, »Xen« und auch die Linux-Container »LXC«. In der Praxis kommt dabei überwiegend KVM zum Einsatz.

Nova verfügt auch über einen simplen Netzwerk-Dienst »Nova-Network«, der die VM-Netzwerke über Bridges anbindet. Das genügt für simple Demo-Installationen.In großen Multi-Node-Setups verwaltet das Netzwerk dann der Dienst »Neutron«, welcher auf dem »OpenVswitch« aufsetzt.

Die Steuerung der kompletten Openstack-Umgebung kann auf der Kommandozeile und in Skripten erfolgen. Für Cloud-Admin-Einsteiger empfiehlt sich »Horizon« das Web-Interface. Dieses dient später auch den Cloud-Nutzern als Selfservice-Portal über das sie sich VMs aus vorgegebenen Templates erstellen dürfen.

Zudem verfügt Openstack über drei verschiedene Storage-Dienste: »Glance« als Image-Service verwaltet Disk-Images. Das können VM-Vorlagen sein oder individuelle Daten-Disks für VMs. Glance nutzt dabei iSCSI als Protokoll, um Images Node-übergreifend zur Verfügung zu stellen.

Der Opjekt Storage »Swift« ist ein alleinstehendes Feature von Openstack, welches nicht für die Operation der VMs nötig ist und nur eine Speichermöglichkeit für Objektdaten offeriert. Swift stellt eine simple Rest-API für den Opjekt-Storage zur Verfügung, der die Daten dann redundant auf mehrere Nodes verteilt. Als Speicher-Backend für Swift und Glance dient »Cinder« der Block-Storage-Dienst von Openstack. Er kontrolliert die Platten-Ressourcen der einzelnen Nova-Nodes.

Viele Wege zur Openstack-Cloud

Openstack ist für fast jede Linux-Distribution erhältlich. Zu den vielen verschiedenen Distributionen gibt es auch eine Reihe ganz unterschiedlicher Installations-Mechanismen. Sehr häufig richtet das mächtige »Packstack«-Skript mit Hilfe des Konfigurations- und Software-Verteilungs-Tools »Puppet« die Umgebung ein. Red Hat offeriert für seine kommerzielle Openstack-Implementierung eine angepasste Kombo aus Puppet und dem Systemvervaltungs-Tool »Foreman« und kann damit automatisiert große Umgebungen mit Openstack ausrollen. In diesem Workshop beschreibt Speicherguide.de eine simple »All-In-One«-Konfiguration, die alle Module auf einem einzigen Server installiert. Dieses Setup nutzt Nova-Network statt Neutron, da das simpler zu verwalten ist und auch mit nur einem LAN-Adapter im Host zu recht kommt. Im All-In-One-Setup erstellt Nova-Network einfach eine Bridge auf dem Loopback-Interface.

Als Open-Stack-Distribution kommt RDO zum Einsatz, die frei verfügbare Openstack-Variante von Red Hat. Das Setup erfordert einen Server mit acht GByte RAM und einer VT-tauglichen CPU. Als Betriebssystem wird »Red Hat Enterprise Linux 6.4« (x86-64) oder ein freier Klon wie »CentOS 6.4« oder »Scientific Linux 6.4« verwendet. Die Installation lädt mehrere MByte Daten vom Internet, daher ist ein schneller Internet-Zugang erforderlich.

Für den Workshop setzt speicherguide.de die aktuelle Openstack-Version 3 Codename »Grizzly« auf einem Intel modular Server-Blade mit zwei »X5670 Xeon«-CPUs und 16 GByte RAM mit »Basis RHEL 6.4« ein. Noch im Herbst soll Openstack 4 »Havanna« auf den Markt kommen, was aktuell nur als Beta-Code verfügbar ist.

Vorbereitung

Installieren Sie Ihr Red Hat oder ein kompatibles Betriebssystem als »Basic Server« und spielen Sie die aktuellen Updates & Fixes via »yum«-Update ein. Über

yum install -y http://rdo.fedorapeople.org/openstack-grizzly/rdo-release-grizzly.rpm

fügen Sie dem System die Openstack-Grizzly-Quellen hinzu. Führen Sie im Anschluss eine

yum update -y; init 6

aus, welches den Openstack-getunten Kernel einspielt und das System neu startet.

Nach dem Neustart, prüfen Sie die Kernel-Version mit uname -r. Hier muss nach der Versionsnummer des Kernels »openstack.el6« stehen, beispielsweise: 2.6.32-358.118.1.openstack.el6.x86_64.

Dann beginnt die eigentliche Installation. das Komamndo:

yum install -y openstack-packstack

lädt das Packstack-Skript. Danach folgt die eigentliche Installation:

packstack --allinone --os-quantum-install=n

Der Parameter »allinone« konfiguriert automatisch alle benötigten Komponenten während os-quantum-install=n verhindert, dass der OpenVswitch und das Modul »Neutron« (alter Codename: Quantum) eingerichtet wird.

Wenn Sie das Skript ohne Angabe der Parameter starten, fragt es alle Module und deren Konfiguration einzeln ab. Sie können über --gen-answer-file eine Antwort-Datei erstellen lassen, dort via Editor alle Ihre individuellen Parameter eintragen. So werden in der Regel größere Umgebungen aufgesetzt und Konfiguriert.

Das Packstack-Skript verlangt zuerst das Root-Passwort des Benutzers und startet dann die Installation welche, je nach der Bandbreite ihrer Internet-Verbindung mehrere Minuten oder Stunden dauern kann.

Nach der Installation befindet sich im /root-Verzeichnis des Servers eine Datei namens »keystonerc_admin«. Diese enthält die nötigen Umgebungsvariablen, so dass Sie auf der Kommandozeile arbeiten können, ohne dabei für jedes Kommando das Passwort eingeben zu müssen. Über

source keystonerc_admin

aktivieren Sie diese Einstellungen. Das Kommando

keystone user-list

listet beispielsweise die aktuell definierten Benutzer auf. Alle anderen Module verfügen über ähnlich strukturierte Befehle. Alle Openstack-Operationen lassen sich auf der CLI ausführen. Die Web-Gui ist nach der Installation via Browser erreichbar. Der Default Login ist User: admin und das Password, welches in der »keystonerc_admin«-Datei hinter der Anweisung export_OS_PASSWORD= steht.

Konfiguration

Um später mit Openstack-Images arbeiten zu können, müssen Sie die Basis-Konfiguration anpassen. Mit dem vorliegenden Setup weist Openstack den neuen VMs eine dynamische IP-Adresse aus einem privaten Segment zu, wobei das VM-Interface am Loopback-Adapter des Hosts hängt. Routing-Regeln erlauben den VMs jedoch, mit der Außenwelt und dem Internet via NAT zu kommunizieren. Aber von außen kommt keiner auf die VMs.

Openstack (ohne Neutron) setzt hierfür das Konzept der »Floating-IPs« ein. Dabei handelt es sich um einen Pool von Adressen, die auf dem Host zur Verfügung stehen. Bekommt eine VM eine »Floating-IP« zugewiesen, bindet der Host diese Adresse als zusätzliche IP an sein externes Interface. Openstack-eigene Firewall-Regeln leiten die Zugriffe dann an VMs weiter. Die VM selbst weiß dabei gar nicht, ob und welche Floating-IP ihr zugewiesen wurde.

Um dieses Feature zu nutzen müssen Sie ein passendes Floating-IP-Segment erstellen und eine gültige Firewall-Regel für den Port 22 (SSH) einstellen.

Um die Floating-IP-Range festzulegen gehen Sie auf die CLI und führen source_keystonerc_admin aus. Dann listet folgendes Kommando die bestehende Floating-IP-Range:

nova floating-ip-bulk-list

Der Standard-Bereich 10.3.4.0/22 lässt sich entfernen via

nova floating-ip-bulk-delete 10.3.4.0/22

Dann können Sie Ihren eigenen Bereich, der im internen Netzwerk verfügbar sein muss, zuweisen. Wer beispielsweise intern das Netzwerk 192.168.1.0/24 verwendet, könnte als Floating-IP-Range den Bereich 192.168.1.208/28 einsetzen und damit die 14 IP-Adressen von 192.168.1.209 bis 192.168.1.222 für Openstack-VMs reservieren.

Das Test-Netzwerk von speicherguide.de verwendet eine erweiterte C-Klasse 10.32.96.0/20 und damit Adressen von 10.32.96.1 bis 10.32.111.254. Für Openstack stellt speicherguide.de 254 Adressen im Subnetz 10.32.109.0/24 ab und konfiguriert dieses als Floating-IP-Segment.

nova floating-ip-bulk-create 10.32.109.0/24

Die erste virtuelle Maschine

Um nun eine virtuelle Maschine (VM) ausrollen zu können brauchen Sie zunächst einmal ein passendes System-Image. Auf der Openstack-Seite gibt es eine Link-Liste, wo Openstack-Images etlicher Distributionen zum Download bereit stehen. Auf den jeweiligen Seiten finden sich direkte http-Links zu raw- oder qcow2-Images. Für den Workshop verwendet speicherguide.de ein CentOS-Image von der Wenseite. Klicken Sie mit der rechten Maustaste auf den Button »Download« neben dem CentOS-6.4-Image und wählen Sie »Link Adresse kopieren« aus. Öffnen Sie im Browser das Horizon-Dashboard der Openstack-Installation und wechselt auf den »Admin«-Tab. Unter »Images« und »Create Image« legen Sie Ihr CentOS-Template an. In diese Ziele »Image Location« fügen Sie den Link aus der Zwischenablage ein und geben das Format »QCOW2« an. Markieren Sie das Image als »Public« und klicken auf »Create Image«. Openstack wird das Abbild automatisch aus dem Internet herunterladen.

Während das Image lädt, gehen Sie auf den Tab »Project«, wählen Sie »Access & Security« und klicken Sie bei der Security Group »default« auf »Edit Rules«. Dort fügen Sie über Add-Rule den Firewall-Zugang für den SSH-Port 22 ein. Add Rule – IP Protocol »TCP«, Open »Port«, Port »22«, Source und CIDR bleiben auf Vorgabe und dann Button »Add« drücken. Ähnlich können Sie für weitere Ports verfahren, wie beispielsweise http.

Unter dem Obermenü »Access und Security« findet sich der Punkt »Keypairs«. Generieren Sie auf Ihrer Admin-Workstation ein ssh-Schlüsselpaar und importieren Sie den öffentlichen Teil via »Import Keypair«. Wenn Sie später VMs erstellen, kann Openstack den öffentlichen SSH-Schlüssel als »trusted Key« in der VM hinterlegen und sie können sich mit dem Password von Ihrer Admin-Station an der VM anmelden.

Bevor Sie nun Ihre erste VM ausrollen können Sie sich im Web-GUI von Openstack umsehen. Der Tab Admin listet als Basiseinstellungen auf, die für das ganze System gelten. Der Projekt-Tab verwaltet einzelne Umgebungen mit virtuellen Instanzen. Die Projekte sind dabei voneinander abgeschottet und teilen sich bestenfalls Basis-Ressourcen wir Floating-IP-Ranges und Image-Templates.

Über den Admin-Tab können Sie Projekte und Benutzer mit verschiedenen Rechten anlegen. Dabei deklarieren Sie auch die Quotas der Projekte. Das Standard-Projekt »Admin« zum Beispiel darf per Default nur zehn VMs ausrollen und nur 10 Floating IPs belegen. Diese Einstellungen können Sie als Admin jederzeit modifizieren. Unter Flavors legen Sie die verschiedenen Größen der VMs fest, also CPU-Zahl, RAM und maximale Größe der zugewiesenen Disks. Auch der Zugriff von Projekten auf Falvors läßt sich über Policys einschränken. Der Tab Volumes verwaltet Disk-Abbilder. Diese Volumes können Sie an einzelnen VMs anhängen. Volumes, welche über das Admin-Panel erstellt wurden, lassen sich verschiedenen Projekten zuweisen. Die Ansicht »Instances« die Maschinen aller Projekte und »Images« listet die verfügbaren Templates auf.

Auch im Projekt-Tab finden sich Einstellungen für Volumes, Instances und Images. Diese beziehen sich nur auf die Ressourcen, welche der Administrator dem jeweiligen Projekt zur Verfügung stellt. Dazu gibt es noch den »Object Store« In den Containern kann der Nutzer via das Web-Interface Daten ablegen. Um die redundante Lagerung auf mehreren Nodes kümmert sich dann das Swift-Modul.

Da Swift als Objekt-Storage sehr leistungsfähig ist, geht speicherguide.de im Rahmen dieses Workshops nicht näher darauf ein, sondern stellt die Lösung in einem gesonderten Workshop ausführlich vor.

Zügiges Ausrollen

Gehen Sie in das Projekt »Admin«. Im Menü »Instances« klicken Sie auf »Launch Instances«. Im folgenden Dialog geben Sie der Maschine einen Namen, wählen als Instance-Source das CentOS-Image und wählen den Flavor »small«. Für den ersten Test rollen Sie ein einzelnes System aus – in der Praxis könnten sich hier auf Knopfdruck dutzende VMs ausrollen lassen. Unter Access & Security wählen Sie ihren SSH-Key aus – für simple Tests mit dem CentOS-Image geht es aber auch ohne Key.

Klicken Sie auf »Launch« und Openstack erstellt und startet die VM. Über »Instance« und »Console« können Sie sich am System anmelden. Hier gibt‘s einen seltsamen Trick: Sie müssen erst auf den grauen Balken oberhalb der VM und dann ins Fenster der VM Klicken. Jetzt können Sie sich an der CentOS-VM als »root« mit dem Password changeme1122 anmelden.

Um auch von außen Zugriff zu erhalten, wählen sie in der Instance-Ansicht neben der VM den Button »More« und »Assoiciate Floating IP«. Openstack zeigt daraufhin die zugewiesene IP an und Sie können sich von außen via SSH mit Key oder Password anmelden. Ein Ping auf die Floating-IP funktioniert übrigens nicht, weil das ICMP-Protokoll mit dem aktuellen Regelwerk nicht durch die Firewall dringt.

Fazit

Mit dem Zugang zur ersten VM endet unser Opernstack Workshop. Jetzt haben Sie eine funktionierende IaaS-Cloud-Testumgebung, auf der Sie Ihre Systeme ausrollen können. Das bestehende Setup lässt sich über Packstack auch mit weiteren Nova-Nodes aufrüsten. Ohne den Neutron-Switch können dabei jedoch nur die Systeme eines Nova-Nodes untereinander ohne Floating-IPs kommunizieren. Diese Konfiguration genügt, wenn Ihre Cloud-Systeme Einzelgänger mit individuellen Zugängen von außen bleiben.