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.

Del tamaño de los Racks

Hay racks del tipo “corto” y racks del tipo “largo” (que miden aproximadamente 1mts de profundidad). Nosotros cometimos el error de adquirir racks cortos debido a: 1) Falta de espacio en el data center, y 2) Los servidores que se iban a colocar allí eran del tipo Tower que cabían perfectamente. La primera razón es la consecuencia del error cometido por nuestros consultores en cuanto al tamaño del Data center, la segunda razón fue el desconocimiento de la tendencia de los servidores del tipo “rackeable” que es la de crecer más a lo largo que a lo alto... inclusive los tipo tower de perfil corporativo, también se volvieron más profundos con el pasar del tiempo.

Este error lo pagamos algunos años después cuando, debido a la inevitable renovación tecnológica, adquirimos servidores “rackeables” que nos obligaron a cambiar dos de los racks “cortos” por “largos” (los otros fue imposible debido al tamaño del Data Center).

Como "acercar" los Servidores a los Switches

Nuestro Data center se estructuró de una forma tradicional: una hilera de racks con servidores y atrás media hilera de racks con los equipos de comunicaciones. El problema de este enfoque es que, para cada interfaz de red de cada servidor, sale un cable que recorre todo el Data Center para alcanzar finalmente los switches del Core de la LAN. Recientemente he visto alternativas en las cuales los racks de los switches están en la mitad de la hilera de los racks de servidores, mejor aún: se pueden poner en cada rack un switch al cual se conectan los servidores de ese rack y estos son conectados mediante fibra al swich maestro que podría estar colocado en la mitad de la hilera de servidores. De esta manera las conexiones de los servidores son mucho más simples, los cables más cortos, se puede ver fácilmente a que puertos están conectados y otras ventajas adicionales.

La SAN HP EVA 4100

A finales del 2007 se hizo preciso mejorar la plataforma del Core Bancario, hasta ese momento residía en un servidor Sun V440 con 6GBytes de memoria RAM, 4 discos internos de 36GBytes y un arreglo de discos externos de 5 discos cada uno de 72Gbytes que, en RAID-5, dejaban disponibles unos 250GBytes. Se decidió entonces pasar a un esquema de Cluster del tipo Activo –Pasivo (ya que el licenciamiento de Oracle hacía prohibitivo tener dos servidores en modalidad Activo – Activo) y se optó la solución de HP con Service Guard.

Para resolver el problema del almacenamiento, se decidió adquirir un EVA 4100 de HP con 8 discos de 300GBytes c/u que finalmente dejaban libres unos 2240Gbytes… ya el administrador podría decidir como dividir los volúmenes de este dispositivo y con que tipo de redundancia (RAID-0, 1 o 5).

Al EVA 4100 se conectaron los dos servidores HP rx3600 con HPUX (que integrarían el Cluster Activo – Pasivo) y un servidor DL380 G5 que haría funcionas de NAS para Windows (teóricamente ese servidor debería estar encargado únicamente de tener la interfaz al EVA, pero hubiese sido un gran desperdicio hacerlo de esa manera).

Para lograr el efecto del Cluster Activo – Pasivo con Service Guard (sobre el cual escribiré posteriormente), se hicieron varios volúmenes de datos:

1)     El de Bases de Datos Oracle para el Core Bancario con 500GBytes en RAID-1

2)     El del Oracle Application Server para el Core Bancario con 45GBytes en RAID-1

3)     El de la Base de Datos de Fideicomisos con 100GBytes en RAID-1

4)     El de la Base de Datos de Cheques Digitalizados con 100GBytes en RAID-1

5)     El de los Home Folders y Carpetas compartidas para los usuarios Windows con 500GBytes en RAID-5

6)     El de Respaldos especiales de 200Gbytes en RAID-0

7)     El de uso interno del Cluster propiamente con 10Gbytes en RAID-1

Todo esto suma prácticamente la capacidad total del EVA.

Lo interesante del enfoque del software del EVA, es que el administrador realmente no sabe en que disco(s) reside un volumen dado, simplemente pide cierto espacio con cierta redundancia (RAID-1, RAID-5 o sin redundancia) y el EVA decide como repartirlo.

Por tres años todo funcionó a la perfección… hasta que llegó la falla!

Un mal día una alarma sonora avisó que había un desperfecto en la SAN, ingresé al utilitario que la maneja y pude ver que efectivamente todos los volúmenes menos los dos relacionados con el Core Bancario y el interno del Cluster, tenían un triángulo amarillo… dos de los discos duros físicos presentaban un error con un icono en rojo. En efectos los usuarios reportaron haber perdido sus carpetas de “Mis Documentos” así como las carpetas compartidas… pánico total!

Ejecuté los comandos necesarios para tratar de recuperar los volúmenes pero no tuve éxito. Finalmente me resigné a perder las particiones marcadas, así que recree la de Windows y bajé los datos del respaldo, ahora los volúmenes quedaron configurados de la siguiente manera:

1)     El de Bases de Datos Oracle para el Core Bancario con 500GBytes en RAID-1 (no quedó afectado)

2)     El del Oracle Application Server para el Core Bancario con 45GBytes en RAID-1 (no quedó afectado)

3)     El de los Home Folders y Carpetas compartidas para los usuarios Windows con 400GBytes en RAID-5

4)     El de uso interno del Cluster propiamente con 10Gbytes en RAID-1 (no quedó afectado)

Dado que se perdieron 2 discos, la capacidad de la SAN bajó a 1680GBytes. Por otro lado la suma teórica de la nueva configuración es de 1610Gbytes, así que estábamos bastante recuperados. Esto duró una semana… ya que falló un tercer disco!

Esta vez la falla fue menos severa ya que en ningún momento se perdió el acceso a algún volumen, lo curioso del asunto es que, a pesar que a la SAN no le quedaba prácticamente espacio disponible (creo que reportaba 8GBytes libres) y a pesar de que fallara un disco, lo cual disminuía la capacidad teórica a 1400GBytes (sensiblemente menos de lo reservado por los volúmenes), la SAN continuó funcionando sin pérdida de datos y ni siquiera reportó que removiese algún tipo de redundancia para tener más espacio. Eso si, se sumergió en un estado de “leveling” desde el primer día (un martes) y el tiempo de respuesta del Core bancario aumentó sensiblemente (el cierre del Core Bancario diario tardaba el cuádruple).

Dado que, evidentemente, la situación no era estable más el temor que fallara un cuarto disco, comenzamos una actividad febril de sacar a los Home Folders y las Carpetas compartidas de la SAN: la idea era la de eliminar el volumen para Windows devolviéndole todo el espacio a la SAN para que el Core bancario pudiese funcionar como lo hacía antes de la falla. Este procedimiento se culminó el jueves por la noche, los volúmenes quedaron así:

1)     El de Bases de Datos Oracle para el Core Bancario con 500GBytes en RAID-1 (no quedó afectado)

2)     El del Oracle Application Server para el Core Bancario con 45GBytes en RAID-1 (no quedó afectado)

3)     El de uso interno del Cluster propiamente con 10Gbytes en RAID-1 (no quedó afectado)

El total teórico es de 1110Gbytes de los 1400 disponibles… a los pocos minutos de haber liberado el volumen de Windows, la SAN culminó su proceso de “leveling” e indicó que el espacio disponible ahora es de 30Gbytes (aun cuando dice que lo ocupado son 1100, debe ser que hay áreas adicionales dañadas). Los tiempos volvieron a los niveles normales anteriores a la falla… se acabó la crisis!

Anécdota: Al producirse la primera falla llamé al servicio técnico de HP para que me atendieran, en ese momento  me informaron que el contrato de mantenimiento se había vencido dos días antes. Yo estoy seguro que HP no “planea” sus fallas para justo después de que venzan los contratos de mantenimiento… pero de que vuelan vuelan!

Sobre la marca de los Racks

Cuando se planeó el Data Center, vimos que había que traer servidores tipo Tower de las empresas que componían el conglomerado pero también se adquirirían un buen número de servidores nuevos. Para los servidores ya presentes no había mucho que hacer, pero para los nuevos traté de que se adquiriese junto con ellos el Rack del fabricante (en nuestro caso Sun y HP)… logré mi objetivo con HP pero no así con Sun. Finalmente la decisión sobre los tipos y marcas de los Racks fue de otros quienes, lamentablemente, seleccionaron Racks genéricos.

Aun cuando para los servidores Tower el tipo de Rack no importaba mucho (básicamente se instalaron uno encima del otro con la ayuda de algunas bandejas), aprendí que los servidores “rackeables” Sun y HP no pueden instalarse “sin problemas” en cualquier Rack… a los servidores Sun, que les tocó uno genérico, la instalación tomó mucho más tiempo de lo normal y se tuvieron que sacrificar los brazos con lo cual se perdió su movilidad.

Conclusión: es preferible gastar algo más de dinero comprando los Racks de la misma marca de los servidores que van a contener.

Distribución de los servidores en los racks

El vendedor me dijo “El rack tiene 41U, por lo tanto puedes meter hasta 41 servidores de 1U de altura o 20 de 2U”… aún cuando la cuenta matemática es exacta, en la práctica es imposible meter 41 servidores en un Rack y muy poco manejable meter a 20, la razón? Cada servidor tiene típicamente dos fuentes de poder, dos tarjetas de red y al menos una conexión al KVM (generalmente estas conexiones meten a las conexiones del Teclado, Mouse y Monitor por un solo cable físico) es decir que cada servidor tiene típicamente cinco cables largos (ya que hay que darle la holgura necesaria para deslizar el servidor hacia adelante por los rieles), con 20 servidores en el rack habría un mínimo de 100 cables dirigidos a distintos puntos del rack (los PDU, a un Switch o al KVM), esta situación es casi inmanejable.

Otra razón importante es el calor que se desprende de 40 fuentes de poder! La refrigeración también es retada fuertemente.

Mi recomendación es la de tener no más de 10-12 servidores tradicionales por rack (con los Blades la cuenta es otra). El espacio sobrante podría usarse para servidores con tamaño mayor (de 4U por ejemplo), para colocar un KVM que permita al operador trabajar con cierta comodidad o para colocar dispositivos adicionales que a menudo hay que poner: unidades de cinta pequeñas externas, discos USB externos, módems, etc.