Altaro Backup langsam

[guh12hi]

Guten Tag,

ich habe folgende Konfiguration:

- Host Server DL380 G7 / SAS und SSD HDD / 4 GBit NIC / 144 GB RAM / ESXi 5.5 9919047 / Raid5 5TB SAS / 2 x 2 TB SSD
- 3 VM Windows Server 2012 R2 DC
- externes NAS 2 x GBit NIC
- GBit Switch
- Altaro neueste Version

Es ist kein produktives System. Es ist nur User angemeldet.
und folgendes Problem:

Die Datensicherung ist sehr langsam und bricht ab.


Was ich auch bemerkt habe, dass der Filetransver zwischen den internen Volumes (SAS <--> SAS auch sehr langsam ist).
Transverdaten von der VM zum externen NAS: upload 45,31 Mbps / 285,7 Mbps download

An welcher Schraube in ESXi Verwaltung müsste ich drehen, damit das alles schneller vor sich geht.

Danke

[Dayworker]

Ist das NAS per NFS angebunden?
Falls JA, hast du damit schon das Problem fast erkannt. Der ESXi bindet NFS immer Sync an und es gibt keinen Weg, ein Asynchron zu erzwingen. Das NAS ist also entweder schnell und wirft den Schreib-Ack fix raus oder es bleibt langsam.

SSDs im HW-RAID machen nur Sinn, wenn dies Server-Modelle sind. Allen Consumer-SSDs ist gemein, daß deren Schreiblatenz zu stark schwankt. Der Controller wirft dadurch früher oder später ein RAID-Member raus und meldet das RAID als degraded/herabgestuft.

Die doch recht geringen Übertragungsraten deuten darauf hin, daß der Controller ohne Schreib-Cache samt BBU bzw dessen Flash-Pendant läuft. Der ESXi hat keinen Dateisystem-Cache und verläßt sich daher völlig auf die Performance des HW-Controllers.

[guh12hi]

Hallo Dayworker,

Danke für Deine Hilfe.

Im Raidverbund sind nur die SAS HDD. Die SSD wird für die Auslagerungsdatei verwendet.

Das NAS ist über SMB Freigabe erreichbar.

Als RAID Controller, ist der "Smart Array P410i mit 512 MB FBWC Cache (6G SAS / 3G SATA)" verbaut, aber ohne Batteriepack.

Kann es evtl. auch sein, dass es am fehlenden Batteriepack liegen kann. Ich hatte mich auf Deine Anregung hin belesen und gesehen, dass der Schreibcache bei fehlendem Akku-Pack, ausgeschaltet wird.

Gruss Gunter

[Dayworker]

Wenn du den FBWC hast, sollte sich der Write-Cache einschalten lassen. Du darfst jedoch aufgrund dessen geringen Grösse keine Wunder erwarten. Normalerweise würde ja der Dateisystemcache diesen deutlich erweitern und genau dafür fehlen dem ESXi die Voraussetzungen allein schon hinsichtlich der verschiedenen Dateisysteme. Spätestens wenn der Write-Cache voll ist, wird es also unweigerlich langsamer.

Ich verstehe allerdings nicht so ganz, weshalb du die Auslagerungsdatei auf die SSD packst?
Wenn die Geschwindigkeit der Auslagerungsdatei wirklich wichtig ist, hast du vermutlich zuwenig p- bzw v-RAM im Host bzw Guest. In allen anderen Szenarien würde ich die zu bearbeitenden Daten draufpacken und damit das Potenzial der SSD maximal ausnutzen. Falls das platzmäßig nicht geht, bieten viele Controller die Einrichtung eines Flash-Cache zur Beschleunigung an. 2x Flash hintereinander ist vielleicht auch nicht optimal, wenn die SSD ein NVMe-Modell ist und den FBWC daher in jedem Fall um Längen übertrumpft.

[guh12hi]

Hallo Dayworker,

da ich hier sicherlich nicht der Experte bin, versuche ich, Step by Step die Ursache dafür zu finden. Deshalb hatte ich den Flash auf dem Controller vermutet. Das hat sich aber, wie Du treffend geschildert hast, erübrigt. Ich hatte den AkkuPack installiert und hatte keine wesentliche Besserung gebracht. Auch hatte ich den 512 gegen einen mit 1GB ausgetauscht.

Die Auslagerungsdatei hatte ich auf die SSD gelegt, weil ich dort genug freien Platz dafür hatte. Auf einer anderen SSD, habe ich zwei VM laufen, wo das Backup auch nicht läuft. Daran kann es also auch nicht liegen.

RAM habe ich eigentlich genug. Installiert sind 144 GB, die ich auf die Gast-VM aufgeteilt habe.

Warscheinlich liegt es auch daran, weil die Ressourcen nicht richtig aufgeteilt sind. Irgendwo dazuwischen, liegt der Fehler.

