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

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.

2 Comments

As a network engineer, I find the Azure Stack development fascinating. A few years ago I felt the future lay with a “data center in box” which would address the significant challenges VMs posed to the traditional networking architecture. As a result, I was wondering if Azure Stack can handle geo-replication for disaster recovery (can I effectively move a complete data center with the push of a button so to speak to another private location). If it comes close to this, I was wondering if any network design documents have been published to help the network engineer provide the needed infrastructure for Stack? thank you