June 20, 2019

Best practices to architect Resource Groups in Azure

On a workshop at the client, we were talking about what are the best practices to design an architecture for Resource Groups (RG) in Azure. This time we have a good time debating what will be the scenarios and what are the limitations when you come to architect and standardize the deployment of RG.

The most interesting scenario was evolving the limitation that RG have at the time of a region failure.

Let me explain. In case an organization is setting up the Primary and Secondary (known as DR) across two different regions, and for some reasons the created all the RG in one region, although the resources (example: VMS) are deployed based on the architecture bellow:

Primary Region: North Central
Second Region: South Central
All RGs: North Central only
Primary Resources: North Central (vNETs, VMs, Storage Accounts, etc)
Second Resources (DR & Backup): South Central (vNETs, VMs, Storage Accounts, etc)

With the scenario above what will happen if the primary region fails?

These are the experiences that you might feel:

  • The most obvious is the access to all the resource are impacted, this means that the resources might not stop running, but you will not able to access from outside of the region
  • Resource in other regions but located on the RG in the region unavailable are still accessible, although you cannot modify them (this means that “writing changes” are not possible)

What is the explanation for that?

The RG location does determine from the ARM side, which ARM region is responsible for writes and includes processing things like template deployment, regardless of which region the resource is in, so on a scenario where a complete region is gone there would be this issue as describe above. 

In regions with zones available, all zones would need to be down, so you don’t have the writes available, as ARM is configured with ZRS in those regions. As ARM (ie. management.azure.com) is a global service with a regional Compute and Storage deployments, Microsoft does have more flexibility for serving reads path transactions than writes. At the end, they also are served by the resource provider, which is often regional as well (example: RG in CentralUS with a VM in NorthUS and a user in Europe will go from management.azure.com to an ARM frontdoor in Europe based on a traffic manager to an ARM worker role in CentralUS to the Microsoft.Compute RP in NorthUS). 

What to do?

As a best practice for design and architecting RG, it’s recommended to create an RG per region, where the resource will be located. Having a 1-1 mapping between the RG and the actual location the resources, will mitigate these issues and have a less impact on your overall Azure deployment.

How I can prevent?

There is a built-in policy that can report when the resource location doesn’t match the resource group location as that is a great best practice.

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Written by Marcos Nogueira

Marcos Nogueira

With more than 18 years experience in Datacenter Architectures, Marcos Nogueira is currently working as a Principal Cloud Solution Architect. He is an expert in Private and Hybrid Cloud, with a focus on Microsoft Azure, Virtualization and System Center. He has worked in several industries, including Aerospace, Transportation, Energy, Manufacturing, Financial Services, Government, Health Care, Telecoms, IT Services, and Gas & Oil in different countries and continents. Marcos was a Canadian MVP in System Center Cloud & Datacenter Managenment and he has +14 years as Microsoft Certified, with more than 100+ certifications (MCT, MCSE, and MCITP, among others). Marcos is also certified in VMware, CompTIA and ITIL v3. He assisted Microsoft in the development of workshops and special events on Private & Hybrid Cloud, Azure, System Center, Windows Server, Hyper-V and as a speaker at several Microsoft TechEd/Ignite and communities events around the world.

Share

Marcos Nogueira

With more than 18 years experience in Datacenter Architectures, Marcos Nogueira is currently working as a Principal Cloud Solution Architect. He is an expert in Private and Hybrid Cloud, with a focus on Microsoft Azure, Virtualization and System Center. He has worked in several industries, including Aerospace, Transportation, Energy, Manufacturing, Financial Services, Government, Health Care, Telecoms, IT Services, and Gas & Oil in different countries and continents. Marcos was a Canadian MVP in System Center Cloud & Datacenter Managenment and he has +14 years as Microsoft Certified, with more than 100+ certifications (MCT, MCSE, and MCITP, among others). Marcos is also certified in VMware, CompTIA and ITIL v3. He assisted Microsoft in the development of workshops and special events on Private & Hybrid Cloud, Azure, System Center, Windows Server, Hyper-V and as a speaker at several Microsoft TechEd/Ignite and communities events around the world.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: