Sdílet prostřednictvím

perspektiva architektury Well-Architected v Azure Traffic Manageru

  • Článek

Azure Traffic Manager je globální nástroj pro vyrovnávání zatížení, který může distribuovat provoz napříč několika oblastmi Azure, zónami v rámci oblasti nebo datovými centry v těchto zónách. K navázání komunikační cesty mezi klientem a koncovými body vaší úlohy používá protokol DNS (Domain Name System). Po navázání připojení se klienti můžou připojit přímo ke koncovému bodu bez pomoci Traffic Manageru.

Tento článek předpokládá, že jako architekt jste si prostudovali možnosti vyrovnávání zatížení v Azure a jako úlohu jste zvolili Azure Traffic Manager, který se nasazuje napříč několika oblastmi v modelu aktivní-aktivní nebo aktivní-pasivní. Pokyny v tomto článku poskytují architektonická doporučení, která odpovídají principům pilířů Well-Architected Framework.

Důležitý

Jak používat tohoto průvodce

Každá část obsahuje kontrolní seznam návrhu, který představuje architektonické oblasti zájmu spolu se strategiemi návrhu lokalizovanými do oboru technologie.

Součástí jsou také doporučení pro technologické možnosti, které můžou pomoct materializovat tyto strategie. Doporučení nepředstavují vyčerpávající seznam všech konfigurací, které jsou k dispozici pro Traffic Manager a jeho závislosti. Místo toho uvedou seznam klíčových doporučení spojených s perspektivami návrhu. Pomocí doporučení můžete vytvořit testování konceptu nebo optimalizovat vaše stávající prostředí.

Základní architektura, která demonstruje klíčová doporučení: vyrovnávání zatížení ve více oblastech pomocí Traffic Manageru, služby Azure Firewall a služby Application Gateway.

rozsah technologie

Tato kontrola se zaměřuje na vzájemně související rozhodnutí pro následující prostředek Azure.

  • Správce dopravy

Diagram znázorňující scénář převzetí služeb při selhání pomocí Azure Traffic Manageru.

Poznámka

U úloh, které hostují aplikace HTTP, je služba Azure Front Door přirozenou volbou z důvodu jejích funkcí, jako je síť pro doručování obsahu, ukončení protokolu TLS (Transport Layer Security) a integrovaná brána firewall.

Ve srovnání se službou Azure Front Door je Traffic Manager jednodušší nastavit, konfigurovat a udržovat. Traffic Manager nemá koncový bod, který můžete řídit přímo. Na rozdíl od služby Front Door, která zpracovává požadavky klientů, Traffic Manager připojuje klienty pouze ke koncovému bodu úlohy.

Tato jednoduchost ale přináší kompromisy, které můžou v architektuře zavádět složitost. Možná budete například muset implementovat další bezpečnostní opatření, která blokují typy útoků Open Worldwide Application Security Project (OWASP). Tuto funkci poskytuje firewall webových aplikací (WAF) ve službě Azure Front Door nebo Azure Application Gateway. Nebo můžete přidat mezipaměť, která může urychlit doručování obsahu, ale zvyšuje složitost, protože musíte spravovat úložiště dat.

Další informace najdete v části Well-Architected Perspektiva rámce ve službě Azure Front Door.

Spolehlivost

Účelem pilíře spolehlivosti je poskytovat nepřetržité funkce tím, že budování dostatečné odolnosti a schopnosti rychle se zotavit ze selhání.

principy návrhu spolehlivosti poskytují základní strategii návrhu použitou pro jednotlivé komponenty, systémové toky a systém jako celek.

Kontrolní seznam návrhu

Zahajte strategii návrhu na základě kontrolního seznamu pro přezkum spolehlivosti. Určete její význam pro vaše obchodní požadavky a přitom mějte na paměti povahu vaší aplikace a důležitost jejích součástí. Rozšiřte strategii tak, aby podle potřeby zahrnovala více přístupů.

  • Zohledněte potenciální selhání. Traffic Manager je navržený tak, aby byl odolný. Přesto může být kritickým bodem selhání pro vaše pracovní zatížení. Chcete-li toto riziko zmírnit, definujte sekundární cestu k alternativní službě, která se stane aktivní, pokud Traffic Manager není k dispozici. Abyste se vyhnuli problémům se směrováním, nepoužívejte Traffic Manager a alternativní službu společně.

  • Mít dobré porozumění pokrytí smlouvy o úrovni služeb (SLA). Když vyhodnotíte smlouvy SLA Traffic Manageru, seznamte se s pokrytím souvisejícím s publikovaným percentilem. Vyhledávání DNS může například několikrát selhat. Tato selhání se nepovažují za výpadky, dokud nedojde k celé minutě nepřetržitých selhání vyhledávání DNS.

  • Začleňte redundanci do architektury úloh. Pokud je vaše služba přístupná prostřednictvím veřejné IP adresy, použijte Traffic Manager k implementaci redundance napříč oblastmi Azure, místními a dalšími cloudy. Můžete mít například místní aplikaci, která má sekundární instanci v cloudu. Pokud místní systém selže, může se cloudová instance stát aktivní, což pomáhá zajistit kontinuitu.

  • K zajištění redundance použijte spolehlivou architekturu nasazení. Traffic Manager jako nástroj pro vyrovnávání zatížení distribuuje provoz mezi koncové body úloh na základě způsobu konfigurace metody směrování. Tuto konfiguraci definujete v profilu Traffic Manageru. Profil je základní součástí vaší strategie nasazení. Příslušnou konfiguraci profilu můžete použít k implementaci modelu aktivní-aktivní nebo pasivního modelu s teplou rezervou.

    Každý profil určuje jednu metodu směrování provozu. Některé scénáře vyžadují sofistikovanější směrování provozu. Profily Traffic Manageru můžete kombinovat, abyste mohli využít více než jednu metodu směrování provozu.

    Další informace o metodách směrování Traffic Manageru naleznete v tématu .

  • Vyhodnoťte dobu ukládání odpovědí DNS do mezipaměti. Nastavení TTL (time-to-live) pro vyhledávání DNS v Traffic Manageru určuje, jak dlouho podřízené překladače DNS ukládají odpovědi DNS do mezipaměti. Výchozí hodnota TTL může vést k delší době ukládání do mezipaměti, než je potřeba, což může způsobit výpadky v případě selhání koncového bodu. Snižte hodnotu TTL, aby se zvýšila frekvence aktualizací mezipaměti. Tato metoda může pomoct zmírnit výpadky, ale zvyšuje frekvenci vyhledávání DNS.

  • Vyhněte se odesílání provozu do nezdravých nebo kompromitovaných instancí. Projděte si integrované funkce sondování stavu v Traffic Manageru.

    Pro aplikace HTTPS a HTTP implementujte model monitorování koncových bodů stavu, který poskytuje vlastní stránku v rámci vaší aplikace. Na základě konkrétních kontrol vrátí stránka odpovídající stavový kód HTTPS. Kromě dostupnosti koncového bodu by měla kontrola stavu monitorovat všechny závislosti vaší aplikace.

    Pro jiné aplikace Traffic Manager používá protokol TCP (Transmission Control Protocol) k určení dostupnosti koncového bodu.

    Pro více informací viz vzor monitorování zdravotních stavových koncových bodů a pochopení sond Traffic Manageru.

  • Určete odolnost proti výpadkům. Pokud se back-end stane nedostupným, může nějaký čas projít, než Traffic Manager rozpozná selhání a přestane směrovat provoz do nedostupného koncového bodu. Existují určité časové období, kdy se žádosti klientů nedají obsloužovat. Tuto toleranci použijte ke konfiguraci nastavení sondy, které určují, jak rychle chcete spustit operace zajištění kontinuity podnikání.

  • Zahrňte koncové body jako součást testování odolnosti. Simulujte nedostupné koncové body a podívejte se, jak Traffic Manager zpracovává selhání. Předpokládejme, že vaše úloha používá nástroj pro vyrovnávání zatížení, jako je Application Gateway v privátní virtuální síti. K simulaci selhání koncového bodu můžete použít pravidla skupiny zabezpečení sítě (NSG) v nástroji Azure Chaos Studio. Přístup k podsíti, ve které se nachází služba Application Gateway, můžete zablokovat.

Doporučení

Doporučení Prospěch
Nasazení několika koncových bodů v profilech Traffic Manageru a jejich povolení. Pokud koncový bod není povolen, není kontrolován pro zdravotní kontroly ani zahrnut do rotace směrování provozu. Tyto koncové body umístěte do různých oblastí. Redundantní instance pomáhají zajistit dostupnost v případě selhání jednoho koncového bodu.
Vyhodnoťte různé metody směrování provozu . Nakonfigurujte jednu nebo kombinaci metod tak, aby odpovídaly vaší strategii nasazení. Traffic Manager použije zvolenou metodu pro každý dotaz DNS a použije metodu k určení koncového bodu, který se vrátí v odpovědi DNS.

– vážená metoda distribuuje provoz na základě nakonfigurovaného koeficientu hmotnosti. Tato metoda podporuje aktivní-aktivní modely.
– Metoda založená na prioritě nakonfiguruje primární oblast tak, aby přijímala provoz a odesílala ji do sekundární oblasti jako zálohu. Tato metoda podporuje aktivní-pasivní modely.
– geografická metoda směruje provoz na základě geografického původu dotazu DNS. Pokud chcete pokrýt všechny oblasti, nakonfigurujte aspoň jeden koncový bod s vlastností All (World).		 Optimalizovaná metoda směrování pomáhá zajistit efektivní distribuci provozu napříč koncovými body.

Cíle modelu nasazení typu aktivní-aktivní nebo aktivní-pasivní můžete podporovat. Efektivní metoda směrování pomáhá zajistit, aby sekundární oblasti mohly zpracovávat provoz nebo fungovat jako záloha.

Geografické směrování pomáhá směrovat uživatele na nejbližší koncový bod na základě jejich umístění. Pomáhá zajistit, aby provoz byl efektivně spravován a nedošlo k jeho ztrátě.
Nastavte interval TTL dns dobu trvání na nízkou hodnotu, pokud možno méně než 60 sekund. Pokud chcete optimalizovat výkon, upravte časování sondy pro kontrolu stavu a hodnotu TTL záznamu DNS. Nízká hodnota TTL pomáhá zajistit častější aktualizace mezipaměti resolveru DNS a rychlejší přepnutí při selhání. Zároveň minimalizuje výpadky a zlepšuje celkovou odezvu aplikace.
Nastavte sondy stavu pro monitorováníkoncového bodu .

– Nepovolujte AlwaysServe, který zakáže monitorování koncových bodů a odesílá požadavky do koncového bodu bez ohledu na stav koncového bodu.
– Nastavte hodnotu probing interval. Zvažte kompromis mezi tím, jak rychle můžete detekovat selhání a počet požadavků na koncový bod. Počet požadavků může být podstatný, protože Traffic Manager je globální služba, která provádí příkazy ping současně z různých umístění.
Nastavte hodnotu probe timeout. Zvažte, jak dlouho čekat, než prohlásíte koncový bod za nezdravý. Do počtu selhání zahrňte falešně pozitivní výsledky.		 Sondy stavu zajišťují, že žádosti uživatelů obsluhují pouze instance, které jsou v pořádku. Pomáhají také určit, jestli selhání nejsoutransientní a jak rychle se mají provádět operace převzetí služeb při selhání.

Bezpečnost

Účelem pilíře zabezpečení je poskytnout důvěrnosti, integritě a dostupnosti zárukám úlohy.

Principy návrhu zabezpečení poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů použitím přístupů k technickému návrhu Traffic Manageru.

Kontrolní seznam návrhu

  • Zkontrolujte standardní hodnoty zabezpečení. Pokud chcete zlepšit svou úroveň zabezpečení, projděte si základní kritéria zabezpečení pro službu Traffic Manager.

  • Zabránit neoprávněným úpravám směrování provozu Zacházet s profily Traffic Manageru jako s důležitými prostředky úloh, protože obsahují nastavení konfigurace pro směrování provozu. K těmto profilům by měly mít přístup pouze autorizované identity. Implementujte řízení přístupu na základě rolí (RBAC) na řídicí rovině, abyste omezili úlohy, jako je vytváření, odstraňování nebo úprava prostředků. Oprávnění k povolení nebo zakázání koncových bodů by měly mít jenom autorizované identity. Neoprávněný přístup může vést ke změnám konfigurace a potenciálně k přesměrování provozu na škodlivé implementace.

  • Chraňte aplikace před hrozbami na periferii sítě. Traffic Manager neposkytuje integrované funkce zabezpečení, jako je WAF. Kvůli lepšímu zabezpečení aplikací HTTP byste měli implementovat kontrolu provozu na úrovni koncového bodu.

    Typická architektura může zahrnovat Traffic Manager a několik koncových bodů. Pro každý koncový bod poskytuje aplikační brána, která zpracovává ukončení protokolu TLS a další funkce zabezpečení, ochranu. Referenční architekturu, která znázorňuje tento vzor, najdete v tématu Vyrovnávání zatížení ve více oblastech s využitím služby Traffic Manager, Azure Firewall a Application Gateway.

  • Zabezpečení položek DNS Traffic Manager může být náchylný k útokům, které manipulují s daty DNS, což může přesměrovat provoz na škodlivé weby a způsobit problémy se zabezpečením. Běžnou hrozbou je převzetí subdomény, ve kterém záznam DNS odkazuje na zrušený prostředek Azure. Pokud chcete zabránit převzetí subdomény, použijte záznamy aliasů Azure DNS a propojte životní cyklus záznamu DNS s prostředkem Azure.

    Další informace naleznete v tématu Zabránit shodným záznamům DNS.

Doporučení

Doporučení Prospěch
Přidání aplikačních bran do koncových bodů úloh.

Pro implementaci inspekce zabezpečení s firewallem pro aplikace HTTP přidejte aplikační brány do koncových bodů pracovních úloh.		 Můžete zkontrolovat příchozí provoz HTTP, který pomáhá chránit aplikaci před běžnými útoky.
Vytvořte aliasový záznam v Azure DNS pro hlavní doménové jméno vaší úlohy, který odkazuje na profil Traffic Manageru. Záznamy aliasů úzce propojují životní cyklus záznamu DNS s prostředkem Azure. Tato konfigurace pomáhá zabránit visícím odkazům, pokud je úloha vyřazena z provozu. Pokud se profil Traffic Manageru odstraní, záznam aliasu DNS se stane prázdnou sadou záznamů. Už to neodkazuje na odstraněný prostředek.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na detekci vzorců výdajů, prioritizaci investic v kritických oblastech a optimalizaci v jiných tak, aby splňoval rozpočet organizace a současně plnil obchodní požadavky.

Principy návrhu optimalizace nákladů poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů a dosažení kompromisů v technickém návrhu souvisejícím s Traffic Managerem a jeho prostředím.

Kontrolní seznam návrhu

Zahajte strategii návrhu na základě kontrolního seznamu návrhu pro optimalizaci nákladů na investice. Dolaďte návrh tak, aby úloha byla v souladu s rozpočtem přiděleným pro danou úlohu. Váš návrh by měl využívat správné možnosti Azure, monitorovat investice a hledat příležitosti k optimalizaci v průběhu času.

  • Vyhodnoťte náklady na funkce. Funkce řídicího panelu zobrazení provozu ukazuje, odkud se vaši klienti připojují, a přidruženou latenci. Tyto informace pomáhají optimalizovat výkon a zpřesnit návrh, což přispívá k efektivitě provozu a efektivitě systému. To však přináší další náklady. Další informace najdete v Přehled provozu fakturace.

    Zvažte také náklady spojené se sondami zdraví. Traffic Manager odešle příkaz ping na definované koncové body z různých umístění a zkontroluje jejich dostupnost. Můžete zvolit pomalé příkazy ping a rychlé příkazy ping. Rychlé snímání detekuje chyby rychleji, ale způsobuje vyšší náklady. Navíc přidají větší zatížení úlohy, protože kontroly stavu jsou častější.

  • Vyhodnoťte náklady na strategii směrování. Pokud například většina klientů přistupuje ke koncovému bodu z oblasti s vysokou latencí, můžete vytvořit další koncový bod blíže těmto uživatelům a upravit metodu směrování v Traffic Manageru. Tento postup snižuje latenci, takže můžete zpracovávat více požadavků s menší kapacitou, což vede k úsporám nákladů.

Doporučení

Doporučení Prospěch
K odhadu nákladů na funkce Traffic Manageru použijte cenovou kalkulačku . V případě potřeby můžete mít přesnější nákladový model a nastavit zásady správného řízení týkající se prostředků.
Během vašich optimalizačních snah aktivujte řídicí panel pro zobrazení provozu. Tato funkce vám pomůže lépe porozumět vzorům použití. Tato data použijte k optimalizaci výkonu, která vám pomůžou splnit cíle úloh.

Povolte funkce ve správný čas a použijte správnou úroveň, abyste se vyhnuli nedostatečnému využití prostředků.
V závislosti na vašich metrikách obnovení si můžete vybrat mezi rychlým nebo pomalým pingem pro sondy zdraví .

Rychlé příkazy ping detekují chyby rychleji, ale stojí více. Pomalé příkazy ping jsou pomalejší, ale stojí méně.

Nezakažujte příkazy ping.		 Minimalizujte četnost pingu, abyste optimalizovali náklady a snížili zatížení na koncových bodech pracovních úloh.

Efektivita provozu

Efektivita provozu se primárně zaměřuje na postupy vývojových postupů, pozorovatelnosti a správy verzí.

Principy návrhu efektivity provozu poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů pro provozní požadavky úlohy.

Kontrolní seznam návrhu

  • Shromážděte a analyzujte provozní data jako součást monitorování úloh. Zachyťte relevantní protokoly a metriky Traffic Manageru. Tato data slouží k řešení potíží, pochopení chování provozu a vyladění logiky směrování.

  • Umožňuje zobrazit data o provozu pro profily. Tato data pomáhají určit oblasti pro zlepšení, jako je rozšíření přítomnosti Azure v oblastech s vysokou latencí. Také zvýrazňuje vzorce provozu v různých oblastech, které vám pomůžou určit, kde se mají investice zvýšit nebo snížit.

  • Implementovat operace zotavení po havárii. Implementaci zotavení po havárii můžete navrhnout tak, aby přesměrovával síťový nebo webový provoz z hlavní lokality na záložní lokalitu. Tuto metodu zotavení po havárii je možné implementovat pomocí Azure DNS a Azure Traffic Manageru (DNS). Pokud dojde ke zhoršení primárního koncového bodu v případě havárie, Traffic Manager přesměruje provoz do sekundárního koncového bodu, který je v pořádku. Traffic Manager ve výchozím nastavení upřednostňuje primární koncový bod, ale lze jej také nakonfigurovat s dodatečnými koncovými body pro převzetí služeb při selhání nebo s vyrovnávači zatížení pro rozložení provozu. Další informace naleznete v tématu Nastavení zotavení po havárii a detekce výpadků.

  • Vyhněte se automatickým operacím obnovy nebo návratu do předchozího stavu. Pokud provedete navrácení služeb po obnovení, nepoužívejte automatické navrácení služeb po obnovení, které se okamžitě přepne zpět na původní koncový bod v primárním bodu, jakmile bude k dispozici. Místo toho zakažte původní koncový bod a použijte sekundární koncový bod, dokud nechcete přepnout. Tento přístup poskytuje čas na stabilizaci. Okamžité obnovení může způsobit dodatečné zatížení a zpoždění.

    Další informace najdete v tématu referenční architektura vyrovnávání zatížení ve více oblastech.

  • Otestujte nastavení konfigurace. Chybné konfigurace můžou ovlivnit všechny aspekty úlohy, zejména spolehlivost. Otestujte konfigurace s více klienty na různých místech. Další informace najdete v tématu Ověření nastavení Traffic Manageru.

Doporučení

Doporučení Prospěch
Povolení diagnostických protokolů pro profil Traffic Manageru.

K přehrávání protokolů a analýze dat kontroly stavu použijte nástroje .		 Diagnostické protokoly poskytují přehledy o chování profilu Traffic Manageru. Můžete například identifikovat důvody vypršení časového limitu jednotlivých sond u koncového bodu.
Povolte řídicí panel zobrazení provozu . Získejte přehled o tom, odkud se vaši klienti připojují, a související latenci. Tyto informace pomáhají optimalizovat výkon a náklady, protože návrh můžete upřesnit.
Využijte rozhraní REST API Heat Map, které poskytuje data o umístěních a latenci klientů. Tento přístup nabízí flexibilitu, například nastavení určitého časového období. Data můžete přidat do vlastních nástrojů nebo řídicích panelů. Toto rozhraní API můžete použít také k integraci s externími nástroji.
Zakázání koncových bodů pro provozní aktivity. Můžete například zakázat návrat po převzetí služeb při selhání, abyste mohli provést údržbu nebo testování. Zakázání koncového bodu z nástroje pro vyrovnávání zatížení je výhodné pro provozní úlohy, protože nemůžete zastavit živý provoz. Během údržby instance nedostávají provoz, pokud koncový bod zakážete. Tento přístup zabraňuje automatickému obnovení.

Efektivita výkonu

Efektivita výkonu se týká zachování uživatelského prostředí, i když se zvyšuje zatížení správou kapacity. Strategie zahrnuje škálování prostředků, identifikaci a optimalizaci potenciálních kritických bodů a optimalizaci výkonu ve špičce.

Principy návrhu výkonnostní efektivity poskytují strategii návrhu vysoké úrovně pro dosažení cílů kapacity vzhledem k očekávanému využití.

Kontrolní seznam návrhu

Zahajte svou strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu a pro efektivitu výkonu. Definujte směrný plán založený na klíčových ukazatelích výkonu pro Traffic Manager.

  • Změřte dopad konfigurace na výkon. Traffic Manager neruší přímé připojení mezi klientem a vaším koncovým bodem. Hlavním dopadem na výkon je počáteční vyhledávání DNS. Nastavení hodnoty TTL ovlivňuje, jak často k tomuto vyhledávání dochází. Nižší hodnota TTL znamená častější překlady DNS, což může mírně ovlivnit výkon. Pokud nastavíte hodnotu TTL na nulu, každý požadavek vyžaduje vyhledávání DNS, které před přístupem ke koncovému bodu přidá malé zpoždění.

    Protože Traffic Manager funguje na úrovni DNS, nepodporuje spřažení relací. Traffic Manager může uživatele směrovat na různé koncové body pro každé volání. Pokud potřebujete vazbu relace, musíte uložit stav do samostatného úložiště dat.

    Další informace najdete v tématu Aspekty výkonu služby Traffic Manager.

  • Upravte chování směrování provozu za účelem optimalizace výkonu. Jeden profil může mít více koncových bodů, ale současně můžete použít pouze jednu metodu směrování.

    V případě složitějších scénářů zvažte vytvoření hierarchie profilů pro kombinování různých metod směrování. Můžete například určit prioritu oblastí a pak použít směrování na základě výkonu v rámci oblastí.

Doporučení

Doporučení Prospěch
Pokud máte koncové body v různých geografických umístěních, použijte metodu směrování výkonu . Tato metoda upřednostňuje odesílání provozu do koncového bodu, který má nejnižší latenci. Tato metoda pomáhá zajistit rychlou službu pro uživatele.
K optimalizaci výkonu použijte specializované nástroje. Změřte výkon vyhledávání DNS . K analýze výkonu provozu použijte panel pohledu na provoz nebo rozhraní REST API Heat Map . Nástroje pro měření latence DNS provádějí úplné vyhledávání DNS a poskytují údaje o výkonu. Tato data můžete použít k nastavení doby trvání hodnoty TTL a optimalizaci výkonu.
Zkombinujte metody provozu s vnořenými profily pro optimální výkon podle vašich požadavků na úlohy. Optimalizovaná metoda směrování pomáhá zajistit, aby provoz byl směrován na nejreagovanější a nejbližší koncové body. Tento přístup pomáhá zlepšit výkon aplikací a uživatelské prostředí.
Použití funkce měření skutečných uživatelů k zobrazení měření latence sítě do oblastí Azure. Tato funkce je k dispozici bez dalších poplatků. Při rozhodování o směrování založeném na datech můžete směrovat dotazy do oblasti Azure, která poskytuje nejnižší latenci.
Nastavte interval TTL DNS na vyšší hodnotu. Klienti můžou výsledky ukládat do mezipaměti po delší dobu, což zkracuje potřebu překládat DNS pokaždé.

Zásady Azure

Azure poskytuje rozsáhlou sadu předdefinovaných zásad souvisejících s Traffic Managerem a jejími závislostmi. Některé z předchozích doporučení je možné auditovat prostřednictvím služby Azure Policy. Můžete například zkontrolovat, jestli:

  • Protokoly prostředků jsou aktivovány ke sledování aktivit.
  • Protokoly pro profily Traffic Manageru se odesílají do služby Azure Event Hubs.

Komplexní zásady řízení najdete v vestavěných definicích Azure Policy pro síťové služby Azure.

Doporučení azure Advisoru

azure Advisor je individuální cloudový konzultant, který vám pomůže postupovat podle osvědčených postupů pro optimalizaci nasazení Azure. Tady je několik doporučení, která vám můžou pomoct zlepšit spolehlivost, zabezpečení, nákladovou efektivitu, výkon a efektivitu provozu instancí webových aplikací.

Kompromisy

Pokud použijete přístupy v kontrolních seznamech pilíře, budete možná muset přistoupit ke kompromisům. Tady je několik příkladů výhod a nevýhod.

spolehlivost a efektivita výkonu

  • Nastavení hodnoty TTL pro vyhledávání DNS. Výchozí nastavení hodnoty TTL může vést k delší době ukládání do mezipaměti. Dlouhé doby ukládání do mezipaměti můžou způsobit výpadek, pokud koncový bod selže, protože aplikace se po dobu trvání hodnoty TTL pokusí o připojení ke koncovému bodu, který selhal.

    Snižte hodnotu TTL, abyste tento problém zmírnili. Nižší hodnota TTL umožňuje častější aktualizace a rychlejší přepnutí, ale zvyšuje frekvenci vyhledávání DNS. Tento přístup může ovlivnit výkon a zvýšit zatížení serverů DNS.

optimalizace nákladů a spolehlivosti

  • Zdravotní sondy Traffic Manager používá sondy stavu ke zjištění dostupnosti vašich koncových bodů pomocí příkazů ping z různých míst. Můžete zvolit pomalé příkazy ping nebo rychlé příkazy ping. Rychlé příkazy ping detekují chyby rychleji, ale přidávají náklady. Pomalé pingy trvají déle, než zjistí selhání, ale stojí méně. Vyvažte rychlost detekce selhání a obnovení s přidruženými náklady.

Další krok

Zvažte následující zdroje informací, které ukazují doporučení v tomto článku.