3 6 月, 2022 |
適用於 Linux 的 SIOS 保護套件/LifeKeeper 的優勢適用於 Linux 的 SIOS 保護套件/LifeKeeper 的優勢
經授權轉載西歐 |
|||||||||||||||||||||
29 5 月, 2022 |
適用於 Linux 的 SIOS 保護套件/LifeKeeper – 集成組件適用於 Linux 的 SIOS 保護套件/LifeKeeper – 集成組件西歐Protection Suite 包括以下軟件組件,用於保護組織的關鍵任務系統。 西歐救生員西歐LifeKeeper 提供了一個完全的容錯軟件解決方案實現服務器、文件系統、應用程序和進程的高可用性。 LifeKeeper 不需要任何定制的容錯硬件。 LifeKeeper 只需將兩個或多個系統組合在一個網絡中,然後創建特定於站點的配置數據以提供自動故障檢測和恢復. 如果發生故障,LifeKeeper 會將受保護的資源從故障服務器遷移到指定的備用服務器。 用戶在實際切換過程中會遇到短暫的中斷。 但是,LifeKeeper 無需操作員干預即可恢復備用服務器上的操作。 西歐數據守護者西歐DataKeeper 為 LifeKeeper 環境提供集成的數據複製功能。 此功能使 LifeKeeper 資源能夠在共享和非共享存儲環境. 應用程序恢復工具包 (方舟s)應用程序恢復工具包 (方舟s) 包括允許 LifeKeeper 管理和控制特定應用程序或服務的工具和實用程序。 當一個方舟為特定應用程序安裝後,LifeKeeper 能夠監控應用程序的健康狀況,並在應用程序失敗時自動恢復應用程序。 這些恢復工具包是非侵入式的,不需要在應用程序中進行任何更改,即可受到 LifeKeeper 的保護。 作為西歐保護套件產品組合。 種類和數量方舟提供的 s 因版本而異西歐已購買保護套件。 經授權轉載西歐 |
|||||||||||||||||||||
25 5 月, 2022 |
高可用性、RTO 和 RPO高可用性、RTO 和 RPO高可用性 (HA) 是一個信息技術術語,指的是在超過 99.99% 的時間內可運行且可用的計算機軟件或組件。 應用程序或系統的最終用戶每年的服務中斷時間少於 52.5 分鐘。 這種可用性級別通常是通過使用高可用性集群來實現的,這種配置通過使用冗餘服務器、網絡、存儲和軟件消除單點故障來減少應用程序停機時間。 什麼是恢復時間目標( RTO ) 和恢復點目標 ( RPO )?除了 99.99% 的可用時間,高可用性環境還滿足嚴格的恢復時間和恢復點目標。 恢復時間目標( RTO ) 是從應用程序故障到恢復應用程序操作和可用性所用時間的度量。 這是衡量公司可以承受多長時間關閉該應用程序的指標。 恢復點目標( RPO ) 衡量在停機問題後應用程序可用性恢復時數據的最新程度。 它通常被描述為發生故障時可以容忍的最大數據丟失量。西歐高可用性集群提供RPO零和一個RTO分鐘。 什麼是高可用性集群?在高可用性集群中,重要的應用程序運行在一個主服務器節點上,該節點連接到一個或多個輔助節點以實現冗餘。 集群軟件,如西歐LifeKeeper,監控集群應用程序和依賴資源,以確保它們在活動節點上運行。 系統級監控是通過集群節點之間的間隔心跳來完成的。 如果主服務器出現故障,則在超過心跳超時時間間隔後,從服務器啟動恢復。 對於應用程序級故障,集群軟件檢測到應用程序在活動節點上不可用。 然後,它將應用程序和相關資源在稱為故障轉移的過程中移動到輔助節點,在該過程中繼續運行並滿足嚴格的要求RTO s。 在傳統的故障轉移集群中,集群中的所有節點都連接到同一個共享存儲,通常是一個存儲區域網絡( SAN )。 故障轉移後,輔助節點被授予訪問共享存儲的權限,使其能夠滿足嚴格的RPO s。 經授權轉載西歐
|
|||||||||||||||||||||
21 5 月, 2022 |
適用於 AWS 雲環境的 SIOS Protection Suite for Linux 評估指南適用於 AWS 雲環境的 SIOS Protection Suite for Linux 評估指南開始在 AWS 中評估適用於 Linux 的 SIOS 保護套件使用此分步指南在 AWS 中配置和測試雙節點集群,以保護 Oracle、SQL Server、PostgreSQL、NFS、SAP 和 SAP HANA 等資源。 開始評估之前在 AWS 中開始您的故障轉移集群項目之前,請查看這些鏈接以了解您需要的關鍵概念。
配置網絡組件本節概述了每個節點所需的計算資源、網絡結構以及配置這些組件所需的過程。 創建一個實例AWS從零開始的 EC2
配置 Linux 節點以運行適用於 Linux 的 SIOS 保護套件安裝適用於 Linux 的 SIOS 保護套件登錄和基本配置保護關鍵資源一旦 IP 資源受到保護,啟動切換(“備用”節點變為“活動”節點)以測試功能。 |
|||||||||||||||||||||
16 5 月, 2022 |
具有區域冗餘存儲 (ZRS) 的 Azure 共享磁盤的性能具有區域冗餘存儲 (ZRS) 的 Azure 共享磁盤的性能2021 年 9 月 9 日,微軟宣布的普遍可用性Azure 磁盤存儲的區域冗餘存儲 (ZRS) ,包括 Azure 共享磁盤。 有趣的是,您現在可以構建跨可用區 (AZ) 的基於共享存儲的故障轉移集群實例。由於集群節點位於不同的 AZ,用戶現在可以獲得 99.99% 的可用性 SLA。 在支持區域冗餘存儲之前,Azure 共享磁盤僅支持本地冗餘存儲 (LRS),將集群部署限制在單個 AZ,如果 AZ 脫機,用戶很容易受到中斷的影響。 但是,在使用 ZRS 部署 Azure 共享磁盤時需要注意一些限制。
我還發現了一個有趣的註釋文件. “除了更多的寫入延遲之外,使用 ZRS 的磁盤與使用 LRS 的磁盤相同,它們具有相同的擴展目標。 對磁盤進行基準測試以模擬應用程序的工作負載並比較 LRS 和 ZRS 磁盤之間的延遲。”雖然文檔表明 ZRS 會產生一些額外的寫入延遲,但由用戶決定他們可以預期多少額外的延遲。 一個鏈接磁盤基準提供文檔以幫助指導您進行性能測試。 按照文檔中的指導,我使用 DiskSpd 來測量您可能遇到的額外寫入延遲。 當然,結果會因工作負載、磁盤類型、實例大小等而異,但這是我的結果。
我運行的 DiskSpd 測試使用了以下參數。 diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat 我寫到一個帶有 ZRS 的 P30 磁盤和一個帶有 LRS 的 P30 連接到標準 DS3 v2(4 vcpus,14 GiB 內存) 實例類型。 共享 ZRS P30 還附加到不同 AZ 中的相同實例,並作為共享存儲添加到空集群應用程序。 2% 的開銷似乎是讓您的數據在兩個 AZ 上同步分佈的合理價格。 但是,我確實想知道如果您將集群應用程序移動到遠程節點會發生什麼,有效地將您的磁盤放在一個 AZ 中,而將您的實例放在另一個 AZ 中。 這是結果。
在那種情況下,我測量了 25% 的寫入延遲增加。 如果您遇到 AZ 完全故障,存儲和實例都將故障轉移到輔助 AZ,您根本不應該遇到這種延遲增加。 但是,其他不屬於 AZ 範圍的故障場景很可能讓您的集群應用程序在一個 AZ 中運行,而您的 Azure 共享磁盤在另一個 AZ 中運行。 在這些情況下,您需要盡快將集群工作負載移回與存儲位於同一可用區的節點,以避免額外的開銷。 微軟文檔如何啟動存儲帳戶故障轉移使用 GRS 時到不同的區域,但在使用區域冗餘存儲時無法手動啟動存儲帳戶到不同 AZ 的故障轉移。 您應該監控您的故障轉移集群實例,以確保在集群工作負載移動到其他服務器時收到警報,併計劃在安全的情況下盡快將其移回。 您可能會意外地發現自己處於這種情況,但在您執行滾動更新時,在集群應用程序服務器的計劃維護期間肯定也會發生這種情況。 意識是幫助您最大限度地減少存儲在降級狀態下執行的時間的關鍵。 我希望將來微軟允許用戶像使用 GRS 一樣啟動 ZRS 磁盤的手動故障轉移。 他們向 GRS 添加該功能的原因是將權力交到用戶手中,以防自動故障轉移沒有按預期發生。 在區域冗餘存儲的情況下,我可以看到人們希望嘗試將存儲和應用程序捆綁在一起,確保它們始終在同一個 AZ 中運行,類似於 SIOS DataKeeper 等基於主機的複制解決方案的做法。 |