如何減少 SAP 的停機時間

想著怎麼做減少 SAP 的停機時間是在初始解決方案設計期間應該訪問的一個重要主題。 可以對現有的 SAP 環境進行更改，但在現有的生產環境中，這些可能會更加棘手，停機時間會成為問題。

SAP 環境中有幾個典型的組件可以被視為單點故障； ASCS（中央服務）、HANA DB、NFS 節點和 SAP 應用程序服務器。 理想情況下，應該通過在高可用性配置中使用冗餘服務器來保護這些。

SAP 的 HA/DR 目標

為 SAP 設計高可用性/災難恢復組件時的核心目標應該是：

● 最大限度地減少停機時間 ● 消除數據丟失 ● 保持數據完整性 ● 支持靈活配置 在當今的現代云環境中，底層硬件的基礎架構通常通過使用多個冗餘 NIC、冗餘存儲和硬件可用區得到很好的保護，避免出現故障——然而，這仍然沒有'不保證您的 SAP 應用程序將運行並響應請求。

用一個高可用性SIOS 保護套件等解決方案引入了智能高可用性以及本地磁盤複製，以確保您的 SAP 應用程序和服務受到持續監控和保護，並能夠在檢測到故障時自動切換到冗餘硬件。

現在讓我們考慮一個不受 HA 保護的 SAP 配置的簡單示例，它可能看起來像這樣（圖 1）：如果此環境用於處理來自用於向客戶銷售服裝的 Web 服務器的交易，那麼 SAP 將用於處理銷售、跟踪訂單、跟踪庫存並基於這些交易提供多個自動訂購等。

現在讓我們假設這個銷售處理環境（如上圖）是在沒有 HA 的情況下在雲中配置的，因為架構師認為雲環境中的高度冗餘硬件足以防止故障。如果該 HANA 數據庫遇到問題並關閉，讓我們看看使數據庫恢復正常運行所需的典型步驟： ● 即使HANA 配置了HANA 系統複製，故障轉移到輔助HANA 數據庫系統也不會自動進行。 這將需要知道 HANA 的人在檢測到故障並通知他們中斷後進行糾正。
● 來自網絡服務器的實時交易將暫停，直到問題得到解決 如果這家小型服裝零售商每年通過網絡銷售進行約 1000 萬美元的交易，這相當於全年平均銷售額約為每小時 1150 美元。 高峰時間每小時會花費更多。

IBM 的這份報告表明每小時的平均停機成本為 1 萬美元圖 2：具有 HA/DR 的 SAP 環境如果 HA 軟件一直在使用中（圖 2），HANA DB 故障轉移將是自動的，並且 Web 服務器的中斷將在配置的超時範圍內，並且絕對不會有任何銷售損失。 將生成警報，並且可以比系統停機情況更輕鬆地查看和診斷原因。

擴大客戶規模，很可能任何系統停機情況都會開始花費數十萬美元並消耗大量人力資源來解決。

其他IBM 報告表明驚人的 44% 的受訪者每兩個月進行一次計劃外停機，另有 35% 的受訪者每月進行一次計劃外停機。

計劃中斷本身是另一個潛在問題，46% 的受訪者報告每月計劃中斷，另有 29% 報告年度計劃中斷。 讓應用程序和服務受 HA 軟件保護還可以通過允許在維護活動期間將服務轉移到正在運行的系統來緩解這些計劃內的中斷。

學習更多關於SAP 和 S/4HANA 的高可用性.

在這篇博客中，我將討論通用負載平衡器應用程序恢復套件 (ARK)適用於 Linux 的 SIOS Lifekeeper，特別是如何在 Microsoft Azure 上配置它。 我將使用一個兩節點 NFS 集群，它們提供的 NFS 導出最終將通過負載平衡器訪問。

SIOS 創建了這個 ARK 以促進在 Azure 中運行的 LifeKeeper 集群中的客戶端重定向。

由於 Azure 不支持免費 ARP，因此客戶端無法直接連接到傳統的集群虛擬 IP 地址。 相反，客戶端必須連接到負載均衡器，負載均衡器將流量重定向到活動集群節點。 . Azure 實現了在第 4 層（TCP、UDP）上運行的負載均衡器解決方案，負載均衡器可以配置為具有私有或公共前端 IP，可以確定哪個節點處於活動狀態的運行狀況探測器，一系列後端 IP 地址（對於集群中的每個節點）和傳入/傳出網絡流量規則。

傳統上，健康探測將監視應用程序上的活動端口並確定該應用程序在哪個節點上處於活動狀態。SIOS 通用負載平衡器 ARK 配置為讓活動節點偵聽用戶定義的端口。 然後在 Azure 負載均衡器中將此端口配置為運行狀況探測端口。 這允許活動集群節點響應 TCP 健康檢查探測，從而啟用自動客戶端重定向。

Azure 中的安裝和配置簡單明了，詳細如下：

在 Azure 門戶中，選擇負載平衡創建一個負載均衡器，您將選擇要部署它的資源組以及名稱，我喜歡使用與我使用負載均衡器的集群類型一致的名稱，例如 IMA -NFS-LB 將位於兩個 IMA-NFS 節點的前面。

您可以確定這是公共 LB 還是私有 LB。 在這種情況下，我將一個私有負載平衡器配置到我的 NFS 服務器前面，以便僅在此資源組中使用。

一旦您確定了名稱、資源組等，您將被要求為負載均衡器分配名稱、虛擬網絡、子網和 IP。 IP 地址應該與您將在 LifeKeeper 中創建為虛擬 IP 地址的 IP 地址相同。

為負載均衡器輸入基本信息後，您需要定義要在後端配置哪些機器來為負載均衡器提供服務，在我的情況下，這個後端池將由我使用的兩個節點組成我的 NFS 服務器。

您將需要一個負載平衡規則，這是負載平衡器確定將哪些流量路由到活動節點的方式。 – 當您配置通用應用程序以支持負載平衡器時，此處配置的端口號將在 SPS-L 中使用。 在此示例中，我們使用“HA 端口”，它將所有流量路由到活動節點。 如果您想限制要路由的流量，您可以指定特定的應用程序端口。

前端 IP 應該是負載均衡器 IP，後端池應該是您配置為負載均衡器使用的資源的節點。 確保選中“HA Ports”按鈕並啟用“Floated IP”。 可以禁用“TCP 重置”。

創建運行狀況探測時，請確保記下您在此處配置的端口，因為我們在 SIOS 保護套件中創建通用應用程序時將使用該端口。 您可以使用“間隔”和“不健康閾值”的標準值。 如果您有應用程序特定的要求，這些可以在以後更改。

現在負載平衡規則應該是完整的，帶有一個運行狀況探測。 選擇“添加”一旦我們選擇“添加”，Azure 將開始部署負載均衡器，這可能需要幾分鐘，一旦完成，配置就會轉到 SIOS 保護套件。

注意：一旦後端機器在負載均衡器後面配置，它們將失去對互聯網網關的訪問權限，因此系統更新等操作將無法正常工作。 您可以從後端資源組中刪除機器以再次允許 Internet 訪問。

使用 SIOS 保護套件進行配置

在本博客中，我配置了三個 NFS 導出以使用 SPS-L 進行保護，這三個導出配置為使用與 Azure 負載均衡器的前端 IP 相同的 IP。 我正在使用 Datakeeper 複製存儲在導出中的數據。

第一步是獲取腳本，最簡單的方法是使用 wget，但您也可以下載整個包並使用 winscp 或類似工具將 rpm 直接上傳到節點。 您需要在 Lifekeeper 集群的所有節點上安裝 Hotfix。

完整的恢復套件可在此處獲得： http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1可以使用 wget 在這裡找到這些部分： wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt下載後，根據 FTP 站點上記錄的值驗證 MD5 總和。

按如下方式安裝 RPM： rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm 通過運行檢查安裝是否成功： rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 如果您出於某種原因需要刪除 RPM，可以通過運行： rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154 來完成.x86_64下面是顯示我已經配置的三個 NFS 導出的 GUI：我們需要在 SIOS 保護套件中做的是使用 SIOS 提供的修補程序腳本定義負載平衡器。

首先我們創建一個新的資源層次結構，我們從下拉列表中選擇 Generic Application定義位於 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 restore.pl 腳本定義位於 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 remove.pl 腳本定義位於 /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ 中的 quickCheck 腳本沒有本地恢復腳本，因此請確保清除此輸入當詢問應用程序信息時，我們希望輸入與在 Health Probe 配置中配置的端口號相同的端口號，例如 54321我們將選擇在服務創建後將其投入使用。

資源標籤是我們將在 SPS-L GUI 中看到的名稱，我喜歡使用易於識別的名稱。

如果一切配置正確，您將看到“結束成功還原”，然後我們可以將其擴展到另一個節點，以便資源可以託管在任一節點上。

這顯示了擴展至兩個節點後完成的負載均衡器配置。

該集群的最後一步是為三個 NFS 導出創建子依賴項，這意味著所有帶有 Datakeeper 鏡像和 IP 的 NFS 導出都將依賴於負載均衡器。 如果活動節點上出現嚴重問題，則所有這些資源都將故障轉移到其他正常運行的節點。

上圖是 Lifekeeper GUI 中完整的層次結構。 下面顯示了擴展的 GUI 視圖，顯示 NFS 導出、IP、文件系統和 DataKeeper 複製卷作為負載均衡器資源的子級。

這只是您如何使用 SIOS LifeKeeper 的一個示例天藍色保護一個簡單的 NFS 集群。 同樣的概念適用於您需要保護的任何關鍵業務應用程序。 您只需利用 SIOS 提供的負載均衡器 ARK 來允許 Azure 負載均衡器（內部或外部）確定當前託管應用程序的節點。