Sie konfigurieren Azure Front Door (Standard/Premium) mit zwei Ursprüngen (Origins): East US und West Europe. Sie möchten, dass beide Ursprünge aktiv sind, Client-Anfragen den Ursprung mit der geringsten Latenz bevorzugen und fehlerhafte Ursprünge automatisch aus der Rotation entfernt werden. Jeder Ursprung stellt einen HTTPS /healthz-Endpunkt bereit, der bei fehlerfreiem Zustand 200 zurückgibt. Wie sollten Sie die Ursprungsgruppe konfigurieren?

Die richtige Konfiguration platziert beide Ursprünge in einer einzigen Ursprungsgruppe und nutzt die Latenz-Lastverteilung mit gleichen Gewichten. Dies stellt sicher, dass Client-Anfragen automatisch an den Ursprung mit der geringsten Latenz weitergeleitet werden, was die Anforderung nach Bevorzugung der geringsten Latenz erfüllt. Der konfigurierte HTTPS GET Health Probe auf /healthz alle 30 Sekunden mit einem erwarteten Statuscode von 200–399 ermöglicht die automatische Erkennung und Entfernung fehlerhafter Ursprünge aus der Rotation. Die Deaktivierung der Sitzungsaffinität ist für dieses Szenario oft wünschenswert, um eine optimale Latenzverteilung zu gewährleisten, es sei denn, die Anwendung erfordert Sticky Sessions. Die anderen Optionen sind falsch, weil: Zwei Ursprungsgruppen mit Priorität würden Failover statt Latenz-Routing implementieren und das Deaktivieren von Health Probes würde die Erkennung fehlerhafter Ursprünge verhindern. Ein HTTP-Probe auf / und gewichtete Lastverteilung (Gewicht 0 für West Europe) würde West Europe nicht aktiv nutzen und wäre nicht latenzbasiert. Separate Ursprungsgruppen und manuelle Auswahl würden keine automatische Latenz- oder Fehlerbehandlung bieten.