¿Cómo funciona el servicio de VMware NSX Edge Load Balancer?
Alberto Giorgi
Posted On noviembre 20, 2014
Hola a todos, en esta nota explicaré los servicios Load Balancing (Balanceo de Carga) que ofrece VMware NSX.
La distribución de la carga entre una granja de servidores permite que los usuarios experimenten una atención más rápida a sus peticiones mejorando así su experiencia con el servicio.
El Balanceo de carga para tráfico IP tiene tres beneficios
- Distribución de la carga
- Escalabilidad
- Tolerancia a fallos
Los servidores (en nuestro caso las VMs) ofrecerán todos el mismo servicio, generalmente se trata de aplicaciones multitier, que se componen de un front end (web server), un middle tier (aplicación) y un back end (bases de datos), un excelente ejemplo para usar una vAPP en lugar de VMs independientes.
La escalabilidad consiste en poder ir agregando servidores a la granja a medida que los usuarios se incrementan.
La tolerancia a fallos consiste en que si el servicio de balanceo detecta que uno o más servidores de la granja han dejado de responder entonces re-direcciona las peticiones a otros servidores. Inevitablemente las sesiones interrumpidas deberán a volver a comenzar en un nuevo servidor, a no ser que haya algún mecanismo de redundancia a nivel de aplicación.
El servicio requiere la asignación de una dirección IP virtual que será el destino del tráfico de los usuarios. Generalmente se trata de una IP pública que será resuelta por el servicio de DNS, ajeno al NSX. Dicha dirección se denomina vIP (virtual IP). Podemos definir múltiples direcciones vIPs para balancear el tráfico de distintas aplicaciones entre distintas VMs, en un entorno multitenant. Asociaremos la o las vIPs a la interfaz externa del Edge Router.
NSX solo balancea localmente y no globalmente, es decir que no redirige el tráfico a la vIP geográficamente más cercana.
Las direcciones IPs de las VMs son transparentes para el usuario, ya que parte de la tarea del balanceador es realizar un servicio de NAT con las direcciones IP de destino (dNAT).
En la versión 6.0 el tráfico que puede balancear el NSX es TCP (L4), HTTP y HTTPS (L7).
El servicio de balanceo cuenta con múltiples algoritmos para balancear la carga de forma eficiente, dependiendo de las características de la aplicación. Los algoritmos soportados en la versión 6.0 son:
- Round Robin
- IP-Hash
- Leastconn
- URI
Algunas aplicaciones requieren persistencia, es decir que una vez que ha sido redirigido a un servidor las siguientes peticiones continúen asociadas al mismo servidor hasta cerrar la sesión. Imaginen que se tratara de una aplicación de comercio electrónico para comprar libros o música por ejemplo. Una vez que hemos elegido nuestra compra no deberíamos ser redirigidos a un servidor que no supiera sobre las transacciones anteriores y tuviera el carro de la compra vacío. En este tipo de aplicaciones es necesario que la misma VM procese toda la sesión, hasta que hayamos terminado.
Los métodos de persistencia soportados son:
- Source IP
- MSRDP
- Cookie
- ssl session-id (solo para https://)
El load Balancer permite controlar la cantidad de conexiones mediante un máximo o bien por cantidad de conexiones por segundo.
El servicio también cuenta con distintos mecanismos de monitorización para verificar si los servidores de la granja están activos o no, que pueden ser desde secuencias tcp a determinados puertos, a tramas get para verificar si la aplicación http:// o https:// está activa.
El algoritmo puede asignarle pesos a las diferentes VMs. Supongamos que ciertas VMs están mejor dimensionadas que otras, es decir que cuentan con el doble de vRAM o vCPU, esos miembros de la granja pueden tener un peso mayor que otros que solo cuentan con la mitad de esos recursos, de manera que aceptarán más peticiones sin degradar el servicio.
Para las aplicaciones https:// podemos hacer que las peticiones pasen directamente a la VMs de destino (SSL pass-trought), es decir que el cliente recibirá el certificado digital de la propia VM, o podemos hacer que la sesión se establezca contra la IF del Edge Router, entregando al cliente el certificado asociado al Edge Router, y que el tráfico hacia las VMs sea http:// lo que requerirá menos certificados digitales a instalar.
Podemos implementar el servicio tanto para IPv4 como para IPv6.
En cuanto a los modos de implementar el servicio, NSX cuenta actualmente con dos, muy comunes en otros balanceadores también:
- One-Arm.
- Inline
One-Arm
One-Arm o proxy mode, significa que solo una parte del tráfico destinado a la vIP será balanceado, para lo cual el Edge Router deberá detectar el tráfico y enviarlo a la granja de servidores asociados. La respuesta a ese tráfico debe volver a pasar por el balanceador, para que este controle las sesiones abiertas, en tránsito, cerradas, etc. La manera de lograr esto es que el Edge Router aplique una regla de source nat, reemplazando la dirección IP de origen por la dirección IP de la interfaz inside del Edge Router, de manera que las VMs volverán a entregar el tráfico procesado al Edge Router.
Quizás es siguiente dibujo le permita entender mejor el escenario.
El tráfico rojo tiene que ser balanceado, supongamos que es http:// pero el tráfico azul FTP no.
Para el tráfico rojo el Edge router le aplica NAT a las IPs de origen y de destino logrando de esta manera que el tráfico vuelva a pasar por el balanceador una vez procesado. Si no hiciera esto las VMs entregarían el tráfico procesado a su Default Gateway que sería al IP interna del Edge, por lo que el balanceador no podría ver si la sesión continua o se cerró. Además el PC de origen recibiría el tráfico desde una IP que no identifica, la de la VM, y lo descartará. El tráfico http se redirige como si el balanceador fuera un servidor proxy.
El tráfico azul en cambio, es enviado a las VMs para ser procesada directamente, y la VM lo devuelve a la interfaz interna del Edge Router por ser su Default Gateway.
El problema con esta estrategia es que al perderse la IP original la aplicación podría perder funcionalidades. Supongamos que la aplicación requiere llevar una estadística del país desde el que se ha realizado la compra. Al perder la IP original no podrá llevar a cabo esa función.
NSX soporta x-forwarder para tráfico HTTP, esto permite conservar la IP de origen en la cabecera del get, por lo que la aplicación puede obtener el dato para sus estadísticas. Lamentablemente este método no es válido para aplicaciones que no utilicen http.
Inline
En la opción Inline todo el tráfico pasa a través del balanceador, por lo tanto no es necesario modificar la IP de origen ya que las VMs enviarán el tráfico a su DG que aplicará el control de tráfico y el NAT sobre la dirección IP de origen, reemplazando la IP de la VM por la vIP para que el PC de origen no note la diferencia.
En este modo las aplicaciones suelen no ser afectadas por el balanceo.
NSX permite integrarse con servicios de balanceo más avanzados de 3ras partes como F5.
En cuanto a la escalabilidad del servicio los números son impresionantes:
- Throughput: 9 Gbps
- Conexiones concurrentes: 1 million
- Nuevas conexiones por segundo: 131k
Espero que esta nota les haya parecido interesante, si así fuera se agradecen los likes. Los espero el próximo jueves con otra nota sobre NSX.
Gracias por leer nuestro blog, participar y compartir.
