Projekt SQL auf VMware – Teil 1 – Einführung oder das „Warum“?
Wir ersetzten die sieben Hardware SQL Server durch eine neue VMware Umgebung.
Dieses Projekt möchte ich hier in einigen Schritten beschreiben vom Warum über die Auswahl bis hin zur (hoffentlich) erfolgreichen Umsetzung.
Das Projekt läuft seit November 2016 mit der Auswahl, die Bestellung ist Ende Januar 2017 erfolgt und jetzt ab März erfolgt die Umsetzung. Geplantes Projektende ist Ende Juli 2017. Bis dahin sollen die Server auf die VMware umgezogen sein.
Zum Anfang aber noch einmal zurück zum
Warum:
- die physikalischen Server laufen nach und nach aus dem Support und müssten ersetzt werden.
- Reduzierung der Kosten für den Neukauf aller physikalischen Server
- Reduzierung der SQL Server 2016 Core Lizenzen – weniger Cores zu lizenzieren
- bessere Hochverfügbarkeit (HA).
- kürzere Wiederherstellungszeiten im Fall eines Disasters (Disaster Recovery – DR)
– wir werden das noch genauer betrachten müssen. - weniger ungenützte Ressourcen auf den physikalischen Servern
Auswahl:
- Zur Analyse und zur Auswahl der Hardware haben wir mit einem Dell Tool (DPack ) die Leistungsdaten der physikalischen Server über eine Woche aufgezeichnet.
- Als ersten Eckpfeiler sahen wir dort ein Maximum von rund 11.000 IOPS welches wir auch entsprechend in der VMware umgesetzt bekommen müssten.
- Das ist nur ein Peak und deshalb als Maximalwert zu betrachten. Der Mittelwert bei 95% liegt bei 2475 IOPS
- Hier zu sehen ist die Zusammenfassung für die 7 Server mit den ermittelten Daten:
- Das ist ebenfalls aus dem DPack-Report, was zwar hauptsächlich für Dell Server gedacht ist, aber meines Wissens durchaus auch für andere Hardware funktioniert.
Darufhin wurde dann eine Auswahl von 3 Dell Poweredge Servern (R730), zwei Dell 10G-Switchen (S4048T) sowie zwei SANs (Compellent SC4020) als zentralem Storage vorgeschlagen.
Für die VMware Version reicht uns an der Stelle die Essentials Plus Variante, da dieses eine komplett eigenständige Umgebung werden soll. Als Betriebssystem in den VMs dient uns Windows 2016 Datacenter mit der richtigen Core Anzahl.
Die SQL Server sind mit SQL Server 2016 Standard inkl. SA in der Core Variante lizenziert, ein einzelner wird auf Enterprise 2016 angehoben für einen Mobile Reports Reporting Server (SSRS).
Bestellung
Leider wurde für die Bestellung aus finanziellen Gründen eines der beiden SANs gestrichen was den Gesamtpreis um ca. 50K reduzierte. Das fehlende SAN beeinträchtigt das Thema HA in nur geringem Maß, ist allerdings für das Disaster Recovery entscheidend.
Bei einem kompletten Ausfall des SANs sind die unternehmenskritischen Produktiv-Datenbanken nun nicht mehr in kürzester Zeit auf dem zweiten SAN verfügbar sondern müssen aus dem Backup wiederhergestellt werden. Hier ist das Ziel der kürzeren Disaster Recovery Zeiten meines Erachtens wieder in weite Ferne gerückt.
Fortsetzung in Teil 2.
Danke fürs Lesen,
Volker