La tolerancia a fallos del software es la capacidad del software informático de continuar su funcionamiento normal a pesar de la presencia de fallos del sistema o del hardware . El software tolerante a fallos tiene la capacidad de satisfacer los requisitos a pesar de los fallos. [1] [2]
Los siguientes patrones de diseño se deben combinar para que el sistema sea más tolerante a fallas: reintento, reserva, tiempo de espera, disyuntor y patrón de mamparo. [3] [4]
Para que su sistema sea más tolerante a fallas, debe medir la latencia del percentil 99 y mantener el 1 % restante (también conocido como latencias de cola) bajo control a través de mecanismos de autocuración. [5]
Lo único constante es el cambio. Esto es ciertamente más cierto en los sistemas de software que en casi cualquier otro fenómeno, [6] no todo el software cambia de la misma manera, por lo que los métodos de tolerancia a fallas de software están diseñados para superar los errores de ejecución modificando los valores de las variables para crear un estado de programa aceptable . [7] La necesidad de controlar las fallas de software es uno de los desafíos más crecientes que enfrentan las industrias de software en la actualidad. La tolerancia a fallas debe ser una consideración clave en la etapa inicial del desarrollo de software .
Existen diferentes mecanismos de tolerancia a fallos del software, entre los que destacan:
Las aplicaciones informáticas realizan una llamada mediante la interfaz de programación de aplicaciones (API) para acceder a recursos compartidos, como el teclado, el ratón, la pantalla, la unidad de disco, la red y la impresora. Estos pueden fallar de dos maneras.
Una llamada bloqueada es una solicitud de servicios del sistema operativo que detiene el programa de la computadora hasta que los resultados estén disponibles.
Por ejemplo, la llamada TCP se bloquea hasta que hay una respuesta disponible de un servidor remoto. Esto ocurre cada vez que se realiza una acción con un navegador web. Los cálculos intensivos provocan demoras prolongadas con el mismo efecto que una llamada API bloqueada.
Hay dos métodos utilizados para gestionar el bloqueo.
El subprocesamiento permite una secuencia de ejecución independiente para cada llamada de API que se pueda bloquear. Esto puede evitar que la aplicación general se detenga mientras espera un recurso. Esto tiene la ventaja de que no se pierde ninguna información sobre el estado de la llamada de API mientras se llevan a cabo otras actividades.
Los idiomas con subprocesos incluyen los siguientes.
Los temporizadores permiten interrumpir una llamada bloqueada. Un temporizador periódico permite al programador emular el subprocesamiento. Las interrupciones suelen destruir cualquier información relacionada con el estado de una llamada a la API bloqueada o un cálculo intensivo, por lo que el programador debe realizar un seguimiento de esta información por separado.
Los idiomas sin subprocesos incluyen los siguientes.
Los temporizadores pueden provocar estados corruptos. Esto se evita con lo siguiente.
Las fallas son inducidas por señales en sistemas compatibles con POSIX, y estas señales se originan en llamadas API, en el sistema operativo y en otras aplicaciones.
Cualquier señal que no tenga código de controlador se convierte en una falla que provoca la finalización prematura de la aplicación.
El manejador es una función que se ejecuta a pedido cuando la aplicación recibe una señal. Esto se denomina manejo de excepciones .
La señal de terminación es la única señal que no se puede manejar. Todas las demás señales se pueden dirigir a una función de manejo.
Las funciones del controlador vienen en dos amplias variedades.
Las funciones de controlador inicializadas se emparejan con cada señal cuando se inicia el software. Esto hace que la función de controlador se inicie cuando llega la señal correspondiente. Esta técnica se puede utilizar con temporizadores para emular el subprocesamiento.
Las funciones de controlador en línea se asocian con una llamada mediante una sintaxis especializada. La más conocida es la siguiente, que se utiliza con C++ y Java.
La tolerancia a fallas de hardware para el software requiere lo siguiente.
La copia de seguridad conserva la información en caso de que sea necesario reemplazar el hardware. Esto se puede hacer de dos maneras.
La copia de seguridad requiere una estrategia de restauración de la información para que la información de la copia de seguridad esté disponible en un sistema de reemplazo. El proceso de restauración suele llevar mucho tiempo y la información no estará disponible hasta que se complete el proceso de restauración.
La redundancia se basa en replicar la información en más de un dispositivo informático para que la demora en la recuperación sea breve. Esto se puede lograr mediante la realización de copias de seguridad continuas en un sistema activo que permanece inactivo hasta que se lo necesita (copia de seguridad sincronizada).
Esto también se puede lograr replicando la información a medida que se crea en múltiples sistemas idénticos, lo que puede eliminar el retraso en la recuperación.