保護部署在 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 是應用程式在事件發生后無法使用的最大可接受時間。 例如，90 分鐘的 RTO 表示您必須能夠在災害開始 90 分鐘內將應用程式還原為執行中狀態。 如果您的 RTO 很低，您可能會讓第二個部署持續處於待命狀態，以防止區域性中斷。 -
恢復點目標 （RPO）
RPO 是災害期間可接受的數據遺失持續時間上限。 例如，如果您在單一資料庫中儲存數據，該資料庫會每小時備份，而且沒有其他資料庫的複寫，則最多可能會遺失一小時的數據。
另一個計量是 平均復原時間 （MTTR），這是在失敗后還原應用程式的平均時間。 MTTR 是系統的經驗值。 如果 MTTR 超過 RTO，則系統中的失敗會導致無法接受的業務中斷，因為無法還原所定義 RTO 內的系統。
保護選項
備份還原
為您的應用程式和數據集進行備份，能夠讓您快速從因數據損毀、意外刪除或災害引起的停機中復原。 針對基於 IaaS VM 的應用程式，您可以使用虛擬機內代理程式來保護應用程式資料、作業系統設定，以及儲存在磁碟區上的資料。
使用客體代理程序進行備份
使用客體 OS 代理程式備份虛擬機通常包括抓取作業系統組態、檔案/資料夾、磁碟、應用程式二進位檔或應用程式資料。
要從代理程式復原應用程式，需要手動重新建立虛擬機器，然後安裝作業系統，再安裝客體代理程式。 此時，數據可以還原至客體OS或直接還原至應用程式。
使用已停止 VM 的磁碟快照集進行備份
備份產品可以保護連結至已停止 VM 的 IaaS VM 設定和磁碟。 使用與 Azure Stack Hub API 整合的備份產品來擷取 VM 組態並建立磁碟快照集。 如果應用程式的計劃停機可能，請確定 VM 處於停止狀態，再啟動備份工作流程。
使用磁碟快照來備份正在執行的虛擬機器
重要
目前不支援透過入口網站使用磁碟快照集，當虛擬機器處於執行中的狀態。 建立連結至執行中 VM 的磁碟快照集可能會降低效能，或影響 VM 中作系統或應用程式的可用性。 如果計劃性停機不是選項，建議使用與儲存體 RP 增量快照功能整合的備份廠商解決方案，或使用客體中代理程式來保護應用程式。
擴展集或可用性設定組中的 VM
擴展集或可用性群組中被視為暫存資源的 VM 不應在 VM 層級進行備份，特別是當應用程式是無狀態時。 針對部署在擴展集或可用性設定組中的具狀態應用程式，請考慮保護應用程式資料（例如存放集區中的資料庫或磁碟區）。
複製/手動故障切換
對於需要最少數據遺失或最短停機時間的應用程式，可以在客體OS或應用層級啟用數據複寫，以將數據復寫到另一個位置。 某些應用程式，例如Microsoft SQL Server，原生支持複寫。 如果應用程式不支援複製，您可以使用客體作業系統中的軟體來複製磁碟，或者使用安裝在客體作業系統中作為代理程式的合作夥伴解決方案。
透過這種方法，應用程式會部署在一個雲端中，並將數據復寫至另一個雲端內部部署或 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 解決方案的相同機架 | 不支援 | 目前，您無法將任何其他裝置連線到不屬於原始解決方案的機架交換器頂端。 |
還原後 IaaS VM 的注意事項
從備份還原機器之後，您必須對 VM 進行一些變更。 這些包括：
-
MAC 位址
虛擬網路配接器將會取得新的 MAC 位址。 沒有方法來保留原始 MAC 位址。 -
IP 位址
如果您的 VM 在內部設定靜態 IP，虛擬網路適配器上的內部 IP 可以設定為符合原始的 IP。 您可能需要考慮 VNET 是否有 S2S VPN 到可能正在使用 IP 位址的外部環境。 -
不需要的人工製品
如果 VM 已備份在不同的平台上，例如 VMware vSphere，您必須執行一些額外的步驟，從原始來源清除任何不需要的人工產物。
後續步驟
本文提供保護部署在 Azure Stack Hub 上的使用者 VM 的一般指導方針。 如需使用 Azure 服務保護使用者 VM 的相關信息，請參閱：