Nejčastější dotazy k Traffic Manageru

  • Článek

Základy Traffic Manageru

Jakou IP adresu Traffic Manager používá?

Jak vysvětluje , jak Traffic Manager funguje, Traffic Manager funguje na úrovni DNS (Domain Name System). Odesílá odpovědi DNS na směrování klientů do příslušného koncového bodu služby. Klienti se pak připojují přímo ke koncovému bodu služby, nikoli prostřednictvím Traffic Manageru.

Traffic Manager proto neposkytuje koncový bod ani IP adresu, ke kterému se mají klienti připojit. Pokud chcete pro vaši službu statickou IP adresu, musí být ve službě nakonfigurovaná, ne v Traffic Manageru.

Jaké typy provozu je možné směrovat pomocí Traffic Manageru?

Jak je vysvětleno v tom, jak Traffic Manager funguje, koncový bod Traffic Manageru může být libovolná internetová služba hostovaná uvnitř Azure nebo mimo Azure. Traffic Manager proto může směrovat provoz pocházející z veřejného internetu do sady koncových bodů, které jsou také přístupné z internetu. Pokud máte koncové body, které jsou uvnitř privátní sítě (například interní verze Azure Load Balanceru) nebo mají uživatele provádějící požadavky DNS z takových interních sítí, nemůžete k směrování tohoto provozu použít Traffic Manager.

Podporuje Traffic Manager relace "sticky"?

Jak vysvětluje , jak Traffic Manager funguje, Traffic Manager funguje na úrovni DNS. Ke směrování klientů na příslušný koncový bod služby používá odpovědi DNS. Klienti se připojují přímo ke koncovému bodu služby, ne přes Traffic Manager. Traffic Manager proto nevidí provoz HTTP mezi klientem a serverem.

Kromě toho zdrojová IP adresa dotazu DNS přijatého Traffic Managerem patří do rekurzivní služby DNS, nikoli do klienta. Traffic Manager proto nemá žádný způsob, jak sledovat jednotlivé klienty a nemůže implementovat "rychlé" relace. Toto omezení platí pro všechny systémy správy provozu založené na DNS a nejsou specifické pro Traffic Manager.

Proč se při používání Traffic Manageru zobrazuje chyba HTTP?

Jak vysvětluje , jak Traffic Manager funguje, Traffic Manager funguje na úrovni DNS. Ke směrování klientů na příslušný koncový bod služby používá odpovědi DNS. Klienti se pak připojují přímo ke koncovému bodu služby, nikoli prostřednictvím Traffic Manageru. Traffic Manager nevidí provoz HTTP mezi klientem a serverem. To znamená, že všechny zobrazované chyby musí pocházet z vaší aplikace. Aby se klient připojil k aplikaci, jsou všechny kroky překladu DNS hotové. To zahrnuje všechny interakce, které Traffic Manager má v toku provozu aplikace.

Další šetření by se proto mělo zaměřit na aplikaci.

Nejčastějším zdrojem problémů je hlavička hostitele HTTP odeslaná z prohlížeče klienta. Ujistěte se, že je aplikace nakonfigurovaná tak, aby přijímala správnou hlavičku hostitele pro název domény, který používáte. Informace o koncových bodech používajících službu Aplikace Azure Najdete v tématu Konfigurace vlastního názvu domény pro webovou aplikaci ve službě Aplikace Azure Service pomocí Traffic Manageru.

Jak můžu vyřešit problém 500 (vnitřní chyba serveru) při použití Traffic Manageru?

Pokud se klientovi nebo aplikaci při používání Traffic Manageru zobrazí chyba HTTP 500, může to být způsobeno zastaralým dotazem DNS. Pokud chcete tento problém vyřešit, vymažte mezipaměť DNS a povolte klientovi vydat nový dotaz DNS.

Když koncový bod služby nereaguje, klienti a aplikace používající tento koncový bod se neobnovují, dokud se neaktualizuje mezipaměť DNS. Doba trvání mezipaměti se určuje podle hodnoty TTL (Time to Live) záznamu DNS. Další informace najdete v tématu Traffic Manager a mezipaměť DNS.

Podívejte se také na následující související nejčastější dotazy v tomto článku:

Jaký je dopad na výkon používání Traffic Manageru?

Jak vysvětluje , jak Traffic Manager funguje, Traffic Manager funguje na úrovni DNS. Vzhledem k tomu, že se klienti připojují přímo ke koncovým bodům služby, při použití Traffic Manageru po navázání připojení nemá žádný vliv na výkon.

Vzhledem k tomu, že Traffic Manager se integruje s aplikacemi na úrovni DNS, vyžaduje, aby se do řetězu překladu DNS vložil další vyhledávání DNS. Dopad Traffic Manageru na dobu překladu DNS je minimální. Traffic Manager používá globální síť názvových serverů a k zajištění toho, aby se dotazy DNS vždy směrovaly na nejbližší dostupný názvový server. Kromě toho ukládání odpovědí DNS do mezipaměti znamená, že dodatečná latence DNS, která vznikla pomocí Traffic Manageru, se vztahuje pouze na zlomek relací.

Metoda výkonu směruje provoz do nejbližšího dostupného koncového bodu. Čistý výsledek je, že celkový dopad na výkon přidružený k této metodě by měl být minimální. Jakékoli zvýšení latence DNS by mělo být posunováno o nižší latenci sítě do koncového bodu.

Jaké aplikační protokoly můžu používat s Traffic Managerem?

Jak vysvětluje , jak Traffic Manager funguje, Traffic Manager funguje na úrovni DNS. Po dokončení vyhledávání DNS se klienti připojují přímo ke koncovému bodu aplikace, ne přes Traffic Manager. Připojení proto může používat libovolný aplikační protokol. Pokud jako monitorovací protokol vyberete protokol TCP, monitorování stavu koncového bodu Traffic Manageru se dá provést bez použití protokolů aplikací. Pokud se rozhodnete ověřit stav pomocí aplikačního protokolu, musí koncový bod odpovídat na požadavky HTTP nebo HTTPS GET.

Můžu použít Traffic Manager s názvem "nahé" domény?

Ano. Informace o vytvoření záznamu aliasu pro vrchol názvu domény pro odkazování na profil Azure Traffic Manageru najdete v tématu Konfigurace záznamu aliasu pro podporu vrcholu názvů domén pomocí Traffic Manageru.

Považuje Traffic Manager adresu podsítě klienta při zpracování dotazů DNS?

Ano. Kromě zdrojové IP adresy dotazu DNS (obvykle IP adresa překladače DNS) Traffic Manager také považuje adresu podsítě klienta, pokud je součástí dotazu DNS, který je odeslán překladačem DNS, který požadavek provede jménem koncového uživatele. Tyto IP adresy se používají k optimalizaci geografických metod směrování, výkonu a podsítě. Konkrétně RFC 7871 – Podsíť klienta v dotazech DNS poskytuje mechanismus rozšíření pro DNS (EDNS0) může předávat adresu podsítě klienta z překladačů, které ji podporují.

Co je hodnota TTL DNS a jaký má vliv na uživatele?

Když dotaz DNS přejde do Traffic Manageru, nastaví hodnotu v odpovědi s názvem TTL (time-to-live). Tato hodnota, jejíž jednotka je v sekundách, udává, jak dlouho se má odpověď ukládat do mezipaměti překladače DNS. I když překladače DNS nezaručují, že tento výsledek uloží do mezipaměti, umožňuje jim reagovat na všechny následné dotazy mimo mezipaměť místo na servery DNS Traffic Manageru. To má vliv na odpovědi následujícím způsobem:

  • Vyšší hodnota TTL snižuje počet dotazů, které se dostanou na servery DNS Traffic Manageru, což může snížit náklady na zákazníka, protože počet obsluhovaných dotazů představuje fakturovatelné využití.
  • vyšší hodnota TTL může potenciálně zkrátit dobu potřebnou k vyhledání DNS.
  • Vyšší hodnota TTL také znamená, že vaše data neodráží nejnovější informace o stavu, které Traffic Manager získal prostřednictvím svých agentů pro zkoumání.

Jak vysoká nebo nízká je hodnota TTL pro odpovědi Traffic Manageru?

Hodnotu TTL DNS můžete nastavit na úrovni profilu tak, aby byla tak nízká jako 0 sekund a až 2 147 483 647 sekund (maximální rozsah kompatibilní s RFC-1035). Hodnota TTL 0 znamená, že podřízené překladače DNS neukládají odpovědi dotazů do mezipaměti a očekává se, že se všechny dotazy dostanou k serverům DNS Traffic Manageru pro překlad.

Jak zjistím objem dotazů přicházejících do mého profilu?

Jednou z metrik poskytovaných Traffic Managerem je počet dotazů, které odpověděl profil. Tyto informace můžete získat na úrovni profilu agregace nebo je můžete dále rozdělit, abyste viděli objem dotazů, ve kterých se vrátily konkrétní koncové body. Kromě toho můžete nastavit upozornění, která vás upozorní, pokud svazek odpovědi dotazu překročí nastavené podmínky. Další podrobnosti najdete v metrikách a upozorněních Traffic Manageru.

Když odstraním profil Traffic Manageru, jaká je doba před tím, než bude název profilu k dispozici pro opakované použití?

Když odstraníte profil Traffic Manageru, přidružený název domény je rezervovaný po určitou dobu. Jiné profily Traffic Manageru ve stejném tenantovi můžou název okamžitě znovu použít. Jiný tenant Azure ale nemůže použít stejný název profilu, dokud nevyprší platnost rezervace. Tato funkce umožňuje udržovat autoritu nad nasazenými obory názvů, což eliminuje obavy, že název může převzít jiný tenant.

Pokud je například název profilu Traffic Manageru label1, label1.trafficmanager.net je vyhrazeno pro vašeho tenanta, i když profil odstraníte. Vyhrazené jsou také podřízené obory názvů, například xyz.label1 nebo 123.abc.label1 . Po vypršení platnosti rezervace se název zpřístupní ostatním tenantům. Název přidružený k zakázanému profilu je vyhrazen neomezeně dlouho. Pokud máte dotazy ohledně doby, po kterou je jméno rezervované, obraťte se na zástupce vašeho účtu.

Metoda geografického směrování provozu Traffic Manageru

Jaké jsou případy použití, kdy je geografické směrování užitečné?

Typ geografického směrování je možné použít v libovolném scénáři, ve kterém zákazník Azure potřebuje odlišit uživatele na základě geografických oblastí. Například pomocí metody geografického směrování provozu můžete uživatelům z konkrétních oblastí poskytnout jiné uživatelské prostředí než z jiných oblastí. Dalším příkladem je dodržování požadavků na suverenitu místních dat, které vyžadují, aby uživatelé z konkrétní oblasti sloužili pouze koncovými body v dané oblasti.

Návody rozhodnout, jestli mám použít metodu směrování výkonu nebo metodu geografického směrování?

Klíčovým rozdílem mezi těmito dvěma oblíbenými metodami směrování je to, že v metodě směrování výkonu vaším primárním cílem je odesílat provoz do koncového bodu, který může volajícímu poskytnout nejnižší latenci, zatímco při geografickém směrování je primárním cílem vynutit geografické ohraničení pro volající, abyste je mohli záměrně směrovat do konkrétního koncového bodu. K překrývání dochází, protože existuje korelace mezi geografickou blízkost a nižší latencí, i když to není vždy pravda. V jiné geografické oblasti může být koncový bod, který může volajícímu poskytnout lepší latenci a v takovém případě směrování výkonu odešle uživatele do daného koncového bodu, ale geografické směrování je vždy odesílá do koncového bodu, který jste namapovali pro svoji geografickou oblast. Pokud chcete lépe zjistit, zvažte následující příklad – s geografickým směrováním můžete provádět neobvyklá mapování, jako je odesílání veškerého provozu z Asie do koncových bodů v USA a veškerý provoz v USA do koncových bodů v Asii. V takovém případě geografické směrování záměrně dělá přesně to, co jste nakonfigurovali, aby dělalo a optimalizace výkonu, není potřeba zvážit.

Poznámka:

Můžou existovat scénáře, kdy potřebujete výkon i možnosti geografického směrování, pro tyto scénáře můžou být vnořené profily skvělou volbou. Můžete například nastavit nadřazený profil s geografickým směrováním, kam odesíláte veškerý provoz z Severní Amerika do vnořeného profilu, který obsahuje koncové body v USA, a pomocí směrování výkonu posílat tyto přenosy do nejlepšího koncového bodu v dané sadě.

Jaké oblasti služba Traffic Manager podporuje pro geografické směrování?

Hierarchii země/oblasti, kterou Traffic Manager používá, najdete tady. I když je tato stránka aktuální s případnými změnami, můžete také prostřednictvím kódu programu načíst stejné informace pomocí rozhraní REST API služby Azure Traffic Manager.

Jak Traffic Manager určí, odkud se uživatel dotazuje?

Traffic Manager se podívá na zdrojovou IP adresu dotazu (s největší pravděpodobností je to místní překladač DNS, který provádí dotazování jménem uživatele) a k určení umístění použije interní IP adresu. Tato mapa se průběžně aktualizuje tak, aby zohlednila změny v internetu.

Je zaručeno, že Traffic Manager dokáže správně určit přesnou zeměpisnou polohu uživatele v každém případě?

Ne, Traffic Manager nemůže zaručit, že geografická oblast, kterou odvodíme ze zdrojové IP adresy dotazu DNS, vždy odpovídá umístění uživatele z následujících důvodů:

  • Nejprve, jak je popsáno v předchozích nejčastějších dotazech, je zdrojová IP adresa, kterou vidíme, že překladač DNS provádí vyhledávání jménem uživatele. I když zeměpisné umístění překladače DNS je vhodným proxy serverem pro geografické umístění uživatele, může se také lišit v závislosti na stopách služby překladače DNS a konkrétní službě překladače DNS, kterou zákazník zvolil. Například zákazník, který se nachází v Malajsii, může v nastavení svého zařízení zadat službu překladače DNS, jejíž server DNS v Singapuru se může vybrat pro zpracování překladů dotazů pro daného uživatele nebo zařízení. V takovém případě může Traffic Manager zobrazit pouze IP adresu překladače, která odpovídá umístění Singapuru. Podívejte se také na předchozí nejčastější dotazy týkající se podpory adres podsítě klienta na této stránce.

  • Za druhé Traffic Manager používá k překladu IP adresy do geografické oblasti interní mapu. I když se tato mapa průběžně ověřuje a aktualizuje, aby se zvýšila jeho přesnost a zohlednila vyvíjející se povaha internetu, stále existuje možnost, že naše informace nejsou přesnou reprezentací geografického umístění všech IP adres.

Musí být koncový bod fyzicky umístěný ve stejné oblasti jako koncový bod, pro který je nakonfigurovaný pro geografické směrování?

Ne, umístění koncového bodu neukládá žádná omezení, na které oblasti je možné na něj mapovat. Koncový bod v oblasti Azure – střed USA může mít například všechny uživatele z Indie.

Můžu přiřadit geografické oblasti koncovým bodům v profilu, který není nakonfigurovaný pro geografické směrování?

Ano, pokud metoda směrování profilu není geografická, můžete pomocí rozhraní REST API služby Azure Traffic Manager přiřadit geografické oblasti ke koncovým bodům v daném profilu. U profilů typů nezeměpisná směrování se tato konfigurace ignoruje. Pokud tento profil později změníte na typ geografického směrování, Traffic Manager může tato mapování použít.

Proč se při pokusu o změnu metody směrování existujícího profilu na Geografickou zobrazuje chyba?

Všechny koncové body v profilu s geografickým směrováním musí mít namapovanou aspoň jednu oblast. Pokud chcete převést existující profil na typ geografického směrování, musíte nejprve přidružit geografické oblasti ke všem jeho koncovým bodům pomocí rozhraní REST API služby Azure Traffic Manager, než změníte typ směrování na geografický. Pokud používáte portál, nejprve odstraňte koncové body, změňte metodu směrování profilu na geografickou a pak přidejte koncové body spolu s jejich mapováním geografické oblasti.

Oblast je možné přiřadit pouze jednomu koncovému bodu v rámci profilu, pokud používá metodu geografického směrování. Pokud tento koncový bod není vnořeným typem s podřízeným profilem připojeným k němu, pokud tento koncový bod není v pořádku, Traffic Manager do něj dál odesílá provoz, protože alternativa k neodesílání jakéhokoli provozu není lepší. Traffic Manager nepředá služby při selhání jinému koncovému bodu, ani když je přiřazená oblast nadřazená koncovému bodu přiřazené ke koncovému bodu, který není v pořádku (například pokud koncový bod, který má oblast Španělsko, není v pořádku, nepředáme služby při selhání jinému koncovému bodu, který má přiřazenou oblast Evropa). Tím zajistíte, aby Traffic Manager respektoval zeměpisné hranice, které zákazník nastavil ve svém profilu. Pokud chcete získat výhodu převzetí služeb při selhání do jiného koncového bodu, když koncový bod není v pořádku, doporučujeme místo jednotlivých koncových bodů přiřadit geografické oblasti k vnořeným profilům s více koncovými body. Pokud se koncový bod ve vnořeném podřízeného profilu nezdaří, může provoz převzít služby při selhání do jiného koncového bodu ve stejném vnořeném podřízeného profilu.

Existují nějaká omezení pro verzi rozhraní API, která tento typ směrování podporuje?

Ano, pouze rozhraní API verze 2017-03-01 a novější podporuje typ geografického směrování. Žádné starší verze rozhraní API se nedají použít k vytvoření profilů typu geografického směrování ani přiřazení geografických oblastí ke koncovým bodům. Pokud se k načtení profilů z předplatného Azure používá starší verze rozhraní API, nevrátí se žádný profil typu geografického směrování. Kromě toho při použití starších verzí rozhraní API nemá zobrazený žádný profil vrácený koncovými body s přiřazením geografické oblasti.

Metoda směrování provozu podsítě Traffic Manageru

Jaké jsou případy použití, kdy je užitečné směrování podsítě?

Směrování podsítě umožňuje odlišit prostředí, které poskytujete pro konkrétní sady uživatelů identifikovaných zdrojovou IP adresou IP adresy požadavků DNS. Příkladem by bylo zobrazení jiného obsahu, pokud se uživatelé připojují k webu z podnikového HQ. Další možností by bylo omezit uživatele z určitých poskytovatelů služeb isp pouze na koncové body přístupu, které podporují pouze připojení IPv4, pokud mají tito poskytovatelé služeb sítě při použití protokolu IPv6 podparaný výkon. Dalším důvodem použití metody směrování podsítě je spojení s jinými profily v sadě vnořených profilů. Pokud například chcete použít metodu geografického směrování pro geografické ohraničení uživatelů, ale u konkrétního zprostředkovatele internetových služeb, který chcete použít jinou metodu směrování, můžete mít profil s metodou směrování podsítě jako nadřazený profil a přepsat ho, aby používal konkrétní podřízený profil a měl standardní geografický profil pro všechny ostatní.

Jak Traffic Manager zná IP adresu koncového uživatele?

Zařízení koncových uživatelů obvykle používají překladač DNS k vyhledávání DNS jejich jménem. Odchozí IP adresa těchto překladačů je to, co Traffic Manager vidí jako zdrojová IP adresa. Kromě toho metoda směrování podsítě hledá také informace o předávané podsíti rozšířené klientské podsítě (ECS) EDNS0. Pokud jsou k dispozici informace ECS, jedná se o adresu použitou k určení směrování. V případě absence informací ECS se zdrojová IP adresa dotazu používá pro účely směrování.

Jak můžu zadat IP adresy při použití směrování podsítě?

IP adresy, které se mají přidružit ke koncovému bodu, je možné zadat dvěma způsoby. Nejprve můžete použít čtyřúhelníkový tečkovaný desetinný zápis s počáteční a koncovou adresou k určení rozsahu (například 1.2.3.4-5.6.7.8 nebo 3.4.5.6-3.4.5.6). Za druhé můžete použít zápis CIDR k určení rozsahu (například 1.2.3.0/24). Můžete zadat více oblastí a v sadě oblastí můžete použít oba typy notace. Platí několik omezení.

  • Rozsahy adres se nedají překrývat, protože každá IP adresa musí být namapovaná jenom na jeden koncový bod.
  • Počáteční adresa nemůže být větší než koncová adresa.
  • V případě zápisu CIDR by IP adresa před znakem /měla být síťová adresa daného rozsahu (například 1.2.3.0/24 je platná, ale hodnota 1.2.3.4.4/24 není platná).

Jak můžu určit záložní koncový bod při použití směrování podsítě?

Pokud v profilu se směrováním podsítě máte koncový bod bez namapovaných podsítí, všechny požadavky, které se neshodují s jinými koncovými body, se sem směrují. Důrazně doporučujeme, abyste ve svém profilu měli takový záložní koncový bod, protože Traffic Manager vrátí odpověď NXDOMAIN, pokud přijde požadavek a není namapovaný na žádné koncové body nebo pokud je namapovaný na koncový bod, ale tento koncový bod není v pořádku.

Co se stane, když je koncový bod v profilu typu směrování podsítě zakázaný?

Pokud v profilu se směrováním podsítě máte koncový bod, který je zakázaný, Traffic Manager se chová, jako by tento koncový bod a mapování podsítí, které neexistuje. Pokud je přijat dotaz, který by odpovídal mapování IP adres a koncový bod je zakázaný, Traffic Manager vrátí záložní koncový bod (jeden bez mapování) nebo pokud takový koncový bod není k dispozici, vrátí odpověď NXDOMAIN.

Metoda směrování provozu Traffic Manageru s více hodnotami

Jaké jsou případy použití, kdy je užitečné směrování MultiValue?

Směrování MultiValue vrací více koncových bodů, které jsou v pořádku, v jedné odpovědi dotazu. Hlavní výhodou je to, že pokud koncový bod není v pořádku, má klient více možností opakování bez provedení jiného volání DNS (což může vrátit stejnou hodnotu z upstreamové mezipaměti). To platí pro aplikace citlivé na dostupnost, které chtějí minimalizovat výpadky. Další možností pro metodu směrování MultiValue je, že koncový bod je "duální domov" na adresy IPv4 i IPv6 a chcete volajícímu dát obě možnosti, ze které se má vybrat, když zahájí připojení ke koncovému bodu.

Kolik koncových bodů se vrátí při použití směrování MultiValue?

Můžete zadat maximální počet koncových bodů, které se mají vrátit, a MultiValue nevrátí více než tolik koncových bodů, které jsou v pořádku při přijetí dotazu. Maximální možná hodnota této konfigurace je 10.

Získám stejnou sadu koncových bodů při použití směrování MultiValue?

Nemůžeme zaručit, že se v každém dotazu vrátí stejná sada koncových bodů. To je také ovlivněno skutečností, že některé koncové body nemusí být v pořádku, v jakém okamžiku nebudou zahrnuty do odpovědi.

Měření reálných uživatelů

Jaké jsou výhody používání reálných měření uživatelů?

Když použijete metodu směrování výkonu, Traffic Manager vybere nejlepší oblast Azure, ke které se má koncový uživatel připojit, kontrolou zdrojové IP adresy a podsítě klienta EDNS (pokud je předána) a zkontroluje ji podle analýzy latence sítě, kterou služba udržuje. Měření skutečných uživatelů to vylepšuje pro vaši základnu koncových uživatelů tím, že jejich zkušenosti přispívají k této tabulce latence a navíc zajišťují, aby tato tabulka adekvátně překlenovala sítě koncových uživatelů z místa, kde se koncoví uživatelé připojují k Azure. To vede ke zvýšení přesnosti směrování koncového uživatele.

Můžu použít měření skutečných uživatelů s oblastmi mimo Azure?

Skutečná měření uživatelů měří a hlásí pouze latenci pro dosažení oblastí Azure. Pokud používáte směrování na základě výkonu s koncovými body hostovanými v oblastech mimo Azure, můžete tuto funkci využít i tak, že budete mít vyšší latenci o reprezentativní oblasti Azure, kterou jste vybrali pro přidružení k tomuto koncovému bodu.

Která metoda směrování přináší výhody měření skutečných uživatelů?

Další informace získané prostřednictvím měření skutečného uživatele platí pouze pro profily, které používají metodu směrování výkonu. Odkaz Měření skutečných uživatelů je k dispozici ze všech profilů, když ho zobrazíte prostřednictvím webu Azure Portal.

Musím povolit měření skutečných uživatelů zvlášť pro každý profil?

Ne, stačí ho povolit jenom jednou pro každé předplatné a všechny informace o latenci měřené a hlášené jsou k dispozici pro všechny profily.

Návody vypnout měření skutečných uživatelů pro moje předplatné?

Pokud zastavíte shromažďování a odesílání měření latence zpět z klientské aplikace, můžete přestat nabíhání poplatků souvisejících s měřením skutečného uživatele. Například při měření JavaScriptu vloženého do webových stránek můžete tuto funkci zastavit odebráním JavaScriptu nebo vypnutím jejího vyvolání při vykreslení stránky.

Pomocí odstranění klíče můžete také vypnout měření skutečných uživatelů. Po odstranění klíče se všechna měření odesílaná službě Traffic Manager s tímto klíčem zahodí.

Můžu použít měření skutečných uživatelů s jinými klientskými aplikacemi než webovými stránkami?

Ano, měření skutečných uživatelů je navržené tak, aby ingestová data shromážděná prostřednictvím různých typů klientů koncových uživatelů. Tyto nejčastější dotazy se aktualizují, protože se podporují nové typy klientských aplikací.

Kolik měření se provádí při každém vykreslení webové stránky s povolenou měřením skutečného uživatele?

Při použití měření skutečného uživatele se zadaným jazykem JavaScript se každé vykreslení stránky projeví v šesti měřeních. Ty se pak nahlásí zpět do služby Traffic Manager. Za tuto funkci se vám budou účtovat poplatky na základě počtu měření hlášených službě Traffic Manager. Pokud například uživatel při odebírání měření přejde mimo vaši webovou stránku, ale před nahlášením se tato měření nepovažují za účely fakturace.

Dochází ke zpoždění před spuštěním skriptu Měření skutečného uživatele na webové stránce?

Ne, před vyvolání skriptu neexistuje žádné naprogramované zpoždění.

Můžu použít měření skutečných uživatelů pouze s oblastmi Azure, které chci měřit?

Ne, pokaždé, když je vyvolána, skript Real User Measurements měří sadu šesti oblastí Azure podle toho, co služba určuje. Tato sada se mění mezi různými vyvoláním a v případě, že dojde k velkému počtu takových vyvolání, rozsah pokrytí měření napříč různými oblastmi Azure.

Můžu omezit počet měření provedených na konkrétní číslo?

Měření JavaScriptu se vloží na webovou stránku a máte úplnou kontrolu nad tím, kdy ji spustit a přestat používat. Pokud služba Traffic Manageru obdrží požadavek na měření seznamu oblastí Azure, vrátí se sada oblastí.

Můžu zobrazit měření pořízená klientskou aplikací jako součást měření skutečných uživatelů?

Vzhledem k tomu, že se logika měření spouští z klientské aplikace, máte plnou kontrolu nad tím, co se stane, včetně zobrazení měření latence. Traffic Manager nehlásí agregované zobrazení měření přijatých pod klíčem propojeným s vaším předplatným.

Můžu upravit měrný skript, který poskytuje Traffic Manager?

I když máte kontrolu nad tím, co je vložené na webové stránce, důrazně nedoporučujeme provádět žádné změny ve skriptu měření, aby se zajistilo, že měří a hlásí latence správně.

Bude možné, aby ostatní viděli klíč, který používám s měřením skutečného uživatele?

Když vložíte měrný skript na webovou stránku, je možné, aby ho ostatní viděli a klíč RUM (Real User Measurements). Je ale důležité vědět, že tento klíč se liší od ID vašeho předplatného a služba Traffic Manager ho vygeneruje, aby se k tomuto účelu používal. Znalost klíče RUM neohrožuje bezpečnost vašeho účtu Azure.

Mohou ostatní zneužít můj klíč RUM?

I když je možné, že váš klíč použije jiní uživatelé k odeslání nesprávných informací do Azure, několik nesprávných měření nezmění směrování, protože se bere v úvahu spolu se všemi ostatními měřeními, které dostáváme. Pokud potřebujete změnit klíče, můžete klíč znovu vygenerovat v okamžiku, kdy se starý klíč zahodí.

Musím do všech svých webových stránek vložit měrný JavaScript?

Real User Measurementss poskytuje větší hodnotu s rostoucím počtem měření. Když jste to řekli, je to vaše rozhodnutí, jestli ho potřebujete umístit na všechny webové stránky nebo vybrat několik. Naším doporučením je začít tím, že ho umístíte na nejnavštěvovanější stránku, kde se očekává, že uživatel zůstane na této stránce pět sekund nebo déle.

Dají se informace o koncových uživatelích identifikovat službou Traffic Manager, pokud používám měření skutečných uživatelů?

Při použití zadaného měření JavaScript má Traffic Manager přehled o IP adrese klienta koncového uživatele a zdrojové IP adrese místního překladače DNS, který používá. Traffic Manager používá IP adresu klienta až po zkrácení, aby nebyl schopen identifikovat konkrétního koncového uživatele, který měření odeslal.

Musí webová stránka měřit měření skutečných uživatelů pro směrování pomocí Traffic Manageru?

Ne, nemusí používat Traffic Manager. Směrovací strana Traffic Manageru funguje odděleně od části Měření skutečného uživatele a i když je vhodné je mít obě ve stejné webové vlastnosti, nemusí být.

Musím hostovat jakoukoli službu v oblastech Azure, aby bylo možné ji používat s měřením skutečného uživatele?

Ne, nemusíte hostovat žádnou komponentu na straně serveru v Azure, aby měření skutečných uživatelů fungovala. Jedna pixelová image stažená měřením JavaScript a služba, která ji spouští v různých oblastech Azure, je hostovaná a spravovaná v Azure.

Zvýší se využití šířky pásma Azure, když použijem měření skutečných uživatelů?

Jak je uvedeno v předchozí odpovědi, komponenty na straně serveru měření skutečných uživatelů jsou vlastněné a spravovány Azure. To znamená, že využití šířky pásma Azure se nezvýší, protože používáte měření skutečných uživatelů. Nezahrnuje žádné využití šířky pásma mimo poplatky za Azure. Minimalizujeme šířku pásma používanou stažením jenom jednoho pixelového obrázku k měření latence do oblasti Azure.

Zobrazení přenosů

Co dělá zobrazení provozu?

Traffic View je funkce Traffic Manageru, která vám pomůže pochopit více o uživatelích a jejich zkušenostech. Používá dotazy přijaté Traffic Managerem a tabulky analýzy latence sítě, které služba udržuje, aby vám poskytla následující:

  • Oblasti, ve kterých se nacházejí uživatelé, kteří se připojují k vašim koncovým bodům v Azure.
  • Objem uživatelů, kteří se připojují z těchto oblastí.
  • Oblasti Azure, do kterých se směrují.
  • Latence uživatelů se směrováním do těchto oblastí Azure.

Tyto informace můžete využívat prostřednictvím překrytí geografických map a tabulkových zobrazení na portálu, kromě toho, že jsou k dispozici jako nezpracovaná data, která si můžete stáhnout.

Jak můžu využít službu Traffic View?

Zobrazení provozu poskytuje celkový přehled o provozu, který vaše profily Traffic Manageru přijímají. Konkrétně se dá použít k tomu, abyste pochopili, odkud se vaše uživatelská základna připojuje, a stejně důležité, jaké je jejich průměrné latence. Tyto informace pak můžete použít k vyhledání oblastí, ve kterých se potřebujete zaměřit, například rozšířením využití Azure do oblasti, která může těmto uživatelům sloužit s nižší latencí. Dalším přehledem, který můžete odvodit ze zobrazení provozu, je vidět vzorce provozu do různých oblastí, které vám pak můžou pomoct při rozhodování o zvýšení nebo snížení vynalézavosti v těchto oblastech.

Jak se zobrazení provozu liší od metrik Traffic Manageru dostupných prostřednictvím služby Azure Monitor?

Azure Monitor se dá použít k pochopení agregované úrovně provozu přijatého vaším profilem a jeho koncovými body. Umožňuje také sledovat stav koncových bodů zveřejněním výsledků kontroly stavu. Pokud potřebujete tyto možnosti překročit a porozumět prostředí koncového uživatele, které se připojuje k Azure na regionální úrovni, můžete toho dosáhnout pomocí zobrazení provozu.

Používá zobrazení provozu informace o podsíti klienta EDNS?

Dotazy DNS obsluhované Azure Traffic Managerem zvažují informace ECS, aby se zvýšila přesnost směrování. Při vytváření datové sady, která ukazuje, odkud se uživatelé připojují, ale zobrazení provozu používá pouze IP adresu překladače DNS.

Kolik dní používá zobrazení provozu?

Zobrazení provozu vytvoří výstup tím, že zpracuje data ze sedmi dnů předcházejících dni, než je zobrazíte. Jedná se o pohyblivé okno a při každé návštěvě se použijí nejnovější data.

Jak zobrazení provozu zpracovává externí koncové body?

Pokud v profilu Traffic Manageru používáte externí koncové body hostované mimo oblasti Azure, můžete se rozhodnout, že se mapuje na oblast Azure, což je proxy server pro jeho charakteristiky latence (to je ve skutečnosti potřeba, pokud používáte metodu směrování výkonu). Pokud má toto mapování oblastí Azure, použijí se při vytváření výstupu Zobrazení provozu metriky latence oblasti Azure. Pokud není zadaná žádná oblast Azure, informace o latenci jsou v datech těchto externích koncových bodů prázdné.

Musím povolit zobrazení provozu pro každý profil v předplatném?

Během období Preview se zobrazení provozu povolilo na úrovni předplatného. Jako součást vylepšení, která jsme provedli před obecnou dostupností, teď můžete povolit zobrazení provozu na úrovni profilu, což vám umožní podrobnější povolení této funkce. Zobrazení provozu je ve výchozím nastavení pro profil zakázané.

Poznámka:

Pokud jste v době preview povolili zobrazení provozu na úrovni předplatného, musíte ho teď znovu povolit pro každý profil v rámci tohoto předplatného.

Jak můžu vypnout zobrazení provozu?

Zobrazení provozu můžete vypnout pro libovolný profil pomocí portálu nebo rozhraní REST API.

Jak funguje fakturace služby Traffic View?

Ceny služby Traffic View vycházejí z počtu datových bodů použitých k vytvoření výstupu. V současné době je jediným podporovaným datovým typem dotazy, které váš profil obdrží. Kromě toho se vám účtuje jenom zpracování, které bylo provedeno, když máte povolené zobrazení provozu. To znamená, že pokud povolíte zobrazení provozu po určitou dobu v měsíci a vypnete ho v jiných časech, budou se do faktury počítat jenom datové body zpracovávané v době, kdy jste měli povolenou funkci.

Koncové body Traffic Manageru

Můžu traffic manager používat s koncovými body z několika předplatných?

Použití koncových bodů z několika předplatných není možné s Azure Web Apps. Azure Web Apps vyžaduje, aby se v rámci jednoho předplatného používal jakýkoli vlastní název domény používaný ve službě Web Apps. Web Apps není možné používat z více předplatných se stejným názvem domény.

U jiných typů koncových bodů je možné použít Traffic Manager s koncovými body z více než jednoho předplatného. V Resource Manageru je možné do Traffic Manageru přidat koncové body z libovolného předplatného, pokud má uživatel konfigurující profil Traffic Manageru přístup ke čtení ke koncovému bodu. Tato oprávnění je možné udělit pomocí řízení přístupu na základě role v Azure (role Azure RBAC). Koncové body z jiných předplatných je možné přidat pomocí Azure PowerShellunebo Azure CLI.

Můžu použít Traffic Manager s přípravnými sloty cloudové služby?

Ano. Přípravné sloty cloudové služby je možné nakonfigurovat v Traffic Manageru jako externí koncové body. Kontroly stavu se stále účtují podle sazby za koncové body Azure.

Podporuje Traffic Manager koncové body IPv6?

Traffic Manager v současné době neposkytuje názvové servery Spv6 adresovatelnými adresami. Pokud rekurzivní server DNS klienta podporuje protokol IPv4, dají se přesto používat klienti IPv6, kteří se připojují ke koncovým bodům IPv6. Klient nesděluje požadavek DNS přímo do Traffic Manageru. Místo toho klient používá rekurzivní službu DNS. Klient pouze s protokolem IPv6 odesílá požadavky do rekurzivní služby DNS prostřednictvím protokolu IPv6. Rekurzivní služba pak musí být schopná kontaktovat názvové servery Traffic Manageru pomocí protokolu IPv4. Traffic Manager odpoví názvem DNS nebo IP adresou koncového bodu.

Můžu použít Traffic Manager s více než jednou webovou aplikací ve stejné oblasti?

Traffic Manager se obvykle používá k směrování provozu do aplikací nasazených v různých oblastech. Dá se ale použít také v případě, že má aplikace ve stejné oblasti více než jedno nasazení. Koncové body Azure Traffic Manageru neumožňují přidání více než jednoho koncového bodu webové aplikace ze stejné oblasti Azure do stejného profilu Traffic Manageru.

Návody přesunout koncové body azure profilu traffic manageru do jiné skupiny prostředků nebo předplatného?

Koncové body Azure, které jsou přidružené k profilu Traffic Manageru, se sledují pomocí jejich ID prostředků. Když se prostředek Azure, který se používá jako koncový bod (například veřejná IP adresa, klasická cloudová služba, webová aplikace nebo jiný profil Traffic Manageru použitý vnořeným způsobem), přesune se do jiné skupiny prostředků nebo předplatného, změní se ID prostředku. V tomto scénáři v současné době musíte profil Traffic Manageru aktualizovat tak, že nejprve odstraníte a pak přidáte koncové body do profilu.

Další informace najdete v tématu Přesunutí koncového bodu.

Monitorování koncových bodů Traffic Manageru

Je Traffic Manager odolný vůči selhání oblastí Azure?

Traffic Manager je klíčovou součástí doručování vysoce dostupných aplikací v Azure. Aby služba Traffic Manager poskytovala vysokou dostupnost, musí mít mimořádně vysokou úroveň dostupnosti a musí být odolná vůči regionálním selháním.

Komponenty Traffic Manageru jsou záměrně odolné vůči úplnému selhání jakékoli oblasti Azure. Tato odolnost se vztahuje na všechny komponenty Traffic Manageru: názvové servery DNS, rozhraní API, vrstvu úložiště a službu monitorování koncových bodů.

V nepravděpodobném případě výpadku celé oblasti Azure se očekává, že Traffic Manager bude normálně fungovat. Aplikace nasazené v několika oblastech Azure můžou pomocí Traffic Manageru směrovat provoz do dostupné instance aplikace.

Jaký vliv má volba umístění skupiny prostředků na Traffic Manager?

Traffic Manager je jedna globální služba. Není to regionální. Volba umístění skupiny prostředků nijak neliší od profilů Traffic Manageru nasazených v této skupině prostředků.

Azure Resource Manager vyžaduje, aby všechny skupiny prostředků určily umístění, které určuje výchozí umístění pro prostředky nasazené v této skupině prostředků. Když vytvoříte profil Traffic Manageru, vytvoří se ve skupině prostředků. Všechny profily Traffic Manageru používají jako umístění globální hodnoty , které přepíše výchozí skupinu prostředků.

Návody určit aktuální stav každého koncového bodu?

Aktuální stav monitorování jednotlivých koncových bodů se kromě celkového profilu zobrazí na webu Azure Portal. Tyto informace jsou k dispozici také prostřednictvím rozhraní REST API služby Traffic Monitor, rutin PowerShellu a azure CLI pro různé platformy.

Azure Monitor můžete také použít ke sledování stavu koncových bodů a k vizuálnímu znázornění těchto koncových bodů. Další informace o používání služby Azure Monitor najdete v dokumentaci k monitorování Azure.

Můžu monitorovat koncové body HTTPS?

Ano. Traffic Manager podporuje sondování přes PROTOKOL HTTPS. Nakonfigurujte https jako protokol v konfiguraci monitorování.

Traffic Manager nemůže poskytnout žádné ověření certifikátu, včetně:

  • Certifikáty na straně serveru se neověřují.
  • Certifikáty na straně serveru SNI se neověřují.
  • Klientské certifikáty se nepodporují.

Používám PŘI přidávání koncového bodu IP adresu nebo název DNS?

Traffic Manager podporuje přidávání koncových bodů pomocí tří způsobů, jak je odkazovat – jako název DNS, jako adresu IPv4 a jako adresu IPv6. Pokud se koncový bod přidá jako adresa IPv4 nebo IPv6, odpověď dotazu je typu záznamu A nebo AAAA. Pokud byl koncový bod přidán jako název DNS, odpověď dotazu je typu CNAME záznamu. Přidání koncových bodů jako adresy IPv4 nebo IPv6 je povoleno pouze v případě, že je koncový bod typu Externí. Všechny metody směrování a nastavení monitorování jsou podporovány třemi typy adresování koncových bodů.

Jaké typy IP adres můžu použít při přidávání koncového bodu?

Traffic Manager umožňuje zadat koncové body pomocí adres IPv4 nebo IPv6. Existuje několik omezení, která jsou uvedena níže:

  • Adresy, které odpovídají vyhrazeným adresám privátních IP adres, nejsou povolené. Tyto adresy zahrnují ty, které jsou uvedené v RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 a RFC 5771
  • Adresa nesmí obsahovat žádná čísla portů (můžete zadat porty, které se mají použít v nastavení konfigurace profilu).
  • Žádné dva koncové body ve stejném profilu můžou mít stejnou cílovou IP adresu.

Můžu v rámci jednoho profilu použít různé typy adresování koncových bodů?

Ne, Traffic Manager neumožňuje kombinovat typy adresování koncových bodů v rámci profilu, s výjimkou případu profilu s typem směrování MultiValue, kde můžete kombinovat typy adres IPv4 a IPv6.

Co se stane, když se typ záznamu příchozího dotazu liší od typu záznamu přidruženého k typu adresování koncových bodů?

Když se dotaz přijímá vůči profilu, Traffic Manager nejprve najde koncový bod, který se musí vrátit podle zadané metody směrování a stavu koncových bodů. Potom se podívá na typ záznamu požadovaný v příchozím dotazu a typ záznamu přidružený ke koncovému bodu před vrácením odpovědi na základě následující tabulky.

Pro profily s jinou metodou směrování než MultiValue:

Příchozí požadavek na dotaz Typ koncového bodu Poskytnutá odpověď
LIBOVOLNÉ A / AAAA / CNAME Cílový koncový bod
A A / CNAME Cílový koncový bod
A AAAA NODATA
AAAA AAAA / CNAME Cílový koncový bod
AAAA A NODATA
CNAME CNAME Cílový koncový bod
CNAME A / AAAA NODATA

Pro profily s metodou směrování nastavenou na MultiValue:

Příchozí požadavek na dotaz Typ koncového bodu Poskytnutá odpověď
LIBOVOLNÉ Kombinace A a AAAAA Cílové koncové body
A Kombinace A a AAAAA Pouze cílové koncové body typu A
AAAA Kombinace A a AAAAA Pouze cílové koncové body typu AAAA
CNAME Kombinace A a AAAAA NODATA

Můžu v vnořeném profilu použít profil s koncovými body adresovanými protokolem IPv4 nebo IPv6?

Ano, s výjimkou, že profil typu MultiValue nemůže být nadřazený profil v sadě vnořených profilů.

V profilu Traffic Manageru jsem zastavil koncový bod webové aplikace, ale nedostávám žádný provoz ani po restartování. Jak to můžu opravit?

Když je koncový bod webové aplikace Azure zastavený, Traffic Manager přestane kontrolovat jeho stav a restartuje kontroly stavu až po zjištění, že se koncový bod restartoval. Pokud chcete tomuto zpoždění zabránit, po restartování koncového bodu ho zakažte a potom znovu spusťte v profilu Traffic Manageru.

Můžu traffic manager použít i v případě, že moje aplikace nepodporuje protokol HTTP nebo HTTPS?

Ano. Protokol TCP můžete zadat jako monitorovací protokol a Traffic Manager může zahájit připojení TCP a čekat na odpověď z koncového bodu. Pokud koncový bod odpoví na žádost o připojení s odpovědí na navázání připojení v časovém limitu, označí se tento koncový bod jako v pořádku.

Jaké konkrétní odpovědi se vyžadují z koncového bodu při monitorování protokolu TCP?

Když se použije monitorování protokolu TCP, Traffic Manager spustí třícestný metodu handshake protokolu TCP odesláním požadavku SYN do koncového bodu na zadaný port. Potom počká na odpověď SYN-ACK z koncového bodu po určitou dobu (zadanou v nastavení časového limitu).

  • Pokud se odpověď SYN-ACK obdrží během časového limitu zadaného v nastavení monitorování, bude tento koncový bod považován za v pořádku. FIN nebo FIN-ACK je očekávaná odpověď od Traffic Manageru, když pravidelně ukončuje soket.
  • Pokud se po zadaném vypršení časového limitu obdrží odpověď SYN-ACK, Traffic Manager odpoví RST a resetuje připojení.

Jak rychle Traffic Manager přesune uživatele mimo koncový bod, který není v pořádku?

Traffic Manager poskytuje několik nastavení, která vám můžou pomoct řídit chování převzetí služeb při selhání profilu Traffic Manageru následujícím způsobem:

  • Můžete určit, že Traffic Manager testuje koncové body častěji nastavením intervalu sondování na 10 sekund. Tím se zajistí, že jakýkoli koncový bod, který není v pořádku, bude možné co nejdříve zjistit.
  • Můžete určit, jak dlouho čekat před vypršením časového limitu žádosti o kontrolu stavu (minimální hodnota časového limitu je 5 sekund).
  • Můžete určit, kolik selhání může nastat, než se koncový bod označí jako v pořádku. Tato hodnota může být nízká jako 0, v takovém případě je koncový bod označený jako špatný, jakmile selže při první kontrole stavu. Použití minimální hodnoty 0 pro tolerovaný počet selhání však může vést k vyřazení koncových bodů z rotace kvůli přechodným problémům, ke kterým může dojít v době sondy.
  • Hodnotu TTL (Time to Live) můžete zadat tak, aby odpověď DNS byla tak nízká jako 0. To znamená, že překladače DNS nemůžou odpověď ukládat do mezipaměti a každý nový dotaz získá odpověď, která obsahuje nejaktuálnější informace o stavu, které má Traffic Manager.

Pomocí těchto nastavení může Traffic Manager poskytovat převzetí služeb při selhání do 10 sekund po tom, co koncový bod není v pořádku a provede se dotaz DNS na odpovídající profil.

Jak můžu určit různá nastavení monitorování pro různé koncové body v profilu?

Nastavení monitorování Traffic Manageru jsou na úrovni profilu. Pokud potřebujete použít jiné nastavení monitorování pouze pro jeden koncový bod, můžete ho provést tak, že tento koncový bod použijete jako vnořený profil , jehož nastavení monitorování se liší od nadřazeného profilu.

Jak můžu přiřadit hlavičky HTTP kontrolám stavu Traffic Manageru ke koncovým bodům?

Traffic Manager umožňuje zadat vlastní hlavičky v kontrolách stavu HTTP(S), které iniciuje do vašich koncových bodů. Pokud chcete zadat vlastní hlavičku, můžete to udělat na úrovni profilu (platí pro všechny koncové body) nebo ji zadat na úrovni koncového bodu. Pokud je hlavička definovaná na obou úrovních, přepíše hlavička zadaná na úrovni koncového bodu úroveň profilu 1. Jedním z běžných případů použití je zadání hlaviček hostitele, aby se požadavky Traffic Manageru mohly správně směrovat do koncového bodu hostovaného ve víceklientských prostředích. Dalším případem použití je identifikace požadavků Traffic Manageru z protokolů požadavků HTTP(S) koncového bodu.

Jakou hlavičku hostitele používají kontroly stavu koncového bodu?

Pokud není k dispozici žádné nastavení hlavičky vlastního hostitele, hlavička hostitele používaná Traffic Managerem je název DNS cíle koncového bodu nakonfigurovaného v profilu, pokud je k dispozici.

Jaké jsou IP adresy, ze kterých pocházejí kontroly stavu?

V tomto článku se dozvíte, jak načíst seznamy IP adres, ze kterých můžou pocházet kontroly stavu Traffic Manageru. K načtení nejnovějšího seznamu můžete použít rozhraní REST API, Azure CLI nebo Azure PowerShell. Zkontrolujte uvedené IP adresy a ujistěte se, že jsou na koncových bodech povolená příchozí připojení z těchto IP adres a zkontrolujte jeho stav.

Příklad použití Azure PowerShellu:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

Poznámka:

Veřejné IP adresy se můžou bez předchozího upozornění změnit. Ujistěte se, že chcete načíst nejnovější informace pomocí rozhraní API zjišťování značek služby nebo souboru JSON ke stažení.

Kolik kontrol stavu do koncového bodu můžu od Traffic Manageru očekávat?

Počet kontrol stavu Traffic Manageru, které se dostanou do vašeho koncového bodu, závisí na následujících:

  • hodnota, kterou jste nastavili pro interval monitorování (menší interval znamená, že do koncového bodu v daném časovém období přistane více požadavků).
  • počet umístění, ze kterých pocházejí kontroly stavu (IP adresy, ze kterých můžete očekávat, že tyto kontroly jsou uvedené v předchozích nejčastějších dotazech).

Jak získám upozornění, když některý z mých koncových bodů přestane fungovat?

Jednou z metrik poskytovaných Traffic Managerem je stav koncových bodů v profilu. Můžete to vidět jako agregaci všech koncových bodů v profilu (například 75 % koncových bodů je v pořádku) nebo na úrovni jednotlivých koncových bodů. Metriky Traffic Manageru se zveřejňují prostřednictvím služby Azure Monitor a pomocí jejích možností upozorňování můžete dostávat oznámení, když dojde ke změně stavu vašeho koncového bodu. Další informace najdete v tématu Metriky a výstrahy Traffic Manageru.

Vnořené profily Traffic Manageru

Návody konfigurovat vnořené profily?

Vnořené profily Traffic Manageru je možné nakonfigurovat pomocí Azure Resource Manageru i klasických rozhraní AZURE REST API, rutin Azure PowerShellu a příkazů Azure CLI pro různé platformy. Podporují se také prostřednictvím nového webu Azure Portal.

Kolik vrstev vnoření traffic Manger podporuje?

Profily můžete vnořit až do hloubky 10 úrovní. Smyčky nejsou povoleny.

Můžu ve stejném profilu Traffic Manageru kombinovat jiné typy koncových bodů s vnořenými podřízenými profily?

Ano. Neexistují žádná omezení, jak kombinovat koncové body různých typů v rámci profilu.

Jak se model fakturace vztahuje na vnořené profily?

Použití vnořených profilů nemá žádný negativní dopad na ceny.

Fakturace Traffic Manageru má dvě komponenty: kontroly stavu koncových bodů a miliony dotazů DNS

  • Kontroly stavu koncového bodu: Za podřízený profil se neúčtují žádné poplatky, pokud je nakonfigurovaný jako koncový bod v nadřazeném profilu. Monitorování koncových bodů v podřízeného profilu se účtuje obvyklým způsobem.
  • Dotazy DNS: Každý dotaz se počítá pouze jednou. Dotaz na nadřazený profil, který vrací koncový bod z podřízeného profilu, se počítá pouze do nadřazeného profilu.

Úplné podrobnosti najdete na stránce s cenami služby Traffic Manager.

Má to vliv na výkon vnořených profilů?

Ne, při použití vnořených profilů nedojde k žádnému dopadu na výkon.

Názvové servery Traffic Manageru procházejí hierarchií profilů interně při zpracování každého dotazu DNS. Dotaz DNS na nadřazený profil může přijímat odpověď DNS s koncovým bodem z podřízeného profilu. Jeden záznam CNAME se používá bez ohledu na to, jestli používáte jeden profil nebo vnořené profily. Není potřeba vytvořit záznam CNAME pro každý profil v hierarchii.

Jak Traffic Manager vypočítá stav vnořeného koncového bodu v nadřazeného profilu?

Nadřazený profil neprovádí kontroly stavu u podřízeného objektu přímo. Místo toho se stav koncových bodů podřízeného profilu používá k výpočtu celkového stavu podřízeného profilu. Tyto informace se rozšíří do hierarchie vnořených profilů, aby bylo možné určit stav vnořeného koncového bodu. Nadřazený profil používá tento agregovaný stav k určení, jestli je možné provoz směrovat do podřízeného objektu.

Následující tabulka popisuje chování kontrol stavu Traffic Manageru pro vnořený koncový bod.

Stav monitorování podřízeného profilu Stav monitorování nadřazeného koncového bodu Notes
Deaktivováno. Podřízený profil byl zakázán. Zastaveno Nadřazený stav koncového bodu je Zastaveno, není zakázáno. Stav Zakázáno je vyhrazený pro označení, že jste zakázali koncový bod v nadřazeném profilu.
Degradované. Alespoň jeden koncový bod podřízeného profilu je v degradovaném stavu. Online: Počet koncových bodů Online v podřízeného profilu je alespoň hodnota MinChildEndpoints.
CheckEndpoint: Počet koncových bodů CheckEndpointu online plus CheckEndpoint v podřízeného profilu je alespoň hodnota MinChildEndpoints.
Degradováno: jinak.		 Provoz se směruje do koncového bodu CheckEndpoint stavu. Pokud je hodnota MinChildEndpoints nastavená příliš vysoká, je koncový bod vždy snížený.
Online. Alespoň jeden koncový bod podřízeného profilu je stav Online. Ve stavu Degraded není žádný koncový bod. Viz výše.
CheckEndpoints. Alespoň jeden koncový bod podřízeného profilu je CheckEndpoint. Žádné koncové body nejsou online nebo degradované. Platí to samé jako výše.
Neaktivní. Všechny koncové body podřízeného profilu jsou buď zakázané, nebo zastavené, nebo tento profil neobsahuje žádné koncové body. Zastaveno

Důležité

Při správě podřízených profilů v rámci nadřazeného profilu v Azure Traffic Manageru může dojít k problému, pokud současně zakážete a povolíte dva podřízené profily. Pokud k těmto akcím dojde současně, může dojít ke krátkému období, kdy jsou oba koncové body zakázány, což vede k tomu, že nadřazený profil zadává ohrožený stav.

Chcete-li se tomuto problému vyhnout, při provádění souběžných změn podřízených profilů buďte opatrní. Zvažte trochu zastřešování těchto akcí, abyste zabránili nezamýšleným přerušením konfigurace správy provozu.

Proč do profilu Traffic Manageru nemůžu přidat koncové body rozšířené podpory Azure Cloud Services?

Aby bylo možné přidat koncové body Rozšířené služby Azure Cloud do profilu Traffic Manageru, musí mít skupina prostředků kompatibilitu s rozhraním API pro správu služeb Azure (ASM). Profily umístěné ve starší skupině prostředků musí dodržovat standardy rozhraní ASM API, které zakazují zahrnutí koncových bodů veřejných IP adres nebo koncových bodů z jiného předplatného než profilu. Pokud chcete tento problém vyřešit, zvažte přesunutí profilu Traffic Manageru a přidružených prostředků do nové skupiny prostředků kompatibilní s rozhraním API ASM.

Další kroky: