Kontrolní seznam k odolnosti pro konkrétní služby Azure

Odolnost je schopnost systému obnovit funkci v případě selhání a pokračovat v provozu. Každá technologie má své vlastní konkrétní režimy selhání, které musíte vzít v úvahu při návrhu a implementaci aplikace. Pomocí tohoto kontrolního seznamu si prohlédněte aspekty odolnosti pro konkrétní služby Azure. Další informace o navrhování odolných aplikací najdete v tématu Návrh spolehlivých aplikací Azure.

App Service

Použijte úroveň Standard nebo Premium. Tyto úrovně podporují pracovní sloty a automatizované zálohy. Další informace najdete v Azure App Service podrobného přehledu plánů.

Vyhněte se škálování nahoru nebo dolů. Místo toho vyberte vrstvu a velikost instance, které splňují vaše požadavky na výkon při typickém zatížení, a pak škálování instancí na více instancí pro zpracování změn objemu provozu. Škálování nahoru a dolů může aktivovat restartování aplikace.

Uložte konfiguraci jako nastavení aplikace. Nastavení aplikace můžete použít k nastavení konfigurace jako nastavení aplikace. Definujte nastavení v šablonách Resource Manager nebo pomocí PowerShellu, abyste je mohli použít jako součást automatizovaného procesu nasazení nebo aktualizace, což je spolehlivější. Další informace najdete v tématu Konfigurace webových aplikací v Azure App Service.

Vytvořte samostatné App Service pro produkční a testovací prostředí. Nepoužívejte sloty v produkčním nasazení pro účely testování. Všechny aplikace v rámci stejného plánu App Service sdílí stejné instance virtuálních počítače. Pokud do stejného plánu vsazíte produkční a testovací nasazení, může to mít negativní vliv na produkční nasazení. Zátěžové testy mohou například snížit výkon živé produkční lokality. Když testovací nasazení dáte do samostatného plánu, oddělíte je od produkční verze.

Oddělte webové aplikace od webových rozhraní API. Pokud má vaše řešení webový front-end i webové rozhraní API, zvažte jejich oddělení do samostatných App Service aplikací. Tento návrh usnadňuje rozložit řešení podle úloh. Webovou aplikaci a rozhraní API můžete spustit v samostatných plánech App Service, aby je bylo možné škálovat nezávisle. Pokud na první úroveň škálovatelnosti nepotřebujete, můžete aplikace nasadit do stejného plánu a v případě potřeby je později přesunout do samostatných plánů.

Vyhněte se App Service zálohování databází Azure SQL zálohování. Místo toho použijte SQL Database automatizované zálohy. App Service zálohování exportuje databázi do SQL BACPAC, což stojí DTU.

Nasazení do pracovního slotu Vytvořte slot nasazení pro pracovní nasazení. Nasaďte aktualizace aplikace do pracovního slotu a před prohozením nasazení do produkčního prostředí ověřte nasazení. Tím se snižuje riziko chybná aktualizace v produkčním prostředí. Zajišťuje také, že se všechny instance před prohodí do produkčního prostředí zahřeje. Mnoho aplikací má významný čas zahřejení a studeného startu. Další informace najdete v tématu Nastavení pracovních prostředí pro webové aplikace v Azure App Service.

Vytvořte slot nasazení pro poslední známé dobré nasazení (LKG). Když nasadíte aktualizaci do produkčního prostředí, přesuňte předchozí produkční nasazení do slotu LKG. To usnadňuje vrácení špatného nasazení zpět. Pokud později zjistíte problém, můžete se rychle vrátit k verzi LKG. Další informace najdete v tématu Základní webová aplikace.

Povolte protokolování diagnostiky, včetně protokolování aplikace a protokolování webového serveru. Protokolování je důležité pro monitorování a diagnostiku. Viz Povolení protokolování diagnostiky pro webové aplikace v Azure App Service

Přihlaste se do úložiště objektů blob. To usnadňuje shromažďování a analýzu dat.

Vytvořte samostatný účet úložiště pro protokoly. Nepoužívejte stejný účet úložiště pro protokoly a data aplikací. To pomáhá zabránit protokolování ve snížení výkonu aplikace.

Monitorujte výkon. Pomocí služby sledování výkonu, jako je New Relic nebo Přehledy monitorování výkonu a chování aplikací při zatížení. Monitorování výkonu poskytuje přehled o aplikaci v reálném čase. Umožňuje diagnostikovat problémy a provádět analýzu hlavní příčiny selhání.

Azure Load Balancer

Vyberte SKU Standard. Standard Load Balancer poskytuje dimenzi spolehlivosti, kterou Basic nepodporuje – zón dostupnosti a odolnosti zón. To znamená, že když dojde k vypnutí zóny, vaše zónově redundantní Standard Load Balancer to nebude mít vliv. Tím se zajistí, že vaše nasazení odolá selháním zón v rámci oblasti. Kromě toho Standard Load Balancer globální vyrovnávání zatížení, což zajišťuje, že selhání oblasti nesnídá vaši aplikaci.

Zřízení alespoň dvou instancí Nasaďte Azure LB s alespoň dvěma instancemi v back-endu. Jedna instance může vést k jedinému bodu selhání. Pokud chcete nástroj pro škálování sestavit, můžete chtít nástroj pro lb spárovat s Virtual Machine Scale Sets.

Použití odchozích pravidel Odchozí pravidla zajišťují, že v důsledku vyčerpání portů SNAT nečelíte selháním připojení. Přečtěte si další informace o odchozím připojení. I když odchozí pravidla pomůžou vylepšit řešení pro nasazení malé až střední velikosti, pro produkční úlohy doporučujeme párovat Standard Load Balancer nebo jakékoli nasazení podsítě s VNet NAT.

Application Gateway

Zř aspoň dvě instance. Nasaďte Application Gateway alespoň se dvěma instancemi. Jedna instance je jediným bodem selhání. Použijte dvě nebo více instancí pro redundanci a škálovatelnost. Abyste mohli mít nárok na sla,musíte zřídit dvě nebo více středních nebo větších instancí.

Cosmos DB

Replikovat databázi napříč oblastmi Cosmos Databáze umožňuje přidružit libovolný počet oblastí Azure k účtu databáze Cosmos DB. Databáze Cosmos DB může mít jednu oblast zápisu a několik oblastí čtení. Pokud dojde k selhání v oblasti zápisu, můžete číst z jiné repliky. Klientská sada SDK to zpracuje automaticky. Oblast zápisu můžete také při selhání přepadnout do jiné oblasti. Další informace najdete v tématu Globální distribuce dat pomocí služby Azure Cosmos DB.

Event Hubs

Použijte kontrolní body. Příjemce události by měl v některém předdefinovaném intervalu zapsat svoji aktuální pozici do trvalého úložiště. Pokud tak u příjemce dojde k chybě (například dojde k chybě příjemce nebo hostitel selže), může nová instance pokračovat ve čtení datového proudu z poslední zaznamenané pozice. Další informace najdete v tématu Spotřebiteli událostí.

Zpracování duplicitních zpráv Pokud příjemce události selže, zpracování zpráv se obnoví od posledního zaznamenaného kontrolního bodu. Všechny zprávy, které byly již zpracovány po posledním kontrolním bodu, budou znovu zpracovány. Logika zpracování zpráv proto musí být idempotentní nebo aplikace musí být schopná zprávy zduřet.

Zpracování výjimek.. Příjemce událostí obvykle zpracovává dávku zpráv ve smyčce. V této smyčce zpracování byste měli zpracovávat výjimky, abyste se vyhnuli ztrátě celé dávky zpráv, pokud jedna zpráva způsobí výjimku.

Použijte frontu pro doručení zpráv. Pokud zpracování zprávy vede k neúspěchu přenosu, umístěte zprávu do fronty nedoručených zpráv, abyste mohli sledovat stav. V závislosti na scénáři můžete zprávu zopakovat později, použít kompenzační transakci nebo provést nějakou jinou akci. Upozorňujeme, Event Hubs neobsahuje žádné integrované funkce fronty zpráv. Frontu fronty Azure můžete Storage nebo Service Bus k implementaci fronty zpráv, případně můžete použít Azure Functions nebo nějaký jiný mechanismus událostí.

Implementujte zotavení po havárii tak, že při selhání přenecháte služby sekundárnímu Event Hubs oboru názvů. Další informace najdete v Azure Event Hubs geografické zotavení po havárii.

Azure Cache for Redis

Nakonfigurujte geografickou replikaci. Geografická replikace poskytuje mechanismus pro propojení dvou instancí Premium vrstvou Azure Cache for Redis instancemi. Data zapisovaná do primární mezipaměti se replikují do sekundární mezipaměti jen pro čtení. Další informace najdete v tématu Konfigurace geografické replikace pro Azure Cache for Redis

Konfigurace trvalosti dat Trvalost Redis umožňuje zachovat data uložená v Redisu. Můžete také pořovat snímky a zálohovat data, která můžete načíst v případě selhání hardwaru. Další informace najdete v tématu Konfigurace trvalosti dat pro Premium vrstvu Azure Cache for Redis

Pokud používáte tuto Azure Cache for Redis jako dočasnou mezipaměť dat, a ne jako trvalé úložiště, tato doporučení se nemusí vztahovat.

Hledat

Zřídit více než jednu repliku. Pro vysokou dostupnost čtení používejte alespoň dvě repliky, nebo tři pro vysokou dostupnost čtení i zápisu.

Nakonfigurujte indexery pro nasazení ve více oblastech. Pokud máte nasazení ve více oblastech, zvažte možnosti kontinuity indexování.

• Pokud je zdroj dat geograficky replikovaný, obecně byste měli každý indexer každé regionální služby Azure Search na jeho místní repliku zdroje dat. Tento přístup se ale nedoporučuje u velkých datových sad uložených v 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, pouze z primárních replik. Místo toho nasažte všechny indexery na primární repliku. Po převzetí služeb při selhání nasažte indexery Služby Azure Search na novou primární repliku.

• Pokud zdroj dat není geograficky replikovaný, odkažte na více indexerů ve stejném zdroji dat, aby služby Azure Search ve více oblastech průběžně a nezávisle indexoval ze zdroje dat. Další informace najdete v tématu Důležité informace o výkonu a optimalizaci služby Azure Search.

Service Bus

Pro Premium použijte úroveň úložiště. Service Bus Premium Messaging poskytuje vyhrazené a vyhrazené výpočetní prostředky a kapacitu paměti pro podporu předvídatelného výkonu a propustnosti. Premium Úroveň zasílání zpráv také poskytuje přístup k novým funkcím, které jsou na první pohled dostupné pouze zákazníkům úrovně Premium. Počet jednotek zasílání zpráv můžete určit na základě očekávaných úloh.

Zpracování duplicitních zpráv. Pokud vydavatel selže ihned po odeslání zprávy nebo dojde k problémům se sítí nebo systémem, může se chybně podařit zaznamenat, že zpráva byla doručena, a může odeslat stejnou zprávu do systému dvakrát. Service Bus tento problém můžete vyřešit povolením vyhledávání duplicit. Další informace najdete v tématu Detekce duplicit.

Zpracování výjimek. Rozhraní API pro zasílání zpráv generují výjimky, když dojde k chybě uživatele, chybě konfigurace nebo jiné chybě. Kód klienta (odesílatelé a příjemci) by měli tyto výjimky zpracovávat ve svém kódu. To je obzvláště důležité při dávkovém zpracování, kdy lze zpracování výjimek použít, aby se zabránilo ztrátě celé dávky zpráv. Další informace najdete v tématu Service Bus zasílání zpráv.

Zásady opakování: Service Bus umožňuje vybrat nejlepší zásady opakování pro vaše aplikace. Výchozí zásadou je povolit maximálně 9 pokusů o opakování a počkat 30 sekund, ale můžete to dále upravit. Další informace najdete v tématu Zásady opakování – Service Bus.

