Change AvZone recommendations

Author: msjuergent

articles/sap/workloads/high-availability-zones.md

@@ -36,11 +36,12 @@ Consider the following when you use Availability Zones:
 
 - More information about Azure Availability Zones is presented in the document [Regions and availability zones](../../availability-zones/az-overview.md).
 - The experienced network roundtrip latency isn't necessarily indicative to the real geographical distance of the datacenters that form the different zones. The network roundtrip latency is also influenced by the cable connectivities and the routing of the cables between these different datacenters. 
-- Availability Zones aren't 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.
+- If you use Availability Zones as small distance DR solution, keep in mind that natural disasters can cause widespread damage in world regions, including heavy damage to power infrastructures. The distances between various zones might not always be large enough to compensate for larger natural disasters.
 - The network latency across Availability Zones isn't the same in all Azure regions. Even within an Azure region, the network latencies between the different zones may vary. Though even in the worst case, synchronous replication on the database level based on HANA System Replication or SQL Server Always On is going to work without impacting the scalability of the workload. 
 - When deciding where to use Availability Zones, base your decision on the network latency between the zones. Network latency plays an important role in two areas:
   - Latency between the two DBMS instances that need to have synchronous replication. Based on largest NetWeaver and S/4HANA deployments between zones with the largest network latencies (still less than 1.5 milliseconds), this consideration can be neglected
   - The difference in network latency between a VM running an SAP dialog instance in-zone with the active DBMS instance and a similar VM in another zone. As this difference increases, the influence on the running time of business processes and batch jobs also increases, dependent on whether they run in-zone with the DBMS or in a different zone (see later in this article)
+- The network latency with Azure Availability Zones, even in the largest zones, is sufficiently low to run SAP business processes. So far, we only saw a small number of exceptional cases where customers needed to co-locate the SAP application layer and DBMS layer under a single datacenter network spine.
 
 When you deploy Azure VMs across Availability Zones and establish failover solutions within the same Azure region, some restrictions apply:
 
@@ -52,10 +53,12 @@ When you deploy Azure VMs across Availability Zones and establish failover solut
 
 ## The ideal Availability Zones combination
 
+Nature of the SAP architecture is that, unless you configure it differently with e.g. using Logon Groups, RFC Server Groups, Batch Server Groups, etc, users and batch jobs can be executed in the different application instances across your SAP application layer. The side effect of this fact is that batch jobs might be executed by any SAP application instances independent on whether those run in the same zone with the active DBMS or not. If the difference in network latency between the difference zones is small compared to network latency within a zone, the difference in run times of batch jobs might not be significant. However, the larger the difference of network latency within a zone, compared to across zone network traffic is, the run time of batch jobs can be impacted more if the job got executed in a zone where the DBMS instance isn't active. It's on you as a customer to decide what acceptable differences in run time are. And with that what the tolerable network latency for cross zones traffic is for your workload. Purely from a technical point of view, the network latencies between Azure Availability Zones within an Azure region work for the architecture of NetWeaver, S/4HANA, or other SAP applications. It is also on you as a customer to potentially mitigate such differences using the SAP concepts of Logon Groups, RFC Server Groups, Batch Server Groups, and similar when you decide for one of the deployment concepts we are intorduciing in this article.
+
 If you want to deploy an SAP NetWeaver or S/4HANA system across zones, there are two architecture patterns you can deploy:
 
