Nachdem es bereits in der CTP-Phase zahlreiche Veränderungen im Aufbau und Funktionsumfang von Windows Azure gegeben hat, steht mit der Produktivsetzung eine Windows Azure Platform in einer ersten Version bereit. Der schematische Aufbau ist in Abbildung 10.2 wiedergegeben.
Abbildung 10.2: Aufbau von Windows Azure
Windows Azure umfasst damit folgende Bestandteile:
Mit der Produkteinführung wurden in den einzelnen Bestandteilen von Windows Azure Kenngrößen und funktionale Erweiterungen eingeführt bzw. angekündigt. Die folgenden Abschnitte geben einen Überblick über diese Änderungen.
Jede Instanz einer Rolle, die in Windows Azure zum Betrieb von Diensten angelegt wird, wird auf einer eigenen virtuellen Maschine (VM) ausgeführt. Während der CTP-Phase standen VMs in einer einzigen Größe zur Verfügung. Die VMs waren jeweils mit einem Prozessorkern mit 1,6 GHz und 1,75 Gigabyte Hauptspeicher ausgestattet.
Mit dem Produktionsstart von Azure stehen nun vier verschiedene Größen von VMs zur Verfügung, aus denen der Nutzer auswählen kann: Small, Medium, Large und XLarge. Diese sind in Tabelle 10.5 aufgelistet.
Small
Medium
Large
X Large
Kosten pro Service-Stunde
0,12 US-$
0,24 US-$
0,48 US-$
0,96 US-$
Prozessor
1 x 1,6 GHz
2 x 1,6 GHz
4 x 1,6 GHz
8 x 1,6 GHz
Speicher (RAM)
1,75 GB
3,5 GB
7,0 GB
14,0 GB
Tabelle 10.5: Verschiedene Größen virtueller Maschinen
Die Variante Small ist die bisher im Rahmen der CTP verfügbare VM. Mit den weiteren VMs gehen bezüglich Zahl der Prozessorkerne und Speicherausstattung jeweils Verdoppelungen einher (Medium ist doppel so groß wie Small usw.).
Die Kommunikation zwischen zwei Rollen erfolgte bislang immer über eine Vermittlerkomponente. Dies konnte eine Windows Azure Storage Queue, Blob-Storage etc. sein, über die Nachrichten zwischen Rollen ausgetauscht und hierüber eine Kommunikationsbeziehung unterhalten werden konnte. Neu ist, dass Web und Worker Roles nun direkt miteinander kommunizieren können. Die API stellt hierzu Funktionen bereit, mit denen einzelne Instanzen einer Rolle identifiziert und Nachrichten über direktem Weg ausgetauscht werden können. Die Identifikation einer Rolle ist insbesondere dann wichtig, wenn mehr als eine Instanz einer Rolle betrieben wird, die Kommunikation aber immer mit der jeweils gleichen Instanz erfolgen soll, da beispielsweise zur Verarbeitung aufeinander folgender Nachrichten beim Empfänger notwendige Kontextinformation im Speicher gehalten werden soll.
Änderungen hat es nicht nur in der Kommunikation zwischen Rollen, sondern auch im Bereich der Kommunikation mit der Außenwelt gegeben. Rollen haben nun gewissen Einfluss darauf, wie sie von außen über den Loadbalancer angesprochen werden können. Während Web Roles Nachrichten grundsätzlich über einen vorgeschalteten Internet Information Server (IIS) empfangen, kann für Worker Roles konfiguriert werden, über welchen Port sie Nachrichten direkt vom Loadbalancer empfangen können. Die Rolle kann dabei über einen ähnlich dem in Listing 10.1 angegebenen Code den eigenen Endpunkt ermitteln.
IPEndPoint endpoint = RoleEnvironment.Roles["HelloWorld_WorkerRole"].Instances[0].InstanceEndpoints["TestEndpoint"].IPEndpoint;
Listing 10.1: Ermittlung des IP-Endpunkts (Ports) über die Windows Azure Runtime API
Dieser Endpunkt kann dann verwendet werden, um Nachrichten zu empfangen, die von außen an den betreffenden Port gesendet wurden. Hierzu stehen wiederum Befehle der Windows Azure Runtime API zur Verfügung. Ein entsprechendes Codefragment ist in Listing 10.2 zu sehen.
var client = new TcpClient(); client.Connect(endpoint); var rd = new StreamReader(client.GetStream()); var test = rd.ReadToEnd(); client.Close();
Listing 10.2: Empfang von Daten über den zuvor ermittelten IP-Endpunkt
Neben den bereits während der CTP-Phase verfügbaren Web und Worker Roles wurde für die Produktivphase der Windows Azure Plattform eine dritte Art von Rollen bekannt gegeben: die Virtual Machine Role. Während bei Web und Worker Roles Software auf eine von Azure vorkonfigurierte VM aufgespielt wird, besteht bei VM Roles die Möglichkeit, auch die VM selbst zu konfigurieren und dann auf Windows Azure auszuführen. Dabei steht eine Auswahl an vorgefertigten VMs zur Verfügung. Diese können angepasst und dann als Snapshot auf Windows Azure geladen und durch dieses betrieben werden. Für die Konfiguration erhält der Entwickler deutlich mehr Flexibilität als bei Web und Worker Roles. Erkauft wird diese Flexibilität allerdings mit Einschränkungen bei der automatisierten Skalierung von Anwendungen (wenn beispielsweise zusätzliche Instanzen einer Rolle hinzugeschaltet werden sollen).
Nachdem ein direktes Debuggen von Anwendungen, die auf Winodws Azure betrieben werden, nicht möglich ist, kommt dem Logging- und Diagnose-System, welches mit Produktivsetzung der Plattform verfügbar ist, besondere Bedeutung zu. Dieses System zielt unter anderem auf folgende Einsatzszenarien ab:
Um Tracing-Ausgaben erzeugen zu können, muss in der web.config-Datei einer Anwendung (diese wird von Visual Studio für Web Roles automatisch erzeugt) ein sogenannter Trace Provider registriert werden. Dies kann wie in Listing 10.3 gezeigt erfolgen.
<system.diagnostics> <trace autoflush="false" indentsize="4"> <listeners> <add name="AzureDiagnostics" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </listeners> </trace> </system.diagnostics>
Listing 10.3: Registrierung eines Trace Providers als Voraussetzung zur Erzeugung von Trace-Ausgaben
Mit Hilfe der bekannten Tracing API können damit dann Tracing-Ausgaben in Logs erfolgen, die gesammelt und dann zeitgesteuert oder auf Anforderung in Windows Azure Storage abgelegt werden. Beispielaufrufe der Tracing API sind in Listing 10.4 zu sehen.
Trace.WriteLine("Hier ist ein KRITISCHER Log-Eintrag", "Critical"); Trace.WriteLine("Hier ist eine INFORMATION für das Log", "Information");
Listing 10.4: Beispielaufrufe der Tracing API
Bei der Übertragung in den Azure Storage, von wo aus die Logs dann auf dem üblichen Weg (Storage API oder Webservices) ausgelesen werden können, können die Logs nach Datentyp, Level und Zeitraum gefiltert werden. Tabelle 10.6 gibt einen Überblick über die möglichen Informationsquellen für die Anwendungsüberwachung und Analyse.
Datenquelle
Standardkonfiguration
Konfiguration
Format
Trace Logs
aktiviert, lokal gespeichert
Diagnostics API, Trace Listener
Table
Performance Counters
deaktiviert
Diagnostics API
Windows Event Logs
Infrastruktur-Logs
IIS Logs
Diagnostics API, Web.config
Blob
IIS Failed Request Logs
Application Crash Dumps
Diagnostics API, Crash API
Beliebige Logs & Dateien
Tabelle 10.6: Informationsquellen für die Anwendungsüberwachung und -analyse
Die Datenquellen erzeugen Informationen, die in den Windows Azure Storage (als Tables oder Blobs) übertragen werden können und dort für Analyseprozesse zur Verfügung stehen.
Der Speicherdienst von Windows Azure umfasste bisher Queue, Table und Blob Storage. Diese wurden auf Basis zahlreichen Kunden- und Anwenderfeedbacks in ihren Funktionen deutlich erweitert. Viele der neuen Funktionen reduzieren den Umstellungsaufwand bei der Migration bestehender Anwendungen auf Windows Azure.
Blob Storage wurde beispielsweise um eine wichtigen Funktionalität erweitert: Drives. Bei Drives handelt es sich um Blob Storage, der als ein virtuelle NTFS-Festplatte (Virtual Hard Drive (VHD)) formatiert wird. Diese steht dann Windows Azure-Anwendungen zur dauerhaften Speicherung von Daten in einem virtuellen Dateisystem zur Verfügung. Drives zeichnen sich durch folgende Eigenschaften aus.
Mit Drives hat Microsoft nun eine Möglichkeit geschaffen, Anwendungen, die auf den Zugriff auf ein Dateisystem angewiesen sind, auf Windows Azure zu migrieren.
Für den Zugriff auf den Windows Azure Storage ist eine offizielle Storage Client Library verfügbar. Dies hat zur Folge, dass Entwickler nicht mehr über Klassenbibliotheken aus dem Samples-Namespace, sondern über den Namespace Microsoft.WindowsAzure.StorageClient mit dem Windows Azure Storage interagieren. Anwendungen, die während der CTP-Phase erstellt wurden, müssen in diesem Bereich also geändert werden, um den neuen Namespace zu unterstützen.
Die Speicherdienste werden noch um einige weitere Funktionalitäten erweitert. Stichpunktartig die wichtigsten Erweiterungen:
Beim Zugriff auf große Dateien, die im Windows Azure Blob Storage abgelegt sind, kann die Netzwerklatenz zu einem Problem werden, wenn der Anwender in großer räumlicher Distanz zum Rechenzentrum ist, in dem der Blob abgelegt ist. Um diese Latenz zu minimieren, bietet Microsoft das sogenannte Content Delivery Network (CDN) an.
Das CDN umfasst 18 Standorte rund um den Globus und wird stetig ausgebaut. Das Windows Azure CDN legt Kopien von Blobs in einem Zwischenspeicher an den verschiedenen Standorten an, um einem Anwender Blobs vom jeweils nächsten Standort auszuliefern und dadurch die Übertragungszeit zu optimieren. Der Einsatz des CDN kann über das Windows Azure Developer Portal aktiviert werden.
Dabei wird für den Blob Storage eine CDN-URL der Form http:/ /<guid>.vo.msecnd.net/ vergeben. Dieser URL kann dazu verwendet werden, Blobs aus einem öffentlichen Blob-Speicher zu lesen. Der Zugriff über den bestehenden URL über den Storage Account ist dabei weiterhin möglich.
Ein Beispiel: Gegeben sei ein Storage Account namens mystorageaccount. In diesem befindet sich ein öffentlicher Container images. Sobald der CDN-Zugriff auf diesen Container eingerichtet ist, können Anwender den Container über zwei URLs auslesen:
Beim Zugriff über den Service-URL erfolgt der Zugriff direkt auf den am ursprünglichen Ort gespeicherten Container. Beim Zugriff über den CDN-URL wird die Anfrage sofort an den Endpunkt weitergeleitet, der dem Anwender am nächsten ist.
Die Klassenbibliothek für die Interaktion mit Windows Azure, die im Windows Azure SDK enthalten ist, wurde im Rahmen der Produktivsetzung der Plattform überarbeitet. Sie umfasst nun die folgenden Namespaces:
Für Anwendungen, die während der CTP-Phase erstellt wurden, ist hier also unter Umständen eine Überarbeitung erforderlich. Dies ist insbesondere dann der Fall, wenn Funktionalitäten des StorageClients genutzt wurden, der sich zur CTP-Phase im Samples-Namespace befand.
Es steht nun eine Management API zur Verfügung, über die die meisten Aktionen, die über das Windows Azure Developer Portal zugänglich sind, aus einem Skript oder Programm (unabhängig davon, ob dieses auf Windows Azure oder außerhalb betrieben wird) heraus ausgeführt werden können. Über die Service Management API können Storage Accounts, Services, Service Deployments und Affinity Groups verwaltet werden. Die API selbst ist dabei eine REST API, deren Operationen über SSL erfolgen und über X.509 v3-Zertifikate abgesichert werden.
Um mit der Service Management API arbeiten zu können, ist zunächst das Anlegen eines Benutzerkontos über das Windows Azure Developer Portal erforderlich. Diesem ist eine eindeutige Subscription ID zugeordnet, die für API-Aufrufe benötigt wird und die auf dem Portal beim Konto angezeigt wird.
Innerhalb eines Benutzerkontos können zwei Arten von Diensten angelegt werden:
Diese Dienste müssen über das Windows Azure Developer Portal angelegt werden. Sobald die Anlage abgeschlossen ist, können sie mittels der Service Management API verwaltet werden.
Im Falle eines Storage Accounts umfasst die API beispielsweise Operationen zum Auflisten von Storage Accounts innerhalb eines Benutzerkontos, zum Ermitteln von Eigenschaften des Storage Accounts, Auslesen oder Neugenerieren des primären oder sekundären Zugriffsschlüssels. Eine vollständige Liste der API-Operationen findet sich in der MSDN-Dokumentation.
Die API kann im Falle von Hosted Services zum Beispiel dazu verwendet werden, die Eigenschaften des Service auszulesen, Deployments zu aktualisieren und zu verwalten und Konfigurationen der Dienste zu ändern.
Zu den wichtigsten Ankündigungen, die zu Azure auf der PDC 2009 gemacht wurden, gehörten die erweiterten Möglichkeiten zur Interoperabilität. Nachdem schon bei den Schnittstellen nach außen großer Wert auf Standards gelegt wurde – so bleibt es grundsätzlich möglich, auf Services, die auf Azure betrieben werden, über REST- und andere Schnittstellen zuzugreifen – können nun auch Dienste, die in PHP oder Java entwickelt wurden, auf Windows Azure betrieben werden. Allgemein formuliert können auf Windows Azure grundsätzlich alle Technologien betrieben werden, die auf Windows ohne Administratorrechte ausgeführt werden können. Entwickler haben hierbei die Möglichkeit, ihre jeweils benötigte Laufzeitumgebung selbst zu bestimmen.
Mit der Möglichkeit Ports auf Windows Azure für den Nachrichtenempfang von außen zu konfigurieren, können auf Azure auch Anwendungsserver wie Apache Webserver oder Tomcat betrieben werden. Darüber hinaus wird MySQL als Datenbanksystem auf Azure unterstützt. Damit sind die Voraussetzungen geschaffen, auf Basis von Azure einen WAMP-Stack (Windows-Apache-MySQL-PHP) in der Cloud bereitzustellen. Auf der PDC wurde dies von Matt Mullenweg, Gründer von Automattic, eindrucksvoll belegt, indem er sein beliebtes, auf PHP, Apache und MySQL basierendes Content Management System WordPress auf Azure installiert vorführte.
Neben Visual Studio wird es auch für Eclipse Entwicklerwerkzeuge zur Programmierung von Windows Azure-basierten Anwendungen bzw. zum Zugriff auf SQL Azure oder die AppFabric geben.
Bereits bekannt sind eine Reihe von Weiterentwicklungen, die die Funktionalitäten von Windows Azure deutlich erweitern werden:
Eine weitere wichtige, angekündigte Funktion ist die laufende Datenreplikation zwischen Rechenzentren einer Affinity Group. Rechenzentren einer Region werden von Microsoft zu Affinity Groups zusammengefasst. Beim anlegen eines Storage Accounts oder eines gehosteten Services kann der Anwender eine Affinity Group (also kein einzelnes Rechenzentrum) wählen. Microsoft garantiert, dass die gebuchten Ressourcen in einem Rechenzentrum aus dieser Affinity Group betrieben werden.