Tilman Beitter arbeitete mehrere Jahre als Softwareentwickler im ERP-Bereich und ist seit 2010 mit großer Begeisterung für die B1 Systems GmbH als Linux Consultant und Trainer unterwegs. Seine Themenschwerpunkte sind Datenbanken und Cloud Computing, im Speziellen OpenStack und die darauf basierende SUSE-Cloud.
Thomas Kärgel ist seit 2012 Teil des B1-OpenStack-Teams. Der Open-Source-Enthusiast und Autodidakt beschäftigt sich seit mehr als 20 Jahren mit der Computerprogrammierung und Netzwerktechnik. Für die B1 Systems GmbH betreut er seit 2012 die SAP AG als Entwickler und Architekt für OpenStack.
André Nähring beschäftigt sich seit seinem Eintritt in die B1 Systems GmbH Anfang 2011 mit OpenStack. Davor sammelte er viele Jahre Erfahrungen als Administrator heterogener Netzwerke und kennt somit genügend Szenarien für Anforderungen und Integrationsmöglichkeiten von OpenStack. Heute ist er mit Begeisterung als Trainer und Solution Architect im Bereich OpenStack für die B1 Systems GmbH unterwegs.
Andreas Steil befasst sich neben Cloud Computing schwerpunktmäßig mit Netzwerktechnik und Virtualisierung. Er ist seit 2010 bei der B1 Systems GmbH als Linux Consultant und Trainer beschäftigt. Zuvor arbeitete er 16 Jahre freiberuflich als Netzwerkadministrator und Trainer.
Sebastian Zielenski ist seit 2008 bei der B1 Systems GmbH als Linux Consultant und Trainer beschäftigt. Davor arbeitete er viele Jahre als Unix-/Linux-Administrator und Trainer. Seine Spezialthemen, in denen er auch Kunden berät und schult, liegen im Bereich Virtualisierung und Storage. Seit 2011 beschäftigt sich Sebastian Zielenski mit OpenStack und hat auf diesem Gebiet diverse Kunden beraten und Kundenprojekte durchgeführt.
Cloud Computing in der Praxis
Tilman Beitter
Thomas Kärgel
André Nähring
Andreas Steil
Sebastian Zielenski
openstack-buch@b1-systems.de
Lektorat: Dr. Michael Barabas
Copy Editing: Ursula Zimpfer, Herrenberg
Satz: Da-TeX, Leipzig
Herstellung: Frank Heidt
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN
Buch 978-3-86490-038-9
PDF 978-3-86491-549-9
ePub 978-3-86491-550-5
1. Auflage
Copyright © 2014 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.de/plus |
Seit dem ersten Release gewinnt OpenStack zunehmend an Bedeutung. Dank seiner offenen Architektur hat OpenStack schnell Enterprise-Kunden gefunden und damit bereits eine wachsende Community geschaffen.
B1 Systems war der erste OpenStack-Partner in Deutschland und hat schon sehr früh erfolgreiche Projekte durchgeführt. Da das Unternehmen mit den vielschichtigen Anforderungen seiner deutschen Enterprise-Kunden vertraut ist, konnte es einen aktiven Entwicklungsbeitrag zur Community leisten und sich nachhaltig in die Weiterentwicklung von OpenStack einbringen.
OpenStack ist heute vielseitig einsetzbar. Es umfasst ein Cloud-Management-Framework für IT-Abteilungen, das die Best Practices der anspruchsvollsten Cloud-Service-Provider beinhaltet. Darüber hinaus bietet es mit jedem Release weitere Features, die für eine gute Positionierung im Wettbewerb sorgen.
Dieses Buch ermöglicht dem Leser, von den Erfahrungen zu profitieren, die B1 Systems zusammen mit seinen Kunden sammeln konnte. Es vermittelt ein grundlegendes Verständnis über die Basisarchitektur von OpenStack, die Funktionsweise der einzelnen Module und erlaubt einen Einblick in die detaillierten Konfigurationsoptionen. Hinweise zum praktischen Einsatz, zu den Voraussetzungen für einen globalen Scale-out und ein Ausblick zu kommenden Releases runden das Thema ab.
Als Leiter einer strategischen Cloud-Initiative mit den herausfordernden Zielen eines globalen Unternehmens kann es manchmal recht hektisch werden. Oft gibt es mehr als einen Lösungsweg. Daher war es für mich immer beruhigend, B1 Systems als starken Lösungspartner an meiner Seite zu haben.
Ich hoffe, mit dem vorliegenden Buch ist es auch anderen Firmen möglich, einen Einstieg in das spannende Umfeld des Cloud Computing zu finden und in die Welt von OpenStack einzutauchen.
Claus-Henning Cappell, MBA
Senior Architect, Cloud Infrastructure Delivery, SAP AG
Dieses Buch richtet sich in erster Linie an Systemadministratoren, die vom Sammeln erster Erfahrungen über das Erarbeiten von Proof-of-Concepts bis hin zum produktiven Einsatz einer OpenStack-Umgebung gelangen wollen. Als Leser sollten Sie über fortgeschrittene Kenntnisse der System- und Netzwerkadministration unter Linux verfügen. Ein Grundverständnis der Virtualisierung – speziell Erfahrungen mit KVM und/oder Xen – sollte ebenfalls vorhanden sein.
Das Durcharbeiten des Buches versetzt Sie in die Lage, OpenStack und dessen Architektur zu verstehen und mögliche Einsatzszenarien für OpenStack zu identifizieren. Das Buch zeigt weiterhin, wie Sie die Kern-komponenten von OpenStack mit ihren Services installieren und konfigurieren, wie Sie Instanzen (= virtuelle Maschinen in der Cloud) anlegen und mit Storage und Netzwerk verbinden, wie Sie für Kunden Tenants, Benutzer, Rollen und ACLs einrichten und verwalten und vieles mehr. Was das Buch nicht leisten kann, ist, dass alle möglichen Setup-Szenarien durchgespielt und sämtliche Konfigurationsoptionen erklärt werden. Allein die zentrale Konfigurationsdatei der IAAS-Komponente Nova beispielsweise kennt mehrere Hundert Optionen, sodass nur die jeweils wichtigsten und gebräuchlichsten Einstellungen aufgeführt werden.
Das Interesse an OpenStack wächst seit Jahren. Fast überall in der IT-Welt ist »Cloud« zu einem zentralen Thema geworden. OpenStack ist die momentan einzige freie Softwarelösung für IaaS-Clouds, die den proprietären Cloud-Anbietern mit zunehmendem Erfolg ernsthafte Konkurrenz bietet. Bisher gab es noch kein deutschsprachiges Buch zu OpenStack.
Die B1 Systems setzt OpenStack seit 2011 erfolgreich bei Kunden ein, bietet Consulting, Support, Schulungen und Entwicklung für OpenStack an, stellt Pakete für OpenStack in Repositories bereit und arbeitet aktiv an der Entwicklung von OpenStack mit.1 Wir profitieren von der Arbeit der Community und wollen selbst etwas beitragen. Mit diesem Buch geben wir gerne gesammelte Erfahrungen und erworbenes Wissen weiter und freuen uns, wenn wir Ihnen auf Ihrem Weg mit OpenStack behilflich sein können.
Nach einführenden Kapiteln zu Grundlagen des Cloud Computing und von OpenStack (Einführung, Infrastruktur) richtet sich der weitere Aufbau nach den einzelnen OpenStack-Kernkomponenten (Keystone, Glance, Nova, Cinder, Neutron, Horizon, Ceilometer, Heat, Swift), denen jeweils ein eigenes Kapitel gewidmet ist. Die Reihenfolge entspricht dabei im Wesentlichen der Reihenfolge, in der die Komponenten beim manuellen Aufbau einer OpenStack-Umgebung eingerichtet werden. Die Kapitel zu einzelnen Komponenten selbst gliedern sich meist in einen einleitenden Abschnitt, in dem Begriffe und Funktionsweise geklärt werden, gefolgt von jeweils einem Abschnitt zu Installation, Konfiguration und Administration der Komponente. Schließlich folgen noch ein Kapitel zu weiteren Komponenten von OpenStack, ein Kapitel, das sich konkreten Setups (Single-Node-Setups, Multi-Node-Setups) widmet und ein Anhang als Sammelbecken für weitere Informationen zum Nachschlagen (Openstackclient, Community, Configuration Management, Portliste, Abkürzungen).
Die Kapitel im Einzelnen:
Einführung (Kapitel 1, S. 1)
klärt den Begriff »Cloud« und ordnet OpenStack in den Wolkenhimmel ein. Es beschreibt die Ursprünge des Projekts und wie es eine solch rasante Entwicklung nahm.
Infrastruktur (Kapitel 2, S. 15)
stellt kurz die einzelnen OpenStack-Komponenten, deren Funktion und Zusammenarbeit vor, um einen Überblick über die anfänglich leicht verwirrende Vielzahl der beteiligten Komponenten zu bieten.
Identity Service – Keystone (Kapitel 3, S. 29)
zeigt die Einrichtung der Rechtestruktur für eine reibungslose Interaktion der Komponenten, die Verwaltung der Benutzer und deren Rechte, von Rollen und Tenants sowie die Anbindung an bestehende Benutzerverwaltungen – Stichwort LDAP.
Image Service – Glance (Kapitel 4, S. 69)
beschäftigt sich mit den Images, die als Basis für die virtuellen Instanzen der Cloud dienen. Das Kapitel zeigt Installation, Konfiguration und Administration des Image Service Glance und wie Sie Images erstellen und in den OpenStack-Kontext einbinden.
Compute Service – Nova (Kapitel 5, S. 93)
zeigt den zentralen Compute Service, der mithilfe eines Hypervisors für die Bereitstellung und Verwaltung der Cloud-Gäste, der Computersysteme innerhalb der Cloud, sorgt. Nach Klärung von Begriffen, Funktionsweise und Konzepten werden Installation, Konfiguration und Administration von Nova vorgestellt. Auch die Live-Migration eines laufenden Cloud-Gastes von einem Host wird kurz gezeigt.
Block Storage – Cinder (Kapitel 6, S. 147)
beschäftigt sich nach einer kurzen Vorstellung der vielen Storage-Möglichkeiten bei OpenStack im Wesentlichen mit dem Einrichten von Cinder, der den Cloud-Gästen Block Storage auch zur dauerhaften Speicherung ihrer Daten bereitstellt.
Network Service – Neutron (Kapitel 7, S. 167)
beschäftigt sich mit Konzeption und Einrichtung der Netzwerkdienste auf Basis von Neutron. Es klärt Fragen, wie die Kommunikation der beteiligten Nodes untereinander und mit der Außenwelt stattfindet. Dazu gehört auch die sicherheitsrelevante Trennung der Kundennetze und das Anbieten weiterer Netzdienste wie Firewall as a Service (FWaaS) und Load Balancing as a Service (LBaaS). Ein Ausflug in die neue Welt der virtuellen Switches mit Open vSwitch, die die Möglichkeiten zur Netzanbindung der virtuellen Instanzen enorm erweitern, bleibt nicht ausgespart.
Dashboard – Horizon (Kapitel 8, S. 227)
Dashboard ist eine browsergestützte Oberfläche, die Anwendern und Endkunden eine einfache Bedienung und Verwaltung ihrer Cloud-Ressourcen ermöglicht – ohne tiefere Kenntnis von Konsolenbefehlen und deren Argumenten.
Telemetry – Ceilometer (Kapitel 9, S. 233)
Das Kapitel beschreibt die Möglichkeiten und den Einsatz der neuen Komponente Ceilometer für den Metering- und Monitoring-Service, mit dem die Nutzung der Cloud-Ressourcen erfasst und ausgewertet werden kann. Damit wird die Überwachung der genutzten Ressourcen und deren Abrechnung beim Kunden wesentlich erleichtert.
Orchestrierung – Heat (Kapitel 10, S. 259)
Heat ist eine ebenfalls noch recht neue Komponente, die es ermöglicht, mehrere Instanzen gleichzeitig bis hin zu ganzen »Serverfarmen« auszurollen. Das Kapitel zeigt das Werkzeug zur Orchestrierung von Cloud-Gästen bis hin zum Autoscaling, einer Funktion zur automatischen Skalierung von Ressourcen.
Object Storage – Swift (Kapitel 11, S. 285)
gibt eine Übersicht über Aufbau und Funktionsweise eines Object Storage und zeigt die grundlegende Installation, Konfiguration sowie Administration von Swift.
Weitere Komponenten (Kapitel 12, S. 299)
liefert Informationen zu Nicht-OpenStack-Komponenten und bietet einen Ausblick auf kommende Projekte: »Ironic« für die Bare-Metal-Provisionierung, den Message Queuing Service »Marconi« und »Trove«, das Database as a Service bietet.
Setup-Szenarien (Kapitel 13, S. 321)
stellt mögliche Setup-Szenarien vor. Von einfachen Single-Node-Setups, die sich zum Ausprobieren und Testen der meisten zuvor vorgestellten Komponenten und Funktionen eignen, bis hin zu komplexen, hochverfügbaren Multi-Node-Umgebungen werden hier mögliche Setup-Szenarien erarbeitet. Eine ausführliche Installationsbeschreibung auf Basis von SLES zeigt Schritt für Schritt alle Stufen zum Einrichten der Kernkomponenten. Wenn Sie schnell und einfach eine lauffähige OpenStack-Umgebung einrichten wollen, bieten sich automatisierte Installationen per Skript an (Pack-Stack und DevStack, S. 343 ff.).
Anhang (Kapitel 14, S. 349)
Der Anhang beschreibt Komponenten, die entweder keine eigenen OpenStack-Projekte sind und/oder für die ein eigenes Kapitel den Rahmen des Buches gesprengt hätte. Dazu gehören der Messaging Service RabbitMQ, das Dateisystem Ceph und die Datenbank MySQL. Eine Liste mit den Services und Ports und eine Übersichtstabelle mit den neuen OpenStack-Client-Befehlen dient zum Nachschlagen. Abgerundet wird das Kapitel mit einem Abschnitt zur Community, der zeigt, wo Sie Hilfe bekommen und wie Sie sich an der Weiterentwicklung von OpenStack beteiligen können.
Folgende typografische Konventionen finden in diesem Buch Verwendung:
Kursivschrift
für Eigennamen, Fachbegriffe und Hervorhebungen
Nichtproportionalschrift
für Konsolenausgaben, Datei- & Paket- und Variablennamen, URLs
Marginalien
für ergänzende Bemerkungen, Verweise auf weitere Informationen.
Neu eingeführte Begriffe werden bei ihrer ersten Nennung ebenfalls kursiv dargestellt.
Bei den Befehlseingaben werden die häufig vorkommenden IDs als Parameterwerte normalerweise entweder mit Variablen oder durch in spitze Klammern eingefasste Feldwerte abstrahiert. So wird beispielsweise aus einem:
# keystone user-password-update \
--pass adminpw 3a4a01c6fd8b4bd1bba4eaf3209fc386
... ein:
# keystone user-password-update --pass adminpw <BENUTZER_ID>
... oder – in der Variablenversion – ein:
# keystone user-password-update --pass adminpw $benutzer-id
Auch die anderen umgebungsspezifischen Werte wurden im Regelfall durch einen allgemeinen Platzhalter in spitzen Klammern (<WERT>) ersetzt.
Ein Abkürzungsverzeichnis am Ende des Buches erleichtert das Nachschlagen.
Ein so komplexes, hochdynamisches und weitreichendes Software-projekt wie OpenStack lässt sich in einem einzigen Buch unmöglich erschöpfend behandeln. Wir verweisen daher an einigen Stellen, meist am Ende eines Abschnitts, auf weiterführende Links für aktuelle und tiefergehende Informationen. Wichtigste Informationsquelle sind die Angebote der OpenStack-Community selbst (siehe auch 14.2 ab S. 351).
Wir danken allen Kollegen bei der B1 Systems, die zu diesem Buch direkt oder indirekt beigetragen und es dadurch ermöglicht haben.
Weiterhin bedanken wir uns beim dpunkt.verlag und Dr. Michael Barabas für die gute Zusammenarbeit und bei Ursula Zimpfer für das professionelle Lektorat.
Last but not least bedanken wir uns bei der Community, die freie Software wie GNU/Linux und OpenStack geschaffen hat.
1 Einführung
1.1 Was ist Cloud Computing?
1.1.1 Anwendungsfälle
1.1.2 Definition: Cloud Computing
1.2 OpenStack
1.2.1 Entstehung
1.2.2 Versionshistorie
1.2.3 Einordnung in das NIST-Modell
1.2.4 Der Entwicklungsweg
1.2.5 Die Gemeinschaft
2 Infrastruktur
2.1 Messaging Service
2.1.1 AMQP
2.1.2 RabbitMQ
2.1.3 Apache Qpid
2.1.4 ZeroMQ
2.1.5 Marconi
2.2 Datenbank
2.2.1 SQLite
2.2.2 MySQL/MariaDB
2.2.3 PostgreSQL
2.3 Keystone – Identity Service
2.4 Glance – Image Service
2.5 Swift – Object Storage
2.6 Cinder – Block Storage
2.7 Nova – Compute Service
2.7.1 Nova Compute
2.7.2 Nova-API
2.7.3 Nova Conductor
2.8 Neutron – Networking Service
2.8.1 Neutron-Server
2.8.2 Neutron Network Node
2.9 Horizon – Dashboard
2.9.1 Administrator
2.9.2 Benutzer
2.10 Ceilometer – Telemetry
2.11 Heat – Orchestration
3 Identity Service – Keystone
3.1 Funktionsweise
3.1.1 Backends
3.2 Begriffe
3.2.1 User
3.2.2 Project/Tenant
3.2.3 Domain
3.2.4 Groups
3.2.5 Roles
3.2.6 Service
3.2.7 Endpoint
3.2.8 Catalog
3.2.9 Credentials
3.2.10 Token
3.2.11 Public Key Infrastructure
3.2.12 Policy
3.3 Installation
3.3.1 Datenbank
3.3.2 Firewall
3.3.3 Paketinstallation
3.4 Konfiguration
3.4.1 SQL-Datenbank
3.4.2 LDAP als Backend
3.4.3 SSL-Verschlüsselung
3.4.4 PKI-Setup
3.4.5 Service Catalog
3.4.6 Template File
3.4.7 Admin-Token
3.4.8 Initiale Daten
3.5 Administration
3.5.1 Allgemeines
3.5.2 Der Keystone-Client
3.5.3 Tenants verwalten
3.5.4 Benutzer verwalten
3.5.5 Rollen verwalten
3.5.6 Services verwalten
3.5.7 Endpunkte verwalten
3.5.8 Anwendungsbeispiel API
3.5.9 Anwendungsbeispiele API v3
4 Image Service – Glance
4.1 Begriffe und Funktionsweise
4.1.1 Speicherorte für Imagedateien
4.1.2 Image-Formate
4.1.3 Container-Formate
4.1.4 Metadaten
4.1.5 Virtual Machine Images
4.2 Installation
4.3 Konfiguration
4.3.1 Glance-API
4.3.2 Glance-Registry
4.3.3 Richtlinien (Policies)
4.4 Administration
4.4.1 Der Glance-Client
4.4.2 Images registrieren
4.4.3 Metadaten für Images
4.4.4 Imagedateien identifizieren
4.4.5 Images aufräumen
4.5 Werkzeuge für Images
4.5.1 Tools zum Erstellen von Images
4.5.2 File Injection
5 Compute Service – Nova
5.1 Begriffe und Funktionsweise
5.1.1 Bestandteile von Nova
5.1.2 API
5.1.3 Cloud Controller
5.1.4 Compute Service und Compute Nodes
5.1.5 Scheduler
5.1.6 Network Controller
5.1.7 Conductor
5.1.8 Rollenbasierte Zugriffsrechte (RBAC)
5.1.9 Security Groups
5.1.10 Regions
5.1.11 Availability Zones
5.1.12 Compute Cells
5.1.13 Host Aggregates
5.1.14 Metadata Service
5.1.15 Start einer Instanz
5.1.16 Erweiterung einer OpenStack-Umgebung
5.2 Virtualisierung
5.2.1 Hypervisoren
5.2.2 Parallelbetrieb mehrerer Hypervisoren
5.2.3 Verschachtelte Virtualisierung (Nested Virtualization)
5.3 Installation
5.3.1 Controller Node
5.3.2 Compute Node
5.4 Konfiguration
5.4.1 Nova-API
5.4.2 Nova Compute
5.4.3 Nova Scheduler
5.4.4 Storage-Anbindung
5.4.5 Netzwerkanbindung
5.4.6 Conductor
5.4.7 Remote-Konsolen
5.4.8 Logging
5.4.9 Quotas
5.4.10 Metadata Service
5.5 Administration
5.5.1 Der Nova-Client
5.5.2 Statusausgaben
5.5.3 Umgang mit Images
5.5.4 Flavors verwalten
5.5.5 Hinterlegen eines SSH-Keys
5.5.6 Instanzen verwalten mit Nova
5.5.7 Host Aggregate
5.5.8 VNC-Konsole
5.5.9 Quotas
5.5.10 Security Groups
5.5.11 Weitere Nova-Befehle
5.5.12 Metadata Service
5.6 Migration und Rootwrap
5.6.1 Live-Migration
5.6.2 Rootwrap
6 Block Storage – Cinder
6.1 Begriffe und Funktionsweise
6.1.1 File Storage
6.1.2 Object Storage
6.1.3 Block Storage
6.1.4 Cinder-API und Storage Backends
6.1.5 Storage Backends
6.2 Installation
6.3 Konfiguration
6.3.1 Datenbank
6.3.2 Konfigurationsdateien von Cinder
6.4 Administration
6.4.1 Der Cinder-Client
6.4.2 Volumes
6.4.3 Quotas
6.4.4 Nova-CLI-Befehle – Volumes
6.4.5 Volumes beim Booten
6.5 Weitere Informationen
7 Network Service – Neutron
7.1 Begriffe und Funktionsweise
7.1.1 Schnittstellen – PIFs, VIFs und Ports
7.1.2 IP-Adressierung – Fixed und Floating IPs
7.1.3 Netzwerke
7.1.4 Agents
7.1.5 Plug-ins
7.1.6 Security Groups
7.1.7 Software-defined Networking (SDN)
7.1.8 VLANs und GREs
7.1.9 Namespaces
7.1.10 Komponenten
7.2 Anwendungsbeispiele
7.2.1 Single Flat Network
7.2.2 Multiple Flat Network
7.2.3 Mixed Flat and Private Network
7.2.4 Provider Router with Private Networks
7.2.5 Per-tenant Routers with Private Networks
7.3 Installation
7.4 Konfiguration
7.4.1 Grundkonfiguration von Neutron
7.4.2 Konfiguration der Plug-ins von Neutron
7.4.3 Open vSwitch
7.4.4 Neutron-DHCP-Agent
7.4.5 Neutron-L3-Agent
7.4.6 Weitere Konfiguration von Neutron
7.4.7 Namespaces
7.5 Administration
7.5.1 Der Neutron-Client
7.5.2 Netzwerke
7.5.3 Agents
7.5.4 Plug-ins
7.5.5 Ports
7.5.6 Floating IPs
7.5.7 Quotas
7.5.8 Router
7.5.9 Security Groups und Security Group Rules
7.5.10 Einbinden einer Instanz beim Booten
7.5.11 Namespaces
7.5.12 Firewall as a Service (FWaaS)
7.5.13 Load Balancing as a Service (LBaaS)
7.5.14 Allowed-Address-Pairs
7.5.15 Metadata Service
7.6 Dnsmasq
7.6.1 Konfigurationsdateien von Dnsmasq
8 Dashboard – Horizon
8.1 Installation und Konfiguration von Horizon
8.2 Administration mit Horizon
8.3 Customizing von Horizon
8.3.1 Links und Quellen zum Customizing von Horizon:
9 Telemetry – Ceilometer
9.1 Funktionsweise
9.1.1 Komponenten
9.2 Begriffserklärung
9.3 Installation
9.4 Konfiguration
9.4.1 Keystone
9.4.2 Message-Bus
9.4.3 Datenbank
9.4.4 Anbindung von Nova
9.4.5 Dienste
9.5 Administration
9.5.1 Meter
9.5.2 Ressourcen
9.5.3 Samples
9.5.4 Statistiken
9.5.5 Alarme
9.5.6 API-Beispiel
9.6 Weiterführende Links und Quellen
10 Orchestrierung – Heat
10.1 Begriffe und Funktionsweise
10.1.1 Ressourcen
10.1.2 Stacks
10.1.3 Templates
10.1.4 Komponenten
10.2 Installation
10.3 Konfiguration
10.3.1 Keystone-Setup
10.3.2 Datenbank
10.3.3 Weitere Konfiguration
10.3.4 Starten der Dienste
10.4 Templates
10.4.1 HOT
10.4.2 CFN
10.5 Administration
10.5.1 Der Heat-Client
10.5.2 Autoscaling
11 Object Storage – Swift
11.1 Object Storage
11.2 Architektur
11.2.1 Ringe, Mappings und Zonen
11.3 Dateisysteme für Swift
11.4 Installation
11.5 Konfiguration
11.5.1 Keystone-Anbindung
11.5.2 Erstellen der Ringe
11.6 Konfiguration als Backend für Glance
11.7 Administration von Swift
12 Weitere Komponenten
12.1 Datenbanken
12.1.1 MySQL/MariaDB – Allgemeines
12.1.2 mysqladmin
12.1.3 Datenbank-Backups
12.1.4 MongoDB
12.2 AMQP
12.2.1 RabbitMQ
12.2.2 Apache Qpid
12.2.3 ZeroMQ
12.3 Ceph
12.3.1 Ceph – ein paar Grundlagen
12.3.2 Ceph-Storage-Plattformen
12.3.3 Ceph Block Storage – RADOS Block Device (RBD)
12.4 Ironic
12.5 Sahara
12.6 Trove
12.7 Marconi
13 Setup-Szenarien
13.1 Single-Node-Setup
13.1.1 SLES
13.1.2 DevStack
13.2 Multi-Node-Setups
13.2.1 Compute Nodes
13.2.2 Network Controller
13.2.3 Storage Nodes
14 Anhang
14.1 Openstackclient
14.1.1 Anwendungsbeispiele
14.2 Community
14.2.1 Dokumentation und Wiki
14.2.2 Mitarbeit an OpenStack
14.2.3 Deployments
14.2.4 Python-Skripte
14.3 Configuration Management
14.3.1 CloudInit
14.3.2 Chef
14.3.3 Puppet
14.3.4 SaltStack
14.3.5 Ansible
14.3.6 Fuel
14.3.7 Crowbar
14.4 Services und Ports
Abkürzungen
Index
Seit einigen Jahren findet sich der Ausdruck Cloud Computing in der Fachwelt, die Verbreitung in den allgemeinen Sprachgebrauch wurde schließlich auch durch die Werbung großer Internet Service Provider vorangetrieben. Doch was bedeutet das genau?
Im IT-Umfeld meint eine Cloud oft zwei verschiedene Dinge:
Abb. 1-1 Cloud Computing – Übersicht
Im Folgenden werden zwei gängige Anwendungsfälle der Cloud für Endanwender vorgestellt.
Ein Kunde nutzt einen Webmail-Anbieter für seinen E-Mail-Zugang und somit den vom Anbieter bereitgestellten Speicherplatz. Ein Teil des Platzes ist dem Postfach des Kunden zugeordnet. Bei der Nutzung entstehen weitere Daten und belegen den Speicher, bis dieser ausgeschöpft ist. Der Anbieter stellt nun zusätzlichen Speicherplatz für den Kunden bereit. Dieser zusätzlich genutzte Speicherplatz wird protokolliert und dem Kunden unter Umständen in Rechnung gestellt.
Ein Kunde ist also ein Verbraucher, der sich an bereitgestellten Ressourcen bedient. Das Postfach läuft voll und der zur Verfügung stehende Speicherplatz wird automatisch erweitert. Dabei wird der neue, zusätzlich benötigte Speicherplatz aus einem Pool genommen. Solch ein Pool enthält Ressourcen, die von anderen Systemen zur Verfügung gestellt werden, und kann von unterschiedlichen Anbietern beansprucht werden. Wäre das Postfach eines anderen Kunden zuerst vollgelaufen, hätte dieser den entsprechenden Speicher bekommen. Es werden also gemeinsam genutzte Ressourcen verteilt. Dabei wird die Nutzung der Ressourcen, der eigentliche Verbrauch, automatisch überwacht und protokolliert. Selbstverständlich kann hier auch eine Kontrolle erfolgen (buchhalterisch ausgedrückt: Erst wenn die Rechnungen des Kunden bezahlt wurden, bekommt er neuen Speicherplatz).
Viele Hosting-Anbieter stellen ihren Kunden mittlerweile Lösungen dieser Art zur Verfügung. Auch große Service-Provider haben inzwischen ein entsprechendes Angebot.
Die Cloud hingegen, die nicht nur den Speicherplatz, sondern auch weitere Ressourcen zur Verfügung stellt, macht dies mit virtuellen Maschinen1. Diese virtuellen Maschinen können mit einer vollständigen Konfiguration eines Betriebssystems auf Anforderung gestartet werden. Hier besteht die Möglichkeit, dass lediglich ein Betriebssystem als Basis für eine virtuelle Maschine angeboten wird. Es können aber auch vollständig konfigurierte Anwendungen bereitgestellt werden.
Ein Onlinekaufhaus bietet in einer Werbeaktion ein sehr gefragtes Produkt günstig an. Daraufhin nehmen die Besuche auf der Plattform des Anbieters in kürzester Zeit rasant zu, die vorhandenen Webserver können die Anfragen nicht mehr abarbeiten. Genau für diese Auslastung startet der Betreiber nun virtuelle Maschinen in seiner Cloud, die über eine Anbindung ans Netzwerk verfügen, ein Betriebssystem starten und einen konfigurierten Webserver bereitstellen. Auf diese nun zusätzlich vorhandenen Webserver können die neuen Anfragen verteilt werden. Ist das Angebot nicht mehr gültig oder die Besucherzahlen flauen ab, beendet der Anbieter die virtuellen Maschinen wieder.
Ein alternatives Einsatzgebiet ist das Testen von Software auf unterschiedlichen Betriebssystemen. Mithilfe einer Cloud können verschiedene Betriebssystemabbilder vorgehalten werden. Auf Knopfdruck startet ein ausgewähltes Betriebssystem in einer virtuellen Maschine (VM). Dort finden nun Softwaretests statt. Nach deren Beendigung wird die Instanz beendet und ein anderes Betriebssystem gestartet. Je nach Anforderung der Testumgebung (z. B. Festplattenplatz, Hauptspeicher oder Anzahl der Netzwerkkarten) können diese Ressourcen angepasst werden. So können verschiedene Anforderungen kurzfristig erfüllt werden; die Hardware kann dadurch optimal ausgenutzt werden und es muss nicht für jede Möglichkeit passende Hardware vorgehalten werden.
Das National Institute of Standards and Technology (NIST) in den USA hat eine allgemeingültige Definition2 von Cloud Computing vorgestellt. Diese wird auch vom deutschen BSI (Bundesamt für Sicherheit in der Informationstechnik) als Grundlage für seine Definition einer Cloud verwendet und auch die ENISA (European Network and Information Security Agency) nutzt die Formulierung des NIST.
Danach umschreibt Cloud Computing ein Modell, um auf einfache Art und Weise auf geteilte Ressourcen von Computern zuzugreifen. Hierbei kann es sich um Netzwerk, Speicher, Anwendungen oder sonstige Serverdienste handeln. Diese Ressourcen können schnell angefordert, genutzt und freigegeben werden. Der entsprechende Service-anbieter wird, wenn überhaupt, nur minimalen Aufwand betreiben müssen, um die Ressourcen zu verwalten.
Außerdem definiert das NIST die wesentlichen Merkmale, Servicemodelle und Verwendungsmodelle von Cloud Computing.
Laut der NIST-Definition existieren fünf essenzielle Charaktermerkmale einer Cloud:
On-demand Self Service
Ein Kunde kann die von ihm genutzten Ressourcen verwalten. Dies betrifft z. B. Speicherplatz. Eine manuelle Aktion des Service-Providers ist nicht notwendig, der Kunde kann rund um die Uhr, an allen Tagen, auf die Ressourcen zugreifen und diese per API-Zugriffen verwalten. »Verwalten« bedeutet in diesem Zusammenhang, dass der Kunde in der Lage ist, Ressourcen anzufordern, einzubinden und freizugeben.
Broad Network Access
Ressourcen sind über ein Netzwerk erreichbar und können über Standardmechanismen über das Netzwerk verwaltet werden.
Resource Pooling
Die verfügbaren Ressourcen eines Anbieters werden als gemeinsame Basis für mehrere Kunden genutzt. Physikalische und virtuelle Ressourcen können dynamisch erweitert oder verringert werden. Ein Kunde benötigt kein Wissen über den geografischen Standort seiner Ressourcen. Diese können über Landesgrenzen hinweg verteilt werden.
Rapid Elasticity
Die zur Verfügung stehenden Ressourcen können je nach Anforderung hinzugefügt oder entfernt werden. Dies kann in einigen Fällen automatisch geschehen, sodass die Ressourcen automatisch reguliert und optimiert werden können. Durch diese Möglichkeiten erscheinen den Kunden die Ressourcen als unbegrenzt vorhanden.
Measured Service
Die genutzten Ressourcen werden gemessen und können korrekt abgerechnet werden.
Die zur Verfügung stehenden Ressourcen können über unterschiedliche Servicemodelle genutzt werden.
Software as a Service (SaaS)
Die vom Anbieter zur Verfügung gestellten Anwendungen stehen über ein schlankes Clientinterface bereit. Der Kunde nutzt die Anwendung eines Anbieters, also z. B. ein Wiki. Beispiele für solche Anwendungen sind z. B. Google Apps, Web-Conferencing-Lösungen und Imaging/Printing-Lösungen.
Platform as a Service (PaaS)
Hier werden Kunden z. B. bestimmte Plattformen wie TomCat o.ä. zur Verfügung gestellt. Im Gegensatz zur SaaS-Cloud sind die Anwendungen eigentlich für Entwickler gedacht und nicht für Endanwender. Die Kunden kümmern sich nicht um die darunter befindlichen Ressourcen wie Netzwerk, Speicher etc. Anbieter für PaaS sind u. a. Microsoft mit Azure und die Google App Engine.
Infrastructure as a Service (IaaS)
Hier wird dem Kunden die benötigte Infrastruktur zur Verfügung gestellt; dies betrifft Netzwerk, Speicher, Rechenleistung etc. Als Beispiele seien Amazon Web Services oder OpenStack genannt.
Abb. 1-2 Cloud Computing – Servicemodelle
Zusätzlich zu den Servicemodellen werden unterschiedliche Verwendungsmodelle definiert. Diese unterscheiden sich je nach Einsatzgebiet:
Private Cloud
Die zur Verfügung gestellten Ressourcen werden exklusiv von einer Organisation genutzt. Hierbei kann es sich beispielsweise um die Bereitstellung der Hardware (und somit der Ressourcen) im eigenen Rechenzentrum handeln. Die Ressourcen werden nicht öffentlich zugänglich gemacht, sie stehen exklusiv nur einer Firma zur Verfügung.
Community Cloud
Die Nutzung der Ressourcen ist für eine bestimmte Community gedacht, die als Kunde auftritt und somit die Ressourcen nutzt. Dabei kannn die Community aus mehreren Organisationen bestehen. Hier kann die Cloud einer Organisation gehören oder von ihr verwaltet werden.
Public Cloud
Eine Organisation kann die Ressourcen dieser Cloud nutzen. Einem Anwender ist nicht bekannt, mit wem er die Ressourcen gerade teilt (z. B. wessen virtuelle Maschinen auf demselben Host laufen, auf dem nun die eigenen VMs gestartet wurden).
Hybrid Cloud
Hierbei werden zwei der bereits erwähnten Verwendungsmodelle verschmolzen, so wird eine öffentliche mit einer privaten Cloud vereint. Somit kann eine private Cloud, die ihre Ressourcen bereits alle zur Verfügung stellt und keine weiteren mehr bereitstellen kann, durch die Anbindung einer öffentlichen Cloud zur einer hybriden Cloud werden. Hier werden dann neue Ressourcen in der öffentlichen Cloud gebucht und verwendet.
Je nach Einsatzzweck und gewünschter Verwendung wird nun aus den entsprechenden Typen gewählt. Unternehmen nutzen vielfach zur Bereitstellung interner Cloud-Strukturen nur eine private Cloud, damit sowohl Kontrolle als auch Daten im eigenen Haus bleiben. Wird eine private Cloud im eigenen Rechenzentrum betrieben und müssen z. B. zur Weihnachtszeit Lastspitzen aufgefangen werden, so kann auf einen externen Anbieter zurückgegriffen werden und die private Cloud zu einer hybriden Cloud erweitert werden. Ist die zusätzliche Last wieder verschwunden, wird nur noch die private Cloud genutzt.
Datensicherheit und Datenschutz spielen bei der Auswahl des korrekten Modells eine wichtige Rolle. Diese Kriterien müssen vor Nutzung einer Cloud berücksichtigt werden.
OpenStack ist eine Open-Source-Software zur Erstellung privater, öffentlicher und hybrider Clouds, mit der Infrastructure as a Service angeboten werden kann.
Dabei können große Pools von Ressourcen verwaltet werden. Die Verwaltung erfolgt über RESTful APIs. Diese können selbstverständlich auch per Weboberfläche angesprochen werden.
OpenStack sieht sich als Cloud Operating System, das aus unterschiedlichen Komponenten besteht, die verschiedene Aufgaben erfüllen. Allerdings sind die Komponenten so aufeinander abgestimmt, dass sie sehr gut miteinander arbeiten können. Eine detaillierte Aufstellung der einzelnen Komponenten und zugehöriger Abhängigkeiten findet sich im Kapitel 2.
Die Projektentwickler haben sich dazu entschlossen, alle Komponenten mithilfe von Python zu implementieren.
Die Quelltexte sind unter der Apache-2.0-Lizenz freigegeben.
Das heutige OpenStack-Projekt entstand ursprünglich durch eine Zusammenarbeit der NASA und der Firma Rackspace.
Interessant an der gesamten Historie ist, dass sowohl die NASA als auch Rackspace ohne Kenntnis voneinander begonnen hatten, Software zu entwickeln, die einzelne Dienste von Amazon nachbilden sollte. So wurde von der NASA der Teil entwickelt, der virtuelle Maschinen verwaltet, ähnlich zu Amazons EC2 (Elastic Compute Cloud). Rackspace hingegen hatte mit dem Teil begonnen, der Speicherplatz zur Verfügung stellen sollte.
Ende Mai 2010 veröffentlichte ein Mitarbeiter der NASA einen kurzen Blogpost, in dem die Veröffentlichung von Nova mit den Worten »It’s live, it’s buggy, it’s beta. Check it out.«3 beschrieben wurde. Diese Ankündigung wurde etwa eine Woche später einem Mitarbeiter von Rackspace bekannt. Dieser sah sich den Quelltext an und verfasste eine interne Mail, in der er beschrieb, dass die Entwicklung der NASA der von Rackspace um ca. drei Monate voraus war. Ein Treffen der beiden Entwicklerteams ergab, dass das jeweilige andere Team den Teil schrieb, der noch vor dem anderen Team lag. Nachdem die Details geklärt waren, wurden beide Projekte zusammen unter dem Namen OpenStack veröffentlicht. Somit setzt sich OpenStack aus mehreren Projekten zusammen, die ersten beiden waren Swift und Nova. Der Quelltext stand von diesem Augenblick an vollkommen unter der Apache-2.0-Lizenz4. Von nun an nahm die Entwicklung des Projektes Fahrt auf. Wenige Monate später, am 21. Oktober 2010, erfolgte das erste offizielle Release von OpenStack unter dem Namen Austin.
Mittlerweile steht hinter dem Projekt die OpenStack Foundation, eine Organisation, unter deren Dach OpenStack entwickelt wird. Ziel der Foundation ist es, die Entwicklung des Projektes zu unterstützen und zu sichern. So werden z. B. gemeinsam genutzte Ressourcen durch die Beiträge finanziert, die von Firmen oder Personen investiert werden, damit diese einen bestimmten Rang in der Foundation erhalten. Jeder Interessierte kann Mitglied der Foundation werden. Details zur Foundation finden sich unter http://www.openstack.org/foundation/.
Die folgenden Erscheinungsdaten belegen die stetige Fortentwicklung des Projektes und seiner Komponenten:
Name |
Erscheinungsdatum |
Austin |
21.10.2010 |
Bexar |
03.02.2011 |
Cactus |
15.04.2011 |
Diablo |
22.09.2011 |
Essex |
05.04.2012 |
Folsom |
27.09.2012 |
Grizzly |
04.04.2013 |
Havana |
17.10.2013 |
Icehouse |
17.04.2014 |
Eine Übersicht der Releases findet sich unter https://wiki.openstack.org/wiki/Releases.
Die Codenamen der Releases sind alphabetisch geordnet. Jeder Name steht für den Namen einer Stadt oder eines Bezirks in der Nähe des Ortes, an dem die Entwicklerkonferenz für das entsprechende Release stattfand, mit einer Ausnahme, die Waldon Exception5: Hierbei können interessant klingende Elemente der entsprechenden Flagge genutzt werden. Dies wurde bei der Benennung von Grizzly (Kalifornien) genutzt. Aber auch bei der Namenswahl für das I-Release wurden aufgrund von Übersetzungsproblemen mit der chinesischen Sprache wieder Ausnahmen gemacht. So lautet der Name für das I-Release Icehouse, benannt nach einer Straße in Hong Kong.
Offiziell wird ein nummeriertes Versionsschema mit dem Aufbau <JAHR>.<VERSION> verwendet. So bedeutet z. B. 2012.2 das zweite Release im Jahr 2012. Dabei handelte es sich um Folsom. Wird eine weitere, durch einen Punkt abgetrennte Nummer angehängt, so ist das die Nummer für das Maintenance-Release (bspw. 2012.2.3).
Die Komponente Swift verwendet eine eigene Versionierung. So trägt die zum Grizzly-Release gehörende Version von Swift die Nummer 1.7.6.
Zur Aktualisierung auf eine neue Version liefert das Projekt entsprechende Kommandos mit, die z. B. notwendige Änderungen im Datenbankschema vornehmen. Allerdings sind solche Versionsaktualisierungen bisher nicht trivial; die Entwickler arbeiten daran, diese Übergänge reibungsloser zu gestalten. Zusätzlich zu den Release Notes existieren auch Upgrade Notes, die für die einzelnen Komponenten die Änderungen zusammenfassen. Diese sollten vor einem Upgrade gelesen werden.
Mittlerweile wurden aus Bestandteilen einzelner Projekte eigene Projekte, wie z. B. das für das Netzwerk zuständige Neutron, das vorher direkt in Nova integriert war und lediglich einen Bruchteil der Funktionalität von Neutron leisten konnte.
Nach dem NIST-Modell handelt es sich bei OpenStack um eine IaaS-Cloud.
Für jeden Nutzer können z. B. eigene Netzwerke definiert werden, die von den restlichen Nutzern abgegrenzt sind. Deren Verwaltung kann der Nutzer selbst übernehmen (On-demand Self Service). Die innerhalb der virtuellen Maschinen verwendeten Betriebssysteme und zusätzliche Software werden vom Kunden selbst ausgewählt und konfiguriert. Hier besteht von Nutzeranforderungen und -wünschen her völlige Flexibilität.
Kunden können über die API6 oder eine webbasierte Benutzeroberfläche (das Dashboard) ihre ihnen zur Verfügung stehenden Ressourcen selbst verwalten. Dies geschieht innerhalb von Projektgrenzen und Quotas. Selbstverständlich können alle verfügbaren Ressourcen als Basis für mehrere Nutzer genutzt werden (Resource Pooling). Die Ressourcen können über eine Netzwerkverbindung verwaltet und adressiert werden, z. B. durch die Nutzung der RESTful APIs (Broad Network Access). Selbstverständlich werden die bereitgestellten Ressourcen überwacht, sonst könnte u. a. kein Accounting implementiert werden (Measured Service). Auch die Anforderung, dass diese Ressourcen dynamisch verändert werden können, trifft zu (Rapid Elasticity).
