Vi, Almacenamiento y Backup - II - Gestión del almacenamiento.

Bueno.... en el post anterior os dejé con mis reflexiones en voz alta sobre el tema del backup y del almacenamiento, reflexiones que me han tenido ocupado gran parte de este verano, dado que en mi organización se prevee un despliegue masivo de máquinas virtuales a lo largo de este año que acaba y el siguiente. Obligatoriamente, una reflexión profunda se impone en estos casos, ya que una elección precipitada puede encadenarnos a una determinada solución que, a medio plazo, se muestra ineficiente o no adaptada a la realidad de nuestro entorno.

Pues bien, Hablé con mi amigo Javier de Network Appliance, y me prestó amablemente una unidad de las suyas... quien me conoce, sabe que tengo total debilidad por los equipos de NetApp, pero en este caso, la elección vino dada por la versatilidad de los equipos (Soporte simultáneo de CIFS, NFS, FC e iSCSI), las capacidades de protección de datos (Snapshotting, soporte NDMP), las de recuperación ante desastres (Replicación local y geográfica) y las de gestión del dato (Instancia única de almacenamiento, etc).

Así que, equipado con mis preocupaciones, un hermoso switch gigabit, un par de Host ESX y una unidad NatApp 2050c, me metí a resolver las primeras y de paso, cacharrear con las capacidades del equipo de NetApp.

Todos los que administramos o implementamos VI, acabamos siempre con el mismo problema: El espacio ocupado por las VM. A diferencia de otros entornos, donde el crecimiento es progresivo, sin grandes incrementos diarios (porcentuales, quiero decir), los entornos virtualizados crecen "a saltos", es decir... un día nos queda un Tbyte libre en nuestra flamante y bien administrada SAN, y al día siguiente nos vemos moviendo VM's al improvisado NFS que, a toda prisa, hemos tenido que montar porque alguien, normalmente con mucha prisa, ha pedido seis o siete máquinas virtuales. A una media de 10 GBytes por disco de arranque, y dos o tres discos de datos de 100Gb, ese Tbyte que nos quedaba libre se va quedando en nada a una velocidad increible: El incremento, de un día para otro, puede suponer un 20 o un 30% del total ya asignado... Todo esto sin contar con el consiguiente backup.

Si nos paramos a pensar un instante, el contenido de 10 (por ejemplo) discos de arranque de windows 2003 server es bastante parecido. Quiero decir que el sistema operativo es el mismo, y si las máquinas virtuales han sido desplegadas desde la misma plantilla (que debería ser lo lógico), no es disparatado suponer que al menos un 80% del contenido de los discos duros virtuales de esas diez máquinas debería ser, al menos en el momento del despliege, idéntico. Eso significa que nuestras diez máquinas virtuales del ejemplo que nos ocupa (asumiendo un muy prudente disco de arranque de 10 Gb) comparten, al menos, 80 de los 100 GBytes que ocupan... 80 valiosos GBytes de datos duplicados.

El almacenamiento de Instancia única (Single Instance Storage o SIS) es una vieja aspiración (y muchas veces mito) en los entornos corporativos, no sólo en lo que a virtualización se refiere: Entornos de almacenamiento de ficheros (donde se estima que entre el 40% y el 50% está duplicado), entornos de Correo corporativo (sólo imaginad lo que ocupa ese documento que enviamos como attach a 5 o 6 personas cuando estas empiezan a hacer lo mismo con otras tantas... cada una), e incluso en las bases de datos (¿Quién no guarda un backup de SQL hecho "a pelo" además de los almacenados en nuestro sistema de backup?). He de reconocer que siempre fuí bastante excéptico respecto al SIS basado en sistema operativo (Mi vieja frase de zapatero a tus zapatos) y respecto al SIS en tiempo real (SIS on-fly), así que cuando Jose me dijo "Prueba nuestro SIS", elevé la ceja y le dije... "bueno, pero no esperes demasiado".

NetApp, en la última versión de DataONTAP, su sistema operativo de gestión de almacenamiento, incluye una capacidad de SIS (que ellos llaman A-SIS) basada en la deduplicación. Me explico: El equipo no se dedica a verificar cada bloque que escribe contra una tabla de bloques para ver si está o no duplicado. Espera pacientemente a la hora que le digamos para revisarse el volumen y, gracias a su tecnología de punteros, elimina los bloques redundantes y los sustituye por punteros.

Bueno... a lo que íbamos. Aprovechando que estamos con la evaluación de Virtual Desktop (de lo que también he de hablaros), decidí probar el A-SIS. Los resultados hablan por sí mismos: 20 máquinas virtuales Windows XP professional, con disco de 32 Gb ocuparon, al finalizar el despliegue de las mismas y ejecutar el proceso de deduplicación, en, aprox, 100 Gb. Es decir, casi un 6:1 de ratio. No sé a vosotros, pero a mí me parece espectacular. El seguimiento de la evolución del A-SIS, teniendo en cuenta que, según los Virtual desktop iban diferenciándose en lo que a contenido del disco virtual. (ficheros temp, archivo de swap, datos de usuario), el primer mes el incremento de uso de disco (osea, lo que A-SIS ha dejado de deduplicar), no ha llegado a 50GBytes... es decir, de mantenerse (y nada indica que deba alterarse), tardaré más de 8 Meses en necesitar los 640 Gb que, inicialmente, hubiese necesitado. En el caso que me ocupa, yo he desplegado Virtual Desktops persistentes, es decir, que se comporta como un desktop físico y evoluciona a lo largo del tiempo.... si los desktops fuesen no persistentes, es decir, se recrearan cada día.... jamás necesitaría los 640 GBytes.

También, y como curiosidad, apliqué A-SIS en un proyecto que mantenemos, formado por unas 30 máquinas virtuales de lo más variopintas que, en su momento, no fueron desplegadas con plantillas y que han ido evolucionando de manera independiente. Este proyecto es una mezcla de Windows 2003 en castellano e inglés, con Windows 2003 web edition, estandar edition y enterprise edition, con múltiples servidores ejecutando IIS, Sharepoint portal, Controladores de dominio y SQL server. La deduplicación inicial se limitó "sólo" a un 2:1... es decir, del Tbyte asignado me quedé con algo más de 500 GBytes libres. Os iré contando como evoluciona.

Una de mis preocupaciones iniciales era el impacto que el proceso de deduplicación tendría en el rendimiento de los ESX y, consecuentemente, en el de mis máquinas virtuales. Aunque en una máquina virtual que no ejecute Cluster de Microsoft es bastante extraño que se produzcan errores de acceso a disco por timeout, no es así en un MSCS, así que cloné un entorno de SQL Server + OLAP (una pesadilla rompemáquinas que mantenemos esperando su extinción), y en medio de esa pesadilla cascadiscos que es la generación de un cubo OLAP, forcé una deduplicación: El impacto en rendimiento fué apenas perceptible, rozando el 1% en momentos pico.

No todo el monte es orégano: Los procesos de deduplicación requieren de una vigilancia constante, ya que corremos el riesgo de que, al asignar más de lo que realmente tenemos, un día nos encontremos con un "file system full", experiencia que, como ya he dicho más de una vez, no es una experiencia agradable en un ESX. Otro riesgo a tener en cuenta es el hecho de que los ratios serán predecibles en tanto en cuanto la organización del disco virtual se mantenga, es decir, mientras que a nadie le dé por, por ejemplo, desfragmentar el disco de la Máquina Virtual.

En la próxima reunión del Grupo de usuarios IBERIA de VMware, hablaremos de estrategias de almacenamiento, así que espero tener terminada esta serie de artículos sobre este tema.

Un saludo;