Guía para actualizar el cluster de Kubernetes (K8s) del NAPP

en 31 octubre, 20245 noviembre, 2024 por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

CONTENIDO

Este post está dirigido para quienes tienen la necesidad de actualizar la versión del clúster de Kubernetes que soporta la solución NSX Application Platform (NAPP). La cual debe estar siempre alineada con la matriz de interoperabilidad de VMware. El proceso que vamos a describir a continuación también debe ser realizado cuando vayamos a realizar una actualización de NSX (que utilice NAPP), vCenter (con vSphere with Tanzu) o VCF (con Workload Management habilitado) para evitar romper la integración con los clústeres de Kubernetes (K8s).

Que es el NAPP

NSX Application Platform (NAPP) es una plataforma basa en microservicios que aloja varias funciones de NSX que recopilan, incorporan y correlacionan información de tráfico de red. A medida que se generan, capturan y analizan los datos en su entorno NSX, NSX Application Platform proporciona una plataforma que puede escalar dinámicamente en función de las necesidades de su entorno.

La plataforma puede alojar las siguientes funciones de NSX que recopilan y analizan los datos en su entorno NSX-T.

VMware NSX® Intelligence™
VMware NSX® Network Detection and Response™
VMware NSX® Malware Prevention
VMware NSX® Metrics

Para mayor información, podemos consultar la documentación oficial NSX Application Platform Overview.

Despliegue de NAPP

Para quienes no tienen claro qué conforma un despliegue de NAPP (NSX Application Platform), podemos dejar una imagen que resume los componentes del despliegue. Donde el componente principal para soportar la solución de NAPP, es la solución de vSphere with Tanzu.

Sé que la imagen anterior puede causar terror. Sin embargo, el equipo de ingeniería de VMware By Broadcom ha desarrollado una herramienta llamada NAPPA (NSX Application Platform Automation Appliance) con el fin de facilitar la implementación de cada uno de los componentes que conforman toda la infraestructura de Kubernetes requerida para soportar la solución de NAPP (NSX Application Platform).

De esta manera NAPPA ejecuta flujos de manera automática para, configurar vSphere with Tanzu, que es una solución que nos permite la ejecución de clústeres de K8s directamente sobre el Hipervisor a través de la creación de vSphere Namespaces. De igual manera NAPPA, usando el Supervisor Clúster desplegado con vSphere with Tanzu, crea automáticamente un vSphere namespace, donde se crea un Tanzu Kubernetes Clúster, al cual llamaremos Guest Cluster de ahora en adelante, y es donde la solución de NSX Application Platform toma vida, así como también todos los pods asociados a los servicios de Metric, VMware NSX® Intelligence™, VMware NSX® Network Detection and Response™, VMware NSX® Malware Prevention y VMware NSX® Metrics.

Para no hacer más largo el cuento lo vamos a dejar hasta ahí.

El problema: Versión TKR fuera de soporte

Ahora bien, el problema que vamos a solucionar acá es cómo mantener este Guest Cluster después de haberlo implementado con el NAPPA. Debido a que en muchas ocasiones, dependiendo de la versión del NSX que teníamos al momento de desplegar el NAPP (NSX Application Platform), la versión de dicho cluster puede quedarse en una versión fuera de soporte que puede generar problemas a medida que vamos actualizando nuestro ambiente de vSphere y de NSX.

Para efectos de laboratorio, hemos desplegado la versión más reciente de NAPP 4.2.0 y curiosamente el guest cluster se ha implementado usando la versión de TKR 1.23.8+vmware.3-tkg.1, que a la fecha está fuera de soporte. Este comportamiento es un issue conocido, para la herramienta de NAPPA y para evitar este comportamiento te invito a leer el siguiente post Desplegar NAPP con version de TKR soportado

Análisis de Compatibilidad

De acuerdo con la matriz de interoperabilidad deberíamos cumplir con las siguientes versiones mínimas de TKR.

Como podemos apreciar en la matriz de interoperabilidad, las versiones de TKR por debajo de 1.26.5 usadas por el guest cluster de NAPP, están actualmente fuera de soporte e incluso algunas de ellas podrían no ser compatible con tu NSX Intelligence o con tu vCenter Server.

Nota: El procedimiento explicado a continuación debe realizarse cuando hagamos una actualización de NSX o vCenter Server ya sea como consecuencia de una actualización de VMware Cloud Foundation (VCF) o cuando actualizamos estas soluciones de manera independiente, con el fin de mantener el clúster de NAPP compatible y dentro del soporte de VMware by Broadcom.

