Design Advice in a two-way Hyper-V 2016 Replication scenario using SCVMM

[massimiliano.rizzi]

Hello Community and good day,

I need your advice with regards to one of our existing customers which has been happily using Veeam for well over 2 years for backups only and that now needs to use it for replication as well. I will try to keep it short.

Current production environment is depicted and described below (Veeam Stencils FTW! ):

==================================================

- Site 1 and Site 2 are in the same campus and are connected with two 10Gb fiber links with no latency. VLANs are stretched
- Each Site has a 3 node Hyper-V cluster managed by SCVMM (which is installed inside a dedicated VM running in Site 1)
- From a Veeam perspective, we are currently using an all-in-one physical server acting as the VBR server/primary backup repository in Site 1 and another physical server acting as the secondary Windows backup repository in Site 2
- From a Veeam perspective, we added the SCVMM server to Veeam Backup & Replication (instead of the two clusters managed by SCVMM) in order to be able to use Hyper-V tags to add VMs to Veeam B&R jobs
- All Hyper-V VMs are currently backed up to the primary repository (1.) and then the most recent restore points are copied to the secondary repository using Backup Copy Jobs (2.)
==================================================

With regards to replication, our customer would like to replicate the most important VMs from Site 1 to Site 2, and viceversa (3. and 4.). Now the single points of failure I can see in this two-way replication scenario are the SCVMM server and the VBR server itself in case Site 1 goes down, so here are the questions:

==================================================
- With regards to the SCVMM server VM, the only solution I see here is to replicate it to Site 2 so that if the SCVMM VM itself or Site 1 should fail the SCVMM VM can be powered on manually in Site 2 in order for Veeam be able to talk with SCVMM again (5.)
- With regards to the VBR server itself, if the latter or Site 1 should fail we lose management to Veeam. As a result, does it make sense to separate the VBR server role from the physical server it currently resides on, move it to a new dedicated VM running in Site 1 (6.) and replicate it as well to Site 2 so that the VM can be powered on manually in Site 2 (7.) to regain contact with Veeam ?
==================================================

Thank you in advance for taking the time to read my post. Any suggestions and thoughts will be greatly appreciated.

Kind Regards,

M.

[HannesK]

Hello,
yes, that makes sense and is one of the main reasons why customers have a virtual backup server.

The only thing to keep in mind is potential chicken-egg issues if the backup server replicates himself with snapshots. So having a second VBR server (that's fine from a licensing perspective) that is only responsible for during replication of the VBR server would be the best way. Well, as we have Hyper-V in the scenario, that implies that both VBR servers need to be upgraded timely close to each other (because of the on-host proxies)

Best regards,
Hannes

[nmdange]

- With regards to the SCVMM server VM, the only solution I see here is to replicate it to Site 2 so that if the SCVMM VM itself or Site 1 should fail the SCVMM VM can be powered on manually in Site 2 in order for Veeam be able to talk with SCVMM again (5.)
- With regards to the VBR server itself, if the latter or Site 1 should fail we lose management to Veeam. As a result, does it make sense to separate the VBR server role from the physical server it currently resides on, move it to a new dedicated VM running in Site 1 (6.) and replicate it as well to Site 2 so that the VM can be powered on manually in Site 2 (7.) to regain contact with Veeam ?

SCVMM supports clustering so you can run two HA SCVMM servers, one in each location. You would also want to run the SCVMM database as a SQL AlwaysOn Availability Group between two SQL VMs in both datacenters. This is how my environment is set up (though actually we have 4 SCVMM VMs, two in each location).

For our VBR VM, we use Hyper-V replica to replicate that so we can perform failover without requiring Veeam itself to be running.

[massimiliano.rizzi]

Hello @HannesK/@nmdange,

first of all thank you for taking the time to read my post and provide me with your thoughts. It is very much appreciated.

Deploying a highly available "stretched" SCVMM server along with a highly available "stretched" SQL Server database for SCVMM is definitely something we may bring to the our customer's attention as it sounds like this could simplify the design from a Veeam perspective (while this adds some complexity on the other side due to the need to set up/manage Failover Clustering in order to make both the SCVMM and its SQL Server database highly available as far as my understanding goes). As there will definitely be some license implications as well, we will need to go through an evaluation/approval process, so I am pretty sure we will need to stick with what we have in the first instance.

@HannesK I got your point with regards to having a second "Helper" VBR server that is only responsible for replication of the production VBR server and with regards to the need of upgrading them timely close to each other.

As both the SCVMM server VM and the new VBR server VM will be running in Site 1, does it make sense to use the physical server currently acting as the secondary Windows backup repository in Site 2 (8.) for that ?



As far as my understanding goes, this second "Helper" VBR server could also be responsible for both backup and replication of the production SCVMM server. The advantage I see here is that we will be able to add the two clusters managed by SCVMM (instead of adding the SCVMM itself) as there will be no need of using Hyper-V tags.

Thank you again for your support.

Kind Regards,

M.

[HannesK]

Hello,

running one VBR server per site and adding the clusters directly would work, but you need to be careful about a few things
- by changing to Hyper-V cluster from SCVMM you would get a new full backup
- the backup copy job would point to repositories managed by another VBR server. They don't know about each other and could potentially overload the machine (reduce tasks settings if needed)
- updating also needs to be done at the same time because of the shared repositories
- repositories must be in different filesystem paths / folders
- in case you have sure-backup, there would be orphaned objects in SCVMM over time

Best regards,
Hannes

[massimiliano.rizzi]

Hello,

thank you for your reply.

I apologize for not being very clear.

I am planning on only adding the clusters directly only to the second VBR server. In my mind this second VBR server should be responsible for backup and replication of two VMs only: the production VBR server (to avoid the potential chicken-egg issues like you suggested) and the SCVMM server.

The rest of the configuration will be left untouched (except for migrating the existing configuration to a virtual backup server).

Sorry about any confusion I may have caused.

Thanks and Regards,

M.

[HannesK]

no problem then only the shared hardware constraints are still relevant (means updating and repository folders)

[mattiamigliorati]

Hi Massimiliano,

I'm didding into Microsoft HyperV for the first time these days.
I'm reading al lot of documentation about HyperV clusters and I tryed in a demo lab SCVMM but I found it really painful to setup.
Have you any useful doc or guide about this type of infrastructure implementation?

Thank you for sharing

Mattia

[HannesK]

Hello,
yes, I also heard it's painful and I would hope that Microsoft has documentation. We only do the backup & restore

Best regards,
Hannes