Erweiterte Trafficverwaltung

Dieses Dokument richtet sich an Mesh- oder Plattform-Administratoren und Dienstentwickler, die fortgeschrittene Kenntnisse von Traffic Director und Service Mesh-Konzepten haben und bestimmen und konfigurieren, wie Traffic in einer Traffic Director-Bereitstellung verwaltet wird. Dieses Dokument bezieht sich nur auf die Service Routing APIs. Wenn Ihre Traffic Director-Bereitstellung die Legacy-Load-Balancing-APIs verwendet, finden Sie weitere Informationen unter Erweiterte Traffic-Verwaltung für Load-Balancing-APIs. Die globalen Load-Balancing-Funktionen von Traffic Director stehen Ihnen unabhängig von der verwendeten API zur Verfügung.

Traffic Director bietet erweiterte Funktionen zur Trafficverwaltung, mit denen Sie besser steuern können, wie Traffic verarbeitet wird. Traffic Director unterstützt die folgenden Anwendungsfälle:

  • Detailliertes Traffic-Routing von Anfragen an einen oder mehrere Dienste.
  • Gewichtete Trafficaufteilung, um Traffic auf mehrere Dienste zu verteilen.
  • Richtlinien für Traffic-Spiegelung, die Anfragen an einen Debugging-Dienst senden und in einen anderen kopieren. Die Trafficspiegelung wird mit den Ressourcen TCPRoute und TLSRoute nicht unterstützt.
  • Optimierte Traffic-Verteilung auf die Back-Ends eines Dienstes für verbessertes Load-Balancing

Mit diesen erweiterten Trafficverwaltungsfunktionen können Sie Ihre Verfügbarkeits- und Leistungsziele erreichen. Einer der Vorteile von Traffic Director für diese Anwendungsfälle ist, dass Sie die Verwaltung des Traffics aktualisieren können, ohne den Anwendungscode ändern zu müssen.

Die Trafficverwaltung in einem Service Mesh von Traffic Director basiert auf den folgenden Ressourcen:

  • Ressource Mesh, die das Service Mesh identifiziert und die Komponente darstellt, die für die Weiterleitung von Traffic und die Anwendung von Richtlinien verantwortlich ist. Die Ressource Mesh identifiziert auch den Port zum Abfangen von Traffic.
  • Gateway-Ressource, die mittlere Proxys identifiziert und die Komponente darstellt, die eine Liste von IP-Adresse:Port-Paaren überwacht, Traffic weiterleitet und Richtlinien anwendet.
  • Ressource Route, die einer von mehreren Typen sein kann und Informationen zum Traffic-Routing für das Mesh enthält. Route-Ressourcen identifizieren Hostnamen und Ports, über die Clients Traffic an Back-End-Dienste weiterleiten können.
  • Back-End-Dienst, mit dem Route Ressourcen verknüpft sind.

Dies sind die verschiedenen Typen von Route-Ressourcen:

  • HTTPRoute, die nur in Mesh-Netzwerken mit Envoy-Proxys verfügbar ist. Wenn Sie die Ressource HTTPRoute zum Konfigurieren der Envoy-Proxys zum Senden von HTTP-Anfragen verwenden, sind alle Funktionen in diesem Dokument verfügbar.
  • TCPRoute, die nur in Mesh-Netzwerken mit Envoy-Proxys verfügbar ist.
  • TLSRoute, die nur in Mesh-Netzwerken mit Envoy-Proxys verfügbar ist.
  • GRPCRoute, der in Mesh-Netzwerken mit Envoy-Sidecar-Proxys und proxylosem gRPC verfügbar ist. Wenn Sie proxylose gRPC-Dienste oder Anwendungen mit Traffic Director verwenden, sind einige der in diesem Dokument beschriebenen Funktionen nicht verfügbar.

Konfiguration

Zum Konfigurieren der erweiterten Trafficverwaltung verwenden Sie dieselben Ressourcen für Route und Back-End-Dienste, die Sie beim Einrichten von Traffic Director verwenden. Traffic Director konfiguriert wiederum Ihre Envoy-Proxys und proxylose gRPC-Anwendungen, um die von Ihnen eingerichteten erweiterten Richtlinien zur Trafficverwaltung durchzusetzen.

Auf übergeordneter Ebene führen Sie diese Schritte aus:

  1. Konfigurieren Sie eine Mesh-Ressource, um das Service Mesh zu identifizieren.

  2. Konfigurieren Sie Route-Ressourcen basierend auf den Eigenschaften der ausgehenden Anfrage für Folgendes:

    1. Wählen Sie den Back-End-Dienst aus, an den Anfragen weitergeleitet werden sollen.

    2. Führen Sie ggf. weitere Aktionen aus.

  3. Konfigurieren Sie den Backend-Dienst, um zu steuern, wie Traffic nach der Auswahl eines Zieldienstes an Backends und Endpunkte verteilt wird.

Trafficrouting und -aktionen

In Traffic Director wird der Traffic anhand von Werten in den Ressourcen Mesh, Route und Back-End-Dienst weitergeleitet. Alle Funktionen der erweiterten Trafficverwaltung im Zusammenhang mit Routing und Aktionen werden mit Route-Objekten konfiguriert.

In den folgenden Abschnitten werden die Features der erweiterten Trafficverwaltung beschrieben, die Sie in den Route-Objekten einrichten können.

Anfragen verarbeiten

Wenn ein Client eine Anfrage sendet, wird sie wie in den folgenden Schritten beschrieben verarbeitet:

  1. Die Anfrage wird so mit einer bestimmten Route-Ressource abgeglichen:

    • Wenn Sie Envoy verwenden:
      • Der Hostheader in der HTTP-Anfrage wird mit dem Feld hostnames in jeder HTTPRoute- oder GRPCRoute-Ressource abgeglichen, um die richtige Route-Ressource für die Anfrage auszuwählen. Nur die Ressourcen HTTPRoute und GRPCRoute haben das Feld hostnames.
      • Die IP-Adresse wird für das Routing von TCP-Traffic über TCPPRoute abgeglichen.
      • SNI und ALPN werden für TLS Passthrough mit TLSRoute verwendet.
      • Die Ressourcen HTTPRoute und GRPCRoute, die mit einem Mesh oder Gateway verknüpft sind, müssen eindeutige Hostnamen haben. Wenn Sie versuchen, mehrere Routen mit in Konflikt stehenden Hostnamen anzuhängen, wird die Konfiguration abgelehnt.
      • Ebenso muss das Feld IP:Port der TCPRoute eindeutig sein. Andernfalls wird die Konfiguration abgelehnt.
      • Ebenso müssen SNI und ALPN für TLSRoute eindeutig sein.
      • Wenn sich Hostnamen wie a.example.com und *.example.com überschneiden, stimmt die Anfrage mit der spezifischeren Route überein.
    • Wenn Sie proxylose gRPC-Dienste verwenden:
      • Proxylose gRPC-Clients verwenden das Namensauflösungsschema xds. Er löst den hostname[:port] im Ziel-URI auf, indem er eine Anfrage an Traffic Director sendet.
      • Nur der Port einer GRPCRoute-Ressource wird mit dem Port im Ziel-URI verglichen, z. B. xds:///example.hostname:8080. Der Ziel-URI muss genau mit dem String im Feld hostnames von GRPCRoute übereinstimmen.

  2. Die Ressource Route kann weitere Routinginformationen und Regeln enthalten.

  3. Nachdem der Ziel-Back-End-Dienst ausgewählt wurde, wird der Traffic basierend auf der Konfiguration in der Back-End-Dienstressource auf die Back-Ends oder Endpunkte für diesen Ziel-Back-End-Dienst verteilt.

Der zweite Schritt wird im folgenden Abschnitt Einfaches Routing nach Host und Pfad beschrieben. Der dritte Schritt wird unter Erweitertes Routing und erweiterte Aktionen beschrieben.

Einfaches Routing nach Host und Pfad

Traffic Director unterstützt ein vereinfachtes und ein komplexeres Routingschema. Im einfachen Schema geben Sie einen Host und optional einen Pfad an. Der Host und der Pfad der Anfrage werden ausgewertet, um den Back-End-Dienst zu bestimmen, an den die Anfrage weitergeleitet wird.

  • Der Host der Anfrage ist der Teil einer URL mit dem Domainnamen. Der Hostteil der URL http://example.com/video/ lautet beispielsweise example.com.
  • Der Pfad der Anfrage ist der Teil der URL, der auf den Hostnamen folgt. Der Pfadteil der URL http://example.com/video/ lautet beispielsweise /video.

Sie richten ein einfaches Routing basierend auf Host und Pfad in der Routingregelzuordnung ein, die aus Folgendem besteht:

  • Ein globales Mesh
  • HTTPRoute oder GRPCRoute

Der größte Teil der Konfiguration wird in HTTPRoute ausgeführt. Nachdem Sie die anfängliche Routingregelzuordnung erstellt haben, müssen Sie nur die Ressource HTTPRoute ändern.

Am einfachsten ist eine Standardregel, in der Sie nur eine Platzhalter-Hostregel (*) und ein Tool zum Abgleich von Pfaden mit einem Standarddienst angeben. Nachdem Sie die Standardregel erstellt haben, können Sie zusätzliche Regeln hinzufügen, mit denen verschiedene Hosts und Pfade angegeben werden. Ausgehende Anfragen werden folgendermaßen ausgewertet:

  • Wenn der Host einer Anfrage (z. B. example.com) mit dem Hostnamen HTTPRoute übereinstimmt:

    1. Als Nächstes wird RouteRule ausgewertet. Mit RouteRule wird angegeben, wie der Traffic abgeglichen und weitergeleitet wird.
    2. Jedes RouteRule enthält eine oder mehrere Routenübereinstimmungen, die anhand des Anfragepfads ausgewertet werden.
    3. Bei einer Übereinstimmung wird die Anfrage an den in RouteAction angegebenen Dienst weitergeleitet.

Weitere Informationen zu den Ressourcenfeldern der HTTPRoute und ihrer Funktionsweise finden Sie in der Dokumentation zur Network Service API.

Erweitertes Routing und erweiterte Aktionen

Wenn Sie nicht nur eine Anfrage weiterleiten möchten, die auf dem Host und dem Pfad der Anfrage basiert, können Sie auch erweiterte Regeln einrichten, um Anfragen weiterzuleiten und Aktionen auszuführen.

Auf übergeordneter Ebene funktionieren erweitertes Routing und erweiterte Aktionen so:

  1. Wie beim einfachen Routing wird der Host der Anfrage mit den Hostregeln verglichen, die Sie in HTTPRoute oder GRPCRoute konfigurieren. Wenn der Host einer Anfrage mit dem Hostnamen übereinstimmt, wird HTTPRoute oder GRPCRoute ausgewertet.
  2. Nachdem eine Route ausgewählt wurde, können Sie Aktionen anwenden.

Erweitertes Routing

Das erweiterte Routing ähnelt dem zuvor beschriebenen einfachen Routing, mit der Ausnahme, dass Sie zusätzliche Abgleichsbedingungen angeben können. Sie können beispielsweise festlegen, dass eine Regel mit dem Header einer Anfrage übereinstimmt, wenn der Name des Headers genau oder nur teilweise übereinstimmt, z. B. anhand eines Präfixes oder Suffixes. Dabei können der Name des Headers mit einem regulären Ausdruck verglichen oder andere Kriterien herangezogen werden. Beispielsweise kann geprüft werden, ob ein Header vorhanden ist.

Weitere Abgleichsbedingungen und Details zu headerMatches und queryParameterMatches finden Sie auf der Seite network services REST API.

Wenn Sie Host-, Pfad-, Header- und Abfrageparameter mit Abgleichsbedingungen kombinieren, können Sie äußerst ausdrucksstarke Regeln erstellen, die genau Ihren Anforderungen an die Traffic-Verwaltung entsprechen. Weitere Informationen finden Sie in der folgenden Tabelle.

HTTP-basierte Anwendung gRPC-basierte Anwendung
HTTP-Hosts im Vergleich zu gRPC-Hosts

Der Host ist der Teil einer URL mit dem Domainnamen, die von der Anwendung aufgerufen wird.

Der Hostteil der URL http://example.com/video/ ist beispielsweise example.com.

Der Host ist der Name, den ein Client im Kanal-URI verwendet, um eine Verbindung zu einem bestimmten Dienst herzustellen.

Der Hostteil des Kanal-URI xds:///example.com ist beispielsweise example.com.
HTTP-Pfade im Vergleich zu gRPC-Pfaden

Der Pfad ist der Teil der URL, der dem Hostnamen folgt.

Der Pfadteil der URL http://example.com/video lautet beispielsweise /video.

Der Pfad befindet sich im Header :path der HTTP/2-Anfrage und sieht so aus: /SERVICE_NAME/METHOD_NAME.

Wenn Sie beispielsweise die Methode Download für den gRPC-Dienst Example aufrufen, sieht der Inhalt des Headers :path so aus: /Example/Download.
Andere gRPC-Header (Metadaten) gRPC unterstützt das Senden von Metadaten zwischen dem gRPC-Client und dem gRPC-Server, um zusätzliche Informationen zu einem RPC-Aufruf bereitzustellen. Diese Metadaten liegen in Form von Schlüssel/Wert-Paaren vor, die als Header in der HTTP/2-Anfrage bereitgestellt werden.

Aktionen

Mit Traffic Director können Sie Aktionen festlegen, die von Envoy-Proxys oder proxylosen gRPC-Anwendungen übernommen werden, wenn eine Anfrage verarbeitet wird. Die folgenden Aktionen können mit Traffic Director konfiguriert werden.

Aktion API-Feldname Beschreibung
Weiterleitungen redirect [pathredirect?] Gibt einen konfigurierbaren 3xx-Antwortcode zurück. Außerdem wird der Antwortheader Location mit dem entsprechenden URI festgelegt, wobei der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt werden.
URL-Umschreibungen urlRewrite Überschreibt den Hostnamen-Teil der URL, den Pfad-Teil der URL oder beide, bevor eine Anfrage an den ausgewählten Back-End-Dienst gesendet wird.
Headertransformationen requestHeaderModifier/responseHeaderModifier? Fügt Anfrageheader hinzu oder entfernt diese, bevor eine Anfrage an den Back-End-Dienst gesendet wird. Außerdem können Antwortheader nach Empfang einer Antwort vom Back-End-Dienst hinzugefügt oder entfernt werden.
Traffic-Spiegelung requestMirrorPolicy

Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Back-End-Dienst auf Fire-and-Forget-Basis wird hierbei eine identische Anfrage an den konfigurierten Spiegel-Back-End-Dienst gesendet. Der Load-Balancer wartet nicht auf eine Antwort vom Back-End, an die die gespiegelte Anfrage gesendet wird.

Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Back-End-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Back-End-Dienstes anstatt in der Produktionsversion zu beheben.
Gewichtete Trafficaufteilung weiDestination.serviceNameght

Lässt zu, dass Traffic für eine übereinstimmende Regel an mehrere Back-End-Dienste verteilt wird, proportional zu einer benutzerdefinierten Gewichtung, die dem einzelnen Back-End-Dienst zugewiesen ist.

Diese Funktion eignet sich zur Konfiguration abgestufter Bereitstellungen oder von A/B-Tests. Die Routingaktion könnte beispielsweise so konfiguriert werden, dass 99 % des Traffics an einen Dienst gesendet werden, der eine stabile Version einer Anwendung ausführt, während 1 % des Traffics an einen separaten Dienst mit einer neueren Version dieser Anwendung gesendet wird.
Neuversuche retryPolicy Konfiguriert die Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, die Wartezeit des Load-Balancers bis zum erneuten Versuch sowie die maximal zulässige Anzahl von Wiederholungen.
Zeitlimit timeout Gibt das Zeitlimit für die ausgewählte Route an. Das Zeitlimit wird vom Zeitpunkt der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen.
Fault Injection faultInjectionPolicy Kann Fehler bei der Bearbeitung von Anfragen einbringen, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Dieses Feature ist hilfreich, um die Ausfallsicherheit eines Dienstes gegenüber simulierten Störungen zu testen.
Sicherheitsrichtlinien corsPolicy Richtlinien für Cross-Origin Resource Sharing (CORS) verarbeiten die Einstellungen für die Erzwingung von CORS-Anfragen.

Weitere Informationen zu Aktionen und ihrer Funktionsweise finden Sie auf der Seite Netzwerkdienste-API.

In jeder Routingregel können Sie eine der folgenden Routingaktionen angeben:

  • Traffic an einen einzelnen Dienst weiterleiten (destination.serviceName)
  • Traffic auf mehrere Dienste aufteilen (destination.weight)
  • Weiterleitungs-URLs (redirect)

Darüber hinaus können Sie eine der zuvor genannten Routingaktionen mit einer oder mehreren der folgenden Routingaktionen kombinieren. Diese werden in der Cloud Console als Add-on-Aktionen bezeichnet:

  • Anfrage- oder Antwortheader bearbeiten (requestHeaderModifier/responseHeaderModifier)
  • Trafficspiegelung (requestMirrorPolicy)
  • URL-Host, -Pfad oder beides umschreiben (urlRewrite)
  • Fehlgeschlagene Anfragen wiederholen (retryPolicy)
  • Zeitlimit festlegen (timeout)
  • Fehler in einem Prozentsatz des Traffics einführen (faultInjectionPolicy)
  • CORS-Richtlinie hinzufügen (corsPolicy)

Da Aktionen bestimmten Regeln zugeordnet sind, können der Envoy-Proxy oder die proxylose gRPC-Anwendung je nach Anfrage, die sie verarbeitet, unterschiedliche Aktionen ausführen.

Traffic auf die Back-Ends eines Dienstes verteilen

Wenn ein Client eine ausgehende Anfrage verarbeitet, wird wie unter Anfragen verarbeiten beschrieben zuerst ein Zieldienst ausgewählt. Nachdem ein Zieldienst ausgewählt wurde, muss er herausfinden, welches Back-End oder welcher Endpunkt die Anfrage erhalten soll.

Traffic auf Back-Ends verteilen.
Traffic auf Back-Ends verteilen (zum Vergrößern klicken)

Im obigen Diagramm wurde die Regel vereinfacht. Die Regel ist häufig eine Hostregel, ein Tool zum Abgleich von Pfaden und mindestens eine Pfad- oder Routingregel. Der Zieldienst ist der Back-End-Dienst. Die Anfrage wird von Back-End 1, ... und Back-End n empfangen und verarbeitet. Bei diesen Back-Ends kann es sich beispielsweise um VM-Instanzen von Compute Engine handeln, die Ihren serverseitigen Anwendungscode hosten.

Standardmäßig sendet der Client, der die Anfrage verarbeitet, Anfragen an das nächstgelegene fehlerfreie Back-End mit Kapazität. Um eine Überlastung eines bestimmten Back-Ends zu vermeiden, wird der Load-Balancing-Algorithmus Round-Robin verwendet, um nachfolgende Anfragen auf andere Back-Ends des Zieldienstes zu verteilen. In bestimmten Fällen muss dieses Verhalten jedoch genauer gesteuert werden.

Load-Balancing, Sitzungsaffinität und Schützen von Back-Ends

Sie können für jeden Dienst die folgenden Richtlinien zur Trafficverteilung festlegen.

Richtlinie API-Feldname Beschreibung
Load-Balancing-Modus balancingMode Steuert, wie eine Netzwerk-Endpunktgruppe (NEG) oder eine verwaltete Instanzgruppe (Managed Instance Group, MIG) ausgewählt wird, nachdem ein Zieldienst ausgewählt wurde. Sie können den Balancing-Modus so konfigurieren, dass die Last auf der Grundlage von gleichzeitigen Verbindungen und der Anfragerate verteilt wird.
Load-Balancing-Richtlinie localityLbPolicy Legt den Load-Balancing-Algorithmus fest, der zur Verteilung des Traffics auf Back-Ends innerhalb einer NEG oder MIG verwendet wird. Zur Optimierung der Leistung können Sie aus verschiedenen Algorithmen auswählen (z. B. Round-Robin oder Least-Request).
Sitzungsaffinität sessionAffinity

Bietet einen Best-Effort-Versuch, Anfragen von einem bestimmten Client an dasselbe Back-End zu senden, solange das Back-End fehlerfrei ist und Kapazität hat.

Traffic Director unterstützt vier Optionen für die Sitzungsaffinität: Client-IP-Adresse, HTTP-Cookie-basiert, HTTP-Header-basiert und Cookie-Affinität, die von Traffic Director selbst generiert wird.
Konsistenter Hash consistentHash Stellt Soft-Sitzungsaffinität basierend auf HTTP-Headern, Cookies oder anderen Attributen bereit.
Schutzschalter circuitBreakers Legt Obergrenzen für die Anzahl von Verbindungen und Anfragen pro Verbindung zu einem Back-End-Dienst fest.
Ausreißererkennung outlierDetection Gibt die Kriterien an, um (1) fehlerhafte Back-Ends oder Endpunkte aus MIGs oder NEGs zu entfernen und (2) ein Back-End oder einen Endpunkt wieder hinzuzufügen, wenn es als fehlerfrei genug gilt, um Traffic zu empfangen. Die mit dem Dienst verknüpfte Systemdiagnose bestimmt, ob ein Back-End oder ein Endpunkt als fehlerfrei gilt.

Weitere Informationen zu den verschiedenen Optionen für die Trafficverteilung und ihrer Funktionsweise finden Sie auf der Seite backendServices REST API und in der Übersicht über Back-End-Dienste.

Anwendungsbeispiele

Die erweiterte Trafficverwaltung deckt viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.

Weitere Beispiele, einschließlich Beispielcode, finden Sie unter Erweiterte Trafficverwaltung mit Envoy konfigurieren und Erweiterte Trafficverwaltung mit proxylosen gRPC-Diensten konfigurieren.

Detailliertes Trafficrouting für die Personalisierung

Sie können Traffic anhand der Parameter der Anfrage an einen Dienst weiterleiten. Beispielsweise können Sie mit diesem Dienst Android-Nutzern ein personalisiertes Erlebnis ermöglichen. Im folgenden Diagramm konfiguriert Traffic Director Ihr Service Mesh so, dass Anfragen mit dem Header user-agent:Android an den Android-Dienst statt an den generischen Dienst gesendet werden.

Routing basierend auf dem User-Agent-Header, der auf Android gesetzt ist
Routing anhand des Headers user-agent, der auf Android festgelegt ist (zum Vergrößern klicken)

Gewichtete Trafficaufteilung für sicherere Bereitstellungen

Die Bereitstellung einer neuen Version eines bestehenden Produktionsdienstes birgt in der Regel ein gewisses Risiko. Auch wenn die Tests in einer Testumgebung erfolgreich sind, möchten Sie unter Umständen nicht sofort alle Nutzer an die neue Version weiterleiten.

Mit Traffic Director können Sie gewichtete Trafficaufteilungen definieren, um den Traffic auf mehrere Dienste zu verteilen. Sie können beispielsweise 1% des Traffics an die neue Version Ihres Dienstes senden, dessen Leistung überwachen und dann den Anteil des Traffics an den neuen Dienst nach und nach erhöhen.

Traffic Director: gewichtete Trafficaufteilung
Gewichtete Trafficaufteilung für Traffic Director (zum Vergrößern klicken)

Trafficspiegelung für das Debugging

Wenn Sie ein Problem beheben möchten, kann es hilfreich sein, Kopien des Produktionstraffics an einen Debugging-Dienst zu senden. Mit Traffic Director können Sie Richtlinien für die Anfragespiegelung einrichten, sodass Anfragen an einen bestimmten Dienst und Kopien dieser Anfragen an einen anderen Dienst gesendet werden.

Traffic Director: Trafficspiegelung
Trafficspiegelung für Traffic Director (zum Vergrößern klicken)

Optimiertes Load-Balancing für bessere Leistung

Je nach den Eigenschaften Ihrer Anwendung stellen Sie möglicherweise fest, dass Sie die Leistung und Verfügbarkeit verbessern können, wenn Sie die Verteilung des Traffics auf die Back-Ends eines Dienstes optimieren. Mit Traffic Director können Sie erweiterte Load-Balancing-Algorithmen anwenden, um den Traffic entsprechend Ihren Anforderungen zu verteilen.

Das folgende Diagramm zeigt im Gegensatz zu vorherigen Diagrammen sowohl einen Ziel-Back-End-Dienst (Produktionsdienst) als auch die Back-Ends für diesen Back-End-Dienst (Virtuelle Maschine 1, Virtuelle Maschine 2, Virtuelle Maschine 3). Mit der erweiterten Trafficverwaltung können Sie konfigurieren, wie ein Ziel-Back-End-Dienst ausgewählt und der Traffic zwischen den Back-Ends für diesen Zieldienst verteilt wird.

Traffic Director: Load-Balancing
Load-Balancing für Traffic Director (zum Vergrößern klicken)

Nächste Schritte