Introduction: Region redundant deployment of the public cloud resources are quite popular because it builds resilience and improves availability. However, regions are quite far apart for 2ms latency perimeter. Availability zones are within the same region but distinct from one another. Each zone comprises of one or more data centers. Each region may have three availability zones. These zones maintain synchronous replication, withstand datacenter failures and ensure minimal customer impact. This article describes what it takes to get a service ready for Azure availability zones.
Description: Availability Zones (AZs) are easy
to opt into and guarantee 99.99% uptime SLA. Though they sound like
Availability sets, the AZs comprise of datacenters with independent power,
cooling and networking and the availability sets are logical groupings of
virtual machines. AZ is a combination of both a fault domain as well as an
update domain, so changes do not occur at the same time. Services that support
availability zones fall under two categories: zonal services – where a resource
is pinned to a specific zone and a zone-redundant service for a platform that
replicates automatically across zones. Business continuity is established with
a combination of zones and azure region pairs.
Azure classifies services into three categories -
foundational, mainstream and specialized. Service categories are assigned at
general availability. They start their lifecycle as a specialized service and
as demand and utilization increases, it may be promoted to mainstream or
foundational. A specialized service has demand driven ability across regions.
It might require customizations. A
mainstream service is one that is available in all recommended regions. A
foundational service is one that is available in all regions where the region
is generally available. Some examples of services that support zone-redundant
services under each of the three categories can be listed as below:
Zone-resilient:
- Foundational
service: Application gateway v2, Cosmos DB, Express Route, Disk Storage, Key
Vault, Load Balancer, Service Bus, Service Fabric, Virtual Network, VPN
Gateway.
- Mainstream
service: Azure Cognitive Search, Active Directory services, Azure API
management, Data Explorer, Firewall, Site recovery, Power BI, Virtual WAN.
- Specialized
service: OpenShift, Bot Service, Front
Door, Managed applications, Resource Graph, Azure Stack, Microsoft Graph,
security center and Traffic manager
The availability zones can be queried from SDK, and they are
mere numbers within a location. For example: az vm list-skus --location eastus2
--output table will list vm skus based on region and zones. The zones are
identified by numbers such as 1, 2, 3 and these do not mean anything other than
that the zones are distinct. The numbers don’t change for the lifetime of the
zone, but they don’t have any direct correlation to physical zone
representations.
There are ways in which individual zone-resilient services
can allow zone-redundancy to be configured.
The clients in the sdk for these services have a builder
pattern where there is an option to specify the redundancy rules as well as a
supported region via the location parameter.
Resources can also be requested to be created in a zone redundant
service at a specific location by mentioning a supported region where the
availability zones are present. This might entail other resources to be
collocated in the same region.
No comments:
Post a Comment