Vanliga frågor och svar om Traffic Manager

  • Artikel

Grunderna i Traffic Manager

Vilken IP-adress använder Traffic Manager?

Som beskrivs i Hur Traffic Manager fungerar fungerar Traffic Manager på DNS-nivå (Domain Name System). Den skickar DNS-svar för att dirigera klienter till rätt tjänstslutpunkt. Klienterna ansluter sedan direkt till tjänstslutpunkten, inte via Traffic Manager.

Traffic Manager tillhandahåller därför ingen slutpunkt eller IP-adress för klienter att ansluta till. Om du vill ha en statisk IP-adress för din tjänst måste den konfigureras i tjänsten, inte i Traffic Manager.

Vilka typer av trafik kan dirigeras med Traffic Manager?

Som förklaras i Hur Traffic Manager fungerar kan en Traffic Manager-slutpunkt vara vilken Internetbaserad tjänst som helst som finns i eller utanför Azure. Därför kan Traffic Manager dirigera trafik som kommer från det offentliga Internet till en uppsättning slutpunkter som också är internetuppkopplade. Om du har slutpunkter som finns i ett privat nätverk (till exempel en intern version av Azure Load Balancer) eller har användare som gör DNS-begäranden från sådana interna nätverk kan du inte använda Traffic Manager för att dirigera trafiken.

Stöder Traffic Manager "klibbiga" sessioner?

Som förklaras i Hur Traffic Manager fungerar fungerar Traffic Manager på DNS-nivå. Det använder DNS-svar till att dirigera klienter till rätt tjänstslutpunkt. Klienter ansluter direkt till tjänstslutpunkten, inte via Traffic Manager. Traffic Manager ser därför inte HTTP-trafiken mellan klienten och servern.

Dessutom tillhör käll-IP-adressen för DNS-frågan som tas emot av Traffic Manager den rekursiva DNS-tjänsten, inte klienten. Därför har Traffic Manager inget sätt att spåra enskilda klienter och kan inte implementera "klibbiga" sessioner. Den här begränsningen är gemensam för alla DNS-baserade trafikhanteringssystem och är inte specifik för Traffic Manager.

Varför visas ett HTTP-fel när jag använder Traffic Manager?

Som förklaras i Hur Traffic Manager fungerar fungerar Traffic Manager på DNS-nivå. Det använder DNS-svar till att dirigera klienter till rätt tjänstslutpunkt. Klienterna ansluter sedan direkt till tjänstslutpunkten, inte via Traffic Manager. Traffic Manager ser inte HTTP-trafik mellan klient och server. Därför måste alla HTTP-fel du ser komma från din app. För att klienten ska kunna ansluta till programmet är alla DNS-matchningssteg slutförda. Det inkluderar all interaktion som Traffic Manager har i programmets trafikflöde.

Ytterligare undersökning bör därför inriktas på programmet.

HTTP-värdhuvudet som skickas från klientens webbläsare är den vanligaste orsaken till problem. Kontrollera att programmet är konfigurerat för att acceptera rätt värdhuvud för det domännamn som du använder. För slutpunkter som använder Azure App Service, se konfigurera ett anpassat domännamn för en webbapp i Azure App Service med Traffic Manager.

Hur löser jag ett 500-problem (internt serverfel) när jag använder Traffic Manager?

Om klienten eller programmet får ett HTTP 500-fel när du använder Traffic Manager kan detta orsakas av en inaktuell DNS-fråga. Lös problemet genom att rensa DNS-cachen och låta klienten utfärda en ny DNS-fråga.

När en tjänstslutpunkt inte svarar återställs inte klienter och program som använder slutpunkten förrän DNS-cachen har uppdaterats. Cachens varaktighet bestäms av TTL (time-to-live) för DNS-posten. Mer information finns i Traffic Manager och DNS-cachen.

Se även följande relaterade vanliga frågor och svar i den här artikeln:

Hur påverkas prestandan av att använda Traffic Manager?

Som förklaras i Hur Traffic Manager fungerar fungerar Traffic Manager på DNS-nivå. Eftersom klienter ansluter direkt till dina tjänstslutpunkter uppstår ingen prestandapåverkan när du använder Traffic Manager när anslutningen har upprättats.

Eftersom Traffic Manager integreras med program på DNS-nivå kräver det att ytterligare en DNS-sökning infogas i DNS-matchningskedjan. Effekten av Traffic Manager på DNS-matchningstiden är minimal. Traffic Manager använder ett globalt nätverk med namnservrar och använder anycast-nätverk för att säkerställa att DNS-frågor alltid dirigeras till närmaste tillgängliga namnserver. Dessutom innebär cachelagring av DNS-svar att den ytterligare DNS-svarstid som uppstår med hjälp av Traffic Manager endast gäller för en bråkdel av sessionerna.

Metoden Prestanda dirigerar trafik till den närmaste tillgängliga slutpunkten. Nettoresultatet är att den övergripande prestandapåverkan som är associerad med den här metoden ska vara minimal. En ökning av DNS-svarstiden bör förskjutas av lägre nätverksfördröjning till slutpunkten.

Vilka programprotokoll kan jag använda med Traffic Manager?

Som förklaras i Hur Traffic Manager fungerar fungerar Traffic Manager på DNS-nivå. När DNS-sökningen är klar ansluter klienterna direkt till programslutpunkten, inte via Traffic Manager. Därför kan anslutningen använda valfritt programprotokoll. Om du väljer TCP som övervakningsprotokoll kan Traffic Managers slutpunktshälsoövervakning göras utan att använda några programprotokoll. Om du väljer att ha hälsotillståndet verifierat med hjälp av ett programprotokoll måste slutpunkten kunna svara på HTTP- eller HTTPS GET-begäranden.

Kan jag använda Traffic Manager med ett "naken" domännamn?

Ja. Information om hur du skapar en aliaspost för ditt domännamns-apex för att referera till en Azure Traffic Manager-profil finns i Konfigurera en aliaspost för att stödja apex-domännamn med Traffic Manager.

Tar Traffic Manager hänsyn till klientens undernätsadress vid hantering av DNS-frågor?

Ja. Förutom DNS-frågans käll-IP-adress (vanligtvis DNS-matcharens IP-adress) tar Traffic Manager även hänsyn till klientens undernätsadress om den ingår i DNS-frågan som skickas av DNS-matcharen och skickar begäran åt slutanvändaren. Dessa IP-adresser används för att optimera geografiska metoder, prestanda och routningsmetoder för undernät. Mer specifikt tillhandahåller RFC 7871 – klientundernät i DNS-frågor en tilläggsmekanism för DNS (EDNS0) som kan skicka vidare klientens undernätsadress från matchare som stöder det.

Vad är DNS TTL och hur påverkar det mina användare?

När en DNS-fråga hamnar på Traffic Manager anger den ett värde i svaret time-to-live (TTL). Det här värdet, vars enhet är i sekunder, anger för DNS-matchare nedströms om hur länge svaret ska cachelagras. Dns-matchare är inte garanterade att cachelagra det här resultatet, men cachelagring gör att de kan svara på efterföljande frågor från cachen i stället för att gå till Traffic Manager DNS-servrar. Detta påverkar svaren på följande sätt:

  • en högre TTL minskar antalet frågor som hamnar på Traffic Manager DNS-servrarna, vilket kan minska kostnaden för en kund eftersom antalet frågor som hanteras är en fakturerbar användning.
  • en högre TTL kan potentiellt minska den tid det tar att göra en DNS-sökning.
  • en högre TTL innebär också att dina data inte återspeglar den senaste hälsoinformationen som Traffic Manager har fått via sina avsökningsagenter.

Hur högt eller lågt kan jag ange TTL för Traffic Manager-svar?

På profilnivå kan du ange att DNS TTL ska vara så lågt som 0 sekunder och så högt som 2 147 483 647 sekunder (det maximala intervallet är kompatibelt med RFC-1035). En TTL på 0 innebär att nedströms DNS-matchare inte cachelagrar frågesvar och att alla frågor förväntas nå Traffic Manager DNS-servrarna för matchning.

Hur kan jag förstå mängden frågor som kommer till min profil?

Ett av måtten som tillhandahålls av Traffic Manager är antalet frågor som besvaras av en profil. Du kan hämta den här informationen på en aggregering på profilnivå eller dela upp den ytterligare för att se volymen av frågor där specifika slutpunkter returnerades. Dessutom kan du konfigurera aviseringar för att meddela dig om frågesvarsvolymen överskrider de villkor som du har angett. Mer information finns i Traffic Manager-mått och aviseringar.

Hur lång tid tar det innan namnet på profilen kan återanvändas när jag tar bort en Traffic Manager-profil?

När du tar bort en Traffic Manager-profil reserveras det associerade domännamnet under en tidsperiod. Andra Traffic Manager-profiler i samma klientorganisation kan omedelbart återanvända namnet. En annan Azure-klientorganisation kan dock inte använda samma profilnamn förrän reservationen upphör att gälla. Med den här funktionen kan du behålla auktoriteten över de namnområden som du distribuerar, vilket eliminerar oron för att namnet kan tas av en annan klientorganisation.

Om ditt Traffic Manager-profilnamn till exempel är label1 är label1.trafficmanager.net reserverat för din klientorganisation även om du tar bort profilen. Underordnade namnområden, till exempel xyz.label1 eller 123.abc.label1 , är också reserverade. När reservationen upphör att gälla görs namnet tillgängligt för andra klienter. Namnet som är associerat med en inaktiverad profil är reserverat på obestämd tid. Kontakta din kontorepresentant om du vill ha frågor om hur lång tid ett namn är reserverat.

Traffic Manager Geografisk trafikroutningsmetod

Vilka är några användningsfall där geografisk routning är användbar?

Geografisk routningstyp kan användas i alla scenarier där en Azure-kund behöver särskilja sina användare baserat på geografiska regioner. Med metoden Geografisk trafikroutning kan du till exempel ge användare från specifika regioner en annan användarupplevelse än användare från andra regioner. Ett annat exempel är att följa lokala datasuveränitetsmandat som kräver att användare från en viss region endast hanteras av slutpunkter i den regionen.

Hur gör jag för att bestämma om jag ska använda prestandaroutningsmetod eller geografisk routningsmetod?

Den viktigaste skillnaden mellan dessa två populära routningsmetoder är att det primära målet i prestandaroutningsmetoden är att skicka trafik till slutpunkten som kan ge den lägsta svarstiden till anroparen, medan det primära målet i Geografisk routning är att framtvinga ett geo-staket för dina anropare så att du avsiktligt kan dirigera dem till en specifik slutpunkt. Överlappningen sker eftersom det finns en korrelation mellan geografisk närhet och kortare svarstid, även om detta inte alltid är sant. Det kan finnas en slutpunkt i ett annat geografiskt område som kan ge en bättre svarstid för anroparen och i så fall skickar prestandadirigering användaren till slutpunkten, men geografisk routning skickar dem alltid till den slutpunkt som du har mappat för deras geografiska region. För att ytterligare klargöra detta bör du överväga följande exempel – med geografisk routning kan du göra ovanliga mappningar, till exempel skicka all trafik från Asien till slutpunkter i USA och all amerikansk trafik till slutpunkter i Asien. I så fall gör geografisk routning avsiktligt exakt vad du har konfigurerat den att göra och prestandaoptimering är inte något att tänka på.

Kommentar

Det kan finnas scenarier där du kan behöva både prestanda och geografiska routningsfunktioner, för dessa scenarier kan kapslade profiler vara bra val. Du kan till exempel konfigurera en överordnad profil med geografisk routning där du skickar all trafik från Nordamerika till en kapslad profil som har slutpunkter i USA och använder prestandaroutning för att skicka trafiken till den bästa slutpunkten inom den uppsättningen.

Vilka regioner stöds av Traffic Manager för geografisk routning?

Den hierarki för land/region som används av Traffic Manager finns här. Även om den här sidan hålls uppdaterad med eventuella ändringar kan du även programmatiskt hämta samma information med hjälp av Rest-API:et för Azure Traffic Manager.

Hur avgör Traffic Manager var en användare frågar från?

Traffic Manager tittar på källans IP-adress för frågan (det här är troligen en lokal DNS-matchare som utför frågan för användarens räkning) och använder en intern IP-adress till regionkarta för att fastställa platsen. Den här kartan uppdateras löpande för att ta hänsyn till ändringar på Internet.

Är det garanterat att Traffic Manager kan fastställa den exakta geografiska platsen för användaren i varje enskilt fall?

Nej, Traffic Manager kan inte garantera att den geografiska region som vi härleder från käll-IP-adressen för en DNS-fråga alltid motsvarar användarens plats på grund av följande orsaker:

  • För det första, enligt beskrivningen i föregående vanliga frågor och svar, är käll-IP-adressen som vi ser för en DNS-matchare som gör sökningen för användarens räkning. Dns-matcharens geografiska plats är en bra proxy för användarens geografiska plats, men den kan också variera beroende på dns-matchningstjänstens fotavtryck och den specifika DNS-matchningstjänst som kunden har valt att använda. En kund i Malaysia kan till exempel i sina enhetsinställningar ange en DNS-matchningstjänst vars DNS-server i Singapore kan väljas för att hantera frågematchningarna för användaren/enheten. I så fall kan Traffic Manager bara se matcharens IP-adress som motsvarar Singapore-platsen. Se även tidigare vanliga frågor och svar om support för klientundernätsadresser på den här sidan.

  • För det andra använder Traffic Manager en intern karta för att göra IP-adressen till geografisk regionöversättning. Även om den här kartan verifieras och uppdateras kontinuerligt för att öka dess noggrannhet och ta hänsyn till internets föränderliga karaktär, finns det fortfarande en möjlighet att vår information inte är en exakt representation av den geografiska platsen för alla IP-adresser.

Måste en slutpunkt finnas fysiskt i samma region som den som den har konfigurerats med för geografisk routning?

Nej, slutpunktens plats medför inga begränsningar för vilka regioner som kan mappas till den. En slutpunkt i azure-regionen USA-centrala kan till exempel ha alla användare från Indien riktade till sig.

Kan jag tilldela geografiska regioner till slutpunkter i en profil som inte är konfigurerad för geografisk routning?

Ja, om routningsmetoden för en profil inte är geografisk kan du använda REST-API:et för Azure Traffic Manager för att tilldela geografiska regioner till slutpunkter i profilen. För profiler av icke-geografisk routningstyp ignoreras den här konfigurationen. Om du ändrar en sådan profil till geografisk routningstyp vid ett senare tillfälle kan Traffic Manager använda dessa mappningar.

Varför får jag ett fel när jag försöker ändra routningsmetoden för en befintlig profil till Geografisk?

Alla slutpunkter under en profil med geografisk routning måste ha minst en region mappad till den. Om du vill konvertera en befintlig profil till geografisk routningstyp måste du först associera geografiska regioner med alla dess slutpunkter med hjälp av Rest-API:et för Azure Traffic Manager innan du ändrar routningstypen till geografisk. Om du använder portalen tar du först bort slutpunkterna, ändrar routningsmetoden för profilen till geografisk och lägger sedan till slutpunkterna tillsammans med deras geografiska regionmappning.

En region kan bara tilldelas till en slutpunkt i en profil om den använder den geografiska routningsmetoden. Om slutpunkten inte är en kapslad typ med en underordnad profil kopplad till den, fortsätter Traffic Manager att skicka trafik till den om slutpunkten inte är felfri eftersom alternativet att inte skicka någon trafik inte är bättre. Traffic Manager redundansväxlar inte till en annan slutpunkt, även om den tilldelade regionen är en "överordnad" region som tilldelats den slutpunkt som inte är felfri (till exempel om en slutpunkt som har regionen Spanien inte är felfri, redundansväxlar vi inte över till en annan slutpunkt som har den tilldelade regionen Europa). Detta görs för att säkerställa att Traffic Manager respekterar de geografiska gränser som en kund har konfigurerat i sin profil. För att få fördelen med att redundansväxla till en annan slutpunkt när en slutpunkt blir felfritt rekommenderar vi att geografiska regioner tilldelas till kapslade profiler med flera slutpunkter i den i stället för enskilda slutpunkter. På så sätt kan trafiken redundansväxla till en annan slutpunkt i samma kapslade underordnade profil om en slutpunkt i den kapslade underordnade profilen misslyckas.

Finns det några begränsningar för API-versionen som stöder den här routningstypen?

Ja, endast API-version 2017-03-01 och senare stöder geografisk routningstyp. Äldre API-versioner kan inte användas för att skapa profiler av geografisk routningstyp eller tilldela geografiska regioner till slutpunkter. Om en äldre API-version används för att hämta profiler från en Azure-prenumeration returneras inte någon profil av geografisk routningstyp. När du använder äldre API-versioner visas dessutom inte någon profil som returneras som har slutpunkter med en geografisk regiontilldelning.

Traffic Manager-trafikroutningsmetod för undernät

Vilka är några användningsfall där routning av undernät är användbart?

Med routning av undernät kan du särskilja den upplevelse du levererar för specifika uppsättningar användare som identifieras av käll-IP-adressen för deras IP-adress för DNS-begäranden. Ett exempel skulle vara att visa annat innehåll om användarna ansluter till en webbplats från företagets huvudkontor. En annan skulle vara att begränsa användare från vissa Internetleverantörer till endast åtkomstslutpunkter som endast stöder IPv4-anslutningar om dessa Internetleverantörer har underpar-prestanda när IPv6 används. En annan anledning till att använda routningsmetoden för undernät är tillsammans med andra profiler i en kapslad profiluppsättning. Om du till exempel vill använda geografisk routningsmetod för geo-stängsel för dina användare, men för en specifik Internetleverantör som du vill utföra en annan routningsmetod, kan du ha en profil med routningsmetod för undernät som överordnad profil och åsidosätta den internetleverantören för att använda en specifik underprofil och ha standardprofilen Geografisk för alla andra.

Hur känner Traffic Manager till slutanvändarens IP-adress?

Slutanvändarenheter använder vanligtvis en DNS-matchare för att göra DNS-sökningen åt dem. Den utgående IP-adressen för sådana matchare är vad Traffic Manager ser som käll-IP. Dessutom ser routningsmetoden för undernät även ut för att se om det finns information om EDNS0 Extended Client Subnet (ECS) som skickades med begäran. Om ECS-information finns är det den adress som används för att fastställa routningen. I avsaknad av ECS-information används källans IP-adress för frågan i routningssyfte.

Hur anger jag IP-adresser när jag använder routning av undernät?

IP-adresserna som ska associeras med en slutpunkt kan anges på två sätt. Först kan du använda notationen quad dotted decimal octet med en start- och slutadress för att ange intervallet (till exempel 1.2.3.4-5.6.7.8 eller 3.4.5.6-3.4.5.6). För det andra kan du använda CIDR-notationen för att ange intervallet (till exempel 1.2.3.0/24). Du kan ange flera intervall och kan använda båda notationstyperna i en intervalluppsättning. Några begränsningar gäller.

  • Du kan inte överlappa adressintervall eftersom varje IP-adress bara behöver mappas till en enda slutpunkt
  • Startadressen får inte vara mer än slutadressen
  • För CIDR-notationen ska IP-adressen före "/" vara nätverksadressen för det intervallet (till exempel är 1.2.3.0/24 giltig men 1.2.3.4.4/24 är INTE giltig)

Hur anger jag en återställningsslutpunkt när jag använder routning av undernät?

Om du har en slutpunkt utan undernät mappade till en profil med undernätsroutning dirigeras alla begäranden som inte matchar andra slutpunkter till här. Vi rekommenderar starkt att du har en sådan återställningsslutpunkt i din profil eftersom Traffic Manager returnerar ett NXDOMAIN-svar om en begäran kommer in och den inte mappas till några slutpunkter eller om den mappas till en slutpunkt men slutpunkten inte är felfri.

Vad händer om en slutpunkt är inaktiverad i en profil för routningstyp för undernät?

Om du har en slutpunkt med inaktiverad i en profil med undernätsroutning fungerar Traffic Manager som om den slutpunkten och de undernätsmappningar som den har inte finns. Om en fråga som skulle ha matchats med dess IP-adressmappning tas emot och slutpunkten är inaktiverad returnerar Traffic Manager en återställningsslutpunkt (en utan mappningar) eller om en sådan slutpunkt inte finns returnerar ett NXDOMAIN-svar.

Traffic Manager MultiValue-trafikroutningsmetod

Vilka är några användningsfall där MultiValue-routning är användbart?

MultiValue-routning returnerar flera felfria slutpunkter i ett enda frågesvar. Den största fördelen med detta är att om en slutpunkt inte är felfri har klienten fler alternativ för att försöka igen utan att göra ett annat DNS-anrop (som kan returnera samma värde från en överordnad cache). Detta gäller för tillgänglighetskänsliga program som vill minimera stilleståndstiden. En annan användning för MultiValue-routningsmetod är om en slutpunkt är "dual-homed" till både IPv4- och IPv6-adresser och du vill ge anroparen båda alternativen att välja mellan när den initierar en anslutning till slutpunkten.

Hur många slutpunkter returneras när MultiValue-routning används?

Du kan ange det maximala antalet slutpunkter som ska returneras och MultiValue returnerar inte mer än så många felfria slutpunkter när en fråga tas emot. Det maximala möjliga värdet för den här konfigurationen är 10.

Får jag samma uppsättning slutpunkter när MultiValue-routning används?

Vi kan inte garantera att samma uppsättning slutpunkter returneras i varje fråga. Detta påverkas också av det faktum att vissa slutpunkter kan bli felaktiga då de inte tas med i svaret

Faktisk slutanvändarmätning

Vilka är fördelarna med att använda verkliga användarmått?

När du använder prestandaroutningsmetoden väljer Traffic Manager den bästa Azure-regionen som slutanvändaren kan ansluta till genom att granska käll-IP och EDNS-klientundernätet (om det skickas in) och kontrollera det mot den nätverkssvarstidsinformation som tjänsten underhåller. Verkliga användarmått förbättrar detta för slutanvändarbasen genom att deras upplevelse bidrar till den här svarstidstabellen, förutom att se till att den här tabellen på ett tillfredsställande sätt sträcker sig över slutanvändarnätverken där slutanvändarna ansluter till Azure. Detta leder till en ökad noggrannhet i routningen av slutanvändaren.

Kan jag använda verkliga användarmått med icke-Azure-regioner?

Real User Measurements mäter och rapporterar endast svarstiden för att nå Azure-regioner. Om du använder prestandabaserad routning med slutpunkter i icke-Azure-regioner kan du fortfarande dra nytta av den här funktionen genom att ha ökad svarstidsinformation om den representativa Azure-region som du hade valt att associeras med den här slutpunkten.

Vilken routningsmetod drar nytta av verkliga användarmätningar?

Den ytterligare information som erhålls via verkliga användarmätningar gäller endast för profiler som använder prestandadirigeringsmetoden. Länken Verkliga användarmått är tillgänglig från alla profiler när du visar den via Azure-portalen.

Behöver jag aktivera verkliga användarmått för varje profil separat?

Nej, du behöver bara aktivera den en gång per prenumeration och all svarstidsinformation som mäts och rapporteras är tillgänglig för alla profiler.

Hur gör jag för att inaktivera Verkliga användarmått för min prenumeration?

Du kan sluta påföra avgifter relaterade till verkliga användarmått när du slutar samla in och skicka tillbaka svarstidsmätningar från klientprogrammet. När du till exempel mäter JavaScript inbäddat på webbsidor kan du sluta använda den här funktionen genom att ta bort JavaScript eller genom att inaktivera dess anrop när sidan återges.

Du kan också inaktivera verkliga användarmått genom att ta bort nyckeln. När du har tagit bort nyckeln ignoreras alla mått som skickas till Traffic Manager med den nyckeln.

Kan jag använda verkliga användarmått med andra klientprogram än webbsidor?

Ja, Real User Measurements är utformat för att mata in data som samlas in via olika typer av slutanvändarklienter. Vanliga frågor och svar uppdateras när nya typer av klientprogram stöds.

Hur många mätningar görs varje gång min webbsida med verkliga användarmått aktiveras?

När Real User Measurements används med den javascript-mätning som tillhandahålls resulterar varje sidåtergivning i sex mätningar. Dessa rapporteras sedan tillbaka till Traffic Manager-tjänsten. Du debiteras för den här funktionen baserat på antalet mått som rapporteras till Traffic Manager-tjänsten. Om användaren till exempel navigerar bort från webbsidan medan mätningarna utförs men innan den rapporterades, beaktas inte dessa mått i faktureringssyfte.

Finns det en fördröjning innan skriptet För verkliga användarmätningar körs på min webbsida?

Nej, det finns ingen programmerad fördröjning innan skriptet anropas.

Kan jag bara använda verkliga användarmått med de Azure-regioner som jag vill mäta?

Nej, varje gång det anropas mäter skriptet Real User Measurements en uppsättning med sex Azure-regioner som bestäms av tjänsten. Den här uppsättningen ändras mellan olika anrop och när ett stort antal sådana anrop inträffar sträcker sig måtttäckningen över olika Azure-regioner.

Kan jag begränsa antalet mått som görs till ett visst tal?

JavaScript-måttet är inbäddat på webbsidan och du har fullständig kontroll över när du ska starta och sluta använda det. Så länge Traffic Manager-tjänsten tar emot en begäran om att en lista över Azure-regioner ska mätas returneras en uppsättning regioner.

Kan jag se de mått som görs av mitt klientprogram som en del av verkliga användarmätningar?

Eftersom måttlogik körs från klientprogrammet har du fullständig kontroll över vad som händer, inklusive att se svarstidsmåtten. Traffic Manager rapporterar inte en sammanställd vy över de mått som tas emot under nyckeln som är länkad till din prenumeration.

Kan jag ändra måttskriptet från Traffic Manager?

När du har kontroll över vad som är inbäddat på webbsidan avråder vi dig starkt från att göra ändringar i måttskriptet för att säkerställa att det mäter och rapporterar svarstiderna korrekt.

Kommer det att vara möjligt för andra att se nyckeln jag använder med verkliga användarmått?

När du bäddar in måttskriptet på en webbsida är det möjligt för andra att se skriptet och din RUM-nyckel (Real User Measurements). Men det är viktigt att veta att den här nyckeln skiljer sig från ditt prenumerations-ID och genereras av Traffic Manager för att endast användas för detta ändamål. Att känna till DIN RUM-nyckel kommer inte att äventyra säkerheten för ditt Azure-konto.

Kan andra missbruka min RUM-nyckel?

Det är möjligt för andra att använda din nyckel för att skicka fel information till Azure, men några felaktiga mått ändrar inte routningen eftersom den beaktas tillsammans med alla andra mått som vi får. Om du behöver ändra dina nycklar kan du återskapa nyckeln då den gamla nyckeln tas bort.

Behöver jag placera måttet JavaScript på alla mina webbsidor?

Real User Measurements ger mer värde i takt med att antalet mätningar ökar. Med det sagt är det ditt beslut om du behöver lägga till det på alla dina webbsidor eller några få utvalda. Vår rekommendation är att börja med att placera den på din mest besökta sida där en användare förväntas stanna på den sidan fem sekunder eller mer.

Kan information om mina slutanvändare identifieras av Traffic Manager om jag använder verkliga användarmått?

När den angivna mätningen JavaScript används har Traffic Manager insyn i klientens IP-adress för slutanvändaren och käll-IP-adressen för den lokala DNS-matchare som de använder. Traffic Manager använder bara klientens IP-adress efter att den trunkerats för att inte kunna identifiera den specifika slutanvändare som skickade måtten.

Behöver webbsidan som mäter verkliga användarmått använda Traffic Manager för routning?

Nej, den behöver inte använda Traffic Manager. Routningssidan i Traffic Manager fungerar separat från den verkliga användarmätningsdelen och även om det är en bra idé att ha dem båda i samma webbegenskap behöver de inte vara det.

Behöver jag vara värd för någon tjänst i Azure-regioner som ska användas med verkliga användarmått?

Nej, du behöver inte vara värd för någon komponent på serversidan i Azure för att verkliga användarmätningar ska fungera. Den bildpunktsbild som laddas ned av mätningen JavaScript och tjänsten som kör den i olika Azure-regioner hanteras av Azure.

Kommer min Användning av Azure-bandbredd att öka när jag använder verkliga användarmått?

Som vi nämnde i föregående svar ägs och hanteras komponenterna på serversidan i Real User Measurements av Azure. Det innebär att din Användning av Azure-bandbredd inte ökar eftersom du använder verkliga användarmått. Detta inkluderar inte någon bandbreddsanvändning utanför vad Azure debiterar. Vi minimerar den bandbredd som används genom att bara ladda ned en bildpunktsbild för att mäta svarstiden till en Azure-region.

Trafikvy

Vad gör trafikvyn?

Traffic View är en funktion i Traffic Manager som hjälper dig att förstå mer om dina användare och hur deras upplevelse är. Den använder de frågor som tas emot av Traffic Manager och tabellerna för nätverkssvarstidsinformation som tjänsten underhåller för att ge dig följande:

  • De regioner där användarna finns som ansluter till dina slutpunkter i Azure.
  • Mängden användare som ansluter från dessa regioner.
  • De Azure-regioner som de dirigeras till.
  • Användarnas svarstid kan dirigeras till dessa Azure-regioner.

Den här informationen är tillgänglig för dig att använda via geografisk kartöverlägg och tabellvyer i portalen förutom att vara tillgänglig som rådata som du kan ladda ned.

Hur kan jag dra nytta av att använda trafikvyn?

Trafikvyn ger dig den övergripande vyn över den trafik som Traffic Manager-profilerna tar emot. I synnerhet kan den användas för att förstå var din användarbas ansluter från och lika viktigt vad deras genomsnittliga svarstidsupplevelse är. Du kan sedan använda den här informationen för att hitta områden där du behöver fokusera, till exempel genom att utöka ditt Azure-fotavtryck till en region som kan ge användarna kortare svarstid. En annan insikt som du kan härleda från att använda trafikvyn är att se trafikmönstren till olika regioner, vilket i sin tur kan hjälpa dig att fatta beslut om att öka eller minska antalet invent i dessa regioner.

Hur skiljer sig Traffic View från Traffic Manager-måtten som är tillgängliga via Azure Monitor?

Azure Monitor kan användas för att på aggregerad nivå förstå vilken trafik som tas emot av din profil och dess slutpunkter. Du kan också spåra slutpunkternas hälsostatus genom att exponera hälsokontrollresultatet. När du behöver gå längre än dessa och förstå slutanvändarens upplevelse av att ansluta till Azure på regional nivå kan trafikvyn användas för att uppnå detta.

Använder trafikvyn EDNS-klientundernätsinformation?

DE DNS-frågor som hanteras av Azure Traffic Manager tar hänsyn till ECS-information för att öka noggrannheten i routningen. Men när du skapar datauppsättningen som visar var användarna ansluter från använder trafikvyn endast IP-adressen för DNS-matcharen.

Hur många dagars data använder trafikvyn?

Traffic View skapar sina utdata genom att bearbeta data från de sju dagarna före dagen innan när de visas av dig. Det här är ett rörligt fönster och de senaste data används varje gång du besöker.

Hur hanterar trafikvyn externa slutpunkter?

När du använder externa slutpunkter som finns utanför Azure-regioner i en Traffic Manager-profil kan du välja att mappa den till en Azure-region, vilket är en proxy för dess svarstidsegenskaper (detta behövs faktiskt om du använder prestandadirigeringsmetoden). Om den har den här Azure-regionmappningen används azure-regionens svarstidsmått när du skapar traffic view-utdata. Om ingen Azure-region anges är svarstidsinformationen tom i data för dessa externa slutpunkter.

Behöver jag aktivera Trafikvy för varje profil i min prenumeration?

Under förhandsgranskningsperioden aktiverades trafikvyn på prenumerationsnivå. Som en del av de förbättringar vi gjorde innan den allmänna tillgängligheten kan du nu aktivera Trafikvy på profilnivå, så att du kan ha mer detaljerad aktivering av den här funktionen. Som standard är trafikvyn inaktiverad för en profil.

Kommentar

Om du har aktiverat Trafikvy på prenumerationsnivå under förhandsversionen måste du nu återaktivera den för var och en av profilerna under den prenumerationen.

Hur inaktiverar jag trafikvyn?

Du kan inaktivera Trafikvy för valfri profil med hjälp av portalen eller REST-API:et.

Hur fungerar fakturering för Trafikvy?

Prissättningen för Traffic View baseras på antalet datapunkter som används för att skapa utdata. För närvarande är den enda datatyp som stöds de frågor som din profil tar emot. Dessutom debiteras du bara för bearbetningen som gjordes när du har trafikvyn aktiverad. Det innebär att om du aktiverar Trafikvy under en viss tidsperiod under en månad och inaktiverar den under andra tider, är det bara de datapunkter som bearbetas när du hade funktionen aktiverad för din faktura.

Traffic Manager-slutpunkter

Kan jag använda Traffic Manager med slutpunkter från flera prenumerationer?

Det går inte att använda slutpunkter från flera prenumerationer med Azure Web Apps. Azure Web Apps kräver att alla anpassade domännamn som används med Web Apps endast används i en enda prenumeration. Det går inte att använda Web Apps från flera prenumerationer med samma domännamn.

För andra slutpunktstyper är det möjligt att använda Traffic Manager med slutpunkter från mer än en prenumeration. I Resource Manager kan slutpunkter från valfri prenumeration läggas till i Traffic Manager, så länge personen som konfigurerar Traffic Manager-profilen har läsbehörighet till slutpunkten. Dessa behörigheter kan beviljas med rollbaserad åtkomstkontroll i Azure (Azure RBAC-roll). Slutpunkter från andra prenumerationer kan läggas till med hjälp av Azure PowerShell eller Azure CLI.

Kan jag använda Traffic Manager med "mellanlagringsplatser" för molntjänsten?

Ja. Molntjänstens mellanlagringsplatser kan konfigureras i Traffic Manager som externa slutpunkter. Hälsokontroller debiteras fortfarande enligt Azure Endpoints-priset.

Stöder Traffic Manager IPv6-slutpunkter?

Traffic Manager tillhandahåller för närvarande inte IPv6-adresserbara namnservrar. Traffic Manager kan dock fortfarande användas av IPv6-klienter som ansluter till IPv6-slutpunkter om klientens rekursiva DNS-server stöder IPv4. En klient gör inte DNS-begäran direkt till Traffic Manager. Klienten använder i stället en rekursiv DNS-tjänst. En klient med endast IPv6 skickar begäranden till den rekursiva DNS-tjänsten via IPv6. Den rekursiva tjänsten måste sedan kunna kontakta Traffic Manager-namnservrarna med hjälp av IPv4. Traffic Manager svarar med slutpunktens DNS-namn eller IP-adress.

Kan jag använda Traffic Manager med mer än en webbapp i samma region?

Normalt används Traffic Manager för att dirigera trafik till program som distribueras i olika regioner. Men det kan också användas där ett program har mer än en distribution i samma region. Traffic Manager Azure-slutpunkter tillåter inte att fler än en webbappslutpunkt från samma Azure-region läggs till i samma Traffic Manager-profil.

Hur gör jag för att flytta Min Traffic Manager-profilens Azure-slutpunkter till en annan resursgrupp eller prenumeration?

Azure-slutpunkter som är associerade med en Traffic Manager-profil spåras med hjälp av deras resurs-ID:n. När en Azure-resurs som används som slutpunkt (till exempel offentlig IP-adress, klassisk molntjänst, WebApp eller en annan Traffic Manager-profil som används på ett kapslat sätt) flyttas till en annan resursgrupp eller prenumeration ändras dess resurs-ID. I det här scenariot måste du uppdatera Traffic Manager-profilen genom att först ta bort och sedan lägga till slutpunkterna i profilen igen.

Mer information finns i Flytta en slutpunkt.

Slutpunktsövervakning för Traffic Manager

Är Traffic Manager motståndskraftigt mot fel i Azure-regionen?

Traffic Manager är en viktig komponent i leveransen av program med hög tillgänglighet i Azure. För att leverera hög tillgänglighet måste Traffic Manager ha en exceptionellt hög tillgänglighetsnivå och vara motståndskraftig mot regionala fel.

Traffic Manager-komponenter är avsiktligt motståndskraftiga mot ett fullständigt fel i alla Azure-regioner. Den här motståndskraften gäller för alla Traffic Manager-komponenter: DNS-namnservrarna, API:et, lagringsskiktet och slutpunktsövervakningstjänsten.

Vid ett osannolikt avbrott i en hel Azure-region förväntas Traffic Manager fortsätta att fungera normalt. Program som distribueras i flera Azure-regioner kan lita på att Traffic Manager dirigerar trafik till en tillgänglig instans av deras program.

Hur påverkar valet av resursgruppsplats Traffic Manager?

Traffic Manager är en enda global tjänst. Det är inte regionalt. Valet av resursgruppsplats gör ingen skillnad för Traffic Manager-profiler som distribueras i den resursgruppen.

Azure Resource Manager kräver att alla resursgrupper anger en plats som avgör standardplatsen för resurser som distribueras i den resursgruppen. När du skapar en Traffic Manager-profil skapas den i en resursgrupp. Alla Traffic Manager-profiler använder global som plats, vilket överskrider standardvärdet för resursgruppen.

Hur gör jag för att fastställa den aktuella hälsan för varje slutpunkt?

Den aktuella övervakningsstatusen för varje slutpunkt, utöver den övergripande profilen, visas i Azure-portalen. Den här informationen är också tillgänglig via Traffic Monitor REST API, PowerShell-cmdletar och plattformsoberoende Azure CLI.

Du kan också använda Azure Monitor för att spåra hälsotillståndet för dina slutpunkter och se en visuell representation av dem. Mer information om hur du använder Azure Monitor finns i dokumentationen om Azure Monitoring.

Kan jag övervaka HTTPS-slutpunkter?

Ja. Traffic Manager stöder avsökning via HTTPS. Konfigurera HTTPS som protokoll i övervakningskonfigurationen.

Traffic Manager kan inte tillhandahålla någon certifikatverifiering, inklusive:

  • Certifikat på serversidan verifieras inte
  • SNI-certifikat på serversidan verifieras inte
  • Klientcertifikat stöds inte

Använder jag en IP-adress eller ett DNS-namn när jag lägger till en slutpunkt?

Traffic Manager har stöd för att lägga till slutpunkter på tre sätt för att referera till dem – som ett DNS-namn, som en IPv4-adress och som en IPv6-adress. Om slutpunkten läggs till som en IPv4- eller IPv6-adress är frågesvaret av posttyp A respektive AAAA. Om slutpunkten lades till som ett DNS-namn är frågesvaret av posttypen CNAME. Det är endast tillåtet att lägga till slutpunkter som IPv4- eller IPv6-adress om slutpunkten är av typen Extern. Alla routningsmetoder och övervakningsinställningar stöds av de tre slutpunktsadresseringstyperna.

Vilka typer av IP-adresser kan jag använda när jag lägger till en slutpunkt?

Med Traffic Manager kan du använda IPv4- eller IPv6-adresser för att ange slutpunkter. Det finns några begränsningar som anges nedan:

  • Adresser som motsvarar reserverade privata IP-adressutrymmen tillåts inte. Dessa adresser inkluderar de som anges i RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 och RFC 5771
  • Adressen får inte innehålla några portnummer (du kan ange vilka portar som ska användas i profilkonfigurationsinställningarna)
  • Inga två slutpunkter i samma profil kan ha samma mål-IP-adress

Kan jag använda olika typer av slutpunktsadressering i en enda profil?

Nej, Traffic Manager tillåter inte att du blandar slutpunktsadresstyper i en profil, förutom för en profil med MultiValue-routningstyp där du kan blanda IPv4- och IPv6-adresseringstyper

Vad händer när en inkommande frågas posttyp skiljer sig från den posttyp som är associerad med adresstypen för slutpunkterna?

När en fråga tas emot mot en profil hittar Traffic Manager först slutpunkten som måste returneras enligt den angivna routningsmetoden och slutpunkternas hälsostatus. Den tittar sedan på den posttyp som begärdes i den inkommande frågan och posttypen som är associerad med slutpunkten innan ett svar returneras baserat på tabellen nedan.

För profiler med andra routningsmetoder än MultiValue:

Inkommande frågebegäran Slutpunktstyp Svar som tillhandahålls
NÅGON A/AAAA/CNAME Målslutpunkt
A A/CNAME Målslutpunkt
A AAAA NODATA
AAAA AAAA/CNAME Målslutpunkt
AAAA A NODATA
CNAME CNAME Målslutpunkt
CNAME A/AAAA NODATA

För profiler med routningsmetod inställd på MultiValue:

Inkommande frågebegäran Slutpunktstyp Svar som tillhandahålls
NÅGON Blandning av A och AAAA Målslutpunkter
A Blandning av A och AAAA Endast målslutpunkter av typen A
AAAA Blandning av A och AAAA Endast målslutpunkter av typen AAAA
CNAME Blandning av A och AAAA NODATA

Kan jag använda en profil med IPv4/IPv6-adresserade slutpunkter i en kapslad profil?

Ja, med undantag för att en profil av typen MultiValue inte kan vara en överordnad profil i en kapslad profiluppsättning.

Jag stoppade en webbappsslutpunkt i min Traffic Manager-profil, men jag får ingen trafik även efter att jag startat om den. Hur kan jag åtgärda detta?

När en Slutpunkt för ett Azure-webbprogram stoppas slutar Traffic Manager att kontrollera hälsotillståndet och startar om hälsokontrollerna först när slutpunkten har startats om. Om du vill förhindra den här fördröjningen inaktiverar du och kan sedan återaktivera slutpunkten i Traffic Manager-profilen när du har startat om slutpunkten.

Kan jag använda Traffic Manager även om mitt program inte har stöd för HTTP eller HTTPS?

Ja. Du kan ange TCP som övervakningsprotokoll och Traffic Manager kan initiera en TCP-anslutning och vänta på ett svar från slutpunkten. Om slutpunkten svarar på anslutningsbegäran med ett svar för att upprätta anslutningen markeras slutpunkten som felfri inom tidsgränsperioden.

Vilka specifika svar krävs från slutpunkten när du använder TCP-övervakning?

När TCP-övervakning används startar Traffic Manager en trevägs TCP-handskakning genom att skicka en SYN-begäran till slutpunkten på den angivna porten. Den väntar sedan på ett SYN-ACK-svar från slutpunkten under en tidsperiod (anges i timeout-inställningarna).

  • Om ett SYN-ACK-svar tas emot inom den tidsgräns som anges i övervakningsinställningarna anses slutpunkten vara felfri. EN FIN eller FIN-ACK är det förväntade svaret från Traffic Manager när den regelbundet avslutar en socket.
  • Om ett SYN-ACK-svar tas emot efter den angivna tidsgränsen svarar Traffic Manager med en RST för att återställa anslutningen.

Hur snabbt flyttar Traffic Manager mina användare från en slutpunkt med feltillstånd?

Traffic Manager innehåller flera inställningar som kan hjälpa dig att styra redundansbeteendet för din Traffic Manager-profil på följande sätt:

  • Du kan ange att Traffic Manager avsöker slutpunkterna oftare genom att ange avsökningsintervallet till 10 sekunder. Detta säkerställer att alla slutpunkter som inte är felfria kan identifieras så snart som möjligt.
  • du kan ange hur lång tid det tar att vänta innan tidsgränsen för en hälsokontrollbegäran uppnås (lägsta timeout-värde är 5 sek).
  • du kan ange hur många fel som kan inträffa innan slutpunkten markeras som felaktig. Det här värdet kan vara lågt som 0, vilket innebär att slutpunkten markeras som felaktig så snart den misslyckas med den första hälsokontrollen. Att använda minimivärdet 0 för det tolererade antalet fel kan dock leda till att slutpunkter tas ur rotation på grund av tillfälliga problem som kan uppstå vid tidpunkten för avsökningen.
  • du kan ange time-to-live (TTL) för DNS-svaret så lågt som 0. Detta innebär att DNS-matchare inte kan cachelagrar svaret och varje ny fråga får ett svar som innehåller den senaste hälsoinformationen som Traffic Manager har.

Med hjälp av de här inställningarna kan Traffic Manager tillhandahålla redundans under 10 sekunder efter att en slutpunkt inte är felfri och en DNS-fråga görs mot motsvarande profil.

Hur kan jag ange olika övervakningsinställningar för olika slutpunkter i en profil?

Övervakningsinställningarna för Traffic Manager finns på profilnivå. Om du behöver använda en annan övervakningsinställning för endast en slutpunkt kan du göra det genom att ha slutpunkten som en kapslad profil vars övervakningsinställningar skiljer sig från den överordnade profilen.

Hur kan jag tilldela HTTP-huvuden till Traffic Manager-hälsokontrollerna till mina slutpunkter?

Med Traffic Manager kan du ange anpassade huvuden i HTTP-hälsokontrollerna som initieras till slutpunkterna. Om du vill ange ett anpassat huvud kan du göra det på profilnivå (gäller för alla slutpunkter) eller ange det på slutpunktsnivå. Om ett huvud definieras på båda nivåerna åsidosätter den som anges på slutpunktsnivå profilnivån 1. Ett vanligt användningsfall för detta är att ange värdhuvuden så att Traffic Manager-begäranden kan dirigeras korrekt till en slutpunkt som finns i en miljö med flera klienter. Ett annat användningsfall för detta är att identifiera Traffic Manager-begäranden från en slutpunkts HTTP-begärandeloggar

Vilket värdhuvud använder slutpunktshälsokontroller?

Om ingen anpassad värdhuvudinställning anges är värdhuvudet som används av Traffic Manager DNS-namnet för slutpunktsmålet som konfigurerats i profilen, om det är tillgängligt.

Vilka IP-adresser kommer hälsokontrollerna från?

I den här artikeln får du lära dig hur du hämtar listor över IP-adresser som Traffic Manager-hälsokontroller kan komma från. Du kan använda REST API, Azure CLI eller Azure PowerShell för att hämta den senaste listan. Granska IP-adresserna i listan för att se till att inkommande anslutningar från dessa IP-adresser tillåts vid slutpunkterna för att kontrollera dess hälsostatus.

