Zálohování a zotavení po havárii pro aplikace AzureBackup and disaster recovery for Azure applications

Zotavení po havárii je proces obnovení funkčnosti aplikace při probuzení závažné ztráty.Disaster recovery is the process of restoring application functionality in the wake of a catastrophic loss.

V cloudu potvrzuji, že dojde k selhání.In the cloud, we acknowledge up front that failures will happen. Místo snahy kompletně zabránit selháním je cílem minimalizace dopadu selhání jedné komponenty.Instead of trying to prevent failures altogether, the goal is to minimize the effects of a single failing component. Testování je jedním ze způsobů, jak tyto efekty minimalizovat.Testing is one way to minimize these effects. Testování aplikací, které jsou v případě potřeby, byste měli provést, ale je potřeba je připravit, až selžou.You should automate testing you applications where possible, but you need to be prepared for when they fail. V takovém případě se strategie zálohování a obnovení budou důležité.When this happens, having backup and recovery strategies becomes important.

Vaše tolerance pro omezenou funkčnost během havárie je obchodní rozhodnutí, které se liší od jedné aplikace po další.Your tolerance for reduced functionality during a disaster is a business decision that varies from one application to the next. Může být přijatelné, aby některé aplikace byly nedostupné nebo byly částečně dostupné s omezenou funkčností nebo opožděným zpracováním po určitou dobu.It might be acceptable for some applications to be unavailable or to be partially available with reduced functionality or delayed processing for a period of time. U ostatních aplikací se neakceptuje žádné omezené funkce.For other applications, any reduced functionality is unacceptable.

Klíčové bodyKey points

  • V pravidelných intervalech Vytvářejte a testujte plán zotavení po havárii s využitím scénářů selhání klíčů.Create and test a disaster recovery plan on a regular basis using key failure scenarios.
  • Navrhněte strategii zotavení po havárii, která spustí většinu aplikací s omezenou funkčností.Design disaster recovery strategy to run most applications with reduced functionality.
  • Navrhněte strategii zálohování, která je přizpůsobená obchodním požadavkům a okolnostem aplikace.Design a backup strategy that is tailored to business requirements and circumstances of the application.
  • Automatizace kroků a procesů převzetí služeb při selhání a navrácení služeb po obnoveníAutomate failover and failback steps and processes.
  • Otestujte a ověřte, jestli úspěšně převzetí služeb při selhání a navrácení služeb po obnovení proběhlo aspoň jednouTest and validate the failover and failback approach successfully at least once.

Plán zotavení po haváriiDisaster recovery plan

Začněte vytvořením plánu obnovení.Start by creating a recovery plan. Plán se považuje za dokončený poté, co byl plně testován.The plan is considered complete after it has been fully tested. Zahrňte lidi, procesy a aplikace potřebné k obnovení funkčnosti v rámci smlouvy SLA (Service-level agreement), kterou jste definovali pro vaše zákazníky.Include the people, processes, and applications needed to restore functionality within the service-level agreement (SLA) you've defined for your customers.

Při vytváření a testování plánu zotavení po havárii Vezměte v úvahu následující návrhy:Consider the following suggestions when creating and testing your disaster recovery plan:

  • Zahrňte proces pro kontaktování podpory a zvýšení problémů.Include the process for contacting support and for escalating issues. Tyto informace vám pomůžou zabránit dlouhotrvajícímu výpadku při prvním použití procesu obnovení.This information will help to avoid prolonged downtime as you work out the recovery process for the first time.
  • Vyhodnoťte obchodní dopad selhání aplikace.Evaluate the business impact of application failures.
  • Vyberte architekturu obnovení mezi jednotlivými oblastmi pro klíčové aplikace.Choose a cross-region recovery architecture for mission-critical applications.
  • Identifikujte konkrétního vlastníka plánu zotavení po havárii, včetně automatizace a testování.Identify a specific owner of the disaster recovery plan, including automation and testing.
  • Zdokumentujte proces, zejména ruční kroky.Document the process, especially any manual steps.
  • Automatizujte proces co nejvíce.Automate the process as much as possible.
  • Vytvořte strategii zálohování pro všechny referenční a transakční data a pravidelně provádějte obnovu záložního zálohování.Establish a backup strategy for all reference and transactional data, and test backup restoration regularly.
  • Nastavte výstrahy pro zásobník služeb Azure spotřebovaných vaší aplikací.Set up alerts for the stack of the Azure services consumed by your application.
  • Školením provozních pracovníků proveďte plán.Train operations staff to execute the plan.
  • K ověření a vylepšení plánu Provádějte pravidelné simulace havárie.Perform regular disaster simulations to validate and improve the plan.

Pokud používáte Azure Site Recovery k replikaci virtuálních počítačů, vytvořte plně automatizovaný plán obnovení pro převzetí služeb při selhání celou aplikaci.If you're using Azure Site Recovery to replicate virtual machines (VMs), create a fully automated recovery plan to fail over the entire application.

Testování provozní připravenostiOperational readiness testing

Proveďte test provozní připravenosti pro převzetí služeb při selhání do sekundární oblasti a pro navrácení služeb po obnovení do primární oblasti.Perform an operational readiness test for failover to the secondary region and for failback to the primary region. Řada služeb Azure podporuje postupy zotavení po havárii s využitím ručního převzetí služeb při selhání nebo testovacího převzetí služeb při selhání.Many Azure services support manual failover or test failover for disaster recovery drills. Alternativně můžete simulovat výpadky vypnutím nebo odebráním služeb Azure.Alternatively, you can simulate an outage by shutting down or removing Azure services.

Automatizované provozní odpovědi by se měly často testovat v rámci normálního životního cyklu aplikace, aby se zajistila provozní efektivita.Automated operational responses should be tested frequently as part of the normal application lifecycle to ensure operational effectiveness.

Převzetí služeb při selhání a testování po obnoveníFailover and failback testing

Otestujte převzetí služeb při selhání a navrácení služeb po obnovení, abyste ověřili, že se závislé služby vaší aplikace při zotavení po havárii synchronizují.Test failover and failback to verify that your application's dependent services come back up in a synchronized manner during disaster recovery. Změny systémů a operací mohou mít vliv na funkce převzetí služeb při selhání a navrácení služeb po obnovení, ale dopad nemusí být zjištěn, dokud nedojde k selhání hlavního systému nebo dojde k jeho přetížení.Changes to systems and operations may affect failover and failback functions, but the impact may not be detected until the main system fails or becomes overloaded. Otestujte možnosti převzetí služeb při selhání, než se budou muset kompenzovat při živém problému.Test failover capabilities before they are required to compensate for a live problem. Ujistěte se také, že ve správném pořadí převzetí služeb při selhání závislých služeb a navrácení služeb po obnovení.Also, be sure that dependent services failover and failback in the correct order.

Pokud k replikaci virtuálních počítačů používáte Azure Site Recovery , spusťte při testování převzetí služeb při selhání pravidelné procházení po havárii, abyste ověřili strategii pro replikaci.If you are using Azure Site Recovery to replicate VMs, run disaster recovery drills periodically by testing failovers to validate your replication strategy. Testovací převzetí služeb při selhání nemá vliv na probíhající replikaci virtuálních počítačů nebo na vaše produkční prostředí.A test failover does not affect the ongoing VM replication or your production environment. Další informace najdete v tématu spuštění postupu zotavení po havárii do Azure.For more information, see Run a disaster recovery drill to Azure.

Výpadek závislé službyDependent service outage

U každé závislé služby byste měli pochopit důsledky přerušení služby a způsob, jakým bude aplikace reagovat.For each dependent service, you should understand the implications of service disruption and the way that the application will respond. Mnohé služby zahrnují funkce, které podporují odolnost a dostupnost, takže vyhodnocování každé služby nezávisle může zlepšit plán zotavení po havárii.Many services include features that support resiliency and availability, so evaluating each service independently is likely to improve your disaster recovery plan. Například Azure Event Hubs podporuje převzetí služeb při selhání sekundárním oborem názvů.For example, Azure Event Hubs supports failing over to the secondary namespace.

Výpadek sítěNetwork outage

Pokud jsou části sítě Azure nedostupné, možná nebudete mít přístup k vaší aplikaci nebo datům.When parts of the Azure network are inaccessible, you might not be able to access your application or data. V této situaci doporučujeme navrhnout strategii zotavení po havárii, aby se spouštěla většina aplikací s omezenou funkčností.In this situation, we recommend designing the disaster recovery strategy to run most applications with reduced functionality.

Pokud omezení funkcí není možnost, zbývající možnosti jsou výpadky aplikace nebo převzetí služeb při selhání do alternativní oblasti.If reducing functionality isn't an option, the remaining options are application downtime or failover to an alternate region.

Ve scénáři se sníženou funkčností:In a reduced functionality scenario:

  • Pokud vaše aplikace nemá přístup k datům z důvodu výpadku sítě Azure, může být možné spustit místně s omezenou funkčností aplikace pomocí dat uložených v mezipaměti.If your application can't access its data because of an Azure network outage, you might be able to run locally with reduced application functionality by using cached data.
  • Dokud nebude připojení obnoveno, může být možné ukládat data do alternativního umístění.You might be able to store data in an alternate location until connectivity is restored.

Automatizaci obnoveníRecovery automation

