Resiliencia de Aplicaciones: Mantenga las Aplicaciones de Windows Disponibles

Introducción

Las aplicaciones de Windows a menudo dependen de mucho más que del servidor que las aloja. Las bases de datos, los servicios de identidad, el almacenamiento, las puertas de enlace, las redes y los puntos finales de los usuarios pueden afectar si una aplicación sigue siendo utilizable durante una interrupción. Este artículo explica cómo los equipos de TI pueden evaluar esas dependencias, diseñar resiliencia en torno a las aplicaciones de Windows existentes, monitorear las capas adecuadas y probar si los planes de recuperación realmente preservan las funciones comerciales en las que confían los usuarios.

¿Qué es la resiliencia de aplicaciones?

La resiliencia de la aplicación es la capacidad de una aplicación y la infraestructura que la rodea para continuar proporcionando funciones vitales durante una interrupción y recuperarse de manera predecible después de una falla.

La interrupción puede ser pequeña o grande, y las causas pueden variar desde fallos de hardware o del sistema operativo, bloqueos de aplicaciones, actualizaciones fallidas, caídas de bases de datos, interrupciones de red, fallos de autenticación, agotamiento de recursos, dependencias no disponibles o incidentes de seguridad.

Una arquitectura resiliente reconoce que las fallas son inevitables, y en lugar de intentar prevenir cada incidente, las organizaciones de TI buscan limitar el impacto de cada uno y establecer procedimientos de recuperación controlados para mantener o restaurar el servicio.

La resiliencia de la aplicación es más que el tiempo de actividad del servidor

Un error común es usar la disponibilidad de un servidor como un proxy para la disponibilidad de la aplicación, que se ejecuta en el servidor.

Para que una aplicación empresarial esté verdaderamente disponible, es necesario que varios componentes estén disponibles al mismo tiempo:

Infraestructura → Sistema operativo → Aplicación → Dependencias → Ruta de acceso → Sesión de usuario → Proceso empresarial

Un problema con cualquier elemento en esta cadena puede resultar en que la aplicación esté efectivamente no disponible.

Por ejemplo, un servidor de aplicaciones puede estar saludable mientras su base de datos es inaccesible. Una aplicación publicada puede estar funcionando correctamente, pero una falla en la puerta de enlace hace que sea imposible para los empleados remotos acceder a ella. Los usuarios incluso pueden iniciar la aplicación con éxito, pero se les puede impedir completar una transacción porque un servicio de licencia, archivo o backend no está disponible.

La resiliencia de la aplicación, por lo tanto, debe medirse en función de la capacidad del usuario para realizar la tarea comercial necesaria, en lugar de si un servidor puede responder a una verificación de disponibilidad o salud.

¿Por qué es diferente la resiliencia de aplicaciones para aplicaciones de Windows?

Las prácticas modernas de resiliencia se centran cada vez más en aplicaciones nativas de la nube, contenedores, microservicios y orquestación automatizada. Si bien estos son enfoques valiosos, no siempre son aplicables a todas las organizaciones.

Muchas organizaciones tienen aplicaciones empresariales heredadas de Windows que se desarrollaron antes de que las arquitecturas nativas de la nube fueran comunes. El software ERP, las aplicaciones de contabilidad, las aplicaciones de fabricación, las aplicaciones de atención médica, las aplicaciones de ingeniería y las aplicaciones desarrolladas internamente pueden ser críticas para las operaciones de una organización.

Reestructurar estas aplicaciones como microservicios puede ser extremadamente costoso, técnicamente desafiante o incluso completamente inviable si la organización no controla el código fuente.

En tales casos, puede haber un valor significativo en hacer que las operaciones en torno a la aplicación sean más resilientes, en lugar de intentar hacer que la aplicación en sí misma sea más resiliente. Publicación de aplicaciones puede ser parte de este enfoque al mantener las aplicaciones de Windows existentes en una infraestructura centralizada mientras se cambia la forma en que los usuarios acceden a ellas. Esto puede incluir cambios en la infraestructura que aloja la aplicación, como eliminar las limitaciones de infraestructura, crear hosts de aplicación redundantes, habilitar métodos de acceso alternativos e implementar procedimientos de recuperación más rápidos para el host de la aplicación.

¿En qué caso podría fallar la disponibilidad de una aplicación de Windows?

Construir la resiliencia de la aplicación comienza con descubrir los componentes que se necesitan para entregar con éxito una aplicación desde sus anfitriones a los usuarios. Este proceso destaca los posibles puntos de falla que pueden derribar toda una aplicación.

Hosts de Aplicaciones

Una aplicación que se ejecuta en un solo servidor Windows tiene un claro punto único de falla.

Problemas de hardware, actualizaciones de Windows, corrupción del sistema operativo, agotamiento de recursos o fallos de aplicaciones pueden interrumpir a cada usuario que dependa de esa máquina. Si se requieren necesidades de disponibilidad, se pueden implementar múltiples hosts de aplicaciones para reducir la dependencia de una sola máquina y proporcionar capacidad cuando un servidor se vuelve no disponible.

Bases de datos, almacenamiento y otras dependencias

Muchas aplicaciones de Windows dependen de servicios externos al host de la aplicación. Estos servicios pueden incluir:

• bases de datos SQL
• comparticiones de archivos
• servidores de licencias
• Active Directory
• Sistema de Nombres de Dominio (DNS)
• certificados
• APIs
• middleware
• almacenamiento en red
• infraestructura de impresión

Introducir un segundo servidor de aplicaciones proporciona una resiliencia mínima si comparten una base de datos común o una dependencia de almacenamiento que no está disponible. Se hace evidente que el mapeo de dependencias necesita extenderse más allá de la infraestructura de aplicaciones visible.

Autenticación e Identidad

Los usuarios no pueden acceder a una aplicación saludable si la infraestructura de autenticación necesaria no está disponible.

Los equipos de TI necesitan identificar los servicios de identidad de los que dependen sus aplicaciones críticas y asegurarse de que tienen planes de recuperación en caso de que estos recursos sean inaccesibles. Active Directory, plataformas de identidad en la nube, servicios de autenticación multifactor (MFA) y puertas de enlace de autenticación pueden ser utilizados para proporcionar una cadena de disponibilidad para una aplicación.

Red y Rutas de Acceso Remoto

Para las aplicaciones de Windows centralizadas, la conectividad entre los usuarios y el entorno de la aplicación representa otro posible dominio de fallo.

Imaginemos la cadena completa:

Dispositivo del usuario → Internet o LAN → puerta de enlace → host de aplicación → servicios de backend

Un fallo en cualquier parte de esta cadena puede impedir que los usuarios realicen su trabajo, incluso si la aplicación está funcionando correctamente. Esto es particularmente relevante para organizaciones distribuidas donde la aplicación puede estar activa y funcionando en el centro de datos, pero inaccesible para los usuarios en otra ubicación.

Puntos finales

La resiliencia de la aplicación no requiere necesariamente que la estación de trabajo normal de un usuario esté disponible.

Ofrecer a los usuarios autorizados los medios para acceder a aplicaciones alojadas de forma central desde un dispositivo alternativo o a través de un navegador puede garantizar el acceso, si un portátil se vuelve inaccesible, una oficina se vuelve inaccesible o los empleados necesitan trabajar desde una ubicación diferente.

La arquitectura de entrega de aplicaciones puede ser un componente de una estrategia más amplia de continuidad del negocio.

¿Cuál es el proceso para construir la resiliencia de aplicaciones para aplicaciones de Windows?

Ninguna tecnología única hace que la aplicación sea resistente. Los equipos de TI, en cambio, deben reducir el número de fallos que pueden hacer que una función completa se caiga y prepararse para mecanismos de recuperación controlada para aquellos que permanecen.

1. Identificar aplicaciones críticas y procesos empresariales

No todas las aplicaciones requieren el mismo grado de protección. Comience por determinar qué aplicaciones soportan operaciones primarias, en cuáles confían los usuarios y su tolerancia al tiempo de inactividad.

Dos objetivos de recuperación traducen los requisitos comerciales en especificaciones técnicas. La guía de planificación de contingencias del NIST define el Objetivo de Tiempo de Recuperación (RTO) y el Objetivo de Punto de Recuperación (RPO) como parámetros clave para determinar los requisitos de recuperación:

• Objetivo de Tiempo de Recuperación (RTO): una duración de tiempo de inactividad aceptable antes de que se restablezca el servicio.
• Objetivo de Punto de Recuperación (RPO): un intervalo de pérdida de datos aceptable, medido en tiempo.

Una aplicación utilizada intensivamente para procesar pedidos puede tener un RTO de minutos, mientras que una aplicación de informes financieros que se ejecuta una vez a la semana puede permitirse días de inactividad.

RTO y RPO definen el tipo de protección necesaria para una aplicación: conmutación por error instantánea, restablecimiento rápido de servicios o simplemente un procedimiento de recuperación documentado.

2. Mapee toda la cadena de dependencia de la aplicación

Documenta todo lo que tiene que estar para que la aplicación haga su trabajo.

No te detengas en el ejecutable o el servidor de Windows. No olvides las bases de datos, el almacenamiento, la autenticación, el DNS, la red, los certificados, los sistemas de licencias, los gateways y los servicios externos.

Para cada uno, pregunta:

¿Qué pasa con la aplicación si esto desaparece?

Este ejercicio revelará puntos únicos de falla ocultos y establecerá la secuencia de recuperación. Restaurar un host de aplicación primero no ayuda mucho si su base de datos, servicio de identidad o almacenamiento aún no están disponibles.

3. Eliminar puntos únicos críticos de fallo

Una vez que se establece el árbol de dependencias, determine qué componentes deben hacerse redundantes, según la importancia comercial y los objetivos de recuperación.

En el caso de la entrega de aplicaciones de Windows, esto podría implicar el despliegue de varios servidores de aplicaciones en lugar de depender de las capacidades de un solo host. Con una capa de balanceo de carga, las sesiones pueden distribuirse entre las instancias de aplicaciones durante las operaciones normales. En caso de una falla del host, las conexiones entrantes pueden ser dirigidas a instancias de servidores de aplicaciones saludables.

La planificación de redundancia debe estar informada por el análisis de dependencia, sin embargo. Múltiples servidores de aplicaciones que acceden a una única base de datos crítica, puerta de enlace de red o capa de almacenamiento aún presentan un único punto de falla.

El diseño de alta disponibilidad debe, por lo tanto, considerar el servicio de aplicación como una entidad integrada. Para entornos de Windows Server que requieren redundancia a nivel de infraestructura, Documentación de Clustering de Conmutación por Error de Microsoft proporciona más orientación sobre topologías de alta disponibilidad y recuperación ante desastres.

4. Separar aplicaciones de puntos finales individuales

Instalar una aplicación crítica directamente en la estación de trabajo de cada empleado puede crear un tipo diferente de problema de resiliencia. Si los usuarios pierden el acceso a su computadora habitual, también podrían perder el acceso a las aplicaciones que necesitan para continuar trabajando.

Centralizando aplicaciones en hosts de Windows gestionados y presentar la interfaz de la aplicación a los usuarios elimina este riesgo. Los datos y el estado de la aplicación se almacenan en el host de Windows gestionado y se accede a ellos a través de puntos finales autorizados.

Al hacer esto, hacemos que la aplicación esté disponible para los usuarios incluso si cambian de dispositivos o ubicaciones. Si bien la centralización de aplicaciones no elimina los problemas de infraestructura, ayuda a trasladarla a un entorno donde puede ser controlada por TI.

5. Proporcionar más de un método de acceso práctico

La resiliencia también se puede lograr evitando una dependencia innecesaria de un solo tipo de punto final o método de conexión.

Dependiendo de la arquitectura de entrega de aplicaciones, los usuarios pueden utilizar diferentes acceso remoto métodos, incluyendo un cliente compatible con RDP, lanzador de aplicaciones dedicado, portal web o sesión de navegador HTML5.

Los métodos de conexión alternativos no deben confundirse con la redundancia de infraestructura. Si todos dependen del mismo servidor fallido, la aplicación sigue sin estar disponible.

Proporcionan resiliencia de acceso cuando la interrupción afecta el dispositivo normal de un usuario, el cliente instalado o la ubicación en lugar del servicio de aplicación en sí.

6. Monitorear antes de que la degradación se convierta en una interrupción

La resiliencia de la aplicación no solo se trata de la recuperación, sino que una detección lo suficientemente temprana puede evitar la degradación en una interrupción.

Los indicadores útiles en entornos de aplicaciones de Windows son la utilización de CPU, la presión de memoria, la capacidad del disco y E/S, la utilización de red, las sesiones activas, el proceso de aplicación, el tiempo de respuesta, la conexión fallida y la disponibilidad de servicios dependientes.

Monitoreo de tendencias es crucial, ya que un servidor que se acerca repetidamente a sus límites puede seguir en línea mientras la experiencia del usuario se deteriora gradualmente.

Las alertas de umbral permiten a los administradores investigar los precursores de un incidente antes de que los usuarios pierdan el acceso.

7. Plan para picos de capacidad y conmutación por error

Una aplicación que sobrevive a fallos a nivel de hardware pero que queda completamente incapacitada para funcionar bajo demandas aumentadas no es verdaderamente resistente a fallos de ningún tipo.

La planificación de la capacidad debe tener en cuenta no solo los patrones de uso diario, sino también considerar los picos debido a demandas estacionales, cambios de turnos, crecimiento o requisitos de alojamiento para otras aplicaciones.

Particularmente en entornos de alojamiento multi-servidor, la pérdida de un solo servidor debe ser compensada asegurando que otros nodos de alojamiento tengan capacidad adicional para acomodar cualquier proceso que de otro modo se ejecutaría en el nodo fallido.

De lo contrario, los procedimientos de conmutación por error pueden convertir un incidente aislado en un problema de rendimiento del sistema más amplio.

8. Proteger datos y configuración

Un servidor Windows de reemplazo es de poca utilidad si el departamento de TI no puede restaurar los componentes necesarios para hacer que la aplicación funcione.

Esto podría significar que los procedimientos de respaldo deben incluir datos de la aplicación, bases de datos, archivos de configuración, certificados, configuraciones de la aplicación, perfiles de usuario, configuración de infraestructura, scripts e información de licencias.

La estrategia variará dependiendo del Objetivo de Tiempo de Recuperación (RTO) y del Objetivo de Punto de Recuperación (RPO) de la aplicación.

Sobre todo, asegúrese de que una copia de seguridad exitosa no sea igual a una recuperación exitosa. Los equipos de TI deben probar que es posible restaurar todo el servicio de aplicación a partir de datos protegidos y configuración.

9. Reducir el radio de explosión de los cambios

No siempre se trata de un desastre imprevisto que causa interrupciones. También pueden ser causadas por mejoras implementadas. Así, los parches de Windows, las actualizaciones de aplicaciones y controladores, así como los cambios en la política de seguridad y configuración, también pueden tener un impacto negativo en la disponibilidad de la aplicación. Se recomienda evitar realizar cambios similares en todos los hosts de producción al mismo tiempo, si es posible.

En una configuración de múltiples servidores, es posible realizar los cambios de mejora en etapas, lo que permite al administrador asegurarse de que todo esté funcionando correctamente. La capacidad de revertir los cambios realizados también es esencial.

Así, al diseñar procedimientos de contingencia, también se deben considerar las opciones de reversión. El proceso debe estar debidamente documentado y el personal debe saber qué hacer si un cambio falla, en lugar de dejarlo simplemente a su criterio.

10. Diseño para degradación elegante

La resiliencia no se trata de mantener el 100% de las funciones normales en funcionamiento en todo momento.

En algunos casos, mantener las operaciones para usuarios o aplicaciones clave puede ser más importante que mantener todos los servicios disponibles para todos los usuarios. Las prioridades se pueden establecer antes de que ocurra un incidente por parte de los equipos de TI.

Si hay capacidad disponible que se puede utilizar, puede tener sentido asignarla primero a producción, servicio al cliente, finanzas u otras funciones.

Eso es una degradación elegante: mantener la capacidad de ejecutar las funciones que generan el mayor valor comercial, en lugar de permitir que la falla de elementos menos críticos haga que todo el sistema colapse.

¿Cómo deben los equipos de TI monitorear la resiliencia de las aplicaciones?

El monitoreo de servidores individuales puede ser útil, pero el monitoreo de la resiliencia debe reflejar el servicio total de la aplicación tal como lo perciben los usuarios.

Un modelo realista comprende varias capas:

Capa	Qué monitorear	Ejemplo de fallo
Anfitrión	CPU, RAM, disco, disponibilidad del sistema operativo	Servidor sobrecargado o fuera de línea
Aplicación	Estado del proceso y servicio	Los fallos de la aplicación
Dependencia	Base de datos, DNS, identidad, almacenamiento	La aplicación se inicia pero no puede operar.
Acceso	Puerta de enlace, portal, ruta de red	Los usuarios no pueden conectarse
Sesión	Usuarios activos, fallos, latencia	La aplicación está en línea pero no se puede usar.
Función empresarial	Finalización exitosa del flujo de trabajo	El usuario no puede completar la tarea requerida.

La capa de función empresarial es una de las más simples de pasar por alto.

Los paneles de infraestructura pueden mostrar todos los servidores, servicios y rutas de red como saludables, mientras que el flujo de trabajo de un usuario real está comprometido. Por lo tanto, es importante que las aplicaciones críticas monitoreen su salud desde la perspectiva de la operación que están diseñadas para apoyar.

¿Cómo se debe probar la resiliencia de la aplicación?

Una arquitectura de resiliencia que nunca ha experimentado una falla controlada contiene suposiciones no probadas.

Utilice pruebas para evaluar la respuesta del sistema cuando los componentes clave se vuelven indisponibles. Las pruebas deben incluir llevar un host de aplicación fuera de línea, detener un servicio de aplicación, simular la pérdida de una ruta de red, verificar el comportamiento del gateway o del balanceo de carga, restaurar desde una copia de seguridad y acceder a la aplicación desde un punto final alternativo.

Los procesos de prueba deben extenderse más allá de los aspectos técnicos de la recuperación. Los equipos de TI deben revisar si se están enviando alertas al personal administrativo correcto, si los pasos de recuperación se están realizando en la secuencia correcta y si los usuarios pueden realizar una tarea comercial real después de que se hayan restaurado los servicios.

Los procedimientos operativos son fundamentales para un sistema resiliente. Procedimientos de escalación de alertas: ¿quién recibe la alerta? ¿Quién tiene la autoridad para iniciar la conmutación por error? ¿Dónde se almacenan la documentación de recuperación y las credenciales? ¿Qué dependencia debe estar en línea primero?

La redundancia técnica proporciona poco beneficio si los procesos para recuperar el acceso no han sido probados.

¿Qué puede ser la lista de verificación de resiliencia de la aplicación?

Antes de embarcarse en una aplicación crítica de Windows resistente, los equipos de TI deben poder responder las siguientes preguntas:

• ¿Qué procesos empresariales dependen de la aplicación?
• ¿Cuáles son su RTO y RPO?
• ¿Qué servidores, bases de datos y servicios externos requiere?
• ¿Dónde están sus puntos críticos de fallo únicos?
• ¿Puede otro host de aplicación aceptar usuarios si uno falla?
• ¿Pueden los usuarios conectarse si su punto final o ubicación normal no está disponible?
• ¿Hay suficiente capacidad adicional para un funcionamiento degradado?
• ¿Se monitorean activamente los problemas de infraestructura, dependencia y sesión?
• ¿Se alerta a los administradores antes de que los umbrales importantes se conviertan en interrupciones?
• ¿Están protegidos los datos y la configuración de la aplicación?
• ¿Se ha probado realmente la restauración?
• ¿Se pueden revertir los cambios problemáticos?
• ¿Está documentada la secuencia de recuperación?
• ¿Pueden los usuarios completar el proceso empresarial requerido después de la recuperación?

No todas las respuestas requieren una infraestructura de alta disponibilidad costosa. El nivel adecuado de protección depende del costo y del impacto operativo del tiempo de inactividad.

Lo que importa es que las decisiones sobre disponibilidad, redundancia y recuperación se tomen de manera deliberada, en lugar de asumirse.

¿Cómo puede TSplus ayudar a mantener disponibles las aplicaciones de Windows?

Para organizaciones que dependen de aplicaciones de Windows existentes, podemos ayudar a mejorar la disponibilidad centralizando las aplicaciones en servidores Windows gestionados y entregándolas a los usuarios a través de clientes compatibles con RDP, acceso estilo RemoteApp o un portal web HTML5. Esto reduce la dependencia de los puntos finales individuales de los usuarios y brinda a los equipos de TI más flexibilidad cuando los usuarios necesitan conectarse desde otro dispositivo o ubicación.

TSplus Acceso Remoto también puede soportar implementaciones de múltiples servidores con balanceo de carga y acceso basado en gateway. Cuando se combina con bases de datos resilientes, almacenamiento, servicios de identidad y redes, esta arquitectura puede reducir la dependencia de un único host de aplicación y ayudar a mantener el acceso a aplicaciones críticas de Windows durante la interrupción de la infraestructura.

Conclusión

La resiliencia de la aplicación depende de comprender el camino completo entre la infraestructura y el uso empresarial. La redundancia, el monitoreo, la copia de seguridad, la planificación de capacidad y los procedimientos de recuperación son más efectivos cuando se diseñan en torno a dependencias de aplicación y objetivos de recuperación claramente definidos.

Para las aplicaciones de Windows existentes, la resiliencia a menudo proviene de fortalecer el entorno que rodea al software en lugar de reconstruir la aplicación en sí. La prueba clave sigue siendo simple: cuando ocurre una interrupción, ¿pueden los usuarios continuar trabajando o puede TI restaurar la función comercial requerida dentro de la ventana de recuperación acordada?