具有區域冗餘存儲 (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 時為您提供保護。

經授權轉載西歐

如何避免 IO 瓶頸：Windows 雲部署的 DataKeeper 意圖日誌放置指南

為了確保最佳的應用程序性能，在部署時SIOS 數據保持器重要的是放置意圖日誌（位圖文件）在可用的最低延遲磁盤上，避免 IO 瓶頸。 在 AWS、GCP 和 Azure 中，可用的最低延遲磁盤是臨時驅動器。 但是，在 Azure 中，使用臨時驅動器與高級 SSD 之間的差異很小，因此在 Azure 中運行 DataKeeper 時沒有必要使用臨時驅動器。 然而，在 AWS 和 GCP 中，必須將意圖日誌重新定位到臨時驅動器，否則寫入吞吐量將受到顯著影響。

在為位圖文件使用臨時磁盤時，需要進行權衡。 臨時驅動器的本質是不能保證存儲在其上的數據是持久的。 事實上，如果從控制台停止雲實例，則附加到該實例的臨時驅動器將被丟棄，並為該實例附加一個新驅動器。 在此過程中，位圖文件將被丟棄，並在其位置上放置一個新的空位圖文件。

在某些情況下，如果位圖文件丟失，則會發生完全重新同步。 例如，如果一個主服務器SANless 集群r 從控制台關閉會發生故障轉移，但是當服務器重新聯機時，將從鏡像的新源到舊源進行完全重新同步。 這會自動發生，因此用戶無需執行任何操作，並且活動節點在此重新同步期間保持在線。

在其他情況下，位圖文件的放置也會影響性能。 例如，如果您要復制 NVMe 驅動器，您將需要在 NVMe 驅動器上劃出一個小分區來保存位圖文件。 一般的經驗法則是位圖文件應該位於實例上最快、最低延遲的磁盤上。 它還應該位於不會對其他 IO 操作過度徵稅的磁盤上。

有關如何重新定位意圖日誌的信息，請參閱DataKeeper 文檔. 有關如何使用意圖日誌的其他信息，請參閱DataKeeper 文檔.

經授權轉載西歐

領先的媒體平台保護 AWS EC2 雲中的關鍵 SAP S/4 HANA

基於 SAP、Amazon Web Services 和 Red Hat Linux 的認證和驗證選擇 SIOS

這家領先的媒體機構每週都會接觸到新加坡幾乎所有的成年人。通過該國最廣泛的媒體平台，包括數字、電視、廣播、印刷和戶外媒體以及四種語言（英語、普通話、馬來語和泰米爾語）的 50 多個產品和品牌。

環境

該公司使用一個SAP S/4 HANA 應用程序和HANA 數據庫為整個組織的運營提供動力，統一多個部門的運營。 他們在本地數據中心的 Red Hat Linux 環境中運行這些關鍵應用程序和數據庫。 保護這些基本系統免受停機和災難的影響是該組織的 IT 團隊的首要任務。

挑戰

該媒體組織的 IT 團隊認識到，他們可以通過將其 SAP 應用程序和 HANA 數據庫遷移到 AWS EC2 雲中來顯著節省成本。 但是，為了成功遷移，他們需要一個高可用性 (HA) 和災難恢復 (DR) 解決方案，該解決方案可以在不中斷現有 SAP 環境的情況下“升級並轉移”到 AWS。

評價

該公司的 IT 團隊需要一個他們可以依賴的 HA/DR 解決方案來滿足其在雲中 99.99% 的可用性 SLA。 該解決方案需要通過 SAP 和 AWS 的認證並支持 Red Hat Linux 操作系統。 最後，為了確保他們能夠為這些關鍵工作負載提供完整的 DR 保護，他們需要一個能夠跨多個 AWS 可用區 (AZ) 進行故障轉移的集群解決方案。 AWS 解決方案架構師建議該組織使用 SIOS LifeKeeper for Linux 集群軟件。 該公司的 IT 團隊完成該項目的時間很短，需要選擇一個既能滿足他們的要求又不妨礙他們進展的 HA 供應商。

解決方案

他們之所以選擇 SIOS LifeKeeper，是因為它不僅符合我們的所有標準，還因為 SIOS 團隊組織得非常迅速，使他們能夠按計劃進行雲遷移項目。 SIOS Lifekeeper 已通過 AWS 和 SAP 認證，可在 Red Hat 和 AWS EC2 雲環境中實現高可用性。 SIOS 解決方案還滿足另一個關鍵標準，因為它能夠跨 AWS 可用區域進行複制和提供冗餘 SIOS 的專門本地支持團隊給組織的 IT 團隊留下了深刻的印象，他們可以 7 天、每天 24 小時回答問題並提供支持一周。 該組織目前有五對故障轉移集群，使用 SIOS LifeKeeper for Linux 來保護在 AWS EC2 中跨多個可用區運行的 S/4 HANA 和 SAP HANA 應用程序。

結果

可用性一直很可靠，自從使用該軟件以來，我們沒有任何延長的停機時間通過使該客戶能夠將這些重要的工作負載遷移到雲而不犧牲 HA/DR 或應用程序性能，SIOS 使我們能夠實現顯著的成本節約，”他說。 SIOS LifeKeeper 的 Mediacorp 易用性通過最大限度地減少 IT 管理時間節省了更多。

經授權轉載西歐

保護系統免於停機

在當今的業務環境中，組織依賴於應用程序、數據庫和 ERP 系統，例如 SAP、SQL Server、Oracle 等。 這些應用程序統一併簡化了您最關鍵的業務運營。 當他們失敗時，他們花費的不僅僅是金錢。 保護這些複雜的系統免於停機至關重要。

經驗證的高可用性和災難恢復

SIOS 在以下領域擁有 20 多年的經驗高可用性和災難恢復.SIOS 知道沒有一種萬能的解決方案。 當今的數據系統是本地、公共雲、混合雲和多雲環境的組合。 應用程序本身可以創造更多的複雜性。 但是配置開源集群軟件可能很費時費力，而且容易出現人為錯誤。

SIOS 擁有為關鍵應用程序提供高可用性和災難恢復的解決方案。 這些解決方案是根據我們在不同行業和用例中的實際經驗開發的。 我們的產品包括適用於 Windows 的 SIOS DataKeeper 集群版和適用於 Linux 的 SIOS LifeKeeper或窗戶。 這些強大的應用程序提供故障轉移保護。 LifeKeeper 隨附的應用程序恢復工具包通過自動配置和驗證輸入來加快應用程序配置時間。

本地、雲端或混合環境中的系統保護

SIOS 為關鍵業務應用程序提供所需的保護，並降低管理它們的複雜性，無論是在本地、雲中還是在混合雲環境中。 在下面的視頻中了解更多關於我們的信息或聯繫我們了解有關業務關鍵應用程序的高可用性和災難恢復的更多信息。

經授權轉載西歐