Considerations to note while using Azure Availability Zones
Notes from the official documentation -
Azure Availability Zones is one of the high-availability features that Azure provides.
Using Availability Zones improves the overall availability of SAP workloads on Azure.
Consider the following when you use Availability Zones:
* This feature is available only in some Azure regions.
* There are no guarantees regarding the distances between various Availability Zones within an Azure region.
* Availability Zones are not an ideal DR solution. Natural disasters can cause widespread damage in world regions, including heavy damage to power infrastructures. The distances between various zones might not be large enough to constitute a proper DR solution.
* The network latency across Availability Zones is not the same in all Azure regions. In these cases, the deployment architecture needs to be different, with an active/active architecture for the application or an active/passive architecture where cross-zone network latency is too high. In the case of latency between the two DBMS instances that need to have synchronous replication, the higher the network latency, the more likely it will affect the scalability of your workload.
* You must use Azure Managed Disks when you deploy to Azure Availability Zones while deploying Azure VMs across Availability Zones and establish failover solutions within the same Azure region. Unmanaged disks aren't supported for zonal deployments.
* You can't deploy Azure availability sets within an Azure Availability Zone unless you use Azure Proximity Placement Group.
* You can't use an Azure Basic Load Balancer to create failover cluster solutions based on Windows Server Failover Clustering or Linux Pacemaker. Instead, you need to use the Azure Standard Load Balancer SKU.
Some customers are using zones for a combined HA and DR configuration that promises a recovery point objective (RPO) of zero. This means that you shouldn't lose any committed database transactions even in the case of disaster recovery. Microsoft recommends that you use a configuration like this only in certain circumstances. For example, you might use it when data can't leave the Azure region for security or compliance reasons.
Azure Availability Zones is one of the high-availability features that Azure provides.
Using Availability Zones improves the overall availability of SAP workloads on Azure.
Consider the following when you use Availability Zones:
* This feature is available only in some Azure regions.
* There are no guarantees regarding the distances between various Availability Zones within an Azure region.
* Availability Zones are not an ideal DR solution. Natural disasters can cause widespread damage in world regions, including heavy damage to power infrastructures. The distances between various zones might not be large enough to constitute a proper DR solution.
* The network latency across Availability Zones is not the same in all Azure regions. In these cases, the deployment architecture needs to be different, with an active/active architecture for the application or an active/passive architecture where cross-zone network latency is too high. In the case of latency between the two DBMS instances that need to have synchronous replication, the higher the network latency, the more likely it will affect the scalability of your workload.
* You must use Azure Managed Disks when you deploy to Azure Availability Zones while deploying Azure VMs across Availability Zones and establish failover solutions within the same Azure region. Unmanaged disks aren't supported for zonal deployments.
* You can't deploy Azure availability sets within an Azure Availability Zone unless you use Azure Proximity Placement Group.
* You can't use an Azure Basic Load Balancer to create failover cluster solutions based on Windows Server Failover Clustering or Linux Pacemaker. Instead, you need to use the Azure Standard Load Balancer SKU.
Comments
Post a Comment