Equilibrador de carga de tipo público a privado

Se asigna un nombre de dominio totalmente calificado y de acceso público a la instancia de servicio del equilibrador de carga. Utilice este nombre de dominio para acceder a sus aplicaciones alojadas detrás del servicio de balanceador de carga. Se puede registrar este nombre de dominio con una o varias direcciones IP públicas. Las direcciones IP públicas y el número de direcciones IP públicas puede cambiar con el tiempo, en función de las actividades de mantenimiento y escalado, que son transparentes para los usuarios. Las instancias de computación back-end que alojen su aplicación deben estar en una red IBM Cloud Private.

Se recomienda, como buena práctica, que se suministren los servidores de fondo solo para private-only a menos que necesiten conectividad pública directa. Esta práctica mejora la seguridad y protege su dirección IP pública. Las aplicaciones alojadas en estos servidores de fondo siguen siendo accesibles a través de las redes públicas mediante el uso del equilibrador de carga.

Hay dos formas de asignar direcciones IP públicas al equilibrador de carga:

• Asignar desde la reserva del sistema IBM: El método por defecto. Este método asigna direcciones IP desde la agrupación de sistemas de IBM.

• Asignar desde una subred pública en esta cuenta: este método asigna direcciones IP desde una subred pública desde la cuenta. De forma predeterminada, la selección de subred es automática. Si utiliza la API, puede seleccionar una subred determinada pasando el ID de subred pública al realizar el pedido.

Equilibrador de carga de tipo privado a privado

El equilibrador de carga interno sólo es accesible dentro de la red privada de IBM Cloud.

Al igual que un equilibrador de carga de tipo público a privado, también se asigna un nombre de dominio completo a la instancia de servicio del equilibrador de carga interno. Sin embargo, este nombre de dominio se registra con una o varias direcciones IP privadas.

Al igual que en un equilibrador de carga público, las direcciones IP privadas y sus números pueden cambiar con el tiempo en función de las actividades de mantenimiento y escalado, que son transparentes para los usuarios.

Las instancias de cálculo de fondo que alojan la aplicación también deben estar en la red privada de IBM Cloud.

Equilibrador de carga de tipo público a público

El equilibrador de carga público a público resulta accesible de forma pública.

Al igual que los otros tipos de equilibradores de carga, también se asigna un nombre de dominio completo a la instancia del servicio equilibrador de carga público a público. Se puede registrar este nombre de dominio con una o varias direcciones IP públicas.

Una vez aprovisionado el equilibrador de carga, sólo son visibles las direcciones IP públicas de los miembros en el contexto de tablas de servidores. Esto es aplicable a los miembros del equilibrador de carga tanto de capa 4 como de capa 7.

Las direcciones IP públicas y sus números pueden cambiar con el tiempo en función de las actividades de mantenimiento y escalado, que son transparentes para los usuarios.

Las instancias de cálculo de fondo que alojan la aplicación deben estar en la red pública de IBM Cloud.

Puertos/Protocolos de aplicaciones frontales y de fondo

Puede definir hasta 10 puertos (protocolos) de aplicación frontal y asignarlos a sus puertos (protocolos) respectivos en los servidores de aplicaciones de fondo. El nombre de dominio totalmente calificado que se asigna a la instancia de servicio del equilibrador de carga y los puertos de la aplicación frontal están expuestos al mundo exterior. Las solicitudes de usuario entrantes se reciben en estos puertos.

Los puertos del back-end sólo se conocen internamente. Estos puertos de fondo pueden o no ser los mismos que los puertos frontales. Por ejemplo, el equilibrador de carga se puede configurar para recibir tráfico web/HTTP entrante en el puerto 80 frontal mientras los servidores de fondo escuchan en el puerto personalizado 81.

Los protocolos/puertos frontales soportados son HTTP, HTTPS y TCP. Los protocolos/puertos de fondo admitidos son HTTP, HTTPS y TCP. El tráfico HTTPS entrante debe finalizar en equilibrador de carga para permitir la comunicación HTTP de texto sin formato con el servidor de fondo. Si el protocolo de fondo es HTTPS, se cifrará el tráfico entre el equilibrador de carga y los servidores de fondo.

Métodos de equilibrio de carga

Los siguientes tres métodos de equilibrio de carga están disponibles para distribuir el tráfico entre los servidores de aplicaciones de fondo:

• Round Robin: Round Robin es el método de equilibrio de carga predeterminado. Con este método, el equilibrador de carga reenvía las conexiones entrantes del cliente de forma rotativa a los servidores de fondo. En consecuencia, todos los servidores de fondo reciben aproximadamente el mismo número de conexiones de cliente.

• Round robin ponderado: con este método, el equilibrador de carga reenvía las conexiones de cliente entrantes a los servidores de fondo en proporción al peso asignado a estos servidores. Cada servidor tiene asignado un peso predeterminado de 50, valor que se puede personalizar en un rango del 0 al 100.

  A modo de ejemplo, si hay tres servidores de aplicaciones A, B y C y se personalizan sus pesos en 60, 60 y 30 respectivamente, los servidores A y B reciben un número igual de conexiones, mientras que el servidor C recibe la mitad.

  Si se restablece el peso de un servidor en 0, dejan de reenviarse conexiones nuevas al servidor en cuestión, pero el tráfico existente sigue fluyendo mientras esté activo. La utilización de una ponderación de 0 puede ayudar a desactivar un servidor y eliminarlo de la rotación de servicio.

  Los valores de ponderación de servidor solo se aplican cuando se utiliza el método round robin ponderado. Los valores de peso del servidor se ignoran con los métodos round-robin y least connection load-balancing.

• Menos conexiones: con este método, la instancia de servidor que sirve el menor número de conexiones en un momento dado recibe la siguiente conexión de cliente.

Escalado horizontal

El equilibrador de carga ajusta su capacidad automáticamente en función de la carga. Cuando se produce este ajuste, puede notar un cambio en el número de direcciones IP asociadas al nombre DNS del equilibrador de carga.

Requisitos de las regiones multizona

Una región multizona (MZR) garantiza una alta disponibilidad desplegando sus dispositivos equilibradores de carga en varios centros de datos. Cuando se crea un equilibrador de carga, se selecciona la subred para el despliegue. Si el centro de datos forma parte de un MZR, un dispositivo se despliega en el centro de datos seleccionado y el otro se despliega en un centro de datos diferente dentro de la misma región.

Por ejemplo, Dallas (us-south) es un MZR que contiene los centros de datos dal10, dal12, y dal13. La subred A está en dal10, las subredes B y C en dal12, y las subredes D y E en dal13. Si crea un equilibrador de carga en el centro de datos dal13, el primer dispositivo se despliega en dal13 y el segundo en la subred con más IPs disponibles entre los centros de datos dal10 o dal12.

Actualmente, el servicio Cloud Load Balancer servicio está disponible en los centros de datos que figuran en Infraestructura clásica.

Las MZR tienen los requisitos siguientes:

• El centro de datos seleccionado debe formar parte de un MZR.
• Su cuenta debe tener habilitada expansión de VLAN o bien VRF.
• Las subredes privadas deben existir en su cuenta en los centros de datos de la MZR. Si se crean dispositivos de cálculo en centros de datos, se crean instancias de subredes privadas.

Si el centro de datos seleccionado no forma parte de un MZR, o si VLAN spanning o VRF no están activados en su cuenta, el equilibrador de carga se creará con todos los nodos instanciados en el centro de datos especificado, siguiendo el comportamiento de despliegue original.

Para obtener más información sobre las regiones multizona, consulte IBM Cloud ubicaciones de regiones y centros de datos para el despliegue de recursos. Para más información sobre la correspondencia entre regiones y zonas, véase Correspondencia de zonas por cuenta.