Windows Azure: Web-, Worker- und VM-Rollen entzaubert

Einige sehnlichst erwartete Funktionen von Microsoft Azure verlassen nun das Beta-Stadium und werden für den kommerziellen Einsatz verfügbar. Eine davon ist die Azure Compute: Virtual Machine (VM), die aufgrund der Möglichkeit, Azure-VMs für verschiedene Zwecke zu verwenden, interessant ist. Für manche Kunden und für einige Server-Rollen mögen der Preis und die Funktionen, wie die weltweite Reichweite von globalen Azure-Rechenzentren, sehr verlockend sein.

Azure wird an Software-Entwickler vermarktet, deshalb ist es ein Muss, sich auf ihre Welt einlassen, um die Plattform effizient zu nutzen. Beispielsweise „publiziert“ man sein „VM Role-Anwendungspaket“ mittels Visual Studio an Azure, um eine VM tatsächlich zu implementieren – für viele IT-Profis sind das keine vertrauten Aufgaben beziehungsweise kein vertrautes Werkzeug. Dies mag ein Grund für die langsame Verbreitung (oder das geringe Verständnis) von Azure bei IT-Profis sein. Erst als die VM-Rolle für den Beta-Test zur Verfügung stand, wurde Azure für viele richtig interessant.

Windows Azure: eine VM mit drei Nutzungsmöglichkeiten

Die Azure-Plattform hat ein Dutzend Funktionen oder mehr, dazu zählt die Windows Azure-Recheninstanz. Hier ist ein einfacher Schlüssel zum Verständnis dessen, was „Recheninstanz“ bedeutet: Jede Windows Azure-Recheninstanz stellt einen virtuellen Server dar. Es kann sehr verwirrend sein, ein Azure-Abo auszuprobieren und zu kaufen, weil eine ungewöhnliche Terminologie verwendet wird. „750 Stunden Nutzung einer kleinen Recheninstanz“, wie Microsoft die Azure-Preisgestaltung beschreibt, was in gängiger Sprache bedeutet: „Ein Monat exklusive Nutzung einer kleinen VM“. Diese VM lässt sich auf drei Weisen nutzen: Als Frontend-/Webserver (Web-Rolle), als Backend-/.NET-Anwendungsserver (Worker-Rolle) oder als VM.

Mit einem Windows Azure Project in Visual Studio 2010 lassen sich drei Rollen erstellen: Web, Worker und Virtual Machine.

Wer eine Frontend-Serverrolle hat, die den IIS benötigt (zum Beispiel eine ASP.NET-fähige Website), verwendet nicht die VM-Rolle, sondern die Azure Compute Web-Rolle, und lädt lediglich seinen Website-Code in die Cloud hoch. Die Azure-Automatisierung wird die Website für die Azure-VM-Instanzen implementieren und man hat mit den eigentlichen VMs nichts zu tun. Microsoft ist für die Aktualisierung des Betriebssystems zuständig und hat ein Service Level Agreement (SLA) über die Verfügbarkeit des Betriebssystems der VM-Instanzen. Dadurch lässt sich Zeit und Geld sparen, weil keine Windows-Webserverfarm verwaltet werden muss, dennoch genießt man die vollständige Rechenisolierung und Leistungsfähigkeit eigener VMs, die Internet Information Services (IIS) ausführen.
Gleichermaßen würde man die Azure Compute Worker-Rolle nutzen, wenn ein Middleware- oder Backend-Prozess-Server betrieben wird, der Code wie etwa das .NET Framework ausführt, aber keine IIS für die Publikation von Websites benötigt. Wie die Web-Rolle befreit einen auch die Worker-Rolle von der Notwendigkeit, den/die Server zu verwalten, die den Code ausführen.

Für die Web- und Worker-Rollen stellt Azure die VHDs bereit und hostet die VMs auf unsichtbare Weise. Mit den Web- und Worker-Rollen wird hinsichtlich der Programmierung interagiert, indem lediglich die eigenen Webserver und/oder .NET-Anwendungspakete in das Azure-Administrationsportal hochgeladen werden, oder direkt aus Visual Studio. Man lässt die Azure-Automatisierung im Hintergrund die VMs konfigurieren und seinen Inhalt verbreiten.

Azure Compute Instance: die Wegwerf-VM

