Veeam B&R virtual backup server Fujitsu Eternus storage slow

[Bernhard Bergmann]

Veeam is installed inside vm. Eternus DX with NL-SAS-Disks is connected by 8G fibrechannel and capacity is completely assigned to esxi. VM uses this storage for booting (VMDK) and as backup storage (another VMDK) -> i know this is not best practice, i would prefer another approach, too. Decision makers want VM, so i would prefer RDM für backup storage, but also here the decision makers want VMDK.

Whenever a job is running, it starts with usable througput (not really good) and becomes slower and slower after a while. The throughput commutes in about 40 MB/sec. This is only about a tenth of the theoretical value the DX should be able to. A test with a comparable equipped QNAP NAS (same type and amount of hard disks, but connected by 10g iSCSI directly to VM) is much faster.
Benchmarks against the two storages (QNAP and DX) show generally good results, but DiskSpd results show exactly this behaviour after some GB while testing against the DX.

has anyone any idea why this happens only with Eternus DX and not with QNAP ? Any ideas what to do to keep perfomance high(er) all over ?

[HannesK]

Hello,
I recommend to open a case at Fujitsu with the DiskSpd results. They should know what the issue really is.

In general, it is normal that speed goes down: as soon as you filled up the write cache (some GByte) the speed goes down to the level the spindles can do.

Good question why it does not happen to QNAP... maybe different cache settings.

Best regards,
Hannes

[Andreas Neufert]

In your case you read and write to the same storage/disks, which create 2 times the IO maybe more.
My guess is that the controller is saturated and disk latency grow. Please check at vcenter or Veeam ONE.

Anyway creating backups to the same storage is a useless approach and risk your company. I strongly suggest to rethink this approach. Backup for example to the QNAP.

[HannesK]

ah, the VMware environment also runs on the same storage? I did not read that. If yes, see Andreas' answer.

[Bernhard Bergmann]

oh sorry not to give clear informations. The vSphere environment does NOT run on DX, just the boot disk of the backup server. Production storage is a datacore-cluster, DX is exclusively intended for backup.

Fujitsu support is already involved, does not really have a clue what could be wrong, even the configuration support is continuously testing different settings...

The slowdown appears after about 250-300GB written data...

[Andreas Neufert]

Thanks for clarification... Can you please open a support case and work with our support team on it?