Archives for 5 月 2022

適用於 Linux 的 SIOS 保護套件/LifeKeeper – 集成組件

西歐Protection Suite 包括以下軟件組件，用於保護組織的關鍵任務系統。

西歐救生員

西歐LifeKeeper 提供了一個完全的容錯軟件解決方案實現服務器、文件系統、應用程序和進程的高可用性。 LifeKeeper 不需要任何定制的容錯硬件。 LifeKeeper 只需將兩個或多個系統組合在一個網絡中，然後創建特定於站點的配置數據以提供自動故障檢測和恢復.

如果發生故障，LifeKeeper 會將受保護的資源從故障服務器遷移到指定的備用服務器。 用戶在實際切換過程中會遇到短暫的中斷。 但是，LifeKeeper 無需操作員干預即可恢復備用服務器上的操作。

西歐數據守護者

西歐DataKeeper 為 LifeKeeper 環境提供集成的數據複製功能。 此功能使 LifeKeeper 資源能夠在共享和非共享存儲環境.

應用程序恢復工具包 (方舟s)

應用程序恢復工具包 (方舟s) 包括允許 LifeKeeper 管理和控制特定應用程序或服務的工具和實用程序。 當一個方舟為特定應用程序安裝後，LifeKeeper 能夠監控應用程序的健康狀況，並在應用程序失敗時自動恢復應用程序。 這些恢復工具包是非侵入式的，不需要在應用程序中進行任何更改，即可受到 LifeKeeper 的保護。

作為西歐保護套件產品組合。 種類和數量方舟提供的 s 因版本而異西歐已購買保護套件。

經授權轉載西歐

適用於 AWS 雲環境的 SIOS Protection Suite for Linux 評估指南

開始在 AWS 中評估適用於 Linux 的 SIOS 保護套件

使用此分步指南在 AWS 中配置和測試雙節點集群，以保護 Oracle、SQL Server、PostgreSQL、NFS、SAP 和 SAP HANA 等資源。

開始評估之前

在 AWS 中開始您的故障轉移集群項目之前，請查看這些鏈接以了解您需要的關鍵概念。

• 高可用性， RTO ， 和RPO – 清楚了解 HA 的基本概念。

• 西歐適用於 Linux 的保護套件 – 集成組件– 了解 SIOS 保護套件中包含的組件：SIOS LifeKeeper、DataKeeper 和應用程序恢復工具包/

• 的好處西歐Linux 保護套件– 了解 SIOS Protection Suite for Linux 如何提供卓越的數據保護

• 遷移到雲環境時應如何分配工作負載– 與本地環境不同，公共雲產品在部署工作負載時為您提供了廣泛的地理區域可用區供您選擇。 了解為雲選擇工作負載分配策略的最佳實踐。

• 公有云平台及其網絡結構差異– 公共雲提供商有自己的網絡結構。 了解這些結構如何影響您的集群配置的基礎知識。

• 客戶端如何連接到活動節點– 了解檢測和管理對應用程序故障的響應的關鍵集群機制。

• 節點之間的數據複製如何工作？– 確保存儲冗餘至關重要。 了解 SIOS DataKeeper 如何在節點之間高效複製數據。

• 什麼是“腦裂”以及如何避免它了解如何確保即使網絡連接失敗，您也能維持一個活動節點和一個或多個備用節點。

配置網絡組件

本節概述了每個節點所需的計算資源、網絡結構以及配置這些組件所需的過程。

• 了解如何為故障轉移群集配置網絡組件
• 本教程中使用的網絡結構
• 本教程中使用的計算資源

創建一個實例AWS從零開始的 EC2

• 從頭開始在 AWS 上創建實例
• 在之間切換AWS服務
• 決定一個AWS地區
• 創建專有網絡
• 創建子網
• 創建 Internet 網關並將其分配給專有網絡
• 創建路由表
• 創建安全組
• 創建第一個 EC2 實例
• 創建第二個和第三個實例

配置 Linux 節點以運行適用於 Linux 的 SIOS 保護套件

• 配置 Linux 節點以運行適用於 Linux 的 SIOS 保護套件

安裝適用於 Linux 的 SIOS 保護套件

• 安裝適用於 Linux 的 SIOS 保護套件

登錄和基本配置

• 登錄和基本配置

保護關鍵資源

• 在網絡中創建 IP 資源本地環境
• 在節點之間切換雲環境

一旦 IP 資源受到保護，啟動切換（“備用”節點變為“活動”節點）以測試功能。

• 如何切換到備用節點以確認切換正常
• 保護 Oracle 資源
• 保護微軟SQL使用快速服務保護
• 保護 PostgreSQL 資源
• 保護一個NFS資源
• 保護樹液資源
• 保護樹液漢娜資源

經授權轉載西歐

具有區域冗餘存儲 (ZRS) 的 Azure 共享磁盤的性能

2021 年 9 月 9 日，微軟宣布的普遍可用性Azure 磁盤存儲的區域冗餘存儲 (ZRS) ，包括 Azure 共享磁盤。

有趣的是，您現在可以構建跨可用區 (AZ) 的基於共享存儲的故障轉移集群實例。由於集群節點位於不同的 AZ，用戶現在可以獲得 99.99% 的可用性 SLA。 在支持區域冗餘存儲之前，Azure 共享磁盤僅支持本地冗餘存儲 (LRS)，將集群部署限制在單個 AZ，如果 AZ 脫機，用戶很容易受到中斷的影響。

但是，在使用 ZRS 部署 Azure 共享磁盤時需要注意一些限制。

• 僅支持高級固態驅動器 (SSD) 和標準 SSD。 不支持 Azure 超級磁盤。
• 帶有 ZRS 的 Azure 共享磁盤目前僅在美國西部 2、西歐、北歐和法國中部區域可用
• 高級 SSD Azure 共享磁盤不支持讀取和寫入磁盤緩存
• 磁盤突發不適用於高級 SSD
• Azure Site Recovery 支持尚不可用。
• Azure 備份僅可通過 Azure 磁盤備份獲得。
• 僅支持服務器端加密，目前不支持 Azure 磁盤加密。

我還發現了一個有趣的註釋文件.

“除了更多的寫入延遲之外，使用 ZRS 的磁盤與使用 LRS 的磁盤相同，它們具有相同的擴展目標。 對磁盤進行基準測試以模擬應用程序的工作負載並比較 LRS 和 ZRS 磁盤之間的延遲。”雖然文檔表明 ZRS 會產生一些額外的寫入延遲，但由用戶決定他們可以預期多少額外的延遲。 一個鏈接磁盤基準提供文檔以幫助指導您進行性能測試。

按照文檔中的指導，我使用 DiskSpd 來測量您可能遇到的額外寫入延遲。 當然，結果會因工作負載、磁盤類型、實例大小等而異，但這是我的結果。

	本地冗餘存儲 (LRS)	區域冗餘存儲 (ZRS)
寫 IOPS	5099.82	4994.63
平均延遲	7.830	7.998

我運行的 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 中。

這是結果。

	本地冗餘存儲 (LRS)	區域冗餘存儲 (ZRS)	從遠程 AZ 寫入時的 ZRS
寫 IOPS	5099.82	4994.63	4079.72
平均延遲	7.830	7.998	9.800

在那種情況下，我測量了 25% 的寫入延遲增加。 如果您遇到 AZ 完全故障，存儲和實例都將故障轉移到輔助 AZ，您根本不應該遇到這種延遲增加。 但是，其他不屬於 AZ 範圍的故障場景很可能讓您的集群應用程序在一個 AZ 中運行，而您的 Azure 共享磁盤在另一個 AZ 中運行。 在這些情況下，您需要盡快將集群工作負載移回與存儲位於同一可用區的節點，以避免額外的開銷。

微軟文檔如何啟動存儲帳戶故障轉移使用 GRS 時到不同的區域，但在使用區域冗餘存儲時無法手動啟動存儲帳戶到不同 AZ 的故障轉移。 您應該監控您的故障轉移集群實例，以確保在集群工作負載移動到其他服務器時收到警報，併計劃在安全的情況下盡快將其移回。

您可能會意外地發現自己處於這種情況，但在您執行滾動更新時，在集群應用程序服務器的計劃維護期間肯定也會發生這種情況。 意識是幫助您最大限度地減少存儲在降級狀態下執行的時間的關鍵。

我希望將來微軟允許用戶像使用 GRS 一樣啟動 ZRS 磁盤的手動故障轉移。 他們向 GRS 添加該功能的原因是將權力交到用戶手中，以防自動故障轉移沒有按預期發生。 在區域冗餘存儲的情況下，我可以看到人們希望嘗試將存儲和應用程序捆綁在一起，確保它們始終在同一個 AZ 中運行，類似於 SIOS DataKeeper 等基於主機的複制解決方案的做法。

可用性 SLA：FT、高可用性和災難恢復——從哪裡開始

可以公平地說，在這個我們生活的許多方面都由技術驅動的現代時代，我們生活在一個瞬息萬變的世界中。例如，只需單擊一個按鈕，我們每週的雜貨訂單就會送到我們家門口。我們可以立即購買活動或旅行的門票。甚至這些天，訂購一輛全新的汽車，而不必去展廳附近的任何地方和一個咄咄逼人的銷售人員打交道。 我們被這個便利的世界寵壞了。

但是，讓我們想想必須支持這種服務水平的所有供應商和服務提供商。他們必須保持高水平的投資，以確保他們的底層基礎設施（特別是他們的 IT 基礎設施）的構建和運營方式能夠支持這種“永遠在線”的期望。應用程序和數據庫必須始終運行，以滿足客戶需求並最大限度地提高公司的生產力和收入。IT 業務連續性的重要性與以往一樣重要。

許多 IT 可用性概念都在流傳，例如容錯 (FT) ,高可用性（哈）和災難恢復(博士) .但這可能會引發更多問題。這些可用性概念之間有什麼區別？其中哪一個適合我的基礎架構？它們可以組合或互換嗎？ 任何可用性計劃的第一步也是最重要的一步是建立明確的應用程序/數據庫可用性服務級別協議 (SLA)。然後，這定義了最合適的可用性方法。

什麼是 SLA？

在某種程度上，我們都知道 SLA 是什麼，但對於本次討論，讓我們確保我們都在同一個波長上。 可用性 SLA 是服務提供商與其最終用戶之間的合同，它定義了供應商要確保的應用程序/數據庫正常運行時間和可訪問性的預期水平，並概述瞭如果商定的服務水平不符合所涉及的處罰（通常是財務）遇見了。在 IT 世界中，SLA 是根據對業務的兩個關鍵性衡量標準制定的——恢復時間目標 (RTO) 和恢復點目標 (RPO)。非常簡單，RTO 定義了在發生故障時我們需要多快恢復應用程序操作。 RPO 定義了在發生恢復情況時我們的數據需要達到的最新程度。 一旦您可以為您的應用程序和數據庫識別這些指標，這將定義您的 SLA。SLA 以百分比來衡量，因此，例如，您可能會遇到諸如 99.9% 或 99.99% 可用等術語。這些是 IT 將在給定年份為應用程序保證多少分鐘的正常運行時間和可用性的度量。 一般來說，更多的保護意味著更多的成本。 因此，估算應用程序或數據庫停機一小時的成本並將此 SLA 用作選擇具有良好業務意義的解決方案的工具至關重要。

一旦我們有了 SLA，我們就可以就哪種類型的解決方案（FT、HA、DR 或它們的組合）做出最適合我們可用性需求的方法的業務決策。

