¿ASÍ, O MÁS BARATO?

 Virtualizar los servidores es todo lo que se necesita para una implementación de recuperación ante desastres efectiva… y muy barata. 

Para las áreas de sistemas siempre ha sido prioritario potenciar los servidores virtualizados para recuperación ante desastres (DR, por sus siglas en inglés), pero para los proveedores esta característica era menor, siempre colocada hasta el final entre oportunidades más “destacables”, como evitar la proliferación de servidores, reducir costos y, desde luego, el siempre presente ‘efecto verde’. Hasta ahora.

Para hablar con claridad, aquí se habla de desastres con “D” mayúscula: incendios, inundaciones, epidemias, y no la recuperación operativa que se efectúa por errores de usuarios o archivos borrados. La mayoría de la gente IT tiene listos algunos planes diarios de protección de datos, pero ¿cuántos tienen forma de garantizar que sus estrategias de DR abarcan poco más que hardware residual, pruebas medio diseñadas y un deshojado cuadernillo de procedimientos?

Ahora, gracias a la virtualización, la recuperación ante desastres ha pasado al frente y al centro. Se ven ofertas especializadas de firmas IT ya establecidas, como el Site Recovery Manager, de VMware, y el Hyper-V, de Microsoft. Otras empresas han lanzado productos o remodelado aplicaciones existentes con vistas a quedar dentro de la ola del DR virtualizado, como Forge, de PlateSpin (recientemente adquirida por Novell), y Double-Take, de Double Take Software.

Y sin duda es una ola visible a todas luces: al revisar sus 50 más recientes proyectos de virtualización, GreenPages Technology Solutions encontró que 90% de las empresas que han virtualizado sus sistemas principales han incluido algún nivel de esta tecnología en sus planes de DR. Asimismo, existe ya una tendencia a virtualizar únicamente ambientes de DR, y no las redes primarias.

 

ES MEJOR CONSIDERARLO. Los entusiastas de la virtualización podrán burlarse, pero la virtualización de la recuperación ante desastres tiene sentido en varios niveles: es mucho menos costoso que construir un sitio de DR estándar, y es una estupenda forma de introducir el tema de la virtualización a la organización construyendo capacidades internas sin afectar la red de producción (esquivando además el preocupante problema de que los proveedores IT no ofrecen oficialmente soporte a las versiones virtualizadas de sus aplicaciones).

Una escuela privada mediana de Rhode Island (en Estados Unidos) emprendió esta ruta luego de verse abrumada por un desastre. Virtualizó su plan de DR mediante una aplicación, mas no la red de producción, pues el desarrollador de la aplicación de contabilidad (crítica sin duda para dicha escuela) no otorga soporte -todavía- si la aplicación corre en ambiente virtualizado. GreenPages mostró al personal IT de la institución cómo hacer para correr software en una máquina virtual, y la estableció en su sitio de DR. Cuando, al cabo, el fabricante de la aplicación contable añada soporte a la virtualización, la escuela ya estará un paso adelante.

La mejor noticia es para quienes ya han virtualizado sus servidores, pues sólo deben decidir sobre el tamaño de la configuración del sitio de DR y establecer un nivel de failover [o sea, dispositivos a los que automáticamente se transfieren las operaciones en caso de falla de los sistemas normales].

No importa si la plataforma es Microsoft, Sun Microsystems, VMware o del emporio de fuente abierta de quien sea: si se tiene virtualización de servidores, entonces se dispone ya de los elementos básicos para un plan de DR económico. Separar el hardware físico de los servidores y aplicaciones físicos significa que los objetos definitivos del deseo de todo CIO -a saber, estrictos objetivos de puntos de recuperación (RPO, por sus siglas en inglés) y objetivos de tiempo de recuperación (RTO)- se pueden alcanzar al fin y sin destripar el presupuesto.

Definir y disponer los RPO y RTO con respecto a cada conjunto importante de datos dentro de la organización establecerá el escenario para un plan general de DR, a la par que las operaciones diarias de respaldo, replicación y archivo. Es preciso recabar un consenso acerca de cuáles son los objetivos que hacen sentido, tras estimar los costos de tiempo y datos perdidos. No sólo este ejercicio aguzará el enfoque en la planeación de recuperación ante desastres, sino que contribuirá a justificar el gasto (para más detalles vea el recuadro adjunto “¿Cómo justificar la inversión?”).

También es necesario hacer un plan de replicación/respaldo de los datos, el cual debe integrarse al ambiente virtualizado; esto, porque la virtualización se refiere a servidores y aplicaciones, no a datos específicos.

Si se ha realizado virtualización de servidores pero no se tiene una SAN la compañía debe saber que está omitiendo algunas características de replicación y de toma de instantáneas incorporadas que contribuirían a complementar la estrategia. Asimismo, es necesario revisar que el software de protección continua de datos y su respaldo estén en capacidad de dar soporte a la virtualización, replicación de datos y restablecimiento remoto. Proveedores como CA, Symantec y Tivoli han expandido o remodelado sus líneas de producto y proporcionan mejor funcionalidad para protección de datos virtuales.

 

CUIDADO CON EL ANCHO. Un distribuidor mediano del noreste de Estados Unidos hizo buen uso de los servidores que le quedaron de repuesto por su proyecto de virtualización: los adecuó para DR del tipo standby en frío, el más común de ambientes de recuperación virtualizados. Las cintas con los datos eran rotadas de forma regular, pero la compañía añadió un plan de reciclado para actualizar las imágenes del servidor cada dos años. Como ya se tenían los servidores base, los costos quedaron limitados a la memoria adicional, la labor de configuración y las licencias.

Muchas empresas buscan convertir en sitios de DR las sucursales, que conforman la parte principal de los costos de infraestructura y telecomunicaciones. Por ejemplo, una firma de inversión neoyorquina que prefirió mantenerse anónima remodeló su plan de DR a partir de su proyecto de virtualización y almacenamiento, que emplea la aplicación de replicación XO Soft, de CA, en un ambiente de VMware para servidores y datos centrales replicados mediante un arreglo EqualLogic SAN. El resultado: “Pudimos crear una configuración completa de failover sin tener que buscar un sitio hospedado -afirma su director IT-. Esto supuso replicar la información principal y construir redundancia en nuestro sistema de correo Domino.”

Con todo, si se sigue esta estrategia viene el problema del ancho de banda. La firma financiera tiene un nexo de 100 Mbps entre las oficinas (sólo abiertas durante las horas de trabajo), lo cual da al área IT tiempo suficiente para la replicación y las actualizaciones. Pero si la conexión entre sucursales fuera de conducto angosto, no se podrían replicar GB de datos de la noche a la mañana. En teoría (y en el mejor de los casos), un T1 vacío puede transferir 550 MB a 650 MB por hora, pero queda poco margen de error cuando se pasan diferentes tipos de datos de 40 GB o más durante la noche.

Otra clase de DR virtualizado es la de los sitios calientes, los que suelen tener las firmas que cotizan en bolsa, como las financieras, que son verdaderamente paranoicas y tienen efectivo a raudales. Su capacidad se determina según los mandatos sobre RPO y RTO; por ejemplo, si el punto de recuperación es de cero pérdida de datos y el tiempo de recuperación es de menos de 10 minutos, se requerirá una inversión muy grande a todos los niveles, como ancho de banda (la fibra es obligatoria) y replicación (failover especializado, más replicación de datos, más aplicaciones especiales para bases de datos y específicas de correo).

En este nivel, existe un fuerte interés en el mercado hacia el Site Recovery Manager (SRM), de VMware, el cual escribe todo el proceso que requiere la activación del failover. No es un sistema de replicación como tal (requiere usar la herramienta de replicación de SAN o un producto de terceros, como XO Soft o Doble-Take), pero el SRM se activa en cuanto ocurre un apagón de importancia, controlando en lo esencial el corte de los servidores entre las filiales. Lo más interesante es que imprime el cuadernillo guía de DR establecido en el plan, material que le encanta a los auditores. Su inconveniente principal: sólo trabaja con servidores VMware.

 

 

Mike Healey es director de tecnología de GreenPages Technology Solutions y colaborador de la publicación hermana, InformationWeek. Se le puede contactar en: michael.healey@greenpages.com

 

LOS IMPACTOS DE LA RECUPERACIÓN ANTE DESASTRES EN AMBIENTES DE VIRTUALIZACIÓN

 

	Beneficios	Riesgos
Organización IT	La virtualización como parte medular de la estrategia de recuperación ante desastres permite posibilidades de protección de los datos, al tiempo que maximiza la inversión en IT	Hay que controlar la creación de las máquinas virtuales y la migración a éstas. Asimismo, es necesario efectuar ejercicios de DR y, por supuesto, no ser tacaños en el ancho de banda entre sitios
Negocio	La virtualización contribuye a crear un plan de DR más robusto y flexible, a menor costo que las alternativas tradicionales, reduciendo los temores de que ocurran apagones sorpresivos	El riesgo es mínimo si ya se tiene virtualización. La principal amenaza sería depender de un sitio de DR sub-potenciado en cuanto a caballos de fuerza de los servidores y ancho de banda
Competitividad del negocio	Potenciando plenamente la inversión en virtualización y designando sucursales remotas ya existentes como sitios de DR, la empresa libera recursos para otras iniciativas más orientadas a las metas del negocio	Si el área IT hace mal uso de los dispositivos de legado o un sistema no virtualizable, el negocio podría sufrir de una caída significativa en la productividad. No hay sustituto de un inventario completo de activos

En resumen: La virtualización es una estupenda forma de implementar una estrategia de recuperación ante desastres total a un costo reducido. Sin embargo, al igual que con toda estrategia de DR, si no se dedican recursos a planear y probar adecuadamente, así como al entrenamiento del personal, la empresa podría toparse con una lamentable sorpresa si sobreviniera un desastre real

 

 ¿CÓMO JUSTIFICAR LA INVERSIÓN?

Si acaba de implementar la virtualización, probablemente lo ha conseguido hacer porque se presentó una repentina oportunidad presupuestaria (que rápidamente desaparecerá en cuanto el CFO se haga una idea de lo que está pasando), y ya disponía de algún dispositivo no usado pero en perfecto estado.

En ese caso, el planteamiento sería el siguiente: si su ambiente de producción es de 275 servidores virtuales que corren sobre 30 aparatos físicos con 10 TB de datos en una red de área de almacenamiento (SAN), ¿requiere la misma capacidad para el sitio de recuperación ante desastres, o puede eliminar algunos servidores para ahorrar dinero?

¿Cómo decidir? No puede hacerlo. Éste es un asunto donde el departamento IT debe conseguir que intervenga la dirección general. Presente el plan de DR al CEO y al COO, y póngalos al corriente de cuál será su uso. Esto será un factor capital en las decisiones sobre banda ancha, servidores y configuración del almacenamiento.

Todo plan de DR requiere definir parámetros de acceso en las actividades de misión crítica. Una manufacturera o una constructora que basa sus operaciones internas en los sistemas IT podría optar por construir un sitio de DR para soportar la mitad de la carga de trabajo habitual, dando prioridad a los jefes de área o a las aplicaciones críticas. En sistemas que corren datos de misión crítica y de cara al cliente hay que volver compatible su configuración y establecer el correspondiente ancho de banda.

¿Y si se reduce el tamaño del sitio de DR? Una gran ventaja de la virtualización y las SAN es que se puede ampliar rápidamente la infraestructura de hardware que las sustenta. Por ejemplo, si dispone de un clúster de servidores físicos de 10 nodos en la oficina matriz, el sitio de DR posee cinco servidores que apoyarían en caso de un desastre. El plan puede incluir una cláusula que diga que si la situación de failover dura más de 48 horas añadirá servidores físicos para mejorar el desempeño y repartir la carga.

 

EL DINERO  MANDA. Hacer un ejercicio para comparar costos entre establecer sitios de DR virtualizados y estándar vale mucho. En el caso de una red de 30 servidores y 4 TB de capacidad de almacenamiento, suponiendo que la red de producción no está virtualizada, los más importantes ahorros provienen de los servidores (hardware). En una situación estándar, la configuración en espejo de la instalación principal que requiera hardware ‘igual para igual’, la cifra sería de $150,000 dólares; mientras que en un escenario virtual se emplearían servidores más grandes con más memoria y más procesadores, pero la ganancia sería de 10 a 1; esto es: el costo sería de $30,000 dólares, por lo que el ahorro neto sería de $120,000.

No hay artículos relacionados