Ochrana virtuálních počítačů nasazených v Azure Stackm centru – robustníProtect VMs deployed on Azure Stack Hub - Ruggedized

Tento článek slouží jako vodítko pro vývoj plánu ochrany virtuálních počítačů, které uživatelé nasazují v Azure Stack hub.Use this article as a guide to develop a plan for protecting virtual machines (VMs) that your users deploy on Azure Stack Hub.

Pro zajištění ochrany před únikem informací a neplánovanými výpadky implementujte plán ochrany dat a zotavení po havárii pro aplikace založené na virtuálních počítačích v centru Azure Stack.To protect against data loss and unplanned downtime, implement a data protection and disaster recovery plan for VM-based applications on Azure Stack Hub. Implementovaný plán ochrany bude záviset na požadavcích firmy a návrhu aplikace.The protection plan implemented will depend on business requirements and design of the application. Tento plán by měl postupovat podle rozhraní, které vaše organizace zavedla v ' komplexní strategii pro provozní kontinuitu a zotavení po havárii (BC/Dr).This plan should follow the framework established by your organization's comprehensive business continuity and disaster recovery (BC/DR) strategy. Základní informace o požadavcích BC/DR pro centrum Azure Stack najdete v článku Azure Stack: požadavky na provozní kontinuitu a zotavení po havárii.For a high level overview of the BC/DR considerations for Azure Stack Hub, see Azure Stack: Considerations for business continuity and disaster recovery.

Cíle obnovení aplikaceApplication recovery objectives

Určete množství výpadku a ztráty dat, které vaše organizace může tolerovat pro každou aplikaci.Determine the amount of downtime and data loss your organization can tolerate for each application. Díky kvantitativnímu výpadku a ztrátě dat můžete vytvořit plán obnovení, který minimalizuje dopad havárie ve vaší organizaci.By quantifying downtime and data loss, you can create a recovery plan that minimizes the impact of a disaster on your organization. Pro každou aplikaci zvažte následující:For each application, consider:

  • Cíl doby obnovení (RTO)Recovery time objective (RTO)
    RTO je maximální přijatelná doba, po kterou může být aplikace po incidentu nedostupná.RTO is the maximum acceptable time that an app can be unavailable after an incident. Například RTO 90 minut znamená, že musíte být schopni obnovit aplikaci do běžícího stavu během 90 minut od začátku havárie.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. Pokud máte malou RTO, můžete zachovat druhé nasazení nepřetržitě běžící na pohotovostním režimu pro ochranu před oblastním výpadkem.If you have a low RTO, you might keep a second deployment continually running on standby to protect against a regional outage.

  • Cíl bodu obnovení (RPO)Recovery point objective (RPO)
    Cíl bodu obnovení (RPO) je maximální období ztráty dat, které je při havárii přijatelné.RPO is the maximum duration of data loss that is acceptable during a disaster. Pokud například ukládáte data do jediné databáze, která se zálohuje každou hodinu a nemá žádnou replikaci do jiných databází, můžete přijít o hodinu dat.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.

Proveďte posouzení pro definování RTO a RPO pro každou aplikaci.Conduct an assessment to define the RTO and RPO for each application.

Další důležitou metrikou, kterou je třeba zvážit, je Střední doba obnovení (MTTR), což je průměrná doba potřebná k obnovení aplikace po selhání.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 je empirická hodnota pro systém.MTTR is an empirical value for a system. Pokud MTTR překročí RTO, pak selhání v systému způsobí nepřijatelné výpadky v podniku, protože bylo výhra, že je ' možné obnovit systém v rámci definovaného 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.

Možnosti ochrany pro virtuální počítače s IaaSProtection options for IaaS VMs

Zálohování – obnoveníBackup-restore

Nejběžnějším schématem ochrany pro aplikace založené na virtuálním počítači je použití zálohovacího softwaru.The most common protection scheme for VM-based apps is to use backup software. Zálohování virtuálního počítače obvykle zahrnuje operační systém, konfiguraci operačního systému, binární soubory aplikace a trvalá data aplikací obsažená ve virtuálním počítači.Backing up a VM typically includes the operating system, operating system configuration, application binaries, and persistent application data contained inside the VM. Zálohy se vytvářejí pomocí agenta v hostovaném operačním systému pro zachycení aplikace, operačního systému nebo systému souborů/svazků.The backups are created by using an agent in the guest OS to capture application, OS, or file system/volumes. Další možností je bez agenta tím, že se spoléhá na integraci s rozhraními API centra Azure Stack ke čtení informací o konfiguraci virtuálních počítačů a snímku disků připojených k virtuálnímu počítači.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. Uvědomte si prosím, že centrum Azure Stack nepodporuje zálohování přímo z hypervisoru.Please note that Azure Stack Hub does not support backing up directly from the hypervisor.

Plánování strategie zálohováníPlanning your backup strategy

Plánování strategie zálohování a definování požadavků na škálování začíná vystanovením počtu instancí virtuálních počítačů, které je potřeba chránit.Planning your backup strategy and defining scale requirements starts with quantifying the number of VM instances that need to be protected. Zálohování všech virtuálních počítačů v systému nemusí být nejúčinnějším způsobem ochrany aplikace.Backing up all VMs in the system may not be the most effective way to protect application. U Azure Stackového centra by se virtuální počítače v sadě škálování nebo skupině dostupnosti neměly zálohovat na úrovni virtuálního počítače.With Azure Stack Hub, VMs in a scale-set or availability set should not be backed up at the VM level. Tyto virtuální počítače se považují za dočasné, protože sadu virtuálních počítačů je možné škálovat nebo oddálit. V ideálním případě se všechna data, která je třeba zachovat, nachází v samostatném úložišti, jako je databáze nebo úložiště objektů.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. Pokud aplikace nasazené v architektuře se škálováním na více instancí obsahují data, která musí být trvalá a chráněná, pak bude vyžadovat zálohování na úrovni aplikace pomocí nativních schopností poskytovaných aplikací nebo spoléhání na agenta.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.

