SAP

 (A)SCS  High  Availability  in  Azure

 Drivers
Automation Core
• Technology improvements mean computing tasks previously requiring interaction with people, can be
fully automated.
• Automation brings repeatability, reduced error rates, easy scalability of service provision.
Platform Agnostic
• Future interoperability and open standards will mean businesses can swap easily between cloud
providers.
• It is key that solutions are designed to operate in such a platform agnostic manner outside the bounds of
normal technical architecture design (i.e. no fixed O/S choices or fixed DB platforms).
Established Technological Principals
• Solutions today, should be built using already established technological principals.
• Using bleeding edge rarely produces the perceived benefits in places such as core business systems,
without significant buy-­‐in from business leaders.
• Pre-­‐empting standards not already widely adopted, could produce a “Beta-­‐Max” scenario.
Future Assurance
• Technology solutions should deliver for a minimum timeframe within the context of the lifecycle of the
related business system.
• Example: Re-­‐writing scripts during any platform migration should not just use the coolest scripting
language, they should use a commonly known language widely used and understood.
 About  the  SAP  (A)SCS
• ASCS = ABAP System Central Services.
• High availability of SAP System requires high availability of ASCS.
• ASCS includes Message Server (MS) & Enqueue (EN) Server processes.
• A failed EN Server process means users’ open transactions rolled back.
• A failed MS Server process means no new user logons possible.
• Protect the MS and EN and if you have at least 1 SAP application server
running, your SAP system will continue to run.
• HA of the ASCS is pointless without HA of the SAP Application Servers
(protection against Azure physical host updates!)
 About  High  Availability  in  Azure
• Primarily you need to protect against Azure underlying physical host failures.
They DO happen!
• Secondarily, provision for server downtime during Microsoft physical host
patching/maintenance. There is no magic that moves your VM to another
Azure physical host (not like vMotion).
• To protect your system: *You* must provision duplicate services into Azure
Availability Sets. For the SAP ASCS, this means you need at least two virtual
machines in one Azure Availability Set with the capability of running the ASCS
on either server.
 About  Azure  Availability   Sets
• A logical grouping of your virtual machines.
• Servers within a group are bound not to be running on the same underlying
physical host at the same time (like anti-­‐affinity rules).
• Availability Sets are assigned at Virtual Machine creation only.

Azure   Subscription(s)

ASCS  Server   Primary ASCS  Server   Standby

Azure  Availability   Set   #1

Azure  Hyper-­‐V   Azure  Hyper-­‐V  

Host   #1 Host   #2
 About  Azure  VM  IP  Address  Resources
• In on-­‐premise virtual machines (VMs) an IP address is assigned at the O/S
level.
• In Azure, an IP address resource is assigned at both the Azure subscription
level and the O/S level.
• Only Azure “aware” software (like SAP LaMa) can move the IP address resource
from one VM to another.
IP  address  can  be  
On  Premise moved  to  another  VM   Azure
using  O/S  level  tools  
Azure  Subscription
Physical   or  VM   Server VM   Server
IP  Address IP  Address
NIC
NIC
IP  address  can  only  be  
Private|Public
moved  to  another  VM   IP  Address
using  Azure  “aware”  
software  tools.
 About  Azure  Internal  Load   Balancer
• A software defined load balancer with port routing in SKU basic or standard.
• The ILB SKU must match the SKU of back-­‐end pool member VMs & IP resources.
• Uses probes (like a ping) to test and route network traffic to available back-­‐end
members.
• You are billed for an ILB once you’ve created one
• An ILB has an initial cost, plus potentially a cost for each of the ports you assign to
it.
• You can map to any IP address on a NIC of a back-­‐end member.
• You define an IP address for the ILB.
• You define the front-­‐end (listen) ports.
• You define the back-­‐end pools of virtual machines.
• You define a probe port and protocol for testing availability of back-­‐end members.
• You define flow rules that map front-­‐end ports to back-­‐end pools and destination
ports.
• Back-­‐end pool members cannot talk to themselves via the ILB (ILB is invisible to
them)!
 About  Azure  Internal  Load   Balancer
Azure   Subscription(s) ILB   IP:  10.0.0.1  (ASCS  IP) There  are  2 x  SKUs:
STANDARD
Front-­‐End   IP  &   “listen”  Ports or  BASIC.
For  STANDARD  SKU  IP  
Azure ASCS  Ports:   3600,  3901  etc addresses  you  must  
Flow  Rules Internal have  STANDARD  ILB.
(port  mappings)
Load   Balancer
Back-­‐End  Pool Probe   Ports Probes   determine  
health  status  for  
ASCS  Server   routing   to   back-­‐end  
Primary NIC pool   members.
IP:  10.0.0.3

ASCS  Server  
Secondary NIC
IP:  10.0.0.4 A   back-­‐end   member   cannot   talk   to   itself  via   the  ILB   !
 Options  for   ASCS  High  Availability  in  Azure

• #1  Classic  “on-­‐premise  style”  HA  cluster  – with  an  Azure  

twist.
• #2  Classic  “on-­‐premise  style”  redundant  servers  – with  
an  Azure  twist.
• #3  Classic  “on-­‐premise  style”  redundant  servers  – with  
auto-­‐detection  and  an  Azure  twist.
 Option  #1  – Classic   High   Availability   Cluster
Azure   Subscription(s)
SAP
SAP
App   Server  1
SAP  GUI ILB   IP:  10.0.0.1  (ASCS  IP) App   Server  1
Azure
Internal
Load   Balancer
ASCS  Server   Primary ASCS  Server   Standby

SAP  MS SAP  MS Cluster

IP:  10.0.0.2
SAP  EN SAP  EN

SAP  ERS SAP  ERS

(offline)
IP:  10.0.0.3 IP:  10.0.0.4
 Option  #1  – Classic   High   Availability   Cluster
• Classic HA active-­‐active cluster setup.
• Enqueue Replication Server (ERS) replicates EN to
ERS on standby.
• Failover to standby detected by cluster software
and:
• Handled  automatically  by  cluster  software.
or
• Manual operator controlled failover process.
• Azure Internal Load Balancer required to direct
traffic to standby (because cluster software cannot
move IP address from primary to standby).
 Option  #2  – Classic   Redundant  Hosts
Azure   Subscription(s)
SAP
SAP
App   Server  1
SAP  GUI ILB   IP:  10.0.0.1  (ASCS  IP) App   Server  1
Azure
Internal ?
Load   Balancer
ASCS  Server   Primary ASCS  Server   Standby

SAP  MS SAP  MS

(offline)
SAP  EN SAP  EN
(offline)

SAP  ERS SAP  ERS

(offline)
IP:  10.0.0.3 IP:  10.0.0.4
 Option  #2  – Classic   Redundant  Hosts

• Classic   2x  server   setup.

• Enqueue  Replication   Server  (ERS)  replicates  EN  
to  ERS  on  standby.
• Failover  to  standby   is  operator  controlled.
• Azure  Internal  Load   Balancer   required  to  direct  
traffic  to  standby  (but   this   depends  on  the  level  
of  the   operator  – they  could  move  the   IP  in  
Azure  or  adjust   DNS).
 Option  #3  – Classic   Redundant  Hosts   ++
Azure   Subscription(s)
SAP
SAP
App   Server  1
SAP  GUI App   Server  1
Azure
Internal ?
Load   Balancer
ASCS  Server   ASCS  Server  
Primary Standby
SAP  MS SAP  MS
(offline)
SAP  EN SAP  EN
(offline)

SAP  ERS SAP  ERS Azure  

(offline)
APIs
SAP  LaMa
with  Azure   Cloud  
Connector
 Option  #3  – Classic   Redundant  Hosts   ++
• Classic 2x server setup with auto-­‐failure detection.
• Enqueue Replication Server (ERS) replicates EN to ERS on standby.
• Primary VM failure detected by SAP LaMa via Azure Cloud Connector.
• LaMa event workflow controls start-­‐up of secondary MS & EN.
• LaMa instigates STONITH on primary (belt & braces).
• Azure Internal Load Balancer required to direct traffic to standby (but
this depends on the level of LaMa integration – LaMa could move the
IP in Azure).
• As an alternative to LaMa, it’s possible to use native Azure Automation
to instigate detection and failover to standby.
• Azure Automation would require custom integration to start/stop the
SAP application layers.
 Conclusion
• Protection  of  the  SAP  ASCS  from  faults  is  critical.
Provisioning  for  Azure  physical  host  maintenance  is  
critical.
• Apart  from  a  few  specific  areas,  HA  of  the  SAP  ASCS  
in  Azure  is  almost  the  same  as  on-­‐premise,  but  with  
an  Azure  twist  (the  ILB).
• The  Azure  fabric  itself  provides  a  number  of  
opportunities  to  integrate  directly  between  Azure  
and  the  SAP  system,  providing  seamless  integration  
between  the  infrastructure  and  the  SAP  system  and  
reducing  the  need  for  third-­‐party  software.
 References
Microsoft  Docs:
• Azure  virtual   machine   high   availability   for  SAP  Netweaver:   https://docs.microsoft.com/en-­‐us/azure/virtual-­‐
machines/workloads/sap/sap-­‐high-­‐availability-­‐guide
• Azure  Load   Balancer   Overview:   https://docs.microsoft.com/en-­‐us/azure/load-­‐balancer/load-­‐balancer-­‐overview
• Azure  Availability   Sets   Overview:   https://docs.microsoft.com/en-­‐us/azure/virtual-­‐machines/windows/manage-­‐
availability#configure-­‐multiple-­‐virtual-­‐machines-­‐in-­‐an-­‐availability-­‐set-­‐for-­‐redundancy
• Azure  Update  Domains   Overview:     https://docs.microsoft.com/en-­‐us/azure/virtual-­‐
machines/windows/manage-­‐availability
• Azure  Automation  Overview:   https://docs.microsoft.com/en-­‐us/azure/automation/automation-­‐intro
• Reference   architecture:   https://docs.microsoft.com/en-­‐us/azure/architecture/reference-­‐architectures/sap/sap-­‐
netweaver

SAP  Docs/Notes:
• Netweaver 7.5  Master   Guide:   https://help.sap.com/doc/18cb1a50b9924bc3b94c2988cc8c51d9/7.5/en-­‐
US/mg_nw_75.pdf
• SAP  Lock   Concept:   https://help.sap.com/viewer/6568469cf5a1460a8d85c58b83d21ec2/7.5.13/en-­‐
US/47df116e6abf296fe10000000a42189b.html
• SAP  ASCS  HA:   SAP  Note  1678705  "Installation  scenarios   for  a   standalone   ASCS  instance"   v4
• SAP  LaMa   Azure   Connector:  SAP  Note  2343511  "Microsoft  Azure  connector   for  SAP  Landscape   Management  
(LaMa)"  v6
Thank   You