Použijte frontu pro doručení zpráv. Pokud se zpráva po několika opakováních nemůže zpracovat ani doručit nějakému příjemci, přesune se do fronty zpráv o zablokování. Implementujte proces pro čtení zpráv z fronty zpráv, jejich kontrolu a nápravu problému. V závislosti na scénáři můžete zprávu opakovat tak, jak je, provést změny a opakovat ji nebo zprávu zahodit. Další informace najdete v tématu Přehled front Service Bus zpráv.

Použijte Geo-Disaster Recovery. Geografické zotavení po havárii zajišťuje, že zpracování dat bude i nadále fungovat v jiné oblasti nebo datacentru, pokud kvůli havárii přestane být dostupná celá oblast nebo datacentrum Azure. Další informace najdete v tématu Azure Service Bus geografické zotavení po havárii.

Storage

Pro data aplikací použijte geograficky redundantní úložiště jen pro čtení (RA-GRS). Úložiště RA-GRS replikuje data do sekundární oblasti a poskytuje přístup jen pro čtení ze sekundární oblasti. Pokud v primární oblasti dojde k výpadku úložiště, může aplikace číst data ze sekundární oblasti. Další informace najdete v tématu Azure Storage replikace.

Pro disky virtuálních počítačů použijte spravované disky. Spravované disky poskytují vyšší spolehlivost virtuálních počítačů ve skupině dostupnosti, protože disky jsou od sebe dostatečně izolované, aby se zabránilo vzniku jediného bodu selhání. Na spravované disky se také vztahují limity IOPS virtuálních pevných disků vytvořených v účtu úložiště. Další informace najdete v tématu Správa dostupnosti virtuálních Windows počítačů v Azure.

Pro Queue Storage vytvořte frontu zálohování v jiné oblasti. Pro Queue Storage má replika jen pro čtení omezené využití, protože položky nemůžete zařadit do fronty ani je z fronty vyřadit. Místo toho vytvořte frontu zálohování v účtu úložiště v jiné oblasti. Pokud dojde k výpadku úložiště, může aplikace použít frontu zálohování, dokud nebude primární oblast opět dostupná. Tímto způsobem může aplikace stále zpracovávat nové požadavky.

SQL Database

Použijte úroveň Standard nebo Premium. Tyto úrovně poskytují delší období obnovení k bodu v čase (35 dnů). Další informace najdete v tématu SQL Database a výkonu.

Povolte SQL Database auditování. Auditování lze použít k diagnostice škodlivých útoků nebo lidských chyb. Další informace najdete v tématu Začínáme s auditem SQL databáze.

Použití aktivní geografické replikace Active Geo-Replication k vytvoření čitelné sekundární oblasti v jiné oblasti. Pokud vaše primární databáze selže nebo je potřeba ji jednoduše pře offline, proveďte ruční převzetí služeb při selhání sekundární databází. Dokud neprovedete převzetí služeb při selhání, sekundární databáze zůstane jen pro čtení. Další informace najdete v tématu SQL Database aktivní geografické replikace.

Použití horizontálního dělení Zvažte horizontální dělení databáze na oddíly. Shardování může zajistit izolaci chyb. Další informace najdete v tématu Horizontální navýšení kapacity pomocí Azure SQL Database.

Obnovení k bodu v čase použijte k zotavení z lidské chyby. Obnovení k bodu v čase vrátí vaši databázi k dřívějšímu bodu v čase. Další informace najdete v tématu Obnovení databáze Azure SQL pomocí automatizovaných záloh databáze.

K zotavení z výpadku služby použijte geografické obnovení. Geografické obnovení obnoví databázi z geograficky redundantní zálohy. Další informace najdete v tématu Obnovení databáze Azure SQL pomocí automatizovaných záloh databáze.

Azure Synapse Analytics

Nezakažte geografické zálohování. Ve výchozím Synapse Analytics zálohování dat každých 24 hodin pro zotavení po havárii. Tuto funkci nedoporučujeme vypnout. Další informace najdete v tématu Geografické zálohy.

SQL Server spuštěný ve virtuálním počítači

Replikovat databázi. K SQL Server databáze použijte skupiny dostupnosti Always On. Poskytuje vysokou dostupnost, pokud SQL Server instance selže. Další informace najdete v tématu Windows virtuálních počítače pro n-vrstvou aplikaci.

Zálohujte databázi. Pokud již k zálohování virtuálních Azure Backup používáte nástroj , zvažte použití Azure Backup pro úlohy SQL Server pomocí DPM. S tímto přístupem je pro organizaci k dispozici jedna role správce zálohování a jednotný postup obnovení pro virtuální počítače a SQL Server. V opačném případě SQL Server spravované zálohování Microsoft Azure.

Traffic Manager

Proveďte ruční navrácení služeb po obnovení. 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í. Před navrácením služeb po obnovení ověřte, zda jsou všechny subsystémy aplikace v dobrém stavu. 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. Další informace najdete v tématu spuštění virtuálních počítačů v několika oblastech pro zajištění vysoké dostupnosti.

Vytvořte koncový bod sondy stavu. Vytvořte vlastní koncový bod, který sestaví celkový stav aplikace. 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. Koncový bod by měl vracet kód chyby HTTP, pokud je některá kritická závislost poškozená nebo nedosažitelná. Nevytvářejte zprávy o chybách pro nekritické služby, ale 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. další informace najdete v tématu Traffic Manager monitorování koncového bodu a převzetí služeb při selhání.

Virtual Machines

Nepoužívejte provozní zatížení na jednom virtuálním počítači. Nasazení jediného virtuálního počítače není odolné vůči plánované nebo neplánované údržbě. 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.

Při zřizování virtuálního počítače zadejte skupinu dostupnosti. 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. 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í. 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.

Každou aplikační vrstvu umístěte do samostatné skupiny dostupnosti. V N-vrstvé aplikaci neumísťujte virtuální počítače z různých vrstev do stejné skupiny dostupnosti. 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). 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ů.

Replikace virtuálních počítačů pomocí 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ě. Body obnovení jsou vytvářeny každých několik minut. To vám umožní určit cíl bodu obnovení (RPO) v řádu minut. 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. Další informace najdete v tématu spuštění postupu zotavení po havárii do Azure.

Vyberte správnou velikost virtuálního počítače na základě požadavků na výkon. 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. 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. To pomáhá zajistit, aby se aplikace v cloudovém prostředí chovala jako očekávaná. Pokud potřebujete více síťových rozhraní, uvědomte si také omezení počtu síťových adaptérů pro jednotlivé velikosti.

Použijte spravované disky pro virtuální pevné disky. 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í. Spravované disky navíc nepodléhají limitům virtuálních pevných disků, které jsou vytvořeny v účtu úložiště. další informace najdete v tématu správa dostupnosti Windows virtuálních počítačů v Azure.

Nainstalujte aplikace na datový disk, nikoli na disk s operačním systémem. V opačném případě se může dosáhnout limitu velikosti disku.

K zálohování virtuálních počítačů použijte Azure Backup. Zálohy chrání před náhodnou ztrátou dat. Další informace najdete v tématu ochrana virtuálních počítačů Azure pomocí trezoru Recovery Services.

Povolte diagnostické protokoly. Zahrnuje základní metriky stavu, protokoly infrastruktury a diagnostiku spouštění. 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. Další informace najdete v tématu Přehled diagnostických protokolů Azure.

Nakonfigurujte 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.

Virtual Network

Pokud chcete zakázat nebo zablokovat veřejné IP adresy, přidejte do podsítě skupinu zabezpečení sítě. 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.

Vytvořte vlastní sondu stavu. Sondy stavu Load Balancer můžou testovat protokol HTTP nebo TCP. Pokud virtuální počítač spustí server HTTP, test HTTP je lepším indikátorem stavu než test TCP. U testu HTTP použijte vlastní koncový bod, který oznamuje celkový stav aplikace včetně všech kritických závislostí. další informace najdete v tématu přehled Azure Load Balancer.

Neblokujte sondu stavu. Sonda stavu Load Balancer se odesílá ze známé IP adresy, 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ě. Blokování sondy stavu způsobí, že nástroj pro vyrovnávání zatížení odebere virtuální počítač z rotace.

Povolte protokolování Load Balancer. 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. Další informace najdete v tématu Log Analytics pro Azure Load Balancer.