• Escrito por 
  • Publicado en Blog
  • 4 comentarios

50 Preguntas y Respuestas sobre vSAN - Parte 5

50 Preguntas sobre vSAN 

41-Qué es y cuáles son las tareas del servicio CLOM?
El acrónimo CLOM proviene del daemon Cluster Level Object Manager que se encarga de aplicar las Políticas distribuyendo los componentes y definiendo su ubicación en los Disk Groups a través de los Hosts de ESXi del Cluster de vSAN, primero en los discos de Caché y luego en los de Capacidad.
A su vez también aplica un balanceo repartiendo la carga de los componentes entre los diferentes Disk Groups del Cluster y finalmente los discos de Capacidad.
Tanto cuando se despliega una nueva VM, como si cambiamos una política o si se produce un fallo que requiere generar nuevos componentes es CLOM quien define la ubicación así como también controla los tiempos límite para generar nuevas réplicas/componentes de los Objetos.
vSAN Health Check muestra el estado de CLOM que está ejecutándose en cada Nodo del Cluster de vSAN.

 

42-Qué ocurre cuando un disco de Capacidad deja de responder?
Depende de lo que se entienda por dejar de responder. vSAN considera dos potenciales estados en caso de fallo: Absent y Degraded.
Un disco se considera en estado Absent cuando de repente no se tiene acceso al mismo, sin mayores indicadores. Eso puede ocurrir debido a un fallo del que no se tenga información o simplemente si alguien removió físicamente el disco del Nodo. En ese caso vSAN esperará 60 minutos (tiempo por defecto que se puede modificar) hasta que el disco esté nuevamente operativo. En el caso que se cumpla el tiempo de espera y el disco siga en estado Absent se comenzarán a recrear los Componentes en otros discos de Capacidad, ya sea en el mismo Disk Group o en otro diferente, tanto del mismo Nodo como en algún otro, siempre aplicando las Políticas. Si el disco vuelve a estar operativo antes de los 60 minutos entonces comienza el proceso de resincronización de los componentes.
En el supuesto caso que un Nodo de vSAN reciba una notificación de fallo en Disco entonces se considera en estado Degraded. Cuando un disco de Capacidad está en modo Degraded inmediatamente comienza el proceso de creación de nuevas réplicas de los Componentes en otros discos de Capacidad.
Tanto si un disco de Capacidad está en modo Absent como Degraded vamos a tener VMs con estado Noncompliant.
Si estamos trabajando en un Cluster de vSAN All-Flash con Deduplicación y Compresión habilitado y falla un disco, ya sea de Capacidad o Caché, entonces todo el Disk Group fallará y se comenzará de forma inmediata con el proceso de creación de nuevas réplicas (en otros Disk Groups) de los componentes que estaban en el Disk Group perdido. La capacidad del vSAN Datastore se verá reducida con lo que aportaba en capacidad el Disk Group con fallo.

 vSAN Disk Absent

 

43-Un disco SSD de Caché no responde, qué sucede con el Disk Group?
En el supuesto caso de fallo, tanto Absent como Degraded, de un disco SSD que está configurado como Caché de un Disk Group, el Disk Group entero dejará de responder inmediatamente. Naturalmente que todas las VMs que tenían componentes almacenados en el mencionado Disk Group pasarán a un estado Non-Compliant y de forma inmediata comenzará el proceso de recreación de los componentes en otros Disk Groups del Cluster.

 vSAN Disk Group Fail

 

44-En una situación de una partición de Red (vSAN Network) cómo afecta al funcionamiento y réplicas de las VMs?
Un Host de vSAN en una situación de partición de Red no puede aportar recursos de Almacenamiento y por lo tanto todos los componentes almacenados en esos Disks Groups afectados aparecerán como Absent y automáticamente las VMs propietarias de esos componentes cambiarán su estado a Non-Compliant.
Dependerá de la política de Alta Disponibilidad configurada en cada VM Storage Policy para vSAN el nivel de tolerancia a fallos. Evidentemente el número de fallos a tolerar podrá ser igual al número de Hosts afectados por la partición pero no superior.
Si transcurridos los 60 minutos (valor por defecto) no se resuelve el estado de partición en la red, vSAN comenzará a crear nuevas réplicas de los componentes en Disk Groups de otros Hosts según las Políticas y los recursos disponibles.
Vale la pena mencionar que una vez que habilitamos vSAN el servicio de vSphere HA dejará de utilizar los VMkernel de Management para utilizar los VMkernel de vSAN con el objetivo de evitar inconsistencias en caso de partición y/o fallos de red.

 

45-Debemos poner un Host de vSAN en Mantenimiento, cuál es el procedimiento correcto y las opciones disponibles?
Desde que aprovisionamos recursos de Almacenamiento en los Hosts del Cluster la puesta en Mantenimiento de un Nodo tiene mayor impacto que si solo tuviésemos capacidad de Cómputo.
Al poner un Host de vSAN en modo mantenimiento tenemos tres opciones (además de la opción de migrar VMs si tenemos habilitado DRS):

vSAN Host Mant Opciones
-Evacuar toda la data a otros Hosts (Evacuate all data to other hosts): Cuando un Host estará más de 60 minutos fuera de producción o si daremos de baja el Nodo entonces tendremos que seleccionar esta opción. Lo que ocurrirá será que absolutamente todos los bloques de datos se crearán nuevamente en Disk Groups de otros Hosts. Hay que tener en cuenta que con esta opción generaremos mucho movimiento de datos en la red de vSAN por lo que no se recomienda hacerlo en horario de máxima producción.
-Asegurar accesibilidad (Ensure data accessibility from other hosts): Si necesitamos parchear o actualizar un Host y el período de tiempo que estará el Nodo fuera de producción se estima que será inferior a 60 minutos, entonces esta opción generará un menor impacto en la red de vSAN. Replicará los bloques de datos únicos (sin otra réplica en otros Hosts) hacia otros Disks Groups para asegurar la continuidad de todas las VMs. El impacto de esta opción es que las VMs con componentes en los Disk Groups de ese Nodo estarán en estado Non-Compliant al tener componentes en estado Absent.
-No mover ningún dato (No data evacuation): Seleccionamos esta opción si estamos seguros que todos los Objetos de las VMs disponen de Réplicas sea cual sea el método de protección.

vSAN Host Maintenance

Una de las novedades en vSAN es el Pre-check evacuation que nos muestra las VMs y sus componentes que tendrá que mover dependiendo cada opción que seleccionemos. Muy bueno!!!

vSAN Pre-Check 

 

46-Cómo afecta al vSAN Datastore y las VMs cuando un Host deja de responder?
Cuando un Host deja de responder el estado de todas las VMs que tengan componentes en los Disk Groups de ese Nodo cambiarán a Non-Compliant. El estado de los recursos de Almacenamiento del Nodo estará, para vSAN, en modo Absent por lo que comienza a correr el reloj dando un margen de 60 minutos hasta que el Nodo se recupere (antes de los 60 minutos) o bien para comenzar a crear nuevas Replicas (a partir de los 60 minutos).
En toda situación de recursos de Almacenamiento ya sea Absent o Degraded, a nivel de Disco de Capacidad, Disk Group y/o Nodo la capacidad del vSAN Datastore se verá reducida en la capacidad RAW que aportan todos los discos de Capacidad que no están prestando servicio.

 

47-Qué sucede si un RAID Controller dejar de Responder?
El RAID Controller en un Host de ESXi que forma parte de un vSAN Cluster únicamente trabaja para ser de nexo entre los discos físicos y el Hypervisor. No hace ningún tipo de RAID ni mucho menos funciona como Caché de Escritura.
Si un RAID Controller deja de funcionar eso supone que todos los discos presentados al Hypervisor también dejarán de responder. Fallo total. En todo caso los Disk Groups de ese Nodo dejarán de funcionar.
Si el ESXi es capaz de identificarlo como un fallo (Degraded) entonces comenzará inmediatamente la creación de los objetos en los Disk Groups de los otros Nodos.
De esta forma el RAID Controller se convierte en un punto único de fallo y es por eso que se recomienda tener dos por Nodo.

 

48-Qué herramientas hay disponibles para Monitorizar un Cluster de vSAN?
Además del mejorado vSphere Web Client (Flash) hay disponibles varias herramientas. Ruby vSphere Console es una herramienta instalada por defecto en vCenter, para ambas plataformas, que nos permite visualizar el estado, configuración y monitorización de todo el Cluster desde línea de comandos. Es especialmente útil en entornos con múltiples Clusters para administradores que se sienten cómodos utilizando líneas de comando.
PowerCLI tiene cada vez más comandos para vSAN. Si bien está muy orientado a automatizar configuraciones también es posible visualizar el estado del Cluster, Host, Red, Disk Groups y gestión de Políticas para VMs incluso utilizando TAGs. Muy útil cuando se trata de administradores con conocimientos previos de Powershell y PowerCLI.

vSAN vROps
vRealize Operations Manager incluye en su versión 6.6 un Management Pack para vSAN por defecto. vROps es la herramienta con mayúsculas cuando se trata de monitorización, análisis y gestión de capacidad de infraestructuras VMware.

vSAN vRealize Operations Manager

Además trabaja en conjunto con su socio preferido que es Log Insight (troubleshooting), ahora integrado en el GUI del propio vROps. Éste es mi preferido ;-)

 

49-En caso que la instancia de vCenter que gestiona el vSAN Cluster cae con un Host, qué ocurre?
De la misma forma que vSphere HA es agnóstico al servicio de vCenter, vSAN no tiene una dependencia en cuanto a funcionamiento. vSphere HA trabaja en conjunto con vSAN para aprovisionar de alta disponibilidad tanto en recursos de Cómputo (HA) como también de Almacenamiento (vSAN) y en caso de caída del Host en el que está funcionando vCenter o bien si la VM de vCenter deja de responder vSAN seguirá operativo.
vCenter puede estar protegida con Políticas de vSAN tanto dentro de un Site como entre Sites en caso de Stretched Cluster configurado.

 

50-Cuál es el procedimiento correcto de actualización de un Cluster de vSAN?
El servicio de vSAN en general está embebido tanto en cada ESXi como también en vCenter por lo que al actualizar cada instancia estamos también actualizando vSAN.
El procedimiento correcto sería el siguiente:

-Todas las instancias de PSC (requerido para vCenter)
-vCenter
-Hosts del Cluster
-vSAN File System (si corresponde en la actualización)

Como se puede apreciar es recomendable disponer de una buena ventana de mantenimiento para la actualización.

 

Hasta aquí llegamos!!! 50 preguntas y respuestas sobre vSAN que bien perfectamente podrías haber sido un Post para cada pregunta. Ni bien tenga tiempo voy a armar un PDF con las 50 preguntas con imágenes y con información adicional para compartir. 

Como siempre espero que te haya resultado de utilidad. Espero tu feedback y si te parece que le puede servir a mas gente dale a compartir!!!

Nos vemos en el próximo Post ;-)

 

4 comentarios

  • Fede
    Fede Jueves, 22 Octubre 2020 09:59 Enlace al Comentario

    Hola Pablo,

    Como ventaja de usar Erasure Coding con un fallo (RAID 5) resepecto a mirroring es el menor consumo de espacio. En R5 consumes un 133% vs un 200%.
    Si estás utilizando all-flash, dependiendo de las aplicaciones y la demanda, muchas veces es apenas perceptible el impacto del calculo de paridad.
    Te recomiendo que vayas cambiando políticas de a poco y verifiques si ves un impacto considerable en cuanto al rendimiento.

  • Pablo
    Pablo Martes, 20 Octubre 2020 07:32 Enlace al Comentario

    Buenas

    Tenemos un cluster de 5 nodos vSAN con almacenamiento All Flash, pero el crecimiento que estamos teniendo es elevado.

    Por defecto, teniamos una politica de almacenamiento basada en RAID1, pero estamos pensando en cambiarla a RAID5 porque necesitamos mas espacio y ahora mismo no podemos crecer comprando nada mas.

    Que ventajas/desventajas a nivel de rendimiento de I/O de disco hay entre ellas?

    Gracias

  • Fede
    Fede Jueves, 11 Octubre 2018 07:29 Enlace al Comentario

    Hola Johanna,

    Muchas gracias por los comentarios.

    En cuanto a tu pregunta debo decir que habría que enfocarla de otra forma. Ese cálculo que estás buscando podríamos obtenerlo fácilmente con almacenamiento clásico a nivel de bloque o fichero.

    En el caso de vSAN estamos hablando de un Almacenamiento basado en Objetos y con Políticas aplicadas a los diferentes Objetos. Cada política impactará de forma diferente en las VMs, debido a su nivel de tolerancia a fallos.

    En el caso que optaras por utilizar una única política como PFTT=1 + FTM = Erasure Coding (Raid 5), podrías tener una idea bastance cercana al consumo por VM considerando que, por defecto, los Swap files vienen con una política PFTT=1 + FTM=Mirroring (Raid 1) y con reserva de espacio.

    Pero de esta forma estarías eliminando la flexibilidad que te aporta vSAN.

    Espero haberte aclarado la duda.

    Un saludo

  • Johanna Ballen
    Johanna Ballen Viernes, 17 Agosto 2018 21:43 Enlace al Comentario

    Hola Federico, Excelente artículo felicidades!!

    Hay alguna formula para calcular el tamaño efectivo de un Disk Group o del cluster?

    Gracias.

Deja un comentario

Muchas gracias por tus comentarios!!
Tras la revisión rutinaria, será publicado.