In this lesson, Sharon provides an overview of the Azure Site Recovery service including the benefits, the difference between failover types, and possible protection scenarios.
- [Instructor] In this chapter, we're going to look at Azure Site Recovery. This solution allows us to protect our virtual machines in Azure. And it's somewhat different than Azure backup. Because when we use Azure site recovery, we're actually replicating the virtual machine from, in this example, the primary site to Azure. And this replication is constant. That way, if our primary site goes down, we can easily fail over into our Azure environment and still connect to VM1, VM2, with very little configuration.
Let's go ahead and explore ASR in a little bit more depth. As you recall backups, we can only back up at certain times. And in some cases, only once or twice a day. With ASR, we can replicate very frequently. And by frequently, I mean every 30 seconds, five minutes, and 15 minutes. One thing to note here, 15 minutes is allowed at the time of this recording in late February, 2018. The 15 minute options will be deprecated and anything that you have set to 15 minutes will drop down to five minutes.
Keep that in mind. The communication is secured using certificates, and no special hardware is required. And you can protect Azure virtual machines, your VMware virtual machines, as well as physical servers. Let's take a moment to talk about planned vs. unplanned failovers. And we'll start with the planned failovers because those are the nicer of the two. A planned failover is an expected outage and it results in zero data loss. A planned outage may be a system upgrade, or you know that the power's going to be out for a certain period of time.
An unplanned outage is an unexpected outage, which will result in minimal data loss. An example of an unplanned outage would be a power failure, or a hardware failure. Now, let's take a look at some of the configurations that we can implement using Azure Site Recovery. We can protect our on-premise Linux and Windows physical machines. We can protect our on-premise Hyper-V virtual machines to Azure, or to another site if we so chose to do so. And the same goes for VMware virtual machines.
We can replicate those to Azure or to a recovery site. We can also protect our AWS, or Amazon Web Services virtual machines to Azure. And finally, we can replicate our virtual machines that are in Azure to another region in Azure. One of the aspects of ASR that I like and have used it for is migration. And that's because ASR will convert all your VHD Xs to VHD. You don't have to do it yourself prior to moving the disc to Azure.
It will also upload everything correctly to Azure for you. So again, you're not having to do this manually through Power Shell. You can also use ASR to migrate your AWS machines to Azure. And again, you can use it to migrate your Azure virtual machines from one region to another. Again, you can do all of this manually if you wish. But since ASR is there for you, and easy to set up, why put yourself through the hassle? Let it do the work for you. ASR provides application consistency because it uses application consistent snapshots that capture disc data, and capture the data in memory, as well as all the transactions in process.
You can also configure customizable recovery plans which will allow you to group machines to fail and start together. For example, when configuring a multi-tier app, you would group the tiers to fail together. Such as, you would fail all your web servers together, and all your database servers together. And then when starting, you would start all the database servers together, and then followed by the front-end web servers. You can add scripts to perform a set of actions to run on the VM. You can also add a manual action to the recovery plan.
And when you do this, the recovery plan will be halted until the manual action is performed. And then the recovery plan will continue. You can also add new groups to your recovery plan, which in turn will allow you to add more machines, and again, more scripts. And finally, you can also add in Azure runbooks to your recovery plan for customization of your virtual machines. As with any recovery plan that you have, one of your key steps will be failover testing. Azure site recovery will validate your failovers.
And it does not disrupt your production environment when you're doing this test failover. I would highly recommend, after you've configured ASR and all your virtual machines have replicated, that you run a failover test and ensure that every machine is coming up correctly. The last thing you want to do is troubleshoot failover issues during an outage. And I don't want you to think that once you've failed into Azure you can't leave again. You can. You can actually fail back from Azure to your environment.
You can fail back to VMware, you can fail back to Hyper-V, and in the case of Hyper-V, you could actually fail back to an alternate location if you wanted to do that. But keep in mind you cannot fail back to a physical server. That is it for ASR in a nutshell. We will be exploring some of these configuration options in detail in the upcoming lessons.
- Creating a Recovery Services vault for Azure Backup
- Protecting virtual machines, files and folders, databases, workloads, and file shares
- Restoring virtual machines, files and folders, databases, workloads, and file shares
- Azure Site Recovery scenarios
- Running failover and failback tests
- Replicating an Azure virtual machine