Kontrolní seznam k odolnosti pro konkrétní služby AzureResiliency checklist for specific Azure services

Odolnost je schopnost systému obnovit funkci v případě selhání a pokračovat v provozu.Resiliency is the ability of a system to recover from failures and continue to function. Každá technologie má své vlastní konkrétní režimy selhání, které je nutné vzít v úvahu při navrhování a implementaci aplikace.Every technology has its own particular failure modes, which you must consider when designing and implementing your application. Pomocí tohoto kontrolního seznamu se můžete podívat na požadavky na odolnost pro konkrétní služby Azure.Use this checklist to review the resiliency considerations for specific Azure services. Další informace o navrhování odolných aplikací najdete v tématu Návrh spolehlivých aplikací Azure.For more information about designing resilient applications, see Design reliable Azure applications.

App ServiceApp Service

Použijte úroveň Standard nebo Premium.Use Standard or Premium tier. Tyto úrovně podporují přípravné sloty a automatizované zálohy.These tiers support staging slots and automated backups. Další informace najdete v tématu Podrobný Přehled plánů Azure App Service .For more information, see Azure App Service plans in-depth overview

Vyhněte se škálování směrem nahoru nebo dolů.Avoid scaling up or down. Místo toho vyberte velikost vrstvy a instance, která vyhovuje vašim požadavkům na výkon při běžném zatížení, a pak nahorizontální navýšení kapacity instancí za účelem zpracování změn v objemu přenosů.Instead, select a tier and instance size that meet your performance requirements under typical load, and then scale out the instances to handle changes in traffic volume. Horizontální navýšení nebo snížení kapacity může aktivovat restart aplikace.Scaling up and down may trigger an application restart.

Konfigurace úložiště jako nastavení aplikaceStore configuration as app settings. Nastavení aplikace můžete použít k uložení nastavení konfigurace jako nastavení aplikace.Use app settings to hold configuration settings as app settings. Definujte nastavení v šablonách Správce prostředků nebo pomocí PowerShellu, abyste je mohli použít jako součást procesu automatizovaného nasazení nebo aktualizace, který je spolehlivější.Define the settings in your Resource Manager templates, or using PowerShell, so that you can apply them as part of an automated deployment / update process, which is more reliable. Další informace najdete v tématu Konfigurace webových aplikací v Azure App Service.For more information, see Configure web apps in Azure App Service.

Vytvořte samostatné plány App Service pro produkci a testování.Create separate App Service plans for production and test. Pro účely testování nepoužívejte sloty pro nasazení v produkčním prostředí.Don't use slots on your production deployment for testing. Všechny aplikace v rámci stejného App Service plánu sdílejí stejné instance virtuálních počítačů.All apps within the same App Service plan share the same VM instances. Pokud zadáte produkční a testovací nasazení ve stejném plánu, může negativně ovlivnit produkční nasazení.If you put production and test deployments in the same plan, it can negatively affect the production deployment. Například zátěžové testy mohou snižovat provozní pracoviště za provozu.For example, load tests might degrade the live production site. Nasazením testů do samostatného plánu je izolujete z produkční verze.By putting test deployments into a separate plan, you isolate them from the production version.

Oddělte webové aplikace od webových rozhraní API.Separate web apps from web APIs. Pokud má vaše řešení webový front-end i webové rozhraní API, zvažte jejich vyvýšení na samostatné aplikace App Service.If your solution has both a web front end and a web API, consider decomposing them into separate App Service apps. Tento návrh usnadňuje rozložit řešení podle zatížení.This design makes it easier to decompose the solution by workload. Webovou aplikaci a rozhraní API můžete spustit v samostatných plánech App Service, takže je můžete škálovat nezávisle.You can run the web app and the API in separate App Service plans, so they can be scaled independently. Pokud nepotřebujete tuto úroveň škálovatelnosti jako první, můžete nasadit aplikace do stejného plánu a později je přesunout do samostatných plánů, a to v případě potřeby.If you don't need that level of scalability at first, you can deploy the apps into the same plan, and move them into separate plans later, if needed.

Nepoužívejte funkci zálohování App Service k zálohování databází SQL Azure.Avoid using the App Service backup feature to back up Azure SQL databases. Místo toho použijte SQL Database automatizované zálohy.Instead, use SQL Database automated backups. App Service Backup exportuje databázi do souboru SQL BACPAC, který DTU náklady.App Service backup exports the database to a SQL BACPAC file, which costs DTUs.

Nasaďte do přípravného slotu.Deploy to a staging slot. Vytvořte slot nasazení pro přípravu.Create a deployment slot for staging. Nasaďte aktualizace aplikace do přípravného slotu a před jejich přepnutím do produkčního prostředí ověřte nasazení.Deploy application updates to the staging slot, and verify the deployment before swapping it into production. Tím se sníží pravděpodobnost špatné aktualizace v produkčním prostředí.This reduces the chance of a bad update in production. Také zajišťuje, aby všechny instance byly před přepnutím do produkčního prostředí zahřívání.It also ensures that all instances are warmed up before being swapped into production. Mnoho aplikací má značný zahřívání a studený čas spuštění.Many applications have a significant warmup and cold-start time. Další informace najdete v tématu Nastavení přípravného prostředí pro webové aplikace v Azure App Service.For more information, see Set up staging environments for web apps in Azure App Service.

Vytvořte slot nasazení pro uložení posledního známého nasazení (LKG).Create a deployment slot to hold the last-known-good (LKG) deployment. Když nasadíte aktualizaci do produkčního prostředí, přesunete předchozí provozní nasazení do slotu LKG.When you deploy an update to production, move the previous production deployment into the LKG slot. Díky tomu je snazší vrátit chybné nasazení.This makes it easier to roll back a bad deployment. Pokud zjistíte problém později, můžete se rychle vrátit k verzi LKG.If you discover a problem later, you can quickly revert to the LKG version. Další informace najdete v tématu základní webová aplikace.For more information, see Basic web application.

Povolte protokolování diagnostiky, včetně protokolování aplikací a protokolování webového serveru.Enable diagnostics logging, including application logging and web server logging. Protokolování je důležité pro monitorování a diagnostiku.Logging is important for monitoring and diagnostics. Viz Povolení protokolování diagnostiky pro webové aplikace v Azure App ServiceSee Enable diagnostics logging for web apps in Azure App Service

Přihlaste se do úložiště objektů BLOB.Log to blob storage. To usnadňuje shromažďování a analýzu dat.This makes it easier to collect and analyze the data.

Vytvořte samostatný účet úložiště pro protokoly.Create a separate storage account for logs. Nepoužívejte stejný účet úložiště pro protokoly a data aplikací.Don't use the same storage account for logs and application data. To pomáhá zabránit protokolování v omezení výkonu aplikace.This helps to prevent logging from reducing application performance.

Monitorujte výkon.Monitor performance. Ke sledování výkonu a chování aplikace v rámci zátěže použijte službu sledování výkonu, jako je třeba New Relic nebo Application Insights .Use a performance monitoring service such as New Relic or Application Insights to monitor application performance and behavior under load. Sledování výkonu vám poskytne přehled o aplikaci v reálném čase.Performance monitoring gives you real-time insight into the application. Umožňuje diagnostikovat problémy a provádět analýzy chyb v původní příčině.It enables you to diagnose issues and perform root-cause analysis of failures.

Azure Load BalancerAzure Load Balancer

Vybrat standardní SKU Standard Load Balancer poskytuje rozměrovou spolehlivost, kterou Basic nepoužívá pro zóny dostupnosti a odolnost zóny.Select Standard SKU Standard Load Balancer provides a dimension of reliability that Basic does not - that of availability zones and zone resiliency. To znamená, že když dojde k výpadku zóny, nebude to mít vliv na Standard Load Balancer redundantní v zóně.This means when a zone goes down, your zone-redundant Standard Load Balancer will not be impacted. Díky tomu můžou vaše nasazení vyodolat selhání zóny v rámci oblasti.This ensures your deployments can withstand zone failures within a region. Kromě toho Standard Load Balancer podporuje globální vyrovnávání zatížení, aby vaše aplikace neovlivnila selhání oblasti.In addition, Standard Load Balancer supports global load balancing ensuring your application is not impacted by region failures either.

Zřídit aspoň dvě instance Nasaďte Azure z více než dvou instancí do back-endu.Provision at least two instances Deploy Azure LB with at least two instances in the backend. Jedna instance může mít za následek selhání v jednom bodě.A single instance could result in a single point of failure. Aby bylo možné sestavovat škálování, můžete chtít párovat Virtual Machine Scale Sets.In order to build for scale, you might want to pair LB with Virtual Machine Scale Sets.

Použít odchozí pravidla Odchozí pravidla zajišťují, že se s chybami připojení nečelí v důsledku vyčerpání portů SNAT.Use outbound rules Outbound rules ensure that you are not faced with connection failures as a result of SNAT port exhaustion. Přečtěte si další informace o odchozím připojení.Learn more about outbound connectivity. I když odchozí pravidla pomůžou zlepšit řešení pro nasazení z malých do střední velikosti, pro produkční úlohy doporučujeme přidružit Standard Load Balancer nebo libovolné nasazení podsítě pomocí překladu adres (NAT) virtuálnísítě.While outbound rules will help improve the solution for small to mid size deployments, for production workloads, we recommend coupling Standard Load Balancer or any subnet deployment with VNet NAT.

Application GatewayApplication Gateway

