SAP ABAP Netweaver容器化,不可能完成的任務嗎?

Jerry之前的文章 一個13年ABAP老兵的建議:瞭解這些基礎知識,對ABAP開發有百利而無一害, 回顧了ABAP Netweaver服務器主要的組件。本文咱們就來聊聊ABAP Netweaver容器化這個話題。


Jerry假定閱讀本文的朋友,都聽說過虛擬機和容器的概念, 並且對虛擬機和容器的區別有所瞭解。


容器與虛擬機的出發點很類似:對應用程序及其依賴進行隔離,生成一套能夠隨處運行的自容納單元;二者都能夠使應用運行在一個虛擬出的抽象層裡,擺脫對傳統物理硬件的依賴,使得計算資源的利用更加高效,能源效率與成本效益得以提升。


容器在虛擬化程度上比虛擬機技術更進一步,擺脫了前者對Hypervisor層的依賴,直接利用宿主機的內核,抽象層比虛擬機更少,更加輕量化,同虛擬機技術相比能達到更高的物理資源利用率,因此更受當今雲服務提供商的青睞。

SAP ABAP Netweaver容器化,不可能完成的任務嗎?


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


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


那麼在2018年5月的時候,SAP社區有一篇博客:


Installing SAP NW ABAP into Docker

https://blogs.sap.com/2018/05/30/installing-sap-nw-abap-into-docker/


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


這又是怎麼一回事呢?我們可以通過閱讀博客瞭解作者是怎麼做到的。


首先,我們從SAP官網上能免費下載Netweaver的開發者試用版,ABAP版本號為7.52 SP04:


https://developers.sap.com/trials-downloads.html?search=7.52%20SP04

SAP ABAP Netweaver容器化,不可能完成的任務嗎?

下載到本地,得到一個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操作系統。

SAP ABAP Netweaver容器化,不可能完成的任務嗎?

Dockerfile的第一行用FROM關鍵字指定了這個基準鏡像的名稱:

SAP ABAP Netweaver容器化,不可能完成的任務嗎?

第16行用COPY將事先從SAP官網下載好的存儲在宿主機NW752文件夾下的Netweaver開發者版本安裝文件,拷貝到容器鏡像裡,然後第22行用RUN關鍵字運行安裝腳本。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?

安裝完畢後,執行47行的啟動腳本run.sh, 這樣就能在容器裡啟動Netweaver服務器了。


這個容器鏡像製作好之後,只需要簡單地使用docker run命令行,就能啟動一個新的容器運行實例了。從SAP官網下載的Netweaver開發者版本,就運行在這個新啟動的容器實例裡。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


我們回顧這種做法,發現Docker技術較之虛擬機的優點並沒有體現出來,按照博客作者提供的信息,通過這種方式製作出的鏡像文件的大小超過了100GB,如此巨型的鏡像文件幾乎無法通過Docker Hub分發給其他人,無法用於生產用途。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


另一方面,通過這種容器化方式,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

SAP ABAP Netweaver容器化,不可能完成的任務嗎?


上面的架構圖裡並沒有看到容器的影子,而Jerry之前文章介紹的ASCS(ABAP SAP Central Services instances)和AS(Application Server,應用服務器),被放置到了名為Pod的邏輯單元裡。


Kubernetes是容器編排和管理的平臺,不直接操作容器,而是將一個或多個功能上相關的容器封裝到稱之為Pod的邏輯單元中,我們可以簡單的把Pod理解成容器的集合。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?

一個SAP系統由一個ASCS實例和一個或多個AS實例構成,對於ASCS裡包含的組件,比如之前介紹過的消息服務器,Enqueue服務器,Dispatcher等等,每個組件分別構建不同的容器鏡像,再將這些鏡像封裝到一個單獨的ASCS Pod裡。


而ABAP Netweaver支持多AS實例部署的這種特性,恰巧能讓Kubernetes原生支持的Horizontal Pod Autoscaler機制大顯身手。將AS單獨製作成容器鏡像並放入AS Pod裡,通過Kubernetes的Deployment Unit管理這些Pod,從理論上說,可以使用Kubernetes命令行進行ABAP應用服務器的水平擴展。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


這種思路將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的有狀態事務處理(會話一致性)的需求。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


(2) 在ABAP Netweaver容器化以前,大部分組件是在同一物理網絡下彼此通信。容器化之後,組件與組件之間的通信會多經過一層Kubernetes的網絡層,這使得整個系統的複雜度增加。


(3) 我們知道ABAP Netweaver有很多種同第三方系統集成的途徑:RFC,Web Service,OData,IDOC等等。將ABAP容器化之後,以前這些技術是否仍然可以在不需要調整Netweaver核心實現的前提下繼續工作,需要進行實際的驗證。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?

所謂No pain,no gain,付出總會有收穫。如果ABAP成功容器化之後,理論上我們會享受到哪些容器技術帶來的便利呢?


(1) ABAP的安裝和部署過程將會大大簡化。假設出現了官方的ABAP容器鏡像和Kubernetes Deployment文件,我們可以僅僅用幾行簡單的命令行,在任何支持容器和Kubernetes的平臺上,輕鬆完成ABAP的安裝和部署。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?

(上圖來自博客:

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 Netweaver容器化,不可能完成的任務嗎?

SAP技術在不斷向前演化,ABAP也從未停止前進的腳步,讓我們活到老,學到老。感謝閱讀。


SAP ABAP Netweaver容器化,不可能完成的任務嗎?


分享到:


相關文章: