Kategorie-Archiv: Uncategorized

Azure Event Hubs – Partitions und Retention Time

 

Competing Consumer vs. Partitioned Consumer

Betrachtet man rein den Funktionsumfang den Azure Service Bus Event Hubs und Azure Service Bus Topics/Subscription zur Verfügung stellen, erscheint im ersten Augenblick kein großer Unterschied. Beide Dienste können über verschiedene Protokolle (http(s), AMQP) Daten bzw. Telemetrie von mehreren Sendern entgegennehmen und an multiple Empfänger zur weiteren Bearbeitung weiterleiten.

Einer der großen Unterschiede findet sich in der Möglichkeit Daten mit geringer Latenz und hoher Zuverlässigkeit entgegenzunehmen und dabei zusätzlich eine hohe Bandbreite (aktuell bis zu 1 GB (!!) pro Sekunde) Daten an einen Event Hub zu senden. Dies wird unter anderem dadurch erreicht, dass ein Event Hub ein “Partitioned Consumer” Modell verfolgt. Topic/Subscriptions arbeiten dagegen nach einem “Competing Consumer” Modell. Vereinfacht ausgedrückt verwendet ein EventHub einen “client-seitigen” Cursor. D. h. wenn ein Client von Event Hubs Daten anfordert, so muss dieser dem Event Hub die Stelle bzw. ein Offset mitteilen, ab dem er Daten empfangen möchte. Im Gegensatz dazu verwendet Topic/Subscriptions einen “server-seitigen” Cursor bei dem der Client keine weiteren Informationen welche Daten er abfordern möchte senden muss.

IEventProcessor / Cursorverwaltung

Um die Verwaltung des “client-seitigen” Cursors so einfach wie möglich zu gestalten, stellt Microsoft ein Nuget Package zur Verfügung, welches in der Package Manager Console dem Projekt hinzugefügt werden kann

PM> install-package Microsoft.Azure.ServiceBus.EventProcessorHost

Nach Implementierung des Interface IEventProcessor in einer Klasse müssen die Funktionen CloseAsync(), OpenAsync() und ProcessEventsAsync() implementiert werden. Besonderes Augenmerk liegt hierbei auf OpenAsync(). Die Library startet für jede Partition die bei der Anlage des EventHub definiert wurde eine eigene Instanz der Klasse. Die Referenz auf die jeweilige Partition wird dabei im Parameter PartitionContext übergeben. Dieser PartitionContext kann nun wiederum verwendet werden um die Informationen für den “client-seitigen” Cursor zu speichern. Mit Aufruf der Methode CheckpointAsync() wird die letzte verarbeitete Nachricht gespeichert und bei einem evtl. Neustart der Applikation nicht wieder vom Event Hub abgerufen. 

image

Intern speichert die Library die Informationen über den “client-seitigen” Cursor in einer JSON formatierten Datei  pro Partition in einem Azure Storage Account ab.

{
    „PartitionId“:“0″,
    „Owner“:“MSTechDemoWorker“,
    „Token“:“7886f96a-990c-4049-93a3-432dc159a4fa“,
    „Epoch“:1,
    „Offset“:““,
    „SequenceNumber“:0
}

Retention Time

Bei der Anlage eines Event Hub muss neben der Anzahl der gewünschten Partitionen ebenfalls eine sog. Retention Time (in Tagen) angegeben werden. Der minimale Wert beträgt hierbei ein Tag und der maximale Wert aktuell 7 Tage. Die Angabe der Retention Time legt fest, wie lange der jeweilige Event Hub die eingehenden Daten, für die weitere Verarbeitung durch Konsumenten speichert.

Häufig wird jedoch z. B. bei einer Retention Time von einem Tag davon ausgegangen, dass alle eingegangenen Daten auch automatisch nach Ablauf des einen Tages wieder aus dem Event Hub gelöscht werden. Dies ist nicht der Fall! Die Angabe der Retention Time ist dahingehend zu verstehen, dass die eingegangenen Daten mindestens für diesen Zeitraum zur Verfügung stehen. Gerade während der Entwicklung von Event Hub Consumern muss man häufig die “client-seitigen” Cursor Informationen löschen um wieder mit den “letzten” Test Daten arbeiten zu können. Sehr häufig stellt man dabei fest, dass der Event Hub auch ältere Daten (z. B. Daten welche vor mehreren Tagen an den Event Hub gesendet wurden) zurück meldet, auch wenn man diese aufgrund der Retention Time (von z. B. einem Tag) nicht mehr erwartet.

Um zu verstehen, warum diese Daten trotzdem noch zur Verfügung stehen muss man sich die interne Arbeitsweise des Event Hub näher betrachten. Um die hohe Skalierungsrate zu erreichen, speichert der Event Hub eingehende Daten in Blöcken von definierter Größe pro Partition. Diese Blöcke werden nun wiederum nur gelöscht, wenn diese eine gewisse Größe und die Retention Time überschritten haben. Dadurch erklärt sich auch, warum gerade in der Entwicklung häufig Daten aus einem EventHub zurück geliefert werden, welche die Retention Time bereits überschritten haben. 

Möchte man dieses Verhalten umgehen, ist es möglich, beim Start des EventHubProcessor eine Lambda Funktion für den InitialOffsetProvider zu definieren. Diese Lambda wird wiederum für jede Partition aufgerufen.

image

Ein einfaches Beispiel mit Code Snippets findet sich auf meinem GitHub Account.

dotnetpro 3/15; “Schlankheitskur für dicke Daten”

dotnetpro 03/2015

Unter diesem Titel ist vor kurzem die aktuelle dotnetpro erschienen. Häufig denkt man dabei an “Big Data” und deren Verarbeitung oder Speicherung in einem Parallel Data Warehouse oder in einem Hadoop bzw. HD-Insight Cluster.

Hierbei handelt es sich jedoch um “Data @ Rest”, d. h. die Daten werden zunächst in einem Storage Container gespeichert um danach in batch-ähnlichen Verarbeitungsschritten analysiert bzw. verarbeitet zu werden.

Bei manchen Anforderungen ist dieser Ansatz jedoch nicht leistungsfähig genug. Soll z. B. in einem Datenstrom die aktuelle Temperatur überwacht werden und sobald diese einen bestimmten Schwellenwert überschreitet eine Aktion ausgelöst werden, am besten noch in “Near Real Time”, stößt dieser Ansatz an seine Grenzen.

In meinem Artikel zu Azure Stream Analytics wird in dieser Ausgabe der dotnetpro eine Möglichkeit vorgestellt, wie diese Anforderung elegant umgesetzt werden kann.

Der Artikel findet sich zum freien Download unter folgendem Link.

Azure Event Hub Ingest; Universal App

image Azure Event Hub ist ein weiterer Service innhalb der Azure Service Bus Familie und ist konzipiert für den Daten Ingest mit hoher  Skalierung und Verfügbarkeit. Ein einzelner Event Hub kann z. B. Daten von bis zu 1 Mega Byte (!) pro Sekunde aufnehmen und für weitere Analyse bzw. Bearbeitung speichern.

Das Azure Service Bus SDK macht es einfach Daten in einen Event Hub zu posten bzw. diese zur weiteren Verarbeitung abzurufen. Verwendet man jedoch eine Universal App (Windows Phone, Windows Store App) steht das entsprechende SDK zum aktuellen Zeitpunkt nicht zur Verfügung. Dies stellt jedoch keine große Problematik dar, da Azure Event Hub für den Daten Ingest neben AMQP auch ein REST API zur Verfügung stellt. So kann mit einfachen HTTP Posts ebenfalls ein Daten Ingest durchgeführt werden.

Um den HTTP Post am Event Hub zu autorisieren, muss dieser im Header mit einer Shared Access Signature ausgestattet werden. Hierzu kann die beigefügte Methode CreateServiceBusSASToken() verwendet werden:

private string CreateServiceBusSASToken(string eventHubSASKeyName, string eventHubSASKey, string serviceBusUri)
{
    int expirySeconds = (int)DateTime.UtcNow.AddMinutes(20).Subtract(new DateTime(1970, 1, 1)).TotalSeconds;
    string stringToSign = WebUtility.UrlEncode(serviceBusUri) + „n“ + expirySeconds.ToString();
    string signature = HmacSha256(eventHubSASKey, stringToSign);
    return String.Format(„sr={0}&sig={1}&se={2}&skn={3}“, WebUtility.UrlEncode(serviceBusUri), WebUtility.UrlEncode(signature), expirySeconds, eventHubSASKeyName);
}

public  string HmacSha256(string eventHubSASKey, string serviceBusUriExpiry)
{
    var keyStrm = CryptographicBuffer.ConvertStringToBinary(eventHubSASKey, BinaryStringEncoding.Utf8);
    var valueStrm = CryptographicBuffer.ConvertStringToBinary(serviceBusUriExpiry, BinaryStringEncoding.Utf8);

    MacAlgorithmProvider macAlgorithmProvider = MacAlgorithmProvider.OpenAlgorithm(MacAlgorithmNames.HmacSha256);
    CryptographicHash cryptographicHash = macAlgorithmProvider.CreateHash(keyStrm);
    cryptographicHash.Append(valueStrm);

    return CryptographicBuffer.EncodeToBase64String(cryptographicHash.GetValueAndReset());
}