Exempel med Azure PowerShell:

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

Kommentar

Offentliga IP-adresser kan ändras utan föregående meddelande. Se till att hämta den senaste informationen med hjälp av API:et för identifiering av tjänsttagg eller nedladdningsbar JSON-fil.

Hur många hälsokontroller till min slutpunkt kan jag förvänta mig av Traffic Manager?

Antalet Traffic Manager-hälsokontroller som når slutpunkten beror på följande:

  • det värde som du har angett för övervakningsintervallet (mindre intervall innebär att fler begäranden landar på slutpunkten under en viss tidsperiod).
  • antalet platser där hälsokontrollerna kommer (IP-adresserna där du kan förvänta dig att dessa kontroller visas i föregående vanliga frågor och svar).

Hur får jag ett meddelande om någon av mina slutpunkter slutar fungera?

Ett av måtten som tillhandahålls av Traffic Manager är hälsostatusen för slutpunkter i en profil. Du kan se detta som en sammanställning av alla slutpunkter i en profil (till exempel att 75 % av dina slutpunkter är felfria) eller på slutpunktsnivå. Traffic Manager-mått exponeras via Azure Monitor och du kan använda dess aviseringsfunktioner för att få meddelanden när slutpunktens hälsostatus ändras. Mer information finns i Traffic Manager-mått och aviseringar.

Traffic Manager-kapslade profiler

Hur gör jag för att konfigurera kapslade profiler?

Kapslade Traffic Manager-profiler kan konfigureras med både Azure Resource Manager och klassiska Azure REST API:er, Azure PowerShell-cmdletar och plattformsoberoende Azure CLI-kommandon. De stöds också via den nya Azure-portalen.

Hur många lager av kapsling stöder Traffic Manger?

Du kan kapsla profiler upp till 10 nivåer djupt. "Loopar" är inte tillåtna.

Kan jag blanda andra slutpunktstyper med kapslade underordnade profiler i samma Traffic Manager-profil?

Ja. Det finns inga begränsningar för hur du kombinerar slutpunkter av olika typer i en profil.

Hur gäller faktureringsmodellen för kapslade profiler?

Det finns ingen negativ prispåverkan av att använda kapslade profiler.

Traffic Manager-faktureringen har två komponenter: hälsokontroller för slutpunkter och miljontals DNS-frågor

  • Hälsokontroller för slutpunkt: Det kostar ingenting för en underordnad profil när den konfigureras som en slutpunkt i en överordnad profil. Övervakning av slutpunkterna i den underordnade profilen faktureras på vanligt sätt.
  • DNS-frågor: Varje fråga räknas bara en gång. En fråga mot en överordnad profil som returnerar en slutpunkt från en underordnad profil räknas endast mot den överordnade profilen.

Fullständig information finns på prissättningssidan för Traffic Manager.

Finns det en prestandapåverkan för kapslade profiler?

Nej, det uppstår ingen prestandapåverkan när du använder kapslade profiler.

Traffic Manager-namnservrarna passerar profilhierarkin internt när varje DNS-fråga bearbetas. En DNS-fråga till en överordnad profil kan ta emot ett DNS-svar med en slutpunkt från en underordnad profil. En enda CNAME-post används oavsett om du använder en enda profil eller kapslade profiler. Du behöver inte skapa en CNAME-post för varje profil i hierarkin.

Hur beräknar Traffic Manager hälsotillståndet för en kapslad slutpunkt i en överordnad profil?

Den överordnade profilen utför inte hälsokontroller på barnet direkt. I stället används hälsotillståndet för den underordnade profilens slutpunkter för att beräkna den underordnade profilens övergripande hälsa. Den här informationen sprids upp i den kapslade profilhierarkin för att fastställa hälsotillståndet för den kapslade slutpunkten. Den överordnade profilen använder den här aggregerade hälsan för att avgöra om trafiken kan dirigeras till det underordnade.

I följande tabell beskrivs beteendet för Traffic Manager-hälsokontroller för en kapslad slutpunkt.

Övervakarstatus för underordnad profil Övervakningsstatus för överordnad slutpunkt Kommentar
Inaktiverat. Den underordnade profilen har inaktiverats. Stoppat Det överordnade slutpunktstillståndet är Stoppat, inte Inaktiverat. Inaktiverat tillstånd är reserverat för att ange att du har inaktiverat slutpunkten i den överordnade profilen.
Försämras. Minst en underordnad profilslutpunkt är i degraderat tillstånd. Online: antalet onlineslutpunkter i den underordnade profilen är minst värdet för MinChildEndpoints.
CheckingEndpoint: antalet Slutpunkter för Online plus CheckingEndpoint i den underordnade profilen är minst värdet för MinChildEndpoints.
Degraderad: annars.		 Trafiken dirigeras till en slutpunkt med statusen CheckingEndpoint. Om MinChildEndpoints anges för högt, degraderas alltid slutpunkten.
Online. Minst en underordnad profilslutpunkt är ett onlinetillstånd. Ingen slutpunkt är i degraderat tillstånd. Se ovan.
CheckEndpoints. Minst en underordnad profilslutpunkt är "CheckingEndpoint". Inga slutpunkter är "Online" eller "Degraderade" Samma som ovan.
Inaktiva. Alla underordnade profilslutpunkter är antingen Inaktiverade eller Stoppade, eller så har profilen inga slutpunkter. Stoppat

Viktigt!

När du hanterar underordnade profiler under en överordnad profil i Azure Traffic Manager kan ett problem uppstå om du inaktiverar och aktiverar två underordnade profiler samtidigt. Om dessa åtgärder utförs samtidigt kan det finnas en kort period när båda slutpunkterna är inaktiverade, vilket leder till att den överordnade profilen går in i ett komprometterat tillstånd.

Undvik det här problemet genom att vara försiktig när du gör samtidiga ändringar i underordnade profiler. Överväg att häpnadsväckande dessa åtgärder något för att förhindra oavsiktliga störningar i din trafikhanteringskonfiguration.

Varför kan jag inte lägga till Azure Cloud Services utökade supportslutpunkter i min Traffic Manager-profil?

För att kunna lägga till Azure Cloud Extended-slutpunkter i en Traffic Manager-profil måste resursgruppen ha kompatibilitet med AZURE Service Management-API:et (ASM). Profiler som finns i den äldre resursgruppen måste följa ASM API-standarder, vilket förbjuder inkludering av offentliga IP-adressslutpunkter eller slutpunkter från en annan prenumeration än profilens. Lös problemet genom att flytta din Traffic Manager-profil och associerade resurser till en ny resursgrupp som är kompatibel med ASM-API:et.

Nästa steg:

  • Läs mer om traffic manager-slutpunktsövervakning och automatisk redundans.
  • Läs mer om Traffic Manager-trafikroutningsmetoder.