Vsan

H O S T E D P R I VAT E C L O U D
El camino más
rápido al cloud
OVH le ofrece la posibilidad de tener su propio Hosted Private Cloud: una infraestructura dedicada y físicamente
aislada para obtener un rendimiento óptimo. Su escalabilidad permite abarcar todas las necesidades empresariales,
desde las más básicas hasta las más avanzadas, disfrutando de todas las ventajas del alojamiento on-premises sin
una gran inversión de capital. Al estar administrada por OVH, usted podrá centrarse en la gestión de su negocio.
S O F T WA R E H A R D WA R E RED
Integración completa Acceso inmediato a una Red mundial de fibra óptica
en su sistema informático, infraestructura dedicada con ancho de banda
con vCenter y vSphere basada en los últimos garantizado, tráfico ilimitado
as a service. procesadores de Intel. y sin costes ocultos.
Lo mejor de la tecnología VMware

Construido sobre la misma plataforma que usted utiliza
actualmente en sus instalaciones, incluyendo vSphere, vCenter,
NSX y vSAN.
Basado en la tecnología Software-Defined Datacenter de VMware.
Con los mejores servicios que ya conoce, más la nueva opción
para desplegar entornos híbridos Hybrid Cloud Extension (HCX).
OVH.COM
PROMOVIENDO TU
TRANSFORMACIÓN
DIGITAL
Capítulo 7
vSAN
Federico Cinalli
#VMwarePorvExperts 302
Capítulo 7 - vSAN Federico Cinalli
1. Introducción y Casos de Uso
VMware presentó Virtual SAN (vSAN de aquí en adelante) durante el VMworld de 2013 (En USA)
aunque el GA recién estuvo disponible en Marzo de 2014 a partir de vSphere 5.5 U1.
Si bien en aquella época todavía no hablábamos de hiperconvergencia, sí que comenzábamos a hacer

referencia al Centro de Datos definido por Software mientras que NSX 6.0, en su primera versión, hacía
su presentación en Octubre de 2013 y comenzaba a patear el tablero de la virtualización de redes. En
aquellos meses estaba naciendo el tándem vSAN-NSX que sería la base, junto con vSphere, sobre la
que se sostiene el SDDC de VMware.
vSAN aporta una robusta solución de Almacenamiento definido por Software utilizando discos locales,
embebida en el Hypervisor, sin dependencia de ninguna pieza de Hardware en concreto ni ninguna
máquina virtual por Host.
Es un producto complementario a vSphere que, al igual que HA o DRS, se configura a nivel de

Cluster y se administra principalmente con vSphere Client aunque también es posible gestionarlo con
herramientas como PowerCLI, vRealize Orchestrator o incluso a través de API.
Las diferentes opciones de protección, capacidad y rendimiento se definen a nivel de objeto utilizando
las políticas de almacenamiento de Máquinas Virtuales en vCenter.
De la mano de vSphere 6.0 llegó también vSAN 6, siempre alineándose con la versión del Hypervisor.
El aporte más significativo fue la introducción de vSAN All Flash, lo que permitía comenzar a considerar
el producto como un serio candidato para dar soporte de almacenamiento a aplicaciones críticas.
Los primeros casos de uso de vSAN fueron entornos de VDI con la Suite Horizon, siendo el Cluster
Híbrido el uso más común. No obstante, a medida que VMware actualizaba vSphere hacía lo propio
con vSAN añadiendo más funcionalidades como la deduplicación y compresión, Stretched Cluster,
Encriptación y UNMAP entre otras. Según se libera una nueva versión de vSAN disponemos de una
plataforma cada vez más madura y estable si cabe, lo que permite ser considerado hoy en día, sin
lugar a dudas, como una gran solución de Almacenamiento definido por Software para aplicaciones
críticas.
Hoy en día, debido al descenso en los precios de los discos SSD e incluso NVMe, la gran mayoría de
los nuevos Clusters de vSAN son All-Flash permitiendo dar soporte a prácticamente cualquier tipo de
carga de trabajo.
Si bien es cierto que vSAN encaja a la perfección en infraestructuras HCI, no estamos hablando de una
solución exclusiva para ese tipo de hardware como sí lo son otros tipos de almacenamiento definidos
por software del mercado.
Es posible ver vSAN funcionando en producción sobre los servidores clásicos de 2U’s aportando una
capacidad importante de espacio disponible a la vez que aporta una escalabilidad tremenda en cuanto
a capacidad de almacenamiento.
En los datacenters en los que se despliega un Cluster de Management también vemos cada día más y
más Clusters de vSAN permitiendo un aislamiento en cuanto a capacidad, rendimiento y disponibilidad
respecto al almacenamiento utilizado para producción.
Existen no obstante determinadas aplicaciones o sistemas que tal vez no sean el ideal para vSAN
como pueden ser las soluciones de gestión documental que requieren grandes cantidades de
almacenamiento.
Debido a requerimientos de licencias podemos ver clusters de bases de datos desplegadas en hosts
físicos que necesiten acceso a un almacenamiento compartido. Si bien vSAN ofrece la posibilidad
de compartir LUNs a través de iSCSI para dar servicio a esos requerimientos no lo solemos ver en
producción, al menos todavía.
Por último, debemos aclarar que todos los conceptos que cubriremos en este capítulo están basados
en la versión 6.7 de vSAN.
2. Conceptos de vSAN
El sistema de almacenamiento definido por software de VMware es extremadamente simple de

implementar y administrar. No obstante, para comprender de forma correcta cómo es la configuración
y administración necesitamos aprender ciertos conceptos y componentes claves en vSAN.
Es posible trabajar con dos tipos de Clusters de vSAN diferentes en cuanto a los tipos de disco y
sus funcionalidades. Por un lado disponemos de vSAN Cluster Híbrido, y por el otro vSAN All-Flash.
Veamos una tabla comparativa.
Característica vSAN Híbrido vSAN All Flash

Discos Capacidad Mecánicos (SAS-SATA) SSD – NVMe
Discos Caché SSD – NVMe SSD – NVMe
70% Lectura
Uso Caché 100% Escritura*
30% Escritura
Deduplicación y Compresión No soportado Soportado (vSAN Enterprise)
Operaciones lectura Primero Caché Principalmente capacidad
Recursos Red vSAN 1Gbps – 10Gbps** 10Gbps o superior
RAID 5/6 No soportado Soportado
*También da servicio de lectura antes que se produzca el movimiento de los datos desde los discos de
caché a los de capacidad, operación conocida como destage.
**Recomendado
Veamos a continuación las diferentes formas de desplegar vSAN en un Cluster.
Cluster de vSAN Clásico

