Seite 1 von 1

Veeam Backup -> Performance

Verfasst: 23.08.2011, 19:02
von Login
Hallo,

ich habe heute testweise ein Backup&Replication Standard 5.02 auf einer VM installiert. Nun kommt mir die Backupperformance sehr langsam vor. VMs werden mit max. 22MB/s gesichert. Am Backupjob wurden diverse Konfigurationsvarianten durchprobiert.

Die VM sichert auf eine 1,7TB große VMDK, die als Festplatte an der BackupVM hängt (D:\Sicherungsordner). Die VMs direkt ins Filesystem des ESX-Host zu sichern ergab meiner Ansicht sogar ein schlechteres Ergebnis.

Die Umgebung:

- ESX 4.1
- iSCSI-Storage (HP P2000 MSA) über 2x 1GBit active/active in Multipathing-Mode (ALUA)
- Jumboframes
- 4 iSCSI-Kernels mit eigenen IP-Netzen an Software-iSCSI-HBA gebunden, über 4 pNICs
- Source-VMs auf 1. und 2. LUN mit 1MB Clustern
- BackupVM auf 3. LUN mit 8MB Clustern
- Lungrößen < 2TB

Und soll das so sein, dass die VM-NIC im Taskmanager konstanten Traffic wären des Backups anzeigt (1,5-2% bei einer 10Gbit vNIC)?

Hat jemand eine Idee? Oder Werte aus einer ähnlichen Umgebung?

Viele Grüße,
Conne

Verfasst: 23.08.2011, 19:55
von JMcClane
Wie viel RAM und vCPU hat die VM? Welches Betriebssystem und ist es sinnvoll Backups

a) in eine VMDK zu schreiben an die man nicht mehr dran kommt wenn ESX kaputt und
b) die Backups auf das gleiche Storage zu legen, wo man auch nicht mehr dran kommt wenn es kaputt ist.

Wie ist das Storage denn bestückt und wie die LUNs geRAIDed?

Verfasst: 23.08.2011, 20:18
von Login
- 2 vCPUs
- 6GB RAM
- Server2008R2

Storage:

- 2x Raid5 aus 10 Platten + 2HS Platten
- SAS01: LUN 1,4TB, 1MB Clusters
- Sata01: LUN 1,8TB, 1MB Clusters
- Sata02: LUN 1,8TB, 8MB Clusters

Einwand a) und b) dankend angenommen, doch aktuell technisch nicht anders lösbar :-(

Gruß,
conne

Verfasst: 23.08.2011, 20:38
von continuum
hast du es mal ohne Jumboframes probiert ?

hab neulich noch eine Untersuchung gesehen nach der iSCSI per jumboframes nur dann Sinn macht wenn bei allen Beteiligten Geraeten die selbe mtu verwendet wird

Verfasst: 23.08.2011, 20:43
von JMcClane
Sind die 2 vCPUs voll ausgelastet beim Backup? Sind die Werte für ein Full-Backup?
Backupmethode ist Hot-Add?

Verfasst: 23.08.2011, 21:18
von Login
@continuum: Jumboframes ist für den iSCSI-Weg durchgehend mit MTU9000 aktiv. Das VM Network ist nachwievor MTU1500.

@JMcClane: die vCPU sind nicht viel ausgelastet! Und ja, hier gehts um das erste FullBackup. Was meinst du mit "HotAdd"?

Im Job ist "Direct SAN Access" aktiv, die VMs sind während der Sicherung an!

Verfasst: 23.08.2011, 21:27
von JMcClane
Ja, genau an der Stelle. Statt DirectSAN den HotAdd Mode nehmen, wenn Veeam als VM läuft. Dann werden die virtuellen Festplatten direkt an die Backup-VM gehängt und es muss nicht erst noch der iSCSI-Stack 2 mal durchlaufen werden.

Verfasst: 23.08.2011, 21:27
von continuum
guck mal in veeam unter jobs - dann doppelklick den Job von dem wir sprechen und poste was unter VM summary und Job summary steht

Verfasst: 23.08.2011, 21:40
von Login
job summary:

6 of 6 VMs processed (2 failed, 0 warnings)

Total size of VMs to backup: 623,83 GB
Processed size: 247,83 GB
Processing rate: 30 MB/s
Start time: 23.08.2011 17:49:28
End time: 23.08.2011 20:08:51
Duration: 2:19:23

VM Summary:

5 of 5 files processed

Total VM size: 33,92 GB
Processed size: 33,92 GB
Processing rate: 21 MB/s
Backup mode: SAN/NBD with changed block tracking
Start time: 23.08.2011 19:11:36
End time: 23.08.2011 19:38:34
Duration: 0:26:58


Unter den Advances Options habe ich den Failover-Haken grad mal rausgenommen -> Job schlägt fehl. Er kann also im Moment nur übers VM-Lan sichern und ist deswegen so langsam?

HotAdd kann ich nicht sehen. Statt dessen: Direkt SAN Access, Virual Appliance und Network.

Auf der SicheurngsLUN (Sata02) sind auf dem Datastore noch knappe 100GB frei. Kann das ein Problem bei dem HotAdd Mode werden?

Verfasst: 23.08.2011, 21:50
von continuum
Veeam versucht den normalen Netzwerkmodus wenn Plan A fehlschlaegt - das erhoehy die Gesamtzeit natuerlich.

Du solltest als erstes herausfinden warum/ welche 2 VMs nicht gebackupt werden koennen

Verfasst: 23.08.2011, 21:56
von Login
Ok, mittlerweile ist es nur noch eine vm die nicht klappt. da hängt eine 256gb gro0e vmdk dran, die wohl probleme macht. Ich werde sie gegen eine 250gb große tauschen.

Was sagst du zur Geschwindigkeit? Schon etwas wenig oder?

Und ier der Fehler:


0 of 0 files processed

Total VM size: 316,00 GB
Processed size: 0,00 KB
Processing rate: 0 KB/s
Backup mode: HOTADD without changed block tracking
Start time: 23.08.2011 21:41:38
End time: 23.08.2011 21:42:40
Duration: 0:01:01


Freezing guest operating system
CreateSnapshot failed, vmRef "112", timeout "1800000", snName "VEEAM BACKUP TEMPORARY SNAPSHOT", snDescription "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False"
File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>

Verfasst: 23.08.2011, 22:18
von irix
Login hat geschrieben:...
File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>


Es kommen Datestores mit unterschiedlichen Blocksize Werten zum Einsatz und das tut natuerlich nicht wenn der Snap auf dem mit der kleinsten Blocksize liegt.

Gruss
Joerg

Verfasst: 23.08.2011, 22:33
von Login
die BackupVM liegt auf nem Dtastore mit 8MB Blöcken, die anderen beiden 1MB. Das sollte doch passen. Die VM wird im Moment gesichert, ich habe die Platte tatsächlich nur gegen eine in 250 GB getauscht, Er kam wohl nicht mir den 256gb klar...

Verfasst: 23.08.2011, 22:38
von irix
IIRC hatten wir das hier schon ein paar mal das es wohl 256GB - XX MB sind.

Gruss
Joerg

Verfasst: 23.08.2011, 23:35
von continuum
Probier mal die Methode "Virtual Appliance" statt "Direct SAN ACCESS"

hier bekomme ich fuer Direct SAN ACCESS aehnlich geringe Werte - fuer Virtual APpliance hingegen deutlich bessere

Verfasst: 24.08.2011, 15:24
von Login
Jepp, mit Virtual Appliance scheint es besser zu laufen und sich kann auch keine Auslastung des TCP/IP Stacks mehr feststellen.

680GB FullBackup in ca 2h15min ist ja mal ganz passabel, es lebe der Dedublizierungsspeicher!!

Euren Aussagen nach sind 20-30MB/s Übertragungsrate in meiner Konfiguration nicht unnormal, sehe ich das richtig?

Danke euch für eure Unterstützung!

Gruß,
Conne

Verfasst: 24.08.2011, 21:20
von continuum
Ich kriege hier die 20 - 30 Mbs mit der SAN methode aber auf Ultra-lowend -storage ;-)
d.h . hier habe ich den billigsten HP proliant und eine billig 1TB SATA Platte am Onboard -controller

aber solche Werte sind auch schwer zu vergleichen - das haengt von so vielen verschiedenen Faktoren ab - wie Inhalt der VM, Veeam-config ...

Was machst du denn eigentlich mit deinen backups nachdem sie in der VM gelandet sind ?

Verfasst: 25.08.2011, 08:27
von Login
ein LowEnd Storage habe ich in dem Fall nicht beim Kunden stehen, ist immerhin eine HP P2000 MSA mit 22 Platten. Aber ich weiß... HighEnd ist was anderes ;-)

Ich denke, in meinem Fall ist einfach das RoundRobin über die beiden GbitE der Flaschenhals.

Kann denn am Veeam Job noch was gedreht werden, um die bestmögliche Performance zu erreichen?

Im Moment liegen die Backups einfach zur Datensicherung vor, auch um eine gewisse Vorhaltezeit gewährleisten zu können. Im weiteren Schritt habe ich vor, die Veeam Backups per Agent wöchentlich auf ein LTO zu kopieren, um die Daten auch außer Haus zu haben.

Gruß,
Conne