Zum Abschluss meiner Artikelserie zur „Migration von physikalischen SQL Servern in eine VMware Umgebung“, kommt hier nun noch die versprochene Zusammenfassung.
Das Projekt wird als abgeschlossen betrachtet, obwohl aktuell noch ein physikalischer SQL Server „übrig“ ist zu virtualisieren. Das hängt zum einen damit zusammen, dass der Server noch bis Ende 2019 im Hardware Support ist, andererseits aber auch mit der noch unklaren Backup Strategie der virtuellen Maschinen.
Dazu muss ich noch ein wenig weiter ausholen. Derzeit werden die SQL Datenbanken mit Standard Backup Methoden (nativ oder mit Redgate SQLBackup) gesichert (Voll- und Log-Sicherungen) auf einen zentralen Server von dem aus dann täglich Sicherungen in unsere Backup Lösung Quest Rapid Recovery (vormals Dell AppAssure) übertragen werden.
Zusätzlich werden die Produktiv Datenbanken per LogShipping alle 15 Minuten auf separate SQL Server gesichert als Disaster Recovery Lösung.
Ein Wiederanlauf einer Datenbank auf dem LogShipping Server dauert geschätzte 30-60 Minuten wenn die richtigen Ressourcen da sind. Dafür sind die folgenden Aktionen notwendig:
- Zugriff auf alte Datenbanken sperren – falls nicht durch Ausfall des alten Servers so und so geschehen.
- entsprechende Datenbank auf dem LogShipping Server aktivieren, d.h. aus dem Recovery Status rausholen, nachdem das letzte Log angewendet wurde.
- Konfigurationsdateien editieren bzw. entsprechenden CNAME im DNS Server auf den LogShipping Server ändern.
- Danach kann die Anwendung wieder neu gestartet werden.
Soweit so gut für die Datenbanken. 😉
Allerdings ist die VM damit noch nicht gesichert, d.h. bei einem Fehler in der VM zum Beispiel durch Updates usw. gibt es kein Backup der kompletten VM. Durch das fehlende zweite SAN (siehe dazu den ersten Artikel meiner Blog Serie) ist eine Replikation der VMs, und damit eine Sicherung derzeit auf diesem Weg nicht möglich. Ich teste aktuell zwei unterschiedliche VM Backup Programme von Veeam und Vembu um die VMs doch irgendwie sichern zu können, bisher aber funktioniert das noch nicht vollautomatisch.
Da die VMs über eine Vorlage erstellt werden können, dauert die Erstellung zwar nicht so lange wie die Neuerstellung aus einem ISO, eine Komplett-Neueinrichtung mit sämtlichen Konfigurationen (RAM, CPU, Agenten-Jobs, Linked Server, Benutzern usw.) dauert aber dann doch ein wenig länger als eine Rücksicherung einer VM.
Bei einer Migration ist der Quellserver vorhanden um schnell die Konfiguration zu übertragen (mittels dbatools), das geht bei einer defekten VM dann im Zweifelsfall nicht mehr.
Hier sehen wir noch Verbesserungs-Potenzial. Entweder eine regelmäßige Sicherung der VMs oder die Replikation auf ein zweites SAN.
Das ist im Grunde die Erklärung warum wir das Projekt als abgeschlossen betrachtet haben, obwohl noch nicht alle Server virtualisiert sind. Ein weiteres VMware Projekt ist für 2019 geplant, dort werden die Überlegungen mit einfließen.
Zu der Zusammenfassung gehört aber auch der Vergleich vorher/nachher. Dieser beinhaltet auch die Beobachtung ob die drei Hardware Server (ESX Hosts) die Last der ehemals eigenständigen physikalischen SQL Server übernehmen können.
Wir haben dabei die Anzahl der physikalischen Cores reduziert von gesamt 116 auf nun 72 in der VMware Umgebung. Der übrig gebliebene physikalische Server ist schon in der VMware Umgebung vorgesehen, aber noch nicht mit der endgültigen Core Anzahl versehen.
Wie wir feststellen konnten, ist die VMware Umgebung in der Lage alle physikalischen Server abzubilden. Aktuell sind die Ressourcen in den VMs noch nicht reserviert und damit fest zugeordnet. Das wird spätestens mit den restlichen VMs dann notwendig werden.
Hier endet nun die Artikelserie.
Vielen Danks fürs Lesen,
Volker
Das sind die Links zu den anderen Teilen der Artikelserie:
Teil 1: Einführung oder das “Warum?”
Teil 2: Konfiguration VMware Umgebung
Teil 3: VMware Guest Konfiguration
Teil 4: Migration of SQL Server with PowerShell dbatools
Gefällt mir:
Gefällt mir Wird geladen …