h1

Virtualización: Qué es, para qué sirve y cómo funciona

11/27/2008

Wizdoc [Icon By Buuf]  Tips & Tricks.

Tal vez usted desea conservar una vieja aplicación, pero sólo puede funcionar con Windows NT. Usted no quiere mantener un servidor NT sólo para esta aplicación, así que prefiere correr una instancia de NT montada en un Microsoft Server 2003, usando software de virtualización.

— Brad Grimes, Joab Jackson, The future of virtualization, Agosto 2006.

Hasta hace poco la forma más común de utilizar los recursos del site o datacenter de una empresa había sido la de asignarle una máquina, disco, nodo de red e IP a cada servicio o solución.

Foto de un site desordenado

Un site "legado": todo desordenado y con una máquina por aplicación.

Sin embargo, con los cada vez más altos costos de energía así como una mayor atención a temas ambientales, los CIOs de muchas de estas empresas se han dado cuenta que es poco rentable seguir creciendo así, y menos aún mantener equipos viejos que consumen al menos 350 Watts, y que equivalen a unos MX$ 8,195.42 o 1,318 Kg de CO2 en nuestra atmósfera por año. Adicionalmente, en tiempos como estos de crisis económica, es indispensable disminuir los costos y rascar algún ahorro de donde se pueda.

Una de las soluciones más usadas para resolver este tipo de problemas es la consolidación de servidores: de acuerdo al número de equipos y su uso de CPU, memoria y espacio en disco podríamos correr más de una aplicación en un mismo servidor y ahorrar costos de energía, nodos de red e incluso espacio en el site. Claro que, esta tarea conlleva ciertos obstáculos que podrían frenar cualquier intento al respecto:

• Por principio, tener dos aplicaciones corriendo en un mismo ambiente implica que si una tira al servidor, la otra también se cae, provocando problemas de inestabilidad y disponibilidad.

• Como extensión del apartado anterior, es indispensable garantizar una distribución equilibrada de recursos entre unas y otras aplicaciones. Por ello, es inaceptable que una aplicación siempre consuma el 100% del ancho de banda de red, impidiendo que las demás funcionen correctamente, pues esto es equivalente a autogenerarnos un ataque de Denial Of Service.

• Se deben tomar en cuenta temas de operación de sistemas. El ejemplo más común es la aplicación de parches: supongamos que una aplicación requiere del "fix 99585" para correr eficazmente, pero justamente este parche hace que la otra aplicación se empiece a chocolatear.

• Finalmente, temas de política que pueden provocar conflictos inter-departamentales: si una aplicación se cae y tira a la otra, ¿de quién es la culpa? ¿De la primera por afectar a la segunda o de la segunda por ser tan inestable que "se dejó tirar"? Este último escenario es común incluso en aplicaciones corriendo en diferentes contextos pero que conviven en la misma máquina, como las soluciones web al generar los temidos OutOfMemoryError.

Siendo así las cosas, ¿existe alguna manera de facilitar de manera transparente la consolidación de los recursos de un site y ahorrarnos tiempo, dinero y esfuerzo, dicho sea de paso?

Compartiendo recursos

La respuesta la tenemos en la virtualización. Este término engloba muchos conceptos, incluyendo "virtualización de ambientes de trabajo", "enmascaramiento de recursos" o "emulación mediante máquinas virtuales". Sin embargo, para efectos de este post manejaremos la siguiente definición:

La virtualización es la abstracción de los recursos de un servidor, incluyendo el número e identidad de servidores físicos, procesadores y sistemas operativos de cara al usuario. El administrador utiliza un software con el que divide un servidor físico en múltiples ambientes virtuales. Estos ambientes virtuales son llamados servidores privados, particiones, clientes, instancias, contenedores o emulaciones.

What is server virtualization?, SearchServerVirtualization.com

En términos más terrenales, podemos entender la virtualización como el equivalente a tener varias instancias del sistema operativo en nuestra computadora, todas corriendo al mismo tiempo con sus respectivas aplicaciones y con asignaciones independientes de cpu, memoria y disco. Esto por supuesto tiene varias ventajas que resuelven los retos de la consolidación descritos más arriba:

