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
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