ADMIN Magazin Gestapelt - Schneller und sicherer mit RAID (Vorschau)

Know-how
Open Stack
und im Grunde identisch damit, ein OS
auf echtem Blech zu installieren. Das kollidiert
mit dem Anspruch, dass es auch
weniger erfahrenen Benutzern möglich
sein soll, sich neue virtuelle Systeme per
Webinterface zusammenzuklicken, um
sie anschließend in der Wolke zu nutzen.
Abhilfe schaffen die Betreiber von
Clouds, indem sie den Nutzern fertige
Abbilder von Betriebssystemen zur Nutzung
in der Umgebung zur Verfügung
stellen. Möchte ein Nutzer dann per Webinterface
eine neue VM starten, wählt er
nur noch das passende Betriebssystem-
Image aus und loggt sich kurz darauf in
seinem neuen System ein.
Glance übernimmt bei Open Stack die
Aufgabe, Betriebssystem-Abbilder zur
Verfügung zu stellen. Es besteht aus
zwei Teilen nämlich »glance‐api« und
»glance‐registry«. Die API ist das Interface
zur Außenwelt während sich
»glance‐registry« darum kümmert, vorhandene
Images zu und die dazugehörige
Datenbank zu verwalten. Glance
beherrscht eine Vielzahl von Optionen,
was das Speichern von Images angeht:
Neben der lokalen Ablage auf dem System,
auf dem Glance läuft, unterstützt
es als Storage-Backend auch Open Stack
Swift, Ceph sowie alles, was kompatibel
zu Amazons S3 ist.
Ein echtes Multitalent ist Glance im Hinblick
auf die Image-Formate, die es unterstützt:
Neben den klassischem KVM-
Format »qcow« kommt Glance ab Werk
auch mit Images für VMWare zurecht.
Grundsätzlich kann als Image für ein Betriebssystem
alles herhalten, was sich auf
einem echten x86-Server booten ließe.
Voraussetzung dafür ist lediglich, dass
das Image ein echtes Abbild einer Festplatte
inklusive Master-Boot-Record ist.
Wer schon Images für Amazons AWS gebaut
hat, kann diese ebenfalls in Glance
verwenden und auch das Feature nutzen,
unterschiedliche Disk-Images mit jeweils
anderen Kerneln zu booten – zumindest
bei Linux-Images.
Netzwerkmanagement
Abbildung 2: Das Dashboard ist die zentrale Benutzerschnittstelle. Vorhandene VMs, die hier Instanzen
heißen, lassen sich löschen und starten.
Seit dem Folsom-Release ist das Netzwerkmanagement
in Open Stack der Job
von Quantum. Bis einschließlich Open
Stack 2012.1 („Essex“) galt Quantum als
Incubated Project, nun halten die Entwickler
es reif für den Einsatz in Produktionsumgebungen.
Quantum kümmert
sich um verschiedene Probleme, die im
Kontext der Servervirtualisierung hinsichtlich
des Netzwerks durch den ISP
zu lösen sind. So wird eine neue virtuelle
Maschine üblicherweise eine IP-Adresse
brauchen, wobei es sich entweder um
eine private oder um eine öffentliche IP-
Adresse handeln kann. Überdies ist es
wünschenswert, einzelne Tenants voneinander
beispielsweise durch VLANs
zu trennen. Damit ist sichergestellt, dass
eine Firma jeweils nur Zugriff auf ihre
eigenen VMs bekommt und nicht etwa
auf die VMs anderer Unternehmen, die
auf demselben Virtualisierungsknoten
laufen. Quantum kümmert sich um eben
diese Aufgaben.
Es ersetzt damit die alte Netzwerkimplementation
»nova‐network«, die zur
Computing-Komponente Nova gehörte
(Abbildung 4, hierzu später mehr). Technisch
ist die Lösung ausgefuchst: Quantum
macht sich neue Technologien wie
Openvswitch [1] zunutze, um die physische
Netzwerkkonfiguration komplett
von der virtuellen Netzwerkkonfiguration
zu trennen. Auf jedem Hypervisor läuft
ein entsprechendes Quantum-Plugin,
das mit der Quantum-Server-Instanz von
Open Stack kommuniziert und von dort
seine Konfiguration erhält. Zum Virtualisierer
hin verhält sich jenes Plugin
wie ein echter Switch: VMs, deren Netzwerkinterface
mit solch einem virtuellen
Switch verbunden ist, lassen sich über
verschiedene Hypervisor-Knoten hinweg
beliebig verbinden. Auch eine virtuelle
VLAN-Konfiguration ist möglich, wenn
Kunden ihre eigene Netzwerktopologie
implementieren möchten. War zuvor lediglich
die Trennung in unterschiedliche
VLANs auf Hardware-Ebene machbar,
um Kunden voneinander zu trennen,
so übernimmt jetzt diese gesamte Konfiguration
Quantum. Und Openvswitch
ist nicht das einzige von Quantum unterstützte
Protokoll: Auch Ciscos UCS/
Nexus-Implementierung kennt der Dienst
bereits, sodass er zusammen mit passender
Hardware deren Fähigkeiten voll
ausnutzen kann.
Cinder: Ein Blockspeicher
für VMs
Virtuelle Maschinen innerhalb einer
Cloud-Umgebung benötigen persistenten
Speicher in Form von Blockdevices, die
als Festplatten dienen. Allerdings läuft die
typische Architektur von Storage der Idee
hinter einer Wolke im Grunde komplett
zuwider. Denn während in einem Cloud-
Setup eine große Zahl gleichwertiger
Knoten vorhanden ist, ist Storage meist
an einer Stelle zentral zusammengefasst.
An dieser Stelle kommt Cinder ins Spiel:
Es sorgt dafür, das zentral verwalteter
Speicher portitioniert als Festplatte bei
den virtuellen Maschinen innerhalb der
Wolke ankommt. Auch Cinder war in
der Vorgängerversion „Essex“ noch fixer
Bestandteil der Computing-Komponente
Nova und hat erst in Folsom den Einzug
als Core-Projekt in Open Stack geschafft.
Es kommt mit mehreren Storage-
Backends zurecht: Block-Speicher, der
Teil einer LVM-Volume-Group ist, stellt
die Standard-Konfiguration dar; das deckt
insbesondere per Fibre Channel angebundene
SANs oder DRBD-Setups ab. Diese
74 Ausgabe 06-2012 Admin www.admin-magazin.de