große Samba VM - Disk consolidate ändert nichts

[ReedyTT]

Hi,

Im produktiven Einsatz, ist eine 3TB „schwere“ Samba VM, welche diverse Shares anbietet.
Guest ist ein Ubuntu18 LTS auf aktuellem Stand.
Ein All Flash Storage ist über 10GB iSCSI angebunden.
Die VM liegt allein in einer 4 TB LUN.
Es liegen aktuell 3351097 Files auf den Shares, von 1MB bis 970MB größe.
Die Shares dienen zu Ablage Build Results und unterschiedlichste Installer, welche ununterbrochen gebaut werden.

Der Wartungsworkflow sieht vor, dem einspielen der Updates ein Snapshot um ausgeschalteten Zustand gezogen wird.
Problem ist nun, das sobald dieser Snap gezogen wurde, direkt danach die Meldung aufpoppt, dass die Platten konsolidiert werden müssen.
Wird die Konsolidierung bzw. delete Snapshot getriggert, läuft der Job zu 100% durch und wird abgeschlossen.
Weiterhin wird der consolidate Trigger angezeigt und die 00001…vmdks liegen weiterhin da, aber das vCenter ist der Meinung, dass keine Snapshots vorhanden sind.
Das die VM clonen eine Möglichkeit ist, ist klar, aber kann ich die VM nicht anders wieder reparieren?

danke für die Hilfe

[irix]

Trigger sind
1. Nicht alle vDisks haben die gleiche Anzahl an Snaps
2. Die SnapDB(kleiene Textdatei) stimmt nicht mit den Dateipfaden ueberein welche immer aufzeigen ob die VM einen Snap hat

Kann es sein das das Snapshot loeschen niemals fertig wird weil die Aenderungsrate zu hoch ist? Sieht man das nicht im vmware.log oder vmkernel?

Gruss
Joerg

[ReedyTT]

hmm hier scheint so einiges im argen zu sein

Code: Alles auswählen

-rw-------    1 root     root      527.8G Jun 10 04:18 tt-ddvs15_5-000003-sesparse.vmdk
-rw-------    1 root     root      236.7G Jun 10 10:52 tt-ddvs15_5-000004-sesparse.vmdk
-rw-------    1 root     root       49.0G Jun  9 00:20 tt-ddvs15_5-000002-sesparse.vmdk
-rw-------    1 root     root       42.7G Jun  8 20:12 tt-ddvs15_5-000001-sesparse.vmdk
-rw-------    1 root     root        1.4G Jun 10 08:38 tt-ddvs15_7-000001-sesparse.vmdk
-rw-------    1 root     root        1.4G Jun 10 10:52 tt-ddvs15_4-000001-sesparse.vmdk
-rw-------    1 root     root        5.5M Jun 10 04:18 tt-ddvs15_7-000001-ctk.vmdk
-rw-------    1 root     root        5.3M Jun  8 20:12 tt-ddvs15_5-000001-ctk.vmdk
-rw-------    1 root     root        5.3M Jun  9 00:20 tt-ddvs15_5-000002-ctk.vmdk
-rw-------    1 root     root        5.3M Jun 10 04:18 tt-ddvs15_5-000003-ctk.vmdk
-rw-------    1 root     root        5.3M Jun 10 04:18 tt-ddvs15_5-000004-ctk.vmdk
-rw-------    1 root     root        1.9M Jun 10 04:18 tt-ddvs15_4-000001-ctk.vmdk
-rw-------    1 root     root         467 Jun  9 00:20 tt-ddvs15_5-000001.vmdk
-rw-------    1 root     root         420 Jun  9 07:57 tt-ddvs15_5-000002.vmdk
-rw-------    1 root     root         397 Jun  9 21:01 tt-ddvs15_5-000003.vmdk
-rw-------    1 root     root         397 Jun 10 04:18 tt-ddvs15_5-000004.vmdk
-rw-------    1 root     root         389 Jun 10 04:18 tt-ddvs15_7-000001.vmdk
-rw-------    1 root     root         388 Jun 10 04:18 tt-ddvs15_4-000001.vmdk

wie genau heißt das SnapDB file?
im Datastore find ich nichts.

[irix]

Ist eine kleine ASCII Datei ... zeig doch mal den ganzen Inhalt des Ordners weil dann muss ich nicht bei mir nachgucken.

Gruss
Joerg

[JustMe]

Der Dateiname lautet <VM-Name>.vmsd (fuer Snapshot Descriptor vmtl.). Wahrscheinlich ist die sogar nur noch 0 Bytes gross, oder enthaelt keine Snapshot-Infos mehr. Evtl. sind beim (mehrfachen) Aufloesen der Snapshots nur einzelne der VMDKs bearbeitet worden, aber nicht alle.

So auf den ersten Blick wuerde ich meinen, dass an der VM mindestens drei bis 8 VMDKs dran haengen, und die haben jeweils unterschiedlich viele Snapshot-Dateien. Und dies bei einer gewaltigen Aenderungsrate.

Das duerfte ein Fall fuer sukzessives Klonen der einzelnen VMDKs per vmkfstools sein, waehrend die VM aber heruntergefahren sein muss.

Die Frage von irix nach dem kompletten Ordnerinhalt wuerde ich um dem Inhalt der <VM-Name>.vmx oder alternativ der aktuellen vmware.log erweitern. Danach braucht's wohl auch noch die kleinen vmdk-Dateien (<1kB), um die Snapshot-Reihenfolge zu verfizieren.

[rprengel]

Hi,

Im produktiven Einsatz, ist eine 3TB „schwere“ Samba VM, welche diverse Shares anbietet.
Guest ist ein Ubuntu18 LTS auf aktuellem Stand.
Ein All Flash Storage ist über 10GB iSCSI angebunden.
Die VM liegt allein in einer 4 TB LUN.
Es liegen aktuell 3351097 Files auf den Shares, von 1MB bis 970MB größe.
Die Shares dienen zu Ablage Build Results und unterschiedlichste Installer, welche ununterbrochen gebaut werden.

Der Wartungsworkflow sieht vor, dem einspielen der Updates ein Snapshot um ausgeschalteten Zustand gezogen wird.
Problem ist nun, das sobald dieser Snap gezogen wurde, direkt danach die Meldung aufpoppt, dass die Platten konsolidiert werden müssen.
Wird die Konsolidierung bzw. delete Snapshot getriggert, läuft der Job zu 100% durch und wird abgeschlossen.
Weiterhin wird der consolidate Trigger angezeigt und die 00001…vmdks liegen weiterhin da, aber das vCenter ist der Meinung, dass keine Snapshots vorhanden sind.
Das die VM clonen eine Möglichkeit ist, ist klar, aber kann ich die VM nicht anders wieder reparieren?

danke für die Hilfe

Ggf. mal überlegen ob man die Daten nicht auf eine Synology oder ein anderes NAS umzieht?
Gruß

[Dayworker]

Wenn ich die Angaben All-Flash-Storage mit 10GBit-Anbindung lese, dürfte der Umzug auf ein NAS nur wenig bis garnix am Problem ändern, weil wir weder die Änderungsrate noch die dabei auftretende Datenmenge kennen und man noch mit einem zusätzlichen Gerät rumhantieren müßte. KISS geht irgendwie anders.
Ohne genauere Angaben zur vorhandenen, eingesetzten HW halte ich jede Empfehlung für weitere HW für wenig zielführend.

[ReedyTT]

Guten Morgen,

am Wochenende ist die LUN dann vollgelaufen.
Nach der Vergrößerung um weitere 2TB und "abklemmen" des internen NICs (wegen der zu hohen Änderungsrate, guter Tipp!) hat das konsolidieren tatsächlich funktioniert.
aktueller DataStore Inhalt:

Code: Alles auswählen

total 3153681728
-rw-------    1 root     root     2911987826688 Jun 13 06:46 tt-ddvs15_5-flat.vmdk
-rw-------    1 root     root     375809638400 Jun 13 05:13 tt-ddvs15_7-flat.vmdk
-rw-------    1 root     root     32212254720 Jun 13 06:46 tt-ddvs15_4-flat.vmdk
-rw-------    1 root     root      87031808 Jun 11 12:39 vmx-tt-ddvs15-ed1d09d2f15cfd908ebf81b14894a3a2ad42ed78-1.vswp
-rw-r--r--    1 root     root      42612607 Jun  8 19:48 vmware-6.log
-rw-r--r--    1 root     root      26344959 May 25 19:26 vmware-3.log
-rw-r--r--    1 root     root       7198036 Jun 13 05:14 vmware.log
-rw-------    1 root     root       5734912 Jun 13 05:14 tt-ddvs15_7-ctk.vmdk
-rw-------    1 root     root       5554688 Jun 13 05:14 tt-ddvs15_5-ctk.vmdk
-rw-------    1 root     root       1966592 Jun 13 05:12 tt-ddvs15_4-ctk.vmdk
-rw-r--r--    1 root     root       1139385 Jun 11 12:29 vmware-7.log
-rw-r--r--    1 root     root        525987 Apr 28 07:07 vmware-2.log
-rw-r--r--    1 root     root        516704 May 25 22:04 vmware-4.log
-rw-r--r--    1 root     root        287334 May 25 22:07 vmware-5.log
drwxr-xr-x    1 root     root         86016 Jun 13 05:13 .
drwxr-xr-t    1 root     root         73728 Apr 27 18:56 ..
-rw-------    1 root     root          8684 Jun 11 12:41 tt-ddvs15.nvram
-rwxr-xr-x    1 root     root          4670 Jun 13 05:13 tt-ddvs15.vmx~
-rwxr-xr-x    1 root     root          4652 Jun 13 05:13 tt-ddvs15.vmx
-rw-------    1 root     root           636 Jun 13 05:13 tt-ddvs15_5.vmdk
-rw-------    1 root     root           634 Jun 13 05:13 tt-ddvs15_7.vmdk
-rw-------    1 root     root           616 Jun 13 05:11 tt-ddvs15_4.vmdk
-rw-r--r--    1 root     root           576 Apr 27 22:10 tt-ddvs15-017cbdf5.hlog
-rw-------    1 root     root           150 Jun 11 12:29 tt-ddvs15.vmxf
-rw-r--r--    1 root     root            45 Jun 13 05:13 tt-ddvs15.vmsd
-rw-r--r--    1 root     root            14 Jun 13 05:13 tt-ddvs15-aux.xml
-rw-------    1 root     root             0 Jun 11 12:39 tt-ddvs15-15b739ad.vswp
-rw-------    1 root     root             0 Jun 11 12:39 tt-ddvs15.vmx.lck


Im Screenshot, sieht man gut den Moment, als ich das konsolidieren angeschmissen hab.
Das besondere an der VM ist, die hohe Dauerschreiblast.
Dazu kommt das Backup, welches auch jede Stunde vorbei kommt und einen Snapshot zieht.
Als erst Folge, werde ich in der Wartung den samba Dienst aus machen.
Logs hänge ich gleich noch an.

Inhalt von der *.vmsd sieht so aus:

Code: Alles auswählen

.encoding = "UTF-8"
snapshot.lastUID = "139"

ps.:
das aktuelle Logfile musste ich zippen, weil 7MB zu groß sind, nicht wundern

[irix]

Dann ist ja das urspruengliche Problem geloest. Die Frage was aber nun das eigentliche Problem ist? Wenn das Problem das naechste mal Auftritt dann bitte im vmware log/vmkernel gucken weil da sollte vermerkt sein das die Aenderungsrate zu hoch ist.

Gruss
Joerg

[ReedyTT]

jep das grundliegende Problem ist gelöst, beim nächste Mal was höchstwahrscheinlich nächste Woche Mittwoch sein wird, melde ich mich.