VMware-Forum

Hallo zusammen,

Bei einem Kunden wurden die Backupstrukturen umgestellt.

Bei der Initialen Sicherung mit Veeam fällt nun eine recht miese Datenübertragungsrate von ~40MB/s auf. Wie sind da eure Werte?

Die vier ESXi5.1 Hosts sind über 8Gbit FC mit dem Stor verbunden (zweipfadig RR).

Veeam läuft auf einer dicken VM, an der ein 13TB RDM (pysical mode) hängt, darauf liegt das Repository.

Die VMs, die gesichert werden, laufen auf dem SAS Teil des IBMs (6x Raid5 aus 8x 10K HDDs gestriped).

Das RDM der Veeam VM liegt auf dem NL-SAS Teil des IBMs (2 x Raid6 aus 9 HDDs gestriped).

Veeam gibt das Bottleneck für die "source" aus, und zwar mit 99% :-/

Ich bin nun etwas verwirrt, läuft etwas falsch oder nicht?

Viele Grüße,
Conne

In der Regel schaffen wir bei Kunden 170 bis 200 MB/s (egal ob iSCSI oder FC) und der Veeam Backupserver ist eigentlich immer das Bottleneck (die CPU). Dedup und Compression sind halt CPU lastig. Da geht noch mehr, wenn man halt auf Dedup etc. verzichtet.

Die Veeam VM hat 8 Cores 16Gb vRAM und ist während Backup zu ca 30% auf der CPU ausgelastet. In den Hosts sind jeweils zwei SandyBridge 2690 drin. Warum zeigt Veeam die source als 99%iges Bottleneck an?

Kopieren auf Dateiebene geht mit ~280Mb/s zwischen den SAS<->NLSAS Teilen, auf der Ebene scheint alles OK zu sein.

Das Bottleneck ist euer Storage, nicht der Backupserver (bei uns sind das i.d.R. Quad- oder Hexacore mit 8 bis 16 GB RAM). Könnte ein Problem mit dem Multipathing sein. Check mal mit Perfmon was die HBAs treiben.

hast du einen Befehl für die Shell oder meinst du Windows?

Windows > Star > Ausführen > perfmon

Die Einstellungen der Backup-Jobs wurden geprüft? Hat sich an den Backup-Proxies was geändert? Sieht so aus, als wenn über LAN gesichert wird.

Nur mal ne Zwischenfrage:

Wer har RR empfohlen? Vmware sagt Fixed mit der Bemerkung, dass man für RR nachfragen sollte

weigeltchen hat geschrieben:Die Einstellungen der Backup-Jobs wurden geprüft? Hat sich an den Backup-Proxies was geändert? Sieht so aus, als wenn über LAN gesichert wird.

Das war auch mein Gedanke. Aber selbst dann sollte doch etwas mehr als 40MB durch die Leitung gehen...

Hallo,

Die Einstellungen der Backup-Jobs wurden geprüft? Hat sich an den Backup-Proxies was geändert? Sieht so aus, als wenn über LAN gesichert wird.

DIe Backupjobs sind noch die alten. Es ist lediglich das neue Repository hinzugekommen. Außer dem neuen Repository und dem verändern von "LAN-Target" nach "local Target", wurde ncihts angepasst.

Vorher wurde auf ein OPEN-E DSS V6 (CIFS) gesichert, das mit 10GbE angefahren wurde, mind. um die 120MB/s beim Fullbackups. Flachenhals war IMMMER das Target...

Wer har RR empfohlen? Vmware sagt Fixed mit der Bemerkung, dass man für RR nachfragen sollte

Das kommt von der FA. die das Stor aufgestellt hat, und die stellen wohl viele von diesem Typ auf... Ich habe mir es schriftlich geben lassen.

weigeltchen hat Folgendes geschrieben:
Die Einstellungen der Backup-Jobs wurden geprüft? Hat sich an den Backup-Proxies was geändert? Sieht so aus, als wenn über LAN gesichert wird.


Das war auch mein Gedanke. Aber selbst dann sollte doch etwas mehr als 40MB durch die Leitung gehen...

Jepp, das käme vom Durchsatz hin. ~40MB/s war auch etwas untertrieben. Besser: zwischen 40 und 60 MB/s.

Aber warum????

Gruß,
Conne

Stell doch einfach mal im BackupProxy ab, daß er als Failover übers LAN sichern soll und stosse einen Job an. Wenn er dann nichts mehr sichert, weißt Du, daß er da ein Problem mit Zugriff aufs Storage hat?

Edit: Tippfehler

Nur so als Randbemerkung: Die zu sichernden VM und das neue Backuprepository liegen alle auf dem v3700? Storage weg, Backup auch weg?

Stell doch einfach mal im BackupProxy ab, daß er als Failover übers LAN sichern soll und stosse einen Job an. Wenn er dann nichts mehr sichert, weißt Du, daß er da ein Problem mit Zugriff aufs Storage hat?

Jupp, wenn es abgeschaltet ist, schlage alle BAckups fehl. Mit ner sehr kuriosen Fehlermeldung.

"Error: Client error: Failed to open VDDK disk [[IBM-LUN09_SAS] vCenter/vCenter.vmdk] ( is read-only mode - [true] ) Failed to open VMDK. Logon attempt with parameters [VC/ESX: [Py-ESX-03];Port: 443;Login: [****];VMX Spec: [moref=8];Snapshot mor: [8-snapshot-35];Transports: [san];Read Only: [true]] failed because of the following errors:"

Nur so als Randbemerkung: Die zu sichernden VM und das neue Backuprepository liegen alle auf dem v3700? Storage weg, Backup auch weg?

Ist eine temp. Lösung. Am WE wird der ganze Haufen aber trotzdem noch auf Band geschrieben. Der OPEN-E DSS ist am Wochenende gecrashed (echter Hardwareschaden) und muss jetzt neu gemacht werden.

Gruß,
Conne

Naja, dann darf die Sicherungs-VM, bzw. deren iSCSI-Initiator nicht richtig auf die LUNs zugreifen. Und die Geschwindigkeit über das über das LAN ganz normal würde ich sagen.

Der-/Diejenigen, die den Zugriff für die VM eingerichtet haben, sollen sich das nochmal anschauen.

Ich hatte vor ein paar Wochen das Problem, daß er auf das SAN immer über Lan und nicht über FC zugegriffen hat. DIe Einstellung Transport Mode im Proxy war "Direct SAN access".
Ich habe dann auf "Automatic selection" gestellt und seitdem geht es wieder im Direct SAN access über FC.

Warum auch immer.......

Gruß
Tommy

wakesetter hat geschrieben:....
Ich habe dann auf "Automatic selection" gestellt und seitdem geht es wieder im Direct SAN access über FC.

Warum auch immer.......

Dann liegt aber alle Last auf dem phys. Backupserver welcher aber bei euch ueppig ausgestattet ist. Bei einer hohen Anzahl an ESXi Hosts machts natuerlich evtl. Sinn die Proxies aus zurollen und HotAdd zumachen.

Gruss
Joerg

Steht auf Automatic, Haken bei Failover über Netzwerk deaktiv.

Aber ich gehe nciht falsch der Annahme, dass die Platten aller VMs innerhalb des HA Clusters in der Zeit des Backups per HotAdd an die Veeam-VM drangehangen werden!?

Klar, bei vielen ESXi Hosts oder keinem vCenter wäre ein Veeam-Proxy pro Host wohl unverzichtbar.

Aus der Veeam-VM sind bei uns keine speziellen "Wege" ins Stor konfiguriert. Das HotAdd hat bisher immer sehr gut funktioniert...

Klar, iwie bekommt Veeam keine Berechtigung für das Anhängen der vHDDs. Aber was umgestellt/angepasst werden muss, damit es wieder funktioniert, ist nciht klar.

Gruß,
Conne

Wenn Veeam eh virtuell läuft würde ich den HotAdd Modus zum sichern nehmen. Ich weiß nur grad nicht ob der sich RDMs in der VM verträgt, das vielleicht noch mal in der Veeam Dokumentation nachschlagen.

ja, das war auch schon meine Vermutung. Das RDM ist aber "nur" das Sicherungsziel. Es muss kein SnapShot von der HDD gemacht werden, noch muss sie irgendwo drangehangen werden.

Ich habe sie vorsichtshalber mal an einen extra SCSI Controller gehangen, und auch an die 15. Stelle, weil es physikalisch die LUN15 ist. Keine A. ob das hier wirklich relevant ist. Aber schaden tuts im Moment auch nicht :-/

Ein Test wäre nun, statt dem RDM ein Repository auf eine neue VMDK an der Veeam VM zu erstellen. Mom...

Test mit VMDK statt physical RDM: Löst das problem leider nicht.

Gruß,
Conne

Wen es interessiert:

Nach Ticketeröffnung bei Veeam und daraus resultierendem Öffnen eines Tickets bei Vmware, konnte das Problem gefunden werden.

Aus irgendwelchen Gründen, hat das System versucht, über "Direct Access" zu sichern, obwohl "Appliance Mode" hinterlegt war. Klar, dass dann kein Zugriff auf die VMDK Dateien möglich war.

Nachdem vom Veeam Support ein paar Dateien gelöscht und ein Patch eingespielt wurde, lief die ganze Sache. Endlich mit annehmbarer Geschwindigkeit (~180MB/s (!) beim Fullbackup).

Etwas schade war, dass Veeam nach Auswertung der Logs erstmal sagte: Es muss an VMware liegen, bitte Ticket öffnen. Bei VMware hat man den Veeam Support wegen seiner wirren Behauptungen und Schlussfolgerungen etwas auslachen müssen.

Die letzte Informationsmail von VMware war deshalb auch sehr amüsant, vor allem, weil sie in CC direkt an den Veeam Support ging.

Grüße,
Conne