SIOC: PARDA llevada a la realidad

Que VMware es una empresa que trata de innovar y superarse a sí misma día a día es algo por todos conocidos, y prueba de ello son el desarrollo de tecnologías como vMotion, Storage vMotion, View, HA o Fault Tolerance por mencionar algunas.

En este artículo me gustaría hablar sobre Storage I/O Control (SIOC), una de esas nuevas funcionalidades que, independientemente de la calidad de la implementación, suelen calificarse como “una gran idea”.

Y es que SIOC es una vuelta de tuerca más al aprovechamiento de recursos, ya que extrapola el concepto de “shares” que ya conocíamos y que se aplicaban a la memoria y a la CPU y lo extiende al almacenamiento. Sin embargo la parte novedosa de SIOC es que esta priorización y optimización del consumo de recursos, en este caso del almacenamiento, se hace en base al almacenamiento compartido y no al almacenamiento local.

Para entender un poco mejor el funcionamiento de SIOC y apreciar verdaderamente la novedad de la solución debemos remontarnos a los tiempo de PARDA, nombre original que se le dio al proyecto, y en cuya definición podremos encontrar las bases de lo que hoy es SIOC.

Como comentaba, la idea base de SIOC/PARDA es la de optimizar el acceso al almacenamiento compartido, y en particular a la LUN que aloja nuestro datastore. Para ello, SIOC controla la latencia de acceso al almacenamiento y modifica la ventana del host en base a un umbral de latencia definido por el usuario. Es importante resaltar que cuando hablamos de umbral de latencia estamos tratando con el tiempo medio de retraso de acceso al almacenamiento de todo el clúster y no de un host en particular. La virtud de SIOC es que mantiene la desviación estándar de este valor bastante baja. Esto quiere decir que para conseguir un umbral de latencia de 20ms no nos encontraremos un hosts con una latencia de 30ms y otro con una latencia de 10ms.

¿Y cómo consigue SIOC mantener el umbral de latencia?

Pues gracias al concepto de ventana, a un algoritmo que se encarga de calcular el valor esta ventana y a la comunicación entre los hosts ESX/ESXi para conocer y poder calcular la latencia total del clúster. Desgranemos un poco estos elementos:

• El concepto de ventana es análogo al utilizado en las pilas TCP/IP, y representa a la longitud de cola de operaciones de entrada salida por segundo (IOPS). Esta ventana es recalculada de forma periódica por el algoritmo ejecutado en el host. Es importante destacar, que al contrario que ocurre con los paquetes TCP que se segmentan en una longitud fija (el MTU), el tamaño de la IO suele cambiar con bastante frecuencia, por lo que se toma el promedio del tamaño de estas IO para hacer el cálculo de la ventana.
• El algoritmo que se usa para ajustar la ventana, que podréis encontrar explicado en la definición del proyecto PARDA, se ejecuta periódicamente en cada host ESX/ESXi de forma independiente. Esto se hace así para evitar la sobre carga que podría suponer la comunicación entre todos los miembros del clúster. Sin embargo, el algoritmo necesita conocer el estado del clúster para poder calcular correctamente el tamaño de la ventana. Para ello hace uso del siguiente componente que encontramos en el siguiente punto.
• La comunicación entre los hosts ESX/ESXi. Como he comentado resulta un elemento fundamental para poder calcular la latencia total del clúster. En este caso se trata de un fichero compartido entre todos los miembros del clúster, en el que se le asigna un bloque completo a cada nodo y donde se almacena la latencia media y el número de IOs de cada uno de ellos.

En el plano más práctico todo esto se traduce en poder priorizar el acceso al almacenamiento de aquellas máquinas virtuales que lo requieran. Y esto se consigue aplicando el mismo concepto de share que ya conocemos de los recursos de memoria y de CPU, con lo que si a una máquina virtual A (VM A) le aplico el doble de shares que a la máquina virtual B (VM B), la VM A tendrá el doble de throughput (medido en IOPS) y la mitad de latencia que la VM B.

¿Y cómo consigo configurar todo esto?

Pues para empezar necesito tener una licencia vSphere Enterprise Plus, que el almacenamiento sea gestionado por un único vCenter, que sea de tipo FiberChannel o iSCSI (de momento NFS y RDM no está soportado) y que el datastore no tenga extensiones (extents).

El siguiente paso será habilitar SIOC en el datastore que queramos monitorizar, y donde se alojarán las máquinas críticas. Esto lo podemos hacer desde las propiedades del datastore, en la pestaña de configuración del vSphere Client, y marcar la opción “Storage I/O Control” y establecer el umbral de latencia. Cuando hayamos habilitado SIOC en el datastore podremos ver el fichero iormstat.sf, que es el encargado de almacenar la información del clúster que necesita SIOC para controlar la latencia de las máquinas virtuales.

El último paso que nos queda sería la asignación de los valores de share para el almacenamiento en cada una de las máquinas virtuales, del mismo modo que lo haríamos con la memoria o la CPU, desde la pestaña de recursos, en la opción de “Disco”.

VMware ha publicado varios documentos en los que se muestra la diferencia entre datacenters con SIOC habilitado y sin él, y lo cierto es que es una opción muy a tener en cuenta, sobre todo en entornos donde existen máquinas virtuales críticas. Quizá la mayor ventaja de esta opción, además de la priorización de acceso al almacenamiento, sea la de hacer previsible el comportamiento del acceso al almacenamiento y evitarnos sorpresas desagradables en los picos de uso para las máquinas críticas, aunque evidentemente todo esto dependerá del entorno de cada uno.

Referencias:

http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_SIOC.pdf
www.vmware.com/pdf/vsphere4/r41/vsp_41_resource_mgmt.pdf
http://www.yellow-bricks.com/2009/02/15/project-parda/
http://www.yellow-bricks.com/2010/10/08/sioc-tying-up-some-loose-ends/
http://blogs.vmware.com/performance/2010/07/sioc.html