Bekannte Probleme bei Netzwerk-Load-Balancern

Bekannte Probleme sind identifizierte Fehler oder unerwartete Verhaltensweisen, die vor der Veröffentlichung nicht behoben wurden, aber nicht kritisch genug waren, um die Veröffentlichung zu verzögern. Diese Probleme werden Ihnen mitgeteilt, oft mit Workarounds, und werden vom Entwicklungsteam mit Priorität für eine kurzfristige Lösung behandelt.

Die folgenden Abschnitte enthalten bekannte Probleme für öffentliche, private und Private Path Network Load Balancer (NLBs).

Bekannte Probleme bei Load Balancern für private und öffentliche Netzwerke

  • Bei einer NLB muss jede Kombination aus Mitglied und Port eindeutig sein.

  • Der Port einer virtuellen Serverinstanz eines NLB-Members kann nur für NLB-Datenverkehr verwendet werden.

  • Jeder Hörer ist einem einzigen Pool zugeordnet (Eins-zu-Eins-Beziehung).

  • Ein NLB nutzt die primären Netzwerkschnittstellen seiner angeschlossenen Mitglieder für den Datenverkehr. Nicht-primäre Netzwerkschnittstellen werden nicht unterstützt.

  • Um die Verfügbarkeit zu verbessern, verwenden Sie ein dediziertes Subnetz für NLBs. Platzieren Sie Clients und Mitglieder wenn möglich in getrennten Subnetzen.

  • Für eine NLB dürfen nicht zwei Mitglieder mit derselben Instanz X und demselben Port Y gleichzeitig vorhanden sein. So werden z. B. zwei Mitglieder, die denselben Server-Port auf derselben Instanz verwenden, nicht unterstützt, und die Weiterleitung des Datenverkehrs kann fehlschlagen. Weitere Informationen finden Sie unter Warum kann ich keine Mitglieder mit demselben Serverport zu meinem NLB hinzufügen?

  • Für eine NLB mit aktiviertem Routing-Modus:

    • Als Backend-Ziele werden nur Virtual Network Function (VNF)-Instanzen unterstützt. Wenn Sie APIs verwenden, setzen Sie port_min auf 1 und port_max auf 65535; lassen Sie port leer.
    • Es wird nur ein Listener unterstützt.
    • Die NLB und die VNF-Back-End-Ziele müssen sich in demselben Teilnetz befinden.

  • Für Kontingente und Service-Limits siehe Kontingente und Service-Limits für Network Load Balancer. Um eine Erhöhung zu beantragen, erstellen Sie einen Support-Fall.

  • Wenn Sie einen Listener für einen NLB erstellen, können Sie eine protocol von tcp oder udp angeben. Allerdings muss jeder Listener im NLB eine eindeutige port verwenden.

  • Privater NLB- Der NLB-Dienst fügt möglicherweise Regeln zu benutzerdefinierten Routing-Tabellen hinzu, um die Verfügbarkeit des Dienstes unter bestimmten Ausfallbedingungen sicherzustellen. Befindet sich der Client daher außerhalb der Zone und/oder der VPC des NLB, müssen Sie in der VPC, in der der NLB gehostet wird, eine benutzerdefinierte Ingress-Routing-Tabelle mit der entsprechenden Datenverkehrsquelle konfigurieren.

  • Private NLB Die erforderliche Ingress-Routing-Tabelle hängt vom Standort des Clients ab:

    Verkehrsquellen, die benutzerdefinierte Routingtabellen erfordern.
    Standort des Clients Typ von Routing-Tabelle Quelle des Datenverkehrs
    Lokaler Ingress Direct Link
    Eine andere VPC oder klassische Infrastruktur Ingress Transit Gateway
    Eine andere Verfügbarkeitszone derselben VPC Ingress VPC-Zone

    Weitere Informationen finden Sie unter Informationen zu Routing-Tabellen und Routen.

  • Sie können maximal 128 direkte Server-Rückkehrkonfigurationen für jede virtuelle Serverinstanz eines Backend-Mitglieds haben.

  • Wenn eine Mitglied-Zielinstanz gelöscht wird, wird das entsprechende NLB-Poolmitglied nicht automatisch entfernt.

Bekannte Probleme bei Private Path Network Load Balancern

  • Wenn Sie einen ALB als Private Path NLB-Mitglied konfigurieren, zeigt der NLB TCP Health Check-Status immer OK an, selbst wenn ALB-Pool-Mitglieder ungesund sind.

  • Private Path NLB-Pool-Mitglieder müssen virtuelle VPC-Serverinstanzen oder reservierte IPs in derselben VPC wie der Load Balancer sein. Um Mitglieder außerhalb des VPC zu erreichen (z. B. Mitglieder vor Ort), können Sie einen ALB als Mitglied des Private Path NLB-Pools konfigurieren und die entfernten Ziele als ALB-Mitglieder definieren. Weitere Informationen finden Sie unter Verbinden eines lokalen Dienstes mit einem Verbraucher unter Verwendung eines ALB in einem Private Path NLB-Pool.

  • Der Zugriff auf einen Private Path NLB aus einer anderen Region wird nicht unterstützt. Das Verbraucher-VPE-Gateway und die NLB-Instanz für den privaten Pfad müssen sich in derselben Region befinden.

    Umgehung: Erstellen Sie ein Transit-Gateway, um den Verbraucher-VPC in der entfernten Region mit dem VPC zu verbinden, der das Private Path VPE hostet. Greifen Sie dann über diesen VPE auf den Dienst zu. Wenn Sie Hilfe bei der Konfiguration benötigen, wenden Sie sich bitte an den IBM-Support.

  • Der Zugriff auf Private Path NLBs von Classic Infrastructure aus wird nicht unterstützt.

    Umgehung: Erstellen Sie ein Transit-Gateway von der klassischen Umgebung zu der VPC, die das Private Path VPE hostet. Greifen Sie dann über diesen VPE auf den Dienst zu.

  • Die Zugriffskontrolle für den Load Balancer wird über einen Private Path Service verwaltet. Sicherheitsgruppen und Netzwerkzugangskontrolllisten (NACLs) werden nicht unterstützt.

  • UDP der Datenverkehr wird vom Load Balancer-Datenpfad nicht unterstützt.

  • Die Integration des Autoscalers wird nicht unterstützt.

  • Die maximale MTU für Private Path NLB-Verkehr beträgt 8500.

  • Informationen zu Kontingenten und Service-Limits finden Sie unter Kontingente und Service-Limits für Private Path Network Load Balancers. Um eine Erhöhung zu beantragen, erstellen Sie einen Support-Fall.

  • Beim Erstellen eines „Private Path NLB“ tritt ein bekanntes Problem auf, bei dem die Felder für die Anfrage und die Antwort des Zustandsmonitors nicht in der GET-API-Antwort zurückgegeben werden.