none
Hyper-V 2012 VM replication as a Sharepoint 2010 DR solution

    Question

  • Has anyone considered using the new replication features of Hyper-V 2012 as a DR/HA solution for a Sharepoint 2010 farm? Is this possible? Good idea? Bad idea?

    davidh

    Thursday, January 17, 2013 7:36 PM

Answers

  • Hello

    yes it is possible..

    DR and HA are always relative to your down time needs.. however you mention sharepoint farm.. so it's dimension could determine if good or bad idea..

    Regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 17, 2013 9:05 PM
  • Hi!

    I think it's a good idea.

    Hyper-V replication is not a function that targets specific servers,roles or applications. It replicates virtual machines from one Hyper-V host to another, making it possible to switch hosting server on demand, or have a cold version of the VM standing by in case of a host failure. It is not a DR or HA strategy, unless you choose to make it so. In Hyper-V terms, HA most usually means Hyper-V servers running in fail-over clusters, where a Hyper-V host goes down, the VMs hosted automatically gets brought up by another Hyper-V host. With Hyper-V replica this is not an automatic procedure, but must be triggered manually, and the VM will only be as current as the last replica.

    So if you have a sharepoint farm running inside a virtual machine, and do not have or intend to build a cluster, then you can most definitely replicate your virtual machine to a secondary Hyper-V server standing by, to minimize downtime in case the first host goes down (or manually shift over the VM to secondary server when performing server updates or maintenance).

    It's my opinion that Hyper-V replica is a very sought-after and nice to have function to ensure a good and simple set of redundancy, but it's not a full substitute for taking the traditional backups.



    Thursday, January 17, 2013 9:35 PM
  • Hi,

    Hyper-V Replica is new in Windows Server 2012. It is an asynchronous, virtual machine replication technology that is designed for business continuity and disaster recovery.

    • Hyper-V Replica allows you, in the event of a failure at a primary site (for example, fire, power outage, or server failure), to fail over your production workloads to Replica servers at a secondary location with minimal downtime.
    • Configurations for the Hyper-V Replica server and storage hardware at each site do not have to be identical. Domain membership is also not required.
    • Hyper-V Replica provides the option to restore virtualized workloads to a point in time, depending on the recovery history selections for the virtual machine.
    • Hyper-V Replica provides the necessary management APIs that enable IT management vendors to build an enterprise disaster recovery solution for their customers.
    • Hyper-V Replica enables Infrastructure as a Service (IaaS) for hosting providers that host dedicated virtual servers for their customers.

    But Hyper-V replica has some disadvantage, just like you should manually start Virtual Machine in Replica Server when fail occur and by default, virtual machine Delta Replication happens every 5 minutes and is not configurable, you may be lost 5 minutes data when encounter unexpected failure. I’m not familiar with SharePoint Disaster Restore farm, if above disadvantage is acceptable, you may use that solution as a SharePoint 2010 DR solution.

    For more information please refer to following MS articles:

    Poster Companion Reference: Hyper-V Replica
    http://download.microsoft.com/download/F/6/9/F6932D74-4ADD-4366-B2BE-22CE4D94E54F/Poster%20Companion%20Reference%20-%20Hyper-V%20Replica.pdf
    Understand and Troubleshoot Hyper-V Replica
    http://download.microsoft.com/download/F/F/1/FF1FA6DE-E82A-48EF-BDCC-612C2D588BFE/Understand%20and%20Troubleshoot%20Guide%20Hyper-V%20Replica%20in%20Windows%20Server%208%20Beta%20.docx

    Hope this helps!

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Lawrence

    TechNet Community Support

    Friday, January 18, 2013 5:59 AM
    Moderator
  • This is indeed a simple Sharepoint deployment, one SP WFE/App VM and one DB VM. 5 minutes of lost data is not significant for this application, neither is the manual failover requirement. I think this will work. I will certainly deploy this solution in the lab enviroment prior to moving the production farm. Thank you guys for helping me think this through.

    davidh

    Friday, January 18, 2013 11:40 AM

