© Michael Likavec, 123RF.com

Wer seine virtuellen Infrastrukturen in der Wolke kreisen lässt, muss sich darauf verlassen, dass die Triebwerke nicht versagen. Ob Public, Private oder Hybrid Cloud, es gibt immer Möglichkeiten, hohe Verfügbarkeit zu erreichen – aber in den Details unterscheiden sich die Angebote doch sehr.

Ostern 2011: Es kracht im Web: Weite Teile von Amazons wichtigstem Cloudangebot, die Webservices AWS, fallen aus. Vor allem amerikanische Start-ups trifft das hart, während Großunternehmen scheinbar weniger Probleme mit der Outage haben. Deren Admins hatten sich offenbar mehr Gedanken über Verfügbarkeit, Ausfallsicherheit und Failover-Konzepte rund ums Cloudangebot des Marktführers gemacht und auf leistungsfähige Motore in den eigenen Wolken gesetzt. Dieser Artikel zeigt, welche Möglichkeiten Cloudanwender haben, mit Amazon, VMware, Eucalyptus und Open Stack ausfallsichere Wolken aufzubauen.

Amazon Web Services

Seit 2006 bietet Amazon mit der Elastic Compute Cloud (EC2) virtuelle Maschinen als Service an [1], die Kunden über die Weboberfläche (Abbildung 1) oder das API erstellen und nutzen. Die Abrechnung erfolgt anhand der Anzahl und Zeit der genutzten Ressourcen, als VM lädt der Benutzer entweder ein eigenes Amazon Machine Image (AMI) hoch oder verwendete eines aus dem Amazon-Marktplatz. Die Authentifizierung gegenüber dem API erfolgt per Public-Key-Verfahren.

Abbildung 1: Die Managementkonsole der Elastic Compute Cloud von Amazon. Für persistente Systeme braucht es hier ein Zusammenspiel mit Amazons Storagediensten S3 oder EBS.

Die Instanzen erhalten neben einer öffentlichen IP-Adresse auch eine private IP, die nur innerhalb der EC2-Cloud erreichbar ist. Security Groups definieren den Zugriff von EC2-Instanzen untereinander und von außen: So erlaubt der Admin bei Webservern nur Port 80 oder betreibt einen Host nur innerhalb der EC2-Wolke.

Eine solche virtuelle Maschine ist allerdings nicht persistent. Beim Beenden entfernt der Hypervisor ihren Zustand und instanziert die virtuelle Maschine beim nächsten Start vom ursprünglichen Image neu. Wer über das Herunterfahren hinaus Daten persistent speichern will, dem bleiben nur Amazons Storagedienste: der Simple Storage Service (S3, [2]) oder der Elastic Block Storage (EBS, [3]).

S3 ist ein Storagedienst, der Daten per API annimmt, speichert und sie innerhalb der VMs zur Verfügung stellt. S3 kennt aber nur Objekte, die per API-Aufruf erreichbar sind. Wer Daten im Betriebssystem als Blockspeicher schreiben und dauerhaft speichern will, nutzt den EBS.

Auch an die regionale Verteilung in Rechenzentren ist gedacht: Amazon stellt seine Ressourcen in Availability Zones [4] zur Verfügung. Fünf über die Welt verteilte Standorte (USA-West, USA-Ost, Irland-Europa, Singapur, Tokio) sollen Kunden Ausfallsicherheit gewährleisten. Fällt eine Zone oder eine ganze Region aus, ist nicht die gesamte Amazon-Infrastruktur betroffen.

Für Redundanz und Verteilung der belegten Ressourcen über Zonen und Regionen hinweg sind aber die Kunden selbst verantwortlich (vergleiche den Artikel zur Cloudstrategie in dieser Ausgabe).

99,99 Prozent Verfügbarkeit

Fürs Monitoring der Auslastung und das automatische Skalieren bietet Amazon mit Cloud Watch und Auto Scaling flexibel konfigurierbare Dienste an, die im Idealfall die Skalierung regelbasiert und vollautomatisch übernehmen.

Das Angebot enthält neben den Grunddiensten im IaaS-Bereich (Infrastucture as a Service) eine wachsende Produktpalette, die von Datenbanken über Monitoring- und Netzwerk- bis hin zu E-Commerce-Diensten reicht. Mit den von Amazon bereitgestellten APIs lassen sich auch eigene Lösungen mit der Amazon-Cloud kombinieren.

