Equilibrador de carga de aplicación público

A una instancia pública de equilibrador de carga de aplicaciones se le asigna un nombre de dominio completo (FQDN) de acceso público, que debe utilizar para acceder a sus aplicaciones alojadas detrás del equilibrador de carga. Se puede registrar este nombre de dominio con una o varias direcciones IP públicas.

Con el tiempo, el número y el valor de estas direcciones IP públicas pueden cambiar debido a las actividades de mantenimiento y escalado. Las instancias de servidor virtual de back-end que alojan su aplicación deben ejecutarse en la misma región y dentro de la misma VPC.

Utilice el FQDN asignado para enviar el tráfico al equilibrador de carga de aplicación público para evitar problemas de conectividad en las aplicaciones durante el mantenimiento del sistema o en las actividades de escalado.

Equilibrador de carga de aplicación privado

Se puede acceder a un equilibrador de carga de aplicación privado a través de las subredes privadas que ha configurado para crear el equilibrador de carga.

De forma similar a un equilibrador de carga de aplicaciones público, se asigna un FDQN a su instancia de equilibrador de carga de aplicaciones privado. Sin embargo, este nombre de dominio se registra con una o varias direcciones IP privadas.

Las operaciones de IBM Cloud pueden cambiar el número y el valor de las direcciones IP privadas asignadas a lo largo del tiempo, en función de las actividades de mantenimiento y de escalado. Las instancias de servidor virtual de back-end que alojan su aplicación deben ejecutarse en la misma región y dentro de la misma VPC.

Utilice el FQDN asignado para enviar el tráfico al equilibrador de carga de aplicación privado para evitar problemas de conectividad en las aplicaciones durante el mantenimiento del sistema o en las actividades de escalado.

Round-robin

Round-robin es el método de equilibrio de carga predeterminado. Con este método, el equilibrador de carga de aplicación 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, un equilibrador de carga de aplicaciones reenvía las conexiones entrantes de los clientes a los servidores de back-end en proporción al peso que se ha asignado a dichos servidores. Se asigna un peso 50 predeterminado de a cada servidor. El peso se puede personalizar a cualquier valor dentro del rango 0- 100.

Por ejemplo, si los servidores de aplicaciones A, B y C tienen las ponderaciones 60, 60 y 30, los servidores A y B reciben un número igual de conexiones, mientras que el servidor C recibe la mitad de ese número de conexiones.

Si se establece la ponderación en 0, significa que no se reenvían nuevas conexiones a dicho servidor, pero el tráfico existente sigue fluyendo. 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'. Se pasan por alto con los métodos de equilibrio de carga round-robin y menos conexiones.

Conexiones mínimas

Con este método, la instancia del servidor back-end que atiende el menor número de conexiones en un momento determinado recibe la siguiente conexión de cliente.

Directrices para utilizar escuchas

Revise las directrices siguientes para escuchas frontales:

• Puede definir hasta 10 escuchas de front-end y asignarlas a grupos de back-end en sus servidores de aplicaciones de back-end.
• El FQDN asignado al equilibrador de carga y los puertos de escucha frontales están expuestos a Internet público. Las solicitudes de usuario entrantes se reciben en dichos puertos.
• Los protocolos admitidos de escucha de componente frontal y agrupación de fondo son HTTP, HTTPS y TCP.
• Puede configurar un escucha frontal HTTP/HTTPS con una agrupación de fondo HTTP/HTTPS.
• HTTP/2 Solo es compatible con los oyentes.
• Los escuchas y las agrupaciones HTTP y HTTPS son intercambiables.
• Solo se puede configurar un listener de front-end de TCP con un grupo de back-end de TCP.
• Puede conectar hasta 50 instancias de servidor virtual a una agrupación de fondo. El tráfico se envía a cada instancia en su puerto de datos especificado. Este puerto de datos no tiene que ser el mismo que el puerto del escucha de componente frontal.
• Los puntos finales solo privados de Secrets Manager no son compatibles con los oyentes de HTTPS. Para configurar un escucha HTTPS en un ALB, hay que subir los certificados TLS a un punto final "público y privado".

Escucha de redirección HTTPS

Los escuchas de redirección HTTPS redirigen el tráfico de un escucha HTTP a un escucha HTTPS. Esta acción no requiere que se apliquen reglas al listener.

Por ejemplo, si un servicio escucha en el puerto 443 con HTTPS y un usuario intenta acceder al servicio en el puerto 80 utilizando HTTP, la solicitud se redirige automáticamente al puerto 443 con HTTPS.

Si hay políticas presentes en el escucha de redirección HTTPS, estas se evalúan en primer lugar. Si no hay ninguna política que coincida, la solicitud se redirige a un listener de HTTPS configurado.

Propiedades del escucha de redirección HTTPS

Políticas a prueba de fallos del fondo de reserva

Al editar un grupo back-end en un equilibrador de carga, puede especificar una de las siguientes acciones de política a prueba de fallos:

• Reenviar: El equilibrador de carga enruta las peticiones a un pool de respaldo designado. Esto proporciona una ruta de conmutación por error limpia a otro conjunto de servidores de aplicaciones. Debe tener un grupo de respaldo existente configurado y listo para recibir tráfico.
• Drop: El balanceador de carga elimina todas las peticiones entrantes y el cliente no recibe respuesta.
• Fallo: El equilibrador de carga rechaza las solicitudes con un código de estado HTTP 503 ("Servicio no disponible"), informando al cliente de que el servicio está temporalmente fuera de servicio.

Puede elegir un destino a prueba de fallos de una lista de grupos de copias de seguridad aplicables.

Requisitos del grupo objetivo a prueba de fallos (si la acción es Forward):

• deben pertenecer al mismo equilibrador de carga
• deben tener el mismo protocolo o uno compatible ( TCP sólo es compatible con TCP, pero cualquier combinación de HTTP y HTTPS es compatible)

Sólo los balanceadores de carga de aplicaciones permiten asociar más de un pool a un único listener. Asegúrese de que existe al menos un grupo en el equilibrador de carga.

En una configuración de balanceador de carga, un listener se considera el recurso padre. Puede asociar pools a ese listener de dos formas, haciendo referencia a ellos directa o indirectamente. Para la asociación directa, configure el pool como default_pool del oyente. Para la asociación indirecta, haga referencia al pool desde otro pool a través de una relación failsafe_policy.target, asegurándose de que el otro pool ya está vinculado al oyente.

Localización del CRN de certificado

Al configurar la autenticación para un equilibrador de carga de aplicaciones durante el aprovisionamiento en la consola, puede optar por especificar el certificado Secrets Manager y SSL, o el CRN del certificado. Quizá te interese hacerlo si no ves Secrets Manager en el menú desplegable, lo que significa que no tienes acceso a la instancia de Secrets Manager. Tenga en cuenta que debe introducir el CRN si utiliza la API para crear un ALB.

Para obtener el CRN, debes tener permiso para acceder a la instancia de Secrets Manager.

Para encontrar el CRN de un certificado, siga estos pasos:

1. En la consola IBM Cloud, vaya al del menú de navegación > Lista de recursos.
2. Haz clic para desplegar Seguridad y, a continuación, selecciona el Secrets Manager del que deseas conocer el CRN.
3. Seleccione cualquier punto de la fila de tabla del certificado para abrir el panel lateral de detalles del certificado. Se indica el CRN del certificado.