Buenas! En el día de hoy venimos con la segunda y ultima parte de como «Utilizar NSX ALB para el NSX-T Management Clúster – Parte 2 «, si te perdiste la parte 1, aquí la tienes. Básicamente en esta segunda parte veremos como crear los Virtual Services e incidir en algunos aspectos los cuales considero importante.
Introducción
En en el anterior post vimos todo lo relacionado con:
- Diferencia entre Cluster VIP y External Load Balancer
- Generar los CSR y las private Key
- Pedir un certificado a nuestra CA para nuestro entorno de NSX
- Introducir la CA tanto en nuestro entorno de NSX como en AVI
- Introducir el certificado tanto en nuestro entorno de NSX como en AVI
- Asignar el certificado a los nodos del clúster, así como al servicio del clúster en si
En el día de hoy nos vamos a meter de ello en crear los Virtual Services, recordar que crearemos dos. Uno para la GUI con persistencia y otro para la API. Alguno se preguntara ¿ Porque dos?. Cuando tenemos múltiples productos que atacan a la API de NSX, no ganamos nada teniendo la persistencia hacia un nodo. Por el contrario si NO hacemos uso de la persistencia, todo estas llamadas a la API se balancearan de una manera mas equitativa entre los diferentes nodos, así evitaremos la saturación de un nodo en concreto.
Nada mas que añadir, vamos a crear esos Virtual Services.
Configuración
Al ser un VS que no estara bajo el paragua del NSX Cloud sino mas bien bajo una VLAN física, deberemos añadir la cloud de VMware vCenter/vSphere ESX. Para ellos nos vamos a Infraestructure –> Clouds–> Create y seleccionamos » VMware vCenter/vSphere ESX»
Indicamos un nombre descriptivo para nuestro vCenter.
Introducimos la IP de nuestro vCenter y las credenciales. En este caso, al estar trabajando sobre un vCenter que no suelo hacer grandes cambios utilizare el usuario «Administrator». Este tipo de usuario no lo debemos utilizar bajo ninguna circunstancia, ya que en caso de usarse mal o cometer algún, no sabríamos quien habría sido. Siempre lo mejor en entornos productivos, usar usuarios nominales.
Seleccionamos el » Data Center», marcamos «Use Content Library», seleccionamos una que hayamos creado y pulsamos «Save & Relaunch».
Seleccionamos, primeramente la VLAN de gestión que tendrán nuestros SEs( esta se podrá modificar cuando creemos el SEG) y por ultimo añadimos un rango de IPs para que las pueda asignar .
Ahora nos vamos a la parte para crear los Service Engine Group, pulsamos sobre «Create».
En esta primera parte asignamos un nombre descriptivo.
En mi caso seleccionamos «N+M» como «High Availability Mode» y un maximo de 2 SEs. Como os comente anteriormente en este apartado tenemos la parte donde modificar la red de «Management» de nuestros SEs.
Una de las cosas que me parecen mas útiles es asignar un «Service Engine Name Prefix» que sea bastante descriptivo. Esto es útil sobre todo para entorno grandes.
El resto de campo a gusto o necesidades de cada uno, en mi caso las SEs serán desplegadas con 1 vCPU y 4 GB de memoria RAM.
En la parte de «Scope», seleccionamos el clúster y el almacenamiento donde queremos que se desplieguen nuestras SEs.
Una vez rellenados todos los campos necesarios, pulsamos en «Save». Ahora ya tenemos nuestro SEG disponible para albergar Virtual Services (Recordar que estos no se despegan hasta que se cree el primer VS).
Virtual Service para GUI
Recordar que este » Virtual Service » será utilizado para que los usuarios puedan hacer uso de la interfaz grafica(GUI), lo que lo hará diferente del otro es que este VS tendra persistencia, y el utilizado para las API CALL no.
Para crear este primer «Virtual Service» nos dirigmos a «Applications» y pulsamos sobre «Create Virtual Service»–> «Advanced Setup «–> Seleccionamos el Cloud de VMware.
En esta primera parte asignamos un nombre descriptivo y seleccionamos el «System Secure HTTP» como Application Profile. En la parte de Services, ponemos el puerto 443 y marcamos el SSL.
Ahora nos vamos a la parte de SSL Profile y seleccionamos «System Standard», por ultimo seleccionamos el certificado que hemos importado anteriormente en el apartado SSL Certificate, en mi caso le llame «nsx manager».
Pasamos a crear la VS VIP, bajo el apartado VS VIP, pulsamos en la flechita y en «Create VS VIP».
Pulsamos en» Add».
Asignamos la IP que considremos oportuno(recordar crear DNS asociado a esta IP) y nos vamos al apartado de «Placement Network» y volvemos a pulsar «Add».
Seleccionamos la red bajo la cual esta nuestra IP que acabamos de asignar. En mi caso tanto los nodos de NSX están bajo la misma red, por lo tanto la VIP también lo estará.
Una vez hemos seleccionado la red, pulsamos «Save».
Comprobamos que todo esta bien, y pulsamos en «Save».
Ahora nos vamos a la parte de «Pool», asignamos el 443 como » Default Server Port» y elegimos el método de balanceo que nosotros queramos.
Bajo el apartado «Placement Server Network», seleccionaremos todas las redes bajos las cuales están nuestros NSX Managers. En mi caso todos ellos residen bajo la misma red, por lo tanto solo seleccionare una.
Añadimos los NSX Nanagers al pool.
En la parte de «Health Monitor», pulsamos sobre los 3 puntitos y pulsamos sobre «Create».
Asignamos un nombre descriptivo y seleccionamos el «Type» HTTPS.
En la parte de «Client Request Header» bajo el apartado de «User Input» deberemos añadir lo siguiente:
Hay que tener en cuenta que el «Header» de «Authorization» debe ir codificado en base64. Para ello podemos usar la siguiente pagina https://www.base64encode.net .
GET /api/v1/reverse-proxy/node/health HTTP/1.1 Content-Type: application/json;charset=UTF-8 Authorization: Basic YWRtaW46Vk13YXJlMSFWTXdhcmUxIQ== Accept: application/json
En la parte de «Server Response Data» bajo el apartado «User Input» añadiremos lo siguiente:
"healthy" : true
Además tendremos que configurar «2xx» como «Response Code». Por ultimo marcaremos el check de » Enable SSL Attributes» ademas de «System Standard» como «SSL Profile».
Por ultimo pulsamos «Save» para guardar.
Seleccionamos» el «Health Monitor» «que acabamos de crear.
Aquí vienen 2 apartado muy importantes. En el primero de ellos seleccionamos el tipo de persistencia. Para este primer Virtual Service el cual contendrá la GUI y que dijimos que necesitaría persistencia, seleccionaremos «System-Persistence-Client-IP».
Por otro lado para realizar para que el VS sea SSL End to End, seleccionaremos «System-Standard» como «SSL Profile». De esta manera la conexión también estará encriptada entre el SE y los NSX Managers.
Ya tenemos casi todo listo, repasamos si todos los datos están bien y nos vamos a la parte de «Advanced».
Seleccionamos el SEG que creamos anteriormente y pulsamos en «Save».
Aquí tenemos una imagen visual del «Virtual Service» .
Ahora ha llegado el momento de probar nuestra nueva VIP, una vez que cargamos la nueva URL » https://nsxt-manager-vip.vmwarelab.local», podemos observar que el certificado que hemos añadido en tanto en AVI se carga de forma satisfactoria.
Si accederíamos a un nodo de forma individual utilizando su FQDN, también nos saldría el certificado de forma correcta, esto es así, ya que recordar que añadimos las 2 VIP y los 3 nodos de NSX en el certificado.
Virtual Service para API CALL
Por ultimo este » Virtual Service » será utilizado para las API CALL , de esta manera todos los productos que integremos contra NSX, podrán hacer uso de este VS, así las API CALLs serán distribuidas entre todos los nodos del pool de manera mas eficiente, gracias a que no tendrá persistencia.
Un consejo es que puedo dar, es que antes de que cambies los productos que atacan a la API, que os aseguréis de que no necesitan persistencia, por ejemplo el NSX ALB(AVI), no es compatible con este tipo de VS.
Para configurar este VS deberemos realizar los mismo pasos que con el anterior VS, con la única diferencia que en la parte de Pool en el apartado de «Persistence», no será necesario seleccionar nada.
Una vez lo hemos creado,en la siguiente imagen podemos observar que tras lanzar un script, las llamadas a la VIP de la API se distribuyen de manera equitativa entre los NSX Managers.
Por ultimo, para mi una de las mayores ventajas es que podemos ver todas las llamadas que se realizan tanto en una VIP como en la otra. Si os fijáis en esta «Request» en la parte de URI, podemos observar como queremos obtener información sobre un «Transport Node».
Esto nos puede venir bien de cara a los siguientes motivos:
- Cantidad de llamadas por cliente
- Que tipo de agente(User Agent) esta realizando las llamadas
- Tipos de «Request» que lanzan (GET,HEAD…)
Conclusión
Hasta aquí hemos llegado en este segunda y ultima parte. Ya tenemos nuestros nodo de NSX con su certificado firmado por la CA, además de tener 2 VIP, cada uno de ellos, para un uso especifico. La verdad que una de las mejores cosas que tiene crear este balanceo como capa 7(L7), es que tendremos capacidad para ver todas las API CALL que se realizan contras ambas VIPs. De esta manera tendremos una visión sobre lo que ocurre contra nuestros NSX Managers. Quizá en algún otro post veamos como limitar el uso de la VIP GUI para uso exclusivo de navegadores. Añadir que seria necesario vigilar de alguna manera, que nadie ataque a los nodos de manera individual, sino todo este esfuerzo no valdría para nada. Espero que os haya gustado y nos vemos en el siguiente post.