Fernüberwachung via Cloud

In dieser fünfteiligen Artikelserie beschäftigen wir uns mit der folgenden Frage: Wie können wir Azure-Dienste sinnvoll und sicher in Nicht-Cloud-Applikationen einsetzen? Ich zeige anhand von Beispielen aus meinem Projektalltag verschiedene Szenarien, in denen Cloud-Dienste eine Lösung für gängige Probleme lokaler Applikationen bieten. Im ersten Teil dieser Serie haben wir gesehen, wie die Cloud als Zwischenablage für größere Datenmengen dienen kann. In diesem Artikel geht es darum, einen Roboter am anderen Ende der Welt zu überwachen.

Ziel dieser Serie ist, dass Sie die Möglichkeiten der Azure-Dienste für Ihre eigenen Applikationen erkennen und deren Konzept verstehen. Ich begleite die Artikel auf meinem Blog http://rolandkru.azurewebsites.net/rwwa, wo Sie Links für die technische Umsetzung sowie eine Visual Studio Solution für die Demonstration der Lösung finden.

Das Problem

Beim heutigen Projekt geht es um einen Hersteller von Industrierobotern. Dieser Hersteller exportiert seine Roboter für die Pharma- und Nahrungsmittelbranche in die ganze Welt. Diese Robotersysteme bestehen zum einen aus dem Roboter selbst sowie aus einer Steuerung, die über ein Bus-System mit dem Roboter kommuniziert. Die Steuerung sendet Kommandos an die Motoren und empfängt Signale von den Sensoren des Roboters. Diese Roboter werden mit einem Wartungsvertrag ausgeliefert: Bei Problemen im Betrieb kann sich der Kunde an die Supportabteilung des Herstellers richten. Falls das Problem nicht am Telefon behoben werden kann, muss ein Mitarbeiter zum Kunden reisen, um den Fehler vor Ort zu beheben. Dies führt zu hohen Reisekosten und zeitlichen Verzögerungen. Daher wurde für die Supportmitarbeiter ein Tool entwickelt, das es ermöglicht, den Aufbau jedes ausgelieferten Roboters am Bildschirm zu visualisieren und anhand der Kommunikationstelegramme auf dem Bus das Verhalten des Roboters zu simulieren. Dieses Tool wird sowohl für die Programmierung der Steuerung wie auch für die Fehleranalyse eingesetzt. Abbildung 1 zeigt uns den Aufbau.

Das Problem ist Folgendes: Wie öffnen wir eine Internetverbindung zwischen der Robotersteuerung und dem Simulations- tool des Supportmitarbeiters? Beide Applikationen laufen in Unternehmensnetzwerken und sind damit in der Regel von außen nicht erreichbar. Firewalls blockieren einkommende Verbindungen und der Einsatz von Network Address Translations (NAT) führt dazu, dass keine statischen IP-Adressen verwendet werden können. Wie kann der Support- mitarbeiter also das Simulationssystem mit einem Roboter verbinden, der am anderen Ende der Welt steht und nicht direkt adressiert werden kann?

Die Lösung

Die Lösung heißt „Azure Service Bus Relay“. Dieser Dienst der Azure-Plattform besitzt einen Mechanismus, der es ermöglicht, eine WCF-Verbindung zwischen zwei Systemen zu öffnen, die beide hinter einer Firewall geschützt sind (Abb.2). Dabei öffnen beide Systeme eine ausgehende Verbindung zum Azure Service Bus. Diese Verbindungen werden offen gehalten. Der Sender kann nun eine Nachricht an den Service-Bus senden und dieser leitet sie durch die geöffnete Verbindung weiter an den Empfänger. Die Antwort wird auf demselben Weg zurück an die Cloud und die ausgehende Verbindung des Senders transportiert. Falls gewünscht, kann der Azure Service Bus nach der Initialisierung sogar ein Upgrade auf eine direkte Verbindung zwischen Sender und Empfänger durchführen[1]. Diese Art der Kommunikation ist vergleichbar mit einem Instant-Messaging- Dienst wie etwa Skype.

Abb.1: Wie verbinden wir zwei Systeme, die keine öffentlichen Schnittstellen besitzen?

