概念驗證：在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中，咱們經過優先級機制肯定能夠終止哪一個容器，從而解決了這一問題。