De Wikipedia, la enciclopedia libre
  (Redirigido de tolerante a fallas )
Saltar a navegación Saltar a búsqueda

La tolerancia a fallas es la propiedad que permite que un sistema continúe funcionando correctamente en caso de falla de (o una o más fallas dentro) de algunos de sus componentes. Si su calidad operativa disminuye en absoluto, la disminución es proporcional a la gravedad de la falla, en comparación con un sistema diseñado ingenuamente, en el que incluso una pequeña falla puede causar una falla total. La tolerancia a fallas se busca particularmente en sistemas de alta disponibilidad o críticos para la vida . La capacidad de mantener la funcionalidad cuando fallan partes de un sistema se conoce como degradación elegante . [1]

Un diseño tolerante a fallas permite que un sistema continúe con su operación prevista, posiblemente a un nivel reducido, en lugar de fallar por completo, cuando falla alguna parte del sistema . [2] El término se usa más comúnmente para describir sistemas informáticos diseñados para continuar más o menos completamente operativos con, tal vez, una reducción en el rendimiento o un aumento en el tiempo de respuesta en caso de alguna falla parcial. Es decir, el sistema en su conjunto no se detiene debido a problemas ni en el hardware ni en el software.. Un ejemplo en otro campo es un vehículo de motor diseñado para que siga siendo manejable si uno de los neumáticos se pincha, o una estructura que puede mantener su integridad en presencia de daños debido a causas como fatiga , corrosión , fabricación. defectos o impacto.

Dentro del alcance de un sistema individual , la tolerancia a fallas se puede lograr anticipando condiciones excepcionales y construyendo el sistema para enfrentarlas y, en general, apuntando a la autoestabilización para que el sistema converja hacia un estado libre de errores. Sin embargo, si las consecuencias de una falla del sistema son catastróficas, o el costo de hacerlo suficientemente confiable es muy alto, una mejor solución puede ser utilizar alguna forma de duplicación. En cualquier caso, si la consecuencia de una falla del sistema es tan catastrófica, el sistema debe poder usar la reversión para volver a un modo seguro. Esto es similar a la recuperación de reversión, pero puede ser una acción humana si hay humanos presentes en el circuito.

Historia [ editar ]

La primera computadora tolerante a fallas conocida fue SAPO , construida en 1951 en Checoslovaquia por Antonín Svoboda . [3] : 155 Su diseño básico era de tambores magnéticos conectados a través de relés, con un método de votación de detección de errores de memoria ( triple redundancia modular ). Varias otras máquinas se desarrollaron a lo largo de esta línea, principalmente para uso militar. Finalmente, se separaron en tres categorías distintas: máquinas que durarían mucho tiempo sin ningún mantenimiento, como las que se utilizan en las sondas y satélites espaciales de la NASA. ; computadoras que eran muy confiables pero requerían un monitoreo constante, como las que se usaban para monitorear y controlar plantas de energía nuclear o experimentos de supercolisionadores ; y finalmente, computadoras con una gran cantidad de tiempo de ejecución que estarían sometidas a un uso intensivo, como muchas de las supercomputadoras utilizadas por las compañías de seguros para su monitoreo de probabilidad .

La mayor parte del desarrollo de la computación llamada LLNM (Long Life, No Maintenance) fue realizada por la NASA durante la década de 1960, [4] en preparación para el Proyecto Apolo y otros aspectos de la investigación. La primera máquina de la NASA entró en un observatorio espacial , y su segundo intento, la computadora JSTAR, se utilizó en la Voyager . Esta computadora tenía una copia de seguridad de las matrices de memoria para usar métodos de recuperación de memoria y, por lo tanto, se la llamó la computadora de autoevaluación y reparación de JPL. Podría detectar sus propios errores y corregirlos o abrir módulos redundantes según sea necesario. La computadora todavía funciona hoy [ ¿cuándo? ] .

Las computadoras hiperconfiables fueron pioneras principalmente en los fabricantes de aviones , [3] : 210 compañías de energía nuclear y la industria ferroviaria en los Estados Unidos. Estos necesitaban computadoras con cantidades masivas de tiempo de actividad que fallarían con suficiente gracia con una falla para permitir un funcionamiento continuo mientras confiaban en el hecho de que la salida de la computadora sería monitoreada constantemente por humanos para detectar fallas. Una vez más, IBM desarrolló la primera computadora de este tipo para la NASA para guiar los cohetes Saturno V , pero más tarde BNSF , Unisys y General Electric construyeron la suya propia. [3] : 223

En la década de 1970, se ha trabajado mucho en el campo. [5] [6] [7] Por ejemplo, F14 CADC tenía una autocomprobación y una redundancia integradas . [8]

En general, los primeros esfuerzos en diseños tolerantes a fallas se centraron principalmente en el diagnóstico interno, donde una falla indicaría que algo estaba fallando y un trabajador podría reemplazarlo. SAPO, por ejemplo, tenía un método mediante el cual los tambores de memoria defectuosos emitían un ruido antes de fallar. [9] Esfuerzos posteriores demostraron que para ser completamente efectivo, el sistema tenía que repararse y diagnosticarse automáticamente, aislando una falla y luego implementando una copia de seguridad redundante mientras alertaba la necesidad de reparación. Esto se conoce como redundancia del modelo N, en el que las fallas provocan dispositivos de seguridad automáticos y una advertencia para el operador, y sigue siendo la forma más común de diseño tolerante a fallas de nivel uno en uso en la actualidad.

La votación fue otro método inicial, como se discutió anteriormente, con múltiples copias de seguridad redundantes operando constantemente y verificando los resultados de cada uno, con el resultado de que si, por ejemplo, cuatro componentes reportaron una respuesta de 5 y un componente reportó una respuesta de 6, los otros cuatro "Votaría" que el quinto componente estaba defectuoso y lo pondría fuera de servicio. A esto se le llama votación mayoritaria M de N.

Históricamente, el movimiento siempre ha sido moverse más del modelo N y más a M fuera de N debido al hecho de que la complejidad de los sistemas y la dificultad de asegurar el estado transitivo de falla negativa a falla positiva no interrumpieron las operaciones. .

Tandem y Stratus estuvieron entre las primeras empresas especializadas en el diseño de sistemas informáticos tolerantes a fallos para el procesamiento de transacciones en línea .

Terminología [ editar ]

Un ejemplo de elegante degradación por diseño en una imagen con transparencia. Cada una de las dos imágenes superiores es el resultado de ver la imagen compuesta en un visor que reconoce la transparencia. Las dos imágenes inferiores son el resultado de un visor sin soporte para la transparencia. Debido a que la máscara de transparencia (centro inferior) se descarta, solo queda la superposición (centro superior); la imagen de la izquierda ha sido diseñada para degradarse con elegancia, por lo que sigue siendo significativa sin su información de transparencia.

Un sistema altamente tolerante a fallos puede continuar con el mismo nivel de rendimiento aunque uno o más componentes hayan fallado. Por ejemplo, un edificio con un generador eléctrico de respaldo proporcionará el mismo voltaje a los tomacorrientes de la pared incluso si falla la energía de la red.

Un sistema que está diseñado para fallar a prueba de fallas , a prueba de fallas o fallar de manera elegante , ya sea que funcione a un nivel reducido o falle por completo, lo hace de una manera que protege a las personas, la propiedad o los datos de lesiones, daños, intrusiones o divulgación. En las computadoras, un programa puede funcionar a prueba de fallas ejecutando una salida elegante (a diferencia de un bloqueo incontrolado) para evitar la corrupción de datos después de experimentar un error. Se hace una distinción similar entre "fallar bien" y " fallar mal ".

Fail-deadly es la estrategia opuesta, que se puede utilizar en sistemas de armas que están diseñados para matar o herir objetivos incluso si parte del sistema está dañado o destruido.

Un sistema que está diseñado para experimentar una degradación elegante o fallar por software (usado en computación, similar a "a prueba de fallas" [10] ) opera a un nivel reducido de desempeño después de fallas en algunos componentes. Por ejemplo, un edificio puede operar la iluminación a niveles reducidos y los ascensores a velocidades reducidas si falla la energía de la red, en lugar de atrapar a las personas en la oscuridad por completo o continuar funcionando a plena potencia. En computación, un ejemplo de degradación elegante es que si no hay suficiente ancho de banda de red disponible para transmitir un video en línea, se puede transmitir una versión de menor resolución en lugar de la versión de alta resolución. Mejora progresivaes un ejemplo en informática, donde las páginas web están disponibles en un formato funcional básico para navegadores web antiguos, de pantalla pequeña o de capacidad limitada, pero en una versión mejorada para navegadores capaces de manejar tecnologías adicionales o que tienen una pantalla más grande disponible.

En los sistemas informáticos tolerantes a fallas , los programas que se consideran robustos están diseñados para continuar funcionando a pesar de un error, una excepción o una entrada no válida, en lugar de fallar por completo. La fragilidad del software es lo opuesto a la robustez. Las redes resistentes continúan transmitiendo datos a pesar de la falla de algunos enlaces o nodos; Asimismo, se espera que los edificios e infraestructura resilientes eviten fallas totales en situaciones como terremotos, inundaciones o colisiones.

Un sistema con alta transparencia de fallas alertará a los usuarios de que se ha producido una falla en un componente, incluso si continúa funcionando a pleno rendimiento, de modo que la falla pueda repararse o anticiparse una falla completa inminente. De la misma forma, un componente a prueba de fallas está diseñado para informar en el primer punto de falla, en lugar de permitir que los componentes posteriores fallen y generen informes en ese momento. Esto permite un diagnóstico más fácil del problema subyacente y puede evitar un funcionamiento incorrecto en un estado roto.

Condición de falla única [ editar ]

Una condición de falla única es una situación en la que un medio de protección contra un peligro es defectuoso. Si una condición de falla única resulta inevitablemente en otra condición de falla única, las dos fallas se consideran como una condición de falla única. [11] Una fuente ofrece el siguiente ejemplo:

Una condición de falla única es una condición cuando un solo medio de protección contra peligros en el equipo está defectuoso o una sola condición anormal externa está presente, por ejemplo, cortocircuito entre las partes activas y la parte aplicada. [12]

Redundancia [ editar ]

La redundancia es la provisión de capacidades funcionales que serían innecesarias en un entorno libre de fallas. [13] Esto puede consistir en componentes de respaldo que "se activan" automáticamente si falla un componente. Por ejemplo, los camiones de carga grandes pueden perder un neumático sin mayores consecuencias. Tienen muchas llantas, y ninguna es crítica (con la excepción de las llantas delanteras, que se usan para conducir, pero generalmente llevan menos carga, todas y en total, que las otras cuatro a 16, por lo que es menos probable que fallen. ). La idea de incorporar redundancia para mejorar la confiabilidad de un sistema fue iniciada por John von Neumann en la década de 1950. [14]

Son posibles dos tipos de redundancia: [15] redundancia de espacio y redundancia de tiempo. La redundancia de espacio proporciona componentes, funciones o elementos de datos adicionales que no son necesarios para un funcionamiento sin fallos. La redundancia de espacio se clasifica además en redundancia de hardware, software e información, según el tipo de recursos redundantes agregados al sistema. En la redundancia de tiempo, el cálculo o la transmisión de datos se repite y el resultado se compara con una copia almacenada del resultado anterior. La terminología actual para este tipo de pruebas se conoce como 'Prueba de tolerancia a fallas en servicio o ISFTT para abreviar.

Criterios [ editar ]

Proporcionar un diseño tolerante a fallas para cada componente normalmente no es una opción. La redundancia asociada conlleva una serie de penalizaciones: aumento de peso, tamaño, consumo de energía, costo, así como tiempo para diseñar, verificar y probar. Por lo tanto, se deben examinar varias opciones para determinar qué componentes deben ser tolerantes a fallas: [16]

  • ¿Qué tan crítico es el componente? En un automóvil, la radio no es crítica, por lo que este componente tiene menos necesidad de tolerancia a fallas.
  • ¿Qué posibilidades hay de que falle el componente? Es poco probable que algunos componentes, como el eje de transmisión de un automóvil, fallen, por lo que no se necesita tolerancia a fallas.
  • ¿Qué tan caro es hacer que el componente sea tolerante a fallas? Exigir un motor de automóvil redundante, por ejemplo, probablemente sería demasiado costoso tanto económicamente como en términos de peso y espacio para ser considerado.

Un ejemplo de un componente que pasa todas las pruebas es el sistema de retención de ocupantes de un automóvil. Si bien normalmente no pensamos en el sistema de sujeción del ocupante principal , es la gravedad . Si el vehículo vuelca o sufre fuerzas G severas, entonces este método principal de sujeción de ocupantes puede fallar. Contener a los ocupantes durante un accidente de este tipo es absolutamente fundamental para la seguridad, por lo que pasamos la primera prueba. Los accidentes que provocaban la expulsión de los ocupantes eran bastante comunes antes de los cinturones de seguridad , por lo que pasamos la segunda prueba. El costo de un método de sujeción redundante como los cinturones de seguridad es bastante bajo, tanto en términos económicos como en términos de peso y espacio, por lo que pasamos la tercera prueba. Por lo tanto, agregar cinturones de seguridad a todos los vehículos es una excelente idea. Otros "sistemas de sujeción suplementarios", comobolsas de aire , son más caras y pasan esa prueba por un margen menor.

Otro ejemplo excelente y a largo plazo de la puesta en práctica de este principio es el sistema de frenos: si bien los mecanismos de freno reales son críticos, no son particularmente propensos a fallas repentinas (en lugar de progresivas) y, en cualquier caso, están necesariamente duplicados para permitir Aplicación uniforme y equilibrada de la fuerza de frenado en todas las ruedas. También sería prohibitivamente costoso duplicar aún más los componentes principales y agregarían un peso considerable. Sin embargo, los sistemas igualmente críticos para accionar los frenos bajo el control del conductor son intrínsecamente menos robustos, generalmente utilizan un cable (puede oxidarse, estirarse, atascarse, romperse) o fluido hidráulico (puede gotear, hervir y desarrollar burbujas, absorber agua y por lo tanto perder efectividad ). Por lo tanto, en la mayoría de los automóviles modernos, el circuito del freno hidráulico del freno de pie está dividido en diagonal para dar dos puntos de falla más pequeños,la pérdida de solo reducir la potencia de frenado en un 50% y no causar un desequilibrio de fuerza de frenado tan peligroso como una división recta de adelante hacia atrás o de izquierda a derecha, y si el circuito hidráulico fallara por completo (una ocurrencia relativamente muy rara), hay una en forma de freno de estacionamiento accionado por cable que acciona los frenos traseros relativamente débiles, pero que aún puede detener el vehículo de manera segura junto con la transmisión / frenado del motor, siempre que las demandas estén en línea con el flujo de tráfico normal . La combinación acumulativamente improbable de falla total del freno de pie con la necesidad de un frenado brusco en una emergencia probablemente resultará en una colisión, pero aún así, a una velocidad menor de lo que hubiera sido el caso de otra manera.Existe un sistema de seguridad en forma de freno de estacionamiento accionado por cable que acciona los frenos traseros relativamente débiles, pero que aún puede detener el vehículo de manera segura junto con la transmisión / frenado del motor, siempre y cuando las demandas estén en línea. con flujo de tráfico normal. La combinación acumulativamente improbable de falla total del freno de pie con la necesidad de un frenado brusco en una emergencia probablemente resultará en una colisión, pero aún así, a una velocidad menor de lo que hubiera sido el caso de otra manera.Existe un sistema de seguridad en forma de freno de estacionamiento accionado por cable que acciona los frenos traseros relativamente débiles, pero que aún puede detener el vehículo de manera segura junto con la transmisión / frenado del motor, siempre y cuando las demandas estén en línea. con flujo de tráfico normal. La combinación acumulativamente improbable de falla total del freno de pie con la necesidad de un frenado brusco en una emergencia probablemente resultará en una colisión, pero aún así, a una velocidad menor de lo que hubiera sido el caso de otra manera.La combinación acumulativamente improbable de falla total del freno de pie con la necesidad de un frenado brusco en una emergencia probablemente resultará en una colisión, pero aún así, a una velocidad menor de lo que hubiera sido el caso de otra manera.La combinación acumulativamente improbable de falla total del freno de pie con la necesidad de un frenado brusco en una emergencia probablemente resultará en una colisión, pero aún así, a una velocidad menor de lo que hubiera sido el caso de otra manera.

En comparación con el freno de servicio activado por pedal, el freno de estacionamiento en sí es un elemento menos crítico y, a menos que se utilice como respaldo único para el freno de pie, no causará un peligro inmediato si se determina que no funciona en el Momento de la aplicación. Por lo tanto, no hay redundancia incorporada en él per se (y generalmente usa un sistema de activación de cable más barato, más liviano pero menos resistente), y puede ser suficiente, si esto sucede en una colina, usar el freno de pie para detener momentáneamente el vehículo. , antes de conducir para encontrar un tramo llano en el que detenerse. Alternativamente, en pendientes poco profundas, la transmisión se puede cambiar a Estacionamiento, Reversa o Primera marcha, y el bloqueo de la transmisión / compresión del motor se puede usar para mantenerla estacionaria, ya que no es necesario que incluyan la sofisticación para detenerla primero. .

En las motocicletas, se proporciona un nivel similar de seguridad contra fallas mediante métodos más simples; en primer lugar, los sistemas de freno delantero y trasero están completamente separados, independientemente de su método de activación (que puede ser por cable, varilla o hidráulico), lo que permite que uno falle por completo mientras que el otro no se ve afectado. En segundo lugar, el freno trasero es relativamente fuerte en comparación con su primo automotriz, incluso siendo un disco potente en los modelos deportivos, aunque la intención habitual es que el sistema delantero proporcione la gran mayoría de la fuerza de frenado; como el peso total del vehículo es más central, el neumático trasero es generalmente más grande y con más agarre, y el ciclista puede inclinarse hacia atrás para poner más peso sobre él, lo que permite aplicar más fuerza de frenado antes de que la rueda se bloquee. En máquinas de clase de servicios públicos más baratas y lentas,Incluso si la rueda delantera debe usar un disco hidráulico para una fuerza de frenado adicional y un empaque más fácil, la parte trasera generalmente será un tambor primitivo, algo ineficiente, pero excepcionalmente robusto, accionado por varilla, gracias a la facilidad de conectar el pedal a la rueda en este camino y, lo que es más importante, la casi imposibilidad de una falla catastrófica incluso si el resto de la máquina, como muchas bicicletas de bajo precio después de sus primeros años de uso, está a punto de colapsar por un mantenimiento descuidado.como muchas bicicletas de bajo precio después de sus primeros años de uso, está a punto de colapsar por un mantenimiento descuidado.como muchas bicicletas de bajo precio después de sus primeros años de uso, está a punto de colapsar por un mantenimiento descuidado.

Requisitos [ editar ]

Las características básicas de la tolerancia a fallos requieren:

  1. Ningún punto único de falla : si un sistema experimenta una falla, debe continuar funcionando sin interrupciones durante el proceso de reparación.
  2. Aislamiento de fallas del componente que falla: cuando ocurre una falla, el sistema debe poder aislar la falla del componente que falla. Esto requiere la adición de mecanismos de detección de fallas dedicados que existen solo con el propósito de aislar fallas. La recuperación de una condición de falla requiere clasificar la falla o el componente defectuoso. El Instituto Nacional de Estándares y Tecnología (NIST) clasifica las fallas según la localidad, causa, duración y efecto. [ donde? ] [ aclaración necesaria ]
  3. Contención de fallas para evitar la propagación de la falla: algunos mecanismos de falla pueden hacer que un sistema falle al propagar la falla al resto del sistema. Un ejemplo de este tipo de falla es el "transmisor deshonesto" que puede inundar la comunicación legítima en un sistema y causar una falla general del sistema. Se requieren cortafuegos u otros mecanismos que aíslen un transmisor no autorizado o un componente defectuoso para proteger el sistema.
  4. Disponibilidad de modos de reversión [ aclaración necesaria ]

Además, los sistemas tolerantes a fallas se caracterizan tanto en términos de interrupciones del servicio planificadas como de interrupciones del servicio no planificadas. Por lo general, se miden a nivel de aplicación y no solo a nivel de hardware. La cifra de mérito se llama disponibilidad y se expresa en porcentaje. Por ejemplo, un sistema de cinco nueves proporcionaría estadísticamente una disponibilidad del 99,999%.

Los sistemas tolerantes a fallas se basan generalmente en el concepto de redundancia.

Técnicas de tolerancia a fallas [ editar ]

La investigación de los tipos de tolerancias necesarias para los sistemas críticos implica una gran cantidad de trabajo interdisciplinario. Cuanto más complejo sea el sistema, más cuidadosamente deben considerarse y prepararse todas las posibles interacciones. Teniendo en cuenta la importancia de los sistemas de alto valor en el transporte, los servicios públicos y el ejército, el campo de temas que tocan la investigación es muy amplio: puede incluir desde temas tan obvios como el modelado y confiabilidad de software , o el diseño de hardware , hasta elementos arcanos como modelos estocásticos , teoría de grafos , lógica formal o excluyente, procesamiento paralelo , transmisión remota de datos y más. [17]

Replicación [ editar ]

Los componentes de repuesto abordan la primera característica fundamental de la tolerancia a fallas de tres maneras:

  • Replicación : Proporcionar múltiples instancias idénticas del mismo sistema o subsistema, dirigir tareas o solicitudes a todas ellas en paralelo y elegir el resultado correcto sobre la base de un quórum ;
  • Redundancia : proporcionar varias instancias idénticas del mismo sistema y cambiar a una de las instancias restantes en caso de falla ( conmutación por error );
  • Diversidad: Proporcionar múltiples implementaciones diferentes de la misma especificación y usarlas como sistemas replicados para hacer frente a errores en una implementación específica.

Todas las implementaciones de RAID , matriz redundante de discos independientes , excepto RAID 0, son ejemplos de un dispositivo de almacenamiento tolerante a fallas que utiliza redundancia de datos .

Una máquina bloqueada y tolerante a fallas utiliza elementos replicados que operan en paralelo. En cualquier momento, todas las réplicas de cada elemento deben estar en el mismo estado. Se proporcionan las mismas entradas para cada réplica y se esperan los mismos resultados. Los resultados de las réplicas se comparan mediante un circuito de votación. Una máquina con dos réplicas de cada elemento se denomina redundante modular dual (DMR). El circuito de votación solo puede detectar una discrepancia y la recuperación se basa en otros métodos. Una máquina con tres réplicas de cada elemento se denomina redundante modular triple.(TMR). El circuito de votación puede determinar qué réplica es errónea cuando se observa un voto de dos a uno. En este caso, el circuito de votación puede generar el resultado correcto y descartar la versión errónea. Después de esto, se supone que el estado interno de la réplica errónea es diferente al de los otros dos, y el circuito de votación puede cambiar a un modo DMR. Este modelo se puede aplicar a cualquier número mayor de réplicas.

Las máquinas de Lockstep tolerantes a fallas se hacen más fácilmente sincrónicas , con cada puerta de cada replicación haciendo la misma transición de estado en el mismo borde del reloj, y los relojes a las replicaciones están exactamente en fase. Sin embargo, es posible construir sistemas bloqueados sin este requisito.

Para sincronizar las réplicas, es necesario hacer que sus estados almacenados internos sean los mismos. Pueden iniciarse desde un estado inicial fijo, como el estado de reinicio. Como alternativa, el estado interno de una réplica se puede copiar en otra réplica.

Una variante de DMR es par y repuesto . Dos elementos replicados operan en sincronía como un par, con un circuito de votación que detecta cualquier desajuste entre sus operaciones y emite una señal que indica que hay un error. Otro par opera exactamente de la misma manera. Un circuito final selecciona la salida del par que no proclama que está en error. Pair-and-spare requiere cuatro réplicas en lugar de las tres de TMR, pero se ha utilizado comercialmente.

Computación inconsciente de fallas [ editar ]

La computación inconsciente de fallas es una técnica que permite que los programas de computadora continúen ejecutándose a pesar de los errores . [18] La técnica se puede aplicar en diferentes contextos. Primero, puede manejar lecturas de memoria inválidas devolviendo un valor fabricado al programa, [19] que a su vez, hace uso del valor fabricado e ignora el valor de memoria anterior al que intentó acceder, esto es un gran contraste con los típicos verificadores de memoria. , que informan al programa del error o abortan el programa. En segundo lugar, se puede aplicar a excepciones en las que algunos bloques de captura se escriben o sintetizan para detectar excepciones inesperadas. [20]Además, sucede que la ejecución se modifica varias veces seguidas, con el fin de evitar fallos en cascada. [21]

El enfoque tiene costos de rendimiento: debido a que la técnica reescribe el código para insertar verificaciones dinámicas para la validez de la dirección, el tiempo de ejecución aumentará entre un 80% y un 500%. [22]

Pastoreo de recuperación [ editar ]

El control de la recuperación es una técnica ligera que permite que los programas de software se recuperen de errores fatales como la eliminación de referencias de puntero nulo y la división por cero. [23] En comparación con la técnica de computación inconsciente de fallas, el control de recuperación funciona en el programa binario compilado directamente y no necesita volver a compilar para programar.

Utiliza el Pin de marco de instrumentación binario justo a tiempo . Se adjunta al proceso de aplicación cuando ocurre un error, repara la ejecución, rastrea los efectos de reparación a medida que la ejecución continúa, contiene los efectos de reparación dentro del proceso de aplicación y se separa del proceso después de que todos los efectos de reparación se eliminan del estado del proceso. No interfiere con la ejecución normal del programa y, por lo tanto, incurre en una sobrecarga insignificante. [23] Para 17 de 18 errores de desreferencia nula y división por cero del mundo real recopilados sistemáticamente, una implementación de prototipo permite que la aplicación continúe ejecutándose para proporcionar una salida y un servicio aceptables a sus usuarios en las entradas que desencadenan errores. [23]

Disyuntor [ editar ]

El patrón de diseño del disyuntor es una técnica para evitar fallas catastróficas en sistemas distribuidos.

Desventajas [ editar ]

Las ventajas del diseño tolerante a fallas son obvias, mientras que muchas de sus desventajas no lo son:

  • Interferencia con la detección de fallas en el mismo componente. Para continuar con el ejemplo anterior del vehículo de pasajeros, con cualquiera de los sistemas tolerantes a fallas puede que no sea obvio para el conductor cuando se pincha una llanta. Esto generalmente se maneja con un "sistema automático de detección de fallas" separado. En el caso del neumático, un monitor de presión de aire detecta la pérdida de presión y notifica al conductor. La alternativa es un "sistema manual de detección de fallas", como inspeccionar manualmente todos los neumáticos en cada parada.
  • Interferencia con la detección de fallas en otro componente. Otra variación de este problema es cuando la tolerancia a fallas en un componente evita la detección de fallas en un componente diferente. Por ejemplo, si el componente B realiza alguna operación basada en la salida del componente A, entonces la tolerancia a fallas en B puede ocultar un problema con A. Si el componente B se cambia más tarde (a un diseño menos tolerante a fallas), el sistema puede fallar repentinamente, haciendo parecer que el nuevo componente B es el problema. Solo después de que el sistema haya sido examinado cuidadosamente, quedará claro que la raíz del problema está realmente en el componente A.
  • Reducción de la prioridad de corrección de fallas. Incluso si el operador es consciente de la falla, es probable que tener un sistema tolerante a fallas reduzca la importancia de reparar la falla. Si las fallas no se corrigen, esto eventualmente conducirá a fallas en el sistema, cuando el componente tolerante a fallas falla completamente o cuando todos los componentes redundantes también han fallado.
  • Prueba de dificultad. Para ciertos sistemas críticos tolerantes a fallas, como un reactor nuclear , no existe una manera fácil de verificar que los componentes de respaldo sean funcionales. El ejemplo más infame de esto es Chernobyl , donde los operadores probaron el enfriamiento de respaldo de emergencia al deshabilitar el enfriamiento primario y secundario. La copia de seguridad falló, lo que resultó en una fusión del núcleo y una liberación masiva de radiación.
  • Costo. Tanto los componentes tolerantes a fallos como los componentes redundantes tienden a incrementar el costo. Este puede ser un coste puramente económico o puede incluir otras medidas, como el peso. Las naves espaciales tripuladas , por ejemplo, tienen tantos componentes redundantes y tolerantes a fallas que su peso aumenta drásticamente en comparación con los sistemas no tripulados, que no requieren el mismo nivel de seguridad.
  • Componentes inferiores. Un diseño tolerante a fallas puede permitir el uso de componentes inferiores, que de otro modo habrían dejado el sistema inoperable. Si bien esta práctica tiene el potencial de mitigar el aumento de costos, el uso de múltiples componentes inferiores puede reducir la confiabilidad del sistema a un nivel igual o incluso peor que un sistema comparable no tolerante a fallas.

Ejemplos [ editar ]

La tolerancia a fallas de hardware a veces requiere que las partes rotas se retiren y se reemplacen por partes nuevas mientras el sistema aún está operativo (en computación se conoce como intercambio en caliente ). Un sistema de este tipo implementado con una sola copia de seguridad se conoce como tolerante a un solo punto y representa la gran mayoría de los sistemas tolerantes a fallas. En tales sistemas, el tiempo medio entre fallas debe ser lo suficientemente largo para que los operadores tengan tiempo para reparar los dispositivos rotos ( tiempo medio para reparar ) antes de que también falle la copia de seguridad. Ayuda si el tiempo entre fallas es lo más largo posible, pero esto no se requiere específicamente en un sistema tolerante a fallas.

La tolerancia a fallos tiene un éxito notable en las aplicaciones informáticas. Tandem Computers construyó todo su negocio en estas máquinas, que utilizaron la tolerancia de un solo punto para crear sus sistemas NonStop con tiempos de actividad medidos en años.

Las arquitecturas a prueba de fallos pueden abarcar también el software informático, por ejemplo, mediante la replicación de procesos .

Los formatos de datos también pueden diseñarse para degradarse con elegancia. HTML, por ejemplo, está diseñado para ser compatible con versiones posteriores , lo que permite que los navegadores web que no las entienden ignoren nuevas entidades HTML sin que el documento quede inutilizable.

Términos relacionados [ editar ]

Existe una diferencia entre la tolerancia a fallas y los sistemas que rara vez tienen problemas. Por ejemplo, los sistemas de barras transversales de Western Electric tenían tasas de falla de dos horas cada cuarenta años y, por lo tanto, eran altamente resistentes a las fallas . Pero cuando ocurrió una falla, dejaron de funcionar por completo y, por lo tanto, no fueron tolerantes a las fallas .

Ver también [ editar ]

  • Tolerancia a fallas bizantinas
  • Control de reconfiguración
  • Tolerancia al daño
  • Redundancia de datos
  • Defensa en profundidad
  • Degradación elegante
  • Detección y corrección de errores
  • Diseño tolerante a errores ( diseño tolerante a errores humanos )
  • Semántica de fallas
  • Retroceder y avanzar
  • Salida elegante
  • Tolerancia a la intrusión
  • Lista de atributos de calidad del sistema
  • Resiliencia (ecología)
  • Mejora progresiva
  • Resiliencia (red)
  • Robustez (informática)
  • Rollback (gestión de datos)
  • Diseño de vida segura
  • Autogestión (informática)
  • Diversidad de software

Referencias [ editar ]

  1. ^ Tolerancia adaptativa a fallas y degradación elegante , Oscar González et al., 1997, Universidad de Massachusetts - Amherst
  2. ^ Johnson, BW (1984). " Sistemas basados ​​en microprocesadores tolerantes a fallas ", IEEE Micro, vol. 4, no. 6, págs. 6-21
  3. ↑ a b c Daniel P. Siewiorek; C. Gordon Bell; Allen Newell (1982). Estructuras informáticas: principios y ejemplos . McGraw-Hill . ISBN 0-07-057302-6.
  4. ^ Algirdas Avižienis; George C. Gilley; Francis P. Mathur; David A. Rennels; John A. Rohr; David K. Rubin. "La computadora STAR (autocomprobación y reparación): una investigación de la teoría y la práctica del diseño informático tolerante a fallas" (PDF) .
  5. ^ Randell, Brian ; Lee, PA; Treleaven, PC (junio de 1978). "Problemas de confiabilidad en el diseño de sistemas informáticos" . Encuestas de computación ACM . 10 (2): 123-165. doi : 10.1145 / 356725.356729 . ISSN 0360-0300 . S2CID 16909447 .  
  6. ^ PJ Denning (diciembre de 1976). "Sistemas operativos tolerantes a fallas" . Encuestas de computación ACM . 8 (4): 359–389. doi : 10.1145 / 356678.356680 . ISSN 0360-0300 . S2CID 207736773 .  
  7. ^ Theodore A. Linden (diciembre de 1976). "Estructuras del sistema operativo para respaldar la seguridad y el software confiable" . Encuestas de computación ACM . 8 (4): 409–445. doi : 10.1145 / 356678.356682 . hdl : 2027 / mdp.39015086560037 . ISSN 0360-0300 . S2CID 16720589 .  
  8. ^ Ray Holt. "La computadora de datos de aire central F14A y el estado del arte de la tecnología LSI en 1968" .
  9. ^ Computación tolerante a fallas en el diseño de computadoras Neilforoshan, MR Journal of Computing Sciences in Colleges archive Volumen 18, Número 4 (abril de 2003) Páginas: 213 - 220, ISSN 1937-4771 
  10. ^ Stallings, W (2009): Sistemas operativos. Principios internos y de diseño , sexta edición
  11. ^ "Control" . Grouper.ieee.org . Archivado desde el original el 8 de octubre de 1999 . Consultado el 6 de abril de 2016 .
  12. ^ Baha Al-Shaikh, Simon G. Stacey, Fundamentos del equipo en anestesia, cuidados intensivos y medicina perioperatoria (2017), p. 247.
  13. ^ Laprie, JC (1985). " Computación confiable y tolerancia a fallas: conceptos y terminología ", Actas del 15º Simposio internacional sobre computación tolerante a fallas (FTSC-15), págs. 2-11
  14. von Neumann, J. (1956). " Lógica probabilística y síntesis de organismos confiables a partir de componentes no confiables ", en Automata Studies, eds. C. Shannon y J. McCarthy, Princeton University Press, págs. 43–98
  15. ^ Avizienis, A. (1976). " Sistemas tolerantes a fallas ", IEEE Transactions on Computers, vol. 25, no. 12, págs. 1304-1312
  16. ^ Dubrova, E. (2013). "Diseño tolerante a fallas", Springer, 2013, ISBN 978-1-4614-2112-2 
  17. ^ Evaluación de confiabilidad de algunas arquitecturas de computadora tolerantes a fallas . Springer-Verlag. Noviembre de 1980. ISBN 978-3-540-10274-8.
  18. ^ Herzberg, Amir; Shulman, Haya (2012). "Computación bipartita asistida por servidor ajena y justa" . 2012 Séptima Conferencia Internacional sobre Disponibilidad, Fiabilidad y Seguridad . IEEE: 75–84. doi : 10.1109 / ares.2012.28 . ISBN 978-1-4673-2244-7. S2CID  6579295 .
  19. ^ Aparejador, Manuel; Pekarek, Daniel; Mössenböck, Hanspeter (2018), "Context-Aware Failure-Oblivious Computing as a Means of Preventing Buffer Overflows" , Network and System Security , Cham: Springer International Publishing, págs. 376–390, arXiv : 1806.09026 , doi : 10.1007 / 978 -3-030-02744-5_28 , ISBN 978-3-030-02743-8, consultado el 7 de octubre de 2020
  20. ^ Zhang, largo; Monperrus, Martín (2019). "TripleAgent: monitoreo, perturbación y olvido de fallas para la mejora automatizada de la resiliencia en aplicaciones Java" . 2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE) . Berlín, Alemania: IEEE: 116–127. arXiv : 1812.10706 . doi : 10.1109 / ISSRE.2019.00021 . ISBN 978-1-7281-4982-0. S2CID  57189195 .
  21. ^ Durieux, Thomas; Hamadi, Youssef; Yu, Zhongxing; Baudry, Benoit; Monperrus, Martín (2018). "Exploración exhaustiva del espacio de búsqueda de computación inconsciente de fallas". 2018 IEEE 11th International Conference on Software Testing, Verification and Validation (ICST) . págs. 139-149. arXiv : 1710.09722 . doi : 10.1109 / ICST.2018.00023 . ISBN 978-1-5386-5012-7. S2CID  4304123 .
  22. ^ Keromytis, Angelos D. (2007), "Caracterización de sistemas de autocuración de software" , en Gorodetski, Vladimir I .; Kotenko, Igor; Skormin, Victor A. (eds.), Caracterización de sistemas de autorreparación de software , Seguridad de redes informáticas: Cuarta Conferencia Internacional sobre Métodos Matemáticos, Modelos y Arquitecturas para la Seguridad de Redes Informáticas, Springer , ISBN 978-3-540-73985-2
  23. ^ a b c Largo, ventilador; Sidiroglou-Douskos, Stelios; Rinard, Martín (2014). "Reparación y contención automática de errores en tiempo de ejecución mediante el pastoreo de recuperación". Actas de la 35ª Conferencia ACM SIGPLAN sobre diseño e implementación de lenguajes de programación . PLDI '14'. Nueva York, NY, EE.UU .: ACM. págs. 227-238. doi : 10.1145 / 2594291.2594337 . ISBN 978-1-4503-2784-8. S2CID  6252501 .