Private Cloud mit SQL Server – wie geht das?

Cloud Computing ist in aller Munde, und auch wenn die Public Cloud mit Windows Azure und SQL Azure die höchsten Potenziale für Effizienz, Kosteneinsparung und Elastizität bringt entscheiden sich viele Kunden derzeit für den Aufbau einer Private Cloud für ihre Unternehmensanwendungen. Die Gründe dafür sind vielfältig, vom Wunsch, die Daten im eigenen Haus zu behalten über Features, die derzeit in SQL Azure nicht unterstützt werden bis zur Flexibilität, bestehende Anwendungen mit geringen Anpassungen weiter zu betreiben.

Der Vorteil von SQL Server ist nun, dass den Kunden alle Wahlmöglichkeiten von „keine Cloud“ bis „Public Cloud“ zur Verfügung stehen:

1. Angepasste Installation auf eigener Hardware
2. Angepasste Installation in Hyper-V oder einer anderen Virtualisierungsumgebung
3. Verwendung einer vorkonfigurierten Appliance
4. Aufbau einer Private Cloud
5. Nutzung der Public Cloud mit SQL Azure

In diesem Artikel soll es nun darum gehen, wie ein Private Cloud Projekt mit SQL Server (auch unter dem Titel „Database as a Service“ – DaaS bekannt) aussieht. Dabei geht es mir hier vor allem um den Projektablauf und die einzelnen Schritte. Einen Überblick über die verwendeten Technologien haben Frank Koch und ich bereits im Artikel „Was ist eine Private Cloud und was brauche ich dafür?“ gegeben.

Ein SQL Server Private Cloud Projekt besteht aus 4 Stufen, die eigene Werkzeuge und Vorgehensweisen erfordern und eigene Vorteile bringen:

1. Resource Pooling (Zusammenfassen von Ressourcen)
2. Elasticity (Elastizität)
3. Self-Service (Selbstbedienung)
4. Control & Customize (Überwachung und Anpassung)

Stufe 1: Resource Pooling

Beim Zusammenfassen der Ressourcen geht es zuerst einmal darum festzustellen, was eigentlich alles in die Private Cloud konsolidiert werden soll und darauf aufbauend eine konsolidierte virtualisierte SQL Server Umgebung aufzubauen. Als Ergebnis dieser Stufe laufen alle (soweit möglich) verteilten Datenbankinstallationen in einer zentral verwalteten virtualisierten Umgebung und werden dort einheitlich administriert. Das senkt die Betriebskosten, erleichtert den Administratoren die Arbeit und ist die Basis für jede Compliance-Lösung.

Diese Stufe in vier Teilschritte unterteilen

1a: Untersuchung der bestehenden Umgebung und Kapazitätsplanung

Zuerst einmal muss festgestellt werden, welche Datenbanken in welchen Versionen es eigentlich im Unternehmen gibt und welche davon Kandidaten für eine Konsolidierung sind. Dazu gibt es zwei wesentliche Werkzeuge: das „Microsoft Assessment and Planning (MAP) Toolkit 5.5“ und das „Microsoft Consolidation Planning Tool for SQL Server v1.0 (CPT)“.

Mit dem MAP Toolkit kann man vorhandene SQL Server Installationen (und, wenn gewünscht, Oracle, MySQL und Sybase-Installationen) im gesamten Netzwerk erkennen und erhält daraufhin Berichte, die eine umfassende Darstellung der vorhandenen Datenbank-Infrastruktur sowie Konsolidierungsempfehlungen enthalten. Das CPT ist darauf aufbauend ein Excel-Addin, das Konsolidierungsempfehlungen auf Basis des Ressourcenverbrauchs von SQL Server Instanzen gibt. Im Ergebnis dieses Schrittes hat man einen Überblick über die eigene Datenbank-Landschaft und bereits einen Eindruck, welche vorhandenen Datenbanken konsolidiert werden sollen.

Auf Basis dieser Empfehlungen sollte dann eine Kapazitätsplanung erfolgen: Welche Hardware, Software (für SQL Server empfiehlt sich aufgrund der Lizenzbedingungen häufig eine Enterprise oder Data Center Edition für Konsolidierungen) und Verwaltungswerkzeuge werden benötigt? Wie groß wird meine SQL Server Private Cloud? Zur Vereinfachung der Lösungsplanung wird es bald die „Database Consolidation Reference Architecture“ von Microsoft geben, und im zweiten Halbjahr erscheint die optimierte „Database Consolidation Appliance“ zuerst von HP, später auch von anderen Hardwarepartnern.

1b. Konsolidierung

Als nächster Schritt sollte soweit wie möglich die vorhandene Infrastruktur aus verschiedenen SQL Server Editionen und Versionen und anderen Datenbanksystemen auf einen einheitlichen, aktuellen Stand gehoben werden damit später Verwaltung, Patching und Entwicklung auf einer gemeinsamen Basis erfolgen können. Dazu sollten vorhandene SQL Server Installationen mit dem Upgrade Advisor auf eventuelle Kompatibilitätsprobleme untersucht werden. Für andere Datenbanken wie Oracle, MySQL, Sybase oder sogar Microsoft Access kann man mit dem SQL Server Migration Assistant (SSMA) abschätzen, wie hoch der Aufwand für eine Migration auf SQL Server ist.

1c. Planung der Migration

Je nach Ergebnis der vorigen Schritte wird nun entschieden, wie mit den vorhandenen Datenbanken umgegangen wird. Es gibt 4 Möglichkeiten für jede einzelne Datenbankumgebung:

1. Beibehaltung der bestehenden physischen Infrastruktur. Das kann bei sehr stark ausgelasteten Maschinen sinnvoll sein oder wenn vom Hersteller der Anwendung keine Freigabe für andere Betriebsmodelle besteht
2. 1:1 Überführung der bestehenden physischen Maschine in eine virtuelle Maschine (P2V). Das ist insbesondere dann sinnvoll, wenn kein Upgrade auf eine aktuelle SQL Server Version möglich oder sinnvoll ist oder wenn die Anwendung zwingend eine eigene Betriebssystemumgebung erfordert – in diesem Fall ist evtl. wenigstens ein Upgrade auf ein aktuelles Betriebssystem und eine aktuelle SQL Server Version möglich.
3. Migration auf eine eigene Instanz in einem virtualisierten SQL Server. Das bietet sich an, wenn eine Anwendung Anforderungen wie besondere Rechte oder eine hohe tempdb-Auslastung hat
4. Migration auf eine konsolidierte virtuelle SQL Server Instanz. Das ist die geeignete Methode für alle Datenbanken, die keine besonderen Anforderungen stellen und bringt die höchste Effizienzsteigerung mit sich.

1d Virtualisierung und Verwaltung der Instanzen

Hier werden nun tatsächlich die vorher geplanten Schritte umgesetzt und die neue virtuelle Umgebung auf Basis von Hyper-V (empfohlen: Windows Server 2008 R1 SP1 – wegen Dynamic Memory) und System Center Virtual Machine Manager 2008 R2 (SCVMM) erstellt. Die P2V-Migration übernimmt dabei der SCVMM, die Datenbankmigration erfolgt mit SQL Server Mitteln. Zusätzlich sollte ein Überwachungswerkzeug für SQL Server und Windows eingesetzt werden: System Center Operations Manager (SCOM) (siehe unten)

Als Gesamtergebnis dieses Schritt 1 hat man eine virtualisierte, konsolidierte Umgebung die einheitlich und zentral betrieben und verwaltet wird.

Stufe 2: Elasticity

Die nächste Stufe ist es, die Umgebung elastisch zu machen, das heißt, eine dynamische Lastverteilung zwischen den einzelnen Instanzen und somit eine gesteigerte Skalierung zu erreichen. So ganz nebenbei wird dabei auch das Thema Hochverfügbarkeit geklärt.

Zuerst beschäftigt man sich hier mit dem Thema Hochverfügbarkeit für die einzelnen Datenbanken oder SQL Server Instanzen. Dazu kann SQL Server Clustering (als Guest Cluster in den virtuellen Maschinen) und/oder Database Mirroring eingesetzt werden. Das ermöglicht im Falle eines Fehlers eine schnelle Wiederherstellung ohne Datenverlust.

Darüber hinaus sollte Hyper-V geclustert werden. Das schützt nicht nur vor dem Ausfall eines Servers sondern ermöglicht auch Live Migration der virtuelle Maschinen. Durch Live Migration können virtuelle Maschinen im laufenden Betrieb von einem Hyper-V Host auf einen anderen verschoben werden. Dadurch ist eine schnelle Verteilung der VMs nach aktueller oder prognostizierter Last über verschiedene physische Hosts möglich. Auch ein Upgrade oder Patching des Hosts ist so durch Verschiebung der virtuellen Maschinen auf einen anderen Host deutlich vereinfacht. Bei Verwendung von SCVMM ist auch ein automatisches Load Balancing für eine optimale Performance der virtuellen Maschinen möglich.

Eine weitere Möglichkeit der Ressourcenoptimierung ist Dynamic Memory in Windows Server 2008 R2 Service Pack 1 Hyper-V. Dynamic Memory ermöglicht die Zuweisung einer Spanne an Hauptspeicher für jede virtuelle Maschine (etwa: 4 GB Minimum, 12 GB Maximum). Der Hauptspeicher wird dann nach aktueller Last und nach Priorität („Memory Weight“) zwischen den VMs verteilt. Für den Einsatz von SQL Server mit Dynamic Memory empfiehlt sich die Vergabe des Rechts „Lock Pages in Memory“ an das Dienstkonto sowie die Beschränkung des maximalen SQL Server Hauptspeichers über die Einstellung „Max Server Memory“.

