概念验证：在Kubernetes中部署ABAP

对于将SAP ABAP应用服务器组件容器化和在Kubernetes中部署它们，我们在SPA LinuxLab中做了概念验证（PoC），本文将介绍一些我们的发现和经验。本文会也会指出这项工作的一些潜在的收益和挑战。

作者：Richard Treu, Henning Sackewitz

英文原文：Proof of Concept: Deploying ABAP in Kubernetes

本文链接：https:////www.cnblogs.com/hhelibeb/p/12320295.html

请注意，本文档并非完整解决方案，当前不提供任何产品或开发内容。

参考 SAP note 1122387，可以获取有关当前ABAP应用服务器在容器（-orchestration）中运行的支持文档。

请随意评论和分享本文。

 

范围

每个ABAP系统都由三层组成：包含数据和程序的数据库，应用服务器和客户端。 此PoC的范围是ABAP应用服务器。

SAP NetWeaver Application Server ABAP可以分解为多个组件，因此它是容器化的主题。 容器化的第一个自然选择是应用服务器实例（AS），因为它们是堆栈中最无状态的部分，并且可以相对轻松地进行扩展。尽管如此，我们选择部署ABAP Central Services的强制性组件，即消息服务器（Message Server）和队列服务器（Enqueue Server）。 最后，我们还将可选的SAP Web Dispatcher和SAProuter添加到设置中。

底层SAP HANA数据库不在我们的PoC范围之内——它被视为给定的外部资源，可以通过安全存储证书连接。

我们的尝试是上面的组件放到单独的容器镜像里，把它们映射到合适的Kubernetes对象并通过某种方式关联到一起，使之可以良好的发挥Kubernetes的特性。

目标

创建一个通用的ABAP Kubernetes部署，可以集成到任何Kubernetes环境，无论它是on-premise, self-managed的k8s产品（比如CaasP, OpenShift）还是作为公有云服务的k8s产品（比如，GKE）。

安装

Docker镜像和k8s部署文件

在Kubernetes中，应用通过预构建的容器镜像和Kubernetes YAML部署文件分发。

我们的目标是构建通用ABAP镜像。可以使用特定于环境的输入参数来自定义ABAP镜像，输入参数可以通过Kubernetes YAML文件配置。 在部署时，参数被注入到Kubernetes环境中。 例如，HANA数据库连接参数将作为Kubernetes密钥注入。

一些属性是静态的、不可变的值，不能在此PoC中配置：

• SAP系统ID
• SAP实例号
• SAP管理员用户

另外，我们选择了最新的、向后兼容的SAP内核，可以与大多数NetWeaver和S/4 HANA版本一起工作。

部署应用服务器（AS）

ABAP系统中的实际工作负载是在服务器端会话中的应用服务器上执行的。 除了数据库，这是消耗大部分内存和处理能力的地方，因此这是最需要根据工作负载使用Kubernetes伸缩的实体。

随着工作负载的增加，扩展应用程序服务器Pod非常容易，但是如果随意销毁Pod，可能导致系统中的用户会话中断。

我们将应用程序服务器放置在具有一个初始副本的Deployment中。 可以按用户控制的顺序按比例缩小Deployment的大小。和StatefulSet不同，无论实际的用户会话负载如何，StatefulSet都只能按相反顺序的缩减Pod。

-----------------------------------

名词解释：

Pod：https://www.kubernetes.org.cn/kubernetes-pod

StatefulSet: https://www.kubernetes.org.cn/statefulset

Deployment: https://www.kubernetes.org.cn/deployment

-----------------------------------

我们通过“Pod水平自动伸缩”（Horizontal Pod Autoscaler）逻辑解决了硬关闭问题：根据当前的会话负载给Pod分配优先级注解。当执行缩减的时候，具有最低优先级的服务器会接收到软关机指令，会话会逐渐从该Pod结束。

应用工作进程会产生多个日志文件，sidecar container用于拉日志并把它们转发到每个应用服务器Pod的相应位置。因此日志文件可以持久化，用于分析工作进程失败和随之而来的容器重启。

消息服务器和队列服务器

根据设计，消息服务器是一个单例，队列服务器也是。为了更加灵活，我们为它们创建了单独的容器镜像，但是把它们放在了同一个Pod里，Pod的名字是ASCS（ABAP SAP Central Services）。

应用服务器需要通过静态DNS名访问消息服务器，我们将ASCS Pod放到了一个StatefulSet中，解决了这个问题。

消息服务器基本上无状态，因此容器重启并不重要。队列服务器会保持对表的锁，所以它不是完全无状态的。为了实现队列服务器的高可用，建议启用二级锁服务器，来保持一个锁表的副本。这被称为队列复制，可以通过创建另一个单例Pod实现。然而，这已经不在Poc的范围内了。

SAProuter和Web Dispatcher

为了通过GUI访问系统，SAProuter可以做到将客户端连接到正确的应用服务器。和Kubernetes负载均衡器相比，SAProuter拥有专有的SAP DIAG协议，可以把连接转发给相应的会话。SAProuter是无状态的，可以按需轻松伸缩。它可以被部署为Pod, DaemonSet或Deployment。

最后一个组件是Web Dispatcher，它是一个包含了专有安全特性和端点控制的负载均衡器。它同样是无状态的，可以按需伸缩。因为我们在PoC中只需要一个Web Dispatcher实例，我们把它和消息服务器、队列服务器绑到一个Pod中。

注意：可以跳过Web Dispatcher，使用Kubernetes负载均衡器直接连接应用服务器容器的ICM（Internet Communication Manager）进程。但是从安全角度来考虑，这么做可能有问题，并且会形成一个非标准的SAP安装。

通信和客户端连接

在全部的SAP组件都被组织成为Kubernetes Pod之后，我们必须确定它们彼此间、和外部客户端之间都可以正常通信。

服务

同一个Kubernetes集群中的Pod之间通过服务（Service）通信。由于Kubernetes会在节点(Node)进行自动的端口映射，不同的Pod会通过不同的端口暴露，这允许SAP应用服务器在单一节点扩展时不产生端口冲突。

-----------------------------------

名词解释：

Service: https://www.kubernetes.org.cn/kubernetes-services

-----------------------------------

应用服务器Deployment和ASCS StatefulSet都会封装到Kubernetes服务中。

负载均衡器

外部客户端（SAP GUI，Web浏览器）与服务的连接是通过外部负载均衡器完成的。 负载均衡器类型取决于运行Kubernetes的底层基础架构。 对于本PoC，我们将OpenStack与HAProxy负载平衡器以及裸机基础结构一起使用。 部署负载均衡器需要对IaaS层进行API调用，因此必须配置IaaS-specific Kubernetes Cloud Provider Interface（CPI）。 为简单起见，最后我们使用MetalLB作为负载均衡器。 我们还成功测试了HAProxy和硬件负载均衡器。

外部负载平衡器IP（其DNS可解析的主机名）是所有客户端通信的单一入口点。

负载均衡器实际上并不像其名称所表示的那样工作。 在此设置中，它仅用作外部通信入口点。 实际上，负载是由Web Dispatcher和消息服务器使用SAP登录组（SAP Logon Groups）来分配的。

命名空间

最后，我们将所有SAP Kubernetes对象组织在专用的Kubernetes命名空间“sap”中，以便与其它集群进行逻辑分离。
此外，可以通过将多个SAP实例分配到单独的命名空间（例如， “ sapqa”，“ sapdev”，“ sapprod”）来将它们部署在单个集群上。

PoC架构图

下图展示了所有这些东西是如何结合到一起的，

结论

原则上，可以在Kubernetes环境中运行ABAP。 它允许快速，灵活地部署，尤其是针对测试、开发和培训系统。 由于ABAP应用程序服务器组件的综合架构，会存在一些挑战和与Kubernetes功能的重叠之处，因此必须有对应地解决（例如负载均衡、名称解析、生命周期）。

好处

无需安装过程

由于有了预先构建的容器映像，因此无需像传统上在裸机硬件或虚拟机上那样安装每个新的ABAP实例。 我们只提供了Kubernetes部署文件和一些容器映像的集合，这些文件在Kubernetes集群中动态部署。

在几秒钟内（重新）部署ABAP实例

一旦下载并缓存了容器映像，Kubernetes将在非常短的时间内引导完整的ABAP系统。每当服务中断（例如硬件中断）时，将在可用的Kubernetes Worker节点上自动协调所有ABAP容器。

一键扩展大型系统

通过将可伸缩的应用服务器与ASCS分开放置在专用容器中，可以通过一个命令或一键扩展多个SAP对话框实例。由于对话实例的封装设计以及Kubernetes中虚拟服务端点的使用，扩展ABAP系统非常容易。

自动伸缩应用程序服务器

Kubernetes的标准功能包括根据CPU利用率或内存压力自动伸缩Pod。当检测到非常高或很低的负载时，可以利用这些自动伸缩功能来弹性伸缩ABAP系统。然后可以更有效地利用客户数据中心中共享的硬件资源，尤其是对于非生产性系统，而无需管理员进行任何实时干预。

部署多个相邻landscape

另一个好处是可以在同一环境中简单快速地部署多个ABAP实例。 可以在单个Kubernetes集群中启动ABAP实例，也可以与多个ABAP实例共享Kubernetes集群。 所有ABAP实例都可以通过基础架构（on-premise/self-managed或公有云）提供的负载平衡器地址使用。 Kubernetes还负责端口映射，并通过分配唯一的中间端口来避免在同一节点上具有相同端口的SAP实例之间的冲突。

挑战

自动伸缩与会话粘滞

ABAP体系结构在整个用户会话期间将用户会话上下文保留在一台特定的Dialog实例服务器上，直到用户注销或会话达到超时为止。缩小Dialog实例服务器的规模可能导致终止用户会话。
此外，批处理（也存在于Dialog实例服务器上）也不应该被终止。在这个的PoC中，我们通过优先级机制确定可以终止哪个容器，从而解决了这一问题。

负载均衡机制

Kubernetes的优点之一是在工作节点之间的内置均衡平衡。但是，ABAP根据使用的访问方法（SAP GUI，Web GUI，RFC等）提供了自己的负载平衡和排队机制。因此，存在功能重叠，所以Kubernetes负载均衡只能以受限的方式使用。

系统连接的复杂性增高

容器化和基础架构平台增加了多个网络层，因此从客户端（SAP GUI，浏览器）访问SAP系统比访问裸机系统更为复杂。另一方面，Kubernetes工具提供了持久性地检查系统可用性和网络性能以发现问题的能力。

需要具有兼容的SAP NetWeaver或S/4 HANA内容的数据库

数据库包含ABAP程序，所有业务逻辑和所有客户数据。要将容器化的ABAP系统与特定内核连接，需要兼容的SAP HANA数据库，其中包含正确的初始数据库载荷。

特定应用需求

我们假设SAP应用服务器及其ABAP应用可能有其他要求，例如web service端点，远程系统连接或移动应用程序连接。对于基础架构也可能有一些隐含的假设，例如SAP许可证key的硬件ID； Linux内核参数值等。