¡Sin más preámbulo vamos al Lab!

Solución

Lo primero que vamos a hacer es seguir la documentación Update a TKG Cluster by Editing the TKR Version, pero no te preocupes acá vamos a explicarlo paso a paso.

Nota: Debemos tener presente que la versión de TKR solo se puede subir de manera gradual, n + 1, es decir que si tenemos la versión 1.23, el primer salto debe ser a la 1.24 y así sucesivamente hasta alcanzar la versión requerida.

Iniciar sesión en el NAPPA vía SSH, con el usuario root ya que desde ahi podremos conectarnos al supervisor cluster sin necesidad de instalar ningún plugin en nuestra VM y vamos a ejecutar el siguiente comando.
Ejecutar el siguiente comando para iniciar conexión al Supervisor cluster. Sino sabes cuál es la IP del Supervisor Cluster solo ve al vCenter Server > Menu > Workload Management > Namespaces > Supervisor Cluster

kubectl vsphere login --insecure-skip-tls-verify --server [IP_SupervisorCluster] --vsphere-username administrator@vsphere.local)
Ahora vamos a elegir el contexto que tiene nuestro despliegue de napp, que debería ser napp-ns-default y para ello usamos el siguiente comando
kubectl config use-context [context_name]
Vamos a validar las versiones compatibles de TKR disponibles en la Libreria de contenido unida a dicho namespace, con el siguiente comando
kubectl get tkr

Acá podemos apreciar que el NAPPA ha publicado en la librería de contenido tres imágenes, entre ellas la imagen de 1.27.6+vmware.1-fips.1-tkg.1 que es superior y compatible. Pero en el momento del despliegue ha usado la 1.23.8+vmware.3-tkg.1, lo cual es una pena porque ahora nos toca subir el Guest Cluster hasta llegar a esa version o una superior compatible de acuerdo con la matriz de interoperabilidad.
Nota: Durante el despliegue, NAPPA configura una librería de contenidos llamada NSX Content Library en el vCenter, con esas tres imágenes. Sin embargo, no podemos hacer el salto desde la v1.23.x hacia la v1.27.x como ya lo mencionamos antes, así que tendremos que cargar las imágenes a dicha librería.
Para descargar y subir a la librería de contenidos las imágenes que nos faltan debemos ir a la siguiente URL https://wp-content.vmware.com/v2/latest/lib.json o también podríamos crear una nueva Content Library Subsribed con la siguiente URL https://wp-content.vmware.com/v2/latest/lib.json y conectar el namespace con esa librería.

En este caso vamos a usar la primera opción y nuestro primer salto será hacia la versión v1.24.x

En el repositorio vemos dos imágenes pero vamos a seleccionar la que se llama ob-22036247-tkgs-ova-photon-3-v1.24.11---vmware.1-fips.1-tkg.1 y que por supuesto sea compatible, de acuerdo con la matriz de interoperabilidad.Así que hacemos clic en ella y luego sobre photon-ova.ovf clic derecho para copiar el link
Vamos ahora a la librería de contenidos NSX Content Library > Actions > Import Library Item y seleccionamos la opción URL, donde vamos a pegar el link copiado anteriormente.

Nota: En el item name, recomiendo colocarle el mismo nombre que tiene en el portal de descarga para que sea fácil identificarla.

Clic en IMPORTAR y esperamos que se descargue
Repetir los pasos para las siguientes imágenes que seran los saltos graduales:
ob-22757567-tkgs-ova-photon-3-v1.25.13---vmware.1-fips.1-tkg.1 ob-23319040-tkgs-ova-photon-3-v1.26.12---vmware.2-fips.1-tkg.2 ob-23049612-tkgs-ova-photon-3-v1.27.6---vmware.1-fips.1-tkg.1 ob-24026550-tkgs-ova-photon-5-v1.28.7---vmware.1-fips.1-tkg.1
La Content Library debería verse de la siguiente forma. Recordemos que las imágenes que hemos seleccionado han sido selecionadas teniendo en cuenta la matriz de interoperabilidad entre NSX intelligence y Tanzu Kubernetes Releases.
Ahora si lanzamos nuevamente el comando kubectl get tkr, las imágenes que hemos cargado deberían mostrarse con true en la columna READY y COMPATIBLE. OJO! No deberíamos aplicar ninguna imagen que no cumpla con estas condiciones.
Ahora lanzamos el siguiente comando para ver la siguiende versión disponible del cluster de kubernetes y el nombre del Guest Cluster que vamos a intervenir.
kubectl get tanzukubernetescluster
Listamos los Tanzu Kubernetes releases
kubectl get tanzukubernetesreleases
Ejecutamos el siguiente comando para editar el manifest de Guest Cluster
kubectl edit tanzukubernetescluster/CLUSTER-NAME

Aqui vamos a editar unicamente las lineas de las referencias para el controlplane y nodePools que aparecen dentro del objeto topology
Verifique en la salida del comando kubectl indique que la edición del manifiesto se realizó correctamente
Verifique con el siguiente comando que el Guest Cluster se este actualizando
kubectl get tanzukubernetescluster

Nota: En la salida del comando vemos que la columna READY dice False debemos esperar a que aparezca True. La paciencia es la clave, esto puede tomar hasta 30 min.
Una vez actualizada debería verse de la siguiente forma
Repetimos los pasos 8 a 11 hasta llegar a la versión de destino. Por ejemplo nuestro siguiente salto sera ala version v1.25.13---vmware.1-fips.1-tkg.1 y asi susesicamente. Sin embargo, antes de hacerlo lee las siguientes notas importantes.
Al finalizar deberíamos ver la versión de distribución de la siguiente manera

Notas importantes

Nota 1: Podemos monitorear el proceso desde napp-ns-default > Monitor

O en napp-ns-default > Compute debemos esperar hasta que la columna Phase pase de Updating a Running. Sin embargo, cuando aparece Running no indica que ya ha terminado. Aún podemos ver eventos y tareas corriendo en el inventario.

Nota 2: Durante cada salto de actualización veremos como se crean nodos adicional mientras ocurre el proceso. La actualización comienza por los nodos del Control Plane y despues en los nodos Worker. Es importante que antes de iniciar con el siguiente salto, verifiquemos no se encuentren tareas en ejecución, que la cantidad de nodos en el inventarios sea la correcta, en mi caso del LAB debería tener únicamente un Control Plane node y un Worker Node. En el siguiente pantallazo vemos un nodo de más, es decir que aún no ha terminado.

Una vez terminan todas las actividades, vamos a ver que el numero de nodos para el Guest Cluster en el inventario es el correcto. Sin embargo, aún debemos esperar que la solucion del NAPP se estabilice.

Nota 3: Debemos esperar que la solución de NSX Application Platform se muestre estable desde la consola de NSX. Esto puede tardar algunos minutos.

Nota 4: Si utilizamos la opción de Troubleshooting del NAPPA (NSX Application Platform Automation Appliance), podemos ver el momento en el que todos los Pods estén arriba.

o podemos usar el comando napp-k get pods -A

Screenshots de referencia para los actualizaciones (saltos) adicionales.

Salto a v1.25.13---vmware.1-fips.1-tkg.1

Salto a v1.26.12---vmware.2-fips.1-tkg.2

Salto a v1.27.10---vmware.1-fips.1-tkg.1

Actualizar Kubernetes Tools

Una vez hemos terminado con las actualizaciones y nos encontremos ahora en una versión compatible de acuerdo con la matriz de interoperabilidad de NSX Intelligence. Es probable que vea la siguiente alerta en la interface. Si estas en una version superior a NSX 4.1.2.2 seguramente no te va a salir esta alerta.

Server version v1.27.10+vmware.1-fips.1 and client version v1.23.3 are incompatible. Please upload Kubernetes Tools to resolve.

Para solucionar dicha alerta solo sigue el siguiente KB NAPP pane in NSX UI shows message "Server version <version> and client version <version> are incompatible. Please upload Kubernetes Tools to resolve.

¡Y eso es todo amigos! Con este procedimiento vas a poder darle mantenimiento al cluster de Kubernetes (K8s) desplegado como parte de la solución NSX Application Platform (NAPP).

¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas.

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Fix Unsupported TKR in NAPP Deployment

en 23 octubre, 202424 octubre, 2024 por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

If you have deployed NSX Application Platform (NAPP) using the latest version of NAPPA (NSX Application Platform Automation Appliance) and upon completion of the deployment you notice that the Guest Cluster supporting the NAPP solution is on a TKR (Tanzu Kubernetes release) version of v1.23.8, this post is for you, and I will explain how to resolve it in under 3 minutes.

Well, if you’re here, it’s because you’ve already realized that even though you’re using the latest version of NAPPA, it is deploying the Guest Cluster in an unsupported version (v1.23.8).

The bad news is that it is a reported issue with the NAPPA tool (version 4.2), which, although it has three images of TKR incorporated and loads them into the content library, ends up choosing version v1.23.8 instead of v1.27.6, even though both were shown as COMPATIBLE.

Solutions

At this point, you have two options: update from TKR v.1.23.8 until you reach at least v1.26.5, although I would recommend going for v.1.27.6. I will be posting an article for that update soon, so don’t miss it!

The other option, which is smarter and requires less effort, is to remove the deployment using the CLEANUP function of NAPPA to redeploy it while keeping in mind some considerations that I will explain later.

If you decided to remove the deployment, go to NSX Application Platform Automation Appliance, proceed next to the wizard until you reach the end. This is where your deployment should have finished; start from the last stage of deployment > Deploy NAPP and click on CLEANUP.

Note: If you had already activated any NAPP service with NSX Intelligence, go to the NSX graphical interface and click on remove that service; otherwise, it will not let you delete the deployment. Once the service is removed, it should look like the following image.

After doing the same (CLEANUP) in the Deploy TKGs stage. This will remove the deployment of NAPP and vSphere With Tanzu from your environment to simply redeploy it.

WARNING! Do this only if you have deployed vSphere With Tanzu using the NAPPA and only for the purpose of the NAPP.

At this point, you have only made a couple of clicks to remove the deployment, which is why it is my preferred option.

Now you just need to update NSX to version 4.1.2.2 or higher and relaunch the NAPP. This update is very straightforward; moreover, it will help you to get rid of one or two vulnerabilities that you might have in the environment.

In my case, I upgraded from NSX version 4.1.2.1 to version 4.1.2.5.

Here you just need to restart the NAPPA assistant from the beginning; the good news is that all the data is already preloaded, you just have to re-enter a couple of passwords.

If all has gone well, you should now have the Guest Cluster deployed that supports the NSX Application Platform (NAPP) in the supported and compatible version (v1.27.6).

And that’s all, friends! With this, we confirm that when we have a version of NSX higher than 4.1.2.2, the guest cluster is deployed with version v1.27.6.

ALL VM NAMES USED IN THIS BLOG ARE FICTITIOUS AND RELATE TO A CUSTOM LAB ENVIRONMENT USED FOR STUDY PURPOSES.

IMPORTANT! I have migrated the blog from the domain nachoaprendevirtualizacion.com to nachoaprendeit.com. If you found this article helpful, please give it a Like and share it with your colleagues; these actions will help me optimize search engines to reach more people.

Solución a TKR incompatible después del despliegue de NSX Application Platform

en 23 octubre, 202422 octubre, 2024 por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

Si estas desplegado NSX Application Platform (NAPP) utilizando la ultima versión de NAPPA (NSX Application Platform Automation Appliance) y al finalizar el despliegue vez que el Guest Cluster que soporta la solución de NAPP esta en una versión de TKR (Tanzu Kubernetes release) v1.23.8. Este post es para ti, y te explico en menos de 3 minutos como solucionarlo.

Pues bien, si estas acá es porque ya te diste cuenta que aunque estas usando la última versión del NAPPA, te esta desplegando el Guest Cluster en una versión fuera de soporte (v1.23.8).

La mala noticia es que es un issue reportado de la herramienta NAPPA (versión 4.2), que aunque tiene incorporadas tres imágenes de TKR y las carga en la librería de contenido, termina eligiendo la versión v1.23.8 y no la v1.27.6, aunque las dos se mostraban como COMPATIBLE.

Soluciones

En este punto tienes dos opciones, hacer actualizaciones desde la TKR v.1.23.8 hasta llegar mínimo a la v1.26.5 aunque yo recomendaría mejor la v.1.27.6. Estaré publicando un post para esa actualización. Así que, ¡No te lo pierdas!

O la otra opción, más inteligente y con menos esfuerzo, es eliminar el despliegue usando la función de CLEANUP del NAPPA para volverlo a lanzar teniendo algunas consideraciones que te explico más adelante.

Si decidiste eliminar el despliegue, ve a NSX Application Platform Automation Appliance, next a el wizard hasta llegar al final, aquí fue donde debió haber terminado tu despliegue, comienza por la última etapa del despliegue > Deploy NAPP y clic en CLEANUP

Nota: Si ya habías activado algún servicio del NAPP con NSX Intelligence, ve a la interface gráfica de NSX y haz clic en eliminar a ese servicio, de lo contrario no te va dejar eliminar el despliegue. Una vez eliminado el servicio, debe lucir como en la siguiente imagen.

Después hacer lo mismo (CLEANUP) en la etapa Deploy TKGs. Esto eliminará el despliegue de NAPP y vSphere With Tanzu de tu ambiente para simplemente volver a lanzarlo.

¡OJO! Hacer esto solo si has desplegado el vSphere With Tanzu usando el NAPPA y solo para el propósito del NAPP.

En este punto solo has hecho un par de clics para eliminar el despliegue, por eso es mi opción preferida.

Ahora solo tienes que hacer un update de NSX a la version 4.1.2.2 o superior y volver a lanzar el NAPP. Esta actualización es muy sencilla, además te va a ayudar a librarte de una que otra vulnerabilidad que puedas tener en el ambiente.

En mi caso pasé de la versión de NSX 4.1.2.1 a la version 4.1.2.5

Aquí ya solo debes volver a lanzar el asistente del NAPPA desde el principio, la buena noticia es que todos los datos ya aparece precargados, solo tienes que reingresar un par de passwords.

Si todo ha salido bien, deberías tener ahora desplegado el Guest Cluster que soporta la solución de NSX Application Platform (NAPP) en la versión soportada y compatible (v1.27.6).

¡Y eso es todo amigos! Con esto comprobamos que, cuando tenemos una versión den NSX superior a 4.1.2.2. El guest cluster se despliega con la versión v1.27.6.

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Solución Rápida para Certificados Expirados en NSX 4.1.x

en 11 octubre, 202417 enero, 2025 por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

Si tienes un ambiente de NSX 4.1.x o superior, has llegado un día a la oficina y te has encontrado con un montón de alertas de certificados expirados. ¡Este post es para ti!

Contexto

El entorno ejecuta NSX 4.1.0.2 o superior y se actualizó desde NSX-T 3.2.x.
Las alarmas de NSX indican que los certificados han expirado o están a punto de expirar.
Los certificados que vencen contienen «Corfu Client» en su nombre.

Causa

Hay dos factores principales que pueden contribuir a este comportamiento:

Los NSX Managers tienen muchos certificados para servicios internos.
En NSX-T 3.2.x, los certificados de servicio de Cluster Boot Manager (CBM) tenían un período de validez incorrecto de 825 días en lugar de 100 años.
Esto se corrigió a 100 años en NSX-T 3.2.3 y NSX 4.1.0.
Sin embargo, en cualquier entorno que haya ejecutado anteriormente NSX-T 3.2.x (anterior a 3.2.3), los certificados internos de CBM Corfu vencerán después de 825 días, independientemente de si se actualiza o no a la versión corregida.
En NSX-T 3.2.x, los certificados de servidor internos podían vencer y no se activaba ninguna alarma. No se produjo ningún impacto funcional.
A partir de NSX 4.1.0.2, las alarmas de NSX ahora controlan la validez de los certificados internos y se activan en el caso de certificados vencidos o que estén a punto de vencer.

Nota: En NSX 4.1.x, no hay impacto funcional cuando caduca un certificado interno. Sin embargo, las alarmas seguirán activándose y esto es lo que verás si estás frente esta situación, que podrás solucionar en menos de 5 min.

Solución

Siguiendo el KB NSX alarms indicating certificates have expired or are expiring nos dice que existe un script en Python que resuelve este problema como por arte de magia. Para ello solo necesitamos una VM con python instalado. La buena noticia es que el vCenter Server ya tiene los módulos que necesitamos para ejecutar estos scripts, así que no vamos a tener que desplegar nada, solo cargar el script al vCenter Server Appliance y lanzarlo desde ahí. Para mayor información por favor revisar el KB indicado anteriormente.

Procedimiento

Descargar el script replace_certs_v1.7.py que se encuentra al final del KB NSX alarms indicating certificates have expired or are expiring
Cargar el archivo a la carpeta /tmp del vCenter Server Appliance utilizando WinSCP o cualquier cliente SFTP.
Como persona responsable asegúrate de tener el Backup de NSX reciente. En mi caso, tomaré un snapshot, ya que es un ambiente Nested.
Hacer login al vCenter Server con el usuario root y navegar hasta la carpeta /tmp. Una vez aquí simplemente ejecutamos el siguiente comando

python3 replace_certs_v1.7.py

Nota: Lo único que tenemos que hacer es responder a las preguntas que nos realiza el script.

Resultado

Una vez finaliza la ejecución del script, aproximadamente 30 minutos en el laboratorio, podemos ver que todas las alertas de certificados se han corregido.

Si revisamos el certificado de uno de los NSX Manager, podremos ver que su fecha ha sido actualizada.

También podemos verificar que ya no tenemos alertas de Certificados en la sección Settings > Certificates

¡Y eso es todo amigos! Ya puedes pasar el susto y volver tus tareas habituales…

Actualización 13012025

La solución de este problema ha sido actualizada y ahora se puede utilizar el script CARR para resolver este problema. Consulte Uso del script CARR (Certificate Analyzer Resolver) para solucionar problemas relacionados con certificados en NSX para descargar el script actualizado.

Actualización 12122024

Nota para las versiones NSX 4.1.2 o anteriores: debido a problemas de permisos de carpetas y archivos, es posible que el script no reemplace los certificados en la primera ejecución y los intentos posteriores sí los reemplacen. Asegúrese de ejecutar el script una segunda vez en caso de que no funcione la primera vez.
Nota para NSX 4.1.1 y versiones posteriores: el script no rota CBM_APIlos certificados (certificado de cliente API-Corfu), ya que estos están obsoletos en la versión 4.1.1. Consulte la resolución de KB#367857.
Después de completar el script, es posible que algunos certificados sin usar permanezcan en la interfaz de usuario con la columna “ Dónde se usa ” establecida en 0. Estos certificados se pueden eliminar si lo desea.
Nota para VCenter 8.0 U3: este script puede fallar en vCenter 8.0 U3 debido a problemas de incompatibilidad. Puede fallar con el error:
SshCommandExecutor: An error occurred: [digital envelope routines] unsupported
Unable to SSH to '192.168.x.x'. Please fix it and rerun the script
Solución: use una versión diferente de vCenter o utilice un dispositivo Linux diferente con los componentes necesarios para ejecutar el script.
Si el script finaliza con » Keystore is not updated post replacement«, consulte el siguiente artículo: El script de reemplazo de certificado genera un error durante la ejecución: el almacén de claves no se actualiza después del reemplazo del certificado ‘CBM_X’ en el nodo ‘IP»

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Licenciamiento de VMware: VCF, VVF y vSAN explicado

en 23 septiembre, 202410 julio, 2025 por Diego Felipe Tunubalá Medinaen VCF/VVF1 comentario

Como todos sabemos, todos los productos y soluciones de VMware by Broadcom ahora se centran el marco de VMware Cloud Foundation (VCF) y VMware vSphere Foundation (VVF). Sin embargo, existe aún mucha confusión con respecto a cómo son cuantificadas las licencias requeridas para el ambiente teniendo en cuenta el modelo de subscripción de Broadcom.

¡Pues bien, es sencillo y acá te lo explico!

CONTENIDO

1. Licenciamiento VCF/VVF por subscripción requerido para el ambiente

Lo primero que debemos tener presente es que el modelo de suscripción se basa en la cantidad total de cores físicos, de cada CPU en todos los hosts ESXi asociados con las instancias de VCF o vCenter Server que los clientes planean licenciar con VCF o VVF.

Sin embargo, existe una reglar que indica que los clientes deben adquirir una capacidad de licencia mínima de 16 cores por CPU.

Pero además de esto, la cantidad de licencias por subscripción requeridas debe ser la mayor entre el resultado de las siguientes dos operaciones:

1) Qta Licencias Subscripcion VCF/VVF: [Número de núcleos por CPU] × [Número de CPU por host ESXi] × [Número de hosts ESXi]

2) Qta Licencias Subscripcion VCF/VVF: [16 núcleos] x [número total de CPU por host ESXi]

Nota: Esto no significa que las licencias se vendan en paquetes de 16, sino que es más bien el mínimo de licencias por subscripción que un cliente puede comprar.

2. Licenciamiento para vSAN por subscripción requerido para el ambiente

Por otro lado, tenemos el caso del licenciamiento para vSAN, pero este es otro asunto un poco diferente, debido a que aquí el licenciamiento depende en primera instancia de si vamos a utilizar VCF o VVF.

Escenario vSAN con VCF

Comencemos por el escenario en el cual vamos a licenciar vSAN para VCF (VMware Cloud Foundation).
Aquí el licenciamiento está definido en TiB (tebibyte), y en este caso la cantidad de licencias de vSAN se basa en el almacenamiento físico total RAW (TiB) reclamado por vSAN en todos los hosts ESXi en cada clúster de vSAN asociado con las instancias de vCenter Server o VCF que los clientes planean licenciar para vSAN.

Nota: Para los que no se acuerda, el Terabyte utiliza el sistema decimal y equivale a 1 billón de bytes, mientras el Tebibyte (TiB) utiliza el sistema binario y equivale a 1.099.511.627.776 bytes o lo que es lo mismo 1024 GiB (Gibibyte), que es como normalmente todos en TI lo asociamos. Es más un tecnicismo y cuestión de acostumbrarnos a colocar las siglas correctas.

Dicho esto, podríamos utilizar la siguiente expresión para definir la cantidad de licencias por subscripción necesarias para vSAN en un ambiente de VCF.

Qta licencias Subscripcion vSAN (en VCF) = [Número total de TiB reclamados por vSAN en cada host ESXi] x [número de hosts ESXi en cada clúster].

De esta manera, cada TiB que reclama vSAN requiere una única licencia. A diferencia del licenciamiento por subscripción de VCF, donde mínimo debíamos adquirir 16 licencias, para este caso de vSAN, NO existe un mínimo.

Algo importante a resaltar, es que el licenciamiento por subscripción de VCF provee el derecho a 1 TiB de vSAN por cada licencia de core de VCF adquirida. Esto quiere decir que si el número de TiB que necesita el ambiente es menor o igual al número de licencias de core de VCF, el cliente no debe adquirir licenciamiento de vSAN adicional. Por otro lado, si el número de TiB que necesita el ambiente es superior al número de licencias de core adquiridas, probablemente deba adquirir licenciamiento adicional para vSAN únicamente.

Resumiendo el párrafo anterior, podríamos expresarlo de la siguiente forma:

1) (Qta Licencias subscripcion VCF) <= Numero de TiB requereridas por el ambiente, entonces no requiere licencias adicional de vSAN
2) (Qta Licencias subscripcion VCF) > Numero de TiB requereridas por el ambiente, entonces se requiere licencias adicional para vSAN

En el siguiente KB Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN vemos un ejemplo de cuantas licencias debería adquirir un cliente para una solución de VCF y vSAN teniendo en cuenta la cantidad de hosts ESXi.

Nota: Para ver todos los ejemplos disponibles, lo invito a revisar el link anterior.

Escenario vSAN con VVF

Por otro lado, tenemos el escenario en el cual vamos a licenciar vSAN para VVF (VMware vSphere Foundation) . Aquí el licenciamiento está definido en GiB (Gibibyte), y en este caso la cantidad de licencias de vSAN se basa en el almacenamiento físico total RAW (GiB) reclamado por vSAN en todos los hosts ESXi en cada clúster de vSAN asociado con las instancias de vCenter Server o VVF que los clientes planean licenciar para vSAN.

Cuando estamos licenciando para VVF, tenemos derecho hasta 100 GiB de vSAN de prueba, por cada licencia por subscripción de core adquirida. Es decir si adquirimos 16 licencias de core para VVF tendríamos derecho a 16 x 100 GiB = 1600 GiB = 1.5624 TiB.

Nota: Aunque acá la referencia es GiB, es mejor convertirlo a TiB para mayor facilidad.

De esta manera, si los clientes exceden la cantidad de capacidad de prueba de vSAN en el clúster de vSAN, deben licenciar la cantidad total de TiB reclamados en el clúster de vSAN comenzando desde 0.

Dicho esto, la expresión para calcular la capacidad máxima trial de vSAN para VVF sería la siguiente:

Capacidad vSAN trial (en VVF) = [Qta de licencias de núcleo de vSphere Foundation en cada host ESXi implementado en el clúster de vSAN] x [100 GiB] / 1024

Nota: De nuevo acá, dividimos por 1024 para convertir la capacidad a TiB y hacer una comparación más sencilla.

Como en el caso anterior, dejamos por un ejemplo de lo expresado anteriormente para el caso de VVF con vSAN. Para ver más ejemplos podemos ver el artículo completo Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN

3. Herramienta para consolidar la información de la cantidad de licencias

Como entendemos que contar la cantidad de licencias en nuestro ambiente puede ser una tarea aburrida, VMware By Broadcom ha puesto a disposición una herramienta (script) para identificar la cantidad de licencias por Core (con un mínimo de 16 cores por CPU física) y licencias TiB que se requieren para licenciar correctamente los siguientes productos VMware: VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF) y VMware vSAN.

Nota: VMware Cloud Foundation y VMware vSphere Foundation requieren licencias por core para todos los cores físicos en cada CPU que ejecute el software. OJO! En caso de que los usuarios deshabiliten los núcleos de CPU físicos en la configuración del BIOS o por otros medios, el script puede producir resultados inexactos. Por lo tanto, todos los núcleos físicos deben estar activados en cada CPU del host al ejecutar el script.

Los requerimientos para ejecutar el script son los siguientes:

VMware PowerCLI 10.x o superior instalado.
En la VM donde se instaló el PowerCLI, abrir una consola de PowerShell y ejecutar el siguiente comando Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypas
Descargar el archivo FoundationCoreAndTiBUsage.psm1 que se encuentra al final del artículo Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN

Nota: Sin nunca has instalado PowerCLI, ¡No has sido un verdadero guerrero, bienvenido al campo de batalla! Es broma, no te preocupes solo revisa el artículo Install PowerCLI si tu VM tiene salida a internet o si no tienes salida a internet entonces usa el siguiente artículo Install PowerCLI Offline. Aunque para evitarte la fatiga, te dejo abajo la instalación para cuando tenemos salida a internet en la VM.

Instalación de PowerCLI

Verificar la versión de PowerShell que tenemos instalada y verificar la Compatibility Matrix de PowerCLI. Sino tenemos la versión correcta de PowerShell indicado en los prerrequisitos de la matriz de compatibilidad (para la versión PowerCLI 13.3), vamos a tener que instalar la nueva versión siguiendo la documentación de Microsoft Installing PowerShell on Windows

En mi caso tenía la versión 5.0.1 y la documentación dice que necesitaba mínimo la 5.1.0. Sin embargo, instalamos de una vez la última versión disponible. En este caso utilicé la opción por MSI que menciona en Installing PowerShell on Windowsporque creo es la más sencilla.

Una vez actualizado nuestro PowerShell, ahora sí, instalamos el PowerCLI usando el comando Install-Module VMware.PowerCLI

Nota: Si les da algún error solo use el comando con los parámetros Install-Module VMware.PowerCLI -Force -skipPublisherCheck

Usar la herramienta (script)

Una vez instalado el PowerCLI seguir los siguientes pasos para ejecutar el script

Desde la consola del PowerShell navegar hasta donde tenemos el archivo descargado del KB indicado anteriormente.
Conectarse a vCenter Server con el siguiente comando
Connect-VIServer -Server IP_FQDN_vCenter_Server
Importar función PowerCLI:
Import-Module .\FoundationCoreAndTiBUsage.psm1

Nota: Si el comando anterior les da el error cannot be loaded. The file xxxx.psm1 is not digitally signed. You cannot run this script on the current system. For more information abut running scripts and setting execution policy, see about_Execution_Policies at htt;s//microsoft....
Solo ejecute el siguiente comando Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass y vuelva a intentar el import.
Ejecute la función Get-FoundationCoreAndTiBUsage y especifique el tipo de implementación para traer los resultados. De manera predeterminada, el script iterará por todos los clústeres de vSphere.Get-FoundationCoreAndTiBUsage -DeploymentType VCF Get-FoundationCoreAndTiBUsage -DeploymentType VVF
Desconectarse del vCenter Server:
Disconnect-VIServer -Server IP_FQDN_vCenter_Server

A continuación se muestra un par ejemplos adicionales después de ejecutar la herramienta en PowerCLI.

Ejemplo de VCF con vSAN

Ejemplo de VVF con vSAN

¡Y eso es todo amigos! Con esta sencilla herramienta podremos verificar la cantidad de licencias VCF/VVF y vSAN que necesitamos en el ambiente.

¡IMPORTANTE! He migrado el blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo deja tu buen Like y compártelo con tus colegas, estas acciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas.