概念验证：在Kubernetes中部署ABAP

时间 2020-02-18

标签概念验证 kubernetes 部署 abap 繁體版

原文原文链接

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

做者：Richard Treu, Henning Sackewitzweb

英文原文：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范围以内——它被视为给定的外部资源，能够经过安全存储证书链接。app

咱们的尝试是上面的组件放到单独的容器镜像里，把它们映射到合适的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内核参数值等。