Supongo que en algunos de los departamentos de TI, el enunciado de este post parecerá algo irrelevante. Desafortunadamente, las personas que trabajamos en servicios a clientes, tenemos que enfrentarnos a problemáticas que no han sido debidamente evaluadas cuando se han decidido cambios estratégicos como la adopción de una infraestructura virtual, transicionando desde entornos típicamente físicos (llamémosles tradicionales).
La sobresuscripción de los enlaces de red son un caso típico de deficiente planificación en el despliegue de Máquinas Virtuales (VMs) con VMWare, pero puedo imaginar que con Xen o Hyper-V, por la naturaleza de la arquitectura y la propensión al uso de sistemas blade en estos proyectos, los problemas son similares.
No es mi foco de atención hoy el networking, aunque no por ello es menos importante. Pero en este post me centraré en los problemas derivados de la realización de copias de seguridad en infraestructuras virtuales. Como dije anteriormente, la imagen que se proyecta de las soluciones de virtualización durante las fases de preventa, tienen mucho que ver con las sorpresas que surgen al poco tiempo de comenzar la fase de producción de la nueva arquitectura. Pero no sería justo responsabilizar de esto sólo a los vendedores de soluciones, porque los usuarios de las mismas imponen en muchas ocasiones ciertos criterios que son solamente fruto del desconocimiento y la falta de experiencia en la plataforma.
La frase que más se ajusta al sentido de lo que quiero decir, es algo así como: "Bueno, al fin y al cabo tenemos que respaldar servidores, y eso ya sabemos hacerlo". Pues bien, a pesar de ser cierta, es sólo un sofisma, porque no sólo se trata de "respaldar servidores" como ya saben hacer, el problema es hacerlo en condiciones diferentes de como se ha hecho hasta ahora: ahora hay una infraestructura virtualizada. Este hecho implica cambios sustanciales en la estrategia a emplear. Veamos lo que subyace entre líneas cuando se habla del backup de VMs.
EL BACKUP TRADICIONAL
En el esquema (a excepción de la parte señalizada como "storage cloud", que ignoraremos por el momento), observamos varios servidores conectados a un segmento de LAN, en el mismo segmento, un servidor que contiene los medios de almacenamiento secundario adecuados realiza el respaldo.
Por supuesto que habrá variaciones sobre éste esquema, fundamentalmente la conexión de servidores a SAN y el uso de una LAN exclusiva para los procesos de respaldo, a medida que el volumen de backup crece y la ventana disminuye.
Pero básicamente el esquema puede ser válido para describir una situación previa al despliegue de soluciones virtuales.
La solución consiste en un agente instalado en el servidor que será respaldado, que opera bajo instrucciones y scheduling del servidor de backup, y que transfiere sus datos al mismo para que sean grabados, generalmente en medios removibles (librerías LTO, autochangers, etcétera) o disco. El proceso requiere ciclos de cpu, memoria y recursos de I/O. Pero ninguno de estos problemas son realmente graves en una infraestructura física donde el uso promedio de los recursos es muy bajo. De hecho la virtualización tiene un importante impulsor en la infrautilización de recursos de las infraestructuras tradicionales como argumento. Generalmente el respaldo no suele ser problemático, si el volumen del mismo no está gravemente penalizado por la lentitud de la red o una mala parametrización (escasez de recursos no asociados a la arquitectura de los servers).
LA DIFERENCIA VIRTUAL
Bien, ahora hemos decicido que nuestro nuevo datacenter será virtual, seleccionamos un HiperVisor y nos ponemos a ello. Convertimos servidores con P2V, creamos plantillas, desplegamos con un leve chasquido de dedos seis servidores nuevos... es tan barato y fácil hacerlo que casi resulta placentero. Llega el momento de la producción et...voilá: Houston, tenemos problemas.
En primer lugar, hemos pasado de emplear recursos físicos, exclusivos, a emplear recursos físicos compartidos ¿ recuerdan, señores usuarios, que precisamente era la mejor utilización de los recursos uno de los argumentos ?. Pues bien, como queríamos conseguir, hemos pasado de una utilización media del 20-30% de los recursos del servidor físico a una utilización media del 85%. Enhorabuena. Ahora apenas quedan recursos de cpu, memoria e I/O para el backup. Lo cual me recuerda a su vez que la sobresuscripción de los enlaces de red también disminuye la velocidad de transferencia, lo que a su vez hace que las cintas, al ser grabadas, repitan incesantemente ese incómodo movimiento de shoe-shine (no tienen masa crítica de datos suficiente a través de la red que llene sus buffers), lo que a su vez ocasiona el desastre: nos hemos quedado fuera de la ventana de backup. Pero que muy fuera. Aquí está el por qué explicado gráficamente:
Y todo ello a pesar de saber cómo se respalda un servidor, hecho que jamás pretendería discutir.
El resultado final de esta historia es que el usuario se enfrenta a un dilema bastante incómodo: o bien expande su ventana de backup, cosa que cada vez es menos posible por la tendencia a ofrecer servicios 7x24 a los usuarios finales, o se renuncia a virtualizar algunos servidores, lo que implica que no podrán beneficiarse de todas las ventajas de la virtualización. Después de una ardua venta interna para conseguir los recursos económicos para emprenderla, supone un golpe tremendamente duro.
La virtualización supone una importante proliferación de servidores en el datacenter, lo que incrementa el volumen del backup, disminuye los ciclos de CPU disponibles para realizarlo y hace ineficiente la estrategia habitual de respaldo.
¿Debe entonces rechazarse la virtualización? por supuesto que no. Entonces ¿Cual es la solución?.
Trataremos esto en próximas publicaciones.
I miss it and I look forward to a day when I myself no longer have a computer tied to my hind quarters right along with the cell phone. I am not condemning these things, just stating what they are, "convienences". Just like anything else.
Posted by: Buy Online Rx | October 14, 2010 at 06:06 PM