Der Versandhändler sichert bei seinem Angebot feste Verfügbarkeit der Dienste zu, die Zahlen liegen hier zwischen 99,95 Prozent für EC2 und 99,99 Prozent für S3. Viele Dienste wie EC2 und EBS sind allerdings auf einzelne Availability Zones beschränkt und bei einem Ausfall einer kompletten Zone dennoch betroffen. Dann helfen wirklich nur Cloud Watch und Auto Scaling weiter.

Es ist mit genügend Planung durchaus möglich, eine redundante, günstige und performante Cloudinfrastruktur mit den Amazon Web Services aufzubauen. Das ändert aber nichts am Vendor-Lock-in: Eine spätere Migration aus Amazon heraus wird mit jedem genutzen Dienst aufwändiger.

Kosten für Amazons Cloud

Die Grundkosten richten sich zunächst nach dem Instanztyp, dabei unterscheidet der Anbieter nach Linux oder Windows. Der Preis der Amazon-EC2-VMs berechnet sich nach deren Laufzeit. Das fängt bei 8,5 US-Cent pro Stunde an und reicht bei extremen Konfigurationen bis zu 2,10 Dollar pro Stunde und VM.

Für EBS-Volumina fallen Kosten je nach Speicherbelegung und Datendurchsatz an. Pro GByte macht das 10 Cent, jeweils eine Million I/O-Zugriffe kosten ebenfalls 10 Cent. Im Objektspeicher S3 kosten neben Speicherplatz und Durchsatz auch die Zugriffe extra. Die Kosten sind gestaffelt und beginnen bei 3,7 US-Cent pro GByte Speichervolumen und 8 Cent pro GByte Transfervolumen. Dazu addieren sich die Zugriffskosten: 1 Cent pro 100 Requests wie »PUT« , »COPY« , »POST« und 1 Cent pro 10 000 »GET« -Requests. »DELETE« -Requests sind kostenfrei.

VMware

VMwares Vsphere-Familie [5] gilt, spätestens seit in Version 4 die lastabhängige Migration von Maschinen Einzug hielt, als erstes Cloud-Betriebssystem. Die Sphäre schaltet dynamisch Hosts aus oder an und verteilt die gesamte Last automatisch nach Adminvorgaben auf mehrere physische Maschinen. Gerade Admins in Umgebungen mit stark schwankenden Auslastungen schätzen dies.

VMware setzt mit ESXi voll auf den eigenen Hypervisor, der in einer Basisversion kostenfrei ist. Wer mehrere ESXi-Server sinnvoll betreiben will, braucht allerdings eine Vcenter-Verwaltungsinstanz und eine Oracle- oder MS-SQL-Datenbank. Kunden bauen mit dem Vcenter große virtuelle Infrastrukturen auf, inklusive Netzwerk- und Storage-Management und hohem Funktionsumfang.

Mit VMware gebaute virtuelle Maschinen sind persistent. Sie erhalten ein Festplattenimage, das erst beim Löschen der VM entfernt wird. Nach dem Beenden einer virtuellen Maschine bleibt diese erhalten, bis der Admin sie löscht.

Die Authentifizierung an Vcenter erfolgt entweder durch lokal gepflegte Benutzer und Gruppen oder über die Verbindung mit einer Windows-Domäne. Sollte der Vcenter-Server ausfallen, funktionieren die virtuellen Maschinen auf den ESXi-Servern wie gewohnt weiter, nur lassen sie sich nicht mehr zentral verwalten und erweiterte Funktionen wie das lastabhängige automatische Migrieren von Host zu Host führt die Sphäre nicht mehr aus. Ein Vcenter sollte daher immer redundant vorhanden sein.

Vcloud

Mit dem Produkt Vcloud Service Director (Vcloud SD) hat VMware 2010 eine Erweiterung vorgestellt, die es einem Verbund aus ESXi-Servern und Vcenter erlaubt, Ressourcen im Pool anzubieten. Per Webfrontend erzeugt der Admin neue Maschinen nach Vorlagen, bildet Pools und pflegt Ressourcen wie IP-Pools oder Storage-Medien ein und partitioniert diese. Für die Pools kann der Admin verschiedene Zugriffsprioritäten festlegen, eine Testumgebung erhält so beispielsweise eine niedrigere I/O-Priorisierung als die Live-Umgebung, obwohl beide auf demselben NFS-Share liegen. Dabei arbeitet der Cloud Director (Abbildung 2) eine Ebene über dem Vcenter.

Abbildung 2: In VMwares Cloud Director steuert der Admin seine private Vsphere-Cloud.

Erweiterte Funktionen, die die Vsphere-Produkte von VMware beherrschen, muss der Admin aber weiterhin im Vcenter administrieren, so zum Beispiel das HA-Feature, das VMs eines ausgefallenen ESXi automatisch auf einem anderen hochfährt und so Ausfallzeiten minimiert. Die Verschachtelungen, die der Vcloud Director anlegt, darf der Admin dabei nicht modifizieren, sonst funktioniert das Namen-basierte Mapping von Vsphere zu Vcloud nicht mehr und muss manuell gepflegt werden.

Erweiterungen und HA

Für Vsphere und für den Vcloud Director sind einige Erweiterungen von VMware selbst sowie von Partnern verfügbar. So lässt sich das Vsphere-Netzwerk mit virtuellen Cisco-Nexus-Switches in die von Netzwerkadmins geschätzten Cisco-Workflows einbinden. Alternativ geben sie im Vcloud Request Manager Abläufe und Regeln vor und prüfen Maschinenanfragen im Webfrontend.

Hochverfügbarkeit virtueller Maschinen lässt sich in VMware durch einen HA-Verbund mehrerer ESXi-Hypervisoren realisieren. Die ESXi-Maschinen überwachen sich dann gegenseitig. Fällt eine aus, fahren die gestoppten VMs auf den restlichen ESXi-Maschinen automatisch wieder hoch.

Zudem gibt es die Fault-Tolerance-Funktion, bei der eine VM auf zwei ESXis gleichzeitig läuft und den Arbeitsspeicher fortlaufend zwischen beiden Hypervisoren synchronisiert. Fällt der ESXi mit der aktiven VM aus, übernimmt der andere sofort die virtuellen Netzwerkinterfaces und der Server ist ohne Datenverlust weiter im Netzwerk verfügbar. Beide Funktionen zählen aber nicht zum Umfang der im Vcloud Service Director administrierbaren Funktionen, der Admin muss sie direkt in Vcenter konfigurieren.

Alles in allem ist VMware mit Vcloud SD ein Werkzeug gelungen, das es Firmen erlaubt, eine komplette interne IaaS-Cloud aufzubauen und sehr einfach via Selbstbedienung per Webfrontend den Nutzern bereitzustellen. Historisch basiert das Ganze auf der bekannten Vsphere-Infrastruktur [6] und ist somit der einfachste Weg für Kunden, die bereits VMware einsetzen und nun ihre Infrastruktur stärker automatisieren und teilweise oder vollständig in eine IaaS-Wolke überführen möchten.

Kosten der Vcloud

Weil unter dem Vcloud Service Director eine komplette Vsphere steckt, sind Lizenzen für das ganze Backend erforderlich. Der ESXi kostet pro CPU-Socket ab etwa 1300 Euro in der kleinen Standard-Variante mit weniger Features und über 4000 Euro für die Enterprise-Plus-Version mit allen Features, etwa lastabhängiger Migration und Distributed Vswitches für Host-übergreifende Netzwerkadministration. Dazu kommt mindestens eine Instanz des Vcenter-Servers zur Verwaltung in der Foundation-Version ab etwa 2000 Euro oder in der Standard-Version ab (zirka 6000 Euro).

Der bringt dann aber schon Features wie den Link Mode zum Betreiben mehrerer geclusterter Vcenter-Server oder ein Webfrontend für den Zugriff per Browser mit. Dazu addieren sich knapp 4000 Euro für jedes 25er-Pack VM-Lizenzen für die Verwaltung per Vcloud SD [7].

Da in elastischen Cloudumgebungen Firmen in der Regel recht dynamisch neue Maschinen instanzieren und wieder zerstören, zieht VMware für die Lizenzierung des Vcloud Service Director die Durchschnittszahlen der VMs über ein Jahr heran. Zusätzlich zu den Kosten für die Infrastruktur fallen allerdings noch die Lizenzen für Clients sowie für eventuelle Zusatzprodukte des Vcloud SD an.

Eucalyptus

Die Cloudverwaltungs-Software Eucalyptus unterliegt einem Open-Core-Lizenzmodell. Neben einer Open-Source-Version [8] gibt es Eucalyptus auch als Enterprise-Variante [9], die die Möglichkeiten der Open-Source-Version ergänzt. Doch schon wer Unterstützung für I-SCSI, SAN und NAS braucht, kommt nicht an der kommerziellen Version vorbei. Die Investition hält sich jedoch in Grenzen, schon mit wenigen Tausend Euro (zirka 200 pro Core) lässt sich eine kleine Infrastruktur aufbauen.

Ursprünglich als Forschungsprojekt an der University of California Santa Barbara entwickelt [10], implementiert die Software eine IaaS-Lösung zunächst als private Cloud, deren API aber Amazon-kompatibel ist. Die erste offizielle Release vom Mai 2008 besaß sogar nur ein EC2-Interface, kurz danach kam Support für S3, wenig später die Ubuntu-Integration als Ubuntu Enterprise Cloud (Abbildung 3). Letztere macht Eucalyptus besonders fürs eigene Rechenzentrum interessant, Admins können Images für virtuelle Maschinen erstellen und diese dann in der eigenen Cloud nutzen.

Abbildung 3: Hinter Ubuntus Enterprise Cloud steckt noch Eucalyptus. Ab 11.10 soll hier Open Stack werkeln.

Maßgeschneiderte Abbilder gibt’s auf der Projektseite, als Hypervisor kommt Xen oder KVM zum Einsatz, via Libvirt angesprochen. Die Benutzerauthentifizierung funktioniert auch hier mit einem Public-Key-Verfahren, vorausgesetzt die vom Projekt bereitgestellten Eucatools sind installiert. Diese orientieren sich stark an Amazons EC2-API-Tools. Auch bei Eucalyptus kann der Admin Security Groups erstellen, ganze Netzwerke beim Starten einer virtuellen Maschine zuweisen und Ports für den Zugriff von außen freischalten.

Wie das große Vorbild speichert auch Eucalyptus die Daten einer virtuellen Maschine nicht persistent. Dafür bedarf es eines Storagevolume, wozu wiederum ein Amazons EBS ähnelndes Verfahren zum Einsatz kommt. Immerhin erlaubt Eucalyptus Volume-Snapshots, was Backups deutlich vereinfacht. Auf den FAQ-Seiten des Projekts findet sich auch eine Beschreibung [11], wie Admins Eucalyptus die Autoskalierung mit Linux-Werkzeugen wie Sar und den Eucatools beibringen, derzeit ist dazu aber noch eigene Programmierarbeit notwendig.

Kostenpflichtiges Management der Eucalyptus-Cloud gibt es von Rightscale [12]. Eucalyptus besitzt von Haus aus ein Clusterkonzept, um die Ressourcen zu verteilen. Ähnlich wie bei Amazon lassen sich die Ressourcen auch über mehrere Verfügbarkeitszonen verteilen, damit der Ausfall einer Location keinen Schaden anrichtet.

Open Stack

2010 taten sich der große amerikanische Provider Rackspace und die Nasa zum Open-Stack-Projekt [13] zusammen. Den Releases Austin und Bexar folgte schon im April 2011 die aktuelle Version Cactus [14]. Da war die Mitgliederzahl bereits auf knapp 50 Unternehmen angewachsen, darunter auch Canonical.

Open Stack (Abbildung 4) besteht aus mehreren Komponenten: Nova übernimmt die Kontrolle der virtuellen Maschinen, Swift stellt den Object-Storage bereit und Glance einen einfachen Dienst, der Images für virtuelle Maschinen registriert. Viel Freiheit hat der Nutzer bei der Planung seiner Wolke: Als Hypervisoren kommen Xen, KVM, Hyper-V, ESXi und kommerzielle Xen-Server in Frage, aber auch Amazons EC2 ist möglich.

Abbildung 4: Am Dashboard von Open Stack verwaltet der Admin Images und Server.

Eigene Images, ein API (Zugriff ebenfalls über Public Keys), die Eucatools und Role-based Access Control (RBAC) für Enduser gehören zum recht stattlichen Funktionsumfang von Open Stack. So definiert ein Admin unterschiedliche Rollen pro Projekt, zum Beispiel darf nur ein der Rolle »network-admins« angehörender Benutzer die Netzwerkeinstellungen des entsprechenden Projekts verwalten.

Außerdem unterstützt Open Stack (durch das EC2-kompatible API) Quotas für Projekte. Damit begrenzen Admins die Anzahl der genutzten CPUs, virtuellen Maschinen, der Floating IPs und Volumes. Security Groups beschränken die Zugriffe laufender Instanzen auf einzelne Ports. Auch bei Open Stack sind gestartete Instanzen nicht beständig, persistente Volumes sind nötig. Die basieren aktuell auf der I-SCSI-Implementierung, alternativ sind auch SMB oder NFS möglich.