Wenn das, was in Azure Compute erreichen werden soll, über die Fähigkeiten der Web- oder Worker-Rollen hinausgeht, gibt einem Microsoft vollständigen Zugriff auf die VM-Instanzen selbst – die VM-Rolle. In dieser Rolle bietet Microsoft kein SLA für das Betriebssystem oder die VM, weil man das Image seiner eigenen virtuellen Festplatte (Virtual Hard Drive, VHD) hochlädt und Microsoft keine Aktualisierung des Betriebssystems vornimmt.
Die Azure VM-Rolle ist nicht wie andere herkömmliche gehostete VM-Umgebungen. Der größte Unterschied ist, dass sich VMs nur paarweise implementieren lassen und durch das Windows Azure Compute SLA von Microsoft abgesichert wird. Wird ein Paar redundanter VM-Instanzen im Rahmen einer Azure VM-Rolle implementiert, besteht ein SLA über 99,95-prozentige Verfügbarkeit der Rolle.

Statt extrem hohe Verfügbarkeit auf einzelnen Servern anzustreben, wählt Microsoft bei der Azure-Plattform einen anderen Ansatz hinsichtlich des Risikomanagements. Der Ausfall einer VM ist erlaubt, wird erwartet und eingeplant, entweder in der Anwendungsschicht oder in einem Kontingenz-Workflow-Prozess. Für den Azure-Softwarearchitekten gibt es einige Möglichkeiten, Permanentspeicherung für Azure-VMs bereitzustellen.

Wenn ein Azure-Host einen Hardware-Ausfall hat, verliert man eine VM-Instanz. Einmalig vorhandene Daten, die sich auf dem System-VHD oder im Arbeitsspeicher dieser VM-Instanz befanden, werden endgültig verloren. Azure reagiert auf den Ausfall durch Starten einer neuen VM, um die verlorene VM zu ersetzen, aber unter Verwendung eines generischen „sysprep’ed“ Virtual Hard Drive (VHD)-Images, das hochgeladen wurde. Bis dahin wird davon ausgegangen, dass die Gesamtanwendung weiterhin korrekt ausgeführt wird, indem die überlebende(n) VM-Instanz(en) in dieser Rolle verwendet werden.

Im Falle der Web- und Worker-Rollen stoppt der Verlust eines bestimmten IIS-Servers in einer Webfarm nicht die gesamte Webanwendung, da IIS- und .NET-Anwendungen im Allgemeinen hinter Lastverteilern gut funktionieren. Dieses Modell für Web- und Worker-Rollen ist die Weise, in der Microsoft ein SLA über die Verfügbarkeit der Plattform bietet – Microsoft muss nur genügend VM-Instanzen einer Web- oder Worker-Rolle am Laufen halten, um das SLA einzuhalten.
Im Falle der VM-Rolle muss die gesamte verteilte Unternehmensanwendung (zu der die VM-Instanzen gehören) so aufgebaut sein, dass sie die Nichtpersistenz von bestimmten Azure-VM-Instanzen ermöglicht. Die meisten Infrastrukturrollen passen nicht zu diesem Modell, ohne modifiziert zu werden.

Wenn die Anwendung der VM-Rolle mit einem zufälligen Computernamen und in einer Standard-„Workgroup“-Konfiguration ohne Konfigurieren nicht läuft (native Azure-VMs tun dies), kann man erwägen, entweder eine automatische Bereitstellungsroutine zu erstellen, die den VMs nach der Implementierung eine Konfiguration zuweist, oder einen manuellen Schritt durchführen, wie etwa das Remote Desktop Protocol (RDP) zu nutzen, um neue VM-Instanzen zu verwalten und Software, die in dem Image installiert ist, zu konfigurieren.

Informationen zu Preisgestaltung, Windows-Lizenz und Testversion

Das Preismodell für die Windows-Azure-VM-Rolle ist das gleiche wie das für die Web- und die Worker-Rolle. Kunden müssen je nach Größe der Recheninstanz bezahlen. Die Windows Azure-Gebühr für das Ausführen einer VM-Rolle beinhaltet die Lizenzkosten für den Windows Server. Darüber hinaus sind keine Windows Server Client-Zugriffslizenzen (CALs) erforderlich, um sich mit der Windows Azure-VM-Rolle zu verbinden.

Der Einstieg bei Azure wird von Microsoft erleichtert, indem das Unternehmen eine Reihe preisgünstiger oder sogar kostenfreier Testabos für Azure anbietet.