Hybride Einsatzszenarien

Die Migration "in die Wolke" schien eine Zeit lang ein eindeutiger Trend. Seit Industriespionage und der NSA-Skandal in die Schlagzeilen gerieten, hat die Datensicherheit verstärkt an Relevanz gewonnen. On-Premises-Hosting und Co-Location in einem Datencenter bleiben für viele Unternehmen immer noch der bevorzugte Weg.

Der On-Premises-Einsatz ist genau das Gegenteil einer Public Cloud: Er bietet die ultimative Kontrolle über die Datensicherheit und verursacht dafür höhere Kosten: Hard- und Software, Personalkosten, die Internetanbindung und so weiter. Gilt es, die verfügbare Leistung heraufzuskalieren, stehen dem betroffenen Unternehmen Neuanschaffungen ins Haus. Es gibt auch keine praktikable Möglichkeit, überschüssige Kapazitäten anderen zugänglich zu machen, damit sich die Investition schneller zurückzahlt.

In einem On-Premises-Szenario sind AlwaysOn-Failover-Cluster-Instanzen in der Edition Standard von SQL Server mit SAN-Speicher eine gangbare Option. In der Wolke sieht es anders aus.

Hochverfügbarkeit in der Wolke

Beim Einsatz von SQL Server in einer virtualisierten Umgebung einer Cloud lassen sich Kostensenkungen gegenüber dem On-Premises-Einsatz in Höhe von bis zu 80% erzielen. Virtualisierung bringt jedoch zusätzliche Ausfallrisiken der Infrastruktur mit sich. Umso größer ist der Bedarf nach Hochverfügbarkeitslösungen in der Wolke. Leider sind diese gerade bei SQL Server nicht so leicht zu implementieren.

Ein gutes Beispiel ist AWS (Amazon Web Services, der führende IaaS-Dienstleister). AWS bietet zwei Lösungen für SQL Server: EC2/VPC (Elastic Compute Cloud/Virtual Private Cloud) und einen schlüsselfertigen Dienst namens RDS (Relational Database Service). Beide Dienste unterstützen auch andere Datenbanken, darunter MySQL und Oracle.

Unternehmen, die nun ihre MS-SQL-Server-Umgebung mit Failover-Cluster-Instanzen in die AWS-Wolke migrieren und in EC2/VPC implementieren möchten, erwartet leider eine böse Überraschung: Der Einsatz von AlwaysOn-Failover-Cluster-Instanzen erfordert nämlich die Konfiguration von zwei EC2-Instanzen in demselben Subnetz oder die Verwendung gemeinsam genutzten SAN-Speichers. Keines dieser beiden Szenarien lässt sich derzeit auf AWS umsetzen. Der in EC2/VPC einzige unterstützte Weg zur Hochverfügbarkeit mit SQL-Servern besteht im Einsatz von AlwaysOn-Hochverfügbarkeitsgruppen in der Ausbaustufe Edition Enterprise.