Buenas chic@s! En día de hoy vengo hablaros acerca de como crear un balanceo ya sea L4/L7, y mantener la IP original durante el balanceo. Para ello haremos uso de AVI y de la parte «Service Insertion Framerwork» de NSX-T . Primero de todo haremos una introducción de la funcionalidad, y luego nos meteremos de lleno en la configuracion.
Introducción
Durante la configuración de diferentes balanceo, nos podemos encontrar que para algunas aplicaciones (especialmente en el modo de Capa 4) requieren que la dirección IP del cliente se presente como la dirección IP de origen cuando el paquete aterriza en el miembro del servidor del grupo backend. NSX ALB( AVI) tiene esta funcionalidad como Preserve Client IP.
Esta solución se implementa en la mayoría de soluciones de balanceo haciendo que la puerta de enlace predeterminada del servidor backend apunte a una IP flotante. La IP flotante se aloja en la interfaz backend del Service Engine activo. Sin embargo, en este modo, la puerta de enlace predeterminada de los servidores debe modificarse/actualizarse para que apunte a la IP flotante. El modelo de despliegue superpuesto de NSX-T, al estar en modo de capa 3, presenta complicaciones para conservar la IP del cliente.
Service Insertion Framework
VMware NSX-T provee «Service Insertion Framework», que tiene la capacidad de redirigir el tráfico. Este se utiliza para conseguir que el tráfico de retorno vaya desde el servidor backend a la IP flotante del «Active Service Engine» sin necesidad de cambiar la puerta de enlace predeterminada del servidor backend.
Flujo de trafico
Los clientes atacan al balanceador, y este realiza un DNAT hacia uno de los nodos de backend. Una vez la solicitud ha sido respondida por el servidor, gracias al Service Insertion Framefork, este tiene la capacidad de redirigir el tráfico hacia el balanceador. El » Service Insertion Framefork» de NSX-T se utiliza para conseguir que el tráfico retorne desde el servidor backend a la IP flotante de Active Service Engine sin necesidad de cambiar la puerta de enlace predeterminada del servidor backend.
Importante el detalle de que no tenemos que cambia el GW de los nodos de backend. Esto es importante ya que en topologías Inline de balanceo, los nodos de backend usan el balanceador como GW. En este caso gracias la magia de NSX-T no es necesario hacer eso.
En esta imagen de aquí abajo vemos un poco lo comentado justo ahora.
Prerequistios
- Requiere versión mínima de NSX ALB 22.1.6
- Solo es compatible usando el modelo de HA Active/Standby
- Es necesario configurar un IP Flotante
- Se necesitan permisos adicionales en NSX para el usuario de AVI, concretamente los siguientes roles «Netx Partner Admin» y «Security Admin»
- El segmento debe ser configurado en modo URPF Mode : None
- Los miembros del pool deben ser configurado bajo un NSG(NSX Security Group)
- Es necesario disponer de un Edge Clúster, ya que el segmento debe ir atachado a un Tier-1 el cual este alojado en un clúster de Edge.
- TIP: Crear un segmento y Tier-1 dedicado para ello
- TIP2: Asegurarse de un buen «rightsizing» para los Edge Nodes que componen el Edge Cluster.
- Los nodo del pool, deben estar en el mismo segmento que la VIP.
Cosas a tener en cuenta
- Cuando añadamos un nuevo nodo al pool, puedo tomar hasta 120 segundos para redirigir el trafico hacia el nuevo servidor.
- Si pasamos de no usar «Preserve IP Client» a usarlo, tendremos un corte de 120 segundos.
- Cunado deshabilitamos el Virtual Service, tarda unos 180 segundos en borrar la regla de dirigir el trafico en NSX.
- Tras la activación de VS después de la desactivación, el VIP tarda unos 5 minutos en estar operativo y en estado OPER_UP.
Desventajas
- Si se cambia el número de puerto del pool o cambio de la IP FIP en el grupo SE provoca la pérdida de tráfico durante unos 90 segundos.
- Las propiedades «Load Balancing» y «Autorebalance» no son compatible .
- El uso del mismo «Server pool» y puerto para el el tipo de balanceo usando «Preserve IP Client» y sin usar » Preserve IP Client» a través de los SEGs causa que el «Virtual Service» sea marcado como caído para «Preserve IP Client» debido a que el tráfico del «monitor de salud «Health Monitor» falla.
- Si el mismo NSG(NSX Security Group) es usando en mas de un «Virtual Service», cada pool tiene que tener un puerto diferente.
- El «Application Profile no soporta «Connection Muliplex»
- No soporta la funcionalidad «Port transalation Disabled» dentro de las opciones del pool, ya que las «redirect rules» desde el servidor de backend están basadas en ip_servidor_de_backend:ip_servidor_puerto.
Topología Laboratorio
Aquí tenemos la topología que usaremos para el laboratorio, la idea es realizar las peticiones desde el cliente a la Ia VIP que contendrá el servidor nginx.
Configuración
Una vez hemos visto toda la parte teórica, ha llegado el momento de la configuración. Para ello lo primero que haremos será el Segmento. Dentro de nuestro NSX Manager, nos dirigimos a Networking–> Segment—> Add.
- Asignamos un nombre descriptivo
- Seleccionamos la Transport Zone de Overlay
- Asignamos el GW, en mi caso 172.27.1.1/24
Ahora nos vamos a la parte de Networking–> Tier-1–>Add
- Asignamos un nombre descriptivo
- Selecciomamos el modo «Active-Standby» y lo enganchamos al Tier-0 que ya tenemos creado.
- Seleccionamos «Auto Allocate Edges»
Yo en mi caso ya tengo creado el Edges Cluster y el Tier-0 de otra post.
Volvemos a la parte del parte y pulsamos en «Edit».
- Lo enganchamos al Tier-1 que hemos en el paso anterior.
- En la parte de URPF Mode seleccionamos «None»
Ahora nos vamos a AVI y nos dirigimos a la parte de Clouds y pulsamos sobre la que sea del tipo «NSX Cloud» y pulsamos sobre el lapicero.
Nos dirigimos hasta la parte de «Data Networks Segments» y añadimos «Logical Router» y «Overlay Segment» que creamos en la parte de NSX-T
Ahora en la parte de Network Profiles, pulsamos en el lapicero sobre el segmento » StormCloud-LB-Inline Segment»
En esta parte vamos añadir las IPs las cuales serán asignadas a nuestras «Services Engines».
Ya estamos preparados para crear nuestro «Service Engine Group», pulsamos en «Create».
Lo mas importante de todo es que debe ser del tipo «Active/Standby». Por ello el nombre que le asignemos que sea bastante descriptivo.
Seleccionamos «Active/Standby» y el resto de opciones de la imagen de abajo las dejamos por defecto.
Asignamos un nombre de prefijo descriptivo y el resto de opciones en mi caso las dejare por defecto. Si consideráis que vuestras SEs tienen que tener mas memoria o vCPU es el momento.
Añadimos el vCenter donde se desplegaran las SEs, para ello pulsamos en «Add».
Rellenamos los siguientes campos:
- Nombre descriptivo
- Cluster donde se desplegaran las SEs
- Almacenamiento del clúster seleccionado donde se desplegaran las SEs
Dado que se van a realizar operativas NO comunes bajo el entorno de NSX, es necesario añadir nuevos permisos a nuestro rol de AVI en NSX.
Por ello nos volvemos a la parte de NSX. Concretamente a System–> User Management
En mi caso ya tengo asociado un rol al usuario de AVI, por lo tanto solo tengo que modificar el rol de AVI añadiendo los siguientes roles : «Next Partner Admin» y «Security Admin».
Ahora ha llegado el momento de modificar el «Portgroup» a nuestra VM, así como su como su configuración de interna red. Para ello asignaremos el segmento que hemos creado anteriormente, «StormCloud-LB – Inline Segment».
Asignamos una IP que este en el rango, y como GW asignamos el del Tier-1. Esta parte es quizás es una de las mas controvertidas, ya que estamos acostumbrados a que cuando creemos balanceos INLINE, el GW sea el balanceador, pero en este caso es el Tier-1. Como hemos comentado en la introducción, solo el trafico balanceado «saldrá usando el GW del balanceador»(pasando por el Edge node), aquí es donde estaría la magia de NSX. El resto del trafico no pasaría por el Edge Node y se enrutaría en el hipervisor.
Accedemos via SSH a nuestro master controller de AVI, y nos conectamos al framework de AVI ejecutando el comando «shell».
configure network nsxt_preserverIP_ns se_group_ref SEG-StormCloud-Inline-\ A/S vrf_ref StormCloud-LB-Inline service_type routing_service floating_intf_ip 172.27.1.2 enable_vip_on_all_interfaces SAVE
Ya estamos preparador para crear el Virtual Service, para ello desde la parte de Virtual Service, pulsamos en «Create Virtual Service»–> Advanced Setup»
Crear virtual Service
Seleccionamos el cloud de NSX.
Seleccionamos la VRF donde crearemos el balanceo. En mi caso el Tier-1 donde tengo asociado el segmento.
Empezaremos asignando un nombre descriptivo, después en la parte de VS VIP, pulsamos en «Create».
Las partes de «TCP/UDP Profile» y «Application Profile» por el momento las dejaremos por defecto. Para que funcione el balanceo INLINE, tendremos que hacer una modificación dentro del «Application Profile», pero mi idea es que veáis la diferencia entre marcar y no marca el flag de «Preserve IP Client address» dentro del «Application Profile».
Asignamos una IP dentro del rango balanceo, en mi caso la 172.27.1.11. y pulsamos «Save»
Nos vamos a la parte de pool, pulsamos en «Create Pool».
Asignamos el puerto 80 en «Default Server Port». El resto de valores de la imagen de abajo los dejamos por defecto.
Ahora nos abrimos una pestaña de NSX, nos vamos a la parte de Invetory–>Group–>Add
Esta parte es importante, los nodos del pool tienen que ser añadidos como un grupo de NSX, sino el balanceo de no funcionara.
Asignamos un nombre descriptivo al grupo.
Seleccionamos los miembros que contendrá el pool.
Ahora siguiendo con la configuración del pool, en la parte de «Servers», seleccionamos «Security Group» y pulsamos en la flechita y seleccionamos el grupo que acabamos de crear.
Seleccionamos «System TCP» como «Health Monitor».
El resto de opciones las dejamos por defecto, y pulsamos en «Save».
Ya tenemos el «Virtual Service» creado, de momento NO mantendrá la IP original ya que aun no lo hemos activado en el «Application Profile» del «Virtual Service».
Si probamos acceder a la URL del balanceador nos cargara perfectamente.
Si hacemos un debug en el hipervisor, podremos observar como el trafico hacia el nodo, no mantiene la IP original. Es decir la IP original esta siendo nateada(SNAT), con la ip de la interfaz del Service Engine.
Esto es el comportamiento espero ya que aun NO hemos activado el «Preserve Client IP Address».
Ahora ha llegado el momento de configurar para que mantega la IP original cuando es balanceado hacia el nodo, para ello editamos el «Virtual Service» y en «Application Profile», pulsamos en «Create Application Profile».
Asignamos nombre descriptivo, seleccionamos el «Type» L4 y lo mas importante, marcamos el flag de «Preserve Client IP Address».
Pulsamos en Save, y nos vamos hasta la ultima pestaña del «Virtual Service» y pulsamos en «Save».
Si nos vamos a la parte de Eventos de AVI, encontraremos los evento relacionado entre NSX y AVI para hacer funcionar este balanceo y que mantenga la IP original
Si nos vamos a la parte de NSX, concretamente a Security–>N-S Network Introspection. En esta parte podremos ver como ha creado una regla «redirect» para que todo el trafico con Origen puerto 80 lo mande al SE y de esta manera se mantenga la simetria del trafico.
Hay que tener en cuenta que si se modificamos cualquier puerto en el «Virtual Service», tendremos un corte de entre 60 a 90 segundos.
Si volvemos a probar la URL, nos ira a la perfección.
Como hemos realizado antes, i hacemos ell debug en la parte del host, ahora si la IP original es mantenida durante el balanceo, además el trafico de vuelta en lugar de enrutarse por el host, este es capturado por el hipervisor y mandado al «Edge Node» para que lo vuelva a mandar al balanceador.
Si yo hago un tracert a google, podemos observar como el trafico no pasa por el balanceador y se enruta en el DR del hipervisor.
Conclusiones
Hasta aquí hemos llegado, la verdad que requiere de bastante configuración tanto en NSX-T como en AVI, pero una vez hagamos el primero, todo será bastante mas fácil. Debemos tener en cuenta, que podemos tener 2 futuros cuellos de botella, ya que todo el trafico de vuelta balanceado pasa por el «Edge Node», además de por el SE(ida y vuelta del flujo).
Siempre y cuando los balanceos sean L7, yo optaría hacer uso de la cabecera » HTTP X-Forwarder For». Esta añade la IP original en una cabecera HTTP y es enviada al nodo, es mas sencillo de configurar y no tiene las limitaciones que tiene el balanceo Inline de AVI. Sino te queda mas remedio, que mantener la IP original, este es tu método, pero ten muy en cuenta las limitaciones.
Nada mas que decir, espero que os haya gustado y nos vemos en los siguientes post.