teched 2009: SQL Server 2008 Konsolidierung und Virtualisierung
Konsolidierung und Virtualisierung ist in aller Munde, auch für Datenbanken. Dabei gibt es aber immer einige Bedenken, die besonders bei Datenbanken kritische Punkte sind:
- Performance (vor allem I/O Performance)
- Verfügbarkeit (kann ich 2 Fliegen mit einer Klappe schlagen – Virtualsieren und Hochverfügbarkeit?)
- Verwaltung (wie soll all die virtuellen Server verwalten)
Warum konsolidieren wir überhaupt Systeme. Im Grunde kann man die Argumente für Konsolidierung in den folgenden drei Punkten zusammenfassen:
- Cap-Ex reduzieren (Hardwarekosten, Strom, …)
Op-Ex reduzieren (Mehr Auslastung der Systeme, bessere Verwaltung, Hochverfügbarkeit ist günstiger) - Infrastruktur Agilität (Load balancing, Standardisierung)
Bevor man loslegt, sollten man sich über die richtige Art der Konsolidierung Gedanken machen. Denn entgegen der reflexartigen Aussage Konsolidierung = Virtualisierung gibt es gerade im Datenbankbereich durchaus noch andere Arten Systeme zu konsolidieren:
- Konsolidierung innerhalb einer Instanz = mehrere DB’s (Vorteil: Nur ein Server mit einer Instanz, geringe Kosten, einfache Verwaltung; Nachteil: Resourcenverwaltung/-trennung, Sicherheit, nur ein Datenbankschema für unterscheidliche Datenbanken)
- Konsolidierung in mehreren Instanzen (Vorteil: Nur ein Server, geringe Kosten, Sicherheit durch getrennte Instanzen, optimale Ausnutzung der Hardware Resourcen; Nachteil: Resourcenauslastung (IO Limitierung)
Konsolidierung durch Virtualisierung (Vorteil: Hochverfügbarkeit, echte Isolation zwischen den Applikationen/DBs; Nachteile: höhere Kosten, aufwendigere Verwaltung/Installation, Resourcen)
In vielen Szenarien kann der zweite Punkt – die Konsolidierung in meheren Instanzen – durchaus eine gute Lösung darstellen. Vorallem für nicht kritische, resourcenschonende Anwendungen ist die Methode gut geeignet. Durch die Aufsplittung in mehrere Instanzen und mit Hilfe des Resource Governors kann das Thema Resourcenaufteilung / Verwaltung gut gelöst werden. Einziger Nachteil: die Phasenweise sehr geringe Auslastung von Hardware kann dadurch schlecht optimiert werden.
Die flexibelste, aber auch aufwendigste Methode ist die Virtualisierung. Im Falle des SQL Servers empfehlen wir dazu die Hyper-V Technologie des Windows Servers 2008 R2 einzusetzen. In entsprechender Konfiguration sind die Performance Einbußen im IO, CPU oder Memory Bereich marginal und nur bei Systemen die eine extreme IO Last produzieren von Bedeutung. Als Fallstudie dient das Konsolidierungsprojekt von Mircosoft IT, die seit einiger Zeit die DB Konsolidierung mittels Virtualisierung durchführen. Anhand der Fallstudie kann nachvollzogen werden welches System mit welcher Konfiguration eingesetzt wurde, wie sich die Performance entwickelt und welches Einsparungspotential sich ergeben hat (siehe dazu Grafiken auf der rechten Seite). Alle Informationen dazu unter der URL: xxxxxxxxxxx
Performanceanalyse virtuell vs. nativ
Rot = virtuell, blau = native Installation
Abschließend noch ein paar Tipps von unseren Virtualisierungsexperten und Lehren aus der Microsoft IT Konsolidierung:
- CPU overcommit vermeiden; das führt bei hoher Arbeitslast zu hohen Performanceeinbußen
- Die Hyper-V “Operating System Enlightenments” aktivieren: führt zu einer besseren IO Performance, reduziert Overhead beim Speicherzugriff
- Passtrough und Fixed Size VHDs verwenden; führt zu einer besseren IO Performance
- Dynamische VHDs unbedingt vermeiden!
- Hauptspeicherkapazität kann nicht dynamisch in den virtuellen Maschinen verändert werden; daher am Vorsystem analysieren um optimal zu konfigurieren
- Sehr netzwerkintensive Anwendungen können mehr Overhead verursachen
- Auf neue Prozessorarchitekturen setzen (SLAT, Snoop filter). Hyper-V nutzt diese Technologien aus und erzielt dadurch deutliche Performancegewinne
- Die Konsolidierung von heterogene Workloads am selben Server verhindern
Weiterführende Links:
Martin Pöckl leider nicht mehr live von der teched 2009 :-)
martin.poeckl@microsoft.com
