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;
Mostrando entradas con la etiqueta backup. Mostrar todas las entradas
Mostrando entradas con la etiqueta backup. Mostrar todas las entradas
domingo, 7 de octubre de 2007
jueves, 27 de septiembre de 2007
VI, Almacenamiento y Backup - I
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
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.
sábado, 13 de enero de 2007
Caso Práctico: Virtualización de entorno de Producción - Infraestructura Virtual
Pasadas las fiestas, turrones, pavos y similares, y el consecuente bebercio, parece que ya salgo de la resaca, así que al tajo.
Vamos a retomar el caso práctico que nos planteábamos en el post anterior, donde pretendíamos virtualizar parte de un entorno de producción. Tras la definición del ámbito del proyecto, pasemos a definir la infraestructura virtual necesaria.
Servidores físicos.
en el ejemplo que nos ocupa, se pretende virtualizar un total de 31 servidores. Hemos de tener en cuenta que todas estas máquinas dependerán de la integridad de los servidores ESX, con lo cual la tolerancia a fallos ha de ser una premisa del diseño de la instalación.
En el caso que nos ocupa, el planteamiento inicial implica la instalación de dos servidores ESX. Ese es un escenario económico y altamente rentable, que sacrifica rendimiento y tolerancia a fallos en pro de la economía. Intentaremos dibujar otros dos posibles escenarios, que balanceen mejor las prestaciones, la tolerancia a fallos y los costes.
Dos servidores, si... ¿Pero con qué configuración?
nº de procesadores.
VMware (y yo, basándome en la experiencia) recomienda no superar las 8 máquinas virtuales por procesador. Esto ha de tomarse como una norma general con múltiples excepciones: No es lo mismo 8 servidores SQL en cluster que 8 servidores web... de hecho, yo mismo he virtualizado hasta 13 servidores por CPU con rendimientos aceptables. También es importante definir los requerimientos de los entornos virtualizados: No tenemos porqué tener el mismo rendimiento en Desarrollo que en los sistemas de producción... y un RADIUS no requiere lo mismo que un SQL server.
En este caso, yo me inclinaría por servidores biprocesador con dual core, más que por sistemas tetraprocesador. VI3 es uno de los pocos entornos donde las ventajas del crecimiento horizontal son realmente palpables. Recordemos que VI3 nos permite hacer crecer nuestra infraestructura virtual añadiendo nuevas máquinas. Una instalación como la que nos ocupa puede comenzar con dos máquinas y crecer sin que por ello la inversión realizada inicialmente quede obsoleta.
Evidentemente, han de distribuirse los recursos de toda la infraestructura virtual de acuerdo con los requerimientos de cada servidor: Balancear entre distintas CPUs las máquinas con más carga (o requerimientos), un buen diseño de los pools de recursos, y un diseño adecuado de la infraestructura de almacenamiento.
Partiendo de esta base, las máquinas que nos ocupan deberían ir equipadas con dos procesadores dual core, lo que nos daría un total de 8 cores.
En el ejemplo que nos ocupa, nuestra infraestructura virtual soporta (teóricamente) hasta 64 máquinas virtuales (8 por core)... una estimación más realista, teniendo en cuenta que en caso de pérdida de servicio de uno de los servidores ESX (ya sea por incidencia o por trabajos planificados de mantenimiento), nos debería permitir mantener en funcionamiento, al menos, el cincuenta por ciento de los servidores virtuales. Una buena fórmula de cálculo deberia ser la siguiente: Nº de VM/8+(12) CPUs (El OR dependerá de la pasta que tengamos)
Memoria.
La respuesta es fácil: La máxima posible. ESX es, por definición, un gran consumidor de memoria. Apurar al máximo las capacidades de ahorro de memoria del VMware no es una buena idea en entornos de producción. Hemos de tener en cuenta que ESX, por muy maravilloso producto que sea, no es capaz de predecir las necesidades de memoria que una VM tendrá dentro de un segundo. Una buena fórmula de cálculo de la memoria total requerida para nuestra infraestructura virtual es asumir entre 768Mb y 1 Gb por máquina virtual.... lo que no quiere decir que definamos todas nuestras VM con 768Mb o 1 Gb de RAM. Hay un consumo "extra" de memoria por parte de la capa de virtualización... Calculemos aproximadamente entre 512 y 1Gb de consumo de RAM para el ESX.
Red.
La red es otro elemento fundamental en VI3. VI3 ha de suministrar conectividad de red a las máquinas virtuales que aloja, por lo que deberíamos garantizar tanto el ancho de banda como la tolerancia a fallos de la misma. LA red, tradicionalmente, suele ser una gran olvidada en los entornos de proceso de datos: Se compra, se instala y punto. Al ser uno de los sistemas más robustos de toda la infraestructura IT, suele relegarse a esa categoría de sistemas que "nunca fallan", asi que, consecuentemente, nunca se tocan.
VI3 requiere de electrónica de red eficiente, y una configuración adecuada. Mi personal consejo es tirar de electrónica de rendimiento contrastado y con potentes opciones de configuración. En mi caso, utilizo una pareja de Cisco Catalyst 3750.
Por contra, el uso de Ethernet como medio de acceso al almacenamiento nos ofrece múltiples ventajas: Trunking de hasta 8 canales gigabit Ethernet, cifrado IPsec estándar, autenticación en base a usuario/password, VLAN's (frente a las zones FC, que son un infierno), y todos los mecanismos ya implementados sobre Ethernet: redundancia, autenticación en conexión (802.1x), y opciones avanzadas de monitorización como el sniffing.
Desde el punto de vista de costes y versatilidad, iSCSI también nos ofrece ventajas, al convertir cualquier puerto de red en un punto de acceso al almacenamiento en potencia. Además, el coste de un puerto ethernet de 1 Gbit/sec, incluso en equipos de gama alta, no llega a la mitad del coste final de un puerto FC.
Tema importantillo... ¿qué licencia adquirir?. Veamos qué nos ofrece VMware.
Vamos a retomar el caso práctico que nos planteábamos en el post anterior, donde pretendíamos virtualizar parte de un entorno de producción. Tras la definición del ámbito del proyecto, pasemos a definir la infraestructura virtual necesaria.
Servidores físicos.
en el ejemplo que nos ocupa, se pretende virtualizar un total de 31 servidores. Hemos de tener en cuenta que todas estas máquinas dependerán de la integridad de los servidores ESX, con lo cual la tolerancia a fallos ha de ser una premisa del diseño de la instalación.
En el caso que nos ocupa, el planteamiento inicial implica la instalación de dos servidores ESX. Ese es un escenario económico y altamente rentable, que sacrifica rendimiento y tolerancia a fallos en pro de la economía. Intentaremos dibujar otros dos posibles escenarios, que balanceen mejor las prestaciones, la tolerancia a fallos y los costes.
Dos servidores, si... ¿Pero con qué configuración?
nº de procesadores.
VMware (y yo, basándome en la experiencia) recomienda no superar las 8 máquinas virtuales por procesador. Esto ha de tomarse como una norma general con múltiples excepciones: No es lo mismo 8 servidores SQL en cluster que 8 servidores web... de hecho, yo mismo he virtualizado hasta 13 servidores por CPU con rendimientos aceptables. También es importante definir los requerimientos de los entornos virtualizados: No tenemos porqué tener el mismo rendimiento en Desarrollo que en los sistemas de producción... y un RADIUS no requiere lo mismo que un SQL server.
En este caso, yo me inclinaría por servidores biprocesador con dual core, más que por sistemas tetraprocesador. VI3 es uno de los pocos entornos donde las ventajas del crecimiento horizontal son realmente palpables. Recordemos que VI3 nos permite hacer crecer nuestra infraestructura virtual añadiendo nuevas máquinas. Una instalación como la que nos ocupa puede comenzar con dos máquinas y crecer sin que por ello la inversión realizada inicialmente quede obsoleta.
Evidentemente, han de distribuirse los recursos de toda la infraestructura virtual de acuerdo con los requerimientos de cada servidor: Balancear entre distintas CPUs las máquinas con más carga (o requerimientos), un buen diseño de los pools de recursos, y un diseño adecuado de la infraestructura de almacenamiento.
Partiendo de esta base, las máquinas que nos ocupan deberían ir equipadas con dos procesadores dual core, lo que nos daría un total de 8 cores.
En el ejemplo que nos ocupa, nuestra infraestructura virtual soporta (teóricamente) hasta 64 máquinas virtuales (8 por core)... una estimación más realista, teniendo en cuenta que en caso de pérdida de servicio de uno de los servidores ESX (ya sea por incidencia o por trabajos planificados de mantenimiento), nos debería permitir mantener en funcionamiento, al menos, el cincuenta por ciento de los servidores virtuales. Una buena fórmula de cálculo deberia ser la siguiente: Nº de VM/8+(12) CPUs (El OR dependerá de la pasta que tengamos)
Memoria.
La respuesta es fácil: La máxima posible. ESX es, por definición, un gran consumidor de memoria. Apurar al máximo las capacidades de ahorro de memoria del VMware no es una buena idea en entornos de producción. Hemos de tener en cuenta que ESX, por muy maravilloso producto que sea, no es capaz de predecir las necesidades de memoria que una VM tendrá dentro de un segundo. Una buena fórmula de cálculo de la memoria total requerida para nuestra infraestructura virtual es asumir entre 768Mb y 1 Gb por máquina virtual.... lo que no quiere decir que definamos todas nuestras VM con 768Mb o 1 Gb de RAM. Hay un consumo "extra" de memoria por parte de la capa de virtualización... Calculemos aproximadamente entre 512 y 1Gb de consumo de RAM para el ESX.
Red.
La red es otro elemento fundamental en VI3. VI3 ha de suministrar conectividad de red a las máquinas virtuales que aloja, por lo que deberíamos garantizar tanto el ancho de banda como la tolerancia a fallos de la misma. LA red, tradicionalmente, suele ser una gran olvidada en los entornos de proceso de datos: Se compra, se instala y punto. Al ser uno de los sistemas más robustos de toda la infraestructura IT, suele relegarse a esa categoría de sistemas que "nunca fallan", asi que, consecuentemente, nunca se tocan.
VI3 requiere de electrónica de red eficiente, y una configuración adecuada. Mi personal consejo es tirar de electrónica de rendimiento contrastado y con potentes opciones de configuración. En mi caso, utilizo una pareja de Cisco Catalyst 3750.
En este ejemplo hemos de tener en cuenta las siguientes conexiones de red:
Red de VM
Dedicaremos, al menos, dos enlaces Gigabit por servidor ESX para el tráfico de las máquinas virtuales. Esta duplicidad no viene dada tanto por el ancho de banda como por tolerancia. Recordemos que, con 31 VMs en dos máquinas, cada tarjeta de red da servicio a 15 VMs.
Almacenamiento
Tanto si usamos iSCSI como FC, el enlace ha de estar redundado. Si existe algún componente crítico, este es el acceso al almacenamiento. Añadiremos otras dos conexiones para el almacenamiento. es importante que NO COMBINEMOS iSCSI y NFS sobre la misma red. Si pensamos en utilizar iSCSI y NFS a la vez, debemos utilizar interfaces distintas.
VMotion/HA
Aquí, dependiendo de si usamos VMotion, o VMotion y HA, podremos dedicar una o dos tarjetas por máquina. Si sólo utilizamos VMotion para el movimiento de VMs entre servidores, una tarjeta debería ser suficiente, pero si implementamos HA, este enlace se hace crítico.
Consola.
La conexión de consola es la que nos permitirá acceder a los servidores ESX tanto directamente como a través de VirtualCenter, con lo cual, su criticidad es relativa. Me explico. Si un ESX deja de ser gestionado por VC, no se para, lo que significa que no supone un impacto en la operatividad del sistema. En otras palabras, si cae la consola, tendremos tiempo de maldecir, ponernos la chaqueta, salir a por un cigarrillo y hasta tomar un café antes de ir al CPD porque las VM no se han parado. Yo no suelo dedicar una tarjeta específica para la consola, así que suelo añadir una VLAN, ya sea en VMotion o en las VM, para la consola, pero una interface de 100 Mbit/sec no parece a priori un desembolso excesivo, salvo que no tengamos splot PCI libres.
Como resumen, no escapamos con menos de 6 conexiones de red por servidor.... aunque 8 tampoco es un mal número.
Miscelánea.
Cosas interesantes que debería tener nuestro servidor ESX perfecto:
- Consola remota: Si, lo de tener que ir al CPD es pelín incómodo, y además, podemos resfriarnos.
- Remote Power On/Off: Más de lo mismo.
- Disco de arranque en Mirror: Vaya que si nos gastamos una pasta en almacenamiento para VMFS y después los ESX no arrancan porque se nos ha cascado un disco nos va a lucir el pelo.
Almacenamiento.
Siempre he apostado por el uso de SAN para VMware. El uso de un almacenamiento compartido nos abre inmensas posibilidades bajo VI3: La capacidad de movimiento de máquinas virtuales entre ESX's, mayor racionalidad en el uso de almacenamiento, y el coste cada vez más bajo de este tipo de soluciones me parecen razones más que suficientes.
Pero no debemos olvidar la opción NFS que nos brinda ESX. NFS no nos va a dar, ni de lejos, el rendimiento de una SAN FC o iSCSI, pero se plantea como una solución económica para el almacenamiento de Templates, imágenes ISO, etc... y para eso podemos utilizar el espacio de nuestro servidor de ficheros Windows mediante productos gratuítos como el Windows Service for Unix, que nos permite compartir una carpeta de nuestro servidor de ficheros como un share NFS. Creedme... por muy grande que hayamos diseñado nuestra LUN para VMware, siempre, siempre, se nos quedará corta.
En mi caso particular, siempre he preferido iSCSI a FC, tanto por razones de coste como de sencillez y simplicidad de configuración. Una instalación FC requiere, además de las HBA FC (a un buen pico cada una, casi 2000€), hemos de tener en cuenta los switches (los minihubs que incorporan algunos fabricantes no son demasiada buena idea), el multipathing o capacidad para que un host vea una LUN por dos controladores FC y no las gestione como dos LUNS, o el trunking (agrupar dos o más canales FC para que actúen como uno solo) suelen tener un coste adicional. (de hecho, siempre he recomendado a los fabricantes de equipamiento FC que incorporen ya el lector de Visa en sus equipos, dado que para hacer casi cualquier cosa hace falta una licencia). También FC es más lioso de gestionar y configurar, y el conocimiento suele ser específico para cada equipo.
iSCSI ofrece menor rendimiento (unos 800-850 Mb/sec teóricos en enlace de un GbE frente a los 900-950 Mbit/sec de un enlace FC), consumen más recursos de la máquina en el caso de iniciadores software (es la CPU del host la que ha de pelearse con el TCP/IP y los comandos SCSI3), pero en una instalación pequeña (llamo pequeña hasta 6 - 10 servidores conectados a un target iSCSI) el diferencial de rendimiento no suele apreciarse.
Por contra, el uso de Ethernet como medio de acceso al almacenamiento nos ofrece múltiples ventajas: Trunking de hasta 8 canales gigabit Ethernet, cifrado IPsec estándar, autenticación en base a usuario/password, VLAN's (frente a las zones FC, que son un infierno), y todos los mecanismos ya implementados sobre Ethernet: redundancia, autenticación en conexión (802.1x), y opciones avanzadas de monitorización como el sniffing.
Desde el punto de vista de costes y versatilidad, iSCSI también nos ofrece ventajas, al convertir cualquier puerto de red en un punto de acceso al almacenamiento en potencia. Además, el coste de un puerto ethernet de 1 Gbit/sec, incluso en equipos de gama alta, no llega a la mitad del coste final de un puerto FC.
Backup.
Algo que se suele tender a olvidar en los entornos VMware es que hay que sacar copias de las VM. Aquí tenemos dos posibles aproximaciones: Copia individual de cada máquina virtual, o copia total de la infraestructura virtual.
Evidentemente la segunda opción, el sacar una copia del VMfs donde tengamos almacenadas las VM puede parecer la mejor opción: Pocas LUN que copiar y un agente por servidor ESX, pero hay que tener en cuenta otro aspecto ciertamente importante.
Veritas, Legato y demás permiten la realización de copias diferenciales o incrementales, es decir, sólo copian los ficheros que han cambiado desde el último backup total o desde el último incremental realizado. Esto nos permite disminuir las ventanas de backup y ahorrar en disco. Si aplicamos esta filosofía a VMware nos encontraremos con la lindeza de que cada backup diario es, en realidad, un full backup. ¿Porqué? porque los discos virtuales, los vmdk son un fichero.... que cambia cada vez que el SO virtualizado está encendido. Así que el backup de, digamos, 600Gb de VMfs (no, no os asustéis, se llega con facilidad), nos obliga a disponer de .. 4.2Tb de espacio de backup.... por semana.
El uso de snapshots ("fotos" del disco que se pueden mantener a intervalos programables y que pueden ser revertidas), también puede parecer una hermosa solución... si no fuera por un par de detalles. En primer lugar, ningún sistema operativo trabaja directamente con el disco, así que si en un momento dado "congelamos" el disco, es probable que la mitad de los datos estén en la memoria del sistema operativo virtualizado y no en el disco. Esto es lo que se llama un punto de consistencia. Lo ideal sería poder decirle al SO que hiciese un flush antes de que nosotros ordenemos un snapshot del VMfs... es teóricamente posible (un buen sync bajo linux y alguna chapuza bajo windows).... pero ¿Y las aplicaciones?. Oracle o SQL server van por su lado. Un flush del sistema operativo no tiene porqué obligar a SQL, Oracle o Exchange (por poner ejemplos) a volcar todas las transacciones pendientes. Un snapshot en estas condiciones no vaticina nada bueno. Esto es lo que los gurús del backup llaman "Punto de consistencia", es decir, el estado de un servidor (aplicación incluída) en el que el backup es realmente una imagen consistente del sistema.
Para más INRI, algunas tecnologías de snapshot a nivel de LUN hacen cosas realmente graciosas: NetApp, por ejemplo, te "sugiere" reservar X * 2 espacio para el primer snapshot... siendo X el tamaño estimado de la LUN...
Cuando trabajaba con ESX 1.x y 2.x y se me apareción este problemilla, la única solución que se me ocurrió fué hacer un script que suspendiera una VM, sacara backup del disco y del fichero de suspensión (importante, de ahí la negrita), y volviese a hacer un power on.
Con VI3, VMware introduce el VMware Consolidated Backup. VCB permite el backup de las máquinas virtuales sin parada, de manera incremental y a nivel de fichero individual contenido en una VM. Se basa en la existencia de un Backup Proxy, un servidor Windows que accede a las LUNs de VMfs y es capaz de hacer un snapshot consistente de nuestras VM, que extraeremos con nuestro software de copias de seguridad preferido, es decir, sobre este servidor montaremos nuestro agente de Veritas, Legato o lo que tengamos, y VCB se encargará del resto. Esto es lo bonito. Lo feo es que requiere de unas configuraciones la mar de entretenidas, sólo funciona con FC y hay que hacer alguna pirindola para que se hable con el agente de backup. Por el momento estoy en fase de prueba del mismo, así que poco os puedo decir aún. Si antes de que termine con este caso práctico acabo la evaluación, incluiré la configuración... si no, ya tengo tema para otros post.
Tema importantillo... ¿qué licencia adquirir?. Veamos qué nos ofrece VMware.
Dejando aparte, oh cielos, opciones como el Consolidated Backup, nadie que conozca que haya probado vMotion es capaz de vivir sin él. Conozco casos de quién ha licenciado un VI3 standard, y a la hora de licenciar vMotion y demás, se ha llevado la grata sorpresa del latigazo consecuente que VMware ha tenido a bien darle. Para un entorno como el descrito, os recomiendo encarecidamente licenciar enterprise. VMware licencia por CPU física, lo que quiere decir que en nuestro caso, sólo hemos de licenciar 4 procesadores... para nuestra flamante instalación de 8... o de 16, con los quad de Intel en puertas.
Resumen de la instalación.
Servidores.
Dos máquinas dual core bi-procesador con 8 tarjetas de red, disco RAID, doble fuente de alimentación y 16 Gb de RAM.
Equipo Ejemplo.
Servidores: SUN X4100
Tarjeta de red: Intel® PRO/1000 GT Quad Port Server Adapter, Broadcom NetXtreme® Gigabit Ethernet Controller for Servers
iSCSI HBA's: Qlogic QLA4052
Nota: Ojito. El soporte para iSCSI HBA está todavía en fase experimental.
Almacenamiento.
Deberíamos disponer de, al menos, 600 Gb NETOS para nuestra instalación... mi consejo es que compréis algo que escale, al menos, hasta 3 veces esa cantidad.
iSCSI: NetApp FAS270c, NetApp FAS3000, para pruebas y/o preproducción o pequeños entornos, Openfiler, FalconSTOR IPStor, como prueba de concepto, StarWind iSCSI Target.
FC: Las anteriores junto con cualquier solución soportada por VMware.
NFS: NetApp, obviamente, o cualquier producto que sirva NFS... Microsoft Windows Services for Unix
Electrónica de red.
De los 48 puertos no deberíamos bajar, por aquello de no quedarnos cortos y no tener que empezar a "empalmar" switches con uplinks a giga. Si sois de los afortunados que ya tenéis un chasis mediano o grande (un Catalyst 4500, 6000 o un Nortel Passport o similar), provisionad puertos suficientes... si debéis adquirir electrónica, os recomiendo os vayáis a un chasis pequeño, o en su defecto a cualquier switch modular que soporte stacks de alta velocidad. Eso sí, procurad que tenga la opción de la fuente de alimentación rendundante.
Cisco Catalyst 3750-40 TS o superior... un backplane de, al menos 32 Gbit/sec.
Licencias VMware.
Licencia VI3 Enterprise para 4 Procesadores.
Seguiremos hablando.
J. L. Medina
Suscribirse a:
Comentarios (Atom)