Hello. In this lesson, I will show you how high availability and disaster recovery can be enabled in an Azure solution using the built -in tools that are provided. You can see that Azure is providing you with a solid global Cloud foundation with over 60 regions that include 200 data centers divided amongst those 60 regions. This is a network that traverses the entire globe. However, this does still run on traditional equipment. You can't have a data center without power supplies, network connections, and computers. All of these physical devices do have the potential for failure. While Microsoft is providing reliability in terms of the most reliable network they can create, it is still your responsibility to determine what additional measures you would like to take for your solution to improve the likelihood of your solution surviving some form of outage. It's especially important to protect production resources that your company relies on to conduct its business. You can see here on this graphic, there are several tools that are built into the Azure subscription that you can enable for resources such as virtual machines or storage accounts or web application services to make sure that those resources can stay up even if there are failures within the Azure environment. You must be aware though that enabling these additional features will incur additional expenses. Therefore, the more reliability you want in your application, the more money you will have to spend in your budget in order to enable that. It's always a balance between how reliable you can make your application versus how much money you can afford to spend. Let's take a look at some of the common ways to protect resources such as virtual machines. That would include availability zones and availability sets. Back here at the Azure portal, we can look at virtual machine creation by clicking on the virtual machine icon at the top of the screen. You can see that we already have a virtual machine, but we can look at the redundancy options that can be enabled when creating a virtual machine by clicking the Create button. You can see in the creation screen for the virtual machine near the bottom, there's an option to determine the availability options. By default, it says no infrastructure redundancy required. This is the default setting for all virtual machines. This means that your virtual machine is not being replicated to any other location within Azure. The reason this is the default is because this is the most affordable setting for virtual machine. Choosing one of the additional availability options will incur additional expenses. You can see the two additional availability options that we would like to cover, the availability zone and the availability set. The virtual machine scale set is an opportunity to replicate your virtual machine within a datacenter under high load scenarios to create a scalable application. That is not related to disaster recovery. We're going to look at how availability zone and availability set can affect your virtual machine's reliability. Reliability is quoted by cloud vendors in terms of an SLA or a service level agreement. We can look at the guaranteed service level agreement for virtual machines if we choose to spend money and add one of these additional availability sets to our solution. You can see in this graphic that a single virtual machine with no additional disaster recovery settings enabled is guaranteed a service level agreement of 99 .9%. That does protect you against isolated failures within a particular rack, but while your virtual machine is rebooted, you will experience downtime and at 99 .9 % availability that could be unavailable for several minutes a day. By enabling the concept of availability set, we are asking Azure to replicate our existing virtual machine configuration to several different physical racks within a single datacenter. This does protect you against something like a rack outage, which could be related to a power supply or a network connectivity issue. If you spend the additional expenses on enabling the availability set, it does take up more disk space at the Azure datacenter and your costs will go up, but you can see that the service level agreement is increased to 99 .95%. That is a fairly significant upgrade, but still not protecting you in the event that an entire datacenter in an Azure region would become unavailable. Datacenters are referred to as zones, and you can see if you were to enable availability zones for the virtual machine, as it shows you in the third column, it's actually going to replicate your virtual machine amongst three different zones in the single Azure region. They will grant you a service level agreement of four nines, 99 .99%. This is the best replication you can get without moving forward to doing a true disaster recovery using Azure's recovery services tools. These are the ways that you can protect a virtual machine in terms of physical outages within the Azure datacenter. The traffic manager is a tool that can be used to expose multiple web applications behind a single domain name. This is the best way for an organization to create a resilient web application based on application services or virtual machines that are running the web application in multiple regions or potentially even a backup instance in your on -premises datacenter. The user will use a browser to connect to Azure's DNS service to attempt to find the web server. Normally, that would return a single IP address to all browsers, meaning all browsers, all connections across the world would be retrieving their web services or websites from a single location. By enabling the traffic manager, requests for a web service are sent to a service running within the Azure cloud. The traffic manager service can actually analyze the client connection to determine where the client is coming from and also know what sort of instances of the web application are enabled in the background. This would allow you to host your application in many Azure including inside your local datacenter, and the traffic manager would be able to direct clients to different running instances of your web application to help them improve their performance by connecting them to the server closest to them or avoiding environments that are experiencing outages and making sure that your application stays up in a resilient way. Another way to protect one of the common resources in an Azure subscription is to enable replication within storage accounts. I'm going to select storage account from the Azure menu to help enable replication within one of our file storage services. By clicking on storage account, you can see we have one already configured. Let's click on it. In the configuration screen for the storage account, on the bottom left -hand menu is an option to click on redundancy. You can see here that right now, this storage account only exists in the East US. This is called locally redundant storage. This is the cheapest option because this does only keep one copy of this data within the Azure cloud. You can see, though, that we could convert this to geo -redundant storage. If we do, what this is going to do is replicate our environment to another data center within the Azure cloud automatically. The advantage of doing geo -redundant storage is that it does create two copies of the data, but you do need to remember that they will be incurring additional charges. Because you have two copies of the data, you will be spending double the budget every month on the amount of disk space that you are incurring. However, you can see here, as it shows in the diagram, it has given you an automatic replica of the entire contents of the storage account in the closest data center, in this particular case, the West US. This protects you in case there is some sort of regional natural disaster that would mean a data center would be unavailable. This provides you with a complete copy of your storage account in a different location. Stay tuned for the next lesson where I will show you how to use Azure Backup to backup and restore files from Azure services. Thanks for watching.