Der vollständige Code um einen HTTP Post Ingest in EventHub durchzuführen, sieht folgendermaßen aus:

public async Task<bool> TelemetryIngest(Telemetry telemetry)
{

    string serviceBusNamespace = „iotmc-ns“;
    string serviceBusUri = string.Format(„{0}.servicebus.windows.net“, serviceBusNamespace);
    string eventHubName = „IoTMC“;
    string eventHubSASKeyName = „Device01“;
    string eventHubSASKey = „t0JK19v94H3R8yAZ1uVkGcIUFi8zmGmBts4N09aNI0s=“;

    using (HttpClient httpClient = new HttpClient())
    {
        httpClient.BaseAddress = new Uri(String.Format(„
https://{0}“, serviceBusUri));
        httpClient.DefaultRequestHeaders.Accept.Clear();

        string sBToken = CreateServiceBusSASToken(eventHubSASKeyName, eventHubSASKey, serviceBusUri);
        httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(„SharedAccessSignature“, sBToken);
        HttpContent httpContent = new StringContent(JsonConvert.SerializeObject(telemetry), Encoding.UTF8);
        httpContent.Headers.ContentType = new MediaTypeHeaderValue(„application/json“);

        string ingestPath = String.Format(„/{0}/publishers/device01/messages“, eventHubName);
        var response =  await httpClient.PostAsync(ingestPath, httpContent);
        if (response.IsSuccessStatusCode)
        {
            return true;
        }

        return false;
    }
}

Mit Hilfe eines HTTP Post ist es einfach möglich, von einer Universal App, sowohl Windows Phone als auch Windows Store App, Daten an einen EventHub zu senden.

IoT; Themenschwerpunkt dotnetpro

dotnetpro 02/2015In der aktuellen dotnetpro findet sich ein Themenschwerpunkt rund um IoT (Internet of Things). Zum Thema durfte ich ebenfalls einen Artikel zusteuern, der die Funktionalität von Microsoft Azure Event Hubs näher beleuchtet. Im Artikel werden Code Snippets sowohl für den Ingest von Sensordaten als auch für die nachgelagerte Verarbeitung zur Verfügung gestellt. In der nächsten dotnetpro Ausgabe findet sich dann ein Folgeartikel, der erläutert, wie in einem IoT Szenario Ingest Daten mittels Azure Stream Analytics weiterverarbeitet werden können.

Wer noch einen Schritt weiter gehen möchte, findet unter meinem GitHub Account ein einfaches End-To-End Beispiel das als Grundlage für eigene IoT Anwendungen Verwendung finden kann. Nachfolgend eine Übersicht der jeweiligen Projekte im Repository:

MC_PowerShellScripts Anlage eines Azure Service Bus als Host Namespace für einen Event Hub mittels Powershell Script
MC_AdminConsole Anlage eines Azure Event Hub mit SAS Token für Daten Ingest von Sensoren. 
MC_SensorDotNet Daten Ingest in einen Event Hub von managed Code (C#) aus
MC_FieldGateway Daten Sammlung (http Server) + Daten Ingest in Event Hub in Node.js zur Ausführung auf einem Field Gateway
MC_SensorNetduino Daten Ingest von einem Netduino 2 Plus zum Field Gateway. Entwicklung und Debugging in VS 2013 möglich (!)
MC_EventConsumer Auslesen  von Daten aus einem Event Hub in managed Code (C#)
MC_EventConsumerAnalyse Auslesen und Verarbeiten bzw. Analyse von Daten aus einem Event Hub in managed Code (C#).
MC_StreamAnalytics Auslesen und Verarbeiten von Daten aus einem Event Hub bei Benützung von Azure Stream Analytics (identische Funktionalität wie MC_EventConsumerAnalyse)

Viel Spaß beim Entwickeln von eigenen IoT Lösungen.

Nachtrag Technical Summit Berlin / TechEd Barcelona

Vielen Dank an alle Teilnehmer der TechEd 20143 in Barcelona die den gemeinsamen Vortrag von Mario Szpuszta und mir zum WP_20141027_010Thema “Architecting Globally Available and Scalable Solutions on Microsoft Azure” als  einen der Besten Vorträge im Architektur Track gewählt haben. Vielen Dank dafür!

Das Recording des Talks ist mittlerweile auf Channel9 publiziert worden. Für alle die dieses Jahr nicht nach Barcelona zur TechEd kommen konnten, aber Interesse an dem Vortrag haben, findet sich das Recording hier.

Auf dem diesjährigen Technical Summit in Berlin konnte ich aus meiner täglichen Arbeit berichten.  Im Detail gig es um sWP_20141111_016 “Internet  of Things und Big Data in der Praxis: ein Kundenszenario aus der Produktion”. Das Recording incl. des Decks findet sich ebenfalls mittlerweile auf Channel9. Auch hier vielen Dank an alle die den Vortrag besucht haben und in die Top 10 der Veranstaltungsvorträge gewählt haben.

MS Azure und der integrierte Load Balancer bzw. “Bring your own LoadBalancer”

Um die von Microsoft Azure zur Verfügung gestellte 99,95% SLA für die Verfügbarkeit von Cloud Servicen oder Virtuellen Maschinen zu erreichen, müssen immer zwei oder mehr Instanzen des Services bzw. der VM betrieben werden. Die setzt jedoch auch voraus, dass der in Windows Azure kostenfrei und “automatisch” zur Verfügung gestellte Load Balancer verwendet wird.

Der Azure Load Balancer arbeitet auf Layer 4, dem Transport Layer des OSI Modells. D. h. er arbeitet auf individuellen Streams von TCP bzw. UDP Traffic und kalkuliert einen Hash basierend auf dem eingehenden Verkehr. Hierzu werden folgende Werte des eingehenden Traffic verwendet: image

    1. Source IP Adresse
    2. Destination IP Adresse
    3. Protocol Type (TCP/UDP)
    4. Source Port
    5. Destination Port

Dies führt zu einer zufälligen Verteilung von eingehenden Traffic auf die verfügbaren Server bzw. Cloud Services. Sollte der Client eine Verbindung schließen und wieder zur gleichen Zieladresse aufbauen erfolgt dies i. d. R. mit einem neuen Source Port. Dadurch wird eine neuer, unterschiedlicher Hash ermittelt und der Traffic wird ggf. auf einen anderen Server im Set der load balanced Server verteilt. Der Load Balancer ermöglicht auch die Konfiguration des TCP Idle Timeout. Dadurch können offene aber inaktive Verbindungen (Stichwort Long-Polling) nach einem bestimmten Zeitintervall unterbrochen werden. Dieser wert kann zwischen 4 und 30 Minuten variieren.

Sollte dieses Verhalten für einen eigenen Service bzw. Server nicht gewünscht sein, kann der Azure eigenen Load Balancer umgangen werden. Seit Frühjahr 2014 bietet Azure eine neue Service Tier “Basic” an. Diese Tier hat eine ähnliche  Konfiguration wie die “Standard” Gegenstücke, wird aber zu einem deutlichen geringeren Preis und ohne Bereitstellung des Azure Load Balancers angeboten. Gedacht sind diese Tiers hauptsächlich als Entwicklungs-, und Testumgebungen bei denen i. d. R. auch kein Load Balancing benötigt wird.

Basic Tier Hoch Verfügbarkeit

imageNur weil die “Basic” Tier keinen Load Balancer anbietet, heißt das nicht, dass nicht die gleiche SLA wie für die Standard Tier (99,95%) erreicht werden kann. Um die Voraussetzungen für die SLA zu erreichen müssen zwei oder mehr Instanzen in das gleiche Availability Set deployed werden. Zusätzlich kann nun auf diesen Instanzen ein eigener Load Balancer, der den speziellen Anforderungen des eigenen Cloud Service entspricht, installiert werden.

Video Aufzeichnungen der DWX 2014 zum Download verfügbar

imageViele die auf der diesjährigen DWX 2014 in Nürnberg mit dabei waren haben sich sicherlich gefragt, warum in jedem Raum im  Hintergrund so viel Technik vorgehalten wurde. Dieses Jahr wurden die Sessions zum Ersten mal aufgezeichnet und stehen nun im Shop der dotnetpro zum Download zur Verfügung. Wer also vor Ort nicht alle Vorträge besuchen konnte, hat nun die Möglichkeit dies nachzuholen .

Freundlicherweise hat mir die dotnetpro einen Satz von 9 Vouchers für den kostenfreien Download aller aufgezeichneten Sessions zur Verfügung gestellt. Der Voucher hat einen Wert von 236,81 €. Sollte jemand die Möglichkeit zum Download nutzen wollen, kann er sich einfach bei mir melden, frei nach dem Prinzip First Come – First Serve.

Debugging im Zeichen der Cloud

imageDer erste Cloud Service ist mit Hilfe von Visual Studio sehr schnell entwickelt und in Windows Azure zur Verfügung gestellt. Auch das debuggen in der lokalen Entwicklungsumgebung ist altbekannt und stellt uns vor keine besonderen Herausforderungen. Sobald es jedoch zu einer Fehlermeldung im Live-Betrieb kommt ist guter Rat teuer. Wie kann das Problem eingegrenzt und behoben werden? Auf welchen der möglicherweise vielen Instanzen eines Cloud Services kam es zu dem Fehler und warum tritt der Fehler nur hier auf?

Auf dem diesjährigen DotNetDay Franken in Nürnberg konnte ich im Rahmen eines Vortrages Methoden und Tools vorstellen die das Debuggen von Cloud Services ermöglichen. Die Slides zum Vortrag finden sich hier.

Windows Azure Compute / Storage / Services

Zusammen mit Marco Richardson konnte ich am Mittwoch den 26.02.2014 die vielfältigen Services von Windows Azure der Cloud Plattform von Microsoft bei der .NET Usergroup Stuttgart vorstellen.

Cloud Computing ist in aller Munde, aber welcher Cloud Service kann bzw. soll für welche Anforderung eingesetzt werden? Der Vortrag gab einen Überblick über die von Windows Azure zur Verfügung gestellten Services und zeigt anhand einer End-To-End Lösung, wie diese praxisnah und sinnvoll eingesetzt werden können.

Im Vortrag gingen wir über die klassische Präsentation und Auflistung von Funktionen hinaus und haben auf Basis des VidPACK Framework den praxisnahen Einsatz der jeweiligen Services demonstriert.

Das Deck des Vortrages kann hier geladen werden. Das VidPACK Template mit allen Source Code Beispielen findet sich auf meinem GitHUB Account.

VidPACK Framework–Das VoD / Live-Streaming Template

VidPACK Framework - support your usergroups!

VidPACK das Template hinter der offiziellen dotnet Day Franken App im Windows Store.

In Zusammenarbeit mit Marco Richardson und dem Team der Dodneddern ist ein App-Projekt entstanden, um die Sessions des Dotnet Day Franken noch einmal hautnah miterleben zu können. Die App des Dotnet Day Franken kann aus dem Windows Store geladen und installiert werden.

auch für weitere Apps) bildet das VidPACK Framework.Das Framework stellt Visual Studio Projekte (C#) und Templates für die App Entwicklung (C# / XAML) zur Verfügung die einfach in Windows Azure betrieben werden können. Rückgrat der Video Streaming Funktionen von VidPACK sind die Windows Azure Media Services. Für Push Nachrichten wird der Windows Azure Notification Hub verwendet.

Auf dieser Basis können Videos als Stream für alle gebräuchlichen Client Plattformen zur Verfügung gestellt werden. HLS, Smooth Streaming usw. steht ohne Probleme zur Verfügung. Plattformübergreifende Push-Nachrichten an z. B. iOS, Android und Windows Geräte ist ebenfalls kein Problem. Das VidPACK Backend kann ebenfalls plattformübergreifend verwendet werden. So wurde Oktober 2013 während eines Hackathons in Nürnberg ein iOS Client entwickelt. Das VidPACK Framework steht zum Download zur Verfügung und kann als Basis für eigene Projekte verwendet werden.

Gerade für Usergroups stellt sich oftmals die Frage, wie die qualitativ hochwertigen und mit viel Aufwand organisierten monatlichen Vorträge auch für Interessierte die an dem Treffen nicht teilnehmen können zur Verfügung gestellt werden können. VidPACK stellt hierfür eine komplette Lösung zur Verfügung. VidPACK beinhaltet eine Win8.1 App, ein zugehöriges Backend mit Zugriff auf eine SQL Server Datenbank, eine Desktop Maintenance Applikation sowie die Kommunikaiton aller Komponenten untereinander zur Verfügung. Der Source Code kann von meinem GitHUB Account geladen werden.

VidPACK konzentriert sich bewusst auf die Entwicklung der Apps sowie des Backends um eine einfache Adaption eines eigenen UI bzw. eines Corporate CIs zu unterstützen.

VidPackRawHub

Details über die Verwendung und Adaption von VidPACK können auf dem Blog von Marco Richardson nachgelesen werden.