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.
¡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.
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.
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…
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.
¡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.
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.
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.
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
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.
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
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
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.
Nacho Aprende IT 