概念驗證：在Kubernetes中部署ABAP
關於將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例項。 我們只提供了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中，我們通過優先順序機制確定可以終止哪個容器，從而解決了這一問題。
負載均衡機制
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核心引數值等。
&nbs