Der Prozessor dümpelt auch nur bei 5%, was mich auch verwundert.

Vieleicht kannst Du mir da auch einen Tipp geben, wie ich dem Host genügend Ressourcen zuteilen kann.

Danke

[guh12hi]

Ich habe die Strucktur, als Bild beigefügt

[Dayworker]

Welche CPU/CPUs steckt/stecken im Server?
Wie hast du den RAM aufgeteilt auf die VMs?
Wie sind die VMs mit vCPUs ausgestattet?

[Martin]

Waren die Raids schon vor dem Einbau des Akkus eingerichtet? Hast Du überprüft, daß der Schreibcache (jetzt) aktiv ist?

[guh12hi]

2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
PDC 64MB, BDC 32MB, APP 32MB
vCPU 2x8

[guh12hi]

OK.

Nein. Wie prüfe ich ob der Schreibcache eingeschalten ist?

Die LED auf dem Cachemodul, leuchtet grün.

Ich habe es geprüft. Der Schreibcache ist eingeschaltet.

[guh12hi]

hat noch jemand eine Idee?

Kann es auch an zugeordneten Ressourcen für den Host liegen? Ich meine damit, ob dort nicht genügend zugeordnet sind?

Danke

[~thc]

Du könntest während des Altaro Backups "esxtop" auf der Shell des ESXi mitlaufen lassen, und dort nach Engpässen in Richtung CPU, Storage und Netzwerk schauen.

[guh12hi]

Danke. Das hatte ich schon gemacht.

Die Ausgabe von esxtop ist schon sehr komplex und ich sehe dort nur "Bahnhof", weil mir dazu die Kentnisse fehlen.

Nachfolgend ein Auszug aus der Ausgabe. Könntest Du da bitte mal rüberschauen.

~ # esxtop
8:37:09am up 12:54, 746 worlds, 11 VMs, 162 vCPUs; CPU load average: 0.26, 0.28, 0.29
PCPU USED(%): 9.7 7.3 7.5 11 6.6 6.8 7.2 7.5 10 6.9 10 10 5.6 3.5 3.3 3.2 3.5 2.4 3.1 4.2 3.1 2.8 2.5 4.2 AVG: 6.0
PCPU UTIL(%): 18 15 15 21 14 14 15 15 21 14 19 20 12 8.5 7.9 7.5 8.1 5.8 7.2 9.4 7.2 6.5 5.8 9.3 AVG: 12
CORE UTIL(%): 29 32 24 26 31 35 17 12 11 14 11 13 AVG: 21




