auffällig langsamer host bzw. vms bzw. langsames veeam

[vmware-admin2016]

Hallo,

kann man hier evtl. so leicht sehen/sagen warum Veeam auffällig langsam ist bei Host1? Danke vorab.

Warum braucht Veeam so lange bzw. hat scheinbar keine so hohe Übertragungsrate beim Vergleich der beiden Hosts?
Habe Ausrufezeichen untenstehend eingefügt bei der Geschwindigkeit.
Host1 = Hannover
Host2 = Köln
Jeweils 1x Synology 1 Meter daneben stehend.


HOST1
ML350 Gen8 bronze cpu
ESX 6
Thick-Provision Lazy-Zeroed
Raid 6 SAS 10k Festplatten
Synology DS1618+ mit zwei LAN Kabeln als BOND
Raid Controller Cache Module zeigt aktuell noch FAILED im ILO.
Im Vmware Client wird auf Cache Module nicht mit Fehler verwiesen

16:41:20 Queued for processing at 18.04.2023 16:41:20
16:41:20 Required backup infrastructure resources have been assigned
16:41:20 VM processing started at 18.04.2023 16:41:20
16:41:20 VM size: 771 GB
16:41:45 Getting VM info from vSphere 00:02
16:41:51 Inventorying guest system 00:04
16:41:57 Preparing guest for hot backup 00:25
16:43:06 Releasing guest 00:01
16:43:06 Creating VM snapshot
16:43:07 Getting list of guest file system local users 00:00
16:43:12 Saving [datastore1] Mailserver NEU/Mailserver NEU.vmx 00:00
16:43:12 Saving [datastore1] Mailserver NEU/Mailserver NEU.vmxf 00:00
16:43:13 Saving [datastore1] Mailserver NEU/Mailserver.nvram 00:00
16:43:14 Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nbd] 00:00
16:43:14 Using backup proxy VMware Backup Proxy for disk Hard disk 2 [nbd] 00:00
!!!!!!!!!!!!!16:43:15 Hard disk 2 (650 GB) 195,9 GB read at 27 MB/s [CBT] 02:04:55
16:43:15 Disk [datastore1] Mailserver NEU/Mailserver NEU_1.vmdk size changed, entire virtual disk must be read
!!!!!!!!!!!!!16:43:16 Hard disk 1 (121 GB) 14,8 GB read at 23 MB/s [CBT] 11:06

==============

HOST2:
DL380 Gen10 bronze cpu
ESX 6.7
Thin Provision
Raid 6 SAS 10k Festplatten
Synology DS918+ mit zwei LAN Kabeln als BOND

Queued for processing at 17.04.2023 19:00:29
Required backup infrastructure resources have been assigned 03:54
VM processing started at 17.04.2023 19:04:29
VM size: 1,4 TB (1,4 TB used)
Getting VM info from vSphere 00:01
VMware Tools are not up to date, some functionality may be affected
Using guest interaction proxy service-pc (Same subnet)
Inventorying guest system 00:02
Preparing guest for hot backup 00:08
Releasing guest 00:00
Creating VM snapshot
Getting list of guest file system local users 00:00
Saving [Datastore1] Exchange/Exchange.vmx 00:00
Saving [Datastore1] Exchange/Exchange.vmxf 00:00
Saving [Datastore1] Exchange/Exchange.nvram 00:00
Using backup proxy VMware Backup Proxy for disk Hard disk 2 [hotadd] 00:38
Using backup proxy VMware Backup Proxy for disk Hard disk 1 [hotadd] 00:20
!!!!!!!!!!Hard disk 1 (1,1 TB) 32,1 GB read at 112 MB/s [CBT] 05:40
!!!!!!!!!!Hard disk 2 (135 GB) 24,4 GB read at 120 MB/s [CBT] 03:56
Using backup proxy VMware Backup Proxy for disk Hard disk 3 [hotadd] 00:18
!!!!!!!!Hard disk 3 (150 GB) 412 MB read at 60 MB/s [CBT] 00:19
Removing VM snapshot 00:16
Saving GuestMembers.xml 00:00
Finalizing 00:01
Truncating Exchange transaction logs 00:03
Swap file blocks skipped: 2,1 GB
Deleted file blocks skipped: 3 GB
Busy: Source 57% > Proxy 88% > Network 62% > Target 3%
Primary bottleneck: Proxy
Network traffic verification detected no corrupted blocks
Processing finished at 17.04.2023 19:12:43

[~thc]

Das sagt doch VEEAM selbst (bei Host2 - beim Host1 hast du es abgeschnitten):

Code: Alles auswählen

Busy: Source 57% > Proxy 88% > Network 62% > Target 3%
Primary bottleneck: Proxy

[vmware-admin2016]

Hallo,

gute Idee, danke

04:54:15 Busy: Source 93% > Proxy 85% > Network 79% > Target 49%
04:54:15 Primary bottleneck: Source

Host3 (steht neben Host1 und ist baugleich) hat ähnliche Werte.
Der Veeam Server ist ein separater Hardware PC.

HOST1:
ML350 Gen8

20:09:43 Queued for processing at 18.04.2023 20:09:43
20:09:43 Required backup infrastructure resources have been assigned 01:49
20:11:34 VM processing started at 18.04.2023 20:11:34
20:11:34 VM size: 771 GB
20:11:39 Getting VM info from vSphere 00:02
20:11:44 Inventorying guest system 00:07
20:11:53 Preparing guest for hot backup 00:37
20:13:53 Releasing guest 00:00
20:13:53 Creating VM snapshot 00:00
20:13:54 Getting list of guest file system local users 00:00
20:14:00 Saving [datastore1] Mailserver NEU/Mailserver NEU.vmx 00:00
20:14:00 Saving [datastore1] Mailserver NEU/Mailserver NEU.vmxf 00:00
20:14:01 Saving [datastore1] Mailserver NEU/Mailserver.nvram 00:00
20:14:01 Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nbd]
20:14:01 Using backup proxy VMware Backup Proxy for disk Hard disk 2 [nbd]
20:14:03 Hard disk 2 (650 GB) 566 GB read at 21 MB/s [CBT] 07:39:14
20:14:03 Disk [datastore1] Mailserver NEU/Mailserver NEU_1.vmdk size changed, entire virtual disk must be read
20:14:04 Hard disk 1 (121 GB) 15,4 GB read at 13 MB/s [CBT] 20:03
03:53:29 Removing VM snapshot 01:00:26
04:53:56 Saving GuestMembers.xml 00:00
04:54:00 Finalizing 00:01
04:54:02 Truncating Exchange transaction logs 00:09
04:54:14 Swap file blocks skipped: 3,7 GB
04:54:14 Deleted file blocks skipped: 58,6 GB
04:54:15 Busy: Source 93% > Proxy 85% > Network 79% > Target 49%
04:54:15 Primary bottleneck: Source
04:54:15 Network traffic verification detected no corrupted blocks
04:54:15 Processing finished at 19.04.2023 04:54:15

eine Win2019 VM auf dem gleichen host hat diese sozusagen die gleichen schlechten "source" Werte:

20:09:43 Queued for processing at 18.04.2023 20:09:43
20:09:43 Required backup infrastructure resources have been assigned
20:09:43 VM processing started at 18.04.2023 20:09:43
20:09:43 VM size: 80 GB
20:10:09 Getting VM info from vSphere 00:02
20:10:15 Inventorying guest system 00:07
20:10:25 Preparing guest for hot backup 00:12
20:11:56 Releasing guest 00:01
20:11:56 Creating VM snapshot
20:11:58 Getting list of guest file system local users 00:00
20:12:02 Saving [datastore1] contoso-wa/contoso-wa.vmx 00:00
20:12:02 Saving [datastore1] contoso-wa/contoso-wa.nvram 00:00
20:12:03 Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nbd] 00:00
20:12:04 Hard disk 1 (80 GB) 4,7 GB read at 15 MB/s [CBT] 05:58
20:18:09 Removing VM snapshot 01:04
20:19:14 Saving GuestMembers.xml 00:00
20:19:15 Finalizing 00:02
20:19:18 Truncating transaction logs 00:06
20:19:28 Swap file blocks skipped: 111 MB
20:19:28 Deleted file blocks skipped: 935,5 MB
20:19:29 Busy: Source 92% > Proxy 75% > Network 70% > Target 49%
20:19:29 Primary bottleneck: Source
20:19:29 Network traffic verification detected no corrupted blocks
20:19:29 Processing finished at 18.04.2023 20:19:29

[~thc]

Wenn an beiden Standorten die VEEAM-Maschine ein separater PC ist, dann geht "Proxy" auf die CPU des VEEAM-PCs zurück - denn bei einer Standard-Installation ist der Standard-Kompressions-Proxy die gleiche Maschine. Sind die CPUs/RAMs/Disks der beiden VEEAM-PCs verschieden?

Die schlechten "Source"-Werte deuten entweder auf einen Netzwerk-Engpass zwischen ESXi und VEEAM-Maschine am Standort oder fehlendes Read-Caching im ESXi oder Überlastung des Disk-Systems im ESXi hin.

Generell sind alle die Werte für mich viel zu hoch - hier mal zum Vergleich eine VEEAM-Installation direkt auf dem Microsoft Hypervisor (nicht meine Idee - habe ich so übernommen - Ersatz wird gerade eingerichtet).

