Windows Azure AppFabric Teil I – Einführung und Caching Features
Ein strategisch wichtiger Teil der Microsoft Azure-Plattform ist PaaS (Platform as a Service). Ein wichtiges Bindeglied zur Realisierung von SaaS (Software as a Service) ist Windows Azure AppFabric.
Der Azure AppFabric-Cache ist eine zentrale Komponente der Microsoft-Cloud-Strategie
Die Erfahrungen des Autors zeigen, dass das Thema AppFabric die meisten Entwickler noch nicht wirklich erreicht hat. Die häufigsten Annahmen gehen davon aus, dass es sich dabei um eine Plattform im Windows Azure Umfeld handelt. Dies ist insofern nicht falsch, da es zwei Varianten von AppFabric bei Microsoft gibt: Neben Windows Server AppFabric gibt es Windows Azure AppFabric. Beide Varianten sind bereits seit einiger Zeit produktiv im Einsatz. Das Gemeinsame an beiden Varianten ist, neben dem Namen, die Middle Ware-Strategie von Microsoft. Ob man es glaubt oder nicht, beide Varianten besitzen viele gemeinsame Features und sollen in Zukunft zu einer Version verschmelzen, die unter dem Namen „App Fabric“ sowohl als gemeinsame Middle Ware-Komponente sowohl in der Cloud als auch „On-Premise“ zur Verfügung stehen soll. Windows Server AppFabric Windows Server AppFabric (vor der offiziellen Einführung auch als „Dublin“ bekannt) ist Bestandteil von Windows Server 2008 R2. Es kann als Application Server-Feature aktiviert oder auf anderen Betriebssystemen wie Windows 7 einfach installiert werden. Windows Server AppFabric erweitert den Internet Information Server 7 (IIS) und bietet eine Anwendungsinfrastruktur für ein Service Hosting (WCF Services und Workflow Services), ein Monitoring und ein Caching (Letzteres ist unter Namen „Velocity“ bekannt). Windows Azure AppFabric Windows Azure AppFabric ist die Middle Ware-Plattform für die Entwicklung, das Deployment und das Management in der Windows Azure AppFabric. Aktuell besteht sie im Wesentlichen aus drei Diensten: Internet Service Bus, Access Control und Cache. Noch diesem Jahr sollen zusätzlich die Integration Features als weiterer Dienst angeboten werden. Windows Server AppFabric Cache Bevor der Name „AppFabric Cache“ offiziell wurde, lief die Technologie bei Microsoft unter dem Beta-Namen „Velocity“. Velocity ist ein Cache Server (Service), der über mehrere Maschinen einen Cache auf der Grundlage einer „Distributed Cache Technologie“ abbildet (Abbildung 1). Das Prinzip ist trotz es imposanten Namens und komplexer Realisierung einfach. Alle Daten, die häufig benötigt werden, werden zu einem bestimmten Zeitpunkt aus einer Datenbank oder einer anderen Quelle gelesen, wenn gegebenenfalls manipuliert und anschliessend im Cache abgelegt. Werden diese Daten bei der nächsten Abfrage benötigt, werden sie direkt aus dem Cache geholt. Dieses Verfahren eignet sich besonders bei sehr komplexen und daher zeitintensiven Datenbankabfragen.
Abbildung 1: Die physikalische Architektur des Cache
Konfiguration per PowerShell Bei der On Premise-Installation (Windows Server AppFabric) können bei Bedarf Cache-Server und Cache-Client Komponenten getrennt voneinander installiert werden. In der Regel wird man die Server-Komponenten auf mehreren Servern installieren. Die Client-Komponenten werden auf jenen Maschinen benötigt, auf denen die Software läuft und die Daten in den Cache schreibt bzw. sie aus dem Cache liest. Die Client-API basiert auf einer sog. Data Cache Factory-Klasse: DataCacheFactory dcf = new DataCacheFactory(); Ein Cache wird mit einem eindeutigen Namen identifiziert („Named Cache“). Ein Cache wird im Allgemeinen nicht über die Cache-API, sondern anwenderfreundlich mit Hilfe von PowerShell-Befehlen angelegt: New-Cache –CacheName MyCache –Secondaries 0 –Eviction LRU –Expirable true –TimeToLive 10 –NotificationsEnabled false Mit dem CacheName-Parameter wird der Name des Named-Cache auf „MyCache“ gesetzt. Interessant ist die Bedeutung des Secondaries-Parameters. Sein Wert kann gegenwertig auf 0 oder 1 gesetzt werden. Er bestimmt die Anzahl von Kopien jedes Wertes im Cache. Wird ein Wert „N“ mit dem Key „K“ (dazu etwas später mehr) in den Cache geschrieben, wird dieser Wert nur einmal im Cache auf einer Maschine abgelegt, da für Secondaries eine 0 übergeben wurde. Anders ausgedrückt: Der in den Cache geschriebene Wert wird 0 sekundäre Kopien enthalten. Wird für den Secondaries-Parameter dagegen eine 1 übergeben, wird für jedes Element im Cache eine Kopie des Elements auf einer anderen Maschine erstellt. Sollte eine von zwei Maschinen ausfallen, ist der Eintrag immer noch einmal vorhanden (dieses Merkmal heisst „High-Availability“). Es ist wichtig zu erwähnen, dass High-Availability nur dann möglich ist, wenn ein Cluster mindestens drei Cache-Maschinen (Hosts) umfasst. Ausgehend von der Vorgabe, dass beim Ausfall einer Maschine von einem Cache-Eintrag immer noch eine Kopie existieren muss, resultiert die erforderliche Zahl von mindestens drei Maschinen. Der Eviction-Parameter (auf Deutsch „Räumung“) definiert, wie die Elemente im Cache „geräumt“ werden. Die in Frage kommenden Werte sind „None“ und „LRU“ (für „Last Recently Used“). Bei „None“ läuft keine Räumung und Cache-Maschinen können sehr schnell in einen „Out-Of-Memory“ laufen. Für den Wert „LRU“ gibt es zwei Einstellungen, welche die Räumung steuern: Low- und High Watermark. Wenn die „Low Watermark“ erreicht ist, werden die abgelaufenen Elemente geräumt. Bei „High-Watermark“ werden einfach alle Werte geräumt bis der Speicher auf den Wert von „Low Watermark“ gesunken ist. Der TimeToLive-Parameter setzt die Lebenszeit aller Elemente im Cache auf 10 Minuten. Der EnableNotifications-Parameter bestimmt, ob vom Cache Benachrichtigungen verschickt werden. Abbildung 2 zeigt den logischen Aufbau des Distributed Cache in der AppFabric. Es wird deutlich, dass ein Named-Cache im Cache-Cluster über mehrere Hosts verteilt ist. Darüber hinaus kann ein Cache in Regionen aufgeteilt werden.
Abbildung 2: Die logische Struktur des Cache
Die folgende C#-Befehlsfolge zeigt wie Daten in den Cache geschrieben werden: DataCacheFactory dcf = new DataCacheFactory(); DataCache cache = dcf.GetCache(“MeinCacheName”); cache.Add("Element1", 123); cache.Put("Element1", 1234); cache.Add("Element2", “Text Value”);
Zuerst wird mit Add der Wert 123 unter den Key „Element1“ hinzugefügt und gleich danach mit „Put“ der existierende Wert überschrieben. Anschliessend wird der Wert „Text Value“ unter dem Key „Element2“ hinzugefügt. Die folgende C#-Befehlsfolge zeigt wie Daten aus dem Cache gelesen werden: DataCacheFactory dcf = new DataCacheFactory(); DataCache cache = dcf.GetCache(“MeinCacheName”); var o1 = ucdCache.Get("Element1"); var o2 = ucdCache.Get("Element2"); In den Cache können grundsätzlich alle Objekte geschrieben werden, die sich serialisieren lassen. Die Grösse der Objekte spielt dabei keine limitierende Rolle. Zu mindestens in der Theorie, da die physikalische Grösse der Objekte einen direkten Einfluss auf die Grösse des Caches und die Performance besitzt. Wird ein Objekt aus dem Cache ausgelesen, muss die Client-Anwendung den statischen Typ des Caches kennen. Der Windows Azure AppFabric Cache
Der Vorteil von Windows Azure AppFabric Cache liegt in der einfachen Verwaltung. Das bedeutet konkret, dass der Cache nicht installiert und gemanagt werden muss. Aus diesem Grund entfällt auch die Notwendigkeit, PowerShell-Befehle für die Verwaltung einsetzen zu müssen. Den Zugang zum Management Portal (zu diesem Zeitpunkt immer noch aktive und kostenfreie CTP) erhält man unter folgendem Link: portal.appfabriclabs.com. Die vor einigen Tagen veröffentlichte produktive Version kann unter dieser Adresse erreicht werden: https://windows.azure.com/
Der Zugang zum Cache erfolgt über einen Namespace (Abbildung 3). Mit diesem Namen wird der Name des Caches festgelegt. Es handelt sich dabei nicht um einen Named Cache-Namen, wie bei Windows AppFabric Cache. Um Windows Azure AppFabric Cache zu verwenden, benötigt man die Daten, die im Management Portal enthalten sind (Abbildung 3).
Abbildung 3: Die Cache-Verwaltung bei Windows Azure AppFabric
Um per Programm auf den Cache zugreifen zu können, werden die Konfigurationsdaten benötigt. Diese erhält man im Azure Management Portal in der Toolbar „Configuration“ (in Abbildung 3 nicht zu sehen). Hier sind die Konfigurationsdaten hinterlegt, die in der Anwendung verwendet werden müssen.
Die folgende Konfiguration führt einen Zugriff auf den Cache DeveloperWorld-Cache (Abbildung 3) durch:
authorizationInfo="…NvbQ==">
Das Beispiel macht deutlich, dass der erwähnte Namespace keine Definition für den „Named Cache“ ist, sondern ein Hostname. Aus diesem Grund arbeitet man im Host immer mit einem Cache mit dem Namen „Default Cache“. Ein weiterer „Named Cache“ lässt sich gegenwärtig nicht erstellen. Das bedeutet, dass der Befehl
dcf.GetCache(“MeinCacheName”);
nicht funktionieren wird. Werden mehrere Cache-Dienste benötigt, muss einfach ein neuer Namespace erstellt werden (was sich technisch einfach anhört, könnte bei der Abrechnung etwas mehr kosten).
Die folgende C#-Befehlsfolge zeigt wie eine Instanz des Caches abgerufen, Daten in den Cache geschrieben und anschliessend wieder eingelesen werden:
DataCacheFactory factory = new DataCacheFactory();
DataCache cache = factory.GetDefaultCache();
cache.Put("KEY1", 122);
var val = cache.Get("KEY1");
Das kleine Beispiel zeigt, dass der Umgang mit einem Cache grundsätzlich einfach ist. Trotzdem sollte das Caching-Pattern bezüglich seiner Komplexität nicht unterschätzt werden. Um eine maximale Performance zu erzielen, sind gute Kenntnisse über die Funktionsweise des Cache erforderlich.
In den meisten Szenarien wird der Windows AppFabric Cache von Anwendungen verwendet, die im Windows Azure gehostet werden. Tests, die in der Firma des Autors durchgeführt wurden, ergaben, dass Methoden wie Put und Add beim „Serialisieren“ von einfachen Textdaten im Bereich von 120 bis 170 ms lagen. Dies kann nicht als schnell bezeichnet werden. Dabei muss allerdings betont werden, dass die Test Client-Anwendungen in Deutschland lagen und der Test-Cache in San Antonio/USA. Aus diesem Szenario ergeben sich Latenzzeiten im Bereich von 50ms und mehr.
Windows Azure AppFabric als die Microsoft Middle Ware-Plattform
Für Microsoft spielt Windows Azure AppFabric die Rolle einer Middle Ware-Plattform, welche die Entwicklung, Verwaltung und das Deployment von Windows Azure Anwendungen deutlich erleichtern soll. Sie bietet umfangreiche Features, die bisher leider nur sporadisch bekannt sind oder einfach unterschätzt werden. Die aktuelle Version von Windows Server AppFabric ist bereits seit einem Jahr verfügbar. Nachfolgeversionen sind derzeit nicht geplant. Aktuell liegt der Fokus explizit auf Windows Azure. Ob und wann die beiden „Main-Streams“ miteinander schmelzen ist zur Zeit noch offen. Fest steht, dass es eine Angleichung stattfinden soll.
In diesem Artikel zu AppFabric lag der Fokus auf dem Distributed Cache. Es wurde beschrieben wie ein Caching On-Premise und in der Cloud verwendet werden kann. Im zweiten Teil liegt der Schwerpunkt auf dem Windows Azure Service Bus.
Damir Dobric ist CTO und Geschäftführer der Firma Daenet, einem Microsoft-Partnerunternehmen in Frankfurt/a.M