Die Hypervisoren KVM und Xen erlauben Livemigrationen laufender Instanzen auf andere Server, wobei die entsprechende Unterstützung in Open Stack für Xen aber noch aussteht. Auch klappt das nur mit einem Shared Storage im Netz. Sowohl für HA als auch fürs Backup ist der Admin bei Open Stack selbst zuständig. Letzteres gestaltet sich mit persistenten Images recht einfach.

Aktuell gibt es keine Möglichkeit der automatischen Skalierung virtueller Maschinen in Open Stack. Vermutlich wird Scalr [15] dies für Open Stack integrieren, zumindest steht ein solcher Eintrag in der Roadmap. Natürlich kann der Admin auch im Eigenbau, unterstützt von Konfigurationsmanagements wie Chef oder Puppet, neue Nodes hinzufügen.

Da es sich bei Open Stack um eine vollständig freie Implementierung handelt, fallen keine Kosten für die Software an. Lediglich die Nutzung externer Dienste (Amazon) oder diverser Erweiterungen (Scalr, Rightscale) verursacht Kosten. Durch die freie Lizenz, gute Dokumentation und eine kommunikationsfreudige Community ist eine aktive Entwicklergemeinschaft entstanden. Die einfache Bedienung von Launchpad für den Sourcecode macht die Teilnahme am Projekt offenbar attraktiv.

Open Stack ist modular aufgebaut, setzt auf bereits bestehende freie Komponenten auf und erstreckt sich von der lokalen bis zur Public Cloud. Die Gefahr eines Vendor Lock-in scheint überschaubar.

Fazit

Die drei existierenden IaaS-Lösungen decken eine denkbar große Bandbreite ab. Abbildung 5 zeigt als Entscheidungshilfe, welches der vorgestellten Projekte für welche Form des Cloud Computing zum Einsatz kommen kann, im Kasten “Alternativen” findet sich ein Ausblick auf drei kommende Produkte.

Abbildung 5: Nur Open Stack und Eucalyptus bieten die ganze Bandbreite von Public, Hybrid und Private Cloud, bedienen sich dafür aber bei Amazon. HA-Vorbild VMware hat bei privaten Clouds die Nase vorn.

Alternativen: Red Hat, Deutsche Wolke und Kamp Virtual Core

Dass die Angst vor dem Vendor-Lock-in eine Ursache für die Zurückhaltung in Sachen Cloud ist, hat auch Red Hat erkannt und arbeitet hart an seinen Produkten. Im Sommer 2011 wird RHEV 3 erwartet, Open Shift, das Delta-API und das scheinbar alles umfassende Cloud Forms sollen helfen, die eigenen Produkte zentral zu platzieren [16].

Deutsche Alternativen

Gegen die Angst vor Rechtsunsicherheiten mit ausländischen Cloudanbietern treten mehr und mehr Hersteller mit dediziert deutschen Standorten an. Neben dem Projekt “Deutsche Wolke” [17] kommt dafür Ende 2011 auch die Open-Source-Software Virtual Core des Hosters Kamp auf den Markt (Abbildung  6, [18]).

Abbildung 6: Derzeit nur als Hosted-Edition erhältlich, soll die Eigenentwicklung Virtual Core vom Hoster Kamp bald ein Open-Source-Projekt werden. Ende 2011 will der Hersteller neben den abgebildeten Monitoring- auch HA-Funktionen bieten.

Hosted Cloud

Die Eigenentwicklung (einst in Typo3 gestrickt) soll bald Auto-Skalierung und -Migration beherrschen, steht aber derzeit nur mit vom Hoster gemieteter Hardware (ab etwa 1400 Euro pro Monat und Rack) zur Auswahl. (Markus Feilner)

Für die private IaaS-Wolke ist meist die bisher im Unternehmen genutzte Virtualisierungssoftware entscheidend. Wer bereits eine gewachsene VMware-Umgebung betreut, wird vielleicht die Lizenzkosten nicht scheuen, die für Vcloud anfallen. Für einen nennenswerten Betrag bekommt er dann ein Produkt, das vor allem in Sachen High Availability und automatische Skalierung viel zu bieten hat, deutlich mehr als die Konkurrenz auf dem Markt.

Eine breite Installationsbasis erweist sich als wichtig, wenn im Problemfall eine möglichst große Entwicklergemeinde mit Erfahrung und technischem Verständnis helfen kann. Wer heute eine freie Lösung sucht, kommt nicht an Open Stack vorbei. Das Projekt ist sehr aktiv und gewinnt mehr und mehr Unterstützer.