Una pregunta recurrente que oigo sobre el terreno es «¿Cómo gestiona usted la alta disponibilidad y la recuperación en caso de desastre?». La alta disponibilidad (HA, por sus siglas en inglés) y su primo a menudo olvidado, la recuperación en caso de desastre (DR, por sus siglas en inglés), son términos que ninguna empresa debería ignorar. Sin embargo, el significado concreto para usted de alta disponibilidad dependerá de su aplicación de negocio, su infraestructura de TI y la perspectiva del usuario final. Así que la auténtica pregunta para nosotros es: «¿Qué implica una configuración de alta disponibilidad en el contexto de un entorno corporativo de output?» ¿Se requiere alguna solución específica o puedo usar las que ya tengo? ¿Existe algún problema técnico específico vinculado con la gestión de output que deba conocer?
Comencemos por el principio: ¿Qué significa «disponible» para un servidor de output de empresa y cómo puede usted garantizar esa disponibilidad? Su primer paso debe ser seleccionar un hardware y un software que sean intrínsecamente estables (esto puede sonar obvio pero no está de más recordarlo). En lo que al hardware se refiere, el servidor no es la única consideración. Por ejemplo, un servidor puede estar funcionando perfectamente según todos los indicadores sobre plataformas y aplicaciones pero, si los usuarios no pueden imprimir, el servidor está inactivo en lo que a ellos concierne. El software de gestión de output de LRS está diseñado para permitir un escalado vertical y horizontal. Sin embargo, es una imprudencia confiar en un único servidor para todo. Las páginas de la historia están llenas de transatlánticos «insumergibles» y de centros de datos que «jamás» podían colapsarse. Es probable que su entorno de alta disponibilidad implique varios servidores.
La aplicación de negocio y los aspectos financieros a menudo determinarán el tipo de configuración de alta disponibilidad que deberá usar. Una de las primeras preguntas que un ingeniero de LRS hace cuando trabaja con un cliente sobre alta disponibilidad es «¿qué está usando actualmente?» La razón de ser de la pregunta no es evitar hacer el trabajo. El software VPSX y sus componentes están diseñados para trabajar con cualquier cantidad de sistemas de alta disponibilidad existentes. Puesto que es probable que la solución existente pueda seguir usándose, para nosotros es bueno determinar qué tiene el cliente y con qué se siente cómodo gestionando el día a día.
Otro factor es con qué rapidez debe restaurarse la función de impresión durante un apagón. En otras palabras, ¿el tiempo de inactividad se mide en términos de comodidad, experiencia del cliente, pérdidas financieras o vidas? Durante una caída del sistema, ¿el sistema debe recuperarse de forma instantánea y transparente o es aceptable un plazo de recuperación entre cinco y quince minutos? Es fácil hablar de recuperación «instantánea» y, por supuesto, es posible. Pero ese nivel de disponibilidad puede requerir más complejidad e infraestructura.
Antes de diseñar una solución de alta disponibilidad, deben considerarse algunos factores clave. En primer lugar, el software LRS ya está diseñado para soportar una instalación donde los componentes ejecutables están separados de la configuración y los datos de la aplicación. Este diseño puede aprovecharse para utilizar sistemas de almacenamiento de alta disponibilidad como SAN o NAS. También ha funcionado bien con varios sistemas de clustering de hardware ejecutados con Windows y UNIX que requieren un centro de datos compartido. Finalmente, también se han usado Controladores de Entrega de Aplicaciones (ADC por sus siglas en ingles) (a menudo denominados sistemas de balanceo de carga). Todos estos tipos de soluciones de alta disponibilidad se están usando actualmente y funcionan bien en entornos con clientes reales. Pero la historia no acaba aquí.
Debe considerar la naturaleza del output. Por ejemplo, una aplicación puede generar un «documento» de negocio que consista realmente en una recopilación de documentos que deben imprimirse en un orden específico. Si un sistema de alta disponibilidad fue configurado para simplemente «repartir las cartas» entre múltiples servidores de output, estos documentos podrían imprimirse de forma desordenada. O puede que un documento ajeno se introduzca involuntariamente en esta serie de documentos. Por fortuna, el software LRS soporta varios enfoques para garantizar que los sistemas están siempre disponibles y que se mantiene la integridad del output.
Otra pregunta recurrente es: «Si estoy ejecutando más de un servidor de output en una configuración activa/pasiva, ¿cómo le puedo decir a un controlador de entrega de aplicaciones qué servidor es el activo?» Tradicionalmente, esto se resolvía haciendo que el dispositivo de alta disponibilidad comprobara si la aplicación estaba conectada con determinados puertos IP, en concreto, IPP, LPR y los puertos de interfaz de aplicaciones. En ocasiones, incluso podemos llamar al servicio web de la aplicación. Pero recientemente, LRS desarrolló una utilidad que puede interrogar a la solución LRS usando un conjunto complejo de reglas heurísticas para determinar la «salud» global del entorno de output. Esta misma utilidad puede gestionar más de dos instancias VPSX y puede incluso ayudar en caso de recuperación automatizada.
También existen varios mecanismos y funciones integrados en la solución LRS y sus componentes de soporte. Por ejemplo, al imprimir desde una aplicación de servidor como SAP, Epic, etc. puede utilizarse el protocolo LRSQ para aumentar la fiabilidad del envío de documentos, así como para especificar un destino alternativo del servidor de output. En caso de que el servidor primario LRS no esté disponible, el flujo de impresión se redirigirá automáticamente hacia un destino secundario. Aunque se trata de una función sencilla, la he visto funcionar espectacularmente bien en situaciones reales cuando todos los demás dispositivos de alta disponibilidad habían fallado (normalmente a causa de un error humano).
La función básica de cola también está integrada en la solución LRS. Esto evita que, cuando se envía un trabajo de impresión al servidor VPSX y, por cualquier motivo, no puede alcanzar el destino final a causa de un problema como un corte de red o un atasco de la impresora, el trabajo se pierda. Podemos esperar durante un periodo de tiempo predeterminado a que el dispositivo esté disponible y entonces enviar el trabajo de impresión. De igual modo, la selección del protocolo de comunicación correcto para la impresora también puede contribuir a aumentar la disponibilidad. Muchas impresoras comerciales soportan el lenguaje PJL (Printer Job Language). Usar comunicaciones PJL con la impresora permite reiniciar un trabajo que fue interrumpido en la página en que se quedó.
Podría seguir horas y horas; existen muchas formas de garantizar la disponibilidad y recuperación de su entorno corporativo de output. El mejor consejo que puedo darle es este: entable una relación consultiva con su equipo de asistencia de LRS. Ellos tienen experiencia real y una amplia red de colegas (incluyéndome a mí) que pueden ayudarle a diseñar un sólido entorno de output. Un entorno capaz de resistir cualquier desafío, a menudo usando la infraestructura existente que su departamento de TI ya posee, comprende y en la que confía.