50 Preguntas y Respuestas sobre vSAN - Parte 3

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.

 

Deja un comentario

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

Utilizamos cookies propias y de terceros para facilitar y mejorar nuestros servicios. Al navegar por nuestra página web aceptas nuestras cookies.

Para más información, o para conocer cómo cambiar la configuración, lee nuestra Política de cookies. Saber más

Acepto

Mis Partners