FAILOVER

No permita que el proceso de failover interrumpa otra vez su operación. Hay opciones; es cuestión de elegir la que más conviene en cada caso. 

Las empresas, sin importar su tamaño, piden entrega de aplicaciones 7X24 y las fallas de los servidores, el tiempo muerto por mantenimiento y los desastres naturales no son excusas válidas.

Quien tenga como trabajo el mantener las aplicaciones clave siempre operativas debería considerarse afortunado porque hoy existen más opciones para mantener vivas las aplicaciones que nunca antes.

Con las herramientas disponibles en la actualidad, las organizaciones tienen menos pretextos -ya ni siquiera los presupuestales- para evitar que se caigan los sistemas debido a un failover mal realizado y sin recurrir a tardados procesos de restauración manual de las aplicaciones de misión crítica desde un respaldo.

Los procedimientos de failover de las aplicaciones abarcan toda una gama: desde el software de servidores interconectados (clúster), donde uno debe ponerse a rezar para que el proceso funcione, hasta sistemas completamente virtualizados y planes para aplicaciones específicas.

Encontrar lo conveniente para cada situación particular supone algo más que mirar la etiqueta del precio, que suele ir de $1,500 a $10,000 dólares y fracción por servidor protegido.

También hay que tomar en cuenta la facilidad de uso, la rapidez del failover, el consumo de banda ancha y la cantidad de datos que están en juego.

AHORA ES MÁS FÁCIL. Cuando la mayoría de los administradores de sistemas tratan de mejorar la disponibilidad de aplicaciones, empiezan por interconectar servidores.

En las ediciones empresariales de Windows Server, desde que Windows NT 4 era lo último a mediados de los 90, están disponibles clústers para failover, pero se ganaron la mala fama de ser caprichosos, y es que los clústers de Windows usaban almacenamiento compartido, lo que llevaba a que el subsistema de almacenamiento fuera un solo punto de fracaso.

Esto cambió cuando fue liberado el Windows Server 2008.

Microsoft ha insistido sólo en soluciones de servidor y almacenamiento integradas, de modo que los usuarios que tenían servidores HP y almacenamiento EqualLogic, por ejemplo, se encontraban en mala situación en cuanto al soporte. Es muy significativo que las aplicaciones tenían que estar conscientes de los clústers para poder conmutar sin problemas de un nodo de servidores a otro.

Incluso antes de que Microsoft añadiera clustering al propio Windows, fabricantes como Double-Take Software liberaron soluciones que combinaban replicación de datos, que elimina el almacenamiento como único punto de fallas, con failover automático. Las primeras versiones de estos productos exigían mucha labor de instalación y ajustes, como instalar el sistema operativo y las aplicaciones en ambos servidores.

Sin embargo, los actuales, como LifeKeeper, de SteelEvye; WAMsync, de CA/XOsoft; Continuous Protectin Suite, de NeverFail, y desde luego Double-Take, pueden clonar un servidor de producción en el nodo pasivo (stand-by) o el servidor de respaldo, lo que apresura la instalación y asegura que los servidores queden configurados de manera similar. Y algunos de estos ofrecimientos soportan clusters Linux y Windows tradicionales.

MONITOREAR LATIDOS… ¿CONVIENE? En un sistema de clusters genéricos, o sea de alta disponibilidad, el servidor o servidores de failover monitorean los ‘latidos’ del servidor primario (o sea, si está vivo), intercambiando mensajes por toda la red.

Si el host primario no responde en determinado tiempo, el servidor standby asume la identidad del host primario y comienza a procesar datos en vez de aquél.

Este método puede impedir la pérdida de datos por alguna falla completa del host primario y permite hacer failover manuales para parchado y mantenimiento de los demás servidores, pero no detecta fallas más pequeñas de servidores y de procesos “demonio” (programas ocultos, como los que dirigen el e-mail a sus destinatarios).

Fabricantes como SonaSoft y Marathon disponen de más productos conscientes de las aplicaciones, que comprueban el estado de los servidores o se conectan directamente con las aplicaciones para cerciorarse de que están funcionando.

Estos productos también usan diferentes métodos para permitir que un servidor stand-by asuma la identidad de un servidor de producción en el caso de una falla. La forma más sencilla es asumir la dirección IP del servidor de producción y comenzar los servicios apropiados.

Un procedimiento más sofisticado, que usa NeverFail y otros, es ocultar el servidor stand-by detrás de un firewall interno para impedir que los usuarios lo accesen mientras no es llamado para tomar el papel del servidor primario.

El mejor producto es EverRun, de Marathon, que corre los servidores primario y stand-by al mismo paso en un ambiente virtual.

Cada servidor procesa todos los datos, pero los usuarios accesan sólo el primario; el servidor de respaldo aguarda por si algo marcha mal.

LO DE HOY NO ES SÓLO VIRTUALIZAR. La virtualización de servidores, igual que en la gestión de centros de datos, ha permitido a los administradores mejorar considerablemente su disponibilidad.

El impacto más obvio es que virtualizar servidores stand-by elimina la costosa relación uno a uno entre los servidores de producción y los nodos pasivos, reduciendo así el costo de proveer servidores stand-by. Debido a que todos los servidores virtuales en la misma plataforma de virtualización parecen iguales al sistema operativo huésped, se eliminan los problemas de drivers y de hardware.

Las organizaciones pueden proveer rápidamente de servidores en los sistemas de alta disponibilidad de los data centers en el host de los servidores virtuales. Las soluciones de failover High Availability (VMware), Clustering of Hyper V (Microsoft) y Linux para Xen protegen todos los servidores huésped de fallas del host, permitiendo el mantenimiento del host sin significativos tiempos muertos para el huésped. EverRun (Marathon) para Hyper-V y Xen pueden también extender la protección del host hasta una auténtica recuperación de desastre multisitios.

Si bien el Site Recovery Manager (SRM) de VMware requiere algo de escritura, por otro lado brinda failover sitio a sitio de los servidores virtuales a lo ancho de una variedad de aplicaciones y sistemas operativos huésped. El SRM se basa en arreglos (arrays) de almacenamiento que replican los datos de un sitio a otro, aunque los fabricantes de arreglos tienen que escribir un adaptador para permitir que el SRM maneje el proceso de replicación.

Tendencia reciente en la disponibilidad de aplicaciones ha sido el desarrollo de soluciones de alta disponibilidad y de recuperación ante desastres que no sólo son conscientes de las aplicaciones, sino que también operan en la capa de aplicaciones. Una solución de propósito general replica escrituras a nivel de archivo o de bloque para que el host primario almacene en un sistema pasivo.

Independientemente de si la replicación se hace usando software en el host primario y en el stand-by o si la ejecucta el propio sistema de almacenamiento, la base de datos de la aplicación es administrada por el host primario, mientras la copia de la aplicación que hay en el stand-by se mantiene ociosa.

Cuando tiene lugar el failover, la aplicación se activa en el servidor pasivo, y monta aquella copia de la base de datos que es consistente con la caída.

Por tanto, lo primero que el servidor debe hacer es un rápido chequeo de la consistencia para echar atrás las transacciones que estaban procesándose cuando ocurrió la caída.

Esta acción suele tomar sólo uno o dos minutos, pero ocasionalmente deja el servicio inalcanzable para los usuarios durante varias horas porque la base de datos es examinada y reindexada, en especial si la caída ocurre durante una defragmentación de la base de datos.

MAS VALE REPLICAR QUE LAMENTAR. Las soluciones específicas para una aplicación replican los datos transaccionales en un servidor stand-by, donde la aplicación que se está corriendo aplica la transacción a su copia de la base de datos.

Este procedimiento tiene varias ventajas: primero, como el servidor de respaldo está corriendo la aplicación, no se tarda mucho en conmutar al back-up, iniciar los procesos de la aplicación y montar la base de datos; en segundo lugar, manejar transacciones completas impide que se propaguen al servidor de respaldo muchas fuentes de corrupción de la base de datos, como las causadas por software malicioso en el host primario, o los errores I/O en el sistema de almacenamiento.

El servidor secundario se puede usar también como fuente de datos para operaciones como las de respaldo, archivo y reporteo, lo que permite que estos procesos corran en cualquier momento sin afectar a los usuarios.

La replicación de los datos transaccionales también reduce la cantidad de datos que deben ser enviados entre los almacenamientos de datos primarios y secundarios. Las actuales bases de datos escriben datos a archivos de registro de transacciones y, cuando se ha completado la transacción, los transfieren a la base de datos en disco.

Las soluciones que replican datos de almacenamiento deben replicar los escritos tanto al registro de transacciones como a la base de datos, mientras que las soluciones basadas en transacciones sólo deben enviar las transacciones por toda la línea una sola vez.

Sólo bastaría dejar clara una cosa: existe un inconveniente en el failover a nivel de aplicaciones, y es que si falla el servidor primario, al menos unas cuantas transacciones se perderán en la transición, porque se encuentran en el servidor primario mas no en el stand-by. Así, no obstante que las soluciones mejoran el tiempo de recuperación, pueden afectar negativamente los puntos de recuperación.

EXCHANGE, EL GANADOR

Muchos procesos de failover para aplicaciones específicas se han enfocado en Exchange (Microsoft), en gran parte porque tiene muchas partes móviles e interconexión al Active Directory y otros servicios de redes. Software como MailShadow OnSite, de Cemaphore, y SonaSafe, de SonaSoft, para Exchange, capturan datos del servidor Exchange usando el protocolo nativo de Exchange MAPI y lo transfieren a un servidor Exchange que esté activado; un servidor de respaldo puede proporcionar protección a varios servidores fuente, y si los servidores de producción SonaSafe se hallan en diferentes oficinas pueden respaldarse recíprocamente.

Microsoft ha probado también con características de recuperación ante desastres en el Exchange 2007: Cluster Continuous Replication (CCR) para alta disponibilidad y continua replicación en el stand-by (SCR), que envía los archivos de registro de transacciones desde el servidor primario al secundario para mantener la base de datos actualizada. El SCR requiere significativa intervención manual, o escritura, para mantener alerta el nodo pasivo, pero promete para el futuro. El CCR se basa en clustering Windows para el failover y se limita a tener todos los sistemas en la misma subred.

¿CUÁL ELEGIR?

El failover es un procedimiento por el que, en caso de avería de un elemento, éste conmuta la operación a otro elemento. Es necesario saber cómo llevar a cabo el proceso, según cada caso. Aquí unos datos que pueden ayudar a decidirse.

Clústers de servidores

Funcionan mejor en ambientes más pequeños con necesidades de failover básico y software específico para una aplicación: ajustan las tareas de failover a aplicaciones individuales y son una buena elección cuando sólo unas cuantas aplicaciones se necesitan en un esquema 7X24.

Software consciente de las aplicaciones

Son mejores para organizaciones que necesitan remediar rápidamente caídas que sean más sutiles que las caídas completas de servidor.

Sistemas de failover virtual

Son los más apropiados para las empresas mayores con múltiples aplicaciones críticas en muchos servidores. Debido a que cada servidor de aplicaciones desempeña la tarea en su propia base de datos, este enfoque también evita la tardada tarea de replicar la escritura de discos cuando las aplicaciones realizan defragmentación interna de las bases de datos (que Exchange 2003 efectúa de noche) y otras ‘labores caseras’.