Riesiger Snapshot, jetzt kein Speicher mehr frei

[ambiDan]

Hallo liebe Forencommunity,

Ich habe gerade ein kleines (großes!) Problem mit einem Snapshot.
Ich habe einen Server mit einer VM, die zuerst zum Testen war. Als der Server dann produktiv ging, wurde vergessen, ihn auf Snapshots zu checken. Jetzt hat der Kunde angerufen, dass der Server dauernd abstürzt, weil auf dem hard Drive kein Speicher mehr frei ist.
Beim nachsehen habe ich herausgefunden, dass ein über 800GB großes Delta-File die Festplatte blockiert. Da der Server aber mittlerweile für einen großen Webshop genutzt wird, kann ich die VM nicht einfach stoppen, um den Snapshot (endlich) zu löschen/konsolidieren. GoTo fällt aus verständlichen Gründen auch flach.
Kann man einen Snapshot (besonders einen so riesigen) auch im laufenden Betrieb konsolidieren? Und wenn ja, wie lange dauert das ca. bzw wie sieht es dann mit der Performance auf dem Server aus?
Arbeitsspeicher sind 32GB, CPU ist ein Intel Xeon CPU E31270 @3.40GHz. Festplatte sind 2 TB, davon nur noch 4 GB frei (daher das Problem). Genaue Anordnung weiß ich leider nicht, da es ein gemieteter Server ist und ich die Rechnung gerade nicht finde (werde aber nochmal suchen).

Ich hoffe, irgendjemand kann mir hier helfen.

Gruß
Daniel

[irix]

Was die Leute nicht verstehen ist das man zum loeschen von Snaps Platz braucht. Diese benoetige Speichermenge wurde ueber die Jahre stark reduziert aber ein wenig braucht man trotzdem.

Bei 800GB wuerde ich von vielen Stunden ausgehen und es haengt natuerlich von der Geschwindigkeit des Storages ab. Ja die VM kann dabei langsam werden und auch stehen bleiben. Es gibt aber keinen Vorteil wenn man die VM ausmacht.


Wenn du die VM ausmachst wird die VM Swap Datei geloescht und man gewinnt etwas Platz. Fuer die welche keine lange Downtime moeglich ist gibt es den Kniff die Memory Reserierung auf 100% zusetzen und die VM wieder zu starten. Hier wird dann keine Swap Datei mehr angelegt

Fragen:
- Liegen noch andere VMs auf dem Datastore?
- Gibts noch weitere Datastores mit ausreichend Platz?

Gruss
Joerg

[ambiDan]

Hallo Joerg, danke für deine Antwort.

Ich hatte das bei den bisherigen Recherchen so verstanden, dass bei nur einem Snapshot kein zusätzlicher Speicher benötigt wird...

Zu deinen Fragen: Nein, keine andere VM und nein, auch kein weiterer Datastore verfügbar leider.
Den Server mussten wir jetzt doch runterfahren, damit das Delta-File nicht komplett den Speicher aufbraucht.

Gruß aus Bayern

Daniel

[irix]

Ja du must sie herunterfahren weil der Snap in 16MB (zumind. war es frueher so) Schritten waechst. Das ist der Grund warum die VM abstuerzt.

Gruss
Joerg

[ambiDan]

Okay, dann danke ich dir für deine Hilfe
Hast du irgendeinen Erfahrungswert, wie lange das dann in etwa dauert? 1 Stunde, 10 Stunden, 1 Tag?

Gruß

Daniel

[Dayworker]

Da das Kind jetzt in den Brunnen gefallen ist...
Wenn im DS kein Platz mehr ist, du auch keine zusätzliche HDD für kurze Zeit in den Mietserver nachstecken kannst, weder ein vCenter noch Trilead VMexplorer im Einsatz hast, bleibt dir wohl nichts anderes übrig, als die VM in voller Grösse auf deinen lokalen Rechner herunterzuladen und dort die VMDK zu konsolidieren. Im Anschluß würde dann die VMDK wieder zeitintensiv auf den ESXi hochgeladen werden müssen.

