Erweitertes Load Balancing

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.

Erweitertes Load-Balancing besteht aus Funktionen, mit denen Sie das globale Load-Balancing und die Trafficverteilung optimieren können, um Ihre Ziele hinsichtlich Verfügbarkeit, Leistung und Kosteneffizienz optimal zu erreichen. Dieses Dokument richtet sich an Nutzer, die mindestens ein mittleres Verständnis der Cloud Service Mesh- und Load-Balancing-Konzepte haben.

Hinweis: In dieser Anleitung werden nur Cloud Service Mesh mit Google Cloud APIs und keine Istio APIs unterstützt. Weitere Informationen finden Sie in der Übersicht zu Cloud Service Mesh.

Zur Implementierung des erweiterten Load-Balancings erstellen Sie eine Richtlinie für das Dienst-Load-Balancing (serviceLbPolicies-Ressource), die Werte enthält, die die Auswahl eines Back-Ends beeinflussen. Anschließend hängen Sie die Load-Balancing-Richtlinie des Dienstes an einen Back-End-Dienst an. Die Load-Balancing-Richtlinie des Dienstes gibt den Algorithmus an, mit dem bestimmt wird, wie der Traffic zu den Back-Ends ausgeglichen wird.

Sie können aus den folgenden Algorithmusoptionen für erweitertes Load-Balancing wählen:

• Abfolge nach Region (Standardalgorithmus).
• In die Region spritzen.
• Spritzt in die Welt.
• Wasserfall nach Zone.

Die folgenden zusätzlichen Optionen sind verfügbar:

• Bevorzugte Back-Ends festlegen Cloud Service Mesh sendet Traffic an diese MIGs oder NEGs, bevor er an andere Back-Ends gesendet wird.
• 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 von Traffic und Load-Balancing durch Cloud Service Mesh

Das folgende Diagramm zeigt, wie Cloud Service Mesh entscheidet, Traffic weiterzuleiten.

Wie Cloud Service Mesh Load-Balancing-Entscheidungen trifft (zum Vergrößern klicken)

Zuerst wählt Cloud Service Mesh basierend auf den Anfrageeigenschaften und den Routingregeln in der Route-Ressource oder der URL-Zuordnung einen Back-End-Dienst aus, je nachdem, welche API in Ihrer Bereitstellung verwendet wird.

Zweitens wählt Cloud Service Mesh eine Back-End-MIG oder -NEG aus, die dem Back-End-Dienst zugeordnet ist. Diese Auswahl basiert auf dem Standort des Clients, dem Standort, dem Zustand und der Kapazität der MIG oder NEG sowie auf Informationen in der mit dem Back-End-Dienst verknüpften Dienst-Load-Balancing-Richtlinie.

Schließlich wählt Cloud Service Mesh 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 welcher für Ihre speziellen Geschäftsanforderungen ausgewählt werden sollte.

Traffic zwischen Back-Ends in einer Region ausgleichen

Der standardmäßige Load-Balancing-Algorithmus verteilt nach Region den Traffic gleichmäßig auf alle MIGs oder NEGs in Zonen in einer Region. Wir empfehlen, den Standardalgorithmus zu verwenden, sofern keine besonderen Anforderungen vorhanden sind.

Bei der Vermittlungsabfolge nach Region empfangen Back-Ends Traffic im Verhältnis zu ihrer Kapazität, was einen Back-End-Überlastungsschutz bietet. Traffic wird bei Bedarf über Zonengrenzen hinweg gesendet, um die Back-Ends gleichmäßig innerhalb der Region zu laden. Auch wenn die lokale Zone des Clients noch Kapazität hat, besteht zonenübergreifender Traffic. Die Anfragen eines jeden Clients können auf mehrere zonale MIGs oder NEGs in der Region verteilt werden, was dazu beiträgt, die Last auf den MIGs oder NEGs gleichmäßig zu halten, wenn die Trafficlast von den Clients nicht gleichmäßig ist.

Erhöhen Sie die Ausfallsicherheit, indem Sie Traffic von einem Client auf mehrere Zonen verteilen

Der Standardalgorithmus des Wasserfalls nach Region versucht, die Kapazitätsnutzung über mehrere zonale MIGs oder NEGs hinweg auszugleichen. Unter diesem Algorithmus werden Anfragen, die von einem einzelnen Client stammen, 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-zu-Region-Algorithmus, wenn Clients ihre Anfragen auf alle MIGs oder NEGs in einer Region verteilen sollen. Dadurch wird das Risiko einer Überlastung von MIGs oder NEGs in einer einzelnen Zone verringert, wenn das Traffic-Volumen schnell lokal ansteigt.

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

Wenn Sie den Spray-zu-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 dauerhaft 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 vom Cloud Service Mesh führen, wenn zwei Cloud Service Mesh-Clients Traffic an dieselben Zonen senden.

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

Wie in den vorherigen Abschnitten erläutert, verteilt der Spray-zu-Region-Algorithmus den Traffic von jedem Client auf alle Zonen in einer Region. Bei Diensten mit MIGs oder NEGs in mehreren Regionen optimiert Cloud Service Mesh trotzdem die Gesamtlatenz, indem 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 an alle MIGs oder NEGs weltweit über mehrere Regionen.

Beachten Sie, dass bei diesem Algorithmus der gesamte Traffic global auf alle Back-Ends verteilt wird. Eine fehlerhafte Abfrage kann alle Back-Ends in Ihren Bereitstellungen beschädigen. Der Algorithmus führt außerdem zu mehr regionsübergreifendem Traffic, was die Anfragelatenz erhöhen und zusätzliche Kosten verursachen kann.

Zonenübergreifenden Traffic minimieren

Mit der Einstellung „Wasserfall nach Zone“ können Sie die Gesamtlatenz optimieren und den zonenübergreifenden Traffic reduzieren. Wenn mehrere MIGs oder NEGs in einer Zone 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, bis die gesamte MIG- oder NEG-Kapazität in der Zone aufgebraucht ist. Erst dann wird der Traffic in die nächstgelegene Zone weitergeleitet.

Mit diesem Algorithmus können Sie unnötigen zonenübergreifenden Traffic minimieren. Die Gesamtlatenz kann leicht verbessert werden, da die nächstgelegenen lokalen Back-Ends bevorzugt werden. Dies kann jedoch auch zu ungleichmäßigen 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 des Cloud Service Mesh.

Verhalten	Wasserfall nach Region	In eine Region sprühen	Sprüh zur Welt	Wasserfall nach Zone
Einheitliche Kapazitätsnutzung innerhalb einer Region im stabilen Zustand	Yes	Yes	Yes	Nein
Einheitliche Kapazitätsnutzung über mehrere Regionen im stabilen Zustand	Nein	Nein	Yes	Nein
Einheitliche Trafficaufteilung innerhalb einer Region im stabilen Zustand	Nein	Yes	Yes	Nein
Zonenübergreifender Traffic	Ja. Dieser Algorithmus verteilt den Traffic gleichmäßig auf die Zonen in einer Region und optimiert gleichzeitig die Netzwerklatenz. Traffic kann bei Bedarf zonenübergreifend gesendet werden.	Yes	Yes	Ja, der Verkehr füllt die nächstgelegene Zone voll aus. Dann geht es in die nächste Zone.
Empfindlichkeit gegenüber Traffic-Spitzen in lokalen Zonen	Durchschnitt: je nachdem, wie viel Traffic bereits verschoben wurde, um die Zonen auszugleichen.	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 einer einzelnen Zone eher von einer einzigen Zone bedient werden, bis Cloud Service Mesh reagieren kann.

Zusätzliche erweiterte Load-Balancing-Optionen

In den folgenden Abschnitten werden Optionen zum Ändern des Cloud Service Mesh-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. Cloud Service Mesh 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 ein Überlauf zu Google Cloud, wo Sie lokale Compute-Ressourcen angeben, die durch eine Hybridkonnektivitäts-NEG dargestellt werden, die vollständig verwendet werden, bevor Anfragen an automatisch skalierte Google Cloud-Back-End-MIGs oder -NEGs weitergeleitet werden. Mit dieser Konfiguration können Sie den Rechenverbrauch von Google Cloud minimieren und dennoch die Ausfallsicherheit bieten, um bei Bedarf schrittweise ein Failover auf Google Cloud durchzuführen.

Automatischer Kapazitätsausgleich

Wenn ein Back-End fehlerhaft ist, ist es in der Regel wünschenswert, es so schnell wie möglich von Load-Balancing-Entscheidungen auszuschließen. Der Ausschluss des Back-Ends verhindert, dass Anfragen an das fehlerhafte Back-End gesendet werden. Darüber hinaus wird der Traffic zwischen fehlerfreien Back-Ends verteilt, um eine Überlastung des Back-Ends zu vermeiden und die Gesamtlatenz zu optimieren.

Diese Option ähnelt dem Setzen von capacityscalar auf null. Cloud Service Mesh bittet Cloud Service Mesh, die Back-End-Kapazität automatisch auf null herunterzuskalieren, wenn weniger als 25% der einzelnen Instanzen oder Endpunkte eines Back-Ends 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 sind, werden sie zurückgesetzt, wenn mindestens 35% der Endpunkte oder Instanzen 60 Sekunden lang fehlerfrei sind. Cloud Service Mesh entleert unabhängig vom Systemstatus des Back-Ends nicht mehr als 50% der Endpunkte in einem Back-End-Dienst.

Ein Anwendungsfall besteht darin, 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 weg verschoben wird.

Failover-Verhalten anpassen

Cloud Service Mesh sendet in der Regel Traffic an Back-Ends. Dabei werden mehrere Faktoren berücksichtigt. In einem stabilen Zustand sendet Cloud Service Mesh 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ätsnutzung als optimal. Sie werden als primäre Back-Ends bezeichnet.

Cloud Service Mesh verfolgt auch die Back-Ends, die verwendet werden sollen, wenn die primären Back-Ends fehlerhaft sind und keinen Traffic empfangen können. Diese Back-Ends werden als Failover-Back-Ends bezeichnet. In der Regel sind sie Back-Ends in der Nähe, die noch Kapazität haben.

Wenn ein Back-End fehlerhaft ist, versucht Cloud Service Mesh, das Senden von Traffic an das Back-End zu vermeiden, und leitet den Traffic stattdessen auf fehlerfreie Back-Ends weiter.

Die Ressource serviceLbPolicy enthält das Feld failoverHealthThreshold, dessen Wert zur Steuerung des Failover-Verhaltens angepasst werden kann. Der von Ihnen festgelegte Schwellenwert 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 Cloud Service Mesh den Traffic nicht unbedingt sofort. Stattdessen könnte Cloud Service Mesh den Traffic an fehlerfreie Endpunkte im primären Back-End verschieben, um den Traffic zu stabilisieren.

Wenn zu viele Endpunkte im Back-End fehlerhaft sind, können die verbleibenden Endpunkte den zusätzlichen Traffic nicht verarbeiten. In diesem Fall wird anhand des Fehlerschwellenwerts entschieden, ob ein Failover ausgelöst wird oder nicht. Cloud Service Mesh toleriert Unregelmäßigkeiten bis zum Schwellenwert und verschiebt dann einen Teil des Traffics von den primären Back-Ends zu den Failover-Back-Ends.

Der Schwellenwert für den Failover-Zustand ist ein Prozentwert. Der von Ihnen festgelegte Wert bestimmt, wann Cloud Service Mesh Traffic an die Failover-Back-Ends weiterleitet. Sie können den Wert auf eine Ganzzahl zwischen 1 und 99 festlegen. Der Standardwert für Cloud Service Mesh ist 70 mit Envoy und 50 für proxylose gRPC-Anwendungen. Ein höherer Wert startet den Traffic-Failover früher als ein kleinerer Wert.

Fehlerbehebung

Die Trafficverteilungsmuster können sich abhängig davon ändern, 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 Cloud Service Mesh- 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 Cloud Service Mesh, Traffic zuzuweisen, damit Back-Ends unter ihrer konfigurierten Kapazität ausgeführt werden. Beachten Sie, dass dies nicht garantiert werden kann. Weitere Informationen finden Sie in der Dokumentation für den Back-End-Dienst.

Dann wird der Traffic basierend auf dem von Ihnen verwendeten Algorithmus zugewiesen. Mit dem Algorithmus WATERFALL_BY_ZONE versucht Cloud Service Mesh beispielsweise, den Traffic in der nächstgelegenen Zone zu halten. Wenn Sie die Netzwerkmesswerte prüfen, stellen Sie fest, dass Cloud Service Mesh 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 gesendet, bevor sie näher aneinander liegen

Dies ist das beabsichtigte Verhalten, wenn bevorzugte Back-Ends mit weiter entfernten MIGs oder NEGs konfiguriert sind. Wenn Sie dies nicht wünschen, ändern Sie die Werte im Feld für bevorzugte Back-Ends.

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

Dies ist das beabsichtigte Verhalten, wenn die MIGs oder NEGs per Drain beendet werden, da eine 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. Dies bedeutet jedoch, dass Traffic an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet wird, sodass die Anfragen mit Fehlern fehlschlagen können.

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

Dies ist das vorgesehene 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 wurde, wird der Traffic nicht an andere MIGs oder NEGs gesendet. Die bevorzugten MIGs oder NEGs werden basierend auf der RTT-Latenz zu diesen Back-Ends zuerst zugewiesen.

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

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

Dies ist das vorgesehene Verhalten, wenn „Spray-to-Region“ oder „Spray-to-World“ verwendet wird. Es können jedoch Probleme mit einer breiteren Verteilung des Traffics auftreten. Cache-Trefferraten können beispielsweise sinken, wenn Back-Ends Traffic von einer größeren Auswahl von Clients erkennen. Erwägen Sie in diesem Fall die Verwendung anderer Algorithmen, z. B. der Wasserfall-Methode 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 Integritätsänderungen auf den primären Back-Ends bleiben soll, setzen Sie failoverHealthThreshold auf einen niedrigeren Wert.

Fehlerfreie Endpunkte werden ü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 möglicherweise auf die verbleibenden Endpunkte in derselben MIG oder NEG verteilt. Wenn das Failover-Verhalten vorzeitig ausgelöst werden soll, legen Sie für failoverHealthThreshold einen höheren Wert fest.

Einschränkungen und Überlegungen

Bei der Konfiguration des erweiterten Load-Balancings sollten Sie die folgenden Einschränkungen und Überlegungen berücksichtigen.

Wasserfall-nach-Zone

• Während transparenter Wartungsereignisse ist es möglich, dass der Traffic vorübergehend außerhalb der lokalen Zone 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 die Endpunkte befindet, sinkt der zonenübergreifende Traffic.

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

Spray-zu-Region

• Wenn die Endpunkte in einer MIG oder einer NEG ausfallen, erstrecken sich die Auswirkungen in der Regel auf eine größere Gruppe von Clients. Mit anderen Worten: Eine größere Anzahl von Mesh-Clients kann betroffen sein, wenn auch weniger stark.

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

• Die Anzahl der für Endpunkte geöffneten Verbindungen kann zunehmen, was zu einer erhöhten Ressourcennutzung führt.

Bevorzugte Back-Ends

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

• Globale Load-Balancing-Algorithmen (Wasserfall nach Region, Spray-zu-Region, Wasserfall nach 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 werden, unterscheidet sich von dem Wert, der bei der Konfiguration mit serviceLbPolicies festgelegt wurde.

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

• Wenn serviceLbPolicies festgelegt ist, beträgt der Mindestprozentsatz der MIGs oder NEGs, die niemals per Drain beendet 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 Draining-Vorgang rückgängig machen kann, müssen mindestens 35% der Instanzen oder Endpunkte fehlerfrei sein. Dies ist erforderlich, um dafür zu sorgen, dass eine MIG oder NEG nicht zwischen dem Drain- und dem Abfallzustand wechselt.

• Die gleichen 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.