Häufig gestellte Fragen (FAQ) zu Traffic Manager

Traffic Manager-Grundlagen

Welche IP-Adresse verwendet Traffic Manager?

Wie unter Funktionsweise von Traffic Manager erläutert, funktioniert Traffic Manager auf der DNS-Ebene (Domain Name System). Clients werden mithilfe von DNS-Antworten an den geeigneten Dienstendpunkt umgeleitet. Anschließend stellen Clients dann eine direkte Verbindung mit dem Dienstendpunkt her (nicht über Traffic Manager).

Traffic Manager bietet daher keinen Endpunkt und keine IP-Adresse für die Verbindungsherstellung von Clients. Wenn Sie für Ihren Dienst eine statische IP-Adresse verwenden möchten, muss diese im Dienst konfiguriert werden, nicht im Traffic Manager.

Welche Arten von Datenverkehr können mithilfe von Traffic Manager weitergeleitet werden?

Wie unter Funktionsweise von Traffic Manager beschrieben, kann ein Traffic Manager-Endpunkt ein beliebiger Dienst mit Internetzugriff sein, der innerhalb oder außerhalb von Azure gehostet wird. Daher kann mithilfe von Traffic Manager Datenverkehr vom öffentlichen Internet an eine Gruppe von Endpunkten weitergeleitet werden, die auch über Internetzugriff verfügen. Bei Endpunkten innerhalb eines privaten Netzwerks (etwa eine interne Version von Azure Load Balancer) oder bei DNS-Anforderungen von Benutzern über solche internen Netzwerke kann Traffic Manager nicht zur Weiterleitung des Datenverkehrs verwendet werden.

Unterstützt Traffic Manager persistente Sitzungen?

Traffic Manager arbeitet, wie unter Funktionsweise von Traffic Manager erläutert, auf der DNS-Ebene. Clients werden mithilfe von DNS-Antworten an den geeigneten Dienstendpunkt umgeleitet. Anschließend stellen Clients dann eine direkte Verbindung mit dem Dienstendpunkt her (nicht über Traffic Manager). Traffic Manager hat somit keinen Zugriff auf den HTTP-Datenverkehr zwischen Client und Server.

Zudem handelt es sich bei der IP-Quelladresse der von Traffic Manager empfangenen DNS-Abfrage um die IP-Adresse des rekursiven DNS-Diensts (und nicht um die IP-Adresse des Clients). Aus diesem Grund kann Traffic Manager keine individuellen Clients nachverfolgen und keine persistenten Sitzungen implementieren. Diese Einschränkung besteht bei allen DNS-basierten Systemen zur Datenverkehrsverwaltung, nicht nur bei Verwendung von Traffic Manager.

Warum tritt bei mir ein HTTP-Fehler auf, wenn ich Traffic Manager verwende?

Traffic Manager arbeitet, wie unter Funktionsweise von Traffic Manager erläutert, auf der DNS-Ebene. Clients werden mithilfe von DNS-Antworten an den geeigneten Dienstendpunkt umgeleitet. Anschließend stellen Clients dann eine direkte Verbindung mit dem Dienstendpunkt her (nicht über Traffic Manager). HTTP-Datenverkehr zwischen Client und Server wird nicht über Traffic Manager abgewickelt. Daher müssen auftretende HTTP-Fehler auf Ihre Anwendung zurückzuführen sein. Damit der Client eine Verbindung mit der Anwendung herstellen kann, werden alle Schritte zur DNS-Auflösung durchgeführt. Hierzu gehört auch die Interaktion von Traffic Manager im Datenverkehrsfluss der Anwendung.

Konzentrieren Sie sich daher bei der weiteren Untersuchung auf die Anwendung.

Der vom Browser des Clients gesendete HTTP-Hostheader ist die häufigste Ursache für Probleme. Konfigurieren Sie die Anwendung so, dass der richtige Hostheader für den verwendeten Domänennamen akzeptiert wird. Informationen zu Endpunkten, die den Azure App Service nutzen, finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens für eine Web-App in Azure App Services, der Traffic Manager verwendet.

Wie kann ich das Problem „500 (Interner Serverfehler)“ bei der Nutzung des Traffic Manager beheben?

Wenn Ihr Client oder Ihre Anwendung einen HTTP 500-Fehler empfängt, während der Traffic Manager verwendet wird, kann eine veraltete DNS-Abfrage der Grund dafür sein. Deaktivieren Sie den DNS-Cache, und erlauben Sie dem Client, eine neue DNS-Abfrage auszustellen, um das Problem zu beheben.

Wenn ein Dienstendpunkt nicht mehr reagiert, werden Clients und Anwendungen, die diesen Endpunkt verwenden, erst dann zurückgesetzt, wenn der DNS-Cache aktualisiert wird. Wie lange die Daten zwischengespeichert werden, hängt von der TTL-Eigenschaft des DNS-Eintrags ab. Weitere Informationen finden Sie unter Traffic Manager und DNS-Cache.

Weitere Informationen finden Sie in diesem Artikel mit den folgenden häufig gestellten Fragen:

• Was ist DNS TTL, und wie wirkt DNS TTL sich auf meine Benutzer aus?
• Wie hoch oder niedrig kann ich die Gültigkeitsdauer (TTL) für Traffic Manager-Antworten festlegen?
• Wie kann ich das Volumen an mein Profil gerichteter Abfragen nachvollziehen?

Wie wirkt sich die Verwendung von Traffic Manager auf die Leistung aus?

Traffic Manager arbeitet, wie unter Funktionsweise von Traffic Manager erläutert, auf der DNS-Ebene. Da von Clients eine direkte Verbindung mit den Dienstendpunkten hergestellt wird, hat die Verwendung von Traffic Manager keinerlei Auswirkungen auf die Leistung, sobald die Verbindung hergestellt wurde.

Da sich Traffic Manager mit Anwendungen auf der DNS-Ebene integriert, muss ein zusätzlicher DNS-Lookup erfolgen, der in die DNS-Auflösungskette eingefügt werden muss. Die DNS-Auflösungszeit wird durch Traffic Manager nur minimal beeinträchtigt. Traffic Manager verwendet ein globales Netzwerk von Namenservern sowie Anycastnetzwerke, um sicherzustellen, dass DNS-Abfragen immer an den nächstgelegenen verfügbaren Namenserver weitergeleitet werden. Dank der Zwischenspeicherung von DNS-Antworten wirkt sich die zusätzliche, durch die Verwendung von Traffic Manager bedingte DNS-Latenz lediglich auf einen Bruchteil der Sitzungen aus.

Mit der leistungsorientierten Methode wird der Datenverkehr an den nächstgelegenen verfügbaren Endpunkt geleitet. Das führt dazu, dass die mit dieser Methode verbundenen Auswirkungen auf die Gesamtleistung minimal sind. Eine höhere DNS-Latenz muss durch eine geringere Netzwerklatenz für den Endpunkt ausgeglichen werden.

Welche Anwendungsprotokolle kann ich mit Traffic Manager verwenden?

Traffic Manager arbeitet, wie unter Funktionsweise von Traffic Manager erläutert, auf der DNS-Ebene. Nach Abschluss des DNS-Lookups stellen Clients eine direkte Verbindung mit dem Dienstendpunkt her (nicht über Traffic Manager). Daher kann für diese Verbindung ein beliebiges Anwendungsprotokoll verwendet werden. Bei Auswahl von TCP als Überwachungsprotokoll kann die Endpunkt-Systemüberwachung durch Traffic Manager ohne Anwendungsprotokolle erfolgen. Wenn Sie wünschen, dass die Integrität mithilfe eines Anwendungsprotokolls überprüft wird, muss der Endpunkt entweder auf HTTP oder HTTPS GET-Anforderungen reagieren können.

Kann ich Traffic Manager mit einem reinen Domänennamen verwenden?

Ja. Um zu erfahren, wie Sie einen Aliaseintrag für Ihre Apex-Domänennamen erstellen, um auf ein Azure Traffic Manager-Profil zu verweisen, finden Sie unter Konfigurieren eines Alias-Ressourceneintrags zur Unterstützung von Apex-Domänennamen mit Traffic Manager.

Berücksichtigt Traffic Manager beim Verarbeiten von DNS-Abfragen die Clientsubnetzadresse?

Ja. Neben der Quell-IP-Adresse der DNS-Abfrage (in der Regel die IP-Adresse des DNS-Resolvers) berücksichtigt Traffic Manager auch die Client-Subnetzadresse, wenn sie in die DNS-Abfrage einbezogen wird, die vom DNS-Resolver gesendet wird, der die Anforderung im Auftrag des Endbenutzers sendet. Diese IP-Adressen werden verwendet, um geografische Methoden, Leistung und Subnetzrouting zu optimieren. Insbesondere RFC 7871 – Client Subnet in DNS Queries, über den ein Extension Mechanism for DNS (EDNS0) bereitgestellt wird, kann die Clientsubnetzadresse von unterstützenden Resolvern weitergeben.

Was ist DNS TTL, und wie wirkt DNS TTL sich auf meine Benutzer aus?

