vSphere 7.0U2 NFS Snapshot Probleme

Einer meiner Kunden hat ein Problem auf vSphere 7.0U2 beim Auflösen eines Snapshots.

Dies führt bei seiner VM dazu, dass sie für einen längeren Zeitraum eingefroren wird, sobald der Konsilidierungsvorgang beginnt (Status bleibt über einen längeren Zeitraum auf 0% stehen). Da die Maschine im Cluster läuft, führt dieser Freeze dazu, dass eine Clusterumschaltung statt findet.

In den VMware Logs ist nichts wesentliches zu sehen. Lediglich, dass die VM für einen längeren Zeitraum keine Einträge mehr erzeugt.

Das Merkmal in dieser Situation ist, dass die VM mehrere große VMDKs angehängt hat (jeweils mehrere TB), die alle auf NFS Datastores liegen.

Das Problem konnte entschärft werden, weil die Applikation zulässt die Daten auch von anderen Systemen zu empfangen. Daher wurden zwei der drei großen Disks auf eine andere VM umgehängt, die nicht im Cluster läuft und dies daher keinen Impact auf die Funktion hat.

Aufgrund des Gesprächs hat sich eine Kausalität zwischen der VMDK Größe und der Dauer des Freeze heraus gestellt.

Ich wollte dies nun mal nachstellen und habe eine alte Synology mit vielen Slots wieder in Betrieb genommen und diese mit allen Platten ausgestattet, die ich noch hatte. Das hat zu ca. 16TB Kapazität geführt (RAID0).

DS1812+

Hier habe ich nun einen NFS Datastore (NFSv3) erstellt und eine 15TB VMDK erstellt und einer Windows VM gegeben. Das erstellen des Snapshot ging wie erwartet unterbrechungsfrei. Beim Auflösen hat sich der Ping von meiner Maschine aus wie folgt gezeigt:

4 bytes from 192.168.10.159: icmp_seq=35 ttl=127 time=0.870 ms
64 bytes from 192.168.10.159: icmp_seq=36 ttl=127 time=0.753 ms
Request timeout for icmp_seq 37
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
Request timeout for icmp_seq 44
Request timeout for icmp_seq 45
Request timeout for icmp_seq 46
Request timeout for icmp_seq 47
Request timeout for icmp_seq 48
Request timeout for icmp_seq 49
Request timeout for icmp_seq 50
Request timeout for icmp_seq 51
Request timeout for icmp_seq 52
Request timeout for icmp_seq 53
64 bytes from 192.168.10.159: icmp_seq=37 ttl=127 time=17605.082 ms
64 bytes from 192.168.10.159: icmp_seq=38 ttl=127 time=16604.065 ms
64 bytes from 192.168.10.159: icmp_seq=39 ttl=127 time=15600.862 ms
64 bytes from 192.168.10.159: icmp_seq=40 ttl=127 time=14598.009 ms
64 bytes from 192.168.10.159: icmp_seq=53 ttl=127 time=1551.582 ms
64 bytes from 192.168.10.159: icmp_seq=54 ttl=127 time=548.213 ms
64 bytes from 192.168.10.159: icmp_seq=56 ttl=127 time=0.695 ms
64 bytes from 192.168.10.159: icmp_seq=57 ttl=127 time=0.621 ms
64 bytes from 192.168.10.159: icmp_seq=58 ttl=127 time=0.667 ms

Die Maschine war komplett eingefroren. Die Remote Konsole war verfügbar, aber innerhalb der Maschine konnte ich nichts machen. Kein Fenster verschieben usw. Ein Ping innerhalb der Maschine wurde gestoppt und lief nach dem Freeze ganz normal weiter. D.h., das VMKernel hat offenbar den VMM komplett gestoppt.

Ich habe danach eine 100GB Disk erstellt. Beim Auflösen dieses Snapshots war nichts zu sehen, ausser einer kleinen Latenzewrhöhung, die sich aber auch im Rahmen der Messungenauigkeit bewegt.

