ersten Jahren lag der Fokus sehr stark auf der Feature-Entwicklung und der Stabilisierung der Plattform, was wichtig für die breite Akzeptanz der Plattform war. Kubernetes und der Schwerpunkt auf Containerisierung führten auch zu einer Umorientierung bei OpenStack. Es herrscht aber nach wie vor ein starkes Interesse an OpenStack. Dieser Umstand ist vor allem dem Umstand zu verdanken, dass das grundsätzliche Problem von Infrastructure as a Service (IaaS) nicht verschwunden ist. Und OpenStack adressiert als einzige selbstständige und stabile Open Infrastructure Platform diesen Anwendungsfall besonders gut. Zudem hat sie sich der komplexen Aufgabe gewidmet, der Infrastruktur eine API zu geben. Diese wird in einem Multi-Tenant-System, also mandantenfähig, zur Verfügung gestellt. Dieser Herausforderung haben sich andere Technologien wie Kubernetes nicht gestellt, obwohl dieses viel Workload-näher wäre. Kubernetes tut sich ebenso schwer mit Einsatzbereichen wie Mandantenfähigkeit oder Workload Isolation. Kubernetes ist hingegen bei der Integration von API zur Produktivitätserhöhung viel besser geeignet, weil es sehr viel Workload-bezogener ist. Wenn Kubernetes auf OpenStack installiert wird, löst dies sowohl das Problem der Mandantenfähigkeit und sorgt zudem für die Workload-Isolierung.

OpenStack ist ein Open-Source-Projekt, das aus einer Reihe von Softwareelementen für die Erstellung von Cloud-Plattformen besteht. Also eine Sammlung von Programmen zum Aufbau einer Cloud-Umgebung. Bei Open Source ist der Quellcode der Software öffentlich verfügbar. Somit kann eine grosse Community an der Weiterentwicklung der Software mitarbeiten, was eine gute Weiterentwicklung garantiert. Durch Cloud-Computing ist das dezentrale Aufrufen von Programmen und Daten gemeint. Diese Umgebung ist vor fremdem Zugriff und Datenverlust zu schützen.
Eigentlich sollte es nicht OpenStack vs OpenShift heissen, sondern mit OpenShift. OpenShift ist eine Container-Plattform, die auf OpenStack betreiben werden kann. Diese ist von Red Hat entwickelt. Der Vorteil dabei ist, die Container-Technologie ist ressourcenintensiver und lässt sich einfacher verwalten.

OpenStack-Ansible bietet Ansible-Playbooks und -Rollen für die Bereitstellung und Konfiguration einer OpenStack-Umgebung. Die Einbindung des openstack-ansible-Repository in ein anderes Projekt kann auf verschiedene Arten erfolgen – mit git-Submodul oder durch automatisches Ausführen eines Git-Checkouts. Sie können zudem Ihre eigene Playbook-, Variablen- und Rollenstruktur erstellen, während Sie weiterhin die OpenStack-Ansible-Rollen und -Bibliotheken enthalten, indem Sie Umgebungsvariablen festlegen.

OpenStack Heat dient der Orchestrierung von OpenStack-Komponenten. Der Umgang mit OpenStack Heat kann für Private Clouds oftmals zu starr sein. Umgebungsdateien können dabei die Flexibilität bei der OpenStack-Konfiguration erhöhen. Denn OpenStack Heat stellt innerhalb des Cloud-Frameworks Orchestrierungsfunktionen zur Verfügung. Es arbeitet zur Orchestrierung von IaaS-Ressourcen mit Templates.

Bei OpenStack Swift – oder auch OpenStack Object Storage genannt – handelt es sich um ein Open-Source Objekt-Storage. Diese steht unter der Apache 2.0 Lizenz und läuft auf einer standardisierten Hardware. OpenStack Swift wird insbesondere für Backup und Archivierung unstrukturierter Daten, wie Dokumente, Bilder, Audio- und Video-Dateien, E-Mail sowie Abbilder virtueller Maschinen eingesetzt. Dabei werden Objekte und Dateien auf mehrere Festplatten geschrieben. Die Software sorgt dafür, dass die Daten über einen Server-Cluster verteilt repliziert wird. Dabei platziert Swift drei Kopien eines jeden Objekts als Standard an einem Ort, der so einzigartig wie möglich ist. Die Reihenfolge ist dabei Region, Zone, Server und dann Festplatte. Denn sollte ein Server oder eine Festplatte ausfallen, die Inhalte aus einem aktiven Node auf einen neuen Ort im Cluster. Das OpenStack Swift System lässt sich horizontal skalieren und der Zugriff erfolgt über ein „REST HTTP API“.

Ein Proxmox-Cluster vereinfacht für Anwender die komplexe Virtualisierungstechnik. Mit wenigen Klicks können ganze Herden virtueller Maschinen verwaltet werden – ohne dass man sich um deren Installation oder Partitionierung kümmern muss. Also könnten Einsteiger beim Vergleich OpenStack vs Proxmox es bei der zweiten Wahl wirklich einfacher haben. Denn es handelt sich dabei um eine komplette, auf Debian basierende Distribution, die es auch Virtualisierungslaien ermöglichen will, auf einfachste Art und Weise mit dieser Technik umzugehen. Es macht also durchaus Sinn, diese Option zu prüfen.

Wie sieht es nun bei OpenStack vs AWS aus? Als Public Clouds kommt auch Amazon Web Services (AWS) in Frage. Das ist eine Cloud-Umgebung, die typischerweise aus IT-Infrastrukturen erstellt werden, die dem Endnutzer gehörten. Heute haben Standort und Eigentum der Cloud ihre Bedeutung durch On-Premise-Service verloren. Bei Public Clouds fallen die Kosten typischerweise entsprechend der Nutzung an. Public Cloud-Nutzer haben praktisch unbegrenzten Zugriff auf Ressourcen, was jedoch zu höheren Betriebskosten führt.

Um für ein Test-Lab ein OpenStack auf eine virtuelle Maschine zu installieren, lesen Sie eine Anleitung und Installationstipps für die OpenStack Installation auf OpenStack Ubuntu. Hier kurz die wichtigsten Schritte:

• Aufbau einer grundlegenden Umgebung aus Datenbank und Host-Dateien
• Installation des Identity Service
• Installation des Image Service
• Installation des Compute Service
• Installation des Dashboards, um sich am lb-Interface anmelden zu können

Vor einigen Jahren gab es noch mehr als eine gleichwertige OpenStack-Alternative. Zu benennen wären beispielsweise: CloudStack, AzureStackEucalyptus, Nimbus, OpenNebula und vCloud. Heute jedoch fragen sich Cloud-Spezialisten, ob überhaupt ein einziger ernsthafter Konkurrent übriggeblieben ist. Denn OpenStack führt den Markt für Private Cloud ganz klar an. Alternativen wären aktuell: Noris Network, Grass-Merkur und Syntax. Diese bringen ebenfalls viele Jahre Erfahrung im Bereich Cloud-Computing mit.

Der OpenStack Neutron Server läuft als Dienst auf dem Netzwerkknoten, um die Networking API und ihre Erweiterungen zu bedienen. Dabei erzwingt es auch das Netzwerkmodell und die IP-Adressierung jedes Portes. Der Neutronenserver benötigt jedoch einen indirekten Zugriff auf eine persistente Datenbank, was durch Plugins geschieht. Die Plugins wiederum kommunizieren mit der Datenbank mit AMQP (Advanced Message Queuing Protocol).