VMs auf iSCSI-Volume des Hypervisors (iSCSI-Target auf einem NAS - 183 MB/s - 16 Minuten):

Code: Alles auswählen

Load: Source 0% > Proxy 7% > Network 0% > Target 0%

VMs auf SMB-Freigabe / USB-Festplatte am gleichen NAS (81 MB/s - 1 Stunde 51 Minuten):

Code: Alles auswählen

Load: Source 0% > Proxy 4% > Network 0% > Target 98%

[vmware-admin2016]

....wenn ich veeam mal aussen vor lasse, dies sind noch 1-2 weitere Infos:

Host1: hat auch eine Server Win2019 VM, habe dies getestet:

Testlauf: 10GB PST Datei von Synology NAS auf kopieren auf Win2019
Kopierrate = 5-20 MB/s

Thin oder Thick erstmal egal vermute ich
RAID 6 mit 5x 600GB 10k
stecken Synology und Host1 am selben 24/48 Port Switch (unbekannt im moment)

ML350 Gen8
48 GB RAM 6x 8GB
1x Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
Smart Array P420i Controller

im vShere Client:
LSI Logic SAS, Netzwerkkarte E1000E

im Gerätemanager Win2019:
LSI SAS 3000, Microsoft Controller für Speicherplätze
Intel 8257EL Gigabit Network Connection (es steht dort 1 GBs statt 10 GBs)

[vmware-admin2016]

Wenn an beiden Standorten die VEEAM-Maschine ein separater PC ist, dann geht "Proxy" auf die CPU des VEEAM-PCs zurück - denn bei einer Standard-Installation ist der Standard-Kompressions-Proxy die gleiche Maschine. Sind die CPUs/RAMs/Disks der beiden VEEAM-PCs verschieden?

Die schlechten "Source"-Werte deuten entweder auf einen Netzwerk-Engpass zwischen ESXi und VEEAM-Maschine am Standort oder fehlendes Read-Caching im ESXi oder Überlastung des Disk-Systems im ESXi hin.

Generell sind alle die Werte für mich viel zu hoch - hier mal zum Vergleich eine VEEAM-Installation direkt auf dem Microsoft Hypervisor (nicht meine Idee - habe ich so übernommen - Ersatz wird gerade eingerichtet).

VMs auf iSCSI-Volume des Hypervisors (iSCSI-Target auf einem NAS - 183 MB/s - 16 Minuten):

Code: Alles auswählen

Load: Source 0% > Proxy 7% > Network 0% > Target 0%

VMs auf SMB-Freigabe / USB-Festplatte am gleichen NAS (81 MB/s - 1 Stunde 51 Minuten):

Code: Alles auswählen

Load: Source 0% > Proxy 4% > Network 0% > Target 98%

ohaa, das sind spitzen werte

..verschiedene Veeam PCs mit cpu/ram specs unterschiedlich << muss ich nochmal prüfen, eher nicht,

...fehlendes Read-Caching im ESXi <<< uff das müsste ich recherchieren wo das steht

...die schlechten "Source"-Werte deuten entweder auf einen Netzwerk-Engpass zwischen ESXi und Synology NAS ( statt VEEAM-Maschine)

ESXi <> Synology NAS

[vmware-admin2016]

Dies sind die Veeam Werte Host 3 Gen10 mit SSD, neuer ESX Host.

Veeam über den gleichen separaten Veeam Hardware PC auf eine einzige Synologyy NAS.
wie Host1 und Host2 (ml350 gen8)
Alle drei im selben Serverraum. Das mit unterschiedlichen Städten/Standorten muss ich revidieren, Verzeihung.

Beispiel Wawi Server auf Host3:

20:15:22 Queued for processing at 18.04.2023 20:15:22
20:15:22 Required backup infrastructure resources have been assigned 06:52
20:22:19 VM processing started at 18.04.2023 20:22:19
20:22:19 VM size: 90 GB
20:22:19 Getting VM info from vSphere 00:01
20:22:24 Inventorying guest system 00:02
20:22:26 Preparing guest for hot backup 00:11
20:22:44 Releasing guest 00:00
20:22:44 Creating VM snapshot 00:00
20:22:44 Getting list of guest file system local users 00:00
20:22:48 Saving [datastore] wawi22/wawi22.vmx 00:00
20:22:48 Saving [datastore] wawi22/wawi22.vmxf 00:00
20:22:49 Saving [datastore] wawi22/wawi22.nvram 00:00
20:22:50 Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nbd] 00:00
20:22:51 Hard disk 1 (90 GB) 1,7 GB read at 44 MB/s [CBT] 00:43
20:23:40 Removing VM snapshot 00:05
20:23:45 Saving GuestMembers.xml 00:00
20:23:47 Finalizing 00:01
20:23:48 Truncating transaction logs 00:02
20:23:54 Swap file blocks skipped: 22 MB
20:23:54 Deleted file blocks skipped: 418 MB
20:23:55 Busy: Source 84% > Proxy 70% > Network 59% > Target 49%
20:23:55 Primary bottleneck: Source
20:23:55 Network traffic verification detected no corrupted blocks
20:23:55 Processing finished at 18.04.2023 20:23:55

