¿Cómo están estimados? ¡Espero que bien! En esta ocasión les traigo una publicación referida a VMware vSAN 6.7 u3. Esto sucedió durante el despliegue de un Cluster en la infraestructura de un cliente, y al ejecutar el primer chequeo con la herramienta nativa «vSAN Skyline Health» nos encontramos con la siguiente alarma:
Apenas vi el mensaje, lo primero que se me vino a la cabeza fue asociar el problema con un tema de compatibilidad con las controladoras RAID Broadcom PERC H730P. Pero por suerte estaba equivocado, y lejos de ser un inconveniente relacionado a incompatibilidad, pude hallar la solución en la siguiente KB:
https://kb.vmware.com/s/article/2148867
En el artículo se puede leer que la alarma se produce por la falta de herramientas de software instaladas en los equipos, y que permitan a vSAN obtener una mejor información sobre cómo está configurado el entorno. ¿Y cuál es el beneficio de instalar estas utilidades? Que vSAN pueda ejecutar un mejor análisis para la obtención de fallos o detectar problemas de configuración en la infraestructura.
Lo mejor de todo esto es que vSAN tiene la inteligencia para identificar que tipo de hardware tenemos instalado en los servidores físicos, y así poder recomendarnos cual es el software que debemos desplegar. Si observan en una de las imágenes del principio, en la columna «Recommended utility», aparece la herramienta «percli».
¿Es «percli» la única herramienta que puede aparecer como recomendada? No, como dije en el párrafo anterior, va a depender del hardware que tengamos instalado en los hosts.
A continuación, les dejo el detalle de cuales son las otras que podrían aparecer listadas:
La utilidad «percli» está relacionada con hardware del fabricante «Dell» y efectivamente los equipos que habíamos montado eran unos «PowerEdge R740». Otra que aparece en la lista es «ssacli», y está relacionada con equipos de la marca «HP».
¿Cómo se instalan estas herramientas? En mi caso les voy a detallar el procedimiento de como instalé la utilidad «percli» en los equipos Dell, pero es el mismo procedimiento para cualquiera de los otros casos:
1 – Lo primero que debemos hacer es descargar el software a instalar desde el sitio oficial del fabricante. En este caso, al tratarse de unos equipos «Dell PowerEdge R740», me dirigí al siguiente link:
https://www.dell.com/support/home/es-ar
Una vez dentro del sitio, debemos buscar soporte relacionado al modelo en cuestión. Siempre lo recomendado es buscar soporte utilizando el «service tag» (etiqueta de servicio) asociado al equipo, pero para esta demo lo haré utilizando el nombre del modelo:
En el siguiente link ir a la solapa «Controladores y descargas» y filtrar la información por tipo de sistema operativo y categoría, tal cual se muestra en la imagen a continuación:
Una vez aplicado el filtro, aparecerá un listado de controladores disponibles, seleccionaremos el necesario y le daremos click al botón descargar.
El nombre está más que claro: «VMware PERCLI Utility for All Deel HBA/PERC Controllers».
Al descargarse, lo va a hacer en un tipo de archivo con extensión «efi»:
Pero ¿me sirve este formato de archivo para instalarlo en un ESXI? No, el formato que necesitamos para instalar cualquier software sobre un hipervisor ESXI, tiene que ser con extensión «vib» (vSphere Installation Bundle). Por lo tanto, tenemos que hacer lo siguiente, expandir las opciones del ítem que deseamos descargar y hacer click en el botón «otros formatos»:
Se abrirá una ventana y seleccionaremos el formato «gz»
Pero «gz» es conocido por ser un formato para sistemas operativos Linux, ¿y si tengo una PC con Windows? No importa, tanto «WinRAR» como «7zip» te lo van a reconocer:
Por ultimo vamos a extraer los archivos que vienen comprimidos y nos vamos a dirigir a la carpeta correspondiente, de acuerdo a la versión de ESXI que tengamos desplegado en nuestro entorno:
En la imagen anterior, pueden notar que ahora si contamos con el formato de archivo necesario para la instalación.
2 – En el segundo paso, vamos a copiar el archivo descargado, dentro de los Datastores locales correspondientes a cada uno de nuestros ESXI que figuran con «Warning». Para eso podemos crear una carpeta con nombre «VIBs» dentro del Datastore y subir el archivo necesario:
3 – En el último paso, ejecutaremos la instalación del software «percli». Para eso nos vamos a conectar a través de SSH (utilizando alguna herramienta como Putty) al ESXI en donde se realizará. Como requisito es necesario contar con la IP o FQDN del equipo y la contraseña del usuario «root». Una vez conectados lo primero que podríamos hacer es verificar que VIBs ya se encuentran instaladas en el equipo, utilizando el comando «esxcli software vib list», lo cual nos va a devolver una lista enorme de todas las «VIBs»:
La lista era mucho más extensa, pero la tuve que acotar para que no me ocupe toda la publicación jajajajaja!. Como notarán, en la columna «Vendor» muestra a que fabricante corresponde el software instalado. Las que figura con las siglas «VMw» son propias de VMware y las que figuran por ejemplo con el vendor «Broadcom», pueden ser drivers necesarios para que alguna pieza de hardware sea reconocida por el ESXI.
Siguiendo con los pasos, lo que haremos será verificar si desde la línea de comandos puedo listar el archivo que subí al Datastore. El intérprete de comando en ESXI es similar a Linux, por lo tanto puedo ejecutar «ls /vmfs/volumes/NOMBRE DEL DATASTORE/NOMBRE DE LA CARPETA/»
Todos los Datastores conectados al ESXI van a figurar dentro del directorio «/vmfs/volumes/». Lo que está tachado en blanco luego de «/vmfs/volumes/», es el nombre del Datastore local del ESXI (que por tratarse de un cliente, obviamente no lo puedo mostrar) y el directorio que está a continuación, «/VIBs/», es la carpeta que creamos y en donde guardamos el archivo «vmware-esx-percli-007XXXX….vib».
Una vez comprobado y sabiendo que está todo en condiciones, vamos ejecutar el comando que ahora si nos permitirá la instalación:
esxcli software vib install -v=/vmfs/volumes/NOMBRE DEL DATASTORE/VIBs/vmware-esx-perccli-007.0529.0000.0000.vib
El resultado es satisfactorio (señalado con una flecha roja), lo cual es un claro indicador de que la operación finalizó de manera correcta, y además nos indica que no hace falta reiniciar el host para aplicar los cambios: «Reboot Requeried: false».
Revisamos el estado del host en «vSAN Skyline Health» y….¡¡¡voilà!!! Problema resuelto, la alarma desapareció en el host en donde se aplicó la instalación:
Si volvemos a ejecutar el comando «esxcli software vib list», ahora si aparecerá listada la VIB correspondiente a «percli»:
Algunos tips antes de ejecutar la tarea:
- Si bien no lo aclaré al principio, es necesario que el host se encuentre en modo mantenimiento.
- Al ejecutar el comando, nos devuelve el resultado y aclara que no es necesario reiniciar el equipo. En mi caso (y por las dudas), igualmente ejecuté un reinicio del ESXI.
- «Skyline Health» está disponible a partir de la versión 6.7 de vSAN. Si dentro de tu infraestructura tenes desplegada una versión de vSAN anterior, te recomiendo que la actualices a la versión 6.7 u3 (siempre y cuando hayas hecho el trabajo de revisar la matriz de compatibilidad) ya que a comparación de versiones anteriores, trae varias features nuevas y además soporta otro tipo de configuraciones.
- Otra recomendación es que, apenas finalices la implementación de vSAN dentro de una infraestructura, lo primero que tenes que hacer es la verificación del entorno utilizando «Skyline Health». Esto te va a brindar un status del Cluster y a detallar los errores existentes de configuración, lo cual te permitirá hacer los ajustes necesarios antes de que salga a producción.
¡Bueno gente, hasta acá llegamos con el post del día de hoy! Cualquier consulta que tengas no dudes en contactarme a través de los comentarios o vía mail. Compartilo con colegas, compañeros o amigos. Si te gusta este tipo de contenido, podes suscribirte a este blog.
¡Hasta la próxima publicación!
Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.
Blog de Cloud Computing y Virtualización 