Éste es el vSAN Clásico que requiere un mínimo de 3 Nodos. Si bien técnicamente es posible configurar
un Cluster de vSAN con hasta 30 Nodos (incluso más), no es muy común ver estas cantidades de
Hosts en producción.
Con independencia del tipo de Cluster de vSAN y el número de Nodos, siempre tendremos un único
vSAN Datastore por Cluster y los únicos Hosts que tendrán acceso a ese Datastore serán los miembros
del propio Cluster de vSAN.
Cluster de vSAN de 3 Nodos

También llamado vSAN ROBO para oficinas remotas, es un Cluster de vSAN compuesto por dos Nodos
que replican los componentes entre sí. El Witness Host es normalmente una máquina virtual (también
puede ser un Host físico) que se despliega en otro sitio y almacena únicamente los componentes de
Witness.
Los Clusters de vSAN de 2 Nodos pueden ser configurados en el mismo Site o en diferentes sites y
funcionar de forma similar a los Stretched Clusters.
vSAN Stretched Cluster

El concepto de Sites para vSAN Stretched Cluster es algo especial ya que se trata de dos centros de
datos remotos (o dos edificios) que puedan ser conectados con 10Gbps y una latencia máxima (round
trip) de 5 milisegundos. Merece la pena comenzar aclarando este concepto de Site debido a que estos
requerimientos pueden estar fuera del alcance de múltiples organizaciones con más de un Site.
Es factible describir un Site de Stretched Cluster como un Campus o simplemente dos ubicaciones
físicas diferentes que cumplan con los requerimientos expuestos anteriormente.
El objetivo de un vSAN Stretched Cluster es crear una protección de objetos entre Sites replicando el
método de protección local.
Esquema vSAN Stretched Cluster
Hardware soportado en vSAN

Si hay una parte importante a cumplir en vSAN, ésa es la compatibilidad y el uso del Hardware validado
para vSAN. Además del Host y las interfaces de Red que se validan como siempre en la HCL de
vSphere, las controladoras RAID y los Discos son de obligada verificación en la lista de compatibilidad
de Hardware para vSAN.
Aunque no solamente el Hardware sino que también el Firmware y los drivers deben estar validados
para esos componentes y su correspondiente versión de vSAN.
Existen 3 formas diferentes de seleccionar el Hardware a utilizar según vemos a continuación.
vSAN Hosts compatibles

También conocidos en inglés como Built your own (o móntelo usted mismo) son Hosts de diferentes
marcas que no son vSAN Ready Nodes aunque la totalidad de sus componentes están soportados
para vSAN.
vSAN Ready Nodes

Tal vez la forma más simple de implementar vSAN es utilizando los Ready Nodes para vSAN. Estamos
hablando de un Hardware pre-validado en diferentes modelos, configuraciones variadas según
necesidades y provistos por múltiples fabricantes como Dell, Fujitsu, Lenovo, Intel, etc.
Están disponibles los modelos HY para Clusters Híbridos y los AF para los Clusters All-Flash.
Tanto los discos como las controladoras están pre-validados para vSAN y ofrecen diferentes
combinaciones de CPU, RAM y Capacidad. Algunos fabricantes ofrecen más flexibilidad que otros.
Intel vSAN Ready Node de Adistec
Dell EMC vXRail

Por último tenemos la opción de elegir este sistema listo para usar (pre-instalado) y con un soporte
único tanto para Software como para Hardware aunque también es cierto que es la opción de mayor
costo y tal vez menor flexibilidad en cuanto a modificaciones de la configuración y, especialmente,
escalabilidad de recursos.
Solución HCI de Dell EMC
La Red de vSAN
Evidentemente un elemento crítico es la Red de vSAN a través de la cual no solo se utiliza para servir
los bloques de datos, sino que también es la plataforma sobre la que viajan los componentes en sus
replicaciones, resincronizaciones, balanceos y operaciones internas entre los componentes de vSAN.
Como mencionamos anteriormente, en el caso de un Cluster de vSAN Híbrido es posible utilizar

interfaces de 1GbE, aunque la recomendación es el uso de interfaces de 10GbE. Cuando se trata de
un Cluster All-Flash de vSAN el requerimiento mínimo es una red de 10GbE aunque poco a poco ya
se ven redes de 25Gbps o incluso superiores. Se dice que los interfaces de 25Gbps son los nuevos
10Gbps.
Naturalmente que para evitar un punto único de fallo aprovisionaremos dos interfaces que trabajaran
con el Port Group de VMkernel de vSAN. La configuración es muy simple, como vemos en el siguiente
esquema, un VMKernel con dos Uplinks de los cuales uno estará Activo y el otro en StandBy.
Esquema simple de la Red de vSAN
No sería correcto afirmar que existe una única forma de configurar la red de vSAN aunque el esquema
anterior muestra la opción más común.
Todo siempre depende de la cantidad y calidad de recursos de que dispongamos y de la configuración

de red del resto de los servicios.
Veamos una lista de opciones y sus recomendaciones.
Jumbo Frames: Si es posible, habilitar.
EtherChannel o LACP: Normalmente se habilita cuando el resto de los servicios ya está trabajando el
agrupado de puertos y el área de networking tiene experiencia previa.
Virtual Switch Standard o Distribuido? Distribuido siempre que sea posible. vSAN incluye licencia
de vDS sin importar si nuestro vSphere es Standard.
NIOC (Network IO Control): Habilitarlo y configurarlo. Es la mejor forma establecer la prioridad del
tráfico de vSAN. Esto lo consideraremos “obligatorio” cuando estamos compartiendo interfaces de
10GbE o superiores para múltiples tipos de tráfico.
QoS (Quality of Service): En un mundo perfecto también habilitaríamos QoS salvo que utilicemos
switches físicos exclusivos para el tráfico de vSAN, lo cual no suele ser muy común.
Política de balanceo: Al configurar un Uplink en Activo y otro en StandBy no hace falta definir ninguna
política de balanceo.
Existe un gran documento oficial de VMware que podemos utilizar como guía para la configuración de
los servicios de red en vSAN:
Documento de Diseño de red en vSAN (174 páginas)
Objetos de Máquinas virtuales

Una Máquina Virtual está compuesta por diferentes ficheros de configuración, logs, swap, discos
virtuales y discos delta entre otros.
vSAN gestiona las políticas de capacidad, alta disponibilidad y rendimiento en base a objetos de
máquina virtual. Veamos a continuación cuáles son esos objetos.
VM home namespace: Este objeto es la carpeta de la VM con los ficheros de bios, vmx, nvram, hlog
y vmsd.
Disco Virtual: Por cada disco virtual que tenga la máquina vSAN gestionará un objeto de tipo disco
vmdk.
VM SWAP: El fichero de swap tendrá un tamaño igual a la cantidad de RAM asignada a la VM menos
la reserva.
Disco Delta: Una máquina con Snapshots tiene un disco delta por cada disco virtual y cada Snapshot
disponible.
VM memory: Cada vez que creamos un snapshot y preservamos el estado de la memoria tendremos
almacenado un fichero .vmem que, en vSAN, es otro objeto.
Máquina Virtual y Objetos que la componen
Grupos de Discos
Según explicamos anteriormente cada máquina virtual está compuesta por Objetos. Una vez asignada
la política correspondiente a cada Objeto, vSAN se encarga de crear los Componentes. Si bien los
Componentes se almacenan en el Datastore de vSAN, en realidad ese Datastore está compuesto por
Grupos de Discos o Disk Groups.
Un Host puede tener un Grupo de Discos, hasta un máximo de 5 Grupos de Discos o incluso ninguno.
La buena práctica es aprovisionar cada Host del Cluster de vSAN con 2 Grupos de Disco.
Cluster de vSAN con 2 Disk Groups en cada Host
Los Grupos de Disco deben disponer de un único disco para Caché, el cual será siempre SSD con
independencia del tipo de Cluster de vSAN, y al menos un disco de Capacidad.
El número mínimo de discos de Capacidad por Grupo de Discos es uno, mientras que el número
máximo de discos de Capacidad son 7.
Los discos de Capacidad en un Cluster de vSAN Híbrido son del tipo mecánicos (SAS o SATA) y los
discos de Capacidad en un Cluster de vSAN All-Flash son siempre SSD.
En una infraestructura hiperconvergente (HCI) normalmente cada Host dispone de 6 slots para discos.
A continuación, vemos 3 ejemplos diferentes de cómo se podrían configurar los Disk Groups en un
Host HCI.
3 Ejemplos de configuración de Disk Groups en HCI
Importante: Únicamente los discos de capacidad son los que aportan el Almacenamiento utilizable
(capacidad) en el Datastore de vSAN.
Datastore de vSAN alimentado por los discos de Capacidad
3. Servicios de Arquitectura de vSAN
vSAN es una solución que se configura y trabaja a nivel de Cluster aunque los servicios almacenamiento,
al igual que vSphere HA, puede continuar operativos aún con el servicio de vCenter caído.
La información que vamos a cubrir a continuación no es crítica desde el punto de vista operativa en sí
misma, pero sí muy importante si pretendemos comprender cómo funciona vSAN a nivel de arquitectura
e incluso nos ayudará a interpretar mejor los Logs en un proceso de resolución de problemas al
reconocer los nombres de los servicios de las diferentes capas funcionales de vSAN.
En el momento en que habilitamos vSAN en un Cluster, los Hosts que son miembros del mismo
comienzan a instalar y configurar los servicios de arquitectura. Los servicios son CMMDS, CLOM,
DOM y LSOM.
CMMDS: El servicio de Cluster Monitoring Member and Directory Service es el encargado de almacenar
y gestionar la base de datos de los servicios de Directorio en vSAN. Todos los objetos, componentes y
recursos están indexados en la base de datos que se almacena en memoria en cada uno de los Hosts
que son miembros del Cluster. Cada Host del Cluster tendrá su rol para dar servicio a CMMDS, los
cuales pueden ser Master, Backup o Agent. Existirá un único Master, un único Backup y el resto de los
nodos del Cluster funcionarán como Agent.
CLOM: El acrónimo CLOM proviene de Cluster Level Object Manager y es un servicio clave en vSAN
al definir la viabilidad en la creación de objetos, la mejor ubicación posible siguiendo las políticas
asignadas y la distribución más equitativa posible de los objetos entre Fault Domains, Hosts y Disk
Groups.
CLOM gestiona además la recreación y actualización de objetos luego de un fallo. El servicio CLOM no
utiliza la red y se comunica únicamente con las instancias locales de CMMDS y DOM.
DOM: Distributed Object Manager es el nombre del servicio que funciona como nexo entre CLOM y
LSOM. Cada instancia de CLOM se comunica con su instancia local de DOM para enviar la orden de
creación, actualización y/o modificación de los componentes. Cada instancia de DOM gestionará las
peticiones con su servicio local LSOM a quien le enviará esas peticiones recibidas por CLOM. Para
las tareas a ejecutarse en Hosts diferentes, DOM tendrá que comunicarse con la instancia de DOM de
los otros Hosts del Cluster para hacer llegar esas peticiones, las cuales se reenviarán a sus servicios
LSOM locales.
DOM también gestiona lo que se conoce como DOM Client y DOM Owner. El Client será quien se
encargue del envío de operaciones de entrada/salida en nombre de cada VM. Por cada objeto de
vSAN hay un Owner y es quien gestiona lo más parecido a un bloqueo en los accesos a esos objetos
y entrega las rutas a la ubicación de los componentes.
LSOM: El Log Structured Object Manager es el único servicio que trabaja con los discos de los Hosts.
Gestiona tanto los discos de Caché como también los de capacidad y se hace cargo de las tareas
de Destage para mover los datos desde los discos de Caché hacia los de Capacidad. Cuando están
habilitados los servicios de Deduplicación y Compresión se encarga de deduplicar (al momento del
destage) y de comprimir, siempre y cuando sea posible comprimir un bloque de 4K en 2K o menos.
Si el Cluster de vSAN tiene habilitado el servicio de encriptación entonces será LSOM quien se
encargue de encriptar los datos.
Y como si fuera poco también identificará y reportará cualquier tipo de fallo en los discos físicos de los
Disk Groups así como también monitorizará el espacio consumido en cada uno de los discos.
Servicios de arquitectura de vSAN
4. Configuración de un Cluster de vSAN
La configuración de un Cluster de vSAN es una tarea realmente simple. Una vez validado el Hardware
y definido el Diseño, es solo cosa de unos cuantos clicks.
Ante todo debemos recordar y destacar que vSAN es una solución embebida en el Hypervisor, de ahí
que el título de este apartado comience con Configuración en lugar de Instalación.
Repasemos los requerimientos de vSAN:

• Hardware validado (incluyendo Firmwares y Drivers)
• vCenter Server
• vSphere HA
• Port Group de VMKernel en cada Host
• Un Disk Group por Host (al menos los 3 primeros Hosts)
• Licencia de vSAN
Si bien no es un requerimiento, es altamente recomendable que se considere una consistencia en los

Hosts en cuanto a recursos de cómputo y discos locales.
¿Creamos un Cluster de vSAN? Ahí vamos!!!
Paso 1: Creación del Cluster

Para crear y configurar el Cluster de vSAN los servicios de HA deben estar deshabilitados, aunque una
vez finalizado el asistente inicial debemos habilitarlos ya que es un requerimiento.
Al marcar la opción de vSAN y hacer click en Ok, al cabo de unos pocos segundos tendremos los
servicios básicos de vSAN habilitados en el Cluster.
Creando el Cluster de vSAN
A partir de vSphere 6.7 (vSAN 6.7) disponemos del asistente quickstart. El asistente es opcional y nos
permitirá configurar la totalidad de los servicios de vSAN en el Cluster.
A continuación, veremos una configuración sin utilizar el quickstart.
Cluster quickstart en vSphere Client
Paso 2: Configuración de servicios adicionales y parámetros

Si tenemos pensado habilitar los servicios de Deduplicación y Compresión o bien si nuestro diseño
requiere la encriptación del Datastore de vSAN, se recomienda habilitar todas estas opciones antes de
agregar los Hosts o bien antes de crear o migrar máquinas al Datastore de vSAN.
Esta recomendación es debido a que los Disk Groups requerirán un formato especial para cada caso
y es preferible aplicar ese formato cuando no existen todavía componentes.
En nuestro caso habilitaremos Deduplicación y Compresión. Además, dejaremos habilitada la opción

Thin Swap para ahorrar espacio al aplicar el formato Thin Provisioning a los ficheros de Swap. También
habilitamos el Performance Service que nos proveerá de métricas muy útiles que utilizaremos para
monitorizar nuestro Cluster.
(Hablaremos de la opción Site Read Locality en el apartado de Stretched Cluster)
Opciones generales del Cluster de vSAN
Paso 3: Agregar los Hosts y validar configuración

Al agregar los Hosts al Cluster veremos que se crea el vSAN Datastore aunque, al no haber definido
todavía los Disk Groups, su capacidad será de 0 bytes.
Una vez que los Hosts estén agregados al Cluster sería muy bueno esperar un par de minutos y
consultar por primera vez el vSAN Health con el objetivo de verificar que la conectividad de Red está
funcionando correctamente.
vSAN Health con configuraciones de Red validadas
En el vSAN Health deberíamos verificar también que las controladoras de discos, firmwares y drivers
están validados. Es posible que tengamos que hacer una actualización o incluso un downgrade de
algún driver. Es el momento de dejar todo a punto (pintar todo de verde!) según lo que requiere el
vSAN Health antes de continuar.
Esto es especialmente importante si no queremos tener problemas a la hora de llamar al soporte de

VMware, ya que comenzarán revisando qué tan verde está nuestro vSAN Health.
Una vez que todo está validado es momento de proceder con la creación de los Disk Groups y hacer
que el vSAN Datastore comience a sumar capacidad disponible.
Paso 4: Creando los Disk Groups

Este proceso es muy simple, solo tenemos que ir Host por Host y seleccionar los discos que serán
parte de cada Disk Group según el Diseño.
Si seleccionamos el Cluster, Configuración y en vSAN hacemos click en Disk Management podremos

configurar los Disk Groups de cada Host.
Configuración de Disk Groups en el Cluster
Creando un Disk Group en un Host
Ejecutamos el mismo proceso en cada uno de los Hosts del Cluster. El tiempo que requerirá la creación
de cada Disk Group dependerá de la cantidad de discos y su capacidad, pero hablamos de solo unos
pocos minutos.
Una vez finalizada la creación del último Disk Group ya podemos confirmar que nuestro Datastore de
vSAN dispone de capacidad utilizable.
En este punto ya estamos listos para migrar máquinas o bien crear nuevas sobre nuestro flamante
Datastore de vSAN. ¿Fácil verdad?
5. Políticas de vSAN
Mencionamos varias veces que vSAN se gestiona a través de las Políticas. En realidad, lo que
gestionamos a través de las políticas de vSAN son los objetos de máquina virtual y, una vez asignada
una política, esos objetos están representados en los Disk Groups de los Hosts como Componentes.
A veces son llamados Réplica Components (normalmente en mirroring), otras Data Components (en
Erasure coding) o incluso simplemente Componentes.
Los niveles de tolerancia a fallos en Almacenamiento, consumo de espacio, nivel de RAID y rendimiento
van a depender de la combinación de reglas que definamos en la política asignada al Objeto. O
diciéndolo de otra forma, las reglas de una política van a impactar en el consumo, rendimiento y
tolerancia a fallos.
Por ejemplo, si seleccionamos RAID 1 consumiremos más espacio que con RAID 5, pero a nivel de
rendimiento será mejor RAID 1 debido a que no es necesario el cálculo de paridad.
También existen reglas dentro de las Políticas que permiten crear reserva de espacio en disco, lo cual
supone un mayor consumo de espacio.
Máquinas, Objetos, Políticas y Componentes
vSAN dispone de varias reglas de Políticas en su versión 6.7. Particularmente en la versión 6.7 tenemos
que tener en cuenta que las reglas se verán diferentes (bastante diferentes) al utilizar vSphere Web
Client o vSphere Client.
Política vSAN con RAID 1 en vSphere Web Client
Política vSAN con RAID 1 en vSphere Client
La recomendación es utilizar vSphere Client ya que será el único cliente en las próximas versiones,
por lo cual en este capítulo utilizaremos ese cliente para revisar las reglas. Veamos cómo funciona y
en qué caso aplica cada regla.
Site disaster tolerance: Si configuramos vSAN Stretched Cluster utilizaremos esta regla en la política
de vSAN para asignar a los objetos de las máquinas virtuales que queremos brindar protección entre
sites. La opción es “Dual site mirroring (stretched cluster)”.
Las otras opciones nos permiten definir protección a nivel de Fault Domains y también seleccionar un
Site de preferencia para los componentes de máquinas en caso que no exista una protección entre
sites. A esto se le aplica el “Site Read Locality” y debe estar configurado a nivel de Cluster de vSAN,
en opciones avanzadas.
Configuración de tolerancia a fallos entre Sites
Fallos a Tolerar (antes PFTT): Como su nombre lo indica es el número de fallos que vamos a tolerar.
Cualquier tipo de error que impacte en el acceso al componente contará como un fallo, incluyendo la
puesta en mantenimiento de un Host.
Las opciones disponibles nos permiten configurar la regla para no disponer de redundancia (RAID 0),
protección contra un fallo (RAID 1 y RAID 5), tolerancia de dos fallos (RAID 1 o RAID 6) y soporte para
protección ante tres fallos (RAID 1).
Las opciones de Mirroring con protección contra dos fallos tendrán 3 réplicas y las que toleren hasta
tres fallos contarán con 4 réplicas.
Definiendo la tolerancia a fallos
Número de componentes por disco: opción por defecto 1 y un máximo de 12, aplica únicamente
en vSAN Híbrido con el objetivo de distribuir los componentes entre múltiples discos y de esa forma
obtener un mayor número de IOPS.
Número de discos en los que se distribuirá el componente
Límite de IOPS por objeto: El valor por defecto es 0 (sin límite). Este valor podría aplicar para crear
una especie de “Tiers virtuales” definiendo 2 o más niveles de rendimiento a través de estos límites.
vSAN considera un IOP(s) a una petición de hasta 32K. Si hubiera una petición de 64K entonces sería
considerado como 2 IOPS.
¿Y si hubiese 4 peticiones de 4K? vSAN las gestionará como 4 IOPS diferentes.
Configuración del límite de IOPS
Reserva de espacio por objeto: por defecto se utiliza thin provisioning, lo que supone que no hay
ningún tipo de reserva. Existe la posibilidad de reservar el espacio en el vSAN Datastore para una parte
o incluso la totalidad del componente (25% - 50% - 75% - Thick provisioning). Esta regla cambiará el
formato thin provisioning del objeto a un thick provisioning lazy zeroed (sin inicializar los bloques) lo
cual incrementará el consumo del Datastore de vSAN producto de la capacidad reservada.
Formato y reserva de espacio para objeto
TIP: Evitar a toda costa crear una reserva de espacio en la política de vSAN por defecto. No vamos a
querer ver el resultado, sobre todo si ya estamos en producción ;-)
Reserva de Flash Read Cache: esta reserva aplica únicamente a vSAN Híbrido y se utiliza para
asignar/reservar una determinada capacidad del objeto para ser almacenada en los discos de caché
del Disk Group con el fin de mejorar el ratio de acierto en caché.
Deshabilitar el Object Checksum: por defecto se le aplica el proceso de validación de escritura a

cada dato que se escribe. Existen algunas aplicaciones, normalmente bases de datos, que realizan
su propio checksum. Es en esos casos cuando definimos la política con esta regla para “deshabilitar”
el Object Checksum con el fin de mejorar el rendimiento evitando una doble comprobación, aunque la
diferencia puede llegar a ser apenas perceptible.
Vale aclarar que no se recomienda deshabilitar el Object Checksum.
Reglas avanzadas en política de vSAN
Forzar el aprovisionamiento: cuando creamos una nueva máquina virtual y/o algún objeto en vSAN,
el servicio CLOM validará que ese objeto estará en modo “compliance” según la política asignada.
Si por algún motivo no disponemos de la mínima cantidad de recursos (por ejemplo, un Host en
mantenimiento) el proceso de creación del objeto no continuará debido a la regla por defecto.
Si queremos forzar la creación de esos objetos por más que el estado sea “non compliance” entonces
configuraremos la regla para que la opción Force Provisioning sea “Yes”.
Regla de vSAN para forzar el aprovisionamiento
Comparando métodos de protección

La siguiente tabla es una excelente comparativa de las diferentes opciones a utilizar para tolerar fallos
con sus correspondientes métodos.
Componentes Objetos Erasure Coding Mínimo de

Fallos a tolerar Protección
Replica/Data Witness vs Mirror Hosts
0 RAID 0 1 0 - 3
1 RAID 1 2 1* - 3
1 RAID 5 4 0 33% menos 4
2 RAID 1 3 2* - 5
2 RAID 6 6 0 50% menos 6
3 RAID 1 4 3* - 7
Tabla comparativa de opciones y métodos de protección
*El número de objetos Witness se crea automáticamente dependiendo de varios factores como número
y tamaño de objetos, número de hosts y opciones en las reglas de la política.
Gestión de Políticas de vSAN

Una vez diseñado, implementado y validado el primer Cluster de vSAN pasamos a la configuración de
las políticas. A través de las políticas de vSAN definiremos aspectos tan importantes como la protección
ante fallos, el consumo del espacio en disco, rendimiento y otros aspectos que nos permiten adaptar
los servicios de almacenamiento a las diferentes cargas de trabajo a nivel de objeto de máquina virtual.
Una vez definidas esas políticas, las cuales se crean a nivel de vCenter, es hora de mover máquinas
al Cluster de vSAN. Da igual si vamos a crear máquinas nuevas o si estamos migrando máquinas
existentes al Datastore de vSAN, siempre tendremos que asignar una política.
Asignación de política en nueva máquina virtual
Todo objeto de máquina virtual que esté almacenado en un Datastore de vSAN deberá tener asignada
su política correspondiente. Por cada Cluster de vSAN tendremos una política por defecto.
La recomendación es NO modificar la política de vSAN por defecto.
Siempre podemos crear una nueva política con las reglas que necesitemos.
Ahora la pregunta es, una vez que tenemos máquinas y políticas, ¿cuáles son las opciones de gestión?
La respuesta es bien simple. Las políticas se pueden modificar según necesitemos y también es posible
cambiar (reasignar) una política a alguno o a todos los objetos de una máquina virtual. Veamos los dos
casos.
Cambiando una política a los objetos de una máquina virtual

Por diferentes motivos tal vez necesitemos cambiar una política a uno o todos los objetos de una
máquina virtual. A continuación, veremos una captura de una VM con todos los objetos trabajando con
la política de vSAN por defecto.
Visualizando la política de una VM
Objetos de máquina virtual con la política de vSAN por defecto
Para cambiar la política a los objetos de una VM simplemente tenemos que seleccionar la VM en el
inventario de vCenter con el botón contextual, VM Policies y Edit VM Storage Policies.
Editando las políticas de una VM en vSAN
En la ventana de edición de políticas de almacenamiento tendremos disponible la opción de configurar

una política por disco (Aunque el nombre correcto debería ser objeto. Te perdonamos VMware ;-).
Asignando una política por objeto de máquina
Una vez que asignamos una política diferente veremos el impacto en los cambios. En este caso hemos
cambiado RAID 1 por RAID 5 con su correspondiente ahorro en el consumo de almacenamiento.
Impacto en la reasignación de política
Al cambiar la política debemos tener en cuenta el potencial impacto que generará el cambio. Un
impacto podría ser el mayor consumo de espacio, ya sea temporal o permanente. Y otro impacto serán
las operaciones de I/O al necesitar (no siempre) recrear un componente.
Máquina con nuevos componentes en RAID 5
Cambiando reglas en Política de vSAN

Otra opción de cambios en políticas asignadas a una o varias VMs es la de editar/cambiar una política
de vSAN que ya esté asignada a uno o múltiples objetos de máquinas virtuales.
En este punto tenemos que ser muy conscientes del impacto que podemos generar.
Existen múltiples cambios en políticas que requieren la recreación de componentes.
Cambios en políticas que requieren recreación de componentes:

• Cambio de RAID 1 a RAID 5
• Cambio número de objetos por componente (disk stripes per object)
• Reserva de espacio en objeto
• Cambio o asignación de reserva en Flash Read Cache
Como hemos podido observar existe un número importante de cambios que requieren la recreación de
componentes. Esos cambios van a generar operaciones adicionales de I/O, consumo de caché, tráfico
de red y consumo de espacio adicional de disco mientras se ejecutan los cambios.
Por lo tanto, debemos ser conscientes del impacto a generar, sobre todo cuando estamos cambiando
reglas en una política asignada a objetos de múltiples máquinas virtuales.
Para cambiar una regla en una política de vSAN simplemente tenemos que seleccionar la política en
Policies and Profiles/VM Storage Policies y hacer clic en Editar o Edit Settings. Una vez aplicados los
cambios en la política y finalizado el asistente veremos una ventana como la siguiente:
Solicitud de confirmación de aplicación de cambios en política
Como hemos visto disponemos de dos opciones. Una es aplicar los cambios inmediatamente,
generando el impacto que hemos comentado en todos los objetos afectados al mismo tiempo.
La otra opción sería seleccionar que queremos aplicar los cambios de forma manual más adelante.
Esto podemos hacerlo máquina por máquina o, en caso que tengamos un número considerable de
máquinas en el inventario, considerar el uso de PowerCLI para seleccionar las VMs y aplicar los
cambios de forma gradual.
Al seleccionar la opción de aplicar los cambios más adelante, podremos visualizar la lista de VMs con
objetos pendientes de aplicar los cambios. El estado de compliance de la máquina será “Out of Date”.
Política pendiente de asignar en VM
Y en caso de desear aplicar los cambios en la política de forma manual solo tendremos que seleccionar
la máquina, Configure y hacer clic en Reaplicar política (Reapply VM Storage Policy).
Compliance Out of Date
Por último, recordar que las políticas pueden ser cambiadas y editadas por más que las máquinas
estén encendidas. El impacto será mayor o menor dependiendo tanto de los recursos disponibles
como también de la cantidad y tamaño de componentes a recrear.
Se recomienda antes de aplicar un cambio de política verificar si el Cluster está recreando o poniendo
al día componentes. Aprenderemos cómo hacer esto más adelante.
6. Stretched Cluster, 2 Node Cluster y Fault Domains
Con la versión 6.0 de vSAN llegaba All-Flash para entrar de lleno a dar servicios para aplicaciones
críticas con una cantidad industrial de IOPS. La misma versión 6.0 nos traía otra novedad con el
nombre de Fault Domains (o dominios de fallo) en el que podemos crear grupos de Hosts, distribuidos
en diferentes racks, con el objetivo de incrementar la disponibilidad en caso de fallo general a nivel de
rack.
Por otra parte la versión 6.1 presentó vSAN Stretched Cluster para incrementar la disponibilidad entre
dos ubicaciones diferentes en donde estarán grupos de Hosts replicando objetos entre sí.
A partir de la misma versión de vSAN (6.1) nos permite además cubrir las necesidades de otro caso
de uso como lo son oficinas remotas en donde 2 Hosts comparten almacenamiento y ofrecen alta
disponibilidad.
vSAN Fault Domains

El objetivo de Fault Domains es distribuir las réplicas de componentes a través de Disk Groups de
Hosts que estén en diferentes zonas, o dominios de fallo.
Como mencionábamos anteriormente el principal caso de uso es la protección ante fallos generales
a nivel de rack. No obstante también es posible aplicar esta misma protección dentro de un mismo
rack para minimizar el impacto en una situación potencial de más de un Host que compartan el mismo
chasis.
La configuración de Fault Domains es francamente simple. Únicamente necesitamos definir los objetos
lógicos de cada Fault Domain y asociar el o los Hosts a cada FD.
Creación de Fault Domain en Cluster
La cantidad mínima de Fault Domains va a estar asociada al tipo de protección a aplicar en las políticas
del Cluster. Por ejemplo, si aplicaremos una política con una regla que define una protección que utiliza
RAID 5, entonces necesitaremos 4 Fault Domains. Para RAID 6, 6 Dominios de fallo serán necesarios.
Una vez creados los Fault Domains los componentes se distribuirán automáticamente a través de los
Disk Groups de cada Host en cada FD según la política aplicada.
Vista de Cluster con Fault Domain configurado
4 Dominios de fallo con Componentes distribuidos
Por último, debemos comentar que únicamente es posible configurar Fault Domains siempre y cuando
no hayamos habilitado Stretched Cluster o 2 Node Cluster debido a que estas dos soluciones utilizan
ya de por sí el concepto de Fault Domains.
Stretched Clusters
Cuando se trata de incrementar la disponibilidad de las aplicaciones, ya sea a nivel de Computo, Red
o Almacenamiento, los objetivos se alinean con la simplicidad y los requerimientos con la fiabilidad.
vSAN Stretched Cluster aporta simplicidad, fiabilidad y resiliencia.
Un Stretched Cluster de vSAN puede escalar hasta 15 Hosts por sitio y, a través de las políticas de
vSAN, es posible seleccionar las máquinas con sus objetos a los que queremos aportar protección.
Comencemos con la lista de requerimientos.
Requerimientos de vSAN Stretched Cluster:
• Mínimo de 1 Host por Site
• Máximo de 15 Hosts por Site*
• Witness Host en un tercer Site (normalmente es un virtual appliance)
• Conectividad de 10 Gbps entre el Site Primario y el Secundario en capa 2
• Latencia máxima de 5ms Roundtrip entre el Site Primario y el Secundario
• Conectividad de 2 Mbps por cada 1000 objetos entre los Sites de Datos y el Witness Host
• Latencia máxima de 100ms (o superior en algunos casos) entre los Sites de Datos y el Witness
Host
• Licencia vSAN Enterprise
*Es posible trabajar con un número superior de Hosts por Site en VMC on AWS.
En base a los requerimientos podemos ver que el concepto de “Site” puede ser algo relativo. Conectar
2 Sites que estén separados por varios kilómetros y cumplir con el requerimiento de no más de 5
milisegundos de latencia puede ser algo complicado. O al menos la factura de la fibra será cuanto
menos elevada.
Esto hace que tal vez reconsideremos el concepto de Site y lo traslademos a algo como Campus,
Edificio o diferentes ubicaciones físicas que permitan cumplir con los requerimientos.
Respecto a los requerimientos del tercer Site para el Witness, también llamado Witness Site, claramente
son más relajados. Incluso cada día más y más empresas utilizan recursos de Cloud Publica para
hostear sus Witness Hosts.
El Witness Host puede ser un Host físico o bien un virtual Appliance que podemos descargar en
formato OVA.
Veamos todos los pasos para configurar un Cluster de vSAN en Stretched Cluster.
1. Despliegue de Appliance
Una vez descargado el OVA del Witness Appliance procedemos con el despliegue. La versión del OVA
debe ser la misma que la de los Hosts del Cluster.
Desplegando Witness Appliance
Las opciones son las normales de cualquier Appliance.
Desplegando Witness Appliance
Debemos seleccionar el tamaño de la VM del Witness Host. Eso dependerá de la cantidad de máquinas
a proteger como podemos apreciar en la siguiente captura.
Definiendo el tamaño del Witness Host
Y otra parte importante es la asignación de redes. Como podemos ver en la siguiente captura, existen
dos redes. Una es para los servicios de Management, al igual que un ESXi tenemos que conectar a la
misma red de vCenter y Hosts, aunque en este caso podría ser una conexión tanto de capa 2 como
de capa 3, es decir, enrutada.
Asignando redes a los servicios del Appliance
Una vez que finalizamos con el asistente del Appliance tendremos una máquina virtual como cualquier
otra. La diferencia es que esta VM es un ESXi virtualizado o, como suele decirse, en modo nested.
vSAN Witness desplegado
Importante: La máquina virtual del vSAN Appliance deberá operar sobre un Host que no forme parte
de un Cluster de vSAN.
2. Configuración del Appliance
La siguiente tarea será encender el Witness Host y configurar los servicios de red. Al igual que con
cualquier otro ESXi necesitaremos definir un registro DNS de tipo A y otro PTR asociado a la IP que le
asignaremos.
Como hemos mencionado, esa IP será la dirección de Management del Witness Host y el vCenter
tendrá que ser capaz de resolver el hostname como también llegar a la dirección IP asignada.
Witness Host con Management configurado
3. Agregando el Witness Host al inventario
El ESXi virtual que da servicio al Witness Host tiene que estar agregado al inventario del mismo
vCenter que da servicio al Cluster de vSAN.
Podremos ver que el Host virtual se diferencia del resto al utilizar un color azul claro o celeste.
Witness Host en el Inventario de vCenter
4. Configuración del servicio Stretched Cluster
Llegados a este punto ya hemos cumplido con los requerimientos previos a la configuración. Siempre
y cuando no tengamos configurado ningún Fault Domain, podremos hacer click en el botón Configure
para comenzar con el asistente de configuración.
El asistente es muy simple como veremos a continuación.
Cluster de vSAN listo para configurar el servicio Stretched Cluster
Lo primero será definir los Hosts que funcionarán en el Site preferido y los que operarán en el Site
secundario.
Asignando Hosts a cada Site
Lo siguiente es seleccionar el Witness Appliance que tenemos disponible en el inventario de nuestro

