Éste es el primer Post de la serie de 50 Preguntas y Respuestas sobre VMware Virtual SAN. La solución de SDS de VMware viene creciendo de forma exponencial tanto en funcionalidades como en implementaciones y hay gran cantidad de conceptos, funcionalidades y buenas prácticas que merecen ser aclaradas. Comenzamos?

1-Qué diferencia hay entre el Almacenamiento Tradicional y vSAN?
El Almacenamiento tradicional está orientado a Bloques y/o Ficheros mientras que vSAN es un sistema de Almacenamiento orientado a Objetos.
Aunque los niveles de protección son similares (RAIDs, Réplicas, Snapshots, Etc) lo que difiere principalmente es el ámbito de protección y la forma de aprovisionar los recursos. Un sistema tradicional presenta sus recursos a través de LUNs y/o Carpetas y todo lo que se almacene en esos repositorios tendrán el mismo nivel de protección, además de disponer y gestionar los recursos de almacenamiento de forma centralizada.
En el caso de vSAN hablamos de un Almacenamiento distribuido entre los Hosts y un sistema de políticas de Protección/Rendimiento/Espacio que se aplican de forma individual a nivel de Objeto. Entendemos como Objeto componentes de Maquinas Virtuales como VMDKs, Snapshots y ficheros Swap entre otros.

2-Puedo utilizar un disco SSD de consumo?
Es especialmente recomendable en vSAN verificar que nuestro Hardware está incluido en la VMware HCL para la versión de vSAN que vamos a utilizar, independientemente si estamos hablando de un disco SSD para Caché o Capacidad como si también hacemos referencia a un disco SATA para Capacidad.
En el caso de los discos SSD la principal diferencia, además del precio, es la cantidad de operaciones de escritura que el fabricante nos asegura que podremos realizar durante el período de garantía del disco. A esto le llamamos “Endurance”.
Incluso hasta podemos encontrar discos SSD de consumo con un mayor número de IOPS pero con menor “Endurance”. Esto es especialmente importante en los discos de Caché.
Los discos SSD están clasificados por clases según prestaciones como IOPS y su Endurance.

3-Es vSAN una solución 100% para entornos Hyperconvergentes?
No necesariamente. Justamente una de las mejores características de vSAN es la flexibilidad a la hora de utilizar Infraestructura. Si bien hablamos que vSAN y un entorno Hyperconvergente (HCI) van como anillo al dedo también hay Infraestructuras de Hosts no Hyperconvergentes totalmente soportados en vSAN. Este último caso se suele aplicar cuando buscamos un crecimiento (Scale Up) importante a nivel de Almacenamiento, especialmente en capacidad, utilizando Hosts con soporte de hasta 40 discos.
Por otra parte podemos comentar que en el caso de los sistemas Blade, si bien se pueden soportar, no es precisamente la mejor solución.

4-Cuáles serían los casos de uso de vSAN?
Personalmente no creo que haya casos de uso específicos para vSAN. Tal vez tendríamos que analizarlo a la inversa, es decir en qué entornos tal vez vSAN no sea la opción mas eficiente.
Independientemente de la comparativa de costes entre vSAN y un entorno clásico (inevitable) debemos considerar si existe algún tipo de limitación ya sea a nivel de Hardware, Soporte o incluso una carga de trabajo específico que indique que vSAN no sea la opción mas eficiente.
Por otra parte hay requerimientos que podríamos decir que son ideales para soportar con una infraestructura de vSAN como pueden ser un Cluster de Management, una solución de VDI, un entorno de Recuperación ante desastres, una Infraestructura en la Nube o hasta incluso el soporte para aplicaciones de rendimiento crítico.
Rendimiento crítico? Si, con las “nuevas” soluciones NVMe sobre Infraestructuras vSAN hablamos de otro concepto a nivel de Ancho de banda, IOPS y sobre todo Latencia.

5-Qué sería lo más importante a considerar en un Proyecto de vSAN?
El Diseño, sin lugar a dudas. Una futura implementación sin su correspondiente análisis de capacidad, rendimiento, disponibilidad, crecimiento, infraestructura, selección y validación de hardware con su correspondiente configuración puede terminar (muy probablemente) en una solución ineficiente, con importantes falencias e incluso con un sobrecosto en licenciamiento.
Una vez implementado vSAN es extremadamente fácil de gestionar pero la fase de diseño y análisis es especialmente importante en vSAN y no debe pasarse por alto.

6-Qué niveles de disponibilidad hay disponibles en vSAN?
Los diferentes ámbitos de protección en vSAN son Host, Rack y Datacenter, éstos últimos distribuidos en múltiples Sites.
Por un lado tenemos redundancia a nivel de Red en cada Host miembro del Cluster de vSAN y vale recordar que vSAN trabaja a nivel de Cluster de HA.
En cuanto a los niveles de protección de datos dependen tanto de las Políticas de vSAN como también de los recursos disponibles. El número de Discos, Hosts, Datacenters, Latencia entre Sites y Ancho de banda definen la posibilidad de aplicar las Políticas de protección.
Las políticas de protección incluyen diferentes Réplicas (RAID 1, RAID 5 y 6) dentro del mismo Datacenter y Réplicas (RAID 1) entre Datacenters. También es posible aplicar zonas de réplica entre Racks del mismo Datacenter así como también desplegar un 2-Node Cluster basado en Réplicas que aplican nivel de protección RAID 1.

7-Puedo reutilizar mi Hardware para desplegar vSAN?
La respuesta depende de qué Hardware estemos hablando. vSAN es muy estricto en cuanto al Hardware requerido, especialmente en Controladoras RAID y Discos. Si el Hardware figura en la vSAN HCL para la versión que se pretende implementar entonces no habrá ningún problema.
Debemos considerar además que en una Infraestructura Hyperconvergente es particularmente valioso un correcto análisis con su sizing correspondiente. Con esto evitamos situaciones como Host descompensados en algún recurso (CPU, RAM y/o Almacenamiento) lo cual muchas veces se torna realmente difícil solventar, y a esto hay que agregarle un posible sobrecoste en licenciamiento por un Análisis, Sizing y Diseño ineficiente sin contar límites en el crecimiento y déficit en Alta Disponibilidad.

8-Sobre qué instalamos ESXi en una Infraestructura vSAN?
Normalmente utilizamos tarjetas SD, dispositivos USB o discos SATADOM. Últimamente los fabricantes de Hardware ofrecen sistemas de alta disponibilidad para tarjetas SD.
Lo que tenemos que considerar es que independientemente del medio que utilicemos para almacenar los binarios del ESXi, una vez que termina el proceso de carga del SO se levantan todos los binarios a memoria. Esto supone que no afecta al rendimiento y no es necesario utilizar grandes recursos para permitir el boot del ESXi dejando los discos SSD/SAS únicamente para Caché y Capacidad en un entorno vSAN.
Aunque debemos considerar que para Hosts de hasta 512GB de RAM podemos utilizar dispositivos USB o SD. En Hosts con RAM superior a 512GB tenemos que utilizar discos SATADOM.

9-Cómo puede escalar en Almacenamiento?
En vSAN se puede crecer de forma Vertical (Scale Up) u Horizontal (Scale Out). Todo depende de lo que se necesite y de los recursos (Infraestructura) que se disponga.
Un Host de vSAN puede soportar hasta 5 Grupos de Discos. Cada Grupo de Discos puede aprovisionarse con hasta 7 Discos de Capacidad. Esto supone que un Host de vSAN puede llegar a tener un máximo de 35 Discos de Capacidad repartidos en 5 Grupos de Discos, cada uno con 1 Disco de Caché y hasta 7 de Capacidad.
Es posible agregar en caliente discos de Capacidad a Grupos de discos existententes así como también Hosts adicionales, que aporten Almacenamiento, a Clusters de vSAN en Producción.
Un Cluster de vSAN puede estar configurado con hasta 64 Hosts. Esto supone un número importante de recursos tanto de Computo como también de Almacenamiento.

10-Qué pasa con el Datastore de VSAN si cae el servicio de vCenter?
Las maquinas virtuales seguirán trabajando sin problemas aunque no se podrán modificar Políticas de vSAN ni cambiar configuraciones hasta que el servicio de vCenter esté operativo nuevamente.
La caída de vCenter no impacta en la disponibilidad ni continuidad de las Maquinas Virtuales pero sí a la gestión del Cluster de vSAN.

Hasta aquí las primeras 10 de un total de 50 preguntas sobre vSAN. Como siempre espero que te resulte de utilidad y te invito a que lo compartas y comentes o bien sugieras mas preguntas.

Hasta el próximo Post!!!

En este segundo Post de la serie de vSAN continuamos con los conceptos, dudas comunes y funcionamiento de vSAN. En el primer Post de la serie hablamos de Hardware, Compatibilidad, Diseño y Funcionalidad entre otras cosas. Hoy toca hacer algo de foco en Caché, Grupos de Discos y conceptos en general. Algunos conceptos y funcionalidades importantes los ampliaremos a través de nuevas preguntas dentro de la misma serie.

11-Qué diferencia existe entre un Cluster Híbrido y uno All-Flash?
Un Cluster de vSAN Híbrido está compuesto por discos SSD para Caché y discos SAS o SATA para aportar Capacidad.
El vSAN Cluster All-Flash tiene discos SSD para Caché (también pueden ser NVMe) y los discos de Capacidad también son en tecnología Flash. El Cluster All-Flash requiere una conectividad de Red de 10GbE para la comunicación entre los Hosts y además dispone de las tecnologías de Compresión y Deduplicación las cuales se aplican en conjunto.
El funcionamiento de los discos de Caché es diferente en un Cluster Híbrido respecto al Cluster All-Flash como se explicará más adelante.
En un Cluster Híbrido las Políticas de Protección únicamente ofrecen RAID 1 mientras que en un Cluster All-Flash podemos, además de RAID 1, utilizar RAID 5 y/o RAID 6 (Erasure Coding), siempre dependiendo del número de Nodos.
Vale mencionar que para habilitar las funcionalidades de Compresión-Deduplicación y Erasure Coding (RAID 5 y RAID 6) es necesario que apliquemos la licencia Advanced al Cluster de vSAN.

12-Qué diferencia hay entre un Objeto, un Componente y un Witness?
En vSAN una Maquina Virtual está compuesta por hasta 5 tipos de Objetos:
VM home namespace / VMDKs / VM Swap / Discos Delta de Snapshots / Memoria de Snapshot
vSphere Web Client solo muestra 2 tipos de Objetos (VM home namespace y VMDKs) pero a nivel de línea de comandos podemos ver todos los Objetos de una VM.
Los componentes son el número de Réplicas que “componen” cada Objeto, basado siempre en las Políticas aplicadas. Las Políticas se asignan a cada Objeto de una VM, de forma que todos los Objetos de una VM pueden tener la misma Política o cada Objeto una Política diferente, según consideremos. Por ejemplo puedo aplicar una política a un VMDK de SO y otra política diferente a un segundo VMDK de Datos de la misma VM.
Un Witness es un componente que funciona a modo de Tie-Break y define la validez de un componente en caso de ausencia o fallo.
Dependiendo de la Política aplicada y el número de componentes podemos tener uno, varios o ningún Witness. La existencia y número de Witness lo define el sistema.

13-Qué es un Disk Group o Grupo de Discos?
Cada Host que aporta Almacenamiento en un Cluster de vSAN debe contar con, al menos, dos discos. Un disco para Caché y un disco de Capacidad. Un Grupo de Discos o Disk Group es un recurso de Almacenamiento compuesto por Capacidad y Caché. El Caché aporta rendimiento y el disco de Capacidad espacio disponible en el Datastore de vSAN.
Un Host puede tener un máximo de 5 Grupos de Discos. Cada Grupo de Discos debe tener un disco SSD para Caché (solo 1) y un mínimo de 1 Disco de Capacidad con un máximo de 7 Discos de Capacidad por Grupo de Discos.
Se recomienda contar con al menos dos Grupos de Discos por Host por cuestiones de Disponibilidad y Distribución de carga.

14-Qué diferencia hay entre un disco de Caché y uno de Capacidad?
Evidentemente los discos de Caché aportan rendimiento y los de Capacidad incrementan el espacio disponible en el Datastore de vSAN pero veamos un poco mas en detalle las diferencias.
El funcionamiento de los discos de Caché es diferente entre los dos tipos de Clusters ya que en el caso del Híbrido los discos de Caché operan en modo lectura y escritura. El objetivo principal de los discos de Caché en un Cluster All-Flash es incrementar la vida útil de los discos SSD de Capacidad. Los discos de Caché en All-Flash únicamente funcionan para las operaciones de Escritura.
Esto supone que en vSAN todas las operaciones de escritura son gestionadas en primera instancia por los discos de Caché que enviarán el ACK al Owner. Dependiendo del número de Réplicas y su distribución (ambas definidas en la Política asignada) esos bloques nuevos o modificados se escribirán en paralelo en dos o más discos de Caché para luego hacer el “Destage” y escribir los bloques en los Discos de Capacidad.
En el caso de un Cluster All-Flash con Compresión y Deduplicación habilitada se aplica la Deduplicación, Compresión y finalmente el Destage (movimiento de los bloques desde Caché hacia los discos de Capacidad) en ese orden.
Como comentario adicional merece la pena añadir que para el caso de un Cluster de vSAN All-Flash, en la fase de Diseño, se eligen diferentes Clases de discos SSD para Caché y para Capacidad según su TBW como se explicará más adelante.

15-Las maquinas virtuales siempre accederán a almacenamiento local?
No necesariamente. vSAN no aplica lo que se conoce como “Data Locality” como sí hacen otros sistemas de SDS similares. VMware considera que estar moviendo los componentes de la VM (VMDKs, Swaps, Logs, Snaps, etc) entre los Hosts para que la VM siempre trabaje en modo “local” accediendo al Almacenamiento genera una sobrecarga de trabajo innecesaria incrementando además la latencia de acceso al Almacenamiento para el resto de VMs durante estos procesos. A esto hay que sumarle la tarea de reconstruir los bloques y niveles de disponibilidad según las políticas aplicadas.
En entornos con DRS y con carga de trabajo variable es muy común ver cómo las VMs migran automáticamente de un Host a otro. Esta misma situación ocurriría en caso de caída del Host en donde están trabajando las VMs.

16-Qué significa TBW? 
Las siglas TBW significa Terabytes written o Terabytes escritos. El TBW es un valor o propiedad que los fabricantes de discos indican en cada modelo o serie para definir la durabilidad o cantidad de operaciones / TBs de escritura que soportan los discos SSD durante el período de garantía (normalmente 5 años) antes de que comiencen a dar fallos las celdas del disco.
Este valor incluye el DWPD (Operaciones de escritura por día) o PBW (Petabytes escritos).

En términos prácticos esto define, en vSAN, el tipo de disco que debemos aprovisionar para Caché (y Capacidad en All-Flash) dependiendo del número de operaciones de escritura que debe soportar nuestro Cluster.

La ecuación para obtener el valor de TBW es la siguiente:
TWB (a 5 años) = Tamaño del Disco x DWPD x 365 x 5
TBW = 0.4TB x 10DWPD x 365 días x 5 años
TBW = 7300TBW

17-Necesito Switches Distribuidos?
No es un requerimiento el uso de Switches Distribuidos para vSAN pero sí muy recomendable.
Especialmente en Infraestructuras HCI en donde normalmente tenemos solo 2 interfaces de 10GbE como recurso es ideal aplicar NIOC (Network IO Control) que únicamente está disponible en Switches Distribuidos.
Con NIOC podemos establecer Shares, Reservas y Límites para gestionar los recursos de red en Port Groups de VMKernel y Virtual Machine.
La buena noticia es que no importa qué versión de vSphere estemos utilizando ya que al aplicar cualquier licencia de vSAN nos desbloqueará el uso de Switches Distribuidos.
Hay una serie de Best Practices a la hora de definir los valores de Shares y las políticas de Balanceo y Alta Disponibilidad. Las podemos encontrar en la Guía de Diseño de Red de vSAN.

18-Puedo agregar un Host sin Almacenamiento local al Cluster de vSAN?
Una vez que cumplimos con el requerimiento mínimo de 3 Hosts (que aportan Almacenamiento) por Cluster es posible agregar Hosts adicionales al Cluster sin necesidad que aporten Almacenamiento.
Todos los Hosts que formen parte del Cluster van a tener acceso al Datastore de vSAN.
Naturalmente que no sería lo ideal ya que tanto la idea, el concepto, el objetivo de un entorno SDS (especialmente sobre una Infraestructura HCI) es aportar Computo, Red y Almacenamiento en todos los Nodos.
Además todo hay que decirlo, todos los Hosts que forman parte del Cluster de vSAN deben tener su licencia correspondiente, tanto de vSphere como también de vSAN.

19-Mi solución de Backup soporta VSAN?
Cualquier solución de Backup es agnóstica a un Almacenamiento en donde trabajen las VMs a copiar. Los Softwares de Backup que trabajan con vSphere lo hacen a través del vSphere Storage API Data Protection. vSAN no es la excepción y también trabaja con el API.
Esto supone que podemos seguir utilizando nuestra actual solución de Backup cuando creamos un nuevo Cluster de vSAN o bien cuando migramos nuestras maquinas a ese vSAN Cluster existente.

20-Tengo varios Clusters sobre un mismo vCenter, cómo se comparte VSAN en ese caso?
No se comparte. El Datastore de vSAN está disponible únicamente en los Hosts que son miembros del propio Cluster de vSAN.
Una vez que tenemos creado el Cluster de vSAN tendremos un único vSAN Datastore por Cluster, con independencia del número de Hosts (hasta un máximo de 64) y el número de Grupos de Discos (máximo 5 por cada Host).
vSAN 6.5 trajo entre sus novedades la posibilidad de compartir Almacenamiento iSCSI a través del Cluster de vSAN. Esta funcionalidad está orientada a servidores físicos y/o aplicaciones clusterizadas. La funcionalidad iSCSI de vSAN NO permite presentar este recurso a otros Hosts de ESXi ya sean miembros del mismo vCenter o de otro vCenter.

Hasta aquí otras 10 Preguntas y Respuestas de la serie, aquí podrás ver el Post de la parte 3 de la serie.

Como siempre espero que te resulte útil y si lo ves interesante te agradezco lo compartas. Cualquier comentario, corrección o pregunta será bien recibida en los comentarios del Post. 

Hasta el próximo Post!!!

Seguimos con la serie de Preguntas y Respuestas de vSAN y ya estamos en la tercera parte! Hoy toca avanzar con los niveles de Protección y algo de Diseño. 

21-Qué diferencia existe al trabajar con un RAID Controller en modo RAID y en modo Pass-through?
Un requerimiento extremadamente importante en vSAN es el RAID Controller. La controladora deberá estar en la HCL y tener la versión de Firmware soportado según la versión de vSphere/vSAN correspondiente.
Las controladores RAID (que en vSAN no se utilizar para configurar RAID) pueden trabajar en dos modos en un entorno vSAN: RAID o Pass-through (también llamado HBA mode).
Un RAID Controller en modo Pass-through presenta los discos de forma independiente como si se tratase de una LUN, aunque sin ningún nivel de protección. Ésta opción es la recomendada.
Si nuestra controladora no soporta el modo Pass-through (aunque esté en la vSAN HCL) es posible trabajar en modo RAID creando un RAID 0 por cada disco físico conectado, incluyendo los discos de Caché.
La diferencia es importante ya que en modo Pass-through el ESXi será capaz de supervisar el estado físico del disco y en caso de fallo solamente hay que reemplazar uno por otro en caliente.
En el caso de fallo de disco en una Controladora en modo RAID será necesario reiniciar el Host y acceder al BIOS de la RAID para eliminar el RAID 0 del disco que falló y crear un nuevo RAID 0 con el disco reemplazado. Como vemos esto impacta no solamente en los tiempos de Mantenimiento, posiblemente también en el SLA a la vez que no es para nada dinámico.
Por último merece la pena destacar que para cualquier Controladora que trabaje en vSAN, con independencia del modo de funcionamiento, se recomienda deshabilitar el Caché de escritura debido a que esa tarea la realizan los discos de Caché del propio vSAN dejando el 100% de Caché de la Controladora en modo Lectura.

22-Qué és un Fault Domain o Dominio de fallo?
vSAN Fault Domain nos permite incrementar la disponibilidad definiendo zonas de réplica. Éste sistema de protección está orientado a reducir el impacto en caso de fallo general a nivel de Rack (Alimentación, Cableado, Switching). Se define un mínimo de 3 Fault Domains y se agrega, al menos, un Host por cada Fault Domain. Una vez definidos y configurados los Fault Domains se comenzarán a distribuir las diferentes Réplicas entre los Hosts de los diferentes Racks, de igual forma con los Witness como si se tratase de una regla de Anti-Afinidad en DRS.
Las Réplicas se distribuirán de tal forma que, en caso de fallo de un Rack o Fault Domain, será posible continuar trabajando con las VMs utilizando las Réplicas existentes.

23-Puedo utilizar FT con vSAN?
Una VM que trabaje sobre un vSAN Datastore puede estar protegida con Fault Tolerance siempre y cuando el ámbito de trabajo sea el mismo Site (Site Local).
Esto significa que, al menos de momento, no está soportado Fault Tolerante en un entorno de vSAN Stretched Cluster debido a que los 5 ms de Latencia máxima soportada para Stretched Cluster son demasiados para una VM con SMP (Symetric Multi-Processor).
La buena noticia es que por más que tengamos configurado un entorno vSAN Stretched Cluster es posible, mediante las Políticas, configurar el nivel de Protección Local de la VM evitando que se replique entre los diferentes Sites. Esto lo hacemos definiendo la regla PFTT en 0 y SFTT en 1 o 2 dependiendo de los Hosts. Esto crea Réplicas de los Objetos de la VM solo en el Site Local.

24-Como se incrementa la capacidad en vSAN?
Los discos de Capacidad que forman parte de los Disks Groups son los que aportan capacidad al vSAN Datastore. Es posible agregar (y también quitar) en caliente discos de Capacidad a un Disk Group siempre y cuando no superemos el límite de 7.
Siempre que sea posible vamos a considerar disponer la misma cantidad, de la misma capacidad y la misma tecnología de discos en todos los Disks Groups de todos los Hosts del Cluster de vSAN aunque es posible tener configuraciones diferentes.
Una vez que agregamos un nuevo disco de Capacidad de forma automática se incrementará el espacio disponible en nuestro vSAN Datastore.

25-Qué requerimientos de Red exige vSAN para un correcto funcionamiento?
Depende del tipo de Cluster que vayamos a configurar.
Un Cluster de vSAN Híbrido puede trabajar con interfaces de 1GbE aunque se recomiendan interfaces de 10GbE.
En el caso del Cluster vSAN All-Flash se requieren interfaces de 10GbE.
La configuración de red para el Port Group de VMKernel de vSAN se define aprovisionando dos VMNics y estableciendo una configuración Active-StandBy. Esto quiere decir que la alta disponibilidad de los servicios de red de vSAN están gestionados por los Virtual Switches. Se recomienda el uso de vDS con NIOC definiendo valores de Shares y evitando establecer Reservas y Límites para gestionar la prioridad de cada Port Group en caso de contención de recursos de red.
La última versión de vSAN eliminó el requerimiento de configurar Multicast para las redes de vSAN.

26-Cuál es el número mínimo de Hosts para VSAN?
El número mínimo de Hosts para un Cluster de vSAN es 3. Desde vSAN 6.5 existe la posibilidad de desplegar lo que se conoce como un 2-Node vSAN Cluster, naturalmente configurado con 2 Hosts mas un Witness.
No obstante una cosa es el número mínimo de Hosts para configurar el Cluster y otra diferente el número mínimo de Hosts que se requieren según las Políticas a aplicar, incluyendo además la tecnología de protección requerida.
Aquí tenemos un ejemplo simple aunque no cubre todos los casos posibles:
RAID 1: 3 Hosts requeridos tolerando 1 Fallo (2 Hosts en un 2-Node Cluster + 1 Host Witness)
RAID 5: 4 Hosts requeridos tolerando 1 Fallo
RAID 6: 6 Hosts requeridos tolerando 2 Fallos

Existen más combinaciones entre números de fallos a tolerar, nivel de protección y las políticas PFTT y SFTT pero lo expuesto anteriormente es un ejemplo que nos servirá de introducción a la cantidad de recursos mínimos necesarios.

27-Qué es y cómo funciona el concepto de Object Ownership?
Por cada Objeto en vSAN se define un Owner o Propietario para tal objeto. El Owner de tal Objeto define quién ejecuta las operaciones de I/O del mismo para asegurar la consistencia.
El Owner a la vez es el encargado de comunicar al Component Manager cómo se puede acceder a tal Objeto (normalmente desde un cliente que es el ESXi).

28-Qué es Stretched Cluster?
Un vSAN Stretched Cluster es un sistema que permite replicar Objetos (y sus Componentes) entre dos Datacenters. Es como si tuviésemos un RAID 1 entre dos Datacenters activos pudiendo definir, a través de las políticas, cuál es el Datacenter en el que trabajará de forma “local” cada VM.
Para poder desplegar un vSAN Stretched Cluster necesitaremos 3 Datacenters. 2 Datacenters para Datos y 1 Datacenter para hostear el Witness que puede ser tanto físico como virtual. El Witness de Stretched Cluster funcionará de forma similar al componente Witness de las Réplicas como si fuera un Tie-Breaker.
Los requerimientos de vSAN Stretched Cluster, además de contar con 3 Sites, son los siguientes:
-Conectividad 10GbE entre los dos Datacenters de Datos. En un 2-Node Cluster es posible utilizar 1GbE con cable directo entre los Hosts.
-Latencia no superior a 5ms entre los dos Datacenters de Datos. Latencia de hasta 200ms entre los Hosts y el Witness.
-Mínimo de Hosts 1+1+1 (2 para Datos + 1 de Witness que puede ser virtual y además no consume licencia)
-Máximo de Hosts 15+15+1 (Hasta 15 Hosts de Datos en cada Site mas 1 de Witness)
-Instancia única de vCenter para gestionar todos los Hosts (puede estar protegido con vCenter HA entre los Sites)
-Comunicación L2 entre los Datacenters de Datos. Comunicación L2 o L3 entre los Hosts y el Witness.
-Licencia vSAN Enterprise o vSAN Enterprise for ROBO (para 2 Nodos + Witness)

29-Que diferencia hay entre SRM y vSAN Stretched Cluster?
VMware Site Recovery Manager es un sistema de Réplica y Orquestación orientado principalmente a Recuperación ante Desastres. También es posible utilizarlo para migrar Datacenters.
Como se explicó en la pregunta anterior vSAN Stretched Cluster está orientado a incrementar la disponibilidad de dos Datacenters activos gestionados por el mismo vCenter y replicando en modo RAID 1 utilizando la tecnología de vSAN.
La principal diferencia es que SRM puede trabajar tanto con vSphere Replication como motor de réplicas como también con sistemas de Réplicas propietarias de sistemas de almacenamiento como EMC, Netapp y similares. No tenemos la limitación de 5ms entre los Datacenters ni un ancho de banda específico aunque naturalmente los valores de RPO dependerán de los recursos existentes.
Para trabajar con SRM necesitamos un vCenter en cada Site y es posible definir procedimientos (orquestación) para la recuperación (cambios de IP, Scripts, prioridades, etc) así como también realizar simulaciones y aplicar un Failback si fuera necesario. No existe el concepto de Witness en SRM aunque el proceso de Failover es manual.
vSAN Stretched Cluster es principalmente el motor de Réplica entre los 2 Datacenters de Datos y la herramienta de recuperación a nivel de VMs entre los Hosts es un viejo conocido: vSphere HA.

30-Cómo se calcula el Almacenamiento disponible en un Cluster de vSAN?
Depende de si hablamos de Capacidad Bruta o Capacidad Neta.
En el caso de la capacidad bruta (RAW Capacity) de un vSAN Cluster es igual a la suma de todos los discos de Capacidad de todos Disks Groups de cada Nodo del Cluster. Fácil verdad?
No obstante basándonos en ese cálculo no llegamos a obtener o estimar la capacidad Neta. Haciendo una analogía con una cabina clásica sería igual a sumar la capacidad total de todos los discos y sabemos perfectamente que eso está muy alejado de la realidad.
La Capacidad Neta es variable ya que depende de múltiples factores. Por ejemplo una vez aplicada una política que requiere RAID 1 se crearán dos Réplicas (Componentes) de los Objetos de la VM mas un Witness. También impactan los ficheros Swap de las VMs (igual a la vRAM aprovisionada menos la reserva de memoria configurada) al igual que los Snapshots y sus correspondientes estados de memoria. Esto mismo hay que considerarlo con cada Objeto de cada VM del Cluster, incluso considerando que cada Política se puede modificar en tiempo real alterando la Capacidad Neta de ese momento.
A nivel de Diseño hay que considerar un 30% de espacio disponible para el Slack lo cual nos permite absorber el impacto de un Host en modo Mantenimiento, fallos en Disks Groups, Discos, etc.
Como vemos una cosa es el Diseño (la parte Lógica) y otra la realidad. Nuevamente merece la pena destacar lo importante de un buen diseño en un Cluster de vSAN para evitar sorpresas inesperadas.

En este cuarto Post de la serie de vSAN nos centraremos en las Virtual Machine Storage Policies. No es posible entender cómo trabaja vSAN si no comprendemos las Políticas. Naturalmente que cada vSAN Policy merece como mínimo un Post pero no es la naturaleza de esta serie la profundización. Ahí vamos!!!

31-Diferencia entre FTT, PFTT y SFTT?
Hasta la versión de vSAN 6.5 existía la política FTT (Failures to Tolerate) que definía el número de fallos a tolerar, como pérdida de Host o Disk Group. A partir de vSAN 6.6 se renombró esta política para afinar aún mas la protección en entornos vSAN Stretched Cluster utilizando PFTT en lugar de FTT y agregando la nueva Política SFTT. De esta forma entendemos porqué FTT aparece en alguna documentación y también la razón de que aparezca PFTT y SFTT (nueva Política) sin que hubiera ninguna mención a FTT en el mismo documento o Post.

PFTT (Primary Failures to Tolerate) indica el número de fallos en Hosts o Disk Groups con un valor por defecto de 1 y un valor máximo de 3.
En un entorno con vSAN Stretched Cluster PFTT define la Réplica a aplicar entre los Sites con un valor de 1 -> PFTT=1 que equivale a un RAID 1 entre los Objetos protegidos entre los 2 Sites a los que se les haya aplicado esta política. En vSAN Stretched Cluster PFTT puede, únicamente, estar configurado con valores de 0 o 1 cuando 0 equivale a que no queremos proteger ese Objeto entre los Sites.

Qué ocurre entonces con PFTT cuando no tenemos Stretched Cluster configurado? En esa situación configuramos la política con valores entre 0 y 3 definiendo los fallos a tolerar en nuestro único Site.

Está muy bien pero y ahora para qué sirve SFTT? SFTT aparece disponible para configurar únicamente cuando tenemos Stretched Cluster habilitado. Como mencionamos anteriormente PFTT, con vSAN SC, definimos el nivel de Protección entre Sites y con SFTT definimos el nivel de Protección local del Objeto.

Veamoslo mejor con ejemplos.
Ejemplo 1: Quiero proteger una VM y sus Objetos con vSAN SC y tolerar 2 fallos en el Site Local: PFTT=1 SFTT=2
Ejemplo 2: Tengo una VM que no quiero protegerla con vSAN SC y necesito tolerar 1 fallo en el Site Local: PFTT=0 SFTT=1
Ejemplo 3: Disponemos de un entorno sin vSAN Stretched Cluster configurado y queremos proteger el Objeto ante 2 fallos: PFTT=2

32-Cuál es el objetivo del concepto Site Affinity?
Cuando habilitamos vSAN Stretched Cluster creamos dos Sites con Hosts: Preferred y Secondary, además del Witness. Hay infraestructuras en las cuales ambos Sites están totalmente operativos en Producción y otras en las cuales únicamente tenemos un Site en Producción (Preferred) y el Site secundario simplemente como Réplica.
A través de la Política Site Affinity tenemos la posibilidad de asignar un Site a una VM/Objetos para que trabaje de forma “local” reduciendo además la latencia y el consumo de ancho de banda.

33-Por qué la Política Number of Disks Stripes Per Object no tiene sentido en un Cluster de vSAN All Flash?

Esta política define el número discos de Capacidad entre los cuales estará repartida cada Réplica pudiendo establecer un valor mínimo de 1 (valor por defecto) y un máximo de 12.
En vSAN Hybrid podría llegar a tener sentido para obtener un mayor número de IOPS al utilizar múltiples discos de Capacidad de forma simultánea aunque con su correspondiente incremento de consumo de recursos. Únicamente se aplica a los Objetos de VMs criticas.

En un Cluster de vSAN All-Flash los discos SSD de Capacidad son los que responden todas las operaciones de lectura y normalmente disponen de IOPS más que suficientes como para no necesitar crear Stripes adicionales. Es por eso que esta Política tiene un valor por defecto de 1.

34-Cuáles son las opciones de la Política vSAN Failure Tolerance Method?
Básicamente tenemos dos opciones con diferentes parámetros disponibles para definir el método de Replicación a utilizar. Estas opciones impactan tanto en el rendimiento como también en la capacidad del Datastore de vSAN.
Los métodos de protección son RAID 1 (Mirroring) y RAID 5/6 (Erasure Coding). La opción RAID 5/6 únicamente está disponible en un Cluster de vSAN All-Flash y viene acompañada por la Política PFTT con opciones 1 y 2.
Una Política Failure Tolerance Method configurada para utilizar RAID 1 vendrá acompañada con la Política PFTT con valores 0, 1 y 2 que define el número de Fallos a Tolerar y, evidentemente, el número de Replicas a generar. Recordemos que PFTT en vSAN Stretched Cluster únicamente tendrá como opciones 0 y 1. Esta Política consumirá mas espacio aunque no penalizará tanto en Rendimiento como RAID 5 o 6.
En el caso de la misma Política configurada para utilizar RAID 5/6 puede tener como opciones en PFTT 1 o 2 siendo las Replicas RAID 5 o RAID 6 respectivamente. Esta Política consumirá menos espacio pero debido al calculo y gestión de la distribución de los bloques de disco no tendrá el mismo rendimiento que un RAID 1.

Es muy importante destacar que todas estas configuraciones estarán disponibles únicamente en el caso de disponer del número de Hosts que requiera cada combinación de Políticas y valores.

35-Política vSAN Flash Reservation
La Política permite definir un porcentaje del Objeto VMDK que será reservado en el Caché de vSAN. Esto se aplica únicamente en Clusters Híbridos orientado a mejorar el Rendimiento. No solamente no debemos abusar de esta Política sino que, además de utilizarla únicamente en Clusters Híbridos, está orientada solamente a VMs críticas en cuanto a rendimiento.
Esta Política no aplica en un Cluster de vSAN All-Flash por razones obvias ya que todas las operaciones de Escritura y Lectura son gestionadas por discos Flash y no tiene ningún sentido aplicar esta Política en ese tipo de Cluster.

36-Política vSAN Force Provisioning
Existen situaciones en que desplegamos una nueva VM y le asignamos una Política determinada. Como mencionamos varias veces las Políticas y sus opciones necesitan de ciertos recursos (requerimientos) para poder ser cumplidas. Puede darse el caso que tengamos algún Host en modo Mantenimiento, un Host o un Disk Group caído. En todos esos casos el estado de cumplimiento para aplicar esa Política en concreto será Non-Compliant.
Por defecto si estamos en un estado Non-Compliant no se desplegará la nueva VM o bien no se aplicará la Política que queremos asignar al Objeto en cuestión.
La Política Force Provisioning (con valor No por defecto) puede configurarse en Yes y nos permitirá desplegar la VM o bien asignar la Política a un Objeto por más que estemos en modo Non-Compliant.

Esta configuración únicamente se recomienda en caso que tengamos la total certeza de que recuperaremos rápidamente el Host o el Disk Group.

37-Qué utilidad tiene la Política IOPS limit for object?
El caso de uso dependerá siempre del administrador pero claramente está orientada a establecer un límite en las operaciones tanto de Lectura como también de Escritura.
Esta Política no considera los aciertos en Caché, únicamente contabiliza y limita las operaciones en los discos de Capacidad. vSAN por defecto no aplica ningún límite de IOPS.

38-Qué es y cómo funciona la Política Disable object Checksum?
El valor por defecto de esta política es NO y significa que, por defecto, todos los objetos ejecutan una validación de integridad de datos. Configurar la Política en Yes deshabilitará la validación de la integridad de datos con su consecuente ahorro de recursos y mejora en rendimiento aunque con el riesgo de que nuestros datos no tengan la integridad correspondiente. Se recomienda dejar el valor por defecto.

39-Cómo se aplica la Política Object Space Reservation?
Por defecto todos los Objetos en vSAN se crean en formato Thin Provisioning. Si bien es posible con la Política Object Space Reservation crear una reserva de espacio para Objetos de VMs críticas en cuanto a disponibilidad eso no supone que cambiará el formato. La política puede estar configurada en 0% (por defecto) o en 100%. Con una política configurada en 100% se creará una reserva en el Datastore de vSAN (se reducirá el espacio disponible) por el espacio aprovisionado en los Objetos afectados por la Política. Se recomienda nunca cambiar este valor en la Política por Defecto.

40-Cuáles son las opciones por defecto en la vSAN Default Storage Policy?
Ahora que estamos familiarizados con las Políticas de vSAN ya podemos analizar las opciones por defecto de la vSAN Default Storage Policy. Lo importante de esto es que si creamos cualquier Política adicional y no definimos alguna opción en concreto, en ese caso se utilizarán los valores de la Política por defecto cuando sea necesario.

Podemos ver que hay un nivel de protección RAID 1 con un PFTT=1 sin forzar el aprovisionamiento en caso de estado Non-Compliant y finalmente sin reserva de Caché ni reserva de espacio en disco.

Como siempre espero que te haya resultado de utilidad y cualquier duda me dejas un comentario. Nos vemos en el próximo y último Post de la serie!!!

Otro excelente libro del gran Xavier Genestós que en esta ocasión nos descubre con todo detalle el servicio RDS que tanto utilizamos.

Antes de mi reseña quisiera destacar dos apectos muy importantes para mí.

La primera es que este Post no es esponsorizado, lo escribo por el respeto personal y profesional que le tengo al autor.

La segunda es que me quito el sombrero ante un autor de libro técnico hoy en día, especialmente en idioma español. A medida que nos especializamos en una tecnología en concreto es cada vez mas difícil encontrar material en cualquier idioma que no sea el ingles. Bravo Xavi!!!

Tanto si trabajamos con tecnología RDS como si también lo hacemos sobre una infraestructura Citrix nos vendrá muy bien la cantidad de información que podremos encontrar en este libro. En la misma línea que en sus libros anteriores veremos explicaciones simples, concretas, prácticas y lo más importante, enfocadas al mundo real.

Una combinación de capturas de pantalla, tablas y comandos hacen que sea un libro muy fácil de leer y que resulte útil tanto para los que estén buscando aprender desde cero como para los que ya tengan algún conocimiento en el servicio de Escritorios Remotos de Windows.
Un ejemplo de esto es que parte de los conceptos del Protocolo y Servicios RDP en un capítulo y en otros se explica el Dimensionamiento, Rendimiento y Certificados SSL.

Información sobre el libro:
Título: Remote Desktop Services para administradores de IT
Autor: Xavier Genestós @sysadmit
Idioma: Español
Formato: Papel A4
Páginas: 198
Precio: € 35.-
Se puede comprar en: http://www.lulu.com/shop/xavier-genest%C3%B3s/rdsit-remote-desktop-services-para-administradores-de-it/paperback/product-23321423.html

Índice:
-Índice
-Prólogo
-Presentación
-Copyright
-Protocolo RDP
-Arquitectura
-Dimensionado y Rendimiento
-Instalación en un Dominio de AD
-Instalación en un Workgroup
-Colecciones y RemotAPP
-Certificados SSL
-Licencias RDS
-Escenarios paso a paso
-Portapapeles
-Impresoras
-Sesión de consola y modos RDP
-Shadow
-Draine Mode
-Combinaciones de teclas
-Instalación de aplicaciones
-Herramientas administrativas de líneas de comandos
-Seguridad
-Herramientas para la resolución de problemas
-Alta disponibilidad
-Próximas publicaciones

Éste es el décimo libro de Xavi Genestós!!! Nuevamente me quito el sombrero por un profesional que dedica su tiempo a escribir con calidad y en nuestro idioma.

Dudas de como adquirir estos libros? aquí un FAQ: http://www.sysadmit.com/p/faq-libros.html

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.

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.

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):

-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.

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!!!

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.

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.

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 ;-)

Si bien el badge de vSAN no se considera una certificación, aunque el precio sea exactamente el mismo que cualquier otra, la demanda y las implementaciones de vSAN están creciendo de forma exponencial.
Siempre dije que una certificación no asegura que tengas el conocimiento y experiencia supuesto, pero ayuda a abrir puertas.

En este Post voy a compartir mi experiencia preparando el examen y los recursos necesarios para poder aprobarlo sin sobresaltos.

Voy a comenzar diciendo que no es una certificación difícil, si bien son 60 preguntas realmente no profundiza demasiado en asuntos complejos.
Lo primero que tenemos que hacer es descargar el Exam Preparation Guide en el que encontraremos absolutamente todo lo que entra en el examen.

Es fundamental tener muy claras las reglas de vSAN en cuanto a requerimientos, tipos de discos, límites y políticas aplicadas a los diferentes Clusters disponibles.

Existe gran cantidad de documentación y Posts sobre vSAN como para aburrir. De lejos los Posts de Cormac Hogan son los mejores y más numerosos aunque hay muchos que son técnicamente avanzados incluso para el examen.

También disponemos de una importante colección de videos en Youtube y aquí recomiendo especialmente la serie de VMware muy bien presentada por Elver Sena Sosa:

Serie vSAN en Youtube presentada por Elver Sena Sosa

What is vSAN?: vSAN Architecture Series #1  

vSAN Disk Groups: vSAN Architecture Series #2 

vSAN Objects: vSAN Architecture Series #3

vSAN Data Placement: vSAN Architecture Series #4 

vSAN FTT: vSAN Architecture Series #5

vSAN Failure Management: vSAN Architecture Series #6

vSAN Erasure Coding: vSAN Architecture Series #7

vSAN Striping: vSAN Architecture Series #8

vSAN Network Architecture: vSAN Architecture Series #9

vSAN Distributed Storage: vSAN Architecture Series #10

vSAN 2-Node Cluster: vSAN Architecture Series #11

vSAN Stretched Clusters: vSAN Architecture Series #12

No es requerimiento asistir a un curso oficial de vSAN aunque evidentemente puede ayudar tanto la parte teórica como sobre todo los Labs.

Advertencia: No tenemos excusa si no disponemos de Lab!!! VMware pone a nuestra disposición unos tremendos Labs (10 puntos + IVA) en su plataforma HOL (Hands On Labs) que son totalmente gratuitos.
En cuestión de un minuto (literal) tendremos listo para comenzar a usar los recursos de Labs con sus correpondientes manuales paso a paso. 

Recomiendo los HOL-1808-01-HCI y HOL-1808-02-HCI, ambos sobre vSAN 6.6.

Y si bien es una buena idea seguir el manual la primera vez que hacemos el Lab tenemos que tener en cuenta que no es obligatorio utilizar el mismo. Con esto confirmo que podemos levantar el Lab y utilizarlo según nos interese ;-)

A continuación tenemos, en líneas generales, información del examen 2VB-601:

Código del examen: 2VB-601

Duración: 105 minutos 

Número de preguntas: 60

Idioma disponible: Ingles

Modalidad: Múltiple choice

Curso obligatorio: No

Precio: U$S 250.-

Como recurso adicional tengo en mi Blog un buen resumen con la serie 50 preguntas y respuestas sobre vSAN que consta de 5 partes y que seguramente te vengan muy bien a la hora de preparar el examen.

Como siempre espero que te haya resultado de utilidad y te pido que me ayudes a compartirlo para que mas gente pueda aprovecharlo.

Y por último espero tu comentario en este Post cuando hayas pasado la certificación!!!

El pasado 15 de Mayo Vembu anunció su ultimo gran release con importantes novedades como ya nos tiene acostumbrados.

A destacar la version Standard que está orientada especialmente a Small business con precios muy competitivos.

La Suite Vembu BDR fué diseñada para proteger ambientes Privados, Públicos e Híbridos para plataformas Virtuales (ESXi – Hyper-V), Cloud y Físicas.

La version 3.9.0 viene con foco principal en mejoras para la Restauración de Datos, Almacenamiento y Seguridad de la información.

Entre las novedades de la version 3.9.0 podemos ver:

-Soporte para Tape Backup

-Quick VM Recovery

-Encriptación a nivel de Backup

-Autorización automatic en OffsiteDR

-Scripts Pre/Post en tareas de Backup

Qué hay de Nuevo en la version 3.9.1?

Como mencionamos anteriormente la nueva version Standard es la gran novedad la cual permite ser más competitiva en cuanto a orientación del negocio y su precio correspondiente.

De forma paralela a la version Standard tenemos ahora disponible la version Enterprise orientado a todo tipo de negocios.

Características destacables de Vembu BDR Suite:

-Backup para VMware y Hyper-V sin agentes

-Quick VM recovery

-Instant File Recovery

-Recuperación granular para aplicaciones Microsoft

-RTO de 15 minutos

-Compresión y deduplicación

-Encriptación AES-256

Te invito a que visites la web de Vembu para comprobar los precios competitivos en todas sus variantes y considerarla como opción económica de Backup y Replicación.

Existen versiones de prueba totalmente funcionales por 30 días.

Para más consultas: vembu-support@vembu.com

 Hace poco más de año y medio los dos gigantes de servicios Cloud llegaron a un acuerdo. Amazon AWS como líder en Cloud Pública en servicios de Infraestructura (IaaS) y VMware como dueño indiscutible del mercado de Cloud Privada.

El acuerdo permite ofrecer a los clientes lo mejor de cada mundo, la madurez y versatilidad del Stack de VMware (vSphere, vSAN y NSX) sobre el Cómputo, servicios y las Comunicaciones en los super Datacenters de Amazon distribuidos en Regiones y Availability zones.

En esta ecuación Amazon estará a cargo del Hardware y todos los servicios del Datacenter como conectividad a Internet, IPs públicas y otros servicios disponibles dentro del portfolio de AWS.
VMware gestiona la infraestructura desplegada bajo demanda, incluyendo configuración inicial, parcheado y actualizaciones. Esto incluye vCenter, ESXi’s, vSAN y NSX.

Y por último y no menos importante el cliente se encarga de migrar y administrar sus cargas de trabajo, además de pagar las facturas por el servicio.

1-vSAN Metrics
Topic: Performance and Troubleshooting
Problem: Poor performance
Impact: High. The Workloads might not receive the expected resources for a base performance
Cause: Host, Device or Network failure. Not optimal vSAN Design. Design or Sizing didn't align with Best Practices
Checklist:
Max Disk Group Congestion
Read Cache / Write Cache Latency (ms)
Avg Read / Write Latency (ms)
vSAN Port Group Packets Dropped
Capacity Disk Latency (ms)
Min Disk Group Write Buffer free (%)
Sum Disk Group Errors
Read Cache Hit Rate (%) (Hybrid vSAN Cluster)
Read Cache Miss Rate Ratio (Hybrid vSAN Cluster)
Best Practice: Align Cache, Endurance and Capacity disks based on Workload behaviour expected (Write, Read and Mix use intensive)

2-What if
Topic: Potential failures on Host Resources or Fault Domains
Problem: After a vSAN failure the Cluster doesn’t have the minimum amount of Resources to provide Availability based on the PFTT Policy Rule
Impact: Medium-High. Components state might be Degraded, Absent or Stale. Some VMs Objects would not be available
Cause: A Host in Maintenance mode, Network partition, Host Isolated, Controller Failure, Disk Failure
Checklist:
RVC: vsan.whatif_host_failures
vSphere Client Health Check -> Limits -> After 1 additional Host failure
ESXCLI vsan health cluster get -t "After 1 additional host failure”
Best Practice: Don’t use the minimum amount of Hosts per Cluster

3-Hardware Compatibility
Topic: vSAN Compatibility Guide (VCG)
Problem: Hardware not supported. Firmware and Drivers not validated
Impact: Medium-High. vSphere Health Check will show a warning or error. VMware support may not accept the ticket
Cause: The Hardware is not in the vSAN VCG for the current vSphere version. The Hardware-Firmware-Driver is not supported or validated for the current version. Firmware and-or Driver was not updated after a vSphere Upgrade
Checklist:
https://www.vmware.com/resources/compatibility
vSphere Client vSAN Health Check -> Hardware compatibility
vSphere Client vSAN Health Check -> Online health -> vCenter Server up to date
esxcli vsan debug controller list
Best Practice: Use vSAN Ready Nodes if possible. Always check the VCG before Upgrading. Keep the vSAN HCL DB (vCenter Health Check) up to date.

4-Network Performance
Topic: Network Configuration and Bandwidth
Problem: Network misconfiguration, physical errors, dropped packets, poor performance
Impact: High. Network problems might result in Isolated Hosts, vSAN Cluster Partitions and implications in the Availability and Performance
Cause: Not following the Best Practices for Network Design. The Network resources provided for vSAN VMkernel are not enough. Potential failures in the Physical layer
Checklist:
Sum vSAN Portgroup Packets Dropped (%)
Total Throughput (KBps)
vSphere Client vSAN Health Check -> Network -> Hosts with connectivity issues
Best Practice: 10Gbps for All-Flash at a minimum. QoS at the physical layer. NIOC if you share vmnics. Jumbo Frames and one VLAN per vSAN Cluster. Enable vDS with Health Check in vCenter.

5-vSAN Components Resynchronizing
Topic: vSAN Object Compliance
Problem: After a Failure or Rebalance the vSAN Cluster has to re-create Components. While that process takes place it is not recommended to run any Maintenance task such as Upgrade, apply a new Policy to existing VMs, force a Proactive Rebalance or put a Host in Maintenance mode.
Impact: Medium-High. It’s possible to see an impact on the Performance. Based on the Available Resources and the PFTT and FTM policy’s, if one Host enters in Maintenance mode, that might affect the Availability of some Components.
Cause: Host or Device failure, proactive or reactive rebalance, Maintenance task and Change vSAN Policy.
Checklist:
vSphere Client -> vSAN Cluster -> Monitor -> vSAN -> Resyncing Components
RVC: vsan.resync_dashboard
PowerCLI -> Get-VsanResyncingComponent -Cluster $cluster
Best Practice: Provide enough Network resources and avoid the deployment of vSAN Clusters with a minimal amount of Hosts (based on the PFTT and FTM rules).

6-vSAN Hosts and KMS Clusters
Topic: vSAN Encryption
Problem: After a general outage over a vSAN Cluster with Encryption services enabled, the Hosts are not able to reach the KMS Servers.
Impact: High. The Virtual Machines in that Cluster won’t be able to be powered on.
Cause: A general outage that powered off all the Hosts and Virtual Machines, including vCenter Server VM.
Checklist:
vSphere Client vSAN Health Check -> Encryption -> vCenter and all hosts are connected to Key Management Servers
vCenter and Hosts have to be able to reach KMS Cluster that on 5696 Port
Best Practice: Avoid single point of failures. Add KMS Cluster based on IP. Don't encrypt vCenter VM.

7-Host Membership
Topic: vSAN Cluster Partitioned
Problem: The Host is not able to provide resources to the Cluster.
Impact: Medium-High. Some Objects will appear as non-compliance and some Components might be Absent.
Cause: Because of a logical problem, a network partition, misconfigurations and human errors, the vSAN Cluster is partitioned, one Host isolated or the Host is not a member of the Cluster (even if the vSphere Client shows the Host inside the Cluster in the UI).
Checklist:
esxcli vsan cluster get
RVC: vsan.cluster_info
vSphere Client vSAN Health Check -> Cluster -> vSphere cluster members
Best Practice: Follow the vSAN Network Design Best Practices. Avoid a SPOF.

8.-Stretched Cluster Sites Connectivity
Topic: Stretched Cluster
Problem: Available Bandwidth, high Latency and lost connectivity.
Impact: Medium. In the case of failures or high latency between Sites, Replicas might be impacted. A Witness failure will suppose Absent Components and Objects in non-compliance state and, for this reason, a Risk.
Cause: Poor network resources such as Low Bandwidth, high Latency and non-stable connectivity between Sites.
Checklist:
vSphere Client vSAN Health Check -> Stretched cluster
Available Bandwidth and Round Trip Latency between Sites (using 3rd party tools)
Best Practice: Follow the vSAN Network Design Best Practices for Stretched Cluster and 2 Node Cluster.

9.-Available Capacity
Topic: vSAN Storage Capacity
Problem: Low available capacity in the vSAN Cluster.
Impact: High. This situation might create a Risk if any failure takes place. It will limit some maintenance tasks and may restrict the creation of new VMs.
Cause: The design didn't consider the usable capacity, the growth, snapshots, swap files, slack and the impact of the policies.
Checklist:
Slack space (between 25% and 30%)
Total Disk Space (GB)
Disk Space Used (%)
Used Disk Space (GB)
Best Practice: Maintain a 25%-30% additional space for Slack. Consider the ratio Cache:Capacity when adding more capacity.

10.-Are you Following the vSAN Best Practices?
Topic: vSAN Best Practices to check
Checklist:
Two or more Disk Groups per Host
Two (or more) Disk Controllers per Host
QoS and Jumbo Frames
LACP (if already configured). Align physical switch configuration with vDS LACP
1 vSAN Cluster, 1 VMkernel PG, 1 VLAN
Use Passthrough Controller mode. Set 100% Read Cache on Controllers
Avoid Dedup and Compression on High-Performance Workloads
Sharing vmnics? Use vDS with NIOC. Configure Bandwidth reservation and high custom shares
Align Cache, Endurance and Capacity disks based on Workload behaviour expected (Write, Read and Mix use intensive)
Deploy homogenous Hosts Configurations for CPU, RAM, NETWORK and DISK
Configure BIOS Host Power Management for OS Controlled
Use multiple Storage Policies
Using controllers with high queue depth improves performance
Consider NVMe Devices for high-performance

Éste es el primer Post de la serie de 50 Preguntas y Respuestas sobre VMware Virtual SAN. La solución de SDS de VMware viene creciendo de forma exponencial tanto en funcionalidades como en implementaciones y hay gran cantidad de conceptos, funcionalidades y buenas prácticas que merecen ser aclaradas. Comenzamos?

1-Qué diferencia hay entre el Almacenamiento Tradicional y vSAN?
El Almacenamiento tradicional está orientado a Bloques y/o Ficheros mientras que vSAN es un sistema de Almacenamiento orientado a Objetos.
Aunque los niveles de protección son similares (RAIDs, Réplicas, Snapshots, Etc) lo que difiere principalmente es el ámbito de protección y la forma de aprovisionar los recursos. Un sistema tradicional presenta sus recursos a través de LUNs y/o Carpetas y todo lo que se almacene en esos repositorios tendrán el mismo nivel de protección, además de disponer y gestionar los recursos de almacenamiento de forma centralizada.
En el caso de vSAN hablamos de un Almacenamiento distribuido entre los Hosts y un sistema de políticas de Protección/Rendimiento/Espacio que se aplican de forma individual a nivel de Objeto. Entendemos como Objeto componentes de Maquinas Virtuales como VMDKs, Snapshots y ficheros Swap entre otros.

2-Puedo utilizar un disco SSD de consumo?
Es especialmente recomendable en vSAN verificar que nuestro Hardware está incluido en la VMware HCL para la versión de vSAN que vamos a utilizar, independientemente si estamos hablando de un disco SSD para Caché o Capacidad como si también hacemos referencia a un disco SATA para Capacidad.
En el caso de los discos SSD la principal diferencia, además del precio, es la cantidad de operaciones de escritura que el fabricante nos asegura que podremos realizar durante el período de garantía del disco. A esto le llamamos “Endurance”.
Incluso hasta podemos encontrar discos SSD de consumo con un mayor número de IOPS pero con menor “Endurance”. Esto es especialmente importante en los discos de Caché.
Los discos SSD están clasificados por clases según prestaciones como IOPS y su Endurance.

3-Es vSAN una solución 100% para entornos Hyperconvergentes?
No necesariamente. Justamente una de las mejores características de vSAN es la flexibilidad a la hora de utilizar Infraestructura. Si bien hablamos que vSAN y un entorno Hyperconvergente (HCI) van como anillo al dedo también hay Infraestructuras de Hosts no Hyperconvergentes totalmente soportados en vSAN. Este último caso se suele aplicar cuando buscamos un crecimiento (Scale Up) importante a nivel de Almacenamiento, especialmente en capacidad, utilizando Hosts con soporte de hasta 40 discos.
Por otra parte podemos comentar que en el caso de los sistemas Blade, si bien se pueden soportar, no es precisamente la mejor solución.

4-Cuáles serían los casos de uso de vSAN?
Personalmente no creo que haya casos de uso específicos para vSAN. Tal vez tendríamos que analizarlo a la inversa, es decir en qué entornos tal vez vSAN no sea la opción mas eficiente.
Independientemente de la comparativa de costes entre vSAN y un entorno clásico (inevitable) debemos considerar si existe algún tipo de limitación ya sea a nivel de Hardware, Soporte o incluso una carga de trabajo específico que indique que vSAN no sea la opción mas eficiente.
Por otra parte hay requerimientos que podríamos decir que son ideales para soportar con una infraestructura de vSAN como pueden ser un Cluster de Management, una solución de VDI, un entorno de Recuperación ante desastres, una Infraestructura en la Nube o hasta incluso el soporte para aplicaciones de rendimiento crítico.
Rendimiento crítico? Si, con las “nuevas” soluciones NVMe sobre Infraestructuras vSAN hablamos de otro concepto a nivel de Ancho de banda, IOPS y sobre todo Latencia.

5-Qué sería lo más importante a considerar en un Proyecto de vSAN?
El Diseño, sin lugar a dudas. Una futura implementación sin su correspondiente análisis de capacidad, rendimiento, disponibilidad, crecimiento, infraestructura, selección y validación de hardware con su correspondiente configuración puede terminar (muy probablemente) en una solución ineficiente, con importantes falencias e incluso con un sobrecosto en licenciamiento.
Una vez implementado vSAN es extremadamente fácil de gestionar pero la fase de diseño y análisis es especialmente importante en vSAN y no debe pasarse por alto.

6-Qué niveles de disponibilidad hay disponibles en vSAN?
Los diferentes ámbitos de protección en vSAN son Host, Rack y Datacenter, éstos últimos distribuidos en múltiples Sites.
Por un lado tenemos redundancia a nivel de Red en cada Host miembro del Cluster de vSAN y vale recordar que vSAN trabaja a nivel de Cluster de HA.
En cuanto a los niveles de protección de datos dependen tanto de las Políticas de vSAN como también de los recursos disponibles. El número de Discos, Hosts, Datacenters, Latencia entre Sites y Ancho de banda definen la posibilidad de aplicar las Políticas de protección.
Las políticas de protección incluyen diferentes Réplicas (RAID 1, RAID 5 y 6) dentro del mismo Datacenter y Réplicas (RAID 1) entre Datacenters. También es posible aplicar zonas de réplica entre Racks del mismo Datacenter así como también desplegar un 2-Node Cluster basado en Réplicas que aplican nivel de protección RAID 1.

7-Puedo reutilizar mi Hardware para desplegar vSAN?
La respuesta depende de qué Hardware estemos hablando. vSAN es muy estricto en cuanto al Hardware requerido, especialmente en Controladoras RAID y Discos. Si el Hardware figura en la vSAN HCL para la versión que se pretende implementar entonces no habrá ningún problema.
Debemos considerar además que en una Infraestructura Hyperconvergente es particularmente valioso un correcto análisis con su sizing correspondiente. Con esto evitamos situaciones como Host descompensados en algún recurso (CPU, RAM y/o Almacenamiento) lo cual muchas veces se torna realmente difícil solventar, y a esto hay que agregarle un posible sobrecoste en licenciamiento por un Análisis, Sizing y Diseño ineficiente sin contar límites en el crecimiento y déficit en Alta Disponibilidad.

8-Sobre qué instalamos ESXi en una Infraestructura vSAN?
Normalmente utilizamos tarjetas SD, dispositivos USB o discos SATADOM. Últimamente los fabricantes de Hardware ofrecen sistemas de alta disponibilidad para tarjetas SD.
Lo que tenemos que considerar es que independientemente del medio que utilicemos para almacenar los binarios del ESXi, una vez que termina el proceso de carga del SO se levantan todos los binarios a memoria. Esto supone que no afecta al rendimiento y no es necesario utilizar grandes recursos para permitir el boot del ESXi dejando los discos SSD/SAS únicamente para Caché y Capacidad en un entorno vSAN.
Aunque debemos considerar que para Hosts de hasta 512GB de RAM podemos utilizar dispositivos USB o SD. En Hosts con RAM superior a 512GB tenemos que utilizar discos SATADOM.

9-Cómo puede escalar en Almacenamiento?
En vSAN se puede crecer de forma Vertical (Scale Up) u Horizontal (Scale Out). Todo depende de lo que se necesite y de los recursos (Infraestructura) que se disponga.
Un Host de vSAN puede soportar hasta 5 Grupos de Discos. Cada Grupo de Discos puede aprovisionarse con hasta 7 Discos de Capacidad. Esto supone que un Host de vSAN puede llegar a tener un máximo de 35 Discos de Capacidad repartidos en 5 Grupos de Discos, cada uno con 1 Disco de Caché y hasta 7 de Capacidad.
Es posible agregar en caliente discos de Capacidad a Grupos de discos existententes así como también Hosts adicionales, que aporten Almacenamiento, a Clusters de vSAN en Producción.
Un Cluster de vSAN puede estar configurado con hasta 64 Hosts. Esto supone un número importante de recursos tanto de Computo como también de Almacenamiento.

10-Qué pasa con el Datastore de VSAN si cae el servicio de vCenter?
Las maquinas virtuales seguirán trabajando sin problemas aunque no se podrán modificar Políticas de vSAN ni cambiar configuraciones hasta que el servicio de vCenter esté operativo nuevamente.
La caída de vCenter no impacta en la disponibilidad ni continuidad de las Maquinas Virtuales pero sí a la gestión del Cluster de vSAN.

Hasta aquí las primeras 10 de un total de 50 preguntas sobre vSAN. Siguiente Post -> 50 preguntas y respuestas sobre vSAN - Parte 2.

Como siempre espero que te resulte de utilidad y te invito a que lo compartas y comentes o bien sugieras mas preguntas.

Hasta el próximo Post!!!

En este segundo Post de la serie de vSAN continuamos con los conceptos, dudas comunes y funcionamiento de vSAN. En el primer Post de la serie hablamos de Hardware, Compatibilidad, Diseño y Funcionalidad entre otras cosas. Hoy toca hacer algo de foco en Caché, Grupos de Discos y conceptos en general. Algunos conceptos y funcionalidades importantes los ampliaremos a través de nuevas preguntas dentro de la misma serie.

11-Qué diferencia existe entre un Cluster Híbrido y uno All-Flash?
Un Cluster de vSAN Híbrido está compuesto por discos SSD para Caché y discos SAS o SATA para aportar Capacidad.
El vSAN Cluster All-Flash tiene discos SSD para Caché (también pueden ser NVMe) y los discos de Capacidad también son en tecnología Flash. El Cluster All-Flash requiere una conectividad de Red de 10GbE para la comunicación entre los Hosts y además dispone de las tecnologías de Compresión y Deduplicación las cuales se aplican en conjunto.
El funcionamiento de los discos de Caché es diferente en un Cluster Híbrido respecto al Cluster All-Flash como se explicará más adelante.
En un Cluster Híbrido las Políticas de Protección únicamente ofrecen RAID 1 mientras que en un Cluster All-Flash podemos, además de RAID 1, utilizar RAID 5 y/o RAID 6 (Erasure Coding), siempre dependiendo del número de Nodos.
Vale mencionar que para habilitar las funcionalidades de Compresión-Deduplicación y Erasure Coding (RAID 5 y RAID 6) es necesario que apliquemos la licencia Advanced al Cluster de vSAN.

12-Qué diferencia hay entre un Objeto, un Componente y un Witness?
En vSAN una Maquina Virtual está compuesta por hasta 5 tipos de Objetos:
VM home namespace / VMDKs / VM Swap / Discos Delta de Snapshots / Memoria de Snapshot
vSphere Web Client solo muestra 2 tipos de Objetos (VM home namespace y VMDKs) pero a nivel de línea de comandos podemos ver todos los Objetos de una VM.
Los componentes son el número de Réplicas que “componen” cada Objeto, basado siempre en las Políticas aplicadas. Las Políticas se asignan a cada Objeto de una VM, de forma que todos los Objetos de una VM pueden tener la misma Política o cada Objeto una Política diferente, según consideremos. Por ejemplo puedo aplicar una política a un VMDK de SO y otra política diferente a un segundo VMDK de Datos de la misma VM.
Un Witness es un componente que funciona a modo de Tie-Break y define la validez de un componente en caso de ausencia o fallo.
Dependiendo de la Política aplicada y el número de componentes podemos tener uno, varios o ningún Witness. La existencia y número de Witness lo define el sistema.

13-Qué es un Disk Group o Grupo de Discos?
Cada Host que aporta Almacenamiento en un Cluster de vSAN debe contar con, al menos, dos discos. Un disco para Caché y un disco de Capacidad. Un Grupo de Discos o Disk Group es un recurso de Almacenamiento compuesto por Capacidad y Caché. El Caché aporta rendimiento y el disco de Capacidad espacio disponible en el Datastore de vSAN.
Un Host puede tener un máximo de 5 Grupos de Discos. Cada Grupo de Discos debe tener un disco SSD para Caché (solo 1) y un mínimo de 1 Disco de Capacidad con un máximo de 7 Discos de Capacidad por Grupo de Discos.
Se recomienda contar con al menos dos Grupos de Discos por Host por cuestiones de Disponibilidad y Distribución de carga.

14-Qué diferencia hay entre un disco de Caché y uno de Capacidad?
Evidentemente los discos de Caché aportan rendimiento y los de Capacidad incrementan el espacio disponible en el Datastore de vSAN pero veamos un poco mas en detalle las diferencias.
El funcionamiento de los discos de Caché es diferente entre los dos tipos de Clusters ya que en el caso del Híbrido los discos de Caché operan en modo lectura y escritura. El objetivo principal de los discos de Caché en un Cluster All-Flash es incrementar la vida útil de los discos SSD de Capacidad. Los discos de Caché en All-Flash únicamente funcionan para las operaciones de Escritura.
Esto supone que en vSAN todas las operaciones de escritura son gestionadas en primera instancia por los discos de Caché que enviarán el ACK al Owner. Dependiendo del número de Réplicas y su distribución (ambas definidas en la Política asignada) esos bloques nuevos o modificados se escribirán en paralelo en dos o más discos de Caché para luego hacer el “Destage” y escribir los bloques en los Discos de Capacidad.
En el caso de un Cluster All-Flash con Compresión y Deduplicación habilitada se aplica la Deduplicación, Compresión y finalmente el Destage (movimiento de los bloques desde Caché hacia los discos de Capacidad) en ese orden.
Como comentario adicional merece la pena añadir que para el caso de un Cluster de vSAN All-Flash, en la fase de Diseño, se eligen diferentes Clases de discos SSD para Caché y para Capacidad según su TBW como se explicará más adelante.

15-Las maquinas virtuales siempre accederán a almacenamiento local?
No necesariamente. vSAN no aplica lo que se conoce como “Data Locality” como sí hacen otros sistemas de SDS similares. VMware considera que estar moviendo los componentes de la VM (VMDKs, Swaps, Logs, Snaps, etc) entre los Hosts para que la VM siempre trabaje en modo “local” accediendo al Almacenamiento genera una sobrecarga de trabajo innecesaria incrementando además la latencia de acceso al Almacenamiento para el resto de VMs durante estos procesos. A esto hay que sumarle la tarea de reconstruir los bloques y niveles de disponibilidad según las políticas aplicadas.
En entornos con DRS y con carga de trabajo variable es muy común ver cómo las VMs migran automáticamente de un Host a otro. Esta misma situación ocurriría en caso de caída del Host en donde están trabajando las VMs.

16-Qué significa TBW? 
Las siglas TBW significa Terabytes written o Terabytes escritos. El TBW es un valor o propiedad que los fabricantes de discos indican en cada modelo o serie para definir la durabilidad o cantidad de operaciones / TBs de escritura que soportan los discos SSD durante el período de garantía (normalmente 5 años) antes de que comiencen a dar fallos las celdas del disco.
Este valor incluye el DWPD (Operaciones de escritura por día) o PBW (Petabytes escritos).

En términos prácticos esto define, en vSAN, el tipo de disco que debemos aprovisionar para Caché (y Capacidad en All-Flash) dependiendo del número de operaciones de escritura que debe soportar nuestro Cluster.

La ecuación para obtener el valor de TBW es la siguiente:
TWB (a 5 años) = Tamaño del Disco x DWPD x 365 x 5
TBW = 0.4TB x 10DWPD x 365 días x 5 años
TBW = 7300TBW

17-Necesito Switches Distribuidos?
No es un requerimiento el uso de Switches Distribuidos para vSAN pero sí muy recomendable.
Especialmente en Infraestructuras HCI en donde normalmente tenemos solo 2 interfaces de 10GbE como recurso es ideal aplicar NIOC (Network IO Control) que únicamente está disponible en Switches Distribuidos.
Con NIOC podemos establecer Shares, Reservas y Límites para gestionar los recursos de red en Port Groups de VMKernel y Virtual Machine.
La buena noticia es que no importa qué versión de vSphere estemos utilizando ya que al aplicar cualquier licencia de vSAN nos desbloqueará el uso de Switches Distribuidos.
Hay una serie de Best Practices a la hora de definir los valores de Shares y las políticas de Balanceo y Alta Disponibilidad. Las podemos encontrar en la Guía de Diseño de Red de vSAN.

18-Puedo agregar un Host sin Almacenamiento local al Cluster de vSAN?
Una vez que cumplimos con el requerimiento mínimo de 3 Hosts (que aportan Almacenamiento) por Cluster es posible agregar Hosts adicionales al Cluster sin necesidad que aporten Almacenamiento.
Todos los Hosts que formen parte del Cluster van a tener acceso al Datastore de vSAN.
Naturalmente que no sería lo ideal ya que tanto la idea, el concepto, el objetivo de un entorno SDS (especialmente sobre una Infraestructura HCI) es aportar Computo, Red y Almacenamiento en todos los Nodos.
Además todo hay que decirlo, todos los Hosts que forman parte del Cluster de vSAN deben tener su licencia correspondiente, tanto de vSphere como también de vSAN.

19-Mi solución de Backup soporta VSAN?
Cualquier solución de Backup es agnóstica a un Almacenamiento en donde trabajen las VMs a copiar. Los Softwares de Backup que trabajan con vSphere lo hacen a través del vSphere Storage API Data Protection. vSAN no es la excepción y también trabaja con el API.
Esto supone que podemos seguir utilizando nuestra actual solución de Backup cuando creamos un nuevo Cluster de vSAN o bien cuando migramos nuestras maquinas a ese vSAN Cluster existente.

20-Tengo varios Clusters sobre un mismo vCenter, cómo se comparte VSAN en ese caso?
No se comparte. El Datastore de vSAN está disponible únicamente en los Hosts que son miembros del propio Cluster de vSAN.
Una vez que tenemos creado el Cluster de vSAN tendremos un único vSAN Datastore por Cluster, con independencia del número de Hosts (hasta un máximo de 64) y el número de Grupos de Discos (máximo 5 por cada Host).
vSAN 6.5 trajo entre sus novedades la posibilidad de compartir Almacenamiento iSCSI a través del Cluster de vSAN. Esta funcionalidad está orientada a servidores físicos y/o aplicaciones clusterizadas. La funcionalidad iSCSI de vSAN NO permite presentar este recurso a otros Hosts de ESXi ya sean miembros del mismo vCenter o de otro vCenter.

Hasta aquí otras 10 Preguntas y Respuestas de la serie, aquí podrás ver el Post de la parte 3 de la serie.

Como siempre espero que te resulte útil y si lo ves interesante te agradezco lo compartas. Cualquier comentario, corrección o pregunta será bien recibida en los comentarios del Post. 

Hasta el próximo Post!!!

Seguimos con la serie de Preguntas y Respuestas de vSAN y ya estamos en la tercera parte! Hoy toca avanzar con los niveles de Protección y algo de Diseño. 

21-Qué diferencia existe al trabajar con un RAID Controller en modo RAID y en modo Pass-through?
Un requerimiento extremadamente importante en vSAN es el RAID Controller. La controladora deberá estar en la HCL y tener la versión de Firmware soportado según la versión de vSphere/vSAN correspondiente.
Las controladores RAID (que en vSAN no se utilizar para configurar RAID) pueden trabajar en dos modos en un entorno vSAN: RAID o Pass-through (también llamado HBA mode).
Un RAID Controller en modo Pass-through presenta los discos de forma independiente como si se tratase de una LUN, aunque sin ningún nivel de protección. Ésta opción es la recomendada.
Si nuestra controladora no soporta el modo Pass-through (aunque esté en la vSAN HCL) es posible trabajar en modo RAID creando un RAID 0 por cada disco físico conectado, incluyendo los discos de Caché.
La diferencia es importante ya que en modo Pass-through el ESXi será capaz de supervisar el estado físico del disco y en caso de fallo solamente hay que reemplazar uno por otro en caliente.
En el caso de fallo de disco en una Controladora en modo RAID será necesario reiniciar el Host y acceder al BIOS de la RAID para eliminar el RAID 0 del disco que falló y crear un nuevo RAID 0 con el disco reemplazado. Como vemos esto impacta no solamente en los tiempos de Mantenimiento, posiblemente también en el SLA a la vez que no es para nada dinámico.
Por último merece la pena destacar que para cualquier Controladora que trabaje en vSAN, con independencia del modo de funcionamiento, se recomienda deshabilitar el Caché de escritura debido a que esa tarea la realizan los discos de Caché del propio vSAN dejando el 100% de Caché de la Controladora en modo Lectura.

22-Qué és un Fault Domain o Dominio de fallo?
vSAN Fault Domain nos permite incrementar la disponibilidad definiendo zonas de réplica. Éste sistema de protección está orientado a reducir el impacto en caso de fallo general a nivel de Rack (Alimentación, Cableado, Switching). Se define un mínimo de 3 Fault Domains y se agrega, al menos, un Host por cada Fault Domain. Una vez definidos y configurados los Fault Domains se comenzarán a distribuir las diferentes Réplicas entre los Hosts de los diferentes Racks, de igual forma con los Witness como si se tratase de una regla de Anti-Afinidad en DRS.
Las Réplicas se distribuirán de tal forma que, en caso de fallo de un Rack o Fault Domain, será posible continuar trabajando con las VMs utilizando las Réplicas existentes.

23-Puedo utilizar FT con vSAN?
Una VM que trabaje sobre un vSAN Datastore puede estar protegida con Fault Tolerance siempre y cuando el ámbito de trabajo sea el mismo Site (Site Local).
Esto significa que, al menos de momento, no está soportado Fault Tolerante en un entorno de vSAN Stretched Cluster debido a que los 5 ms de Latencia máxima soportada para Stretched Cluster son demasiados para una VM con SMP (Symetric Multi-Processor).
La buena noticia es que por más que tengamos configurado un entorno vSAN Stretched Cluster es posible, mediante las Políticas, configurar el nivel de Protección Local de la VM evitando que se replique entre los diferentes Sites. Esto lo hacemos definiendo la regla PFTT en 0 y SFTT en 1 o 2 dependiendo de los Hosts. Esto crea Réplicas de los Objetos de la VM solo en el Site Local.

24-Como se incrementa la capacidad en vSAN?
Los discos de Capacidad que forman parte de los Disks Groups son los que aportan capacidad al vSAN Datastore. Es posible agregar (y también quitar) en caliente discos de Capacidad a un Disk Group siempre y cuando no superemos el límite de 7.
Siempre que sea posible vamos a considerar disponer la misma cantidad, de la misma capacidad y la misma tecnología de discos en todos los Disks Groups de todos los Hosts del Cluster de vSAN aunque es posible tener configuraciones diferentes.
Una vez que agregamos un nuevo disco de Capacidad de forma automática se incrementará el espacio disponible en nuestro vSAN Datastore.

25-Qué requerimientos de Red exige vSAN para un correcto funcionamiento?
Depende del tipo de Cluster que vayamos a configurar.
Un Cluster de vSAN Híbrido puede trabajar con interfaces de 1GbE aunque se recomiendan interfaces de 10GbE.
En el caso del Cluster vSAN All-Flash se requieren interfaces de 10GbE.
La configuración de red para el Port Group de VMKernel de vSAN se define aprovisionando dos VMNics y estableciendo una configuración Active-StandBy. Esto quiere decir que la alta disponibilidad de los servicios de red de vSAN están gestionados por los Virtual Switches. Se recomienda el uso de vDS con NIOC definiendo valores de Shares y evitando establecer Reservas y Límites para gestionar la prioridad de cada Port Group en caso de contención de recursos de red.
La última versión de vSAN eliminó el requerimiento de configurar Multicast para las redes de vSAN.

26-Cuál es el número mínimo de Hosts para VSAN?
El número mínimo de Hosts para un Cluster de vSAN es 3. Desde vSAN 6.5 existe la posibilidad de desplegar lo que se conoce como un 2-Node vSAN Cluster, naturalmente configurado con 2 Hosts mas un Witness.
No obstante una cosa es el número mínimo de Hosts para configurar el Cluster y otra diferente el número mínimo de Hosts que se requieren según las Políticas a aplicar, incluyendo además la tecnología de protección requerida.
Aquí tenemos un ejemplo simple aunque no cubre todos los casos posibles:
RAID 1: 3 Hosts requeridos tolerando 1 Fallo (2 Hosts en un 2-Node Cluster + 1 Host Witness)
RAID 5: 4 Hosts requeridos tolerando 1 Fallo
RAID 6: 6 Hosts requeridos tolerando 2 Fallos

Existen más combinaciones entre números de fallos a tolerar, nivel de protección y las políticas PFTT y SFTT pero lo expuesto anteriormente es un ejemplo que nos servirá de introducción a la cantidad de recursos mínimos necesarios.

27-Qué es y cómo funciona el concepto de Object Ownership?
Por cada Objeto en vSAN se define un Owner o Propietario para tal objeto. El Owner de tal Objeto define quién ejecuta las operaciones de I/O del mismo para asegurar la consistencia.
El Owner a la vez es el encargado de comunicar al Component Manager cómo se puede acceder a tal Objeto (normalmente desde un cliente que es el ESXi).

28-Qué es Stretched Cluster?
Un vSAN Stretched Cluster es un sistema que permite replicar Objetos (y sus Componentes) entre dos Datacenters. Es como si tuviésemos un RAID 1 entre dos Datacenters activos pudiendo definir, a través de las políticas, cuál es el Datacenter en el que trabajará de forma “local” cada VM.
Para poder desplegar un vSAN Stretched Cluster necesitaremos 3 Datacenters. 2 Datacenters para Datos y 1 Datacenter para hostear el Witness que puede ser tanto físico como virtual. El Witness de Stretched Cluster funcionará de forma similar al componente Witness de las Réplicas como si fuera un Tie-Breaker.
Los requerimientos de vSAN Stretched Cluster, además de contar con 3 Sites, son los siguientes:
-Conectividad 10GbE entre los dos Datacenters de Datos. En un 2-Node Cluster es posible utilizar 1GbE con cable directo entre los Hosts.
-Latencia no superior a 5ms entre los dos Datacenters de Datos. Latencia de hasta 200ms entre los Hosts y el Witness.
-Mínimo de Hosts 1+1+1 (2 para Datos + 1 de Witness que puede ser virtual y además no consume licencia)
-Máximo de Hosts 15+15+1 (Hasta 15 Hosts de Datos en cada Site mas 1 de Witness)
-Instancia única de vCenter para gestionar todos los Hosts (puede estar protegido con vCenter HA entre los Sites)
-Comunicación L2 entre los Datacenters de Datos. Comunicación L2 o L3 entre los Hosts y el Witness.
-Licencia vSAN Enterprise o vSAN Enterprise for ROBO (para 2 Nodos + Witness)

29-Que diferencia hay entre SRM y vSAN Stretched Cluster?
VMware Site Recovery Manager es un sistema de Réplica y Orquestación orientado principalmente a Recuperación ante Desastres. También es posible utilizarlo para migrar Datacenters.
Como se explicó en la pregunta anterior vSAN Stretched Cluster está orientado a incrementar la disponibilidad de dos Datacenters activos gestionados por el mismo vCenter y replicando en modo RAID 1 utilizando la tecnología de vSAN.
La principal diferencia es que SRM puede trabajar tanto con vSphere Replication como motor de réplicas como también con sistemas de Réplicas propietarias de sistemas de almacenamiento como EMC, Netapp y similares. No tenemos la limitación de 5ms entre los Datacenters ni un ancho de banda específico aunque naturalmente los valores de RPO dependerán de los recursos existentes.
Para trabajar con SRM necesitamos un vCenter en cada Site y es posible definir procedimientos (orquestación) para la recuperación (cambios de IP, Scripts, prioridades, etc) así como también realizar simulaciones y aplicar un Failback si fuera necesario. No existe el concepto de Witness en SRM aunque el proceso de Failover es manual.
vSAN Stretched Cluster es principalmente el motor de Réplica entre los 2 Datacenters de Datos y la herramienta de recuperación a nivel de VMs entre los Hosts es un viejo conocido: vSphere HA.

30-Cómo se calcula el Almacenamiento disponible en un Cluster de vSAN?
Depende de si hablamos de Capacidad Bruta o Capacidad Neta.
En el caso de la capacidad bruta (RAW Capacity) de un vSAN Cluster es igual a la suma de todos los discos de Capacidad de todos Disks Groups de cada Nodo del Cluster. Fácil verdad?
No obstante basándonos en ese cálculo no llegamos a obtener o estimar la capacidad Neta. Haciendo una analogía con una cabina clásica sería igual a sumar la capacidad total de todos los discos y sabemos perfectamente que eso está muy alejado de la realidad.
La Capacidad Neta es variable ya que depende de múltiples factores. Por ejemplo una vez aplicada una política que requiere RAID 1 se crearán dos Réplicas (Componentes) de los Objetos de la VM mas un Witness. También impactan los ficheros Swap de las VMs (igual a la vRAM aprovisionada menos la reserva de memoria configurada) al igual que los Snapshots y sus correspondientes estados de memoria. Esto mismo hay que considerarlo con cada Objeto de cada VM del Cluster, incluso considerando que cada Política se puede modificar en tiempo real alterando la Capacidad Neta de ese momento.
A nivel de Diseño hay que considerar un 30% de espacio disponible para el Slack lo cual nos permite absorber el impacto de un Host en modo Mantenimiento, fallos en Disks Groups, Discos, etc.
Como vemos una cosa es el Diseño (la parte Lógica) y otra la realidad. Nuevamente merece la pena destacar lo importante de un buen diseño en un Cluster de vSAN para evitar sorpresas inesperadas.

Hasta aquí la tercera parte de la serie de Preguntas y Respuestas sobre vSAN. Como siempre espero que te resulte de utilidad. Aquí puedes ver el siguiente Post de la serie.

En este cuarto Post de la serie de vSAN nos centraremos en las Virtual Machine Storage Policies. No es posible entender cómo trabaja vSAN si no comprendemos las Políticas. Naturalmente que cada vSAN Policy merece como mínimo un Post pero no es la naturaleza de esta serie la profundización. Ahí vamos!!!

31-Diferencia entre FTT, PFTT y SFTT?
Hasta la versión de vSAN 6.5 existía la política FTT (Failures to Tolerate) que definía el número de fallos a tolerar, como pérdida de Host o Disk Group. A partir de vSAN 6.6 se renombró esta política para afinar aún mas la protección en entornos vSAN Stretched Cluster utilizando PFTT en lugar de FTT y agregando la nueva Política SFTT. De esta forma entendemos porqué FTT aparece en alguna documentación y también la razón de que aparezca PFTT y SFTT (nueva Política) sin que hubiera ninguna mención a FTT en el mismo documento o Post.

PFTT (Primary Failures to Tolerate) indica el número de fallos en Hosts o Disk Groups con un valor por defecto de 1 y un valor máximo de 3.
En un entorno con vSAN Stretched Cluster PFTT define la Réplica a aplicar entre los Sites con un valor de 1 -> PFTT=1 que equivale a un RAID 1 entre los Objetos protegidos entre los 2 Sites a los que se les haya aplicado esta política. En vSAN Stretched Cluster PFTT puede, únicamente, estar configurado con valores de 0 o 1 cuando 0 equivale a que no queremos proteger ese Objeto entre los Sites.

Qué ocurre entonces con PFTT cuando no tenemos Stretched Cluster configurado? En esa situación configuramos la política con valores entre 0 y 3 definiendo los fallos a tolerar en nuestro único Site.

Está muy bien pero y ahora para qué sirve SFTT? SFTT aparece disponible para configurar únicamente cuando tenemos Stretched Cluster habilitado. Como mencionamos anteriormente PFTT, con vSAN SC, definimos el nivel de Protección entre Sites y con SFTT definimos el nivel de Protección local del Objeto.

Veamoslo mejor con ejemplos.
Ejemplo 1: Quiero proteger una VM y sus Objetos con vSAN SC y tolerar 2 fallos en el Site Local: PFTT=1 SFTT=2
Ejemplo 2: Tengo una VM que no quiero protegerla con vSAN SC y necesito tolerar 1 fallo en el Site Local: PFTT=0 SFTT=1
Ejemplo 3: Disponemos de un entorno sin vSAN Stretched Cluster configurado y queremos proteger el Objeto ante 2 fallos: PFTT=2

32-Cuál es el objetivo del concepto Site Affinity?
Cuando habilitamos vSAN Stretched Cluster creamos dos Sites con Hosts: Preferred y Secondary, además del Witness. Hay infraestructuras en las cuales ambos Sites están totalmente operativos en Producción y otras en las cuales únicamente tenemos un Site en Producción (Preferred) y el Site secundario simplemente como Réplica.
A través de la Política Site Affinity tenemos la posibilidad de asignar un Site a una VM/Objetos para que trabaje de forma “local” reduciendo además la latencia y el consumo de ancho de banda.

33-Por qué la Política Number of Disks Stripes Per Object no tiene sentido en un Cluster de vSAN All Flash?

Esta política define el número discos de Capacidad entre los cuales estará repartida cada Réplica pudiendo establecer un valor mínimo de 1 (valor por defecto) y un máximo de 12.
En vSAN Hybrid podría llegar a tener sentido para obtener un mayor número de IOPS al utilizar múltiples discos de Capacidad de forma simultánea aunque con su correspondiente incremento de consumo de recursos. Únicamente se aplica a los Objetos de VMs criticas.

En un Cluster de vSAN All-Flash los discos SSD de Capacidad son los que responden todas las operaciones de lectura y normalmente disponen de IOPS más que suficientes como para no necesitar crear Stripes adicionales. Es por eso que esta Política tiene un valor por defecto de 1.

34-Cuáles son las opciones de la Política vSAN Failure Tolerance Method?
Básicamente tenemos dos opciones con diferentes parámetros disponibles para definir el método de Replicación a utilizar. Estas opciones impactan tanto en el rendimiento como también en la capacidad del Datastore de vSAN.
Los métodos de protección son RAID 1 (Mirroring) y RAID 5/6 (Erasure Coding). La opción RAID 5/6 únicamente está disponible en un Cluster de vSAN All-Flash y viene acompañada por la Política PFTT con opciones 1 y 2.
Una Política Failure Tolerance Method configurada para utilizar RAID 1 vendrá acompañada con la Política PFTT con valores 0, 1 y 2 que define el número de Fallos a Tolerar y, evidentemente, el número de Replicas a generar. Recordemos que PFTT en vSAN Stretched Cluster únicamente tendrá como opciones 0 y 1. Esta Política consumirá mas espacio aunque no penalizará tanto en Rendimiento como RAID 5 o 6.
En el caso de la misma Política configurada para utilizar RAID 5/6 puede tener como opciones en PFTT 1 o 2 siendo las Replicas RAID 5 o RAID 6 respectivamente. Esta Política consumirá menos espacio pero debido al calculo y gestión de la distribución de los bloques de disco no tendrá el mismo rendimiento que un RAID 1.

Es muy importante destacar que todas estas configuraciones estarán disponibles únicamente en el caso de disponer del número de Hosts que requiera cada combinación de Políticas y valores.

35-Política vSAN Flash Reservation
La Política permite definir un porcentaje del Objeto VMDK que será reservado en el Caché de vSAN. Esto se aplica únicamente en Clusters Híbridos orientado a mejorar el Rendimiento. No solamente no debemos abusar de esta Política sino que, además de utilizarla únicamente en Clusters Híbridos, está orientada solamente a VMs críticas en cuanto a rendimiento.
Esta Política no aplica en un Cluster de vSAN All-Flash por razones obvias ya que todas las operaciones de Escritura y Lectura son gestionadas por discos Flash y no tiene ningún sentido aplicar esta Política en ese tipo de Cluster.

36-Política vSAN Force Provisioning
Existen situaciones en que desplegamos una nueva VM y le asignamos una Política determinada. Como mencionamos varias veces las Políticas y sus opciones necesitan de ciertos recursos (requerimientos) para poder ser cumplidas. Puede darse el caso que tengamos algún Host en modo Mantenimiento, un Host o un Disk Group caído. En todos esos casos el estado de cumplimiento para aplicar esa Política en concreto será Non-Compliant.
Por defecto si estamos en un estado Non-Compliant no se desplegará la nueva VM o bien no se aplicará la Política que queremos asignar al Objeto en cuestión.
La Política Force Provisioning (con valor No por defecto) puede configurarse en Yes y nos permitirá desplegar la VM o bien asignar la Política a un Objeto por más que estemos en modo Non-Compliant.

Esta configuración únicamente se recomienda en caso que tengamos la total certeza de que recuperaremos rápidamente el Host o el Disk Group.

37-Qué utilidad tiene la Política IOPS limit for object?
El caso de uso dependerá siempre del administrador pero claramente está orientada a establecer un límite en las operaciones tanto de Lectura como también de Escritura.
Esta Política no considera los aciertos en Caché, únicamente contabiliza y limita las operaciones en los discos de Capacidad. vSAN por defecto no aplica ningún límite de IOPS.

38-Qué es y cómo funciona la Política Disable object Checksum?
El valor por defecto de esta política es NO y significa que, por defecto, todos los objetos ejecutan una validación de integridad de datos. Configurar la Política en Yes deshabilitará la validación de la integridad de datos con su consecuente ahorro de recursos y mejora en rendimiento aunque con el riesgo de que nuestros datos no tengan la integridad correspondiente. Se recomienda dejar el valor por defecto.

39-Cómo se aplica la Política Object Space Reservation?
Por defecto todos los Objetos en vSAN se crean en formato Thin Provisioning. Si bien es posible con la Política Object Space Reservation crear una reserva de espacio para Objetos de VMs críticas en cuanto a disponibilidad eso no supone que cambiará el formato. La política puede estar configurada en 0% (por defecto) o en 100%. Con una política configurada en 100% se creará una reserva en el Datastore de vSAN (se reducirá el espacio disponible) por el espacio aprovisionado en los Objetos afectados por la Política. Se recomienda nunca cambiar este valor en la Política por Defecto.

40-Cuáles son las opciones por defecto en la vSAN Default Storage Policy?
Ahora que estamos familiarizados con las Políticas de vSAN ya podemos analizar las opciones por defecto de la vSAN Default Storage Policy. Lo importante de esto es que si creamos cualquier Política adicional y no definimos alguna opción en concreto, en ese caso se utilizarán los valores de la Política por defecto cuando sea necesario.

Podemos ver que hay un nivel de protección RAID 1 con un PFTT=1 sin forzar el aprovisionamiento en caso de estado Non-Compliant y finalmente sin reserva de Caché ni reserva de espacio en disco.

Como siempre espero que te haya resultado de utilidad y cualquier duda me dejas un comentario. Nos vemos en el próximo y último Post de la serie!!!

Otro excelente libro del gran Xavier Genestós que en esta ocasión nos descubre con todo detalle el servicio RDS que tanto utilizamos.

Antes de mi reseña quisiera destacar dos apectos muy importantes para mí.

La primera es que este Post no es esponsorizado, lo escribo por el respeto personal y profesional que le tengo al autor.

La segunda es que me quito el sombrero ante un autor de libro técnico hoy en día, especialmente en idioma español. A medida que nos especializamos en una tecnología en concreto es cada vez mas difícil encontrar material en cualquier idioma que no sea el ingles. Bravo Xavi!!!

Tanto si trabajamos con tecnología RDS como si también lo hacemos sobre una infraestructura Citrix nos vendrá muy bien la cantidad de información que podremos encontrar en este libro. En la misma línea que en sus libros anteriores veremos explicaciones simples, concretas, prácticas y lo más importante, enfocadas al mundo real.

Una combinación de capturas de pantalla, tablas y comandos hacen que sea un libro muy fácil de leer y que resulte útil tanto para los que estén buscando aprender desde cero como para los que ya tengan algún conocimiento en el servicio de Escritorios Remotos de Windows.
Un ejemplo de esto es que parte de los conceptos del Protocolo y Servicios RDP en un capítulo y en otros se explica el Dimensionamiento, Rendimiento y Certificados SSL.

Información sobre el libro:
Título: Remote Desktop Services para administradores de IT
Autor: Xavier Genestós @sysadmit
Idioma: Español
Formato: Papel A4
Páginas: 198
Precio: € 35.-
Se puede comprar en: http://www.lulu.com/shop/xavier-genest%C3%B3s/rdsit-remote-desktop-services-para-administradores-de-it/paperback/product-23321423.html

Índice:
-Índice
-Prólogo
-Presentación
-Copyright
-Protocolo RDP
-Arquitectura
-Dimensionado y Rendimiento
-Instalación en un Dominio de AD
-Instalación en un Workgroup
-Colecciones y RemotAPP
-Certificados SSL
-Licencias RDS
-Escenarios paso a paso
-Portapapeles
-Impresoras
-Sesión de consola y modos RDP
-Shadow
-Draine Mode
-Combinaciones de teclas
-Instalación de aplicaciones
-Herramientas administrativas de líneas de comandos
-Seguridad
-Herramientas para la resolución de problemas
-Alta disponibilidad
-Próximas publicaciones

Éste es el décimo libro de Xavi Genestós!!! Nuevamente me quito el sombrero por un profesional que dedica su tiempo a escribir con calidad y en nuestro idioma.

Dudas de como adquirir estos libros? aquí un FAQ: http://www.sysadmit.com/p/faq-libros.html

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.

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.

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):

-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.

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!!!

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.

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.

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 ;-)

Si bien el badge de vSAN no se considera una certificación, aunque el precio sea exactamente el mismo que cualquier otra, la demanda y las implementaciones de vSAN están creciendo de forma exponencial.
Siempre dije que una certificación no asegura que tengas el conocimiento y experiencia supuesto, pero ayuda a abrir puertas.

En este Post voy a compartir mi experiencia preparando el examen y los recursos necesarios para poder aprobarlo sin sobresaltos.

Voy a comenzar diciendo que no es una certificación difícil, si bien son 60 preguntas realmente no profundiza demasiado en asuntos complejos.
Lo primero que tenemos que hacer es descargar el Exam Preparation Guide en el que encontraremos absolutamente todo lo que entra en el examen.

Es fundamental tener muy claras las reglas de vSAN en cuanto a requerimientos, tipos de discos, límites y políticas aplicadas a los diferentes Clusters disponibles.

Existe gran cantidad de documentación y Posts sobre vSAN como para aburrir. De lejos los Posts de Cormac Hogan son los mejores y más numerosos aunque hay muchos que son técnicamente avanzados incluso para el examen.

También disponemos de una importante colección de videos en Youtube y aquí recomiendo especialmente la serie de VMware muy bien presentada por Elver Sena Sosa:

Serie vSAN en Youtube presentada por Elver Sena Sosa

What is vSAN?: vSAN Architecture Series #1  

vSAN Disk Groups: vSAN Architecture Series #2 

vSAN Objects: vSAN Architecture Series #3

vSAN Data Placement: vSAN Architecture Series #4 

vSAN FTT: vSAN Architecture Series #5

vSAN Failure Management: vSAN Architecture Series #6

vSAN Erasure Coding: vSAN Architecture Series #7

vSAN Striping: vSAN Architecture Series #8

vSAN Network Architecture: vSAN Architecture Series #9

vSAN Distributed Storage: vSAN Architecture Series #10

vSAN 2-Node Cluster: vSAN Architecture Series #11

vSAN Stretched Clusters: vSAN Architecture Series #12

No es requerimiento asistir a un curso oficial de vSAN aunque evidentemente puede ayudar tanto la parte teórica como sobre todo los Labs.

Advertencia: No tenemos excusa si no disponemos de Lab!!! VMware pone a nuestra disposición unos tremendos Labs (10 puntos + IVA) en su plataforma HOL (Hands On Labs) que son totalmente gratuitos.
En cuestión de un minuto (literal) tendremos listo para comenzar a usar los recursos de Labs con sus correpondientes manuales paso a paso. 

Recomiendo los HOL-1808-01-HCI y HOL-1808-02-HCI, ambos sobre vSAN 6.6.

Y si bien es una buena idea seguir el manual la primera vez que hacemos el Lab tenemos que tener en cuenta que no es obligatorio utilizar el mismo. Con esto confirmo que podemos levantar el Lab y utilizarlo según nos interese ;-)

A continuación tenemos, en líneas generales, información del examen 2VB-601:

Código del examen: 2VB-601

Duración: 105 minutos 

Número de preguntas: 60

Idioma disponible: Ingles

Modalidad: Múltiple choice

Curso obligatorio: No

Precio: U$S 250.-

Como recurso adicional tengo en mi Blog un buen resumen con la serie 50 preguntas y respuestas sobre vSAN que consta de 5 partes y que seguramente te vengan muy bien a la hora de preparar el examen.

Como siempre espero que te haya resultado de utilidad y te pido que me ayudes a compartirlo para que mas gente pueda aprovecharlo.

Y por último espero tu comentario en este Post cuando hayas pasado la certificación!!!

El pasado 15 de Mayo Vembu anunció su ultimo gran release con importantes novedades como ya nos tiene acostumbrados.

A destacar la version Standard que está orientada especialmente a Small business con precios muy competitivos.

La Suite Vembu BDR fué diseñada para proteger ambientes Privados, Públicos e Híbridos para plataformas Virtuales (ESXi – Hyper-V), Cloud y Físicas.

La version 3.9.0 viene con foco principal en mejoras para la Restauración de Datos, Almacenamiento y Seguridad de la información.

Entre las novedades de la version 3.9.0 podemos ver:

-Soporte para Tape Backup

-Quick VM Recovery

-Encriptación a nivel de Backup

-Autorización automatic en OffsiteDR

-Scripts Pre/Post en tareas de Backup

Qué hay de Nuevo en la version 3.9.1?

Como mencionamos anteriormente la nueva version Standard es la gran novedad la cual permite ser más competitiva en cuanto a orientación del negocio y su precio correspondiente.

De forma paralela a la version Standard tenemos ahora disponible la version Enterprise orientado a todo tipo de negocios.

Características destacables de Vembu BDR Suite:

-Backup para VMware y Hyper-V sin agentes

-Quick VM recovery

-Instant File Recovery

-Recuperación granular para aplicaciones Microsoft

-RTO de 15 minutos

-Compresión y deduplicación

-Encriptación AES-256

Te invito a que visites la web de Vembu para comprobar los precios competitivos en todas sus variantes y considerarla como opción económica de Backup y Replicación.

Existen versiones de prueba totalmente funcionales por 30 días.

Para más consultas: vembu-support@vembu.com

 Hace poco más de año y medio los dos gigantes de servicios Cloud llegaron a un acuerdo. Amazon AWS como líder en Cloud Pública en servicios de Infraestructura (IaaS) y VMware como dueño indiscutible del mercado de Cloud Privada.

El acuerdo permite ofrecer a los clientes lo mejor de cada mundo, la madurez y versatilidad del Stack de VMware (vSphere, vSAN y NSX) sobre el Cómputo, servicios y las Comunicaciones en los super Datacenters de Amazon distribuidos en Regiones y Availability zones.

En esta ecuación Amazon estará a cargo del Hardware y todos los servicios del Datacenter como conectividad a Internet, IPs públicas y otros servicios disponibles dentro del portfolio de AWS.
VMware gestiona la infraestructura desplegada bajo demanda, incluyendo configuración inicial, parcheado y actualizaciones. Esto incluye vCenter, ESXi’s, vSAN y NSX.

Y por último y no menos importante el cliente se encarga de migrar y administrar sus cargas de trabajo, además de pagar las facturas por el servicio.

1-vSAN Metrics
Topic: Performance and Troubleshooting
Problem: Poor performance
Impact: High. The Workloads might not receive the expected resources for a base performance
Cause: Host, Device or Network failure. Not optimal vSAN Design. Design or Sizing didn't align with Best Practices
Checklist:
Max Disk Group Congestion
Read Cache / Write Cache Latency (ms)
Avg Read / Write Latency (ms)
vSAN Port Group Packets Dropped
Capacity Disk Latency (ms)
Min Disk Group Write Buffer free (%)
Sum Disk Group Errors
Read Cache Hit Rate (%) (Hybrid vSAN Cluster)
Read Cache Miss Rate Ratio (Hybrid vSAN Cluster)
Best Practice: Align Cache, Endurance and Capacity disks based on Workload behaviour expected (Write, Read and Mix use intensive)

2-What if
Topic: Potential failures on Host Resources or Fault Domains
Problem: After a vSAN failure the Cluster doesn’t have the minimum amount of Resources to provide Availability based on the PFTT Policy Rule
Impact: Medium-High. Components state might be Degraded, Absent or Stale. Some VMs Objects would not be available
Cause: A Host in Maintenance mode, Network partition, Host Isolated, Controller Failure, Disk Failure
Checklist:
RVC: vsan.whatif_host_failures
vSphere Client Health Check -> Limits -> After 1 additional Host failure
ESXCLI vsan health cluster get -t "After 1 additional host failure”
Best Practice: Don’t use the minimum amount of Hosts per Cluster

3-Hardware Compatibility
Topic: vSAN Compatibility Guide (VCG)
Problem: Hardware not supported. Firmware and Drivers not validated
Impact: Medium-High. vSphere Health Check will show a warning or error. VMware support may not accept the ticket
Cause: The Hardware is not in the vSAN VCG for the current vSphere version. The Hardware-Firmware-Driver is not supported or validated for the current version. Firmware and-or Driver was not updated after a vSphere Upgrade
Checklist:
https://www.vmware.com/resources/compatibility
vSphere Client vSAN Health Check -> Hardware compatibility
vSphere Client vSAN Health Check -> Online health -> vCenter Server up to date
esxcli vsan debug controller list
Best Practice: Use vSAN Ready Nodes if possible. Always check the VCG before Upgrading. Keep the vSAN HCL DB (vCenter Health Check) up to date.

4-Network Performance
Topic: Network Configuration and Bandwidth
Problem: Network misconfiguration, physical errors, dropped packets, poor performance
Impact: High. Network problems might result in Isolated Hosts, vSAN Cluster Partitions and implications in the Availability and Performance
Cause: Not following the Best Practices for Network Design. The Network resources provided for vSAN VMkernel are not enough. Potential failures in the Physical layer
Checklist:
Sum vSAN Portgroup Packets Dropped (%)
Total Throughput (KBps)
vSphere Client vSAN Health Check -> Network -> Hosts with connectivity issues
Best Practice: 10Gbps for All-Flash at a minimum. QoS at the physical layer. NIOC if you share vmnics. Jumbo Frames and one VLAN per vSAN Cluster. Enable vDS with Health Check in vCenter.

5-vSAN Components Resynchronizing
Topic: vSAN Object Compliance
Problem: After a Failure or Rebalance the vSAN Cluster has to re-create Components. While that process takes place it is not recommended to run any Maintenance task such as Upgrade, apply a new Policy to existing VMs, force a Proactive Rebalance or put a Host in Maintenance mode.
Impact: Medium-High. It’s possible to see an impact on the Performance. Based on the Available Resources and the PFTT and FTM policy’s, if one Host enters in Maintenance mode, that might affect the Availability of some Components.
Cause: Host or Device failure, proactive or reactive rebalance, Maintenance task and Change vSAN Policy.
Checklist:
vSphere Client -> vSAN Cluster -> Monitor -> vSAN -> Resyncing Components
RVC: vsan.resync_dashboard
PowerCLI -> Get-VsanResyncingComponent -Cluster $cluster
Best Practice: Provide enough Network resources and avoid the deployment of vSAN Clusters with a minimal amount of Hosts (based on the PFTT and FTM rules).

6-vSAN Hosts and KMS Clusters
Topic: vSAN Encryption
Problem: After a general outage over a vSAN Cluster with Encryption services enabled, the Hosts are not able to reach the KMS Servers.
Impact: High. The Virtual Machines in that Cluster won’t be able to be powered on.
Cause: A general outage that powered off all the Hosts and Virtual Machines, including vCenter Server VM.
Checklist:
vSphere Client vSAN Health Check -> Encryption -> vCenter and all hosts are connected to Key Management Servers
vCenter and Hosts have to be able to reach KMS Cluster that on 5696 Port
Best Practice: Avoid single point of failures. Add KMS Cluster based on IP. Don't encrypt vCenter VM.

7-Host Membership
Topic: vSAN Cluster Partitioned
Problem: The Host is not able to provide resources to the Cluster.
Impact: Medium-High. Some Objects will appear as non-compliance and some Components might be Absent.
Cause: Because of a logical problem, a network partition, misconfigurations and human errors, the vSAN Cluster is partitioned, one Host isolated or the Host is not a member of the Cluster (even if the vSphere Client shows the Host inside the Cluster in the UI).
Checklist:
esxcli vsan cluster get
RVC: vsan.cluster_info
vSphere Client vSAN Health Check -> Cluster -> vSphere cluster members
Best Practice: Follow the vSAN Network Design Best Practices. Avoid a SPOF.

8.-Stretched Cluster Sites Connectivity
Topic: Stretched Cluster
Problem: Available Bandwidth, high Latency and lost connectivity.
Impact: Medium. In the case of failures or high latency between Sites, Replicas might be impacted. A Witness failure will suppose Absent Components and Objects in non-compliance state and, for this reason, a Risk.
Cause: Poor network resources such as Low Bandwidth, high Latency and non-stable connectivity between Sites.
Checklist:
vSphere Client vSAN Health Check -> Stretched cluster
Available Bandwidth and Round Trip Latency between Sites (using 3rd party tools)
Best Practice: Follow the vSAN Network Design Best Practices for Stretched Cluster and 2 Node Cluster.

9.-Available Capacity
Topic: vSAN Storage Capacity
Problem: Low available capacity in the vSAN Cluster.
Impact: High. This situation might create a Risk if any failure takes place. It will limit some maintenance tasks and may restrict the creation of new VMs.
Cause: The design didn't consider the usable capacity, the growth, snapshots, swap files, slack and the impact of the policies.
Checklist:
Slack space (between 25% and 30%)
Total Disk Space (GB)
Disk Space Used (%)
Used Disk Space (GB)
Best Practice: Maintain a 25%-30% additional space for Slack. Consider the ratio Cache:Capacity when adding more capacity.

10.-Are you Following the vSAN Best Practices?
Topic: vSAN Best Practices to check
Checklist:
Two or more Disk Groups per Host
Two (or more) Disk Controllers per Host
QoS and Jumbo Frames
LACP (if already configured). Align physical switch configuration with vDS LACP
1 vSAN Cluster, 1 VMkernel PG, 1 VLAN
Use Passthrough Controller mode. Set 100% Read Cache on Controllers
Avoid Dedup and Compression on High-Performance Workloads
Sharing vmnics? Use vDS with NIOC. Configure Bandwidth reservation and high custom shares
Align Cache, Endurance and Capacity disks based on Workload behaviour expected (Write, Read and Mix use intensive)
Deploy homogenous Hosts Configurations for CPU, RAM, NETWORK and DISK
Configure BIOS Host Power Management for OS Controlled
Use multiple Storage Policies
Using controllers with high queue depth improves performance
Consider NVMe Devices for high-performance