Ergebnis dieser Stufe ist eine hochverfügbare, skalierbare virtuelle Umgebung bei der eine Anpassung der Ressourcenzuteilung basiert auf den aktuellen Anforderungen leicht möglich ist.

Stufe 3: Self Service

In dieser Stufe wird die zentrale Infrastruktur so gestaltet, dass die Nutzer (Fachabteilungen, andere IT-Abteilungen,…) selbst über ein Self-Service-Portal standardisierte Datenbankressourcen anfordern können. Das entlastet die zentrale IT-Abteilung und ermöglicht für die Nutzer einen deutlich einfacheren und schnelleren Zugang zu den benötigten Datenbanken. Darüber hinaus bringt die Standardisierung hier Effizienzsteigerungen bei der Pflege und Wartung der Umgebung.

Zuerst werden Templates (Vorlagen) für die standardisierten Datenbank-Ressourcen im SCVMM erstellt. Wenn später ein Nutzer eine neue Instanz braucht so wird diese direkt aus der Vorlage erstellt. In dieser Vorlage können auch Skripte eingebunden werden, die notwendige Schritte nach einer Provisionierung ausführen (zum Beispiel die Anmeldung bei SCOM für die automatische Überwachung oder die Einrichtung eines Backup-Jobs)

Die Basis für das Self Service Portal ist der „System Center Virtual Machine Manager Self-Service Portal 2.0”. Auf diesem Portal bekommen die Benutzer Rechte, bestimmte Ressourcen anzufordern und neue SQL Server Instanzen auf Basis der Templates anzulegen oder später auch zu entfernen. Das Portal enthält auch einen Freigabeprozess, über den die IT die Anforderungen freigeben kann.

Das Self Service Modell kann je nach Anforderung auch deutlich ausgebaut werden. Sollen zum Beispiel Drittsysteme für Konfiguration, Backup, ITIL-Prozesse oder ähnliches angebunden werden so eignet sich System Center Opalis mit seinen Workflows und den vielen Schnittstellen dazu sehr gut. Soll das Deployment von VMs statt aus Templates flexibler erfolgen so lässt sich eine Basisinstallation + automatisches Softwaredeployment mit System Center Configuration Manager (SCCM) einfach umsetzen.

Als Ergebnis dieser Stufe können Datenbankressourcen einheitlich und schnell provisioniert und genehmigt werden. Das erhöht die Flexibilität für die Nutzer und entlastet die IT-Abteilung.

Stufe 4: Control & Customize

In dieser Stufe wird die einheitliche Provisionierung um eine darauf basierende Abrechnung (charge back) und einen standardisierten Betrieb erweitert.

Für die Abrechnung enthält das Self Service Portal ein Chargeback-Modul, über den die verwendeten Ressourcen den einzelnen Kunden verrechnet werden können. Es gibt vorgefertigte Berichte, die die Nutzung belegen. Soll eine detailliertere Abrechnung auf Basis von tatsächlicher Last oder anderen Faktoren wie Kühlung oder Platzverbrauch erfolgen so ist dies über die Partnerlösung vKernel Chargeback möglich.

 

Mit System Center Operations Manager (SCOM) ist schließlich eine einheitliche Überwachung über die gesamte Umgebung möglich, man kann vom Hyper-V Host über die virtuellen Maschinen bis zum SQL Server mit seinen Komponenten die gesamte Umgebung über ein Werkzeug verwalten. Über Management Packs enthält der SCOM produktspezifisches Wissen und von der Produktgruppe oder auch vom Kunden selbst definierte Regeln. Über die „Performance and Resource Optimization (PRO)“ Management Packs können auch erweiterte Empfehlungen ausgesprochen werden, wie zum Beispiel die Aktualisierung der Integration Components oder das Verschieben einer VM auf einen anderen Host.

Zusammenfassung

Durch die Implementierung der vier genannten Stufen einer SQL Server Private Cloud kann eine optimierte, skalierbare, zentral verwaltbare, effiziente und agile Datenbankumgebung aufgebaut werden die die IT entlastet und für die Nutzer einen schnellen, standardisierten Self Service ermöglicht. Jede einzelne Stufe bringt bereits für sich implementiert deutliche Vorteile, mit allen 4 Stufen bekommt man eine vollständige integrierte Lösung auf Basis verfügbarer Produkte

Weitere Informationen, insbesondere ein Überblicksposter und 2 Präsentationen finden sich auf der SQL Server Private Cloud Seite. Eine Demo der fertigen Umgebung werde ich demnächst als Video auf diesem Blog bereitstellen

Gruß,
Steffen Krause