Learn how to plan a highly available compute infrastructure, by leveraging availability sets, storage replication strategies, and using the different Azure regions.
- [Instructor] Let's review regional and high availability frameworks that will keep your infrastructure up and running. As of this recording, May 2017, there are 34 Azure regions worldwide. The regions are paired with another region that is several hundred miles away to ensure redundancy in the case that the primary region becomes unavailable. Some of the pairings include the West US is paired with the East US. North Europe is paired with West Europe.
And Southeast Asia is paired with East Asia. Let's start by building a single virtual machine without any redundancy to demonstrate the vulnerabilities of this design. We have our primary region, and then within our primary region, we have our resource group. After we've created our resource group, we'll create our virtual network and subnets. Now let's go ahead and pop a virtual machine into that subnet. And our virtual machine happens to contain disks, which include an operating system disk, and in this example here, we have two data disks that have been attached to this virtual machine.
This is a separate process outside of provisioning the VM, and finally, when we create the VM, a temporary disk is created. This temporary disk is a scratch disk. And it's a physical solid state drive that sits on the Azure host system. And you will notice that each of these data disks has a corresponding VHD that sit in our storage account. And finally, we have a log storage account that contains our diagnostic logs. Here, you can see, if we lost our storage accounts or our virtual machine, we would not have access to that VM any longer.
Now, let's build on that single VM design, using a load balancer and availability sets. As before, we have our primary region and our resource group. We have our virtual network. And now we've created a web tier subnet, and you'll notice, within this web tier subnet, we have two virtual machines within an availability set. We will talk about availability sets in depth in a later chapter, but for now, just know that when you have two virtual machines in an availability set, one is always available to you.
Next, we've included a load balancer, which distributes our traffic among the virtual machines within the availability set, and each of these virtual machines has an associated storage account. And as before, we do have a log storage account. As you can see in this design, if we lose a storage account or a virtual machine, we have a secondary copy that can be used. Now let's go ahead and build on our previous design even further. As before, we have our primary region, we have our load balancer, and our web tier subnet.
In this example, we have three virtual machines within that subnet, within an availability set. Again ensuring that we always have a virtual machine available to us. Next, we now have a database tier, or a back end tier. In this case, we happen to be using SQL server. Therefore, we also have to have a witness virtual machine, and these machines are sitting in an availability set, ensuring that one virtual machine is always available. In addition, we also have an active directory subnet, which contains two active directory domain services servers.
By using this design, we ensure that we always have one VM available to us. And now, let's continue to build on this for regional availability. As before, we have our primary region with our two tiers and our active directory subnet. Then we'll go ahead and duplicate that to a secondary region. And as you can see, these two regions are exactly the same. This is Microsoft's reference architecture for an active-passive failover. If our primary region goes down, our secondary region is available.
And to ensure that the secondary region becomes available, if the primary goes down, we introduce the Azure traffic manager. The Azure traffic manager will direct the traffic to the secondary region if the primary region becomes unavailable. This reference architecture includes a SQL server always-on availability group. This is the best practice for SQL server when requiring high availability. And in order for SQL server always-on availability to work, we must include a VPN gateway subnet with the VPN gateway.
This allows the communication to flow between the two virtual networks, and for our data to be replicated from our data tier subnet in the primary region to the data tier subnet in the secondary region. Now that we've explored multi-region, let's move to replication strategy. Replicating your data ensures your data is durable and available, even if your primary region is down. And please, remember, I said replication. This is not a backup.
Replication does not protect you from the fat finger delete or a bad patch-up date. You will need to SLA for the specific storage replication strategy when using replication. Please refer to the storage SLA for details on the specific method, but on average, the SLA is 99 to 99.99%. In Azure, we have four types of replication. Your needs, and maybe even the cost, will dictate the type of strategy you use.
Let's go ahead and take a look at these four strategies. First we have our locally redundant storage, or LRS. When we use LRS, all of our data is contained within a single data center. This is great for tests and dev, maybe for backups. Next we have zone redundant storage, or ZRS. When we use this replication strategy, our data is replicated asynchronously to another data center in the same region. We also have geo-redundant storage, or GRS.
Which replicates our data asynchronously to another region. And finally, we have read-access geo-redundant storage, or RA-GRS. And just as the geo-redundant storage, our data is replicated asynchronously to another region, but it is also readable. Let's go ahead and compare these replication strategies in a little bit more detail. First, we have the number of copies. In LRS, we do have three copies, because these are within the same data center.
You'll also notice that ZRS has three copies. Now, this could actually be six copies, because you'll have three copies in one data center in the region, and then you will have another three copies in another data center within that same region. The GRS is six copies, because data is replicated from our primary region to our secondary region. Can our data be read from the secondary copy? In all cases, it is no, unless you're using the read-access geo-redundant storage. And finally, is your data replicated to another data center? In all cases, it is yes, except for our locally redundant storage.
In that case, our data is not replicated anywhere else. It sits within that single data center. And there are some storage replication considerations that you have to take into account. First of all, because of the delay with asynchronous replication, data loss may occur. You have to wait for Microsoft to initiate the failover in order for the copies to be available in another region. And finally, if you would like read-access, without having to wait for a failover to be initiated by Microsoft, then you will select read-access geo-redundant storage.
And just on a side note, this is actually the default setting. I know I'm starting to sound like a broken record, but the key to moving to Azure is planning, and then more planning. You are responsible for ensuring your infrastructure is always up and running. Understanding and using regional availability, high availability, and selecting the right storage replication strategy ensures your environment and resources are always available.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design