Hispanopedia WikiLa tolerancia a fallos del software es la capacidad del software informático para 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 cumplir los requisitos a pesar de los fallos. [ 1 ] [ 2 ]
Se deben combinar los siguientes patrones de diseño para hacer que el sistema sea más tolerante a fallos: reintento, reserva, tiempo de espera, disyuntor y patrón de mamparo. [ 3 ] [ 4 ]
Para que su sistema sea más tolerante a fallos, debe medir la latencia del percentil 99 y mantener bajo control el 1% restante ( también conocida como latencias de cola) mediante mecanismos de autorreparación. [ 5 ]
Introducción
En los sistemas de software, el cambio es una constante. 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 fallos 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 los fallos de software es uno de los desafíos más crecientes que enfrentan las industrias de software en la actualidad. La tolerancia a fallos debe ser una consideración clave en la etapa inicial del desarrollo de software .
Existen diferentes mecanismos para la tolerancia a fallos del software, entre los que se incluyen:
- Bloques de recuperación
- Software de versión N
- Software de autocomprobación
Fallo del sistema operativo
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.
- Llamadas bloqueadas
- Fallos
Llamadas bloqueadas
Una llamada bloqueada es una solicitud de servicios al sistema operativo que detiene el programa informático hasta que se obtengan los resultados.
Por ejemplo, la llamada TCP se bloquea hasta que se recibe una respuesta de un servidor remoto. Esto ocurre cada vez que se realiza una acción con un navegador web . Los cálculos complejos provocan retrasos prolongados con el mismo efecto que una llamada a la API bloqueada.
Existen dos métodos para gestionar los bloqueos.
- Trapos
- Temporizadores
El uso de subprocesos permite una secuencia de ejecución independiente para cada llamada a la API que puede bloquearse. Esto evita que la aplicación se detenga mientras espera un recurso. La ventaja es que no se pierde información sobre el estado de la llamada a la API mientras se realizan otras actividades.
Los lenguajes multihilo incluyen los siguientes.
Los temporizadores permiten interrumpir una llamada bloqueada. Un temporizador periódico permite al programador emular el uso de subprocesos. 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 mantener un registro de esta información por separado.
Los lenguajes no multihilo incluyen los siguientes.
Se producirá un estado corrupto con los temporizadores. Esto se evita con lo siguiente.
Fallos
En los sistemas compatibles con POSIX, las fallas son inducidas por señales , y estas señales se originan en llamadas a la API, en el sistema operativo y en otras aplicaciones.
Cualquier señal que no tenga un código de controlador se convierte en un fallo que provoca la terminación prematura de la aplicación.
El manejador es una función que se ejecuta bajo demanda cuando la aplicación recibe una señal. Esto se denomina manejo de excepciones .
La señal de terminación es la única que no se puede gestionar. Todas las demás señales se pueden dirigir a una función controladora.
Las funciones de controlador se presentan en dos grandes variedades.
- Inicializado
- En línea
Las funciones de controlador inicializadas se asocian a cada señal al iniciar el software. Esto provoca que la función de controlador se ejecute cuando llega la señal correspondiente. Esta técnica se puede utilizar con temporizadores para simular el uso de subprocesos.
Las funciones de controlador en línea se asocian a una llamada mediante una sintaxis especializada. La más conocida es la siguiente, utilizada en C++ y Java.
- intentar {
- Llamada a la API();
- } atrapar {
- código_manejador_señal;
- }
Fallo de hardware
La tolerancia a fallos 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.
- Copia de seguridad automática programada mediante software
- Copias de seguridad manuales periódicas
- Restauración de información
La copia de seguridad requiere una estrategia de restauración de la información para que esta esté disponible en un sistema de reemplazo. El proceso de restauración suele ser largo y la información no estará disponible hasta que finalice.
La redundancia se basa en replicar la información en más de un dispositivo informático para que el tiempo de recuperación sea breve. Esto se puede lograr mediante copias de seguridad continuas en un sistema activo que permanece inactivo hasta que sea necesario (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.
Véase también
Referencias
- ↑ "Tolerancia a fallos de software" . Universidad Carnegie Mellon.
- ↑ "Sistemas de software portátiles y tolerantes a fallos" (PDF) . Instituto Tecnológico de Massachusetts.
- ↑ Microservicios nativos de Kubernetes con Quarkus y MicroProfile . Manning. 2022. ISBN 9781638357155.
- ↑ Cómo superar la entrevista de diseño de sistemas . Manning. 2024. ISBN 9781638355915.
- ↑ Vitillo, Roberto (2021). Comprensión de los sistemas distribuidos: Lo que todo desarrollador debería saber sobre las grandes aplicaciones distribuidas . Roberto Vitillo. ISBN 978-1838430207.
- ↑ Eckhardt, DE, "Diferencias fundamentales en la fiabilidad de la redundancia N-modular y la programación N-version", The Journal of Systems and Software, 8, 1988, pp. 313–318.
- ↑ Ray Giguette y Johnette Hassell, “Hacia un método ingenioso de tolerancia a fallos de software”, conferencia regional del sureste de la ACM, abril de 1999.
Lecturas adicionales
- Tolerancia a fallos de software, por Chris Inacio en la Universidad Carnegie Mellon (1998)
- Calidad del software
- Arquitectura de software
- Tolerancia a fallos