All replies

  • Hello

    yes it is possible..

    DR and HA are always relative to your down time needs.. however you mention sharepoint farm.. so it's dimension could determine if good or bad idea..

    Regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 17, 2013 9:05 PM
  • Hi!

    I think it's a good idea.

    Hyper-V replication is not a function that targets specific servers,roles or applications. It replicates virtual machines from one Hyper-V host to another, making it possible to switch hosting server on demand, or have a cold version of the VM standing by in case of a host failure. It is not a DR or HA strategy, unless you choose to make it so. In Hyper-V terms, HA most usually means Hyper-V servers running in fail-over clusters, where a Hyper-V host goes down, the VMs hosted automatically gets brought up by another Hyper-V host. With Hyper-V replica this is not an automatic procedure, but must be triggered manually, and the VM will only be as current as the last replica.

    So if you have a sharepoint farm running inside a virtual machine, and do not have or intend to build a cluster, then you can most definitely replicate your virtual machine to a secondary Hyper-V server standing by, to minimize downtime in case the first host goes down (or manually shift over the VM to secondary server when performing server updates or maintenance).

    It's my opinion that Hyper-V replica is a very sought-after and nice to have function to ensure a good and simple set of redundancy, but it's not a full substitute for taking the traditional backups.



    Thursday, January 17, 2013 9:35 PM
  • Hi,

    Hyper-V Replica is new in Windows Server 2012. It is an asynchronous, virtual machine replication technology that is designed for business continuity and disaster recovery.

    • Hyper-V Replica allows you, in the event of a failure at a primary site (for example, fire, power outage, or server failure), to fail over your production workloads to Replica servers at a secondary location with minimal downtime.
    • Configurations for the Hyper-V Replica server and storage hardware at each site do not have to be identical. Domain membership is also not required.
    • Hyper-V Replica provides the option to restore virtualized workloads to a point in time, depending on the recovery history selections for the virtual machine.
    • Hyper-V Replica provides the necessary management APIs that enable IT management vendors to build an enterprise disaster recovery solution for their customers.
    • Hyper-V Replica enables Infrastructure as a Service (IaaS) for hosting providers that host dedicated virtual servers for their customers.

    But Hyper-V replica has some disadvantage, just like you should manually start Virtual Machine in Replica Server when fail occur and by default, virtual machine Delta Replication happens every 5 minutes and is not configurable, you may be lost 5 minutes data when encounter unexpected failure. I’m not familiar with SharePoint Disaster Restore farm, if above disadvantage is acceptable, you may use that solution as a SharePoint 2010 DR solution.

    For more information please refer to following MS articles:

    Poster Companion Reference: Hyper-V Replica
    http://download.microsoft.com/download/F/6/9/F6932D74-4ADD-4366-B2BE-22CE4D94E54F/Poster%20Companion%20Reference%20-%20Hyper-V%20Replica.pdf
    Understand and Troubleshoot Hyper-V Replica
    http://download.microsoft.com/download/F/F/1/FF1FA6DE-E82A-48EF-BDCC-612C2D588BFE/Understand%20and%20Troubleshoot%20Guide%20Hyper-V%20Replica%20in%20Windows%20Server%208%20Beta%20.docx

    Hope this helps!

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Lawrence

    TechNet Community Support

    Friday, January 18, 2013 5:59 AM
    Moderator
  • This is indeed a simple Sharepoint deployment, one SP WFE/App VM and one DB VM. 5 minutes of lost data is not significant for this application, neither is the manual failover requirement. I think this will work. I will certainly deploy this solution in the lab enviroment prior to moving the production farm. Thank you guys for helping me think this through.

    davidh

    Friday, January 18, 2013 11:40 AM
  • Hi,

    I don't think this solution will be supported by Microsoft for the whole SharePoint Farm, because of the risk that DB could be desynchronized. Imagine that the replication occurs while store procedure has not finish the job ? How can Microsoft guaranteed that there will be no corrupted data at the app level (in this case in the database) ? I think that this "might" be supported for the WFE or APP server (except if the replica occurs during a patch and / or software deployment).

    Anyone have a "real" answer from Microsoft on this point (anything else that "Yes, I think it is supported") ?

    Best regards,

    Edgar Maucourant

    Wednesday, February 13, 2013 12:12 PM
  • Hi Edgar,

    I suspect you are correct. I am testing this in a lab enviroment now and I have had positive results so far. In my enviro I have one WFE/APP VM and one DB VM. I am using Filestream RBS provider which adds another layer of potential DB corruption issues. This mimics my production enviro.

    Things I have tried so far: 

    I performed an uplanned failover scenario: I have started a data dump to the primary VM's and then pulled the plug in the middle of the dump. When I brought up the replica VM's in failover mode none of this data was there becuase the recovery snapshot was at a time before the data dump was begun. The data on the replica server is is update approximately every 5-15 minutes, depending on the time required for each replicaiton operation. There were no errors in the logs and the DB's were not corrupted. At this point I made no changes on the replica VM's and simply brought the Primary VM's backup, canceled failover which starts a synchronization process. When the primary VM's were back online the data dump, at least that part of it that had completed before I pulled the plug, was there. There were no errors in the logs and the DB's were not corrupted.

    I will begin testing today using a similar scenario but will modify/add/delete information on the replica vm's to see what happens when the primary comes back online and synchs.

    Conclusion:

    At this time I think this is a viable solution for a Disaster recovery scenario if you are willing to accept some loss of data which in my production environment is more acceptable than having no access to the data for whatever the duration of the primary site failure might be. The standard MS guidance for DR when using RBS is rediculously complicated and involves a lot of hands on log shipping. This is not an acceptable solution for my environment. I do have tape backup daily of course but I am hoping that Hyper-V replication will be a better solution.

    This may also be a viable solution when you are performing a planned failover in order to perform maintenance tasks on the primary hyperv host.

    Just my $.02 YMMV


    davidh


    • Edited by DAH69 Thursday, February 14, 2013 11:16 AM
    Thursday, February 14, 2013 11:04 AM
  • Hello Everyone, 

    For a multi-server SharePoint farm, what about the following setup?

    Use a SQL technology (mirroring/log shipping/replication/always-on, etc...) to replicate the SQL server/data, but then use Hyper-V Replica to replicate the other VM's (DC, WFE, APP, etc...)

    Thoughts?

    Wednesday, June 25, 2014 1:32 AM