Kroky potřebné k obnovení nebo převzetí služeb při selhání aplikace v sekundární oblasti Azure v situacích selhání by měly být kodifikováné, nejlépe v automatizovaných způsobech, aby se zajistilo, že možnosti existují k účinné reakci na výpadky způsobem, který omezuje dopad.The steps required to recover or failover the application to a secondary Azure region in failure situations should be codified, preferably in an automated manner, to ensure capabilities exist to effectively respond to an outage in a way that limits impact. Pro zachycení procesu potřebného k navrácení služeb po obnovení do primární oblasti by se měly také provést podobné kodifikováné kroky, jakmile bude vyřešen problém s aktivací převzetí služeb při selhání.Similar codified steps should also exist to capture the process required to failback the application to the primary region once a failover triggering issue has been addressed.

Při automatizaci postupů převzetí služeb při selhání se ujistěte, že nástroj používaný pro orchestraci převzetí služeb při selhání se taky považuje za v strategii převzetí služeb při selháníWhen automating failover procedures, ensure that the tooling used for orchestrating the failover are also considered in the failover strategy. Pokud například spustíte převzetí služeb při selhání z Jenkinse běžícího na VIRTUÁLNÍm počítači, dojde k problémům, pokud je tento virtuální počítač součástí výpadku.For example, if you run your failover from Jenkins running on a VM, you'll be in trouble if that virtual machine is part of the outage. Azure DevOps Projects jsou vymezena také v oblasti.Azure DevOps Projects are scoped to a region too.

Strategie zálohováníBackup strategy

K dispozici je řada alternativních strategií pro implementaci distribuovaných výpočtů napříč oblastmi.Many alternative strategies are available for implementing distributed compute across regions. Ty musí být upraveny na konkrétní obchodní požadavky a podmínky aplikace.These must be tailored to the specific business requirements and circumstances of the application. V nejvyšší úrovni je možné tyto přístupy rozdělit do následujících kategorií:At a high level, the approaches can be divided into the following categories:

  • Opětovné nasazení při havárii: v tomto postupu se aplikace znovu nasadí od začátku v době havárie.Redeploy on disaster: In this approach, the application is redeployed from scratch at the time of disaster. To je vhodné pro nekritické aplikace, které nevyžadují garantovanou dobu obnovení.This is appropriate for non-critical applications that don’t require a guaranteed recovery time.

  • Volná (aktivní/pasivní): sekundární hostovaná služba se vytvoří v alternativní oblasti a role se nasadí, aby se zaručila Minimální kapacita. role ale neobdrží provozní provoz.Warm Spare (Active/Passive): A secondary hosted service is created in an alternate region, and roles are deployed to guarantee minimal capacity; however, the roles don’t receive production traffic. Tento přístup je užitečný pro aplikace, které nejsou navržené pro distribuci provozu napříč oblastmi.This approach is useful for applications that have not been designed to distribute traffic across regions.

  • Vyměnitelné za chodu (aktivní/aktivní): aplikace je navržená tak, aby přijímala provozní zatížení ve více oblastech.Hot Spare (Active/Active): The application is designed to receive production load in multiple regions. Cloudové služby v jednotlivých oblastech můžou být nakonfigurované pro větší kapacitu, než je potřeba pro účely zotavení po havárii.The cloud services in each region might be configured for higher capacity than required for disaster recovery purposes. Cloudové služby se případně můžou v případě havárie a převzetí služeb při selhání škálovat podle potřeby.Alternatively, the cloud services might scale-out as necessary at the time of a disaster and failover. Tento přístup vyžaduje značné investice do návrhu aplikací, ale má významné výhody.This approach requires substantial investment in application design, but it has significant benefits. Mezi ně patří nízká a zaručená doba obnovení, nepřetržité testování všech umístění obnovení a efektivní využití kapacity.These include low and guaranteed recovery time, continuous testing of all recovery locations, and efficient usage of capacity.

Plánování regionálních selháníPlan for regional failures

Azure je rozdělen fyzicky a logicky do jednotek nazývaných oblasti.Azure is divided physically and logically into units called regions. Oblast se skládá z jednoho nebo více datových center v těsné blízkosti.A region consists of one or more data centers in close proximity.

Ve výjimečných případech je možné, že zařízení v celé oblasti můžou být nepřístupná, například kvůli selháním sítě.Under rare circumstances, it is possible that facilities in an entire region can become inaccessible, for example, due to network failures. Nebo můžete zařízení zcela ztratit, například kvůli přirozené havárii.Or, facilities can be lost entirely, for example, due to a natural disaster. Azure obsahuje možnosti pro vytváření aplikací, které jsou distribuované napříč oblastmi.Azure has capabilities for creating applications that are distributed across regions. Tato distribuce pomáhá minimalizovat možnost, že selhání v jedné oblasti může ovlivnit jiné oblasti.Such distribution helps to minimize the possibility that a failure in one region could affect other regions.

Další krokNext step

Vraťte se k hlavnímu článku: testováníGo back to the main article: Testing