Resiliente Architekturen und Infrastrukturen in Microsoft® Azure

Der Microsoft Azure Traffic Manager hilft Ihnen dabei, sich vor Ausfällen zu schützen, sowie Ihren Datenverkehr auf mehrere Regionen und Standorte ohne signifikante Verzögerungen bei gleichzeitig permanent hoher Verfügbarkeit bereitzustellen.

Verzichten Sie also auf den Traffic Manager, beschränkt sich der Datenverkehr Ihrer Lösung auf eine einzige Region, die Sie vorab festlegen. Das bedeutet, dass jeder Anwender, der sich nicht in der Nähe der von Ihnen festgelegten Region befindet, möglicherweise mit großer Verzögerung auf Ihre Anwendungen zugreifen kann. Abgesehen davon ist die Gefahr von Dienstunterbrechungen wesentlich höher. Gerne klären wir Ihre Fragen zur Implementierung des Microsoft Azure Traffic Managers. Kommen Sie auf uns zu!

Mit einem sogenannten Load Balancer (also einem Lastenausgleich) lässt sich Ihre Anwendung mit vergleichsweise wenig Aufwand skalieren. Sie können den eingehenden Datenverkehr Ihrer Anwendungen also auf eine beliebige Anzahl von Rechnern verteilen. Weitere Kapazitäten (in Form von Infrastruktur) lassen sich zu Ihrem Load Balancer hinzuzufügen oder bestehende wieder entfernen. Das funktioniert hervorragend insbesondere bei virtuellen Maschinen, aber auch bei Containern (etwa mithilfe von Kubernetes). So lässt sich der Anstieg des Datenverkehrs, aber auch der Lastenausgleich und damit implizit der Ausfall von Infrastruktur signifikant vermeiden. Wenn Sie mehr über den Einsatz eines Load Balancers wissen möchten, kontaktieren Sie unser Expertenteam.

Was passiert eigentlich, wenn Sie keinen Load Balancer vor Ihren virtuellen Maschinen oder Containern einsetzen? Ohne einen Load Balancer sind Sie nicht in der Lage, in die Breite zu skalieren. Ihre einzige Option ist die Skalierung nach oben, um die Kapazität Ihrer virtuellen Maschine zu erhöhen. Damit erhöhen Sie aber wiederum die Fehlerquelle, wie bereits beschrieben, und die Problematik bzgl. der Azure Virtual Machine SLA‘s.

Ein Availability Set ist eine logische Gruppierungsfunktion zur Isolierung von Infrastruktur-Ressourcen (bspw. virtuelle Maschinen) voneinander bereits zum Zeitpunkt der Bereitstellung. Microsoft stellt in Azure sicher, dass virtuelle Maschinen, die Sie in einem Availability Set platzieren, über mehrere physische Server, Computer-Racks, Speichereinheiten und Netzwerk-Switches laufen.

Wenn Sie Ihre Maschinen auf einer Ebene in einem Availability Set einordnen, kommen Ihre virtuelle Maschinen für das „Azure VM SLA“ in Frage. Die Zugehörigkeit zu einem Availability Set stellt auch sicher, dass Ihre Maschinen in verschiedene Update-Domänen (d.h. verschiedene Host-Rechner, die zu verschiedenen Zeiten gepatcht werden) und nicht störungsfreie Domänen (d.h. Host-Rechner, die sich eine gemeinsame Stromquelle und einen gemeinsamen Netzwerk-Switch teilen) eingesetzt werden. Ohne das Availability Set könnten sich alle Ihre virtuellen Maschinen auf demselben Host-Rechner befinden. Somit sind Fehlerquellen für Sie nicht sichtbar. Wenn Sie weitere Informationen über die Erhöhung der Verfügbarkeit Ihrer Infrastruktur mithilfe von Availability Sets erhalten möchten, rufen Sie uns gerne an.

Ohne die Verwendung eines Availability Set sind Sie also nicht in der Lage, die Vorteile des Azure VM SLA zu nutzen. Es bedeutet auch, dass alle virtuellen Maschinen, und somit Ihre gesamten Anwendungen, offline gehen könnten sofern bspw. ein Update auf dem Host-Rechner (also der physischen Maschine, die von Ihnen VMs verwendet wird) durchgeführt wird oder aber es einen allgemeinen Hardwarefehler gibt.

Ein gut skalierbares und ausgereiftes Infrastruktur-Konzept verwendet Virtual Machine Scale Sets (VMSS) um sicherzustellen, dass Sie die Anzahl Ihrer Geräte jederzeit bedarfsgerecht vergrößern oder verkleinern können. Mit VMSS definieren Sie, ob Sie notwendige Kapazitäten (bspw. weitere Serverressourcen) hinzufügen oder entfernen möchten. Die Grundlage dafür sind von Ihnen einstellbare Kriterien. Wenn Sie mehr darüber erfahren möchten, wie Sie die „Scale Sets“ für virtuelle Maschinen von Microsoft Azure verwenden können, um Ihre Ausfallsicherheit bei extremen Lastspitzen (bspw. Traffic) zu erhöhen, wenden Sie sich an unser Expertenteam.  

Ohne ein VMSS schränken Sie Ihre Möglichkeiten zur unbegrenzten Skalierung und zur Optimierung Ihrer Ressourcennutzung unnötig ein. Ein Infrastruktur-Konzept ohne VMSS hat eine obere Skalierungsgrenze, die mit zusätzlichem Quelltext etwa aus der Softwareentwicklung heraus aufgefangen werden müsste. Nicht zuletzt würden fehlende VMSS bedeuten, dass Ihre Anwendung nicht ohne weitere Ressourcen (unabhängig von der Skalierung) hinzufügen oder entfernen kann, welche Ihnen bei der Bewältigung großer Lastspitzen helfen können (z. B. während einer Werbeaktion oder wenn erhöhter Zugriff auf Ihre Website oder Anwendung besteht).

Ein gängiges Verfahren im Bereich der Infrastruktur ist es, einen sogenannten „Premium-Storage“ für Ihre virtuellen Maschinen zu verwenden. Darüber hinaus sollten Sie sicherstellen, dass Sie für jede virtuelle Maschine einen separaten Storage-Account verwenden (das ist selbst bei kleineren Lösungen ratsam). Betriebskritische Anwendungen sollten Storage-Accounts für mehrere Maschinen niemals wiederverwenden. Wenn Sie mehr über den Azure Storage Account erfahren möchten, rufen Sie uns gerne an.

Ein Storage-Account ist jedoch, wie viele andere Ressourcen auch, eine mögliche Fehlerquelle. Obwohl Azure mit dem Storage Account über viele Schutz- und Ausfallsicherheitsfunktionen verfügt, sind Fehlerquellen in keinem Infrastruktur-Konzept einfach hinzunehmen. Wenn zum Beispiel die Zugriffsrechte auf einem Storage-Account kompromittiert sind, ein Speicherlimit oder ein IOPS-Limit erreicht wird, sind alle virtuellen Maschinen, die diesen Storage-Account verwenden, gleichzeitig betroffen.

Die Verwendung von Load Balancern oder Queues zwischen den einzelnen Anwendungen ermöglicht es Ihnen, jede Ebene Ihrer Anwendungen einfach und unabhängig zu skalieren. Sie sollten zwischen diesen Technologien je nach Anforderungen an Latenz, Komplexität und Verteilung (d.h. wie weit Sie Ihre Anwendung verteilen) wählen. Queues haben in der Regel eine höhere Latenzzeit und benötigen auch mehr Speicherkapazität, bieten aber den großen Vorteil, dass sie belastbarer sind. Das führt dazu, dass Sie Ihre Anwendungen über größere Bereiche (z. B. über Regionen hinweg) noch einfacher verteilen können. Wenn Sie mehr darüber erfahren möchten, wie Sie Load Balancer oder Queues verwenden können, wenden Sie sich gerne an uns.

Ohne einen Load Balancer oder eine Queue zwischen den einzelnen Anwendungsebenen ist es schwierig, Ihre Anwendungen nach oben oder unten zu skalieren und die Last auf viele Ressourcen zu verteilen. Wenn Sie dies jedoch nicht tun, kann es im Falle einer plötzlichen Erhöhung Ihres Datenverkehrs zu einer Downtime Ihrer Komponenten und damit dem Risiko von Systemausfällen und damit implizit einer schlechten User Experience führen.

Mithilfe der aktiven Georeplikation können Sie bis zu vier lesbare Sekundärdatenbanken in denselben, aber auch in unterschiedlichen Regionen, konfigurieren. Sekundärdatenbanken kommen dann zum Einsatz, wenn Ihre Dienste unterbrochen werden oder die Verbindung mit der Primärdatenbank nicht möglich ist. Wenn Sie mehr über aktive Georeplikation von SQL-Datenbanken erfahren möchten, kommen Sie jederzeit auf uns zu.

Was passiert, wenn Sie keine aktive Georeplikation mit Ihren SQL-Datenbanken verwenden? Wenn Ihre primäre Datenbank ohne aktive Georeplikation jemals offline geht (geplante Wartung, Serviceunterbrechung, Hardwareausfall usw.), ist diese so lange offline, bis Sie diese in einem intakten Zustand wieder online bringen können. In dieser Zeit stehen Prozesse, welche von der Datenbank abhängig sind, still. Das hat oftmals enorme Auswirkungen auf Ihr Unternehmen und Ihre Geschäftstätigkeit. Um das zu vermeiden, empfehlen wir von der Cloud Business Group bei betriebskritischen Prozessen die Aktivierung einer Georeplikation.

Erfolgt ein erhöhter Zugriff auf Ihre Anwendungen oder aber auf Ihre Datenbank, können Sie die Geschwindigkeit Ihrer Anwendungen steigern und etwa die Zugriffe auf Ihre Datenbank reduzieren, indem Sie eine bestimmte Anzahl von Daten im „Azure Redis Cache“ ablegen. Alternativ lässt sich der „Azure Redis Cache“ auch direkt von Ihrer Datenbank ausgehend implementieren. Um die Skalierbarkeit zu erhöhen, können Sie diesen Vorgang auch mehrfach anwenden. Wenn Sie mehr über den Azure Redis Cache erfahren möchten, hilft Ihnen das Team von der Cloud Business Group gerne weiter.

Was hat es eigentlich zur Folge, wenn Sie keinen Cache vor Ihrer Datenbank verwenden? Wenn Ihr Datenbank-Server leistungsfähig genug ist, um jeden Zugriff, ganz gleich welcher Größenordnung, zu bewältigen, dann werden Ihre Anwendungen wie gewohnt reagieren und natürlich stabil laufen. Eine derart leistungsstarke Datenbank-Infrastruktur bedeutet aber selbstverständlich auch, dass höhere Kosten für eine solche Infrastruktur aufkommen werden, denn damit müssen Sie selbstverständlich für den gesamten Workload direkt gegenüber der Datenbank aufkommen. Wenn Ihr Datenbank-Server jedoch nicht derart leistungsfähig ist (und das ist bei der Cloud Business Group oftmals unsere Beobachtung bei Kunden) und dieser den hohen Anforderungen bzw. Zugriffen nicht immer Stand hält, werden Ihre Anwender definitiv eine schlechtere Performance regelmäßig spüren (Latenz, Timeouts und möglicherweise Ausfallzeiten Ihrer Dienste).

Die Verwendung eines CDN hilft Ihnen (ganz ähnlich wie der Azure Redis Cache gegenüber einer Datenbank), Ihre Server oftmals signifikant zu entlasten. Content wird in den sogenannten „CDN-POP-/edge locations“, die sich rund um den Globus in allen erdenklichen Microsoft Rechenzentren befinden können, zwischengespeichert. Setzen Sie Azure CDN ein, verringern Sie Latenzzeiten oftmals erheblich. Außerdem erhöhen Sie wiederum die Skalierbarkeit, verringern Lasten auf Ihrer Infrastruktur – und bauen zugleich eine Strategie zum Schutz vor Denial-of-Service (DOS)-Angriffen auf. Wenn Sie wissen wollen, wie Sie das Azure CDN nutzen können, um Ihre Ausfallsicherheit zu erhöhen und die Latenzzeit für Ihre Kunden zu verringern, nehmen Sie mit unserem Expertenteam Kontakt auf.

Wenn Sie kein Azure CDN verwenden, wird Ihr gesamter Datenverkehr direkt auf Ihren eigenen Infrastrukturressourcen abgewickelt. Eine höhere Auslastung Ihrer Server wird die Folge sein und die Skalierbarkeit wird verringert. Zusätzlich erleiden Ihre Kunden oftmals höhere Latenzen, denn Azure bietet Ihnen mit dem CDN Standorte auf der ganzen Welt an – Zugriffe erfolgen dann in der Regel direkt vom Anwender zum nächstgelegenen Standort.