Schlechte Performance Datastore

[mcdaniels]

Hallo,

ich bin jetzt schon einige Zeit damit beschäftigt zu eruieren, weshalb unsere Datensicherung mit VEEAM (NBD Mode) so langsam ist. 90MB/SEC bei einer 10GBit Anbindung. Raid 10 über 10 SAS Festplatten 10k. (DAS-Storage = direkt im Server verbaut).

Auch wenn die Sicherung über das Managementnetzwerk erfolgt, das gedrosselt ist, sollte der Datentransfer schneller sein, denke ich.

Der Veeamsupport verweist nach Analyse (ohne wirklichem Ergebnis) auf ein VMWARE-Problem mit dem Datastore.
Das wiederum halte ich für ausgeschlossen, da wir das Problem von Anfang an hatten und das Problem auch bei einem neuen ESXI Server (gleiche Ausstattung) exakt so besteht.

Veeam in einen anderne Netzwerkmodus wie NBD zu bringen, ist aufgrund des DAS Storage nicht möglich.

Bottleneck lt. Veeam ist immer Source. Ich habe auch einen Netzwerktransfertest durchgeführt. Dieser hat einen Durchsatz von :

Code: Alles auswählen

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   327 MBytes  2.74 Gbits/sec  8626536   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   1.00-2.00   sec   357 MBytes  2.99 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   2.00-3.00   sec   393 MBytes  3.30 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   3.00-4.00   sec   394 MBytes  3.31 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   4.00-5.00   sec   395 MBytes  3.32 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   5.00-6.00   sec   396 MBytes  3.32 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   6.00-7.00   sec   392 MBytes  3.29 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   7.00-8.00   sec   393 MBytes  3.30 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   8.00-9.00   sec   391 MBytes  3.28 Gbits/sec    0   0.00 Bytes
iperf3: getsockopt - Function not implemented
[  4]   9.00-10.00  sec   393 MBytes  3.30 Gbits/sec  4286340760   0.00 Bytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  3.74 GBytes  3.21 Gbits/sec    0             sender
[  4]   0.00-10.00  sec  3.74 GBytes  3.21 Gbits/sec                  receiver
CPU Utilization: local/sender 50.2% (50.3%u/0.0%s), remote/receiver 0.7% (0.1%u/0.7%s)

Hat jemand von euch Erfahrung damit bzw. betreibt VEEAM im NBD Mode und hat einen DAS Datastore?

[irix]

Bei NBD wird eigentlich *immer* die Source als Bottleneck angezeigt. Ich bin gerade bei einem Kunden 3 Server und phys. Backup mit lokalem SAS RAID6 am hinstellen.
Ich hatte das initial Backup schon gemacht aber mir die Werte nicht gemerkt. Da die VMs noch recht klein sind und dank Thin bzw. "Nullen" sind es eh Phantasie Werte welche Veeam da anzeigt. Es waren IIRC 700MB/s bei 6 Tasks gleichzeitig... aber die rechnen die Transferrate basierend auf der Zeit und "Groesse" der vDISKs. Wenn ich es recht noch weiss dann war die "rote" Schreibleistung bei 200MB/s oder so.

Ich gucke morgen noch mal nach bzw. kann ein Active Full machen.

Gruss
Joerg

[mcdaniels]

Hi Jörg,
das wäre super. Ja bitte!

Das war heut mal ein Test, während der Veeam Support via Teamviewer "mit dabei war".

Danke!

[~thc]

Hmmmm.

Wenn man all diesen Infos glauben schenken darf, dann ist es doch so: In der 20 GB VMDK sind 2 GB belegt, die mit dem Beschleunigungsfaktor 2,4 in 80 Sekunden gesichert werden. Da ich annehme, dass das ein Full Backup war, müssen die Daten komprimiert worden sein. Zusammen mit der Load-Angabe (99%) lese ich daraus, dass nicht schneller komprimiert werden kann.

Kann man zum Testen mal die Kompression ausschalten?

[irix]

Da ich sonst eher mit HotAdd zutun haben.... ich meine das bei NBD die Kompression auf den pyhs. Backup Server stattfindet genau wie das wegschmeissen der Nullen und so. Der "ESXi" komprimiert da auf jeden Fall nichts und ein einzig CBT reduziert die Datenmenge (nicht bei FullBackup) zu diesem Zeitpunkt. Behaupte ich solange bis zum Gegenteil
Falls ein Kunde da gespart hat sehen wir dann immer hohe CPU Auslastung auf dem Geraet.

Der Faktor 2.4 ist die Summe aller Einsparungen welche Veeam erreichen konnte um Verhaeltnis der Datenmenge was Lesen und letztendlichen Wegschreiben auf Platte angeht.

Gruss
Joerg

[~thc]

O.K., aber bei physischer Backup-Server-Kompression macht die Angabe der Target-Load (0%) keinen Sinn.

[irix]

