Azure locations, regions, datacenters, fault domains, update domains, clusters, availability sets??

I was at a conference couple of weeks and we were discussing the latest improvements in Azure geo-redundancy across different locations…or was it regions or within different datacenters? But what about fault domains and upgrade domains? This blogpost will review the Azure datacenter model and explain the difference between all of those constructs.

 Azure Regions

The Azure datacenters are located around the world in strategic places that best meets the customer demands. These areas are known as Azure regions and are placed at a distance of at least 300miles or 480km from each other in case there is a natural disaster that would affect more than one region at a time.

Azure operates out of 20 regions around the world at the time of writing this blog post. Geographic expansion is a priority for Azure because it enables the customers to achieve higher performance and it supports their requirements and preferences regarding data location.

In the table below you can find the Azure regions and location. For the latest list of Azure datacenter locations, see Azure Regions.

Azure Region	Location
Central US	Iowa
East US	Virginia
East US 2	Virginia
US Gov Iowa	Iowa
US Gov Virginia	Virginia
North Central US	Illinois
South Central US	Texas
West US	California
North Europe	Ireland
West Europe	Netherlands
East Asia	Hong Kong
Southeast Asia	Singapore
Japan East	Tokyo, Saitama
Japan West	Osaka
Brazil South	Sao Paulo State
Australia East	New South Wales
Australia Southeast	Victoria
Central India	Pune
South India	Chennai
West India	Mumbai</p>

Before you can deploy anything in Azure you need to have an understanding of the following:

• What is a Region?
• Where are the regions located?
• What are the different capabilities of the regions with respect to each other?
• What are the preview features vs. general availability within a region?
• Are there any restrictions on where you can deploy to a region? For example: Legal compliance, Government regulations?

It is very important to correctly choose a region or regions that meet your organization’s needs. There are a number of elements to consider when choosing a region to deploy your applications and services:

• Data
• Location of service consumers
• Service capability and availability
• Network performance
• Pricing
• Redundancy for high availability

Data

Where the data is physically stored is very important for customers. When a storage account is created, the customer chooses the primary location for their storage account. However, the secondary location for the storage account is fixed and customers do not have the ability to change this. The following table shows the current primary and secondary location pairings:

Primary Region	Secondary Region
North Central US	South Central US
South Central US	North Central US
East US	West US
West US	East US
US East 2	Central US
Central US	US East 2
North Europe	West Europe
West Europe	North Europe
Southeast Asia	East Asia
East Asia	Southeast Asia
East China	North China
North China	East China
Japan East	Japan West
Japan West	Japan East
Brazil South	South Central US
Australia East	Australia Southeast
Australia Southeast	Australia East

Service capability and availability

Not all Azure services are available everywhere at the same time. Azure will first release a new feature in preview to only a subset of regions, prior to being generally available.

Before deploying an Azure service, review the following link and choose a region or regions to verify what services are available in your selected region: Services by region.

Network performance

It is best to validate the latency between the customer location and Microsoft Azure regions. Choose the one with the lowest latency, which will provide the best performance from a networking perspective. You can test the network latency with this tool for examaple: http://www.azurespeed.com/

Pricing

The pricing can be different for different regions for the same services. The cost for Azure Services is controlled by many factors. If latency is not important for your application you may deploy it in a region with a lower cost. In some regions however are only for a certain set of customers. The Australian region is only for customers with a business pressense in Australia or New Zealand. Please refer to the following site for the pricing details of each service provided by Microsoft Azure: Azure Pricing.

Datacenter Architecture

As described earlier, Azure hosts its services in a series of globally distributed datacenters. These datacenters are located in a specific location and are grouped together in regions. Datacenters within a given region are divided into “clusters,” which host the Azure services.  Within each datacenter, the racks of equipment are built to be fault tolerant on a networking, physical host servers, storage, and power level. The physical host servers are placed in high availability units called a cluster.

One single rack is referred to as a Fault Domain (FD), and it can be viewed as a vertical partitioning of the hardware. A second partition within the datacenter is called the Upgrade Domain (UD) and it can be viewed as a set of horizontal stripes passing through the vertical racks of fault domains. To provide redundancy to your application, we recommend that you group two or more virtual machines in an Availability Set. This configuration ensures that during either a planned or unplanned maintenance event, at least one virtual machine will be available. Each virtual machine in your Availability Set is assigned an Update Domain (UD) and a Fault Domain (FD) by the underlying Azure platform. The following diagram shows a high-level relationship between fault domains and update domains in the Azure datacenters.

Virtual machines are placed in specific fault domains and update domains based on the location of respective virtual machines in the same Availability Set.

Fault Domains

The fault domain is considered the lowest common denominator within the datacenter for fault tolerance. Microsoft Azure can lose a complete rack, and the hosted services can continue unaffected. FDs define the group of virtual machines that share a common power source and network switch. By default, the virtual machines configured within your Availability Set are separated across two FDs. While placing your virtual machines into an Availability Set does not protect your application from operating system or application-specific failures, it does limit the impact of potential physical hardware failures, network outages, or power interruptions.

Upgrade domains

Upgrade domains are used to deploy updates (security patches) within Azure without affecting the availability of the running services within the Azure fabric. For a given Availability Set, five non-user-configurable UDs are assigned to indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. When more than five virtual machines are configured within a single Availability Set, the sixth virtual machine will be placed into the same UD as the first virtual machine, the seventh in the same UD as the second virtual machine, and so on. The order of UDs being rebooted may not proceed sequentially during planned maintenance, but only one UD will be rebooted at a time.

Conclusion

I hope you have a understanding now of the differences between Azure regions, locations and so on and how the different Azure architectural constructs relate to each other.

Kind regards,

Alexandre Verkinderen