¿Cómo conectarse a la API de NSX?

El 31 de diciembre es el último día de soporte de Adobe Flash. Por lo que la mayoría de los browsers van a dejar de ser compatible son flash y algunos productos no van a funcionar correctamente.
La mayoría de los vendors sacaron parches y upgrade paths para sus productos a modo de no tener dependencias fuera de soporte.
Yendo al caso puntual de VMware, hay un post de William Lam que detalla todo a la perfección. Adicionalmente en la KB 78589 hay más detalles.

Yendo al caso de NSX-V: Es un producto que originalmente fue concebido en flash y fue pasando gradualmente a HTML5 (UI)
La recomendación oficial de VMware en relación a NSX-V es actualizar a 6.4.8, pero el problema es que perdemos algunas capacidades, por ejemplo, administrar de forma gráfica el servicio SSL VPN dentro de los NSX Edges y las definiciones de servicio.
(En este post hay más detalles sobre el cambio de versiones a NSX-V 6.4.8)

Lo bueno, es que vamos a poder seguir operando con normalidad mediante la API de NSX.

¿Cómo me conecto a la API de NSX?

Requisitos:
Tener instalado y configurado un cliente API REST.
Por ejemplo, este tutorial lo hicimos con RESTer


Procedimiento:
1. Descargar el certificado del NSX Manager:
Abrimos una pestaña nueva y navegamos hasta el NSX Manager
Aceptamos el certificado o generamos una excepción de seguridad (Firefox)


2. Agregamos la autorización para el cliente API

3. Configuramos las credenciales con las que nos vamos a autenticar al NSX Manager

4. Agregamos el header accept con el valor “application/json” para evitar el formato xml

5. Ejecutamos la request que queramos y nos aseguramos que la respuesta sea HTTP 200 (Ok)

La petición que le hicimos a la API era para saber el estado de SSLVPN en un Edge en particular.
GET /api/4.0/edges/{edgeId}/sslvpn/config
Para ver un listado de requests a la API de NSX podemos usar este link https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/nsx_64_api.pdf
A partir de la página 460 tenemos documentación sobre SSL VPN.

6. Revisamos la respuesta.
Como la respuesta es en JSON podemos parsearla usando esta herramienta https://jsoneditoronline.org/

De este modo podemos conectarnos a la API de NSX para administrar SSL-VPN en nuestros edges.

Pasando de NSX-V a NSX-T

A fines de 2018 me tocó ser  parte de un proyecto que requería que aprenda y certifique toda la suite de NSX, en Enero de 2019 terminé de certificar el examen VMware Certified Advanced Professional – Network Virtualization 6 (Deploy) y pude trabajar con eso por algunos meses.
Entre abril de 2019 y mayo de 2020 estuve alejado de NSX por motivos laborales, durante ese año VMware decidió discontinuar la versión del producto que yo conozco (NSX-V) y darle foco a NSX-T, acompañando su visión Any App, Any Device, Any Cloud.
Para no quedarme atrás estuve investigando, y algo que me sirve a mi es hacer paralelismos con lo que entiendo.
En algunas líneas quiero compartir cuales son las diferencias entre NSX-V y NSX-T para que puedas “pasar tu conocimiento” haciendo algunas equivalencias y/o diferencias.

Arquitectura

Al igual que en NSX-V, NSX-T Cuenta con 3 planos (Management, Control, y Datos) pero en esta nueva versión hay algunas diferencias.

This image has an empty alt attribute; its file name is image-9.png

Management Plane

El Management Plane es el encargado de la administración de NSX. En NSX-V era un solo appliance (OVF) que después se registraba contra vCenter y hacia el deploy del control plane y preparaba los hosts, manteniendo un mapeo 1 a 1 entre el vCenter y el NSX Manager.
El deploy de NSX-T comienza del mismo modo (instalando un appliance) pero no requiere un vCenter para funcionar.
Adicionalmente ahora el NSX Manager está distribuido en un cluster de 3 virtual machines.
En la tabla a continuación podemos ver algunas diferencias entre ambos productos:

Sin embargo, el NSX Manager (Cluster) sigue siendo responsable de preparar hosts, crear nuevos logical switches, crear VMs de NSX Edge, al igual que proveer la API y la línea de comandos centralizada.

Control Plane:

La mayor diferencia entre NSX-V y NSX-T en relación al plano de control es el hecho de que ahora corre en las mismas  máquinas que el management Management Plane.
Adicionalmente al no existir el concepto de Distributed Logical Router, la máquina de control del DLR no es necesaria.

Plano de datos – Encapsulación y Switching:

La mayor diferencia entre NSX for vSphere y NSX Transformers a nivel encapsulación dejamos de usar el protocolo VXLAN y pasamos a usar el protocolo GENEVE.
Adicionalmente, NSX-V requeria MTU 1600 para funcionar y ahora requiere 1700.
A continuación dejo algunos detalles extra:

Respecto a los distributed switches, para NSX-T solo en entornos VMware se recomienda usar vSphere vDS, si vamos a usar KVM estamos limitados a usar N-VDS.

Plano de datos – L2 Bridging:

Una vez más, al no existir la VM del DLR, el Bridging se modifica y se crean los bridge nodes (dentro del kernel para los hipervisores).
Adicionalmente podemos crear bridge clusters para proveer redundancia.

Plano de datos – Routing:

Estas son algunas de las diferencias entre NSX-V y NSX-T a nivel routeo.

Esto me costó un poco entenderlo:
Tanto el Service Router como el Distributed Router existen dentro de los logical routers (T1 y T0)
Es decir, en un Logical Router T0 vamos a tener un componente del Distributed Router y un Componente del Service Router:
– El distributed router vive en el kernel de todos los hipervisores (al igual que el DLR)
– El service router vive en los edge nodes (debido a que hay servicios Norte-Sur que no son distribuidos, por ejemplo: NAT)

Adicionalmente, los Logical router Tier-0 corren sobre los recuirsos del Edge Cluster.

Plano de datos – NSX Edge

Ahora cada vez que creas un NSX Edge, vas a necesitar un NSX Edge cluster, como decíamos antes los Logical Router Tier-0 corren en los recursos del Edge Cluster, por más que tengas un solo NSX Edge, necesitas crear un Edge Cluster.
Otro cambio importante a nivel NSX Edge es que ahora podemos instalarlo sobre servidores bare metal y no solo como VMs. Esto es sumamente interesante si tenemos en cuenta el partnership de VMware con Nvidia, Project monterey y el avance de ESXi on ARM, ¿Te imaginas corriendo un NSX edge en un raspberry pi?, no es algo tan lejano.

Seguridad

Algunas de las mejoras a nivel seguridad.

Cabe aclarar que el identity firewall solo funciona con VMs windows que tengan active directory (Windows 10 y Windows 2019 están soportados)

Migración

De momento exiten dos modos de migración:
Migración en paralelo: en otras palabras significa tener NSX-V y NSX-T en paralelo, esta opción está buena si aprovechamos un recambio de hardware o un upgrade de versión.
La migración In place sirve para entornos que es dificil el recambio, esto es un estilo Lift and Shift.

2 Methods for VMware NSX Migration

VMware recomienda contactar a PSO para revisar los pasos previos a la migración.

Conclusión

Por más que NSX for vSphere es un producto super robusto, está limitado al SDDC de VMware vSphere.
NSX-T es un producto concebido para el Multi-Cloud, teniendo en cuenta productos Cloud Native como Kubernetes.
Como se prevee que para 2025 el 60% de las empresas van a tener sus Workloads en la nube, sería una buena idea empezar a considerar NSX-T para llegar al Multi-Cloud

Espero que te haya servido, por favor comentame que te pareció.

Saludos
N.

Guia de Backup NSX-V 6.4

Antes de arrancar, vamos a repasar rapido los 3 planos de acción de NSX.
El Management Plane son los componentes que nos permiten administrar la plataforma.
Es imporante entender que el NSX Manager tiene embebidos los templates de los controllers y los edges y está en constante sincronía con el control cluster) sumado a eso, las reglas de firewall distribuído se administran desde acá.

En el Control Plane es donde se administran las funciones del Distributed Logical Switch y el Distributed Logical Router. Por lo que mantiene la información de Switching y Routeo de los hosts consistente y actualizada.

En el Data Plane es donde se da la comunicación (Switching, Routeo y Firewalling). Esta compuesto del vSphere Distributed switch sumado a los componentes de kernel de NSX (VXLAN, Logical Switch, Logical Router, Distributed Firewall).

nsx-planes - jeffreykusters.nl

¿Por qué hacer un backup?

NSX no es más que las reglas de routeo, de firewall y la comunicación entre las maquinas virtuales de nuestro SDDC ¿Por qué haríamos un back-up, no?
No tener backup de NSX puede causar los siguientes problemas:
– Podrías perder acceso de administrador a las redes virtuales.
– Podrías perder las reglas de firewall.
– O lo que es peor podrías tener un incidente.
En el día a día de las operaciones de IT nos encontramos con dos tipos de backups. Backups para prevención de desastres (DR) o para salvaguardar cambios (Change Management).

