菜单 学习猿地 - LMONKEY

VIP

开通学习猿地VIP

尊享10项VIP特权 持续新增

知识通关挑战

打卡带练!告别无效练习

接私单赚外块

VIP优先接,累计金额超百万

学习猿地私房课免费学

大厂实战课仅对VIP开放

你的一对一导师

每月可免费咨询大牛30次

领取更多软件工程师实用特权

入驻
65
0

概念验证:在Kubernetes中部署ABAP

原创
05/13 14:22
阅读数 54019

关于将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内核参数值等。

 

 
 
 
 

发表评论

0/200
65 点赞
0 评论
收藏
为你推荐 换一批