Da hast du in der Tat Recht!

Gruss
Joerg

[~thc]

Ich mache mal die Annahme, dass der Backup-Proxy die Dateisystemanalyse (2 von 20 GB müssen gesichert werden) und die Kompression macht (Load 24%). Dann wirft der ESXi einfach nur die VMDK auf das Management-Netzwerk.

80 Sekunden mal 99 MB/s sind 7920 MB oder 7,7 GB - weder 869 MB noch 2 GB noch 20 GB. Der Wert ist also hirnrissig.

80 Sekunden für 20 GB (die rohe VMDK) sind 256 MB/s oder 2048 MBit
80 Sekunden für 2 GB (unkomprimierte Daten) sind 25,6 MB/s oder 205 MBit
80 Sekunden für 869 MB (komprimierte Daten) sind 10,8 MB/s oder 86,4 MBit (4% von 2 GBit)

Meine Vermutung: Der ESXi liefert tatsächlich 20 GB an den Backup-Proxy aus - dann wäre das Management-Netzwerk zu zwei Dritteln ausgelastet (wenn der Durchsatz-Test vernünftige Werte liefert).

[irix]

Anbei meine Werte. Sind aehnlich denen welche ich oben schon geschrieben hatte. Unterschied ist nur das die VMs auf 3 Hosts nun verteilt sind und nicht auf einem liegen und das Windows hat mittlerweile Daten aufgenommen und es wurde Software installiert.

Hier so mitten drin

Veeam

Das Ende

Veeam

Oben sieht man das der pyhs. Server unter Last ist. Die rote Schreibrate sind 380-410MB/s.
ESX-> 2x10Gb LR -> Backup Server mit lokal RAID6.

Gruss
Joerg

[mcdaniels]

@Jörg
so eine Performance hätte ich gerne!

Da sind meine Werte trotz Raid 10 + 10Gbit Netzwerk ja lächerlich!

Ist das auch im NBD Mode von Veeam? Läuft somit auch über das Managementnetzwerk des ESXI? D.h. da "bremst" also nix....

Der Veeam Support schiebt es auf den ESXI. Somit stehe ich quasi wieder bei 0 und muss mir wiedermal selbst helfen

Ich werf jetzt nochmal bei mir ein Backup einer größeren VM an und poste das dann hier.

Das Management-Netzwerk ESXI hängt auf 10Gbit LAN:

[irix]

@Jörg
so eine Performance hätte ich gerne!

Da sind meine Werte trotz Raid 10 + 10Gbit Netzwerk ja lächerlich!

Ich verkaufe eigentlich an jeden und wenn jemand nett Fragt dann baue ich es auch auf
Allerdings habe ich SSDs in dem Shared SAS SAN.

Ist das auch im NBD Mode von Veeam? Läuft somit auch über das Managementnetzwerk des ESXI? D.h. da "bremst" also nix....

Definitiv NBD da ich keine Veeam Proxies deployed habe.

Der Veeam Support schiebt es auf den ESXI. Somit stehe ich quasi wieder bei 0 und muss mir wiedermal selbst helfen

Ich werf jetzt nochmal bei mir ein Backup einer größeren VM an und poste das dann hier.

Erzeuge dir eine vDisk wo du 20GB Schrottdaten drin hast und die zu 100% auch gefuellt ist. Muss ja keine Lauffaehige VM sein. Dann guck mal im esxtop was an Traffic ueber die vmnics raus geht.

Gruss
Joerg

[mcdaniels]

Die Ausgabe von esxtop ist aber recht umfangreich... wo muss ich denn da genau schauen?

ah ok.. man drücke "n"

[irix]

"n" wie network. Ein "s2" stellt die Refreshrate auf 2 Sekunden.

Gruss
Joerg

[mcdaniels]

Das hier ist n grade laufendes Backup mit ner ziemlich vollen VMDK.

Management ist vmnic3:

[mcdaniels]

Load am Backupserver:

und nochmal:

so wie es aussieht, empfängt der Backupserver lt. Taskmanager mit maximal 1GB/sec?

EDIT: Sehe ich das korrekt, dass der ESXI mit rund 600 MBit nicht Megabyte/sec sendet?

Das heißt, es ist definitiv der ESXI das Problem?

[mcdaniels]

weiter Details zum ESXI (vSwitch / vNic) - Managementnetwork:

[irix]

so wie es aussieht, empfängt der Backupserver lt. Taskmanager mit maximal 1GB/sec?

Yupp.

EDIT: Sehe ich das korrekt, dass der ESXI mit rund 600 MBit nicht Megabyte/sec sendet?

Yupp

Das heißt, es ist definitiv der ESXI das Problem?

Nunja... evtl. kann der Backup Server nicht schneller die Daten wegschreiben. Was passierst denn wenn du mehrere Tasks konfigurierst (Veeam Proxy/Repository) und dann mehr vDisks bzw. VMs in den Job packst.


Bei dem gleichen Kunden von Gestern... eine VRTX noch mit angebunden. Alle 6-8 VMs auf einem einem Host welcher 10K SAS RAID6 Datastores hat. 225MB/s Processing Speed und ca. 345GB in unter 18min sofern ich mich recht erinnere.

Gruss
Joerg

[mcdaniels]

Hi,

im Backupproxy hab ich die Tasks jetzt auf 6 angehoben, wobei wir da folgende Meldung kriegen:

wird aber vermutlich mit dem Speed nix zu tun haben, denk ich.

in den Backup-jobs sind 1x 7 vms und 1x 9vms enthalten.

D.h. das sollte ab sofort parallel laufen (6vms gleichzeitig).

Mal schauen, was sich jetzt tut.

[irix]

Mein Repository ist natuerlich vom Typ ReFS mit 64k. Das spielt dann seinen Trumpf auf mein SynteticFull bzw. wenn er halt die Chain nachrollt.

Achtung. Man gibt die Anzahl der gleichzeitigen TASKs an. Ein Task ist eine vDisk. Wenn eine VM mehrere vDisks hat dann belegt sie gleich die entsprechende Anzahl an Tasks. Somit nicht wundern wenn du im Job die die "passende" Anzahl an Running VMs da hast.

Mal davon abgesehen, Iich wuerde eher gucken ob das Backupfenster ausreicht und wie die Geschwindigkeit beim Restore ist.

Gruss
Joerg

[mcdaniels]

Hi,
momentan laufen mehrere VM-Backups gleichzeitig.

Etwas besser. Der Backupserver empfängt jetzt mit rund 3GBit/sec. Der Datenträger am Backupserver schreibt mit 250 - 300 mb/sec

Das Backupfenster reicht.

Wenn du aber mal 4TB restoren musst und dann einen Tag stehst, schaut die Sache anders aus. (Bei der Geschwindigkeit durchaus vorstellbar!). Aber ich hab jetzt die Möglichkeit ein komplettes Restore auf einen baugleichen ESXI durchzuführen. Mal schauen, wie schnell das geht.

Btw. wenn man über den Graphen hovert dann meint dieser 300 mb / sec read / 280mb/sec write speed.

Heißt aber auch, dass die Infrastruktur offenbar mehr Speed hergibt, das allerdings bei einzel VM Backups nicht "ausspielen" kann.

Ich werd mal schauen ob ich mit dem Hotadd Modus von Veeam "zum fahren" komme. Vlt. hilft das...

[irix]

Nunja.. das hat sich ja nun schon mal verdoppelt was Processing angeht und von knapp 1Gbit auf 3Gbit was den Backup Server angeht.

Fuer das zurueckspielen von Monster VMs oder einem grossflaechigen Restore setzen wir eher auf SAN Snapshots und nicht aus dem eigentlich Backup. Ist natuerlich bei Localstorage oder auch vSAN und Co. ein Problem.

Gruss
Joerg

[mcdaniels]

Hey,
so gut sind wir leider nicht aufgestellt.
Bin mal gespannt was mit dem Hot-add Mode rausschaut.

[irix]

Mit dem HotAdd werde sich auf jeden Fall die Zahlen drastisch verschieben. Ich sage meinen Kollegen immer sie sollen sich nicht an den hohen Zahlen ergoetzen sondern die einzig die Gesamtlaufzeit angucken.
Man kann nicht pauschal sagen das HotAdd oder NBD oder gar SANMode oder SAN Storage das beste ist. Es haengt von mehreren Faktoren ab und HotAdd erhoeht etwas das Betriebsrisiko weil dann und wann passiert das die vDisks am Proxy haengen bleiben und der Admin das nicht auf dem Schirm hat.

Das ist der Grund warum HotAdd im aktuellen Kundenprojekt nicht zum Einsatz kommt.

Gruss
Joerg

[mcdaniels]

Hi Jörg,
danke für die Infos. Ich teste gerade "hot add". Hab dem Proxy Srv 2k16, 8GB Ram, 2x 2,1 Ghz Xeon, VMXNET3 - 10GBIT gegeben.

Nach Backupstart ist die CPU des hot add Proxy sehr schnell auf Dauer 100% Last.
Durchsatz lt. Veeam 250 mb/sec.

Bottleneck in dem Fall der "hot-add-proxy"
Netzwerk allerdings auch auf 96% (was ich gar nicht verstehe... läuft doch maximal mit 1,5Gbit?)

Ethernet

Veeam

Aufgrund der offenbar vorhandenen Risiken (wie du sagst), werd ich Hotadd aber sein lassen.

Verstehen "tu" ich das ganze aber nicht, denn die ganze Konfiguration mit dem Hotadd-Proxy schafft wieder nicht viel mehr als 1,5 GBit ggf.

CPU Limit weil auf 100%?

LG

[irix]

Yupp.