¿Qué backupear?

Los componentes a realizar backup son los siguientes:

NSX Manager

vSphere Distributed Switches

Si bien hacer un backup de vCenter es igual de importante o más (ya que sin un vCenter perdemos toda administración de NSX-V). Lo voy a cubrir en otro post.

¿Qué pasa con los otros componentes?
Los NSX Edges son VMs stateless (se pueden redeployar a voluntad) y su configuración se guarda en el NSX Manager.
Los NSX Controllers guardan la información de VXLAN, lo que los hace importantes. Pero al estar desplegados en clusters de 3 puede haber uno desconectado (o todos si esta CDO habilitado) por lo que los convierte en componentes prescindibles. Sumado a eso su configuración esta guardada en el NSX Manager y se pueden desplegar y sincronizar en minutos.
Por último, VMware solo soporta el backup de controllers y edges a traves del NSX Manager. (https://kb.vmware.com/s/article/2144087)

NSX Manager – File based backup

El file based backup se configura desde el portal de administración del NSX Manager.
En este link te dejo un documento que explica como configurarlo.
Algo a tener en cuenta: el file based backup no tiene rotación de archivos. Por lo que tendrías que crear una tarea programada o algo similar para limpiar los archivos luego de 2 semanas.

Es importante que usemos SFTP como protocolo de transferencia.
Yo personalmente recomiendo hacer backups del SFTP share con una herramienta de terceros.

¿Cada cuánto hacer los backups?
Como siempre, depende del tamaño y la criticidad de tu deployment.
En este caso particular vamos a hacer los backups automaticos todos los días a las 23:00 hs

En caso de un cambio, simplemente tenemos que ejecutar un backup on demand. Haciendo click en el boton Backup.

¿Cómo restaurar el backup?

Para restaurar un backup vamos a tener que hacer un deploy de un NSX Manager nuevo (en la misma versión) y configurar el SFTP server al que estamos haciendo backup en la parte de Backup & Restore una vez hecho esto nos aparecera la opción restore.

VMware NSX - Backup & Restore VMware NSX Manager Data

Para mas detalles dejo este link

vSphere Distributed Switches

Como ya hablamos antes, NSX corre sobre vDS:
Hacer un backup de un vSphere Distributed Switch es bastante facil. No obstante es importante porque si llegamos a borrar un portgroup y tenemos que recrearlo, tendríamos que recrear también todas las politicas especificas de ese portgroup.
Para hacer un backup on demand de un vDS

Hacemos click derecho en el vDS –> Settings –> Export Configuration.


Lo que va a abrir este wizard.


Seleccionamos la opción Distributed Switch and all portgroups.
Esto nos va a devolver un archivo backup.zip

Ahora, hacer este proceso todos los días es algo tedioso.
Por suerte tenemos este script de PowerCLI que nos permite exportar la configuración de los vSphere distributed switches de forma automatizada.

Vamos a necesitar un host que corra PowerCLI y en el que podamos correr tareas programadas.

Respecto al schedule del script.
Nuevamente es un gran “depende”.
Si en tu infraestructura no propagan nuevos portgroups o logical switches seguido, podes hacerlo cada una vez por mes o on demand. En este caso como se hacen cambios bastante seguido lo estoy corriendo una vez por semana.


Restaurar un vSphere Distributed Switch

Para restaurar un vDS nos paramos en el vSphere Distributed Switch –> Settings –> Restore configuration.

Esto nos va a abrir un wizard que nos va a pedir el archivo de backup.

Seleccionamos el archivo backup.zip y la opcion restore distributed switch and all portgroups. y hacemos click en next.

Nos va a dar un resumen de las configuraciónes que va a aplicar. Hacemos click en finish va a ejecutar el restore.

¿Por qué no usar herramientas de terceros?

De hecho me parece perfecto agregar un punto extra de backup. Aunque no es del todo necesario.
Tengamos en cuenta lo siguiente:

1. No hagas backup de los Controllers, Edges y DLRs como maquinas virtuales. Simplemente usar el NSX manager.
2. Si vas a hacer backups del NSX Manager y usas una herramienta con VADP no uses quiescing.
3. Hacé backups del ftp share.


Espero que les haya servido.

Cualquier duda o consulta me pueden contactar.