Utilizar NSX ALB para el NSX-T Management Cluster – Parte 1

Buenas chic@s! En el día de hoy vamos a iniciar una serie de dos posts, sobre como utilizar NSX ALB para el NSX-T Management Cluster, con certificados emitidos por nuestra propia CA. Además vamos a explorar la características/limitaciones de usar un balanceador externo, o la posibilidad de usar el «Cluster VIP» que nos proporciona NSX.

Introducción

Cuando desplegamos nuestro clúster de NSX, una de las dudas que nos surge es como vamos balancear el trafico entre los 3 nodos. Lo primero que hay que dejar claro es que los 3 nodos se pueden atacar de manera individual tanto a la GUI/API, obviamente esto no escalable ni manejable, es por ello que tenemos que tener alguna manera de solucionarlos. NSX nos presentar 2 formas:

• Clúster VIP :
  • Características
    • Fácil de configurar.
    • Una única para acceder tanto a la API/GUI
  • Limitaciones
    • Sólo se puede utilizar cuando las instancias de NSX-T Manager se despliegan con adyacencia L2.
    • Siempre se vincula a una de las instancias de NSX-T Manager (conocido como «Leader»), no equilibra las peticiones(API/UI) entre los managers.
    • En caso de caída del nodo «Leader», la convergencia a otro nodo tarda entre 60 a 90 segundos para la API/UI.
    • Plantea un problema de escalabilidad, especialmente con las aplicaciones que generan demasiadas solicitudes de API contra el clúster del gestor NSX-T.
    • En una arquitectura típica L3 Leaf-Spine sin extensibilidad L2 entre chasis, esto también significaría que las instancias de NSX-T Manager tienen su límite de clúster a nivel de chasis.

• External Load Balancer:
  • Características
    • Una única para acceder tanto a la API/GUI.
    • Soporta direccionamiento L2/L3.
    • UI/API siempre disponible ante la caída de un nodo o dos nodos.
    • Posibilidad de poner en mantenimiento sin perdida de servicio.
    • Capacidad para crear una segunda VIP solo para las «API CALL» y balancear mejor el trafico aun mas, ya que no necesitaría persistencia a diferencia del creado para el GUI.
  • Limitaciones
    • Requiere de una solución externa.
    • Dependiendo del software, complejo de configurar.

Una vez visto la 2 formas, para mi la gran diferenciación es el tamaño del entorno así como el uso que se daría a la API. Si es un entorno pequeño, optaría por Cluster VIP. En cambio si tenemos un entorno grande, optaría por el uso de un balanceador externo por delante. Esto es así, ya que si tenemos productos que ataquen a la API, usando el método «Cluster VIP» seguramente el nodo «Leader» se vería afectado por un uso de CPU alto (generado por la abundante cantidad de «API CALL»), lo que finalmente se vería con una degradación de la manejabilidad y del rendimiento.

Una vez hecha la introducción, y haber explicado los 2 métodos que nos proporciona NSX para balancear las peticiones, es hora de entrar al barro. En este post y el siguiente, vamos a realizar los siguientes objetivos:

• Generar los CSR y las private Key — Parte 1
• Pedir un certificado a nuestra CA para nuestro entorno de NSX — Parte 1
• Introducir la CA tanto en nuestro entorno de NSX como en AVI — Parte 1
• Introducir el certificado tanto en nuestro entorno de NSX como en AVI — Parte 1
• Asignar el certificado a los nodos del clúster, así como al servicio del clúster en si — Parte 1
• Crear 2 «Virtual Services» capa L7 que balanceen sobre nuestros nodos de NSX. — Parte 2
  • Un «Virtual Service» será para acceso GUI y el otro para acceso a la API.
  • La gran diferencia es que uno tendrá persistencia(GUI) y el otro no(API)

Vamos al lio 🙂

Configuración

Lo primero que haremos seria mediante el uso del Open SSL generar una solicitud de CSR para después enviarla a nuestra CA. Empezaremos creando la «Private Key» mediante el siguiente comando:

openssl genrsa -out nsx.key 2048

Ahora generamos un archivo de configuración(nsx.cnf) mediante VI que contenga los siguientes datos, siendo los mas importantes los siguientes datos:

• commonName : En este caso será el nombre principal del certificado, esta caso la VIP de los manager de NSX.
• subjectAltName : Añadiremos todo los nombres secundarios, aquí volveremos a meter el FQDN de la VIP, así como la otra VIP para la API y por los últimos los 3 nombres de los manager.

[ req ]
default_bits            = 2048
encrypt_key             = no
default_md              = sha256
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
countryName         = ES
stateOrProvinceName = MICASA
localityName        = ES
organizationName    = STORMCLOUD
organizationalUnitName = ST
commonName          = nsxt-manager-vip.vmwarelab.local
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = nsxt-manager-vip.vmwarelab.local
DNS.2 = nsxt-manager-api.vmwarelab.local
DNS.3 = nsxt-manager.vmwarelab.local
DNS.3 = nsxt-manager-dos.vmwarelab.local
DNS.5 = nsxt-manager-tres.vmwarelab.local

Una vez tenemos la «Private Key» y el archivo de configuración que hemos llamado nsx.cnf , lanzamos el siguiente comando para generar la solicitud CSR.

openssl req -new -sha256 -out nsx.csr -key nsx.key -config nsx.cnf

Aquí tenemos el CSR, el cual copiaremos. Importante copiar desde los guiones del principio hasta el final.

Ahora nos dirigimos a nuestra CA(En mi caso me he montado una utilizando Microsoft Server 2022), y pegamos el CSR y pulsamos enviar para que nos genere el certificado.

Ahora nos descargamos el certificado generado tanto en formato DER como en Base64.

La imagen de abajo nos muestra el certificado de nuestra CA empresarial, este certificado, al igual que el anterior nos lo tenemos que descargar tanto en formato DER como en Base 64. Importante tener la CA instalada en nuestro equipo en entidades de raíz de confianza, sino el certificado no podrá ser ser validado cuando carguemos la URL de la VIP de NSX.

Por este lado tenemos nuestra CA en formato Base 64.

Por otro lado tenemos el certificado que hemos generado en formato Base64.

Aquí tenemos la clave «Private Key» que hemos generado anteriormente en formato Base64.

Ahora ha llegado el momento de importar los certificados en el NSX Manager así como en el balanceador AVI(NSX ALB).

Empezaremos implantándolos en AVI, para ellos nos vamos «Templates»–>»Security»–> «SSL/TLS Certificates»–> «Create»–> «Root/Intermediate CA Certificate».

Asignamos un nombre descriptivo y pegamos el certificado, pulsamos en «Validate» y «Save».

Aquí vemos como ya la tendríamos agregada.

Ahora para añadir el certificado que usara el VS(Virtual Service) de NSX, repetimos casi los pasos anterior pero pulsamos sobre «Application Certificate»

Asignamos un nombre descriptivo y en «Type» pulsamos sobre «Import».

Pegamos el certificado primero y en el segundo campo la key. Si hubiéramos generado el certificado con «Key Passphrase» también deberíamos añadirlo, no ha sido mi caso.

Pulsamos en «Validate» y comprobamos que el certificado es el correcto.

Ahora nos vamos a la parte de NSX para repetir el mismo proceso. Una vez que nos hemos logueado nos vamos a al parte «System»–> «Settings»–> «Certificates» –> «Import CA Certificate».

Asignamos un nombres descriptivo, deseleccionamos «Service Certificate» y pegamos el certificado de nuestra CA.

Ahora repetimos los pasos pero elegimos la opción de «Certificate».

Asignamos un nombres descriptivo, deseleccionamos «Service Certificate» y en la parte de «Certificate Contents» añadimos el certificado de la siguiente manera:

• Primero el certificado propio
• Después cualquier CA intermedia que hubiera
• CA Raiz

Todo estos certificados deben estar en Base64.

En mi caso pego primero el certificado generado, y después el certificado de la CA. Por ultimo pegamos la «Private Key» en el campo «Private Key» y si tendríamos «Passphrase» también.

Ya tenemos en NSX tanto la CA empresarial, como nuestro certificado de NSX.

Ahora he llegado el momento de aplicar este certificado a nuestros nodos, para ello vamos a lanzar la siguiente «API CALL» para comprobar que el certificado importado es valido.

GET https://<nsx-mgr>/api/v1/trust-management/certificates/<cert-id>?action=validate

Una vez validado el certificado, una de las preguntas que nos tendremos que hacer es, ¿ Donde lo tenemos que modificar?. No hace mucho hicimos un post sobre los certificados de NSX.

En este caso tenemos que cambiar los certificados del tipo API(cada nodo tiene el suyo) y el certificado de MGMT_CLUSTER. Si quieres tener mas información sobre los certificados de NSX, por aquí te dejo un enlace.

Empezaremos por el de API, para ello lanzaremos la siguiente API. Recordar lanzar una por cada nodo, modificando lógicamente el Node ID.

POST https://<nsx-mgr>/api/v1/trust-management/certificates/<cert_id>?action=apply_certificate&service_type=API&node_id=<nodo>

Ahora llevaremos a cabo el certificado relacionado con el MGMT_CLUSTER, este solo se lanza una vez y de la siguiente forma.

https://<nsx-mgr>/api/v1/trust-management/certificates/<cert_id>?action=apply_certificate&service_type=MGMT_CLUSTER

Como vemos, ya tenemos funcionado NSX con el certificado creado anteriormente. Hasta aquí hemos llegado esta primera parte, en la segunda nos meteremos de lleno en todo lo relacionado con crear las 2 VIP, tanto la principal que la usaremos como GUI como la que dará servicio a la llamadas de las APIs.

Conclusión

Espero que os haya gustado, como veo son unos cuantos paso para esta primera parte, no es complicado pero hay que tener claro como proceder. Nos vemos en la segunda parte.