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é je nutné vzít v úvahu při navrhování a implementaci aplikace. Pomocí tohoto kontrolního seznamu se můžete podívat na požadavky na odolnost 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í přípravné sloty a automatizované zálohy. další informace najdete v tématu podrobný přehled plánů Azure App Service .

Vyhněte se škálování směrem nahoru nebo dolů. 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ů. Horizontální navýšení nebo snížení kapacity může aktivovat restart aplikace.

Konfigurace úložiště jako nastavení aplikace Nastavení aplikace můžete použít k uložení nastavení konfigurace jako nastavení aplikace. definujte nastavení v šablonách Resource Manager nebo pomocí powershellu, abyste je mohli použít jako součást procesu automatizovaného nasazení nebo aktualizace, který je spolehlivější. Další informace najdete v tématu Konfigurace webových aplikací v Azure App Service.

vytvořte samostatné plány App Service pro produkci a testování. Pro účely testování nepoužívejte sloty pro nasazení v produkčním prostředí. všechny aplikace v rámci stejného App Service plánu sdílejí stejné instance virtuálních počítačů. Pokud zadáte produkční a testovací nasazení ve stejném plánu, může negativně ovlivnit produkční nasazení. Například zátěžové testy mohou snižovat provozní pracoviště za provozu. Nasazením testů do samostatného plánu je izolujete z 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 vyvýšení na samostatné aplikace App Service. Tento návrh usnadňuje rozložit řešení podle zatížení. webovou aplikaci a rozhraní API můžete spustit v samostatných plánech App Service, takže je můžete škálovat nezávisle. 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.

nepoužívejte funkci App Service backup k zálohování databází Azure SQL. místo toho použijte SQL Database automatizované zálohy. App Service backup exportuje databázi do souboru SQL BACPAC, který vám dtu náklady.

Nasaďte do přípravného slotu. Vytvořte slot nasazení pro přípravu. 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í. Tím se sníží pravděpodobnost špatné aktualizace v produkčním prostředí. Také zajišťuje, aby všechny instance byly před přepnutím do produkčního prostředí zahřívání. Mnoho aplikací má značný zahřívání a studený čas spuštění. Další informace najdete v tématu Nastavení přípravného prostředí pro webové aplikace v Azure App Service.

Vytvořte slot nasazení pro uložení posledního známého nasazení (LKG). Když nasadíte aktualizaci do produkčního prostředí, přesunete předchozí provozní nasazení do slotu LKG. Díky tomu je snazší vrátit chybné nasazení. Pokud zjistíte problém později, 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í aplikací 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í v omezení výkonu aplikace.

Monitorujte výkon. 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 . Sledování výkonu vám poskytne přehled o aplikaci v reálném čase. Umožňuje diagnostikovat problémy a provádět analýzy chyb v původní příčině.

Azure Load Balancer

vyberte možnost standardní SKU Standard Load Balancer poskytuje rozměrovou spolehlivost, kterou základní nezahrnuje zóny dostupnosti a odolnost zóny. to znamená, že když dojde k výpadku zóny, nebude to mít vliv na Standard Load Balancer redundantní v zóně. Díky tomu můžou vaše nasazení vyodolat selhání zóny v rámci oblasti. kromě toho Standard Load Balancer podporuje globální vyrovnávání zatížení, aby vaše aplikace neovlivnila selhání oblasti.

Zřídit aspoň dvě instance Nasaďte Azure z více než dvou instancí do back-endu. Jedna instance může mít za následek selhání v jednom bodě. Aby bylo možné sestavovat škálování, můžete chtít párovat 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. Přečtěte si další informace o odchozím připojení. 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ě.

Application Gateway

Zřiďte aspoň dvě instance. nasaďte Application Gateway s alespoň dvěma instancemi. Jediná instance je jediným bodem selhání. Pro zajištění redundance a škálovatelnosti použijte dvě nebo víc instancí. 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í.

Cosmos DB

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

Event Hubs

Používejte kontrolní body. 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. 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. Další informace najdete v tématu příjemci událostí.

Zpracování duplicitních zpráv. Pokud příjemce události neprojde, zpracování zprávy se obnoví z posledního zaznamenaného kontrolního bodu. Všechny zprávy, které byly již zpracovány po posledním kontrolním bodu, budou zpracovány znovu. Proto musí být logika zpracování zpráv idempotentní nebo aplikace musí být schopna odstranit duplicitní zprávy.

Zpracovat výjimky... Spotřebitel události obvykle zpracovává dávku zpráv ve smyčce. 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.

Použijte frontu nedoručených zpráv. 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. 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. Všimněte si, že Event Hubs nemá žádnou integrovanou funkci fronty nedoručených zpráv. 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.

Implementace zotavení po havárii převzetím služeb při selhání sekundárním oborem názvů Event Hubs. další informace najdete v tématu Azure Event Hubsho geografického zotavení po havárii.

Azure Cache for Redis

Nakonfigurujte geografickou replikaci. geografická replikace poskytuje mechanismus pro propojení dvou instancí Azure Cache for Redis Premium vrstvy. Data zapsaná 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 .

Nakonfigurujte Trvalost dat. Redis Persistence umožňuje zachovat data uložená v Redis. Můžete také pořizovat snímky a zálohovat data, která můžete načíst v případě selhání hardwaru. další informace najdete v tématu jak nakonfigurovat trvalost dat pro Premiumovou vrstvu Azure Cache for Redis

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

Zřídit více než jednu repliku. Pro vysokou dostupnost pro čtení i zápis použijte aspoň dvě repliky pro čtení s vysokou dostupností nebo tři.

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ý, měli byste obecně nasměrovat každý indexer každé místní služby Azure Search na svou místní repliku zdroje dat. Tento přístup se ale nedoporučuje u rozsáhlý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, jenom z primární repliky. Místo toho nasměrujte všechny indexery na primární repliku. Po převzetí služeb při selhání ukažte Azure Search indexery na novou primární repliku.

  • 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. Další informace najdete v tématu Azure Search posouzení výkonu a optimalizace.

Service Bus

pro produkční úlohy použijte vrstvu Premium. Service Bus Premium zasílání zpráv 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. Premium vrstva zasílání zpráv vám taky umožní přístup k novým funkcím, které jsou k dispozici jenom zákazníkům ve verzi Premium. Počet jednotek zasílání zpráv můžete určit na základě očekávaných zatížení.

Zpracování duplicitních zpráv. 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. Service Bus může tento problém vyřešit tím, že povolí detekci duplicit. Další informace najdete v tématu zjištění duplicit.

Zpracování výjimek. Rozhraní API pro zasílání zpráv generují výjimky, pokud dojde k chybě uživatele, konfigurační chybě nebo k jiné chybě. Kód klienta (odesílatelé a přijímače) by měl tyto výjimky zpracovat ve svém kódu. 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. další informace najdete v tématu Service Bus výjimky zasílání zpráv.

Zásady opakování. Service Bus umožňuje vybrat pro vaše aplikace osvědčené zásady opakování. 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. Další informace najdete v tématu zásady opakování – Service Bus.

Použijte frontu nedoručených zpráv. 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. Implementujte proces pro čtení zpráv z fronty nedoručených zpráv, zkontrolujte je a opravte problém. 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. další informace najdete v tématu přehled Service Bus front nedoručených zpráv.

Použijte obnovení Geo-Disaster. 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. další informace najdete v tématu Azure Service Busho geografického zotavení po havárii.

Storage

Pro data aplikací použijte geograficky redundantní úložiště s přístupem 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ě, aplikace může číst data ze sekundární oblasti. další informace najdete v tématu replikace Azure Storage.

Pro disky virtuálních počítačů použijte spravované 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.

Ve frontě úložiště vytvořte frontu zálohování v jiné oblasti. 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. 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í region znovu dostupný. Aplikace tak může nadále zpracovávat nové požadavky.

SQL Database

použijte úroveň Standard nebo Premium. Tyto úrovně poskytují delší dobu obnovení k určitému bodu v čase (35 dní). další informace najdete v tématu SQL Database možnosti a výkon.

povolte auditování SQL Database. Auditování se dá použít k diagnostice škodlivých útoků nebo lidské chyby. další informace najdete v tématu Začínáme s SQL auditování databáze.

Použít aktivní geografickou replikaci Pomocí aktivní Geo-Replication můžete v jiné oblasti vytvořit čitelný sekundární objekt. 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í. Dokud převezmete služby 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žijte horizontálního dělení. Zvažte použití horizontálního dělení pro horizontální rozdělení databáze. Horizontálního dělení 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 obnovení z lidské chyby. Obnovení k bodu v čase vrátí databázi k dřívějšímu bodu v čase. další informace najdete v tématu obnovení databáze Azure SQL pomocí automatických záloh databáze.

Pro obnovení 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í automatických záloh databáze.

Azure Synapse Analytics

Nepovolujte geografickou zálohu. 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. Tato funkce se nedoporučuje vypnout. Další informace najdete v tématu geografická zálohování.

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

Replikujte databázi. k replikaci databáze použijte SQL Server skupiny dostupnosti Always On. poskytuje vysokou dostupnost, pokud se jedna instance SQL Server nezdařila. další informace najdete v tématu spuštění Windows virtuálních počítačů pro N-vrstvou aplikaci .

Zazálohujte databázi. 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. 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. jinak použijte SQL Server spravované zálohování pro 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.