¿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.

¿Que tener en cuenta a la hora de implementar vSphere?

Hace algunos meses que estoy entrando día a día a VMTN (VMware Communities) y veo que muchas de las preguntas son del índole de ¿Puedo instalar ESXi en X hardware? o Instalé vCenter y no anda como espero.
Muchos de esos posteos son de usuarios que están probando vSphere por primera vez o de gente que no es nativa de la virtualización, no obstante, este post tiene como objetivo ayudar a todos los que están dando sus pasos en el mundo de la virtualización.

Diseño

La parte más importante de cualquier proyecto, en cualquier rubro, es el planeamiento.
Cuanto más tiempo pongamos planeando las cosas menos vamos a tener que poner arreglando problemas derivados de diseños fallidos.
Te dejo algunas preguntas que podes hacerte a la hora de empezar un proyecto de vSphere.

Análisis inicial

¿Para que quiero hacer esta implementación? Puede ser que quiera hacer un recambio de hardware por obsolescencia, puede ser que quiera desarrollar un proyecto de Hybrid Cloud o algo similar.
De este análisis inicial van a salir los requerimientos iniciales del proyecto, por ejemplo:
¿Cuántas VMs vamos a alocar en nuestros clusters?
¿Qué máquinas van a correr en mis clusters? No es lo mismo a nivel recursos correr un cluster de VDI que un cluster de Kubernetes o una base de datos Oracle.
¿Cuántos datos podemos ubicar en nuestro storage?
¿Puedo aceptar contención de recursos?
¿Cuánto voy a crecer por año?
¿Necesito un solo sitio? ¿Necesito más de un sitio?

Hardware

Un proyecto de virtualización depende del hardware que se use, algunas de las preguntas que podemos hacernos antes de adquirir el hardware son:
¿Qué tipo de servidores vamos a usar? (Blades/Rackeables/HCI) ¿Vamos a adquirir hardware nuevo? ¿Vamos a actualizar el hardware existente?
¿Cuántos CPU’s necesitamos? ¿Qué procesadores vamos a usar? ¿Cuántos cores voy a tener?
Estas primeras preguntas van a ser clave. Tené en cuenta que dentro de un mismo cluster lo ideal es tener hosts de la misma versión de ESXi y que los procesadores sean de la misma marca y familia (por EVC)
¿Cuánta memoria necesitamos?
¿Cuántas NICs necesito? ¿Cuántas HBA? Como mínimo siempre 2 para tener redundancia
¿Qué versión de vSphere voy a implementar?
¿Necesitamos algún tipo de hardware especial? (Placas de video, Hard Tokens, etc)
¿Tengo lugar en el datacenter? ¿Tengo suficiente capacidad en los racks? ¿Me alcanza la capacidad de computo? ¿Tengo puertos libres en los switches?
¿Dónde voy a instalar mi host? (Disco Local, SATADOM, SD, etc )
¿Voy a armar RAID para los discos locales? ¿Qué RAID?

Algo que me parece super importante aclarar, no podemos ir a instalar ningún servidor sin antes haber chequeado la matriz de compatibilidad (más ahora, ya que vSpher 7 no usa más los drivers VMKlinux como en versiones anteriores). Si nuestro proyecto usa vSAN podemos chequear la matriz de compatibilidad de vSAN o usar hardware vSAN ready.

Storage

¿Qué tipo de storage vamos a usar? (SAN/iSCSI/vSAN/NFS)
¿Vamos a adquirir hardware dedicado o tenemos que usar el hardware existente?
Cada tipo de storage tiene sus ventajas y sus limitaciones, por ejemplo, el storage SAN suele sumar complejidad a la administración (Zoning), mientras que iSCSI es más sencillo.
SAN tiene una red dedicada (con su propio protocolo) mientras que vSAN, iSCSI y NFS usan la red LAN. Por consiguiente, sumando tráfico a las NICs del servidor.
¿Necesito una solución metro?
¿Tengo suficientes puertos de SAN disponibles? (si es que los uso)

Networking

Algunas de las preguntas importantes a nivel redes
¿Voy a usar NSX?
¿Cuál es el troughput de mis equipos?
¿Cuántas VLANs administro?
¿Cómo está configurado MTU?
¿Tengo configurado CDP o LLDP?
¿Voy a usar algún mecanismo para prevenir loops (STP)?
¿Tengo suficientes puertos disponibles en los switches de red?

Estas respuestas nos van a decir como tenemos que configurar nuestros switches de vSphere.

vSphere

¿Qué servicios voy a necesitar? ¿Voy a tener solo ESXi? ¿Voy a tener vCenter? ¿vSAN? ¿vROPs?
¿Necesito más de un vCenter?
¿Necesito priorizar la disponibilidad?
¿Mis aplicaciones pueden tolerar un reinicio o no es aceptable?
¿Cuántos hosts caídos puedo tolerar?
¿Cómo van a bootear mis hosts? (Stateless vs Stateful)

Esta información te va a ayudar a determinar, entre otras cosas, cual es la licencia que necesitas.

Estas son algunas (porque siempre hay más) de las preguntas que tenemos que hacernos para empezar a diseñar una solución de vSphere que sea de calidad y resiliente a fallos.

A la hora de la implementación yo tengo este checklist para validar que todo esté listo para instalar y evitar perdidas de tiempo.

Una aclaración importante: Que algo no esté soportado en la matriz de comptabilidad significa que VMware no te va a aceptar los casos de soporte, no que no va a funcionar.
Por ejemplo, correr ESXi en modo nested no está soportado y se recomienda no correr VMs productivas, pero si lo usas para laboratorios está perfecto.

Espero te haya servido
Saludos

Nacho

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.

vSphere Availability Basics – Storage vMotion

This is the second in a series of posts discussing about VMware vSphere Availability features, how do they work and what are their requirements.
Please keep in mind, the intended audience for this posts are Sysadmins that want to know a little more about vSphere. If you have been working with VMware products for a while you might find this post kind of boring.

In my last post of the series I spoke about vSphere vMotion but that’s not the only way of migrating VMs arround in VMware environments.
I would like to discuss a few of them.

Storage vMotion

Storage vMotion was introduced in VMware Infrastructure (ESXi 3.5) and it is a feature that allows administrators to move Virtual Machines across different datastores without powering off a virtual machine.

Compatibilidad de Storage vMotion en VMware vSAN

Some of it’s key features are:
– Workload migration across different physical LUN’s.
– IOPS load balancing (With sDRS Datastore clusters).
– Storage Capactiy Management.
– The ability to perform maintenance on phyisical storage without downtime.

How Does it work?
Before I explain that, please take a look at this post regarding what files compose a virtual machine.
The process is the following

  1. The user selects a VM to be migrated and a destination datastore. (Thus defining source and destination datastores and files to be migrated).
  2. VM folder is copied to the destination datastore. (That includes all VM files but VMDK’s)
  3. Once all files are copied a “shadow VM” is started at the destination DS and it’s idled waiting for VM disk file(s) to finish copying.
  4. During the disk file transfer all changes to the files are tracked with changed block tracking (CBT).
  5. svMotion iteratively repeats the CBT process during data transfer.
  6. Once the ammount of outstanding blocks is small enough, svMotion invokes a FSR (Fast Suspend and Resume) similar to the stun on vMotion. To transfer the running VM to the idle “shadow VM”
  7. After FSR finishes files on the source datastore are deleted and space is reclaimed.

Considerations:

  • Storage vMotion can be used to rename VM folders and files on datastores.
  • It can also be used to change VM disk provisioning.
  • Before the svMotion process is initiated a target datastore capacity check is done, so you can’t migrate a VM in a full datastore.
  • svMotion is “storage agnostic” meaning it can work with anything that can provide a VMware datastore. (iSCSI, FCoE, vSAN, NFS, NAS, etc)
  • svMotion might cause issues on IO intensive applications such as databases. Please keep that in mind.
  • The max concurrent svMotion migrations is 16, nevertheless doing this can cause performance degradation on the storage array.
  • While vMotion requires a dedicated vmkernel TCP/IP stack for traffic. Storage vMotion migrates data two ways: over FC switches in case you are using Fiber Channel or using Management or Provissioning interfaces.

Requirements and limitations:

  • You need vCenter to do a storage vMotion
  • ESXi host in which the VM is running must have access to source and destination datastores.
  • ESXi on which the virtual machine is running must have at least Standard licenses.
  • Storage vMotion during VMware tools installation is not supported.
  • VM disks must be in persistent mode. If you are using RDM’s you can migrate the mapping file if it is phyiscal or virutal (if it is virtual you can change it’s provisioning) but not the data.

¿Cómo preparar el VCP-Data Center Virtualization 2020?

Después de más de un año sin rendir certificaciones me decidí a ponerme al día y prepararme para el VCIX-DCV.
Lamentablemente, por los cambios en las políticas de certificación de VMware me di cuenta que mi VCP-DCV6 estaba vencido y no iba a servir.

Al tener una certificación VCP-DCV6, no me era necesario rendir el examen vSphere 6.7 Foundations ni asistir a ningún curso. Por lo que directamente agendé el examen delta de vSphere 6.7. Con esto ya tenía una fecha limite, a partir de eso empecé a trabajar.

Lo primero que hice fue descargar la guía de del examen. En base a esa guía separé los temas en 3 “pilas”: Lo sé, no lo sé, hace falta un repaso. Entonces, por ejemplo: SIOC y NIOC entraron en la pila de lo sé, Fault Tolerance entró en la pila de repaso y temas como vCenter HA o VM encryption en la pila de no lo sé. Siendo la ultima pila la de mayor prioridad.

Desde la documentación oficial de VMware leí la teoría para cada tema en las pilas de repaso y no lo sé, también aprovechando la oferta de VMware Learning Zone gratis por seis meses elegí ver los videos de Exam Prep (hay uno para el foundations si tuvieras que prepararlo), hay un video por cada objetivo.
Entonces, por ejemplo, Para el objetivo 1.2 – Identify vCenter high availability (HA) requirements leí todo lo referente a vCenter HA hasta estar seguro de que lo había entendido y después me vi el video relacionado del Exam Prep donde un instructor te da tips del estilo de:
¿En qué se diferencian vCenter HA y vSphere HA? ¿Cuántos componentes tiene? ¿Cuáles son los requisitos?


El día del examen rendí remoto con el modo proctored de Pearson Vue (en otro post te cuento la experiencia). El examen son 40 preguntas multiple choice y es en inglés, tenes 90 minutos para rendirlo (la página dice 75, pero te dan unos minutos extra por no ser un país donde el inglés es el idioma oficial). Por referencias de conocidos, el nivel de inglés puede afectar tu performance en el examen. Personalmente no me pareció dificil, muchas de las preguntas vienen desde vSphere 6.0 y al tener experiencia con la solución salen fácil. Una vez terminas con las preguntas podes revisarlas todas o directamente ir a la devolución.
Al temrinar el examen sabes la nota, yo me saque 462/500 y la nota minima para aprobar es 300, también te podes imprimir el resultado. Más o menos a las 24 horas VMware me mandó el badge de la certificación mediante YourAcclaim.

VMware Certified Professional - Data Center Virtualization 2020

En esta crónica te conté mi forma de preparar esta certificación, que en mi caso puntual ya había rendido antes y es un producto con el que tengo experiencia. Como siempre digo, es mi forma de hacer las cosas, no quiere decir que sea la única, simplemente es la que a mi me funciona.

Gracias por leer
Por favor contame que te pareció el articulo.

Nacho