Hey community, I want to use VBR 11a and VeeamPluginforSAPHANA to backup my SAP HANA database.Howerver, the test result is not ideal, Processing rate is only 1M/s.
In my environment, the bandwidth between the VBR server and the HANA server is 10Gbps, and I have tested it with iperf3, everything is OK. and when I use VBR to backup VMs and NAS, everything is OK too. I also tried to set up different repositories using SapBackintConfigTool, but it doesn't work.
What could be the reason? tks.
Best answer by StefanZi
Hi
When the plugin communicates to the repo it will ask for all available IPs and tries them in the order returned. So let’s say you have two IPs on the repo: 192.168.100.100/24 and 10.10.100.100/24 and the traffic should flow over the 10. network.
If the returned IP list is [ 192.168.100.100, 10.10.100.100 ] the HANA plugin tries the first IP first. That traffic might flow via the default GW, blocked by some FW and the system does not get any response back, so it will wait for a timeout to happen - that takes a long time.
Only when these timeouts happened the plugin will try 10.10.100.100 and will connect to the repo and transfer the files.
It looks like your job is exactly this (because theres a long time nothing happening).
If this describes your environment, please try to configure preferred networks in Veeam Backup & Replication.
So for above example, you prefer 10.10.100.0/24 as a network and the returned IP list for the repository will be ordered [ 10.10.100.100, 192.168.100.100 ]. That way the plugin will directly connect to the repo and the job duration will be smaller.
+3Hi
When the plugin communicates to the repo it will ask for all available IPs and tries them in the order returned. So let’s say you have two IPs on the repo: 192.168.100.100/24 and 10.10.100.100/24 and the traffic should flow over the 10. network.
If the returned IP list is [ 192.168.100.100, 10.10.100.100 ] the HANA plugin tries the first IP first. That traffic might flow via the default GW, blocked by some FW and the system does not get any response back, so it will wait for a timeout to happen - that takes a long time.
Only when these timeouts happened the plugin will try 10.10.100.100 and will connect to the repo and transfer the files.
It looks like your job is exactly this (because theres a long time nothing happening).
If this describes your environment, please try to configure preferred networks in Veeam Backup & Replication.
So for above example, you prefer 10.10.100.0/24 as a network and the returned IP list for the repository will be ordered [ 10.10.100.100, 192.168.100.100 ]. That way the plugin will directly connect to the repo and the job duration will be smaller.
+8Hello,
Could you specify the % of your bottleneck? Source? Is it a same time to do the backint on local machine?
The processing rate is an average of your jobs, you should more consider “the speed” . We’re not using this plugins in my company for the moment but if it’s the same as RMAN, there is a lot checks did by RMAN before sending data. Maybe check logs of your running jobs in “%programdata%/veeam/backup”?
Hi
When the plugin communicates to the repo it will ask for all available IPs and tries them in the order returned. So let’s say you have two IPs on the repo: 192.168.100.100/24 and 10.10.100.100/24 and the traffic should flow over the 10. network.
If the returned IP list is [ 192.168.100.100, 10.10.100.100 ] the HANA plugin tries the first IP first. That traffic might flow via the default GW, blocked by some FW and the system does not get any response back, so it will wait for a timeout to happen - that takes a long time.
Only when these timeouts happened the plugin will try 10.10.100.100 and will connect to the repo and transfer the files.
It looks like your job is exactly this (because theres a long time nothing happening).
If this describes your environment, please try to configure preferred networks in Veeam Backup & Replication.
So for above example, you prefer 10.10.100.0/24 as a network and the returned IP list for the repository will be ordered [ 10.10.100.100, 192.168.100.100 ]. That way the plugin will directly connect to the repo and the job duration will be smaller.
Hi,
Back to my production environment, VBR have two IPs, one for the management network [ 192.168.100.100] , and the other for the storage network [10.10.100.100] which don’t have GW . My storage device uses NFS protocol to provide datastore to ESXi hosts, so I used ‘Direct NFS Access’ mode and specifying preferred networks to the storage network.
However, I can’t modify the preferred networks, because there are a lot of VMs need to backup. Now, I think there are two ways to try:
1.Set up a new environment to backup SAP HANA, which have no problem;
2.Add an interface to HANA server, and configure an IP address in storage network, need to test.
Do you have any suggestion?
+3Hi,
Back to my production environment, VBR have two IPs, one for the management network [ 192.168.100.100] , and the other for the storage network [10.10.100.100] which don’t have GW . My storage device uses NFS protocol to provide datastore to ESXi hosts, so I used ‘Direct NFS Access’ mode and specifying preferred networks to the storage network.
However, I can’t modify the preferred networks, because there are a lot of VMs need to backup. Now, what I can do is to set up a new environment to backup SAP HANA.
Do you have any Suggestion?
Preferred network will only come into play when Veeam components talk to each other. So even without this setting on the storage network your Direct NFS access will be fine. Basically we ask vCenter for the NFS datastores and we get back something like: 10.10.100.101:/vsphere and we will try to reach this from the proxies, so with the direct connected network that will still work perfectly.
So you can configure the preferred network to be the 192.168.100.100 which is reachable from your SAP system and you’ll be fine.
If you don’t want to touch the preferred networks, just make sure that if the SAP system tries to reach the 10.10.100.100 it get’s a proper not accessible message as fast as possible, e.g. by blocking access on a firewall (not dropping the package, but really blocking it) - can be the host firewall or the network firewall.
Hi,
Back to my production environment, VBR have two IPs, one for the management network [ 192.168.100.100] , and the other for the storage network [10.10.100.100] which don’t have GW . My storage device uses NFS protocol to provide datastore to ESXi hosts, so I used ‘Direct NFS Access’ mode and specifying preferred networks to the storage network.
However, I can’t modify the preferred networks, because there are a lot of VMs need to backup. Now, what I can do is to set up a new environment to backup SAP HANA.
Do you have any Suggestion?
Preferred network will only come into play when Veeam components talk to each other. So even without this setting on the storage network your Direct NFS access will be fine. Basically we ask vCenter for the NFS datastores and we get back something like: 10.10.100.101:/vsphere and we will try to reach this from the proxies, so with the direct connected network that will still work perfectly.
So you can configure the preferred network to be the 192.168.100.100 which is reachable from your SAP system and you’ll be fine.
If you don’t want to touch the preferred networks, just make sure that if the SAP system tries to reach the 10.10.100.100 it get’s a proper not accessible message as fast as possible, e.g. by blocking access on a firewall (not dropping the package, but really blocking it) - can be the host firewall or the network firewall.
That’s great! Thanks very much for your help to solve my problem.
After I configure the preferred network to be the 192.168.100.100 which is reachable from SAP HANA server, VMs backup still use NFS ( I confirm this in veeam statistics and taskmgr-performance-Ethernet), and HANA databases backup works well too.
Have a nice weekend!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