-- Active/active: The pair of VMs running ASCS/SCS and the pair of VMs running the DBMS layer are distributed across two zones. The number of VMs running the SAP application layer are deployed in even numbers across the same two zones. If a DBMS or ASCS/SCS VM is failing over, some of the open and active transactions might be rolled back. But users are remaining logged in. It doesn't really matter in which of the zones the active DBMS VM and the application instances run. This architecture is the preferred architecture to deploy across zones.
-- Active/passive: The pair of VMs running ASCS/SCS and the pair of VMs running the DBMS layer are distributed across two zones. The number of VMs running the SAP application layer are deployed into one of the Availability Zones. You run the application layer in the same zone as the active ASCS/SCS and DBMS instance. You use this deployment architecture if the network latency across the different zones is too high to run the application layer distributed across the zones. Instead the SAP application layer needs to run in the same zone as the active ASCS/SCS and/or DBMS instance. If an ASCS/SCS or DBMS VM fails over to the secondary zone, you might encounter higher network latency and with that a reduction of throughput. And you're required to fail back the previously failed over VM as soon as possible to get back to the previous throughput levels. If a zonal outage occurs, the application layer needs to be failed over to the secondary zone. An activity that users experience as complete system shutdown. In some of the Azure regions, this architecture is the only viable architecture when you want to use Availability Zones. If you can't accept the potential impact of an ASCS/SCS or DBMS VMs failing over to the secondary zone, you might be better of staying with availability set deployments
+- Active/active: The pair of VMs running ASCS/SCS and the pair of VMs running the DBMS layer are distributed across two zones. The number of VMs running the SAP application layer are deployed in even numbers across the same two zones. If a DBMS or ASCS/SCS VM is failing over, some of the open and active transactions might be rolled back. But users are remaining logged in. It doesn't really matter in which of the zones the active DBMS VM and the application instances run. This architecture is the preferred architecture to deploy across zones. In cases where the network latencies between zones is causing larger differences when executing business processes, SAP funcitonalities like Logon Groups, RFC Server Groups, Batch Server Groups, and similar can be used to route the execution of the business processes to specific dialog instances that are in the same zone with the active database instance
+- Active/passive: The pair of VMs running ASCS/SCS and the pair of VMs running the DBMS layer are distributed across two zones. The number of VMs running the SAP application layer are deployed into one of the Availability Zones. You run the application layer in the same zone as the active ASCS/SCS and database instance. You can use this deployment architecture if you deem the network latency across the different zones being too high and with that causing intollerable differences in the runtime of your business processes. Or if you want to use Availability Zone deployments as Short Distance DR deployments. the zones. If an ASCS/SCS or DBMS VM fails over to the secondary zone, you might encounter higher network latency and with that a reduction of throughput. And you're required to fail back the previously failed over VM as soon as possible to get back to the previous throughput levels. If a zonal outage occurs, the application layer needs to be failed over to the secondary zone. An activity that users experience as complete system shutdown. 
 
 So before you decide how to use Availability Zones, you need to determine:
 
@@ -89,9 +92,10 @@ In making these decisions, also take into account SAP's network latency recommen
 
 ## Active/Active deployment
 
-This deployment architecture is called active/active because you deploy your active SAP application servers across two or three zones. The SAP Central Services instance that uses enqueue replication are deployed between two zones. The same is true for the DBMS layer, which is deployed across the same zones as SAP Central Service. When considering this configuration, you need to find the two Availability Zones in your region that offer cross-zone network latency that's acceptable for your workload and your synchronous DBMS replication. You also want to be sure the delta between network latency within the zones you selected and the cross-zone network latency isn't too large.
+This deployment architecture is called active/active because you deploy your active SAP application servers across two or three zones. The SAP Central Services instance that uses enqueue replication are deployed between two zones. The same is true for the DBMS layer, which is deployed across the same zones as SAP Central Service. When considering this configuration, you need to find the two Availability Zones in your region that offer cross-zone network latency that's acceptable for your workload. You also want to be sure the delta between network latency within the zones you selected and the cross-zone network latency is acceptable for your workload.
+
+
 
-Nature of the SAP architecture is that, unless you configure it differently with e.g. using Logon Groups, RFC Server Groups, Batch Server Groups, etc, users and batch jobs can be executed in the different application instances. The side effect of this fact with the active/active deployment is that batch jobs might be executed by any SAP application instances independent on whether those run in the same zone with the active DBMS or not. If the difference in network latency between the difference zones is small compared to network latency within a zone, the difference in run times of batch jobs might not be significant. However, the larger the difference of network latency within a zone, compared to across zone network traffic is, the run time of batch jobs can be impacted more if the job got executed in a zone where the DBMS instance isn't active. It's on you as a customer to decide what acceptable differences in run time are. And with that what the tolerable network latency for cross zones traffic is for your workload. Purely from a technical point of view, the network latencies between Azure Availability Zones within an Azure region work for the architecture of NetWeaver, S/4HANA, or other SAP applications.
 
 A simplified schema of an active/active deployment across two zones could look like this: