Software de alta disponibilidad

El software de alta disponibilidad se utiliza para garantizar que los sistemas estén operativos y disponibles la mayor parte del tiempo. La alta disponibilidad se define como un alto porcentaje de tiempo de funcionamiento del sistema. Formalmente, se puede definir como (1 – (tiempo de inactividad/tiempo total))*100%. Si bien la disponibilidad mínima requerida varía según la tarea, los sistemas suelen intentar alcanzar una disponibilidad del 99,999% (cinco nueves). Esta característica es menos robusta que la tolerancia a fallos , que generalmente busca proporcionar una disponibilidad del 100%, aunque con importantes penalizaciones en precio y rendimiento.

El software de alta disponibilidad se mide por su rendimiento ante la falla de un subsistema, su capacidad para reanudar el servicio en un estado similar al del sistema en el momento de la falla original y su capacidad para realizar otras tareas que afectan al servicio (como actualizaciones de software o cambios de configuración) de manera que se elimine o minimice el tiempo de inactividad. Todas las fallas que afectan la disponibilidad (hardware, software y configuración) deben ser abordadas por el software de alta disponibilidad para maximizarla.

Puedes agregar redundancia para lograr alta disponibilidad. Si se hace correctamente, agregar redundancia puede aumentar exponencialmente la disponibilidad y hacer que el sistema general sea altamente disponible. Si tienes N hosts redundantes y paralelos, cada uno con una disponibilidad X, puedes usar la siguiente fórmula: ^{[ 1 ] [ 2 ]}

Disponibilidad de componentes paralelos y redundantes = 1 - (1 - X)^ N

Por ejemplo, si cada uno de sus servidores tiene solo un 50 % de disponibilidad, al usar 10 servidores en paralelo, puede lograr una disponibilidad del 99,9023 %.

Tenga en cuenta que la redundancia no siempre conduce a una mayor disponibilidad. De hecho, la redundancia aumenta la complejidad, lo que a su vez reduce la disponibilidad. Según Marc Brooker, para aprovechar la redundancia, asegúrese de que: ^{[ 3 ]}

1. Se logra una mejora neta positiva en la disponibilidad general del sistema.
2. Sus componentes redundantes fallan de forma independiente.
3. Su sistema puede detectar de forma fiable los componentes redundantes en buen estado.
4. Su sistema puede escalar horizontalmente y verticalmente de forma fiable, incorporando componentes redundantes.

El software típico de alta disponibilidad proporciona características que:

Habilitar la redundancia de hardware y software : Estas características incluyen:

1. El descubrimiento de entidades de hardware y software,
2. La asignación de roles activos/en espera a estas entidades,
3. Detección de componentes defectuosos,
4. Notificación a los componentes redundantes de que deben activarse, y
5. La capacidad de escalar el sistema.

Un servicio no está disponible si no puede atender todas las solicitudes que recibe. La capacidad de escalabilidad horizontal de un sistema se refiere a la habilidad de crear múltiples copias de un subsistema para satisfacer la creciente demanda y distribuir eficientemente el trabajo entrante entre estas copias ( balanceo de carga) , preferiblemente sin apagar el sistema. El software de alta disponibilidad debe permitir la escalabilidad horizontal sin interrumpir el servicio.

Habilitar la comunicación activo/en espera (en particular, el punto de control) : Los subsistemas activos necesitan comunicarse con los subsistemas en espera para garantizar que estos últimos estén listos para continuar donde el activo lo dejó. El software de alta disponibilidad puede proporcionar abstracciones de comunicación, como colas de mensajes y eventos redundantes, para ayudar a los subsistemas activos en esta tarea. Además, un concepto importante llamado "punto de control" es exclusivo del software de alta disponibilidad. En un sistema con punto de control, el subsistema activo identifica todos sus estados críticos y actualiza periódicamente el subsistema en espera con cualquier cambio en dicho estado. Esta idea se suele abstraer como una tabla hash distribuida : el subsistema activo escribe registros clave/valor en la tabla y tanto el subsistema activo como el de espera leen de ella. A diferencia de una tabla hash distribuida en la nube ( Chord (peer-to-peer) , Kademlia , etc.), un punto de control está completamente replicado. Es decir, todos los registros en la tabla hash del punto de control son legibles siempre que al menos una copia esté en ejecución. ^{[ 4 ]} Otra técnica, denominada [punto de control de la aplicación], guarda periódicamente el estado completo de un programa. ^{[ 5 ]}

Habilitar actualizaciones en servicio : La actualización de software en servicio permite actualizar el software sin degradar el servicio. Normalmente se implementa en sistemas redundantes mediante una actualización gradual: se actualiza el sistema en espera mientras el sistema activo presta servicio, se produce la conmutación por error y, a continuación, se actualiza el sistema activo anterior. Otra característica importante es la capacidad de volver rápidamente a una versión anterior del software y la configuración si la nueva versión falla. ^{[ 6 ] [ 7 ]}

Minimizar la latencia de espera y garantizar la corrección de la espera : La latencia de espera se define como el tiempo entre el momento en que se le indica a un sistema de espera que se active y el momento en que realmente presta servicio. Los sistemas de espera "calientes" son aquellos que actualizan activamente su estado interno en respuesta a los puntos de control del sistema activo, lo que resulta en tiempos de inactividad de milisegundos. Los sistemas de espera "fríos" están fuera de línea hasta que el sistema activo falla y, por lo general, se reinician desde un estado de "línea base". Por ejemplo, muchas soluciones en la nube reiniciarán una máquina virtual en otra máquina física si la máquina física subyacente falla. La latencia de la espera por conmutación por error "fría" puede variar desde más de 30 segundos hasta varios minutos. Finalmente, la espera "caliente" es un término informal que abarca todos los sistemas que están en funcionamiento pero que deben realizar algún procesamiento interno antes de activarse. Por ejemplo, un sistema de espera caliente podría estar manejando trabajos de baja prioridad; cuando el sistema activo falla, aborta estos trabajos y lee el estado del punto de control del sistema activo antes de reanudar el servicio. Las latencias de la espera caliente dependen de la cantidad de datos que se almacenan en el punto de control, pero generalmente tienen una latencia de unos pocos segundos.

El software de alta disponibilidad permite a los ingenieros crear arquitecturas de sistemas complejas diseñadas para minimizar el alcance de los fallos y gestionar modos de fallo específicos. Un fallo «normal» se define como aquel que puede ser gestionado por la arquitectura del software, mientras que un fallo «catastrófico» se define como aquel que no puede ser gestionado. Por lo tanto, un fallo catastrófico provoca una interrupción del servicio. Sin embargo, el software puede aumentar considerablemente la disponibilidad al restablecer automáticamente el servicio una vez solucionado el fallo catastrófico.

La configuración más sencilla (o «modelo de redundancia») es 1 activo, 1 en espera, o 1+1. Otra configuración común es N+1 (N activos, 1 en espera), que reduce el coste total del sistema al tener menos subsistemas en espera. Algunos sistemas utilizan un modelo totalmente activo, que tiene la ventaja de que los subsistemas en espera se validan constantemente.

También se pueden definir configuraciones con subsistemas activos, de reserva en caliente y de reserva en frío (o inactivos), extendiendo la nomenclatura tradicional de "activo + reserva" a "activo + reserva + inactivo" (por ejemplo, 5+1+1). Normalmente, los subsistemas de "reserva en frío" o "inactivos" están activos para tareas de menor prioridad. A veces, estos sistemas se ubican lejos de su par redundante en una estrategia denominada redundancia geográfica. ^{[ 8 ]} Esta arquitectura busca evitar la pérdida de servicio por eventos físicamente locales (incendio, inundación, terremoto) mediante la separación de máquinas redundantes.

El software de alta disponibilidad permite especificar políticas sofisticadas para diferenciar los fallos de software de los de hardware, e intentar reiniciar con retardo procesos de software individuales, pilas de software completas o sistemas completos.

En los últimos 20 años, las redes de telecomunicaciones y otros sistemas de software complejos se han convertido en partes esenciales de las actividades empresariales y recreativas.

“Al mismo tiempo [que la economía está en recesión], casi el 60% —es decir, seis de cada diez empresas— requieren una disponibilidad del 99,999%. Esto significa cuatro nueves o cinco nueves de disponibilidad y tiempo de actividad para sus aplicaciones críticas de negocio. Y el 9% de los encuestados, es decir, casi una de cada diez empresas, afirma necesitar un tiempo de actividad superior a cinco nueves. Esto significa cero tiempo de inactividad. En otras palabras, se necesitan aplicaciones y sistemas de hardware realmente a prueba de balas y bombas. Entonces, ¿qué se puede usar? Bueno, una opción son los clústeres de alta disponibilidad o los servidores de tolerancia a fallos, que son más caros y complejos.” ^{[ 9 ]}

Telecomunicaciones : El software de alta disponibilidad es un componente esencial de los equipos de telecomunicaciones, ya que una interrupción de la red puede ocasionar pérdidas significativas de ingresos para los proveedores de telecomunicaciones, y el acceso telefónico a los servicios de emergencia es una cuestión importante de seguridad pública.

Defensa/Militar : Recientemente, el software de alta disponibilidad se ha incorporado a proyectos de defensa como una forma económica de proporcionar disponibilidad para vehículos tripulados y no tripulados ^{[ 10 ].}

Espacio : Se propone un software de alta disponibilidad para el uso de equipos no resistentes a la radiación en entornos espaciales. La electrónica resistente a la radiación es significativamente más cara y de menor rendimiento que los equipos comerciales. Sin embargo, el software de alta disponibilidad que se ejecuta en uno o dos controladores resistentes a la radiación puede gestionar muchos ordenadores redundantes de alto rendimiento no resistentes a la radiación, con la posibilidad de conmutar por error y reiniciarlos en caso de fallo. ^{[ 11 ]}

Los servicios en la nube suelen proporcionar un conjunto de ordenadores en red (normalmente máquinas virtuales) que ejecutan un sistema operativo de servidor estándar como Linux. Estos ordenadores pueden comunicarse gratuitamente con otras instancias dentro del mismo centro de datos (red de inquilinos) y con ordenadores externos pagando una tarifa. La infraestructura en la nube puede ofrecer detección de fallos y reinicios sencillos a nivel de máquina virtual. Sin embargo, los reinicios pueden tardar varios minutos, lo que reduce la disponibilidad. Además, los servicios en la nube no pueden detectar fallos de software dentro de las máquinas virtuales. El software de alta disponibilidad que se ejecuta dentro de las máquinas virtuales en la nube puede detectar fallos de software (y de la máquina virtual) en segundos y utilizar puntos de control para garantizar que las máquinas virtuales en espera estén listas para asumir el servicio.

El Service Availability Forum define estándares para la alta disponibilidad con reconocimiento de aplicaciones. ^{[ 12 ]}

• clúster de computadoras
• Software de alta integridad

• Software de alta disponibilidad OpenClovis SAFplus
• Software Linux-HA archivado el 5 de julio de 2008 en Wayback Machine.
• Keepalived para Linux
• Software Evidian SafeKit para Windows y Linux