Umzug zu Azure: warum und was wir gelernt haben

arrow_downward

 

Looking for the English version instead?

Wie wir bereits vor kurzem angekündigt haben, wechseln wir zu Microsoft Azure Deutschland als unseren neuen Hosting-Partner bis zum Ende des Jahres 2016. Hier erfährst du mehr über die Gründe, unsere Schritte und was wir dabei gelernt haben.

Ein paar Infos zum Hosting des HQ

Vor weit mehr als einem Jahr haben wir diskutiert, wie wir das HQ in Zukunft noch zuverlässiger hosten können. Einer der wichtigsten Aspekte beim Betrieb einer Anwendung ist das Verhalten im Fehlerfall eines Servers. Eine hohe Ausfallsicherheit erreicht man in der Regel, indem man mehrere identische Server mit einem Load Balancer betreibt, der die eingehenden Anfragen von Nutzern auf die Server verteilt. Wenn ein Server ausfällt weiß der Load Balancer, dass die Anfragen nur noch an die verbleibenden, fehlerfreien Server verteilt werden sollen.

So eine Ausfallsicherheit ist nicht nur wichtig für den Anwendungsserver, sondern auch Datenbankserver und viele andere Komponenten des HQ würden von solch einer Struktur profitieren.

Wir haben dann angefangen verschiedene Load Balancing Szenarien für das HQ, unsere Datenbanken und alle ressourcenintensiven Tasks auszuprobieren. Wir haben dabei aber schnell gemerkt, dass das Aufsetzen und Betreiben einer solchen Server-Architektur eine Menge Zeit und Arbeit beansprucht, die wir lieber in die Weiterentwicklung des HQ investieren wollen.

Die Cloud als Lösung

Die Anbieter von Cloud-Plattform wie Microsoft Azure bieten oft skalierbare und redundante Komponenten an, die bereits von Load Balancern vor Serverausfällen gesichert sind, zum Beispiel Datenbanken und Anwendungsserver as a Service. Solche Dienste können auch tagsüber automatisch hoch skalieren und somit höhere Lasten abfangen, um dann Nachts wieder runterzuskalieren. Ein hohes Maß an Ausfallssicherheit ist hier oft inklusive. Azure ist eine solche Cloud-Plattform, welche von Microsoft entwickelt und betrieben wird, und unterstützt besonders, aber nicht ausschließlich, moderne .NET Web Anwendungen wie das HQ.

In den vergangenen Jahren ist Azure weltweit in über 30 Daten- und Rechenzentren gewachsen, welche immer im Doppelpack in einer Region entstehen. Die europäischen Rechenzentren stehen in Dublin und Amsterdam. Aufgrund der empfindlichen Rechtslage und der hohen Datenschutzerwartungen deutscher Kunden können diese ihre Daten oft nur in Deutschland speichern und auch nur von einem deutschen Unternehmen, um den illegalen Datentransfer ins Ausland zu unterbinden. Die bisher in Europa verfügbaren, von Microsoft betriebenen Rechenzentren konnten dieser Erwartung nicht gerecht werden, besonders da Microsoft ein US-amerikanisches Unternehmen ist.azure_db_german

Zu Beginn des Jahres 2016 hat Microsoft angekündigt, auch in Deutschland zwei Rechenzentren zu bauen, welche von T-Systems betrieben werden sollen, um damit alle rechtlichen Bedingungen der deutschen Kunden zu erfüllen. Wir sind der Testphase sehr früh beigetreten und haben seitdem hart daran gearbeitet, das HQ Azure-kompatible zu machen. Microsoft Azure Deutschland ist seit Oktober 2016 offiziell im Betrieb und wir haben unsere Kundensysteme bis Ende 2016 auf Azure produktiv genommen.

Das HQ Azure-kompatibel machen

Damit wir aber von den ganzen Funktionen einer Cloud-Plattform wie Skalierbarkeit und Zuverlässigkeit Gebrauch machen konnten, mussten wir erstmal einige Anpassungen am HQ machen.

