Choosing SOBR Extend/Gateway server/Proxy

[Henrik.Grevelund]

Hi,

I have a setup with 20 virtual machines which has these roles:
Gateway server/data mover to an dedicated extend in a SOBR writing to a Data Domain
Proxy server limited to Virtual appliance(Hotadd) with no fail over allowed to NDB

The machines are spread on different clusters in the same vcenter.
The SOBR has Data locality as placement rule. Proxy affinity on each extend has been set the same as gateway server

When i start new backup it doesn't choose to use the same server for both gateway server as proxy server.
Is this expected behaviour ?

[veremin]

Did I get it correct - during backup job a server running gateway role is not selected as proxy server? If so, what backup proxies are selected instead? Thanks!

[Henrik.Grevelund]

Hi Vladimir,

Correct, It chooses an extend on 1 server writting "Cannot find a proxy meeting the proxy affinity rules", then chooses another proxy than the one who has access to the extend.
The backup proxy does backup using Hotadd.

[PetrM]

Hello,

Proxy affinity on each extend has been set the same as gateway server

Looks like proxy affinity settings are ignored, do you have a support case ID for the issue?

Thanks!

[Henrik.Grevelund]

Hi Petr,

Not yet. The way i read the manuel it seems to first select the extend, and then chooses a proxy. So i wasn't sure it was suppose to work.
But i will open one if its doing it wrong.

[PetrM]

Hi Henrik,

If you're talking about an example described on this page, then it's expected to get a message that requirements of proxy affinity rules are not met. Anyway, it's worth checking backup job settings as well, what did you set for proxy selection: a specific proxy or automatic selection?

Thanks!

[Henrik.Grevelund]

Hi,

When i start a backup of VM1 it chooses extend3 as destination. But only Proxy3 has access to this extend(No automatic gateway selection).
The backup job has been set to automatic selection of proxy because it has VM's selected from several clusters. It does figure out a proxy to use for hotadd, but then have to send the backup to the gateway server over the nic.

Code: Select all

---cluster01---proxy1--extend1
 |           |-proxy2--extent2
 |           |-VM1
 |
 |-cluster02---proxy3--extend3
 

[PetrM]

Hi Henrik,

Maybe proxy3 has no access to the datastore hosting disks of VMs? In this case, another proxy that meets all requirements for HotAdd will be selected and proxy affinity rules will not be respected. Also, I'd like to ask you to open a support case and share its ID over here so that we can keep an eye on it.

Thanks!

[Henrik.Grevelund]

Hi,

Support case # 04993466

[Henrik.Grevelund]

Hi Petr,

According to this :https://helpcenter.veeam.com/docs/backu ... ml?ver=110
It says :
Proxy affinity can be set up for the following types of backup repositories:

• Backup repositories

• Scale-out backup repositories

But under Proxy Affinity for Scale-Out Backup Repositories
It says :
Extent selection rules have a higher priority than proxy affinity rules. Veeam Backup & Replication first selects an extent and then picks a backup proxy according to the proxy affinity rules specified for this extent.

So basically it says that the affinity rules are set aside. So it chooses an extend first, then it looks after a proxy that has access to this extend.

And this : https://helpcenter.veeam.com/docs/backu ... ml?ver=110
says:
However, if you use a deduplicating storage appliance as an extent to the scale-out backup repository, Veeam Backup & Replication will attempt to place a new full backup (active or synthetic) to the extent where the full backup from the previous backup chain resides.

I will have a very hard time getting Veeam to change the backup to a extend.

[PetrM]

Hi Henrik,

Yes, both statements from our help center are valid and I already referred to the first one in the thread above. On the other hand, I'm not sure that I understand how is the second statement about dedupe storage is related to the problem we're discussing now because proxy is picked up after extent selection is completed. And the issue is that a job takes a proxy which does not fit affinity rules for the selected extent. Could you please confirm that my understanding of the issue is correct?

Thanks!

[Henrik.Grevelund]

Hi Petr,

The second statement was just pointing out an unexpected behaviour, which i wanted to point out.
Since this is the only way to distribute backup if an extend is running full.

This server having these issues is only the small one, the production set is 3 times larger, and i might end up using 3-4 Data domain boxes in 1 SOBR. If 1 of the DD boxes runs full i will need some magic to force veeam to distribute the load.

If Veeam was able to select correctly, it would be the number of proxies in each cluster that would decide how many extends used, then i could better distribute the extends on the different DD boxes.

[PetrM]

Hi Henrik,

The current design is that in case of dedupe storage, Veeam tries to place a new full on the extent on which full from the previous chain resides. This approach allows us to get higher deduplication ratio. Anyway, your concerns are noted.

Thanks!