[Feature Request] Proxy and Repository Zoning

[PaulJGamma]

One thing I would like to see implemented for large multi-site installs, would be when creating Proxies and Repos you can Zone them off in a logical container. Not only would it make it easier selecting the correct resource for the job but when linking jobs and moving replicas to different sites you would pre-set the Proxy on the source Zone and destination Zone. That way you aren’t looking through lists at the point of creating the job. Just link Zone A to Zone B.

Also putting the repositories in the Zones you can set what is the main primary fast backup storage for that Zone and what is cold Storage as well. So when creating backup copy jobs, you just select the Zone and it prepopulates with your preferred storage types for primary and secondary. You could also force certain backup types and job configuration at the Zone level to keep consistency. Like the email global setting but this would only apply to that Zone or Zones.

Also you could tailor the Zone to use whatever method of transport you are using. Some sites might not have a physical proxy and you can pre-set the transport to Hotadd or NDB, so when adding some VM proxy machines in they are set how you want them. Or it could be you only want to use NBD due to a fast 10GB backbone, one container set to only use NDB and you can just throw your VM's in, no need to go and edit each one.

Thoughts?

Paul

[DeadEyedJacks]

+1 on being able to group proxies by site and just define a proxy group within jobs.

[nitramd]

+1 would be most helpful.

[richardkraal]

+1 on being able to group proxies by site and just define a proxy group within jobs.

+1

[DaveWatkins]

There have been various requests for this that I've seen in the last couple of years always with slight variations but any of which would probably work for what we're all trying to achieve. For me just having proxies be "site specific" in some way would be enough. Even if Veeam looked up AD Sites and Services sites to determine the local proxy if a subnet didn't match would work for me. Having actual groups would also work.

Just something to stop Veeam going to an offsite proxy

[Gostev]

Couple of comments/questions.

First, how is this different from Proxy Affinity feature of 9.5? Not from the perspective of implementation (how you see this feature in UI), but from the use case perspective. Because from the UI perspective, of course I will exhaust all my options before adding the totally new concept of "Zones" for our users to deal with. We don't want to become another CommVault in terms of complexity

@DeadEyedJacks ability to group proxies is something we do plan to add, in fact this was originally planned for 9.5 - but eventually I've decided to instead use the same dev resources to build Proxy Affinity functionality instead. Not that the latter completely replaces the need for proxy groups, but it certainly allowed us to address much more scenarios than proxy groups alone would.

[DaveWatkins]

My understanding of proxy affinity is that it ties proxies to repository servers. In my case I have a single repository server in our DR site with 1Gb WAN links to all our other sites.

Setting up proxy affinity doesn't get me anything in that scenario. Being able to have some way to tell a job that these VM's are on this site and should only use this/these proxy/proxies that are on the same site without having to have jobs for every site is what I'm after

[DavidReimers]

+ 1 to this.

95% of the VMs we back up are at one site, where hotadd works fine.
We have a proxy at a second site (will be used for replication eventually) and I want to be able to use that for that 5% of VMs we back up at the second site.

[veremin]

If it is a proxy, why not to tie jobs to this proxy server, instead of allowing them to select proxy automatically? Just wondering.

[PaulJGamma]

So I would see this in the UI as Zones appearing under Proxies and Repository’s. When you create your first zone you Label it. So as an example Zone A or The Datacentre name.

You then add the Proxies and repository’s in this Zone and set the primary proxies and repository’s against it.
The proxies can be ordered in this Zone by connectivity and resources so that the machine with the best set of resources and connectivity are chosen for the job. This can be edited after the fact if need be.
You could also tier the storage into primary and secondary. Useful when doing backup copy jobs.
You can also set a Wan accelerator against it if need be.

This would also include the VMware datacentres and the included clusters or just the clusters.
The Same would be repeated for any other data centres you have. So when you select the Vm you want to be backup it pre-populates all of the above in the job and sets the defaults on the jobs.

Also another idea is disabling jobs by zone so you can run maintenance processes without the backups contesting for resources while migrating MV’s and bouncing hosts. This would leave your other sites running their backup processes while the zone you are working on is not smashing hosts and storage for VM reconfigurations and snapshots.

The main Idea of this is if you have a lot of different VM/physical resources in your Veeam environment you can group them together and manage them at a higher level. If you have multiple datacentres and one Veeam B&R instance running these sites you can easily and rapidly create, edit and manage interconnected parts of the system.

So the configuration of a Zone would include.
•Proxies (setting backup proxies for direct access, nbd, hot add and which proxy to use to leave the zone via replication)
•Repository’s (setting the storage to a zone means you can’t use it for another zones backup)
•Vcentre Datacentres/clusters
•HyperV clusters
•Wan Accelerators
•Email settings

I am sure i have missed things off here but i hope you get the general gist of this. Its not going ot be much use to any one with single sites. But multisite business's will be able to pre configure these zones and apply maintinance windows and easy configuration changes.

Paul

[jhoughes]

+1 on the option for grouping proxies.

[soehl]

Another +1 for grouping proxies.

[DeadEyedJacks]

I agree that Proxy affinity has definitively been useful in fine-tuning repository access.
Currently we have around 24 Veeam Backup proxies across 12 host clusters, six locations and 3 vCenters.
Proxy affinity has helped ensure that the most appropriate resources are used for each site and environment plus we are better able to manage concurrent access.

However it hasn't helped with job administration, this is where proxy groups would be beneficial.
Rather than having to add/remove individual proxies from multiple jobs for backup, copy and guest processing, simply add or remove them from the group.
Would save our backup administrators a heap of time.

[DaveWatkins]

If it is a proxy, why not to tie jobs to this proxy server, instead of allowing them to select proxy automatically? Just wondering.

Our jobs span sites, so that's not an option.