Virtual Volumes (vVols) – Como funcionan?

/, Lanzamiento, Software Defined Datacenter, Storage, VMware, vSphere/Virtual Volumes (vVols) – Como funcionan?

[Total: 0    Average: 0/5]
VVols

Hola a todos!!!
Seguimos con las novedades en el lanzamiento de vSphere 6.0, hablando de una de las funcionalidades largamente anunciada, que de hecho fue mencionada por primera vez en el VMworld 2012 en San Francisco.  Hace unos meses, en el VMworld 2014 se anunciaron algunas de sus características que podían encontrar en el Beta de vSphere 6.0, y de lo cual hablamos en otro post hace unos meses, explicando que eran los VVols.
En esta ocasión, hablaremos respecto a la arquitectura de vVols, sus componentes, y como éstos funcionan.

Componentes de VVols.

La arquitectura de VVols, la cual detallaremos un poco más adelante, esta compuesta de distintos componentes los cuales explicaremos a continuación:

Virtual Volumes

Captura de pantalla 2015-01-30 19.04.44Los Virtual Volumes son encapsulaciones de los archivos que componen las maquinas virtuales, como los archivos de configuración, archivos swap, etc., así como también de los discos virtuales y sus snapshots correspondientes.  Son objetos almacenados nativamente en un Storage compatible, independiente del tipo de conexión que éste utilice (Ethernet o SAN) y pueden ser gestionados directamente en el Storage.  Al igual que otros objetos, los Virtual Volumen son identificados por un GUID único.
A diferencia de las LUNs en una arquitectura tradicional de almacenamiento, los Virtual Volumen no son provisionados previamente, sino que son creados automáticamente cuando se realiza una operación que involucre a una maquina virtual, como sería la creación, clonación y snapshot de una máquina virtual.
A nivel de vSphere, ESXi y vCenter asocian uno o más Virtual Volumes a una máquina virtual:
  • Un Virtual Volume para los archivos de configuración, equivalente al Home Directory en un Datastore VMFS tradicional.  Este vVol contiene los archivos metadata de una maquina virtual, incluyendo el archivo .vmx, los descriptores de los discos virtuales (.vmdk), archivos de logs, etc.  Este vVol en particular es formateado con un sistema de archivos, dependiendo del protocolo utilizado para conectarse al Storage, pudiendo ser VMFS o NFS.
  • Un Virtual Volume para archivos Swap, el cual contiene los archivos swap de una máquina virtual.
  • Un Virtual Volume para cada disco virtual (-flat.vmdk).  Al igual que los discos virtuales en un Datastore tradicional, los VVols que contienen los discos virtuales son presentados a las máquinas virtuales como discos SCSI.  Los VVols soportan el mismo conjunto de comandos SCSI que se usa en VMFS, así como también los comandos típicos de NFS.
  • Se pueden requerir Virtual Volumes adicionales para otros componentes de una máquina virtual, por ejemplo:
    • vVols para Discos virtuales delta generados durante un snapshot.
    • vVols para memoria virtual, requerido para almacenar el contenido de la memoria de una máquina virtual cuando se genera un snapshot que incluye la opción de snapshot de memoria virtual.
Es decir, como minimo requerimos 3 vVols para cada máquina virtual: Configuración, Disco virtual y Swap.  Por ejemplo, si tenemos una máquina virtual con 2 discos virtuales, tendremos 4 vVols:
  • vVol de configuración (Home Directory)
  • vVol para archivos Swap
  • 2 vVols, uno por cada disco virtual.
Si a ésta máquina virtual le tomamos un snapshot, que incluya la memoria virtual, requeriremos 3 vVols adicionales:
  • vVol para la memoria virtual
  • 2 vVols, uno para cada archivo delta de los discos virtuales.
Como podemos ver, al usar distintos virtual volumen para diferentes componentes de las máquinas virtuales, es posible aplicar políticas de almacenamiento con un alto nivel de granularidad.  Por ejemplo, para una misma máquina virtual es posible asignar distintos niveles de performance y redundancia a sus vVols, pudiendo proveer de mejor performance al disco virtual de datos que al disco virtual utilizado para el boot del Sistema Operativo.

VVols Storage Providers

También conocidos como VASA provider, es un componente de software que permite la comunicación entre vSphere (vCenter y hosts ESXi) y el Storage.
Un Storage Provider entrega información desde el Storage, o del Storage Container en el caso de los vVols, de manera que las características del Storage Container puedan aparecer visibles a través de vSphere Web Client.  De la misma forma, el Storage Provider envía los requerimientos de almacenamiento de una máquina virtual, los cuales se definen a través de una Storage Policy, a la capa de Storage.
La implementación del VVol Storage Provider se realiza a través de VASA (Vmware APIs for Storage Awareness), luego de lo cual  debe ser registrado apropiadamente en vCenter Server.  Este Storage Provider se integra con el servicio SMS (Storage Monitoring Service) de vSphere, para así comunicarse con vCenter Server y los hosts ESXi.  Este proceso de integración asegura que un VVol creado en el Storage cumpla con los requerimientos definidos en la Storage Policy.
Los responsables de desarrollar y proveer Storage Providers que se integren con vSphere y que soporten VVols, son los fabricantes de Storage.  Estos Storage Providers deben pasar por un proceso de certificación en VMware.

Storage Container

Captura de pantalla 2015-01-30 18.50.29A diferencia del almacenamiento basado en LUNs o en NFS, y como ya mencionamos antes, los VVols no requieren que los volúmenes sean creados previamente en el Storage.   En lugar de esto, los VVols utilizan lo que se denomina como Storage Container, el cual es básicamente un pool de capacidad de almacenamiento RAW que un Storage compatible provee para el uso de vVols.
Un Storage Container es una unidad lógica dentro de un Storage compatible, el cual permite agrupar lógicamente múltiples VVols basado en los requerimientos del cliente, actuando básicamente como un almacén de VVols, proveyendo así la capacidad y características requeridas por las máquinas virtuales.  Los Storage Container son creados en el arreglo de Storage, y tipicamente esta tarea recae en el administrador de Storage.
El numero de Storage Containers y sus capacidades dependen de las limitaciones impuestas por los fabricantes de storage, pero se requiere al menos un Storage Container por cada Storage.  Un unico Storage Container puede contar con múltiples Profiles, cada uno con sus propias características de performance, disponibilidad, etc.  De esta manera, en un Storage Container se pueden almacenar máquinas virtuales con distintas necesidades y distintas politicas de almacenamiento.
Para que los hosts ESXi tengan visibilidad de los Storage Container, se requiere que en vCenter Server se haya registrado previamente un VVols Storage Provider asociado con el Storage.  De esta manera, vCenter Server puede descubrir todos los Storage Containers configurados, junto con sus características, Protocol Endpoints, y otros atributos.
Los Storage Containers descubiertos no son inicialmente conectados a un host especifico.  Para poder montar un Storage Container, se debe mapear a un VVols Datastore, lo cual lo detallaremos a continuación en este mismo post.

Protocol Endpoints (PE)

Captura de pantalla 2015-01-30 19.26.19En una arquitectura con VVols, los hosts ESXi no tienen acceso directo a los VVols en el Storage, sino que utilizan un Proxy I/O lógico llamado Protocol Endpoint para comunicarse con los VVols y los archivos encapsulados en éstos.   ESXi utiliza los Protocol Endpoints para establecer un data path desde una máquina virtual a sus respectivos VVols.  Casa VVol es asociado a un PE especifico, de manera que cuando una maquina virtual realiza una operación de I/O, el PE dirige este I/O al VVol apropiado.
Típicamente un Storage requiere un numero muy pequeño de PEs, donde un único PE puede conectar cientos o miles de VVols.  Desde el Storage, el administrador configura los Protocol Endpoints, pudiendo configurar uno o varios por Storage Container.  Estos luego son presentados a vSphere, junto con los Storage Containers asociados, a través de un VVols Storage Provider.
Los Protocol Endpoints son descubiertos por los hosts ESXi, y quedan visibles en vSphere Web Client, luego de crear un VVol Datastore o durante un Storage Rescan.  En vSphere Web Client la lista de PEs disponibles luce similar a la lista de Host Storage Devices.
Para exponer un PE en ESXi se puede utilizar un protocolo basado en SCSI (FC, FCoE, iSCSI), donde el PE es representado de manera similar a una LUN, con un WWN (world wide name) en formato T10.  Tambien es posible utilizar protocolo NFS para exponer un PE en ESXi, donde el PE corresponde a un punto de montaje como por ejemplo la dirección IP y un nombre de Share.
Es posible configurar multipath solo cuando un PE esta utilizando un protocolo basado en SCSI.  No obstante, independiente del protocolo de transporte utilizado, un Storage puede proveer múltiples PEs para propósito de alta disponibilidad en la conexión entre ESXi y los VVols.

VVols Datastores

Captura de pantalla 2015-01-30 19.14.51Un VVols Datastore es la representación de un Storage Container en vCenter Server y en vSphere Web Client.

Después de que vCenter descubre los Storage Containers presentados por el Storage, estos deben ser montados en los hosts ESXi para poder utilizarlos.  Para esto se utiliza el asistente de creación de Datastores en el vSphere Web Client, de manera de crear un VVols Datastore por cada Storage Container.

Desde la perspectiva del administrador de vSphere, un VVols Datastore es similar a cualquier otro datastore (VMFS o NFS), y es utilizado para almacenar máquinas virtuales.  Como otros datastores, es posible navegar (browse) en un VVols Datastore, y listar los VVols de configuración (Home Directory) de cada máquina virtual.
Es posible montar y desmontar un VVols Datastore, pero no es posible realizar operaciones tales como upgrade y redimensionamiento del Datastore.  La capacidad de un VVols Datastore solo es configurable en el Storage, y no en vSphere.

Arquitectura

Captura de pantalla 2015-01-30 21.29.45Ya discutimos los distintos componentes que forman la arquitectura de VVols.  Ahora pongamos pongamos todo eso junto y hagamos un resumen de la arquitectura utilizada con Virtual Volumes en vSphere 6.0, viendo como todos los componentes interactuan entre si.
Viendo el diagrama de la derecha, podemos resumir la arquitectura de la siguiente forma:
  • En primer lugar, debemos contar con un Storage que soporte VVols y que pueda integrarse con vSphere a través de VASA (vSphere APIs for Storage Awareness )
  • En el Storage, el administrador deberá crear uno o más Storage Container, los cuales posteriormente contendrán los VVols.
  • El Administrador del Storage también deberá crear los Protocol Endpoints requeridos.  Es posible crear múltiples Protocol Endpoints para proveer de redundancia en las conexiones al Storage.
  • Se debe realizar el deploy de un VVols Storage Provider (en la imagen VASA Provider).  La implementación de este Provider varía dependiendo del fabricante del Storage.
  • A nivel de vSphere, debemos contar con una conexión adecuada entre los hosts ESXi y el Storage, pudiendo utilizar cualquiera de los protocolos soportados por vSphere, pudiendo ser FC, FCoE, iSCSI o NFS.  En el caso de utilizar iSCSI, se configura el uso de Dynamic Discovery, utilizando la dirección IP del VVols Storage Provider.
  • El VVols Storage Provider debe ser registrado en vCenter Server, para permitir el uso de Virtual Volumes.
  • Los VVols Datastores son creados a traves del vSphere Web Client, utilizando el asistente “New Datastore”.  De esta forma, se realiza el mapping entre un VVols Datastore y un Storage Container.
  • ESXi utiliza los Protocol Endpoints creados previamente para comunicarse con los VVols y los archivos encapsulados en ellos.  Estos PE son visibles en vSphere Web Client despues de crear un VVols Datastore o de realizar un Rescan.
  • Opcionalmente, se puede cambiar la politica de multipath en un Protocol Endpoint, siempre que el protocolo de transporte utilizado este basado en SCSI (FC, FCoE, iSCSI).  Para esto se utiliza la opción “Edit Multipathing Policies”.

Una vez teniendo clara la arquitectura de VVols y de como interactuan sus componentes, podemos ver los componentes involucrados en la creación de una máquina virtual

  • Las máquinas virtuales son provisionadas en un VVols Datastore.
  • Para utilizar VVols, se requiere el uso de VM Storage Policy.  Si no se crea una VM Storage Policy compatible con VVols, el sistema utiliza la politica por defecto, “No Requirements“.  Esta es una politica generica de VVols que no contiene reglas o especificaciones de almacenamiento.  Si una máquina virtual tiene un requerimiento especifico, por ejemplo de performance o redundancia, se puede crear una VM Storage Policy para definir estos requerimientos.
  • Al momento de crear o clonar una máquina virtual es posible asignarle una VM Storage Policy, la cual permite asegurar que el storage donde se crearán los VVols correspondientes, cumpla con los requisitos de almacenamiento de la máquina virtual.
  • Como podemos ver en el diagrama de arquitectura, es posible crear multiples VM Storage Policies, cada una representando distintos requerimientos de almacenamiento, desde el punto de vista de la performance, redundancia y alta disponibilidad.  En el diagrama tenemos tres VM Storage Policies (Gold, Silver y Bronze), las cuales se pueden aplicar a las máquinas virtuales y sus VVols, dependiendo de sus requerimientos.

Conclusiones

Como podemos ver, la introducción de los VVols en vSphere 6.0 nos permite dar un enorme paso en la adopción del Software Defined Storage, proveyendo de una infraestructura de almacenamiento mucho más flexible y sencilla de administrar, tanto para el administrador de vSphere como para el administrador de Storage, facilitando enormemente la tarea de proveer de capacidad de almacenamiento en ambientes virtuales.

Los VVols también nos permiten contar con un mayor nivel de granularidad a la hora de asignar y controlar el uso de los recursos de almacenamiento a las máquinas virtuales, pudiendo por ejemplo crear una máquina virtual con un requerimiento de alta disponibilidad y redundancia, compartiendo VVols Datastore (Storage Container) con máquinas virtuales con requerimientos de menor redundancia y disponibilidad.  Esto puede sonar familiar a aquellos que se hayan involucrado con VSAN, ya que si bien son tecnologias distintas, tienen muchos puntos en común, al ser ambas representaciones de Software Defined Storage.

Esto permite hacer un uso mucho más eficiente de los recursos, reduciendo el desperdicio de éstos, y que las máquinas virtuales obtengan los recursos de almacenamiento que realmente requieren, lo que redunda finalmente en un mejor funcionamiento global de la plataforma, y en una reducción de costos.

Si bien la arquitectura de VVols puede parecer un cambio radical en la forma en que hemos venido trabajando durante varios años (Datastores VMFS/NFS), e incluso a algunos puede parecerles confusa, si leen detenidamente verán que no es un modelo complejo de entender e implementar, y que de hecho si VMware ha hecho bien su trabajo en el desarrollo de VVols, es un modelo que tiene mucho futuro en ambientes virtualizados y de Cloud Computing.

Espero les haya sido de interes 🙂

 

By | 2017-07-05T19:51:37+00:00 February 2nd, 2015|Cloud Computing, Lanzamiento, Software Defined Datacenter, Storage, VMware, vSphere|1 Comment

About the Author:

One Comment

  1. Patricio May 15, 2017 at 12:02 - Reply

    Gran explicación como siempre.

Leave A Comment

EnglishPortugueseSpanish