白皮書:使用 SIOS 保護套件保護 Amazon EC2 中的 SAP 和 SAP S/4HANA
雖然 AWS 具有確保基礎設施層級可用性的規定,但 SAP 環境的業務關鍵型性質需要更多保護。也就是說,需要特別關注應用程式層和資料庫層。有多種選項可以提供這種額外的保護。
本白皮書著重於在 AWS 上的 Linux 發行版(包括 Oracle Linux、Red Hat、SUSE 和 CentOS)上運行 SAP 或 SAP S/4HANA 的最佳實務。
經許可轉載安全作業系統
SIOS SANless clusters High-availability Machine Learning monitoring
雖然 AWS 具有確保基礎設施層級可用性的規定,但 SAP 環境的業務關鍵型性質需要更多保護。也就是說,需要特別關注應用程式層和資料庫層。有多種選項可以提供這種額外的保護。
本白皮書著重於在 AWS 上的 Linux 發行版(包括 Oracle Linux、Red Hat、SUSE 和 CentOS)上運行 SAP 或 SAP S/4HANA 的最佳實務。
經許可轉載安全作業系統
Amazon EBS 多重附加磁碟區和 Microsoft故障轉移集群是雲端運算和資料管理領域的強大工具。然而,整合這兩種技術可能充滿挑戰。這篇部落格文章深入探討了為什麼使用 Amazon EBS Multi-Attach for Microsoft 故障轉移叢集通常不是最佳選擇。
Amazon EBS 磁碟區的一個主要限制是它們僅限於單一可用區 (AZ)。對於強大的故障轉移集群,跨多個可用區部署執行個體是建議的最佳實踐,這是 EBS 磁碟區無法直接支援的。
雖然 EBS 磁碟區提供了99.9% 可用性 SLA,這低於高可用性解決方案通常預期的 99.99%。在跨多個可用區部署執行個體時,AWS 確實保證了更高的 SLA,但這一優勢並未擴展到單一可用區部署。
具有多重附加 EBS 磁碟區的 Windows 故障轉移叢集需要使用 IO2 卷,該磁碟區比具有相似大小和效能的 GP3 捲貴約九倍。這種成本差異非常顯著,特別是對於大規模部署。
大樓AWS 中的集群節點位於相同可用區時,需要將可用區劃分為多個子網,以支援Windows叢集中不同的虛擬IP位址(VIP)。這種複雜性以及無法跨叢集節點共享單一 VIP 增加了配置挑戰。
SIOS資料管理器作為一種卓越的解決方案,它允許叢集跨越子網,同時提供所需的 99.99% 可用性 SLA。它不僅提供更靈活的儲存選項(包括使用 GPT3 磁碟),而且更具成本效益。使用帶有 GPT3 磁碟的 SIOS DataKeeper 的叢集的成本大約是基於 IO2 的類似叢集的 20%,並且可用性增強。
在 Microsoft 故障轉移叢集中使用 Amazon EBS 多附加磁碟區帶來了多項重大挑戰,從有限的可用區部署選項和較低的可用性 SLA 到更高的成本和增加的配置複雜性。SIOS DataKeeper 提供了一個引人注目的替代方案,可以更有效地平衡成本、靈活性和可靠性。對於尋求高可用性和成本效率的組織來說,探索 EBS Multi-Attach 以外的選項是一個謹慎的策略。聯絡SIOS了解更多。
經許可轉載安全作業系統
SIOS Technology 是一家高可用性 (HA) 和災難復原 (DR) 解決方案公司,跨 Windows 和 Linux 系統以及各種雲端平台為客戶提供關鍵任務資料庫、應用程式和服務的應用程式可用性。卡修斯·魯伊SIOS Technology 客戶體驗副總裁分享了他對 2024 年的預測。
隨著對應用程式的依賴不斷增加,IT 團隊面臨越來越大的壓力,需要為傳統上被認為是非關鍵應用程式和關鍵任務應用程式提供高效的高可用性和災難復原。由於這種轉變,我們可能會看到高可用性軟體解決方案和服務的擴展來滿足這一期望。
隨著越來越多的公司擴展到雲端並跨越不同的作業系統,預計會有更多的團隊涵蓋不同的作業系統、應用程式和雲端平台。團隊將尋找在這些不同作業系統和雲端環境中保持一致的應用程式和解決方案,以降低複雜性並提高成本效率。
HA 解決方案還需要在作業系統和雲端環境中保持一致,我們將看到與雲端無關的 HA 的發展趨勢。公司需要簡單、自動化、快速且智慧的 HA 和 DR 解決方案。隨著越來越多的組織遷移到雲端,他們需要確保在此過程中不會遺失資料。HA 解決方案需要彌合舊系統和更現代系統之間的差距。
到 2024 年,人們將更加關注資料保留、安全存取控制和權限,促使組織將更多增強的安全措施整合到其高可用性和災難復原解決方案、服務和策略中。隨著收集的資料量不斷增加,組織還需要更多有關故障發生原因的資訊。自動化和編排工具可能會在簡化根本原因分析和提供智慧響應方面發揮核心作用。
SIOS Technology 將在來年繼續專注於客戶,幫助他們避免和減少停機時間,並確保他們的數據和應用程式在業務最需要時可用。該公司將繼續優化其解決方案,提供額外的相鄰服務以使客戶受益,並幫助應用程式提供者和雲端提供者制定有效的HA策略。
經許可轉載安全作業系統
當三菱汽車公司使用新的基於雲端的系統來改造其三個地點的倉庫管理系統時,他們需要一種新的方法來提供高可用性,而不增加複雜性或降低性能。
「即使出現問題,LifeKeeper 也會自動從主伺服器節點故障轉移到輔助伺服器節點系統立即啟動,操作繼續進行,用戶不會出現任何明顯的延遲,從而節省了 IT 時間並消除了客戶的服務中斷。”
三菱汽車全球 IT 部門業務 IT 部經理 Hiromasa Tsuboshima 說道
環境
每個三菱汽車倉庫都依賴一個管理系統來處理經銷商銷售的汽車零件和配件的訂單和庫存,例如腳踏墊和車頂架。它管理零件和用品的接收、經銷商國內和國際訂單的發貨管理以及倉庫地點內的庫存管理和分配。
遺留系統運行在老化的本地伺服器硬體上,這些硬體越來越容易出現問題,浪費 IT 時間進行故障排除並導致操作頻繁中斷。現有系統使用硬體製造商專有的冗餘來減少停機時間。如果遺留系統出現問題,IT 人員必須手動停止系統並將操作切換到冗餘硬件,直到問題解決 – 這個過程需要 IT 人員花費兩到四個小時的時間。
三菱汽車必須確保在規定的驗收期內訂購的任何零件或配件均在第二天交付給經銷商。因此,即使這些關鍵任務系統的停機時間很短,也可能對業務產生重大影響。
倉庫管理系統在確保及時處理所有訂單以滿足交貨計劃方面發揮關鍵作用。例如,為了確保下午 4:29 輸入的訂單次日送達,倉庫管理系統必須在下午 4:40 之前處理並顯示該訂單,以便可以將其放入當天的最後一輛卡車或航班上。「我們需要在 10 分鐘內恢復,」岩崎說。
挑戰
三菱汽車公司全球IT 部門業務IT 部經理Hiromasa Tsuboshima 表示:「我們六個倉庫中的三個倉庫的現有系統都是2012 年開始使用的硬體。我們需要用新系統取代它們,以消除對系統的消耗。 IT 資源並減少對營運的負面影響。” 為其新的基於雲端的倉庫系統尋找高可用性解決方案對於專案的成功至關重要。三菱汽車公司全球 IT 部門業務 IT 部成員 Satoshi Iwasaki 表示:“根據公司範圍的政策,每當我們建立新系統時,我們都需要從舊的本地系統遷移到公有雲。 ”
高可用性軟體
在將倉庫管理系統遷移到公有雲時,三菱汽車諮詢了一位外部 IT 顧問,後者推薦了 SIOS LifeKeeper for Linux 以實現高可用性。「根據我們過去的經驗,我們總是使用硬體解決方案來實現高可用性,」Iwasaki 先生說。“我向 SIOS 代表提出了很多有關使用 HA 軟體的深入問題,SIOS 提供了準確、完整的答案,這建立了我對 SIOS LifeKeeper 的信任。”
決定選擇 LifeKeeper 的另一個關鍵因素是可選的 LifeKeeper 專業服務,它提供了根據三菱特定倉庫系統要求量身定制的應用程式感知恢復套件 (ARK)。
SIOS ARK 使 LifeKeeper 能夠監控整個應用程式堆疊是否存在潛在的停機問題。他們還根據最佳實踐來協調應用程式故障轉移,以便在輔助節點上順利運行。「我們能夠客製化和開發 LifeKeeper 來滿足我們的要求,並且 SIOS 能夠回應我們的所有要求,」Iwasaki 先生說。
快速、自動的故障轉移
「即使出現問題,LifeKeeper 也會立即自動從主伺服器節點故障轉移到輔助節點,操作會繼續進行,使用者不會出現任何明顯的延遲。它節省了 IT 時間並消除了客戶的服務中斷。」Tsuboshima 先生說。坪島先生負責全球IT部門的部分系統的管理。在升級專案之前,他常常在夜間隨時收到故障警報,需要他立即關注。如今,如果發生故障,他只需收到故障轉移通知,系統即可繼續運行,無需幹預。SIOS 解決方案為 Tsuboshima 先生和 IT 團隊的其他成員節省了許多小時的寶貴時間,並消除了服務中斷。
結果
在應對 2020 年的大流行時,將倉庫管理系統遷移到雲端,同時確保 LifeKeeper 的高可用性的好處是顯而易見的。「將我們的系統置於雲端,使我們能夠遠端管理系統。「如果我們繼續使用舊的本地系統,我們將面臨在 COVID-19 緊急情況期間進入辦公室解決問題或管理系統的巨大額外風險,」Iwasaki 先生說。
儘管三菱汽車繼續轉向公有雲,但其許多系統仍然使用大型主機。「當我們考慮將我們的關鍵任務系統從這些主機系統轉移到雲端時,我們將尋求 LifeKeeper 的高可用性保護,」Iwasaki 先生說。未來我們會向公司推薦它。”
了解有關 Linux 版 SIOS LifeKeeper 的更多信息
學習更多關於SIOS 保護套件,包括 SIOS LifeKeeper、SIOS DataKeeper 和 SIOS 應用程式復原套件。
經許可轉載安全作業系統
DKCE 是 的縮寫DataKeeper叢集版。DKCE 是一款 SIOS 軟體,它將 DataKeeper 的使用與以下功能結合:Windows 故障轉移叢集提供高可用性透過基於遷移的資料複製。
對於此範例,我將設定一個三節點集群,其中第三個節點保持節點多數。
步驟1:您必須在 2/3 的系統上安裝 DataKeeper 才能設定 DKCE 叢集。點擊以下連結按照我們的快速入門指南完成此安裝:https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide
第2步:新增您計劃在伺服器管理員中管理的伺服器。這需要在您計劃新增到叢集的所有伺服器上完成。
在您的伺服器上導航到伺服器管理員
點擊“新增其他要管理的伺服器”
我在這裡按伺服器名稱添加了伺服器。為此,您需要驗證主機檔案中的系統名稱和 IP 項目,該檔案位於:C:\Windows\System32\drivers\etc\hosts
新增所有伺服器後,您可以透過導航至伺服器管理員中的「所有伺服器」進行驗證
步驟3:您可能會注意到 winRM 錯誤,要繞過它,請以管理員身份在 PS 中執行此命令。運行此命令將叢集中的伺服器新增為可信任主機。該命令需要在叢集中的每個系統上運行。
Set-Item WSMan:\localhost\Client\TrustedHosts -Value ‘<伺服器 1 的名稱>,<伺服器 2 的名稱>’
步驟4:安裝故障轉移集群
跟隨安裝故障轉移集群的步驟。
第5步:導航至故障轉移群集管理器
第6步:點擊“建立集群”
第7步:接下來,新增應該在叢集中的伺服器,並在每個條目後按一下「新增」。
步驟8:該列表應類似於下圖中的列表
第9步:選擇“執行所有測試”進行驗證測試,然後按一下“下一步”。
第10步:測試完成後,按一下“完成”
第11步:命名您的集群,我將其命名為“Cluster1”,點擊“下一步”
步驟12:確認“將所有符合條件的儲存新增至叢集”已選中,按一下“下一步”
步驟13:完成第 12 步後,按一下“完成”
第14步:在故障轉移群集管理器中,群集最初將處於離線狀態。我將分配一個未使用的 IP 使其上線。在「叢集核心資源」中右鍵點選 IP 位址資源並選擇屬性。
在屬性面板中,我的子網路遮罩是/28,因此我將選擇範圍內的可用IP,12.0.0.14。點擊“應用”
在“叢集核心資源”中右鍵單擊叢集並選擇“上線”
資源現在應該在線
第15步:導航至 DataKeeper
第16步:右鍵單擊“作業”,然後按一下“建立作業”開始建立我們的第一個鏡像
為作業命名,我將作業命名為“job1”,然後按一下“建立作業”
選擇要從中複製資料的來源和磁碟區。我選擇了 Box1 作為來源,卷 D,點擊“下一步”
接下來,選擇要作為目標的伺服器和磁碟區。我選了Box2,卷D。
將出現一條提示,要求您將建立的磁碟區自動註冊為 WSFC 卷,選擇「是」以使該磁碟區高度可用。
在 DataKeeper 中,您現在可以看到該磁碟區目前正在鏡像。
步驟17:在故障轉移群集管理器中,導航到存儲,然後導航到磁碟。您將看到您自動註冊的磁碟區是 WSFC。
第18步:讓我們驗證應該檢查的所有者。右鍵單擊該卷,然後單擊“屬性”
由於我需要第三個來作為見證人並維持節點多數,因此 Box3 將需要取消選取/保持取消選取狀態。
步驟19:現在我們可以透過故障轉移叢集管理器測試遷移。導航至檔案總管並在目前正在鏡像的磁碟區中建立新的文字檔案。在您的來源上執行此操作。
導覽至故障轉移群集管理器,按一下“DataKeeper Volume D”,然後從“操作”窗格中選擇“移動可用儲存”。
右鍵單擊“最佳可能節點”。這應該會自動遷移到您的目標。
在故障轉移叢集管理器中,驗證「DataKeeper Volume D」的擁有者現在是目標節點
導航至 DataKeeper 以驗證您的目標現在是來源,反之亦然。
您已完成 DKCE 叢集的設定。
經許可轉載安全作業系統