none
Hyper-V Replica Broker to multiple CSVs

    Question

  • With some help from the TechNet community and a whole lot of trial and error, I have successful configured my failover cluster and performed a couple of planned failovers. Hooray! However, I have 3 CSVs on my DR cluster and would like to utilize the entire disk space for replication. I have a replica broker on the primary side (not configured) and one on the DR side that points to the primary broker and points to 1 volume on the DR cluster for storage. I just found out that I cannot add additional volumes in the specified servers section by pointing to the same primary server. So do I  (A) make multiple brokers on the primary side with unique names and point them each to a CSV. (B) Delete my volumes and make one big one to facilitate all the replicas? Is there a third or even fourth option I haven't contemplated. Obviously, I would like to keep the setup as simple and efficient as possible. Thank you in advance for any help.

    Brian Gilmore Lead IT Technician Don-Nan Pump & Supply

    Monday, February 16, 2015 9:50 PM

Answers

  • Hi Brian,

    It is only possible to create a single Replica Broker per cluster. The cluster will not allow you to create a second or third role. The normal way would be to create a larger CSV for VM replicas and leave normal running VMs on the other CSVs.

    The only other way would be to use multiple standalone hosts on the primary site and split the incoming data up by host name but then you lose the whole point of a fail over cluster without the cluster.

    Hope that helps a little, regards Michael


    Monday, February 16, 2015 11:30 PM

All replies

  • Hi Brian,

    It is only possible to create a single Replica Broker per cluster. The cluster will not allow you to create a second or third role. The normal way would be to create a larger CSV for VM replicas and leave normal running VMs on the other CSVs.

    The only other way would be to use multiple standalone hosts on the primary site and split the incoming data up by host name but then you lose the whole point of a fail over cluster without the cluster.

    Hope that helps a little, regards Michael


    Monday, February 16, 2015 11:30 PM
  • It does. I was leaning towards making a larger single volume. Again, thank you very much.

    Brian Gilmore Lead IT Technician Don-Nan Pump & Supply

    Tuesday, February 17, 2015 12:47 PM
  • It is only possible to create a single Replica Broker per cluster. The cluster will not allow you to create a second or third role. The normal way would be to create a larger CSV for VM replicas and leave normal running VMs on the other CSVs.

    The only other way would be to use multiple standalone hosts on the primary site and split the incoming data up by host name but then you lose the whole point of a fail over cluster without the cluster.

    This is something I have been battling with as well.  I have 2 identical clusters but Microsoft clustering will only allow me to replica 5 LUNs of VMs onto 1 LUN.  Is this on the roadmap to be fixed. This seems like a major bug in failover clustering and replication.  

    Thank you.

    Friday, November 20, 2015 3:30 PM
  • There is no bug because there is no problem. After one CSV fills up with Replicas, change the Replica Broker's default storage location to the next CSV. Or Storage Live Migrate old Replicas to new CSVs. Or both. Replicas can be maintained anywhere that the Replica Broker can reach. There is absolutely no requirement that they all be in the same place.

    Eric Siron
    Altaro Hyper-V Blog
    I am an independent blog contributor, not an Altaro employee. I am solely responsible for the content of my posts.

    Friday, November 20, 2015 4:21 PM
  • I guess I was hoping the failover clustering would do the fill and spill automatically instead of requiring manual intervention each time a replica lun filled up. 

    I did find a way to get around what I think is a limitation by enabling the replication but not stating the initial copy. Move over to my replica system and do a storage migration to the various luns, then go back to the primary and start the initial copy.  A lot of extra work but at least I get the things moving to multiple luns without constantly making changes my replica broker.  

    Friday, November 20, 2015 9:41 PM
  • You want Replica trying to decide where best to place a virtual machine? I want tight control over where my VMs live. They might have to actively run from that location some day. To each their own, I guess.

    I think it would be perfectly reasonable for the wizard to allow an override of the default storage location at the time that you enable replication for a VM, just like the new VM wizard does. I don't know why it doesn't do that. I don't think that qualifies as a bug, though. More like a not fully mature feature.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent blog contributor, not an Altaro employee. I am solely responsible for the content of my posts.

    Friday, November 20, 2015 10:09 PM
  • Hi Eric

    Interested in the answers here from yourself and FlyingV.

    We are in the initial planning/setting up phase for Replicas on a DR site using Failover clusters and I have just come across this issue - we have multiple CSVs on our Replica cluster due to the way our Storage group tier our assigned storage (Tier1 disks on one CSV, Tier2 disks on another).

    If we want the ability to be able to direct what CSV (Tier) each individual VM has their replica VM on the two suggested options here seem to be:

    1) Complete the VM replication process as normal with the replica VM being created on the default storage path, say CSV2. Once the replica VM exists storage migrate the replica VM to the preferred storage location, say CSV1. Now Replication will work normally for this VM, writing all data (the HRL and Recovery points) to the new CSV (?).

    2) Start the VM replication process, interrupt the process (when the replica VM has been created but initial replication has not started) and move to the DR cluster and do a storage migration of thr replica VM to the preferred CSV (as in option 1).

    Have I understood both of you correctly (luckily we are still at the stage where we can test and sign-off this process before using it with Production VMs) ?

    Lastly, as storage migration allows you to choose different locations for different files of a VM, can I leave one VHD on my CSV and another on a different CSV (i.e. OS disk on CSV2 and Database disk on CSV1) and the Replication process will work as normal (i.e. it is replicating to the VM object so does not care where individual disks of that VM are) ?

    Thanks in advance for all advice.

    Tom

    • Edited by thazlett Wednesday, April 20, 2016 9:52 AM
    Wednesday, April 20, 2016 9:51 AM
  • I would try out each method and see what works best for your processes. If it were me, I would choose to drop to a sufficiently large default location and worry about moving it later. Micromanagement isn't my thing.

    Yes, a single VM, replica or otherwise, can run perfectly well with its components in different storage locations. That also opens it up to more ways to fail, so be mindful of that.


    Eric Siron
    Altaro Hyper-V Blog
    I am an independent blog contributor, not an Altaro employee. I am solely responsible for the content of my posts.

    Wednesday, April 20, 2016 4:50 PM
  • Thanks Eric for the quick reply.

    We agreed with you that micromanagement isn't required and used storage migration after we had set up the initial replicas. This worked fine with the same behaviour as seen in standard storage migration - with the exception that both test VMs migrated all files completely (copied then removed originals) to the new location apart from the disk files. In both cases the original disk files were left behind even though new files were created and the VMs were running from them. We left them for a few replication cycles just to observe timestamps and where log files were forming (being ultra cautious) and then after seeing nothing of concern deleted the originals.

    We are happy that this is the process we will run with due to the tiering, CSV sizes and performance of the storage environment that is not under our direct control. We will probably go as far as to set the default storage location as a 'staging' smaller CSV and have a step in the process to be to migrate the VM to a 'home' CSV after initial replication.

    Best regards

    Tom

    Friday, April 22, 2016 8:57 AM
  • Why would they mature this feature, MS is pushing there overpriced ASR solution.
    Tuesday, October 31, 2017 2:27 PM