Ich habe versucht herauszufinden, warum meine Backups mit GhettoVCB vom ESXI-Host so langsam waren.
Ich sichere derzeit meine virtuellen Rechner mit ghettoVCB vom Host-Betriebssystem auf einer NFS-Freigabe auf TrueNAS.
Wenn ich Dateien von einem Gast (Ubuntu 20.04) auf der ESXI-Maschine in die NFS-Freigabe kopiere, erhalte ich etwa 257 MB/s (was ungefähr richtig ist, da ich einen dedizierten 2,5-GB-Kanal zwischen NAS und ESXI habe).
su@test:/mnt/guest$ time sh -c "dd if=/dev/zero of=test bs=1MB count=1024 && sync"
1024+0 records in
1024+0 records out
1024000000 bytes (1.0 GB, 977 MiB) copied, 3.98153 s, 257 MB/s
real 0m4.470s
user 0m0.002s
sys 0m0.619s
Guest NFS Mount Options:
rw, relatime, vers=4.2,
rsize=1048576, wsize=1048576,
namlen=255, hard, proto=tcp, timeo=600,
retrans=2, sec=sys, local_lock=none,
Wenn ich versuche, vom ESXI-Host auf dieselbe NFS-Freigabe zu kopieren, ist der Durchsatz viel geringer und liegt bei etwa 45 MB/s:
/vmfs/volumes/9043e582-0376fe3e] time sh -c "dd if=/dev/zero of=./test bs=1MB count=1024 && sync"
1024+0 records in
1024+0 records out
real 0m 22.70s
user 0m 0.00s
sys 0m 0.00s
ESXI NFS Mount Options
Cant seem to find a way to see the mount options ESXI uses?
Mir ist aufgefallen, dass das Deaktivieren der Synchronisierung der ZFS-Datenfreigabe auf dem Server die ESXI-Schreibvorgänge auf 146 MB/s beschleunigte. Immer noch viel niedriger als beim Gastbetriebssystem.
Ich gehe davon aus, dass ESXI supersicher ist und dafür sorgt, dass alles zu 100 % synchronisiert ist. Weiß jemand, ob das der Fall ist, und hat jemand Tipps zur Leistungssteigerung beim Backup?
Antwort1
Was Sie sehen, ist absolut normal und kann SO WIE ES IST nicht behoben werden. VMware ESXi hat „von Haus aus“ keinen Festplattencache, anders als das Gastbetriebssystem in einer VM, das hat wirklich einen! Wenn Sie also Ihre Datei aus einer VM heraus kopieren (was selbst ein betrügerischer Test ist, Sie sollten anspruchsvollere Benchmarks verwenden), sättigen Sie Ihr Netzwerk, da Ihr pipelined sequentielles Lesen schneller ist als das Netzwerk selbst, aber Host-ESXi muss die Daten (langsam, es gibt kein Vorauslesen) in mmap()-verarbeitete gemeinsam genutzte Speicher-/Netzwerkspeicherpuffer lesen, zustandslosen NFS-Schreibvorgang initiieren, die Festplatte erneut lesen und so weiter. Wenn Sie WireShark starten, sehen Sie, dass der Tx-Verkehr der Gast-VM stabil ist und das Host-Betriebssystem dies mit einer Art Spitzen beim Tx tut.
Als Workaround könnten Sie sich einen RAID-Controller mit Cache und großem integrierten Speicher zulegen oder einen zweiten Knoten einbauen, einen Cluster erstellen und vSAN konfigurieren (VMUG-Preise sind für vSphere+vSAN recht erschwinglich). VMware vSAN speichert lokale Festplatten auf seiner Ebene unterhalb von VMFS, sodass Sie Ihre 2,5 GB wieder voll auslasten.
Antwort2
Als Workaround könnten Sie sich einen RAID-Controller mit Cache und großem integrierten Speicher zulegen oder einen zweiten Knoten einbauen, einen Cluster erstellen und vSAN konfigurieren (VMUG-Preise sind für vSphere+vSAN recht erschwinglich). VMware vSAN speichert lokale Festplatten auf seiner Ebene unterhalb von VMFS, sodass Sie Ihre 2,5 GB wieder voll auslasten.
Das ist eine lohnende Option. Alternativ können Sie sich auch für Starwind VSAN entscheiden, das auf Blockebene arbeitet und Ihnen eine bessere Leistung bieten sollte. Es unterstützt einen mdamd-Raid, den Sie vielleicht auch ausprobieren möchten.