Die Steuerung und das Simulationstool unseres Roboters können sich also in der Cloud treffen. Die Steuerung sendet alle gesendeten Kommandos und empfangenen Signalwerte via Service-Bus an das Simulationstool. Der Supportmitarbeiter kann dann das Verhalten des Roboters als Simulation beobachten und die Steuerung live debuggen.

Den Azure-Service-Bus-Relay-Mechanismus in einer bestehenden WCF-Applikation zu nutzen, ist sehr einfach: Man muss im Idealfall lediglich die Konfiguration ändern. Im Quellcode selbst müssen keine Anpassungen gemacht werden. Das NuGet-Packet WindowsAzure.ServiceBus fügt die Library Microsoft.ServiceBus.dll zum Projekt hinzu. Teil dieser Library sind sechs WCFBinding-Erweiterungen, die im Detail in[2] beschrieben sind. Das folgende Listing zeigt einen Ausschnitt aus der app.config-Datei des Servers:

<service name=“Server.SimulationServer“>
<endpoint address=“sb://rwwa.servicebus.windows.net/Simulation“
binding=“netTcpRelayBinding“
behaviorConfiguration=“sharedAccessSignatureCredentials“
contract=“Common.ISimulationServer“ />
</service>

In diesem Beispiel wird anstelle des NetTcpBindings einfach das NetTcpRelayBinding aus der ServiceBus.dll verwendet und als Endpoint-Adresse wird der URL des Azure Service Bus Namespace angegeben. Die gleichen Konfigurations- änderungen muss man auch auf der Clientseite machen. Nach der Änderung können Client und Server via Cloud miteinander kommunizieren – trotz Firewalls und NAT.

Beurteilung

Die Lösung zeigt einen einfachen Weg, wie Applikationen über Systemgrenzen hinweg miteinander kommunizieren können, ohne dass sie sich direkt adressieren. Diese Lösung beschränkt sich natürlich nicht auf das Roboterbeispiel: Wir können die Cloud als Treffpunkt nutzen, um Anbieter und Nutzer von Schnittstellen zusammenzubringen. Der Azure Service Bus ist vergleichbar mit einem Enterprise Service Bus (ESB) als Service mit globaler Verfügbarkeit und hoher Ausfallsicherheit. Er eignet sich daher sehr gut für hybride Szenarien, also der Verbindung von lokalen und Cloud-Anwendungen, und für das Internet der Dinge (IoT – Internet of Things), also dem Trend, dass immer mehr Industriegüter über das Internet kommunizieren.

Azure Service Bus

Babylonische Namensverwirrungen haben bei Microsoft Tradition und das ist beim Azure Service Bus nicht anders. Der Azure Service Bus besteht aus drei unterschiedlichen Diensten: Service Bus Relay (um den es hier im Artikel geht), Service Bus Messaging und Service Bus Notification Hub. Service Bus Messaging wurde bereits im ersten Artikel dieser Serie erwähnt: Es ermöglicht eine asynchrone Kommunikation via Cloud mit Warteschlangen (Queues und Topics). Der Dienst Service Bus Notification Hub bietet einen Massenversand von Push Notifications an unterschiedliche mobile Endgeräte. Der Azure Service Bus besitzt einen kleinen Bruder und der heißt Windows Server Service Bus. Der Windows Server Service Bus entspricht dem Azure-Service-Bus-Messaging-Dienst als lokale Installation und setzt auf dem SQL Server auf. Zum Zeitpunkt des Verfassens dieses Artikels ist der Windows Server Service Bus in der Version 1.1 kompatibel mit dem Azure Service Bus SDK Version 2.1,hinkt also der Cloud-Variante etwas nach, welche bereits in der Version 2.3 verfügbar ist[3].

Die Lösung via Service Bus Relay ist geeignet für zeitnahe, synchrone Anwendungen. Alternativ könnte man auch die Kommunikation zwischen Roboter und Steuerung aufzeichnen, um sie später zu simulieren. Dann ist es sinnvoll, die Nachrichten der Steuerung in der Cloud zu speichern, zum Beispiel im Azure Storage. Dies ist ein sehr günstiger, strukturierter Speicher (vergleiche Artikel 1 dieser Serie „Azure Storage als Zwischenspeicher für den Datenaustausch“, in Windows Developer 6.14, S. 50).

Abb. 2: Der Azure Service Bus als Kommunikationsbrücke

Sicherheit

Auch wenn der Service-Bus-Relay-Mechanismus einfach und praktisch ist, müssen wir eines beachten: Wir hebeln mit dieser Lösung bis zu einem gewissen Grad die Sicherheitsfunktionen der Firewall aus und bauen eine Hintertür ein. Wenn wir das tun, müssen wir sicher sein, dass wir kein Sicherheitsloch schaffen. Wie stellen wir also sicher, dass nicht unbefugt via Azure Service Bus auf unsere Applikationen zugegriffen werden kann?

Zunächst einmal sollten wir nach Möglichkeit „Sicherheit by Design“ schaffen. Eine Verbindung sollte beispielsweise nur dann aufgebaut werden können, wenn ein Mitarbeiter des Kunden dies vor Ort erlaubt. Ähnlich wie es eine Zustimmung des Benutzers bei TeamViewer braucht, damit eine andere Person auf den eigenen Desktop zugreifen kann. Weiter sollten von der Steuerung nur Daten gesendet, aber nicht empfangen werden. Damit wird eine Manipulation von außen unterbunden. Weiter können wir, in Verbindung mit den WCF-eigenen Sicherheitsfunktionen, die Kommunikation via Azure Service Bus auf zwei unterschiedliche Arten absichern: Am einfachsten geht es mittels Shared Access Signatures. Dabei verwenden die Applikationen ein 256-Bit starken Schlüssel für die Signatur eines Tokens für den Zugriff auf den Service-Bus. Das Demoprojekt auf der Magazinseite und auf meinem Git-Hub-Account verwendet Shared Access Signatures für die Autorisierung. Die zweite, weitaus komplexere Art der Zugriffsverwaltung ist die Verwendung des Azure Access Control Service ACS.

ACS ist ein weiterer Dienst der Azure-Plattform und ermöglicht eine feingranulare Authentifizierung und Autorisierung von Zugriffsrechten und Benutzern[4]. Zudem unterscheidet der Azure Service Bus die Zugriffsarten „Send“ und „Listen“. Jede zugreifende Applikation kann mit einem oder beiden Rechten ausgestattet werden. „Send“-Applikationen sind WCF-Clients und können Service-Calls ausführen. „Listen“-Applikationen sind WCF-Server und können einen WCF Endpoint hosten.

SLA und Kosten

Das Azure SLA von Microsoft garantiert monatlich  mindestens eine 99,9-prozentige Verfügbarkeit des Service-Bus-Diensts. Pro hundert Stunden kostet der Azure Service Bus Relay 0,08 Euro. Diese Zeit beginnt, sobald eine Applikation sich mit dem Service-Bus verbindet, und endet, sobald sich die letzte Applikation trennt. Die Anzahl der Applikationen spielt dabei keine Rolle. Zusätzlich werden pro 10 000 Nachrichten 0,008 Euro verrechnet, wobei Nachrichten über 64 KB als mehrere Nachrichten verrechnet werden[5].

Fazit

Dieser zweite Artikel in der Serie „Real World Azure“  zeigt, wie die Cloud als Treffpunkt und Weiterleitungsmechanismus für WCF-Applikationen verwendet werden kann, welche sonst keine öffentliche Schnittstelle besäßen. Mithilfe des Azure-Service-Bus-Relay-Mechanismus können Verbindungen zur Cloud genutzt werden, um synchron Nachrichten zwischen lose gekoppelten Systemen zu übertragen. Im nächsten Artikel werden wir sehen, wie mithilfe des Azure Blob Storage Daten aus der Cloud direkt in die eigenen Applikationen eingebettet werden können.

Links & Literatur

[1] http://msdn.microsoft.com/en-us/library/ee173548.aspx
[2] http://msdn.microsoft.com/en-us/library/windowsazure/hh410102.aspx
[3] http://msdn.microsoft.com/en-us/library/dn282143.aspx
[4] http://msdn.microsoft.com/en-us/library/dn170478.aspx
[5] http://azure.microsoft.com/de-de/pricing/details/service-bus/