Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Azure Traffic Manager einfach erklärt: DNS-Lastenausgleich, 6 Routing-Methoden und automatisches Failover (KI-Synchronfassung)

Transcript

Azure Traffic Manager einfach erklärt: DNS-Lastenausgleich, 6 Routing-Methoden und automatisches Failover (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

0:00
Bereit für 10 Tage Microsoft 365, Co-Pilot, KI, Azure und die Menschen, die die Zukunft der Arbeit gestalten?
0:07
Diesen Januar ist die M3M565-Con zurück und wird noch größer.
0:12
Nehmen Sie an Live-Sitzungen, Demos aus der Praxis und praktischem Wissen von MVPs und Branchenexperten aus aller Welt teil.
0:18
Keine generischen Folien, keine endlosen Schlagwörter.
0:21
Wir stellen uns den echten Herausforderungen Co-Pilot Studio, KI-Agents, Fabric, Sicherheit, Governance und Automatisierung.
0:28
Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt speziell auf Sie zugeschnittene Sitzungen.
0:35
An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen.
0:40
Sehen Sie sich die Live-Übertragung an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen.
0:45
Januar 2027, 10 Tage, eine Microsoft-Community.
0:49
Die Registrierung ist ab sofort möglich.
0:51
Besuchen Sie m3m555.net und sichern Sie sich noch heute Ihren Platz.
0:56
Das ist m3m5.net.
0:58
Melden Sie sich jetzt auf m3m5.net an und wir sehen uns im Januar live, live.
1:05
Willkommen zu einer weiteren Folge von Microsoft Knowledge Nuggets.
1:07
Ich bin der Gastgeber Milko Peters.
1:09
Das heutige Thema ist Azure Traffic Management.
1:12
Stellen Sie sich vor, Sie haben eine Web-App entwickelt, die Menschen auf der ganzen Welt verwenden möchten.
1:15
Benutzer in Tokio, London und Sao Paulo versuchen alle gleichzeitig auf ihre App zuzugreifen.
1:19
Aber hier ist das Problem.
1:20
Jeder einzelne dieser Benutzer greift auf einen Server in einer Region zu, sagen wir in Virginia.
1:24
Der Benutzer in Tokio wartet über 200 Millisekunden pro Anforderung und der Benutzer in Sao Paulo hat eine noch schlechtere Erfahrung.
1:30
Wenn dieses Rechenzentrum in Virginia ausfällt, ein Stromausfall, ein Netzwerkausfall oder etwas Unerwartetes vorliegt, ist Ihre gesamte App offline.
1:37
Jeder Benutzer überall ist eine einzelne Fehlerquelle und ein großes Problem.
1:40
Was wäre also, wenn Sie jeden Benutzer automatisch an den nächstgelegenen, schnellsten und fehlerfreisten Server weiterleiten würden?
1:45
Was wäre, wenn ein Benutzer in Tokio von einem Rechenzentrum in Japan bedient würden?
1:48
Ein Benutzer in London aus Irland und wenn eine Region ausfällt, wird der Datenverkehr einfach an eine andere Stelle verschoben, ohne dass Sie etwas tun müssen?
1:54
Genau das macht Azure Traffic Manager und zwar auf DNS-Ebene.
1:58
Das heißt, es ist einfacher als Sie denken.
1:59
Am Ende dieser Folge wissen Sie, was Traffic Manager eigentlich ist, wie seine sechs Routing-Methoden funktionieren und wann Sie welche verwenden und wann Sie welche verwenden.
2:06
Holen Sie sich Ihren Kaffee und legen wir los.
2:08
Warum global ist Datenverkehrsrouting wichtig? Lassen Sie es uns aufschlüsseln.
2:11
Die meisten Leute, wenn Sie den Begriff Lastenausgleich hören, denken an einen einzelnen Server, der den Datenverkehr auf mehrere Computer an einem Rechenzentrum verteilt.
2:17
Das ist Azure Load Balancer und es eignet sich hervorragend für eine einzelne Rechnung.
2:20
Doch was passiert, wenn Ihre Benutzer über verschiedene Kontinente verteilt sind?
2:22
Ein Benutzer in Japan, der auf einen Server in Virginia zugreift, wird nie eine schnelle Antwort erhalten.
2:27
Die physikalischen Grundlagen des Internets lassen das einfach nicht zu.
2:30
Licht breitet sich mit einer festen Geschwindigkeit aus und jeder Netzwerk-Hopfe verursacht Verzögerungen.
2:35
Das lässt sich nicht mit besserem Code oder einem schnelleren Dienst beheben.
2:37
Denn langsame Apps verlieren Benutzer.
2:39
Eine Verzögerung von einer Sekunde reduziert die Conversions um 7% an regionaler Ausfall, verlangsamt nicht nur die Abläufe, sondern setzt Ihre gesamte App offline.
2:46
Ihre Nutzer können Sie nicht erreichen, Ihre Einnahmen bleiben aus und Ihr Ruf leitet.
2:50
Vor 20 Jahren bestand der alte Ansatz darin, in jeder Region Server zu installieren und die Nutzer manuell an den richtigen Server weiterzuleiten.
2:56
DNS-Einträge wurden manuell aktualisiert, Tabellenkalkulationen darüber geführt, welche Nutzer wohin gegangen sind und man betete, dass man beim Failover gemacht hatte.
3:03
Dieser Ansatz ist unpraktisch und instabil, da er nicht skalierbar ist und unter Druck zusammenbricht.
3:08
Der neue Ansatz ist ein einzelner DNS-basierter Traffic Director, der den besten Endpunkt pro Nutzer und Anfrage auswählt.
3:13
Er erfordert keine manuellen Updates oder instabilen Kalkulationen.
3:16
Stattdessen wird geprüft, wo sich der Nutzer befindet, welche Endpunkte fehlerfrei sind und der beste Endpunkt wird zurückgegeben.
3:21
Stellen Sie sich das wie ein globales Flugsicherungssystem vor, bei dem jedes Rechenzentrum ein Flughafen ist und der Traffic Manager der Kontrollturm ist, der jeden Nutzer zum nächstgelegenen verfügbaren Server leitet.
3:30
Hier kommt Traffic Manager ins Spiel.
3:32
Sprechen wir also darüber, was Traffic Manager eigentlich ist.
3:35
Ist die einfachste Definition.
3:36
Traffic Manager ist ein DNS-basierter Lastenausgleich, der auf globaler Ebene ausgeführt wird.
3:40
Stellen Sie sich das wie einen intelligenten Empfangstresen am Eingang eines Bürogebäudes auf der ganzen Welt vor.
3:44
Wenn Sie hereinkommen, nimmt der Empfangsmitarbeiter weder Ihre Anrufe entgegen noch bearbeitet Ihre Unterlagen.
3:48
Er verweist Sie lediglich an die richtige Eta.
3:50
Das ist alles, was Traffic Manager tut.
3:51
Er verweist Benutzer an den richtigen Server.
3:53
Hier ist der wichtigste Unterschied.
3:55
Traffic Manager sieht nie Ihren tatsächlichen Datenverkehr.
3:58
Er leitet keine Anforderungen als Proxy weiter, überprüft keine Pakete und speichert keine Inhalte zu.
4:01
Wenn ein Benutzer Ihren Domain-Namen in seinen Browser eingibt, wird eine DNS-Abfrage gesendet.
4:06
Traffic Manager beantwortet diese Abfrage mit der IP-Adresse des besten, nächstgelegenen, fehlerfreisten Endpunkts, den Sie als Priorität konfiguriert haben.
4:12
Dann stellt der Benutzer eine direkte Verbindung mit diesem Endpunkt her und Traffic Manager tritt vollständig in den Hintergrund.
4:17
Das bedeutet, dass Ihrem Datenverkehrsfahrt keinerlei Latenz hinzugefügt wird, da er sich nicht in der Mitte des Datenflusses befindet und die Daten nicht verlangsamen.
4:23
Er funktioniert auch mit jedem beliebigen Endpunkt mit Internetzugriff, mit Azure-Diensten, Servern in einer anderen Cloud und sogar mit Ihrem eigenen lokalen Rechenzentrum.
4:30
Solange der Endpunkt über eine öffentliche IP-Adresse oder einen Domain-Namen verfügt, kann Traffic Manager Daten dorthin weiterleiten.
4:35
Da es sich um einen globalen Dienst handelt, ist er gegenüber regionalen Ausfällen widerschenkt.
4:38
Wenn eine gesamte Azure-Region ausfällt, wird Traffic Manager weiterhin ausgeführt und leitet Benutzern fehlerfreie Endpunkte an anderen Stellen weiter.
4:45
Woher weiß Traffic Manager, welche Endpunkte fehlerfrei sind?
4:48
Sie werden standardmäßig alle 30 Sekunden getestet, wobei eine HTTP- oder HTTPS-Anforderung an einen bestimmten Pfad auf jedem Endpunkt gesendet wird.
4:54
Wenn der Endpunkt innerhalb eines Timeouts mit einem Statuscode der Ebene 200 antwortet, ist er fehlerfrei.
4:58
Wenn er mehrmals hintereinander nicht antwortet, kennzeichnet Traffic Manager ihn als beeinträchtigt und leitet keine Benutzer mehr dorthin weiter.
5:04
Wenn der Endpunkt wiederhergestellt ist, erkennt Traffic Manager dies ebenfalls und nimmt ihn wieder in die Rotation auf.
5:09
Diese Integritätsüberwachung ermöglicht das automatische Failover.
5:12
Sehen wir uns nun die verschiedenen Methoden an, mit denen Traffic Manager entscheidet, an welchen Endpunktbenutzer weitergeleitet werden.
5:17
Wir kommen die Routing-Methoden ins Spiel.
5:21
Prioritätsrouting, Notfallwiederherstellung leicht gemacht.
5:23
Prioritätsrouting ist die am einfachsten zu verstehende Methode.
5:25
Sie ordnen ihre Endpunkte von 1 bis zur gewünschten Anzahl.
5:28
Das ist alles.
5:29
Der gesamte Datenverkehr hält Priorität 1.
5:30
Wenn dieser Endpunkt ausfällt, erhält der Datenverkehr Priorität 2.
5:33
Denn 3 USWs handelt sich um eine Aktiv-Passiv-Konfiguration.
5:36
Ein Endpunkt kümmert sich um alles die anderen.
5:38
Warte Schleife, eine Warte Schleife.
5:40
Hier ist ein Beispiel aus der Praxis.
5:41
Angenommen, Ihre primären Server werden in USA-Osten ausgeführt und Sie haben Einsicherungsserver in Europa-Westen.
5:45
Sie legen USA-Osten als Priorität 1 und Europa-Westen als Priorität 2 fest.
5:49
Im Normalfall werden alle Benutzer an USA-Osten weitergeleitet.
5:52
Wenn es jedoch in USA-Osten kommt, wie durch einen Stromausfall oder ein Netzwerkproblem erkennt Traffic Manager dies innerhalb von Sekunden.
5:57
Neue Benutzer werden nicht mehr an USA-Osten weitergeleitet, sondern an Europa-Westen.
6:02
Ihre App bleibt online und Ihre Benutzer bemerken möglicherweise nicht einmal, dass etwas passiert ist.
6:05
Hier gibt es ein wichtiges Detail.
6:07
Vorhandene Benutzer behalten ihre aktuelle Verbindung.
6:09
DNS-basiertes Routing wirkt sich nur auf neue DNS-Look-Absolven.
6:11
Wenn also jemand Ihre App bereits geladen hat und über eine aktive Sitzung verfügt, wird diese Sitzung weiterhin an den ursprünglichen Endpunkt weitergeleitet, bis sie beendet wird oder der DNS-Cache abläuft.
6:18
Aus diesem Grund sollten Sie Ihre DNS-TTL niedrig festlegen. 30 bis 60 Sekunden sind der optimale Wert.
6:23
Eine niedrige TTL bedeutet, dass DNS-Auflösungsmodule häufiger nach Updates suchen.
6:26
Wenn Traffic Manager also zwischen Endpunkten wechselt, wird die Änderung schneller übernommen.
6:30
Ein häufiger Fehler besteht darin, dass vergessen wird, das Failover zu testen.
6:33
Wir legen ein Prioritäts-Routing fest, stellen Ihre Sicherungsregionen bereit und gehen dann einfach davon aus, dass alles funktioniert.
6:37
Aber hier ist der Clou. Ihre Sicherungsregion muss die Gesamtlast verarbeiten können.
6:40
Wenn Ihre primäre Region eine Million Benutzer pro Tag verarbeitet und Ihre Sicherungsregion im Normalbetrieb nur 100.000 Benutzer, kann diese Sicherungsregion ausfallen, wenn der gesamte Datenverkehr plötzlich dorthin verlagert wird.
6:50
Testen Sie Ihr Failover. Simulieren Sie tatsächlichen Ausfall und beobachten Sie, was passiert.
6:54
Nur so können Sie sicherstellen, dass alles funktioniert.
6:55
Priorität hat Ihre App bei Fehlern am Laufen zu halten. Aber wie sieht es mit der Geschwindigkeit für alle aus?
7:01
Leistungsrouting. Schwindigkeit hat oberste Priorität. Leistungsrouting funktioniert anders als Prioritätsrouting.
7:06
Anstelle von immer zuerst diesen Endpunkt verwenden, heißt es, jeden Benutzer an den Endpunkt weiterleiten,
7:10
der Ihnen die schnellste Verbindung bietet.
7:12
Ein Benutzer in Tokio wird also an einen Server in Japan weitergeleitet.
7:14
Ein Benutzer in London wird nach Irland weitergeleitet.
7:16
Ein Benutzer in Sao Paulo wird nach Brasilien weitergeleitet.
7:18
Jeder Benutzer erhält die schnellstmögliche Erfahrung, egal wo er sich befindet.
7:22
Woher weiß Traffic Manager, welcher Endpunkt der schnellste ist?
7:25
Er verwendet eine sogenannte Internetlatenztabelle.
7:27
Stellen Sie sich diese wie eine Karte vor, die von Azure auf den neuesten Stand greift.
7:29
Sie verfolgt die tatsächliche Netzwerklatenz zwischen verschiedenen Teilen der Welt und jeder Azure-Region nach.
7:33
Wenn eine DNS-Abfrage eingeht, überprüft Traffic Manager, wo sich der DNS-Resolver des Benutzers befindet,
7:39
schlägt in der Latenztabelle nach und gibt den Endpunkt zurück, der dem Benutzer die geringste Latenz bietet.
7:44
Hier ist etwas, das Sie vielleicht überraschen wird.
7:46
Es basiert nicht auf der physischen Entfernung.
7:48
Ein Benutzer in Indien erhält möglicherweise eine geringere Latenz nach USA, Osten als nach Südostasien,
7:52
je nachdem, wie die Unterseekabel und Internetknoten den Datenverkehr zu diesem Zeitpunkt weiterleiten.
7:56
Die Latenztabelle erfasst die tatsächlichen Netzwerkbedingungen, nicht nur die Luftlinie, nicht nur die Luftlinie.
8:00
Daher ist der nächstgelegene Endpunkt nicht immer der geografisch nächstgelegene.
8:05
Leistungsrouting eignet sich hervorragend für globale Apps, bei denen die Benutzererfahrung von der Geschwindigkeit abhängt.
8:10
E-Commerce-Websites, Video-Streaming-Tools für die Zusammenarbeit in Echtzeit all jene Bereiche,
8:13
in denen eine langsame Antwort den Verlust eines Benutzers bedeutet.
8:15
Es gibt jedoch einen Haken.
8:16
Es berücksichtigt nicht, wie viel Last jeder Endpunkt bereits verarbeitet.
8:19
Wenn Ihre Region USA Osten zu 95 Prozent, Ihre Region Europa-Westen zu 20 Prozent ausgelastet ist,
8:24
leitet das leistungsorientierte Routing neue Benutzer möglicherweise trotzdem an die Region USA möglicherweise herrschen.
8:28
Ihre Serverauslastung ist im Routing.
8:29
Daher kombinieren Sie in der Regel das leistungsorientierte Routing mit anderen Lastenausgleichsmodulen in jeder Region Azure Load Balancer oder Application Gateway,
8:36
um die tatsächliche Verteilung des Datenverkehrs auf Ihres Server zu verarbeiten, sobald der Benutzer in der richtigen Region ankommt.
8:41
Das leistungsorientierte Routing optimiert die Geschwindigkeit.
8:44
Was aber, wenn Sie steuern müssen, wie viel Datenverkehr jeder Endpunkt erhält?
8:48
Gewichtetes und geografisches Routing, Kontrolle und Compliance.
8:51
Beim leistungsorientierten Routing geht es um Geschwindigkeit.
8:52
Was aber, wenn Sie genau steuern möchten, wie viel Datenverkehr jeder Endpunkt erhält?
8:56
Oder wenn Sie benutzerbasierend auf Ihrem Standort auf der Welt weiterleiten möchten?
8:59
Hier kommen gewichtetes und geografisches Routing-Spiel.
9:01
Beginnen wir mit dem gewichteten Routing.
9:03
Dies ist genau das, wonach es sich anhört.
9:05
Sie weisen jedem Endpunkt eine Gewichtung zu, eine Zahl zwischen 1 und 1000.
9:09
Traffic Manager verteilt dann den Datenverkehr proportional auf Grundlage dieser Gewichtung.
9:12
Wenn Sie also Endpunkt A mit einer Gewichtung von 80 und Endpunkt B mit einer Gewichtung von 20 haben,
9:17
werden etwa 80% Ihrer Benutzer an A und 20% an B weitergeleitet.
9:21
Einfache Mathematik.
9:22
Warum sollten Sie das tun?
9:24
Denken Sie an einen Canary Release.
9:25
Sie haben eine neue Version Ihrer App erstellt und möchten Sie mit echten Benutzern testen,
9:28
bevor Sie sie für alle bereitstellen.
9:30
Sie richten einen zweiten Endpunkt ein, auf dem die neue Version ausgeführt wird,
9:33
weisen Ihnen eine Gewichtung von 5 und Ihrem aktuellen Produktionsendpunkt eine Gewichtung von 590 zu.
9:36
5% Ihrer Nutzer greifen auf die neue Version zu.
9:38
Sie achten auf Fehler, überwachen die Leistung
9:40
und wenn alles gut aussieht, erhöhen Sie langsam die Gewichtung der neuen Version,
9:43
vielleicht nächste Woche um 20%, dann um 50%, dann um 100%.
9:46
Wenn etwas schief geht, setzen Sie die Gewichtung wieder auf 0 zurück und das Problem ist eingedämmt.
9:50
Keine Big Bang-Bereitstellung, kein Rollback eines fehlerhaften Releases vor den Augen aller Ihrer Nutzer.
9:54
Dieselbe Idee gilt für A-B-Tests.
9:56
Sie möchten feststellen, ob ein neues Feature das Engagement verbessert.
9:58
Senden Sie die Hälfte Ihrer Nutzer mit gleichen Gewichtungen an Version A und die andere Hälfte an Version B.
10:02
Vergleichen Sie die Ergebnisse.
10:03
Oder Sie migrieren Nutzer von einer Region in eine andere.
10:06
Verschieben Sie die Gewichtung über einige Wochen schrittweise von der alten in die neue Region.
10:09
Hier ist jedoch etwas wichtig zu verstehen.
10:11
Gewichtetes Routing ist kein Round-Robin-Verfahren.
10:13
Es wechselt nicht jeweils an Anforderungen zwischen Endpunkten.
10:16
Es handelt sich um eine statistische Verteilung.
10:17
Bei einer großen Anzahl von Anforderungen wird der Datenverkehr entsprechend Ihrer Gewichtungen aufgeteilt.
10:21
Ein einzelner Nutzer, der mehrere Anforderungen stellt,
10:23
trifft möglicherweise immer wieder auf denselben Endpunkt,
10:25
da sein DNS-Resolver das Ergebnis zwischenspeichert.
10:28
Stellen Sie sich das also nicht als perfekte Lastverteilung.
10:30
Stellen Sie sich vor, Sie steuern den Gesamtanteil des Datenverkehrs im Zeitverlauf.
10:33
Sprechen wir nun über geografisches Routing.
10:35
Bei diesem Routing werden Benutzer basierend darauf weitergeleitet, wo Ihre DNS-Erfang hat.
10:38
Land, Kontinent oder eine bestimmte Region.
10:41
Ein Benutzer in Deutschland wird also einen Endpunkt in Frankfurt weitergeleitet.
10:43
Ein Benutzer in Brasilien wird dann ihren Endpunkt in Sao Paulo weitergeleitet.
10:47
Diese Detailebene ist sehr detailliert.
10:48
Warum sollten Sie dies verwenden?
10:49
Datenhoheit ist ein wichtiges Thema.
10:51
Die Vorschriften der Europäischen Union schreiben möglicherweise vor,
10:53
dass Benutzerdaten in Europa bleiben.
10:54
Mit geografischem Routing können Sie dies auf DNS-Ebene durchsetzen.
10:57
Ein Benutzer aus Frankreich löst Ihre Domäne auf
10:59
und der Traffic-Manager gibt die IP-Adresse Ihres europäischen Endpunkts zurück.
11:02
Deine Daten verlassen niemals den Kontinent.
11:04
Dasselbe gilt für lokalisierte Inhalte.
11:05
Wenn Sie möchten, dass Benutzer in Japan eine japanische Version Ihrer Website sehen,
11:09
werden Sie durch geografisches Routing an den Endpunkt weitergeleitet, der diesen Inhalt bereitsteht.
11:12
Eine wichtige Regel müssen Sie kennen.
11:14
Jede geografische Region muss genau einem Endpunkt zugeordnet sein.
11:17
Sie können ein einzelnes Land nicht auf zwei Endpunkte aufteilen.
11:19
Wenn Sie also Benutzer in Deutschland haben und möchten,
11:21
dass 50% nach Frankfurt und 50% nach Berlin geleitet werden,
11:24
können Sie dies nicht allein mit geografischem Routing bewerkschieben.
11:26
Stattdessen müssten Sie ein geschachteltes Profil verwenden.
11:28
Geschachtelte Profile sind genau das, wonach der Name schon sagt.
11:30
Sie fügen ein Traffic-Manager-Profil in ein anderes ein.
11:33
Auf der obersten Ebene verwenden Sie also geografisches Routing um europäische Benutzer an ein Profil,
11:37
nordamerikanische Benutzer an ein anderes US-E-Zene.
11:39
Anschließend verwenden Sie innerhalb jedes dieser Profile gewichtetes Routing
11:41
und den Datenverkehr zwischen Endpunkten innerhalb dieser Region aufzuteilen.
11:44
Geografisch ganz oben für die Einhaltung von Vorschriften gewichtet und für die Kontrolle.
11:47
Das ist eine leistungsstarke Kombination.
11:48
Zwei weitere Routing-Methoden behandeln spezifische Resszenarien.
11:51
Werfen einen Blick darauf.
11:53
Mehrwertiges und Subnet-Routing für eine differenzierte Steuerung.
11:56
Mehrwertiges Routing ist ein einfacher, aber nützlicher Trick.
11:58
Anstatt nur einen Endpunkt in der DNS-Antwort zurückzugeben,
12:01
sendet Traffic-Manager mehrere fehlerfreie IP-Adressen gleichzeitig zurück.
12:05
Ihr Browser oder Ihre App wählt die erste aus der Liste aus,
12:07
wodurch die Last verteilt wird, ohne dass Traffic-Manager für jede Anforderung eine Entscheidung treffen muss.
12:11
Es gibt jedoch einen Hack.
12:12
Multi-Value funktioniert nur mit IPv4 und IPv6 Endpunkten.
12:15
Daher können Sie es nicht mit App-Diensten, Cloud-Diensten oder Endpunkten verwenden,
12:19
die einen Domänen-Namen anstelle einer IP-Adresse verwenden.
12:22
Es ist ausschließlich für IP-basierte Endpunkte vorgesehen.
12:24
Wenn Sie über diese verfügen, wird das System jedoch widerstandsfähiger,
12:27
da der Client beim Ausfall einer IP-Adresse eine andere aus der Liste ausprobieren kann,
12:30
ohne eine neue DNS-Suche durchführen zu müssen.
12:31
Dies bedeutet ein schnelleres Failover auf der Client-Seite.
12:34
Subnet-Routing ist noch spezieller, aber leistungsstark, wenn Sie es benötigen.
12:37
Es leitet Benutzer basierend auf dem Quell-IP-Subnetz weiter, aus dem Ihre DNS-Abfrage stammt.
12:40
Sie können also den IP-Adressbereich Ihres Unternehmens einem Staging-Endpunkt zuordnen
12:44
und alle anderen erhalten die Produktionsversion.
12:47
Sie können Benutzer auch von einem bestimmten VPN-Subnetz zu einem dedizierten Backend für Tests weiterleiten.
12:52
Stellen Sie sich ein internes Test-Szenario vor, bei dem Ihr Entwicklungsteam im Büro arbeitet.
12:56
Die DNS-Abfragen stammen aus Ihrem Unternehmens-IP-Bereich
12:58
und Sie ordnen diesen Bereich einer Staging-Umgebung zu, in der Sie den neuesten Bild testen können.
13:03
Alle anderen im Internet erhalten die Produktionsversion.
13:05
Keine speziellen URLs, keine VPN-Konfigurationen, nur transparentes Routing basierend darauf, woher die Anforderungen stammen.
13:11
Beide Methoden sind Nischenmethoden.
13:12
Die meisten Benutzer verwenden für ihr primäres Datenverkehrsmanagement die Methoden Priorität, Leistung, Gewichtung, Gewichtung oder Geld.
13:17
Aber mehrere Werte und Subnetz sind verfügbar, wenn Sie sie benötigen.
13:20
Und Sie lösen Probleme, die mit den anderen Methoden nicht gelöst werden können.
13:23
Integritätsüberwachung und Fehlerpraxis
13:24
Alle diese Routing-Methoden hängen von einer Sache ab, dem Wissen, welche Endpunkte tatsächlich fehlerfrei sind.
13:29
Das Weiterleiten von Datenverkehr an einen defekten Server hilft niemandem.
13:31
Lassen Sie uns darüber sprechen, wie die Integritätsüberwachung in der Praxis funktioniert.
13:34
Traffic-Manager sendet standardmäßig alle 30 Sekunden einen Integritätstest an jeden Endpunkt.
13:39
Dieser Test ist eine HTTP- oder HTTPS-Anforderung an einen bestimmten Pfad auf Ihrem Endpunkt.
13:43
Innerhalb eines bestimmten Timeout-Zeitraums wird eine Antwort mit einem Statuscode zwischen 200 und 299 erwartet.
13:48
Wenn der Endpunkt ordnungsgemäß antwortet, ist er fehlerfrei.
13:51
Tut er dies nicht, versucht Traffic-Manager es erneut.
13:53
Nach einer konfigurbaren Anzahl von Fehlern, standardmäßig drei,
13:56
kennzeichnet Traffic-Manager diesen Endpunkt als beeinträchtigt und schließt ihn vom Routing aus,
13:59
bis er die Integritätsprüfungen wieder besteht.
14:01
Sie können das Prüfintervall und das Timeout konfigurieren.
14:04
Schnellere Prüfungen bedeuten ein schnelleres Fehler.
14:06
Wenn Sie das Intervall auf 10 Sekunden statt auf 30 festlegen,
14:08
erkennt Traffic-Manager Fehler früher und leitet den Datenverkehr schneller um.
14:12
Allerdings belasten schnellere Prüfungen Ihre Endpunkte stärker,
14:15
da jede Prüfung eine Anforderung ist, die Ihr Server verarbeiten muss.
14:18
Wenn Sie also über tausende von Endpunkten verfügen und alle 10 Sekunden eine Prüfung durchführen,
14:21
summieren sich die Anforderungen.
14:22
Da müssen Sie Geschwindigkeit und Mehraufwand gegeneinander haben.
14:24
Die tatsächliche Auswirkung einer ordnungsgemäßen Konfiguration der Integritätsprüfung
14:27
ist der Unterschied zwischen einem reibungslosen Failover und einem Fehlalarm, der Ihr Routing unterbricht.
14:31
Wenn Ihre Prüfung zu empfindlich ist, können Sie einen Endpunkt als beeinträchtigt kennzeichnen,
14:34
obwohl er eigentlich in Ordnung ist.
14:36
Eine vorübergehende Spitze bei der Latenz, eine kurze Netzwerkstörung oder eine langsame Datenbankabfrage.
14:41
All diese Faktoren können einen falsch positiven Wert auslösen.
14:43
Wenn Traffic-Manager keine Benutzer mehr an diesen Endpunkt sendet,
14:46
haben Sie soeben einen unnötigen Ausfall verursacht.
14:48
Ist ein häufiger Fehler.
14:49
Benutzer legen den Testpfad mit nur einem Schrägstrich auf das Stammverzeichnis Ihrer Anwendung fest.
14:53
Das ist für eine grundlegende Integritätsprüfung ausreichend, aber nicht ideal,
14:57
da die Stammseite möglicherweise langsam geladen wird,
14:59
wenn sie eine vollständige Seite mit Datenbankabfragen, Bildern und JavaScript rendert.
15:02
Ein besserer Ansatz besteht darin, einen dedizierten Endpunkt für die Integritätsprüfung zu erstellen.
15:06
Dabei sollte es sich um eine einfache Funktion handeln,
15:08
die schnell den Statuscode 200 zurückgibt und bestätigt, dass die Anwendung ausgeführt wird.
15:11
Keine Datenbankabfragen, keine umfangreiche Verarbeitung, nur ein Hardbeat.
15:14
Auf diese Weise sind Ihre Tests schnell und zuverlässig und lösen mit geringerer Wahrscheinlichkeit Fehlalarme aus.
15:19
Lassen Sie mich noch einmal zusammenfassen,
15:20
wann Sie Traffic Manager im Vergleich zu anderen Optionen tatsächlich verwenden sollten.
15:24
Fazit und Entscheidungshilfe
15:25
Hier also eine kurze Zusammenfassung.
15:27
Traffic Manager ist ein DNS-basierter globaler Datenverkehrsmanager mit sechs Routing-Methoden.
15:31
Er verarbeitet Ihren Datenverkehr nicht tatsächlich.
15:33
Es leitet Benutzer einfach an dem richtigen Ort weiter, aber Sie haben auf der von Ihnen ausgewählten mit.
15:37
Prioritätsrouting dient der Notfallwiederherstellung.
15:39
Damit wird Ihre App auch dann ausgeführt, wenn eine gesamte Region ausfährt.
15:42
Beim Leistungsrouting dreht sich alles umgeschwindig.
15:45
Es leitet jeden Benutzer an den Endpunkt mit der geringsten Latenz weiter.
15:48
Gewichtetes Routing ermöglicht Ihnen kontrollierte Rollouts wie Canary-Reses oder AB-Tests.
15:53
Geografisches Routing kümmert Sie Compliance.
15:55
Sie speichern Daten in der richtigen Region, je nachdem, wo sich Ihre Benutzer befinden.
15:59
Mehrwertig dient der einfachen Verteilung auf IP-Ebene über mehrere Adressen.
16:02
Und Subnets Routing routet basierend auf der Quell-IP der DNS-Abfrage.
16:06
Lassen Sie uns nun darüber sprechen, wie sich Traffic Manager in eine echte Architektur einführen.
16:09
Lernen Sie sich vor.