Problèmes connus pour les équilibreurs de charge réseau

Les problèmes connus sont des bogues identifiés ou des comportements inattendus qui n'ont pas été corrigés avant la publication, mais qui n'étaient pas suffisamment critiques pour la retarder. Ces problèmes vous sont communiqués, souvent avec des solutions de contournement, et sont traités en priorité par l'équipe de développement pour être résolus à court terme.

Les sections suivantes présentent les problèmes connus pour les équilibreurs de charge réseau (NLB) publics, privés et Private Path.

Problèmes connus pour les équilibreurs de charge des réseaux privés et publics

  • Un NLB exige que chaque combinaison « membre-port » soit unique.

  • Le port d'une instance de serveur virtuel de membre NLB peut être utilisé uniquement pour le trafic NLB.

  • Chaque auditeur est associé à un seul pool (relation univoque).

  • Un NLB utilise les interfaces réseau principales de ses membres associés pour le trafic de données. Les interfaces réseau non principales ne sont pas prises en charge.

  • Pour améliorer la disponibilité, utilisez un sous-réseau dédié pour les NLB. Dans la mesure du possible, placez les clients et les membres dans des sous-réseaux distincts.

  • Il ne peut pas exister simultanément deux membres dont l'instance X et le port Y sont identiques pour un équilibreur de charge d'application. Par exemple, deux membres utilisant le même port de serveur sur la même instance ne sont pas pris en charge et l'acheminement du trafic risque d'échouer. Pour plus d'informations, voir Pourquoi ne puis-je pas ajouter des membres ayant le même port de serveur à mon NLB?

  • Pour un NLB avec le mode de routage activé :

    • Seules les instances de fonctions de réseau virtuel (VNF) sont prises en charge en tant que cibles back-end. Lorsque vous utilisez des API, définissez port_min comme 1 et port_max comme 65535; laissez port vide.
    • Un seul programme d'écoute est pris en charge.
    • Les cibles back-end NLB et VNF doivent se trouver dans le même sous-réseau.

  • Pour les quotas et les limites de service, consultez Quotas et limites de service pour les équilibreurs de charge réseau. Pour demander une augmentation, créez un dossier d'assistance.

  • Lorsque vous créez un listener pour un NLB, vous pouvez spécifier un protocol de tcp ou udp. Cependant, chaque listener dans le NLB doit utiliser un port unique.

  • [NLB privée] : le service NLB peut ajouter des règles aux tables de routage personnalisées afin de garantir la disponibilité du service dans certaines situations de défaillance. Par conséquent, si le client se trouve en dehors de la zone et/ou du VPC du NLB, vous devez configurer une table de routage d'entrée personnalisée dans le VPC qui héberge le NLB, en indiquant la source de trafic appropriée.

  • Private NLB La table de routage d'entrée requise dépend de l'emplacement du client :

    Sources de trafic qui nécessitent des tables de routage personnalisées d'entrée.
    Site client Type de table de routage Source de trafic
    Port Ingress Direct Link
    Autre VPC ou infrastructure classique Ingress Transit Gateway
    Autre zone de disponibilité du même VPC Ingress Zone du VPC

    Pour plus d'informations, voir A propos des tables de routage et des routes.

  • Vous pouvez avoir un maximum de 128 configurations de retour direct au serveur pour chaque instance de serveur virtuel membre back-end.

  • Lorsqu'une instance cible membre est supprimée, le membre du pool NLB correspondant n'est pas automatiquement supprimé.

Problèmes connus pour les équilibreurs de charge du réseau Private Path

  • Lorsque vous configurez un ALB en tant que membre Private Path NLB, l'état du contrôle de santé NLB TCP indique toujours OK, même si les membres du pool ALB ne sont pas en bonne santé.

  • Les membres du pool NLB Private Path doivent être des instances de serveurs virtuels VPC ou des IP réservées dans le même VPC que l'équilibreur de charge. Pour atteindre des membres en dehors du VPC (par exemple, des membres sur site), vous pouvez configurer un ALB en tant que membre du pool NLB Private Path et définir les destinations distantes en tant que membres de l'ALB. Pour plus d'informations, voir Connexion d'un service sur site à un consommateur à l'aide d'un ALB dans un pool NLB à chemin privé.

  • L'accès à un chemin privé NLB à partir d'une région différente n'est pas pris en charge. La passerelle VPE du consommateur et l'instance NLB du chemin privé doivent se trouver dans la même région.

    Solution de contournement : Créez une passerelle de transit pour connecter le VPC consommateur dans la région distante au VPC qui héberge le Private Path VPE. Accédez ensuite au service par l'intermédiaire de cet EPV. Pour obtenir de l'aide concernant la configuration, veuillez contacter le service d'assistance d' IBM.

  • L'accès aux NLB Private Path à partir de l'infrastructure classique n'est pas pris en charge.

    Solution : Créez une passerelle de transit entre l'environnement classique et le VPC qui héberge le VPE Private Path. Accédez ensuite au service par l'intermédiaire de cet EPV.

  • Le contrôle d'accès à l'équilibreur de charge est géré par un service Private Path. Les groupes de sécurité et les listes de contrôle d'accès au réseau (NACL) ne sont pas pris en charge.

  • UDP n'est pas pris en charge par le chemin de données de l'équilibreur de charge.

  • L'intégration du programme de mise à l'échelle automatique n'est pas prise en charge.

  • La MTU maximale pour le trafic NLB de chemin privé est 8500.

  • Pour les quotas et les limites de service, consultez Quotas et limites de service pour les équilibreurs de charge réseau Private Path. Pour demander une augmentation, créez un dossier d'assistance.

  • Lors de la création d'un NLB « Private Path », un problème connu fait que les champs de requête et de réponse du moniteur d'intégrité ne sont pas renvoyés dans la réponse de l'API GET.