Erweiterte Trafficverwaltung

Dieses Dokument richtet sich an Mesh- oder Plattformadministratoren und Dienste Entwickelnden, die sich mit dem Thema Cloud Service Mesh- und Service-Mesh-Konzepte und legen Sie fest, wie wird der Traffic in einer Cloud Service Mesh-Bereitstellung verwaltet.

Cloud Service Mesh bietet erweiterte Funktionen für die Traffic-Verwaltung mit denen Sie genau steuern können, wie Traffic verarbeitet wird. Cloud Service Mesh unterstützt die folgenden Anwendungsfälle:

  • Detailliertes Traffic-Routing von Anfragen an einen oder mehrere Dienste.
  • Gewichtete Trafficaufteilung, um den Traffic auf mehrere Dienste zu verteilen.
  • Trafficspiegelungsrichtlinien, die Anfragen an einen Debugging-Dienst senden und in ein anderes kopiert. Trafficspiegelung wird mit dem TCPRoute nicht unterstützt oder die TLSRoute-Ressource.
  • Optimierte Traffic-Verteilung auf die Back-Ends eines Dienstes zur Verbesserung der Last für ein ausgewogenes Verhältnis.

Mit diesen erweiterten Trafficverwaltungsfunktionen können Sie Ihre Verfügbarkeits- und Leistungsziele erreichen. Einer der Vorteile der Verwendung von Cloud Service Mesh für diese Anwendungsfälle besteht darin, dass Sie die wird verwaltet, ohne dass Sie Ihren Anwendungscode ändern müssen.

Die Trafficverwaltung in einem Cloud Service Mesh-Service-Mesh basiert auf Ressourcen:

  • Mesh-Ressource, die das Service Mesh identifiziert und den Komponente, die für die Weiterleitung von Traffic und die Anwendung Richtlinien. Die Ressource Mesh identifiziert auch den Abfangport von Traffic.
  • Gateway-Ressource, die mittlere Proxys identifiziert und die Komponente, die eine Liste von IP-Adresse:Port-Paaren überwacht, und wendet Richtlinien an.
  • Route-Ressource. Diese kann einen von mehreren Typen haben und enthält Traffic-Routinginformationen für das Mesh-Netzwerk. Route Ressourcen identifizieren Hostnamen und Ports, mit denen Clients Traffic an Backend weiterleiten können . Es gibt die folgenden Typen von Route-Ressourcen:
    • HTTPRoute, das nur in Mesh-Netzwerken mit Envoy-Proxys verfügbar ist. Wenn Sie Verwenden Sie die Ressource HTTPRoute, um die Envoy-Proxys zum Senden von HTTP zu konfigurieren -Anfragen enthalten, sind alle in diesem Dokument beschriebenen Funktionen verfügbar.
    • TCPRoute, das nur in Mesh-Netzwerken mit Envoy-Proxys verfügbar ist.
    • TLSRoute, das nur in Mesh-Netzwerken mit Envoy-Proxys verfügbar ist.
    • GRPCRoute, das in Mesh-Netzwerken mit Envoy-Sidecar-Proxys und proxylose gRPC-Dienste. Wenn Sie proxylose gRPC-Dienste oder -Anwendungen mit Cloud Service Mesh nutzen können, sind einige der hier beschriebenen Funktionen Dokument nicht verfügbar.
  • Back-End-Dienst, mit dem Route-Ressourcen verknüpft sind.

Konfiguration

Für die Konfiguration der erweiterten Trafficverwaltung verwenden Sie dieselben Route- und Back-End-Dienstressourcen, die Sie beim Einrichten von Cloud Service Mesh verwenden. Cloud Service Mesh wiederum konfiguriert Ihre Envoy-Proxys und proxylose gRPC-Dienste Anwendungen, um die von Ihnen festgelegten Richtlinien für die erweiterte Traffic-Verwaltung zu erzwingen nach oben.

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 für Folgendes, basierend auf dem Eigenschaften der ausgehenden Anfrage:

    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 Cloud Service Mesh wird Traffic basierend auf Werten in der Ressource Mesh weitergeleitet. Route und Back-End-Dienstressource. Gesamte erweiterte Traffic-Verwaltung Funktionen für Routing und Aktionen werden mithilfe der Route konfiguriert Objekte.

In den folgenden Abschnitten werden die erweiterten Traffic-Verwaltungsfunktionen beschrieben, die 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 einer bestimmten Route-Ressource zugeordnet:

    • Wenn Sie Envoy verwenden: <ph type="x-smartling-placeholder">
        </ph>
      • Der Host-Header in der HTTP-Anfrage wird mit hostnames abgeglichen. in jeder HTTPRoute- oder GRPCRouteRessource, um das richtige Route für die Anfrage. Nur HTTPRoute und GRPCRoute Ressourcen haben das Feld hostnames.
      • Die IP-Adresse wird für das Routing von TCP-Traffic mit TCPPRoute abgeglichen.
      • SNI und ALPN werden für TLS-Passthrough mithilfe von TLSRoute verwendet.
      • Die Ressourcen HTTPRoute und GRPCRoute sind mit einem Mesh- oder Eine Gateway muss eindeutige Hostnamen haben. Wenn Sie mehrere die widersprüchliche Hostnamen haben, wird die Konfiguration abgelehnt.
      • Ebenso muss das Feld IP:Port der TCPRoute eindeutig sein oder der Wert Konfiguration abgelehnt wurde.
      • Ebenso müssen SNI und ALPN für TLSRoute eindeutig sein.
      • Wenn sich Hostnamen wie a.example.com und *.example.com stimmt die Anfrage mit der spezifischeren Route überein.
    • Wenn Sie proxylose gRPC-Dienste verwenden:
      • Proxylose gRPC-Clients verwenden das Namensauflösungsschema xds. Sie hostname[:port] im Ziel-URI auflösen, indem Sie eine Anfrage senden zum Cloud Service Mesh.
      • Nur der Port einer GRPCRoute-Ressource wird verglichen auf den Port im Ziel-URI (z. B. xds:///example.hostname:8080). Der Ziel-URI muss genau übereinstimmen Den String im Feld hostnames von GRPCRoute.

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

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

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

Cloud Service Mesh unterstützt ein vereinfachtes Routingschema und eine erweiterten Schemas. Im einfachen Schema geben Sie einen Host und optional einen Pfad. Der Host und der Pfad der Anfrage werden ausgewertet, um den Back-End-Dienst zu ermitteln 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 erfolgt in der HTTPRoute. Nach dem Erstellen der anfängliche Routingregelzuordnung verwenden, müssen Sie nur die HTTPRoute-Ressource ä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 von HTTPRoute:

    1. Als Nächstes wird RouteRule ausgewertet. RouteRule gibt an, wie abgeglichen werden soll. und wie Traffic weitergeleitet wird, wenn Traffic übereinstimmt.
    2. Jede RouteRule enthält eine oder mehrere Routenübereinstimmungen, die ausgewertet werden mit dem Anfragepfad vergleichen.
    3. Wird eine Übereinstimmung gefunden, wird die Anfrage an den Dienst weitergeleitet, der in RouteAction.

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

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 dem Host Regeln, die Sie in HTTPRoute oder GRPCRoute konfigurieren. Wenn eine Anfrage Host mit dem Hostnamen übereinstimmt, wird HTTPRoute oder GRPCRoute ausgewertet.
  2. Nachdem eine Route ausgewählt wurde, können Sie Aktionen ausführen.

Erweitertes Routing

Erweitertes Routing ähnelt dem beschriebenen einfachen Routing, mit der Ausnahme, dass Sie zusätzliche Übereinstimmungsbedingungen 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.

Indem Sie Host-, Pfad-, Header- und Suchparameter mit der Keyword-Option können Sie aussagekräftige Regeln erstellen, die genau zu Ihrem Traffic zu entwickeln. 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 Cloud Service Mesh können Sie Aktionen angeben, die Ihre Envoy-Proxys oder Proxylose gRPC-Anwendungen verarbeiten Anfragen. Folgende Aktionen können mit Cloud Service Mesh 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 Schreibt den Hostnamen-Teil der URL, den Pfadteil der URL, oder beides, 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. Kann Antwortheader auch nach dem eine Antwort vom Back-End-Dienst zu erhalten.
Traffic-Spiegelung requestMirrorPolicy

Zusätzlich zur Weiterleitung der Anfrage an das ausgewählte Backend -Dienst, sendet eine identische Anfrage an das konfigurierte Spiegel-Back-End Service auf einem Feuer und Vergessenwerden. Der Load-Balancer wartet nicht auf eine Antwort vom Back-End, und sendet die gespiegelte Anfrage.

Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Back-End-Dienstes. Sie können sie auch verwenden, um Produktionsfehler in einer Debugversion von in Ihrem Back-End-Dienst und nicht in der Produktionsversion.
Gewichtete Trafficaufteilung weiDestination.serviceNameght

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

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 Dient zum Konfigurieren von Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, der Wartezeit des Load-Balancers bis zum erneuten Versuch sowie der maximal zulässigen Anzahl an Wiederholungsversuchen.
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 findest du in der Network Services 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, kann der Envoy-Proxy oder Eine proxylose gRPC-Anwendung kann basierend auf der Anfrage verarbeitet wird.

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, Back-End oder Endpunkt die Anfrage erhalten soll.

Traffic auf Back-Ends verteilen.
Traffic zwischen 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. Die Der Zieldienst ist der Back-End-Dienst. Back-End 1, ... und Back-End n empfängt und verarbeitet die Anfrage. Diese Back-Ends könnten zum Beispiel Compute Engine-VM-Instanzen, die Ihre serverseitigen Anwendungscode.

Standardmäßig sendet der Client, der die Anfrage verarbeitet, Anfragen an den nächsten fehlerfreien Back-End mit Kapazität. Um eine Überlastung eines bestimmten wird der Round-Robin-Load-Balancing-Algorithmus nachfolgende Anfragen über andere Back-Ends des Zieldienstes. 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 zum Senden von Anfragen von einem bestimmten Client zum selben Back-End gesendet, dass das Back-End fehlerfrei ist und Kapazität hat.

Cloud Service Mesh unterstützt vier Optionen für die Sitzungsaffinität: Client-IP-Adresse, HTTP-Cookie-, HTTP-Header-basiert und Cookie-Affinität, die von Cloud Service Mesh 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 fest. Verbindung zu einem Back-End-Dienst.
Ausreißererkennung outlierDetection Gibt die Kriterien zum Entfernen (1) fehlerhafter Back-Ends oder von MIGs oder NEGs und (2) fügen Sie ein Back-End oder Endpunkt zurück, wenn er als fehlerfrei genug für den Empfang von Traffic gilt. noch einmal. Die mit dem Dienst verknüpfte Systemdiagnose bestimmt, ob ein Back-End oder Endpunkt als fehlerfrei gilt.

Weitere Informationen zu den verschiedenen Optionen zur Traffic-Verteilung und Informationen zur Funktionsweise finden Sie in den folgenden Dokumenten:

Anwendungsbeispiele

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

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

Detailliertes Traffic-Routing 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 Cloud Service Mesh Ihr Service Mesh, um Anfragen mit dem user-agent:Android-Header an Ihr Android-Dienst statt zu Ihrem allgemeinen Dienst.

Routing basierend auf dem User-Agent-Header, der auf Android gesetzt ist
Routing anhand des Headers user-agent, für den Android angegeben 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 Cloud Service Mesh können Sie gewichtete Trafficaufteilungen definieren, um den Traffic für mehrere Dienste. 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.

<ph type="x-smartling-placeholder">
</ph> Gewichtete Traffic-Aufteilung in Cloud Service Mesh.
Gewichtete Traffic-Aufteilung in Cloud Service Mesh (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 Cloud Service Mesh können Sie Anfragen Spiegelrichtlinien, sodass Anfragen an einen Dienst und Kopien dieser Richtlinien -Anfragen an einen anderen Dienst gesendet.

<ph type="x-smartling-placeholder">
</ph> Trafficspiegelung in Cloud Service Mesh.
Trafficspiegelung für Cloud Service Mesh (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 Cloud Service Mesh können Sie und fortschrittlichen Load-Balancing-Algorithmen Ihren Bedürfnissen entsprechen.

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

<ph type="x-smartling-placeholder">
</ph> Cloud Service Mesh-Load-Balancing.
Cloud Service Mesh-Load-Balancing (zum Vergrößern klicken)

Weitere Informationen zum Load-Balancing mit Cloud Service Mesh finden Sie unter Erweitertes Load-Balancing.

Nächste Schritte