Tras un par de meses de “descanso”, volvemos al ataque. Este verano ha sido especialmente caluroso en lo que a trabajo se refiere, sin tiempo para “refrescarme” con este blog, así que intentaré compensaros.
El tema que voy a tratar en este post, almacenamiento y backup, es una vieja espina que tengo clavada en lo que a este blog se refiere, y que suscita el mayor número de dudas en los círculos tecnológicos en los que me muevo. El almacenamiento y el backup, a mi parecer, necesita un replanteamiento nuevo en los entornos virtuales, ya que nos presenta nuevos problemas a los que hemos de dar nuevas soluciones.
En lo referente al almacenamiento, más que centrar la discusión en qué tecnología es la mejor (Canal de Fibra, iSCSI o NFS), centraré este post en las estrategias de uso del almacenamiento que, de manera independiente de la tecnología, empieza a presentar desafíos aparentemente no abordables que nos plantean los entornos de virtualización. Tanto si somos adeptos al “Virtual first” o primero en virtual como si somos más conservadores y sólo utilizamos la virtualización para entornos periféricos, tenemos el mismo problema: las VM ocupan espacio en disco. Y el disco no es ilimitado.
Respecto al backup, otro de los temas que más controversia está generando en el mundo de la virtualización corporativa, también hemos de estrujar nuestras neuronas en la búsqueda de una solución para nuestros entornos. No hace falta incidir en la importancia de una adecuada política de backup en cualquier entorno de producción, pero la propia naturaleza de los entornos virtualizados hace que la definición de una correcta política de backup sea dificultosa y dada a la ambigüedad.
Almacenamiento.
Miremos por un segundo nuestro entorno de toda la vida. Comprábamos un servidor, normalmente con un par de discos de 73 o 143 Gb en espejo, y nuestra siguiente preocupación era buscar o arañar espacio en la SAN existente para almacenar los datos. Todo es(era) así de simple. Desde el punto de vista del almacenamiento centralizado, el disco de sistema no existe y, consecuentemente, tendemos a olvidar esos pocos gigas que requiere cada servidor. Un pequeño estudio que he realizado, obligado por la necesidad de definir las plantillas de mis máquinas virtuales, me ha dado los siguientes datos:
Plantilla Base: Windows Server 2003 Estándar/Enterprise
Unidad de disco de arranque: 6 GB
Unidad de disco para swap y temps: 2 – 4 Gb
Unidad de disco para programas y demás 4 – xxx Gb
¿Porqué este esquema de disco? En lo referente al disco de arranque, le asigno 6GB con lo que le damos al sistema el espacio necesario para los ficheros de sistema, espacio libre para las actualizaciones (si no miraros como os queda el c:\windows después de un update), y un par de gigas de oxígeno por lo que pueda pasar. A efectos de backup, resitúo el swap y los temps en otro VMFS (al que no saco backup, al fin y al cabo, tanto los temporales como el archivo de swap, a efectos del sistema, es algo sin transcendencia a la hora de recuperarlo, ya que se regeneran en el primer arranque) cuyo tamaño dependerá de la memoria de la VM. Por último, reservo entre 4 y n gigabytes para la(s) aplicación(es) y dato(s) de la(s) misma(s).
En algunas plantillas más específicas, estas cifras se elevan:
Plantilla Virtual desktop: Windows XP con SP2
Unidad de disco de arranque 32 Gb
Lo que aparentemente parece inofensivo a efectos de espacio, progresa de una manera escalofriante: 20 Servidores virtuales nos requieren la nada desdeñable cantidad mínima de 240 Gb…. ¡!!Sólo para un servidor básico¡¡¡. 100 servidores, escenario nada disparatado – y si no ya veréis -, elevan esta cantidad a .. ¡¡¡¡1.2 TB!!!!. Si a esto le sumanos entre 20 y 25 Virtual desktops nos añaden entre 640 y 800 Gb.
A estos GB, hay que añadir los archivos de swap de VMware de las máquinas virtuales. El tamaño de los mismos dependerá de la memoria RAM del host, de las políticas de asignación de recursos y del uso de memoria de las máquinas virtuales. Por precaución, recomiendo asignar espacio extra en los VMfs según la siguiente fórmula: Nº de VMs x Memoria de las VM. Es decir… en el ejemplo de los 100 Máquinas virtuales con (digamos) 512 Mb de RAM, añadamos otros 50 Gb para el swapping de ESX. Un “filesystem full” en un ESX es una experiencia que no recomiendo a nadie.
Como podemos observar, incluso planteamientos muy conservadores nos obligan a provisionar entre 1 y 2 Tb para nuestros servidores virtuales. Apuesto un virtual switch a que a ninguno de los lectores de este post le sobran, así de pronto, 2 Tb en su SAN.
Tecnologías.
No es un secreto que soy un firme defensor de iSCSI en entornos ESX. No con esto quiero decir que, contra viento y marea, implemente o recomiende la implementación de iSCSI. Mi postura es, sin embargo, “iSCSI first”. Es decir, mi primera opción es, hasta el momento, usar iSCSI antes que cualquier otra tecnología. Sin embargo, hay escenarios, ya sea por la intensidad u otros factores, hay que pararse a considerar FC o NFS como opciones.
En mi personal caso, siempre he usado NFS como depósito de templates, imágenes ISO y VM de “baja intensidad” o de test. Lo hago así porque utilizo el mismo espacio que tengo asignado como servidor de ficheros en un Windows 2003 Server… y teniendo en cuenta que Windows Services for Unix es gratis, consigo ahorrarme valiosos Gb en mi querida SAN de Netapp. Conozco alguna experiencia (la de mi querido Alberto) en que usa NFS sobre NetApp, y aunque en su momento le miré con gesto torcido (“¿Porqué no iSCSI, ya que tienes un Netapp?”), poco a poco voy descubriendo las bondades de NFS sobre Netapp para almacenar VMs, ya que determinadas características de esta SAN/NAS incrementan su valor usando las capacidades NAS de este equipo. El siguiente post de esta serie, en donde describo mi experiencia con Network Apliance y ESX en lo referente al almacenamiento, backup y recuperación de desastres, me extenderé en estas ventajas.
Me reservo el uso de FC para entornos donde el acceso a disco sea crítico y necesite ser absolutamente predecible, es decir, independiente de la carga de CPU de los ESX. No hay que olvidar que el procesamiento IP y SCSI inherente iSCSI es realizado por la propia CPU de los ESX, con lo que en determinadas cirscunstancias, la carga impuesta por la propia virtualización puede penalizar el acceso a disco, provocando picos de muy poca duración (mi experiencia dice que prácticamente inapreciables en cualquier monitor SNMP) que, sin embargo, la VM si percibe. Las configuraciones de clustering de VM son especialmente sensibles a estos picos, lo que ocasiona failovers indeseados e, incluso, caídas del servicio de cluster en entornos Microsoft.
También la simplicidad y economía de los entornos iSCSI puede volverse en nuestra contra. Es toda una tentación ir añadiendo host iSCSI a nuestra red de almacenamiento debido al bajo coste de la solución. En entornos no virtuales, el hecho de que cuatro máquinas accedan a un Target iSCSI a gigabit por segundo (es decir, cuatro máquinas a 1 Gbit contra un target también a 1 Gbit) no es necesariamente peligroso o inconveniente, ya que, raramente, los requerimientos de I/O de esas 4 máquinas puedan exceder la capacidad del target. En un entorno de 4 servidores ESX con 100 máquinas virtuales en simultáneo la cosa cambia.
ESX 3.0.x , en mis pruebas, es capaz de mantenidos de 350 Mbit por segundo y con picos de 650 Mbit/sec sobre iSCSI… si multiplicamos por 4, observamos que el ancho de banda de un hipotético target a 1 Gbit/sec queda unos 400 Mbit/sec por debajo del mantenido esperado. Esto se traduce en timeouts en el acceso a disco de las VM y, consecuentemente, en posibles errores de disco. Tened en cuenta que un iniciador iSCSI por software en una máquina física o virtual “asume” pequeños picos en el acceso a disco y “defiende” al subsistema de disco del sistema operativo (esto también es aplicable a las HBA tanto iSCSI como FC). En el caso de una VM con un driver SCSI virtual, esta tolerancia a picos es inferior. En mi personal caso, intento hacer más tolerante al subsistema de disco de las VM en Windows (especialmente picajoso con estas cosas) incrementando los tiempos de timeout del disco.
Mi fórmula del millón para las redes iSCSI es simple: El target iSCSI ha de tener, al menos, Nº de ESX x 350 Mbit/sec redondeado al Gbit superior de ancho de banda para prevenir estas situaciones.
En el caso de que usemos FC en nuestros ESX, el escenario de 4 a 1 es bastante más tolerante. En primer lugar porque las propias HBA lidian con estas cosas del ancho de banda y los delay asociados… y por otra, porque liberan a ESX del procesamiento del protocolo de encapsulado y almacenamiento, eliminando el cuello de botella inherente al uso de CPU de los ESX.
¿Y los datastores sobre NFS? Pues sí… en principio debería sufrir los mismos problemas que iSCSI ya que, básicamente, es almacenamiento sobre IP. Bueno, no es del todo exacto. Mientras el control del flujo (cuando tengo o no datos) en iSCSI se limita a los comandos SCSI3 (que por definición no asumen demasiados delays y, consecuentemente son menos tolerantes), NFS, dada su naturaleza, los asume como inevitables, así que el cliente NFS ya se las compone para cachear y darle al host ESX una “buena explicación” de porqué ha de esperarse un poco cuando accede al vmdk en cuestión. ESX también se las compone (a través del driver SCSI paravirtualizado que instalamos con las VMware Tools), para que la VM no empiece a gritar “error de disco, error de disco!!!”. Cuidado con confiarse…. Estos “engaños” no nos solucionan el problema… simplemente nos lo hacen más asumible. Mis test indican que, ante la misma carga, la probabilidad de un error de disco en una VM por un acceso congestionado al VMFS es, como mínimo, un 12% inferior sobre NFS que sobre iSCSI, y la de un error crítico que fuerce la caída de un servicio, un 5% inferior.
(Como podéis ver, pocas vacaciones he tenido)
Por el contrario, NFS no permite el uso de VCB ni multipath…. Nada es perfecto.
Copia de seguridad.
Vale, ya tenemos donde guardar las VM… ¿pero cómo protegerlas ante un desastre, un borrado ocasional o una midificación indeseada que requiere la vuelta a una situación anterior?
Un planteamiento inicial, y totalmente válido, es mantener la estrategia de backup que aplicamos a las máquinas físicas, esto es, instalar agentes en cada uno de los servidores e incluírlos en nuestra programación de backup. Esta es, sin duda, la más inmediata y razonable de las estrategias abordables en cualquier entorno, pero no exenta de inconvenientes.
El primero de ellos es, sin duda, el coste. Dado que la virtualización puede - y de hecho lo hace - aumentar exponencialmente la proliferación de servidores y servicios, el coste de los agentes de backup puede multiplicarse y la complicación de nuestro entorno de backup, también. Si nos decidimos por esta opción, debemos tener en cuenta varias cosas.
La primera, y más evidente, es que, a más máquinas, más ventana de backup. Si multiplicamos por dos el número de servidores, quizá no se multiplique por dos la ventana de backup, pero desde luego, se incrementará.
El segundo, y quizá no tan evidente, es la carga extra que supone para los ESX subyacentes. En un entorno CDP (Continuous Data Protection) donde no existe ventana de backup, sino que cada cierto tiempo hacemos un backup transaccional de las máquinas virtuales (por ejemplo, una base de datos donde realizamos un respaldo de logs cada dos horas), la carga de ese proceso (que obliga a la VM a ratios de IO altos cada cierto tiempo, nos obliga a tenerlo en cuenta a la hora de asignar recursos extra de IO de disco y CPU para asumir la carga extra que supone el backup mientras el servidor da servicio a los usuarios. Evidementemente, una planificación correcta a la hora de diseñar nuestra infraestructura virtual debería darnos respuesta a esta situación. En lo referente al uso de red en un entorno de backup, poco podemos hacer, exceptuando quizá el dedicar un virtual switch para el backup - y consecuentemente una tarjeta de red extra en cada VM. ESX no está diseñado para cargas de red extremas (como la que supone un backup), así que esta situación puede alargar los tiempos de backup y, en caso de que este se "salga" de la ventana, afectar a la operación de las VM y los servicios asociados.
En tercer lugar, no debemos olvidarnos de realizar copias de seguridad de la configuración del ESX y de nuestras VM. ESX no es precisamente una plataforma fácil de configurar a mano, y en caso de caída, parametrizarlo "by hand" es una labor tediosa. Una copia del directorio /etc debería bastarnos para recuperar nuestro ESX, y otra de los archivos *.vmx, *.vmxf y *.nvram de nuestras VM. De esta manera, recuperar un ESX no debería ser más complicado que recuperar el /etc, los ficheros de configuración de las VM y registrarlas de nuevo con un comando del tipo:
/usr/bin/vmware-cmd -s register /vmfs/volumes/nombre VMfs/máquina virtual.vmx
Evidentemente, los textos en cursiva y rojo se corresponderán con los datos de cada VM en particular.
Bueno, de esta manera parece que tenemos solucionada la papeleta del backup de nuestro entorno virtual, protegiéndolo contra las contingencias habituales en un entorno físico... pero ¿Corremos los mismos riesgos en un entorno físico que en uno virtual?
Aparentemente sí. Cuando un servidor cae, lo reinstalamos, restauramos el backup y listos. Si se pierde el almacenamieto (por ejemplo, nuestra SAN queda inaccesible), pues rearrancamos los servidores, reconfiguramos la conexión a la SAN reparada, restauramos la copia y a seguir con lo nuestro. Pues no. Si perdemos el almacenamiento donde están nuestras VM (Corrupción de datos, caida temporal del mismo), los discos de arranque de nuestras VM dejarán de estar disponibles, lo que quizá nos oblige a reinstalar de nuevo las máquinas virtuales. Y eso, en un entorno donde las VM han superado ampliamente a las físicas puede resultar inoperante.
Como parte de la estrategia de backup tradicional, hay quien utiliza software de recovery de servidores, que nos permiten restaurar desde el metal el servidor mediante un CD, un arranque PXE, etc. Aún siendo una alternativa de gran valor, no está ampliamente extendida dado su coste y el hecho indiscutible de que no siempre es posible sacar una imagen de un servidor.
Una aproximación inmediata al problema de sacar backups de nuestras VM puede pasar por un backup incremental diario de nuestros VMFS, con su correspondiente full semanal, integrando nuestros ESX dentro de la estructura de backup existente. Eso será posible, evidentemente, si disponemos de suficiente capacidad de cinta u otros dispositivos para almacenar unos diferenciales diarios enormes (Hay que tener en cuenta que el vmdk cambia diariamente - y mucho - Carpetas temporales, archivo de swap (¿recordáis mis templates con el swap y Temp. Separados?) por no incluir lo que tengamos ejecutándose dentro de esa VM).
Si no disponemos de un entorno de backup que maneje los diferenciales a nivel de bloques, tendremos que asumir que cada backup incremental es, en realidad, un full backup.
Un ejemplo claro es VERITAS que, en su configuración básica copia ENTEROS los ficheros modificados. Esto, evidentemente, alargará nuestras ventanas de backup, y hará que nuestro consumo de cintas o similar se incremente enormemente. Sin embargo, en entornos pequeños y/o limitados, puede ser una solución.
Dejo una pregunta en el aire: ¿Nos vale de algo, a efectos de funcionalidad y gestión, una imagen de una VM de hace 1 mes? Espero respuestas.
Existen en el mercado varias soluciones de backup y restore de VM. Unos, como VMware Centralized Backup, suministran una interface para acceder directamente tanto al VMDK como al contenido del mismo de manera transparente y sin necesidad de ventana de backup, actuando como “proxy” para el backup tanto de los contenidos de los VMDK como de los VMDK en si.
Sin ánimo de hacer una descripción del producto, este gráfico ilustra el modo de operación de VMware Centralized Backup. Nótese que VCB NO supone carga para los ESX, aspecto de vital importancia en entornos con uso mantenido alto, y que, a mi parecer, hace las cosas como deben ser hechas: ESX a virtualizar, no a gestionar backups.
Otras, como ESX Ranger, van algo más allá: Fuerzan un snapshot usando VSS (Volume Shadow service) de Windows 2003 para forzar una imagen consistente (Point in time) y, posteriormente, realizar una copia con posterior compresión.
Como en el caso anterior, esta imagen ilustra su funcionamiento.
Recuperación de desastres.
Pero… ¿qué pasa si lo que necesitamos es recuperar todo nuestro entorno en cuestión de horas. La recuperación de un full backup no me parece la respuesta adecuada. En estos entornos, la replicación de los VMFS aparece como única opción viable. El poder replicar una gran cantidad de datos (como la mencionada en los apartados anteriores) no es, en sí, el mayor de los problemas con el que nos enfrentamos. A mi parecer, que la réplica de esos datos sean entendibles por los ESX de destino como válidos sin intervención manual es, sin duda, el mayor de los problemas. Con esto quiero decir que si confiamos en la capacidad de replicación de nuestras cabinas de disco para una rápida recuperación de desastres, como dicen en mi pueblo, vamos aviados. No será el primer caso que veo en que los ESX de destino se niegan a considerar válidos unos VMFS replicados, obligando a unas cuantas horas de intensivo y aterrador trabajo de re-registro manual de VMFS y VMs.
Conozco incluso un caso, gracias a mi querido Josep Ros, de una fastuosa replicación entre cabinas SUN realmente estrepitosa.
Cuidado con lo que nos venden: que nos lo enseñen primero.
Vizioncore nos ofrece un producto, vReplicator que permite la replicación a nivel de host y que el siguiente gráfico ilustra:
Esta solución, a pesar de ser efectiva, desde mi punto de vista tiene un solo problema: hace trabajar a los host ESX en algo que no es lo suyo. El cálculo de diferenciales en entornos multiterabit puede ser un gran consumidor de recursos que yo, personalmente, prefiero dedicar a mis VM. No dejéis de probarlo si tenéis ocasión.
Otras soluciones como el MetroCluster de Network Appliance, que suministran entornos de alta disponibilidad y recuperación de desastres me resultan más elegantes y, sobre todo, cumplen con mi premisa principal: Son transparentes para los ESX, liberando a las CPU de estos de la carga inherente a la replicación.
Otra aproximación interesante viene de la mano de Topio, una compañía adquirida por NetApp a finales del 2006, y cuyas soluciones mi estimado Jose me ha mostrado recientemente.
ReplicatorX no es un producto especialmente diseñado para Máquinas virtuales, pero es perfectamente aplicable. ReplicatorX Intercepta todas las peticiones de IO de una VM (o un servidor físico con linux, Windows, AIX, Solaris o demás) y las envía a un servidor espejo. Viene a funcionar como un raid entre el disco de la máquina cliente y el disco de la máquina destino…. A través de TCPIP. Os dejo, como no, gráfico explicativo. Echadle un ojo.
Y ahora la pregunta del millón: ¿Qué pasa si replicamos un error?
Bueno… y hasta aquí por hoy…. Prometo la segunda parte en breve.
Un abrazo.
