HOTADD faster than SAN transport ...

[Didi7]

Hello guys,

strange situation here. I noticed that HOTADD transport protocol is faster than SAN transport in one of our environments. Storage is a NetApp FAS8020 connected 4x with 10GBit/s Ethernet to a Cisco Nexus switch. I have one VBR 9.5 U2 server running on Windows Server 2012R2, equipped with one 10GBit/s interface into the iSCSI network, which runs over the Cisco Nexus switch.

If I use SAN transport, I get around 235MB/s throughput rate using the VBR server as proxy allowing 1 concurrent task and a repository limited to 1 task.

When I use HOTADD transport (Hotadd proxy is a Windows 2012R2 Server with 4 vCPUs, 4GB RAM and a vNIC with 10GBit/s), I get around 470MB/s throughput. Proxy and repository are limited to 1 concurrent task here as well.

Anybody else with such a behaviour?

Regards,
Didi7

[foggy]

Should be a result of introducing advanced data fetcher in v9.5, which reads asynchronously via hotadd.

[Didi7]

Hello foggy,

very interesting! As far as I understand, SAN transport does not profit from this 'Advanced data fetcher'?

On SATA disk I have throughput of 60Mb/s using SAN transport (Bottleneck Source) and around 300Mb/s using HOTADD transport mode (Bottleneck Source).
On SAS disk I have throughput of 275Mb/s using SAN transport (Bottleneck Source) and around 470Mb/s using HOTADD transport mode (Bottleneck Proxy).

The Test-VMs have thin disk. Might I get better throughput using SAN transport mode, if disks are all THICK?

Regards,
Didi7

[foggy]

Right, direct SAN is not affected and I don't think thick disks will take any effect (still, CBT is used).

...around 470Mb/s using HOTADD transport mode (Bottleneck Proxy).

Btw, you could get a bit more here if you upgrade the proxy (CPU).

[Didi7]

Right, direct SAN is not affected and I don't think thick disks will take any effect (still, CBT is used)

In fact, it is slower with Thick disks

Means, HOTADD is the way to go. Awkward, if you ask me. NetApp sucks!

Regards,
Didi7

[tsightler]

Means, HOTADD is the way to go. Awkward, if you ask me. NetApp sucks!

It means that HOTADD "might" be the way to go if single stream throughput of a full backup is the most critical deciding factor. However, it's important to note that hotadd may be significantly slower for incremental runs since it has much more overhead and much more time is spend performing the hotadd/hotremove functions.

[jmmarton]

It's also worth noting that since NetApp FAS is the underlying storage, BfSS is another option (with Enterprise Plus licensing) and that takes advantage of the new Advanced Data Fetcher, just like HotAdd. That may give you better performance than other Direct SAN (without storage snapshots) or HotAdd.

Joe

[Didi7]

Exactly jmmarton,

that's why I am planning the new backup solution in our datacenter with Enterprise Plus Edition licenses to still use SAN transport and make backups from Storage Snspshots or snapmirrored volumes.

I am wondering, if I need to reserve snapshot space on my NetApp volumes (where the LUNs reside) for Veeam initiated snapshots and if yes how much percent is recommended or is this done automatically, as long as there is enough space in a NetApp volume, because snapshots are discarded automatically, when Veeam backup ends?

Would be nice to know, as I have no experience with backup from Storage Snapshots (NetApp) so far, but it sounds great.

Thanks

[foggy]

I am wondering, if I need to reserve snapshot space on my NetApp volumes (where the LUNs reside) for Veeam initiated snapshots

You need to follow the recommendations from storage vendor here (and keep data change rate inside VM in mind).

[Didi7]

Hello foggy,

soon I will deepen my knowledge with an iSCSI test lun located on a NetApp volume to experiment with VBR backup jobs using storage snapshots on a NetApp FAS8020. So far, there is no snapshot space configured for this iSCSI test lun and I will see, what happens, if I backup VMs from this lun using storage snapshots in VBR only.

I am looking forward to see, what kind of transfer speed I can reach using SAN transport on this iSCSI test lun using storage snapshot in combination with Advanced Data fetcher technology from VBR.

Thanks again.

Regards,
Didi7