sgmelin@sgmelin-a01 ~ % ping 192.168.10.159PING 192.168.10.159 (192.168.10.159): 56 data bytes
64 bytes from 192.168.10.159: icmp_seq=0 ttl=127 time=1.384 ms
64 bytes from 192.168.10.159: icmp_seq=1 ttl=127 time=0.745 ms
64 bytes from 192.168.10.159: icmp_seq=2 ttl=127 time=0.901 ms
64 bytes from 192.168.10.159: icmp_seq=3 ttl=127 time=0.688 ms
64 bytes from 192.168.10.159: icmp_seq=4 ttl=127 time=0.777 ms
64 bytes from 192.168.10.159: icmp_seq=5 ttl=127 time=0.633 ms
64 bytes from 192.168.10.159: icmp_seq=6 ttl=127 time=0.710 ms
64 bytes from 192.168.10.159: icmp_seq=7 ttl=127 time=0.750 ms
64 bytes from 192.168.10.159: icmp_seq=8 ttl=127 time=0.928 ms
64 bytes from 192.168.10.159: icmp_seq=9 ttl=127 time=0.730 ms

Im nächsten Test habe ich eine 1TB Disk angehängt:

sgmelin@sgmelin-a01 ~ % ping 192.168.10.159
PING 192.168.10.159 (192.168.10.159): 56 data bytes
64 bytes from 192.168.10.159: icmp_seq=0 ttl=127 time=1.224 ms
64 bytes from 192.168.10.159: icmp_seq=1 ttl=127 time=0.898 ms
64 bytes from 192.168.10.159: icmp_seq=2 ttl=127 time=0.711 ms
64 bytes from 192.168.10.159: icmp_seq=3 ttl=127 time=0.897 ms
64 bytes from 192.168.10.159: icmp_seq=4 ttl=127 time=0.782 ms
64 bytes from 192.168.10.159: icmp_seq=5 ttl=127 time=0.843 ms
64 bytes from 192.168.10.159: icmp_seq=6 ttl=127 time=0.960 ms
64 bytes from 192.168.10.159: icmp_seq=7 ttl=127 time=0.658 ms
64 bytes from 192.168.10.159: icmp_seq=8 ttl=127 time=1.073 ms
64 bytes from 192.168.10.159: icmp_seq=9 ttl=127 time=0.767 ms
64 bytes from 192.168.10.159: icmp_seq=10 ttl=127 time=0.755 ms
64 bytes from 192.168.10.159: icmp_seq=11 ttl=127 time=0.812 ms

Wie man sehen kann, ist hier eine ca. 40% Latenzerhöhung sichtbar. Aber immer noch nicht dramatisch.

Daher habe ich den Test mit einer 5TB Disk gemacht:

64 bytes from 192.168.10.159: icmp_seq=16 ttl=127 time=0.742 ms
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
64 bytes from 192.168.10.159: icmp_seq=17 ttl=127 time=6146.813 ms
64 bytes from 192.168.10.159: icmp_seq=18 ttl=127 time=5142.396 ms
64 bytes from 192.168.10.159: icmp_seq=19 ttl=127 time=4140.058 ms
64 bytes from 192.168.10.159: icmp_seq=20 ttl=127 time=3134.282 ms
64 bytes from 192.168.10.159: icmp_seq=21 ttl=127 time=2132.952 ms
64 bytes from 192.168.10.159: icmp_seq=22 ttl=127 time=1132.718 ms
64 bytes from 192.168.10.159: icmp_seq=23 ttl=127 time=130.209 ms
64 bytes from 192.168.10.159: icmp_seq=24 ttl=127 time=0.953 ms

Wie man sieht, sieht es plötzlich anders aus. Maschine wieder voll eingefroren.

Danach habe ich eine Disk mit 3TB angehängt:

64 bytes from 192.168.10.159: icmp_seq=12 ttl=127 time=0.802 ms
64 bytes from 192.168.10.159: icmp_seq=13 ttl=127 time=1.058 ms
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
64 bytes from 192.168.10.159: icmp_seq=14 ttl=127 time=3258.506 ms
64 bytes from 192.168.10.159: icmp_seq=15 ttl=127 time=2258.491 ms
64 bytes from 192.168.10.159: icmp_seq=16 ttl=127 time=1254.781 ms
64 bytes from 192.168.10.159: icmp_seq=17 ttl=127 time=251.121 ms
64 bytes from 192.168.10.159: icmp_seq=18 ttl=127 time=0.738 ms

Auch wieder eingefroren, aber deutlich kürzer. Also das Problem hängt direkt mit der VMDK Größe zusammen.

Um zu testen, ob das ein generelles Problem vorliegt, habe ich auf das Volume eine 15TB iSCSI LUN erstellt und dort eine 10TB VMDK reingelegt. In diesem Fall war beim Auflösen des Snapshots nichts zu sehen. Weder ein Freeze, noch eine Ping Latenz.

Comments

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert