災難：活著！ SQL Server 從災難到運營

發生了什麼SQL Server 災難? 這是您參與行動的機會。

該網絡研討會將指導您完成一些 SQL Server 模擬災難。 通過 DR 計劃和清單離開此網絡研討會，以確保您的業務運營在發生中斷時按預期運行。

白皮書：高可用性解決方案為 Oracle 提供成本節約和靈活性

遷移 Oracle 數據庫可能是一項艱鉅的任務。 這個過程通常很複雜，而且成本很高。 然而，有時遷移是不可避免的。 當支持和許可考慮一起使遷移成為必要時，尤其如此。 在遷移業務關鍵型數據庫時，提供高可用性保護以防止停機很重要，因為停機會導致收入和生產力損失。 Oracle 已宣布即將結束對 Oracle Database 12c 的支持。 因此，運行 Oracle Database 12c 的組織將面臨迫在眉睫的遷移需求。

下載白皮書：高可用性解決方案為 Oracle 提供成本節約和靈活性

白皮書：了解業務關鍵型應用程序高可用性的複雜性

在當今競爭激烈、永遠在線的全球經濟中，對於現代企業來說，停機時間變得比以往任何時候都更加昂貴。 除了損失生產力和收入之外，當組織的關鍵業務系統、數據庫和應用程序無法提供可靠和卓越的客戶體驗時，他們還面臨失去客戶的風險。 SIOS 的這份技術簡報解釋了在關鍵業務應用程序中實現高可用性的複雜性。

下載白皮書：了解業務關鍵型應用程序高可用性的複雜性

介紹適用於 SIOS LifeKeeper 和 Google Cloud 的通用負載平衡器套件

這將討論通用負載均衡器應用程序恢復工具包(ARK) 適用於 SIOS Lifekeeper for Linux，特別是如何在 Google Cloud 上配置它。 SIOS ARK 是 SIOS LifeKeeper 產品的插件，可增加平台或應用程序感知。

本博客展示瞭如何使用雙節點 NFS 集群以及它們提供的 NFS 導出最終可以通過負載均衡器訪問。

SIOS 創建了這個 ARK 來促進 SIOS LifeKeeper 中的客戶端重定向在 GCP 中運行的集群.

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

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

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

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

您可以確定這將是面向 Internet 還是在您的 VPC 內部。 在這種情況下，我將配置一個僅用於內部的負載平衡器來放置在我的 NFS 服務器前面，以便僅在我的 VPC 中使用。

一旦您確定了名稱、區域等，您將被要求分配一個後端配置，這將需要一個包含您將作為前端的 HA 節點的實例組。

一旦您分配了一個實例組，您將定義一個運行狀況檢查 – 這是與您將在 Lifekeeper 通用負載均衡器配置中使用的端口匹配的端口，在這種情況下我使用的是 54321。同樣，請注意端口號，因為這將與 Lifekeeper 一起使用。

我只是堅持使用健康標準的默認值。

為負載均衡器輸入後端配置信息和運行狀況檢查後，您將需要定義前端配置。 這包括您要為負載均衡器創建的子網、區域和 IP。

您將配置您的 IP，這將匹配您正在保護的 Lifekeeper IP。

一旦您對配置感到滿意，您可以查看它或直接單擊創建。

一旦我們選擇“創建”，GCP 將開始部署負載均衡器，這可能需要幾分鐘，一旦完成，配置就會轉到 SIOS 保護套件。

使用 SIOS 保護套件進行配置

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

第一步是獲取腳本，最簡單的方法是使用 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 提供的 Hotfix 腳本定義負載均衡器。

首先我們創建一個新的資源層次結構，我們從下拉列表中選擇 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 腳本沒有本地恢復腳本，因此請確保清除此輸入當詢問應用程序信息時，我們希望輸入與在 Healthcheck 端口中配置的端口號相同的端口號，例如 54321我們將選擇在服務創建後將其投入使用Resource Tag 是我們將在 SPS-L GUI 中看到的名稱，我喜歡使用易於識別的名稱如果一切配置正確，您將看到“結束成功還原”，然後我們可以將其擴展到另一個節點，以便資源可以託管在任一節點上。

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

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

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

如何減少 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 的高可用性.