Limpiando particiones en discos para configuración de vSAN

en 8 julio, 202016 julio, 2022 por Diego Tunubaláen VSAN, vSphereDeja un comentario

En esta oportunidad explicaremos como abordar una situación en la cual al intentar crear el cluster vSAN de forma manual a través del asistente de configuración, no tenemos disponibles algunos discos que deberían aparecer para la creación de los Disk Groups. En ese momento nos preguntaremos ¿Por qué no aparecen todos los discos disponibles?, pues bien lo más probable es que el o los discos que no aparecen listados para ser Claimed por vSAN no están vacíos y deban ser formateados para poderlos liberar.

Es aquí donde nos podríamos encontrar con un error común que puede convertirse en un dolor de cabeza sino conocemos su causa raíz. El error básicamente se produce al intentar ejecutar la acción Erase Partitions en la configuración del host en el apartado Configure->Storage->Storage Devices, como se muestra en la siguiente imagen.

Al hacer clic sobre la opción anterior nos mostrará un resumen de las particiones con las que cuenta este disco y razón por la cual no esta disponible para el asistente de configuración de VSAN.

Al hacer click sobre el botón OK, en la mayoría de los casos, las particiones serán eliminadas y el disco quedará disponible para vSAN. Una forma rápida de verificarlo es que al hacer nuevamente clic sobre Erase Partition, no debería listar ninguna partición y el asistente de configuración de vSAN debería ahora listar el o los discos.

¿Y SI FALLA?…

Es ahora cuando aparece el problema ¿Que hacemos si esta tarea falla y nos muestra el siguiente error: “Cannot change the host configuration”? Primero que todo ¡calma, calma!, no tenemos que ir a ninguna línea de comandos a intentar limpiar estas particiones, la solución es mucho más sencilla que eso.

Nota 1: Para las versiones de ESXi anteriores a 7,0, scratch partition es un espacio temporal que se configura automáticamente durante la instalación o el primer arranque de un host ESXi. El instalador de ESXi crea una partición FAT16 de 4GB en el dispositivo de destino durante la instalación si hay suficiente espacio y si el dispositivo se considera local. Esta partición no es creada cuando el hipervisor se instala en tarjetas SD o unidades flash USB.

Nota 2: Si no existe espacio temporal persistente disponible en el disco local o la partición no es creada (en el caso de SD, Flash USB), ESXi almacenará estos datos temporales en la memoria RAM. Esto puede ser problemático en situaciones con poca memoria, pero no es fundamental para el funcionamiento de ESXi.

Explicado lo anterior, el problema pudo haberse producido si ese disco o discos, en algún momento fueron formateados como Datastore (VMFS), y esto hace que el hipervisor configure ese datastore como su mejor candidato para ubicar el Scratch Partition (Partición creada para almacenar la salida de vm-support necesaria para el soporte de VMware).

Por esta razón, la solución a este problema se basa en cambiar la configuración asociada a la opción avanzada del hipervisor ScratchConfig.ConfiguredScratchLocation, que probablemente estará apuntando al datastore local que en algún momento se configuró en dicho disco.

SOLUCIÓN

1. Si ya tiene vCenter instalado navegue en el inventario hasta el Host –> Configure –> Advanced System Settings. Clic en Edit… y en el filtro escriba ScratchConfig.ConfiguredScratchLocation.

2. Sino tiene instalado un vCenter aún, inicie sesión en el Host Client del host en cuestión (en cualquier navegador web https://IP_FQDN_Host ) y navegue hasta Manage->System-> Advanced Settings y en el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

3. Independientemente de si se realizó el paso anterior desde el vCenter o desde el Host Client, podrá ver que en el campo value aparecerá la ruta hacia un datastore, lo único que debemos hacer es editar este valor y colocar /tmp, para redireccionarlo a la memoria RAM (no recomendado) o especificar la ruta de un almacenamiento persistente diferente.

Nota 3: Al editar el valor de ScratchConfig.ConfiguredScratchLocation será /tmp, mientras el valor de ScratchConfig.CurrentScratchLocation permanecerá sin cambios. Esto se debe a que es necesario realizar un reinicio del host para que los mismo sean aplicados.

4. Una vez realizado el reinicio, inicie sesión nuevamente en el Host Client y navegue hasta Manage->System-> Advanced Settings. En el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

En la columna value podrá observar que el valor tanto para ScratchConfig.ConfiguredScratchLocation como para ScratchConfig.CurrentScratchLocation es /tmp.

5. Por ultimo, intente nuevamente la acción Erase Partition.

Desde el vCenter

o desde el Host Client (Clear partition table)

Y notará que la tarea finaliza con éxito.

En este momento ya habrá liberado el o los discos y ahora estarán disponibles para ser reclamados por VSAN desde el asistente de configuración.

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.

Silenciar alarmas de health check en vSAN

en 25 julio, 201816 julio, 2022 por Diego Tunubaláen VSAN, vSphereDeja un comentario

En esta ocasión se presenta un procedimiento fácil y rápido para silenciar las alarmas generadas por el health check de vSAN, que puede ser utilizado en ambientes Nested (ESXi virtualizados) o en ambientes de laboratorio propiamente dichos. Esta puede ser una opción para omitir algunas de la verificaciones debido a que no siempre contamos con las condiciones de hardware, firmware y drivers apropiados para implementar la solución; ni mucho menos contamos con vSAN ReadyNodes disponibles para una POC (Proof of Concept).

¡CUIDADO! En ningún momento se recomienda este procedimiento en ambientes vSAN productivos ya que todos los componentes de hardware, drivers y firmware deben coincidir con la Guía de Compatibilidad de VSAN indicada para los nodos que conforman la solución.

Antes de iniciar el procedimiento comentemos un poco acerca de RVC (Ruby vSphere Console). Es una consola de línea de comando para VMware vSphere y Virtual Center. Ruby vSphere Console es basada en la popular interface RbVmomi Ruby para vSphere API. RbVmomi fue creada para reducir drásticamente la cantidad de codificación requerida para realizar tareas rutinarias, así como aumentar la eficacia de la ejecución de tareas, al tiempo que permite la máxima potencia de la API cuando es necesario. RVC se encuentra incluida en el vCenter Server Appliance (VCSA) y la versión de Windows de vCenter Server, y se ha convirtiendo en una de las principales herramientas para administrar y solucionar problemas de entornos Virtual SAN (vSAN).

RVC tiene muchas de las capacidades que se esperan de una interfaz de línea de comandos.

Finalización de tabulación
Comodines
Marcas
Modo Ruby
Modo Python
Introspección VMODL
Conexiones múltiples

Extensibilidad

Guiones de Ruby de una sola línea
Casos de uso y ventajas de RVC
Funcionalidad Virtual SAN cubierta
Configuración de VSAN y políticas de almacenamiento
Comandos de monitorización / resolución de problemas
Monitoreo del desempeño a través de VSAN Observer

Ventajas

Más información detallada sobre Virtual SAN vSphere Web Client
Vista de grupo de VSAN mientras que esxcli solo puede ofrecer una perspectiva de servidor
Operaciones masivas a través de comodines
Funciona directamente contra ESX host, incluso si VC no funciona

NOTA: Para mayor información acerca de la utilización de RVC aplicada a vSAN podemos consultar la guía oficial VMware Ruby vSphere Console Command Reference for Virtual SAN.

PROCEDIMIENTO

1. Tenga presente que existe una lista de checks o validaciones que están disponibles para ser configurados y se encuentran consignados en la siguiente tabla. De manera que primero debemos verificar si la alarma que muestra el monitor de salud de vSAN se encuentra en éste listado.

Descripción	Check ID
Cloud Health
Controller utility is installed on host	vendortoolpresence
Controller with pass-through and RAID disks	mixedmode
Customer experience improvement program (CEIP)	vsancloudhealthceipexception
Disks usage on storage controller	diskusage
Online health connectivity	vsancloudhealthconnectionexception
vSAN and VMFS datastores on a Dell H730 controller with the lsi_mr3 driver	mixedmodeh730
vSAN configuration for LSI-3108 based controller	h730
vSAN max component size	smalldiskstest
Cluster
Advanced vSAN configuration in sync	advcfgsync
Deduplication and compression configuration consistency	physdiskdedupconfig
Deduplication and compression usage health	physdiskdedupusage
Disk format version	upgradelowerhosts
ESXi vSAN Health service installation	healtheaminstall
Resync operations throttling	resynclimit
Software version compatibility	upgradesoftware
Time is synchronized across hosts and VC	timedrift
vSAN CLOMD liveness	clomdliveness
vSAN Disk Balance	diskbalance
vSAN Health Service up-to-date	healthversion
vSAN cluster configuration consistency	consistentconfig
vSphere cluster members match vSAN cluster members	clustermembership
Data
vSAN VM health	vmhealth
vSAN object health	objecthealth
Encryption
CPU AES-NI is enabled on hosts	hostcpuaesni
vCenter and all hosts are connected to Key Management Servers	kmsconnection
Hardware compatibility
Controller disk group mode is VMware certified	controllerdiskmode
Controller driver is VMware certified	controllerdriver
Controller firmware is VMware certified	controllerfirmware
Controller is VMware certified for ESXi release	controllerreleasesupport
Host issues retrieving hardware info	hclhostbadstate
SCSI controller is VMware certified	controlleronhcl
vSAN HCL DB Auto Update	autohclupdate
vSAN HCL DB up-to-date	hcldbuptodate
Limits
After 1 additional host failure	limit1hf
Current cluster situation	limit0hf
Host component limit	nodecomponentlimit
Network
Active multicast connectivity check	multicastdeepdive
All hosts have a vSAN vmknic configured	vsanvmknic
All hosts have matching multicast settings	multicastsettings
All hosts have matching subnets	matchingsubnet
Hosts disconnected from VC	hostdisconnected
Hosts with connectivity issues	hostconnectivity
Multicast assessment based on other checks	multicastsuspected
Network latency check	hostlatencycheck
vMotion: Basic (unicast) connectivity check	vmotionpingsmall
vMotion: MTU check (ping with large packet size)	vmotionpinglarge
vSAN cluster partition	clusterpartition
vSAN: Basic (unicast) connectivity check	smallping
vSAN: MTU check (ping with large packet size)	largeping
Performance service
All hosts contributing stats	hostsmissing
Performance data collection	collection
Performance service status	perfsvcstatus
Stats DB object	statsdb
Stats DB object conflicts	renameddirs
Stats master election	masterexist
Verbose mode	verbosemode
Physical disk
Component limit health	physdiskcomplimithealth
Component metadata health	componentmetadata
Congestion	physdiskcongestion
Disk capacity	physdiskcapacity
Memory pools (heaps)	lsomheap
Memory pools (slabs)	lsomslab
Metadata health	physdiskmetadata
Overall disks health	physdiskoverall
Physical disk health retrieval issues	physdiskhostissues
Software state health	physdisksoftware
Stretched cluster
Invalid preferred fault domain on witness host	witnesspreferredfaultdomaininvalid
Invalid unicast agent	hostwithinvalidunicastagent
No disk claimed on witness host	witnesswithnodiskmapping
Preferred fault domain unset	witnesspreferredfaultdomainnotexist
Site latency health	siteconnectivity
Unexpected number of fault domains	clusterwithouttwodatafaultdomains
Unicast agent configuration inconsistent	clusterwithmultipleunicastagents
Unicast agent not configured	hostunicastagentunset
Unsupported host version	hostwithnostretchedclustersupport
Witness host fault domain misconfigured	witnessfaultdomaininvalid
Witness host not found	clusterwithoutonewitnesshost
Witness host within vCenter cluster	witnessinsidevccluster
vSAN Build Recommendation
vSAN Build Recommendation Engine Health	vumconfig
vSAN build recommendation	vumrecommendation
vSAN iSCSI target service
Home object	iscsihomeobjectstatustest
Network configuration	iscsiservicenetworktest
Service runtime status	iscsiservicerunningtest

2. Inicie sesión SSH en el vCenter Server Appliance y conéctese al Ruby vSphere Console (RVC) ejecutando el siguiente comando (sin habilitar el Shell)

rvc username@localhost

Ejemplo:

Command> rvc administrator@vsphere.local@localhost

3. Ingrese el password del usuario administrator@vsphere.local

Se utilizarán los siguientes comandos RVC para verificar y silenciar las alarmas

vsan.health.silent_health_check_status
vsan.health.silent_health_check_configure

4. Verifique el estado de las alertas con el primer comando, para el cual se debe conocer la ruta de cluster a analizar. Puede apoyarse de los comando cd y ls para navegar hasta encontrar la ruta correcta del cluster vSAN.

Ejemplo:

vsan.health.silent_health_check_status /localhost/Datacenter-Lab01/computers/vSAN-Cluster

5. Desde el vSphere Web Client navegue hasta el NombredelCluster|vSAN|Health para identificar el nombre de la alerta que se desea silenciar, teniendo en cuenta por supuesto que la misma no sea de impacto para la operación normal de la solución, de lo contrario deberá realizarse una adecuada investigación y solución del problema.

Para este caso al ser un ambiente de laboratorio virtualizado, se tiene la alerta SCSI controller is VMware certified que nos indica acerca de la incompatibilidad de la controladora de discos para el uso de vSAN, que no podemos solucionar debido a que la controladora es virtual; por lo tanto puede ser ignorada o silenciada. (¡Recuerde! Esto acción no debe ser realizada en ambientes productivos).

6. En la salida del comando anterior se muestra el mismo listado de Health Checks disponibles para configurar y su estado actual. De manera que para silenciar la verificación SCSI controller is VMware certified, se debe utilizar su correspondiente identificador o Check ID controlleronhcl

7. Ahora solo queda ejecutar el comando de configuración vsan.health.silent_health_check_configure de la siguiente manera para silenciar la alarma

vsan.health.silent_health_check_configure /localhost/Datacenter-Lab01/computers/vSAN-Cluster –a ‘controlleronhcl’

Utilice los parámetros de configuración disponibles, de acuerdo a su necesidad.

-a	–add-checks=	Agregar verificación a la lista silenciosa, uso: -a [Health Check Id].
-r	–remove-cheques=	Eliminar verificación de la lista silenciosa, uso: -r [Health Check Id]. Para restaurar la lista de verificación silenciosa, utilizando ‘-r all’
-i	–interactive-add	Usa el modo interactivo para agregar verificación a la lista silenciosa
-n	–interactive-remove	Usa el modo interactivo para eliminar las verificaciones de la lista silenciosa
-h	–help	Muestra este mensaje

8. Regrese al vSphere Web Client y haga click en Retest en el Health monitor de vSAN para validar el cambio y podrá observar que la alerta aparece ahora como Skipped y no como Warning.

Detectar ubicación física de discos que hacen parte de vSAN

en 18 junio, 201816 julio, 2022 por Diego Tunubaláen VSAN, vSphereDeja un comentario

Muchas veces nos encontramos con el dilema de no poder rastrear la ubicación de un disco de la vSAN hasta la ubicación real (slot) en el servidor. Esto por lo general ocurre cuando necesitamos reemplazar un disco perteneciente a un Disk Group que se encuentra alarmado o un Storage Device que se muestra como degradado en la configuración de vSphere, pero a nivel físico no se visualiza ninguna alerta. ¿Como hacemos entonces para saber cuál disco es el que debemos cambiar? Pues bien he aquí un procedimiento sencillo que nos puede ayudar a salir de la incertidumbre.

1. Desde el vSphere Web Client seleccionar el host al que se desea realizar la inspección del discos en el mundo físico, sea éste que se encuentre alarmado o no. Vaya a la pestaña Configure | Storage Devices, y tomar nota de nombre canónico (naa.*) del dispositivo en cuestión.

2. Inicie sesión SSH en el host ESXi que se encuentra el disco local que hace parte de la vSAN, con el usuario root y la contraseña configurada, para ejecutar el siguiente comando que mostrará la ruta reclamada por el plugin de multipathing nativo para VMware (NMP: VMware Native Multipath Plugin) perteneciente al Pluggable Storage Architecture.

[root@esxi:~]esxcli storage nmp path list

En la imagen mostrada arriba aparecen varios identificadores sas.*, que de izquierda a derecha el primero corresponde a la dirección SAS de la controladora de discos, la segunda a la dirección SAS del disco y el ultimo el nombre canónico (naa.*) definido por vSphere para cada Storage Device.

De esta manera, si se quiere buscar cuál es la posición física correspondiente a un determinado disco local se debe buscar de manera inversa, esto es; identificar primero el nombre canónico naa.* del disco en vSphere (Paso 1) y posteriormente buscar dicho naa.* en la salida del comando anterior (Paso 2). Una vez encontrado, se debe tomar nota de su correspondiente SAS Address (segunda dirección de izquierda a derecha).

Ejemplo:

Para buscar la ubicación física del Storage Device seleccionado en la siguiente figura

Al ejecutar el comando esxcli storage nmp path list y buscar el nombre canónico en la salida de comando (naa.5002538c40896228) se obtiene lo siguiente

3. Ahora se debe buscar en cada uno de los discos locales del servidor, la dirección sas.* encerrada en color rojo o el target del dispositivo TXX encerrado en color azul, desde la interface de administración del mismo (iLO, CIMC, iDRAC, etc.). A continuación, una muestra de la coincidencia para el caso de un servidor CISCO.

En la imagen anterior se puede observar que el disco corresponde al slot 4 (PD-4), ya que al realizar la búsqueda en cada uno de los discos éste coincide tanto para la Dirección SAS como para el Target (id. del dispositivo para el caso de CISCO).

Nota: Puede haber casos en que debido al firmware sugerido por la matriz de compatibilidad de vSAN para la controladora de discos, la dirección sas.* en salida del comando del Paso 2 aparezca como desconocido (unknown) para la dirección sas de la controladora y de los discos, por lo que nos queda solo rastrear el disco en el mundo físico por su target encerrado en color azul.