Having a copy of your primary VBK server at the DR site is crucial for recovery so I can see why the Veeam Architect recommended that. You can go with his solution or just ensure you have a Configuration Backup of your VBR server stored offsite so you can stand up a new server in case of DR.
The replication of the VBR server is the best route in my opinion.
@Chris.Childerhose what would be the disadvantage of having a VBR server in each DC backing up VMs from local clusters and managing replication of VMs from the remote cluster to the local cluster? Would this not reduce the time to recover the VBR on the other side if it is managing only a single cluster?
You typically in this scenario have only one VBR to manage everything and not two. Also in order to recover there is some work needing to be done on the VBR server that will take over the recovery. Having just one you got all the configuration there so replicating it like mentioned by the Veeam SA would be faster to bring up and recover.
+1 for only one vbr. Use VMware HA / Veeam Replication and Config Backup Restore for Restore Scenarios. It’s much more easier regarding the handling and config.
Does this work fine if Veeam is replicating VMs from both DC1 → DC2 and DC2 → DC1? This means the single VBR instance needs to manage both ways replication.
VM replication (traditional way, not CDP) is from my opinion only for your VIP/ “top 10” VMs. It’s not a solution for all VMs at big scale. Maybe you can do this at bigger scale, but im conservative here. Especially CDP is not a “for all VMs” solution because i will add heavy (network) load on your systems.
From my opinion if you want to have all “mirrored”/replicated think about a syncronous mirrored storage….
Does this work fine if Veeam is replicating VMs from both DC1 → DC2 and DC2 → DC1? This means the single VBR instance needs to manage both ways replication.
Yes it works perfectly fine with one VBR managing both replication directions.
+1 one VBR on the DC with fewer production servers and replication of backups between the two sites.
I was going to suggest what I use..which is a 2nd VBR server at my remote site to manage Replications. I do this so if my main site (site 1) goes down, I can manage my Replicas from my DR site, then failback to site 1 when (if) I’m able. Why this works for me is because my DR site is just that...for DR. I don’t have or run an active-active environment.
But, this I don’t think is appropriate for 2 active sites. Reason is, if a site goes down, you still have a VBR server which can’t manage its Replication (and even Backup) Jobs. So, why add complexity to your design? As what was shared by Chris/Matthias above, Replicate each server across to the other site in case a given site goes down, or at the very least keep your Config DB backed up to the remote site, so you can recover and perform needed recovery operations with a given VBR Server. I believe this is the reason why the Veeam Architect suggested what he did...or, at least 1 reason 
@sudhir_h You can also replicate the VBR server and related proxies with the CDP.
I would also go with the solution mentioned by Chris and Matthias. If you have a mirrored SAN between your DCs, it’s an “easy” approach to manage this by a VBR instance inside a VM, thanks to VMware HA - also when DRS is available you could make a rule, where this VM should be hosted.
Only one virtual VBR in this scenario make’s it easy to manage.
If you customer has the requirement to also test (not only with Sure Backup/Replica) or automatically document some DR scenarios, check if defined RPOs/RTOs are met within this environment, you could also consider to take a look at Veeams Recovery Orchestrator. For sure, not a cheap solution (Veeam Data Plattform Premium or VRO +10 Packs) and also adds more complexity, but definitly a worth looking for.
A single VBR is also how we run. We have mega port links all over with ESX, repos & SAN in different geos. If we lose the VBR, we drop a template and restore the DB config and we’re up and rolling again with complete failover plans intact. We could stand that VBR up at any of the other sites if we had to with the networking in place. Likewise, when we have cleanroom tests I have the end-user send a local VBR DB and we restore that in the clean room env and run that config as if we were still the local VBR.
I completely agree with the solutions that have already been proposed.
One VBR server that is replicated to the 2nd data center via replication. In the DR case you can simply boot the replica VM.
For the storage servers, I would consider installing them as a Veeam Hardened Repository (one Hardened Repo can also only be managed by a single VBR!). This is a good way to store the backup data more securely
If you also need the backup data from DC1 in the DC or the other way around, you would have to set up a backup copy job
