Escrito por: Agustín Malanco, CTO Ambassador, VCDX #141
Que tal, el día de hoy les estaré hablando de las nuevas capacidades, cambios de arquitectura y ventajas que vSphere 6.0 nos ofrece a nivel de almacenamiento.
Como sabemos vSphere es la plataforma más confiable para virtualizar aplicaciones de todo tipo incluyendo aquellas consideradas como críticas, vSphere cuenta con múltiples mecanismos y tecnologías para asegurar los niveles de servicio que estas aplicaciones requieren siendo el almacenamiento uno de los más críticos por el impacto que puede llegar a tener en el rendimiento de las máquinas virtuales (incluyendo a los servicios que se ejecutan dentro de estas). Con la nueva versión de nuestra plataforma se continúa innovando y mejorando capacidades en este aspecto, entre las muchas mejoras que tienen nuestra plataforma podemos encontrar:
Virtual SAN (AKA VSAN) 2.0
VSAN no es algo nuevo para vSphere 6, en este caso fue mejorado sustancialmente, alcanzando nuevos límites en términos de escalabilidad y rendimiento. Con esta nueva versión de VSAN se liberaron mejoras bastante interesantes, vamos a revisar aquellas más relevantes:
- Incremento en número de componentes – Cada máquina virtual almacenada en VSAN está constituida por objetos y estos a su vez por componentes lo cual permite asegurar la disponibilidad y los SLAs definidos, en la versión previa se tenía un máximo de 3,000 componentes por host ESXi limitando la cantidad de MVs que podíamos tener almacenadas por host (cosa que podíamos notar claramente en ambientes de VDI donde se recomendaba un máximo de 100 MVs por host). Con vSphere 6.0 la cantidad máxima de componentes se incrementó a 9,000 por Host ESXi definiendo nuevos niveles de escalabilidad.
- All Flash VSAN – En la versión anterior de VSAN (vSphere 5.5), sólo existía una arquitectura que se lo conoce como “Hibrida” es debido a la mezcla de discos duros mecánicos y dispositivos Flash (SSD, PCIe,etc) teniendo como función de cache de lecturas y buffer de escrituras a los dispositivos Flash mientras que los discos duros (HDD) estaban encargados principalmente de proveer espacio persistente. La nueva opción de arquitectura para VSAN está constituida en su totalidad por dispositivos Flash, cambiando de manera sustancial en como trabaja Virtual SAN a nivel de escrituras y lecturas. En el caso de All Flash, se dedica un dispositivo flash como capa de “aceleración” exclusivamente para escrituras (Write buffer) y entregando todas las lecturas a partir de la capa de “persistencia” que también está constituida por dispositivos flash. En este caso se recomienda distintos tipos de dispositivos flash para cada una de las capas, por ejemplo, para la capa de “aceleración” de escrituras se recomiendan discos SSD o dispositivos PCIe que hayan sido pensados para un ambiente con muchas escrituras a disco (Write Intensive). Todas las recomendaciones y mayor información la podemos encontrar en la guía de diseño y dimensionamiento para VSAN 6.0
- Fault Domains – Con la versión de vSphere 6.0 se le agrega a VSAN el concepto de Failure Domains, en la siguiente imagen considerando que tuviéramos VSAN y vSphere 5.5 sin failure domains. Aquí podemos ver un cluster de VSAN donde en cada uno de los Racks (3 racks) tenemos ubicados dos nodos ESXi, vamos a suponer que cada uno de estos hosts sólo tiene un Disk group, por lo que el dominio de falla es un host ESXi y que estamos usando un FTT de 1, por lo que tendríamos 2 copias del objeto y un “witness”:
Imagen cortesía de hispavirt.com
Claramente estaríamos cumpliendo con el objetivo de proveer acceso a la máquina virtual pero lamentablemente estaríamos utilizando más espacio en disco para este motivo por lo cual tenía un impacto claro en el dimensionamiento y diseño de nuestro ambiente de VSAN. Con Failure Domains podemos definir grupos de hosts que pertenezcan a un “failure domain” que no es más que una agrupación lógica que le dicta a VSAN el cómo distribuir los componentes ni copias de los objetos en cuestión por lo que no se puede tener más de un componente ni copia de un objeto residiendo en un sólo failure domain. Tomando como base la misma imagen, si deseáramos tener disponibilidad de la máquina virtual aún cuando un rack completo quedara sin operación se debería de ver así:
Imagen cortesía de hispavirt.com
Esta nueva construcción lógica nos ayuda bastante a mitigar problemas de disponibilidad y además nos ayuda a simplificar el diseño de nuestra infraestructura de VSAN. Los failure domains nos ayudan a poder mitigar fallas en:
- Energía
- Racks
- Switches
- Disk groups
- Nuevo formato de disco – VMware adquirió a una empresa llamada Virsto hace casi ya 2 años, con esta empresa se agregaron tecnologías bastante interesantes al portafolio de VMware y no fue hasta VSAN 6.0 que estamos viendo reflejadas estas tecnologías en productos públicos. En el caso de VSAN se cambio el sistema de archivos que se utilizaba en la versión 5 (VMFS-L) a un sistema basado en tecnología virsto (VirstoFS) para habilitar snapshots más eficientes utilizando una tecnología llamada vsanSparse. Más información
Nuevos límites y escalabilidad – En la siguiente tabla podemos ver los nuevos límites y mejoras a nivel de VSAN 6, tanto All Flash como híbrida:
Virtual Volumes (vVOLs)
Virtual Volumes o mejor conocidos como vVOLs habilita a los administradores de vSphere el poder asignar políticas a nivel de las MVs de manera granular incluso a nivel de VMDK (disco duro virtual). Para lograr esto vVOLs se apoya de los APIs de VASA (vSphere APIs for Storage Awareness) lo cual habilita a los proveedores de almacenamiento presentar las capacidades específicas de sus arreglos a través de una serie de construcciones lógicas tanto a nivel de vSphere como a nivel del almacenamiento, vamos a darle un vistazo rápido a estos nuevos elementos:
- Protocol endpoint – Este componente permite el acceso al almacenamiento, cualquier operación de I/O pasa a través del. La tarea principal es la de direccionar las operaciones al vVOL correspondiente en arreglo de discos, los administradores de vSphere trabajarán con una LUN (en el caso de almacenamiento por bloque) o un punto de montaje para NFS.
- Storage Container – Es importante notar que un contenedor ofrece el espacio en disco y los servicios de datos disponibles por parte de dicho arreglo de discos. No estamos hablando de un LUN, estamos hablando de otro concepto exclusivamente utilizado por arreglos que soportan vVOLs, a través de este contenedor se pueden controlar que servicios (replicación, deduplicación, patrones de I/O, etc) se ofrecen a los vVOLs que residen en este contenedor.
- VASA/SPBM – vSphere ha utilizado VASA (vSphere APIs for Array Awareness) y SPBM (Storage Policy Based Management) desde versiones anteriores, en este caso se emplean para definir políticas aplicables directamente a las MVs y para poder comunicarse con el almacenamiento y entender de que es capaz (refiriéndonos a los servicios de datos y capacidades propias del arreglo).
- Virtual Volume (vVOL) – Cualquier archivo de MV se le asigna un vVOL, al igual que VSAN estamos hablando de objetos, por lo cual archivos como el VMDK (disco duro virtual), VMX (archivo de configuración), etc. Estarán siendo almacenados como un objeto que se considera a su vez un virtual volume, este virtual volume o vVOL gozará de las capacidades y servicios definidos a nivel del contenedor (Storage Container).
A mí me gusta comparar Virtual Volumes con VSAN, es debido a que permite a los arreglos de discos “tradicionales” el gestionar las MVs de manera granular gracias al manejarlas como objetos y poder asignar los servicios requeridos a estos objetos para cumplir los SLAs definidos.
NFS v4
Se agrega soporte para NFS v4 algo que fue esperado desde hace mucho tiempo siendo que VMware ha utilizado hasta la versión 5.5 NFS v3. Es importante notar que NO se incluye soporte para pNFS pero si se permite contar con multipathing agregando múltiples servidores en el momento de montar un export de NFS. Otra mejora sustancial con NFS v4 en vSphere es el ámbito de la seguridad, permitiendo utilizar Kerberos para la autenticación con el servidor de NFS. La implementación de NFS v4 actualmente no soporta Storage DRS, SIOC, SRM ni vVOLs.
Mejoras a Storage DRS y Storage I/O Control
Aunque tal vez estas mejoras a las dos tecnologías no las vemos publicitadas como VSAN ni vVOLs, para quienes hemos estado trabajando con VMware las encontramos bastante emocionantes. A grandes rasgos en esta nueva versión de vSphere SDRS y VASA tienen un nivel de integración mucho mayor lo que le permite a SDRS entender de mejor manera que servicios de datos están configurados en los datastores (y los LUNs que están respaldando a dichos datastores). Vamos a darle un vistazo a algunas de estas mejoras:
- Storage DRS y deduplicación a nivel del almacenamiento – SDRS ahora puede saber que datastores están respaldados por LUNs que están siendo deduplicadas, esto para evitar el migrar MVs a LUNs que no estén siendo deduplicadas en el mismo grupo esto a través de VASA que permite al almacenamiento comunicar que LUNs pertenecen a un mismo grupo de deduplicación.
- Auto-tiering y SDRS – Con vSphere 6 VASA es capaz de identificar que datastores están siendo respaldados por LUNs que participan en el movimiento automático de bloques a través de la solución especifica del proveedor de almacenamiento, en base a esto SDRS puede tomar decisiones que no interfieran con las decisiones tomadas por el almacenamiento.
Los invito a revisar los recursos disponibles relevantes al almacenamiento.
