保護部署在 Azure Stack Hub 模組化資料中心 (MDC) 的 VmProtect VMs deployed on Azure Stack Hub - Modular Data Center (MDC)

請使用本文作為指南,以開發可保護您的使用者在 Azure Stack Hub 上部署之虛擬機器 (Vm) 的計畫。Use this article as a guide to develop a plan for protecting virtual machines (VMs) that your users deploy on Azure Stack Hub.

為了防止資料遺失和未規劃的停機時間,請在 Azure Stack Hub 上為 VM 型應用程式執行資料保護和嚴重損壞修復計畫。To protect against data loss and unplanned downtime, implement a data protection and disaster recovery plan for VM-based applications on Azure Stack Hub. 所實行的保護方案將取決於商務需求和應用程式的設計。The protection plan implemented will depend on business requirements and design of the application. 此計畫應遵循您組織的全方位商務持續性和嚴重損壞修復所建立的架構, (BC/DR) 策略。This plan should follow the framework established by your organization's comprehensive business continuity and disaster recovery (BC/DR) strategy. 如需 Azure Stack Hub 的 BC/DR 考慮概要說明,請參閱 Azure Stack:商務持續性和嚴重損壞修復的考慮。For a high level overview of the BC/DR considerations for Azure Stack Hub, see Azure Stack: Considerations for business continuity and disaster recovery.

應用程式復原目標Application recovery objectives

判斷您的組織可容忍每個應用程式的停機時間和資料遺失量。Determine the amount of downtime and data loss your organization can tolerate for each application. 將停機時間和資料遺失量化,您可以建立復原計劃,將對組織造成嚴重損壞的影響降到最低。By quantifying downtime and data loss, you can create a recovery plan that minimizes the impact of a disaster on your organization. 針對每個應用程式,請考量:For each application, consider:

  • 復原時間目標 (RTO)Recovery time objective (RTO)
    RTO 是應用程式在事件發生之後可能無法使用的最大可接受時間。RTO is the maximum acceptable time that an app can be unavailable after an incident. 例如,RTO 為 90 分鐘表示必須能夠在災害開始的 90 分鐘內,將應用程式還原為執行狀態。For example, an RTO of 90 minutes means that you must be able to restore the app to a running state within 90 minutes from the start of a disaster. 如果您的 RTO 偏低,就可以讓第二個部署持續以待命狀態執行,從而防止區域性中斷。If you have a low RTO, you might keep a second deployment continually running on standby to protect against a regional outage.

  • 復原點目標 (RPO)Recovery point objective (RPO)
    RPO 是在災害期間可接受的最大資料遺失時間長度。RPO is the maximum duration of data loss that is acceptable during a disaster. 例如,如果您在每小時執行備份的單一資料庫中儲存資料,而且沒有複寫到其他資料庫,您可能會遺失最多一個小時的資料。For example, if you store data in a single database which is backed up hourly and has no replication to other databases, you could lose up to an hour of data.

進行評量來定義每個應用程式的 RTO 和 RPO。Conduct an assessment to define the RTO and RPO for each application.

另一個要考慮的重要度量是復原 (MTTR) 的平均 時間 ,也就是在失敗後還原應用程式所需的平均時間。Another important metric to consider is Mean Time to Recover (MTTR), which is the average time that it takes to restore the application after a failure. MTTR 是系統的經驗值。MTTR is an empirical value for a system. 如果 MTTR 超過 RTO,系統失敗就會導致無法接受的商務中斷,因為將無法在定義的 RTO 內還原系統。If MTTR exceeds the RTO, then a failure in the system will cause an unacceptable business disruption because it won't be possible to restore the system within the defined RTO.

IaaS Vm 的保護選項Protection options for IaaS VMs

備份 - 還原Backup-restore

虛擬機器型應用程式上最常見的保護配置就是使用備份軟體。The most common protection scheme for VM-based apps is to use backup software. 備份 VM 通常包含作業系統、作業系統設定、應用程式二進位檔,以及包含在 VM 內的持續性應用程式資料。Backing up a VM typically includes the operating system, operating system configuration, application binaries, and persistent application data contained inside the VM. 備份是使用來賓 OS 中的代理程式來建立,以抓取應用程式、OS 或檔案系統/磁片區。The backups are created by using an agent in the guest OS to capture application, OS, or file system/volumes. 另一種方法是透過依賴與 Azure Stack Hub Api 的整合,來讀取 VM 設定的相關資訊,並將連接至 VM 的磁片快照集。Another approach is agent-less by relying on integration with Azure Stack Hub APIs to read information about the VM configuration and snapshot the disks attached to the VM. 請注意,Azure Stack Hub 不支援直接從虛擬程式進行備份。Please note that Azure Stack Hub does not support backing up directly from the hypervisor.

規劃您的備份策略Planning your backup strategy

從量化需要保護的 VM 執行個體數目開始,規劃您的備份策略及定義規模需求。Planning your backup strategy and defining scale requirements starts with quantifying the number of VM instances that need to be protected. 備份系統中的所有 Vm,可能不是保護應用程式最有效的方式。Backing up all VMs in the system may not be the most effective way to protect application. 使用 Azure Stack Hub 時,不應在 VM 層級備份擴展集或可用性設定組中的 Vm。With Azure Stack Hub, VMs in a scale-set or availability set should not be backed up at the VM level. 這些 Vm 會被視為暫時的,因為 Vm 集合可以相應縮小或相應放大。在理想的情況下,需要保存的任何資料都在不同的儲存機制中,例如資料庫或物件存放區。These VMs are considered ephemeral since the set of VMs can be scaled-in or out. Ideally any data that needs to be persisted is in a separate repository such as a database or object store. 如果部署在向外延展架構中的應用程式包含必須保存且受保護的資料,則需要使用應用程式所提供的原生功能或依賴代理程式來進行應用層級備份。If the applications deployed in a scale-out architecture contains data that must be persisted and protected, then that will require application level backup using native capabilities provided by the application or by relying on an agent.

