SAP ABAP Netweaver容器化, 不可能完成的任务吗?
Jerry之前的文章 一个13年ABAP老兵的建议:了解这些基础知识,对ABAP开发有百利而无一害, 回顾了ABAP Netweaver服务器主要的组件。本文咱们就来聊聊ABAP Netweaver容器化这个话题。
Jerry假定阅读本文的朋友,都听说过虚拟机和容器的概念, 并且对虚拟机和容器的区别有所了解。
容器与虚拟机的出发点很类似:对应用程序及其依赖进行隔离,生成一套能够随处运行的自容纳单元;二者都能够使应用运行在一个虚拟出的抽象层里,摆脱对传统物理硬件的依赖,使得计算资源的利用更加高效,能源效率与成本效益得以提升。
容器在虚拟化程度上比虚拟机技术更进一步,摆脱了前者对Hypervisor层的依赖,直接利用宿主机的内核,抽象层比虚拟机更少,更加轻量化,同虚拟机技术相比能达到更高的物理资源利用率,因此更受当今云服务提供商的青睐。
Docker是一个开源的应用容器引擎,是当今最流行的容器技术之一。
那么SAP ABAP Netweaver,能否利用Docker引擎,让它运行在容器里呢?
SAP官方的note 1122387 - Linux: SAP Support in virtualized environments给出了答案:截至2020年1月17日,答案是不支持。SAP官方不支持将ABAP应用服务器运行在容器或者容器编排环境内。比如目前业界流行的Docker和LXC,以及运行在Google Cloud Platform, Microsoft Azure, AWS上的Kubernetes Cluster,都不是SAP官方支持的能够将ABAP Netweaver服务器以容器的方式运行的平台。
https://launchpad.support.sap.com/#/notes/1122387
那么在2018年5月的时候,SAP社区有一篇博客:
Installing SAP NW ABAP into Docker
https://blogs.sap.com/2018/05/30/installing-sap-nw-abap-into-docker/
这又是怎么一回事呢?我们可以通过阅读博客了解作者是怎么做到的。
首先,我们从SAP官网上能免费下载Netweaver的开发者试用版,ABAP版本号为7.52 SP04:
https://developers.sap.com/trials-downloads.html?search=7.52%20SP04
下载到本地,得到一个rar文件,解压之后执行里面的安装文件即可把ABAP Netweaver安装到本地。
因此SAP社区上的一群ABAP爱好者们,想到了一个点子:如果把下载的Netweaver安装文件,解压之后,将其内容构建成一个Docker镜像文件,在这个Docker镜像内完成Netweaver的安装和启动工作。如此一来,岂不是达到了在容器里运行ABAP Netweaver的目的?
我们可以在这位ABAP爱好者的github仓库上找到用来制作Docker镜像的Dockerfile文件,从中了解到该容器镜像的制作过程:
https://github.com/tobiashofmann/sap-nw-abap-docker/blob/master/Dockerfile
这个Dockerfile构建的镜像选择了openSUSE Leap作为母镜像,该镜像提供了ABAP Netweaver运行的Linux操作系统。
Dockerfile的第一行用FROM关键字指定了这个基准镜像的名称:
第16行用COPY将事先从SAP官网下载好的存储在宿主机NW752文件夹下的Netweaver开发者版本安装文件,拷贝到容器镜像里,然后第22行用RUN关键字运行安装脚本。
安装完毕后,执行47行的启动脚本run.sh, 这样就能在容器里启动Netweaver服务器了。
这个容器镜像制作好之后,只需要简单地使用docker run命令行,就能启动一个新的容器运行实例了。从SAP官网下载的Netweaver开发者版本,就运行在这个新启动的容器实例里。
我们回顾这种做法,发现Docker技术较之虚拟机的优点并没有体现出来,按照博客作者提供的信息,通过这种方式制作出的镜像文件的大小超过了100GB,如此巨型的镜像文件几乎无法通过Docker Hub分发给其他人,无法用于生产用途。
另一方面,通过这种容器化方式,Jerry之前文章 一个13年ABAP老兵的建议:了解这些基础知识,对ABAP开发有百利而无一害 介绍的Netweaver服务器的诸多组件,被放置到同一个容器内,无法通过简单地增加容器实例的方式,实现Netweaver处理能力的水平扩展。
正是因为意识到将Netweaver所有组件放置于同一容器镜像内这种措施无法发挥容器技术的优势,SAP Linux实验室的工程师们采取了另一种思路,即这篇SAP社区博客里给出的架构图所体现的,将Netweaver组件进行拆分,分别放置于不同的容器编排逻辑单元中。
Proof of Concept: Deploying ABAP in Kubernetes
https://blogs.sap.com/2020/02/06/proof-of-concept-deploying-abap-in-kubernetes
上面的架构图里并没有看到容器的影子,而Jerry之前文章介绍的ASCS(ABAP SAP Central Services instances)和AS(Application Server,应用服务器),被放置到了名为Pod的逻辑单元里。
Kubernetes是容器编排和管理的平台,不直接操作容器,而是将一个或多个功能上相关的容器封装到称之为Pod的逻辑单元中,我们可以简单的把Pod理解成容器的集合。
一个SAP系统由一个ASCS实例和一个或多个AS实例构成,对于ASCS里包含的组件,比如之前介绍过的消息服务器,Enqueue服务器,Dispatcher等等,每个组件分别构建不同的容器镜像,再将这些镜像封装到一个单独的ASCS Pod里。
而ABAP Netweaver支持多AS实例部署的这种特性,恰巧能让Kubernetes原生支持的Horizontal Pod Autoscaler机制大显身手。将AS单独制作成容器镜像并放入AS Pod里,通过Kubernetes的Deployment Unit管理这些Pod,从理论上说,可以使用Kubernetes命令行进行ABAP应用服务器的水平扩展。
这种思路将ABAP Netweaver的组件分别进行容器化,大大缩小了每个组件对应的容器镜像文件的尺寸,使得应用服务器实例能够根据实际计算能力的需求变化,进行动态伸缩。如果想将这种方法应用到生产场景中,面临的一些挑战有:
(1) Kubernetes对待Pod的方式是官网里所谓的Cattle-like treatment,即Kubernetes就是Pod的上帝,可以根据实际需要,随时创建新的Pod或销毁已有的Pod,而运行在Pod内的应用消费者,完全感知不到Pod的这些变化。另一方面,我们知道,运行在ABAP Netweaver上的很多应用都是有状态的事务,比如编辑一个订单之前,用户先点击编辑按钮,此时应用会往Enqueue服务器发起一个申请锁的请求,成功获取锁之后继续编辑操作。如果此时运行该事务的AS实例所在的Pod正好被Kubernetes销毁了,那该用户尚未结束的编辑操作该如何处理?再比如某个Pod内的AS实例正在运行很多后台作业,那么这种Pod可以被Kubernetes销毁么?
这种挑战简单概括起来,就是如何调和Kubernetes Pod的水平伸缩机制和ABAP Netweaver的有状态事务处理(会话一致性)的需求。
(2) 在ABAP Netweaver容器化以前,大部分组件是在同一物理网络下彼此通信。容器化之后,组件与组件之间的通信会多经过一层Kubernetes的网络层,这使得整个系统的复杂度增加。
(3) 我们知道ABAP Netweaver有很多种同第三方系统集成的途径:RFC,Web Service,OData,IDOC等等。将ABAP容器化之后,以前这些技术是否仍然可以在不需要调整Netweaver核心实现的前提下继续工作,需要进行实际的验证。
所谓No pain,no gain,付出总会有收获。如果ABAP成功容器化之后,理论上我们会享受到哪些容器技术带来的便利呢?
(1) ABAP的安装和部署过程将会大大简化。假设出现了官方的ABAP容器镜像和Kubernetes Deployment文件,我们可以仅仅用几行简单的命令行,在任何支持容器和Kubernetes的平台上,轻松完成ABAP的安装和部署。
(上图来自博客:
https://www.itsfullofstars.de/2017/09/dockerfile-for-sap-netweaver-abap-7-5x-developer-edition/)
(2) 假设前文介绍的ABAP会话一致性的挑战已经成功解决,那么ABAP应用服务器实例的弹性伸缩,仅仅通过Kubernetes几条简单的命令行就可轻松实现。在ABAP传统部署场景下,增添新的应用服务器实例需要ABAP Basis人员进行繁琐配置的局面将不复存在。
除了在Kubernetes里通过人工敲命令行的方式调整Kubernetes的计算资源以外,Kubernetes原生就具有根据CPU或者内存的使用率,进行全自动伸缩的调整能力。这种完全无需人工界入的资源调整功能,如果能够运用到ABAP Netweaver上,无疑给我们留下了太多美好的想象空间。
SAP技术在不断向前演化,ABAP也从未停止前进的脚步,让我们活到老,学到老。感谢阅读。
本文来自云栖社区合作伙伴“汪子熙”,了解相关信息可以关注微信公众号"汪子熙"。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
由于漏洞,Let’s Encrypt将从今天起撤销近300万个TLS证书
今天(3月4日)起,由于域验证和发布软件中的一个错误,Let’s Encrypt将吊销近300万个证书。日前,Let’s Encrypt已经向受影响的客户发邮件告知,以便其及时地更新。 发送给受影响用户的电子邮件 2 月底的时候,Let’s Encrypt发现其证书颁发机构(CA)中的软件漏洞导致某些证书不能通过为关联域配置的证书颁发机构授权(CAA)正确验证。 漏洞 CAA是一项安全功能,允许域管理员创建DNS记录,该记录使得网站所有者,仅授权指定CA机构为自己的域名颁发证书,以防止HTTPS证书错误签发。并且,当局必须在颁发证书不超过8小时前,检查CAA记录。 Let’s Encrypt的CA软件——Boulder中的漏洞导致多域证书上的一个域被多次检查,而不是证书上的所有域都被一次检查。这意味着,在某些域没有被验证的情况下,颁发了证书。 那么,假设一个订阅者验证了一个域名,并且该域名被允许加密发布,即使某些域名是不符合Let’s Encrypt的CAA记录,该订阅者也能够正常发布包含该域名的证书,直到30天后。 因此,为了避免业务中断,从今天起,Let’s Encrypt将加密撤...
- 下一篇
ECS自建的Elasticsearch迁移至阿里云Elasticsearch
场景描述 将在ECS上自建的Elasticsearch迁移至阿里云Elasticsearch。 解决问题 通过在新集群中创建索引或者为新集群开启自动创建索引的方式,根据迁移的数据量大小和具体操作情况,选择匹配的方案完成数据迁移。 产品列表 阿里云Elasticsearch
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS7设置SWAP分区,小内存服务器的救世主
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Hadoop3单机部署,实现最简伪集群
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7安装Docker,走上虚拟化容器引擎之路