Dieser Artikel ist Teil 1 einer Serie von 6 Blog-Posts, die die Änderungen der Windows Azure Platform, die diese seit Fertigstellung des Manuskripts zum Buch “Cloud Computing mit der Windows Azure Platform” erfahren hat.

Die 6 Teile sind:
Teil 1: Allgemeine  Änderungen der Windows Azure Platform
Teil 2: Änderungen in Windows Azure
Teil 3: Änderungen der Live Services
Teil 4: Änderungen der .NET Services
Teil 5: Änderungen in SQL Azure
Teil 6: Neue Dienste

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.

BLD10_02

Abbildung 10.2: Aufbau von Windows Azure

Windows Azure umfasst damit folgende Bestandteile:

  • Business Portal
    Über dieses Portal erfolgt die Abrechnung der genutzten Dienste. Dabei teilt sich Windows Azure das Portal mit Microsofts SaaS-Angeboten (SharePoint Online, Exchange Online etc.). Somit haben Nutzer stets einen Überblick über die laufenden Kosten für die Nutzung aller Microsoft Cloud Services.
  • Developer Portal
    Entwickler und Administratoren nutzen dieses Portal, um Anwendungen auf Windows Azure zu installieren und zu verwalten. Hier können neue Projekte angelegt und Konfigruationseinstellungen vorgenommen werden.
  • Service Management Service
    Der Verwaltungsdienst führt die Management-Aufgaben, die ihm entweder über das Entwicklerportal oder die neue Management API (von der aus Aufgaben über Webservice-Aufrufe eingehen) übergeben werden, aus.
  • Storage Cluster
    In den Storage Clustern werden die Dienste für den Windows Azure Storage betrieben. Diese sind von den Rechendiensten getrennt. Ein Zugriff ist direkt von Windows Azure-Anwendungen und von außen über REST Webservices möglich.
  • Compute Cluster
    Die VMs zur Ausführung von Anwendungen werden in Compute Clustern betrieben. Diese sind von den Speicherdiensten getrennt.
  • Entwicklungsumgebung
    Für Entwickler stehen zum einen die Tools für Visual Studio (die für Visual Studio 2010 nochmals erweitert werden), zum anderen ein überarbeitetes Software Development Kit (SDK) zur Verfügung.

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.

Windows Azure Compute

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.

Verschiedene Größen virtueller Maschinen

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.).

Nachrichtenaustausch mit Rollen

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).

Logging- und Diagnose-System

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:

  • Messung der Performanz der Anwendung
  • Ermittlung des Ressourcenverbrauchs
  • Fehlersuche und -behebung
  • Überwachung
  • Prüfung der Metriken für die Dienstqualität der Anwendung
  • Kapazitätsplanung (um die Zahl der Anwendungsinstanzen zu optimieren)
  • Auslastungsanalyse (Anwender, Zugriffsstatistiken)
  • Abrechnung und Auditierung der Anwendung

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

Table

Windows Event Logs

deaktiviert

Diagnostics API

Table

Infrastruktur-Logs

aktiviert, lokal gespeichert

Diagnostics API

Table

IIS Logs

aktiviert, lokal gespeichert

Diagnostics API, Web.config

Blob

IIS Failed Request Logs

deaktiviert

Diagnostics API, Web.config

Blob

Application Crash Dumps

deaktiviert

Diagnostics API, Crash API

Blob

Beliebige Logs & Dateien

deaktiviert

Diagnostics API

Blob

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.

Windows Azure Storage

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.

Drives als virtuelle NTFS-Festplatten

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.

  • Ein Drive kann eine Maximalgröße von 1 Terabyte haben
  • Eine VM kann dynamisch bis zu acht Drives anbinden
  • Ein Drive kann zu einem Zeitpunkt nur an eine einzige VM angebunden werden
  • Zugriff von außen erfolgt über die Page Blob API
  • Import und Export von Drives ist möglich. Ein VHD kann über die Blob-Schnittstelle hochgeladen bzw. darüber auch wieder heruntergeladen werden.

Mit Drives hat Microsoft nun eine Möglichkeit geschaffen, Anwendungen, die auf den Zugriff auf ein Dateisystem angewiesen sind, auf Windows Azure zu migrieren.

Offizielle Storage Client Library

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.

Erweiterte Funktionalitäten der Speicherdienste

Die Speicherdienste werden noch um einige weitere Funktionalitäten erweitert. Stichpunktartig die wichtigsten Erweiterungen:

  • Operationen auf Table Entitys können unter bestimmten Voraussetzungen zu Entity Group Transactions (bis zu 100 Anweisungen in einer Transaktion) zusammengefasst werden
  • Auf Tables sind (neben Partition/Row-Key) Sekundärindizes möglich
  • Mittels CopyBlob können Kopien eines Blobs innerhalb eines Storage Accounts angelegt werden
  • Über SnapshotBlob können schreibgeschützte Backups und Versionen eines Blobs erzeugt werden. Kostenpflichtig sind dabei nur jeweils individuelle Versionen von Blöcken über alle Versionen eines Blobs.
  • Für den Blob Storage kann ein Root Blob Container definiert werden. Dieser hat die Form http://mystorage.blob.core.windows.net/$root/blobdocument.xml. Beim Zugriff kann dann die Angabe eines Containernamens entfallen.
  • Für den Windows Azure Storage kann ein eigener Domainname vergeben werden
Content Delivery Network (CDN)

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:

  • Windows Azure Blob Service URL: http://mystorageaccount.blob.core.windows.net/images/
  • Windows Azure CDN URL: http://<guid>.vo.msecnd.net/images/

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.

Version 1.0 der Windows Azure Managed Library

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:

  • Microsoft.WindowsAzure
    Über die Klassen dieses Namespaces können die Credentials für Windows Azure Storage Accounts verwaltet werden
  • Microsoft.WindowsAzure.ServiceRuntime
    Klassen in diesem Namespace erlauben die Interaktion mit der Windows Azure-Umgebung aus einer Role heraus
  • Microsoft.WindowsAzure.Diagnostics
    Die Klassen aus diesem Namespace werden für die Sammlung von Logging- und Diagnosemeldungen benötigt
  • Microsoft.WindowsAzure.Diagnostics.Management
    Klassen dieses Namespaces können dazu verwendet werden Logging- und Diagnoseinformationen auszulesen
  • Microsoft.WindowsAzure.StorageClient
    Dieser Namespace umfasst die Klassen für den Zugriff auf den Windows Azure Storage Service. Die betreffenden Klassen waren während der CTP-Phase im Namespace Samples enthalten.
  • Microsoft.WindowsAzure.StorageClient.Protocol
    Klassen aus diesem Namespace stellen Wrapper für den Zugriff auf den Windows Azure Storage via REST-Protokoll zur Verfügung.

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.

Programmgestützte Verwaltung über die Service Management API

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:

  • Storage Account
    Ein Storage Account bietet Zugriff auf die Windows Azure Storage Services zur Nutzung von Blob, Queue und Table Services.
  • Hosted Service
    Ein gehosteter Service umfasst Web, Worker und VM Roles innerhalb der Windows Azure-Umgebung in der Cloud.

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.

Erweiterte Interoperabilität

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.

Ausblick

Bereits bekannt sind eine Reihe von Weiterentwicklungen, die die Funktionalitäten von Windows Azure deutlich erweitern werden:

  • Gewährung von Administratorrechten auf den VMs
  • Deployment vorkonfigurierter VM-Images (VM Roles)
  • Remote Terminal Server-Zugriff auf die VMs

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.