在 Azure Stack 上備份 VM 的重要考量:Important considerations for backing up VMs on Azure Stack:

  • 分類Categorization
    • 考慮使用者加入宣告 VM 備份的模型。Consider a model where users opt into VM backup.
    • 根據應用程式優先順序或業務上受到的影響,來定義復原服務等級協定 (SLA)。Define a recovery service level agreement (SLA) based on the priority of the applications or the impact to the business.
  • 縮放Scale
    • 如果有大量新的 VM 正在上架時,請考慮交錯進行備份 (如果有備份需要)。Consider staggered backups when on-boarding a large number of new VMs (if backup is required).
    • 評估可有效率地擷取並傳輸備份資料的備份產品,以盡可能減少解決方案上的資源內容。Evaluate backup products that can efficiently capture and transmit backup data to minimize resource content on the solution.
    • 評估可有效率地使用增量或差異備份來儲存備份資料的備份產品,以盡可能減少完整備份環境中所有 VM 的需求。Evaluate backup products that efficiently store backup data using incremental or differential backups to minimize the need for full backups across all VMs in the environment.
  • 還原Restore
    • 備份產品可還原虛擬磁碟、現有 VM 中的應用程式資料,或整個 VM 資源及相關聯的虛擬磁碟。Backup products can restore virtual disks, app data within an existing VM, or the entire VM resource and associated virtual disks. 您需要的還原配置取決於您打算如何還原應用程式。The restore scheme you need depends on how you plan to restore the app. 例如,您可以較輕鬆地從範本重新部署 SQL 伺服器,然後再還原資料庫,而不是還原整個 VM 或一組 VM。For example, it may be easier to redeploy SQL server from a template and then restore the databases instead of restoring the entire VM or set of VMs.

複寫/手動容錯移轉Replication/manual failover

支援復原的替代方法是將資料複寫至另一個環境。An alternate approach to supporting recovery is to replicate data to another environment. 您可以使用代理程式將資料的範圍設定為應用程式,例如資料庫複寫或虛擬作業系統中的作業系統,或與 Azure Stack Hub Api 整合,以在 VM 層級進行。The data can be scoped to the application like database replication or to the operating system in the guest OS using an agent, or at the VM level by integrating with Azure Stack Hub APIs. 如果發生嚴重損壞狀況,則需要容錯移轉至次要位置。In the event of a disaster, failover to the secondary location is required. 您可以透過使用代理程式或叢集技術的應用程式,或在 VM 層級使用保護產品,以原生方式處理容錯移轉。The failover can be handled natively by the application like with SQL Availability Groups or at the guest OS level using agents or cluster technology, or at the VM level using a protection product.

高可用性/自動容錯移轉High availability/automatic failover

原生支援高可用性或依賴叢集軟體的應用程式,可以在一個 Azure Stack Hub 或跨多個 Azure Stack Hub 實例的一組 Vm 上部署。Applications that natively support high availability or rely on cluster software to achieve high availability across nodes can be deployed across a group of VMs in one Azure Stack Hub or across multiple Azure Stack Hub instances. 在所有情況下,一定要有某種程度的負載平衡,以確保應用程式流量正確地路由傳送。In all cases, some level of load balancing is required to ensure application traffic is routed correctly. 在此設定中,應用程式可以從錯誤中自動復原。In this configuration, the application can automatically recover from faults. 針對本機硬體錯誤,Azure Stack Hub 基礎結構會在實體基礎結構中實行高可用性和容錯功能。For local hardware faults, Azure Stack Hub infrastructure implements high availability and fault tolerance in the physical infrastructure. 針對計算層級錯誤,Azure Stack Hub 會在多個設定中使用縮放單位中的多個節點。For compute level faults, Azure Stack Hub uses multiple nodes in a scale unit in an N-1 configuration. 在 VM 層級中,可用性和擴展集會將縮放單位中的每個節點模型為容錯網域,以確保節點層級的反親和性,讓節點失敗不會關閉分散式應用程式。At the VM level, availability and scale sets model each node in the scale-unit as a fault domain to guarantee node-level anti-affinity so node failures do not take down a distributed application.

無保護No protection

有些應用程式可能沒有需要保存的資料。Some applications may not have data that needs to be persisted. 例如,用於開發和測試的 Vm 通常 ' 不需要復原。For example, VMs used for development and testing typically don't need to be recovered. 另一個範例是無狀態應用程式,可在發生失敗時,從 CI/CD 管線重新部署。Another example is a stateless application that can be re-deployed from a CI/CD pipeline in the event of a failure. 請務必找出不需要保護的應用程式,以避免不必要的保護 Vm。It is important to identify the applications that do not require protection to avoid unnecessarily protecting VMs.

後續步驟Next steps

本文提供一般指引,說明如何保護部署在 Azure Stack 上的使用者 VM。This article provided general guidelines for protecting user VMs deployed on Azure Stack. 如需有關如何使用 Azure 服務保護使用者 VM 的詳細資訊,請參閱:For information about using Azure services to protect user VMs, refer to:

合作夥伴產品Partner products