[~thc]

...die schlechten "Source"-Werte deuten entweder auf einen Netzwerk-Engpass zwischen ESXi und Synology NAS ( statt VEEAM-Maschine)

ESXi <> Synology NAS

Nö - so wie ich die Architektur von VEEAM verstanden habe, werden die Quelldaten zunächst von der "Source" (ESXi) zum "Proxy" (VEEAM-PC) geschaufelt, dort komprimiert und dann per Netzwerk zum "Target" (NAS) geschoben.

[vmware-admin2016]

Ein normaler Büro PC (nebenan)
und eine eine Windows-VM
auf host3 (neu-mit SSDs)

können beide
mit 100 MB/s
von Synology auf den eigenen Windows Desktop kopieren

ERGO ist bei HOST1 und HOST2 was im ARGEN.

Das Synology und Host3 an einem neuen Switch hängen,
und Host1+2 an einem älteren Switch kann ich noch nicht ausschließen.

Ich erinnere, das damalig irrtümlich SATA Controller im ESX oder im Windows installiert wurden, d.h. es gab da irgendwie mal eine Korrektur.

[Dayworker]

HOST1
Raid 6 SAS 10k Festplatten
Synology DS1618+ mit zwei LAN Kabeln als BOND
Raid Controller Cache Module zeigt aktuell noch FAILED im ILO.

Cache-Probleme und Raid6 sind eher ungünstig, vor allem wenn BTRFS als Dateisystem ins Spiel kommt. Laut Synology DS1618 Plus Data Sheet ger.pdf werden als Highlights angeführt:

Code: Alles auswählen

Herausragende Leistung mit über 2.030 MB/s (Lesen) und 620 MB/s (Schreiben)

Habt ihr eigentlich die "M2D17-Adapterkarte für M.2 SSD-Cache" verbaut und den Speicher aufgerüstet?

HOST2
Raid 6 SAS 10k Festplatten
Synology DS918+ mit zwei LAN Kabeln als BOND

Laut Synology DS918 Plus Data Sheet ger.pdf ein kleineres Modell und ebenfalls mit BTRFS.


Ob das etwas zu sagen hat, dazu fehlt mir die Erfahrung vor allem mit BTRFS. ABER ausgehend von ZFS hilft viel Arbeitsspeicher immer viel beim Cachen.
Schaut man sich die Lese-Werte von Host3 an, bekommt man sowas gereicht:

Code: Alles auswählen

20:22:51 Hard disk 1 (90 GB) 1,7 GB read at 44 MB/s [CBT] 00:43

Für Server-HW würde ich dort höhere Werte erwarten, aber für eine vergleichende Einschätzung fehlt mir die Erfahrung.

[irix]

1. Solange deine Serverhardware ein Cache Problem beim RAID Controller meldet ist alles andere Zeitverschwendung. Die Default Einstellung wuerde zumind. den WriteBack deaktivieren welche am Ende auch die ReadPerformance beintraechtigen wird.
2. Bei dem einen Host wird [nbd] und beim anderen[hotAdd] verwendet. Das ist somit alles Apfel und Birnen. Der ~thc hats schon angedeutet das der Datenfluss ein ganz anderer ist als du evtl. erwartest. Das kann schon daran liegen das der Veeam Job falsch konfiguriert ist was die Auswahl evtl. Proxies angeht.

Nebenbei
1. Gibt einen RegistryKey welcher die parallele SessionAnzahl fuer NBD erhoeht(Default ist wohl 1.)
2. Wenn es nen 0815 Bond fuer deine Synology ist dann wuerde sich dieser nur auf sendene Pakete von der Synology aus auswirken.... und da auch nur wenn mehrere Ziele bedient werden. Du hast beim Backup aber eingehende Pakete und somit wirk sich der zumin.d nicht Positiv aus weil hierfuer muesste ein richtiger LACP LAG konfiguriert werden damit der Switch auch richtig mitarbeiten kann. Wenn iSCSI verwendet wird dann ist nen LAG eher weniger gut.
3. Veeam Vergleichswerte mach ich nur immer mit einem Active Full weil bei allen anderen Faellen muss man genau hingucken was die Zahlen angeht.


Gruss
Joerg