EchEd Europe 2014 – Architecting Globally Scalable Solutions

 TechEd2014

Mario Szpuszta und ich haben auf der diesjährigen TechEd Europe im Vortrag “Architecting Globaly Scalable Solutions” das Toolset an Produkten und Services von Microsoft Azure vorgestellt, mit dem globale, skalierende und ausfallsichere Applikationen in Microsoft Azure entwickelt und betrieben werden können.

Die horizontale Verteilung von Compute Workload (Scale Out) kann sehr einfach durch die Verwendung mehrere statusloser Compute Instanzen gelöst werden. Werden Statusinformationen auf den Instanzen benötigt, kann dies ebenfalls sehr elegant über Services wie z. B. Azure Cache gelöst werden. Hierbei sollte der auf Redis basierende Azure Cache verwendet werden.

Interessant wird es, wenn auch der Data Tier skalieren soll bzw. muss, weil der eingehende Workload nicht mehr von einem einzigen Datenbank Server verarbeitet werden kann. Die Aufrüstung des Servers mit mehr Speicher, HDD bzw. mehr Prozessoren (Scale Up) stellt hierbei i. d. R. nur eine zeitlich begrenzte Lösung dar. Vielmehr sollte auch das Datenbanksystem die eingehende Last auf mehrere Server (virtuell oder physikalisch) verteilen. Azure SQL Database Elastic Scale kann hierbei verwendet werden, um diese Last auf mehrere sog. Shards zu verteilen.

Die notwendigen Binaries um mit Azure SQL Database Elastic Scale zu arbeiten können via Nuget einfach in eigene Projekte eingebunden werden: 

install-package Microsoft.Azure.SqlDatabase.ElasticScale.Clientimage
 

Eine detaillierte Einführung in die Funktionalität stellt Microsoft in der Azure Dokumentation zur Verfügung.  Ebenfalls steht ein End-To-End Beispiel zum Download über den Visual Studio Project Wizzard zur Verfügung. Einfach unter “Online” – “Samples” nach “Elastic Scale” suchen und eines der Beispiele auswählen. Ein Utility zum migrieren von Azure SQL Federation Datenbanken auf Azure SQL Database Elastic Scale wird hierbei ebenso angeboten wie Beispiele für die Verwendung von Entity Framework und “bekannten” ADO.NET SqlCommands.

Im Überblick betrachtet stellt Azure SQL Database Elastic Scale die folgenden Komponenten / Funktionalitäten zur Verfügung:

  1. Funktionalität zur Anlage und Verwaltung einer “Global Shard Map” (GSM). Vereinfacht ausgedrückt ist die GSM eine Sammlung von Tabellen in einer Datenbank welche ConnectionStrings zu Daten Shards speichert. D. h. die GSM weiß, welche Daten in welchem Shard zu finden sind.
  2. Um die GSM als Bottleneck auszuschließen werden deren Informationen auch in den jeweiligen Daten Shards gespeichert (Local Shard Map) sowie in der Client Library gecached. image 
  3. Für den reinen Datenzugriff oder auch Data Dependent Routing genannt stehen Methoden die auf einzelne Daten Shards und auch Shard übergreifende Queries erlauben zur Verfügung. Zu beachten ist im speziellen bei Shard übergreifenden Queries dass es sich hierbei um eine Fan Out Query auf alle Shards handelt. Die Ergebnisse der einzelnen Queries werden in der Client Library ähnlich wie mit einem “Union All” zu einer Rückgabe kombiniert. 

Einige Code Snippets um Azure Elastic Scale zu verwenden finden sich in meinem GitHub Repository. Interessant ist im speziellen der Aufbau der Connection Strings zur GSM Datenbank und den lokalen Shards. Für die Verbindung zur GSM Datenbank (GetGsmConnectionString()) ist der Name der Datenbank (Initial Catalog) mit anzugeben. Die Connection Strings zu den jeweiligen Daten Shards sind jedoch ohne Name der Datenbank zu erstellen.

47         internal static string GetGsmConnectionString()
48         {
49             return new SqlConnectionStringBuilder
50             {
51                 InitialCatalog = Configuration.EsDataBase,
52                 DataSource = Configuration.EsServerName,
53                 UserID = Configuration.EsUserId,
54                 Password = Configuration.EsPassword,
55                 IntegratedSecurity = false,
56                 ApplicationName = "GlobalyScalable",
57                 ConnectTimeout = 30
58             }.ToString();
59         }
60

61         internal static string GetShardConnectionString()
62         {
63             return new SqlConnectionStringBuilder
64             {
65                 UserID = Configuration.EsUserId,
66                 Password = Configuration.EsPassword,
67                 IntegratedSecurity = false,
68                 ApplicationName = "GlobalyScalable",
69                 ConnectTimeout = 30,
70             }.ToString();
71         }
 

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.