Zřiďte aspoň dvě instance.Provision at least two instances. Nasaďte Application Gateway s alespoň dvěma instancemi.Deploy Application Gateway with at least two instances. Jediná instance je jediným bodem selhání.A single instance is a single point of failure. Pro zajištění redundance a škálovatelnosti použijte dvě nebo víc instancí.Use two or more instances for redundancy and scalability. Aby bylo možné získat nárok na smlouvu SLA, je nutné zřídit dvě nebo více středních nebo větších instancí.In order to qualify for the SLA, you must provision two or more medium or larger instances.

Cosmos DBCosmos DB

Replikujte databázi napříč různými oblastmi.Replicate the database across regions. Cosmos DB vám umožní přidružit libovolný počet oblastí Azure k databázovému účtu Cosmos DB.Cosmos DB allows you to associate any number of Azure regions with a Cosmos DB database account. Databáze Cosmos DB může mít jednu oblast zápisu a několik oblastí pro čtení.A Cosmos DB database can have one write region and multiple read regions. Pokud v oblasti pro zápis dojde k selhání, můžete si přečíst z jiné repliky.If there is a failure in the write region, you can read from another replica. Klientská sada SDK to zpracuje automaticky.The Client SDK handles this automatically. Můžete také převzít služby při selhání oblasti zápisu do jiné oblasti.You can also fail over the write region to another region. Další informace najdete v tématu Globální distribuce dat pomocí služby Azure Cosmos DB.For more information, see How to distribute data globally with Azure Cosmos DB.

Event HubsEvent Hubs

Používejte kontrolní body.Use checkpoints. Příjemce události by měl zapsat svou aktuální pozici do trvalého úložiště v některém předdefinovaném intervalu.An event consumer should write its current position to persistent storage at some predefined interval. To znamená, že pokud spotřebitel dojde k chybě (například dojde k selhání příjemce nebo dojde k selhání hostitele), nová instance může pokračovat v čtení datového proudu z poslední zaznamenané pozice.That way, if the consumer experiences a fault (for example, the consumer crashes, or the host fails), then a new instance can resume reading the stream from the last recorded position. Další informace najdete v tématu příjemci událostí.For more information, see Event consumers.

Zpracování duplicitních zpráv.Handle duplicate messages. Pokud příjemce události neprojde, zpracování zprávy se obnoví z posledního zaznamenaného kontrolního bodu.If an event consumer fails, message processing is resumed from the last recorded checkpoint. Všechny zprávy, které byly již zpracovány po posledním kontrolním bodu, budou zpracovány znovu.Any messages that were already processed after the last checkpoint will be processed again. Proto musí být logika zpracování zpráv idempotentní nebo aplikace musí být schopna odstranit duplicitní zprávy.Therefore, your message processing logic must be idempotent, or the application must be able to deduplicate messages.

Zpracovat výjimky...Handle exceptions.. Spotřebitel události obvykle zpracovává dávku zpráv ve smyčce.An event consumer typically processes a batch of messages in a loop. V rámci této smyčky zpracování by měly být zpracovány výjimky, aby nedošlo ke ztrátě celé dávky zpráv, pokud jedna zpráva způsobí výjimku.You should handle exceptions within this processing loop to avoid losing an entire batch of messages if a single message causes an exception.

Použijte frontu nedoručených zpráv.Use a dead-letter queue. Pokud při zpracování zprávy dojde k nepřechodnému selhání, uložte zprávu do fronty nedoručených zpráv, abyste mohli stav sledovat.If processing a message results in a nontransient failure, put the message onto a dead-letter queue, so that you can track the status. V závislosti na scénáři můžete zprávu opakovat později, použít kompenzační transakci nebo provést nějakou jinou akci.Depending on the scenario, you might retry the message later, apply a compensating transaction, or take some other action. Všimněte si, že Event Hubs nemá žádnou integrovanou funkci fronty nedoručených zpráv.Note that Event Hubs does not have any built-in dead-letter queue functionality. K implementaci fronty nedoručených zpráv můžete použít Azure Queue Storage nebo Service Bus nebo použít Azure Functions nebo jiný mechanismus pro události.You can use Azure Queue Storage or Service Bus to implement a dead-letter queue, or use Azure Functions or some other eventing mechanism.

Implementace zotavení po havárii převzetím služeb při selhání sekundárním oborem názvů Event Hubs.Implement disaster recovery by failing over to a secondary Event Hubs namespace. Další informace najdete v tématu Azure Event Hubs geografické zotavení po havárii.For more information, see Azure Event Hubs Geo-disaster recovery.

Azure Cache for RedisAzure Cache for Redis

Nakonfigurujte geografickou replikaci.Configure Geo-replication. Geografická replikace poskytuje mechanismus pro propojení dvě mezipaměti Azure úrovně Premium pro instance Redis.Geo-replication provides a mechanism for linking two Premium-tier Azure Cache for Redis instances. Data zapsaná do primární mezipaměti se replikují do sekundární mezipaměti jen pro čtení.Data written to the primary cache is replicated to a secondary read-only cache. Další informace najdete v tématu Konfigurace geografické replikace pro Azure cache pro Redis .For more information, see How to configure geo-replication for Azure Cache for Redis

Nakonfigurujte Trvalost dat.Configure data persistence. Redis Persistence umožňuje zachovat data uložená v Redis.Redis persistence allows you to persist data stored in Redis. Můžete také pořizovat snímky a zálohovat data, která můžete načíst v případě selhání hardwaru.You can also take snapshots and back up the data, which you can load in case of a hardware failure. Další informace najdete v tématu jak nakonfigurovat Trvalost dat pro Azure cache úrovně Premium pro Redis .For more information, see How to configure data persistence for a Premium-tier Azure Cache for Redis

Pokud používáte službu Azure cache pro Redis jako dočasnou mezipaměť dat a ne jako trvalé úložiště, tato doporučení se nemusí vztahovat.If you are using Azure Cache for Redis as a temporary data cache and not as a persistent store, these recommendations may not apply.

Zřídit více než jednu repliku.Provision more than one replica. Pro vysokou dostupnost pro čtení i zápis použijte aspoň dvě repliky pro čtení s vysokou dostupností nebo tři.Use at least two replicas for read high-availability, or three for read-write high-availability.

Nakonfigurujte indexery pro nasazení ve více oblastech.Configure indexers for multi-region deployments. Pokud máte nasazení ve více oblastech, zvažte možnosti kontinuity indexování.If you have a multi-region deployment, consider your options for continuity in indexing.

  • Pokud je zdroj dat geograficky replikovaný, měli byste obecně nasměrovat každý indexer každé místní Azure Search služby na jeho místní repliku zdroje dat.If the data source is geo-replicated, you should generally point each indexer of each regional Azure Search service to its local data source replica. Tento přístup se ale nedoporučuje u rozsáhlých datových sad uložených v Azure SQL Database.However, that approach is not recommended for large datasets stored in Azure SQL Database. Důvodem je to, že Azure Search nemůže provádět přírůstkové indexování ze sekundárních SQL Database replik, jenom z primární repliky.The reason is that Azure Search cannot perform incremental indexing from secondary SQL Database replicas, only from primary replicas. Místo toho nasměrujte všechny indexery na primární repliku.Instead, point all indexers to the primary replica. Po převzetí služeb při selhání ukažte Azure Search indexery na novou primární repliku.After a failover, point the Azure Search indexers at the new primary replica.

  • Pokud zdroj dat není geograficky replikovaný, najeďte více indexerů na stejný zdroj dat, aby Azure Search služby v několika oblastech průběžně a nezávisle na indexu ze zdroje dat.If the data source is not geo-replicated, point multiple indexers at the same data source, so that Azure Search services in multiple regions continuously and independently index from the data source. Další informace najdete v tématu Azure Search posouzení výkonu a optimalizace.For more information, see Azure Search performance and optimization considerations.

Service BusService Bus

Pro produkční úlohy použijte úroveň Premium.Use Premium tier for production workloads. Zasílání zpráv Service Bus úrovně Premium poskytuje vyhrazené a rezervované prostředky pro zpracování a kapacitu paměti pro zajištění předvídatelného výkonu a propustnosti.Service Bus Premium Messaging provides dedicated and reserved processing resources, and memory capacity to support predictable performance and throughput. Úrovně zasílání zpráv na úrovni Premium vám také umožní přístup k novým funkcím, které jsou k dispozici pouze zákazníkům v úrovni Premium.Premium Messaging tier also gives you access to new features that are available only to premium customers at first. Počet jednotek zasílání zpráv můžete určit na základě očekávaných zatížení.You can decide the number of messaging units based on expected workloads.

Zpracování duplicitních zpráv.Handle duplicate messages. Pokud se Vydavatel po odeslání zprávy ihned nezdaří nebo dojde k potížím se sítí nebo systémem, může dojít k chybnému záznamu o doručení zprávy a může stejnou zprávu odeslat do systému dvakrát.If a publisher fails immediately after sending a message, or experiences network or system issues, it may erroneously fail to record that the message was delivered, and may send the same message to the system twice. Service Bus může tento problém vyřešit tím, že povolí detekci duplicit.Service Bus can handle this issue by enabling duplicate detection. Další informace najdete v tématu zjištění duplicit.For more information, see Duplicate detection.

Zpracování výjimek.Handle exceptions. Rozhraní API pro zasílání zpráv generují výjimky, pokud dojde k chybě uživatele, konfigurační chybě nebo k jiné chybě.Messaging APIs generate exceptions when a user error, configuration error, or other error occurs. Kód klienta (odesílatelé a přijímače) by měl tyto výjimky zpracovat ve svém kódu.The client code (senders and receivers) should handle these exceptions in their code. To je obzvláště důležité při dávkovém zpracování, kde je možné použít zpracování výjimek k tomu, abyste se vyhnuli ztrátě celé dávky zpráv.This is especially important in batch processing, where exception handling can be used to avoid losing an entire batch of messages. Další informace najdete v tématu Service Bus výjimky zasílání zpráv.For more information, see Service Bus messaging exceptions.