• Puesto que las particiones o contenedores son independientes unas de otras, en caso de caerse una de éstas no se afectará la disponibilidad de las demás. Por cierto, es necesario mencionar que la virtualización muestra mejor sus beneficios si el servidor donde se implementa posee recursos "compartibles": por ejemplo, 2 o más CPUs, DIMMS de memoria y discos – de preferencia, éstos últimos deberían ser externos.

• La virtualización garantiza la distribución de recursos ya sea de manera estática (por ejemplo, asignando ancho de red a un contenedor el 33% de la capacidad total) o dinámica (si un contenedor ocupa picos de 20% del ancho de banda, asignar dinámicamente el 80% restante a las demás particiones).

• De acuerdo al método de virtualización empleado (ver más adelante), los contenedores pueden tener diferentes niveles de parches e incluso diferentes sistemas operativos corriendo en un mismo servidor.

En los siguientes diagramas puede apreciarse el cambio de un ambiente "estándar" a uno virtualizado:

Arquitectura pre-virtualizacion
Una arquitectura pre-virtualización. Para este ejemplo, las tres bases de datos están subutilizando los recursos de sus respectivos servidores (por simplicidad, sólo consideramos el uso de CPU) por lo que es posible consolidarlas en un solo equipo.

Arquitectura post-virtualizacion
La misma arquitectura, consolidada con la ayuda de contenedores. Las tres bases de datos se encuentran físicamente en la misma máquina, pero cada una de ellas "vive" de manera independiente de las demás. Entre las tres consumen el 30% del CPU y disminuyen costos al facilitar la remoción de dos equipos.

Por otro lado, es importante mencionar algunos detalles a tomar en cuenta al implementar la consolidación y virtualización de servidores, para no encontrarnos con sorpresas:

• Se deben recabar las características de los servidores donde corren las aplicaciones, incluyendo detalles como las velocidades de los relojes de CPU y memoria así como de giro de los discos y se requiere un assessment – que normalmente puede ser realizado por el proveedor de hardware – para migrar correctamente estos ambientes. Por ello, si tenemos dos aplicaciones, una en un servidor con un Quad-Core a 1.5 GHz y otra en un servidor con dos CPUs Single-Core a 1 GHz, no es tan transparente pasarlo todo a un servidor 8-Core a 1.0 GHz: (4 x 1.5) + (2 x 1) != 8.

• Dependiendo del método de virtualización (como veremos más adelante), al virtualizar un ambiente hay que transformar instrucciones del sistema operativo virtualizado a instrucciones nativas del hardware sobre el que corre. Esto implica una carga u overhead que se presentará sobre los recursos utilizados que deberemos considerar.

• Por otro lado, también se debe verificar con los proveedores de las aplicaciones si existe un soporte sobre su software al estar virtualizado. Por ejemplo, Oracle RAC o Solaris Cluster son ciertamente soportados en un ambiente virtualizado, pero dicho soporte es relativamente reciente (Abril de 2008).

• Es importante recordar que la virtualización puede abrir muchos agujeros de seguridad que es necesario tapar. Un resumen de este tipo de amenazas se encuentra en el documento Virtual Machine Security Guidelines publicado por el Centro para la Seguridad en Internet (Center for Internet Security – CIS).

De esta manera, siguiendo ciertos lineamientos y buenas prácticas es posible lograr muy buenos resultados:

Cuando las compañías aplican la virtualización por primera vez, la proporción es de alrededor de 15:1 [contenedores o máquinas virtuales por servidor]. Después de un año esta proporción baja a 8:1 y después de tres años se estabiliza en una media de 3:1. Para dar cupo a 15 o 20 máquinas virtuales es un sólo servidor, la utilización de CPU de éstas debe ser de 5% a 8%. Esto representa equipos con baja o intermitente demanda de recursos: servidores de pruebas y desarrollo, pequeños web servers con muchas páginas estáticas, aplicaciones raramente usadas, etcétera.

Cómo funciona

Concretamente, existen tres maneras de virtualizar un hardware:

• La primera, denominada virtualización por contenedores, implica una solución de firmware que permite subdividir la memoria, CPU y disco de manera eficiente y con poco overhead, pero tiene un monto fijo en cuanto al número de instancias o cantidad de recursos que pueden ser compartidos. Adicionalmente, en muchos casos las instancias corriendo deben tener las mismas versiones de sistema operativo y nivel de parches.

• La segunda, facilitada mediante máquinas virtuales o dominios, es una solución netamente de software, donde el componente de gestión (denominado hipervisor) asigna tiempos de CPU y memoria a los diferentes contenedores de manera parecida a la de un proceso multitareas, permitiendo asignar al detalle las cantidades de recursos para cada partición. Sin embargo, dicha solución implica estar "refrescando" los estados de los contenedores sobre CPU y memoria (proceso denominado cambio de contexto o context switch) y cuyo principal defecto es un mayor overhead.

• Finalmente, la tercera opción es un híbrido de las dos anteriores, haciendo uso de optimizaciones en los procesadores y acelerando los cambios de contexto sobre ciertas instrucciones, pero también incluyendo los beneficios de un hipervisor que facilite la gestión sobre los montos de recursos asignados para cada dominio. En el caso del hardware de Sun Microsystems basado en procesadores UltraSPARC-T1 y sistema operativo Solaris 10, dicha solución es denominada Dominio Lógico (Logical Domain – LDom).

Los proveedores…

A partir de los tres tipos de virtualización, se ha lanzado al público toda una gama de soluciones de software y hardware que permiten virtualizar servidores de acuerdo a las necesidades de una aplicación – o la capacidad de nuestros bolsillos. Sin embargo, vale la pena mencionar que estos productos son la última generación de una clase de herramientas que tiene existiendo poco más de 40 años: desde 1967 IBM lanzó al tatarabuelo de las soluciones de virtualización: el IBM VM Operating System (una solución basada en firmware) y cuyo descendiente directo es el z/VM.

Actualmente, las soluciones de virtualización incluyen a proveedores como VMware, amo y señor de la industria con 89% del mercado (según este reporte publicado por Gartner en marzo de este año) así como proveedores de infraestructura y middleware como Microsoft, Citrix, IBM e incluso Oracle y Sun Microsystems.

… y hacia donde va la tecnología

Conforme evolucione la virtualización y mejore el nivel tecnológico de las aplicaciones que la facilitan, iremos más allá de la simple consolidación de las máquinas, utilizando un esquema parecido al lenguaje de programación Java: Compile once, run everywhere (Compílese una sola vez, córrase donde sea) dejando a los sistemas operativos como algo obsoleto. A final de cuentas, esto puede facilitar una mayor productividad al usuario final y al desarrollador. Usando el ejemplo más práctico: a mi personalmente me gustaría tener una laptop con Ubuntu Linux instalado, pero ¿alguna vez han intentado usar OpenOffice? con un ambiente virtualizado puedo usar MS Office o MS Project (el mejor software de su tipo, pero que corre en Windows), mientras utilizo algunas de las poderosas aplicaciones de Linux Red Hat y conservo el bonito ambiente gráfico de Ubuntu.

Corriendo Windows XP sobre SUSE Linux Enterprise Desktop (original extraído de desktoplinux.com)
[Click en imagen para ver fuente]

Para terminar, no creo que haya una mejor visión del futuro de esta tecnología que la que nos proporciona Charles Babcock, analista de la revista InformationWeek:

El software tenderá a ser distribuido como un paquete combinado. Las aplicaciones serán empaquetadas con un sistema operativo ligero para correrlas a ellas y solo a ellas. La aplicación de base de datos será empaquetada con su application server preferido. Los expertos en crear paquetes estándar harán más fácil instalar y correr software en máquinas virtuales en el datacenter. Cualquier cambio o configuración a detalle será delegada a consultores externos. Las aplicaciones empresariales, como Oracle o SAP requerirán menos soporte. Los "Software Appliances" o software como archivos virtualizados ya empaquetados en combinación con el sistema operativo y otros elementos necesarios para ejecutarlos, se convertirán en la manera estándar para distribuir software.

— Charles Babcock, VMware, XenSource, and The Future Of Virtualization, InformationWeek, Agosto 2007.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: