Vanliga frågor och svar om Traffic Manager

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 internetanslutna. 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.

Har Traffic Manager stöd för "fasta" 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 beständiga 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änstendpoint. 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 måste alla DNS-upplösningssteg vara slutförda. Det inkluderar all interaktion som Traffic Manager har på programmets trafikflöde.

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

HTTP-värdhuvudet som skickas från klientens webbläsare är den vanligaste orsaken till problem. Kontrollera att applikationen är konfigurerad för att acceptera rätt host header 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-cachepost. 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:

• Vad är DNS TTL och hur påverkar det mina användare?
• Hur högt eller lågt kan jag ange TTL för Traffic Manager-svar?
• Hur kan jag förstå mängden frågor som kommer till min profil?

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-upplösningskedjan. Effekten av Traffic Manager på tiden för DNS-namnupplösning ä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 Performance 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 kompenseras av lägre nätverksfördröjning till slutpunkten.

Vilka applikationsprotokoll 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 applikationsslutpunkten, inte via Traffic Manager. Därför kan anslutningen använda valfritt applikationsprotokoll. 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 få hälsan verifierad med hjälp av ett applikationsprotokoll måste slutpunkt kunna svara på HTTP- eller HTTPS GET-begäranden.

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

Ja. För att lära dig hur man använder Traffic Manager vid domänroten, se Traffic Manager Linked Records, vilket är den rekommenderade metoden. Traffic Manager Linked Records returnerar IP-adresser direkt utan ett CNAME-hopp. Du kan också använda en aliaspost – se 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-resolverns IP-adress) tar Traffic Manager även hänsyn till klientens undernätsadress om den ingår i DNS-frågan som skickas av DNS-resolvern som skickar begäran för slutanvändaren. Dessa IP-adresser används för att optimera metoder för geografisk routning, prestandaroutning och undernätsroutning. Mer specifikt tillhandahåller RFC 7871 – klientundernät i DNS-frågor en tilläggsmekanism för DNS (EDNS0) som kan vidarebefordra klientens undernätsadress från resolvere som stöder detta.

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-resolver nedströms om hur länge svaret ska cachelagras. Det finns ingen garanti för att DNS-resolverare cachelagrar 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 förfrågningar som hamnar på Traffic Manager DNS-servrarna, vilket kan minska kostnaden för en kund eftersom antalet förfrågningar som hanteras är en debiterbar 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-resolvere inte cachelagrar frågesvar och att alla frågor förväntas nå Traffic Manager DNS-servrarna för namnupplösning.

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

Ett av måtten som tillhandahålls av Traffic Manager är antalet förfrågningar som besvaras av en profil. Du kan hämta den här informationen som en aggregering på profilnivå eller dela upp den ytterligare för att se volymen av frågor där specifika ändpunkter 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 driftsätter, vilket eliminerar oron för att namnet kan tas av en annan klientorganisation.

Om ditt Traffic Manager-profilnamn till exempel är label1, då ä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 har frågor om hur lång tid ett namn är reserverat.

Vilken version av TLS krävs av Traffic Manager?

Microsoft-implementeringen av äldre TLS-versioner är inte känd för att vara sårbar, men TLS 1.2 och senare erbjuder förbättrad säkerhet med funktioner som perfekt framåtsekretess och starkare chiffreringssviter. För att förbättra säkerheten och tillhandahålla förstklassig kryptering för dina data kräver Traffic Manager att interaktioner med tjänster skyddas med TLS (Transport Layer Security) 1.2 eller senare före den 28 februari 2025. Traffic Manager-stöd för TLS 1.0 och 1.1 upphör det här datumet. Det här datumet kan skilja sig från det Azure-omfattande avvecklingsdatumet för TLS 1.0 och TLS 1.1.

Rekommenderad åtgärd

För att undvika avbrott i tjänsten måste resurser som interagerar med Traffic Manager använda TLS 1.2 eller senare.

• Om resurser redan uteslutande använder TLS 1.2 eller senare behöver du inte vidta ytterligare åtgärder.
• Om resurserna fortfarande är beroende av TLS 1.0 eller 1.1, migrerar du dem till TLS 1.2 eller senare senast den 28 februari 2025.

Information om hur du migrerar från TLS 1.0 och 1.1 till TLS 1.2 finns i Lösa problemet med TLS 1.0.

Vilka TLS-chiffersviter stöds av Azure Traffic Manager?

Azure Traffic Manager stöder moderna TLS-chiffersviter för TLS 1.2 och TLS 1.3 för att säkerställa säker kommunikation. Följande chiffersviter stöds:

TLS 1.3 Chiffersviter

Dessa är associerade med protokoll 772 (vilket motsvarar TLS 1.3):

TLS 1.2 Chiffersviter

Dessa är associerade med protokoll 771 (TLS 1.2) och/eller 65277 (används av vissa system som en intern/anpassad kod för TLS 1.2):

Dessa chiffersviter ger stark kryptering och är kompatibla med moderna säkerhetsstandarder. Traffic Manager förhandlar automatiskt om den bästa tillgängliga chiffersviten under TLS-handskakningsprocessen.

Traffic Manager metod för geografisk trafikdirigering

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 routningsmetoden Prestanda eller routningsmetoden Geografisk?

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 geostängsel 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å.

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

Hierarkin 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 Azure Traffic Manager REST API.

Hur avgör Traffic Manager varifrån en användare skickar frågan?

Traffic Manager tittar på källans IP-adress för frågan (det här är troligen en lokal DNS-resolver som utför frågan för användarens räkning) och använder en intern mappning från IP-adress till region för att fastställa den geografiska 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 FAQ, är den käll-IP-adress vi ser den för en DNS-resolver som gör sökningen för användarens räkning. DNS-resolverns geografiska plats är en bra proxy för användarens geografiska plats, men den kan också variera beroende på DNS-resolvertjänstens fotavtryck och den specifika DNS-resolvertjänst som kunden har valt att använda. En kund i Malaysia kan till exempel i sina enhetsinställningar ange en DNS-resolvertjänst vars DNS-server i Singapore kan väljas för att hantera frågeupplösningarna för användaren/enheten. I så fall kan Traffic Manager bara se resolverns IP-adress som motsvarar platsen i Singapore. Se även tidigare vanliga frågor och svar om stöd för klientundernätsadresser på den här sidan.

• För det andra använder Traffic Manager en intern mappning för att översätta IP-adressen till en geografisk region. Ä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 styra alla användare från Indien till den.

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 Azure Traffic Manager REST API 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 Azure Traffic Manager REST API:et innan du ändrar routningstypen till geografisk. Om du använder portalen tar du först bort slutpunkter, ändrar routningsmetoden för profilen till geografisk och lägger sedan till slutpunkter tillsammans med deras geografiska regionmappning.

Varför rekommenderar vi starkt att kunder skapar kapslade profiler i stället för slutpunkter under en profil med geografisk routning aktiverad?

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 blir felaktig, 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 blev felaktig (till exempel om en slutpunkt som har regionen Spanien blev felaktig, 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 felaktig 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 den geografiska regiontilldelningen för profiler som returneras och har slutpunkter med en geografisk regiontilldelning.

trafikroutningsmetod för Traffic Manager-undernät

Vilka användningsområden finns det där routing av undernät är användbar?

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 DNS-begäranden. Ett exempel skulle vara att visa annat innehåll om användarna ansluter till en webbplats från företagets huvudkontor. Ett annat alternativ vore att begränsa användare hos vissa internetleverantörer till att bara få åtkomst till slutpunkter som endast stöder IPv4-anslutningar om dessa internetleverantörer har underpresterande 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 geostängsling för dina användare, men för en specifik internetleverantör vill använda 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-resolver för att göra DNS-sökningen för deras räkning. Den utgående IP-adressen för sådana DNS-resolverare är vad Traffic Manager ser som käll-IP. Dessutom kontrollerar undernätets routningsmetod även 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 frågans käll-IP-adress i routningssyfte.

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

IP-adresserna som ska associeras med en ändpunkt 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 måste mappas till en enda slutpunkt
• Startadressen får inte vara större ä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 reservslutpunkt när jag använder routning av undernät?

I en profil med undernätsroutning dirigeras alla begäranden som inte matchar andra slutpunkter hit om du har en slutpunkt utan undernät mappade till den. Vi rekommenderar starkt att du har en sådan reservslutpunkt 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 endpoint är inaktiverad i en profil för routningstyp för undernät?

Om du har en slutpunkt som är 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 Traffic Manager ett NXDOMAIN-svar.

Traffic Manager MultiValue-trafikroutningsmetod

I vilka fall är MultiValue-routning användbar?

MultiValue-routning returnerar flera felfria slutpunkter i ett enda frågesvar. Den största fördelen med detta är att om en ändpunkt inte fungerar korrekt 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 uppströmscache). 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 endpoints som ska returneras och MultiValue returnerar inte mer än så många felfria endpoints när en förfrågan 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 endpoints returneras i varje query. Detta påverkas också av det faktum att vissa slutpunkter kan bli otillgängliga då de inte tas med i svaret

Mätningar av verkliga användare

Vilka är fördelarna med att använda Real User Measurements?

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. Real User Measurements förbättrar detta för era slutanvändare genom att deras upplevelse bidrar till den här svarstidstabellen, utöver att säkerställa att den här tabellen täcker slutanvändarnas nätverk på ett tillräckligt sätt där era slutanvändare ansluter till Azure. Detta leder till en ökad noggrannhet i routningen till slutanvändaren.

Kan jag använda Real User Measurements med icke-Azure-regioner?

Real User Measurements mäter och rapporterar endast latensen 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 få mer svarstidsinformation om den representativa Azure-region som du hade valt att associera 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 Real User Measurements (Verkliga användarmått) är tillgänglig från alla profiler när du visar den via Azure Portal.

Behöver jag aktivera Real User Measurements separat för varje profil?

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 Real User Measurements för min prenumeration?

Du kan sluta få avgifter relaterade till Real User Measurements när du slutar samla in och skicka tillbaka svarstidsmätningar från klientprogrammet. Om du till exempel använder inbäddad JavaScript-kod för mätning på webbsidor kan du sluta använda den här funktionen genom att ta bort JavaScript-koden eller genom att inaktivera dess anrop när sidan återges.

Du kan också inaktivera Real User Measurements genom att ta bort din nyckel. När du har tagit bort nyckeln ignoreras alla mått som skickas till Traffic Manager med den nyckeln.

Kan jag använda Real User Measurements med andra klientprogram än webbsidor?

Ja, Real User Measurements är utformat för att ta emot 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 Real User Measurements renderas?

När Real User Measurements används med det tillhandahållna JavaScriptet för mätning 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ätvärden som rapporteras till Traffic Manager-tjänsten. Om användaren till exempel navigerar bort från webbsidan medan mätningarna utförs men innan de rapporterades, beaktas inte dessa mätningar i faktureringssyfte.

Finns det en fördröjning innan skriptet Real User Measurements körs på min webbsida?

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

Kan jag använda Real User Measurements med bara 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ätningar som görs till ett visst tal?

JavaScript-koden för mätning är inbäddad i webbsidan och du har fullständig kontroll över när du ska starta och sluta använda den. När 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ätningar som samlas in av mitt klientprogram som en del av mätningar av verkliga användare?

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ätvärden som tas emot under nyckeln som är länkad till din prenumeration.

Kan jag ändra mätskriptet 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ätskriptet 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 Real User Measurements?

När du bäddar in mätskriptet 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ätvärden ändrar inte routningen eftersom den beaktas tillsammans med alla andra mätvärden som vi får. Om du behöver ändra dina nycklar kan du generera om nyckeln då den gamla nyckeln tas bort.

Behöver jag placera JavaScript-kod för mätning 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 Real User Measurements?

När det angivna JavaScript-mätskriptet används har Traffic Manager insyn i klientens IP-adress för slutanvändaren och käll-IP-adressen för den lokala DNS-resolvern som slutanvändaren 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ätningarna.

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 delen för Real User Measurement, och även om det är en bra idé att ha dem båda i samma webbegendom behöver de inte vara det.

Behöver jag hosta någon tjänst i Azure-regioner för att använda med Real User Measurements?

Nej, du behöver inte hosta någon komponent på serversidan i Azure för att Real User Measurements ska fungera. Bilden med en enda pixel som laddas ned av mätnings-JavaScriptet och tjänsten som kör det i olika Azure-regioner hostas och 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 Real User Measurements. 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 förfrågningar 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-regionerna som de dirigeras till.
• Användarnas trafik kan dirigeras till dessa Azure-regioner.

Den här informationen kan användas via kartöverlagringar på geografiska kartor och i tabellvyer i portalen, och finns dessutom tillgänglig som rådata för nedladdning.

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 Traffic View är att se trafikmönstren till olika regioner, vilket i sin tur kan hjälpa dig att fatta beslut om att öka eller minska lagret 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 visa resultaten från hälsokontrollerna. 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 Traffic View användas för att uppnå detta.

Använder Traffic View 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-resolvern.

Hur många dagars data använder trafikvyn?

Traffic View skapar sina utdata genom att bearbeta data från de sju dagarna före gårdagen när du tittar på den. Det här är ett glidande tidsfönster och de senaste data används varje gång du besöker.

Hur hanterar Traffic View 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.

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 Traffic View?

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 som räknas med på 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 Cloud Service-"Staging"-slotar?

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

Stöder Traffic Manager IPv6-slutpunkter?

Ja, Traffic Manager har fullt stöd för IPv6-slutpunkter. Traffic Manager tillhandahåller både IPv4- och IPv6-adresserbara namnservrar, vilket gör att klienter kan ansluta sömlöst med något av protokollen. IPv6-klienter kan göra DNS-begäranden direkt via IPv6-aktiverade rekursiva DNS-tjänster, och Traffic Manager kan svara med DNS-namnet eller IP-adressen för IPv6-slutpunkten, vilket möjliggör fullständig kompatibilitet med IPv6-nätverk.

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 driftsättning 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 Azure-slutpunkterna i min Traffic Manager-profil 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 Så här flyttar du en slutpunkt.

Har Azure Traffic Manager stöd för IPv6-tilläggsmekanismer för DNS (ECS)?

Azure Traffic Manager stöder IPv6-adresser med tilläggsmekanismer för DNS (ECS). Det innebär att när en DNS-fråga innehåller ECS-information kan Azure Traffic Manager använda käll-IP-adressen i ECS för att fatta intelligenta routningsbeslut.

Stödet för IPv6 ECS medför flera fördelar:

• Förbättrad lokalisering: Genom att överväga IPv6-adressen i ECS kan Traffic Manager dirigera användare till närmaste eller lämpligaste slutpunkt, vilket förbättrar användarupplevelsen med kortare svarstid.
• Förbättrad trafikkontroll: IPv6 ECS möjliggör mer detaljerade trafikdirigeringsbeslut, vilket möjliggör bättre hantering av global trafik och distribution.

När du använder IPv6 ECS är det viktigt att se till att dina slutpunkter är korrekt konfigurerade för att hantera IPv6-trafik. Kontrollera också att DNS-infrastrukturen, inklusive rekursiva resolver, kan hantera ECS-information med IPv6-adresser.

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 applikationer 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 utformade för att vara motståndskraftiga mot ett fullständigt fel i en valfri Azure-region. 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. Applikationer som distribueras i flera Azure-regioner kan lita på att Traffic Manager dirigerar trafik till en tillgänglig instans av deras applikation.

Hur påverkar valet av resursgruppsplats Traffic Manager?

Traffic Manager är en enda global tjänst. Det är inte regionalt. Valet av resursgruppens plats 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 åsidosätter resursgruppens standardvärde.

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

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

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

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 ändpunkt?

Traffic Manager har stöd för att lägga till slutpunkter på tre sätt för att referera till dem:

• Som DNS-namn
• Som en IPv4-adress
• 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 ändpunkt?

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.
• IP-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?

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

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 förfrågan 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 endpointen innan ett svar returneras baserat på tabellen nedan.

För profiler med någon routningsmetod annan än MultiValue:

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

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 slutpunkt för webbappen i min Traffic Manager-profil, men jag får ingen trafik även efter att jag startat den igen. 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 aktiverar sedan den slutpunkten igen 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 inom tidsgränsen markeras slutpunkten som fungerande.

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 TCP-trevägshandskakning 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 felaktig slutpunkt?

Traffic Manager innehåller flera inställningar som kan hjälpa dig att styra redundansväxlingsbeteendet 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 blir ohälsosamma kan identifieras så snart som möjligt.
• du kan ange hur länge du ska vänta innan en hälsokontrollbegäran får timeout (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 så 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 ändpunkter 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-resolvers inte kan cachelagra 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 växling vid fel inom 10 sekunder efter att en slutpunkt blir felaktig 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 för Traffic Manager-hälsokontrollerna för mina slutpunkter?

Med Traffic Manager kan du ange anpassade rubriker i de HTTP(S)-hälsokontroller som initieras mot dina slutpunkter. Om du vill ange en anpassad header kan du göra det på profilnivå (gäller för alla slutpunkter) eller ange den på slutpunktsnivå. Om en header definieras på båda nivåerna åsidosätter den som anges på ändpunktsnivå 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 ändpunkt som finns i en miljö med flera klientorganisationer. Ett annat användningsfall för detta är att identifiera Traffic Manager-begäranden i en slutpunkts HTTP(S)-begärandeloggar

Vilken Host-header använder hälsokontroller för slutpunkter?

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?

Se den här artikeln om du vill 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 så att deras hälsostatus kan kontrolleras.

Exempel med Azure PowerShell:

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

Hur många hälsokontroller till min ändpunkt 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å ändpunkten under en viss tidsperiod).
• antalet platser där hälsokontrollerna kommer från (IP-adresserna där du kan förvänta dig dessa kontroller listas i föregående vanliga frågor och svar).

Hur får jag ett meddelande om någon av mina ändpunkter 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 ändpunkter i en profil (till exempel att 75 % av dina ändpunkter är felfria) eller på ändpunktsnivå. 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.

Hur konfigurerar jag brandväggsregler för att tillåta hälsokontroller

Azure Traffic Manager förlitar sig på hälsokontroller för att övervaka tillgängligheten och prestandan hos slutpunkter. För att avsökningarna ska lyckas måste slutpunkter vara nåbara och alla brandväggar eller åtkomstkontrollistor (ACL: er) i sökvägen måste tillåta trafik från alla Traffic Manager IP-adresser. Om ip-adresser för avsökning inte tillåts kan hälsokontroller misslyckas. Ändpunkter som har markerats som felaktiga kan orsaka oväntad trafikomdirigering eller driftstopp.

Alternativ 1: Använd tjänsttaggar (rekommenderas) Den rekommenderade metoden är att använda tjänsttaggen AzureTrafficManager i NSG:er eller Azure Firewall. Tjänsttaggar innehåller automatiskt de senaste IP-intervallen och kräver inte manuella uppdateringar.

• Använda tjänsttaggar med NSG:er
• Använda tjänsttaggar med Azure Firewall

Alternativ 2: Uppdatera brandväggsregler manuellt Om tjänsttaggar inte kan användas (till exempel med anpassade brandväggsenheter eller i icke-Azure-miljöer) uppdaterar du ACL:er eller brandväggsregler så att de senaste Azure Traffic Manager-IP-adresserna tillåts.

• Den fullständiga listan över IP-adresser publiceras i Azure IP-intervall och tjänsttaggar – Public Cloud JSON-fil.
• Uppdatera regler regelbundet för att säkerställa att de senaste IP-adresserna inkluderas.

kapslade profiler i Traffic Manager

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å i den nya Azure-portalen.

Hur många kapslingslager stöder Traffic Manager?

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

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 tillämpas 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 barnprofilen 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 går igenom 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 ändpunkt 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å den underordnade profilen direkt. I stället används hälsotillståndet för den underordnade profilens ändpunkter 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 ändpunkten. Den överordnade profilen använder den här aggregerade hälsan för att avgöra om trafiken kan dirigeras till den underordnade profilen.

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

Varför kan jag inte lägga till Azure Cloud Services Extended Support-slutpunkter 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.

Trafikhanterarens länkade poster

Vad är Traffic Manager Linked Records?

Traffic Manager Linked Records är en Azure DNS-funktion som skapar en direktlänk mellan en DNS-postuppsättning och en Traffic Manager-profil med hjälp av egenskapentrafficManagementProfile. När en klient frågar DNS-posten löser Azure DNS Traffic Manager-profilen internt och returnerar endpoint-IP-adresser direkt – utan en CNAME-omdirigering till trafficmanager.net.

För mer information, se översikt över Traffic Manager Linked Records.

Hur skiljer sig Traffic Manager Linked Records från alias-poster?

Traffic Manager Linked Records är det rekommenderade tillvägagångssättet och är bättre än alias-till-Traffic Manager på följande sätt:

• Namnmatchning: Traffic Manager Linked Records returnerar alltid IP-adresser direkt. Alias CNAME-poster returnerar namnet trafficmanager.net, vilket kräver en andra DNS-uppslagning.
• TTL: Traffic Manager Linked Records ärver alltid TTL från Traffic Manager-profilen. Aliasposter använder TTL på DNS-postuppsättningen.
• Typkontroll: Traffic Manager Linked Records använder strikt typade profiler för att säkerställa att ändpunktens IP-typer matchar DNS-posttypen. Alias Records gör en svagare kontroll först vid skapandet.

Vad är en strikt typad profil?

En Traffic Manager-profiltyp kan ställas in under skapandet eller konfigurationen av en profil. Profilen är låst till IP-adresstypen (IPv4 för A-poster, IPv6 för AAAA-poster eller CNAME) och endast DNS-poster av respektive typ kan kopplas till Traffic Manager-profilen. Traffic Manager säkerställer sedan att alla endpoints som läggs till i profilen matchar den deklarerade typen. För mer information, se Strictly Typed Profiles.

Kan en Traffic Manager-profil kopplas till både A- och AAAA-trafikmanagerlänkade poster samtidigt?

Nr. En profil kan bara låsas till en IP-typ åt gången. Profiltypen ställs in när profilen skapas eller konfigureras. En Traffic Manager Linked Record som använder en annan IP-posttyp än profilens typ kommer att misslyckas. CNAME Traffic Manager Linked Records innebär ingen IP-typbegränsning och kan samexistera med andra CNAME-poster som pekar på samma profil.

Stöder Traffic Manager Linked Records nästlade profiler?

Ja. Traffic Manager Linked Records stöder nästlade Traffic Manager-profiler för alla profiltyper.

Varför exponerar inte Traffic Manager Linked Records trafficmanager.net?

Med Traffic Manager Linked Records utför Azure DNS intern Traffic Manager-upplösning och returnerar endpoint-IP-adresser direkt till klienten. Domänen trafficmanager.net ingår aldrig i DNS-svaret. Detta är viktigt för kunder som begränsar utgående DNS till specifika domäner – med aliasposter eller CNAME-poster var klienterna tvungna att lösa trafficmanager.net, en delad domän som är värd för profiler för alla Azure-kunder. Traffic Manager Linked Records eliminerar detta krav.

Är Traffic Manager Linked Records kompatibla med DNSSEC?

Ja. Eftersom Azure DNS löser Traffic Manager-profilen internt finns det inget osignerat mellanliggande hopp till trafficmanager.net i DNS-upplösningskedjan. Detta bevarar DNSSEC:s förtroendekedja, vilket gör Traffic Manager Linked Records lämpliga för DNSSEC-signerade zoner.

Vad är gränsen för poster kopplade till Traffic Manager-profiler?

Både aliasposter och Traffic Manager Linked Records stöder upp till 50 länkar per Traffic Manager-profil.

Vad händer om jag raderar en Traffic Manager-profil som har länkade poster?

En Traffic Manager-profil blockeras från att tas bort medan Traffic Managers länkade poster fortfarande refererar till den. Du måste ta bort alla länkade DNS-poster innan profilen kan raderas. Detta förhindrar att kunder av misstag bryter länkar till DNS-poster och säkerställer ren hantering av länkade resurser.

Nästa steg

• Läs mer om Traffic Manager-slutpunktsövervakning och automatisk redundansväxling.
• Läs mer om Traffic Manager trafikroutningsmetoder.