Hochverfügbarkeit in der Public Cloud
Mit dem Einsatz der Public Cloud verschwindet die Sichtbarkeit von Rechenzentren, Servern und der ganzen Infrastruktur im eigenen Betrieb. Beim fröhlichen Klicken in Web-Konsolen geht leicht vergessen, dass auch die Public Cloud aus «ganz normalen» Systemen und Architekturen besteht.
1 Server ist 1 Server
Ob physisch oder virtuell, ein System bleibt ein System. Dank der Virtualisierung ist zwar dessen «Verschiebung» von einem Blech aufs andere, sowie eine einfachere Wiederherstellung dank Trennung von Rechenleistung und Speicherplatz, möglich. Doch es bleibt ein System. Fallen eine oder mehrere der darunterliegenden Komponente aus, so ist das System weg. Dies ist auch in der Public Cloud nicht anders. Diese Gesetzmässigkeiten gelten nicht nur für VMs, sondern auch für alle potentiell bezogenen Cloud-basierten Dienste, wie beispielsweise Datenbank-Services (Was ist Database as a Service (DBaaS)? ).
Hochverfügbarkeit in der Public Cloud
Es empfiehlt sich also, auch in der Public Cloud Hochverfügbarkeit anzustreben und Systeme und Anwendungen dementsprechend zu konzipieren. Public-Cloud-Anbieter nutzen zu diesem Zweck Verfügbarkeitszonen (Availability Zones, AZs) und Regionen. Typischerweise befinden sich in einer Region mehrere Availaibilty Zones, die voneinander isoliert sind. Dies entspricht in etwa zwei unabhängigen Rechenzentren am selben Ort.
Hochverfügbarkeit in Azure wird beispielsweise so erreicht, dass VMs physisch über Zonen hinweg getrennt werden und an jedem Standort, mit Hilfe von Load Balancern, ein virtuelles Netzwerk erstellt wird:
Quelle: Azure
- Zonenredundanten Load Balancer
- Front-End-Subnetz einrichten
- DB-Subnetz einrichten
- VMs in drei Verfügbarkeitszonen
- Konfigurieren von zonenredundanter SQL-DB
- Hinzufügen der VMs zum Back-End-Pool des Load Balancers
- Bereitstellung der Anwendung auf VMs für Redundanz und Hochverfügbarkeit
SLA: 99% pro Monat, ein Typo?
Was aus technischer Sicht mehr als empfehlenswert ist, lässt sich auch anhand der SLA der Public Cloud Provider ableiten. Für den Betrieb einer VM in einer Availability Zone beispielsweise weist Azure gar keine Verfügbarkeit aus. Erst wer seine VMs in mindestens 2 Availability Zones verteilt kommt in Genuss eines SLA. Dieses wird mit 99.99% pro Monat angegeben. Beim genauer lesen wird man aber feststellen, dass die Konsequenzen bei Nichterfüllung erst bei einer viel tieferen Verfügbarkeit wirklich ins Gewicht fallen. Und selbst dann fallen diese nur in Form von «Service Credits» an:
Fazit
Auch im Zeitalter der Public Cloud muss man die Anforderungen an die Verfügbarkeit der eigenen Anwendung ausformulieren. Daraus kann die Technik die richtige Architektur ableiten. Auch in der Public Cloud gelten die physikalischen Gesetze und die SLAs müssen gelesen und verstanden werden. Der Baukasten «Public Cloud» verfügt über alle nötigen Elemente, mit der richtigen Auswahl und Zusammenstellung erreicht man seine Ziele - mit dem entsprechenden Preis, versteht sich.
-
Azure Availability Zones: Hochverfügbarkeit in Azure (Computerweekly)
-
AWS and Azure High Availability: Architectures, Service Options, and Benefits (NetApp-Blog)
-
AWS Regions and AWS Availability Zones (NetApp-Blog)
-
SLA for Virtual Machines (Microsoft Azure)