In this first part, it will explain the scope of work, objectives, installation, and how to develop ABAP in testing.
1. Scope of Work
Each ABAB system is divided into 3 parts: the first is the database used to store data and programs, the second is the application server, and the third is the client. The discussion of this POC only covers the server application.
The ABAB SAP NetWeaver Application Server can be broken down into several sections, each of which can be placed in a container. The Server Instance application is prioritized to be placed in containers
because it doesn't have a big impact on other applications, and their needs tend to be easily measured. However, we can also choose to deploy several mandatory components from ABAB Central Services, namely Message Server and Enqueue Server. In the final stage, we deploy SAP Webdispatcher and SAP Router to be configured.
The discussion of the SAP HANA database is beyond the current discussion, the SAP Hana database is considered to provide an external resource that can be linked through a credential configuration.
2. Configuration
Docker Image and Kubernetes Deployment File
In Kubernetes, the application is "broken" before creating an image container with the Kuberntes YAML deployment file.
Our goal is to build an ABAP image with an environment that is configured using the Kubernetes YAML file. At the time of deployment, ABAP image will be injected into the Kubernetes environment.
Some of the attributes are static, cannot be changed, and will not be configured in this POC are:
SAP SID
SAP Instance Number
SAP Admin User
We also chose the most recent SAP Kernel and is compatible with NetWeaver and S4Hana.
3. Deployment in Kubernetes
Application Server
The real workload on the ABAP Application Server system is on the server side. On this side, memory and CPU will work more, besides the database. So it is important to define workload first. It is not recommended to reduce the capacity or scale down of the Application Server Instance because it risks damaging user sessions. Whereas deployment can be reduced to user-controlled orders, in contrast to "Statefulset" which is reversed-ordered which allows it to scale down regardless of the user's session load.
We solve the shutdown problem by implementing the "Horizontal Pod Autoscaler" logic: Priority annotations are assigned according to session load as they occur. Whenever scale down is done, the server with low priority will be shutdown.
As an application whose manufacturing process produces several log files, the sidecar container is used to pull logs and forward the target log to each Application Server pod.
Message Server and Enqueue Server
Message Server is a single instance, like an enqueue server. For better flexibility, an image container is created by placing it in 1 pods called ASCS (ABAP SAP Central Instance). Since it is necessary for the application server to reach the message server via static DNS, therefore placing ASCS pods in statefulset can solve the problem.
Since the message server becomes stateless, restarting the container is not critical. Enqueue Server keeps the table locked so it's not stateless. To implement high availability for enqueue server, it is recommended to create a backup enqueue server to store the results of copying tables. This is called enqueue replication and can be done by creating other singleton pods.
SAPRouter and Web Dispatcher
SAP Router functions to connect clients to the application server in accessing the system through the SAP GUI. Unlike the Kubernetes load balancer, the SAP Router knows the SAPDIAG protocol and forwards it to the session-related connection. SAP Router is stateless and can be scaled easily if needed.
Client Communication and Connectivity
After all SAP components are arranged in podernetes, we must ensure that all components can be connected to each other, including with clients.
- Services
Communication between pods in the Kubernetes cluster is done through services. Since Kubernetes does a port mapping automatically on the node where several pods open the identic port, this configuration allows the SAP application server to be upgraded on a single node without conflicts between ports. The statefullset Deployment and ASCS application servers are stored in the Kubernetes service.
–Load Balancer
Connections from external clients (SAP GUI, Web) to services are done by an external load balancer. The type of load balancer depends on the infrastructure in which Kubernetes runs. For this POC, we use OpenStack with HAProxy load balancer, like a bare-metal infrastructure. Deploy load balancers require an API connection to the IaaS layer.
–Load Balancer
Connections from external clients (SAP GUI, Web) to services are done by an external load balancer. The type of load balancer depends on the infrastructure in which Kubernetes runs. For this POC, we use OpenStack with HAProxy load balancer, like a bare-metal infrastructure. Deploy load balancers require an API connection to the IaaS layer.
–Namespaces
In the final stage, arrangements are made for all SAP Kubernetes objects in the Kubernetes Namespace which have been split into several clusters. Furthermore, several SAP Instances can be stored in a single cluster by dividing them into several namespaces, such as Sapqa, sapdev, sapprod.
