概念验证：在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实例
一键扩展大型系统
自动伸缩应用程序服务器
部署多个相邻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内核参数值等。
