Skip to main content

 none
Azure site recovery questions? Can we configure the replicated server at the secondary site before the cut-over? RRS feed

  • Question

  • During ASR's initial replication where the DR site has replicated however not cut-over, can the replicated VMs(application servers) at the DR site be RDP to and can we configure the applications and connections to other replicated VMs at the DR site (ie, Database servers)?  If the IPs are different at the DR site how can we be sure the application server are able to communicate with the database servers before they are cut over in a DR scenario?   Would it be best to include both the data base servers and application servers in the same ASR grouping (group of server replicating together)?  

    What I am most concerned about is that the servers which have replicated to the DR site can be reconfigured to communicate with each other without having to do a cut-over ( which is permanent? )?   

    So if we use ASR to migrate to Azure from On-Premise will we be able to configure and test the applications in the cloud before we do a cut-over?   What is the fail back step after a cut-over is done?   


    dsk

    Wednesday, October 23, 2019 2:25 AM

All replies

  • ASR do provide Test Failover feature to failover the applications temporary to an isolated environment and later do the actual failover.

    Yes, it's always good to group these servers(which are interdependent) in one recovery plan and kick them off based on the priority.

    Like:

    1. Database server 

    2. Web server

    (This will also reduce the RTO and easy to manage as group)

    ASR do also has failback support, incase if you want to failover VMs back to on-premises.

    • Proposed as answer by Mara Ram Wednesday, October 23, 2019 8:08 AM
    Wednesday, October 23, 2019 8:08 AM
  • There is no replicated server while the VM is replicating. The VM in the recovery region is only created when the VM is failed over.

    For the IP configuration you have multiple options:
    1. ASR allows you to retain the same IP post failover
    2. You can configure the application service IP configuration post failover using Recovery Plan scripting or Manual action 

    It doesn’t require you to replicate the servers in a replication group.
    Wednesday, October 23, 2019 11:36 AM
    Moderator
  • So are you saying that when the VMs in a recovery group ( application servers, web server , and database servers) have finished replicating that these VMs can be RDP and configured to connections can be configured and certificates can be installed?  Can we do all this without doing a cut-over to the DR site?   Can we also do this in a migration to azure cloud scenario?  We want to be able to confirm that systems can function without any major reconfiguration (i.e. just simple DNS changes) before they are cut-over (fail-over) to the DR site ( or when migrating from on-premise to the cloud ).

    Is cut-over the same definition as fail-over?  Or is the previous reply by Mara Ram imply that fail-over is not a permanent state where configurations and modification can be done at the destination site (DR) once replication is finished?  And cut-over is the permanent disconnection that terminates the possibility to fail-back to the primary site?  My organization will require us to fail-over and test functionality then fail back and test functionality.

    We want to be able to determine if the systems which either move to the cloud or fail-over to a DR site will function after ASR?   How do we keep the same IPs if we fail-over to a DR site (different vnet which have a different subnet)?   What is we choose not to keep the same IPs with a new subnet? ( Destination site usually the a different subnet ).   What is recommended to let ASR choose the new IP for replicated VM or to specify the same IP's?

    For ASR do we need the same subscription?  Is it a best practice to use the same subscription for ASR?


    dsk


    • Edited by kimdav111 Wednesday, October 23, 2019 2:11 PM
    Wednesday, October 23, 2019 2:08 PM
  • So are you saying that when the VMs in a recovery group ( application servers, web server , and database servers) have finished replicating that these VMs can be RDP and configured to connections can be configured and certificates can be installed?  Can we do all this without doing a cut-over to the DR site? 

    --> No without doing a Cutover it is not possible to test the applications. This can done during test failover means, you will be still running your original Vms and failover the azure VMs to an isoldated env where your azure vms are not reachable to onpremises Vms.

     Can we also do this in a migration to azure cloud scenario?  We want to be able to confirm that systems can function without any major reconfiguration (i.e. just simple DNS changes) before they are cut-over (fail-over) to the DR site ( or when migrating from on-premise to the cloud ).

    --> If you are too worried, most of the customers do actual failover by shutting down there original Vm and they will verify all the checks like DNS in the azure production network and disable the replication and kill those VMs on azure and power on the original source.. For this you need large downtime.

    Is cut-over the same definition as fail-over?  Or is the previous reply by Mara Ram imply that fail-over is not a permanent state where configurations and modification can be done at the destination site (DR) once replication is finished?  And cut-over is the permanent disconnection that terminates the possibility to fail-back to the primary site?  My organization will require us to fail-over and test functionality then fail back and test functionality.

    --> yes, cutover and failover are same.  You can't failback VMs to on-premises in test failover state, you can only failback when you did the planned/unplanned failover.

    We want to be able to determine if the systems which either move to the cloud or fail-over to a DR site will function after ASR?   How do we keep the same IPs if we fail-over to a DR site (different vnet which have a different subnet)?   What is we choose not to keep the same IPs with a new subnet? ( Destination site usually the a different subnet ).   What is recommended to let ASR choose the new IP for replicated VM or to specify the same IP's?

    --> This diagram has more info if you want to retain IP and gives a bit understanding:

    https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-retain-ip-azure-vm-failover

    For ASR do we need the same subscription?  Is it a best practice to use the same subscription for ASR?

    --> It always good to maintain same subscription, though you can still protect those VMs to another subscription also.

    • Proposed as answer by Mara Ram Thursday, October 24, 2019 8:26 AM
    Thursday, October 24, 2019 8:26 AM
  • For a Primary Azure site replication to a DR Azure Site (cloud to cloud), once we fail-over to the DR site we will be able to RDP and check/configure the systems such as DNS.   If there are changes on the corresponding primary site how will these be replicated to the DR site which we have fail-over?  Especially things like databases will have changes if we do not take the system located in the primary site offline then place the DR site online.  

    XXXXXXXXXXXXX

    Mara Ram's above--> If you are too worried, most of the customers do actual failover by shutting down there original Vm and they will verify all the checks like DNS in the azure production network and disable the replication and kill those VMs on azure and power on the original source.. For this you need large downtime.

    My response >>> Are you saying the following, once we do a fail-over /cutover we will shut down the source VMs. Next we can RDP the destination system,... we can RDP / make configuration changes / updates DNS / Add certificates ?  Are you saying that we do not have any RDP access to the destination system until we have made the cut over/fail-over?   You are recommending we shut off the source system so that the both the source and destination systems will have no differences during this cut-over?   You are also saying that bring the destination system on-line can take some time because SSL certificates have to be installed, application configuration may need to adjusted, DNS changes, and prior firewall changes will need to be tested?  If we want to reverse steps or reverse the fail-over how would we proceed?  Often we need to reverse the change (ie fail-over) if there is a major issue bring the destination system online?,... how would we do this?

    Because our colocation site (ie. equinix) will be routing traffic from on-premise to both the source azure and destination azure the IPs will need to change because the limitation that all traffic will be routed through the same core router?   Both the destination site, source site, and on-premise site will need to communicate with each other so this would be difficult if there are any duplicate IPs (ASR by default uses the same IPs)?

    Once we fail-over to the DR site (site B) then a week later there is a need to fail-back to the original source site (site A) would we just need to follow the same steps in reverse?  Is it possible with ASR to just to update the site A's systems from site B?    



    dsk


    • Edited by kimdav111 Friday, October 25, 2019 11:42 AM
    Thursday, October 24, 2019 6:09 PM