Options for providing HA for the SAP Central Services in the Microsoft Azure public cloud without the need for a traditional operating system cluster.

1. SAP
(A)SCS
High
Availability
in
Azure

2. 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.
Drivers

3. • 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
the
SAP
(A)SCS

4. • 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
High
Availability
in
Azure

5. • 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
Host
#1
Azure
Hyper-­‐V
Host
#2
About
Azure
Availability
Sets

6. • 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.
On
Premise Azure
Azure
Subscription
Physical
or
VM
Server
IP
Address
NIC
VM
Server
IP
Address
Private|Public
IP
Address
NIC
IP
address
can
be
moved
to
another
VM
using
O/S
level
tools
IP
address
can
only
be
moved
to
another
VM
using
Azure
“aware”
software
tools.
About
Azure
VM
IP
Address
Resources

7. • A software defined load balancer with port routingin 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 availabilityofback-­‐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

8. Azure
Subscription(s)
Azure
Internal
Load
Balancer
ASCS
Server
Primary
ILB
IP:
10.0.0.1
(ASCS
IP)
ASCS
Ports:
3600,
3901
etc
IP:
10.0.0.3
IP:
10.0.0.4
ASCS
Server
Secondary
Front-­‐End
IP
&
“listen”
Ports
Back-­‐End
Pool Probe
Ports
NIC
NIC
Flow
Rules
(port
mappings)
Probes
determine
health
status
for
routing
to
back-­‐end
pool
members.
A
back-­‐end
member
cannot
talk
to
itself
via
the
ILB
!
There
are
2x
SKUs:
STANDARD
or
BASIC.
For
STANDARD
SKU
IP
addresses
you
must
have
STANDARD
ILB.
About
Azure
Internal
Load
Balancer

9. • #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.
Options
for
ASCS
High
Availability
in
Azure

10. Azure
Subscription(s)
Azure
Internal
Load
Balancer
ASCS
Server
Primary ASCS
Server
Standby
Cluster
IP:
10.0.0.2
SAP
EN
SAP
MS
SAP
ERS
SAP
App
Server
1
SAP
App
Server
1SAP
GUI
SAP
EN
SAP
MS
SAP
ERS
(offline)
ILB
IP:
10.0.0.1
(ASCS
IP)
IP:
10.0.0.3 IP:
10.0.0.4
Option
#1
– Classic
High
Availability
Cluster

11. • 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 controlledfailover process.
• Azure Internal Load Balancer required to direct
traffic to standby (because cluster software cannot
move IP address from primary to standby).
Option
#1
– Classic
High
Availability
Cluster

12. Azure
Subscription(s)
Azure
Internal
Load
Balancer
ASCS
Server
Primary ASCS
Server
Standby
SAP
EN
SAP
MS
SAP
ERS
SAP
App
Server
1
SAP
App
Server
1SAP
GUI
SAP
EN
(offline)
SAP
MS
(offline)
SAP
ERS
(offline)
ILB
IP:
10.0.0.1
(ASCS
IP)
IP:
10.0.0.3 IP:
10.0.0.4
?
Option
#2
– Classic
Redundant
Hosts

13. • 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
#2
– Classic
Redundant
Hosts

14. Azure
Subscription(s)
Azure
Internal
Load
Balancer
ASCS
Server
Primary
ASCS
Server
Standby
SAP
EN
SAP
MS
SAP
ERS
SAP
App
Server
1
SAP
App
Server
1SAP
GUI
SAP
EN
(offline)
SAP
MS
(offline)
SAP
ERS
(offline) SAP
LaMa
with
Azure
Cloud
Connector
?
Azure
APIs
Option
#3
– Classic
Redundant
Hosts
++

15. • Classic 2x server setupwith auto-­‐failuredetection.
• EnqueueReplication Server(ERS) replicatesEN to ERS on standby.
• Primary VM failuredetectedbySAP LaMa viaAzure Cloud Connector.
• LaMa eventworkflowcontrolsstart-­‐upof secondary MS & EN.
• LaMa instigatesSTONITHon 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 instigatedetectionandfailoverto standby.
• Azure Automation would require custom integration to start/stop the
SAP applicationlayers.
Option
#3
– Classic
Redundant
Hosts
++

16. • 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.
Conclusion

17. 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
References

18. Thank
You