Chapter 14: High Availability and Redundancy Concepts

In the previous two chapters, we examined how to create scalable databases and the different options for integrating them using data flows.

This chapter looks at how we can ensure our solutions are highly available and automatically respond to failures.

Many Azure components, especially Platform as a Service (PaaS) and serverless options such as Azure Functions, automatically implement high availability. We examined how to best leverage and architect applications to take advantage of those features in Chapter 11, Comparing Application Components.

However, Infrastructure as a Service (IaaS) components such as virtual machines need more thought to respond to outages. Azure storage and Azure databases offer more options on top of the default configuration to expand the concept of high availability across regions. Again, we touched on this in Chapter 12, Creating Scalable and Secure Databases, when investigating the use of...

Technical requirements

This chapter will use the Azure portal (https://portal.azure.com) for examples.

Understanding virtual machine availability

A common misconception in Azure is that VMs are automatically highly available. Although this may be true to a certain extent as the failure of hardware results in a VM being moved to healthy hardware, this process temporarily interrupts the accessibility of that VM.

Additionally, during maintenance events, the Azure platform may need to forcefully reboot your VM. This is performed gracefully, but again it causes a brief outage for your workload.

Finally, in the unlikely event of an entire region outage, for example, due to networking failure, your VMs will be inaccessible until that outage is rectified.

Another aspect of your VM availability is the type of disks you choose to build it with. Standard magnetic HDDs have the lowest availability, whereas premium SSDs have the greatest due to how they are used and distributed.

These factors can have a significant impact on the Service-Level Agreement (SLA) of your service. For example...

Understanding Azure storage resiliency options

Azure storage accounts have several options when creating them to define how the data within them is protected and made available in the event of hardware or even regional failure.

We looked in detail at storage accounts in Chapter 9, Exploring Storage Solutions, where we looked at different replication options such as locally redundant storage (LRS) and geo-redundant storage (GRS).

To recap, data in Azure is always replicated to ensure durability and high availability. Storage replication can be set during the creation of a storage account; however, you can change the type of replication later by using the Azure portal, PowerShell, or the CLI.

In the event of an outage of the region that contains your storage account, failover is not automatic. You must manually switch your secondary replica to be the primary. Note that because data is copied from one region to another asynchronously, that is, the data is copied to the secondary...

Understanding SQL database availability

Even when your databases are hosted in Azure, there is still a chance that failures and outages will occur. In the case of an outage (such as a total regional failure, which a natural disaster could cause, an act of terrorism, war, a government action, or a network or device failure external to the data centers of Microsoft), your data still needs to be accessible.

In Chapter 12, Creating Scalable and Secure Databases, we looked at database service tiers chosen when creating a SQL Server database – the General tier, Hyperscale tier, and Business Critical tier.

With the General and Hyperscale tiers, by default, data is replicated within a single region. However, it Is not regionally redundant. This is partly due to how data is protected within them. Essentially, data is stored in Azure storage accounts and therefore uses that underlying technology to spread and replicate data among physical disks. However, there is still only ever one...

Understanding Cosmos DB availability

Azure Cosmos DB is built with availability in mind. The underlying database of a Cosmos DB account is written to four replicas with any given region – this is the default and minimal configuration in regard to availability.

You can optionally create one or more replicas of your databases in any Azure region that supports Cosmos DB. Replicas in other regions are also replicated within that region to four other replicas. For example, suppose you set up your Cosmos DB account to be multi-region across two regions. In that case, you will have eight replicas of your data – four in the primary and four in the secondary regions.

Although data within a region is replicated four times, it is not stored across Availability Zones by default. This is an optional configuration applied to a Cosmos DB account in regions that support high-Availability Zones.

Another factor to consider when using Cosmos DB with global replication is whether to...

Summary

In this chapter, we concluded Part 4, Applications and Databases by looking at the options for introducing high availability into our solutions.

Although many Azure components provide a redundancy level by default, some services require availability to be designed in, and others offer different levels of resilience depending on your needs.

We also looked at how we can apply these concepts to Azure VMs using scale sets, which enable us to automate the scaling of VMs based on demand and thresholds we can set.

We also looked at the different Azure storage accounts and databases, namely Azure SQL and Azure Cosmos DB. These services provide a default level of local redundancy, meaning you are protected against hardware failure. However, we examined how this can be extended across regions should it be required.

In the next chapter, we begin Part 5, Operations and Monitoring, starting with the different ways to set up logging and monitoring components.

Exam scenario

MegaCorp Inc. has an e-commerce application that they wish to expand to serve global customers, but they are concerned about performance. Local distribution centers in each region (the Americas, Europe, and Asia) perform their order shipping and management. The performance and a local view of stock levels within each region are important. However, a consolidated global view is still required for reporting purposes, but as reports are run in the evening, an up-to-date view of levels across regions is not required.

Currently, the application is built using traditional VMs because it requires specific OS components and custom modules to be installed. The backend database has been built with NoSQL in mind, currently being used on a Mongo DB. The application team has tested and confirmed the solution can be migrated to Cosmos DB using the MongoDB APIs with little effort.

Currently, there are only 2 VMs and a load balancer running the application. Although these VMs are...

Further reading

For more information on topics covered in this chapter, you can refer to the following links:

• Azure Scale Sets: https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview
• Azure SQL Availability Groups: https://docs.microsoft.com/en-us/azure/azure-sql/database/auto-failover-group-overview
• Azure Cosmos DB Consistency Levels: https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels