Hola a todos de nuevo.Soy Miguel Ángel Alonso y aquí estoy como cada martes para hablaros sobre el mundo de la virtualización de sistemas.

En el post de hoy te voy a hablar de la solución NEXENTASTORE (basada en Solaris) para crear almacenamiento en casi cualquier hardware que reúna un mínimo de requerimientos de hardware para la virtualización de sistemas.

Te preguntarás: ¿Qué tiene de especial esta solución si ya se ha hablado en anteriores posts  de otras como DataCore, Starwind o incluso de soluciones como Openfiler, Freenas para nuestros laboratorios?

Pues lo que hace especial, a mi modo ver, a esta solución son estas características que te voy a numerar y que para mí son primordiales. Estas características, asociadas a la facilidad de instalación de XeXentaStore, han hecho que incluso en el entorno de laboratorio de JMG VirtualConsulting nos hayamos decidido por migrar todo nuestro entorno virtual de VMware, Citrix y Microsoft a esta maravillosa solución de almacenamiento para entornos virtuales.

Es que es gratuita, aunque por supuesto tienes la versión de pago

• NexentaStore 3.1.1 Community Edition (free) y hasta 18 TB
• NexentaStore Enterprise 3.1.1 con soporte, acceso a Plugins de virtualización y pago en función de los TB que necesites en tu entorno de trabajo.

Permite Compresión, Snapshots, Deduplicación, Reparación

La versión gratuita te permite todas estas funcionalidades en segundo plano de cualquier bloque o archivo dañado, optimización del rendimiento en el apartado de I/O en cabina, ISCSI,FC,NFS v2,v3 y v4, CIFS,FTP,WEBDAV, lecturas de I/O a nivel de disco y de red muy completa y un largo etcétera de opciones que nos serán de gran utilidad.

En la versión de pago (Enterprise) dispondras, además ,de alta disponibilidad y mirroring entre cabinas dealmacenamiento.

Integración con VAAI (segunda generación),  para VMware vSphere 4.1 y  5.0 que incluye las siguientes primitivas

Este es el este punto mas interesante a tener en cuenta, ya que tanto la versión gratuita como la de pago nos ofrecen 2 características que en el mundo de la virtualización nos van a dar muchas ventaja:

Primitiva 1:

SCSI Write Same

Acelerando la escritura de Zeros en los bloques cuando creamos una máquina virtual. (Compatible con vSphere 4.1 y posteriores)

Primitiva 2:

SCSI ATS

Crea una “región” en la LUN para ser bloqueada en lugar de utilizarla entera a la hora de crear Snapshots. (Compatible con vSphere 4.1 y posteriores)

Primitiva 3:

SCSI Block Copy

Evita la lectura y la escritura de los bloques de datos “a través” del host ESX   durante una operación de copia de bloque al permitir que “VMware” pueda instruir a la SAN para hacerlo. (Compatible con vSphere 4.1 y posteriores)

Primitiva 4:

SCSI Unmap

Permite a los bloques liberados, el ser devueltos a la zpool (pools de Volúmenes Zvol) para la asignación de nuevos, cuando ya no se utilizan o dejan de utilizarse para el almacenamiento de las VMs. (Compatible con vSphere 5 y versiones posteriores).

Como resultado podremos ver desde nuestro vCenter o nuestro ESX  y desde la pestaña de Storage, que tenemos Aceleración por Hardware como si de cualquier cabina de DELL, EMC, NETAPP o cualquier gran marca se tratara.

Integración con Citrix StorageLink

Por ultimo, NeXentaStore soporta Citrix StorageLink, la cual es una herramienta que nos permite crear VMs de manera masiva a partir de templates en cuestión de minutos o de crear planes de recuperación ante desastres entre algunas de sus características.

Lo único que tendremos que hace es instalar el adaptador de Storage link,  de apenas 700 Kb desde Nexenta, e instalarlo donde tengamos la consola de Citrix StorageLink.

En la imagen anterior, se muestra que ya podemos tener acceso a las cabinas NAS o SAN con Nexenta después de instalar el Adapatador.

Y aquí, podemos ver la creación y manejo de repositorios de nuestra cabina Nexenta con Citrix StorageLink.

La instalación de Nexenta es muy sencilla y creo que no cabe lugar en el post para ello. Si fuese necesario y tuvieseis dudas sobre su instalación hacernos lo saber y no dudaré en crear un post de la instalación si así lo requereis.

También, y antes de terminar, me gustaría deciros que también la podéis bajar en formato Appliance para VMware y Citrix como Máquina Virtual.

Bueno hasta aquí por hoy. Espero que te haya gustado y te emplazo hasta la semana que viene con un nuevo capítulo sobre la virtualización.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

En un post publicado la semana pasada, te explique que es la política de balanceo de VMware vSphere llamada Round Robin y como configurar esta para una cabina de Dell EqualLogic.

En el post de hoy te enseñare a configurar y elegir automáticamente la política de balanceo de E/S de disco en VMware vSphere llamada Round Robin.

Para poder configurar el PSP – de las siglas en inglés Path Selection Plugin – para cualquier dispositivo de almacenamiento, es necesario ejecutar el siguiente comando:

esxcli -–server nmp device setpolicy –device –psp

Nota: Puedes una explicación más detallada de los que es PSP en el post llamado: He configurado el Round Robin, pero los caminos no son utilizados de manera uniforme”

Lo importante que me gustaría destacar en este punto es que la configuración del PSP es por DataStore, es decir, que si tienes 100 datasotres y quieres cambiar la configuración del PSP de Fixed a Round Robin has de hacer el mismo cambio en los 100 datastores.

Sin embargo, podemos configurar VMware vSphere ESX/ESXi para que automáticamente este pueda elegir Round Robin para cualquier dispositivo controlado por el SATP – de las siglas en ingles Storage Array type Plugin.

Y aquí es donde bien lo interesante de la cuestión: ¿Cuál es el comando o comandos para configurar tu VMware vSphere ESX/ESXi de manera que el PSP por defecto sea Round Robin?

Estos son los cuatro commandos que has de ejecutar directamente en tu servidor VMware vSphere ESX/ESX 4.x:

1. esxcli –server corestorage claiming unclaim –type location
2. esxcli –server nmp satp setdefaultpsp –satp –psp VMW_PSP_RR
3. esxcli –server corestorage claimrule load
4. esxcli –server corestorage claimrule run

Una vez ejecutados estos commandos tu politica de PSP por defecto sera Round Robin.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Ya esta disponible online el episodio #24 en virtualizacion.tv, el programa de televisión web que ayuda a profesionales como tú, a entender la virtualización de sistemas y el cloud computing en español.

En el episodio de esta semana, hablaremos de los discos de estado sólido en entornos de virtualización, responderé a la pregunta de un usuario en relación a los beneficios del hardware virtual versión 7 en las máquinas virtuales, te enseñare otra utilizad impresionante relacionada con el mundo de la virtualización y del Cloud Computing y terminaremos con el caso de éxito del mundo de la virtualización del Correo Gallego.

Gracias a todos los que dejaron su comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, entra en virtualizacion.tv hazlo ahora. Tu apoyo permitirá que este programa de televisión web sobre la virtualización de sistemas y el cloud computing en español, pueda continuar beneficiando a muchas personas.

¿Crees que este videopost puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por tu apoyo.

Buenos días, soy Jose Maria Gris y como cada miércoles estoy aquí para hablar sobre el Ecosistema de VMware.

Os he ido enseñando poco a poco la nueva versión de Datacore. En post anteriores sobre laboratorios de bajo coste, en algunas transparencias os he ido enseñando la nueva cara de nuestro viejo amigo.

Lo cierto es que no tiene nada que ver. La consola de SANmelody ahora se nos antoja antigua y poco amigable, ahora todo es muy intuitivo y además nos trae nuevas funcionalidades.

Hablando de nuevas funcionalidades, especial mención al CDP que incorpora. Nos ayudará mucho en momentos de apuro y nos dará tranquilidad en el resto del tiempo (que falta hace)

Quien me conoce sabe que muchas veces digo “A mi no me crea, pruébelo”. Nuestros amigos de Datacore han hecho lo mismo y han montado unas maquetas para que quien quiera pueda probar el nuevo producto.

Pulsando aquí, podréis acceder a la pagina de su web donde podréis ver dos interesantes videos sobre la presentación del producto y sobre una demostración de alta disponibilidad. Interesante de ver.

¡Pero queremos probar! Pues a ello vamos, en este link podéis acceder a un “Test Drive” y probar con vuestro mouse como funciona. Ojo, tan sólo funciona con Internet Explorer.

En breve haré un tutorial de cómo se instala y como se gestiona nuestro nuevo SANsymphony-V.

A lo mejor hago algún pinito y grabo un video. ¿Que opina nuestro Chief Editor?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

Esta semana me gustaría retomar el scripting con PowerCLI para trabajar en esta ocasión con los contadores de rendimiento de nuestra plataforma vSphere.

Para obtener la información de nuestra plataforma contaremos con dos cmdlets principales, complementarios entre sí, encargados de darnos la información que requeríamos de nuestro entorno. Básicamente se tratan de:

• Get-Stat, que es el que realmente nos devuelve la información acerca de los contadores de rendimiento que requiramos.
• Get-StatType, que nos informa de los contadores disponibles para el objeto que queramos interrogar, ya sea una máquina virtual, un host ESX(i) o un vCenter.

Si os parece bien, en lugar de ponerme a enumerar los parámetros de cada uno de los cmdlets Get-Stat y Get-StatType, vemos cómo usarlos mediante un par de ejemplos.

En su ejecución más simple, sin parámetro ninguno, este cmdlet nos devolverá el promedio de los contadores de rendimiento normales en el intervalo de muestreo, que por defecto se establece en 20 segundos, para host o vCenter al que estemos conectados. Por ejemplo:

PowerCLI> Get-Stat
MetricId Timestamp Value Unit Instance
——– ——— —– —- ——–
mem.usage.average 11/05/2011 15:27:00 90,42 %
mem.usage.average 11/05/2011 15:26:40 90,43 %
mem.usage.average 11/05/2011 15:26:20 90,43 %
…
net.usage.average 11/05/2011 15:27:00 0 KBps
net.usage.average 11/05/2011 15:26:40 0 KBps
net.usage.average 11/05/2011 15:26:20 0 KBps
…
disk.usage.average 11/05/2011 15:27:00 129 KBps
disk.usage.average 11/05/2011 15:26:40 98 KBps
disk.usage.average 11/05/2011 15:26:20 125 KBps
…

Si sólo estamos interesados en alguno de los grupos genéricos usaremos los modificadores Memory, CPU, Disk o Network según el que nos interese.

Sin embargo, como todos sabemos, los contadores de rendimiento en vmware no se limitan solo al Host o al vCenter, sino que se extienden a máquinas virtuales, resource pools, etc… Para acceder a esta información sólo tendremos que usar el parámetro Entity al que le pasaremos un array con los objetos sobre los que queramos información.

Por ejemplo, como ya vimos en otro post anterior, el cmdlet Get-VM nos devuelve todas las máquinas virtuales registradas en un host, cluster o vCenter. Si queremos obtener los contadores de rendimiento comunes de todas nuestras máquinas virtuales encendidas, sólo tendremos que ejecutar el siguiente comando:

PowerCLI>Get-Stat (Get-VM | Where-Object { $_.PowerState –eq ‘PoweredOn’ } | Export-CSV –delimiter “;” perfVM.csv

Donde Where-Object { $_.PowerState –eq ‘PoweredOn’ } es el filtro que nos permite discriminar por el estado de la máquina virtual y Export-CSV –delimiter “;” perfVM.csv exporta el resultado a un fichero CSV para que sea más sencillo realizar el tratamiento de los datos. Si estáis interesados en los datos de una VM en particular sólo tenéis que cambiar el filtro y la pipe anterior (el símbolo |) por el nombre de la máquina virtual.

No me gustaría terminar sin comentaros el modificador para mí más importante Stat. Este modificador admite como parámetro una array de tipo cadena con un listado de los contadores de rendimiento en los que estamos interesados. Es precisamente en este punto donde entra en juego el otro cmdlet que os mencionaba al principio, Get-StatType, que es el encargado de mostrarnos los contadores que tenemos disponibles para un tipo de objeto en particular. Tened presente que la lista de contadores disponibles dependerá de los elementos de los que dispongáis en vuestra plataforma.

Una vez consultado los contadores que nos interesen mediante Get-StatType, podemos interrogar a nuestra plataforma por los valores que nos interesen.

En el siguiente ejemplo comprobaremos la latencia y el throughput en el adaptador de almacenamiento vmhba2.

PowerCLI> Get-Stat -Stat @(“storageAdapter.totalReadLatency.average”, “storageAdapter.totalWriteLatency.average”, “storageAdapter.read.average”, “storageAdapter.write.average”) | Where-Object { $_.Instance -eq ‘vmhba2′ } |Out-GridView

Donde @(“storageAdapter.totalReadLatency.average”, “storageAdapter.totalWriteLatency.average”, “storageAdapter.read.average”, “storageAdapter.write.average”) es el array con los contadores que nos interesan y Where-Object { $_.Instance -eq ‘vmhba2′ } de nuevo es un filtro que en esta ocasión nos permite fijarnos sólo en el adaptador vmhba2.

Esta vez en lugar de exportar los datos a un fichero CSV he preferido sacar los resultados a una ventana externa donde además podremos filtrar mucho más los resultados.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

StarWind Software es el líder global de administración de bases de almacenamiento y desarrollo de software de SAN para pequeñas y medianas empresas.

El ejemplo más representativo de productos de StarWind es el software de SAN que convierte cualquier servidor estándar de Windows en una SAN iSCSI segura y tolerante a fallos. El programa está diseñado para su uso como almacenamiento en una red con VMware, Hyper-V, Microsoft SQL Server, Microsoft Exchange, Microsoft SharePoint y otras aplicaciones de servidor que se configuran en los clústeres de servidor.

La compañía StarWind Software está orientada a las pequeñas y medianas empresas ofreciéndoles la tecnología barata de alta disponibilidad que hace poco solamente estaba disponible en los productos prestigiosos y caros de almacenamiento.

Las características avanzadas de sus productos incluyen creación de espejos síncronos con tolerancia a fallos y recuperación automática, replicación remota en una WAN, protección continua de datos y puntos de recuperación, thin provisioning y administración de cintas virtuales.

En el año 2003 StarWind lanza su primer programa de SAN iSCSI convirtiéndose en el producto favorito para más de 30.000 usuarios de todo el mundo en más de 100 países, desde pequeñas y medianas empresas, hasta gobiernos y compañías de Fortune 1000.

Aprenda más sobre las soluciones de productos StarWind registrándose en nuestros seminarios web gratuitos:

Hola de nuevo, soy Jose Maria Gris y seguimos comentando el caso APD.

La foto no es un cuadro de Miró, es un masking de pintores…. (Nota del Blogger…)

Hoy vamos a ver como tenemos que hacer para que aunque tengamos o no el parche adecuado para solventar el APD, pues si nos aseguramos de quitar de forma correcta la LUN, estaremos mas tranquilos no?

El KB 1015084 nos indica paso a paso lo que hay que hacer por consola.

- Dejar de usar el datastore en cuestión

• Desregristrar las VM que estén allí registradas
• Asegurarse de que no hay scripts que están trabajando con la LUN en cuestión

- En ESX tenemos el NMP (Native Multi Path) y el MASK-PATH Plugin que es el que usamos para hacer masking con las LUNs. Para saber si están disponibles:

• # esxcfg-mpath –G

El output debe ser parecido a

• # esxcfg-mpath -G?MASK_PATH?NMP

Listamos las claimrules existentes

• # esxcli corestorage claimrule list

El output será parecido a

• # esxcli corestorage claimrule list?Rule Class Type Plugin Matches?0 runtime transport NMP transport=usb?1 runtime transport NMP transport=sata?2 runtime transport NMP transport=ide?3 runtime transport NMP transport=block?4 runtime transport NMP transport=unknown?101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport?101 file vendor MASK_PATH vendor=DELL model=Universal Xport?65535 runtime vendor NMP vendor=* model=*

Añadimos una rule mediante el la siguiente instrucción:

• # esxcli corestorage claimrule add –rule  -t location -A -C -T -L -P MASK_PATH

donde -A <hba_adapter> -C <channel> -T <Target> -L <lun> define un único path. El numero de la “rule” debe ser entre 101 y 200.

Verificamos que la rule esta incluida….

# esxcli corestorage claimrule list

Y la cargamos. Así con todos los paths.

# esxcli corestorage claimrule load

Si todo ello esta correcto podemos hacer el claiming

# esxcli corestorage claiming reclaim -d

Donde <naa.id> es el identificador del device.

Con todo ello efectuado y borrados todos los paths, iremos a vCenter y nos iremos a Host > Configuration > Storage, click Refresh y el datastore desaparecerá.

Podemos deshacer el maping de la LUN desde nuestro Array.

Como ultimo paso, nos quedaría limpiar la tabla de rules

# esxcli corestorage claimrule delete –rule

Cargar

# esxcli corestorage claimrule load

Y listar para ver que todo queda limpio. Si queda alguna rule, pues a empezar el proceso de cleaning de nuevo.

Espero haya sido interesante.

Referencias :

Unpresenting a LUN containing a datastore from ESX 4.x and ESXi 4.x (1009449)

Masking a LUN from ESX and ESXi 4.x using the MASK_PATH plug-in (1009449)

Queridos lectores,

En el post de hoy os enseñaré un pequeño truco para poder disponer de nuestras ISOs en el almacenamiento local de nuestro XenServer.

Como sabéis desde la consola de XenCenter la única manera de poder crear un repositorio para ISOs es a través de la red:

Os recuerdo los pasos:

1.- Añadimos nuevo storage, seleccionamos NFS ISO

2.- Introducimos la ruta del servidor y del directorio publicado por NFS y pulsamos en finalizar

Lógicamente para este método necesitaremos un sistema que permita almacenamiento en red. Pero para instalaciones más modestas existe este otro método que explico a continuación en el cual podremos meter nuestras ISOs en el repositorio local del servidor XenServer

Nos conectamos por SSH al servidor XenServer y desde CLI ejecutaremos los siguientes comandos:

1.- Creamos el directorio por ejemplo:

mkdir /var/opt/xen/isos

2.- Creamos el repositorio en el directorio anteriormente creado:

xe sr-create name-label=ISOs type=iso device-config:location=/var/opt/xen/isos device-config:legacy_mode=true content-type=iso

Y como podéis apreciar si hacemos un listado de los repositorios sale en nuevo creado:

A partir de ahora tendremos que subir los ISOs mediante SCP desde Linux o Mac o cualquier cliente Windows como WinSCP.

Esto es todo amigos, como siempre espero que sea de utilidad.

Hola soy Jose Maria Gris y de nuevo estoy aquí con vosotros. Últimamente esta sección parece un poco como cuarto milenio . Lo que os comentaré hoy no es que sea cosa de brujas pero si es cierto que me ha traído de cabeza en 2 instalaciones estos días y la verdad es que no acababa de verlo claro. Tras investigación y pruebas de laboratorio, ha quedado bastante claro.

Bien, todo empieza cuando llego a una instalación que “se ha vuelto loca”. Sencillamente es ingobernable, no contesta ni responde correctamente ni al VI client ni a vCenter…. No se comporta correctamente con SSH. Vamos, un potro desbocado. Eso sí, las VM continúan dando servicio sin problema.

Nos ponemos en contacto con soporte y nos comentan que lo que tenemos es un “All paths Down” o APD. Solución: Hay que entrar en las vms por RDP, pararlas y posteriormente hacer caer el ESX/i con un Cold Reset. Cuando se levante, todo estará en su sitio. Soporte “dixit”

Bien, vamos a ver como ocurre esto. El KB 1016626 nos empieza a dar luz sobre el tema. El resumen es “si se efectúa un rescan cuando una lun esta con todos los enlaces caídos puede generar o bien que otra vm deje de responder o como me ocurrió a mi, que los hosts se vuelvan locos.” Las razones pueden ser múltiples, error de hardware, sacar una lun de golpe, etc. Lo cierto es que con diversos levels de ESX he visto comportamientos muy parecidos, pero distintos.

Por lo que he estado investigando, es un bug de vSphere. Con 3.5 no pasaba. Básicamente si en un rescan el sistema detecta que no encuentra una Lun, se vuelca con el proceso hotsd a buscarla, tanto, que llega a bloquear nics, etc….

Si estás leyendo esto y estas en 4.0. U1, tienes que pensar en instalar el parche que se indica mas abajo en referencias, el cual minimiza el tiempo de “no respuesta”. Con 4.0 U2 y 4.1 ya viene instalado.

La buena noticia es que ya leí en un KB que en versión 4.1 U1 el tema se solventaba. La tengo instalada en mi laboratorio y efectivamente entre las features comenta que “ya no deberá pasar mas”, aunque hay un comentario sobre “si ocurre, contacta con soporte técnico.”

No contento con ello he cogido una instalación grande en preproducción, con SANs y con Datacore importante y simplemente he sacado una lun para posteriormente hacer un rescan manual desde el cluster. Lo cierto es que no le ha gustado nada, ha “tosido” se ha molestado, se ha recorcobecado, pero al cabo de un par de minutos estaba todo bien y continuaba en su sitio. Nada que no se pueda mitigar.

Lo reconozco, no me he quedado contento. Lo he probado en mi pobre labo. Los resultados han sido los mismos.

No os voy a decir que el APD ha quedado eliminado, esto lo debe decir el fabricante, pero en mis pruebas, al menos, no ha aparecido….

No obstante, la próxima semana os presentaré como hacer correctamente un “masking” desde ESXi para despresentar una LUN en vSphere 4.x (esté o no solventado el APD, por si las moscas).

Hasta la semana que viene.

Referencias
KB Article: 1016626 Virtual machines stop responding when any LUN on the host is in an all-paths-down condition (APD)
VMware ESX 4.0, Patch ESX400-200912401-BG: Updates vmkernel, vmklinux, tools, CIM, and perftools (1016291)
VMware ESXi 4.0, Patch ESXi400-200912401-BG: Updates Firmware (1016295)

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://virtualscoop.org/files/gulati.pdf
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