Wenn eine DNS-Abfrage bei Traffic Manager eingeht, legt er in der Antwort einen als Gültigkeitsdauer (Time To Live, TTL) bezeichneten Wert fest. Dieser Wert gibt Downstream-DNS-Resolvern in der Einheit Sekunden an, wie lange diese Antwort zwischengespeichert werden soll. Es ist zwar nicht garantiert, dass die DNS-Resolver dieses Ergebnis zwischenspeichern, doch das Zwischenspeichern ermöglicht ihnen, auf etwaige weitere Abfragen aus dem Cache heraus zu antworten, statt auf Traffic Manager-DNS-Server zuzugreifen. Dies wirkt sich wie folgt auf die Antworten aus:

• Eine höhere Gültigkeitsdauer (TTL) reduziert die Anzahl der bei den Traffic Manager-DNS-Servern eingehenden Abfragen, was die Kosten für einen Kunden verringern kann, da die Anzahl der verarbeiteten Abfragen eine abrechenbare Nutzung ist.
• Eine höhere Gültigkeitsdauer (TTL) kann möglicherweise den Zeitaufwand für eine DNS-Suche reduzieren.
• Eine höhere Gültigkeitsdauer (TTL) bedeutet auch, dass Ihre Daten nicht die aktuellen Integritätsinformationen wiedergeben, die Traffic Manager mithilfe seiner Test-Agents ermittelt hat.

Wie hoch oder niedrig kann ich die Gültigkeitsdauer (TTL) für Traffic Manager-Antworten festlegen?

Sie können die DNS-TTL pro Profil auf minimal 0 und maximal 2.147.483.647 Sekunden festlegen (der mit RFC-1035 kompatible Maximalbereich). Der TTL-Wert 0 bedeutet, dass Downstream-DNS-Resolver Abfrageantworten nicht zwischenspeichern und alle Abfragen zur Auflösung an die Traffic Manager-DNS-Server gesendet werden.

Wie kann ich das Volumen an mein Profil gerichteter Abfragen nachvollziehen?

Eine der von Traffic Manager bereitgestellten Metriken ist die Anzahl von Abfragen, die von einem Profil beantwortet werden. Sie können diese Informationen in Form einer Profilebenenaggregation erhalten oder weiter aufschlüsseln, um das Volumen von Abfragen anzuzeigen, wo bestimmte Endpunkte zurückgegeben wurden. Darüber hinaus können Sie Warnungen einrichten, damit Sie benachrichtigt werden, wenn das Volumen der Antworten auf Abfragen die von Ihnen festgelegten Bedingungen überschreitet. Weitere Informationen finden Sie unter Traffic Manager-Metriken und -Warnungen.

Wie lange dauert es nach dem Löschen eines Traffic Manager-Profils, bis der Name des Profils wiederverwendet werden kann?

Wenn Sie ein Traffic Manager-Profil löschen, wird der zugehörige Domänenname für einen bestimmten Zeitraum reserviert. Andere Traffic Manager-Profile im selben Mandanten können den Namen sofort wiederverwenden. Ein anderer Azure-Mandant kann diesen Profilnamen jedoch erst nach Ablauf der Reservierung verwenden. Mit diesem Feature behalten Sie die Kontrolle über die von Ihnen bereitgestellten Namespaces, sodass Sie sich keine Sorgen machen müssen, dass der Name möglicherweise von einem anderen Mandanten übernommen wird.

Wenn Ihr Traffic Manager-Profilname beispielsweise label1 lautet, ist label1.trafficmanager.net für Ihren Mandanten reserviert, selbst wenn Sie das Profil löschen. Untergeordnete Namespaces wie xyz.label1 oder 123.abc.label1 sind ebenfalls reserviert. Wenn die Reservierung abläuft, wird der Name anderen Mandanten zur Verfügung gestellt. Der mit einem deaktivierten Profil verknüpfte Name bleibt unbegrenzt reserviert. Wenn Sie Fragen dazu haben, wie lange ein Name reserviert ist, wenden Sie sich an Ihr Kontoteam.

Welche Version von TLS ist für Traffic Manager erforderlich?

Es ist nicht bekannt, dass die Microsoft-Implementierung älterer TLS-Versionen gefährdet ist. TLS 1.2 und spätere Versionen bieten jedoch eine verbesserte Sicherheit mit Funktionen wie Perfect Forward Secrecy und stärkeren Cipher Suites. Um die Sicherheit zu erhöhen und eine erstklassige Verschlüsselung Ihrer Daten zu gewährleisten, erfordert Traffic Manger ab dem 28. Februar 2025, dass Interaktionen mit Diensten mit Transport Layer Security (TLS) 1.2 oder höher gesichert werden. Die Traffic Manger-Unterstützung für TLS 1.0 und 1.1 endet an diesem Datum. Dieses Datum kann sich vom Azure-weiten Datum für die Einstellung von TLS 1.0 und TLS 1.1 unterscheiden.

Empfohlene Maßnahme

Um Dienstunterbrechungen zu vermeiden, müssen Ressourcen, die mit Traffic Manager interagieren, TLS 1.2 oder höher verwenden.

• Wenn die Ressourcen TLS 1.2 oder höher bereits nutzen, brauchen Sie nichts weiter tun.
• Wenn die Ressourcen noch TLS 1.0 oder 1.1 verwenden, migrieren Sie bis 28. Februar 2025 auf TLS 1.2 oder höher.

Informationen zum Migrieren von TLS 1.0 und 1.1 zu TLS 1.2 finden Sie unter Beheben des TLS 1.0-Problems.

Geografische Methode für das Datenverkehrsrouting in Traffic Manager

Was sind einige Anwendungsfälle, in denen geografisches Routing nützlich ist?

Der geografische Routingtyp kann in jedem Szenario verwendet werden, in dem ein Azure-Kunde seine Benutzer auf der Grundlage geografischer Regionen unterscheiden muss. Beispielsweise können Sie mithilfe des geografischen Routings für Benutzer aus bestimmten Regionen eine andere Benutzeroberfläche anzeigen als für Benutzer aus anderen Regionen. Ein weiteres Beispiel wäre die Einhaltung ortsbezogener Datenhoheitsmandate, für die es erforderlich ist, dass Benutzer aus einer bestimmten Region nur von Endpunkten in der betreffenden Region bedient werden.

Wie entscheide ich, ob ich die leistungsbezogene oder geografische Routingmethode verwenden sollte?

Der Hauptunterschied zwischen diesen zwei gängigen Routingmethoden ist, dass das primäre Ziel bei der leistungsbezogenen Routingmethode im Senden von Datenverkehr an den Endpunkt besteht, der dem Aufrufer die niedrigste Latenz bieten kann; bei der geografischen Routingmethode besteht das primäre Ziel hingegen im Erzwingen eines geografischen Zauns für Aufrufer, damit Sie sie absichtlich an einen bestimmten Endpunkt weiterleiten können. Die Überlappung geschieht, weil eine Korrelation zwischen geografischer Nähe und geringerer Latenz besteht, obwohl dies nicht immer zutrifft. Möglicherweise gibt es einen Endpunkt in einer anderen Region, der dem Anrufer eine bessere Latenzzeit bietet. In diesem Fall schickt das Performance-Routing den Benutzer zu diesem Endpunkt, aber das geografische Routing schickt ihn immer zu dem Endpunkt, den Sie für seine geografische Region zugeordnet haben. Das folgende Beispiel soll dies noch mehr verdeutlichen: Mit der geografischen Routingmethode können Sie ungewöhnliche Zuordnungen vornehmen, z.B. allen Datenverkehr aus Asien an Endpunkte in den USA senden und allen US-Datenverkehr an Endpunkte in Asien. In diesem Fall tut Geographic Routing absichtlich genau das, wofür Sie es konfiguriert haben, und die Leistungsoptimierung ist nicht von Bedeutung.

Welche Bereiche werden von Traffic Manager für das geografische Routing unterstützt?

Die Landes/Regionshierarchie, die von Traffic Manager verwendet wird, finden Sie hier. Diese Seite wird jeweils auf dem neuesten Änderungsstatus gehalten, jedoch können Sie dieselben Informationen auch programmgesteuert mithilfe der Azure Traffic Manager-REST-API abrufen.

Wie bestimmt Traffic Manager, woher die Abfrage eines Benutzers stammt?

Traffic Manager untersucht die IP-Quelladresse der Abfrage (dabei handelt es sich mit größter Wahrscheinlichkeit um einen lokalen DNS-Resolver, der die Abfrage im Auftrag des Benutzers ausführt) und verwendet eine interne Zuordnung von IPs zu Regionen, um den Standort zu bestimmen. Diese Zuordnung wird fortlaufend aktualisiert, um Änderungen im Internet Rechnung zu tragen.

Ist garantiert, dass Traffic Manager immer den genauen geografischen Standort des Benutzers ermitteln kann?

Nein, Traffic Manager kann aus den folgenden Gründen nicht garantieren, dass die geografische Region, die wir aus der Quell-IP-Adresse einer DNS-Anfrage ableiten, immer dem Standort des Benutzers entspricht:

• 1. Wie in der vorherigen Frage beschrieben wurde, ist die erkannte Quell-IP-Adresse die eines DNS-Resolvers, der das Lookup im Namen des Benutzers durchführt. Wenngleich der geografische Standort des DNS-Resolvers ein guter Anhaltspunkt für den geografischen Standort des Benutzers ist, kann er je nach Speicherort des DNS-Resolverdients und dem vom Kunden verwendeten spezifischen DNS-Resolverdienst abweichen. Hier ein Beispiel: Ein in Malaysia ansässiger Kunde könnte in den Geräteeinstellungen einen DNS-Resolverdienst angeben, dessen zugehöriger DNS-Server in Singapur möglicherweise ausgewählt wird, um die Abfrageauflösungen für diesen Benutzer/Dienst durchzuführen. In diesem Fall kann Traffic Manager nur die IP-Adresse des Resolvers erkennen, die dem Standort in Singapur entspricht. Siehe hierzu auch die Frage zur Unterstützung von Clientsubnetzadressen auf dieser Seite.

• 2\. Traffic Manager verwendet eine interne Zuordnung zur Übersetzung der IP-Adressen in geografische Regionen. Wenngleich diese Zuordnung regelmäßig überprüft und aktualisiert wird, um ihre Genauigkeit zu erhöhen und der ständigen Weiterentwicklung des Internets Rechnung zu tragen, besteht dennoch die Möglichkeit, dass unsere Informationen den geografischen Standort nicht für alle IP-Adressen genau abbilden.

Muss sich ein Endpunkt physisch in der Region befinden, für die er für geografisches Routen konfiguriert ist?

Nein, der Standort des Endpunkts bringt keine Einschränkungen hinsichtlich der ihm zuzuordnenden Regionen mit sich. Beispielsweise können einem Endpunkt in der Azure-Region „US-Central“ alle Benutzer aus Indien zugeleitet werden.

Kann ich geografische Regionen Endpunkten in einem Profil zuweisen, das nicht für geografisches Routing konfiguriert ist?

Ja, falls die Routingmethode eines Profils nicht geografisch ist, können Sie die Azure Traffic Manager-REST-API verwenden, um Endpunkten im betreffenden Profil geografische Regionen zuzuweisen. Diese Konfiguration wird für Profile von nicht geografischen Routingtypen ignoriert. Wenn Sie ein derartiges Profil zu einem späteren Zeitpunkt auf den geografischen Routingtyp umstellen, kann Traffic Manager diese Zuordnungen verwenden.

Warum tritt ein Fehler auf, wenn ich versuche, die Routingmethode eines vorhandenen Profils in geografisch zu ändern?

Allen Endpunkten in einem Profil mit geografischem Routing muss mindestens eine geografische Region zugeordnet sein. Um ein vorhandenes Profil in den geografischen Routingtyp zu konvertieren, müssen Sie zuerst mithilfe der Azure Traffic Manager-REST-API allen seinen Endpunkten geografische Regionen zuordnen, bevor Sie den Routingtyp in geografisch ändern. Wenn Sie das Portal verwenden, löschen Sie zuerst die Endpunkte, ändern Sie die Routingmethode des Profils in geografisch und fügen Sie anschließend alle Endpunkte zusammen mit ihrer geografischen Regionszuordnung hinzu.

Warum wird es Kunden dringend empfohlen, in einem Profil mit aktiviertem geografischem Routing geschachtelte Profile anstelle von Endpunkten zu erstellen?

Bei der geografischen Routingmethode kann eine Region nur einem einzigen Endpunkt innerhalb eines Profils zugewiesen sein. Wenn der betreffende Endpunkt kein geschachtelter Typ mit zugeordnetem untergeordnetem Profil ist, fährt Traffic Manager auch bei fehlerhaftem Integritätsstatus des betreffenden Endpunkts fort, Datenverkehr an den Endpunkt zu senden, da die Alternative, gar keinen Datenverkehr zu senden, nicht besser ist. Traffic Manager führt auch dann kein Failover auf einen anderen Endpunkt aus, wenn die zugeordnete Region dem fehlerhaften Endpunkt „übergeordnet“ ist (z. B. erfolgt kein Failover auf einen anderen Endpunkt mit der Region „Europa“, wenn ein Endpunkt mit der Region „Spanien“ fehlerhaft ist). Dies erfolgt, um sicherzustellen, dass Traffic Manager die geografischen Grenzen beachtet, die Kunden in ihren Profilen konfiguriert haben. Damit der Vorzug des Failovers auf einen anderen Endpunkt genutzt werden kann, wenn ein Endpunkt fehlerhaft ist, wird empfohlen, dass geografische Regionen geschachtelten Profilen, die mehrere Endpunkte enthalten, anstelle von einzelnen Endpunkten zugeordnet werden. Wenn ein Endpunkt innerhalb des geschachtelten untergeordneten Profils ausfällt, kann auf diese Weise ein Failover des Datenverkehrs auf einen anderen Endpunkt innerhalb desselben geschachtelten untergeordneten Profils erfolgen.

Gibt es Einschränkungen hinsichtlich der API-Version, die diesen Routingtyp unterstützt?

Ja, nur die API-Version 2017-03-01 und höhere Versionen unterstützen den geografischen Routingtyp. Ältere API-Versionen können nicht zum Erstellen von Profilen vom geografischen Routingtyp oder zum Zuweisen von geografischen Regionen zu Endpunkten verwendet werden. Wenn eine ältere API-Version zum Abrufen von Profilen aus einem Azure-Abonnement verwendet wird, werden keine Profile mit dem geografischen Routingtyp zurückgegeben. Darüber hinaus wird bei Verwendung älterer API-Versionen für zurückgegebene Profile, die Endpunkte mit einer geografischen Regionszuweisung aufweisen, die geografische Regionszuweisung nicht angezeigt.

Subnetzroutingmethode für Datenverkehr in Traffic Manager

Welche Anwendungsfälle gibt es, in denen Subnetzrouting sinnvoll ist?

Das Subnetzrouting ermöglicht die Differenzierung der für bestimmte, durch die Quell-IP der IP-Adresse ihrer DNS-Anfragen identifizierte Benutzergruppen bereitgestellten Oberflächen. Beispielsweise könnten verschiedene Inhalte angezeigt werden, wenn Benutzer aus Ihrer Unternehmenszentrale auf eine Website zugreifen. Ein weiteres Beispiel wäre die Beschränkung von Benutzern bestimmter ISP auf Endpunkte, die nur IPv4-Verbindungen unterstützen, wenn diese ISP bei Verwendung von IPv6 eine unterdurchschnittliche Performance aufweisen.

Ein weiterer Grund für die Verwendung der Subnetzroutingmethode ist die Kombination mit anderen Profilen in einem verschachtelten Profilsatz. Wenn Sie beispielsweise für das Geofencing Ihrer Benutzer die geografische Routingmethode, für einen bestimmten ISP aber eine andere Routingmethode verwenden möchten, können Sie ein Profil mit einer Subnetzroutingmethode als übergeordnetes Profil verwenden und diesen ISP außer Kraft setzen, um ein bestimmtes Unterprofil zu verwenden, und das geografische Standardprofil für alle anderen Benutzer verwenden.

Wie erkennt Traffic Manager die IP-Adresse des Endbenutzers?

Endbenutzergeräte verwenden in der Regel einen DNS-Resolver, um das DNS-Lookup für sie durchzuführen. Die ausgehende IP-Adresse dieser Resolver wird von Traffic Manager als Quell-IP-Adresse betrachtet. Darüber hinaus prüft die Subnetzroutingmethode auch, ob es EDNS0 Extended Client Subnet-Informationen (ECS) gibt, die mit der Anforderung übergeben wurden. Wenn ECS-Informationen vorhanden sind, wird das Routing anhand dieser Adresse bestimmt. Sind keine ECS-Informationen vorhanden, wird die Quell-IP der Abfrage für Routingzwecke verwendet.

Wie kann ich bei der Verwendung von Subnetzrouting IP-Adressen angeben?

Die IP-Adresse, die einem Endpunkt zugeordnet werden soll, kann auf zwei Arten angegeben werden. Erstens können Sie die Quad-gepunktete dezimale Oktettnotation mit Start- und Endadresse verwenden, um den Bereich festzulegen (beispielsweise 1.2.3.4-5.6.7.8 oder 3.4.5.6-3.4.5.5.5.6). Zweitens können Sie den Bereich in der CIDR-Notation angeben (Beispiel: 1.2.3.3.0/24). Sie können mehrere Bereiche angeben und beide Notationstypen in einem Bereichssatz verwenden. Es gelten ein paar Einschränkungen.

• Adressbereiche dürfen sich nicht überschneiden, da jede IP-Adresse genau einem Endpunkt zugeordnet sein muss
• Die Startadresse darf nicht größer als die Endadresse sein
• Für die CIDR-Notation sollte die IP-Adresse vor dem „/“ die Netzwerkadresse dieses Bereichs sein (z. B. 1.2.3.0/24 ist gültig, aber 1.2.3.4.4/24 ist ungültig)

Wie kann ich bei der Verwendung von Subnetzrouting einen Fallbackendpunkt angeben?

Wenn Sie in einem Profil mit Subnetz-Routing einen Endpunkt haben, dem keine Subnetze zugeordnet sind, werden alle Anfragen, die nicht mit anderen Endpunkten übereinstimmen, hierher geleitet. Es wird dringend empfohlen, einen solchen Fallback-Endpunkt in Ihrem Profil einzurichten, da Traffic Manager eine NXDOMAIN-Antwort zurückgibt, wenn eine Anfrage eingeht, die keinem Endpunkt zugeordnet ist, oder wenn sie einem Endpunkt zugeordnet ist, aber dieser Endpunkt nicht in Ordnung ist.

Was geschieht, wenn ein Endpunkt in einem Profil vom Typ Subnetzrouting deaktiviert ist?

Wenn Sie in einem Profil mit Subnetz-Routing einen Endpunkt haben, der deaktiviert ist, verhält sich Traffic Manager so, als ob dieser Endpunkt und die dazugehörigen Subnetz-Zuordnungen nicht existieren würden. Wenn eine Abfrage empfangen wird, die mit der IP-Adresszuordnung übereingestimmt hätte, und der Endpunkt deaktiviert ist, gibt Traffic Manager einen Ersatzendpunkt zurück (einen ohne Zuordnungen) oder, wenn ein solcher Endpunkt nicht vorhanden ist, eine NXDOMAIN-Antwort.

Routingmethode „MultiValue“ für Datenverkehr in Traffic Manager

Was sind einige Anwendungsfälle, in denen MultiValue-Routing nützlich ist?

Das MultiValue-Routing gibt mehrere fehlerfreie Endpunkte in einer einzigen Abfrageantwort zurück. Der Hauptvorteil besteht darin, dass der Client, wenn ein Endpunkt fehlerhaft ist, mehr Möglichkeiten für erneute Versuche hat, ohne einen weiteren DNS-Aufruf zu tätigen (der möglicherweise den gleichen Wert aus einem Upstream-Cache zurückgibt). Dies gilt für verfügbarkeitssensible Anwendungen, deren Ausfallzeiten minimiert werden sollen. Eine weitere Verwendung für die MultiValue-Routingmethode sind Endpunkte, die sowohl IPv4- als auch IPv6-Adressen umfassen und für die Sie dem Anrufer beide Optionen zur Auswahl geben möchten, wenn er eine Verbindung zum Endpunkt herstellt.

Wie viele Endpunkte werden zurückgegeben, wenn das MultiValue-Routing verwendet wird?

Sie können die maximale Anzahl der zurückzugebenden Endpunkte angeben und MultiValue gibt bei einer Abfrage nicht mehr als so viele gesunde Endpunkte zurück. Der maximal mögliche Wert für diese Konfiguration ist 10.

Erhalte ich den gleichen Satz von Endpunkten, wenn das MultiValue-Routing verwendet wird?

Wir können nicht garantieren, dass bei jeder Abfrage dieselbe Gruppe von Endpunkten zurückgegeben wird. Dies wird auch dadurch beeinflusst, dass einige der Endpunkte fehlerhaft werden könnten, sodass sie dann nicht mehr in die Antwort einbezogen werden.

Benutzer-Realmessungen

Welche Vorteile hat die Verwendung von Benutzer-Realmessungen?

Wenn Sie die Routingmethode „Leistung“ verwenden, wählt Traffic Manager für Ihre Endbenutzer die beste Azure-Region aus, mit der eine Verbindung hergestellt werden kann. Hierzu werden die Quell-IP und das EDNS-Clientsubnetz (falls übergeben) untersucht und mit den Intelligence-Daten zur Netzwerklatenz des Diensts abgeglichen. Mithilfe von Benutzer-Realmessungen wird dies für Ihre Endbenutzer verbessert, indem deren Erfahrungen zu dieser Latenztabelle einen Beitrag leisten. Außerdem wird sichergestellt, dass diese Tabelle in adäquater Weise die Endbenutzernetzwerke widerspiegelt, aus denen die Endbenutzer Verbindungen mit Azure herstellen. Dies führt zu einer höheren Genauigkeit beim Routing Ihres Endbenutzers.

Kann ich Benutzer-Realmessungen auch für andere Regionen als Azure-Regionen verwenden?

Bei Benutzer-Realmessungen wird nur die Latenz bei der Erreichung von Azure-Regionen gemessen und gemeldet. Wenn Sie das leistungsbasierte Routing für Endpunkte verwenden, die in anderen Regionen als Azure-Regionen gehostet werden, können Sie trotzdem von diesem Feature profitieren. Sie verfügen so nämlich über mehr Latenzinformationen zur repräsentativen Azure-Region, die Sie für die Zuordnung zu diesem Endpunkt ausgewählt haben.

Welche Routingmethode profitiert von Benutzer-Realmessungen?

Die zusätzlichen Informationen, die mit Benutzer-Realmessungen ermittelt werden, gelten nur für Profile, für die die Routingmethode „Leistung“ verwendet wird. Der Link für Benutzer-Realmessungen steht in allen Profilen zur Verfügung, wenn Sie das Azure-Portal verwenden.

Muss ich Benutzer-Realmessungen für jedes Profil separat aktivieren?

Nein. Sie müssen sie nur einmal pro Abonnement aktivieren. Alle gemessenen und gemeldeten Latenzinformationen sind dann für alle Profile verfügbar.

Wie deaktiviere ich Benutzer-Realmessungen für mein Abonnement?

Sie können die Berechnung von Gebühren für Benutzer-Realmessungen beenden, wenn Sie aufhören, über Ihre Clientanwendung Latenzmessungen zu sammeln und einzusenden. Wenn JavaScript-Code für die Messung beispielsweise in Webseiten eingebettet ist, können Sie die Nutzung dieses Features beenden, indem Sie den JavaScript-Code entfernen oder das Aufrufen beim Rendern der Seite deaktivieren.

Sie können Benutzer-Realmessungen auch deaktivieren, indem Sie Ihren Schlüssel löschen. Wenn Sie den Schlüssel löschen, werden alle Messungen verworfen, die über diesen Schlüssel an Traffic Manager gesendet werden.

Kann ich Benutzer-Realmessungen mit anderen Anwendungen als Webseiten nutzen?

Ja. Benutzer-Realmessungen sind so konzipiert, dass Daten erfasst werden können, die über unterschiedliche Arten von Endbenutzerclients gesammelt werden. Diese FAQ werden aktualisiert, wenn neue Arten von Client-Anwendungen unterstützt werden.

Wie viele Messungen werden jeweils durchgeführt, wenn meine Webseite mit aktivierten Benutzer-Realmessungen gerendert wird?

Wenn Benutzer-Realmessungen mit dem angegebenen JavaScript-Code für Messungen verwendet werden, führt jeder Renderingvorgang der Seite dazu, dass sechs Messungen durchgeführt werden. Diese werden dann an den Traffic Manager-Dienst gemeldet. Dieses Feature wird Ihnen basierend auf der Anzahl von Messungen in Rechnung gestellt, die an den Traffic Manager-Dienst gemeldet werden. Wenn der Benutzer beispielsweise von Ihrer Webseite wegnavigiert, während die Messungen durchgeführt werden, und dies vor dem Melden der Ergebnisse geschieht, werden diese Messungen nicht für die Abrechnung herangezogen.

Kommt es zu einer Verzögerung, bevor das Skript für Benutzer-Realmessungen auf meiner Webseite ausgeführt wird?

Nein. Vor dem Aufrufen des Skripts kommt es nicht zu einer programmierten Verzögerung.

Kann ich Benutzer-Realmessungen auf die Azure-Regionen begrenzen, für die ich Messungen durchführen möchte?

Nein. Bei jedem Aufruf wird mit dem Skript für Benutzer-Realmessungen eine Gruppe von sechs Azure-Regionen gemessen, die vom Dienst bestimmt wird. Diese Gruppe ändert sich zwischen den einzelnen Aufrufen, und wenn eine große Zahl dieser Aufrufe erfolgt, werden durch die Messungen unterschiedliche Azure-Regionen abgedeckt.

Kann ich die Anzahl von durchgeführten Messungen auf einen bestimmten Wert beschränken?

Der JavaScript-Code für die Messung ist in Ihre Webseite eingebettet, und Sie haben die vollständige Kontrolle darüber, wann Sie den Vorgang starten und beenden. Solange der Traffic Manager-Dienst eine Anforderung zum Messen einer Liste mit Azure-Regionen erhält, wird eine Gruppe von Regionen zurückgegeben.

Kann ich die Messungen, die von meiner Clientanwendung durchgeführt werden, als Teil der Benutzer-Realmessungen anzeigen?

Da die Messlogik über Ihre Clientanwendung ausgeführt wird, haben Sie die vollständige Kontrolle über die Abläufe, also auch über die Anzeige der Latenzmessungen. Traffic Manager stellt keine Aggregatansicht der Messungen bereit, die über den mit Ihrem Abonnement verknüpften Schlüssel eingehen.

Kann ich das von Traffic Manager bereitgestellte Skript für die Messungen ändern?

Sie können zwar steuern, was auf Ihrer Webseite eingebettet ist, aber wir raten dringend davon ab, Änderungen am Skript für die Messungen vorzunehmen. So ist sichergestellt, dass die Latenzen richtig gemessen und gemeldet werden.

Können andere Personen den Schlüssel sehen, den ich für Benutzer-Realmessungen verwende?

Wenn Sie das Skript für die Messungen in eine Webseite einbetten, können andere das Skript und Ihren RUM-Schlüssel (Real User Measurements) sehen. Folgender Hinweis ist hierbei wichtig: Dieser Schlüssel unterscheidet sich von der Abonnement-ID und wird von Traffic Manager nur für diesen Zweck generiert. Wenn Ihr RUM-Schlüssel anderen Personen bekannt ist, bedeutet dies also nicht, dass die Sicherheit Ihres Azure-Kontos kompromittiert ist.

Können andere Personen meinen RUM-Schlüssel für schädliche Zwecke missbrauchen?

Es ist zwar möglich, dass Ihr Schlüssel von anderen Personen genutzt wird, um falsche Informationen an Azure zu senden. Durch einige falsche Messergebnisse ändert sich aber nicht das Routing, da diese zusammen mit allen anderen Messungen, die wir erhalten, berücksichtigt werden. Falls Sie Ihre Schlüssel ändern müssen, können Sie einen Schlüssel erneut generieren. Der alte Schlüssel wird dann verworfen.

Muss ich den JavaScript-Code für die Messungen auf allen meinen Webseiten einfügen?

Je höher die Anzahl von Messungen ist, desto größer ist der Nutzen von Benutzer-Realmessungen. Es ist jedoch Ihre Entscheidung, ob Sie es auf all Ihren Webseiten oder nur auf einigen wenigen einbauen wollen. Wir raten Ihnen, den Code zuerst auf Ihrer meistbesuchten Seite einzufügen, auf der Benutzer normalerweise mindestens fünf Sekunden lang verweilen.

Können Informationen zu meinen Endbenutzern von Traffic Manager identifiziert werden, wenn ich Benutzer-Realmessungen verwende?

Wenn das mitgelieferte Mess-JavaScript verwendet wird, hat Traffic Manager Einblick in die Client-IP-Adresse des Endbenutzers und die Quell-IP-Adresse des von ihm verwendeten lokalen DNS-Auflösers. Die Client-IP-Adresse wird von Traffic Manager erst verwendet, nachdem diese abgeschnitten wurde. Auf diese Weise ist es nicht möglich, den jeweiligen Endbenutzer zu identifizieren, der die Messungen gesendet hat.

Muss für die Webseite, für die Benutzer-Realmessungen durchgeführt werden, Traffic Manager zu Routingzwecken eingesetzt werden?

Nein. Die Verwendung von Traffic Manager ist nicht erforderlich. Der Routingbereich von Traffic Manager ist vom Bereich für die Benutzer-Realmessungen getrennt. Es ist zwar hilfreich, wenn beide unter derselben Webeigenschaft angeordnet sind, aber dies muss nicht zwingend der Fall sein.

Muss ich für die Verwendung mit Benutzer-Realmessungen einen Dienst in den Azure-Regionen hosten?

Nein. Es ist nicht erforderlich, serverseitige Komponenten in Azure zu hosten, um Benutzer-Realmessungen verwenden zu können. Das Bild mit dem einzelnen Pixel, das vom JavaScript für die Messungen heruntergeladen wird, und der Dienst, der in den verschiedenen Azure-Regionen ausgeführt wird, wird von Azure gehostet und verwaltet.

Erhöht sich meine Azure-Bandbreitenauslastung, wenn ich Benutzer-Realmessungen verwende?

Wie schon in der vorherigen Antwort erwähnt: Die serverseitigen Komponenten von Benutzer-Realmessungen befinden sich im Besitz von Azure und werden auch von Azure verwaltet. Dies bedeutet, dass sich Ihre Azure-Bandbreitenauslastung nicht erhöht, wenn Sie Benutzer-Realmessungen verwenden. Dies gilt nicht für die Bandbreitenauslastung außerhalb der Azure-Gebührenabrechnung. Wir verringern die Bandbreite, indem wir ein Bild mit nur einem Pixel herunterladen, um die Latenz einer Azure-Region zu messen.

Datenverkehrsansicht

Wozu dient die Datenverkehrsansicht?

Die Datenverkehrsansicht ist ein Feature von Traffic Manager, mit dem Sie mehr Informationen zu Ihren Benutzern und zur Benutzerfreundlichkeit erhalten. Mithilfe der Abfragen von Traffic Manager und den Tabellen mit den Intelligence-Daten zur Netzwerklatenz, die vom Dienst gepflegt werden, werden folgende Informationen für Sie bereitgestellt:

• Die Regionen, in denen sich Benutzer befinden, die eine Verbindung mit Ihren Endpunkten in Azure herstellen.
• Die Menge an Benutzern, die aus diesen Regionen Verbindungen herstellen.
• Die Azure-Regionen, an die sie weitergeleitet werden.
• Das Routing der Latenz der Benutzer an diese Azure-Regionen.

Diese Informationen können Sie im Portal in geografischen Kartenüberlagerungen und Tabellenansichten nutzen und außerdem als Rohdaten herunterladen.

Welche Vorteile ergeben sich für mich durch die Verwendung der Datenverkehrsansicht?

Die Datenverkehrsansicht ermöglicht Ihnen eine Gesamtübersicht über den Datenverkehr, der bei Ihren Traffic Manager-Profilen eingeht. Sie dient vor allem dem besseren Verständnis, von wo aus Ihre Benutzer Verbindungen herstellen und – was genauso wichtig ist – welche durchschnittliche Latenz dabei zu beobachten ist. Sie können diese Informationen dann nutzen, um Bereiche zu identifizieren, die Ihre besondere Aufmerksamkeit erfordern. Beispielsweise können Sie Ihre Azure-Abdeckung auf eine Region erweitern, in der die Latenz für diese Benutzer geringer ist. Eine weiterer Vorteil bei Verwendung der Datenverkehrsansicht ist die Verfolgung von Datenverkehrsmustern für verschiedene Regionen. Diese Informationen können hilfreich für das Treffen der Entscheidung sein, ob Sie die Anstrengungen für diese Regionen erhöhen oder verringern sollten.

Inwiefern unterscheidet sich die Datenverkehrsansicht von den Traffic Manager-Metriken, die über Azure Monitor verfügbar sind?

Azure Monitor kann genutzt werden, um den Datenverkehr, der von Ihrem Profil und dessen Endpunkten eingeht, auf Aggregatebene zu verstehen. Außerdem können Sie den Integritätsstatus der Endpunkte nachverfolgen, indem Sie die Ergebnisse der Integritätsprüfung verfügbar machen. Wenn Ihre Anforderungen höher sind und Sie verstehen möchten, wie sich die Verbindungsherstellung mit Azure auf regionaler Ebene für Benutzer gestaltet, können Sie dies mithilfe der Datenverkehrsansicht erreichen.

Werden für die Datenverkehrsansicht EDNS-Clientsubnetz-Informationen verwendet?

In den von Azure Traffic Manager bereitgestellten DNS-Abfragen werden ECS-Informationen berücksichtigt, um die Genauigkeit des Routings zu erhöhen. Beim Erstellen des Datasets, in dem angezeigt wird, von wo aus Benutzer eine Verbindung herstellen, nutzt die Datenverkehrsansicht aber nur die IP-Adresse der DNS-Auflösung.

Wie viele Tage mit Daten werden von der Datenverkehrsansicht genutzt?

Die Datenverkehrsansicht erstellt ihre Ausgabe, indem die Daten der letzten sieben Tage vor dem Tag verwendet werden, an dem Sie die Informationen anzeigen. Dies ist ein bewegliches Fenster und bei jedem Besuch werden die neuesten Daten verwendet.

Wie werden externe Endpunkte von der Datenverkehrsansicht behandelt?

Bei Verwendung von externen Endpunkten, die außerhalb von Azure-Regionen gehostet werden, können Sie in einem Traffic Manager-Profil die Zuordnung zu einer Azure-Region wählen, die dann quasi als Proxy für die Latenzmerkmale dient (dies ist erforderlich, wenn Sie die Routingmethode „Leistung“ verwenden). Wenn es diese Azure-Regionszuordnung hat, werden die Latenzmetriken dieser Azure-Region bei der Erstellung der Traffic View-Ausgabe verwendet. Wenn keine Azure-Region angegeben ist, sind die Latenzinformationen in den Daten für diese externen Endpunkte leer.

Muss ich die Datenverkehrsansicht für jedes Profil meines Abonnements aktivieren?

Während des Vorschauzeitraums wurde die Datenverkehrsansicht auf einer Abonnementebene aktiviert. Im Rahmen der vorgenommenen Verbesserungen vor der allgemeinen Verfügbarkeit können Sie die Datenverkehrsansicht jetzt auf einer Profilebene aktivieren, um für die Aktivierung dieses Features eine feinere Abstimmung zu ermöglichen. In der Standardeinstellung ist die Verkehrsansicht für ein Profil deaktiviert.

Wie kann ich die Datenverkehrsansicht deaktivieren?

Sie können die Datenverkehrsansicht für alle Profile über das Portal oder die REST-API deaktivieren.

Wie funktioniert die Abrechnung für die Datenverkehrsansicht?

Die Preise für die Datenverkehrsansicht basieren auf der Anzahl von Datenpunkten, die zum Erstellen der Ausgabe verwendet werden. Derzeit werden als Datentyp nur die Abfragen unterstützt, die von Ihrem Profil empfangen werden. Außerdem wird Ihnen nur die Verarbeitung berechnet, die durchgeführt wurde, als Sie die Datenverkehrsansicht aktiviert hatten. Dies bedeutet Folgendes: Wenn Sie die Datenverkehrsansicht während eines Monats einige Zeit aktivieren und dann wieder deaktivieren, werden nur die Datenpunkte, die bei aktiviertem Feature verarbeitet wurden, zur Abrechnung herangezogen.

Traffic Manager-Endpunkte

Kann ich Traffic Manager mit Endpunkten mehrerer Abonnements verwenden?

Die Verwendung von Endpunkten aus mehreren Abonnements ist mit Azure-Web-Apps nicht möglich. Für Azure-Web-Apps dürfen mit Web-Apps verwendete, benutzerdefinierte Domänennamen nur innerhalb eines einzelnen Abonnements genutzt werden. Es ist nicht möglich, Web-Apps aus mehreren Abonnements mit demselben Domänennamen zu verwenden.

Für andere Endpunkttypen kann Traffic Manager mit Endpunkten aus mehreren Abonnements verwendet werden. In Resource Manager können Endpunkte aus jedem Abonnement zu Traffic Manager hinzugefügt werden, solange die Person, die das Traffic Manager-Profil konfiguriert, über Lesezugriff für den Endpunkt verfügt. Diese Berechtigungen können über die rollenbasierte Zugriffssteuerung von Azure (Azure-RBAC-Rolle) gewährt werden. Endpunkte aus anderen Abonnements können über Azure PowerShell oder die Azure CLI hinzugefügt werden.

Kann ich Traffic Manager mit „Stagingslots“ des Clouddiensts verwenden?

Ja. Stagingslots des Clouddiensts können in Traffic Manager als externe Endpunkte konfiguriert werden. Integritätsprüfungen werden weiterhin mit der Rate von Azure-Endpunkten berechnet.

Unterstützt Traffic Manager IPv6-Endpunkte?

Traffic Manager stellt derzeit keine IPv6-adressierbaren Nameserver zur Verfügung. Traffic Manager kann jedoch weiterhin von IPv6-Clients verwendet werden, die eine Verbindung mit IPv6-Endpunkten herstellen, wenn der rekursive DNS-Server des Clients IPv4 unterstützt. Ein Client richtet keine DNS-Anforderungen direkt an Traffic Manager. Stattdessen verwendet der Client einen rekursiven DNS-Dienst. Ein reiner IPv6-Client sendet Anforderungen an den rekursiven DNS-Dienst über IPv6. Der rekursive Dienst muss anschließend in der Lage sein, die Traffic Manager-Namensserver per IPv4 zu kontaktieren. Traffic Manager antwortet mit dem DNS-Namen oder der IP-Adresse des Endpunkts.

Kann ich Traffic Manager mit mehr als einer Web-App in derselben Region verwenden?

Normalerweise wird Traffic Manager verwendet, um Datenverkehr an Anwendungen zu leiten, die in verschiedenen Regionen bereitgestellt wurden. Traffic Manager kann aber auch eingesetzt werden, wenn eine Anwendung über mehr als eine Bereitstellung in derselben Region verfügt. Die Traffic Manager-Azure-Endpunkte lassen es nicht zu, dass demselben Traffic Manager-Profil mehr als ein Web-App-Endpunkt für dieselbe Azure-Region hinzugefügt wird.

Wie werden die Azure-Endpunkte meines Traffic Manager-Profils in eine andere Ressourcengruppe oder in ein anderes Abonnement verschoben?

Azure-Endpunkte, die einem Traffic Manager-Profil zugeordnet sind, werden über ihre Ressourcen-IDs nachverfolgt. Wenn eine Azure-Ressource, die als Endpunkt (z. B. öffentliche IP-Adresse, klassischer Clouddienst, WebApp oder anderes Traffic Manager-Profil, das in geschachtelte Weise verwendet wird) verwendet wird, in eine andere Ressourcengruppe oder in ein anderes Abonnement verschoben wird, ändert sich ihre Ressourcen-ID. In diesem Szenario müssen Sie das Traffic Manager-Profil derzeit aktualisieren, indem Sie zuerst die Endpunkte löschen und sie dann wieder zum Profil hinzufügen.

Weitere Informationen finden Sie unter So verschieben Sie einen Endpunkt.

Unterstützt Azure Traffic Manager IPv6-Erweiterungsmechanismen für DNS (ECS)?

Azure Traffic Manager unterstützt IPv6-Adressen mit Erweiterungsmechanismen für DNS (ECS). Dies bedeutet, dass Azure Traffic Manager, wenn eine DNS-Abfrage ECS-Informationen enthält, die Quell-IP-Adresse innerhalb des ECS verwenden kann, um intelligente Routingentscheidungen zu treffen.

Die Unterstützung für IPv6 ECS bietet mehrere Vorteile:

• Verbesserte Lokalisierung: Wenn Sie die IPv6-Adresse im ECS berücksichtigen, kann Traffic Manager Benutzer an den nächstgelegenen oder am besten geeigneten Endpunkt weiterleiten, wodurch die Benutzerfreundlichkeit mit geringerer Latenz verbessert wird.
• Verbesserte Datenverkehrskontrolle: IPv6 ECS ermöglicht präzisere Datenverkehrsroutingentscheidungen und ermöglicht eine bessere Verwaltung des globalen Datenverkehrs und der Verteilung.

Bei Verwendung von IPv6 ECS ist es wichtig sicherzustellen, dass Ihre Endpunkte ordnungsgemäß für die Verarbeitung von IPv6-Datenverkehr konfiguriert sind. Überprüfen Sie außerdem, ob Ihre DNS-Infrastruktur, einschließlich rekursiver Resolver, ECS-Informationen mit IPv6-Adressen verarbeiten kann.

Traffic Manager-Endpunktüberwachung

Ist Traffic Manager gegenüber Ausfällen von Azure-Regionen resistent?

Traffic Manager ist eine Schlüsselkomponente der Bereitstellung von hoch verfügbaren Anwendungen in Azure. Um Hochverfügbarkeit bereitzustellen, muss Traffic Manager ein außergewöhnlich hohes Maß an Verfügbarkeit aufweisen und resistent gegenüber Regionsausfällen sein.

Traffic Manager-Komponenten sind standardmäßig gegenüber einem vollständigen Ausfall jeder Azure-Region resistent. Diese Resilienz gilt für alle Traffic Manager-Komponenten: DNS-Namensserver, API, Speicherebene und Endpunkt-Überwachungsdienst.

Im unwahrscheinlichen Fall eines Ausfalls einer gesamten Azure-Region wird erwartet, dass Traffic Manager weiterhin normal funktioniert. Bei Anwendungen, die in mehreren Azure-Regionen bereitgestellt wurden, kann darauf vertraut werden, dass Traffic Manager Datenverkehr an eine verfügbare Instanz der Anwendung leitet.

Wie wirkt sich die Wahl des Ressourcengruppenstandorts auf Traffic Manager aus?

Traffic Manager ist ein einzelner globaler Dienst. Es handelt sich nicht um einen regionalen Dienst. Die Wahl des Ressourcengruppenstandorts spielt für Traffic Manager-Profile, die in der Ressourcengruppe bereitgestellt werden, keine Rolle.

Für Azure Resource Manager ist es erforderlich, dass für alle Ressourcengruppen ein Standort angegeben wird, mit dem der Standardstandort für die in dieser Ressourcengruppe bereitgestellten Ressourcen bestimmt wird. Wenn Sie ein Traffic Manager-Profil erstellen, wird es in einer Ressourcengruppe erstellt. Für alle Traffic Manager-Profile wird als Standort global verwendet, wobei der Standardwert der Ressourcengruppe überschrieben wird.

Wie kann ich den aktuellen Integritätsstatus jedes Endpunkts bestimmen?

Der aktuelle Überwachungsstatus jedes Endpunkts sowie das Gesamtprofil werden im Azure-Portal angezeigt. Diese Informationen sind auch über die REST-API von Traffic Manager, PowerShell-Cmdlets und die plattformübergreifende Azure-Befehlszeilenschnittstelle verfügbar.

Sie können auch mit Azure Monitor die Integrität Ihrer Endpunkte nachverfolgen und eine visuelle Darstellung anzeigen. Weitere Informationen zum Verwenden von Azure Monitor finden Sie in der Dokumentation zur Azure-Überwachung.

Kann ich HTTPS-Endpunkte überwachen?

Ja. Traffic Manager unterstützt Tests per HTTPS. Konfigurieren Sie in der Überwachungskonfiguration HTTPS als Protokoll.

Traffic Manager kann keine Zertifikatüberprüfung bereitstellen. Dazu zählt Folgendes:

• Serverseitige Zertifikate werden nicht überprüft
• Serverseitige SNI-Zertifikate werden nicht überprüft
• Clientzertifikate werden nicht unterstützt

Verwende ich beim Hinzufügen eines Endpunkts eine IP-Adresse oder einen DNS-Namen?

Traffic Manager unterstützt das Hinzufügen von Endpunkten mithilfe von drei Möglichkeiten, auf sie zu verweisen:

• Als DNS-Name
• Als IPv4-Adresse
• Als IPv6-Adresse

Wenn der Endpunkt als IPv4- oder IPv6-Adresse hinzugefügt wird, ist die Abfrageantwort vom Typ A bzw. AAAA. Wenn der Endpunkt als DNS-Name hinzugefügt wurde, hat die Abfrageantwort den Eintragstyp CNAME. Das Hinzufügen von Endpunkten als IPv4- oder IPv6-Adresse ist nur bei Endpunkten vom Typ Extern zulässig.

Alle Routingmethoden und Überwachungseinstellungen werden von den drei Endpunktadressierungsarten unterstützt.

Welche Arten von IP-Adressen kann ich beim Hinzufügen eines Endpunkts verwenden?

In Traffic Manager können Sie IPv4- oder IPv6-Adressen zur Angabe von Endpunkten verwenden. Es gibt einige Einschränkungen, die im Folgenden aufgeführt sind:

• Adressen, die reservierten privaten IP-Adressräumen entsprechen, sind nicht zulässig. Zu diesen Adressen gehören die in RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 und RFC 5771 genannten Adressen.
• Die IP-Adresse darf keine Portnummern enthalten (Sie können die Ports angeben, die in den Profilkonfigurationseinstellungen verwendet werden sollen).
• Zwei Endpunkte im gleichen Profil dürfen nie die gleiche Ziel-IP-Adresse aufweisen.

Kann ich verschiedene Endpunktadressierungsarten innerhalb eines einzigen Profils verwenden?

-Nr. In Traffic Manager ist es nicht zulässig, Endpunktadressierungstypen innerhalb eines Profils zu mischen, außer im Falle eines Profils mit dem Routingtyp „MultiValue“. Hierbei können Sie IPv4- und IPv6-Adressierungstypen mischen.

Was passiert, wenn sich der Eintragstyp einer eingehenden Abfrage vom Eintragstyp unterscheidet, der dem Adressierungstyp der Endpunkte zugeordnet ist?

Wenn eine Abfrage für ein Profil empfangen wird, sucht Traffic Manager zunächst den Endpunkt, der nach der angegebenen Routingmethode und dem Integritätsstatus der Endpunkte zurückgegeben werden muss. Anschließend wird der in der eingehenden Abfrage angeforderte Eintragstyp und der dem Endpunkt zugeordneten Eintragstyp betrachtet, bevor eine Antwort basierend auf der folgenden Tabelle zurückgegeben wird.

Für Profile mit einer beliebigen Routingmethode außer „MultiValue“:

Eingehende Abfrageanforderung	Endpunkttyp	Bereitgestellte Antwort
ANY	A/AAAA/CNAME	Zielendpunkt
Ein	A/CNAME	Zielendpunkt
Ein	AAAA	NODATA
AAAA	AAAA/CNAME	Zielendpunkt
AAAA	Ein	NODATA
CNAME	CNAME	Zielendpunkt
CNAME	A/AAAA	NODATA

Für Profile mit der Routingmethode „MultiValue“:

Eingehende Abfrageanforderung	Endpunkttyp	Bereitgestellte Antwort
ANY	Kombination aus A und AAAA	Zielendpunkte
Ein	Kombination aus A und AAAA	Nur Zielendpunkte vom Typ A
AAAA	Kombination aus A und AAAA	Nur Zielendpunkte vom Typ AAAA
CNAME	Kombination aus A und AAAA	NODATA

Kann ich ein Profil mit über IPv4/IPv6 adressierten Endpunkten in einem verschachtelten Profil verwenden?

Ja, Sie können, mit Ausnahme, dass ein Profil vom Typ MultiValue kein übergeordnetes Profil in einem geschachtelten Profilsatz sein kann.

Ich habe einen Webanwendungs-Endpunkt in meinem Traffic Manager-Profil angehalten, aber ich empfange auch nach einem Neustart keinen Datenverkehr. Wie kann ich dieses Problem beheben?

Wenn ein Azure-Webanwendungs-Endpunkt beendet wird, überprüft Traffic Manager nicht mehr die Integrität, und die Integritätsprüfungen werden erst wieder aufgenommen, wenn erkannt wird, dass der Endpunkt neu gestartet wurde. Um diese Verzögerung zu vermeiden, deaktivieren Sie diesen Endpunkt im Traffic Manager-Profil, und aktivieren Sie ihn erneut, nachdem Sie den Endpunkt neu gestartet haben.

Kann ich Traffic Manager auch dann verwenden, wenn meine Anwendung HTTP oder HTTPS nicht unterstützt?

Ja. Wenn Sie TCP als Überwachungsprotokoll angeben, kann Traffic Manager eine TCP-Verbindung initiieren und auf eine Antwort vom Endpunkt warten. Wenn der Endpunkt auf die Verbindungsanforderung innerhalb des Zeitlimits mit einer Antwort zum Herstellen der Verbindung antwortet, wird dieser Endpunkt als fehlerfrei markiert.

Welche bestimmten Antworten vom Endpunkt sind bei Verwendung der TCP-Überwachung erforderlich?

Bei Verwendung der TCP-Überwachung startet Traffic Manager durch Senden einer SYN-Anforderung an den Endpunkt am angegebenen Port ein Drei-Wege-TCP-Handshake. Dann wird eine bestimmte Zeit (wie in den Timeouteinstellungen angegeben) auf eine SYN-ACK-Antwort vom Endpunkt gewartet.

• Wenn innerhalb des in den Überwachungseinstellungen angegeben Timeoutzeitraums eine SYN-ACK-Antwort empfangen wird, wird dieser Endpunkt als fehlerfrei angesehen. Eine FIN- oder FIN-ACK-Antwort ist die erwartete Antwort vom Traffic Manager, wenn ein Socket regulär beendet wird.
• Wenn nach dem angegebenen Timeout eine SYN-ACK-Antwort empfangen wird, antwortet Traffic Manager mit einem RST, um die Verbindung zurückzusetzen.

Wie schnell verschiebt Traffic Manager meine Benutzer von einem fehlerhaften Endpunkt weg?

Traffic Manager bietet mehrere Einstellungen, mit denen Sie wie folgt das Failoververhalten Ihres Traffic Manager-Profils steuern können:

• Sie können angeben, dass Traffic Manager die Endpunkte häufiger prüft, indem Sie das Testintervall auf 10 Sekunden festlegen. Dadurch wird sichergestellt, dass jeder fehlerhafte Endpunkt so bald wie möglich erkannt werden kann.
• Sie können einen Timeoutwert für die Anforderung einer Integritätsprüfung festlegen (der Minimalwert sind 5 Sekunden).
• Sie können angeben, wie viele Fehler auftreten können, bevor der Endpunkt als fehlerhaft markiert wird. Dieser Wert kann niedriger als 0 (null) sein. In diesem Fall wird der Endpunkt als fehlerhaft anzeigt, sobald die erste Integritätsprüfung negativ ausfällt. Jedoch kann ein Mindestwert von 0 für die zulässige Anzahl von Fehlern dazu führen, dass Endpunkte aufgrund vorübergehender, zum Zeitpunkt der Überprüfung auftretender Probleme aus der Rotation herausgenommen werden.
• Sie können für die DNS-Antwort eine minimale Gültigkeitsdauer (TTL) von 0 angeben. Dies bedeutet, dass die DNS-Resolver die Antwort nicht zwischenspeichern können und jede neue Abfrage eine Antwort erhält, die die aktuellen Integritätsinformationen wiedergibt, über die Traffic Manager verfügt.

Mithilfe dieser Einstellungen kann Traffic Manager Failover in weniger als 10 Sekunden bereitstellen, nachdem ein Endpunkt fehlerhaft ist und eine DNS-Abfrage des entsprechenden Profils erfolgt.

Wie kann ich verschiedene Überwachungseinstellungen für verschiedene Endpunkte in einem Profil angeben?

Traffic Manager-Überwachungseinstellungen werden pro Profil festgelegt. Wenn Sie nur für einen Endpunkt eine andere Überwachungseinstellung verwenden müssen, kann dieser Endpunkt als geschachteltes Profil konfiguriert werden, dessen Überwachungseinstellungen sich vom übergeordneten Profil unterscheiden.

Wie kann ich meinen Endpunkten HTTP-Header für die Traffic Manager-Integritätsprüfungen zuweisen?

Mit Traffic Manager können Sie benutzerdefinierte Header in den für Ihre Endpunkte initiierten HTTP(S)-Integritätsprüfungen angeben. Wenn Sie einen benutzerdefinierten Header angeben möchten, können Sie dies auf Profilebene (gilt für alle Endpunkte) oder auf Endpunktebene tun. Wenn ein Header auf beiden Ebenen definiert ist, überschreibt der auf Endpunktebene angegebene Header den auf Profilebene angegebenen Header. Ein häufiger Anwendungsfall hierfür ist die Angabe von Host-Headern, damit Traffic Manager-Anfragen korrekt an einen Endpunkt weitergeleitet werden, der in einer mandantenfähigen Umgebung gehostet wird. Ein weiterer Anwendungsfall ist die Identifizierung von Traffic Manager-Anforderungen aus den HTTP(S)-Anforderungsprotokollen eines Endpunkts.

Welcher Hostheader wird für die Integritätsprüfungen für Endpunkte verwendet?

Wenn keine benutzerdefinierte Hostheadereinstellung angegeben wird, ist der vom Traffic Manager verwendete Hostheader der DNS-Name des im Profil konfigurierten Endpunktziels, sofern verfügbar.

Wie lauten die IP-Adressen, von denen die Integritätsüberprüfungen stammen?

In diesem Artikel erfahren Sie, wie Sie die Listen der IP-Adressen abrufen können, von denen Traffic Manager-Integritätsprüfungen stammen können. Sie können die REST-API, die Azure CLI oder Azure PowerShell verwenden, um die aktuelle Liste abzurufen. Überprüfen Sie die aufgelisteten IP-Adressen, um sicherzustellen, dass eingehende Verbindungen von diesen IP-Adressen an den Endpunkten zur Überprüfung des Integritätsstatus zugelassen sind.

Beispiel mit Azure PowerShell:

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

Wie viele Integritätsprüfungen meines Endpunkts kann ich von Traffic Manager erwarten?

Die Anzahl der Traffic Manager-Integritätsprüfungen Ihres Endpunkts hängt von Folgendem ab:

• dem Wert, den Sie für das Überwachungsintervall festgelegt haben (ein kleineres Intervall bedeutet, dass in einem bestimmten Zeitraum mehr Anforderungen auf dem Endpunkt eingehen).
• der Anzahl der Standorte, von denen die Integritätsprüfungen ausgehen (die IP-Adressen, von denen aus diese Überprüfungen durchgeführt werden können, sind in der vorherigen FAQ aufgelistet).

Wie kann ich benachrichtigt werden, wenn einer meiner Endpunkte ausfällt?

Eine der vom Traffic Manager bereitgestellten Metriken ist der Integritätsstatus von Endpunkten in einem Profil. Dies wird als Aggregat aller Endpunkte in einem Profil angezeigt (z.B. sind 75% Ihrer Endpunkte fehlerfrei) oder auf Pro-Endpunkt-Ebene. Azure Monitor stellt Traffic Manager-Metriken bereit, und Sie können dessen Warnfunktionen verwenden, um bei einer Änderung des Integritätsstatus Ihres Endpunkts Benachrichtigungen zu erhalten. Weitere Informationen finden Sie unter Traffic Manager-Metriken und -Warnungen.

Geschachtelte Profile in Traffic Manager

Wie konfiguriere ich geschachtelte Profile?

Geschachtelte Traffic Manager-Profile können sowohl mit Azure Resource Manager als auch mit den klassischen Azure-REST-APIs, Azure PowerShell-Cmdlets und plattformübergreifenden Befehlen der Azure-Befehlszeilenschnittstelle konfiguriert werden. Sie werden auch im neuen Azure-Portal unterstützt.

Wie viele Schachtelungsebenen werden in Traffic Manager unterstützt?

Sie können Profile bis zu 10 Ebenen schachteln. Schleifen sind nicht zulässig.

Kann ich andere Endpunkttypen mit geschachtelten untergeordneten Profilen im gleichen Traffic Manager-Profil kombinieren?

Ja. Es gibt keine Einschränkungen hinsichtlich der Kombination von Endpunkten verschiedener Typen innerhalb eines Profils.

Wie wird das Abrechnungsmodell auf geschachtelte Profile angewendet?

Die Verwendung geschachtelter Profile wirkt sich nicht negativ auf die Preise aus.

Die Abrechnung für Traffic Manager besteht aus zwei Komponenten: Integritätsprüfungen der Endpunkte und Millionen von DNS-Abfragen.

• Überprüfungen der Endpunktintegrität: Wenn ein untergeordnetes Profil als Endpunkt in einem übergeordneten Profil konfiguriert wird, fallen keine Gebühren an. Die Überwachung von Endpunkten im untergeordneten Profil wird in gewohnter Weise abgerechnet.
• DNS-Abfragen: Jede Abfrage wird nur einmal gezählt. Die Abfrage eines übergeordneten Profils, die einen Endpunkt aus einem untergeordneten Profil zurückgibt, wird nur im übergeordneten Profil gezählt.

Ausführliche Informationen finden Sie auf der Seite Traffic Manager Preise.

Wirken sich geschachtelte Profile auf die Leistung aus?

Nein, durch geschachtelte Profile entstehen keine Leistungseinbußen.

Die Traffic Manager-Namenserver durchlaufen bei der Verarbeitung der einzelnen DNS-Abfragen intern die Profilhierarchie. Eine DNS-Abfrage an ein übergeordnetes Profil kann eine DNS-Antwort mit einem Endpunkt aus einem untergeordneten Profil erhalten. Unabhängig davon, ob Sie ein einzelnes Profil oder geschachtelte Profile verwenden, wird nur ein einziger CNAME-Eintrag verwendet. Es gibt keine Notwendigkeit, für jedes Profil in der Hierarchie einen CNAME-Eintrag zu erstellen.

Wie berechnet Traffic Manager die Integrität eines geschachtelten Endpunkts in einem übergeordneten Profil?

Das übergeordnete Profil führt die Integritätsprüfung nicht direkt am untergeordneten Profil durch. Stattdessen wird mit der Integrität der Endpunkte des untergeordneten Profils die Gesamtintegrität des untergeordneten Profils berechnet. Diese Informationen werden in der Hierarchie der geschachtelten Profile nach oben weitergegeben, um die Integrität des geschachtelten Endpunkts zu bestimmen. Das übergeordnete Profil verwendet diese aggregierte Integrität, um festzulegen, ob der Datenverkehr an das untergeordnete Profil weitergeleitet wird.

Die folgende Tabelle beschreibt das Verhalten von Traffic Manager-Integritätsprüfungen für einen geschachtelten Endpunkt.

Überwachungsstatus von untergeordneten Profilen	Überwachungsstatus von übergeordneten Endpunkten	Notizen
Deaktiviert. Das untergeordnete Profil wurde deaktiviert.	Beendet	Der übergeordnete Endpunktstatus ist Stopped, und nicht Disabled. Der Status Disabled zeigt lediglich an, dass Sie den Endpunkt im übergeordneten Profil deaktiviert haben.
Beeinträchtigt. Der Status mindestens eines untergeordneten Endpunkts ist Degraded.	Online: Die Anzahl der Online Endpunkte im untergeordneten Profil ist mindestens gleich dem Wert von MinChildEndpoints. CheckingEndpoint: Die Anzahl der Online plus CheckingEndpoint Endpunkte im untergeordneten Profil ist mindestens gleich dem Wert von MinChildEndpoints. Heruntergestuft: andere Fälle.	Der Datenverkehr wird an einen Endpunkt mit dem Status CheckingEndpoint weitergeleitet. Wenn MinChildEndpoints zu hoch festgelegt wurde, wird der Endpunkt immer heruntergestuft.
Online. Der Status mindestens eines untergeordneten Endpunkts ist Online. Kein Endpunkt befindet sich im Degraded-Zustand.	Siehe oben.
CheckingEndpoints. Mindestens ein untergeordneter Endpunkt ist CheckingEndpoint. Keine Endpunkte sind Online oder Degraded	Wie oben.
Inaktiv. Alle untergeordneten Profilendpunkte sind Disabled oder Stopped, oder dieses Profil weist keine Endpunkte auf.	Beendet

Warum kann ich den erweiterten Support für Endpunkte in Azure Cloud Services Extended nicht zu meinem Traffic Manager-Profil hinzufügen?

Um erweiterte Endpunkte in Azure Cloud zu einem Traffic Manager-Profil hinzuzufügen, muss die Ressourcengruppe mit der Azure Service Management (ASM)-API kompatibel sein. Profile, die sich in der älteren Ressourcengruppe befinden, müssen die Standards der ASM-API einhalten, die die Aufnahme von Endpunkten öffentlicher IP-Adressen oder von Endpunkten von einem anderen Abonnement als dem des Profils verbieten. Um dieses Problem zu beheben, erwägen Sie, Ihr Traffic Manager-Profil und die zugehörigen Ressourcen in eine neue Ressourcengruppe zu verschieben, die mit der ASM-API kompatibel ist.

Nächste Schritte:

• Informieren Sie sich ausführlicher über Endpunktüberwachung und automatisches Failovervon Traffic Manager.
• Informieren Sie sich ausführlicher über Traffic Manager-Routingmethoden.