Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

VM vorgehensweise bei kritischen Eingriffen

Moderatoren: irix, continuum, Dayworker, Tschoergez

Member
Beiträge: 2
Registriert: 15.07.2015, 12:12

VM vorgehensweise bei kritischen Eingriffen

Beitragvon Mika90 » 15.07.2015, 12:19

Hallo zusammen,

ich habe eine Frage bezüglich der richtigen Vorgehensweise bei kritischen Eingriffen auf virtuellen Maschinen.

Ich habe es bisher immer so gemacht, dass ich von der Maschine einen Snapshot gemacht habe, dort die Eingriffe durchgeführt und anschließend getestet habe.
Danach habe ich den Snapshot entfernt und die gleiche Änderung auf dem Livesystem durchgeführt.

Wie würdet ihr bei solchen Eingriffen vorgehen?


Viele Grüße
Mika

Jenseits von Gut & Böse
Beiträge: 10781
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Re: VM vorgehensweise bei kritischen Eingriffen

Beitragvon irix » 15.07.2015, 12:36

Mika90 hat geschrieben:..
Danach habe ich den Snapshot entfernt und die gleiche Änderung auf dem Livesystem durchgeführt.


Hmmm? Kannst du das nochmal erklaeren weil das hoert sich unlogisch an.

Hier gibts folgende vorgehensweisen
1. Snapshot machen. Aenderungen machen: Sofort/Zeitnah entscheiden ob Aenderung erfolgreich war und wenn dem so ist dann Snap loeschen und es geht Produktiv weiter. Bei Problemen gibts Revert to Snapshot und vorher muss klar sein ob das System in dieser Zeit Daten in Empfang genommen hat und das diese Fehlen wenn das System zurueck gesetzt wird.

2. Sandbox/Kopie/Clone
Veeam kann bequemm eine Sandbox fuer eine oder mehre VMs einrichten in der man in Ruhe testen kann. Sofern alles i.O muessen diese Aenderungen dann wiederholt werden auf den eigentlichen Livesystemen.
Wenn es sich um ein Einzelsystem handelt und man Veeam hat dann macht man einen Clone oder aber auch mal ein Restore from Backup und faehrt dieses System ohne Netzwerk bzw. auf einer Shadow Portgruppe (vSwitch ohne pNIC). Auch hier muesste muss die Aenderung dann im Livesystem wiederholen.

Gruss
Joerg

Member
Beiträge: 76
Registriert: 19.04.2014, 14:05

Beitragvon dlehner84 » 15.07.2015, 13:22

Ich würde das Live-System mit dem VMware vCenter Converter "klonen" und dann testen. Dann kannst du den Klon (mit den vorgenommenen Änderungen) wieder per vCenter zum Live-System "konvertieren" und das "alte" Live-System löschen.

Gruß dlehner84

Member
Beiträge: 2
Registriert: 15.07.2015, 12:12

Beitragvon Mika90 » 15.07.2015, 14:00

Ok dann scheine ich wohl den Sinn eines Snapshots nicht verstanden zu haben bzw. falsch verstanden zu haben.

Ich mache doch einen Snapshot vom Livesystem um auf diesem die Änderungen zu testen oder etwa nicht?

Grüße
Mika

Member
Beiträge: 76
Registriert: 19.04.2014, 14:05

Beitragvon dlehner84 » 15.07.2015, 14:04

Das ist ja auch nicht falsch aber ich finde die Verwendung eines Klons immer besser.
Bei Unternehmenskritischen Anwendungen in einer VM (SQL-Datenbanken, Exchange-Server, Sharepoint) wird das verwenden von Snapshots außerdem expliziet nicht empfohlen.

Member
Beiträge: 240
Registriert: 27.03.2012, 15:03
Wohnort: Würzburg

Beitragvon Gad » 15.07.2015, 14:31

dlehner84 hat geschrieben:Ich würde das Live-System mit dem VMware vCenter Converter "klonen" und dann testen. Dann kannst du den Klon (mit den vorgenommenen Änderungen) wieder per vCenter zum Live-System "konvertieren" und das "alte" Live-System löschen.


Wieso über den Konverter?

Wir machen einen Snapshot des Systems, Updates, Test ob alles funktioniert und dann entweder Zurückrollen oder Snap löschen.

dlehner84 hat geschrieben:Bei Unternehmenskritischen Anwendungen in einer VM (SQL-Datenbanken, Exchange-Server, Sharepoint) wird das verwenden von Snapshots außerdem expliziet nicht empfohlen.


Hast du dazu ne offizielle Aussage?

Member
Beiträge: 76
Registriert: 19.04.2014, 14:05

Beitragvon dlehner84 » 15.07.2015, 14:37

dlehner84 hat geschrieben:Bei Unternehmenskritischen Anwendungen in einer VM (SQL-Datenbanken, Exchange-Server, Sharepoint) wird das verwenden von Snapshots außerdem expliziet nicht empfohlen.

Hast du dazu ne offizielle Aussage?


Ja: http://www.datacenter-insider.de/toms-a ... es/443761/
Hier noch mal offiziell: https://technet.microsoft.com/de-de/lib ... v=exchg.80).aspx

Und ich sekbst hatte damit auch schon Probleme.
Wir betreiben den Exchange Server in ESXi 5.5.

Jenseits von Gut & Böse
Beiträge: 10781
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 15.07.2015, 15:23

Ich will nicht sagen das die obige Aussage Humbug ist aber der Kontext stimmt so nicht. Des weiteren sind diese von einem Hersteller welcher von seinen eigenen techn. Rueckstaenden spricht und was hier und da bei ihm nicht Supportet ist. Das sieht auch heute bei MS anders aus und hier bei vSphere sowieso.

Die Gefahr bei einem Snapshot ist:
- Macht man Gedankenlos ein Revert. Das ist bei Transaktionsbasierten Systemen bzw. wenn mehrere im Verbund sind extrem unschoen. Je nach Fall ist der Datenbestand nun inkonsistenz oder man hat einen Teilverlust. Windows AD (USN Problem!)
- Tiefe Snapshotketten bzw. diesen lange zuhaben kann auf die Performance gehen
- Bei aktiven Snaps ist das Management der VM limitiert

Daraus nun pauschal zusagen das Snapshots schlecht bzw. ungeeignet sind ist halt Humbug.

Seit 2008 wird hier alles virtuell und es sind direkt hier intern 500 VMs und das 2-3 Fache nochmal bei den Kunden Vorot. Ja und jeder macht Snapshots.... und sei es nur fuer das VM Backup weil es hier techn. garnicht anders geht. Es mag ja leute geben welche ihre VM zum Backup ausschalten oder halt traditonell nen Agent drin haben, aber da sag ich mal die sind in der Minderheit.

Gruss
Joerg

Benutzeravatar
Member
Beiträge: 65
Registriert: 03.09.2013, 11:08

Beitragvon 2-D » 16.07.2015, 10:40

irix hat geschrieben:Die Gefahr bei einem Snapshot ist:
- Macht man Gedankenlos ein Revert. Das ist bei Transaktionsbasierten Systemen bzw. wenn mehrere im Verbund sind extrem unschoen. Je nach Fall ist der Datenbestand nun inkonsistenz oder man hat einen Teilverlust. Windows AD (USN Problem!)
- Tiefe Snapshotketten bzw. diesen lange zuhaben kann auf die Performance gehen
- Bei aktiven Snaps ist das Management der VM limitiert


...leider auch nicht komplett.
Der bei uns in dem Zusammenhang meist auftretende Fehler ist, dass sog. PowerUser gerne Snapshots machen wollen und dies gedankenlos tun, und damit die Datastores vollaufen lassen. Denn ein Snap kann so groß wie die konfigurierte Größe der VMDK werden. Zudem brauch der beim konsoldieren auch nochmal Platz. Snapt man mit RAM kommt die RAM Größe nochmal dazu.

Und kommt es dazu, dass der Datastore voll ist, sind angefangene revert/delete Jobs im Snapmanager meist zerstört.

Zum Thema Snapshots hat VMware ein KB veröffentlicht:
http://kb.vmware.com/selfservice/micros ... Id=1025279


Zurück zu „VMs & Appliances“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast