Veelgestelde vragen over Traffic Manager (FAQ)

  • Artikel

Basisprincipes van Traffic Manager

Welk IP-adres gebruikt Traffic Manager?

Zoals uitgelegd in Hoe Traffic Manager werkt, werkt Traffic Manager op DNS-niveau (Domain Name System). Dns-antwoorden worden verzonden om clients naar het juiste service-eindpunt te leiden. Clients maken vervolgens rechtstreeks verbinding met het service-eindpunt, niet via Traffic Manager.

Daarom biedt Traffic Manager geen eindpunt of IP-adres waarmee clients verbinding kunnen maken. Als u een statisch IP-adres voor uw service wilt, moet dit worden geconfigureerd in de service, niet in Traffic Manager.

Welke soorten verkeer kunnen worden gerouteerd met Traffic Manager?

Zoals uitgelegd in Hoe Traffic Manager werkt, kan een Traffic Manager-eindpunt elke internetgerichte service zijn die binnen of buiten Azure wordt gehost. Daarom kan Traffic Manager verkeer routeren dat afkomstig is van het openbare internet naar een set eindpunten die ook internetgericht zijn. Als u eindpunten hebt die zich in een particulier netwerk bevinden (bijvoorbeeld een interne versie van Azure Load Balancer) of gebruikers DNS-aanvragen van dergelijke interne netwerken laten indienen, kunt u Traffic Manager niet gebruiken om dit verkeer te routeren.

Ondersteunt Traffic Manager plaksessies?

Zoals uitgelegd in Hoe Traffic Manager werkt, werkt Traffic Manager op DNS-niveau. DNS-antwoorden worden gebruikt om clients naar het juiste service-eindpunt te leiden. Clients maken rechtstreeks verbinding met het service-eindpunt, niet via Traffic Manager. Daarom ziet Traffic Manager het HTTP-verkeer tussen de client en de server niet.

Daarnaast behoort het bron-IP-adres van de DNS-query die door Traffic Manager wordt ontvangen, tot de recursieve DNS-service, niet tot de client. Traffic Manager kan daarom geen afzonderlijke clients volgen en kan geen 'plaksessies' implementeren. Deze beperking is gebruikelijk voor alle op DNS gebaseerde verkeersbeheersystemen en is niet specifiek voor Traffic Manager.

Waarom zie ik een HTTP-fout bij het gebruik van Traffic Manager?

Zoals uitgelegd in Hoe Traffic Manager werkt, werkt Traffic Manager op DNS-niveau. DNS-antwoorden worden gebruikt om clients naar het juiste service-eindpunt te leiden. Clients maken vervolgens rechtstreeks verbinding met het service-eindpunt, niet via Traffic Manager. Traffic Manager ziet geen HTTP-verkeer tussen client en server. Daarom moet elke HTTP-fout die u ziet afkomstig zijn van uw toepassing. De client kan alleen verbinding maken met de toepassing als alle STAPPEN voor DNS-omzetting zijn voltooid. Dit omvat elke interactie die Traffic Manager heeft op de verkeersstroom van de toepassing.

Verder onderzoek moet zich daarom richten op de toepassing.

De HTTP-hostheader die vanuit de browser van de client wordt verzonden, is de meest voorkomende bron van problemen. Zorg ervoor dat de toepassing is geconfigureerd voor het accepteren van de juiste hostheader voor de domeinnaam die u gebruikt. Zie het configureren van een aangepaste domeinnaam voor een web-app in Azure-app Service met Traffic Manager voor eindpunten die gebruikmaken van de Azure-app Service.

Hoe kan ik een probleem met 500 (interne serverfout) oplossen bij het gebruik van Traffic Manager?

Als uw client of toepassing een HTTP 500-fout ontvangt tijdens het gebruik van Traffic Manager, kan dit worden veroorzaakt door een verlopen DNS-query. Als u het probleem wilt oplossen, wist u de DNS-cache en staat u de client toe een nieuwe DNS-query uit te voeren.

Wanneer een service-eindpunt niet reageert, worden clients en toepassingen die dat eindpunt gebruiken, pas opnieuw ingesteld als de DNS-cache is vernieuwd. De duur van de cache wordt bepaald door de time-to-live (TTL) van de DNS-record. Zie Traffic Manager en de DNS-cache voor meer informatie.

Zie ook de volgende verwante veelgestelde vragen in dit artikel:

Wat is de invloed op de prestaties van het gebruik van Traffic Manager?

Zoals uitgelegd in Hoe Traffic Manager werkt, werkt Traffic Manager op DNS-niveau. Omdat clients rechtstreeks verbinding maken met uw service-eindpunten, is er geen invloed op de prestaties wanneer u Traffic Manager gebruikt zodra de verbinding tot stand is gebracht.

Omdat Traffic Manager kan worden geïntegreerd met toepassingen op DNS-niveau, moet er een extra DNS-zoekactie worden ingevoegd in de DNS-omzettingsketen. De impact van Traffic Manager op DNS-omzettingstijd is minimaal. Traffic Manager maakt gebruik van een globaal netwerk van naamservers en maakt gebruik van anycast-netwerken om ervoor te zorgen dat DNS-query's altijd worden gerouteerd naar de dichtstbijzijnde beschikbare naamserver. Bovendien betekent caching van DNS-antwoorden dat de extra DNS-latentie die door Traffic Manager wordt gemaakt, alleen van toepassing is op een fractie van sessies.

De prestatiemethode routeert verkeer naar het dichtstbijzijnde beschikbare eindpunt. Het nettoresultaat is dat de algehele impact op de prestaties die aan deze methode is gekoppeld, minimaal moet zijn. Elke toename van de DNS-latentie moet worden verschoven door een lagere netwerklatentie naar het eindpunt.

Welke toepassingsprotocollen kan ik gebruiken met Traffic Manager?

Zoals uitgelegd in Hoe Traffic Manager werkt, werkt Traffic Manager op DNS-niveau. Zodra de DNS-zoekopdracht is voltooid, maken clients rechtstreeks verbinding met het toepassingseindpunt, niet via Traffic Manager. Daarom kan de verbinding elk toepassingsprotocol gebruiken. Als u TCP als bewakingsprotocol selecteert, kan de eindpuntstatuscontrole van Traffic Manager worden uitgevoerd zonder toepassingsprotocollen te gebruiken. Als u ervoor kiest om de status te laten verifiëren met behulp van een toepassingsprotocol, moet het eindpunt kunnen reageren op HTTP- of HTTPS GET-aanvragen.

Kan ik Traffic Manager gebruiken met een 'naakte' domeinnaam?

Ja. Zie Een aliasrecord configureren ter ondersteuning van apex met Traffic Manager voor meer informatie over het maken van een aliasrecord voor uw domeinnaam apex-apexdomeinen met Traffic Manager.

Beschouwt Traffic Manager het subnetadres van de client bij het verwerken van DNS-query's?

Ja. Naast het bron-IP-adres van de DNS-query (meestal het IP-adres van de DNS-resolver), beschouwt Traffic Manager ook het subnetadres van de client als deze is opgenomen in de DNS-query die wordt verzonden door de DNS-resolver die de aanvraag namens de eindgebruiker indient. Deze IP-adressen worden gebruikt voor het optimaliseren van geografische, prestatie- en subnetrouteringsmethoden. RfC 7871 – Clientsubnet in DNS-query's biedt een uitbreidingsmechanisme voor DNS (EDNS0) kan het clientsubnetadres doorgeven van resolvers die dit ondersteunen.

Wat is DNS TTL en hoe heeft dit invloed op mijn gebruikers?

Wanneer een DNS-query in Traffic Manager terechtkomt, wordt een waarde ingesteld in het antwoord met de naam time-to-live (TTL). Deze waarde, waarvan de eenheid in seconden is, geeft aan dat DNS-resolvers downstream zijn over hoe lang dit antwoord in de cache moet worden opgeslagen. Hoewel DNS-resolvers dit resultaat niet gegarandeerd in de cache opslaan, kunnen ze in de cache reageren op eventuele volgende query's buiten de cache in plaats van naar Dns-servers van Traffic Manager te gaan. Dit heeft als volgt invloed op de antwoorden:

  • een hogere TTL vermindert het aantal query's dat op de Traffic Manager DNS-servers terechtkomt, waardoor de kosten voor een klant kunnen worden verlaagd, omdat het aantal uitgevoerde query's een factureerbaar gebruik is.
  • een hogere TTL kan de tijd verminderen die nodig is om een DNS-zoekopdracht uit te voeren.
  • een hogere TTL betekent ook dat uw gegevens niet overeenkomen met de meest recente statusinformatie die Traffic Manager heeft verkregen via de testagenten.

Hoe hoog of laag kan ik de TTL voor Traffic Manager-antwoorden instellen?

U kunt instellen dat de DNS-TTL per profielniveau zo laag is als 0 seconden en zo hoog als 2.147.483.647 seconden (het maximale bereik dat compatibel is met RFC-1035). Een TTL van 0 betekent dat downstream-DNS-resolvers geen queryantwoorden in de cache opslaan en dat alle query's naar verwachting de DNS-servers van Traffic Manager bereiken voor omzetting.

Hoe begrijp ik het aantal query's dat naar mijn profiel komt?

Een van de metrische gegevens van Traffic Manager is het aantal query's dat door een profiel wordt gereageerd. U kunt deze informatie ophalen op een aggregatie op profielniveau of u kunt deze verder opsplitsen om het aantal query's weer te geven waar specifieke eindpunten zijn geretourneerd. Daarnaast kunt u waarschuwingen instellen om u op de hoogte te stellen als het antwoordvolume van de query de voorwaarden overschrijdt die u hebt ingesteld. Voor meer informatie, metrische gegevens en waarschuwingen van Traffic Manager.

Wanneer ik een Traffic Manager-profiel verwijder, wat is de hoeveelheid tijd voordat de naam van het profiel beschikbaar is voor hergebruik?

Wanneer u een Traffic Manager-profiel verwijdert, wordt de bijbehorende domeinnaam gedurende een bepaalde periode gereserveerd. Andere Traffic Manager-profielen in dezelfde tenant kunnen de naam onmiddellijk opnieuw gebruiken. Een andere Azure-tenant kan echter pas dezelfde profielnaam gebruiken als de reservering verloopt. Met deze functie kunt u de autoriteit behouden voor de naamruimten die u implementeert, waardoor u geen zorgen hoeft te maken dat de naam door een andere tenant kan worden genomen.

Als de naam van uw Traffic Manager-profiel bijvoorbeeld label1 is, label1.trafficmanager.net is gereserveerd voor uw tenant, zelfs als u het profiel verwijdert. Onderliggende naamruimten, zoals xyz.label1 of 123.abc.label1 , zijn ook gereserveerd. Wanneer de reservering verloopt, wordt de naam beschikbaar gesteld aan andere tenants. De naam die is gekoppeld aan een uitgeschakeld profiel, is voor onbepaalde tijd gereserveerd. Neem contact op met uw accountvertegenwoordiger voor vragen over de tijdsduur waarop een naam is gereserveerd.

Geografische verkeersrouteringsmethode van Traffic Manager

Wat zijn enkele use cases waarbij geografische routering nuttig is?

Het type geografische routering kan worden gebruikt in elk scenario waarin een Azure-klant de gebruikers moet onderscheiden op basis van geografische regio's. U kunt bijvoorbeeld gebruikers van specifieke regio's een andere gebruikerservaring geven dan die uit andere regio's. Een ander voorbeeld is het voldoen aan lokale machtigingen voor gegevenssoevereine die vereisen dat gebruikers uit een specifieke regio alleen worden bediend door eindpunten in die regio.

Hoe kan ik bepalen of ik de methode prestatieroutering of geografische routeringsmethode moet gebruiken?

Het belangrijkste verschil tussen deze twee populaire routeringsmethoden is dat in de methode Prestatieroutering uw primaire doel is om verkeer naar het eindpunt te verzenden dat de laagste latentie voor de beller kan bieden, terwijl bij geografische routering het primaire doel is om een geo-omheining af te dwingen voor uw bellers, zodat u ze bewust naar een specifiek eindpunt kunt routeren. De overlapping treedt op omdat er een correlatie is tussen geografische nabijheid en lagere latentie, hoewel dit niet altijd waar is. Er is mogelijk een eindpunt in een andere geografie die een betere latentie-ervaring kan bieden voor de beller en in dat geval stuurt prestatieroutering de gebruiker naar dat eindpunt, maar geografische routering verzendt deze altijd naar het eindpunt dat u voor hun geografische regio hebt toegewezen. Bekijk het volgende voorbeeld om het duidelijk te maken: met geografische routering kunt u ongebruikelijke toewijzingen maken, zoals het verzenden van al het verkeer van Azië naar eindpunten in de VS en al het Amerikaanse verkeer naar eindpunten in Azië. In dat geval doet geografische routering opzettelijk precies wat u hebt geconfigureerd om te doen en is prestatieoptimalisatie geen aandachtspunt.

Notitie

Er kunnen scenario's zijn waarin u mogelijk zowel prestatie- als geografische routeringsmogelijkheden nodig hebt, voor deze scenario's geneste profielen een uitstekende keuze kunnen zijn. U kunt bijvoorbeeld een bovenliggend profiel instellen met geografische routering waar u al het verkeer van Noord-Amerika naar een genest profiel met eindpunten in de VS verzendt en prestatieroutering gebruikt om dat verkeer naar het beste eindpunt in die set te verzenden.

Wat zijn de regio's die worden ondersteund door Traffic Manager voor geografische routering?

De land-/regiohiërarchie die door Traffic Manager wordt gebruikt, vindt u hier. Hoewel deze pagina up-to-date blijft met eventuele wijzigingen, kunt u ook programmatisch dezelfde informatie ophalen met behulp van de Rest API van Azure Traffic Manager.

Hoe bepaalt Traffic Manager waar een gebruiker query's op uitvoert?

Traffic Manager kijkt naar het bron-IP-adres van de query (dit is waarschijnlijk een lokale DNS-resolver die namens de gebruiker query's uitvoert) en gebruikt een intern IP-adres om de locatie te bepalen. Deze kaart wordt voortdurend bijgewerkt om rekening te houden met wijzigingen in internet.

Is het gegarandeerd dat Traffic Manager in elk geval de exacte geografische locatie van de gebruiker correct kan bepalen?

Nee, Traffic Manager kan niet garanderen dat de geografische regio die we afleiden van het bron-IP-adres van een DNS-query altijd overeenkomt met de locatie van de gebruiker vanwege de volgende redenen:

  • Ten eerste, zoals beschreven in de vorige veelgestelde vragen, is het bron-IP-adres dat we zien dat van een DNS-resolver die de zoekactie uitvoert namens de gebruiker. Hoewel de geografische locatie van de DNS-resolver een goede proxy is voor de geografische locatie van de gebruiker, kan deze ook verschillen, afhankelijk van de footprint van de DNS-resolverservice en de specifieke DNS-resolverservice die een klant heeft gekozen om te gebruiken. Een klant die zich in Maleisië bevindt, kan bijvoorbeeld in de instellingen van het apparaat een DNS-resolverservice gebruiken waarvan de DNS-server in Singapore kan worden gekozen om de queryresoluties voor die gebruiker/het apparaat af te handelen. In dat geval kan Traffic Manager alleen het IP-adres van de resolver zien dat overeenkomt met de locatie van Singapore. Zie ook de eerdere veelgestelde vragen met betrekking tot clientsubnetadresondersteuning op deze pagina.

  • Ten tweede gebruikt Traffic Manager een interne kaart om het IP-adres uit te voeren voor geografische regioomzetting. Hoewel deze kaart voortdurend wordt gevalideerd en bijgewerkt om de nauwkeurigheid ervan te vergroten en rekening te houden met de veranderende aard van internet, is er nog steeds de mogelijkheid dat onze informatie geen exacte weergave is van de geografische locatie van alle IP-adressen.

Moet een eindpunt zich fysiek in dezelfde regio bevinden als het eindpunt waarmee het is geconfigureerd voor geografische routering?

Nee, de locatie van het eindpunt legt geen beperkingen op voor welke regio's eraan kunnen worden toegewezen. Een eindpunt in de Azure-regio US - centraal kan bijvoorbeeld alle gebruikers uit India naar het eindpunt laten omsturen.

Kan ik geografische regio's toewijzen aan eindpunten in een profiel dat niet is geconfigureerd om geografische routering uit te voeren?

Ja, als de routeringsmethode van een profiel niet geografisch is, kunt u de REST API van Azure Traffic Manager gebruiken om geografische regio's toe te wijzen aan eindpunten in dat profiel. Voor profielen van niet-geografische routeringstypen wordt deze configuratie genegeerd. Als u een dergelijk profiel op een later tijdstip wijzigt in het geografische routeringstype, kan Traffic Manager deze toewijzingen gebruiken.

Waarom krijg ik een foutmelding wanneer ik de routeringsmethode van een bestaand profiel probeer te wijzigen in Geographic?

Alle eindpunten onder een profiel met geografische routering moeten ten minste één regio hebben toegewezen. Als u een bestaand profiel wilt converteren naar een geografisch routeringstype, moet u eerst geografische regio's koppelen aan alle eindpunten met behulp van de Azure Traffic Manager REST API voordat u het routeringstype wijzigt in geografisch. Als u de portal gebruikt, verwijdert u eerst de eindpunten, wijzigt u de routeringsmethode van het profiel in geografisch en voegt u vervolgens de eindpunten toe, samen met de geografische regiotoewijzing.

Een regio kan worden toegewezen aan slechts één eindpunt binnen een profiel als deze gebruikmaakt van de geografische routeringsmethode. Als dat eindpunt geen genest type is waaraan een onderliggend profiel is gekoppeld, blijft Traffic Manager verkeer naar het eindpunt verzenden omdat het alternatief voor het verzenden van verkeer niet beter is. Traffic Manager voert geen failover uit naar een ander eindpunt, zelfs als de toegewezen regio een 'bovenliggende' regio is die is toegewezen aan het eindpunt dat beschadigd is gegaan (bijvoorbeeld als een eindpunt met regio Spanje niet in orde is, wordt er geen failover uitgevoerd naar een ander eindpunt waaraan de regio Europa is toegewezen). Dit wordt gedaan om ervoor te zorgen dat Traffic Manager de geografische grenzen respecteert die een klant heeft ingesteld in hun profiel. Als u het voordeel wilt krijgen van een failover naar een ander eindpunt wanneer een eindpunt beschadigd raakt, is het raadzaam om geografische regio's toe te wijzen aan geneste profielen met meerdere eindpunten erin in plaats van afzonderlijke eindpunten. Op deze manier kan verkeer een failover uitvoeren naar een ander eindpunt binnen hetzelfde geneste onderliggende profiel als een eindpunt in het geneste onderliggende profiel mislukt.

Zijn er beperkingen voor de API-versie die ondersteuning biedt voor dit routeringstype?

Ja, alleen API-versie 2017-03-01 en hoger ondersteunt het geografische routeringstype. Oudere API-versies kunnen niet worden gebruikt voor het maken van profielen van het geografische routeringstype of het toewijzen van geografische regio's aan eindpunten. Als een oudere API-versie wordt gebruikt om profielen op te halen uit een Azure-abonnement, wordt geen profiel van het geografische routeringstype geretourneerd. Wanneer u oudere API-versies gebruikt, wordt bovendien geen profiel weergegeven dat eindpunten bevat met een toewijzing van een geografische regio.

Verkeersrouteringsmethode voor Traffic Manager-subnet

Wat zijn enkele use cases waarbij subnetroutering nuttig is?

Met subnetroutering kunt u onderscheid maken tussen de ervaring die u levert voor specifieke sets gebruikers die zijn geïdentificeerd door het bron-IP-adres van hun DNS-aanvragen. Een voorbeeld is het weergeven van verschillende inhoud als gebruikers verbinding maken met een website vanuit uw zakelijke HQ. Een andere is het beperken van gebruikers van bepaalde internetproviders tot alleen toegangseindpunten die alleen IPv4-verbindingen ondersteunen als deze internetproviders subpar performance hebben wanneer IPv6 wordt gebruikt. Een andere reden om subnetrouteringsmethode te gebruiken, is in combinatie met andere profielen in een geneste profielset. Als u bijvoorbeeld de geografische routeringsmethode wilt gebruiken voor geo-fencing van uw gebruikers, maar voor een specifieke internetprovider wilt u een andere routeringsmethode uitvoeren, kunt u een profiel met een subnetrouteringsmethode hebben als het bovenliggende profiel en die internetprovider overschrijven om een specifiek onderliggend profiel te gebruiken en het standaard geografische profiel voor iedereen te hebben.

Hoe weet Traffic Manager het IP-adres van de eindgebruiker?

Apparaten van eindgebruikers gebruiken doorgaans een DNS-resolver om namens hen de DNS-zoekopdracht uit te voeren. Het uitgaande IP-adres van dergelijke resolvers is wat Traffic Manager als bron-IP ziet. Daarnaast wordt er met de subnetrouteringsmethode ook gezocht of er ECS-gegevens (EDNS0 Extended Client Subnet) zijn die zijn doorgegeven met de aanvraag. Als ECS-informatie aanwezig is, is dat het adres dat wordt gebruikt om de routering te bepalen. Als er geen ECS-gegevens zijn, wordt het bron-IP-adres van de query gebruikt voor routeringsdoeleinden.

Hoe kan ik IP-adressen opgeven wanneer ik subnetroutering gebruik?

De IP-adressen die aan een eindpunt moeten worden gekoppeld, kunnen op twee manieren worden opgegeven. U kunt eerst de vier decimale octet notatie met een begin- en eindadres gebruiken om het bereik op te geven (bijvoorbeeld 1.2.3.4-5.6.7.8 of 3.4.5.6-3.4.5.6). Ten tweede kunt u de CIDR-notatie gebruiken om het bereik op te geven (bijvoorbeeld 1.2.3.0/24). U kunt meerdere bereiken opgeven en beide notatietypen in een bereikset gebruiken. Er gelden enkele beperkingen.

  • U kunt adresbereiken niet overlappen omdat elk IP-adres moet worden toegewezen aan slechts één eindpunt
  • Het beginadres mag niet meer zijn dan het eindadres
  • Voor de CIDR-notatie moet het IP-adres vóór de '/' het netwerkadres van dat bereik zijn (bijvoorbeeld 1.2.3.0/24 is geldig, maar 1.2.3.4.4/24 is NIET geldig)

Hoe kan ik een terugvaleindpunt opgeven wanneer ik subnetroutering gebruik?

Als u in een profiel met subnetroutering een eindpunt hebt waaraan geen subnetten zijn toegewezen, worden alle aanvragen die niet overeenkomen met andere eindpunten naar hier doorgestuurd. Het wordt ten zeerste aanbevolen dat u een dergelijk terugvaleindpunt in uw profiel hebt, omdat Traffic Manager een NXDOMAIN-antwoord retourneert als een aanvraag binnenkomt en deze niet is toegewezen aan eindpunten of als het is toegewezen aan een eindpunt, maar dat eindpunt niet in orde is.

Wat gebeurt er als een eindpunt is uitgeschakeld in een profiel voor subnetrouteringstypen?

Als u in een profiel met subnetroutering een eindpunt hebt dat is uitgeschakeld, gedraagt Traffic Manager zich alsof dat eindpunt en de subnettoewijzingen die het heeft niet bestaan. Als een query die overeenkomt met de IP-adrestoewijzing wordt ontvangen en het eindpunt is uitgeschakeld, retourneert Traffic Manager een terugvaleindpunt (één zonder toewijzingen) of als een dergelijk eindpunt niet aanwezig is, retourneert een NXDOMAIN-antwoord.

Traffic Manager MultiValue-verkeersrouteringsmethode

Wat zijn enkele use cases waarbij MultiValue-routering nuttig is?

Routering met meerdere waarden retourneert meerdere eindpunten die in orde zijn in één queryantwoord. Het belangrijkste voordeel hiervan is dat als een eindpunt niet in orde is, de client meer opties heeft om het opnieuw te proberen zonder een andere DNS-aanroep te maken (die mogelijk dezelfde waarde retourneert vanuit een upstream-cache). Dit is van toepassing op beschikbaarheidsgevoelige toepassingen die de downtime willen minimaliseren. Een ander gebruik voor multivalue-routeringsmethode is als een eindpunt 'dual-homed' is voor zowel IPv4- als IPv6-adressen en u de aanroeper beide opties wilt geven waaruit u kunt kiezen wanneer er een verbinding met het eindpunt wordt gestart.

Hoeveel eindpunten worden geretourneerd wanneer multivalue-routering wordt gebruikt?

U kunt het maximum aantal eindpunten opgeven dat moet worden geretourneerd en MultiValue retourneert niet meer dan dat veel goede eindpunten wanneer een query wordt ontvangen. De maximaal mogelijke waarde voor deze configuratie is 10.

Krijg ik dezelfde set eindpunten wanneer MultiValue-routering wordt gebruikt?

We kunnen niet garanderen dat dezelfde set eindpunten in elke query wordt geretourneerd. Dit wordt ook beïnvloed door het feit dat sommige eindpunten mogelijk beschadigd raken op welk moment ze niet worden opgenomen in het antwoord

Real-user-metingen

Wat zijn de voordelen van het gebruik van Real User Measurements?

Wanneer u de routeringsmethode voor prestaties gebruikt, kiest Traffic Manager de beste Azure-regio waarmee uw eindgebruiker verbinding moet maken door het bron-IP- en EDNS-clientsubnet (indien doorgegeven) te inspecteren en te controleren op basis van de netwerklatentie-informatie die de service onderhoudt. Real User Measurements verbetert dit voor uw eindgebruikersbestand door hun ervaring bij te dragen aan deze latentietabel, naast ervoor te zorgen dat deze tabel voldoende de netwerken van eindgebruikers omvat van waaruit uw eindgebruikers verbinding maken met Azure. Dit leidt tot een grotere nauwkeurigheid in de routering van uw eindgebruiker.

Kan ik echte gebruikersmetingen gebruiken met niet-Azure-regio's?

Real User Measurements meet en rapporteert alleen over de latentie om Azure-regio's te bereiken. Als u routering op basis van prestaties gebruikt met eindpunten die worden gehost in niet-Azure-regio's, kunt u nog steeds profiteren van deze functie door meer latentiegegevens te hebben over de representatieve Azure-regio die u hebt geselecteerd om aan dit eindpunt te worden gekoppeld.

Welke routeringsmethode profiteert van Real User Measurements?

De aanvullende informatie die is verkregen via Real User Measurements, is alleen van toepassing op profielen die gebruikmaken van de routeringsmethode voor prestaties. De koppeling Real User Measurements is beschikbaar vanuit alle profielen wanneer u deze bekijkt via Azure Portal.

Moet ik real user measurements afzonderlijk inschakelen?

Nee, u hoeft deze slechts één keer per abonnement in te schakelen en alle latentiegegevens die zijn gemeten en gerapporteerd, zijn beschikbaar voor alle profielen.

Hoe kan ik Real User Measurements voor mijn abonnement uitschakelen?

U kunt stoppen met de toename van de kosten die betrekking hebben op real user measurements wanneer u stopt met het verzamelen en verzenden van latentiemetingen vanuit uw clienttoepassing. Wanneer bijvoorbeeld JavaScript wordt ingesloten in webpagina's, kunt u stoppen met het gebruik van deze functie door JavaScript te verwijderen of door de aanroep uit te schakelen wanneer de pagina wordt weergegeven.

U kunt Real User Measurements ook uitschakelen door uw sleutel te verwijderen. Nadat u de sleutel hebt verwijderd, worden alle metingen die naar Traffic Manager met die sleutel worden verzonden, verwijderd.

Kan ik Real User Measurements gebruiken met andere clienttoepassingen dan webpagina's?

Ja, Real User Measurements is ontworpen voor het opnemen van gegevens die zijn verzameld via verschillende typen eindgebruikersclients. Deze veelgestelde vragen worden bijgewerkt naarmate nieuwe typen clienttoepassingen worden ondersteund.

Hoeveel metingen worden er uitgevoerd telkens wanneer mijn webpagina metingen voor echte gebruikers is ingeschakeld?

Wanneer Real User Measurements wordt gebruikt met de opgegeven meting van JavaScript, resulteert elke pagina-rendering in zes metingen die worden uitgevoerd. Deze worden vervolgens gerapporteerd aan de Traffic Manager-service. Er worden kosten in rekening gebracht voor deze functie op basis van het aantal metingen dat is gerapporteerd aan de Traffic Manager-service. Als de gebruiker bijvoorbeeld weg van uw webpagina navigeert terwijl de metingen worden uitgevoerd, maar voordat deze zijn gerapporteerd, worden deze metingen niet in aanmerking genomen voor factureringsdoeleinden.

Is er een vertraging voordat het script Real User Measurements op mijn webpagina wordt uitgevoerd?

Nee, er is geen geprogrammeerde vertraging voordat het script wordt aangeroepen.

Kan ik echte gebruikersmetingen gebruiken met alleen de Azure-regio's die ik wil meten?

Nee, elke keer dat het wordt aangeroepen, meet het script Real User Measurements een set van zes Azure-regio's zoals bepaald door de service. Deze set verandert tussen verschillende aanroepen en wanneer een groot aantal dergelijke aanroepen plaatsvindt, loopt de metingsdekking over verschillende Azure-regio's.

Kan ik het aantal metingen beperken tot een specifiek getal?

De meting van JavaScript is ingesloten op uw webpagina en u hebt volledige controle over wanneer u deze wilt starten en stoppen. Zolang de Traffic Manager-service een aanvraag ontvangt voor een lijst met Azure-regio's die moeten worden gemeten, wordt een set regio's geretourneerd.

Kan ik de metingen van mijn clienttoepassing zien als onderdeel van Real User Measurements?

Omdat de meetlogica wordt uitgevoerd vanuit uw clienttoepassing, hebt u volledige controle over wat er gebeurt, inclusief het zien van de latentiemetingen. Traffic Manager rapporteert geen geaggregeerde weergave van de metingen die zijn ontvangen onder de sleutel die aan uw abonnement is gekoppeld.

Kan ik het meetscript van Traffic Manager wijzigen?

Hoewel u de controle hebt over wat is ingesloten op uw webpagina, raden we u ten zeerste af om wijzigingen aan te brengen in het meetscript om ervoor te zorgen dat de latenties correct worden gemeten en gerapporteerd.

Is het mogelijk voor anderen om de sleutel te zien die ik gebruik met echte gebruikersmetingen?

Wanneer u het meetscript insluit op een webpagina, kunnen anderen het script en uw RUM-sleutel (Real User Measurements) zien. Maar het is belangrijk om te weten dat deze sleutel verschilt van uw abonnements-id en wordt gegenereerd door Traffic Manager om alleen voor dit doel te worden gebruikt. Als u weet dat uw RUM-sleutel geen inbreuk maakt op de veiligheid van uw Azure-account.

Kunnen anderen mijn RUM-sleutel misbruiken?

Hoewel het mogelijk is voor anderen om uw sleutel te gebruiken om verkeerde gegevens naar Azure te verzenden, veranderen enkele verkeerde metingen de routering niet, omdat er rekening wordt gehouden met alle andere metingen die we ontvangen. Als u uw sleutels wilt wijzigen, kunt u de sleutel opnieuw genereren op welk punt de oude sleutel wordt verwijderd.

Moet ik de meting JavaScript in al mijn webpagina's plaatsen?

Real User Measurements levert meer waarde naarmate het aantal metingen toeneemt. Dat gezegd hebbende, is het uw beslissing of u het op al uw webpagina's of een aantal moet plaatsen. We raden u aan om deze eerst op uw meest bezochte pagina te plaatsen waar een gebruiker naar verwachting vijf seconden of langer op die pagina blijft.

Kan informatie over mijn eindgebruikers worden geïdentificeerd door Traffic Manager als ik Real User Measurements gebruik?

Wanneer de opgegeven meting JavaScript wordt gebruikt, heeft Traffic Manager inzicht in het IP-adres van de client van de eindgebruiker en het bron-IP-adres van de lokale DNS-resolver die ze gebruiken. Traffic Manager gebruikt het IP-adres van de client pas nadat het is afgekapt om de specifieke eindgebruiker te identificeren die de metingen heeft verzonden.

Moet de webpagina die Real User Measurements meet Traffic Manager gebruiken voor routering?

Nee, het hoeft Traffic Manager niet te gebruiken. De routeringszijde van Traffic Manager werkt afzonderlijk van het onderdeel Real User Measurement en hoewel het een goed idee is om ze beide in dezelfde webeigenschap te hebben, hoeven ze niet te zijn.

Moet ik een service hosten in Azure-regio's voor gebruik met echte gebruikersmetingen?

Nee, u hoeft geen onderdeel aan de serverzijde te hosten in Azure om echte gebruikersmetingen te laten werken. De afbeelding met één pixel die is gedownload door de meting JavaScript en de service die deze in verschillende Azure-regio's uitvoert, wordt gehost en beheerd door Azure.

Neemt het gebruik van mijn Azure-bandbreedte toe wanneer ik Echte gebruikersmetingen gebruik?

Zoals vermeld in het vorige antwoord, zijn de onderdelen aan de serverzijde van Real User Measurements eigendom van en worden beheerd door Azure. Dit betekent dat uw Azure-bandbreedtegebruik niet toeneemt omdat u Echte gebruikersmetingen gebruikt. Dit omvat geen bandbreedtegebruik buiten de kosten van Azure. We minimaliseren de bandbreedte die wordt gebruikt door slechts één pixel afbeelding te downloaden om de latentie naar een Azure-regio te meten.

Verkeersweergave

Wat doet de verkeersweergave?

Traffic View is een functie van Traffic Manager waarmee u meer inzicht krijgt in uw gebruikers en hoe hun ervaring is. Hierbij worden de query's gebruikt die worden ontvangen door Traffic Manager en de tabellen met netwerklatentiegegevens die de service onderhoudt om u het volgende te bieden:

  • De regio's waarin gebruikers zich bevinden die verbinding maken met uw eindpunten in Azure.
  • Het aantal gebruikers dat vanuit deze regio's verbinding maakt.
  • De Azure-regio's waarnaar ze worden gerouteerd.
  • De latentie van gebruikers wordt doorsturen naar deze Azure-regio's.

Deze informatie is beschikbaar voor u om te gebruiken via geografische kaartoverlay- en tabelweergaven in de portal, naast dat deze beschikbaar zijn als onbewerkte gegevens die u kunt downloaden.

Hoe kan ik profiteren van het gebruik van de verkeersweergave?

De verkeersweergave geeft u de algemene weergave van het verkeer dat uw Traffic Manager-profielen ontvangen. Het kan met name worden gebruikt om te begrijpen waar uw gebruikersbestand verbinding mee maakt en even belangrijk is wat hun gemiddelde latentie-ervaring is. U kunt deze informatie vervolgens gebruiken om gebieden te vinden waarin u zich moet richten, bijvoorbeeld door uw Azure-footprint uit te breiden naar een regio die deze gebruikers met een lagere latentie kan bedienen. Een ander inzicht dat u kunt afleiden van het gebruik van de verkeersweergave is het bekijken van de patronen van verkeer naar verschillende regio's, die u op zijn beurt kunnen helpen bij het nemen van beslissingen over het vergroten of verkleinen van de invent in die regio's.

Hoe verschilt de verkeersweergave van de metrische gegevens van Traffic Manager die beschikbaar zijn via Azure Monitor?

Azure Monitor kan worden gebruikt om inzicht te krijgen in het verkeer dat door uw profiel en de eindpunten ervan wordt ontvangen. Hiermee kunt u ook de status van de eindpunten bijhouden door de resultaten van de statuscontrole weer te geven. Wanneer u verder moet gaan en inzicht wilt krijgen in de ervaring van uw eindgebruiker die verbinding maakt met Azure op regionaal niveau, kan traffic view worden gebruikt om dat te bereiken.

Gebruikt de verkeersweergave informatie over het EDNS-clientsubnet?

De DNS-query's die door Azure Traffic Manager worden geleverd, overwegen ECS-informatie om de nauwkeurigheid van de routering te verhogen. Maar bij het maken van de gegevensset die laat zien waar de gebruikers verbinding mee maken, gebruikt de verkeersweergave alleen het IP-adres van de DNS-resolver.

Hoeveel dagen aan gegevens gebruikt Traffic View?

Traffic View maakt de uitvoer door de gegevens te verwerken van de zeven dagen voorafgaand aan de dag voordat deze door u worden bekeken. Dit is een bewegend venster en de meest recente gegevens worden elke keer dat u bezoekt gebruikt.

Hoe verwerkt de verkeersweergave externe eindpunten?

Wanneer u externe eindpunten gebruikt die buiten Azure-regio's worden gehost in een Traffic Manager-profiel, kunt u ervoor kiezen om deze toe te wijzen aan een Azure-regio. Dit is een proxy voor de latentiekenmerken (dit is in feite nodig als u de routeringsmethode voor prestaties gebruikt). Als deze Azure-regiotoewijzing is, worden de metrische latentiegegevens van die Azure-regio gebruikt bij het maken van de uitvoer van de verkeersweergave. Als er geen Azure-regio is opgegeven, is de latentiegegevens leeg in de gegevens voor die externe eindpunten.

Moet ik de verkeersweergave inschakelen voor elk profiel in mijn abonnement?

Tijdens de preview-periode is de verkeersweergave ingeschakeld op abonnementsniveau. Als onderdeel van de verbeteringen die we hebben aangebracht vóór de algemene beschikbaarheid, kunt u nu de verkeersweergave op profielniveau inschakelen, zodat u deze functie gedetailleerder kunt inschakelen. De verkeersweergave is standaard uitgeschakeld voor een profiel.

Notitie

Als u de verkeersweergave op abonnementsniveau hebt ingeschakeld tijdens de preview-tijd, moet u deze nu opnieuw inschakelen voor elk profiel onder dat abonnement.

Hoe kan ik de verkeersweergave uitschakelen?

U kunt de verkeersweergave uitschakelen voor elk profiel met behulp van de portal of REST API.

Hoe werkt facturering in Traffic View?

Prijzen voor traffic view zijn gebaseerd op het aantal gegevenspunten dat wordt gebruikt om de uitvoer te maken. Momenteel is het enige ondersteunde gegevenstype de query's die uw profiel ontvangt. Bovendien worden er alleen kosten in rekening gebracht voor de verwerking die is uitgevoerd wanneer traffic view is ingeschakeld. Dit betekent dat als u de verkeersweergave gedurende een bepaalde periode in een maand inschakelt en deze tijdens andere tijden uitschakelt, alleen de gegevenspunten die zijn verwerkt terwijl u de functie hebt ingeschakeld, telt mee voor uw factuur.

Traffic Manager-eindpunten

Kan ik Traffic Manager gebruiken met eindpunten uit meerdere abonnementen?

Het gebruik van eindpunten uit meerdere abonnementen is niet mogelijk met Azure Web Apps. Voor Azure Web Apps is vereist dat elke aangepaste domeinnaam die wordt gebruikt met Web Apps alleen binnen één abonnement wordt gebruikt. Het is niet mogelijk om Web Apps van meerdere abonnementen met dezelfde domeinnaam te gebruiken.

Voor andere eindpunttypen is het mogelijk Om Traffic Manager te gebruiken met eindpunten uit meer dan één abonnement. In Resource Manager kunnen eindpunten van elk abonnement worden toegevoegd aan Traffic Manager, zolang de persoon die het Traffic Manager-profiel configureert leestoegang heeft tot het eindpunt. Deze machtigingen kunnen worden verleend met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC-rol). Eindpunten van andere abonnementen kunnen worden toegevoegd met behulp van Azure PowerShell of de Azure CLI.

Kan ik Traffic Manager gebruiken met staging-sites van de cloudservice?

Ja. Faseringssites van de cloudservice kunnen als externe eindpunten worden geconfigureerd in Traffic Manager. Statuscontroles worden nog steeds in rekening gebracht tegen het tarief voor Azure-eindpunten.

Ondersteunt Traffic Manager IPv6-eindpunten?

Traffic Manager biedt momenteel geen IPv6-adresseerbare naamservers. Traffic Manager kan echter nog steeds worden gebruikt door IPv6-clients die verbinding maken met IPv6-eindpunten als de recursieve DNS-server van de client IPv4 ondersteunt. Een client doet geen DNS-aanvraag rechtstreeks naar Traffic Manager. In plaats daarvan gebruikt de client een recursieve DNS-service. Een IPv6-client verzendt aanvragen naar de recursieve DNS-service via IPv6. De recursieve service moet vervolgens contact kunnen opnemen met de Traffic Manager-naamservers met behulp van IPv4. Traffic Manager reageert met de DNS-naam of het IP-adres van het eindpunt.

Kan ik Traffic Manager gebruiken met meer dan één web-app in dezelfde regio?

Traffic Manager wordt doorgaans gebruikt om verkeer te leiden naar toepassingen die in verschillende regio's zijn geïmplementeerd. Het kan echter ook worden gebruikt wanneer een toepassing meer dan één implementatie in dezelfde regio heeft. De Traffic Manager Azure-eindpunten staan niet toe dat meer dan één web-app-eindpunt uit dezelfde Azure-regio wordt toegevoegd aan hetzelfde Traffic Manager-profiel.

Hoe kan ik de Azure-eindpunten van mijn Traffic Manager-profiel verplaatsen naar een andere resourcegroep of een ander abonnement?

Azure-eindpunten die zijn gekoppeld aan een Traffic Manager-profiel, worden bijgehouden met behulp van hun resource-id's. Wanneer een Azure-resource die wordt gebruikt als eindpunt (bijvoorbeeld openbaar IP, klassieke cloudservice, web-app of een ander Traffic Manager-profiel dat op een geneste manier wordt gebruikt), wordt verplaatst naar een andere resourcegroep of een ander abonnement, wordt de resource-id gewijzigd. In dit scenario moet u momenteel het Traffic Manager-profiel bijwerken door eerst de eindpunten te verwijderen en vervolgens weer toe te voegen aan het profiel.

Zie Een eindpunt verplaatsen voor meer informatie.

Eindpuntbewaking in Traffic Manager

Is Traffic Manager bestand tegen fouten in Azure-regio's?

Traffic Manager is een belangrijk onderdeel van de levering van maximaal beschikbare toepassingen in Azure. Om hoge beschikbaarheid te leveren, moet Traffic Manager een uitzonderlijk hoog beschikbaarheidsniveau hebben en bestand zijn tegen regionale storingen.

Traffic Manager-onderdelen zijn standaard bestand tegen een volledige fout in een Azure-regio. Deze tolerantie is van toepassing op alle Traffic Manager-onderdelen: de DNS-naamservers, de API, de opslaglaag en de eindpuntbewakingsservice.

In het onwaarschijnlijke geval van een storing in een hele Azure-regio zal Traffic Manager normaal blijven functioneren. Toepassingen die in meerdere Azure-regio's zijn geïmplementeerd, kunnen afhankelijk zijn van Traffic Manager om verkeer naar een beschikbaar exemplaar van hun toepassing te leiden.

Hoe heeft de keuze van de locatie van de resourcegroep invloed op Traffic Manager?

Traffic Manager is één globale service. Het is niet regionaal. De locatie van de resourcegroep maakt geen verschil voor Traffic Manager-profielen die in die resourcegroep zijn geïmplementeerd.

Azure Resource Manager vereist dat alle resourcegroepen een locatie opgeven, waarmee de standaardlocatie wordt bepaald voor resources die in die resourcegroep zijn geïmplementeerd. Wanneer u een Traffic Manager-profiel maakt, wordt dit gemaakt in een resourcegroep. Alle Traffic Manager-profielen gebruiken globaal als locatie, waarbij de standaardresourcegroep wordt overschreven.

Hoe kan ik de huidige status van elk eindpunt bepalen?

De huidige bewakingsstatus van elk eindpunt, naast het algehele profiel, wordt weergegeven in Azure Portal. Deze informatie is ook beschikbaar via de Traffic Monitor REST API, PowerShell-cmdlets en platformoverschrijdende Azure CLI.

U kunt Azure Monitor ook gebruiken om de status van uw eindpunten bij te houden en een visuele weergave ervan te bekijken. Zie de documentatie voor Azure Monitoring voor meer informatie over het gebruik van Azure Monitor.

Kan ik HTTPS-eindpunten bewaken?

Ja. Traffic Manager biedt ondersteuning voor het testen via HTTPS. Configureer HTTPS als het protocol in de bewakingsconfiguratie.

Traffic Manager kan geen certificaatvalidatie opgeven, waaronder:

  • Certificaten aan de serverzijde worden niet gevalideerd
  • SNI-certificaten aan serverzijde worden niet gevalideerd
  • Clientcertificaten worden niet ondersteund

Gebruik ik een IP-adres of een DNS-naam bij het toevoegen van een eindpunt?

Traffic Manager biedt ondersteuning voor het toevoegen van eindpunten op drie manieren, zoals een DNS-naam, als een IPv4-adres en als een IPv6-adres. Als het eindpunt wordt toegevoegd als een IPv4- of IPv6-adres, is het queryantwoord respectievelijk van recordtype A of AAAA. Als het eindpunt is toegevoegd als een DNS-naam, is het queryantwoord van recordtype CNAME. Het toevoegen van eindpunten als IPv4- of IPv6-adres is alleen toegestaan als het eindpunt van het type Extern is. Alle routeringsmethoden en bewakingsinstellingen worden ondersteund door de drie typen eindpuntadressering.

Welke typen IP-adressen kan ik gebruiken bij het toevoegen van een eindpunt?

Met Traffic Manager kunt u IPv4- of IPv6-adressen gebruiken om eindpunten op te geven. Hieronder vindt u enkele beperkingen:

  • Adressen die overeenkomen met gereserveerde privé-IP-adresruimten zijn niet toegestaan. Deze adressen omvatten de adressen die worden genoemd in RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 en RFC 5771
  • Het adres mag geen poortnummers bevatten (u kunt de poorten opgeven die moeten worden gebruikt in de profielconfiguratie-instellingen)
  • Er kunnen geen twee eindpunten in hetzelfde profiel hetzelfde doel-IP-adres hebben

