O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

SAP ASCS on Kubernetes - A Proposal

A an example of how the SAP ASCS could be operated in a Kubernetes pod environment.

  • Seja o primeiro a comentar

SAP ASCS on Kubernetes - A Proposal

  1. 1. SAP (A)SCS on Kubernetes
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Thank You