什麼是容錯 (FT)？

FT 提供了令人印象深刻的可用性 SLA，達到 99.999%。在現實世界中，FT 解決方案將保證一年內不超過 5.25 分鐘的停機時間。本質上，兩台相同的服務器彼此並行運行，在所謂的“鎖步”過程中以主動-主動配置同時處理兩台服務器上的事務。 如果主服務器出現故障，輔助服務器將繼續處理，不會中斷應用程序或丟失任何數據。最終用戶會很高興地沒有意識到發生了服務器故障。

這聽起來太棒了！這聽起來棒極了！為什麼我們還需要其他東西？但是等等……就像 FT 在紙上聽起來一樣棒，有一些警告需要考慮。

“鎖步”過程是一頭奇怪的野獸。它可以運行的服務器硬件類型非常挑剔，特別是在處理器方面。這個有限的硬件兼容性列表迫使 FT 解決方案位於成本範圍的高端，當您考慮兩個或更多具有相關支持和服務的 FT 集群時，成本可能高達數十萬美元。

軟件錯誤漏洞

FT 解決方案在設計時也考慮到了硬件容錯，不會過多關注任何潛在的應用程序錯誤。請記住，FT 解決方案同時運行相同的事務和進程，因此如果主服務器上出現應用程序錯誤，這也會在輔助服務器上得到復制。

什麼是高可用性 (HA)？

對於大多數 SLA，對於普通用例來說，購買和管理 FT 的成本太高了。在大多數情況下，HA 解決方案是更好的選擇。 它們以很少的成本提供幾乎相同級別的保護。HA 解決方案通過以 Active-Standby 方式部署，可提供 99.99% 的 SLA，相當於一年內停機約 52 分鐘。引入了減少的 SLA，因為在恢復操作之前活動服務器必須切換到備用服務器的一小段停機時間。好吧，這不像 FT 解決方案那樣令人印象深刻，但是對於大多數 IT 要求，HA 滿足 SLA，即使對於 CRM 和 ERP 系統等超關鍵應用程序也是如此。

同樣重要的是，高可用性解決方案與應用程序無關，並且還可以在應用程序故障以及硬件或操作系統故障時管理服務器的故障轉移。 它們還允許更多的配置靈活性。沒有類似 FT 的硬件兼容性列表需要處理，因為在大多數情況下，它們將在支持底層操作系統的任何平台上運行。

災難恢復 (DR) 如何融入其中？

與 FT 和 HA 一樣，DR 也可用於支持關鍵業務功能。 但是，DR 可以與 FT 和 HA 結合使用。容錯和高可用性專注於維護本地級別的正常運行時間，例如在數據中心（或云可用性區域）內。災難恢復提供冗餘站點或數據中心以在災難襲擊主數據中心時進行故障轉移。

這是什麼意思呢？

歸根結底，沒有錯誤或正確的可用性方法可供選擇。它歸結為您試圖保護的業務流程的重要性以及解決方案的基本經濟性。在某些情況下，這是不費吹灰之力的。例如，如果您正在運行核電站，我會覺得關鍵操作受到 FT 系統的保護會更舒服。 讓我們面對現實吧，您可能不希望那裡的服務有任何中斷。但是對於大多數 IT 環境，關鍵的正常運行時間也可以通過 HA 以更易於消化的價格提供。

如何選擇：FT、HA和DR？

• 首先，詳細了解您的業務運營並確定停機成本。
• 建立 SLA 後，權衡選擇的可用性解決方案的成本與任何潛在停機時間的成本。
• 在選擇可用性解決方案時，請考慮易於部署和易於使用，因為這些也會影響可用性解決方案的總體 TCO。

IT 系統很強大，但在最不方便的時候它們可能會出錯。 FT、HA 和 DR 是您的保險單，可在這個以即時和便利為主導的世界中向客戶提供 SLA 時為您提供保護。

經授權轉載西歐