Proxy Design Questions

[collinp]

If I have a default proxy server with 2 modern 8 core procs (16 cores total) and 16gb of memory with a 10GB nic and running SAN mode (4 4gb fiber channel paths), is there any reason for an offhost proxy in addition to the default proxy? I am backing up 80 vm's or so a night by chaining jobs. None of the jobs are running concurrently at the moment. Not sure what my bottleneck is in my current situation (CPU, mem, network, san) that would necessitate another proxy. And lastly, when running concurrent jobs, do you need to coordinate jobs so that 2 vm's aren't being backed up at the same time that reside on the same datastore? We keep about 15% free space per datastore. Not sure if 2 simultaneous backups on same datastore would cause snapshots to fail due to free space issues.

[Gostev]

Hi - the default proxy is VMware only, and you have posted this in Hyper-V forum, so can you please confirm what hypervisor you are using? Thanks.

[collinp]

Oh...Forgive me. I am still new to Hyper-v and backing up Hyper-v with Veeam.

I am backing up both VMWare and Hyper-v. VMWare is configured to backup in SAN mode (automatic selection, but it always chooses SAN mode). I am trying to get the Hyper-v role installed on the Veeam Backup server (Microsoft issue, long story) and once I get the Hyper-v role installed, I was assuming I could backup Hyper-v using SAN mode as well from the Veeam backup server?

I guess my questions partain to both hypervisors. Are concurrent jobs with a single Veeam backup server recommended or should they be run over 2 different proxy servers? When running concurrent jobs, should I be careful not to backup 2 VM's on the same CSV at the same time?

[Gostev]

That's right, but you will also need hardware VSS provider installed on your backup server, because you want to leverage SAN snapshots instead of software VSS for Hyper-V backups. This provides multiple significant benefits.

And don't worry about concurrent jobs hitting VM's on the same CSV at the same time, this will not cause any issues. Each VM will be backed up from its "own" volume snapshot anyway.

The max number of concurrent jobs is defined by your offhost backup proxy hardware, you will see those settings when setting up off host proxy. After that, the scheduling engine will take care of not exceeding available concurrency itself, without you having to babysit your jobs schedules.

[collinp]

Just to clarify. I would need a snapshot license on my EMC array in order to use the Hardware VSS Provider. Correct?

[Gostev]

You should check with EMC on that.

[collinp]

I have 10 days left on my trial license. I am still trying to determine if I want to move forward with using Veeam and Hyper-v. It works great with VMWare but I am having some issues with Hyper-v. From reading the user guide, I am not using the recommended backup approach since I am using the Software VSS provider and I am not offloading the processing using a proxy. I am still doing testing and haven't yet forked over the money for a snapshot license. When I come in, in the morning about a quarter of my vm's are powered down and show "missing" under status. I have to repair them all to reassociate the .vhd's to the vm. The system log on the vm's show "unexpected shutdown" during the backup window with not a whole lot of other information. I am trying to figure out if Veeam is causing these shutdowns but after suspending the job last night, there were no more unexpected shutdowns.

I have 2 questions. The first is, will using the Hardware VSS, and offloading via proxy, resolve these unexpected shutdowns? Secondly, can I achieve a Lan free, Direct SAN Access, backup using Veeam and Hyper-v? I don't see a Direct SAN Access option in the Hyper-v proxy options. In VMWare, I have presented the LUNs to both the vmware hosts and the Veeam backup server and I am under the impression that most of the backup traffic goes over the SAN fabric. My bottleneck ratio in VMWare shows 2% for network.

I believe most of these reliability issues are caused by the relative newness of Hyper-v and CSV's, and not an issue with Veeam itself. For instance, I don't think there is anything I can do in Veeam that would take down and corrupt a VMWare virtual machine.

[Gostev]

1. You should have our support investigate the reason for those shutdowns first. Generally speaking, this should not be happening no matter of backup mode or VSS provider used. And I have not heard similar reports either.
2. Yes. Off-host backup mode is essentially the same as VMware direct SAN option.

[collinp]

I will take your word on #2 but I would think that if there was a direct SAN option that Veeam wanted us to know about, I feel like I would see this option in the Hyper-v proxy settings and this would be explained in the Hyper-v user guide.

[Gostev]

The usage of direct SAN access by off-host Hyper-V backup proxy is covered right in the user interface (on the Backup Infrastructure dashboard). But the User Guide could certainly take an improvement here

[collinp]

Has anybody done direct SAN backups successfully in Hyper-v? I am a little nervous about doing this. In VMWare, I can present my vmfs lun to both the vmware hosts and the Veeam proxy server. I see the VMWare vmfs luns in disk management on my Veeam proxy server and make sure that I don't touch them or format them! But I am a little nervous to do this with NTFS. It would mean that my NTFS LUNs would be presented to the Hyper-v Hosts and the Veeam proxy server. Something tells me that NTFS isn't going to like it when I present it to the Veeam backup proxy that isn't a part of a cluster. NTFS wants to be active/passive unless CSV is enabled.

[collinp]

Come to think of it, I don't think a SAN backup is possible with Veeam and Hyper-v. Veeam does say in one place on the Backup Infrastructure dashboard the following:

"Off-host proxy backup provies the ability to offload backup tasks from Hyper-v hosts to the designated server. The proxy server must be connected into the SAN Fabric, and have the Hyper-v role enabled".

But if you think about it, the Veeam host being connected into the SAN Fabric is not enough (unless I am totally missing something which wouldn't be the first time). In order for the Veeam Backup server to see the Hyper-v luns, you have to create a zone between the lun and both Hyper-v hosts and the Veeam backup server. NTFS is not natively a clusterable file system without some type of clustering software. So if the Veeam backup server and the Hyper-v hosts see this NTFS lun at the same time, it may corrupt the file system.

I logged onto EMC powerlink and a few articles confirmed this. Here is another comment I saw on there:

"It is technically possible but not recommended without some sort of clustering software because of the risk of file system corruption. NTFS does not support multiple hosts accessing the same file system simultaneously. If two separate hosts mount the same file system and both try to write to it, it can corrupt the file system."

[Gostev]

Not only possible, but is the recommended way to backup Hyper-V. Of course it is not the same LUN, VSS snapshot is mounted to the off-host backup proxy server as another LUN. VSS snapshot transportability makes it possible > http://blogs.msdn.com/b/adioltean/archi ... 29934.aspx