Virtualización de Servidores: Tips

A lo largo de nuestro trabajo con la virtualización de servidores obtuvimos algunas experiencias útiles que se pueden compartir:

1. Tener un software para pasar de un servidor físico a uno virtual. Nosotros lo hicimos con Acronis que es una herramienta para respaldos, hoy en día hay programas  especializados que facilitan la tarea.
2. La memoria lo es todo. Definitivamente lo más importante es la cantidad de memoria disponibles para los servidores virtuales, el uso del CPU es secundario (en nuestro caso el promedio de uso de los servidores anfitriones estaba cerca del 15%). Obviamente hay que tener espacio en disco suficiente para mantener a los servidores virtuales cuyo tamaño mínimo puede ser de 5GBytes.
3. Cuidado con las VLans. Puede ocurrir que se tenga la necesidad de colocar un servidor virtual que esté en una VLan distinta a la del servidor anfitrión, de ser así el servidor anfitrión deberá tener otra tarjeta de red con una dirección IP de la otra VLan (obvio); lo que hay que tener cuidado es el Default Gateway a colocar entre las distintas propiedades IP de las distintas tarjetas para que el flujo de datos sea eficiente.
4. Aislar Servidores Virtuales intensivos. Si se tienen servidores virtuales que hagan uso intensivo del disco, es prudente que cada uno de ellos se aísle en un volumen del servidor anfitrión para permitir una defragmentanción de su disco sin molestar a los demás servidores virtuales residentes en el mismo anfitrión.
5. Respaldos Totales. Lo mejor de los servidores virtuales es que el respaldo es trivial: se copia la carpeta que lo compone al servidor de respaldos y punto!
6. En el tiempo de espera para cargar un Servidor Virtual cuando se inicia el servidor anfitrión, es prudente espaciar cada servidor virtual en 90 o 120 segundos para no sobre cargar el servidor anfitrión.
7. Si se van a usar servidores anfitriones con Windows Server 2008, hay que recordar que hace falta una tarjeta de red únicamente para su administración, si luego se desean hospedar servidores virtuales en distintas VLANs y además con redundancia en las tarjetas de red… habrá que comprar tarjetas adicionales de red.
8. Para que los servidores virtuales sean realmente “transportables” de un servidor anfitrión a otro, hay que disminuir los factores variables de los cuales ellos dependen:
• Mapeo a las tarjetas de Red: si se mantiene una norma estricta sobre la nomenclatura de las tarjetas de red, este problema se subsana.
• Mapeo a discos externos: Un servidor virtual puede mapear un disco a un disco físico del servidor anfitrión… si esto se hace… adiós a su portatibilidad!
• Usuario que levanta el servidor virtual: lo mejor es tener un usuario del dominio para esta función, sin embargo mi experiencia es que el password no se copia de un servidor anfitrión a otro, así que siempre se tendrá que reparametrizar.

Virtualización de Servidores: en producción

Al poco tiempo de haber cosechado el primer éxito virtualizando servidores de desarrollo, decidí pasar a la etapa de virtualizar servidores de producción.

Para dar este importante paso primero me aseguré de tener una herramienta de software que permitiese pasar de un servidor físico a uno virtual sin mayores traumas; el analista encargado luego de investigar se decidió por Acronis, este es un software para efectuar respaldos que toma imágenes de servidores Windows. La metodología era la de tomar una imagen del servidor a virtualizar con Acronis, “vaciarlo” en el cascarón de un servidor virtual y luego fajarse con los ajustes normales de Windows Server ya que el servidor se estaría “despertando” en un hardware distinto al que estaba acostumbrado (esto se resuelve teniendo el CD del Windows Server en cuestión a mano). Lo cierto es que en un tiempo relativamente corto, se podía pasar un servidor físico a uno virtual.

Para la instalación de un servidor anfitrión para servidores virtuales de producción, nos hizo falta adquirir un hardware adicional. Adquirimos un HP DL380G4, con dos discos de 72GBytes y otros tres discos de 146Gbytes, también tenía 8Gbytes de memoria RAM. El servidor lo configuramos con los dos primeros discos en RAID-1 y los otros 3 en RAID-5, de esta forma Windows Server tendría a su disposición “un” disco de 72Gbytes (para el sistema operativo y posiblemente un servidor virtual) y un segundo disco de 280Gbytes.

Con el pasar del tiempo fuimos virtualizando servidores físicos: algunos eran PCs, otros eran servidores HP DL380 o IBM x346, la mayoría de los casos se trataba de servidores con funciones de Front End con IIS o Sun Application Server o programas propietarios, pero también se virtualizaron servidores que manejaban datos propiamente con Pervasive (para el famoso sistema LA de la Casa de Bolsa) o con Sybase (para el sistema IcaavWin de la Agencia de Viajes). Se virtualizaron servidores de desarrollo de las Agencias bancarias, se virtualizó la pasarela de autorizaciones de transacciones para POS y ATM y hasta se virtualizaron dos servidores Linux de Red Hat (así es, Red Hat dentro de Servidores Windows)… todo funcionó perfectamente!

En la cúspide la virtualización tuvimos tres servidores anfitriones (uno para la VLAN de Desarrollo, uno para la VLAN desmilitarizada y otro para la VLAN de Producción) que mantenía un total de unos 24 servidores virtuales con sistemas operativos variados:

-          Windows Server 2003 R2

-          Windows Server 2000 SP4

-          Windows Profesional 2000 SP4

-          Windows XP SP3

-          Linux Red Hat 3

Lo que nunca pudimos virtualizar fue un servidor Novell Netware (nos daba problemas la tarjeta de red) pero tengo que reconocer que no hicimos nuestro mejor esfuerzo al respecto.

A lo largo de los cinco años que duró nuestra experiencia con servidores virtualizados, nunca tuvimos caídas “extrañas” imputables a la plataforma implementada, ni en los servidores anfitriones ni en los servidores huéspedes.

Virtualización de Servidores: primeros pasos

Aproximadamente en el año 2005 comenzamos a coquetar con la virtualización de servidores, para ese momento solo teníamos la teoría de las presentaciones de los proveedores, mayoritariamente de VmWare, y yo había visto funcionando en una Laptop de un amigo con Windows XP a una máquina virtual también con XP y otra con Linux de Red Hat… se veía todo muy bien y prometía cosas increíbles.

En particular había un tema que nos tenía muy ajetreados: la creación de Agencias de prueba. El departamento de calidad con frecuencia nos pedía la creación de una agencia en desarrollo, eso tenía un impacto importante a la hora de crear el ambiente necesario: Windows Server 2000, Oracle Standard 9i, IIS más el software del negocio (Flexbranch que es el módulo de Flexcube para las agencias). La idea era la de tener a esas agencias virtualizadas para que, en caso de querer "rehacerlas", solo sería cuestión de recopiar el servidor virtual.

Así que comenzamos como todo el mundo: virtualización de ambientes de prueba sin criticidad. Nuestras pruebas iniciales las hicimos con en el software de virtualización de Windows (Virtual Server) ya que mi analista estrella tenía varias certificaciones de Microsoft y conocía el software muy bien. Nuestra primera plataforma anfitriona era un simple servidor HP DL380G3 con 2Gbytes de memoria RAM y dos discos de 72GBytes cada uno.

Dados los pocos requerimientos, pudimos meter en ese modesto servidor anfitrión 2 o 3 servidores virtuales sin problema alguno… los usuarios no se dieron cuenta del cambio… con ese aval preparé una presentación y fui a hablar con el Director. La idea del proyecto inicial era la de repotenciar al servidor que estábamos usando añadiendo otros dos discos de 146GBytes y llevándolo a 6GBytes de memoria RAM, de esta forma podríamos meter allí unos 6 servidores virtuales de desarrollo (cada uno con 512MBytes de memoria RAM y unos 15Gbytes de espacio en disco); el financiamiento del proyecto fue trivial: el costo de la ampliación del hardware era menor al de los PCs en los cuales se encontraban los servidores que serían reciclados a usuarios normales. Pero el gran atractivo del proyecto en verdad era el ahorro en espacio: remplazar a 6 PCs de distintos tamaños que estaban en un Rack del DataCenter por un servidor de 2U fue realmente irresistible.

Aun cuando estudiamos la solución ofrecida por VmWare, decidimos seguir con Microsoft Virtual Server ya que:

1. Nos sentíamos cómodos con la herramienta
2. No teníamos grandes requerimientos de eficiencia (nos imaginamos que VmWare sería mejor)
3. No había que pagar por un software adicional, y
4. En ese momento Microsoft condonaba las licencias de Windows Server 2003 R2 de los primeros 4 servidores virtuales que fuesen hospedados en un Windows Server 2003 Standard (había distintos planes para los distintos sabores de las licencias de Windows Server)

De esta forma comenzó nuestro proyecto de virtualización. En poco tiempo pudimos concretar lo prometido: remoción de 6 PCs del DataCenter (ahorro en espacio, en energía, en punto de red, en puertos de KVM y reciclaje de los PC como tales) concentrando sus funciones en un servidor existente repotenciado en memoria y disco, de haberse requerido se hubiese podido añadir un segundo CPU pero hubiese sido tremendamente oneroso.

Habiendo logrado un éxito rotundo con los ambientes de desarrollo, decidí proseguir para virtualizar servidores de producción.

VLan para cuarentena

Típicamente cuando se detecta a un PC con Virus, a éste no se le aísla ó, en caso de desconectarse de la red,  su reconfiguración puede ser laboriosa sin los recursos que están en la red. He estado en presentaciones de soluciones comerciales en las cuales se puede configurar una VLAN de “ingreso” a la red, si los criterios de ingreso no son satisfechos (huella actualizada, sistema operativo actualizado, etc.), entonces el usuario no puede entrar a la red hasta tanto lo haga. Pareciera una buena solución pero no quiero imaginarme el caos que ocurriría cuando haya excepciones que se tengan que hacer sobre la marcha o haya falsos positivos que contemplar estando en plena operación!

Una solución intermedia es crear una VLAN en la cual únicamente estarían los PC contaminados, una salida a Internet (que no interfiera con la corporativa) y un servidor, posiblemente Linux, que tenga el software necesario para las reconfiguraciones y que sirva de autenticación. De esta manera los PC contaminados puedan “curarse” en un ambiente que no los contamine ni ellos puedan contaminar a nadie más.