利用 AWS 達成 SAP 應用服務的 Auto Scaling

如今在 AWS 上運行 SAP 的客戶們,可得利於原生雲端服務的廣度與深度。在可靠的全球基礎架構下,不但包含運算、儲存、databases 等傳統服務,也涵蓋 IoT、機器學習等新興科技。

我們發現客戶使用的主要功能之一是 instance 類型的更改,隨著工作負載的變化,instances 會出現過度利用或未充分利用的情況。此種擴展性的概念稱作垂直擴展,簡單來說,系統透過添加資源即可容納更多工作負載的能力。SAP database 層級的垂直擴展性當然很重要,那應用服務伺服器層級呢?我們無法僅憑一個超大型應用服務伺服器來支援所有工作負載,就算辦得到,這也不會是一個好主意。這就是 SAP 將應用服務伺服器設計成得以進行水平擴展的原因,Auto scaling 的概念便在這裡發揮了作用。

對於水平擴展性,客戶們透過用量大小調整的歷史數據,決定他們需要多少應用服務伺服器才能支持其尖峰的工作負載。當銷售訂單暴增,或在報告上臨時需求提取大數據資料量等意外情境發生時,可能造成資源利用上的浪費或瓶頸。討論水平擴展性時,DevOps 團隊或雲端工程團隊可能會建議使用 Amazon EC2 Auto Scaling,但眾所周知的是,SAP 與新技術有時跟得沒那麼緊密,基於其 on-premise 特性,SAP 應用的擴展性並不總是很容易處理。

AWS 可協助搭建一座橋樑,串接 SAP on-premise 需要的擴展性至雲端原生的 Auto Scaling group 技術。

解決方案

傳統的 Auto Scaling 使用 CPU 利用率與送到負載均衡器的請求數量等一系列衡量指標,這些指標的確可有效衡量工作負載與應用服務的資源使用量,但是,它們沒有反映出客戶使用SAP時,必要考慮的一些行為模式。

SAP 應用服務伺服器由工作流程組成,包含了基於 SAP kernel 的各種 SAP 服務,這是 SAP 的獨特處。每個工作流程都專精於特定的任務類型,其運行在 OS 層級上,消耗 CPU、內存、網路等多種資源。調整 SAP 應用服務伺服器的大小時,工作流程資源的平衡與分佈對於健康運行的 SAP 系統至關重要。

對於微服務和大多數現代應用服務來說,CPU 利用率與請求計數等標準指標通常已足以處理應用服務的 Auto Scaling。但對於 SAP,您必須還要考慮工作流程,尤其是狀態為閒置或使用中的數量。所以,我們該如何將 CPU 利用率與請求計數等原生 Auto Scaling 指標再加上工作流程消耗考量呢?

此解決方案使企業和 SAP Basis 管理員能夠基於特定於 SAP 的對話、批次處理、enqueue 和打印工作流程等工作負載指標,自動偵測 SAP 應用服務伺服器使用情況。如此便能適應於併發用戶登錄、月末結算、付款運行以及各種可預測和不可預測的工作負載增減峰谷。/span>

本方案使用按需求雲端模型,僅配置您所需的應用服務伺服器。它根據您定義的指標作水平擴展(計算資源的增減基於應用服務伺服器的啟動與停止)。就像恆溫器保持房屋溫度那樣 – 您只需選擇一個溫度,恆溫器便搞定一切。

架構圖:

當我們提到此解決方案進行的擴展可增可「減」時,是否表示它會關閉正在運行的應用服務伺服器,影響使用者與後台作業?這是 SAP 帶來的另一項小挑戰,並非所有 SAP 流量都通過負載均衡器,讓我們得以為此主動使用 connection draining。其中一些流量是 SAPGUI 上的使用者,或來自其他系統透過原生 SAP RFC 調用去呼叫您的系統。

想用 SAP 原生地處理此問題,請通過無服務器計算層 AWS Lambda 調用 SAP 中的 soft shutdown(或稱 graceful shutdown)功能,如此可確保在結束 SAP instances 時不會丟失任何請求或數據,並且可以最大程度地降低此解決方案的總體 TCO。

Soft shutdown 將等待事務按特定順序完成。然後,您可將其與 EC2 的 API 控制平面結合使用,以協調應用服務伺服器的 EC2 實例,從而整體性地按需求提供 SAP 容量。

AWS 專業服務解決方案使用 AWS 無服務器計算機、儲存和分析功能,使受 on-premise 和整體 SAP 架構約束的客戶能夠以更具彈性、可擴展性和成本效益的方式運行 SAP 服務。

結論

藉由 AWS Auto Scaling,您只需支付所需的費用,從而降低營運成本,並提供了更高的服務水平。就像恆溫器那樣便利,您選擇衡量指標,其餘的就由此解決方案達成。

2020-01-02T18:29:31+00:00 2020/01/02 |商業洞悉, 雲講堂|