Questions on Veeam VM using iSCSI

[timofcourse]

Hi all
Im setting up a new Veeam installation on a Windows 2012 R2 VM. We have a PowerVault MD3220i iSCSI SAN with 2 LUNs - 1 used for production VMs and 1 to use exclusively for Veeam Backups. The SAN is configured on a separate network (10.20.3.x) from our VM Management Network (10.7.7.x).

Based on the numerous articles I've read around (and referenced) here I realize the Veeam Backup server should have direct access to the LUN used for backup storage rather than using a VMFS datastore on that LUN.

My primary question is because we use a separate network for our SAN traffic, what is the best way to expose that network (and corresponding iSCSI targets) to the Windows backup server? Should I just add a 2nd vNIC to the Backup VM or is there something else that's preferred?

Please let me know if you need more info regarding our environment to best answer this.

Thanks in advance!

[timofcourse]

After a bit of digging, I think Ive answered my own question, but would love for someone to verify...

As part of our iSCSI setup, we have 2 VMKernel Adapters configured on a single vSwitch thats for dedicated SAN traffic. It looks as though all I need to do is add a Port Group to this vSwitch, then add a vNIC thats configured to that Port group network to the Veeam backup server VM. I have then assigned an IP address on the SAN network range and able to access the SAN/LUN through the Microsoft iSCSI initiator. In fact because our SANs are configured for 2 separate subnets, I've added 2 port groups/vNICs so the VM will have access to both networks.

Again, would love confirmation this is all "by the book" as Im still getting my feet wet in this area.

Thanks again!

[timofcourse]

Well, something is definitely wrong.

I added the port groups/nics as previously described, added the backup repository drive via MS initiator, verified all SAN luns (VMFS and the backup lun) are exposed to the server via Disk Management. Then brought the backup volume online, formatted NTFS and added to Veeam as a backup repository.

Backup jobs to this max out at 5-7MB/s with 99% processing at the source.

I also performed an ATTO test with the following results which appear to be pretty slow as well...


Hope someone can shed some light on what Im doing wrong here...

[Vitaliy S.]

Backup jobs to this max out at 5-7MB/s with 99% processing at the source.

Looks like you are doing everything correct, but can you please tell me what were your previous backup job rates and bottleneck stats? What performance do you have if you choose to write data to the virtual disk of the backup server? Also what backup mode are you using network or direct SAN (need to have VMFS LUNs present to the proxy)?

[timofcourse]

Looks like you are doing everything correct, but can you please tell me what were your previous backup job rates and bottleneck stats?

We've recently revamped our VM environment. Previously our Veeam Backup server VM was backing up to an RDM that was on the backup LUN we're using now. This was using network backup and we averaged around 25MB/s and load averaged Source: 55-65% > Proxy 35% > Network 26% > Target 50-60%.

Since this setup we have setup a new Veeam environment (basically starting from scratch) in the configuration mentioned in the OP. In addition we've also made a handful of other changes to our VM environment including adding additional paths between SAN and hosts, using hardware iSCSI adapters instead of VMware Software adapter and configuring round robin on the multiple paths.

What performance do you have if you choose to write data to the virtual disk of the backup server?

Not sure exactly what you're asking for here. The ATTO benchmark posted previously was run on the backup server against the new backup repository.

I also created a repository on the Veeam server system drive (which is a vDisk on our production SAN). This ran in network mode and averaged 25MB/s with Load at Source 99% > Proxy 7% > Network 0% > Target 0%.

Also what backup mode are you using network or direct SAN (need to have VMFS LUNs present to the proxy)?

With our new setup our backups are using direct san as we have all VMFS LUNs (in addition to the backup lun) presented to the Veeam Backup server.

I also ran a backup in network transport mode to the backup repository and processing rates average 30-40MB/s with load around Source 99% > Proxy 10 % > Network 0% > Target 0%. Finally, Virtual appliance mode always seems to fail over to network mode in this setup. Not sure what this means as honestly I haven't looked much in to appliance mode to know how it works.

Let me know if theres any other info I can provide.

Thanks again!

[Vitaliy S.]

Tim, it appears that it doesn't matter how you present your target repository, as source storage is always the bottleneck, the reason for this could either storage firmware or MPIO software. In order to make hotadd backup mode work, you need to install virtual proxy server and place it on the host which has access to all datastores where you backup the VMs from. Let's check what performance rates you will have with hotadd backup configuration.

[timofcourse]

The current config is a single Veeam B&R server VM and is located on a host with access to all data stores. So adding a proxy VM should make a difference? Again, while I've read a bunch Im still learning a bit so just want to have a better understanding of these more advanced setups. From what Ive read it seemed the primary reasons to use proxies is to get the processing closer to source/target and/or to offload processing from the primary B&R server.

Finally, if we do setup the separate proxy, does the proxy VM need to be configured similar to what I mentioned in the first couple posts where the SANs are added via Microsoft iSCSI initiator so that VMFS luns are presented to the proxy?

Thanks again!

[Vitaliy S.]

The current config is a single Veeam B&R server VM and is located on a host with access to all data stores. So adding a proxy VM should make a difference?

Not really, but I do not understand why your current proxy server fails over to the network mode. You can investigate this further by looking through the logs with our support team.

From what Ive read it seemed the primary reasons to use proxies is to get the processing closer to source/target and/or to offload processing from the primary B&R server.

Yes, that's correct. You can distribute the load among multiple proxy servers and offload your backup server that can be installed on any machine.

Finally, if we do setup the separate proxy, does the proxy VM need to be configured similar to what I mentioned in the first couple posts where the SANs are added via Microsoft iSCSI initiator so that VMFS luns are presented to the proxy?

No, it shouldn't. HotAdd proxy is easy to setup, please check out this topic for more info. Anyway, the reason why I have asked you to try hotadd proxy is to compare job performance numbers with direct SAN mode. Currently, it doesn't matter how you present your repository to the backup console, source data retrieval performance matters here.

Try to disable MPIO (if you have it deployed) and see what job rates you will have.