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

  • Článek

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é zvážit při návrhu a implementaci aplikace. Pomocí tohoto kontrolního seznamu zkontrolujte aspekty odolnosti konkrétních služeb Azure. Další informace o návrhu 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 podrobném přehledu plánů služby Aplikace Azure

Vyhněte se vertikálnímu navýšení nebo snížení kapacity. Místo toho vyberte úroveň a velikost instance, která splňuje vaše požadavky na výkon v rámci typického zatížení, a pak škálujte instance tak, aby zpracovávaly změny objemu přenosů. Vertikální navýšení a snížení kapacity může aktivovat restartování aplikace.

Uložte konfiguraci jako nastavení aplikace. Nastavení aplikace slouží k uložení nastavení konfigurace jako nastavení aplikace. Definujte nastavení v šablonách Resource Manageru 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í ve službě Aplikace Azure Service.

Vytvořte samostatné plány služby App Service pro produkční a testovací prostředí. Pro testování nepoužívejte sloty v produkčním nasazení. Všechny aplikace v rámci stejného plánu služby App Service sdílejí stejné instance virtuálních počítačů. Pokud nasadíte produkční a testovací nasazení do stejného plánu, může negativně ovlivnit produkční nasazení. Zátěžové testy můžou například snížit výkon živého produkčního webu. Umístěním testovacích nasazení do samostatného plánu je izolujete 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 rozdělení do samostatných aplikací App Service. Tento návrh usnadňuje dekompilování řešení podle úloh. Webovou aplikaci a rozhraní API můžete spustit v samostatných plánech služby App Service, aby se mohly škálovat nezávisle. Pokud tuto ú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ů.

Nasaďte zónově redundantní plány služby App Service. V podporovaných oblastech je možné plány služby App Service nasadit jako zónově redundantní, což znamená, že instance se automaticky distribuují napříč zónami dostupnosti. App Service automaticky distribuuje provoz mezi zóny a zpracovává převzetí služeb při selhání, pokud dojde k výpadku zóny. Další informace najdete v tématu Migrace služby App Service do podpory zóny dostupnosti.

Nepoužívejte funkci zálohování služby App Service k zálohování databází Azure SQL. Místo toho použijte automatizované zálohování služby SQL Database. Zálohování služby App Service exportuje databázi do souboru SQL BACPAC, který stojí DTU.

Proveďte nasazení do přípravného slotu. Vytvořte slot nasazení pro přípravu. Nasaďte aktualizace aplikace do přípravného slotu a před prohozením nasazení do produkčního prostředí ověřte nasazení. To snižuje riziko špatné aktualizace v produkčním prostředí. Také zajišťuje, že se všechny instance před prohozením do produkčního prostředí zahřejí. Mnoho aplikací má významný čas zahřátí a studeného startu. Další informace najdete v tématu Nastavení přípravných prostředí pro webové aplikace ve službě Aplikace Azure 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řesuňte předchozí produkční nasazení do slotu LKG. To usnadňuje vrácení chybného nasazení. Pokud později zjistíte problém, můžete se rychle vrátit k verzi LKG. Další informace naleznete 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 ve službě Aplikace Azure Service

Přihlaste se k úložišti 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í při zatížení použijte službu monitorování výkonu, jako je New Relic nebo Application Přehledy. 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 původní příčiny selhání.

Azure Load Balancer

Vyberte skladovou položku Standard. Load Balancer úrovně Standard poskytuje dimenzi spolehlivosti, kterou Basic nepodporuje – zóny dostupnosti a odolnost zón. To znamená, že když dojde k výpadku zóny, nebude to mít vliv na zónově redundantní Load Balancer úrovně Standard. Tím zajistíte, že vaše nasazení můžou odolat selhání zón v rámci oblasti. Kromě toho Load Balancer úrovně Standard podporuje globální vyrovnávání zatížení, které zajišťuje, že vaše aplikace nebude mít vliv ani na selhání oblastí.

Zřiďte aspoň dvě instance. 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 vytvořit škálování, možná budete chtít spárovat nástroj pro vyrovnávání zatížení se škálovacími sadami virtuálních počítačů.

Použijte pravidla odchozích přenosů. Odchozí pravidla zajišťují, že v důsledku vyčerpání portů SNAT nebudete čelit selháním připojení. Přečtěte si další informace o odchozím připojení. I když odchozí pravidla pomáhají zlepšit řešení pro nasazení malých až středních velikostí, pro produkční úlohy doporučujeme spárovat Standard Load Balancer nebo jakékoli nasazení podsítě s překladem adres virtuální sítě.

Application Gateway

Zřiďte aspoň dvě instance. Nasaďte službu Application Gateway s alespoň dvěma instancemi. Jedna instance je kritickým bodem selhání. Pro redundanci a škálovatelnost použijte dvě nebo více instancí. Pokud chcete získat nárok na smlouvu SLA, musíte zřídit dvě nebo více středně velkých nebo větších instancí.

Azure Cosmos DB

Nakonfigurujte zónovou redundanci. Když používáte redundanci zón, Azure Cosmos DB synchronně replikuje všechny zápisy napříč zónami dostupnosti. V případě výpadku zóny automaticky převezme služby při selhání. Další informace najdete v tématu Dosažení vysoké dostupnosti se službou Azure Cosmos DB.

Replikujte databázi napříč oblastmi. Azure Cosmos DB umožňuje přidružit libovolný počet oblastí Azure k databázovému účtu služby Azure Cosmos DB. Databáze Azure Cosmos DB může mít jednu oblast zápisu a více oblastí čtení. Pokud dojde k selhání v oblasti zápisu, můžete číst z jiné repliky. Klientská sada SDK to zpracovává 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álostí by měl zapsat aktuální pozici do trvalého úložiště v určitém předdefinovaném intervalu. Pokud dojde k chybě příjemce (například dojde k chybě příjemce nebo hostitel selže), může nová instance obnovit č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álostí selže, zpracování zpráv se obnoví z posledního zaznamenaného kontrolního bodu. Všechny zprávy, které už byly zpracovány po posledním kontrolním bodu, budou znovu zpracovány. Proto musí být logika zpracování zpráv idempotentní nebo aplikace musí být schopná odstranit duplicitní zprávy.

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

Použijte frontu nedoručených zpráv. Pokud zpracování zprávy způsobí nepřerušované selhání, vlož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. Služba Event Hubs nemá žádnou integrovanou funkci fronty nedoručených zpráv. Službu Azure Queue Storage nebo Service Bus můžete použít k implementaci fronty nedoručených zpráv nebo použití azure Functions nebo jiného mechanismu událostí.

Nakonfigurujte zónovou redundanci. Pokud je v oboru názvů povolená redundance zóny, služba Event Hubs automaticky replikuje změny mezi několika zónami dostupnosti. Pokud jedna zóna dostupnosti selže, převzetí služeb při selhání proběhne automaticky. Další informace najdete v tématu Zóny dostupnosti.

Implementujte zotavení po havárii převzetím služeb při selhání do sekundárního oboru názvů služby Event Hubs. Další informace najdete v tématu Geografické zotavení po havárii služby Azure Event Hubs.

Azure Cache for Redis

Nakonfigurujte zónovou redundanci. Pokud je v mezipaměti povolená redundance zón, Azure Cache for Redis rozloží virtuální počítače, které hostují vaši mezipaměť napříč několika zónami dostupnosti. Redundance zón poskytuje vysokou dostupnost a odolnost proti chybám v případě výpadku datového centra. Další informace najdete v tématu Povolení redundance zón pro Azure Cache for Redis.

Konfigurace geografické replikace Geografická replikace poskytuje mechanismus pro propojení dvou instancí Azure Cache for Redis na úrovni Premium. 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.

Konfigurace trvalosti dat Trvalost Redis umožňuje trvalé uchování dat uložených v Redis. Můžete také pořídit 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 Azure Cache for Redis úrovně Premium.

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

Zřízení více než jedné repliky Pro vysokou dostupnost čtení použijte aspoň dvě repliky nebo tři pro vysokou dostupnost pro čtení i zápis.

Použijte redundanci zón. Repliky kognitivního vyhledávání můžete nasadit napříč několika zónami dostupnosti. Tento přístup pomáhá vaší službě zůstat funkční i v případě výpadků datového centra. Další informace najdete v tématu Spolehlivost ve službě Azure Cognitive Search.

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

  • Pokud je zdroj dat geograficky replikovaný, měli byste obecně nasměrovat každý indexer jednotlivých regionálních služeb Azure Cognitive Search na jeho místní repliku zdroje dat. Tento přístup se ale nedoporučuje pro velké datové sady uložené ve službě Azure SQL Database. Důvodem je, že Služba Azure Cognitive Search nemůže provádět přírůstkové indexování ze sekundárních replik služby SQL Database, pouze z primárních replik. Místo toho nasměrujte všechny indexery na primární repliku. Po převzetí služeb při selhání nasměrujte indexery služby Azure Cognitive Search na novou primární repliku.

  • Pokud zdroj dat není geograficky replikovaný, nasměrujte více indexerů na stejný zdroj dat, aby služba Azure Cognitive Search ve více oblastech nepřetržitě a nezávisle indexovala 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 produkční úlohy použijte úroveň Premium. Zasílání zpráv Service Bus Premium poskytuje vyhrazené a rezervované prostředky pro zpracování a kapacitu paměti, aby podporovala předvídatelný výkon a propustnost. Úroveň Zasílání zpráv úrovně Premium také poskytuje přístup k novým funkcím, které jsou k dispozici pouze zákazníkům úrovně Premium. Na základě očekávaných úloh můžete určit počet jednotek zasílání zpráv.

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

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

Zásady opakování Service Bus umožňuje vybrat nejlepší zásady opakování pro vaše aplikace. Výchozí zásadou je povolení 9 maximálních pokusů o opakování a čekání na 30 sekund, ale to je možné dále upravit. 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 příjemci po několika opakovaných opakováních, přesune se do fronty nedoručených zpráv. Implementujte proces čtení zpráv z fronty nedoručených zpráv, prozkoumejte je a opravte problém. V závislosti na scénáři můžete zprávu opakovat tak, jak je, provádět změny a opakovat nebo zprávu zahodit. Další informace najdete v tématu Přehled front nedoručených zpráv služby Service Bus.

Použijte redundanci zón. Pokud je v oboru názvů povolená redundance zóny, Service Bus automaticky replikuje změny mezi několika zónami dostupnosti. Pokud jedna zóna dostupnosti selže, převzetí služeb při selhání proběhne automaticky. Další informace najdete v tématu Osvědčené postupy pro izolaci aplikací před výpadky a haváriemi služby Service Bus.

Použijte geografické zotavení po havárii. Geografické zotavení po havárii zajišťuje, že zpracování dat bude dál 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 Geografické zotavení po havárii služby Azure Service Bus.

Úložiště

Použijte zónově redundantní úložiště. Zónově redundantní úložiště (ZRS) kopíruje data synchronně napříč třemi zónami dostupnosti Azure v primární oblasti. Pokud dojde k výpadku zóny dostupnosti, Azure Storage automaticky převezme služby při selhání do alternativní zóny. Další informace najdete v článku Možnosti redundance Azure Storage.

Při použití geografické redundance nakonfigurujte přístup pro čtení. Pokud používáte architekturu s více oblastmi, použijte vhodnou úroveň úložiště pro globální redundanci. Při použití RA-GRS nebo RA-GZRS se vaše data replikují do sekundární oblasti. RA-GRS používá místně redundantní úložiště (LRS) v primární oblasti, zatímco RA-GZRS používá zónově redundantní úložiště (ZRS) v primární oblasti. Obě konfigurace poskytují přístup k datům jen pro čtení v sekundární oblasti. Pokud dojde k výpadku úložiště v primární oblasti, může aplikace číst data ze sekundární oblasti, pokud jste ji pro tuto možnost navrhli. Další informace najdete v článku Možnosti redundance Azure Storage.

Pro disky virtuálních počítačů použijte spravované disky.Spravované disky poskytují lepší spolehlivost virtuálních počítačů ve skupině dostupnosti, protože disky jsou dostatečně izolované od sebe, aby se zabránilo kritickým bodům selhání. Spravované disky se také nevztahují na 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 počítačů s Windows v Azure.

Pro Queue Storage vytvořte záložní frontu v jiné oblasti. Ve službě Queue Storage má replika jen pro čtení omezené použití, protože nemůžete zařadit položky do fronty ani zrušit jejich frontu. Místo toho vytvořte frontu zálohování v účtu úložiště v jiné oblasti. Pokud dojde k výpadku služby Azure Storage, může aplikace použít frontu zálohování, dokud primární oblast nebude znovu dostupná. Aplikace tak může během výpadku dál zpracovávat nové žádosti.

Databáze SQL

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

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

Pomocí aktivní geografické replikace použijte aktivní geografickou replikaci k vytvoření čitelné sekundární oblasti v jiné oblasti. Pokud primární databáze selže nebo je potřeba ji jednoduše převést do offline režimu, proveďte ruční převzetí služeb při selhání sekundární databázi. 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 Aktivní geografická replikace služby SQL Database.

Používejte horizontální dělení. Zvažte horizontální dělení databáze pomocí horizontálního dělení. Horizontální dělení může poskytovat izolaci chyb. Další informace najdete v tématu Horizontální navýšení kapacity ve službě Azure SQL Database.

Obnovení k určitému bodu v čase použijte k zotavení z lidské chyby. Obnovení k určitému 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ází.

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

Azure Synapse Analytics

Nezakažujte geografické zálohování. Služba Synapse Analytics ve výchozím nastavení každých 24 hodin provádí úplné zálohování dat ve vyhrazeném fondu SQL, aby se zotavení po havárii. Tuto funkci nedoporučujeme vypnout. Další informace najdete v tématu Geografické zálohy.

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

Zálohujte databázi. Pokud už k zálohování virtuálních počítačů používáte Azure Backup , zvažte použití služby Azure Backup pro úlohy SQL Serveru 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 Managed Backup do Microsoft Azure.

Traffic Manager

Proveďte ruční navrácení služeb po obnovení. Po převzetí služeb při selhání Traffic Manageru proveďte ruční navrácení služeb po obnovení místo automatického navrácení služeb po obnovení. Před navrácením služeb po obnovení ověřte, že jsou všechny subsystémy aplikací v pořádku. Jinak můžete vytvořit situaci, kdy se aplikace překlopí mezi datacentry a zpět. Další informace najdete v tématu Spouš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ý hlásí celkový stav aplikace. To umožňuje službě Traffic Manager převzít služby při selhání, pokud selže nějaká kritická cesta, nejen front-end. Koncový bod by měl vrátit kód chyby HTTP, pokud nějaká kritická závislost není v pořádku nebo je nedostupná. Neoznamujte ale chyby pro nekritické služby. 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řit falešně pozitivní výsledky. Další informace najdete v tématu Monitorování koncových bodů Traffic Manageru a převzetí služeb při selhání.

Virtual Machines

Vyhněte se spouštění produkčních úloh na jednom virtuálním počítači. Jedno nasazení virtuálního počítače není odolné vůči plánované nebo neplánované údržbě. Místo toho umístěte několik virtuálních počítačů do skupiny dostupnosti nebo škálovací sady virtuálních počítačů s nástrojem pro vyrovnávání zatížení.

Při zřizování virtuálního počítače zadejte sadu 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ž do existující skupiny dostupnosti přidáte nový virtuální počítač, nezapomeňte pro virtuální počítač vytvořit síťovou kartu a přidat síťové rozhraní do back-endového fondu adres v nástroji pro vyrovnávání zatížení. Jinak nástroj pro vyrovnávání zatížení nebude směrovat síťový provoz na tento virtuální počítač.

Každou aplikační vrstvu umístěte do samostatné skupiny dostupnosti. V N-vrstvé aplikaci neumisť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í (FD) a aktualizačními doménami (UD). Pokud ale chcete získat výhodu redundance FD a UD, musí bý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 Recovery se všechny disky virtuálních počítačů průběžně replikují do cílové oblasti asynchronně. Body obnovení se vytvoří každých několik minut. Tím získáte cíl bodu obnovení (RPO) v pořadí minut. Postupy zotavení po havárii můžete provádět tolikrát, kolikrát chcete, aniž by to mělo vliv na produkční aplikaci nebo probíhající replikaci. Další informace najdete v tématu Spuštění postupu zotavení po havárii do Azure.

Na základě požadavků na výkon zvolte správnou velikost virtuálního počítače. Při přesunu existující úlohy do Azure začněte velikostí virtuálního počítače, která je nejblíže vašim místním serverům. Pak změřte výkon skutečné úlohy s ohledem na počet IOPS procesoru, paměti a disku a v případě potřeby upravte velikost. To pomáhá zajistit, aby se aplikace v cloudovém prostředí chovala podle očekávání. Pokud potřebujete více síťových adaptérů, mějte také na paměti limit síťové karty pro každou velikost.

Používejte spravované disky pro virtuální pevné disky.Spravované disky poskytují lepší spolehlivost virtuálních počítačů ve skupině dostupnosti, protože disky jsou dostatečně izolované od sebe, aby se zabránilo kritickým bodům selhání. Spravované disky se také nevztahují na 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 počítačů s Windows v Azure.

Nainstalujte aplikace na datový disk, ne na disk s operačním systémem. V opačném případě můžete 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 služby Recovery Services.

Povolte diagnostické protokoly. Zahrnují základní metriky stavu, protokoly infrastruktury a diagnostiku spouštění. Diagnostika spouštění vám může pomoct s diagnostikou selhání spouštění, pokud se váš virtuální počítač dostane do nebooovatelného stavu. Další informace najdete v tématu Přehled diagnostických protokolů Azure.

Nakonfigurujte Azure Monitor. Shromážděte a analyzujte data monitorování z virtuálních počítačů Azure, včetně hostovaného operačního systému a úloh, které v něm běží, viz Azure Monitor a rychlý start: Azure Monitor.

Virtual Network

Pokud chcete povolit nebo blokovat veřejné IP adresy, přidejte do podsítě skupinu zabezpečení sítě. Zablokujte přístup od uživatelů se zlými úmysly nebo povolte přístup jenom uživatelům, kteří mají oprávnění k přístupu k aplikaci.

Vytvořte vlastní sondu stavu. Sondy stavu Load Balanceru můžou testovat protokol HTTP nebo TCP. Pokud na virtuálním počítači běží server HTTP, je sonda HTTP lepším indikátorem stavu než test TCP. Pro sondu HTTP použijte vlastní koncový bod, který hlásí celkový stav aplikace, včetně všech kritických závislostí. Další informace najdete v přehledu služby Azure Load Balancer.

Nezablokujte sondu stavu. Sonda stavu Load Balanceru se odesílá ze známé IP adresy 168.63.129.16. Neblokujte provoz do této IP adresy ani z této IP adresy v zásadách brány firewall ani pravidlech 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 Balanceru. Protokoly ukazují, kolik virtuálních počítačů na back-endu nedostává síťový provoz kvůli neúspěšným odpovědím sondy. Další informace najdete v tématu Log Analytics pro Azure Load Balancer.