Das HQ war bisher entwickelt worden, um auf einem einzigen Server zu laufen und war von dem Zustand des Servers abhängig. Temporäre und hochgeladene Dateien wurden zum Beispiel auf dem Dateisystem des Servers zwischengespeichert. Da wir das HQ jetzt aber auf vielen verteilten Servern laufen lassen wollen funktioniert dies nicht mehr, da die anderen Server ein eigenes Dateisystem haben und der Zustand der Server sich unterscheiden kann. Wenn ein Server zum Beispiel ausfällt und eine Anfrage eines Nutzers auf einem anderen Server landet, kann es es zu Fehlern kommen, da gewisse Dateien dort nicht vorhanden sind.

Als Lösung bietet Azure dafür ein gehostetes, verteiltes Dateisystem an, mit dem wir Dateien speichern können, welche auf allen Servern direkt verfügbar sind. Das funktioniert wunderbar in einem Szenario, wo viele identische Server hinter einem Load Balancer betrieben werden. Wir speichern darin jetzt also temporäre Uploads von Nutzern, kundenspezifische .css Dateien und die Ansichtszustände.

Wo wir gerade von Dateien reden: es gibt noch ein weiteres Problem mit der bisherigen Art Dateien zu speichern. Damit wir die hochgeladenen Dateien von unseren Nutzern zusammen mit den Daten sichern konnten, haben wir diese als sogenannte File Streams in der Datenbank abgelegt. Das ist zwar ein sehr einfacher weg, hat aber auch Nachteile: zum einen wächst die Größe der Datenbank schnell an, das schnell sehr teuer werden kann, und zum anderen werden diese File Streams nicht von Azure unterstützt.

Statt dessen speichern wir die Dateien nun in Azure Blob Storages, ein sehr schneller, zuverlässiger und zudem in Deutschland redundant gesicherter Speicherdienst für viele kleine und große Dateien. Und ebenfalls wichtig: bezahlbar im Vergleich zu großen Datenbanken. So legen wir also nur noch die Links zu den Dateien in unserer Datenbank ab. Dieser Umbau hat uns doch einiges an Arbeit gekostet, wir sind aber sehr zufrieden mit dem Ergebnis. Azure bietet viele Wege, um mit diesem Speicherdienst zu arbeiten und wir haben erst den kleinsten Teil davon genutzt.

Azure Dashboard

 

Um Kundendaten sicher zu trennen speichert das HQ die Daten jedes Kunden in einer eigenen Datenbank. Diese Logik ist tief im HQ verankert und hat sich über die Jahre bewährt. Auf Azure bezahlt man aber normalerweise für jede Datenbank extra und erhält als Gegenleistung eine garantierte Performance jeder Datenbank. Für jede Datenbank einzeln zu bezahlen wäre für uns aber aufgrund der großen Anzahl sehr teuer, und das obwohl die Last pro Datenbank eher gering ausfällt.

 

Azure Elastic Database Pools ermöglichen es uns, viele Datenbanken in einem Pool zu vereinen, die sich eine garantierte Performance teilen. Damit zahlen wir für einen Pool von mehreren Hundert Datenbanken, was die Kosten akzeptabel macht. Datenbanken können so gemeinsam gemanaged werden und zwischen Pools verschoben werden, um dem Performance-Bedarf abhängig von der Last optimal zu entsprechen. Aktuell verwenden wir mehrere Pools mit unterschiedlicher Performance, zum Beispiel für die Kundensysteme und unsere internen Tools. Die Azure API ermöglicht es uns, die Pools zu überwachen, damit wir wenn nötig die Performance-Level anpassen können.

 

Nach einigen Tests und Erfahrung sieht unsere Hosting-Infrastruktur ungefähr so aus. Die Basis bilden Netzwerkinfrastruktur-Komponenten wie ein virtuelles Netzwerk, das mit unserem Büro verbunden ist, sowie ein paar virtuelle Maschinen für unsere Tools und Utilities. Unsere Datenbanken werden in mehreren Elastic Database Pools auf einem von Azure gehosteten SQL Server gehalten. Dazu kommen die erwähnten Blob Storages und das verteilte Dateisystem. Die Anwendung, unsere API und asynchrone Tasks laufen in einer Produktivumgebung sowie mehreren weiteren Umgebungen für Testing und QA.

azure2

 

Unsere Datenbanken zu Azure migrieren

Wir haben das HQ auf Azure eine ganze Zeit lang auf Herz und Nieren geprüft und die gesamte Infrastruktur aufgesetzt, die wir zum Betreiben und Warten der Anwendung benötigen. Alle Komponenten laufen seit einiger Zeit stabil und wir haben das auf Azure gehostete HQ über einen Monat produktiv eingesetzt. Daher sind wir jetzt sicher, dass wir eine stabile und ausfallfreie Architektur für unsere Web-Anwendung, die API und alle anderen Teile des HQ anbieten können.

Der letzte Schritt ist also, die Daten und Dateien unserer Kunden zu Azure zu übertragen und die Systeme dort produktiv zu nehmen. Das haben wir in Batches gemacht, um die Last auf den neuen Servern dabei beobachten und ggf. anpassen zu können. Um das zu tun haben wir eine Migrations-Routine entwickelt, die Backups der Datenbanken erstellt und die Dateien aus unserem alten File Stream in die entsprechenden Azure Blob Storages lädt. Danach sind mehrere Datenbank-Schema-Migrationen, Anpassungen und Verbesserungen nötig. Die Datenbanken werden dann auf dem Azure SQL Server wieder eingespielt und zu dem richtigen Elastic Pool hinzugefügt. Zum Schluss werden alle Konfigurationen und Einstellungen wie Hostnames und DNS-Einträge für jeden Kunden von unserem alten Server zu Azure übertragen. Für das eigentliche Übertragen der Datenbanken haben wir die Command Line Tools des SQL Azure Migration Wizards verwendet, was reibungslos geklappt hat.

Das Hochladen der Dateien war meistens der längste Schritt und hängt von der Menge und Größe der Dateien in der Kundendatenbank ab. In der Regel hat die Migration eines Kundensystems ungefähr 2 Minuten gedauert. Dieser Prozess hat im Dezember in einem nächtlichen Wartungsintervall stattgefunden, welches wir unseren Kunden vorher angekündigt haben. Einige Demosysteme und ein paar unserer Kunden haben uns beim Testen der neuen Infrastruktur unterstützt. Alle anderen wurden im Laufe des Monats Dezember migriert.

Was wir gelernt haben

In den letzten Wochen und Monaten waren wir mit dem Umbau und der Migration aller Kunden auf die neue Azure Infrastruktur beschäftigt. Ausser ein paar wenigen DNS Propagation Problemen ist eigentlich alles wie erwartet verlaufen. Ein paar Dinge haben wir dabei aber gelernt.

Nimm dir Zeit

Einen Umzug zu Azure, oder auch jeder anderen Cloud-Plattform, dauert. Bei uns lag das besonders daran, dass wir eine paar Dinge hatten, die vom Server-Zustand abhängig waren und wir diese für ein Load Balancer Szenario umbauen mussten. Wir wollten, dass das HQ von den Vorteilen der Cloud wirklich profitiert und nicht nur einigermaßen kompatibel ist. Änderungen an Kernkomponenten von einer großen Anwendung wie dem HQ brauchen aber einfach seine Zeit und längere Testzeiträume.

Aber auch unsere Kunden brauchten etwas Vorlaufzeit, bevor wir die Migration durchführen konnten. Da unsere Anwendung teilweise auch auf on-premise gehostete Systeme unserer Kunden zugreift, mussten wir mit deren IT-Abteilungen sichere Remote-Verbindungen einrichten und Firewalls aktualisieren. Azure unterstützt eine Reihe von VPN Gateways, aber nicht alle, weshalb wir mit ein paar Kunden immer noch nachhaltige Lösungen suchen.

Erwarte Änderungen an der Infrastruktur

Es war nicht immer leicht, die richtige Azure Komponente für eine Aufgabe zu finden und wir suchen natürlich weiterhin nach besseren Optionen, um das HQ zu verbessern. Hinzu kommt, dass Azure Deutschland bisher nur einen Teil der Komponenten aufweist, die in globalen Rechenzentren verfügbar sind. Es ist zwar bereits sehr umfangreich und besonders die wichtigsten Dienste sind bereits in Deutschland verfügbar, aber besonders kleinere Details haben uns hin und wieder davon abgehalten, einen bestimmten Dienst zu verwenden. Zum Beispiel konnten Azure Web Apps bisher nicht in virtuelle Netzwerke integriert werden, was uns dazu gezwungen hat, den Traffic zwischen den Web Apps und den Servern im virtuellen Netzwerk zu senden. Bis vor wenigen Tagen war der Redis Cache as a Service auch nur mit sehr begrenzten Ressourcen (bis zu 100MB, wo wir aber mehrere GB benötigen) verfügbar, so dass wir Redis aktuell selbst hosten müssen. Wir glauben aber, dass diese Funktionen in naher Zukunft auch in Deutschland verfügbar sein werden und wir das HQ noch weiter verbessern können.

Als wir die ersten Testsysteme zu Azure gezogen haben, haben wir die Performance des Load Balancers und der Anwendungsserver beobachtet. Aber erst als ein paar produktiv genutzte Systeme auf Azure gehostet waren hatten wir genug Traffic um diesen Fall erst wirklich testen zu können. Wir haben dabei festgestellt, dass der Load Balancer die Anfragen nicht so gleichmäßig verteilt hat wie wir uns das vorgestellt hatten, was zu hohen CPU-Lasten auf einem Server geführt hat während die anderen Server nicht ausgelastet waren. Wir haben bei weiteren Nachforschungen herausgefunden, dass dieser Load Balancer Typ nicht für die gleichmäßige Verteilung von HTTP-Requests geeignet ist und daher für unseren Anwendungsfall die falsche Komponente war. Um eine schnelle Lösung zu finden haben wir uns an den Azure Support gewendet, wo uns ein gerade kürzlich vorgestellter Load Balancer Typ empfohlen wurde. Application Gateways haben sich dann als die richtige Komponente für unsere Situation herausgestellt, bei dem Web Traffic auf mehrere Anwendungsserver verteilt werden soll. Wir haben diese Komponente zusammen mit dem Azure Support konfiguriert und hatten sehr schnell das gewünscht Ergebnis.

Die Experten zu Rate ziehen

Von Anfang an war das Team von Microsoft Deutschland und Azure für alle unsere Fragen offen und stand mit Rat und Tat zur Seite. Von Workshops, vor-Ort und telefonischem technischem Support bis hin zu organisatorischen und rechtlichen Fragen besonders zu den besonderen Datenschutz-Themen haben die Microsoft-Mitarbeiter uns sehr geholfen. Daher ist es sehr sinnvoll, die Experten auf diesen Gebieten in so ein Projekt einzubeziehen. Wir sind sehr dankbar für die Unterstützung, die guten Kontakte und dass wir so einen motivierten Technologie-Partner an unserer Seite haben.

 

Wir sind überzeugt, dass wir die aktuell beste Hosting-Lösung für das HQ in Deutschland anbieten können. Wir freuen uns nun darauf, auch alle weiteren Vorteile der Cloud für uns nutzen zu können. Wir haben den ersten großen Schritt in die Cloud gewagt und in Zukunft werden noch viele spannende Dinge auf euch zukommen. Stay tuned!

 

Hast du Fragen oder selbst Erfahrung mit Azure gemacht? Lass es uns in den Kommentaren wissen.


Get Angularity updates

mail

 

Schreibe einen Kommentar!

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

comment
face
mail
place