Dos servidores de aplicación pueden compartir un punto de fallo

Un segundo servidor de aplicación puede asumir el trabajo de un proceso averiado. Que el cliente pueda continuar también depende de los componentes compartidos. Por eso, la siguiente inversión debería cubrir un fallo identificado, en vez de limitarse a aumentar el número de servidores.

Microsoft recomienda considerar la redundancia de cómputo, datos y red a lo largo de los flujos críticos. Duplicar la capa de aplicación todavía no resuelve la cuestión del flujo completo.

Hacer visible el camino compartido

En el ejemplo ficticio, los clientes abren una lista de proyectos. Dos instancias de aplicación en máquinas virtuales distintas leen la misma base de datos. Delante hay un único balanceador de carga operado por el equipo. Distribuye solicitudes; no se trata de un servicio de acceso gestionado con redundancia interna. Los datos de sesión necesarios para continuar no se guardan únicamente en una instancia de aplicación.

Los identificadores de la tabla pertenecen solo a este ejemplo. Inicialmente no hay sustituto para la base de datos ni para el balanceador. La tabla describe efectos esperados, no disponibilidad medida.

Qué fallo puede cubrir la segunda instancia

Incluso el primer caso es una expectativa que debe probarse. Si la máquina restante se sobrecarga o el encaminamiento no funciona, su mera existencia no basta. Dos VM también pueden compartir ubicación, alimentación eléctrica u otra infraestructura; los dominios de fallo reales deben ajustarse al requisito.

Tratar específicamente la capa de datos compartida

Si la lista debe seguir disponible cuando falla la base de datos, la capa de datos necesita un enfoque adecuado de disponibilidad y conmutación. Deben aclararse la pérdida de datos aceptable, la coherencia y el comportamiento de las escrituras en curso. Un segundo proceso de base de datos tampoco demuestra por sí solo una continuidad segura.

Microsoft distingue las réplicas en funcionamiento de las copias de seguridad de un momento determinado. Una copia sirve para restaurar; no es automáticamente una base de datos de sustitución en marcha e inmediatamente disponible. La replicación no sustituye una restauración probada tras un cambio involuntario de datos. Las medidas necesarias dependen del objetivo del negocio.

Decidir a partir del flujo de usuario afectado

El análisis de fallos de Microsoft sigue cada flujo crítico y sus dependencias internas y externas. En nuestro ejemplo, los tres casos de la tabla deberían probarse por separado en un entorno autorizado. Deben registrarse detección, comportamiento al cargar la lista, recuperación y rol responsable.

Si un procedimiento de recuperación acordado cubre suficientemente una interrupción de la base, la instancia adicional puede seguir siendo útil ante fallos de proceso o para mantenimiento. Si el negocio exige continuar durante un fallo de base de datos o acceso, esas carencias permanecen. No puede deducirse un porcentaje de disponibilidad del número de máquinas.

Fuentes

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup