Veeam - 3par - vvol

[Shane_John]

Hi,
Currently upgrading our vsphere storage to a 3par 8200, Our infrastructure is relatively small in size, 4 vpshere hosts, Dual HP SN3000 san switches, 1 physical Veeam backup server, MS 2040 and 8200 3par.
Main reason for the upgrade is to take advantage of the vvol technology which offloads the snapshots to the 3par and with this the snap/delta is the source for the backup job not the actual VMDK.
We have a number of large VM's which are taking an age to consolidate the deltas back to the VM, the largest VM is 20tb, the release of the snapshot is causing issues for users.
I understand the limitation where vvols cannot be backed up using direct san connection.
Does anyone have any advice on the best method of backup, ie HOTADD, NBD, Proxy

[foggy]

Hi Shane, hotadd is generally more preferable than NBD. Proxy is a component performing data processing, not transport mode.

[EugeneK]

hotadd is my personal preference as well, but if for some reason it's not an option, a robust network (10Bgps+) + NDB would do. With hotadd the only caveat is to make sure the there's no connection drops between VBR and vsphere environment, otherwise you may get a disk "stuck" mounted to another VM rfor backup purposes, but not removed due to the interruptions during the process.

[dellock6]

I did all my tests against vvol using nbd on purpose:
http://www.virtualtothecore.com/en/back ... are-vvols/

and as you can see , speed with 10GB links using nbd are not bad at all. That said, hotadd is still a lot faster than nbd even on 10gb network, so it possible I'd stick with hotadd. Whatever is the choice, you are going for sure to see a huge improvement in snapshot commit time, in my test with a vm making 4000 iops, commit over vmfs was 27 minutes while it was only 5 seconds over vvols.

[NightBird]

Why not use storage snapshot integration and stay away from vvol ?
I push between 1.2-1.6GB/s from a 3par 8200 with 12x1,92 ssd with direct san mode

[Shane_John]

Thanks everyone for their answers.
Further to my initial question, when using hotadd my understanding is the veeam proxy mounts the guest vm's disks and backs them up, is this proxy sending the backed up data over the network to the storage repo?
And if my storage repo is local to the veeam server, direct attached, is this not causing a major botteneck for all backed up data regardless of the backup transport method.

[foggy]

Further to my initial question, when using hotadd my understanding is the veeam proxy mounts the guest vm's disks and backs them up, is this proxy sending the backed up data over the network to the storage repo?

Correct, if the repository is not local or directly attached to the proxy.

And if my storage repo is local to the veeam server, direct attached, is this not causing a major botteneck for all backed up data regardless of the backup transport method.

Not sure I fully understand the question.

[Shane_John]

Re phrase question - HOTADDing (proxing) can only work effectively when the repo is attached locally to itself? - Is this stated in veeam proxy deployment guide? You could have 10 proxies utilising hotadd but with out repos attached they are effectively the same as network mode. I understand HOTADD utilises the resources on the PROXY server to speed up the backup process however if the repo is attached to the VEEAM Server the speed of the LAN connection is still a critical factor in the total overall time of the backup job.

[dellock6]

Hi Shane,
let's rewind a bit: hotadd processing mode can only be done when the Veeam proxy is a virtual machine. This is because it has to mount as a temporary secondary disk the original disk of the protected virtual machine.
From here, data has to be sent over to the repository, this can be:
- a locally attached disk, but then it means that the disk is coming from a volume that is connected also to the underlying ESXi server and presented to the proxy VM as a raw disk or a vmfs volume
- a remote volume over the network, be it a iscsi volume mapped in-guest in the proxy vm, or a secondary machine working as a dedicated repository, running the veeam datamover component

In the latter, data has to exit the vsphere environment via network, using the VM network. You can plan to have dedicated networks for this purpose (so called "backup network") or use the same network of other VMs, this is totally depending on your environment, but Veeam has no preference on this part of the design. I'd personally stay away from the first option, too complicated and too many layers of software managing that volume before it arrives to the VM.

[DanielG]

Hi Shane,
Here is an example. We've been using hardware snapshots with the 3PAR for few years now (don't remember the model). We don't use vvol's. For that particular environment when we have the 3par (a source) we use a "cheap" target storage connected to an old HP pizza through SAS. The HP server acts as Veeam proxy/repo and connected to the 3par through FC (otherwise HW snapshots won't work ). You can also use iSCSI. First Veeam creates a VMware snapshot and 10-20 seconds after removes the snapshot, so you have a very little delta to commit back. Then it pools the data from the 3par directly trough FC/iSCSI. In the end it removes a hardware snapshot and this operation is not so heavy as the native hypervisor snapshot removal. This processes uses Direct SAN method and does not involve HOTADD or NBD.

We have another similar environment which has more powerful "expensive" target storage, which also acts as a veeam proxy/repo (all-in-one). That target storage runs Microsoft's Storage Spaces and connected to the source server (VNX) through FC as well.

When we restore VMs the traffic also goes trough FC or iSCSI network, which is nice.

So hardware snapshots solve the issue with the long and impacting performance snapshots. The thing that you still need to keep in mind (just a friendly advise) and we see it all the time, countless examples is the - latency issues. I'll give you a little example. Let's say we have the 3par as the source and we do NOT use hardware snapshots. Veeam proxy runs on a VM and transfers the data using HotAdd method or though LAN (NBD). During the consolidation process the latency of a particular LUN as well as the entire disk pool is sucks (sometimes we see funny figures 200-300ms ).
Now we get a new FC or iSCSI storage with tons of drives to act as Veeam repository. That storage has 8-10Gb HBAs. We enable hardware snapshots and solve "long consolidation" issue. However you may get into a different trouble. 3par may have 8/16Gb HBAs and our target storage 8/16Gb or higher. So we may saturate the source storage (3par) too much (even using hardware snapshots) because the connection to the target storage is fast and the target storage might be faster than the source. So the simplest thing to do to overcome this issue is to set/adjust latency control and number of concurrent tasks in Veeam.
Hope this make sense.

Daniel