Globales DNS-Failover benötigt? Konfiguriere Traffic Manager

Veröffentlicht am: 15. August 2026

CloudTrips besitzt einen regionalen Load Balancer in West Europe. Azure Traffic Manager bietet globales DNS-basiertes Routing und liefert anhand der Routingmethode einen fehlerfreien Endpunkt zurück. Dieses Lab verteilt die vorhandenen Web-VMs vorübergehend auf zwei kleine öffentliche Load Balancer und verwendet Priority Routing, um DNS zwischen ihnen umzuschalten.

1. Client fragt DNS nach dem Traffic-Manager-Namen
                         |
                         v
              Azure Traffic Manager
                 Priority Routing
                  /            \
       1: Ursprünglicher LB   2: Zweiter LB
               |                   |
             WEB01               WEB02

2. DNS liefert den ausgewählten Load-Balancer-Namen
3. Client verbindet sich direkt mit diesem öffentlichen Endpunkt

Traffic Manager ist kein Proxy und stellt keine globale Frontend-IP bereit. Er beantwortet DNS-Anfragen; Anwendungstraffic fließt danach direkt zum ausgewählten öffentlichen Endpunkt.

Dieser Trip benötigt nur lb-cloudtrips-web-test-weu, sein vorhandenes öffentliches Frontend, die HTTP-Regel, den Health Probe und den fehlerfreien WEB01/WEB02 Backend Pool. Es wird keine zusätzliche VM benötigt.

Diese Topologie demonstriert Traffic-Manager-Priorität, Monitoring, DNS-TTL und Endpunktwechsel. Sie bietet keine regionale Hochverfügbarkeit: Beide öffentlichen Endpunkte bleiben im selben VNet und in West Europe. Regionales Produktionsfailover benötigt unabhängige Endpunkte in verschiedenen Regionen.

Traffic Manager, der zweite Standard Load Balancer und seine Public IP können Kosten verursachen. Führe nach der Prüfung die Bereinigung durch.

WEB02 vom ursprünglichen Backend Pool trennen

Eine VM-NIC sollte nicht gleichzeitig an zwei öffentlichen Load Balancern teilnehmen. Öffne lb-cloudtrips-web-test-weu > Backend pools, öffne den vorhandenen Web-Pool, entferne nur die NIC/IP-Konfiguration von vm-cloudtrips-web02-test-weu und wähle Save. Behalte WEB01 im ursprünglichen Pool und warte, bis es fehlerfrei ist.

Die ursprüngliche Public IP sollte jetzt immer WEB01 liefern:

PRIMARY_IP=$(az network public-ip show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pip-cloudtrips-lb-test-weu \
  --query ipAddress \
  --output tsv)

curl --silent --show-error --connect-timeout 10 "http://${PRIMARY_IP}/"

Zweiten Load Balancer erstellen

Erstelle einen weiteren Standard Load Balancer:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: lb-cloudtrips-web-tm-test-weu
Region: West Europe
SKU: Standard
Type: Public
Tier: Regional

Füge sein Frontend hinzu:

Name: fe-cloudtrips-web-tm-test-weu
IP version: IPv4
Public IP: Create new
Public IP name: pip-cloudtrips-lb-tm-test-weu
SKU: Standard
Availability zone: Zone-redundant

Füge einen NIC-basierten Backend Pool hinzu:

Name: be-cloudtrips-web-tm-test-weu
Virtual network: vnet-cloudtrips-test-weu
Backend pool configuration: NIC
Backend: Nur NIC/IP-Konfiguration von vm-cloudtrips-web02-test-weu

Füge einen TCP Health Probe hinzu:

Name: probe-tcp-80
Protocol: TCP
Port: 80

Füge eine Load-Balancing-Regel hinzu:

Name: rule-http-80
IP version: IPv4
Frontend IP address: fe-cloudtrips-web-tm-test-weu
Backend pool: be-cloudtrips-web-tm-test-weu
Protocol: TCP
Frontend port: 80
Backend port: 80
Health probe: probe-tcp-80
Session persistence: None
TCP reset: Enabled
Floating IP: Disabled

Erstelle den Load Balancer, warte auf fehlerfreies WEB02 und teste den Endpunkt:

BACKUP_IP=$(az network public-ip show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pip-cloudtrips-lb-tm-test-weu \
  --query ipAddress \
  --output tsv)

curl --silent --show-error --connect-timeout 10 "http://${BACKUP_IP}/"

Die Antwort sollte CloudTrips response from WEB02 lauten. Die Topologie ist:

Traffic Manager
├── Priorität 1 -> lb-cloudtrips-web-test-weu    -> WEB01
└── Priorität 2 -> lb-cloudtrips-web-tm-test-weu -> WEB02

Die beiden globalen Designs vergleichen

Funktion	Traffic Manager	Cross-Region Load Balancer
Entscheidungsebene	DNS	Layer-4-Netzwerkfluss
Client verbindet sich mit	Ausgewähltem regionalen Endpunkt	Einer globalen Anycast-IP
Endpunkttypen	Öffentliche Azure-, externe oder verschachtelte Endpunkte	Frontends regionaler Azure Load Balancer
Sichtbarkeit des Failovers	Abhängig von DNS-TTL und Client-Cache	Bestehende Flows verwenden das globale Frontend
Geeignet für	DNS-basiertes Anwendungsfailover über unterschiedliche Endpunkte	Statische globale IP und regionales Azure-Layer-4-Balancing

Priority Routing liefert normalerweise Endpunktpriorität 1 als DNS-Antwort. Priorität 2 wird erst geliefert, wenn der erste Endpunkt deaktiviert ist oder sein Traffic-Manager-Probe ihn als beeinträchtigt erkennt.

Beiden Public IPs DNS-Namen geben

Eine Azure-Public-IP-Ressource benötigt einen DNS-Namen, bevor sie als Azure- Endpunkt in Traffic Manager gewählt werden kann. Generiere eindeutige Labels in Cloud Shell:

RG_NAME="rg-cloudtrips-network-test-weu"
SUFFIX=$(az account show --query id --output tsv | tr -d '-' | cut -c1-8)

az network public-ip update \
  --resource-group "$RG_NAME" \
  --name pip-cloudtrips-lb-test-weu \
  --dns-name "cloudtrips-web-weu-${SUFFIX}"

az network public-ip update \
  --resource-group "$RG_NAME" \
  --name pip-cloudtrips-lb-tm-test-weu \
  --dns-name "cloudtrips-web-tm-backup-${SUFFIX}"

az network public-ip list \
  --resource-group "$RG_NAME" \
  --query "[?name=='pip-cloudtrips-lb-test-weu' || name=='pip-cloudtrips-lb-tm-test-weu'].{Name:name,FQDN:dnsSettings.fqdn,IP:ipAddress}" \
  --output table

Die Ausgabe sollte zwei unterschiedliche Namen unter *.westeurope.cloudapp.azure.com zeigen. Teste beide vor der nächsten Routingebene:

curl --silent --show-error --connect-timeout 10 \
  "http://cloudtrips-web-weu-${SUFFIX}.westeurope.cloudapp.azure.com/"

curl --silent --show-error --connect-timeout 10 \
  "http://cloudtrips-web-tm-backup-${SUFFIX}.westeurope.cloudapp.azure.com/"

Der ursprüngliche FQDN sollte WEB01 liefern, der Backup-FQDN WEB02. Behebe Probleme mit Load-Balancer-Regel, Health Probe, Backend-Mitgliedschaft oder VM Listener, bevor du fortfährst.

Priority-Traffic-Manager-Profil erstellen

DNS-Namen von Traffic-Manager-Profilen müssen in der Zone trafficmanager.net global eindeutig sein. Gib den Profilnamen in Cloud Shell aus:

TM_NAME="tm-cloudtrips-${SUFFIX}"
printf 'Traffic Manager profile: %s\n' "$TM_NAME"

Suche im Azure-Portal nach Traffic Manager profiles und wähle Create:

Name: <ausgegebener Traffic-Manager-Profilname>
Routing method: Priority
DNS record type: CNAME
Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu

Die Resource Group besitzt eine Region, das Traffic-Manager-Profil ist jedoch ein globaler Dienst. Wähle Create.

Erstellung des Traffic-Manager-Profils mit Priority Routing für CloudTrips

DNS und Endpunktüberwachung konfigurieren

Öffne das Profil und wähle Settings > Configuration:

Routing method: Priority
DNS record type: CNAME
DNS time to live (TTL): 30 seconds
Endpoint monitor protocol: HTTP
Port: 80
Path: /
Probing interval: 30 seconds
Tolerated number of failures: 3
Probe timeout: 10 seconds
Expected status code ranges: 200-299

Wähle CNAME, nicht A. Die beiden Azure-Public-IP-Ressourcen besitzen DNS- Labels; Traffic Manager behandelt ihre Endpunktziele deshalb als DomainName. Ein A-Profil akzeptiert nur IPv4Address-Ziele und erzeugt beim Speichern eines Azure-Endpunkts diesen Fehler:

Endpoint target type, 'DomainName', is not allowed for this profile.
Valid values are: IPv4Address.

Der Endpunkt-Record-Typ kann nach dem Erstellen dieses Profils nicht geändert werden. Hast du es bereits mit A erstellt, brich die fehlgeschlagene Endpunktänderung ab, lösche nur das Traffic-Manager-Profil und erstelle es mit DNS record type: CNAME erneut. Innerhalb desselben Microsoft-Entra-Tenants kannst du denselben Profilnamen normalerweise sofort wiederverwenden. Lösche weder Load Balancer noch Public IPs.

Wähle Save. Der Probe fragt / auf jedem DNS-Namen der Public IP ab. Eine erfolgreiche Antwort beweist, dass Load-Balancer-Regel, Health Probe, NSG, Backend Listener und Rückweg funktionieren.

Verwende die NSG-Standardregel AllowAzureLoadBalancerInBound nicht als Nachweis, dass Traffic-Manager-Probes zugelassen sind. Diese Regel gilt für den Service Tag AzureLoadBalancer. Die CloudTrips-HTTP-Regel erlaubt bereits den öffentlichen Webendpunkt auf TCP 80 und damit auch die externen Health Probes von Traffic Manager.

DNS-TTL und HTTP-Endpunktüberwachung des Traffic Manager

Primären und Standby-Endpunkt hinzufügen

Wähle Settings > Endpoints > Add und erstelle den primären Endpunkt:

Type: Azure endpoint
Name: ep-cloudtrips-weu-primary
Target resource type: Public IP address
Target resource: pip-cloudtrips-lb-test-weu
Priority: 1
Status: Enabled

Füge den Standby-Endpunkt hinzu:

Type: Azure endpoint
Name: ep-cloudtrips-weu-backup
Target resource type: Public IP address
Target resource: pip-cloudtrips-lb-tm-test-weu
Priority: 2
Status: Enabled

Warte, bis beide Monitoring States Online zeigen. Bleibt ein Endpunkt auf Checking endpoint oder wird Degraded, teste seinen Endpunkt-FQDN direkt und bestätige, dass HTTP / einen Status aus 200-299 liefert.

Traffic-Manager-Endpunkte mit ursprünglicher Public IP auf Priorität 1 und Backup Public IP auf Priorität 2 im Status Online

Primäres DNS-Routing prüfen

Die Profilübersicht zeigt einen DNS-Namen wie:

tm-cloudtrips-<suffix>.trafficmanager.net

Setze auf deinem Laptop den tatsächlichen Namen und prüfe seine DNS-Kette:

TM_FQDN="<traffic-manager-profile-name>.trafficmanager.net"

dig +short "$TM_FQDN"
curl --silent --show-error --connect-timeout 10 "http://${TM_FQDN}/"

DNS sollte zum Endpunkt in West Europe führen, solange er Online ist; curl sollte eine WEB01- oder WEB02-Antwort liefern. Das Ergebnis beweist Priorität, nicht geografische Nähe: Priorität 1 gewinnt unabhängig vom Clientstandort.

Kontrolliertes Failover ausführen

Deaktiviere nur den Traffic-Manager-Endpunkt; stoppe oder lösche für diesen Test keine Produktivressourcen. Markiere unter Endpoints ep-cloudtrips-weu-primary und wähle Disable.

Warte mindestens die DNS-TTL von 30 Sekunden und wiederhole auf dem Laptop:

for attempt in {1..12}; do
  printf '\nAttempt %s\n' "$attempt"
  dig +short "$TM_FQDN"
  curl --silent --show-error --connect-timeout 10 "http://${TM_FQDN}/"
  sleep 10
done

dig sollte zur zweiten Public IP wechseln und die Anwendung mit WEB02 antworten. Vergleiche die beiden aufgezeichneten Public IPs und Antworttexte, um den DNS-Endpunktwechsel zu beweisen.

Lokale Betriebssystem-, Browser- und rekursive Resolver-Caches können die alte Antwort bis zum Ablauf ihrer TTL behalten. Traffic Manager steuert neue DNS- Antworten; er kann bereits gecachte Antworten nicht zurückrufen.

Terminal mit Umschaltung des Traffic-Manager-Namens von der ursprünglichen zur Backup Public IP

Aktiviere ep-cloudtrips-weu-primary wieder, warte auf Online und lasse die DNS-TTL ablaufen. Derselbe Profilname sollte danach wieder West Europe liefern.

Produktions-DNS-Namen verstehen

Benutzer würden normalerweise einen Unternehmensnamen wie www.cloudtrips.example statt des trafficmanager.net-Hostnamens verwenden. Erstelle beim autoritativen öffentlichen DNS-Provider einen CNAME vom Anwendungsnamen zum Profil:

www.cloudtrips.example CNAME tm-cloudtrips-<suffix>.trafficmanager.net

Erstelle diesen Beispielrecord nicht in einer echten Zone. DNS-Provider und Domaininhaber müssen den tatsächlichen Namen genehmigen. Verwende für ein Zone Apex wie cloudtrips.example einen Azure-DNS-Aliasrecord oder eine Apex-Alias- Funktion des Providers; ein normaler CNAME kann nicht am Zone Apex koexistieren.

Traffic Manager bietet Endpunktfailover, aber keine Replikation des Anwendungszustands. Sessions, Datenbanken, Secrets und hochgeladene Dateien benötigen weiterhin ein regionales Datenreplikations- und Recovery-Design.

Traffic-Manager-Lab entfernen

Lösche tm-cloudtrips-<suffix> unter Traffic Manager profiles. Das entfernt Profil und Endpunktdefinitionen, aber weder Load Balancer, Public IPs noch VMs.

Entferne optional die temporären von Azure verwalteten DNS-Labels und behalte die Public-IP-Ressourcen:

az network public-ip update \
  --resource-group "$RG_NAME" \
  --name pip-cloudtrips-lb-test-weu \
  --remove dnsSettings

az network public-ip update \
  --resource-group "$RG_NAME" \
  --name pip-cloudtrips-lb-tm-test-weu \
  --remove dnsSettings

Lösche den temporären Load Balancer und danach seine Public IP:

lb-cloudtrips-web-tm-test-weu
pip-cloudtrips-lb-tm-test-weu

Öffne zuletzt den ursprünglichen Backend Pool von lb-cloudtrips-web-test-weu und füge die NIC/IP-Konfiguration von WEB02 wieder hinzu. Warte, bis WEB01 und WEB02 fehlerfrei sind. Behalte den ursprünglichen Load Balancer, seine Public IP, VMs, das NSG und den HTTP-Dienst.