This document discusses placing the SAP Application Server Central Services (ASCS) into containers on Kubernetes. It proposes using containers for the ASCS and Enqueue Replication Server (ERS) with anti-affinity rules to ensure high availability without traditional clustering. Benefits include simplified high availability without requiring cluster technology while still providing required features and allowing SAP systems to utilize anonymous compute nodes rather than dedicated hardware. Considerations include licensing and ensuring the Message Server and ERS are never placed on the same node.

1. SAP (A)SCS on Kubernetes

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. • SAP customers are always demanding more value from technologies that are
seen as common within the IT landscape.
• Using an existing Conainer (e.g. Kubernetes) deployment, for hosting the SAP
ASCS could release defined hardware from sole allocation to the SAP estate.
• Using containers for the ASCS has benefits around the HA aspect by not
requiring cluster technology, yet still being able to provide the required HA
features.
About this Proposal

4. • A key part of the SAP Netweaver ABAP stack since it’s original inception as
part of the Central Instance concept of the early SAP R/3.
• Provides critical application layer locking mechanism for business objects
within the SAP system/database.
• Contains built-in process availability protection (restart) since the advent of
the SAP instance agent (sapstartsrv).
• Architecturally compliant in many cluster scenarios.
• Contains 2 critical processes: Message Server and Enqueue Server.
About SAP (A)SCS

5. • EN2 is the next generation of the Enqueue Server component within the ASCS.
• Provides improved reliability through a slightly different mechanism for HA.
• Not wildly different to the older version, therefore inherent technical skills will
still be useable.
• New transaction SMENQ to manage/administer.
About SAP Enqueue 2 (EN2)

6. • Is it possible to place the ASCS into a container?
• Is there a benefit to simplified HA (no traditional clusters)?
• Is this the natural progression of SAP onto “anonymous” nodes instead of
nominated “hardware”?
Proposal
Containerization of EN2

7. POD (ASCS)
Container
SAP
MS
SAP
EN2
POD (ERS)
Container
SAP
ERS
HA NFS
sapmnt
ContainerServices
Dialog
WPWP
SAPNWABAP
Dialog
WPWP
Proposed Architecture
Proposal

8. POD (ASCS)
Container
SAP
MS
SAP
EN2
POD (ERS)
Container
SAP
ERS
Host
#1
NODE
Host
#2
NODE
ACTIVE
Host
#3
NODE
ACTIVE
Container Services
Anti-Affinity
using
nodeSelector
Normal Operation
Proposal

9. POD (ASCS)
Container
SAP
MS
SAP
EN2
POD (ERS)
Container
SAP
ERS
Host
#1
NODE
Host
#2
NODE
ACTIVE
Host
#3
NODE
ACTIVE
Container Services
ACTIVEACTIVE
Failure Operation
Proposal

10. POD (ASCS)
Container
SAP
MS
SAP
EN2
POD (ERS)
Container
SAP
ERS
Host
#1
NODE
Host
#2
NODE
ACTIVE
Host
#3
NODE
ACTIVE
Container Services
Anti-Affinity
using
nodeSelector
Resuming Operation
Proposal

11. • EN2 and ERS pods need to be under same jurisdiction of the same Kubernetes
master.
• Anti-affinity is critical to ensure EN2 and ERS are never on the same node.
• The Message Server would need license keys for each possible node that it
could be running on.
Is this even possible to be known in a Container environment?
Considerations

12. SAP Notes:
• 2630416 - Support for Standalone Enqueue Server 2
• 538081 - High-availability SAPLICENSE.
• 181543 - License key for high availability environment
SAP Guides:
• https://help.sap.com/viewer/cff8531bc1d9416d91bb6781e628d4e0/1709%20002/en-
US/6d655c383abf4c129b0e5c8683e7ecd8.html
HA with SAP EN2
• https://help.sap.com/viewer/cff8531bc1d9416d91bb6781e628d4e0/1709%20002/en-
US/a2d5c422cfff4fc286bc571965451093.html
Failover of EN2
Container Guides:
• https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
Kubernetes anti-affinity.
• https://kubernetes.io/docs/concepts/architecture/nodes/
Kubernetes node architecture overview.
References

13. Thank You