Kan ik verschillende typen eindpuntadressering in één profiel gebruiken?

Nee, Traffic Manager staat u niet toe om eindpuntadresseringstypen in een profiel te combineren, met uitzondering van het geval van een profiel met het routeringstype MultiValue, waarin u IPv4- en IPv6-adresseringstypen kunt combineren

Wat gebeurt er wanneer het recordtype van een binnenkomende query verschilt van het recordtype dat is gekoppeld aan het adresseringstype van de eindpunten?

Wanneer een query wordt ontvangen op basis van een profiel, vindt Traffic Manager eerst het eindpunt dat moet worden geretourneerd volgens de opgegeven routeringsmethode en de status van de eindpunten. Vervolgens wordt gekeken naar het recordtype dat is aangevraagd in de binnenkomende query en het recordtype dat is gekoppeld aan het eindpunt voordat er een antwoord wordt geretourneerd op basis van de onderstaande tabel.

Voor profielen met een andere routeringsmethode dan MultiValue:

Binnenkomende queryaanvraag Eindpunttype Antwoord opgegeven
WILLEKEURIG A / AAAA / CNAME Doeleindpunt
A A/ CNAME Doeleindpunt
A AAAA NODATA
AAAA AAAA / CNAME Doeleindpunt
AAAA A NODATA
CNAME CNAME Doeleindpunt
CNAME A / AAAA NODATA

Voor profielen met routeringsmethode ingesteld op MultiValue:

Binnenkomende queryaanvraag Eindpunttype Antwoord opgegeven
WILLEKEURIG Mix van A en AAAA Doeleindpunten
A Mix van A en AAAA Alleen doeleindpunten van het type A
AAAA Mix van A en AAAA Alleen doeleindpunten van het type AAAA
CNAME Mix van A en AAAA NODATA

Kan ik een profiel gebruiken met IPv4-/IPv6-geadresseerde eindpunten in een genest profiel?

Ja, met uitzondering dat een profiel van het type MultiValue geen bovenliggend profiel kan zijn in een geneste profielset.

Ik heb een eindpunt van een webtoepassing gestopt in mijn Traffic Manager-profiel, maar ik ontvang geen verkeer, zelfs niet nadat ik het opnieuw heb opgestart. Hoe kan ik dit oplossen?

Wanneer een Eindpunt van een Azure-webtoepassing wordt gestopt, stopt Traffic Manager met het controleren van de status en start u de statuscontroles pas opnieuw nadat is vastgesteld dat het eindpunt opnieuw is opgestart. Als u deze vertraging wilt voorkomen, schakelt u dat eindpunt uit en schakelt u dit opnieuw in het Traffic Manager-profiel uit nadat u het eindpunt opnieuw hebt opgestart.

Kan ik Traffic Manager gebruiken, zelfs als mijn toepassing geen ondersteuning heeft voor HTTP of HTTPS?

Ja. U kunt TCP opgeven als het bewakingsprotocol en Traffic Manager kan een TCP-verbinding initiëren en wachten op een reactie van het eindpunt. Als het eindpunt antwoordt op de verbindingsaanvraag met een antwoord om de verbinding tot stand te brengen, binnen de time-outperiode, wordt dat eindpunt gemarkeerd als in orde.

Welke specifieke antwoorden zijn vereist vanaf het eindpunt bij het gebruik van TCP-bewaking?

Wanneer TCP-bewaking wordt gebruikt, start Traffic Manager een tcp-handshake in drie richtingen door een SYN-aanvraag naar het eindpunt op de opgegeven poort te verzenden. Vervolgens wordt gewacht op een SYN-ACK-antwoord van het eindpunt gedurende een bepaalde periode (opgegeven in de time-outinstellingen).

  • Als een SYN-ACK-antwoord wordt ontvangen binnen de time-outperiode die is opgegeven in de bewakingsinstellingen, wordt dat eindpunt beschouwd als in orde. Een FIN of FIN-ACK is de verwachte reactie van Traffic Manager wanneer deze regelmatig een socket beëindigt.
  • Als er een SYN-ACK-antwoord wordt ontvangen na de opgegeven time-out, reageert Traffic Manager met een RST om de verbinding opnieuw in te stellen.

Hoe snel verplaatst Traffic Manager mijn gebruikers van een beschadigd eindpunt?

Traffic Manager biedt meerdere instellingen waarmee u het failovergedrag van uw Traffic Manager-profiel als volgt kunt beheren:

  • u kunt opgeven dat Traffic Manager de eindpunten vaker test door het testinterval op 10 seconden in te stellen. Dit zorgt ervoor dat elk eindpunt dat niet in orde is, zo snel mogelijk kan worden gedetecteerd.
  • u kunt opgeven hoe lang moet worden gewacht voordat er een time-out optreedt voor een statuscontroleaanvraag (minimale time-outwaarde is 5 sec).
  • u kunt opgeven hoeveel fouten kunnen optreden voordat het eindpunt als beschadigd wordt gemarkeerd. Deze waarde kan laag zijn als 0. In dat geval wordt het eindpunt gemarkeerd als beschadigd zodra de eerste statuscontrole mislukt. Het gebruik van de minimumwaarde van 0 voor het getolereerde aantal fouten kan er echter toe leiden dat eindpunten uit de rotatie worden gehaald vanwege tijdelijke problemen die zich kunnen voordoen op het moment van testen.
  • u kunt de time-to-live (TTL) opgeven voor het DNS-antwoord dat zo laag is als 0. Dit betekent dat DNS-resolvers het antwoord niet in de cache kunnen opslaan en dat elke nieuwe query een antwoord krijgt dat de meest recente statusinformatie bevat die traffic manager heeft.

Door deze instellingen te gebruiken, kan Traffic Manager failovers bieden die minder dan 10 seconden duren nadat een eindpunt niet in orde is en er een DNS-query wordt uitgevoerd op basis van het bijbehorende profiel.

Hoe kan ik verschillende bewakingsinstellingen opgeven voor verschillende eindpunten in een profiel?

De bewakingsinstellingen van Traffic Manager zijn per profielniveau. Als u voor slechts één eindpunt een andere bewakingsinstelling moet gebruiken, kunt u dit eindpunt gebruiken als een genest profiel waarvan de bewakingsinstellingen afwijken van het bovenliggende profiel.

Hoe kan ik HTTP-headers toewijzen aan de Traffic Manager-statuscontroles aan mijn eindpunten?

Met Traffic Manager kunt u aangepaste headers opgeven in de HTTP(S)-statuscontroles die worden gestart voor uw eindpunten. Als u een aangepaste header wilt opgeven, kunt u dat doen op profielniveau (van toepassing op alle eindpunten) of op eindpuntniveau opgeven. Als een header op beide niveaus is gedefinieerd, overschrijft de header die op eindpuntniveau is opgegeven het profielniveau 1. Een veelvoorkomend gebruiksvoorbeeld hiervoor is het opgeven van hostheaders, zodat Traffic Manager-aanvragen correct kunnen worden gerouteerd naar een eindpunt dat wordt gehost in een omgeving met meerdere tenants. Een ander gebruiksvoorbeeld hiervan is om Traffic Manager-aanvragen te identificeren vanuit de HTTP(S)-aanvraaglogboeken van een eindpunt

Welke hostheader gebruikt eindpuntstatuscontroles?

Als er geen aangepaste hostheaderinstelling wordt opgegeven, is de hostheader die wordt gebruikt door Traffic Manager de DNS-naam van het eindpuntdoel dat is geconfigureerd in het profiel, indien beschikbaar.

Wat zijn de IP-adressen van waaruit de statuscontroles afkomstig zijn?

Zie dit artikel voor meer informatie over het ophalen van de lijsten met IP-adressen waaruit Traffic Manager-statuscontroles afkomstig kunnen zijn. U kunt REST API, Azure CLI of Azure PowerShell gebruiken om de meest recente lijst op te halen. Controleer de IP-adressen die worden vermeld om ervoor te zorgen dat binnenkomende verbindingen van deze IP-adressen zijn toegestaan op de eindpunten om de status ervan te controleren.

Voorbeeld van Azure PowerShell:

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

Notitie

Openbare IP-adressen kunnen zonder kennisgeving worden gewijzigd. Zorg ervoor dat u de meest recente informatie ophaalt met behulp van de Service Tag Discovery-API of het downloadbare JSON-bestand.

Hoeveel statuscontroles voor mijn eindpunt kan ik verwachten van Traffic Manager?

Het aantal Traffic Manager-statuscontroles dat uw eindpunt bereikt, is afhankelijk van het volgende:

  • de waarde die u hebt ingesteld voor het bewakingsinterval (kleiner interval betekent dat er in een bepaalde periode meer aanvragen op uw eindpunt binnenkomen).
  • het aantal locaties waar de statuscontroles vandaan komen (de IP-adressen van waaruit u deze controles kunt verwachten, worden vermeld in de voorgaande veelgestelde vragen).

Hoe krijg ik een melding als een van mijn eindpunten uitvalt?

Een van de metrische gegevens van Traffic Manager is de status van eindpunten in een profiel. U kunt dit zien als een samenvoeging van alle eindpunten in een profiel (bijvoorbeeld 75% van uw eindpunten is in orde) of, op eindpuntniveau. Metrische gegevens van Traffic Manager worden weergegeven via Azure Monitor en u kunt de waarschuwingsmogelijkheden ervan gebruiken om meldingen te ontvangen wanneer er een wijziging is in de status van uw eindpunt. Zie de metrische gegevens en waarschuwingen van Traffic Manager voor meer informatie.

Geneste Traffic Manager-profielen

Hoe kan ik geneste profielen configureren?

Geneste Traffic Manager-profielen kunnen worden geconfigureerd met zowel De Azure Resource Manager als de klassieke Azure REST API's, Azure PowerShell-cmdlets en platformoverschrijdende Azure CLI-opdrachten. Ze worden ook ondersteund via de nieuwe Azure-portal.

Hoeveel nestlagen ondersteunt Traffic Manger?

U kunt profielen tot 10 niveaus diep nesten. 'Lussen' zijn niet toegestaan.

Kan ik andere eindpunttypen combineren met geneste onderliggende profielen in hetzelfde Traffic Manager-profiel?

Ja. Er zijn geen beperkingen voor het combineren van eindpunten van verschillende typen binnen een profiel.

Hoe is het factureringsmodel van toepassing op Geneste profielen?

Er is geen negatieve invloed op het gebruik van geneste profielen.

Traffic Manager-facturering heeft twee onderdelen: eindpuntstatuscontroles en miljoenen DNS-query's

  • Statuscontroles voor eindpunten: er worden geen kosten in rekening gebracht voor een onderliggend profiel wanneer dit is geconfigureerd als een eindpunt in een bovenliggend profiel. Bewaking van de eindpunten in het onderliggende profiel wordt op de gebruikelijke manier gefactureerd.
  • DNS-query's: elke query wordt slechts eenmaal geteld. Een query op een bovenliggend profiel dat een eindpunt uit een onderliggend profiel retourneert, wordt alleen meegeteld voor het bovenliggende profiel.

Zie de pagina met prijzen van Traffic Manager voor meer informatie.

Is er een invloed op de prestaties voor geneste profielen?

Nee, er is geen invloed op de prestaties bij het gebruik van geneste profielen.

De Traffic Manager-naamservers doorlopen de profielhiërarchie intern bij het verwerken van elke DNS-query. Een DNS-query naar een bovenliggend profiel kan een DNS-antwoord ontvangen met een eindpunt van een onderliggend profiel. Er wordt één CNAME-record gebruikt, ongeacht of u één profiel of geneste profielen gebruikt. U hoeft geen CNAME-record te maken voor elk profiel in de hiërarchie.

Hoe berekent Traffic Manager de status van een genest eindpunt in een bovenliggend profiel?

Het bovenliggende profiel voert geen statuscontroles rechtstreeks uit op het onderliggende profiel. In plaats daarvan wordt de status van de eindpunten van het onderliggende profiel gebruikt om de algehele status van het onderliggende profiel te berekenen. Deze informatie wordt doorgegeven aan de geneste profielhiërarchie om de status van het geneste eindpunt te bepalen. Het bovenliggende profiel gebruikt deze geaggregeerde status om te bepalen of het verkeer naar het onderliggende element kan worden omgeleid.

In de volgende tabel wordt het gedrag van Traffic Manager-statuscontroles voor een genest eindpunt beschreven.

Status van onderliggende profielcontrole Status van bovenliggende eindpuntmonitor Opmerkingen
Disabled. Het onderliggende profiel is uitgeschakeld. Gestopt De status van het bovenliggende eindpunt is gestopt, niet uitgeschakeld. De status Uitgeschakeld is gereserveerd om aan te geven dat u het eindpunt in het bovenliggende profiel hebt uitgeschakeld.
Gedegradeerd. Ten minste één eindpunt voor een onderliggend profiel heeft een gedegradeerde status. Online: het aantal online-eindpunten in het onderliggende profiel is ten minste de waarde van MinChildEndpoints.
CheckingEndpoint: het aantal Online plus CheckingEndpoint-eindpunten in het onderliggende profiel is ten minste de waarde van MinChildEndpoints.
Gedegradeerd: anders.		 Verkeer wordt doorgestuurd naar een eindpunt van status CheckingEndpoint. Als MinChildEndpoints te hoog is ingesteld, wordt het eindpunt altijd gedegradeerd.
Online. Ten minste één eindpunt voor een onderliggend profiel is een onlinestatus. Er is geen eindpunt met de gedegradeerde status. Zie hierboven.
CheckingEndpoints. Ten minste één onderliggend profieleindpunt is 'CheckingEndpoint'. Er zijn geen eindpunten 'Online' of 'Gedegradeerd' Hetzelfde als hierboven.
Inactief. Alle eindpunten van het onderliggende profiel zijn uitgeschakeld of gestopt, of dit profiel heeft geen eindpunten. Gestopt

Belangrijk

Bij het beheren van onderliggende profielen onder een bovenliggend profiel in Azure Traffic Manager kan er een probleem optreden als u tegelijkertijd twee onderliggende profielen uitschakelt en inschakelt. Als deze acties tegelijkertijd plaatsvinden, kan er een korte periode zijn waarin beide eindpunten zijn uitgeschakeld, wat leidt tot het bovenliggende profiel dat een gecompromitteerde status invoert.

Om dit probleem te voorkomen, moet u voorzichtig zijn bij het aanbrengen van gelijktijdige wijzigingen in onderliggende profielen. Overweeg deze acties enigszins te staken om onbedoelde onderbrekingen in de configuratie van uw verkeersbeheer te voorkomen.

Waarom kan ik geen Uitgebreide ondersteuningseindpunten voor Azure Cloud Services toevoegen aan mijn Traffic Manager-profiel?

Als u Azure Cloud Extended-eindpunten wilt toevoegen aan een Traffic Manager-profiel, moet de resourcegroep compatibiliteit hebben met de AZURE Service Management-API (ASM). Profielen die zich in de oudere resourcegroep bevinden, moeten voldoen aan asm-API-standaarden, waardoor het opnemen van openbare IP-adreseindpunten of eindpunten uit een ander abonnement dan dat van het profiel wordt verboden. U kunt dit oplossen door uw Traffic Manager-profiel en de bijbehorende resources te verplaatsen naar een nieuwe resourcegroep die compatibel is met de ASM-API.

Volgende stappen: