Wer wollte nicht schon immer mal den eigenen virtuellen Serverraum mit wenigen Klicks selbst zusammenstellen? Nach der Inbetriebnahme der CMS-OpenStack-Installation kommen wir diesem Gedanken nun schon näher.

OpenStack ist eine Open-Source Software zum Betrieb von Clouds, die es uns als CMS ermöglicht, mehr und mehr Technologien zu abstrahieren, zu virtualisieren und als Selbstbedienungsfunktionen anzubieten. Hierzu zählen unter anderem die Virtualisierung von Rechenleistung, Storage, Netzwerken, Sicherheitsregeln, speziellen Appliances oder auch Diensten für Desktops. OpenStack besteht aus mehreren Komponenten für diese einzelnen Zwecke. Die Implementierung von OpenStack am CMS für die HU ist die HU-Cloud.

Eine gute Übersicht zur Architektur findet sich unter

http://docs.openstack.org/juno/install-guide/install/yum/content/ch_overview.html

Anfangend mit dem Netzwerk, IP-Subnetzen, Routern, deren Schnittstellen und IP-Zuweisungen bis hin zu unterschiedlichen Servern kann nun die eigene Infrastruktur aufgebaut werden. Hierfür werden verschiedene „flavors“ – sprich Größenklassen – angeboten, die derzeit von einem Kern und 512 MB Arbeitsspeicher bis hin zu 8 Kernen und 16 GB RAM reichen. Auch bei den Betriebssystemen gibt es eine größere Auswahl unterschiedlicher Linux-Systeme und es werden verschiedene Möglichkeiten für Storage angeboten.

Die Konfigurationsmöglichkeiten im Web-Interface reichen vom einfachen Aufbau von Netzwerken und Servern über die Verwaltung von Block- oder Objekt-Speicher bis hin zur Verwaltung von Load-Balancern und entsprechenden Server-Pools für einzelne Dienste.

Im nächsten Schritt geht es dann jedoch nicht nur um das Anlegen von Infrastruktur per Hand oder per Klick, sondern automatisiert über die Benutzung der APIs. Jedes Modul in OpenStack bietet solche Schnittstellen. Zusätzlich ist seit dem OpenStack-Icehouse-Release das Modul „Heat“ hinzugekommen, um die anderen Module orchestrieren zu können, Templates zu erstellen und somit eine einheitliche Umgebung auch für Skripte zu bieten. In Zusammenarbeit mit dem Modul „Ceilometer“ lassen sich darüber hinaus dynamische Aspekte, wie z.B. die Erzeugung zusätzlicher Server bei hoher Last, abbilden.

Diese Funktionen sind besonders interessant, da wir so als Dienstleister Stück für Stück Templates erarbeiten und zusammenstellen können, um sie den Anwendern zur Selbstbedienung anzubieten. Das erfordert nicht nur ein klares Verständnis der OpenStack-Technologie, sondern auch den engen Austausch mit Nutzern, im ersten Schritt insbesondere den DV-Beauftragten der HU. Ein erstes Szenario wird vielleicht eine Art Basis-Rechenzentrum sein, bei dem wir im Template Netzwerke, Sicherheitsregeln und Router definieren, anhand derer die DV-Beauftragten dann weitere Server anlegen und betreiben können.

OpenStack pflegt eine recht eigenständige Terminologie, die insbesondere für die Erstellung von Skripten unbedingt zu berücksichtigen ist.

So definiert OpenStack den Begriff „network“ rein als Layer-2 Broadcast Domain und den Begriff „subnet“ als Layer-3 IP-Block. Ein „port“ ist ein virtueller Switch-Port, bei den Firewall-Regeln jedoch auch eine Software-Schnittstelle für Anwendungen (z.B. Port 80-HTTP).

Ein „subnet“ wird „networks“ zugewiesen, IP-Adressen, DNS und Gateway-Adressen dem „subnet“ zugeordnet. Jedes virtuelle Gerät verbindet sich über einen „port“ mit den Netzwerk und so können auch schon an dieser Stelle zusätzliche Sicherheitsregeln und Zugriffsmechanismen festgelegt werden. In der Grafik unter

https://docs.hpcloud.com/content/documentation/media/networking_overview.jpg

ist dieser Zusammenhang noch einmal deutlicher dargestellt.

Ports sind bei OpenStack der zentrale Anschlusspunkt für Netze und Geräte und auch die zentrale Stelle für die Filterregeln.

Beim Aufbau eines virtuellen Serverraums mit OpenStack muss die Gesamtstruktur genauso geplant werden wie bei physischen Serverräumen auch, damit bei der Vielfalt an Komponenten nichts vergessen wird.

Wer OpenStack vorab schon im Web-Interface ausprobieren möchte, erzeugt sich ein erstes Setting über:

-> Compute -> Access -> KeyPair anlegen (für den Zugriff per SSH)
-> Compute -> Access -> Security Group anlegen (Bei den Filterregeln SSH und ICMP nicht vergessen)
-> Compute -> Access -> Allocate IP (damit man eine echte IP für das Projekt hat)
-> Network -> Network Create (Mit Subnet IP-Adressen, z.B. 192.168.0.0/24 und DNS 141.20.1.3)
-> Network -> Routers -> Create Router
-> Network -> Routers -> Set Gateway (für NAT zwischen dem privaten und öffentlichen Netz)
-> Compute -> Instances -> Launch Instances (Hier dann die gewünschten Server anlegen)
-> Compute -> Instances -> Instanz auswählen -> "Associate Floating IP"

Nach einer kurzen Prüfung, ob beim Anlegen der Instanz auch das richtige Schlüsselpaar und die Sicherheitsregeln übernommen wurden, sollte der Login per SSH problemlos funktionieren.

Im nächsten Beitrag soll ein kleiner Serverraum geplant und per Skript automatisiert aufgebaut werden.