Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Tolerancia a Fallos

No description
by

Melodi Romero

on 23 April 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Tolerancia a Fallos

Tolerancia a Fallos
Decimos que un sistema falla cuando no cumple su especificación
• La réplica activa: todos los procesadores se utilizan todo el tiempo como servidores (en paralelo) para ocultar las fallas por completo.
• Respaldo primario: utiliza un procesador como servidor, reemplazándolo con un respaldo si falla.

• El grado de réplica requerido.
• El desempeño en el caso promedio y en el peor caso, en ausencia de fallas.
• El desempeño en el caso promedio y en el peor caso, cuando ocurre una falla.
Para ambas, los aspectos a considerar son:.
El método general para la tolerancia de fallas consiste en el uso de redundancia. Existen tres tipos posibles:
Redundancia de la información: Se agregan algunos bits para poder recuperar los bits revueltos. Por ejemplo, se puede agregar un código Hamming para transmitir los datos y recuperarse del ruido en la línea de transmisión.
Fallas de Componentes
Los sistemas de cómputo pueden fallar debido a una falla en algún componente:
Ejemplos:
En un sistema de ordenamiento distribuido en un supermercado: una falla podría provocar la falta de algún producto en la tienda.
En un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica.
Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de evitar las fallas es cada vez mayor.
Se presentara algunos aspectos relativos a las fallas del sistema y cómo evitarlas.

Redundancia del tiempo: se realiza una acción, y entonces, en caso necesario, se vuelve a realizar. Si una transacción aborta, puede volverse a realizar sin daño alguno. La redundancia de tiempo es de particular utilidad cuando las fallas son transitorias o intermitentes (El uso de las transacciones atómicas es un ejemplo).
Redundancia física: se agrega un equipo adicional para permitir que el sistema como un todo tolere la pérdida o el mal funcionamiento de algunos componentes. Por ejemplo, se pueden agregar más procesadores, de modo que si unos pocos de ellos fallan, el sistema pueda seguir funcionando de manera correcta.
• Procesador
• Memoria
• Dispositivo de E/S
• Cable
• Software
• Un error de diseño
• Un error de fabricación
• Un error de programación
• Un daño físico
• El deterioro con el curso de tiempo
• Condiciones ambientales adversas
• Entradas inesperadas
• Un error del operador
• Roedores comiendo parte del sistema
• Entre muchas causas mas
Una falla es un desperfecto, causado por:
• TRANSITORIAS:
Ocurren una vez y después desaparecen. Si la operación se repite, la falla ya no se presenta. Un pájaro que vuela a través del rayo de un transmisor de microondas provoca la pérdida de bits en una red (por no mencionar un pájaro frito).

• INTERMITENTES:
Ésta desaparece, reaparece, etcétera. Un mal contacto de un conectar causa con frecuencia una falla intermitente, las cuales son graves por su difícil diagnóstico. Lo usual es que cuando aparece el doctor, el sistema funcione de manera perfecta.

• PERMANENTES:
Es aquella que continúa existiendo hasta reparar el componente con el desperfecto. Los circuitos quemados, los errores del software y el rompimiento de la cabeza del disco provocan con frecuencia fallas permanentes. El objetivo del diseño y construcción de sistemas tolerantes de fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en la presencia de fallas.

Las fallas se clasifican en:
Analizaremos las fallas del procesador, pero esto debe entenderse también como fallas del proceso (por ejemplo, debido a errores del software). Se pueden distinguir dos tipos de fallas del procesador:
• Fallas silentes (de detención): un procesador que falla sólo se detiene, excepto que puede anunciar que ya no está funcionando.
• Fallas bizantinas: un procesador que falla continúa su ejecución, proporcionando respuestas incorrectas a las preguntas, y posiblemente trabajando de manera maliciosa junto con otros procesadores que han fallado, para dar la impresión de que todos funcionan de manera correcta aunque no sea así.

Los errores no detectados en el software exhiben con frecuencia fallas bizantinas. Es claro que enfrentarse a las fallas bizantinas será más difícil que enfrentarse a las fallas silentes. El término "bizantino" se refiere al imperio bizantino, época (330-1453) y lugar (Los Balcanes y la Turquía moderna) en los cuales supuestamente hubo innumerables conspiraciones, intrigas e infidelidades en los círculos gobernantes. Las fallas bizantinas fueron analizadas por primera vez por Pease et al. (1980) y Lamport et al. (1982).
Sistemas síncronos vs. Asíncronos
Como acabamos de ver, las fallas de los componentes pueden ser transitorias, intermitentes o permanentes, mientras que las fallas del sistema pueden ser silentes o bizantinas. Un tercer eje ortogonal trata del desempeño en un sentido abstracto. Supongamos que tenemos un sistema en el cual, si un procesador envía un mensaje a otro, se garantiza que obtiene una respuesta dentro de un tiempo T conocido de antemano. Si no se obtiene una respuesta, esto significa que el sistema receptor ha fallado. El tiempo T incluye el tiempo suficiente para considerar la pérdida de mensajes (enviándolos hasta n veces). En el contexto de la investigación relativa a la tolerancia de fallas, un sistema que tiene la propiedad de responder siempre a un mensaje dentro de un límite finito conocido, si está funcionando, es síncrono. Un sistema que no tiene esta propiedad es asíncrono. Aunque esta terminología es desafortunada, ya que entra en conflicto con usos más tradicionales de los términos, se utiliza con amplitud entre las personas que trabajan con la tolerancia de fallas. Debe ser claro que los sistemas asíncronos serán más difíciles de tratar que los síncronos. Si un procesador puede enviar un mensaje y sabe que la ausencia de respuesta dentro de T segundos significa que el pretendido receptor ha fallado, puede realizar una acción correctiva. Si no existe una cota superior para el tiempo de la respuesta, será un problema determinar incluso si ha ocurrido una falla.
USO DE REDUNDANCIA
Hay dos formas de organizar estos procesadores adicionales (Consideremos el caso de un servidor):
MUCHAS GRACIAS!!!
Tolerancia de fallas mediante réplica activa
También se ha utilizado durante años para la tolerancia de fallas en los circuitos electrónicos.
En muchos sistemas, los servidores actúan como grandes máquinas de estado finito: aceptan solicitudes y producen respuestas. La lectura de solicitudes no altera el estado del servidor, pero la escritura de solicitudes sí lo hace. Si cada solicitud cliente se envía a cada servidor y todas son recibidas y procesadas en el mismo orden, entonces, después de procesar cada una, todos los servidores que no han fallado tendrán con exactitud el mismo estado y darán las mismas respuestas. El cliente puede combinar todos los resultados para enmascarar las fallas.
Un aspecto importante es la cantidad de réplica necesaria. La respuesta depende de la cantidad de tolerancia de fallas deseada. Un sistema es tolerante de k fallas si puede sobrevivir a fallas en k- componentes y seguir cumpliendo sus especificaciones. Si los componentes fallan de manera silente, entonces bastan k + 1 de ellos para proporcionar la tolerancia de k-fallas. Si k de estos componentes sólo se detienen, se puede utilizar la respuesta del otro componente.
Por otro lado, si los procesadores exhiben fallas bizantinas, continúan su ejecución al enfermar y envían respuestas erróneas o aleatorias, se necesita un mínimo de 2k + 1 procesadores para lograr la tolerancia de k- fallas.
Así, incluso en un sistema tolerante de fallas, se necesita cierto tipo de análisis estadístico. Una condición previa implícita para que este modelo de máquina de estado finito sea relevante es que todas las solicitudes lleguen a todos los servidores en el mismo orden, lo que a veces se llama el problema de transmisión atómica.
La réplica activa es una técnica muy conocida para proporcionar la tolerancia de fallas mediante la redundancia física. Se utiliza:
• Biología (Los mamíferos tienen dos ojos, dos oídos, dos pulmones, etc.).
• Aviación (los 747 tienen cuatro motores pero pueden volar con tres).
• Los deportes (varios árbitros, en caso de que alguno omita un evento).
Algunos autores se refieren a la réplica activa como el método de la máquina de estados.
Una forma de garantizar que todas las solicitudes se procesen en el mismo orden en todos los servidores consiste en numerarlas de forma global. Se han diseñado varios protocolos para lograr este objetivo. Por ejemplo, todas las solicitudes se podrían enviar primero a un servidor global de números, con el fin de obtener un número consecutivo, pero entonces habría que tomar previsiones para la falla de este servidor (por ejemplo, haciéndolo tolerante de fallas internas).
Otra posibilidad es utilizar los relojes lógicos de Lamport. Si cada mensaje enviado a un servidor recibe una marca de tiempo y los servidores procesan. Todas las solicitudes según el orden de dichas marcas, todas las solicitudes serán procesadas en el mismo orden en todos los servidores. El problema con este método es que, cuando un servidor recibe una solicitud, no sabe si las solicitudes anteriores están en camino. De hecho, la mayor parte de las soluciones con marcas de tiempo sufren de este problema. En resumen, la réplica activa no es un asunto trivial.
Tolerancia de fallas mediante respaldo primario
La tolerancia de fallas con respaldo primario tiene dos ventajas principales sobre la réplica activa. En primer lugar, es más sencilla durante la operación normal, puesto que los mensajes van sólo a un servidor (el primario) y no a todo un grupo. Los problemas asociados con el ordenamiento de estos mensajes también desaparecen. En segundo lugar, en la practicase requieren menos máquinas, puesto que en cualquier instante se necesitan un primario y un respaldo (aunque cuando un respaldo se pone en servicio como primario, se necesita un nuevo respaldo de manera instantánea).
Como desventaja, trabaja mal en presencia de fallas bizantinas, en las que el primario afirma erróneamente que funciona de manera perfecta. Además, la recuperación de una falla del primario puede ser compleja y consumir mucho tiempo. Como ejemplo de la solución con respaldo primario: El cliente envía un mensaje al primario, quien realiza el trabajo y después envía un mensaje de actualización al respaldo. Cuando el respaldo lo recibe, realiza el trabajo y entonces envía un reconocimiento de regreso al primario. Cuando llega el reconocimiento, el primario envía la respuesta al cliente.
Consideremos ahora el efecto de una falla del primario durante varios momentos durante una RPC. Si el primario falla antes de realizar el trabajo (paso 2), no hay ningún daño. El cliente expira y vuelve a intentar. Si intenta las veces suficientes, entonces de manera eventual llegará al respaldo y el trabajo se realizará con exactitud. Si el primario falla después de realizar el trabajo pero antes de enviar la actualización, cuando el respaldo ocupa su lugar y la solicitud vuelve a llegar, el trabajo se realizará por segunda vez. Si el trabajo tiene efectos colaterales, esto podría ser un problema. Si el primario falla antes del paso 4 pero antes del paso 6, el trabajo podría terminar realizándose tres veces, una por el primario, otra por el respaldo como consecuencia del paso 3 y otra después de que el respaldo se convierte en el primario. Si solicita identificadores de acarreo, entonces podríamos garantizar que el trabajo sólo se realiza dos veces, pero hacer que se realice una vez es difícil o imposible.
La idea esencial del método de respaldo primario es que en cualquier instante, un servidor es el primario y realiza todo el trabajo. Si el primario falla, el respaldo ocupa su lugar. En forma ideal, el remplazo debe ocurrir de manera limpia, y ser notado únicamente por el sistema operativo cliente, no por los programas de aplicación. Como la réplica activa, este esquema se utiliza con amplitud en el mundo. Algunos ejemplos son el gobierno (el vicepresidente), la aviación (los copilotos), los automóviles (llantas de refacción), y los generadores de energía eléctrica con base en diesel en las salas de operación de un hospital.
Un problema teórico y práctico con el método del respaldo primario es el momento en que debe pasarse del primario al respaldo. En el protocolo anterior, el respaldo podría enviar el mensaje "¿Estás vivo?" de manera periódica al primario. Si el primario no responde después de cierto tiempo, el respaldo tomaría el control. Sin embargo, ¿qué ocurre si el primario no ha fallado, sino que sólo es lento? No existe forma de distinguir entre un primario lento y uno que ha fallado. Aun así, existe la necesidad de garantizar que cuando el respaldo toma el control, el primario se detiene y deja de intentar actuar como tal. Lo ideal es que el respaldo y el primario tengan un protocolo para discutir esto, pero es difícil negociar con un muerto. La mejor solución es un mecanismo de hardware en el que un respaldo pueda obligar a detenerse o volver a arrancar el primario.
En muchos sistemas distribuidos existe la necesidad de que los procesos coincidan en algo. Algunos ejemplos son la elección de un coordinador, decidir cuándo comprometer una transacción o no, dividir las tareas entre los trabajadores, la sincronización, etc. Cuando la comunicación y los procesadores son todos perfectos, llegar a tales acuerdos es con frecuencia algo directo, pero cuando no lo son, surgen los problemas. El objetivo general de los algoritmos de acuerdo distribuido es lograr que todos los procesadores no defectuosos alcancen el consenso acerca de cierto tema, en un número finito de pasos.
Existen varios casos dependientes de los parámetros del sistema, entre los que están:
1. ¿Se entregan los mensajes de manera confiable todo el tiempo?
2. ¿Pueden fallar los procesos, y, en tal caso, las fallas son silentes o bizantinas?
3. ¿Es el sistema síncrono o asíncrono?

Acuerdo en sistemas defectuosos
Full transcript