關於將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實例
一鍵擴展大型系統
自動伸縮應用程序服務器
部署多個相鄰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內核參數值等。