Volúmenes virtuales en vSphere 6.0. Cinco aspectos a tener en cuenta
Con la actualización de vSphere 6.0, VMware ha incorporado una nueva característica a su catálogo, Virtual Volumes (VVOL), que permiten aplicar políticas basadas en métricas a nivel de máquina virtual, no a nivel global. Se trata de un paso importante frente a la versión 5.5, y un cambio de paradigma en lo referido a cómo se gestiona el almacenamiento externo y las máquinas virtuales.
Los desarrollos con VVOL permiten simplificar tareas operativas, mejorar el uso de los recursos y ofrecer un servicio a nivel de aplicación más granular. Sin embargo, es necesario tener en cuenta una serie de elementos, en concreto cinco, a la hora de implementar una estrategia VVOL.
Si el almacenamiento está sobre protocolos iSCI, Fiber Channel o FCoE (basado en bloques) o NFS (basado en ficheros), las máquinas virtuales se almacenan en un objeto lógico conocido como almacén de datos. En el caso de los almacenes de datos NFS, usan el propio sistema de ficheros de la plataforma NFS, pero las soluciones basadas en bloques usan Virtual Machine File System, un formato propietario de VMware que ha ido siendo ampliado en las sucesivas versiones de vSphere, y ahora soporta una capacidad mayor (62TB VMDK) y rendimiento,
Cuando se emplean arrays externos, los almacenes de datos casi siempre se construyen sobre un único volumen (LUN), es que normalmente la unidad más pequeña de almacenamiento direccionable.
En plataformas no virtualizadas, la granularidad a nivel LUN es una restricción aceptable cuando mapeamos una o más LUN en un único servidor, permitiendo aplicar políticas de servicio a nivel LUN. Cuando están virtualizadas, la relación entre LUN y las máquinas virtuales se invierte y se convierte en uno a varios, todos aportando el mismo nivel de servicio porque están en un mismo volumen compartido.
Esta arquitectura presenta un buen número de problemas. Las diferentes métricas basadas en políticas, incluidas las de calidad de servicio (QoS) sólo pueden aplicarse a nivel LUN, lo que significa que todas las máquinas virtuales en un mismo almacén de datos tienen aplicado el mismo nivel de servicio. Hasta ahora, los clientes de VMware paliaban esto con funcionalidades como Storage DRS.
El cambio en los niveles de servicio de una máquina virtual al moverla a otro almacén de datos tenía un impacto en el consumo de tiempo y recursos y una reserva de espacio a nivel físico por su tenemos necesidades de rebalanceamiento.
Incluso, no es posible aplicar políticas de QoS a nivel de máquina virtual. Una estrategia de una máquina virtual por LUN tampoco funciona porque ESXi (el hypervisor en vShere) está limitado a 256 LUN por host, lo que limita la capacidad de escalabilidad.
Con los cambios implementados en la nueva version, se permite una aproximación más granular, y el resultado son los volúmenes virtuales.
Cada VVOL direcciona un componente de una máquina virtual, con lo que múltiples VVOL componen un objeto de máquina virtual.
VVOL introducen nuevos conceptos que explican cómo se implementa la tecnología:
1. Proveedor de almacenamiento (SP). Actúa como una interfaz entre el hypervisor y el array externo. No está en la ruta de los datos y usa el protocolo VASA (vSphere API for Storage Awareness) API existente. Requiere el soporte de VASA 2.0, presente en vSphere 6.
2. Contenedor de almacenamiento (SC). Es un conjunto de configuraciones físicas de almacenamiento en el dispositivo externo. La implementación puede variar según el proveedor del almacenamiento, por lo que es necesario tener en cuenta cómo lo resuelve cada uno.
3. Protocolo Endpoint (PE). Este objeto proporciona visibilidad de los VVOL al hypervisor. Para aquellos usuarios familiarizados con la tecnología VMAX de EMC, este protocolo de acceso es similar a un gatekeeper.
La mayor parte del trabajo para implementar VVOL está en el lado del array. VMware ha proporcionado las especificaciones, pero los proveedores tienen que implementarlas. Con esto en mente, hay cinco aspectos a tener en cuenta:
1- ¿Cuántos VVOL soporta la plataforma? Cada máquina virtual necesita más de uno. Es preciso también uno para el VM config, VM swap y cada VMDK de cada máquina virtual. Esto supone que el número de máquinas virtuales permitidas por la plataforma es muy inferior al número de VVOL necesarios, lo que puede suponer una complicación en algunos arrays all-flash.
2.- ¿Qué capacidades están soportadas a nivel de máquina virtual? A priori, deberíamos esperar que QoS, snapshots y replicación sí estén soportadas, pero a veces depende del fabricante del array ofrecerlas como parte de una plataforma existente.
3.- ¿Puedo ejecutar cargas de trabajo mixtas? La implementación de VVOL no tiene que ser un todo o nada. Los proveedores deben establecer que la implementación de los VVOL funciona y no supone un impacto para el resto de cargas de trabajo.
4.- ¿Cómo se soporta VASA? VASA 2.0 es necesario para hacer correr los VVOL. Algunas implementaciones de VASA son nativas en el array, pero algunos proveedores requieren implementar software adicional para proporcionar el servicio. Un soporte no nativo debe hacer pensar sobre el impacto en coste y en tiempo o activos para su desarrollo.
5.- ¿Son los VVOL una opción de pago? Algunos proveedores pueden decidir poner precio a esta capacidad, sobre todo si la ofrecen como una actualización. Ahora sabemos que VMware va a cobrarla para la versión all-flash de VSAN en vSphere 6, por lo que no sería una sorpresa que algunos proveedores quisieran recuperar parte de esta inversión al ofrecer esta capacidad.