vCenter.
Vale aclarar que un Witness Appliance únicamente podrá dar servicio a un Stretched Cluster en
particular.
Asignando el Witness Host al Cluster
Como parte de la configuración del Stretched Cluster es necesario crear un Disk Group en el Witness
Host.
El Witness Host almacenará los componentes Witness de los objetos pertenecientes a las máquinas
protegidas con Stretched Cluster.
Creando el Disk Group en el Witness Host
Y una vez que visualizamos el resumen de la configuración, al hacer click en finalizar comenzará el
proceso de creación o conversión de nuestro vSAN a Stretched Cluster.
Si estamos ejecutando el Quickstart entonces creará el Cluster como Stretched. Y si nuestro Cluster ya
está operando con los servicios de vSAN, se convertirá el servicio para que opere en modo Stretched
Cluster.
Habilitando los servicios de Stretched Cluster
Una vez finalizado el proceso ya podremos ver cómo queda el servicio Stretched Cluster en la consola
de vSphere Client.
Vista de la consola de vSAN Stretched Cluster
A partir de ahora simplemente tendremos que asignar la política correspondiente a los objetos de las
máquinas que queremos proteger a nivel de Site.
Políticas de vSAN para definir protección a nivel de Site
En las políticas podemos ver varias opciones, las cuales explicaremos a continuación.
None – standard cluster: No protegemos los objetos con Stretched Cluster.
None – standard cluster with nested fault domains: Utilizaremos Fault Domain para protección,
aunque tampoco a nivel de Site.
Dual site mirroring (stretched Cluster): Se protegerán los objetos de la máquina a través de Sites
pero no definimos ningún Site en particular. Dependerá de la carga de cada Site o bien de las reglas
de DRS si es que las configuramos.
None – keep data on Preferred (stretched cluster): No se protegen los objetos de la máquina con
Stretched Cluster pero preferimos que los componentes se almacenen en los Disk Groups de los Hosts
pertenecientes al Site Preferred.
None – keep data on Non-preferred (stretched cluster): No se protegen los objetos de la máquina
con Stretched Cluster pero preferimos que los componentes se almacenen en los Disk Groups de los
Hosts pertenecientes al Site Non-preferred.
None – stretched cluster: No se protegen los objetos de la máquina con Stretched Cluster y el propio
Cluster, en base al espacio disponible, seleccionará el Site con menor consumo para balancear la
carga y que los componentes residan en los Disk Groups del Site seleccionado.
Site Read Locality: esta opción está disponible a partir de vSAN 6.7 y la podemos habilitar o deshabilitar
seleccionando el Cluster, en Configuración, Servicios y Opciones Avanzadas.
El objetivo es consumir un menor ancho de banda entre los Sites al ejecutar las operaciones de lectura
únicamente en los Disk Groups del Site en donde se está ejecutando la VM (recursos de computo).
Reglas DRS afinidad VM-Host: otra configuración muy común es la creación de grupos de Máquina
y Hosts para definir una afinidad. Al aplicar estas reglas de DRS, las máquinas funcionarán,
preferiblemente, los recursos de cómputo del grupo de Hosts del Site preferido o no-preferido, según
hayamos configurado la regla.
Esta es otra forma de acercar las máquinas a consumidores de recursos localizados en un Site concreto
y también en cierta forma a balancear la carga.
Clusters de 2 Nodos
Habiendo cubierto ya los servicios de Stretched Cluster únicamente nos quedaría explicar la diferencia
entre 2 Node Cluster y Stretched Cluster.
Los Clusters de 2 Nodos no tienen por qué operar en Sites diferentes. Está soportado un Stretched
Cluster de 2 Nodos y también un mini-cluster de 2 Nodos de vSAN que funcionen en el mismo Site.
Cluster ROBO de 2 Nodos
La configuración es prácticamente igual debido a que seguimos necesitando un Witness Host y la

configuración es en la misma ubicación del vSphere Client.
En cuanto a reglas, si estamos trabajando con un Cluster de 2 Nodos sin Stretched, la única política
de protección que podemos aplicar es RAID 1 y, al igual que en SC, los Witness components se
almacenarán en el Witness Host.
Cluster de 2 Nodos en modo Stretched
Una opción muy interesante que está únicamente disponible en los Clusters de 2 Nodos que operan en
el mismo sitio es que podemos utilizar un cable cruzado para conectar las vmnics que dan servicio a
los puertos VMKernel de vSAN. Esto nos evita tener que invertir en un Switch de 10Gbps por ejemplo.
Cuántos litros de cerveza podríamos comprar con lo que ahorramos en dos Switches de 10Gbps?
Y la última diferencia considerable es la licencia. Existe un paquete de licencias para Clusters de 2

Nodos que se llama ROBO, aunque no aplica a Stretched Cluster.
No obstante, también es posible licenciar un Cluster de 2 Nodos, con o sin Stretched, utilizando el
licenciamiento normal de vSAN que aplica a nivel de procesador físico o socket.
7. Componentes y fallos en vSAN
En este apartado revisaremos los diferentes tipos de fallos y cómo afectan a los componentes.
Dependiendo el tipo de fallo, los componentes se mostrarán en un estado u otro, así como también las
acciones a ejecutar por parte de vSAN pueden ser variadas.
Comencemos con los diferentes estados en que puede estar un componente:
Active: El componente está funcionando correctamente.
Absent: No hay acceso al componente y vSAN no sabe qué ocurrió. Puede deberse a un fallo de red,
un host caído, fallo de disco o un host en mantenimiento. El sistema esperará 60 minutos hasta que se
recupere el error y una vez pasado ese tiempo, en caso que el componente continúe en modo Absent,
vSAN recreará el componente de forma automática.
Degraded: El estado degradado indica que vSAN confirma un fallo, probablemente en uno de los discos
o incluso en la controladora. De forma inmediata comenzará el proceso de recreación de componente.
Reconfiguring: Ése será el estado del componente mientras se está aplicando una reconfiguración
debido a un cambio en una política que requiere aplicar cambios en los componentes.
A la hora de trabajar con un cluster de vSAN lo primero que debemos comprender es cómo el Cluster
entiende y gestiona los fallos.
Muy probablemente sepamos que si el Host está en modo mantenimiento no será capaz de proveer
servicios de cómputo a máquinas virtuales. De la misma forma, en un Cluster de vSAN, un Host
en modo mantenimiento no proveerá servicios de Almacenamiento. Veremos más adelante cómo
gestionar las operaciones en un Cluster de vSAN pero centremos la atención ahora mismo en ver
cómo impactan en los componentes los diferentes tipos de errores y/o operaciones.
Fallo Estado Componente Alcance fallo Recreación

Todos los componentes
Host en Mantenimiento Absent A partir de los 60 minutos
del Host
Host Absent A partir de los 60 minutos
del Host
Red (Host aislado) Absent A partir de los 60 minutos
del Host
Controladora Degraded Todos los discos del Host Inmediatamente
Disco Caché Degraded Disk Group Inmediatamente
Disco Capacidad (sin
Degraded Componentes en disco Inmediatamente
deduplicación)
Disco Capacidad (con
Degraded Disk Group Inmediatamente
deduplicación)
Tabla comparativa de fallos y estados
Recreación automática a partir de los 60 minutos
El servicio CLOM gestiona lo que se conoce como CLOM repair delay. Cada vez que un componente
está en modo Absent el servicio CLOM da un margen para que el componente se recupere o vuelva a la

Vsan

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Vsan

Загружено:

Авторское право:

Доступные форматы

H O S T E D P R I VAT E C L O U D

Lo mejor de la tecnología VMware

1. Introducción y Casos de Uso

Si bien en aquella época todavía no hablábamos de hiperconvergencia, sí que comenzábamos a hacer

Es un producto complementario a vSphere que, al igual que HA o DRS, se configura a nivel de

El sistema de almacenamiento definido por software de VMware es extremadamente simple de

Característica vSAN Híbrido vSAN All Flash

Veamos a continuación las diferentes formas de desplegar vSAN en un Cluster.

Cluster de vSAN Clásico

Cluster de vSAN de 3 Nodos

Cluster de vSAN de 2 Nodos

Cluster de vSAN de 2 Nodos

vSAN Stretched Cluster

Esquema vSAN Stretched Cluster

Hardware soportado en vSAN

Existen 3 formas diferentes de seleccionar el Hardware a utilizar según vemos a continuación.

vSAN Hosts compatibles

vSAN Ready Nodes

Intel vSAN Ready Node de Adistec

Dell EMC vXRail

Solución HCI de Dell EMC

Como mencionamos anteriormente, en el caso de un Cluster de vSAN Híbrido es posible utilizar

Esquema simple de la Red de vSAN

Todo siempre depende de la cantidad y calidad de recursos de que dispongamos y de la configuración

Veamos una lista de opciones y sus recomendaciones.

Jumbo Frames: Si es posible, habilitar.

Documento de Diseño de red en vSAN (174 páginas)

Objetos de Máquinas virtuales

Máquina Virtual y Objetos que la componen

Cluster de vSAN con 2 Disk Groups en cada Host

3 Ejemplos de configuración de Disk Groups en HCI

Datastore de vSAN alimentado por los discos de Capacidad

3. Servicios de Arquitectura de vSAN

Servicios de arquitectura de vSAN

4. Configuración de un Cluster de vSAN

Repasemos los requerimientos de vSAN:

• Port Group de VMKernel en cada Host

• Un Disk Group por Host (al menos los 3 primeros Hosts)

Si bien no es un requerimiento, es altamente recomendable que se considere una consistencia en los

¿Creamos un Cluster de vSAN? Ahí vamos!!!

Paso 1: Creación del Cluster

Creando el Cluster de vSAN

A continuación, veremos una configuración sin utilizar el quickstart.

Cluster quickstart en vSphere Client

Paso 2: Configuración de servicios adicionales y parámetros

En nuestro caso habilitaremos Deduplicación y Compresión. Además, dejaremos habilitada la opción

(Hablaremos de la opción Site Read Locality en el apartado de Stretched Cluster)

Opciones generales del Cluster de vSAN

Paso 3: Agregar los Hosts y validar configuración

todavía los Disk Groups, su capacidad será de 0 bytes.

vSAN Health con configuraciones de Red validadas

Esto es especialmente importante si no queremos tener problemas a la hora de llamar al soporte de

Paso 4: Creando los Disk Groups

Si seleccionamos el Cluster, Configuración y en vSAN hacemos click en Disk Management podremos

Configuración de Disk Groups en el Cluster

Creando un Disk Group en un Host

Máquinas, Objetos, Políticas y Componentes

Política vSAN con RAID 1 en vSphere Web Client

Política vSAN con RAID 1 en vSphere Client

Configuración de tolerancia a fallos entre Sites

Definiendo la tolerancia a fallos

Número de discos en los que se distribuirá el componente