Zásady opakování.Retry policy. Service Bus umožňuje vybrat pro vaše aplikace osvědčené zásady opakování.Service Bus allows you to pick the best retry policy for your applications. Výchozí zásady jsou povoleny 9 maximálního počtu opakovaných pokusů a čekají na 30 sekund, ale můžete je dál upravovat.The default policy is to allow 9 maximum retry attempts, and wait for 30 seconds but this can be further adjusted. Další informace najdete v tématu zásady opakování – Service Bus.For more information, see Retry policy – Service Bus.

Použijte frontu nedoručených zpráv.Use a dead-letter queue. Pokud zprávu nelze zpracovat ani doručit všem příjemcům po více opakovaných pokusech, bude přesunuta do fronty nedoručených zpráv.If a message cannot be processed or delivered to any receiver after multiple retries, it is moved to a dead letter queue. Implementujte proces pro čtení zpráv z fronty nedoručených zpráv, zkontrolujte je a opravte problém.Implement a process to read messages from the dead letter queue, inspect them, and remediate the problem. V závislosti na scénáři můžete zprávu zkusit znovu, jak je, provést změny, opakovat akci nebo zrušit zprávu.Depending on the scenario, you might retry the message as-is, make changes and retry, or discard the message. Další informace najdete v tématu přehled Service Bus front nedoručených zpráv.For more information, see Overview of Service Bus dead-letter queues.

Použijte obnovení Geo-Disaster.Use Geo-Disaster Recovery. Geografické zotavení po havárii zajišťuje, že zpracování dat pokračuje v provozu v jiné oblasti nebo datacentru v případě, že celá oblast Azure nebo datacentrum nebude k dispozici kvůli havárii.Geo-disaster recovery ensures that data processing continues to operate in a different region or datacenter if an entire Azure region or datacenter becomes unavailable due to a disaster. Další informace najdete v tématu Azure Service Busho geografického zotavení po havárii.For more information, see Azure Service Bus Geo-disaster recovery.

StorageStorage

Pro data aplikací použijte geograficky redundantní úložiště s přístupem pro čtení (RA-GRS).For application data, use read-access geo-redundant storage (RA-GRS). Úložiště RA-GRS replikuje data do sekundární oblasti a poskytuje přístup jen pro čtení ze sekundární oblasti.RA-GRS storage replicates the data to a secondary region, and provides read-only access from the secondary region. Pokud v primární oblasti dojde k výpadku úložiště, aplikace může číst data ze sekundární oblasti.If there is a storage outage in the primary region, the application can read the data from the secondary region. Další informace najdete v tématu replikace Azure Storage.For more information, see Azure Storage replication.

Pro disky virtuálních počítačů použijte spravované disky.For VM disks, use managed disks. Spravované disky poskytují lepší spolehlivost pro virtuální počítače ve skupině dostupnosti, protože disky jsou dostatečně izolované od sebe navzájem, aby se předešlo jednomu bodu selhání.Managed disks provide better reliability for VMs in an availability set, because the disks are sufficiently isolated from each other to avoid single points of failure. Spravované disky navíc nepodléhají limitům virtuálních pevných disků, které jsou vytvořeny v účtu úložiště.Also, managed disks aren't subject to the IOPS limits of VHDs created in a storage account. Další informace najdete v tématu Správa dostupnosti virtuálních počítačů s Windows v Azure.For more information, see Manage the availability of Windows virtual machines in Azure.

Ve frontě úložiště vytvořte frontu zálohování v jiné oblasti.For Queue storage, create a backup queue in another region. V případě úložiště ve frontě má replika jen pro čtení omezené použití, protože položky nemůžete zařadit do fronty nebo je vyřadit z fronty.For Queue storage, a read-only replica has limited use, because you can't queue or dequeue items. Místo toho vytvořte frontu zálohování v účtu úložiště v jiné oblasti.Instead, create a backup queue in a storage account in another region. Pokud dojde k výpadku úložiště, může aplikace použít frontu zálohování, dokud nebude primární region znovu dostupný.If there is a storage outage, the application can use the backup queue, until the primary region becomes available again. Aplikace tak může nadále zpracovávat nové požadavky.That way, the application can still process new requests.

SQL DatabaseSQL Database

Použijte úroveň Standard nebo Premium.Use Standard or Premium tier. Tyto úrovně poskytují delší dobu obnovení k určitému bodu v čase (35 dní).These tiers provide a longer point-in-time restore period (35 days). Další informace najdete v tématu SQL Database možnosti a výkon.For more information, see SQL Database options and performance.

Povolte auditování SQL Database.Enable SQL Database auditing. Auditování se dá použít k diagnostice škodlivých útoků nebo lidské chyby.Auditing can be used to diagnose malicious attacks or human error. Další informace najdete v tématu Začínáme s auditováním služby SQL Database.For more information, see Get started with SQL database auditing.

Použít aktivní geografickou replikaci Pomocí aktivní Geo-Replication můžete v jiné oblasti vytvořit čitelný sekundární objekt.Use Active Geo-Replication Use Active Geo-Replication to create a readable secondary in a different region. Pokud se vaše primární databáze nepovede nebo je nutné ji jednoduše převést do režimu offline, proveďte ruční převzetí služeb při selhání sekundární databází.If your primary database fails, or simply needs to be taken offline, perform a manual failover to the secondary database. Dokud převezmete služby při selhání, sekundární databáze zůstane jen pro čtení.Until you fail over, the secondary database remains read-only. Další informace najdete v tématu SQL Database aktivní geografické replikace.For more information, see SQL Database Active Geo-Replication.

Použijte horizontálního dělení.Use sharding. Zvažte použití horizontálního dělení pro horizontální rozdělení databáze.Consider using sharding to partition the database horizontally. Horizontálního dělení může zajistit izolaci chyb.Sharding can provide fault isolation. Další informace najdete v tématu horizontální navýšení kapacity pomocí Azure SQL Database.For more information, see Scaling out with Azure SQL Database.

Obnovení k bodu v čase použijte k obnovení z lidské chyby.Use point-in-time restore to recover from human error. Obnovení k bodu v čase vrátí databázi k dřívějšímu bodu v čase.Point-in-time restore returns your database to an earlier point in time. Další informace najdete v tématu obnovení databáze SQL Azure pomocí automatických záloh databáze.For more information, see Recover an Azure SQL database using automated database backups.

Pro obnovení z výpadku služby použijte geografické obnovení.Use geo-restore to recover from a service outage. Geografické obnovení obnoví databázi z geograficky redundantní zálohy.Geo-restore restores a database from a geo-redundant backup. Další informace najdete v tématu obnovení databáze SQL Azure pomocí automatických záloh databáze.For more information, see Recover an Azure SQL database using automated database backups.

Azure Synapse AnalyticsAzure Synapse Analytics

Nepovolujte geografickou zálohu.Do not disable geo-backup. Ve výchozím nastavení služba synapse Analytics pro zotavení po havárii provádí úplnou zálohu vašich dat každých 24 hodin.By default, Synapse Analytics takes a full backup of your data every 24 hours for disaster recovery. Tato funkce se nedoporučuje vypnout.It is not recommended to turn this feature off. Další informace najdete v tématu geografická zálohování.For more information, see Geo-backups.

SQL Server spuštěný ve virtuálním počítačiSQL Server running in a VM

Replikujte databázi.Replicate the database. K replikaci databáze použijte SQL Server skupiny dostupnosti Always On.Use SQL Server Always On availability groups to replicate the database. Poskytuje vysokou dostupnost, pokud se jedna instance SQL Server nezdařila.Provides high availability if one SQL Server instance fails. Další informace najdete v tématu spuštění virtuálních počítačů s Windows pro N-vrstvou aplikaci .For more information, see Run Windows VMs for an N-tier application

Zazálohujte databázi.Back up the database. Pokud už používáte Azure Backup k zálohování virtuálních počítačů, zvažte použití Azure Backup pro SQL Server úloh pomocí DPM.If you are already using Azure Backup to back up your VMs, consider using Azure Backup for SQL Server workloads using DPM. S tímto přístupem existuje jedna role správce zálohování pro organizaci a jednotný postup obnovení pro virtuální počítače a SQL Server.With this approach, there is one backup administrator role for the organization and a unified recovery procedure for VMs and SQL Server. Jinak použijte SQL Server spravované zálohování pro Microsoft Azure.Otherwise, use SQL Server Managed Backup to Microsoft Azure.

Traffic ManagerTraffic Manager

Proveďte ruční navrácení služeb po obnovení.Perform manual failback. Po převzetí služeb při selhání Traffic Manager proveďte ruční navrácení služeb po obnovení, nikoli Automatické navracení služeb po obnovení.After a Traffic Manager failover, perform manual failback, rather than automatically failing back. Před navrácením služeb po obnovení ověřte, zda jsou všechny subsystémy aplikace v dobrém stavu.Before failing back, verify that all application subsystems are healthy. V opačném případě můžete vytvořit situaci, kdy se aplikace v datových centrech Překlopí zpátky a zpátky.Otherwise, you can create a situation where the application flips back and forth between datacenters. Další informace najdete v tématu spuštění virtuálních počítačů v několika oblastech pro zajištění vysoké dostupnosti.For more information, see Run VMs in multiple regions for high availability.

Vytvořte koncový bod sondy stavu.Create a health probe endpoint. Vytvořte vlastní koncový bod, který sestaví celkový stav aplikace.Create a custom endpoint that reports on the overall health of the application. To umožňuje Traffic Manager převzít služby při selhání, pokud selže nějaká kritická cesta, nikoli jenom front-end.This enables Traffic Manager to fail over if any critical path fails, not just the front end. Koncový bod by měl vracet kód chyby HTTP, pokud je některá kritická závislost poškozená nebo nedosažitelná.The endpoint should return an HTTP error code if any critical dependency is unhealthy or unreachable. Nevytvářejte zprávy o chybách pro nekritické služby, aleDon't report errors for non-critical services, however. V opačném případě může sonda stavu aktivovat převzetí služeb při selhání, když není potřeba, a vytvoří falešně pozitivní výsledky.Otherwise, the health probe might trigger failover when it's not needed, creating false positives. Další informace najdete v tématu Traffic Manager monitorování koncového bodu a převzetí služeb při selhání.For more information, see Traffic Manager endpoint monitoring and failover.

Virtual MachinesVirtual Machines

Nepoužívejte provozní zatížení na jednom virtuálním počítači.Avoid running a production workload on a single VM. Nasazení jediného virtuálního počítače není odolné vůči plánované nebo neplánované údržbě.A single VM deployment is not resilient to planned or unplanned maintenance. Místo toho vložte více virtuálních počítačů do skupiny dostupnosti nebo sady škálování virtuálních počítačůs nástrojem pro vyrovnávání zatížení předem.Instead, put multiple VMs in an availability set or virtual machine scale set, with a load balancer in front.

Při zřizování virtuálního počítače zadejte skupinu dostupnosti.Specify an availability set when you provision the VM. V současné době neexistuje způsob, jak přidat virtuální počítač do skupiny dostupnosti po zřízení virtuálního počítače.Currently, there is no way to add a VM to an availability set after the VM is provisioned. Když přidáte nový virtuální počítač do existující skupiny dostupnosti, nezapomeňte vytvořit síťovou kartu pro virtuální počítač a přidat síťovou kartu do fondu back-end adres v nástroji pro vyrovnávání zatížení.When you add a new VM to an existing availability set, make sure to create a NIC for the VM, and add the NIC to the back-end address pool on the load balancer. V opačném případě nástroj pro vyrovnávání zatížení neprovede směrování síťového provozu do tohoto virtuálního počítače.Otherwise, the load balancer won't route network traffic to that VM.

Každou aplikační vrstvu umístěte do samostatné skupiny dostupnosti.Put each application tier into a separate Availability Set. V N-vrstvé aplikaci neumísťujte virtuální počítače z různých vrstev do stejné skupiny dostupnosti.In an N-tier application, don't put VMs from different tiers into the same availability set. Virtuální počítače ve skupině dostupnosti jsou umístěné napříč doménami selhání (doménami selhání) a aktualizačními doménami (UD).VMs in an availability set are placed across fault domains (FDs) and update domains (UD). Aby bylo ale možné využít redundanci doménami selhání a UDs, musí mít každý virtuální počítač ve skupině dostupnosti schopný zpracovávat stejné požadavky klientů.However, to get the redundancy benefit of FDs and UDs, every VM in the availability set must be able to handle the same client requests.

Replikace virtuálních počítačů pomocí Azure Site Recovery.Replicate VMs using Azure Site Recovery. Při replikaci virtuálních počítačů Azure pomocí Site Recoveryjsou všechny disky virtuálních počítačů neustále replikovány do cílové oblasti asynchronně.When you replicate Azure VMs using Site Recovery, all the VM disks are continuously replicated to the target region asynchronously. Body obnovení jsou vytvářeny každých několik minut.The recovery points are created every few minutes. To vám umožní určit cíl bodu obnovení (RPO) v řádu minut.This gives you a Recovery Point Objective (RPO) in the order of minutes. Postup zotavení po havárii můžete provést tolikrát, kolikrát chcete, aniž by to ovlivnilo produkční aplikaci nebo průběžnou replikaci.You can conduct disaster recovery drills as many times as you want, without affecting the production application or the ongoing replication. 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.

Vyberte správnou velikost virtuálního počítače na základě požadavků na výkon.Choose the right VM size based on performance requirements. Při přesunu existující úlohy do Azure začněte s velikostí virtuálního počítače, která je nejvhodnější pro vaše místní servery.When moving an existing workload to Azure, start with the VM size that's the closest match to your on-premises servers. Pak změřte výkon svého skutečného zatížení s ohledem na procesor, paměť a IOPS disku a v případě potřeby upravte velikost.Then measure the performance of your actual workload with respect to CPU, memory, and disk IOPS, and adjust the size if needed. To pomáhá zajistit, aby se aplikace v cloudovém prostředí chovala jako očekávaná.This helps to ensure the application behaves as expected in a cloud environment. Pokud potřebujete více síťových rozhraní, uvědomte si také omezení počtu síťových adaptérů pro jednotlivé velikosti.Also, if you need multiple NICs, be aware of the NIC limit for each size.

