Azure Availability Zones vs Availability Set
Notes from various Microsoft sources -
Availability Zones (AZ) are fault-isolated locations, within an Azure region, providing redundant power, cooling, and networking. AZs allow your customers to run mission critical applications with high availability and fault tolerance to datacenter failures.
The goal of AZ is to serve and support applications that need to use synchronous data replication (the latency could be around 1.5 - 2.0 ms, official numbers may come after general availability release of AZ).
Azure Virtual Networks (VNETs) and Subnets, are and will remain "regional" entities. Once you will define in a region, they will be visible and usable across all the AZ since Network Resource Manager in Azure is region-wide. There is no AZ specification for these objects, VNETs and Subnets can cross AZ.
You can synchronously replicate your applications and data using Availability Zones within an Azure region for high-availability and asynchronously replicate across Azure regions for disaster recovery protection.
There are three Availability Zones per supported Azure region.
Availability Zones and Availability Sets cannot be used together: when creating a Virtual Machine (VM), you will have to specify an AS, or AZ assignment, you cannot do both.
AZs cannot be used for legacy Cloud Services (Worker and Web roles).
Only certain resources like Virtual Machine (VM), VM Scale Sets (VMSS), Managed disks (MD), Virtual IP (VIP) are available to be pinned to specific AZs
[To be verified: Azure Availability Zone does not compare with AWS Availability zones]
Availability sets ensure that the VMs you deploy on Azure are distributed across multiple isolated hardware nodes in a cluster. Doing this ensures that if a hardware or software failure within Azure happens, only a sub-set of your VMs are impacted and that your overall solution remains available and operational.
The now deprecated Affinity Groups were used earlier to group resources together in a datacenter
Azure region-pairs provide an even-larger isolation across an Azure geography for disaster recovery purposes.
Differences -
SLAs:
* 99.90% on single instance VMs with premium storage for an easier lift and shift; no other cloud provider so far provides this.
* 99.95% VM uptime SLA for Availability Sets (AS) to protect for failures within a datacenter.
* 99.99% VM uptime SLA through Availability Zones with loss protection from fire, power, cooling disruption.
Mutually exclusive: Availability Zones and Availability Sets cannot be used together: when creating a Virtual Machine (VM), you will have to specify an AS, or AZ assignment, you cannot do both.
ARM support only - Since there is no Azure Service Management (ASM) API support planned, AZs cannot be used for legacy Cloud Services
Bandwidth:
Following Availability Zone data transfer is charged:
* Data transfer, ingress and egress, from a VNet resource deployed in an Availability Zone to another resource in different Availability Zone in the same VNET
(Following Availability Zone data transfer is NOT charged:
* Data transfer between VNet resources located in same Availability Zone
* Data transfer between a VNet resource and a Public IP address in the same Azure Region
* Data transfer between VNet resources located in peered VNets across Availability Zones. This data transfer will be charges as per VNet peering rates.)
Current restrictions:
- Availability Zones are currently supported only in limited Regions
- Azure services that support Availability Zones fall into two categories:
+ Zonal services – where a resource is pinned to a specific zone (for example, virtual machines, managed disks, Standard IP addresses), or
+ Zone-redundant services – when the Azure platform replicates automatically across zones (for example, zone-redundant storage, SQL Database).
- The above categories including the following Azure services supporting Availability Zones:
* Linux Virtual Machines
* Windows Virtual Machines
* Zonal Virtual Machine Scale Sets
* Managed Disks
* Standard Load Balancer
* Standard IP address
* VPN Gateway
* ExpressRoute
* Zone-redundant storage
* SQL Database
* Event Hubs
- Supported virtual machine size families
* Av2
* Dv2
* DSv2
Last updated: 12/June/18
Also see: Azure Services that can be deployed into a Virtual Network
Availability Zones (AZ) are fault-isolated locations, within an Azure region, providing redundant power, cooling, and networking. AZs allow your customers to run mission critical applications with high availability and fault tolerance to datacenter failures.
The goal of AZ is to serve and support applications that need to use synchronous data replication (the latency could be around 1.5 - 2.0 ms, official numbers may come after general availability release of AZ).
Azure Virtual Networks (VNETs) and Subnets, are and will remain "regional" entities. Once you will define in a region, they will be visible and usable across all the AZ since Network Resource Manager in Azure is region-wide. There is no AZ specification for these objects, VNETs and Subnets can cross AZ.
You can synchronously replicate your applications and data using Availability Zones within an Azure region for high-availability and asynchronously replicate across Azure regions for disaster recovery protection.
There are three Availability Zones per supported Azure region.
Availability Zones and Availability Sets cannot be used together: when creating a Virtual Machine (VM), you will have to specify an AS, or AZ assignment, you cannot do both.
AZs cannot be used for legacy Cloud Services (Worker and Web roles).
Only certain resources like Virtual Machine (VM), VM Scale Sets (VMSS), Managed disks (MD), Virtual IP (VIP) are available to be pinned to specific AZs
[To be verified: Azure Availability Zone does not compare with AWS Availability zones]
Availability sets ensure that the VMs you deploy on Azure are distributed across multiple isolated hardware nodes in a cluster. Doing this ensures that if a hardware or software failure within Azure happens, only a sub-set of your VMs are impacted and that your overall solution remains available and operational.
The now deprecated Affinity Groups were used earlier to group resources together in a datacenter
Azure region-pairs provide an even-larger isolation across an Azure geography for disaster recovery purposes.
Differences -
SLAs:
* 99.90% on single instance VMs with premium storage for an easier lift and shift; no other cloud provider so far provides this.
* 99.95% VM uptime SLA for Availability Sets (AS) to protect for failures within a datacenter.
* 99.99% VM uptime SLA through Availability Zones with loss protection from fire, power, cooling disruption.
Mutually exclusive: Availability Zones and Availability Sets cannot be used together: when creating a Virtual Machine (VM), you will have to specify an AS, or AZ assignment, you cannot do both.
ARM support only - Since there is no Azure Service Management (ASM) API support planned, AZs cannot be used for legacy Cloud Services
Bandwidth:
Following Availability Zone data transfer is charged:
* Data transfer, ingress and egress, from a VNet resource deployed in an Availability Zone to another resource in different Availability Zone in the same VNET
(Following Availability Zone data transfer is NOT charged:
* Data transfer between VNet resources located in same Availability Zone
* Data transfer between a VNet resource and a Public IP address in the same Azure Region
* Data transfer between VNet resources located in peered VNets across Availability Zones. This data transfer will be charges as per VNet peering rates.)
Current restrictions:
- Availability Zones are currently supported only in limited Regions
- Azure services that support Availability Zones fall into two categories:
+ Zonal services – where a resource is pinned to a specific zone (for example, virtual machines, managed disks, Standard IP addresses), or
+ Zone-redundant services – when the Azure platform replicates automatically across zones (for example, zone-redundant storage, SQL Database).
- The above categories including the following Azure services supporting Availability Zones:
* Linux Virtual Machines
* Windows Virtual Machines
* Zonal Virtual Machine Scale Sets
* Managed Disks
* Standard Load Balancer
* Standard IP address
* VPN Gateway
* ExpressRoute
* Zone-redundant storage
* SQL Database
* Event Hubs
Also see: Azure Services that can be deployed into a Virtual Network
Comments
Post a Comment