Buenas chic@s! Tras unas largas y merecidas vacaciones del mundo bloguero, hoy vengo para seguir hablando de AVI. En el día de hoy nos centraremos en el funcionamiento de AVI o como el titulo dice «Avi Undet the hood». Por ello vamos a ver la tripas de como funciona AVI y su integración con NSX-T . Además aprenderemos sobre su funcionamiento desde que realizamos una petición en el navegador, hasta que se atiende por uno de los nodos del pool .
Por otro lado si conocemos como funciona el producto, nos será mas fácil solucionar cualquier tipo de problema. Por ello que mejor, que leer algunos los post sobre AVI, aquí te dejos algunos.
En la siguiente imagen podemos observar una petición que hemos realizado desde unos de ordenadores de la LAN. Observaremos numerosos detalles, como que SE atiende la petición, a que nodo del pool dirige la petición, diferentes tiempos de respuesta desde las diferentes capas.
Ha llegado el momento de aprender como ha llegado desde unos de los ordenadores de la LAN hasta uno de los nodos del pool.
Partimos de la siguiente topología.
Vista de la topologia Activo – Pasivo
El usuario introduce la URL de nuestra VIP en el navegador desde una ordenador de la red LAN. Esta solicitud llegara al «Router WAN», donde observaremos lo siguiente, tenemos la VIP 172.26.5.50/32 que esta siendo anunciada por nuestro router «R1». Recordar que esta ruta es anunciada desde el Tier-1 y posteriormente desde el el Tier-0. Esto es así ya que marcamos la opción de redistribuir las «All LB VIP Routes».
Una vez el paquete ha llegado a R1, este lo encaminara hacia el Edge activo, en este caso es el Edge-Node-1.
Una vez nuestra solicitud llega al «Edge Node-1» esta es enviada al DR del Tier-1. Hay que tener en cuenta que dentro del «Edge Node», tenemos el SR/DR del Tier-0 y el DR del Tier-1, por lo tanto esta se enruta localmente.
Una vez la solicitud esta dentro del DR del tier -1, nos podemos fijar que para llegar a la VIP 172.26.5.50 tiene una ruta estática apuntando 172.26.9.2,echando un vistazo a la topología, esa IP se corresponde con la IP del Service Engine Activo.
Aquí tenemos en detalle el funcionamiento de cuando llega el trafico al Tier -1, básicamente como solo tenemos el VS activo en uno de los SEs, el DR del tier solo tendrá una ruta estática apuntando al SE activo.
Una vez el trafico ha llegado al SE(Service Engine), el SE elegirá unos de los servidores dentro del pool al que mandar la solicitud ( todo dependerá del método del balanceo). Una vez haya elegido a donde mandarla, modificara la IP Origen/Destino del paquete, es decir hará un SNAT/DNAT del paquete y lo enrutara hacia el nodo elegido.
Para ello pondrá como IP origen la del SE, y como IP destino la del nodo elegido para mandar la solicitud . De esta manera se asegura que la vuelta del trafico pasa por el SE. Una vez el trafico haya vuelto del nodo, el SE deshará los SNAT/DNAT y lo enrutara hacia arriba.
¿ Que sucede cuando tenemos nuestro Virtual Service en Activo – Activo?
En nuestro caso, tenemos el Virtual Service corriendo en uno de los SE, ¿Como hacemos para que corra en mas de un SE?, muy sencillo, realizando un «Scale Out».
Sino sabes lo que es un «Scale Out», no te preocupes que aquí te lo explico. Básicamente consiste en expandir nuestro «Virtual Service» a uno o mas SE, y que este activo en mas de un SE. Esto nos dará cierta ventajas como : Mayor Perfomance, Alta disponibilidad en caso de caída de uno de los SE, no tendríamos perdida de servicio.
Para realizar un «Scale Out», pasaremos por el rato por encima del «Virtual Service» y pulsaremos » Scale Out».
Seleccionamos el SE recomendado, en mi caso como mi Service Engine group esta compuesto por 2 SE no necesito crear nada.
Aquí podemos observar como va modificando el SE que esta como Standby a la espera de una posible caída del activo.(Esto no es del todo correcto, ya que no estamos usando la Topología Activo-Standdy) sino la de N+M. Dado que solo tengo creado un VS en el «Service Engine Group», uno de los SE no esta corriendo ningún VS, por lo tanto esta únicamente haciendo de buffer HA.
Una vez realizado el «Scale Out», sino fijamos en la topología, ahora los 2 SEs están en activo-activo, es decir, ambos procesaran trafico de nuestra VIP.
Vista de la topología Activo – Activo
Si nos vamos a la parte del DR del Tier-1, podremos ver como tenemos 2 rutas estáticas para alcanzar la VIP.
Si nos vamos en detalle al funcionamiento de cuando llega el trafico al Tier-1, como tenemos el VS activo en los 2 SEs, el DR del tier 1 tendrá dos estáticas apuntando al los SEs activos. El DR del Tier -1 usara ECMP para distribuir las peticiones sobre los SEs.
Realizando peticiones constantes a la VIP, observamos como el trafico es dirigido a los 2 SEs. He de comentar que tengo la persistencia quitada para observar que balancea entre los 2 SEs.
Bonus Track
En un supuesto caso de tuviéramos la VIP en 3 SEs de manera activa y se cayera uno de los SEs, pasaría lo siguiente:
- La ruta estática seria removida del Tier-1.
- Todos los flujos que estarían pasando por el SE caído, tendrían que reiniciarse.
- Los nuevos flujos se repartirían entre los dos SEs restantes
Conclusión
Hasta aquí hemos llegado, como veis uno de las mejores cosas que tiene AVI en su integración con NSX, es fácil y sencillo el escalado, tanto horizontal(Scale Out) como vertical(Scale IN). Espero que os haya gustado, si necesitas mas informacion sobre AVI, aqui te dejo su web. Nada mas,nos vemos en los siguientes post.