Buenas chic@s! Ya estamos aquí un día mas para hablar sobre AVI/ALB. En el post anterior vimos como añadir el Cloud de nsx-t, aquí te lo dejo para que lo tengas si te lo perdiste. En el día de hoy aprenderemos la manera de crear nuestro «Service Engine Group», además de crear los «Virtual Services» . Requiere de realizar algún pequeño paso previo, pero por lo general es un proceso bastante sencillo y nos ofrece una alta gama de variedades para crear nuestros «Virtual Services».
Introducción
Lo primero que nos podríamos preguntar es, ¿ Que es un «Virtual Service»?. Los «Virtual Services» son el core de AVI/ALB. Un «Virtual Server» puede ser considerado como una dirección IP en la que AVI/ALB está escuchando, es decir lista para recibir peticiones.
Mapa Deseado
Antes de comenzar a configurar nada, esta es la foto a la cual queremos llegar. Como vemos, tendremos una Service Engine que tendrá conectado 2 tarjetas de red, una al segmento de AVI-MGMT para su conexión con el clúster de AVI. Otra interfaz de red en el segmento de «LB segment», la que el denomina «Data Segment». Por ultimo el SE estará escuchando en la IP VIP que definiremos.
Por ultimo tendremos la red «Web Segment» donde esta alojados nuestros servidores nginx.
Configuración Service Engine Group
Una de las primeras cosas que haremos será crear el «Service Engine Group», para buscar un símil, es como un clúster de SEs. En este «clúster» de SEs es donde se ejecutaran nuestros virtual services. Los «Service Engine Group» que creemos pueden ser de diferentes características. Por ejemplo, unos pueden tener definido un modelo de HA, pueden tener diferentes «Sizing»,….
En este caso vamos a intentar simplificar todo, por ello vamos a crear nuestro primer «Service Engine Group» con casi las opciones por defecto. Para ello nos dirigimos a «Infraestructure –> Service Engine Group–> Create».(Importante esta sobre el Cloud de NSX-T)
Asignamos un nombre descriptivo, y en este caso seleccionamos el modelo de HA «N+M». Este modelo de HA, nos creara un SE de respaldo, para que en caso de que se nos caiga el service engine activo, todos los virtual services hagan «failover» sobre el pasivo. Esta es una forma rápida de resumirlo, pero tiene bastante mas miga detrás:)
En mi caso he seleccionado que como mucho un SE pueda albergar un maximo 10 «Virtual Services» y tengamos un buffer de 1. Con esto el AVI/ALB se encargara de tener minimo un SE con capacidad para 10 Virtual Services.
En este parte de aquí, podremos asignar un prefix a nuestros SE. En mi caso la única modificación que he realizado es la siguiente, si hay SE que no se estén usando, que se borren después de un minuto de inactividad. Ademas también podríamos definir el «Sizing» y otros parámetros mas avanzados.
Configuración Virtual Service
Una vez que ya tenemos donde alojar nuestros «Virtual Services», vamos a ultimar los últimos pasos antes de empezar a configurar nuestros «Virtual Services». Para ello nos vamos a nuestra Cloud de NSX-T, después a la parte de parte «Infraestructure» –> «VRF Context», y seleccionamos primeramente la VRF global, y pulsamos sobre el lápiz para editarla.
En este caso debemos asignar el GW que tendrán nuestra interfaz de MGMT de nuestras SEs. Recordar que este segmento lo creamos en post anteriores, y es la interfaz que usara para la conexión de nuestro SE con el clúster de AVI.
Una vez finalizado pulsamos sobre «Save».
Ahora nos vamos a la otra VRF, concretamente a la «StormCloud-Tier-1», y asignaremos el GW que tiene nuestra red de balanceo.
Ahora nos vamos a dirigir a la parte de «Network Profiles», para asignar el direccionamiento que tendrá nuestra red de MGMT de la VRF global y nuestra red de balanceo de la VRF StormCloud-Tier-1. Para que nos hagamos una idea, de estos direccionamientos que vamos asignar a continuación, el los utilizara para asignar a nuestros SEs a media que se vayan desplegando..
Se podría realizar también por un DHCP, pero este no ese caso.
Para empezar a crearlos pulsamos en «Create».
Asignamos el nombre de «AVI_MGMT», seleccionamos la VRF «Global» y pulsamos sobre «ADD».
En la parte de «Subnet Prefix», ponemos la red en formato CIDR, y pulsamos ADD. Ahora asignamos un rango de red para que tengan nuestro SEs como interfaz o como VIP.
Una vez hayamos guardado todo lo referente a la VRF global, pulsaremos sobre «Create». Asignaremos un nombre descriptivo, seleccionaremos el «StormCloud-Tier-1» como Routing Context, y pulsamos sobre ADD.
En mi caso aunque haya marcado las 2 opciones, yo solo lo voy a usar para que asigne IPs las interfaces de los SE, ya que para las VIP usare IPs de la red del segmento donde estén mis servidores(Esta parte se ve mas clara en el mapa).
Este seria el resumen de los 2 «Network Profiles» que acabamos de crear.
Ahora si ha llegado el momento de crear los «Virtual Services», en este primero caso, voy a crear un «Virtual Service» el cual se encargue de balancear sobre servidores web basados en NGINX. Por ello pulsamos sobre «Create Virtual Service».
Seleccionamos la Cloud de NSX-T.
Elegimos la VRF de StormCloud-Tier-1.
Asignamos un nombre descriptivo y sobre el apartado «VS VIP», pulsamos » Create VS VIP».
Asingamos una IP del segmento «Web Segment». Esto puede parecer raro, pero al «Virtual Service» no le voy asignar direccionamiento del segmento «LB Segment», lo podría hacer sin problema. Pero mi idea es que la VIP esta en el mismo rango que los servidores del pool. Esto puede confundir un poco, pero en el siguiente explicare como funciona por debajo los SEs y quedara todo mas aclarado.
Una vez tenemos asignada la «Virtual IP», en el apartado Services asignaremos el port 80, en este puerto es donde escuchara nuestro «Virtual Service».Ahora ha llegado el momento de crear el pool con los nodos donde se balanceara el trafico, para ello en el apartado de Pool, pulsaremos sobre «Create Pool.»
Asignaremos los siguientes campos:
- Nombre
- Load Balance Algorithm : Round Robin
- Tier-1 Logical Router : StormCloud-Tier-1
Añadimos la IPS de los nodos y pulsamos sobre «ADD».
En el apartado «Health Monitor», seleccionamos el monitor «System-HTTP»
En cuanto a la persistencia, no asignaremos ninguna, ya que queremos observar como balancea todos los nodo de manera correcta. Una vez hemos revisado todos los elementos, bajamos hasta abajo y pulsamos «Save».
Si todo esta bien, pulsamos sobre «Next».
En este apartado seleccionamos 2 opciones, la primera de ellas en «Real Metrics» asignaremos el valor de 0, para que envié nos todas las métricas en tiempo real, esto solo se debe configurar para pruebas. El otro parámetro que modificaremos será el de «Log all headers», para que nos envié todos los logs del trafico que el considere correcto. Una vez modificados estos parámetros, pulsamos sobre «Next».
En este apartado, seleccionaremos sobre el «Service Engine Group» el que hemos creado anteriormente y pulsaremos sobre «Save».
Ya tenemos nuestro «Virtual Service» creado, al ser primero que se aloja dentro del «Service Engine Group», este comenzara a desplegar los SeS por detrás dentro de nuestro vCenter. Esto mismo lo podemos observar en el mensaje que nos muestra con la exclamación.
Si nos vamos a nuestro vCenter, vemos que con el usuario «avivcenter» que lo creamos en post anteriores,esta desplegando los SEs.
Una vez estén desplegados nuestros SE, de primeras tendrá nuestro «Virtual Service» estará en uno como activo, mientras en el otro SE esta preparado para un posible failover.
Una cosa que debemos hacer, sobre todo si es nuestro primer «Virtual Service» que publicamos es redistribuir los «LB VIP Routes» y «SNAT IP Routes» tanto en el Tier-1 como en el Tier-0.
Para ello bastara con marca los siguientes checks en la parte de redistribución de rutas de los Tier-1 y Tier-0 respectivamente.
Tier-1
Tier-0
Una vez tenemos todos listo,ha llegado el momento de probar, si accedemos a nuestro navegador y ponemos la VIP que he hemos asignado a nuestro «Virtual Service», veremos que todo funciona a la perfección.
Conclusión
Hasta aquí hemos llegado en este post, como veis son unas cuantos pasos los que tenemos que tener en cuenta para tener listos nuestros «Virtual Services». En el siguiente post veremos como funciona todo desde que lanzamos la request hasta que esta vuelve al cliente, de esta manera entenderemos mejor porque necesitamos ciertos elementos y como interactuan entre ellos. Nada mas por hoy, nos vemos en el siguiente post.