¿Qué tal colegas? ¿Cómo están? Bienvenidos a una nueva publicación. Hoy nos toca hablar sobre una alarma relacionada a VMware vSAN y que nos apareció la semana pasada en un cliente. Antes de mostrar los detalles de la misma y como resolverla, los voy a poner un poco en contexto. Estuvimos realizando tareas de actualización de hardware sobre unos host ESXI, con el objetivo de ampliar la cantidad de memoria física disponible. Durante los últimos meses la cantidad de VMs desplegadas en el cliente habían crecido de manera exponencial, por lo tanto, los recursos del Cluster ya estaban quedando escasos. Para poder trabajar sobre los equipos, procedimos a ponerlos en modo mantenimiento y por consiguiente apagarlos. El Cluster estaba conformado por seis ESXI 6.7 u3, así que decidimos hacer de a uno a la vez, para no tener que afectar a las VMs productivas.
Para los que no saben, cuando se trata de un Cluster vSAN y queremos poner un host en modo mantenimiento, vamos a tener 3 opciones disponibles:
- Garantizar la accesibilidad
Esta es la opción que viene por default. Al apagar o quitar el host del clúster, vSAN garantiza que todas las máquinas virtuales accesibles de este host sigan siendo accesibles. Seleccione esta opción si desea sacar el host del clúster temporalmente, por ejemplo, para instalar actualizaciones y planear que el host vuelva al clúster. Esta opción no es adecuada si desea quitar el host del clúster de forma permanente. Normalmente, solo se requiere evacuación parcial de datos. Sin embargo, es posible que la máquina virtual ya no sea totalmente compatible con una directiva de almacenamiento de máquina virtual durante la evacuación. Eso significa que es posible que no tenga acceso a todas sus réplicas. Si se produce un error mientras el host está en modo de mantenimiento y el nivel principal de errores que se toleran se establece en 1, es posible que experimente la pérdida de datos en el clúster. Este es el único modo de evacuación disponible si está trabajando con un clúster de tres hosts o un clúster de vSAN configurado con tres dominios de error.
- Migración completa de datos
vSAN evacua todos los datos a otros hosts del clúster, mantiene o corrige el cumplimiento de disponibilidad de los componentes afectados y protege los datos cuando existen recursos suficientes en el clúster. Seleccione esta opción si tiene previsto migrar el host permanentemente. Al evacuar datos del último host del clúster, asegúrese de migrar las máquinas virtuales a otro almacén de datos y, a continuación, coloque el host en modo de mantenimiento. Este modo de evacuación da como resultado la mayor cantidad de transferencia de datos y consume la mayor cantidad de tiempo y recursos. Todos los componentes del almacenamiento local del host seleccionado se migran en otra parte del clúster. Cuando el host entra en modo de mantenimiento, todas las máquinas virtuales tienen acceso a sus componentes de almacenamiento y siguen cumpliendo con sus directivas de almacenamiento asignadas. Si no se puede acceder a un objeto de máquina virtual que tenga datos en el host y no se evacue por completo, el host no puede entrar en modo de mantenimiento.
- Sin migración de datos
vSAN no evacua ningún dato de este host. Si apaga o quita el host del clúster, es posible que algunas máquinas virtuales se vuelvan inaccesibles.
En nuestro caso seleccionamos la opción «Migración completa de datos». Por lo tanto, cada vez que poníamos un host en modo mantenimiento, todos los datos que se encontraban almacenados en los discos locales de capacidad eran migrados hacia otros miembros del Cluster. A la hora de evacuar los datos, tardaba aproximadamente 40 minutos por host, lo cual estaba dentro de los parámetros normales. Ahora bien, cuando le tocó el turno al host número 4, nos encontramos con una demora que no esperábamos. En total demoró unas 6 horas, un claro indicio de que algo no estaba bien (obviamente si lo comparamos con los otros).
Una vez apagado el host, procedimos a ejecutar «vSAN Skyline Health» (una feature que siempre recomiendo) y nos encontramos con la siguiente alarma:
Efectivamente el Cluster no estaba balanceado de manera correcta, había hosts ESXI que tenían muchos más datos almacenados que el resto. Un claro ejemplo era el ESXI 4, el cual había demorado mucho más a la hora de migrar los datos. Investigando un poco sobre si existía alguna feature o servicio que realice la tarea de balanceo de manera automática, nos topamos con la siguiente KB: https://kb.vmware.com/s/article/2149809 .
Así que procedimos a realizar los pasos que se detallan en la misma:
¡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 la virtualización es tu hobby o si te dedicas de manera profesional, te invito a que te suscribas.
¡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 