Clase 7: Tácticas de disponibilidad y eficiencia
Anuncio
Ingeniería de Software II
Primer Cuatrimestre de 2009
Concerns y Tácticas de Dependability
Buenos Aires, 16 de Abril de 2009
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
2009
Conceptos Generales
DEPENDABILITY
2
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Dependability
―Dependability‖ es la propiedad del sistema de software
que indica el nivel justificable de confianza que puede ser
delegada sobre los servicios que éste entrega
Pueder ser caracterizado a través de los siguientes atributos:
Disponibilidad (availability) — prontitud para el uso
Confiabilidad (reliability) — continuidad de servicio en el tiempo
Safety — no ocurrencia de consecuencias catastróficas para el entorno
Confidencialidad (confidentiality) — no apertura de información no autorizada
Integridad (integrity) — no ocurrencia de alteraciones de información no
deseables
Mantenibilidad (maintainability ) — aptitud para sobrellevar reparaciones
correctivas y evolutivas
Notar que los últimos tres ítems corresponden a seguridad y modificabilidad
December 1995; Mario Barbacci Mark H. Klein Thomas A. Longstaff Charles B. Weinstock; Technical Report CMU/SEI-95-TR-021 ESC-TR-95-021, Quality Attributes
3
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Disponibilidad
Disponibilidad: La habilidad del sistema de estar completa o
parcialmente operacional cuando se lo requiera.
Disponibilidad = (Periodo de tiempo – tiempo no operativo ) /
Periodo de Tiempo
La disponibilidad se suele medir en cantidad de ―nueves‖, siendo el
período base de un año. Se usa para especificar SLA de proveedores
sobre los cuales delego parte de mi operación.
Por ejemplo un proveedor de enlace punto a punto nos puede decir que
su ―SLA es de 99,99%‖
¿ Esto es mucho o es poco ?
Veamos la siguiente tabla
4
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Ejemplo de Disponibilidad
SLA Disponibilidad
5
7x24
8760 horas al año
7x8
2920 horas al año
90%
876 horas (36,5 días)
292 horas (12,16 días)
95%
438 horas (18,25 días)
146 horas (6,07 días)
99%
87,6 horas (3,65 días)
29,2 horas (1,21 días)
99,9%
8,76 horas
2,92 horas
99,99%
52,56 minutos
17,47 minutos
99,999%
5,256 minutos
1,747 minutos
99,9999%
31,536 segundos
10,483 segundos
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Confiabilidad
Confiabilidad: Es la habilidad del sistema para continuar operando
a lo largo del tiempo.
En muchos sistemas esto podría no ser un concern, lo cual no tiene
necesariamente relación con que no se requiera disponibilidad.
Ejemplo: Un sistema de control de aterrizaje tiene un requerimiento
alto de disponibilidad, éste debe estar disponible cuando se lo
requiera, sin embargo no tiene grandes requerimientos de
confiabilidad puesto que no debe estar operativo por un tiempo
excesivo de uso.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Disponibilidad y Confiabilidad
MTTR
Falla
MTTF
Reparación
Falla
MTBF
MTBF
7
Confiabilidad = MTTF
Disponibilidad = MTTF / (MTTF+MTTR)
7
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Mantenibilidad
Mantenibilidad: La habilidad del sistema de
aptitud para sobrellevar reparaciones correctivas
y evolutivas.
¿Por que lo deberíamos considerar aquí?
8
Aunque es un concern más cercano a
Modificabilidad, podríamos no referirnos solo a
piezas de software.
MTTR tiene dependencias sobre esta propiedad
incluso cuando nos refiramos a mantenibilidad de
software y no del sistema en general.
La dependencia en el MTTR hace que nuevos
stakeholders ahora entren en juego con ese
concern en mente al hablar de modificabilidad.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Failures (fallas)
Un sistema falla cuando su comportamiento difiere del
intencionado.
9
Notar que la defición de ―falla‖ está basada en cuanto a
la intención y no con respecto a la especificación. Si la
intención con respecto al comportamiento del sistema
difiere de la especificación del comportamiento, entonces
tenemos una falta (defecto) en la especificación.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Failures Classes
Domain
Value: valor incorrecto computado
Time: servicio entregado fuera de tiempo
Halting
No
-> fail-stop
entrega mas output -> fail-silent
Consecuences
Rango desde benignas hasta catastróficas
Perception
10
Concistent: todos los usuarios tienen la misma
percepción de la falla
Inconsistent: algunos usuarios tienen percepciones
diferentes de la falla (BIZANTINE FAILURE)
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Errors
Un error es un estado del sistema que es
probable nos lleve a un estado de falla (failure).
Sin importar si nos lleva o no a ese estado,
tenemos tres factores:
1.
La redundancia del sistema (por diseño o
inherente a éste)
2.
La actividad del sistema (el error podría
erradicarse antes que cause daño)
3.
La consideración del usuario con respecto a cual
sería un comportamiento aceptable.
Por ejemplo en transmisión de datos existe el concepto
de ―acceptable error rate‖
11
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Faults
Una falta (fault) es la adjudicación o causa
hipotética de un error.
12
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Pathology
Fault -> Error -> Failure
Faults que no se han manifestado en errores se
conocen como dormant failures, en caso contrario
se conoce como active failure.
Un error puede estar latent o detected.
Los errores normalmente se propagan creando otros
errores.
Faults activas no pueden ser observadas solo los
errores pueden serlo.
Un failure se produce cuando un error afecta un
servicio que está siendo entregado al usuario.
Un failure en un elemento de runtime puede o no
afectar el sistema.
13
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Requerimientos para Dependability
RELEVAMIENTO DE CONCERNS
14
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Concerns
Clases de servicios (QoS)
Tiempo fuera planeado
Tiempo de Recuperación
Tasa de fallas
Recuperación de desastres.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Class of Service
Consideremos un sistema de cajeros automáticos. Los cajeros se comunican en tiempo
real con una computadora central que mantiene la información de las cuentas.
Full Service implica que los usuarios pueden consultas saldos e ingresar transacciones
soportadas.
No Service significa que no se pueden realizar consultas ni transacciones.
Ocasionalmente las comunicaciones entre los cajeros y la computadora central fallan, la
computadora central debe ser apagada por cuestiones de mantenimiento, o el servicio
puede verse disminuido en su tiempo de respuesta en situaciones de gran carga de
trabajo.
En casos podríamos aún disponer de parte de los servicios gracias al soporte de
computación local en los cajeros:
Restringir los usuarios a consulta de saldo solamente.
Restringir las transacciones por debajo de determinado límite.
Requerir mayor tiempo para realizar las transacciones.
Restringir a los usuarios solo a efectuar depositos.
La disponibilidad no es un problema binario.
Asociamos grupos de funciones a niveles de
servicio. Esto nos define las clases de servicio.
Debemos identificar el correcto balance entre costo
y nivel de disponibilidad requeridos.
Software Systems Architecture: Foundations; Rick Rozansky, Eoin Woods
16
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Downtime
Planeado
Tareas de mantenimiento requieren remover de servicio
el sistema de manera parcial o total.
Es posible estimar el tiempo que demoran estas tareas.
No Planeado
Ocurre debido a fallas no previstas.
Es posible identificar posibles puntos de falla y trabajar
sobre ellos.
Time to repair (MTTR)
17
La falla es la mitad del problema. Requerimos conocer
para cada posible punto de falla el tiempo que demora
poner el sistema disponible nuevamente.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Resumen: Identificar necesidad real
Capturar requerimientos de disponibilidad
Identificar los tipos de servicio
Identificar los niveles de servicio
Construir un schedule de operación
Operación Normal Requerida
No disponibilidad permitida
Estimar la Disponibilidad de la Plataforma
Estimar la Disponibilidad Funcional
18
Operación regular
Actividades de mantenimiento (backups), analizar
posibilidades de concurrencia.
Proceso batch requeridos
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
ARQUITECTURA Y DEPENDABILITY
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
19
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Software Components & Dependability
Relación entre dependability de los componentes
y de los sistemas
20
Usando (Undependable Components) podemos
construir (Dependable Systems)
Usando (Dependable Component) podríamos
incurrir en construir (Undependable System)
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Software Components & Dependability
Controlar cuidadosamente inter-dependencias
externas del componente
Los cambios de comportamiento de un componente
en particular, incluyendo anomalías, debería tener
mínimo impacto en el comportamiento del sistema
en general.
Restringir
todas las dependencias inter-componente a
ser explicitas a través de sus interfaces públicas.
Minimizar
o completamente eliminar efectos
colaterales en las operaciones que realizan los
componentes.
21
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Software Components & Dependability
Proveer capacidades de reflection a los componentes
En caso que un componente reduzca o interrumpa su
servicio, debe ser posible monitorear su estado interno
de modo de comprender la salud del mismo.
Proveer mecanismos de manejo de excepciones
Si un componente falla, el resto del sistema debe poder
responder ajustándose a esa falla. Para que esto suceda
es necesario que el componente que falla exponga la
información necesaria al resto del sistema.
Los mecanismos de manejo de excepciones forman parte
de la interfaz publica del componente.
Especificar invariantes de estado de los componentes
22
Acotar los cambios internos permitidos al estado de los
componentes permite identificar situaciones
excepcionales.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Software Connectors & Dependability
Emplear conectores que explícitamente controlen
inter-dependencias entre componentes
23
Dependencias no intencionadas a los largo del
sistema dañará la disponibilidad del sistema.
Debemos usar conectores de primera clase que
restrinjan las interacciones y dependencias.
Si es necesario podemos aislar completamente los
componentes.
Algunos conectores ampliamente usados como por
ejemplo shared-memory y procedure-call brindan
excesiva libertad sobre lo que puede el
desarrollador hacer en cuanto a incrementar las
dependencias entre los componentes
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Software Connector & Dependability
Proveer garantías de interacción explícitas.
En algunos escenarios es imperativo que un
componente reciba la informacion enviada, incluso
multiples veces si es necesario. En otros casos
debemos garantizar que los mensajes sean
transmitidos una sola vez y que hacer si nunca son
enviados
Imaginemos un sistema de control de vuelo que recibe cambio de
posición de flaps múltiples instancias que correspondían al mismo
mensaje.
24
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Ejemplo Client-Server
CLIENT = (call->wait->continue->CLIENT).
SERVER = (request->service->reply->SERVER).
||CLIENT_SERVER = (CLIENT || SERVER)
/{call/request, reply/wait}.
25
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Software Connector & Dependability
Utilizar conectores avanzados para soportar
disponibilidad
26
Instanciar replicas de componentes que están
fallando.
Reemplazar en ejecucion componentes caídos.
Soportar multiples versiones de la misma
funcionalidad.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Configuración de Arquitectura & Dependability
Evitar SPOF (Single Point of Failure)
27
Analizar interdependencias entre elementos
(componentes y conectores).
Evitar que la caída o falla de uno de los elementos
comprometa todo el sistema.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Configuración de Arquitectura & Dependability
Proveer backups para funcionalidad y datos
críticos.
Respaldar infraestructura y configuración, además
de datos.
Proveer mecanismos de helth-monitoring no
intrusivos.
Algunas fallas no son obvias hasta que han
generado daños. Es posible tener tratamiento
preventivo.
Identificar eventos que debemos monitorear y que
son indicadores de anomalías.
Muchos sistemas de storage y memoria utilizan un proceso de lectura posterior a
la escritura para verificar que el sistema funciona correctamente. En caso de
diferencia, repiten el proceso sobre otro espacio físico del dispositivo (memoria o
disco) hasta tener éxito. El hecho de falla parcial de este tipo disminuye el nivel
de servicio del dispositivo e inicia el proceso de remoción y reemplazo.
28
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Configuración de Arquitectura & Dependability
Soportar adaptación dinámica
Permiten la adición, remoción, reemplazo y
reconexión de componentes y conectores.
Sistemas descentralizados soportan el
descubrimiento de servicios que es útil para
facilitar la reconfiguración.
Notar
que la disponibilidad del sistema se encuentra
reducida durante y luego de una reconfiguración.
29
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
TÁCTICAS PARA DEPENDABILITY
30
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fallas
Todo sistema de hardware o software tiene fallas.
Se dice que un sistema es tolerante a fallas si
puede seguir operando en presencia de fallas.
SPOF (Single Point of Failure): Punto de falla que
hace que todo el sistema deje de funcionar.
Uno de los puntos a lograr es que no tenga SPOF.
31
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Tipos de falla que debemos identificar
Tipo de Falla
Descripción
Crash failure
El sistema funciona perfectamente hasta que ocurre un error
inesperado. (Kernel panic, pantalla azul, etc)
Omission failure
Receive or Send
El sistema falla recibiendo requerimientos, enviando o recibiendo
mensajes.
Timing failure
El sistema responde fuera de los tiempos esperados
Response failure
Value failure
State transition failure
Respuesta del sistema incorrecta o se desvía del flujo de control
correcto.
Arbitrary failure
El servicio produce una salida incorrecta que no puede ser
detectada
32
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Tactics
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault detection
Ping/Echo
Uno de los componentes emite un ping y espera recibir
un echo de respuesta dentro de un tiempo determinado
Se
34
puede usar
Cuando mas de un componente es responsable de llevar
adelante una tarea.
Cuando un componente cliente quiere asegurar que el
componente server y el conector están operativos. En este
caso el timeframe usado sirve para verificar condiciones de
performance además de disponibilidad.
Detectores de Falla de tipo "Ping/echo" pueden ser
organizados en jerarquías donde el nivel mas bajo
verifica al proceso con quien comparte el procesador, y
los niveles mas altos verifica al nivel anterior. Esto
reduce el ancho de banda requerido contra un fautl
detector remoto que verifique todos los procesos.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault detection
Heartbeat (dead man timer)
Un componente emite una señar de heartbeat
periódicamente y otro componente escucha dicha
señal (listener).
La
falla sobre el componente monitoreado se asume
cuando el listener deja de percibir dicha señal.
El heartbeat tambien puede acarrear datos.
Por
ejemplo un cajero automático podría
periodicamente enviar el log de la ultima transaccion
al server.
35
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Ping/Echo y Heartbeat
Heatbeat
Monitor
Component
Monitor
Ping/Echo
Ping/Echo
Component
Monitor
Ping/Echo
Thread A
Echo/Ping
Thread B
Shared Memory and Processor
36
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault detection
Exceptions
La semántica de ciertas fallas tiene mayor complejidad
que la simple ausencia de interacción.
Un método para reconocer la fallas es detectar por
comportamiento la violación de un contrato (situación
excepcional).
Esto dispara un proceso que se ejecuta en el mismo
procesador que donde se ha originado la falla.
Resumen de Fault Detection
38
El ping/echo y heartbeat operan sobre diferentes
procesos mientras que las excepciones lo hacen sobre el
mismo.
El exception handler normalmente efectúa
transformaciones semánticas a efectos de permitir el
proceso continúe.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Recovery - Estructura
Fault recovery
Recovery / Preparation / Repair
Active
redundancy
Passive
redundancy
Spare
Voting
Recovery reintroduction
Shadow
Synch
Rollback
39
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Recovery - Redundancy
Se puede evitar los SPOF con redundancia y esta se puede
clasificar en:
Redundancia de Información: Se agrega información
redundante en una transmisión o en un
almacenamiento.
Redundancia de Tiempo: Se realiza un acción y luego
si es necesario se vuelve a realizar. Es muy útil para las
fallas transitorias o intermitentes.
Redundancia física: Se agrega hardware o software
extra para que el sistema soporte el mal
funcionamiento de uno de sus componentes.
40
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Redundancy - Confiabilidad en Serie
La Confiabilidad de un conjunto de equipos en serie es el producto de la
confiabilidad de cada uno de los equipos.
Conf.A
Conf.B
Conf.C
N
R (t ) Ri (t )
i 1
Por ejemplo: R = 0,95 * 0,94 * 0, 99 = 0,884
La confiabilidad total de un sistema serie siempre será menor que la
confiabilidad de cualquiera de sus componentes.
41
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Redundancy - Confiabilidad en Paralelo
La Confiabilidad de un conjunto de equipos en paralelo
Conf.A
Conf.B
Conf.C
N
R (t ) 1 (1 Ri (t ))
i 1
La Confiabilidad del conjunto es: ( Conf.A + Conf.B + Conf.C ) / n
Por ejemplo: R = 1 - ( 0,05 * 0,06 * 0, 01 ) = 0,99997
42
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Recovery - Redundancy
Passive redundancy
(warm restart/dual redundancy/triple redundancy).
Un componente (the primary) responde a los eventos e
informa a otros componentes (the standbys) acerca de
actualizaciones del estado en pos de estar
sincronizados.
Ante una falla, el sistema verifica el estado de
actualización de la copia secundaria.
Esta
táctica tiene una gran dependencia en que los
componentes standby sean capaces de tomar el
control.
Se
pueden forzar switchovers periódicamente para
aumentar la disponibilidad del sistema.
44
Notar que la sincronización es responsabilidad del
componente primario que podría usar atomic
broadcasts (pequeñas transacciones del conector que
son reliables) para asegurar sincronización.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Redundancy - Rejuvenecimiento
Si bien los clusters (failover, load balancing ) proveen alta
disponibilidad, se busca soluciones para lo que se
denomina ―Envejecimiento de Software‖ (software
aging), que lleva a fallas de sistema.
La tendencia es que los procesos se ―auto-sanen‖ (sealfhealing)
< MTTR vs > MTBF
Existen dos formas de realizarlo
Por tiempo
Reinicio a intervalos constantes.
En forma predictiva
Analizando parámetros del contexto
45
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Recovery - Redundancy
Active redundancy (hot restart).
Todos los componentes responden en paralelo,
consecuentemente poseen el mismo estado
Solo la respuesta de un componente es usada.
Si ocurre una falla, el tiempo de caída es muy
reducido.
Usualmente
aplica a configuraciones client/server
donde la latencia requerida es baja aún ante caídas.
46
Si son state-full, requerimos que todas las
instancias del mismo componente reciben los
mismos mensajes para que estén sincronizadas
(el estado se actualiza en paralelo).
Aquí los componentes envejecen también en
paralelo.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Recovery - Redundancy
Spare
Una plataforma completa es configurada para
reemplazar diferentes componentes que podrían
fallar
El reemplazo implica reiniciarla con la correcta
configuración de software y setear su estado
interno en caso necesario.
Hacer checkpoint del estado del sistema de
manera periódica y registrando los cambios de
estado (transaction log) facilita la sincronización
de estado
Una
estación de trabajo de repuesto es un ejemplo
frecuente de este modelo.
47
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Sincronización– Checkpoint & Restart
Los checkpoint se pueden realizar desde la aplicación por
intervalos fijos o en lugares de determinados
Una desventaja es que no se pueden recuperar sucesos
únicos que ocurrieron después del checkpoint (en caso
de utilizarlo)
48
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Sincronización–Checkpoint Par de
procesos
Ambos corren versiones idénticas de software.
El procesador primario genera chekpoints y los envía al
secundario.
Al detectarse una falla el procesador secundario retoma a
partir del ultimo checkpoint.
Se puede reemplazar el procesador primario
49
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Voting
Un “Voter” recibe entradas ( no binarias ) y replica en la salida el valor que
tenga la mayoría de sus entradas, en este ejemplo vemos un TMR
Por lo tanto, como las unidades A1, A2 y A3 son exactamente iguales,
deberían dar los mismos valores a la entrada del Voter.
¿ Y si falla el Voter ? [SPOF]
50
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Redundancia – Sistemas Duplex
Los dos procesadores ejecutan lo
mismo.
Si las salidas coinciden se asume
que el resultado es correcto.
Si hay diferencia: ¿ Cuál falló ?
Soluciones posibles:
1 - Test de ambos procesadores.
2 – Utilizar un tercer procesador
para determinar el resultado correcto
3 – Implementar un Sistema Duplex
de backup.
51
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
The Byzantine General’s Problem
Todo sistema de software que se considere
confiable debe lidiar con la falla de uno o más de
sus componentes. Un componente que falle puede
exhibir un tipo de comportamiento anómalo difícil
de identificar.
por ejemplo enviar información anómala a
diferentes partes del sistema.
Este problema se conoce como the Byzantine
Generals Problem.
LESLIE LAMPORT, The Byzantine Generals Problem
http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf
52
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
The Byzantine General’s Problem
Principios
1. Todo general leal debe obtener la misma
información v(1) . . . . , v(n).
2. Si el general ith es leal, entonces el valor que
envía debe ser usado por todo general leal como
el valor v(i).
LESLIE LAMPORT, The Byzantine Generals Problem
http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf
53
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
The Byzantine General’s Problem
Liutenant 2 es traidor
Commander es traidor
54
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
The Byzantine General’s Problem
Algorithm OM(0).
(1) The commander sends his value to every lieutenant.
(2) Each lieutenant uses the value he receives from the commander, or uses
the value RETREAT if he receives no value.
Algorithm OM(m), m > O.
(1) The commander sends his value to every lieutenant.
(2) For each i, let vi be the value Lieutenant i receives from the commander,
or else be RETREAT if he receives no value.
Lieutenant i acts as the commander in Algorithm OM(m - 1) to send the value
vi to each of the n - 2 other lieutenants.
(3) For each i, and each j <> i, let vj be the value Lieutenant i received from
Lieutenant j in step (2) (using Algorithm OM(m - 1)), or else RETREAT if he
received no such value. Lieutenant i uses the value majority (v1 . . . . . vn-1 ).
LEMMA. For any m and k, Algorithm OM (m ) is satisfactory if there are
more than 2k + m generals and at most k traitors.
LESLIE LAMPORT, The Byzantine Generals Problem
http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf
55
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Métodos Multi-Version
Están basados en usar dos o mas versiones del sistema,
y ejecutarlos en secuencia o en paralelo
Recovery Blocks
Recovery Blocks Distribuido
N-Versiones
56
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Recovery Block
Utiliza múltiples versiones de software
Una sola versión corre a la vez, si se detecta que falla se
ejecuta una de backup
Cuando ―Primary‖
termina su ejecución,
envía su salida para
test.
En caso de falla, la
primera versión
alternativa corre
nuevamente desde el
checkpoint mas
cercano.
57
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Recovery Block Distribuido
El Primario del nodo 1 corre en paralelo con el Secundario del
nodo 2
Si falla el Primario en nodo1 se utiliza la salida del nodo 2
El nodo 2 sigue su ejecución hasta fallar.
La ventaja es que no se debe esperar que el sistema haga
rollback.
58
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fault Prevention
Removal from service
Bajo condiciones de falla detectadas desde un componente,
es posible removerlo de servicio de manera anticipada.
Process monitor
Una vez que una falla en un procesador es detectada, un
proceso de monitoreo puede elimiar el proceso anómalo y
crear una nueva instancia.
Transactions
Una transacción es un conjunto de pasos secuenciales tal
que el conjunto se realiza de forma completa o ninguno de
los pasos individuales es efectuado.
Compensación
59
En casos que no sea posible concentrar el estado en un
componente, debemos manejar mecanismos de ―undo‖ o de
compensación.
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Tactics - Estructura
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
Fin
© Cátedra de Ingeniería de Software II – FCEN – UBA, 2009
