Posted by En la parte 8 de esta serie vimos como montar un servidor DHCP, en esta parte 9 vamos a ver como crear un balanceo de carga (en adelante LB).
Antes de pasar a la parte de configuración repasamos algunos aspectos importantes de LB de NSX-T.
Primero de todo a tener en cuenta, el LB lógico solo esta soportado en el routers lógicos T1 y un LB no se puede asociar a mas de un T1. Se pueden crear LB de capa 4 o 7.
Este articulo cubre el balanceo de carga de NSX-T en «Manager mode», podemos consultar más información del modo NSX Advanced Load Balancer (Avi Networks) aquí.
LB distribuye las solicitudes de servicio entrantes de manera uniforme entre varios servidores, de tal manera que la distribución es transparente para los usuarios, ayuda a la utilización optima de los recursos, maximizar rendimiento, minimizar tiempos de respuesta y evitar sobrecarga de servidores.
Podemos asignar una IP virtual (Virtual Server) a un conjunto de servidores (Server Pool) para equilibrar la carga de solicitudes TCP, UDP, HTTP o HTTPS y LB decidirá que servidor del grupo utilizar.
Un «Virtual Server» no entiende de servicios de aplicación, es un conjunto único de IP, puerto y protocolo a balancear y se asocia a uno o varios «Server Pool». A nivel de «Server Pool» se pueden establecer monitores para comprobar el estado de salud de los servidores del pool.
Los balanceos normalmente se configuran o en modo Inline o One-Arm.
One-Arm LB.
En el modo One-Arm, el cliente y el servidor pueden estar en cualquier lugar. El LB realiza Source NAT (SNAT) para forzar que el tráfico de retorno del servidor al cliente pase por el LB. Esta topología requiere que en el «Virtual Server» el SNAT esté habilitado.
Cuando el LB recibe el tráfico del cliente en la dirección IP virtual, el LB selecciona un miembro del grupo de servidores y le reenvía el tráfico del cliente. En el modo One-Arm, el LB reemplaza la dirección IP del cliente con la dirección IP del LB para que la respuesta del servidor siempre se envíe al LB y que se el LB el que la reenvíe al cliente.
Inline LB.
En el modo Inline LB (el que veremos en este post) el LB se encuentra en la ruta del tráfico entre el cliente y el servidor. Los clientes y servidores no deben estar conectados al mismo T1. Esta topología no requiere SNAT en el «Virtual Server».
No soy un experto en balanceo de carga, pero a mi entender las grandes diferencias resumidas serian:
- En modo One-Arm perdemos la habilidad de controlar la IP origen, se me ocurren casos de uso en los que queremos saberlo, como geo-localizar la petición para dirigirnos al servidor más cercano. En modo Inline si mantenemos la IP origen de la petición.
- En modo Inline cliente y servidor no pueden estar bajo el mismo T1.
- En modo One-Arm el T1 al que este asociado el LB no debe estar linkado a T0, mientras en modo Inline si debe estarlo.
- En modo Inline la IP del «Virtual Server» tiene que estar en un rango no anunciado en ninguna otra parte de la red.
En LB tradicionales el modo One-Arm suele ser el más simple de configurar pero en el caso de NSX-T en realidad necesita mas configuración, ya que LB en NSX-T realmente es un servicio que corre dentro del Service Router (SR) de un T1. Normalmente al desplegar un T1 lo linkamos a un T0 para permitir la conexión al mundo exterior, con lo que para hacer One-Arm necesitariamos un T1 adicional que no este linkado a T0.
Podemos consultar los limites de LB en NSX-T aquí y aquí.
Vista esta breve introducción vamos al lío.
Para este balanceo de carga utilizaremos nuestros 2 servidores Web de laboratorio, que ya tenemos con conectividad configurada en post anteriores.
Vamos a crear un nuevo T1 para nuestro LB que se instanciara en nuestro clúster de EDGE, no puedo usar el existente ya que mi máquina cliente cuelga de él y en modo Inline como hemos comentado cliente y servidor no pueden estar en el mismo T1.
Le damos un nombre, lo asociamos a nuestro T0 (en One-Arm como hemos comentado no iría asociado) y como hemos indicado antes lo asociamos a nuestro clúster de EDGE.
Asociamos nuestro nuevo T1 al segmento WEB. Nuestra máquina cliente esta en el segmento DHCP-Segment con lo que ya cumpliríamos que cliente y servidor no estén bajo el mismo T1.
Creamos un nuevo LB.
Indicamos nombre, tamaño y a que T1 asociarlo.
Al guardar nos pregunta si queremos seguir configurándolo, indicamos que si y pinchamos sobre «Set Virtual Servers».
Como en nuestro caso no tenemos ninguno, añadimos un L4 TCP.
Le indicamos el nombre, la IP por la que se servirá el balanceo (no debe estar en el rango de los servidores WEB ni con el rango anunciado en otro parte de la red al usar modo Inline), el puerto y como no tenemos ningún «Server Pool» lo creamos.
Indicamos el nombre, el tipo de algoritmo de balanceo (en nuestro caso Round Robin) y seleccionamos los miembros, como ya teníamos un grupo que incluía los dos servidores Web de un post anterior, lo seleccionamos.
Vemos como queda.
Si probamos la Web desde la IP del balanceador veremos que no funciona porque aun no hemos anunciado las rutas.
Vamos al T1 que hemos creado para nuestro LB y habilitamos el «All LB VIP Routes» en el apartado «Route Advertisement».
Ahora si si vamos a la Web en la IP del balanceo que hemos configurado, veremos que ya funciona y que si refrescamos el navegador, se va alternando el servidor que nos contesta.
Para habilitar el balanceo hacia el mundo exterior, tenemos que habilitar en nuestro T0 que se anuncien las rutas «LB VIP».
Veamos una parte de linea de comandos también. Conectamos a uno de los EDGE de nuestro clúster por ssh, podemos listar nuestros LB mediante el comando «get load-balancer» .
Usando los ID anteriores consultamos los datos del «Virtual Server» .
Sacamos la info del «Server Pool» .
Con esto finalizamos esta parte 9 en la parte 10 veremos la configuración de NAT.
Comparte si te gusta 🙂