Mejorar la performance con View Storage Accelerator

Cuando nos enfrentamos a un proyecto de virtualización de escritorios con VMware View, una de nuestras principales preocupaciones es la performance del equipamiento de Storage, específicamente el numero de IOPS que este soporta v/s el numero de IOPS requerido por los escritorios virtuales.  De hecho, este punto puede marcar la diferencia entre el éxito y el fracaso de un proyecto de virtualización de escritorios (VDI).

El momento más critico que puede enfrentar un entorno VDI, en cuanto a performance, es cuando se produce lo que se conoce como “Boot Storm”.  Una Boot Storm es una degradación del servicio que ocurre cuando un numero significativo de usuarios se conectan a sus escritorios virtuales en forma simultánea (o en un periodo de tiempo muy corto), provocando un alto consumo de IOPS a nivel de Storage, además de afectar la performance de los hosts y el throughput de la red.

Las Boot Storms son un problema serio, ya que no solo puede degradar la performance de la plataforma VDI, sino que puede incluso provocar que esta deje de funcionar temporalmente.  Esto eventualmente puede provocar que proyectos de VDI fracasen por las constantes quejas de los usuarios.

En otro post hablaremos de como prevenir, o al menos reducir el impacto de las Boot Storm, y de otros problemas asociados a la performance en un entorno VDI, como las Login Storm y Antivirus Storms.

Como una forma de combatir este punto critico del diseño de un proyecto VDI, es posible ahora utilizar VMware View Storage Accelerator, el cual apalanca la funcionalidad llamada Content-Based Read Cache (CBRC) incluida a partir de vSphere 5.0 y que se integra con VMware View 5.1.

Ahora, que es CBRC???

Bueno, CBRC no es más que un cache basado en la RAM de los hosts ESXi, para bloques VMDK comúnmente accedidos por virtual desktops.  Esta disponible a partir de vSphere 5.0 y fue diseñado específicamente para entornos VDI.  La idea aquí es “sacrificar” algo de la memoria de los nodos ESXi que proveen de los recursos de computo a una plataforma VDI, y reutilizarla como un cache de lectura.

Como su nombre lo indica esta cache esta basada en contenido, por lo que puede almacenar en cache cualquier bloque de cualquier MV que contenga contenido idéntico, sin importar de como fueron creadas las MVs (Clones, Linked Clones, P2V, etc).  Debido a que el cache mantiene bloques de datos indexados por su contenido en vez de por sectores lógicos, el tamaño de cache requerido es bastante pequeño.

Y como funciona CBRC?

El modulo principal de CBRC es el CBRC VSCSI Filter (llamado también CBRC Filter), que se conecta al archivo de disco (vmdk) de una maquina virtual para proveer de la interfaz necesaria para realizar el Hashing y el Caching.

El CBRC filter es atachado en forma transparente a un disco VMDK habilitado para CBRC.  Esto mantiene una cache global en la RAM para atender los requerimientos de I/O de las maquinas virtuales.

Offline Hashing

Al momento de la creación de una MV (y a intervalos regulares), el contenido de cada  archivo VMDK es indexado en un proceso llamado Offline Hashing. Durante el Offline Hashing, se crean archivos VMDK (Digest files) por cada VMDK de booteo almacenado en el datastore VMFS.  Estos nuevos VMDK estarán nombrados como archivos terminados en -digest.vmdk, y contienen metadata y un conjunto de hashes con informacion acerca de los bloques contenidos en el VMDK de booteo.  Basicamente es una tabla hash donde cada valor hash apunta a un bloque particular.

Si la MV contiene un Snapshot, entonces se crea un Digest File para el VMDK del Snapshot.  Si el VMDK es clonado, el digest file es también copiado.

En el caso de utilizar Linked Clones (View Composer), el digest file del disco base (replica) es compartido por todas las máquinas virtuales de la misma forma que comparten dicho disco base.  Por cada MV en Linked Clone se crea un Digest File separado que corresponde al disco delta de cada clon.

Online Caching

El Online Caching es configurado por el administrador de la plataforma y tiene un tamaño fijo máximo de 2GB de RAM por host, mientras que el tamaño por defecto es de 400MB de memoria RAM.

Cuando una MV se enciende, la metadata del Digest File es cargada en el espacio reservado de la RAM en los hosts ESXi 5.x.  Esta contiene el mapeo del hash de los bloques validos del Digest File.

Con ambos componentes (Offline Hashing y Online Caching), cuando una MV emite una solicitud de lectura de I/O para leer un bloque, revisa la copia en cache del Digest buscando un hash valido del bloque requerido.  Si el hash requerido es valido y el bloque se encuentra presente, es atendido directamente desde el cache en RAM, lo cual elimina los I/Os de lectura hacia el Storage.  Si el hash solicitado es valido pero el bloque no existe en el cache en RAM, entonces se accede al Storage y el bloque es copiado en cache en la RAM para luego ser entregado a la MV.

Si el valor hash del bloque solicitado esta marcado como invalido, entonces el contenido es atendido directamente desde el Storage.

Consideraciones

• El cache solo almacena bloques comunes a más de una MV.
• El contenido de los Digest Files es regenerado en intervalos configurables (tipicamente semanales o mensuales).
• Debido a que el Cache está diseñado solo pare lecturas, cuando un bloque de una MV es modificado, el valor hash correspondiente dentro del Digest File es marcado como invalido, por lo que dicha MV no podrá utilizar la copia del bloque almacenada en cache (debido a que el contenido cambió).
• Es necesario regenerar el Digest File regularmente para asegurar que el Cache tiene entradas validas.  Si este proceso no es hecho regularmente, grandes porciones del Digest File podrían estar marcadas como invalidas y se verán limitados los beneficios de View Storage Accelerator.
• Si la nueva data escrita es idéntica en múltiples MVs (por ejemplo al aplicar el mismo parche a múltiples maquinas virtuales), los bloques correspondientes serán almacenados en cache la próxima vez que los Digest Files sean regenerados.

View Storage Accelerator

Ahora que ya tenemos claro que es Content-Based Read Cache, podemos centrarnos en View Storage Accelerator para VMware View.

Como indicamos anteriormente, CBRC solo existe por y para VMware View, proveyendo de soporte para Host Caching para escritorios virtuales.  CBRC debe ser habilitado y configurado explícitamente en View Administrator, a la vez que no es necesario realizar configuraciones manuales de los parámetros de CBRC en vSphere.

View Storage Accelerator es configurado a traves de los parametros de Host Cache en dos niveles:

1. Configuración de vCenter Server en View Administrator.  Esta configuración se debe realizar por cada vCenter asociado a la plataforma View.  En Inventory > Servers se debe editar el vCenter Server e ir a la sección Host Cache para habilitar Host Caching (Estas opciones están disponibles también cuando agregamos un nuevo vCenter Server al View Administrator).
   Cuando el Host Caching es habilitado en un vCenter Server, todos los hosts vSphere (versión 5 o posterior) que son parte de dicho vCenter son identificados como hosts habilitados para Host Caching.
   Cada host puede ser configurado con un tamaño de Cache diferente, pero no es posible deshabilitar Host Caching en un host especifico.
   Nota: Aunque los parámetros de Host Caching son configurados a traves de View Administrator, la configuración no es aplicada en un host vSphere hasta que una MV con Host Caching habilitado utilice dicho host.
2. Configuración de Advanced Storage en un pool de escritorios.  Una vez que tenemos habilitado Host Caching a nivel de vCenter Server, entonces cualquier pool de escritorios que es creado en dicho vCenter provee de la opción Use Host Caching.  Mientras se está creando un Pool, en la sección Advanced Storage Options se puede habilitar el Host Caching, así como las siguientes opciones
   1. Frecuencia de regeneración del Cache para reducir el numero de hashes inválidos en el Digest File.  Por defecto la frecuencia es de 7 días.
   2. Tipo de discos de la maquina virtual que serán usadas para Host Caching.  Esta opción solo está disponible para polos con Linked Clones con redirección de datos de usuarios.  Por defecto solo el disco del Sistema Operativo (VMDK de boot) es seleccionado para Online Caching.  Es posible también seleccionar que los discos persistentes de los Linked Clones sean incluidos en el Cache.
   3. Blackout Times.  Este parámetro permite indicar periodos de tiempo cuando la regeneración de Cache no debiera ser realizada.  Esto permite, por ejemplo, evitar que la regeneración se lleve a cabo en horarios de trabajo o en periodos peak.

Es posible también realizar esta configuración editando un pool de escritorios existente.  No obstante lo anterior, la configuración de Host Caching de un pool solo es aplicada cuando la MV se encuentra apagada.
Si el Host Caching está deshabilitado a nivel de vCenter Server, la opción de Host Caching no se encontrará disponible a nivel de Pool de escritorio.

Ventajas de View Storage Accelerator

1. View Storage Accelerator  ofrece grandes mejoras de performance durante boot storms cuando un gran numero de MV clonadas son encendidas.
2. View Storage Accelerator es altamente eficiente cuando los discos virtuales tienen el mismo contenido, sin importar de donde proviene dicho contenido.  Esto es muy frecuente en entornos View donde pueden haber discos compartidos como las replicas de View Composer, o pools de escritorios full clone, que son clonados a partir del mismo templare.
3. View Storage Accelerator ofrece beneficios también cuando los usuarios cargan frecuentemente aplicaciones como Outlook, Adobe Reader y otras aplicaciones o datos.  En estos casos, las solicitudes de lectura de contenido idéntico son atendidas directamente desde el Cache.
4. View Storage Accelerator es soportado para Pools de escritorios manuales, Pools automáticos para escritorios Full Clone, y para Pools de Linked Clones..
5. La configuración de View Storage Accelerator  puede ser realizada fácilmente a traves de la consola de View Administrator.
6. Mantener View Storage Accelerator  es bastante sencillo a traves del uso de parámetros de automatización para Regeneración de Digest y de periodos de Blackput.
7. En el caso de escritorios con discos persistentes para datos de usuarios, es posible configurar View Storage Accelerator tanto para el disco de sistema operativo como para los discos persistentes.
8. La configuración CBRC es aplicada a hosts vSphere en forma dinámica, basado en la posible ubicación de los escritorios virtuales con Host Caching habilitado.  Esto asegura que no se realicen reservaciones innecesarias de memoria para Cache en hosts que nunca serán utilizados por escritorios virtuales.

Limitaciones

1. Virtual machine host caching es aplicado solo cuando la máquina virtual se encuentra apagada.  Si la MV se encuentra encendida al momento de habilitar Host Caching, es necesario que dicha MV sea apagada para que la configuración sea aplicada.  En el caso de Linked Clones, el Host Caching no puede ser habilitado mientras una de las MV que compartan el mismo disco base se encuentre encendida.
2. Host Caching utiliza la RAM de los hosts ESXi, lo cual reduce el radio de consolidación de la plataforma virtual.
3. Al habilitar Host Caching se crearán discos adicionales por cada VMDK de boot y por cada VMDK de snapshots, lo cual resultará en un aumento del uso del almacenamiento.
4. Host Caching no puede ser configurado para Pool no gestionados por vCenter o para Pools de Terminar Server.

Conclusiones

Como hemos visto, entornos de Escritorios Virtuales con VMware View podrán obtener mejoras de performance a nivel de I/O de almacenamiento al utilizar View Storage Accelerator y Content Based Read Cache, especialmente en ambientes que no cuentan con arreglos de Storage con gestión de Cache.

En caso de que el Storage utilizado cuente con Cache de lectura o de lectura/escritura, de igual forma CBRC ayudará a reducir la latencia de las operaciones de I/O debido a que las operaciones de I/O de lectura serán atendidas por la cache en memoria RAM y no será necesario traer los bloques de datos a traves de la red de almacenamiento.

Si quieren más información pueden leer el whitepaper View Storage Accelerator in VMware View 5.1.