共用方式為

使用 Azure Site Recovery 的容量規劃

  • 發行項

身為組織，請務必採用商務持續性和災害復原 (BCDR) 策略，以在計劃性和非計劃性中斷期間讓數據保持安全、應用程式可用，以及工作負載上線。

透過將虛擬機複寫 (VM) 主要月臺到次要位置的工作負載，Azure Stack Hub 上的 Azure Site Recovery 提供可在中斷期間支援組織數據、應用程式可用性和工作負載安全性的服務。 例如，當您的主要月台發生中斷時，您會故障轉移至次要位置以存取您的應用程式。 只要主要月臺再次執行，您就可以容錯回復。 如需詳細資訊，請參閱關於 Site Recovery。

若要啟用跨兩個 Azure Stack Hub 戳記的 VM 複寫，您可以設定兩個環境：

  • 來源 環境：
    • 租使用者 VM 執行所在的 Azure Stack Hub 戳記。
  • 目標 環境：
    • Azure Site Recovery 資源提供者執行的位置。

跨兩個 Azure Stack Hub 戳記復寫 VM 的快照集。

業務持續性和災害復原計劃成功的重要元件是容量規劃。 在容量規劃期間，需要考慮幾個因素：

  • 復原時間目標 (RTO) 和恢復點目標 (RPO) 您想要保護的特定工作負載。

  • 工作負載和應用程式特性：

    • 個別 VM 內的數據變更頻率。
    • 產生或移除多少數據？
    • 應用程式設計的外觀等等？

  • VM 大小、磁碟數目，以及每個 VM 如何系結至其他 VM。

    • 針對需要數部 VM 的解決方案，請瞭解這些 VM 需要啟動的順序。

  • 來源與目標環境之間的網路頻寬。 此元件可能會影響 RPO。

這其中每一點都很重要，而且在建置 BCDR 計劃時具有廣泛的影響。

下列各節列出從 Azure Site Recovery 觀點考慮的主要重點。 每個BCDR方案都不同，而且是以您計劃保護的工作負載細節為基礎。 因此，這份清單並不完整。

來源考慮

在來源環境中，Azure Stack Hub 會執行 Azure Site Recovery VM 設備。 VM 是 Standard_DS4_v2 (8 個 vCPU、28 Gb 記憶體、32 個數據磁碟，) 在 Azure Stack Hub 使用者訂用帳戶中執行的 VM。

在來源環境中，請考慮下列區域：

  • 配額：

    • 您應該有足夠的配額來建立 Azure Site Recovery VM 設備。 您需要一或多個，視整體計劃而定。

  • Azure Site Recovery VM 設備的記憶體：

    • Azure Site Recovery VM 裝置本身具有 VM 大小所定義的數據需求。

    • 規劃容量時，請確定設備 VM 有足夠的記憶體來練習容錯回復和重新保護機制。

      注意

      如果有記憶體限制，容錯回復和重新保護可能會失敗，並 出現錯誤 發生內部錯誤 訊息。 使用者應該檢查設備的事件記錄檔，以確認實際的 Azure Resource Manager 錯誤。 如需詳細資訊，請參閱 Azure Site Recovery 的已知問題。

  • 頻寬：

    • 初始複寫會產生高頻寬使用量。
    • 根據復寫原則和每種應用程式類型而定，會復寫每個 VM 上的變更。

目標考慮

在目標環境中，有兩個考慮進行容量規劃：

  • Azure Site Recovery 服務需求：耗用多少來執行 Azure Site Recovery，而不需要保護任何工作負載。

  • 受保護的工作負載需求。

目標環境需要為每個 Site Recovery 設備建立一個 Azure Site Recovery 保存庫，以保護 VM 免於每個保存庫 (每個保存庫一個設備) 。 雖然這不是容量觀點的限制，但在規劃整體環境的設計時，應該將它納入考慮。

Azure Site Recovery RP 資源

在 Azure Stack Hub 上安裝 Azure Site Recovery 時，您必須安裝 Site Recovery 資源提供者 (RP) 。

注意

透過 Microsoft.SiteRecovery-1.2301.2216.2287，Azure Stack Hub 上的 Azure Site Recovery 不需要事件中樞作為相依性。

在 Azure Stack Hub 上安裝 Azure Site Recovery 之三項服務的螢幕快照。

此服務是在 Azure Stack Hub 管理員訂用帳戶上建立，並由 Azure Stack Hub 本身管理，因此不需要設定。 不過，如同任何服務，這些資源會耗用記憶體、記憶體，並配置特定的 vCPU：

服務 vCore 記憶體 磁碟大小
Azure Site Recovery 12 42 GB 1.4 TB

注意

這些資源是 Azure Stack Hub 管理端的 Azure Stack Hub 服務。 安裝之後，平臺會管理這些資源。

受保護的工作負載

建立BCDR方案時，請考慮受保護工作負載的所有層面。 下列清單不完整，而且應該視為起點：

  • VM 大小、磁碟大小、IOPS、數據變換，以及建立的新數據。

  • 網路頻寬考慮：

    • 差異複寫所需的網路頻寬。
    • Azure Site Recovery 可從來源環境取得的目標環境輸送量。
    • 一次要批處理的 VM 數目。 此數目是以預估的頻寬為基礎，以在特定時間內完成初始復寫。
    • 可針對指定頻寬達成的 RPO。
    • 布建較低的頻寬時，對所需 RPO 的影響。

  • 記憶體考慮：

    • 初始複寫需要多少數據。
    • 在這些間隔期間，保留多少恢復點，以及每個受保護 VM 的數據增加方式。
    • 必須將多少配額指派給目標 Azure Stack Hub 使用者訂用帳戶，讓使用者有足夠的配置。
    • 用於復寫的快取記憶體帳戶。

  • 計算考慮：

    • 發生故障轉移時，VM 會在目標 Azure Stack Hub 使用者訂用帳戶上啟動。 必須有足夠的配額配置，才能啟動這些 VM 資源。
    • 在 VM 的保護期間，當受保護的 VM 在來源環境中處於作用中狀態時，目標環境不會取用任何 VM 相關資源，例如 vCPU、記憶體等。 這些資源只會在故障轉移程式期間變得相關，例如測試故障轉移。

針對 Azure Stack Hub 上的 Azure Site Recovery 範圍，以下是計算的起點，特別是針對使用的快取記憶體帳戶：

  1. 如果有故障轉移，在正常作業期間，請將復寫的磁碟數目乘以平均 RPO。 例如，您可能 (2MB * 250s) 。 快取記憶體帳戶通常每個磁碟的 KB 到 500 MB。

  2. 如果有故障轉移，假設最糟的情況，請將復寫的磁碟數目乘以一天的平均 RPO。

    重要

    如果 Azure Site Recovery 的某些部分無法運作，但有些部分正在運作，在 Azure Site Recovery 決定逾時之前，記憶體帳戶中最多可以有一天的差異。

  3. 容錯回復至新的 VM。 計算每個批次的磁碟大小總和。

    • 整個磁碟必須複製到要套用的目標 VM 的快取記憶體帳戶，因為目標是空的磁碟。
    • 複製之後，就會刪除相關聯的數據，但可能會看到具有所有磁碟大小總和的尖峰使用量。

根據您嘗試保護的解決方案細節建立 BDCR 方案。

下表是測試在我們的環境中執行的範例。 您可以使用此深入解析來取得您自己的應用程式的基準，但每個工作負載都不同：

設定

區塊大小 輸送量/磁碟
2 MB 2 MB/秒
64 KB 2 MB/秒
8 KB 1 MB/秒
8 KB 2 MB/秒

結果

支援的磁碟數目 輸送量總計 總 OPS Bottleneck
68 136 MB/秒 68 儲存
60 120 MB/秒 2048 儲存
28 28 MB/秒 3584 Azure Site Recovery CPU 和記憶體
16 32 MB/秒 4096

注意

8Kb 是 Azure Site Recovery 支援的數據最小區塊大小。 小於 8Kb 的任何變更都會被視為 8Kb。

為了進一步測試，我們產生了一致的工作負載類型;例如，每個磁碟最多 1 MB/秒之區塊中 8 Kb 的一致記憶體變更。 此案例不太可能在實際工作負載中，因為變更可能會發生在一天的各種時間，或各種大小的尖峰。

為了復寫這些隨機模式，我們也測試了下列案例：

  • 120 部 VM (80 個 Windows、40 Linux) 透過相同的 Azure Site Recovery VM 設備保護。

    • 每個 VM 都會以隨機間隔產生，每小時至少產生兩次，隨機區塊總計五個檔案的 5 Gb 數據。

    • 在 Azure Site Recovery 服務上，複寫在所有 120 部 VM 上都成功，且負載低到中。

      注意

      這些數字應該只當做基準使用。 它們不一定會以線性方式調整。 新增相同數目 VM 的另一個批次，可能會比初始 VM 的影響少。 結果高度相依於使用的工作負載類型。

您應該如何規劃和測試

應用程式和解決方案工作負載具有特定復原時間目標， (RTO) 和恢復點目標 (RPO) 需求。 有效的商務持續性和災害復原 (BCDR) 設計會利用符合這些需求的平臺層級功能，因為我們使用解決方案特定的機制。 若要設計 BCDR 功能，請擷取平臺災害復原 (DR) 需求，並在您的設計中考慮所有這些因素：

  • 應用程式和資料可用性需求：

    • 每個工作負載的 RTO 和 RPO 需求。
    • 支援主動-主動和主動-被動可用性模式。

  • 支援多區域部署以進行容錯移轉，並對效能具有元件鄰近性。 您可能會在中斷期間遇到功能降低或效能降低的應用程式作業。

    注意

    應用程式可能知道原生執行方式，或有特定元件能夠跨多個 Azure Stack Hub 環境執行。 在此情況下，您可以使用 Azure Site Recovery，只復寫具有沒有此功能之元件的 VM;例如，前端或後端類型解決方案，您可以在其中跨 Azure Stack Hub 環境部署前端。

  • 避免在生產和DR網路中使用重疊的IP位址範圍。

    • 具有重疊 IP 位址的生產與DR網路需要故障轉移程式，才能使應用程式故障轉移複雜並延遲。 可能的話，請規劃可提供並行連線所有網站的 BCDR 網路結構。

  • 調整目標環境的大小：

    • 如果您是以 1：1 的方式使用來源和目標，請在目標環境中配置稍微更多的記憶體。 這是因為磁碟書籤的歷程記錄發生方式。 此配置不是增加 2 倍，因為它只會包含資料的變更。 根據數據類型和預期的變更，以及目標上具有 1.5 倍到 2 倍以上的記憶體的復寫原則，可確保故障轉移程式不會造成任何疑慮。
    • 您可以將目標 Azure Stack Hub 環境視為多個 Azure Stack Hub 來源的目標。 在此情況下，您會降低整體成本，但必須規劃特定工作負載關閉時會發生什麼情況;例如，哪些來源必須排定優先順序。
    • 如果您的目標環境用於執行其他工作負載，BCDR 方案必須包含這些工作負載的行為。 例如，您可以在目標環境上執行開發/測試 VM，如果來源環境發生問題，您可以關閉目標上的所有 VM，以確保有足夠的資源可供啟動受保護的 VM。

您應該測試BCDR並定期驗證。 您可以使用測試故障轉移程式，或移動整個工作負載來驗證流程的端對端來執行此動作。

下一步

Azure Stack Hub 上的 Azure Site Recovery