Hace unos años, durante mi asistencia a EMC World, tuve la oportunidad de reunirme con Chuck Hollis y otros empleados de VMware para hablar sobre una idea que tenían. Querían aprovechar los recursos de almacenamiento local sin usar dentro de un host ESX. En lugar de simplemente almacenar la imagen de arranque de ESX, querían que el recurso fuera utilizable para máquinas virtuales dentro de todo el clúster ESX. Hablamos sobre lo que parecía ser un sistema de archivos en clúster que podría proteger los datos en todos los hosts ESX. Señalé que los discos duros tradicionales son lentos y hablaron sobre el uso de unidades SSD para acelerar las operaciones de E/S. Era una idea interesante y tenía curiosidad por saber si llegaría a materializarse. Como habrán adivinado, sí se materializó: Virtual SAN. Con el lanzamiento inicial de VSAN, me interesó, pero, la verdad, me decepcionó un poco. Un año después de su disponibilidad general, VSAN ha dado un gran salto adelante con la última actualización a VSAN 6.0.
Por supuesto, VSAN 6.0 es mejor, más rápido y más grande. En consonancia con vSphere 6.0, los VMDK pueden obtener hasta 62 TB y pueden tener hasta 64 hosts en el clúster. El número de máquinas virtuales en un nodo se ha duplicado de 100 a 200, con un máximo de 6,400 por clúster. Más nodos significan más capacidad y más rendimiento. El uso de unidades de 4 TB pone el límite en alrededor de 9 petabytes de capacidad bruta.
VSAN 6.0 presenta un nuevo modelo de administración basada en políticas de almacenamiento, que permite políticas a nivel de máquina virtual en lugar de todo el almacén de datos. Esto permite que cada VM tenga su propia configuración para aspectos como la disponibilidad, el rendimiento y el aprovisionamiento ligero. Estas son configuraciones dinámicas, por lo que, si una VM de repente necesita protección adicional, VSAN se adaptará. En comparación con las versiones anteriores, este nuevo enfoque es mucho más simple y permite un control más granular.
Históricamente, VSAN ha operado en una configuración híbrida utilizando unidades magnéticas tradicionales como capacidad de almacenamiento, con flash como caché de lectura para acelerar el rendimiento. Para lograr el máximo rendimiento, se ha introducido una configuración all-flash. Para mantener bajo el costo de esta opción, el papel de la capacidad lo desempeñará una unidad MLC rentable. VSAN aún requiere un nivel de almacenamiento en caché, pero no para el rendimiento. En cambio, la idea es minimizar la carga de trabajo de escritura en el nivel de capacidad y extender su vida útil. Es importante tener en cuenta la naturaleza de escritura de la carga de trabajo.

En un esfuerzo por mejorar la utilidad en los servidores blade, VSAN 6.0 ahora tiene una opción de almacenamiento adjunto directo de alta densidad. No veo esto como una gran opción ya que VMware aún recomienda que todos los servidores en un clúster VSAN tengan la misma configuración de almacenamiento. El uso de tantos gabinetes JBOD externos utiliza una cantidad significativa de espacio en el chasis blade, por lo que esta podría ser una solución muy costosa.

VSAN 6.0 ahora es compatible con rack. Al crear Fault Domains, que representan un mínimo de tres racks, VSAN será lo suficientemente inteligente como para distribuir datos entre estos racks. Esto ayudará a protegerlo contra cortes de energía, problemas con el controlador de almacenamiento y fallas en la red.
¿Cuál es el próximo titular? ¿Se podría usar la próxima versión de VSAN junto con un arreglo de almacenamiento externo? De hecho, esto es algo de lo que Chuck Hollis habló hace más de un año en su blog. Ahora que tenemos un dominio de fallas ampliado, ¿el siguiente paso será un clúster de VSAN ampliado? Veo un futuro en el que VSAN se extienda a vCloud Air como una simplificación de la recuperación ante desastres. La perceptibilidad que falta en VSAN 6.0 es cualquier tipo de tecnología de reducción de datos y otros servicios de datos avanzados. Con los desarrollos recientes en VSAN 6.0, está claro que VMware está invirtiendo mucho en la tecnología. Espero con ansias lo que pueda traer el próximo lanzamiento.
Sobre la autora
Mark May es ingeniero de almacenamiento en Cincinnati, Ohio. Cuenta con más de 15 años de experiencia en almacenamiento y copias de seguridad empresariales. Es EMC Elect, Cisco Champion y un apasionado de la tecnología. En su tiempo libre, le gusta ayudar a otros a comprender los entresijos de la industria del almacenamiento, en constante evolución. Se le puede encontrar en línea en diversos sitios, pero los más comunes son su blog personal y su cuenta de Twitter: @cincystorage.




Amazon