5623 5623 19 Client10 guh 14 41.68 73.30 0.08 1338.57 0.4
11490 11490 13 Client04 ibu 22 25.46 40.85 0.10 2174.03 0.0
10674 10674 53 Windows Serv 28 16.17 30.47 0.08 2782.34 0.0
9729 9729 52 Windows Serv 24 13.98 26.75 0.05 2382.74 1.2
11448 11448 11 Client02 sza 22 9.66 18.42 0.04 2196.94 3.4
9062 9062 50 Windows Serv 18 5.38 10.95 0.06 1793.07 2.2
11492 11492 12 Client03 dko 22 4.70 10.03 0.02 2200.00 0.0
11423 11423 10 Client01 ama 17 3.58 6.76 0.03 1700.00 2.1
11489 11489 14 Client05 lst 22 3.14 7.21 0.02 2200.00 0.0
9207 9207 51 Windows Serv 22 2.81 6.63 0.03 2200.00 0.0
249276 249276 esxtop.163051 1 2.52 2.98 0.00 97.85
11491 11491 15 Client06 17 1.98 4.27 0.03 1700.00 0.0
2 2 system 136 1.84 2.24 0.00 13600.00
2338 2338 hostd.34182 26 0.20 0.35 0.01 2600.00
2862 2862 sh.34453 1 0.16 0.33 0.00 100.00
8 8 helper 162 0.12 0.18 0.00 16200.00
2416 2416 rhttpproxy.3422 11 0.04 0.08 0.00 1100.00
248803 248803 sshd.162815 1 0.04 0.04 0.00 100.00
3046 3046 vpxa.34551 8 0.03 0.05 0.00 800.00
1845 1845 vmware-usbarbit 2 0.01 0.02 0.00 200.00
1220 1220 net-lacp.33524 3 0.01 0.02 0.00 300.00
1334 1334 vmkiscsid.33584 2 0.01 0.01 0.00 200.00
3892 3892 openwsmand.3499 3 0.01 0.01 0.00 300.00
9 9 drivers 13 0.00 0.01 0.00 1300.00
4620 4620 sfcb-ProviderMa 10 0.00 0.01 0.00 1000.00
2749 2749 dcbd.34397 1 0.00 0.00 0.00 100.00
2152 2152 sensord.34093 1 0.00 0.00 0.00 100.00
1591 1591 ntpd.33814 1 0.00 0.00 0.00 100.00
1932 1932 swapobjd.33986 1 0.00 0.00 0.00 100.00
5002 5002 sfcb-ProviderMa 9 0.00 0.00 0.00 900.00
10 10 ft 5 0.00 0.00 0.00 500.00
2468 2468 slpd.34258 1 0.00 0.00 0.00 100.00
4617 4617 sfcb-ProviderMa 8 0.00 0.00 0.00 800.00
2104 2104 storageRM.34070 1 0.00 0.00 0.00 100.00
1 1 idle 24 0.00 2400.00 0.00 0.00
11 11 vmotion 1 0.00 0.00 0.00 100.00
362 362 init.33084 1 0.00 0.00 0.00 100.00
884 884 vmsyslogd.33322 1 0.00 0.00 0.00 100.00
886 886 vmsyslogd.33323 3 0.00 0.00 0.00 300.00
900 900 sh.33332 1 0.00 0.00 0.00 100.00
947 947 vobd.33355 18 0.00 0.00 0.00 1800.00
951 951 sh.33374 1 0.00 0.00 0.00 100.00
995 995 vmkeventd.33396 1 0.00 0.00 0.00 100.00
1002 1002 busybox.33399 1 0.00 0.00 0.00 100.00
1064 1064 vmkdevmgr.33446 1 0.00 0.00 0.00 100.00
1173 1173 sh.33501 1 0.00 0.00 0.00 100.00
1318 1318 busybox.33578 1 0.00 0.00 0.00 100.00
1544 1544 sh.33791 1 0.00 0.00 0.00 100.00
1798 1798 sh.33919 1 0.00 0.00 0.00 100.00
1886 1886 sh.33963 1 0.00 0.00 0.00 100.00
1983 1983 sh.34011 1 0.00 0.00 0.00 100.00
2030 2030 sdrsInjector.34 1 0.00 0.00 0.00 100.00
2057 2057 sh.34047 1 0.00 0.00 0.00 100.00
2131 2131 sh.34083 1 0.00 0.00 0.00 100.00
2179 2179 sh.34106 1 0.00 0.00 0.00 100.00
2226 2226 net-lbt.34129 1 0.00 0.00 0.00 100.00
2291 2291 sh.34159 1 0.00 0.00 0.00 100.00
2369 2369 sh.34201 1 0.00 0.00 0.00 100.00
2419 2419 nssquery.34230 1 0.00 0.00 0.00 100.00
2494 2494 sh.34271 1 0.00 0.00 0.00 100.00
2557 2557 smartd.34302 1 0.00 0.00 0.00 100.00
2670 2670 sh.34358 1 0.00 0.00 0.00 100.00
2782 2782 sh.34414 1 0.00 0.00 0.00 100.00
2829 2829 net-cdp.34437 1 0.00 0.00 0.00 100.00
2917 2917 nscd.34480 6 0.00 0.00 0.00 600.00
2999 2999 sh.34528 1 0.00 0.00 0.00 100.00
3057 3057 nssquery.34566 1 0.00 0.00 0.00 100.00
248872 248872 sh.162848 1 0.00 0.00 0.00 100.00
249346 249346 sleep.163086 1 0.00 0.00 0.00 100.00
3600 3600 sh.34848 1 0.00 0.00 0.00 100.00
249409 249409 sleep.163122 1 0.00 0.00 0.00 0.00
3809 3809 sh.34952 1 0.00 0.00 0.00 100.00
4187 4187 cimslp.35138 1 0.00 0.00 0.00 100.00
4192 4192 sfcbd.35140 1 0.00 0.00 0.00 100.00
4194 4194 sfcb-sfcb.35141 1 0.00 0.00 0.00 100.00
4198 4198 sfcb-sfcb.35143 1 0.00 0.00 0.00 100.00

[~thc]

11 VMs, 162 vCPUs

WTF? Einhundertzweiundsechzig vCPUs in 11 VMs? Was ist das denn?

[guh12hi]

Ok. Kann ich jetzt auch lesen.

Aber auch wenn ich alle VM ausschalte, läuft das Backup genauso langsam.

1:17:34pm up 17:34, 632 worlds, 6 VMs, 77 vCPUs; CPU load average: 0.22, 0.27, 0.27
PCPU USED(%): 10 9.3 14 8.8 16 3.3 8.7 36 3.3 92 22 3.5 38 11 51 23 105 2.0 30 9.6 66 16 41 31 AVG: 27
PCPU UTIL(%): 10 16 15 10 18 2.8 9.1 36 6.5 51 23 5.0 42 15 70 32 99 3.9 31 11 70 24 53 43 AVG: 29
CORE UTIL(%): 19 22 19 41 51 25 48 82 99 38 78 68 AVG: 49

[guh12hi]

Als Anlage habe ich die CPU Historie beigefügt

[guh12hi]

Als Anlage habe ich die CPU Historie beigefügt

[~thc]

O.K.

Du hast einen DL380 G7 - dieser hat ein oder zwei Xeon-CPUs - jeder mit n physischen Kernen (Hypertreading bleibt außen vor) - also hast du maximal 2 n physische Kerne.

Die Grundregel ist, einen Kern für den ESXi abzuziehen und den Rest kannst du auf die VMs verteilen. Das würde bei zwei Sechskern-CPUs bedeuten, dass du 11 VMs jeweils eine vCPU gibst. Du kannst natürlich mehr vCPUs verteilen (Overprovisioning), aber zusammen mit Mehrkern-VMs und abhängig von der Last der VMs muss man dann aufpassen, dass sich die VMs nicht gegenseitig auf den CPU-Füßen stehen.

Bei deinem Server haben die VMs im Durchschnitt 11 bis 16 vCPUs - der Hypervisor muss dann für jede Multi-Core-VM warten, bis alle physischen Kerne gleichzeitig mal frei sind (Co-Stop). Das kann zu massiven Leistungseinbrüchen führen.

[guh12hi]

Danke, dass habe ich verstanden. Da es sich nur um ein Projekt zu Wissensaneignung handelt, kann ich die Auslastung so gestalten.

Aber auch wenn ich nur eine VM zu laufen habe, ist das Backup sehr langsam.

[guh12hi]

Welchen Eintag muss ich machen, damit ich dem Host-System, diese Ressourcen zuweise?

[Martin]

Versuche als ersten einmal eine VM mit nur 4 vCPU laufen zu lassen und dann nochmal zu testen.
Du hast zwei 6core CPUs im Server, damit werden VMs mit mehr vCPUs nicht wirklich effektiv parallel laufen.

[~thc]

Da es sich nur um ein Projekt zu Wissensaneignung handelt, kann ich die Auslastung so gestalten.

Das kannst du - das ist dann aber möglicherweise eine Ursache für das langsame Backup.

Welchen Eintag muss ich machen, damit ich dem Host-System, diese Ressourcen zuweise?

Diese Frage hast du auch weiter oben schon einmal gestellt:

Kann es auch an zugeordneten Ressourcen für den Host liegen? Ich meine damit, ob dort nicht genügend zugeordnet sind?

Glaubst du, dass der ESXi Ressourcen deines Server links liegen lässt?

[guh12hi]

Hallo thc,

auch wenn Du dir anscheinend mehr Wissen bei VMWARE angeeignet hast, heist das nicht zwangsläufig, dass Du mich vorführen musst.
Ich stelle hier meine Fragen, weil ich es besser machen möchte und NICHT um irgendjemand damit zu ärgern.

Ja, eine Frage hatte ich schon einmal gestellt. Diese wurde aber nicht zielführend beantwortet. Deshalb ein zweites mal. Vieleicht kannst Du sie mir beantworten?

Ich bin wirklich jenen dankbar, die ihr Wissen mit mir teilen und mir mit ihrem Rat weiterhelfen.

Falls Du mal einen Tip zu OPC Servern oder Automatisierungsnetzen (LON oder anderen Feldbussystemen, Routern, ...) haben möchtest, bin ich der Experte und helfe denen gern, die Hilfe benötigen.

Jeder ist Experte auf seinem Gebiet. Hier bin ich es devinitv nicht und stelle daher auch mal Fragen, die Dir komisch vorkommen. Schämen muss ich mich dafür nicht.

Hallo Martin,

Danke für Deine Antwort. Das werde ich heute Abend testen und das Ergebnis hier Posten und freue mich für Deine Hilfe.

[~thc]

Ich sehe an deiner Antwort, dass ich einfach hätte sagen sollen: Reduziere alle VMs auf ein oder zwei vCPUs.

Wieder was gelernt.

[irix]

In den meisten meiner Faelle wo das Backup langsam ist treffen wir am Ende immer auf ein LowCost NAS mit wenigen Spindeln, dafuer Hohe Kapazitaet, mit Festplatten die keine 5400rpm machen was in keinster weise Parallele Datenstroeme aufnehmen kann.

Was zeigt denn die Backupsoftware so an Transferaten an bzw. was zeigen denn die Performancegrafen des ESXi fuer die entsprechende pNIC an? Wie gross ist denn die Datenmenge bzw. wielange dauerts? Spaeter dank CBT und Inkremental ist die Datenmenge ja viel geringer und ob es dann ein paar MB mehr oder weniger sind spielt keine Rolle.

Des weiteren sind natuerlich esxtop Auszuege interessant wenn das Backup laeuft.

Gruss
Joerg