保護部署在 Azure Stack Hub 上的 VM

  • 發行項

以本文為指南，協助您針對在 Azure Stack Hub 上的使用者部署 IaaS 虛擬機器 (VM) 開發資料保護和災害復原策略。

為了因應資料遺失或長時間停機的狀況，請為使用者應用程式或其資料實作備份復原或災害復原計劃。 必須評估每個應用程式，這是組織完整商務持續性和災害復原 (BC/DR) 策略的一部分。

保護 IaaS VM 的考量

角色和職責

首先，請確定已清楚瞭解在保護和復原內容中，對應用程式擁有者和操作員的角色和責任。

使用者負責保護 VM。 操作員負責保持 Azure Stack Hub 上線和狀況良好。 Azure Stack Hub 有可以從基礎結構服務備份內部服務資料的服務，但「不包含」 任何使用者資料，包括使用者建立的 VM、具有使用者或應用程式資料的儲存體帳戶、或使用者資料庫。

應用程式擁有者/架構設計人員 Azure Stack Hub 操作員
- 讓應用程式架構與雲端設計原則保持一致。
- 視需要將傳統應用程式現代化，以針對雲端環境做好準備。
- 定義應用程式的可接受的 RTO 和 RPO。
- 識別需要保護的應用程式資源和資料存放庫。
- 實作最符合應用程式架構和客戶需求的資料和應用程式復原方法。		 - 識別組織的商務持續性和災害復原目標。
- 部署足夠的 Azure Stack Hub 實例，以符合組織的 BC/DR 目標。
- 設計和操作應用程式/資料保護基礎結構。
- 提供受控解決方案或自助存取保護服務。
- 請與應用程式擁有者/架構設計人員合作，以瞭解應用程式設計和建議保護原則。
- 啟用服務修復和雲端復原的基礎結構備份。

來源/目標組合

需要防止資料中心或網站中斷的使用者，可以使用另一個 Azure Stack Hub 或 Azure 來提供高可用性或快速復原。 透過主要和次要位置，使用者可以跨兩個環境，部署主動/主動或主動/被動設定的應用程式。 對於較不重要的工作負載，使用者可以使用次要位置的容量，從備份執行應用程式的隨選還原。

可將一或多個 Azure Stack Hub 雲端部署至一個資料中心。 為了承受嚴重損壞情形，請在不同的資料中心部署至少一個 Azure Stack Hub 雲端，確保您可以容錯移轉工作負載，並將非計劃的停機時間最小化。 如果您只有一個 Azure Stack Hub，應該考慮使用 Azure 公用雲端作為復原雲端。 關於您的應用程式可在何處執行的決定，將取決於政府法規、公司原則、以及嚴格的延遲需求。 您可以彈性地決定每個應用程式的適當復原位置。 例如，您可以將一個訂用帳戶中的應用程式資料備份到另一個資料中心另一個訂用帳戶，將資料複寫至 Azure 公用雲端。

應用程式復原目標

應用程式擁有者主要負責判斷應用程式，和組織可容忍的停機時間和資料遺失。 將可接受的停機時間和資料遺失量化，您可以建立復原計劃，將對組織造成嚴重損壞的影響降到最低。 每個應用程式皆要考量下列要素：

  • 復原時間目標 (RTO)
    RTO 是應用程式在事件發生之後可能無法使用的最大可接受時間。 例如，RTO 為 90 分鐘表示必須能夠在災害開始的 90 分鐘內，將應用程式還原為執行狀態。 如果您的 RTO 偏低，就可以讓第二個部署持續以待命狀態執行，從而防止區域性中斷。
  • 復原點目標 (RPO)
    RPO 是在災害期間可接受的最大資料遺失時間長度。 例如，如果您在每小時會進行備份的單一資料庫中儲存資料，而且沒有覆寫至其他資料庫，您可能會遺失最多一個小時的資料。

另一個計量是平均復原時間 (MTTR)，這是在失敗後還原應用程式所花費的平均時間。 MTTR 是系統的經驗值。 如果 MTTR 超過 RTO，系統失敗將導致無法接受的商務中斷，因為將無法在定義的 RTO 內還原系統。

保護選項

備份 - 還原

備份您的應用程式和資料集，可讓您快速地從因資料損毀、意外刪除或發生災難導致的停機時間復原。 針對 IaaS VM 型應用程式，您可以使用客體內代理程式，來保護應用程式資料、作業系統設定，以及儲存在磁碟區上的資料。

使用客體內代理程式進行備份

使用客體 OS 代理程式備份 VM，通常要擷取作業系統設定、檔案/資料夾、磁碟、應用程式二進位檔或應用程式資料。

從代理程式復原應用程式需要手動重新建立 VM、安裝作業系統、安裝客體代理程式。 此時，資料可以還原到客體作業系統或直接還原到應用程式中。

使用磁碟快照為已停止的 VM 備份

備份產品可以保護 IaaS VM 設定和連接至已停止 VM 的磁碟。 使用與 Azure Stack Hub API 整合的備份產品擷取 VM 設定並建立磁碟快照集。 如果可以規劃應用程式的停機時間，請確定 VM 處於已停止狀態，然後再啟動備份工作流程。

使用磁碟快照集為執行中的 VM 備份

重要

目前不支援從入口網站使用磁片快照集，VM 處於執行中狀態。 為連接至執行中 VM 的磁碟建立快照，可能會降低效能，或影響 VM 中作業系統或應用程式的可用性。 建議使用與儲存體 RP 累加快照集功能整合的備份廠商解決方案，或客體內代理程式，如果計劃性停機時間不是選項，則保護應用程式。

擴展集或可用性設定組中的 VM

擴展集或可用性群組中的 VM 被視為暫時資源，不應在 VM 層級備份，特別是當應用程式為無狀態時。 針對在擴展集或可用性設定組中具狀態的已部署應用程式，請考慮保護該應用程式的資料 (例如存放集區中的資料庫或磁碟區)。

複寫/手動容錯移轉

對於需要最少資料遺失或最少停機時間的應用程式，可以在客體 OS 或應用程式層級啟用資料複寫，以將資料複寫到另一個位置。 某些應用程式 (例如 Microsoft SQL Server) 原本就支援複寫。 如果應用程式不支援複寫，您可以在客體 OS 中使用軟體來複寫磁碟，或在客體 OS 中將合作夥伴解決方案安裝為代理程式。

運用這個方法，應用程式會部署在某個雲端，而資料則會複寫到另一個內部部署雲端或複寫到 Azure。 當容錯移轉觸發時，必須先啟動目標中的應用程式，並將其附加至複寫的資料，應用程式才能開始處理要求。

高可用性/自動容錯移轉

如果無狀態應用程式只能容許幾秒或幾分鐘的停機時間，請考慮高可用性的設定。 高可用性應用程式的設計目的，是要在主動/主動拓撲中的多個位置部署 - 這種拓樸中的所有執行個體都可以服務要求。 發生本機硬體故障時，Azure Stack Hub 基礎結構會使用兩個機架頂端的交換器，在實體網路中實作高可用性。 針對計算層級的錯誤，Azure Stack Hub 會在縮放單位中使用多個節點，並自動容錯移轉 VM。 在 VM 層級中，您可以使用擴展集或可用性設定組中的 VM，以確保節點失敗不會關閉您的應用程式。 相同應用程式必須部署到相同設定中的次要位置。 若要讓應用程式變成主動/主動，可以使用負載平衡器或 DNS，將要求導向所有可用的執行個體。

沒有復原功能

在您的環境中，某些應用程式可能不需要對意外的停機或資料遺失有所防護。 例如，用於開發和測試的 VM 通常不需要進行復原。 您可以決定不對應用程式或資料集進行保護。

Azure Stack Hub 部署的重要考量：

建議 註解
將 VM 備份/還原至已部署在您資料中心的外部備份目標 建議 充分利用現有備份基礎結構和操作技術。 務必調整備份基礎結構的大小，讓其可以保護額外的 VM 執行個體。 請確定備份基礎結構不是非常接近您的來源。 您可以將 VM 還原至來源 Azure Stack Hub、次要 Azure Stack Hub 執行個體或 Azure。
將 VM 備份/還原至 Azure Stack Hub 專用的外部備份目標 建議 您可以購買新的備份基礎結構，或佈建 Azure Stack Hub 專用的備份基礎結構。 請確定備份基礎結構不是非常接近您的來源。 您可以將 VM 還原至來源 Azure Stack Hub、次要 Azure Stack Hub 執行個體或 Azure。
直接將 VM 備份/還原至全域 Azure 或受信任的服務提供者 建議 只要能符合您的資料隱私權和法規要求，您可以將備份儲存在全域 Azure 或受信任的服務提供者中。 最理想的情況是服務提供者也執行 Azure Stack Hub，如此，你在還原時就會有一致的操作體驗。
將 VM 複寫/容錯移轉至個別的 Azure Stack Hub 執行個體 建議 在容錯移轉的案例中，您必須有第二個可完全正常運作的 Azure Stack Hub 雲端，以避免應用程式停機時間拖長。
直接將 VM 複寫/容錯移轉至 Azure 或受信任的服務提供者 建議 只要能符合您的資料隱私權和法規要求，您可以將資料複寫至全域 Azure 或受信任的服務提供者中。 最理想的情況是服務提供者也執行 Azure Stack Hub，如此，你在容錯移轉後就會有一致的操作體驗。
將備份目標部署在相同 Azure Stack Hub 上，而且此 Azure Stack Hub 也裝載同一備份目標所保護的所有應用程式。 獨立目標：不建議
在外部複寫備份資料的目標：建議		 如果您選擇在 Azure Stack Hub 上部署設備 (為了作業還原最佳化的目的)，您必須確定所有資料會持續複製到外部的備份位置。
將實體備份設備部署至安裝 Azure Stack Hub 解決方案的相同機架中 不支援 目前，您無法將任何其他裝置連線到機架頂端的交換器，這不屬於原始方案的一部份。

還原的 IaaS VM 考量

從備份還原機器之後，您將需要變更 VM 的部分內容。 其中包含：

  • MAC 位址
    虛擬網路介面卡將會取得新的 MAC 位址。 沒有可保留原始 MAC 位址的方法。
  • IP 位址
    如果您的 VM 在內部設定靜態 IP，則可以將虛擬網路介面卡上的內部 IP 設定為與原始 IP 相符。 您可能需要考慮 VNET 是否具有可連線到外部環境的 S2S VPN，該外部環境可能正在使用 IP 位址。
  • 不需要的成品
    如果 VM 是在不同的平臺（例如 VMware vSphere）進行備份，您將需要遵循一些額外的步驟，來清除來源中不需要的成品。

後續步驟

本文提供一般指引，說明如何保護部署在 Azure Stack Hub 上的使用者 VM。 如需使用 Azure 服務來保護使用者 VM 的相關資訊，請參閱：