Důležité informace pro zálohování virtuálních počítačů na Azure Stack:Important considerations for backing up VMs on Azure Stack:

  • KategorizaceCategorization
    • Vezměte v úvahu model, ve kterém uživatelé můžou použít zálohování virtuálních počítačů.Consider a model where users opt into VM backup.
    • Definujte smlouvu o úrovni služeb (SLA) pro obnovení na základě priority aplikací nebo dopadu na firmu.Define a recovery service level agreement (SLA) based on the priority of the applications or the impact to the business.
  • ŠkálováníScale
    • Při připojování k velkému počtu nových virtuálních počítačů (Pokud se vyžaduje zálohování) zvažte možnost rozložit zálohy.Consider staggered backups when on-boarding a large number of new VMs (if backup is required).
    • Vyhodnoťte zálohovací produkty, které můžou efektivně zachytit a přenést data záloh, aby se minimalizoval obsah prostředků v řešení.Evaluate backup products that can efficiently capture and transmit backup data to minimize resource content on the solution.
    • Vyhodnoťte záložní produkty, které efektivně ukládají zálohovaná data pomocí přírůstkových nebo rozdílových záloh, abyste minimalizovali potřebu úplných záloh napříč všemi virtuálními počítači v prostředí.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.
  • ObnoveníRestore
    • Záložní produkty můžou obnovit virtuální disky, data aplikací v existujícím virtuálním počítači nebo celý prostředek virtuálního počítače a přidružené virtuální disky.Backup products can restore virtual disks, app data within an existing VM, or the entire VM resource and associated virtual disks. Schéma obnovení, které potřebujete, závisí na tom, jak plánujete aplikaci obnovit.The restore scheme you need depends on how you plan to restore the app. Může být například snazší znovu nasadit systém SQL Server ze šablony a pak obnovit databáze namísto obnovení celého virtuálního počítače nebo sady virtuálních počítačů.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.

Replikace/ruční převzetí služeb při selháníReplication/manual failover

Alternativním přístupem k podpoře obnovení je replikace dat do jiného prostředí.An alternate approach to supporting recovery is to replicate data to another environment. Tato data můžou být vymezená na aplikaci, jako je například replikace databáze nebo operační systém v hostovaném operačním systému, pomocí agenta nebo na úrovni virtuálního počítače integrací s rozhraními API centra Azure Stack.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. V případě havárie se vyžaduje převzetí služeb při selhání do sekundárního umístění.In the event of a disaster, failover to the secondary location is required. Převzetí služeb při selhání může nativně zpracovávat aplikace jako se skupinami dostupnosti SQL nebo na úrovni hostovaného operačního systému pomocí agentů nebo technologie clusterů nebo na úrovni virtuálního počítače pomocí produktu ochrany.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.

Vysoká dostupnost/automatické převzetí služeb při selháníHigh availability/automatic failover

Aplikace, které nativně podporují vysokou dostupnost nebo spoléhá na software clusteru, aby dosáhli vysoké dostupnosti napříč uzly, se dají nasadit napříč skupinou virtuálních počítačů v jednom Azure Stackovém centru nebo mezi různými Azure Stack instancemi hub.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. Ve všech případech je potřeba určitou úroveň vyrovnávání zatížení, aby se zajistilo správné směrování provozu aplikací.In all cases, some level of load balancing is required to ensure application traffic is routed correctly. V této konfiguraci se může aplikace automaticky zotavit z chyb.In this configuration, the application can automatically recover from faults. U místních hardwarových chyb implementuje infrastruktura centra Azure Stack vysokou dostupnost a odolnost proti chybám ve fyzické infrastruktuře.For local hardware faults, Azure Stack Hub infrastructure implements high availability and fault tolerance in the physical infrastructure. V případě chyb na úrovni výpočetní služby používá rozbočovač služby Azure Stack v konfiguraci N-1 více uzlů v jednotce škálování.For compute level faults, Azure Stack Hub uses multiple nodes in a scale unit in an N-1 configuration. Na úrovni virtuálního počítače se v sadách dostupnosti a škálování modelují jednotlivé uzly v jednotce škálování-jednotka jako doména selhání, aby se zaručila ochrana na úrovni uzlu, takže selhání uzlů nevezmou distribuovanou aplikaci.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.

Bez ochranyNo protection

Některé aplikace nemusí obsahovat data, která je třeba zachovat.Some applications may not have data that needs to be persisted. Například virtuální počítače používané pro vývoj a testování obvykle ' nemusí být obnoveny.For example, VMs used for development and testing typically don't need to be recovered. Dalším příkladem je Bezstavová aplikace, kterou je možné v případě selhání znovu nasadit z kanálu CI/CD.Another example is a stateless application that can be re-deployed from a CI/CD pipeline in the event of a failure. Je důležité určit aplikace, které nevyžadují ochranu, aby nedocházelo k zbytečné ochraně virtuálních počítačů.It is important to identify the applications that do not require protection to avoid unnecessarily protecting VMs.

Další krokyNext steps

V tomto článku najdete obecné pokyny pro ochranu virtuálních počítačů, které jsou nasazené v Azure Stack.This article provided general guidelines for protecting user VMs deployed on Azure Stack. Informace o použití služeb Azure k ochraně virtuálních počítačů uživatele najdete v tématu:For information about using Azure services to protect user VMs, refer to:

Partnerské produktyPartner products