+1Hello,
I have backup copy job to copy the bcckup to Azure File share. The VBR main repository using SMB and connection speed is 1Gbps. Connection from VBR to Azure file share via VPN site to site with 100Mbps internet bandwidth.
What can i see is my internet utilization is still low, only about 20-30Mbps used. Is there any trick how to utilize the connection?
Best answer by MicoolPaul
Hi, is it to Azure file share or object storage? You’re more likely to hit a bottleneck sending the traffic via VPN than over WAN so is this a security requirement that can’t be satisfied with only permitting specific public IPs to access the storage? Depending on how fast you want to send data to the cloud you could look at Expressroute as an alternative to VPN if it must go via a private network. Otherwise you’ve got to make sure both sides of the VPN have sufficient performance for the throughput required.
Aside from the VPN, you’ve mentioned you’re using SMB to your primary backup storage. This is by far the slowest and least reliable of the available storage options so if you have the ability to move to something like DAS, or iSCSI/FC or even NFS is better IMO. Assuming it’s your VBR talking to both SMB and Azure storage. Your VBR server has to fetch the backup data via SMB over your network, which means no multipathing or anything to optimise performance, and then send that over the network to Azure via the VPN. If you’re using DAS or a dedicated storage network then your VBR server isn’t utilising its production network-facing bandwidth to both fetch data and then send data onwards, this can optimise transfer times.
I do want to know if you are using Azure as a file share via SMB instead of as an object storage repository as this has dramatic performance implications and file size limitations.
+23Hi, is it to Azure file share or object storage? You’re more likely to hit a bottleneck sending the traffic via VPN than over WAN so is this a security requirement that can’t be satisfied with only permitting specific public IPs to access the storage? Depending on how fast you want to send data to the cloud you could look at Expressroute as an alternative to VPN if it must go via a private network. Otherwise you’ve got to make sure both sides of the VPN have sufficient performance for the throughput required.
Aside from the VPN, you’ve mentioned you’re using SMB to your primary backup storage. This is by far the slowest and least reliable of the available storage options so if you have the ability to move to something like DAS, or iSCSI/FC or even NFS is better IMO. Assuming it’s your VBR talking to both SMB and Azure storage. Your VBR server has to fetch the backup data via SMB over your network, which means no multipathing or anything to optimise performance, and then send that over the network to Azure via the VPN. If you’re using DAS or a dedicated storage network then your VBR server isn’t utilising its production network-facing bandwidth to both fetch data and then send data onwards, this can optimise transfer times.
I do want to know if you are using Azure as a file share via SMB instead of as an object storage repository as this has dramatic performance implications and file size limitations.
+1Hi
Yes I use Azure file share as for 2nd copy job and not object storage. Parallel i also raise the ticket to our firewall vendor to make sure is there anything to fine tunning to get more throughput.
+20Hi
Yeah....several things could cause your low performance. Michael pretty much hit on it all. Keep us posted what you find out from your f/w vendor.
+23Was there a technical decision that made you use Azure Files? Microsoft Azure Storage Accounts are only certified for Veeam Backup & Replication in the context of object storage.
Hi,
> Connection from VBR to Azure file share via VPN site to site with 100Mbps internet bandwidth.
7 MB/s == 56 Mbit/s, so I think the monitoring tool is maybe missing some items.
Veeam has no real tweaking for the network connections as it’s beyond the product code -- such network share connections are handled by the OS itself, and Veeam simply sends data to be written.
I would test with Diskspd: https://www.veeam.com/kb2014
You can target a network share with this, just run it on the Veeam server and write a sizeable amount of data (50 GiB I usually recommend). Just watch what happens on the connection.
Almost certainly you are hitting Azure File Share ingress limits: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-scale-targets#azure-file-share-scale-targets
That’s not a lot of IOPs and as I get it, Azure scales this based on load (no idea how they prioritize it)
Basically, I’m pretty sure you’re just fighting Azure File Share limitations here, and there’s not going to be much you can do. I would advise consider seeding the initial full backup and just re-map the backup chain after moving it to your fileshare outside of Veeam -- this will avoid the long production snapshot during the Active Full, and then you should have better performance. Problem is, I would not recommend using any synthetic operations (Synthetic Full, Forever Forward Incremental merge for retention) with such a configuration -- the performance for these operations will be very poor with Azure File Share since the available IOPs are so low and ever write during a synthetic operation will need to be routed first to the gateway server (likely local with your VBR) and then sent back to Azure. This will be a ton of traffic, ingress/egress costs, and very slow performance.
I would really advise follow the advices earlier in this topic and just use an Object Storage Repository in Azure. You avoid the Azure Fileshare limitations, you avoid the needless traffic back and forth for merge operations, you avoid long production snapshots during active fulls as you’re not limited by the Azure Fileshare scaling limits, and you even get Immutability now on your backups.
https://helpcenter.veeam.com/docs/backup/vsphere/adding_azure_object_storage.html?ver=120
I am doubtful you will significantly improve the performance with Azure File Share due to the above, and I think all the considerations there make Object Storage repositories in Azure a better choice.
+1hi
My firewall vendor say try to change the ipsec algo from DES to AES, and this make the connection more better now.
+20That's great to hear. Thanks for sharing what worked for you
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
