Modos de distribución de Azure Load Balancer
Azure Load Balancer admite los modos de distribución que se indican a continuación para enrutar las conexiones a las instancias del grupo de back-end:
| Modo de distribución | Por hash | Persistencia de la sesión: IP del cliente | Persistencia de la sesión: IP y protocolo del cliente |
|---|---|---|---|
| Información general | El tráfico de la misma dirección IP del cliente se enruta a cualquier instancia correcta del grupo de back-end. | El tráfico de la misma dirección IP del cliente se enruta a la misma instancia de back-end. | El tráfico de la misma dirección IP y el mismo protocolo del cliente se enruta a la misma instancia de back-end. |
| Tuplas | tupla de cinco | tupla de dos | tupla de tres |
| Configuración de Azure Portal | Persistencia de la sesión: Ninguna | Persistencia de la sesión: IP del cliente | Persistencia de la sesión: IP y protocolo del cliente |
| REST API | "loadDistribution":"Default" |
"loadDistribution":SourceIP |
"loadDistribution":SourceIPProtocol |
No hay tiempo de inactividad al cambiar de un modo de distribución a otro en un equilibrador de carga.
Por hash
Azure Load Balancer usa un modo de distribución basado en un hash de tupla de cinco elementos de manera predeterminada.
La tupla de cinco elementos consta de:
- IP de origen
- Puerto de origen
- IP de destino
- Puerto de destino
- Tipo de protocolo
El hash se usa para enrutar el tráfico a instancias correctas de back-end del grupo de back-end. El algoritmo solo proporciona adherencia dentro de una sesión de transporte. Cuando el cliente inicia una nueva sesión desde la misma IP de origen, el puerto de origen cambia y provoca que el tráfico vaya a una instancia de back-end diferente. Para configurar la distribución basada en hash, debe definir la persistencia de la sesión como Ninguna en Azure Portal. Esta opción especifica que cualquier máquina virtual puede controlar las solicitudes sucesivas del mismo cliente.
Ilustración: Distribución predeterminada basada en un hash de tupla de cinco elementos
Persistencia de la sesión
La persistencia de sesión también se conoce como afinidad de sesión, afinidad de IP de origen o afinidad de IP de cliente. Este modo utiliza un hash de tupla de dos elementos (IP de origen e IP de destino) o de tres elementos (IP de origen, IP de destino y tipo de protocolo) para enrutar a instancias de back-end. Al usar la persistencia de sesión, las conexiones del mismo cliente van a la misma instancia de back-end del grupo de back-end.
El modo de persistencia de sesión tiene dos tipos de configuración:
- Dirección IP de cliente (tupla de 2 elementos): especifica que la misma instancia de back-end controla las solicitudes sucesivas de la misma dirección IP de cliente.
- Dirección IP y protocolo de cliente (tupla de 3 elementos): especifica que la misma instancia de back-end controla las solicitudes sucesivas de la combinación de la misma dirección IP y el mismo protocolo de cliente.
En la figura siguiente, se ilustra la configuración de tupla de dos elementos. Observe cómo la tupla de dos elementos se ejecuta a través del equilibrador de carga en la máquina virtual 1 (VM1). VM2 y VM3 realizan una copia de seguridad de VM1.
Casos de uso
La afinidad de IP de origen con la IP y el protocolo de cliente (afinidad de IP de origen de tres tuplas) resuelve una incompatibilidad entre Azure Load Balancer y Puerta de enlace de Escritorio remoto.
Otro escenario de caso de uso es la carga de elementos multimedia. La carga de datos tiene lugar a través de UDP, pero el plano de control se consigue mediante TCP:
- Un cliente inicia una sesión TCP en la dirección pública de carga equilibrada y se le dirige a una DIP específica. El canal se mantiene activo para supervisar el estado de conexión.
- Se inicia una nueva sesión UDP desde el mismo equipo cliente al mismo punto de conexión público de carga equilibrada. La conexión se dirige al mismo punto de conexión DIP que la conexión TCP anterior. La carga de elementos multimedia se puede ejecutar a alto rendimiento al tiempo que mantiene un canal de control a través de TCP.
Nota:
Cuando cambian los miembros del grupo de back-end de Load Balancer mediante la eliminación o incorporación de una máquina virtual, se vuelve a calcular la distribución de las solicitudes de cliente. No puede depender de nuevas conexiones desde clientes existentes para terminar en el mismo servidor. Además, el uso del modo de distribución de afinidad de IP de origen puede ocasionar una distribución desigual del tráfico. Los clientes que se ejecutan detrás de servidores proxy pueden considerarse como una sola aplicación cliente.
Pasos siguientes
Para más información sobre cómo configurar el modo de distribución de Azure Load Balancer, consulte Configuración del modo de distribución de Azure Load Balancer.