Unter GSX3 ist es im gegensatz zu GSX2.5.1 möglich VMs on the fly zu backupen. wie funktioniert das technisch wenn währeddessen in den VMs daten geschrieben werden?
sind die backups dann konsistent? werden die funktionieren wenn man sie einschaltet?
hintergrund ist dass ich webserver unter GSX betreibe bei denen alles on the fly passieren muss weil es keinen zeitpunkt gibt um sie runterfahren zu können.
sollte das einfache kopieren der maschinen nicht empfehlenswert sein wie kann man dann ein automatisches backup on the fly der kompletten maschine realisieren?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
VMs unter GSX3 on the fly backupen
was gelesen?
dass das backupen on the fly möglich ist habe ich ausprobiert.
wenn man eine gsx2.5.1 maschine im laufenden betrieb kopiert und während dieser zeit schreibzugriffe in der vm stattfinden stoppt gsx2.5.1 die vm (wie beim shrinken der vmdks) und man muss nach dem kopieren manuell bestätigen damit sie wieder online geht.
gsx3 stoppt die vm nicht, d.h. schreibzugriffe während des kopierens der vmdk files sind möglich.
dass das backupen on the fly möglich ist habe ich ausprobiert.
wenn man eine gsx2.5.1 maschine im laufenden betrieb kopiert und während dieser zeit schreibzugriffe in der vm stattfinden stoppt gsx2.5.1 die vm (wie beim shrinken der vmdks) und man muss nach dem kopieren manuell bestätigen damit sie wieder online geht.
gsx3 stoppt die vm nicht, d.h. schreibzugriffe während des kopierens der vmdk files sind möglich.
Tja und wenn schreibzugriffe möglich sind dann kannst du das backup vergessen. die vmdk files sind dann inkonsistent. ein komplettes backup einer maschine während sie läuft und daten empfängt ist nur noch für den papierkorb gut.
*habs getestet*
wenn die maschine allerdings im ruhezustand ist, bzw. nur daten von ihr gelesen werden, dann gehts.
*habs getestet*
wenn die maschine allerdings im ruhezustand ist, bzw. nur daten von ihr gelesen werden, dann gehts.
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Hi
im laufendem System Snapshot machen - dann die Basis-vmdk back-upen - und anschliessend den Snapshot entfernen.
O-ton Petr:
Kann ich leider nicht testen - ich hab kein GSX.
Continuum
im laufendem System Snapshot machen - dann die Basis-vmdk back-upen - und anschliessend den Snapshot entfernen.
O-ton Petr:
I really do not know what you are looking for. If you are looking for online backuping, just take snapshot, backup non-REDO .vmdk, and then delete snapshot. That way you'll loose some time while taking snapshot, some while deleting it, but while you are backuping .vmdk VM is alive and ready to serve requests.
Kann ich leider nicht testen - ich hab kein GSX.
Continuum
continuum hat geschrieben:Hi
im laufendem System Snapshot machen - dann die Basis-vmdk back-upen - und anschliessend den Snapshot entfernen.
O-ton Petr:
I really do not know what you are looking for. If you are looking for online backuping, just take snapshot, backup non-REDO .vmdk, and then delete snapshot. That way you'll loose some time while taking snapshot, some while deleting it, but while you are backuping .vmdk VM is alive and ready to serve requests.
Kann ich leider nicht testen - ich hab kein GSX.
Continuum
klingt gut, werde ich testen. wie kann man das per script automatisieren?
Hmm.. da steht man soll den Snapshot entfernen..aber das geht doch i.m.h.o. nur wenn die VM powered off (oder suspendet) ist... 
Wie wäre denn das Vorgehen.. ??
1. Snapshot machen
2. Sichern
3. Kurz suspenden
4. Snapshot löschen
5. Aufwecken
6. fertig
So ??
Wäre die Maschine aber trotzdem kurz offline..nämlich für die Zeit von 3-5.
Maxel
Wie wäre denn das Vorgehen.. ??
1. Snapshot machen
2. Sichern
3. Kurz suspenden
4. Snapshot löschen
5. Aufwecken
6. fertig
So ??
Wäre die Maschine aber trotzdem kurz offline..nämlich für die Zeit von 3-5.
Maxel
Das kann nicht sein, denn dann würde ja der Inhalt der redo files ja nicht mehr in die vm eingemerged werden... das muss imho schon eine vmware funktion machen
so wie ich das verstanden habe wird bei erzeugung eines snapshots der stand der vm eingefroren indem änderungen im filesystem und speicher in extra dateien geschrieben werden , eben die redo logs. wenn man zum stand des snapshots zurück will braucht die anwendung wirklich nichts anderes machen als die redos zu löschen.. somit ist man ja wieder beim eingefrorenen stand.
wenn du allerdings wie nach dem backup ja zum aktuellen stand mit allen änderungen willst (was ja nichts anderes als snapshot löschen ist), musst du ja die änderungen in den redo logs in die normalen vm files einmergen (wahrscheinlich ist das auch der grund warum beim löschen des snapshots die vm suspended werden muss).. ein einfaches rm hätte also fatale folgen.
Korrigiert mich falls ich das alles falsch verstanden hab...
maxel
so wie ich das verstanden habe wird bei erzeugung eines snapshots der stand der vm eingefroren indem änderungen im filesystem und speicher in extra dateien geschrieben werden , eben die redo logs. wenn man zum stand des snapshots zurück will braucht die anwendung wirklich nichts anderes machen als die redos zu löschen.. somit ist man ja wieder beim eingefrorenen stand.
wenn du allerdings wie nach dem backup ja zum aktuellen stand mit allen änderungen willst (was ja nichts anderes als snapshot löschen ist), musst du ja die änderungen in den redo logs in die normalen vm files einmergen (wahrscheinlich ist das auch der grund warum beim löschen des snapshots die vm suspended werden muss).. ein einfaches rm hätte also fatale folgen.
Korrigiert mich falls ich das alles falsch verstanden hab...
maxel
maxel hat geschrieben: eben die redo logs. wenn man zum stand des snapshots zurück will braucht die anwendung wirklich nichts anderes machen als die redos zu löschen.. somit ist man ja wieder beim eingefrorenen stand.
genau das hab ich gemeint
sorry für die unsaubere ausdrucksweise
schönen abend
lg gsx²
Redo Logs
Wenn ich das richtig verstehe werden nach der erzeugung eines snapshots keine änderungen in die vmdks geschrieben sondern in die redo logs (welche extension haben die?).
und wie lange geht das so? bis man den shapshot per vm funktion löscht, sprich die redo logs einmerged? und wenn man das nicht macht für immer???
ist dieser ablauf möglich und wenn wie?
1.) snapshot erzeugen per script
2.) alle files sichern ausgenommen redo logs (die sind ja in verwendung)
3.) redo logs einmergen (wie heisst das im vmware jargon?
und fertig ist das hot backup?
könnte es nicht sein dass gsx3 automatisch in redo logs schreibt wenn eine andere applikation die entsprechende vmdk locked? sprich wenn die applikation xcopy.exe auf die hdd0.vmdk zugreift und ein file lock setzt wird in redo logs geschrieben bis das file lock aufgehoben ist?
wie gesagt, unter gsx2.5 friert die virtuelle maschine ein wenn man vmdks locked (wegkopiert), gsx3 maschinen laufen weiter.
und wie lange geht das so? bis man den shapshot per vm funktion löscht, sprich die redo logs einmerged? und wenn man das nicht macht für immer???
ist dieser ablauf möglich und wenn wie?
1.) snapshot erzeugen per script
2.) alle files sichern ausgenommen redo logs (die sind ja in verwendung)
3.) redo logs einmergen (wie heisst das im vmware jargon?
und fertig ist das hot backup?
könnte es nicht sein dass gsx3 automatisch in redo logs schreibt wenn eine andere applikation die entsprechende vmdk locked? sprich wenn die applikation xcopy.exe auf die hdd0.vmdk zugreift und ein file lock setzt wird in redo logs geschrieben bis das file lock aufgehoben ist?
wie gesagt, unter gsx2.5 friert die virtuelle maschine ein wenn man vmdks locked (wegkopiert), gsx3 maschinen laufen weiter.
Hallo I.P.,
hast Du auf Deine 1. Frage (snapshot per script erzeugen) eigentlich eine Antwort erhalten ?
Für mich wäre folgende die ideale Lösung:
1.) SNAPSHOT per script (???)
2.) Dateien, außer redo LOGS kopieren (OK)
3.) VM suspenden
4.) SNAPSHOT löschen (???) damit redologs "eingepflegt" werden
5.) VM wieder starten
hast Du auf Deine 1. Frage (snapshot per script erzeugen) eigentlich eine Antwort erhalten ?
Für mich wäre folgende die ideale Lösung:
1.) SNAPSHOT per script (???)
2.) Dateien, außer redo LOGS kopieren (OK)
3.) VM suspenden
4.) SNAPSHOT löschen (???) damit redologs "eingepflegt" werden
5.) VM wieder starten
Blöde Frage, aber der VMWare-Server kann sein (ohnehin einziges) Smapshot nur anfertigen, indem er kurzfristig die VM anhält, oder?
Mir fehlen gerade VMs an denen ich das testen könnte, ich meine aber diesen Effekt gesehen zu haben.
Wenn dem so ist bringt ein Snapshot in Bezug auf Backups auch nicht viel, die VM wird trotzdem kurzzeitig angehalten -- wenn auch kürzer als das der Fall wäre, wenn ich Festplatten- und RAM-Inhalte zwischen Suspend und Resume kopieren müsste anstatt sie wie mittels Snapshot erst nach dem Resume zu kopieren.
Da der VMWare-Server den GSX abslösen solll wäre eine Backuplösung für den GSX eine recht kurzlebige.
Mir fehlen gerade VMs an denen ich das testen könnte, ich meine aber diesen Effekt gesehen zu haben.
Wenn dem so ist bringt ein Snapshot in Bezug auf Backups auch nicht viel, die VM wird trotzdem kurzzeitig angehalten -- wenn auch kürzer als das der Fall wäre, wenn ich Festplatten- und RAM-Inhalte zwischen Suspend und Resume kopieren müsste anstatt sie wie mittels Snapshot erst nach dem Resume zu kopieren.
Da der VMWare-Server den GSX abslösen solll wäre eine Backuplösung für den GSX eine recht kurzlebige.
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
aber der VMWare-Server kann sein (ohnehin einziges) Smapshot nur anfertigen, indem ...
Wer erzaehlt denn sowas ? - wie sollte das denn auch wohl gehen?
Mach mal im laufenden Betrieb einen neuen Snapshot - dieser steht sofort bereit und wird benutzt. Waehrend die VM laeuft wird im Hintergrund der alte Snapshot mit der basedisk consolidiert (so wird der Vorgang im log genannt)
Die Limitierung auf ein REDO kannst du umgehen, indem du die REDOs so umbenennst, das sie nicht auf den ersten Blick als REDOs zu erkennen sind.
Hatte neulich mal 4 REDOs auf ein ander gesetzt ...
Mit der selben Geschichte kannst du auch linked clones machen ...
Guck mal auf meiner Seite: da habe ich beschrieben wie man mit VMserver GSX 2.5 platten mit undoable-disks handelt ...
Ulli
al!ve hat geschrieben:Blöde Frage, aber der VMWare-Server kann sein (ohnehin einziges) Smapshot nur anfertigen, indem er kurzfristig die VM anhält, oder?
Mir fehlen gerade VMs an denen ich das testen könnte, ich meine aber diesen Effekt gesehen zu haben.
Wenn dem so ist bringt ein Snapshot in Bezug auf Backups auch nicht viel, die VM wird trotzdem kurzzeitig angehalten -- wenn auch kürzer als das der Fall wäre, wenn ich Festplatten- und RAM-Inhalte zwischen Suspend und Resume kopieren müsste anstatt sie wie mittels Snapshot erst nach dem Resume zu kopieren.
Da der VMWare-Server den GSX abslösen solll wäre eine Backuplösung für den GSX eine recht kurzlebige.
weder bei snapshots noch bei vsc wird die vm angehalten, es gibt maximal eine kurze performanceeinbuße, die vm bleibt aber imme online.
ich würde das thema auch nicht als backup-lösung für gsx ansehen sondern als backup-methode für virtuelle server und das gilt dann auch für vmware server - soferne dieser nicht mit eigenen mitteln etwas entsprechendes anbietet, ich hab ihn noch nicht getestet.
continuum hat geschrieben:Die Limitierung auf ein REDO kannst du umgehen, indem du die REDOs so umbenennst, das sie nicht auf den ersten Blick als REDOs zu erkennen sind.
Hatte neulich mal 4 REDOs auf ein ander gesetzt ...
nur machen snapshots die vms immer langsamer und kaskadierte erst recht. wegbekommen tut man sie leider dann nur wenn man die vm runterfährt und die redos einmerged. genau die fehlende fähigkeit im laufenden betrieb redo-logs einzumergen macht das live-backupen ja erst zum problem.
Gut, dann hab ich mich da getäuscht. So oft hab ich noch keine Snapshots von VMs angelegt, bei allen aufenden sogar die Funktion deaktiviert weil ich sie nicht benötige. Deshalb konnte ich bisher noch nicht testen ob sich das so verhält wie ich glaube. Wenn ihr hier der Meinung seid dass die VM über einen Snapshot nicht kurz stehen bleibt glaub ich euch das mal 
Zurück zu „VMserver 1 und GSX“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste