Erweitertes Load-Balancing – Übersicht

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Weitere Informationen zum Zugriff auf diesen Release finden Sie auf der Seite Zugriffsanfrage.

Das erweiterte Load-Balancing besteht aus Funktionen, mit denen Sie das globale Load-Balancing und die Traffic-Verteilung im Hinblick auf Ihre Ziele in den Bereichen Verfügbarkeit, Leistung und Kosteneffizienz optimieren können. Dieses Dokument richtet sich an Nutzer, die bereits mit den Grundlagen von Traffic Director und Load-Balancing-Konzepten vertraut sind.

Zur Implementierung des erweiterten Load-Balancings erstellen Sie eine Dienst-Load-Balancing-Richtlinie (serviceLbPolicies-Ressource). Diese enthält Werte, die die Auswahl eines Back-Ends beeinflussen. Anschließend hängen Sie die Load-Balancing-Richtlinie für den Dienst an einen Back-End-Dienst an. Die Richtlinie für das Dienst-Load-Balancing legt den Algorithmus fest, der verwendet wird, um zu bestimmen, wie der Traffic auf die Back-Ends verteilt wird.

Für das erweiterte Load-Balancing können Sie aus den folgenden Algorithmusoptionen auswählen:

• Wasserfall nach Region (Standardalgorithmus).
• Auf den Bereich spritzen.
• Sprühen für die Welt.
• Wasserfall nach Zone.

Folgende zusätzliche Optionen sind verfügbar:

• Legen Sie bevorzugte Back-Ends fest. Traffic Director sendet Traffic an diese MIGs oder NEGs, bevor er Traffic an andere Back-Ends sendet.
• Richten Sie den automatischen Kapazitätsausgleich ein.
• Failover-Verhalten anpassen

Bevor Sie eine der erweiterten Load-Balancing-Optionen konfigurieren, sollten Sie die Dokumentation zur Back-End-Dienstressource lesen.

Weiterleitung des Traffics durch Traffic Director und Load-Balancing

Das folgende Diagramm zeigt, wie Traffic Director entscheidet, den Traffic weiterzuleiten.

Wie Traffic Director Load-Balancing-Entscheidungen trifft (zum Vergrößern klicken)

Zuerst wählt Traffic Director einen Back-End-Dienst anhand der Anfrageeigenschaften und der Routingregeln in der Route-Ressource oder der URL-Zuordnung aus, je nachdem, welche API von Ihrer Bereitstellung verwendet wird.

Zweitens wählt Traffic Director eine Back-End-MI oder NEG aus, die mit dem Back-End-Dienst verknüpft ist, basierend auf dem Clientstandort, dem Standort, dem Zustand und der Kapazität der MIG oder NEG und den Informationen in der Load-Balancing-Richtlinie des Dienstes, die dem Back-End-Dienst zugeordnet ist.

Zuletzt wählt Traffic Director eine Instanz oder einen Endpunkt innerhalb der MIG oder NEG aus. Diese Auswahl basiert auf Informationen in der Ort-Load-Balancing-Richtlinie in den Back-End-Diensten.

Unterstützte und nicht unterstützte Back-Ends

Die folgenden Back-End-Typen werden für erweitertes Load-Balancing unterstützt:

• Nicht verwaltete Instanzgruppen
• Verwaltete Instanzgruppen (MIGs)
• Zonale Netzwerk-Endpunktgruppen (GCE_VM_IP_PORT-NEGs)
• Netzwerk-Endpunktgruppen mit Hybridkonnektivität (NON_GCP_PRIVATE_IP_PORT NEG)

Die folgenden Back-End-Typen werden für erweitertes Load-Balancing nicht unterstützt:

• Regional verwaltete Instanzgruppen
• Internetnetzwerk-Endpunktgruppen (INTERNET_FQDN_PORT-NEGs)

Anwendungsfälle

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Algorithmen funktionieren und welche Auswahl Sie für Ihre speziellen Geschäftsanforderungen treffen sollten.

Traffic auf Back-Ends in einer Region ausgleichen

Der Standard-Load-Balancing-Algorithmus (Wasserfall nach Region) verteilt den Traffic gleichmäßig auf alle MIGs oder NEGs in Zonen in einer Region. Wir empfehlen die Verwendung des Standardalgorithmus, sofern es keine besonderen Anforderungen gibt.

Bei der Vermittlungsabfolge nach Region empfangen Back-Ends Traffic im Verhältnis zu ihrer Kapazität, was einen Schutz vor Back-End-Überlastungen bietet. Der Traffic wird bei Bedarf über Zonengrenzen hinweg gesendet, um eine gleichmäßige Belastung der Back-Ends innerhalb der Region zu gewährleisten. Selbst wenn die lokale Zone des Clients noch Kapazität hat, gibt es zonenübergreifenden Traffic. Die Anfragen jedes Clients können auf mehrere zonale MIGs oder NEGs in der Region verteilt werden. Dies trägt dazu bei, die Last der MIGs oder NEGs einheitlich zu halten, wenn die Trafficlast von den Clients nicht einheitlich ist.

Erhöhen Sie die Ausfallsicherheit, indem Sie Traffic von einem Client über Zonen verteilen

Der Standardalgorithmus „Wasserfall nach Region“ versucht, die Kapazitätsnutzung auf mehrere zonale MIGs oder NEGs auszugleichen. Bei diesem Algorithmus werden Anfragen von einem einzelnen Client jedoch nicht konsistent an alle Zonen gesendet. Anfragen von einem einzelnen Client werden in der Regel an MIGs oder NEGs in einer einzelnen Zone weitergeleitet.

Verwenden Sie den Spray-to-Region-Algorithmus, wenn Sie möchten, dass Clients ihre Anfragen auf alle MIGs oder NEGs in einer Region verteilen. Dadurch wird das Risiko einer Überlastung von MIGs oder NEGs in einer einzelnen Zone reduziert, wenn das Trafficvolumen schnell lokalisiert wird.

Wenn Sie mit dem Spray-to-Region-Algorithmus die beiden Zonen A und B haben und in Zone B eine Trafficspitze auftritt, wird der Traffic auf die beiden Zonen aufgeteilt. Mit dem Standardalgorithmus könnte eine Spitze in Zone B eine Überlastung in der Zone auslösen, bevor Traffic Director auf die Änderung reagieren kann.

Wenn Sie den Spray-to-Region-Algorithmus verwenden, wird der Traffic für jeden Client immer auf die Back-End-Zonen in einer Region verteilt. Dies führt zu einem konstant höheren zonenübergreifenden Traffic, selbst wenn in der lokalen Zone noch Kapazität vorhanden ist, und kann zu einem größeren betroffenen Bereich für den Traffic aus Traffic Director führen, wenn zwei Traffic Director-Clients Traffic an dieselben Zonen senden.

Traffic von Ihrem Client auf alle Back-Ends in mehreren Regionen verteilen

Wie in den vorherigen Abschnitten erläutert, verteilt der Spray-to-Region-Algorithmus den Traffic von jedem Client auf alle Zonen in einer Region. Bei Diensten mit MIGs oder NEGs in mehreren Regionen optimiert Traffic Director trotzdem die Gesamtlatenz, indem der Traffic an die nächstgelegene Region gesendet wird.

Wenn Sie einen größeren Streuradius bevorzugen, verwenden Sie den Spray-to-World-Algorithmus. Mit diesem Algorithmus verteilen Clients ihre Anfragen auf alle MIGs oder NEGs auf der ganzen Welt in mehreren Regionen.

Beachten Sie, dass bei diesem Algorithmus der gesamte Traffic an alle Back-Ends global verteilt wird. Eine fehlerhafte Abfrage kann alle Back-Ends in Ihren Bereitstellungen beschädigen. Der Algorithmus sorgt auch für mehr regionsübergreifenden Traffic, was die Anfragelatenz erhöhen und zusätzliche Kosten verursachen kann.

Zonenübergreifenden Traffic minimieren

Mit der Einstellung „Wasserfall nach Zonen“ können Sie die Gesamtlatenz optimieren und den zonenübergreifenden Traffic reduzieren. Wenn in einer Zone mehrere MIGs oder NEGs konfiguriert sind, wird Clienttraffic bis zu seiner Kapazität an die nächstgelegene MIG oder NEG in der Zone weitergeleitet, bevor Traffic an die nächste MIG oder NEG in der Zone gesendet wird und so weiter, bis die gesamte MIG oder NEG-Kapazität in der Zone aufgebraucht ist. Erst dann wird der Traffic an die nächstgelegene Zone weitergeleitet.

Mit diesem Algorithmus können Sie unnötigen zonenübergreifenden Traffic minimieren. Die Gesamtlatenz kann geringfügig verbessert werden, da die nächstgelegenen lokalen Back-Ends bevorzugt werden. Das kann jedoch auch zu ungleichmäßigem Traffic zwischen den MIGs oder NEGs innerhalb einer Region führen.

Vergleich der Load-Balancing-Algorithmen

Die folgende Tabelle enthält einen detaillierten Vergleich der vier Load-Balancing-Algorithmen von Traffic Director.

Verhalten	Wasserfall nach Region	Auf Region sprühen	Bete auf die Welt	Wasserfall nach Zone
Einheitliche Kapazitätsnutzung innerhalb einer Region in stabilem Zustand	Ja	Ja	Ja	Nein
Einheitliche Kapazitätsnutzung über mehrere Regionen hinweg in stabilem Zustand	Nein	Nein	Ja	Nein
Einheitliche Trafficaufteilung innerhalb einer Region mit stabilem Status	Nein	Ja	Ja	Nein
Zonenübergreifender Traffic	Ja. Dieser Algorithmus verteilt den Traffic gleichmäßig auf Zonen in einer Region und optimiert gleichzeitig die Netzwerklatenz. Traffic kann bei Bedarf zonenübergreifend gesendet werden.	Ja	Ja	Ja, der Traffic füllt die Zone, die der Kapazität am nächsten ist. Dann geht es in die nächste Zone.
Sensibilität gegenüber Trafficspitzen in der lokalen Zone	Durchschnitt; abhängig davon, wie viel Traffic bereits zum Ausgleich zwischen Zonen verschoben wurde.	Niedriger: da Spitzen in einer einzelnen Zone auf alle Zonen in der Region verteilt werden.	Niedriger: Da Spitzen in einer einzelnen Zone über alle Regionen verteilt werden.	Höher; da Spitzen in einzelnen Zonen mit höherer Wahrscheinlichkeit vollständig von einer einzelnen Zone bereitgestellt werden, bis Traffic Director reagieren kann.

Zusätzliche erweiterte Load-Balancing-Optionen

In den folgenden Abschnitten werden Optionen zum Ändern des Traffic Director-Load-Balancings erläutert.

Bevorzugte Back-Ends

Sie können das Load-Balancing so konfigurieren, dass eine Gruppe von Back-Ends eines Back-End-Dienstes als bevorzugt festgelegt wird. Diese Back-Ends werden vollständig genutzt, bevor nachfolgende Anfragen an die verbleibenden Back-Ends weitergeleitet werden. Traffic Director verteilt den Clienttraffic zuerst an die bevorzugten Back-Ends und minimiert so die Anfragelatenzen für Ihre Clients.

Jeglicher Traffic, der die konfigurierte Kapazität der bevorzugten Back-Ends überschreitet, wird an nicht bevorzugte Back-Ends weitergeleitet. Der Load-Balancing-Algorithmus verteilt den Traffic auf die nicht bevorzugten Back-Ends.

Ein Anwendungsfall ist der Überlauf zu Google Cloud, wo Sie lokale Rechenressourcen angeben, die durch eine NEG für Hybridkonnektivität dargestellt werden. Sie müssen vollständig genutzt werden, bevor Anfragen an automatisch skalierte Google Cloud-Back-End-MIGs oder -NEGs weitergeleitet werden. Diese Konfiguration kann den Google Cloud-Computing-Verbrauch minimieren und trotzdem die Ausfallsicherheit bieten, bei Bedarf schrittweise an Google Cloud zu übertragen oder ein Failover durchzuführen.

Automatischer Kapazitätsausgleich

Wenn ein Back-End fehlerhaft ist, empfiehlt es sich in der Regel, es so schnell wie möglich von Load-Balancing-Entscheidungen auszuschließen. Durch den Ausschluss des Back-Ends wird verhindert, dass Anfragen an das fehlerhafte Back-End gesendet werden. Außerdem wird der Traffic zwischen fehlerfreien Back-Ends ausgeglichen, um eine Überlastung des Back-Ends zu vermeiden und die Gesamtlatenz zu optimieren.

Diese Option ähnelt dem Festlegen von capacityscalar auf null. Traffic Director wird aufgefordert, die Back-End-Kapazität automatisch auf null zu reduzieren, wenn bei einem Back-End weniger als 25% der einzelnen Instanzen oder Endpunkte Systemdiagnosen bestehen. Mit dieser Option werden fehlerhafte Back-Ends aus dem globalen Load-Balancing entfernt.

Wenn die automatisch per Drain beendeten Back-Ends wieder fehlerfrei arbeiten, werden sie entfernt, wenn mindestens 35% der Endpunkte oder Instanzen 60 Sekunden lang fehlerfrei sind. Traffic Director entleert nicht mehr als 50% der Endpunkte in einem Back-End-Dienst, unabhängig vom Systemstatus des Back-Ends.

Ein Anwendungsfall ist, dass Sie den automatischen Kapazitätsausgleich mit bevorzugten Back-Ends verwenden können. Wenn eine Back-End-MIG oder NEG bevorzugt wird und viele der darin enthaltenen Endpunkte fehlerhaft sind, schützt diese Einstellung die verbleibenden Endpunkte in der MIG oder NEG, indem der Traffic von der MIG oder NEG weggeleitet wird.

Failover-Verhalten anpassen

Traffic Director sendet in der Regel Traffic an Back-Ends. Dabei werden mehrere Faktoren berücksichtigt. In einem stabilen Zustand sendet Traffic Director Traffic an Back-Ends, die anhand der zuvor beschriebenen Algorithmen ausgewählt werden. Die ausgewählten Back-Ends gelten in Bezug auf Latenz und Kapazitätsauslastung als optimal. Sie werden als primäre Back-Ends bezeichnet.

Traffic Director verfolgt auch die zu verwendenden Back-Ends, wenn die primären Back-Ends fehlerhaft sind und keinen Traffic empfangen können. Diese Back-Ends werden als Failover-Back-Ends bezeichnet. Normalerweise handelt es sich dabei um Back-Ends in der Nähe, auf denen noch Kapazität übrig ist.

Wenn ein Back-End fehlerhaft ist, versucht Traffic Director, das Senden von Traffic an das Back-End zu vermeiden und stattdessen den Traffic auf fehlerfreie Back-Ends zu verlagern.

Die Ressource serviceLbPolicy enthält das Feld failoverHealthThreshold, dessen Wert angepasst werden kann, um das Failover-Verhalten zu steuern. Der von Ihnen festgelegte Grenzwert bestimmt, wann der Traffic von primären Back-Ends zu Failover-Back-Ends verschoben wird.

Wenn einige Endpunkte im primären Back-End fehlerhaft sind, verschiebt Traffic Director den Traffic nicht unbedingt sofort. Stattdessen kann Traffic Director den Traffic auf fehlerfreie Endpunkte im primären Back-End verlagern, um ihn zu stabilisieren.

Wenn zu viele Endpunkte im Back-End fehlerhaft sind, können die verbleibenden Endpunkte keinen zusätzlichen Traffic verarbeiten. In diesem Fall wird anhand des Fehlergrenzwerts entschieden, ob ein Failover ausgelöst wird oder nicht. Traffic Director toleriert Unintegrität bis zum Schwellenwert und verlagert dann einen Teil des Traffics von den primären Back-Ends auf die Failover-Back-Ends.

Der Schwellenwert für den Failover-Zustand ist ein Prozentsatz. Der von Ihnen festgelegte Wert bestimmt, wann Traffic Director den Traffic an die Failover-Back-Ends weiterleitet. Sie können den Wert auf eine Ganzzahl zwischen 1 und 99 festlegen. Der Standardwert für Traffic Director ist 70 bei Envoy und 50 für proxylose gRPC-Dienste. Bei einem höheren Wert startet das Traffic-Failover früher als bei einem kleineren Wert.

Fehlerbehebung

Die Traffic-Verteilungsmuster können sich ändern, je nachdem, wie Sie die neue serviceLbPolicy mit dem Back-End-Dienst eingerichtet haben.

Verwenden Sie zum Beheben von Trafficproblemen die vorhandenen Monitoringsysteme, um zu prüfen, wie der Traffic zu Ihren Back-Ends fließt. Zusätzliche Traffic Director- und Netzwerkmesswerte können Ihnen helfen, zu verstehen, wie Load-Balancing-Entscheidungen getroffen werden. In diesem Abschnitt finden Sie allgemeine Vorschläge zur Fehlerbehebung.

Insgesamt versucht Traffic Director, Traffic zuzuweisen, damit Back-Ends unter der konfigurierten Kapazität ausgeführt werden können. Dies ist jedoch nicht garantiert. Weitere Informationen finden Sie in der Dokumentation zum Back-End-Dienst.

Der Traffic wird dann basierend auf dem von Ihnen verwendeten Algorithmus zugewiesen. Beispiel: Mit dem Algorithmus WATERFALL_BY_ZONE versucht Traffic Director, den Traffic in der nächsten Zone zu halten. Wenn Sie die Netzwerkmesswerte prüfen, stellen Sie fest, dass Traffic Director beim Senden von Anfragen ein Back-End mit der geringsten RTT-Latenz bevorzugt, um die RTT-Gesamtlatenz zu optimieren.

In den folgenden Abschnitten werden Probleme beschrieben, die mit der Richtlinie für das Dienst-Load-Balancing und den bevorzugten Back-End-Einstellungen auftreten können.

Traffic wird an weiter entfernte MIGs oder NEGs vor näher gelegenen MIGs oder NEGs gesendet

Dies ist das beabsichtigte Verhalten, wenn bevorzugte Back-Ends mit weiter entfernten MIGs oder NEGs konfiguriert werden. Wenn Sie dieses Verhalten nicht wünschen, ändern Sie die Werte im Feld „Bevorzugte Back-Ends“.

Traffic wird nicht an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet

Dies ist das beabsichtigte Verhalten, wenn die MIGs oder NEGs per Drain beendet werden, da ein autoCapacityDrain konfiguriert ist. Mit dieser Einstellung werden MIGs oder NEGs mit vielen fehlerhaften Endpunkten aus Load-Balancing-Entscheidungen entfernt und somit vermieden. Wenn dieses Verhalten nicht erwünscht ist, können Sie die Einstellung autoCapacityDrain deaktivieren. Beachten Sie jedoch, dass Traffic an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet werden kann, sodass die Anfragen möglicherweise mit Fehlern fehlschlagen.

Traffic wird nicht an einige MIGs oder NEGs gesendet, wenn bestimmte MIGs oder NEGs bevorzugt werden

Dies ist das beabsichtigte Verhalten, wenn als bevorzugt konfigurierte MIGs oder NEGs die Kapazität noch nicht erreicht haben.

Wenn bevorzugte Back-Ends konfiguriert sind und ihr Kapazitätslimit nicht erreicht haben, wird der Traffic nicht an andere MIGs oder NEGs gesendet. Die bevorzugten MIGs oder NEGs werden basierend auf der RTT-Latenz für diese Back-Ends zuerst zugewiesen.

Wenn Traffic lieber an eine andere Stelle gesendet werden soll, können Sie entweder den Back-End-Dienst ohne bevorzugte Back-Ends oder mit konservativeren Kapazitätsschätzungen für die bevorzugten MIGs oder NEGs konfigurieren.

Traffic wird aus einer einzigen Quelle an zu viele verschiedene MIGs oder NEGs gesendet

Dies ist das beabsichtigte Verhalten, wenn die Spray-to-Region oder Spray-to-World verwendet wird. Es können jedoch Probleme mit einer breiteren Verteilung Ihres Traffics auftreten. Beispielsweise kann die Cache-Trefferquote reduziert werden, wenn Back-Ends Traffic von einer größeren Auswahl von Clients erhalten. Erwägen Sie in diesem Fall die Verwendung anderer Algorithmen, z. B. Wasserfall nach Region.

Traffic wird an einen Remote-Cluster gesendet, wenn sich der Systemzustand des Back-Ends ändert

Wenn failoverHealthThreshold auf einen hohen Wert festgelegt ist, ist dies das beabsichtigte Verhalten. Wenn der Traffic bei vorübergehenden Systemänderungen auf den primären Back-Ends verbleiben soll, setzen Sie failoverHealthThreshold auf einen niedrigeren Wert.

Fehlerfreie Endpunkte sind überlastet, wenn einige Endpunkte fehlerhaft sind

Wenn failoverHealthThreshold auf einen niedrigen Wert festgelegt ist, ist dies das beabsichtigte Verhalten. Wenn einige Endpunkte fehlerhaft sind, wird der Traffic für diese fehlerhaften Endpunkte unter Umständen auf die verbleibenden Endpunkte in derselben MIG oder NEG verteilt. Wenn das Failover-Verhalten frühzeitig ausgelöst werden soll, setzen Sie failoverHealthThreshold auf einen höheren Wert.

Einschränkungen und Überlegungen

Die folgenden Einschränkungen und Überlegungen sollten Sie beim Konfigurieren des erweiterten Load-Balancings beachten.

Wasserfall nach Zone

• Bei transparenten Wartungsereignissen ist es möglich, dass der Traffic außerhalb der lokalen Zone vorübergehend ausgeglichen wird.

• Es ist zu erwarten, dass einige MIGs oder NEGs ausgelastet sind, während andere MIGs oder NEGs in derselben Region nicht ausgelastet sind.

• Wenn sich die Quelle des Traffics zu Ihrem Dienst in derselben Zone wie seine Endpunkte befindet, verzeichnen Sie weniger zonenübergreifenden Traffic.

• Eine Zone kann verschiedenen Clustern interner physischer Hardware in Google-Rechenzentren zugeordnet werden, z. B. aufgrund der Zonenvirtualisierung. In diesem Fall werden VMs in derselben Zone möglicherweise nicht gleichmäßig geladen. Im Allgemeinen wird die Latenz insgesamt optimiert.

Auf Region spritzen

• Wenn die Endpunkte in einer MIG oder NEG ausfallen, wirken sich die Folgen in der Regel auf eine größere Gruppe von Clients aus. Es kann also sein, dass eine größere Anzahl von Mesh-Clients betroffen ist, aber weniger stark.

• Wenn die Clients Anfragen an alle MIGs oder NEGs in der Region senden, kann dies in einigen Fällen den zonenübergreifenden Traffic erhöhen.

• Die Anzahl der offenen Verbindungen zu Endpunkten kann ansteigen, was zu einer erhöhten Ressourcennutzung führt.

Bevorzugte Back-Ends

• Die als bevorzugte Back-Ends konfigurierten MIGs oder NEGs sind möglicherweise weit von den Clients entfernt und können eine höhere durchschnittliche Latenz für Clients verursachen. Dies kann auch dann passieren, wenn andere MIGs oder NEGs die Clients mit einer geringeren Latenz bedienen.

• Globale Load-Balancing-Algorithmen (Wasserfall nach Region, Spray-to-Region, Wasserfall-by-Zone) gelten nicht für MIGs oder NEGs, die als bevorzugte Back-Ends konfiguriert sind.

Automatischer Kapazitätsausgleich

• Die Mindestanzahl von MIGs, die nie per Drain beendet wird, unterscheidet sich von dem Wert, der bei der Konfiguration mit serviceLbPolicies festgelegt wurde.

• Standardmäßig beträgt die Mindestanzahl von MIGs, die nie per Drain beendet werden, 1.

• Wenn serviceLbPolicies festgelegt ist, beträgt der Mindestprozentsatz von MIGs oder NEGs, die nie entleert werden, 50%. In beiden Konfigurationen wird eine MIG oder NEG als fehlerhaft markiert, wenn weniger als 25% der Instanzen oder Endpunkte in der MIG oder NEG fehlerfrei sind.

• Damit eine MIG oder NEG nach einem Drain-Vorgang wieder ausgeführt werden kann, müssen mindestens 35% der Instanzen/Endpunkte fehlerfrei sein. Dies ist erforderlich, damit eine MIG oder NEG nicht zwischen dem Entwässern und dem Nichtzustand wechseln kann.

• Dieselben Einschränkungen für den Kapazitätsskalierer für Back-Ends, die keinen Balancing-Modus verwenden, gelten auch hier.

Nächste Schritte

• Eine Einrichtungsanleitung finden Sie unter Erweitertes Load-Balancing einrichten.