7
Kann vMotion eine laufende Datenbank verlustfrei übertragen?
Hallo zusammen,
eigentlich ist es ja eine einfache Frage: Ein Server mit Datenbank (SQL 2008) läuft auf einem Host (A), der mit vMotion auf einen zweiten (B) bereitgestellt wird. Angenommen A hat einen worst case Hardwareschaden, während einer Belastungsspitze, ist es dann möglich, dass vMotion versagt und gewisse Daten nicht auf B vorhanden sind bzw. dass das System nicht ohne Unterbrechung weiterläuft? Wir gehen hier von einem gemeinsam genutzten iSCSI-Speicher aus.
Ist es denn von VMWare offiziell erlaubt/zertifiziert, dies so laufen zu lassen? Welche Probleme könnten sich hieraus entwickeln?
Vielen Dank schon mal.
eigentlich ist es ja eine einfache Frage: Ein Server mit Datenbank (SQL 2008) läuft auf einem Host (A), der mit vMotion auf einen zweiten (B) bereitgestellt wird. Angenommen A hat einen worst case Hardwareschaden, während einer Belastungsspitze, ist es dann möglich, dass vMotion versagt und gewisse Daten nicht auf B vorhanden sind bzw. dass das System nicht ohne Unterbrechung weiterläuft? Wir gehen hier von einem gemeinsam genutzten iSCSI-Speicher aus.
Ist es denn von VMWare offiziell erlaubt/zertifiziert, dies so laufen zu lassen? Welche Probleme könnten sich hieraus entwickeln?
Vielen Dank schon mal.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 232635
Url: https://administrator.de/forum/kann-vmotion-eine-laufende-datenbank-verlustfrei-uebertragen-232635.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
7 Kommentare
Neuester Kommentar
Moin,
With vSphere HA, SQL Server virtual machines on a failed vSphere host can be restarted on another vSphere host. This feature provides a cost effective failover alternative to expensive third party clustering and replication solutions. If you use vSphere HA, be aware that:
vSphere HA handles Sphere host hardware failure but does not monitor the status of the SQL Server services these must be monitored separately.
Proper DNS hostname resolution is required for each vSphere host in a vSphere HA cluster.
vSphere HA heartbeat is sent over the vSphere service console network, so redundancy in this network is recommended.
Grundsätzlich aber die Datenbanksicherung nicht vernachlässigen. Dennn sollte das Filesystem der VM korrupt sein, hilft dir vMotion auch nicht weiter.
SQL - Clustering innerhalb von VMWare ist eine Lösung. Aber es gibt einige Einschränkungen. Dazu gibt es von VMWare einen KB-Artikel.
Grüße,
Dani
Ist es denn von VMWare offiziell erlaubt/zertifiziert, dies so laufen zu lassen?
Auszug aus einer VMWare Doku:With vSphere HA, SQL Server virtual machines on a failed vSphere host can be restarted on another vSphere host. This feature provides a cost effective failover alternative to expensive third party clustering and replication solutions. If you use vSphere HA, be aware that:
vSphere HA handles Sphere host hardware failure but does not monitor the status of the SQL Server services these must be monitored separately.
Proper DNS hostname resolution is required for each vSphere host in a vSphere HA cluster.
vSphere HA heartbeat is sent over the vSphere service console network, so redundancy in this network is recommended.
eigentlich ist es ja eine einfache Frage: Ein Server mit Datenbank (SQL 2007)
Du meinst sicher SQL 2008...ist es dann möglich, dass vMotion versagt und gewisse Daten nicht auf B vorhanden sind bzw. dass das System nicht ohne Unterbrechung weiterläuft? Wir gehen hier von einem gemeinsam genutzten iSCSI-Speicher aus.
Was durch aus sein kann, dass beim Ausfall dei Daten gerade vom SQL-Server noch verarbeitet werden und parallel der Host A ausfällt. Gerade bei größeren SQL-Server die unter permanent unter Last stehen, ist es möglich. Normalfall auf Host B VM wieder starten und weiter geht es. Ansonsten Dateien/Odner sind 1:1 identisch, da der Host nur die VM betreibet aber keine Daten vor hält.Grundsätzlich aber die Datenbanksicherung nicht vernachlässigen. Dennn sollte das Filesystem der VM korrupt sein, hilft dir vMotion auch nicht weiter.
SQL - Clustering innerhalb von VMWare ist eine Lösung. Aber es gibt einige Einschränkungen. Dazu gibt es von VMWare einen KB-Artikel.
Grüße,
Dani
1
@Dani
Er fragt doch nach Vmotion und nicht nach HA.
@Addl123
Wenn das Vmotion an sich sauber funktioniert, dann ist das für den SQL-Server kein Problem. Normalerweise sollte der Netzwerkausfall kleiner als 1 Sekunde sein, was wiederrum ein DB-Client verkraften sollte.
Wenn man jetzt permanent extreme Schreib-Datenströme hat, dann muss man - in jedem HA-Szenario - sowieso hinterher die Konsistenz prüfen.
Wir haben hier 4 große SQL Server als VM im Einsatz und hatten Vmotion-bzgl. noch nie Probleme damit.
E.
Er fragt doch nach Vmotion und nicht nach HA.
@Addl123
Wenn das Vmotion an sich sauber funktioniert, dann ist das für den SQL-Server kein Problem. Normalerweise sollte der Netzwerkausfall kleiner als 1 Sekunde sein, was wiederrum ein DB-Client verkraften sollte.
Wenn man jetzt permanent extreme Schreib-Datenströme hat, dann muss man - in jedem HA-Szenario - sowieso hinterher die Konsistenz prüfen.
Wir haben hier 4 große SQL Server als VM im Einsatz und hatten Vmotion-bzgl. noch nie Probleme damit.
E.
1
Wenn Du von vMotion redest:
A hat als worst case Hardwareschaden beispielsweise einen gleichzeitigen Ausfall aller redundanten Netzteile:
Wie soll vMotion dann die VM migrieren, wenn A sofort runterkracht?
Natürlich hast Du dann eine Unterbrechung und nicht committete Transactionen werden zurückgerollt, nachdem der Rechner auf B NEU gestartet wird.
Solange A noch läuft, ist das migrieren allerdings kein Problem, da hat emeriks recht.
Wenn Du von vSphere Fault Tolerance redest:
Da sollte es gehen, allerdings sind nur VMs mit einer vCPU für FT zulässig, was die Performance etwas behindert.
A hat als worst case Hardwareschaden beispielsweise einen gleichzeitigen Ausfall aller redundanten Netzteile:
Wie soll vMotion dann die VM migrieren, wenn A sofort runterkracht?
Natürlich hast Du dann eine Unterbrechung und nicht committete Transactionen werden zurückgerollt, nachdem der Rechner auf B NEU gestartet wird.
Solange A noch läuft, ist das migrieren allerdings kein Problem, da hat emeriks recht.
Wenn Du von vSphere Fault Tolerance redest:
Da sollte es gehen, allerdings sind nur VMs mit einer vCPU für FT zulässig, was die Performance etwas behindert.
1
Vielen dank, das glaube ich gerne. Was mich persönlich noch interessiert ist ob ein HW-Ausfall schon mal getestet wurde. Ich kann das aktuell leider nicht tun, von daher bin ich auf der Suche danach. 
Mir wurde berichtet, dass vMotion ständig alle Änderungen weiterleitet und im Falle eines Ausfalles (Kann ja auch der Kaffee des Admins auf dem Mainboard sein) der Server einfach auf dem Ziel weiterläuft - mit einem Verlust von einigen Millisekunden bzw. Sekunden. Genau deswegen interessiert mich ja auch was dann mit dem SQL-System passiert, da der RAM sich ja geändert hätte während die DB gleich geblieben wäre, das System also gar nicht weiß was Sache ist. So erscheint mir das ganze ein wenig suspekt (oder ich wurde falsch informiert).
Der "Zauber" beim vMotion liegt "bloß" darin, dass der Arbeitsspeicher der VM zwischen zwei physischen ESX übertragen, synchronisiert und dann umgeschaltet werden muss. Und das passiert nicht ständig sondern nur für die Dauer des Verschiebevorgangs. Wenn also eine VM im eingeschalteten Zustand per vMotion auf einen anderen ESX verschoben werden soll, dann müssen
- schon mal beide ESX auf alle Dateien dieser VM gemeinsam zugreifen können
- die VM darf keine Ressourcen benutzen, die nur dem aktuellen ESX gehören (z.B. USB-Ports, CD-ROM-Laufwerke, lokale HDD)
- benötigen beide ESX jeweils min. einen Vmkernel-Port mit aktivierter Unterstützung für vMotion
- Vmkernel-Ports müssen miteinander über Netzwerk "reden" können.
- die ESX in einem HA-Cluster sein
Bei Start des vMotions fangen die ESX an, den z.Z. genutzten physikalischen Arbeitsspeicher der VM zu kopieren, während die VM einfach weiterläuft. Das muss man sich in etwa so vorstellen, dass der VM-RAM einmal komplett kopiert wird, dann immer wieder nur die geänderten Bytes seit der letzten Kopie, bis die Differenz so klein ist, dass die VM kurz angehalten werden kann, die letzten paar Bytes des RAM kopiert werden, die Prozessor-Werte (Register, Pointer oder weiß der Geier was) übertragen werden und dann der andere ESX die Ausführung der VM fortsetzt.
Aus Sicht des Gastbetriebssystems ist nichts passiert, außer dass die CPU kurz gepennt hat. Und das kann der Gast auch nur dadurch feststellen, dass er die "Uhr beobachtet". Alle Prozesse des Gast laufen 1:1 weiter. Das einzige, wass passieren kann, ist, dass aktive Netzwerkverbindungen, sei es als Client oder als Server, wegfliegen und einen Retry ausführen müssen.
Bezogen auf den SQL Server heißt das also, dass jede Transaktion, welche auf dem SQL Server bereits angestoßen wurde, weiteräuft. Nur wenn diese auf Netzwerkressourcen zugreift (z.B. Replikation, Export/Import usw., auch Backup), kann sie betroffen sein. Die, welche nur in den DB's auf diesem Server laufen, merken nichts. Alle Transaktionen, die gerade im Begriff waren, vom Client ausgelöst zu werden, können möglicherweise in der Erzeugung abbrechen, aber ohne Datenverlust in der DB weil sie ja noch nicht laufen. Hier ist der Programmierer der Clientsoftware sowieso gefordert, so einen Fall zu berücksichtigen und dann ggf. Meldungen am Frontend zu bringen oder einfach einen 2. Versuch (Retry) zu starten. Das hat nix mit vMotion zu tun sondern ganz einfach damit, dass man ja immer damit rechnen muss, dass die Verbindung zur DB wegfliegen kann.
E.
- schon mal beide ESX auf alle Dateien dieser VM gemeinsam zugreifen können
- die VM darf keine Ressourcen benutzen, die nur dem aktuellen ESX gehören (z.B. USB-Ports, CD-ROM-Laufwerke, lokale HDD)
- benötigen beide ESX jeweils min. einen Vmkernel-Port mit aktivierter Unterstützung für vMotion
- Vmkernel-Ports müssen miteinander über Netzwerk "reden" können.
- die ESX in einem HA-Cluster sein
Bei Start des vMotions fangen die ESX an, den z.Z. genutzten physikalischen Arbeitsspeicher der VM zu kopieren, während die VM einfach weiterläuft. Das muss man sich in etwa so vorstellen, dass der VM-RAM einmal komplett kopiert wird, dann immer wieder nur die geänderten Bytes seit der letzten Kopie, bis die Differenz so klein ist, dass die VM kurz angehalten werden kann, die letzten paar Bytes des RAM kopiert werden, die Prozessor-Werte (Register, Pointer oder weiß der Geier was) übertragen werden und dann der andere ESX die Ausführung der VM fortsetzt.
Aus Sicht des Gastbetriebssystems ist nichts passiert, außer dass die CPU kurz gepennt hat. Und das kann der Gast auch nur dadurch feststellen, dass er die "Uhr beobachtet". Alle Prozesse des Gast laufen 1:1 weiter. Das einzige, wass passieren kann, ist, dass aktive Netzwerkverbindungen, sei es als Client oder als Server, wegfliegen und einen Retry ausführen müssen.
Bezogen auf den SQL Server heißt das also, dass jede Transaktion, welche auf dem SQL Server bereits angestoßen wurde, weiteräuft. Nur wenn diese auf Netzwerkressourcen zugreift (z.B. Replikation, Export/Import usw., auch Backup), kann sie betroffen sein. Die, welche nur in den DB's auf diesem Server laufen, merken nichts. Alle Transaktionen, die gerade im Begriff waren, vom Client ausgelöst zu werden, können möglicherweise in der Erzeugung abbrechen, aber ohne Datenverlust in der DB weil sie ja noch nicht laufen. Hier ist der Programmierer der Clientsoftware sowieso gefordert, so einen Fall zu berücksichtigen und dann ggf. Meldungen am Frontend zu bringen oder einfach einen 2. Versuch (Retry) zu starten. Das hat nix mit vMotion zu tun sondern ganz einfach damit, dass man ja immer damit rechnen muss, dass die Verbindung zur DB wegfliegen kann.
E.
2
