So first off, thank you so much for the very informative video. I do have questions, I have watched many videos on this topic and none of them have done the failover method you outlined. 1. Is it correct to assume during this process, when you click failover, that's the official cutover? So, at that point as an example, that's when you would have your cutover window, then swap over DNS records? 2. In most of the videos on this topic that outline a lab demo, they install the migrate appliance on the target VM. Can we install this migrate appliance essentially on any server that would via network have access to the other VMs? Or do we need a dedicated VM for said appliance? Is it ok to use a target VM to install said appliance if we are unable to install a dedicated VM for said appliance? I'm just used to the term appliance being used for a dedicated NVA as an example or appliance in the context of VCSA for VMware where it's a dedicated appliance. 3. Many videos outline a sync process before cutover, where once syncing is completed, it continues to delta sync until you are ready to cutover. Comments on this? 4. Did I understand correct that on day of cutover, we will want to turn off the target VM BEFORE the migration? Or after? Sorry I didn't understand that clearly. Bonus Question if you have the expertise and time: 5. Thoughts on VMs that are AD joined? I have thought about this in detail. If we say build new domain controllers, replicate to them, and then ensure that said domain controllers have access to the network our target VMs will be migrated to, THEN migrate said target VMs, this would break their join to the domain wouldn't it? We would need to rejoin them since they are considered different objects now by the domain controller. So would it then be wise to unjoin said VM first from the domain controller, migrate, then have the rejoin to the new domain controllers? I greatly appreciate the content you uploaded and how it was clear and concise and would also greatly appreciate if you find the time to answer these questions. Thank you!
Hi Phillip, thanks for your comments and these are all good questions! Please see response below. 1. During a failover (or migration), the source VM is shutdown and the destination DR VM is then powered up i.e cutover. In this case in another Azure region. For Active Directory DNS, if there are AD Domain Controllers/DNS in the DR region then the VM would be able to resolve DNS once failed over. For other DNS (i.e external public facing from the internet) yes you would either change DNS records to a new public IP or use something like Azure Traffic Manager (DNS traffic load balancer) which would also allows you to distribute traffic to your public facing applications. During a test failover the source VM normally stays powered up. 2. You either create a replication appliance through a OVF template then import this into your hypervisor as a VM. i.e VMware, HyperV etc. Or you can download the installer and setup the appliance through Powershell. Further details here on Microsoft article here: learn.microsoft.com/en-us/azure/site-recovery/deploy-vmware-azure-replication-appliance-modernized For disaster recovery on on-premises physical servers, you deploy the configuration server manually. learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-config-process-server-overview 3. The first recovery point that's generated has the complete copy. Any successive recovery points have delta changes. A near-constant data replication process makes sure copies are in sync. learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq#are-all-the-recovery-points-a-complete-copy-of-the-vm-or-a-differential- Hyper-V: Hyper-V VMs can be replicated every 30 seconds (except for premium storage) or five minutes. Azure VMs, VMware VMs, physical servers: A replication frequency isn't relevant here. Replication is continuous. learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq#how-often-can-i-replicate-data- 4. As in question 1. During a failover (or migration), the source VM is shutdown and the destination (target) VM is then powered up i.e cutover on the secondary Azure region. During a test failover the source VM normally stays powered up. 5. In a hub and spoke network topology. The hub hosts services that can be consumed by the different workloads hosted in the spoke virtual networks. Shared services such as Active Directory Domain Services, DNS, firewalling, VPN gateways exist in the hub network. On the failover region, the hub network would contain Active Directory Domain Services, and once the domain joined VM was failed over in the spoke network then the VM would have access to Domain Controllers in the hub. Check out video in the Cloud Inspired channel which covers Hub Spoke Architecture in more detail ua-cam.com/video/Y9rvAGEikx8/v-deo.html
thank you for this effort, sir, I have a question please: what's the best way to know the best storage type that I need to use for the replication ? and to avoid any future latency "churn", how can I know the appropriate target Disks type "HDD, SSD, premium " ? and how to know the best number of configuration servers needed for the replication if I have a lot of servers? thank you in advance!
Hi Abd, Thanks for your comment and questions. For storage type you would need to measure current IOPS, throughput and compare to the five disk types to help you decide which to use. For example, HDD, Premium SSD, Standard SSD, Ultra disk, Premium. Below is a table to help you compare max IOPS and throughput. learn.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-type-comparison Heres is are some other links to help measure the right number of configuration and process servers to deploy. Sizing and capacity requirements learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-deploy-configuration-server Azure Site Recovery Deployment Planner tool. learn.microsoft.com/en-us/azure/site-recovery/site-recovery-deployment-planner Plan capacity and scaling for VMware disaster recovery to Azure learn.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-capacity-vmware
I want to know if this Azure Site Recovery of Process/CS server Migration tool is still used in Azure or there is any other new technology replaced under Azure Site Recovery . Please do let me know
Hi Varunm, yes Azure migrate and Azure Site Recovery is still a valid tool to use for migration, replication, DR for native disaster recovery as a service (DRaaS), or failover of Virtual Machines in the Azure Cloud. Site Recovery is automatically updated with new Azure features as they’re released.
Hello, I'm sorry you felt this way. However the video is at an advanced level. Prerequisites and a good understanding of VMware and Azure environments would be required to understand the content being discussed in this video. I would recommend you study some basics around VMware and Azure and the tooling used (i.e networking, virtual machines, azure migrate, DR/Migration concepts) before watching this video. Thanks and good luck!
Quite a good demo here. 👏🏾 👏🏾👏🏾
Thanks @ThatDevOpsKid
So first off, thank you so much for the very informative video. I do have questions, I have watched many videos on this topic and none of them have done the failover method you outlined.
1. Is it correct to assume during this process, when you click failover, that's the official cutover? So, at that point as an example, that's when you would have your cutover window, then swap over DNS records?
2. In most of the videos on this topic that outline a lab demo, they install the migrate appliance on the target VM. Can we install this migrate appliance essentially on any server that would via network have access to the other VMs? Or do we need a dedicated VM for said appliance? Is it ok to use a target VM to install said appliance if we are unable to install a dedicated VM for said appliance? I'm just used to the term appliance being used for a dedicated NVA as an example or appliance in the context of VCSA for VMware where it's a dedicated appliance.
3. Many videos outline a sync process before cutover, where once syncing is completed, it continues to delta sync until you are ready to cutover. Comments on this?
4. Did I understand correct that on day of cutover, we will want to turn off the target VM BEFORE the migration? Or after? Sorry I didn't understand that clearly.
Bonus Question if you have the expertise and time:
5. Thoughts on VMs that are AD joined? I have thought about this in detail. If we say build new domain controllers, replicate to them, and then ensure that said domain controllers have access to the network our target VMs will be migrated to, THEN migrate said target VMs, this would break their join to the domain wouldn't it? We would need to rejoin them since they are considered different objects now by the domain controller. So would it then be wise to unjoin said VM first from the domain controller, migrate, then have the rejoin to the new domain controllers?
I greatly appreciate the content you uploaded and how it was clear and concise and would also greatly appreciate if you find the time to answer these questions. Thank you!
Hi Phillip, thanks for your comments and these are all good questions! Please see response below.
1. During a failover (or migration), the source VM is shutdown and the destination DR VM is then powered up i.e cutover.
In this case in another Azure region. For Active Directory DNS, if there are AD Domain Controllers/DNS in the DR region then the VM would be able to resolve DNS once failed over. For other DNS (i.e external public facing from the internet) yes you would either change DNS records to a new public IP or use something like Azure Traffic Manager (DNS traffic load balancer) which would also allows you to distribute traffic to your public facing applications.
During a test failover the source VM normally stays powered up.
2. You either create a replication appliance through a OVF template then import this into your hypervisor as a VM. i.e VMware, HyperV etc. Or you can download the installer and setup the appliance through Powershell. Further details here on Microsoft article here:
learn.microsoft.com/en-us/azure/site-recovery/deploy-vmware-azure-replication-appliance-modernized
For disaster recovery on on-premises physical servers, you deploy the configuration server manually.
learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-config-process-server-overview
3. The first recovery point that's generated has the complete copy. Any successive recovery points have delta changes.
A near-constant data replication process makes sure copies are in sync.
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq#are-all-the-recovery-points-a-complete-copy-of-the-vm-or-a-differential-
Hyper-V: Hyper-V VMs can be replicated every 30 seconds (except for premium storage) or five minutes.
Azure VMs, VMware VMs, physical servers: A replication frequency isn't relevant here. Replication is continuous.
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq#how-often-can-i-replicate-data-
4. As in question 1. During a failover (or migration), the source VM is shutdown and the destination (target) VM is then powered up i.e cutover on the secondary Azure region. During a test failover the source VM normally stays powered up.
5. In a hub and spoke network topology. The hub hosts services that can be consumed by the different workloads hosted in the spoke virtual networks. Shared services such as Active Directory Domain Services, DNS, firewalling, VPN gateways exist in the hub network. On the failover region, the hub network would contain Active Directory Domain Services, and once the domain joined VM was failed over in the spoke network then the VM would have access to Domain Controllers in the hub. Check out video in the Cloud Inspired channel which covers Hub Spoke Architecture in more detail ua-cam.com/video/Y9rvAGEikx8/v-deo.html
thank you for this effort, sir, I have a question please:
what's the best way to know the best storage type that I need to use for the replication ?
and to avoid any future latency "churn", how can I know the appropriate target Disks type "HDD, SSD, premium " ?
and how to know the best number of configuration servers needed for the replication if I have a lot of servers?
thank you in advance!
Hi Abd, Thanks for your comment and questions.
For storage type you would need to measure current IOPS, throughput and compare to the five disk types to help you decide which to use. For example, HDD, Premium SSD, Standard SSD, Ultra disk, Premium.
Below is a table to help you compare max IOPS and throughput.
learn.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-type-comparison
Heres is are some other links to help measure the right number of configuration and process servers to deploy.
Sizing and capacity requirements
learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-deploy-configuration-server
Azure Site Recovery Deployment Planner tool.
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-deployment-planner
Plan capacity and scaling for VMware disaster recovery to Azure
learn.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-capacity-vmware
I want to know if this Azure Site Recovery of Process/CS server Migration tool is still used in Azure or there is any other new technology replaced under Azure Site Recovery . Please do let me know
Hi Varunm, yes Azure migrate and Azure Site Recovery is still a valid tool to use for migration, replication, DR for native disaster recovery as a service (DRaaS), or failover of Virtual Machines in the Azure Cloud. Site Recovery is automatically updated with new Azure features as they’re released.
Sorry to say this. Honestly, you are going way too fast, and for beginners like me who want to understand this migration is quite difficult.
Hello, I'm sorry you felt this way. However the video is at an advanced level. Prerequisites and a good understanding
of VMware and Azure environments would be required to understand the content being discussed in this video.
I would recommend you study some basics around VMware and Azure and the tooling used (i.e networking, virtual machines, azure migrate, DR/Migration concepts) before watching this video. Thanks and good luck!