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

2020 年 3 月 5 日
筆記

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