Azure Rechenzentren verstehen
Microsoft Azure ist der einfache Weg für schnelle und skalierbare Dienste in der Cloud. „Cloud“, das bedeutet im üblichen Sprachgebrauch das Konsumieren von Diensten bei gleichzeitig geringerem Aufwand und Verantwortung für die Infrastruktur. Microsoft 365 als Software-as-a-Service-Dienst ist hier ein tolles Beispiel, wie Dienste aus der Cloud ohne Serverbetrieb nutzbar sind.
Hinweis: Die wichtigsten Begriffe rund um das Thema Azure finden Sie in unserem Azure Glossar.
Microsoft Azure bietet verschiedene Möglichkeiten, Dienste bereitzustellen und diese zu verwalten. Unterschieden wird hier zwischen den verschiedenen „shared responsibility“-Modellen, bei denen ein Teil der Verantwortung bei Microsoft und der andere Teil beim Nutzer liegt:
Das nutzbare Modell ist abhängig von der Art des Dienstes, der bereitgestellt werden soll.
Eine virtuelle Maschine ist ein ganz klassischer Infrastructure-as-a-Service (IaaS)-Dienst. Der Betrieb und die Verwaltung der physischen Infrastruktur zum Betrieb der virtuellen Maschine liegt bei Microsoft. Der Nutzer ist ab der Betriebssystemebene verantwortlich für die Konfiguration und den Betrieb.
Der Nutzer administriert bei klassischen IaaS-Diensten das VM-Objekt und sorgt durch andere Dienste wie Backupservices für eine höhere Ausfallsicherheit, muss sich aber nicht um den Betrieb der physischen Infrastruktur sorgen. Werden stattdessen Software-as-a-Service (SaaS)-Dienste genutzt, wird die Ausfallsicherheit meist vom Anbieter des Dienstes gewährleistet.
Für die Konfiguration einer höheren Ausfallsicherheit von genutzten Diensten werden direkte Bereiche des Azure Rechenzentrums in der Konfiguration referenziert. Den Aufbau eines Azure Rechenzentrums zu verstehen hilft also, die richtige Wahl bei der Konfiguration der Hochverfügbarkeit zu treffen.
Verteilung & Aufbau eines Rechenzentrums
Microsoft’s Azure-Rechenzentren sind auf dem ganzen Globus verteilt und werden nach geografischen Regionen benannt, weswegen diese auch „Region“ genannt werden. „Regions“ werden immer paarweise gebaut und betrieben, wobei sich ein Paar immer innerhalb derselben geografischen Region befindet.
Ein Beispiel: Die Region „Germany West Central“ (Frankfurt am Main) hat die Paar-Region „Germany North“ (Berlin). Bei der Paar-Konstellation dient eine Region als Haupt-Rechenzentrum, die andere als Disaster Recovery-Region. Diese Konstellation ist der Standard für Microsoft Azure Rechenzentren. Es ist kein direkter Zugriff zur Ressourcenerstellung auf die Disaster Recovery-Region möglich. Hierbei gibt es jedoch auch Ausnahmefälle:
Besondere Anforderungen, beispielsweise der Betrieb sensibler Infrastruktur mit medizinischen Daten. In solch einem Fall prüft Microsoft den Bedarf und schaltet die einzelnen Tenants für die Disaster-Recovery-Region zur normalen Dienstnutzung frei.
Availability Zones
Betrachtet man eine einzelne Region, so sind in dieser Region verschiedene Gebäude bzw. Gebäudegruppen, angesiedelt. Diese einzelnen Gebäude werden „Availability Zones“ (Verfügbarkeitszonen) genannt. Jede dieser Gebäudegruppen arbeitet autark, also mit einer eigenen Stromversorgung, eigener Netzwerkanbindung, eigener Kühlung und weiteren benötigten Systemen. Die einzelnen Gebäudegruppen werden als Availability Zone 1, Availability Zone 2 und Availability Zone 3 bezeichnet.
Werden in Azure nun IaaS-Dienste wie virtuelle Maschinen genutzt, können diese Availability Zones gezielt angewählt werden. Dadurch können verschiedene virtuelle Maschinen gezielt über verschiedene Gebäudegruppen hinweg verteilt werden, um eine Hochverfügbarkeit zu gewährleisten. Das normale SLA wird durch diese Maßnahme nochmals erhöht. Es besteht also die Möglichkeit, die virtuelle Maschine in einer Zone, oder Replica meiner VM in mehreren Availability Zones aktiv zu nutzen.
Availability Sets
Innerhalb Azure sind weitere Möglichkeiten vorhanden, die SLA und damit die Verfügbarkeit zu erhöhen. Availability Sets geben die Möglichkeit, mehrere VM’s in einem Set zu gruppieren, um diese gezielt über unterschiedliche Hardware in einer Availability Zone zu verteilen.
Hierbei gibt es innerhalb eines Availability Sets die sogenannten „Fault Domains“ (Fehlerdomänen) und die „Update Domains“ (Updatedomänen).
• Als Fault Domain (FD) wird die Gruppe der virtuellen Computer bezeichnet, die sich einen gemeinsamen Netzwerkswitch und eine gemeinsame Stromquelle teilen. Kurz gesagt: VM’s, die im selben Rack betriebenwerden.
• Als Update Domain (UD) wird die Gruppe der virtuellen Computer bezeichnet, die gleichzeitig neu gestartet werden kann, beispielsweise aufgrund einer von Microsoft geplanten Wartung.
Jede erstellte VM wird bei Zuteilung zu einem Availability Set automatisch einer Fault Domain und einer Update Domain zugeordnet. Hierbei sind maximal drei Fault Domains und 20 Update Domains konfigurierbar. Wenn innerhalb eines Availability Sets mit fünf konfigurierten Update Domains eine sechste virtuelle Maschine ergänzt wird, dann wird diese der ersten Update Domain hinzugefügt, die siebte VM der zweiten Updatedomain usw.
Durch die Nutzung von Availability Sets lassen sich so Ausfälle durch Hardwarefehler im Rechenzentrum oder (un-)geplante Wartungen umgehen.
Ausfallsicherheit für Storage-Lösungen
Availability Zones und Availability Sets sind für Computing geeignet. Eine Hochverfügbarkeit ist aber nicht nur relevant für Computing, sondern auch für den Datenspeicher, also wie Daten gespeichert werden. Bei Verwendung einer virtuellen Maschine in einem Availability Set wird die angehängte Disk automatisch danach ausgerichtet, in welcher Fault Domain sich die VM befindet. Wie verhält es sich aber mit anderen Storage-Lösungen wie Speicherkonten oder dem Datenspeicher in PaaS/SaaS-Lösungen?
Azure Storage wird immer dreimal synchron repliziert. Folgende Konfigurationen sind in Azure verfügbar:
• Ein dreifaches Replica der Daten innerhalb einer Availability Zone wird „Local redundant storage“, oder auch kurz „LRS“ genannt. LRS ist die kostengünstigste Variante. Gibt es jedoch einen Ausfall in der Availability Zone, könnten alle Replica davon betroffen und die Daten nicht wiederherstellbar sein.
• Die nächsthöhere Konfiguration repliziert Daten synchron über mehrere Availability Zones hinweg. Hier kommen also die Zonen dazu, weswegen diese Option „Zone redundant storage“, kurz „ZRS“ genannt wird. ZRS schützt vor dem Ausfall einer oder zwei Availability Zones, jedoch nicht vor dem Ausfall einer kompletten Region.
• „Geo-redundant storage“ (GRS) beschreibt eine Datenspeicherung mit LRS in einer Region und eine anschließende Replikation und Speicherung der Daten in die Disaster Recovery-Region mit LRS.
• Die letzte, mögliche Option lautet „Geo-zone-redundant storage“ (GZRS) und dient der Datenspeicherung in der primären Region nach ZRS, repliziert anschließend die Daten in die Disaster Recovery-Region und speichert dort die Daten mit LRS
Bei den Geo-replizierenden Varianten sind die Daten, welche sich in der anderen Region befinden, nicht verfügbar für lesenden/schreibenden Zugriff außer natürlich im Falle eines Failovers. Sollen die Daten dennoch ohne einen Failover lesbar sein, dann ist es möglich einen Lesezugriff mit den Optionen „Read-Access-Geo-redundant storage“ (RA-GRS) und „Read-Access-Geo-Zone-redundant storage“ (RA-GZRS) zu konfigurieren.
Fazit
Egal, welches Shared Responsibility Modell genutzt wird: Zu Wissen, wie ein Azure Rechenzentrum aufgebaut ist, hilft bei der richtigen Wahl für die Konfiguration der Hochverfügbarkeit.
Ob die Wahl nun auf ein Availability Set oder eine Availability Zone fällt und welche Datenredundanz nötig ist, ist individuell abzuwägen. Sind Daten aufgrund der Datenmenge schwer sicherbar, so fällt die Wahl eher auf eine höhere Redundanz.
Das Thema „Backup“ ist ebenfalls nicht zu vernachlässigen und wird oft in einem Atemzug mit „Redundanz“ genutzt, sind es doch aber zwei grundverschiedene Dinge. In Azure gibt es spannende Backup-Mechanismen, mit welchen man sich im Zuge eines Disaster Recovery Plans ebenfalls beschäftigen sollte.
Dennoch ist ein Backup neben den verschiedenen Verfügbarkeitsoptionen bei hochkritischen Systemen Pflicht, ein Disaster Recovery Plan sollte immer verfügbar sein.