Použijte spravované disky pro virtuální pevné disky.Use managed disks for VHDs. Spravované disky poskytují lepší spolehlivost pro virtuální počítače ve skupině dostupnosti, protože disky jsou dostatečně izolované od sebe navzájem, aby se předešlo jednomu bodu selhání.Managed disks provide better reliability for VMs in an availability set, because the disks are sufficiently isolated from each other to avoid single points of failure. Spravované disky navíc nepodléhají limitům virtuálních pevných disků, které jsou vytvořeny v účtu úložiště.Also, managed disks aren't subject to the IOPS limits of VHDs created in a storage account. Další informace najdete v tématu Správa dostupnosti virtuálních počítačů s Windows v Azure.For more information, see Manage the availability of Windows virtual machines in Azure.

Nainstalujte aplikace na datový disk, nikoli na disk s operačním systémem.Install applications on a data disk, not the OS disk. V opačném případě se může dosáhnout limitu velikosti disku.Otherwise, you may reach the disk size limit.

K zálohování virtuálních počítačů použijte Azure Backup.Use Azure Backup to back up VMs. Zálohy chrání před náhodnou ztrátou dat.Backups protect against accidental data loss. Další informace najdete v tématu ochrana virtuálních počítačů Azure pomocí trezoru Recovery Services.For more information, see Protect Azure VMs with a Recovery Services vault.

Povolte diagnostické protokoly.Enable diagnostic logs. Zahrnuje základní metriky stavu, protokoly infrastruktury a diagnostiku spouštění.Include basic health metrics, infrastructure logs, and boot diagnostics. Diagnostika spouštění vám může pomáhat diagnostikovat selhání při spuštění, pokud se váš virtuální počítač stane nespouštěcím stavem.Boot diagnostics can help you diagnose a boot failure if your VM gets into a nonbootable state. Další informace najdete v tématu Přehled diagnostických protokolů Azure.For more information, see Overview of Azure Diagnostic Logs.

Nakonfigurujte Azure Monitor.Configure Azure Monitor. Shromažďování a analýza dat monitorování z virtuálních počítačů Azure, včetně hostovaného operačního systému a úloh, které jsou v něm spuštěné, najdete v tématu Azure monitor a rychlý Start: Azure monitor.Collect and analyze monitoring data from Azure virtual machines including the guest operating system and the workloads that run in it, see Azure Monitor and Quickstart: Azure Monitor.

Virtual NetworkVirtual Network

Pokud chcete zakázat nebo zablokovat veřejné IP adresy, přidejte do podsítě skupinu zabezpečení sítě.To allow or block public IP addresses, add a network security group to the subnet. Blokuje přístup uživatelů se zlými úmysly nebo povolí přístup pouze uživatelům, kteří mají oprávnění pro přístup k aplikaci.Block access from malicious users, or allow access only from users who have privilege to access the application.

Vytvořte vlastní sondu stavu.Create a custom health probe. Sondy stavu Load Balancer můžou testovat protokol HTTP nebo TCP.Load Balancer Health Probes can test either HTTP or TCP. Pokud virtuální počítač spustí server HTTP, test HTTP je lepším indikátorem stavu než test TCP.If a VM runs an HTTP server, the HTTP probe is a better indicator of health status than a TCP probe. U testu HTTP použijte vlastní koncový bod, který oznamuje celkový stav aplikace včetně všech kritických závislostí.For an HTTP probe, use a custom endpoint that reports the overall health of the application, including all critical dependencies. Další informace najdete v tématu přehled Azure Load Balancer.For more information, see Azure Load Balancer overview.

Neblokujte sondu stavu.Don't block the health probe. Sonda stavu Load Balancer se odesílá ze známé IP adresy, 168.63.129.16.The Load Balancer Health probe is sent from a known IP address, 168.63.129.16. Neblokovat provoz do nebo z této IP adresy v jakýchkoli zásadách brány firewall nebo pravidel skupiny zabezpečení sítě.Don't block traffic to or from this IP in any firewall policies or network security group rules. Blokování sondy stavu způsobí, že nástroj pro vyrovnávání zatížení odebere virtuální počítač z rotace.Blocking the health probe would cause the load balancer to remove the VM from rotation.

Povolte protokolování Load Balancer.Enable Load Balancer logging. Protokoly ukazují, kolik virtuálních počítačů v back-endu nepřijímá síťový provoz kvůli neúspěšným odpovědím na testy.The logs show how many VMs on the back-end are not receiving network traffic due to failed probe responses. Další informace najdete v tématu Log Analytics pro Azure Load Balancer.For more information, see Log analytics for Azure Load Balancer.