Ist die VM zufälligerweise auf Windows-Basis und du hast dir eine BartPE/MOA-ISO mit Drivesnapshot oder einem anderen Imager erstellt?
Dann könntest du dir über den Start der VM mit einer Boot-CD ein Image innerhalb der VM ziehen und hättest dann wirklich nur den aktuellen Datenbestand nach Löschen der originalen VMDK auf dem ESXi und Neuanlegen einer VMDK gleichen Namens wieder auf den ESXi schieben können.
Wenn die VM auf Linux-Basis ist, solltest du mit rsync ebenfalls ans Ziel kommen. Ich würde die VM aber in jedem Fall von einer Live-CD booten, damit keine Dienste gestartet werden und du uneingeschränkten Zugriff hast.

[irix]

1. Haengt vom Storage ab
2. Der Host wendet nicht 100% der Resource dafuer auf

Aber ich wuerde eher die 10h tippen. Keine Panik wenn die Aktion in einen Timeout laeuft! Dann eher in die Logs bzw. direkt in den Datastore gucken weil am Timestamp sollte man erkennen koennen das er mit den Dateien noch arbeitet.

Gruss
Joerg

[Dayworker]

Bei 800GB an geänderten Daten kommt es auf den vorherigen Änderungsstand und vor allem die Geschwindigkeit des Storage an. Ich würde aber von 1 Tag ausgehen und mir in jedem Fall noch Zeit nach hinten lassen.

[ambiDan]

Ich hab noch ein paar Isos auf dem Datenspeicher gefunden, jetzt sind 20 GB frei, reicht das?
Wie gesagt, es ist nur ein Snapshot vorhanden. Auch mit anderen Programmen wurden keine erstellt.

Gruß
Daniel

[irix]

Sollte ausreichen und letztendlich sind ja auch keine Alternativen vorhanden.

Gruss
Joerg

[ambiDan]

Dann danke ich nochmal für eure Hilfe und wünsch euch einen schönen Tag noch!
*Kekse verteilt*

Gruß
Daniel

[Dayworker]

Keks mitgenommen und ich drück die Daumen, daß der Platz wirklich ausreicht.
Wie groß hattest du denn die vDISK angelegt? Damit 800GB an Änderungen auflaufen können, müßte die vDISK ja mindestens dieselbe Grösse haben...
In jedem Fall würde ich vorher ein Backup des VM-Ordners machen. Andernfalls verlierst du Daten, wenn der Platz nämlich doch nicht ausreicht.

[ambiDan]

1 TB ist die vDisk
Den Ordner hab ich schon vorher gesichert, bevor ich so etwas riesiges angefangen habe.
Kann man dem ganzen Prozess irgendwie noch zusätzliche Ressourcen zuweisen? Ich habe die VM jetzt während dem Vorgang gestoppt, und der Server langweilt sich auf <1% CPU-Auslastung und 1GB Arbeitsspeichernutzung.

Gruß
Daniel

[irix]

Nein kann man nicht.

Zeigt esxtop Diskaktivitaet an?

Gruss
Joerg

[ambiDan]

Schade
Ja, 12MB/sek

[irix]

Dann muesste es man es ja ausrechnen koennen wenn man einfach mal annimmt das der Vorgang linear ist.

Gruss
Joerg

[Dayworker]

Ausgehend von 12MB/s brauchst du dann für 800GB mal ebend knapp 19 Stunden.

[ambiDan]

Ja, leider. Aber etwas Ähnliches hatte ich nach den bisherigen Beiträgen in anderen Foren schon erwartet und dem Kunden eine Downtime von 22-24 Stunden angegeben.

Bisher hat sich übrigens nichts gezeigt, was darauf deutet, dass der Vorgang irgendwo mehr als 1GB Speicher zusätzlich vereinnahmt hat.
*Tee hinstellt*

[Dayworker]

Wielange war eigentlich der Snapshot aktiv?
Wenn inzwischen 800GB an veränderten Daten aufgelaufen sind, ist die vDISK ja bereits zu mindestens 80% belegt und je nach Datenvolumen (Stunde, Tag, Monat) geht dir irgendwann der Platz in der VM aus. Von der Warte ist es günstig, daß du den Snapshot jetzt endlich einpflegst. Vorher wäre ein Vergrössern der VMDK ja überhaupt nicht möglich gewesen...

[ambiDan]

Der Snapshot ist seit November 2012 aktiv, wie gesagt, beim Übergang zum Produktiv-Server wurde der einfach vergessen.
Da läuft unter anderem auch ein SQL-Server und ein umfangreicher Webshop drauf.

Vergrößern der VMDK ist doch eh nicht möglich, solange ein Snapshot existiert dachte ich...

[ambiDan]

Er arbeitet jetzt schon seit über 26 Stunden, ist das noch im Rahmen? Bzw woran erkenn ich, wenn was schief gegangen ist?

[Dayworker]

Bei jeder Festplatte bricht die IO-Leistung zur Plattermitte hin ein. Wie stark hängt davon ab, welcher Plattentyp (SAS-, NL-SAS- oder SATA) bei dir zum Einsatz kommt. SATA und aufgrund der Bauartnähe vermutlich auch bei NL-SAS verlieren zur Mitte hin 50% ihrer IO-Leistung. Wenn deine VM ihre Daten wild durcheinander geschrieben (fragmentiert) hat, dauert es halt noch etwas länger.

Um zu sehen wieviel Platz noch frei ist, schalte dich mal direkt per SSH oder WinSCP auf den ESXi und poste dann die Terminalausgabe von:

Code: Alles auswählen

df -h

Welchen Plattentyp hattest du der VM eigentlich gegönnt, Thin oder Thick?

[irix]

Waren die 12MB/s Gesamttransferrate? Weil du liest und schreibst auf die gleiche Platte.

Wenn es dann doch nur 6MB/s sind sollte man nochmal nachrechnen.

Gruss
Joerg

[ambiDan]

Wo sehe ich, welchen Plattentyp ich habe?

Ich bin in der unangenehmen Situation, dass ich werder die VM noch den Snapshot angelegt/konfiguriert habe, sondern die Arbeit meines Vorgängers übernehmen durfte. Ich hatte vorher auch mit VM nicht viel am Hut.

Hier die Ausgabe von df -h:

Code: Alles auswählen

/$ df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5       1.8T   1.8T     20.1G  99% /vmfs/volumes/x204-local-storage-1
vfat         4.0G  21.7M      4.0G   1% /vmfs/volumes/50be2761-4f3e8eb0-ed4c-009c02a84b5f
vfat       249.7M 126.4M    123.3M  51% /vmfs/volumes/454a0870-58395541-fc0d-41f98f52762f
vfat       249.7M   8.0K    249.7M   0% /vmfs/volumes/0530d17c-0fb129bd-b3ce-822424dd9c71
vfat       285.8M 179.8M    106.1M  63% /vmfs/volumes/50be272b-4fa00ab0-e9c8-009c02a84b5f

Das ist in etwa dasselbe, was mir im vSphere Client an Festplattennutzung gezeigt wird.

@Joerg: Grad rechtzeitig vorm Absenden noch deinen Post gesehen
Der vSphere Client trennt zwischen Lese- und Schreibrate, jeweils im Durchschnitt:
Leserate: 5452,233 KB/s
Schreibrate: 10911,939 KB/s

[continuum]

Der Plattentyp wird dir normalerweise im ViClient angezeigt.

Wenn die Basis-vmdk thick provisioned ist kann man auch solche sehr grossen Snapshots im laufenden Betrieb konsolidieren - man braucht nur 2 ganz kurze downtimes - % Minuten etwa - einmal vor der Konsolidierung und einmal wenn sie durch ist.

Das ist dann aber etwas komplizierter ...