La tolerancia a fallas de software es la capacidad del software de computadora para continuar su operación normal a pesar de la presencia de fallas del sistema o del hardware . El software tolerante a fallas tiene la capacidad de satisfacer los requisitos a pesar de las fallas. [1] [2]
Introducción
Lo único constante es el cambio. Esto es ciertamente más cierto en los sistemas de software que en casi cualquier fenómeno, [3] 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 . [4] La necesidad de controlar las fallas del software es uno de los desafíos más crecientes que enfrentan las industrias del 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 de software, entre los que se encuentran:
- Bloques de recuperación
- Software versión N
- Software de autocomprobación
Fallo del sistema operativo
Las aplicaciones informáticas realizan una llamada utilizando la interfaz de programación de aplicaciones (API) para acceder a recursos compartidos, como el teclado, el mouse, la pantalla, la unidad de disco, la red y la impresora. Estos pueden fallar de dos formas.
- Llamadas bloqueadas
- Fallas
Llamadas bloqueadas
Una llamada bloqueada es una solicitud de servicios del sistema operativo que detiene el programa de computadora hasta que los resultados estén disponibles.
Por ejemplo, la llamada TCP se bloquea hasta que se dispone de una respuesta de un servidor remoto. Esto ocurre cada vez que realiza una acción con un navegador web. Los cálculos intensivos provocan retrasos prolongados con el mismo efecto que una llamada API bloqueada.
Hay dos métodos que se utilizan para manejar el bloqueo.
- Hilos
- Temporizadores
El subproceso permite una secuencia de ejecución independiente para cada llamada a la API que se puede 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 a la API mientras se llevan a cabo otras actividades.
Los idiomas con subprocesos incluyen los siguientes.
Ada | Afnix | C ++ | C# | CILK | Eiffel | Erlang |
Java | Ceceo | Magenta | Modula 3 | Napier 88 | Onz | Presto |
pSather | Perl 5.8.7+ | PHP | Pitón | R | Rubí | Charla |
Tcl / Tk | V |
Los temporizadores permiten interrumpir una llamada bloqueada. Un temporizador periódico permite al programador emular el enhebrado. Las interrupciones normalmente destruyen cualquier información relacionada con el estado de una llamada API bloqueada o un cálculo intensivo, por lo que el programador debe realizar un seguimiento de esta información por separado.
Los lenguajes sin subprocesos incluyen los siguientes.
Intento | Javascript | SQL | Visual Basic |
Se producirá un estado corrupto con los temporizadores. Esto se evita con lo siguiente.
Fallas
Las fallas son inducidas por señales en sistemas compatibles con POSIX, y estas señales se originan en llamadas a API, desde el sistema operativo y desde otras aplicaciones.
Cualquier señal que no tenga un código de controlador se convierte en una falla que causa la terminación prematura de la aplicación.
El controlador es una función que se realiza a pedido cuando la aplicación recibe una señal. A esto se le llama 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 pueden dirigirse a una función de controlador.
Las funciones del controlador vienen en dos amplias variedades.
- Inicializado
- En línea
Las funciones del 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 enhebrado.
Las funciones de controlador en línea se asocian con una llamada utilizando una sintaxis especializada. El más familiar es el siguiente que se usa con C ++ y Java.
- intentar
- {
- API_call ();
- }
- captura
- {
- signal_handler_code;
- }
Fallo de hardware
La tolerancia a fallas de hardware para el software requiere lo siguiente.
La copia de seguridad mantiene información en caso de que deba reemplazarse el hardware. Esto se puede hacer de dos formas.
- Copia de seguridad programada automática mediante software
- Copia de seguridad manual en un horario regular
- Restauración de información
La copia de seguridad requiere una estrategia de restauración de 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 la replicación de información en más de un dispositivo informático para que el retraso de recuperación sea breve. Esto se puede lograr utilizando una copia de seguridad continua en un sistema activo que permanece inactivo hasta que se necesite (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.
Ver también
- Autoprueba incorporada
- Equipo de prueba incorporado
- Diseño tolerante a fallas
- Sistema tolerante a fallas
- Sistema informático tolerante a fallas
- Programación consciente de la inmunidad
- Autoprueba integrada de lógica
- Programación de la versión N
- Ingeniería de Seguridad
- OpenSAF: API de disponibilidad de servicios
Referencias
- ^ "Tolerancia a fallas de software" . Universidad de Carnegie mellon.
- ^ "Sistemas de software portátiles y tolerantes a fallas" (PDF) . Instituto de Tecnología de Massachusetts.
- ^ Eckhardt, DE, "Diferencias fundamentales en la confiabilidad de la redundancia N-Modular y la programación de N-Versión", The Journal of Systems and Software, 8, 1988, págs. 313–318.
- ^ Ray Giguette y Johnette Hassell, "Hacia un método ingenioso de tolerancia a fallas de software", Conferencia regional del Sudeste de ACM, abril de 1999.