2 2 月, 2024 |
三菱汽車利用 LifeKeeper 將關鍵系統轉移到雲端以實現高可用性保護三菱汽車利用 LifeKeeper 將關鍵系統轉移到雲端以實現高可用性保護當三菱汽車公司使用新的基於雲端的系統來改造其三個地點的倉庫管理系統時,他們需要一種新的方法來提供高可用性,而不增加複雜性或降低性能。 「即使出現問題,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 應用程式復原套件。 經許可轉載安全作業系統
|
30 1 月, 2024 |
如何設定 DataKeeper 叢集版本(DKCE 叢集)如何設定 DataKeeper 叢集版本(DKCE 叢集)什麼是 DKCE 叢集?DKCE 是 的縮寫DataKeeper叢集版。DKCE 是一款 SIOS 軟體,它將 DataKeeper 的使用與以下功能結合:Windows 故障轉移叢集提供高可用性透過基於遷移的資料複製。 建立DKCE叢集的步驟對於此範例,我將設定一個三節點集群,其中第三個節點保持節點多數。 步驟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 叢集設置您已完成 DKCE 叢集的設定。 經許可轉載安全作業系統 |
24 1 月, 2024 |
確保訪問關鍵教育應用程式確保訪問關鍵教育應用程式教育和資訊科技 (IT) 越來越密不可分。所討論的 IT 是否是支援課堂白板的應用程式、支援大學註冊系統的資料庫、學習管理系統 (LMS),還是控制學生進入實驗室、宿舍和餐廳的建築維護系統(如果是關鍵組件)如果您的IT 基礎設施突然陷入癱瘓,教師、管理員和學生都無法完成他們應該完成的任務。該機構的使命被中斷。如果中斷太頻繁,如果學生、教師和管理人員的經驗受到影響,機構本身的聲譽也會受到影響。 IT 基礎架構旨在確保對教育體驗至關重要的應用程式的高可用性 (HA),可以最大限度地降低這些系統因任何原因變得無回應時可能發生的中斷和聲譽損失的風險。在這種情況下,HA 基礎設施被定義為能夠確保關鍵應用程式在不低於 99.99% 的時間內可用性的基礎設施。換句話說,這意味著您的關鍵應用程式每月不會意外離線超過四分鐘。 如何實現 HA?這個問題很容易回答,但這並不是您需要問的唯一問題。同樣重要的是:哪些應用程式非常重要以至於需要 HA 配置?從本質上講,為HA 配置的IT 基礎架構具有一組或多組輔助伺服器和儲存子系統,這些伺服器和儲存子系統位於不同的地理位置(如果您的主伺服器駐留在本地或單獨的可用性中,則可以是遠端資料中心)區域 [AZ](如果您的伺服器駐留在雲端)。如果某些原因導致主伺服器上執行的應用程式停止回應,管理應用程式的 HA 軟體會立即將應用程式故障轉移到輔助伺服器,您的關鍵應用程式將從主伺服器停止回應的位置再次啟動。根據您計劃複製的主伺服器的大小和效能特徵,輔助伺服器可能會很昂貴,因此您不太可能為 HA 配置所有學術應用程式。一旦確定哪些應用程式值得對 HA 進行投資,您就會知道需要在哪裡建立 HA 環境。 實現高可用性的選擇一旦您選擇了要保護的應用程序,您實現 HA 的選項就會變得更加清晰。它們在 Windows 還是 Linux 上運作?您的資料庫管理系統 (DBMS) 是否內建對 HA 配置的支援?如果是這樣,它的限制是什麼?例如,如果您的關鍵應用程式在 Windows 和 SQL Server 上執行,您可以使用 SQL Server 本身的可用性群組 (AG) 功能來啟用 HA。或者,您可以使用第三方 SANless 叢集工具來設定 HA,該工具提供 SQL Server 中的 AG 服務不提供的選項。如果您試圖保護來自多個供應商的資料庫伺服器,或者如果您的某些關鍵應用程式在Windows 上運行而其他應用程式在Linux 上運行,則使用支援多個DBMS 和作業系統的HA 解決方案將有助於您管理HA 的能力平台。與同時處理多個資料庫本機 HA 服務的潛在複雜性和繁瑣相比,選擇適應不同 DBMS 和作業系統平台的叢集解決方案可以簡化管理。 透過資料庫本機 HA 解決方案確保高可用性如果您使用資料庫本機 HA 解決方案(例如 SQL Server 的 AG 功能),該軟體會將主 SQL Server 資料庫中的所有資料同步複製到輔助系統伺服器上該資料庫的相同執行個體。如果某些原因導致主伺服器停止回應,AG 元件中的監控功能將自動導致輔助伺服器接手。由於AG功能即時複製了所有數據,因此輔助伺服器可以立即接管,幾乎不會出現服務中斷或資料遺失的情況。 許多資料庫本機 HA 工具都以類似的方式運作。不過,在考慮資料庫本機方法時,有一些注意事項:如果 HA 服務捆綁到 DBMS 本身中,它們可能只會複製與該 DBMS 關聯的資料。如果其他關鍵資料駐留在主伺服器上,則在資料庫本機 HA 場景中,這些資料不會複製到輔助伺服器。資料庫本機服務複製的內容可能還有其他限制。例如,如果您使用捆綁到 SQL Server 標準版中的基本 AG 功能,則每個 AG 只能將單一 SQL 資料庫複製到單一輔助位置。如果您的應用程式涉及多個 SQL 資料庫,您可以建立多個基本 AG,但您無法控制在故障轉移情況下每個 AG 是否同時進行故障轉移,否則可能會出現問題。解決此限制的一種方法是使用捆綁到SQL Server Enterprise Edition 中的Always On AG 功能,該功能可以將多個SQL 資料庫複製到多個輔助伺服器,但如果您的應用程式不這樣做,請從授權角度來看,這可能會變得非常昂貴否則,請使用 SQL Server Enterprise Edition 的任何功能。 其他資料庫本機 HA 解決方案可能有類似的限制,因此在投資這種方法之前一定要了解它們。 透過 SANless 叢集確保高可用性作為資料庫本機 HA 方法的替代方法,您可以使用第三方工具建立 SANless 叢集。如上述 AG 配置一樣,SANless 叢集軟體會自動將資料從主伺服器同步複製到輔助伺服器;如果主伺服器無回應,它還會安排立即故障轉移到輔助伺服器。由於故障轉移只需幾秒鐘,管理員、教師和學生對關鍵應用程式的存取幾乎不會中斷。 SANless 叢集和資料庫本機方法之間的關鍵差異在於實際細節。SANless 叢集方法與資料庫無關。它複製指定儲存卷上的任何資料。這可能包括來自多個供應商的多個資料庫、文字檔案、視訊檔案或任何其他可用性很重要的教育資產。如果資料庫本機 HA 方法需要升級到更昂貴的資料庫版本,這可以為機構節省大量資金。最後,如前所述,如果您試圖保護在多個操作環境中執行的應用程式和數據,SANless 叢集方法可能比單一資料庫本機方法更易於管理。您可以使用 SANless 叢集來確保 Windows 或 Linux 環境中的高可用性,這可以消除因操作環境而異的資料庫本機方法部署所帶來的複雜性。 經許可轉載安全作業系統 |
19 1 月, 2024 |
網路研討會:雲端中的災難復原:了解 SQL Server 的挑戰和策略網路研討會:雲端中的災難復原:了解 SQL Server 的挑戰和策略註冊參加點播網路研討會確保雲端中的高可用性 (HA) 和災難復原 (DR) 對許多組織來說可能是一個挑戰。與雲端中 HA/DR 相關的挑戰包括利用不同雲端供應商的各種工具的複雜性、資料主權考量、合規性挑戰以及持續的成本管理。 本次網路研討會將討論應對這些挑戰的方法,強調冗餘和故障轉移對於不間斷服務和資料保護的重要性,並探討有關雲端彈性的常見誤解以及強大的備份和災難復原策略的必要性。 經許可轉載安全作業系統 |
14 1 月, 2024 |
使用 SIOS LifeKeeper 在 AWS 中透過 HANA 3 節點 HSR 叢集建置高可用性使用 SIOS LifeKeeper 在 AWS 中透過 HANA 3 節點 HSR 叢集建置高可用性簡介:如何確保資料庫的 HA 和 DR在 AWS 中建立高度可用的 SAP HANA 環境是許多企業的關鍵任務。本指南提供了使用以下命令設定 3 節點 HANA 系統複製 (HSR) 叢集的詳細演練:SIOS 生命守護者在AWS中,確保資料庫彈性和高可用性。 先決條件
步驟 1:準備您的 AWS 環境 EC2執行個體部署 在 AWS 中部署三個 EC2 執行個體。這些實例將充當 HANA 叢集的主節點、輔助節點和第三節點。確保它們符合 SAP HANA 和 SIOS LifeKeeper 的硬體和軟體要求。確保在建置實例時遵循 SAP HANA 大小調整指南。 網路設定 配置您的 VPC、子網路和安全群組,以允許節點之間進行通訊並允許存取必要的服務。 在不同區域配置 HANA 節點時,您可以使用 SIOS LifeKeeper for Linux Route53 應用程式復原套件或 ARK 保護 DNS 名稱。以下是 AWS 中 3 節點 HANA 資料庫的架構: 設定儲存時,請為 /usr/sap、/hana/data、/hana/log 和 /hana/shared 使用單獨的 EBS 磁碟區。 我們有 2 個 VPC,每個區域一個。我們需要在 VPC 之間設定對等互連,並將路由新增至路由表中,以確保伺服器可以相互通訊。我們還需要修改安全群組以允許伺服器之間的流量。 最後,我們需要建立一個包含兩個 VPC 的託管區域,並新增用於與活動 HANA 節點通訊的網域和主機名稱的記錄。 步驟 2:安裝並設定 SAP HANA 每個節點上的安裝 在每個 EC2 執行個體上安裝 SAP HANA。確保所有節點的版本一致,以避免相容性問題。這是迄今為止最具挑戰性的過程。 首先確定您的安裝設定。對於我來說,我使用以下內容: SID:D11
本地實例儲存:
*對於此安裝,這些 HANA 資料庫伺服器之間未共用儲存。如果您嘗試使用共用存儲,您將無法建立相同的伺服器,因為 hdblcm 將阻止安裝並出現有關 SID 和實例已存在的錯誤。 在每個節點上獨立安裝 HANA 伺服器軟體,就好像它是一個獨立系統一樣。確保安裝了所有必需的庫,對於 RHEL 8,它們位於 SAP note 2772999 中。您需要確保在安裝 compact-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm 後創建符號鏈接通過運行: ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6
建立分割區、格式化儲存並附加它。建立您的交換文件。 我在所有主機上建立 RSA 金鑰,然後透過將公鑰新增至 .ssh/authorized_keys 檔案來允許 root ssh 在 hana 節點之間登入。這將使安裝變得更加容易。 裝載 HANA 安裝媒體磁碟區。
從正確的 hana 安裝媒體目錄運行 hdblcm。在所有節點上成功安裝 HANA 後,您就可以開始下一步了。 系統複製設定 您需要在啟用 HSR 之前進行備份:
在所有節點上重複上述備份過程。 在每個節點上配置 HANA 系統複製: 在主 HANA 系統上啟動 HDB 實例(如果尚未執行): sapcontrol -nr <實例編號> -function StartSystem HDB [即:sapcontrol -nr 11 -function StartSystem HDB] 在主站啟動 HSR: hdbnsutil -sr_enable –name=<主站台名稱> [即。hdbnsutil -sr_enable –name=sapdemohana1 停止輔助 HANA 系統上的 HDB 實例: sapcontrol -nr <實例編號> -function StopSystem HDB [即。sapcontrol -nr 11 -function StopSystem HDB] 在其他 HANA 系統中,備份 KEY 和 DAT 檔案並將主 KEY 和 DAT 檔案複製到所需位置:
確保金鑰和 dat 檔案的擁有者是 <SID>adm sapsys:
將附加 HANA 系統註冊到主 HANA 系統 – 必須以管理員使用者身分完成:
[IE。hdbnsutil -sr_register –name=sapdemohana2 –remoteHost=sapdemohana1 –remoteInstance=11 –operationMode=logreplay –replicationMode=sync] 檢查所有系統上的 HSR 狀態,以管理員使用者身分執行以下命令: d11adm@sapdemohana4:/usr/sap/D11/HDB11>hdbnsutil -sr_state 一旦所有系統都在線,您就可以進入下一步。 步驟 3:安裝 SIOS LifeKeeper AWS CLI 安裝 安裝 AWS CLI 並使用具有以下權限的金鑰對其進行配置: 路由表(後端)配置:
LifeKeeper安裝 在每個節點上安裝 SIOS LifeKeeper。這涉及運行安裝腳本並遵循安裝嚮導,該嚮導將指導您完成必要的步驟。對於此安裝,我使用網路、Route53 ARK 和資料庫、SAP HANA ARK 以及見證功能。 編輯 /etc/selinux/config 檔案並停用 selinux: 我還更改了主機名稱並編輯了 /etc/hosts 檔案。最後編輯 /etc/default/LifeKeeper 檔案並將 /usr/local/bin 加入到 PATH 中: 更改 NOBCASTPING=1: 我還將 QUORUM_LOSS_ACTION 更改為 osu: 確保 Xwindows 可以工作。我從.bashrc 中刪除cp 別名,並將/opt/LifeKeeper/bin 和/usr/local/bin 加入到我的.bash_profile 中,並將ec2-users .Xauthority 檔案複製到root 和<SID>adm 主目錄,以便Xwindows將工作: 我更改 root 密碼並重新啟動。在啟動 LifeKeeper GUI 之前。確保 HSR 在所有節點上都在線並且所有節點都已註冊: 配置 啟動 LifeKeeper GUI:lkGUIapp 並使用 root 使用者和密碼登入: 點選連線按鈕登入叢集中的其他節點: 登入所有節點後,按一下「建立通訊路徑」按鈕: 當它要求本地伺服器時點擊下一步,然後按住 Shift 並選擇所有節點: 點擊“接受預設值”並在完成後點擊“完成”。再次點擊「建立通訊路徑」按鈕,這次更改為第二個節點: 點擊下一步並選擇第三個節點: 按一下“下一步”按鈕,直到您可以按一下“接受預設值”按鈕。當完成擊中完成。現在點選「建立資源層次結構」按鈕: 選擇 IP 套件並點擊下一步: 點擊下一步,直到到達 IP 資源頁面。這裡輸入 0.0.0.0 並點選下一步: 點擊下一步,直到到達“創建”按鈕。點擊建立按鈕: 完成後點選下一步:點選接受預設值,目標伺服器顯示第二個節點: 完成後點擊下一個伺服器: 點擊“接受預設值”,顯示第三個節點,完成後點擊“完成”: 命中完成: 現在我們有了一個 IP 資源,我們可以新增 Route53 資源,這將更改 dns 條目以將 FQDN 解析為活動節點 IP 位址。在這種情況下,saphana.sapdemo 將解析為 sapdemohana1 的 IP 位址 (172.31.0.25)。點擊「建立資源層次結構」按鈕開始這個過程: 選擇 Route53 並點選下一步: 繼續點擊下一步,直到到達網域。它應該預先填入活動託管區域名稱。點擊下一步。 輸入所有內容將用於連接 HANA 資料庫的主機名,然後點擊下一步: 點擊下一步,直到到達建立按鈕,然後點擊建立按鈕。完成後點選下一步: 在預擴展精靈中點選接受預設值: 完成後點擊下一個伺服器: 目標伺服器將顯示第三個節點。點擊接受預設值: 完成後點選“完成”。然後點選“完成”。然後您可以展開樹。開啟與第二個節點的終端會話並 ping HANA 資料庫的 FQDN [即。ping -c3 saphana.sapdemo] 右鍵單擊 sapdemohana3 下的頂部 Standby,然後選擇 In Service: 在下一個畫面上點選“服務中”,然後在完成後點選“完成”: 轉到終端機視窗並重複 ping 測試: 您可以看到主機名稱現在解析為 sapdemohana3。在繼續下一步之前,將 sapdemohana1 重新投入使用。 步驟 4:將 SAP HANA 與 SIOS LifeKeeper 集成 資源層次結構創建 使用 LifeKeeper GUI,在每個節點上為 SAP HANA 建立資源層次結構。此設定對於管理故障轉移和復原過程至關重要。確保 HSR 在節點 1 上處於活動狀態並且其他節點已註冊: 點選建立資源按鈕: 選擇 SAP HANA 復原工具包並點選下一步,直到到達 IP 位址畫面: 選擇無並點選下一步: 點擊下一步,直到到達「建立」畫面並點擊「建立」: 建立後點選下一步,然後接受節點2的預設值: 當node2完成後,再次點選「Next Server」並接受預設值: 完成後點選“完成”,然後點選“完成”: 右鍵點選 Hana Hierarchy 並選擇 Create Dependency: 對於子資源標籤,從下拉清單中選擇route53資源,然後點選下一步: 按一下建立依賴項: 按一下“完成”。然後選擇查看展開樹: 如果一切都是綠色的,我們就準備好測試了。 第 5 步:測試和驗證 故障轉移/切換測試 進行徹底的故障切換測試,確保在主節點發生故障時系統能夠正確切換到輔助或第三節點。此測試應包括網路故障、硬體問題和軟體崩潰等場景。 我們將執行的第一個測試是切換,用於執行維護活動或計劃停機。右鍵點選第二個節點並選擇 In Service – Takeover with Handshake… 點選執行接管: 此測試將切換到第二個節點,以最大限度地減少使用者的停機時間。當第二個節點啟動並運行時,點擊完成: 一段時間後,節點 1 將恢復待機狀態 – 同步。 現在我們可以執行故障轉移測試。開啟節點 2 的終端並輸入 echo c > /proc/sysrq-trigger 以模擬系統崩潰。您將看到節點 1 接管,因為它具有最高優先權 1: 最終,一切都會恢復正常: 您可能想要測試許多其他類型的故障場景。只需在開始測試之前確保備用節點同步即可。 資料同步驗證 驗證資料是否在所有節點之間正確複製。節點間資料的一致性對於 HSR 設定的完整性至關重要。 效能監控 定期監控 SAP HANA 實例和 LifeKeeper 設定的效能。檢查是否有任何可能表明潛在問題的異常或問題。檢查 /var/log/lifekeeper.log 檔案以確保一切都按預期執行。您可能需要根據網路效能調整心跳定時器和心跳失去次數。這些可以在 /etc/default/LifeKeeper 檔案中配置。可調參數為 LCMHBEATTIME 和 LCMNUMHBEATS。您也可以使用指令 lcdstatus -q 從命令列檢查 Lifekeeper 的狀態。 結論 使用 SIOS LifeKeeper 在 AWS 中設定 3 節點 HANA HSR 叢集涉及詳細的規劃和執行。透過仔細遵循這些步驟,您可以在雲端建立強大、有彈性且高度可用的 SAP HANA 環境,確保您的關鍵資料保持可存取且安全。適用於 Linux 的 SIOS LifeKeeper 讓 SAP HANA 的管理、監控和維護變得快速、輕鬆。 經許可轉載安全作業系統
|