fiabilidade de sistemas informÁticos recovering a consistent state trabalho elaborado por : nelson...
TRANSCRIPT
FIABILIDADE DE SISTEMAS INFORMÁTICOS
Recovering a consistent state
Trabalho elaborado por :Nelson De Sousa
n° 20825
RECOVERING A CONSISTENT STATE
1. Introdução 2. Estudo da arte
1. Asynchronous Checkpoint1. Rollback and Domino effect2. Protocolos
2. Synchronous Checkpoint1. Distributed snapshot2. Checkpoint using synchronised clocks
3. Implementação futura 4. Conclusão
1. INTRODUÇÃO
2 métodos de acordo com o tipo de sistema :
a) Uniprocess system● É simples● Usa checkpoint (recovery points) periodicamente● Informações guardadas num espaço seguro● Contem as variáveis, o ambiente, os registros ....● Se há um erro, o process é “rolled back” para o ultimo
checkpoint guardado no espaço seguro
1. INTRODUÇÃO
2 métodos de acordo com o tipo de sistema :
b) Multiple process system● É mais complicado● Estado do sistema = estado de todos os processos● Não há métodos diretos par fazer checkpoints
sincronizados de todos os processos● Método ingénuo: estabelecer independentemente os
checkpoints dos processos● As mensagens trocadas não são representadas
2. ESTUDO DA ARTE
1. Asynchronous Checkpoint• Estado consistente não é necessariamente um
estado que existiu na execução • Neste caso a sequencia de estado é unica• O maior problema é se uma mensagem é enviada,
o checkpoint do processo que recebe deve indicar que recebeu esta mensagem
• Cada processo “checkpoint” periodicamente sem coordinação
• O checkpoint do sistema é o checkpoint de todos os processos (forma um estado consistente)
2.1 ASYNCHRONOUS CHECKPOINT
1. Rollback• O objectivo do “rollback” é de voltar a um estado
que existiu o que podia existir• Os problemas surgem quando há troca de
mensagens, e resulta num estado inconsistente• Mensagem perdidos (Lost message)
• P envia uma mensagem, faz o checkpoint, Q faz o checkpoint antes de receber a mensagem
• Mensagem órfão (Orphan message) • Q recebeu uma mensagem de P, faz o checkpoint, mas
o checkpoint de P indica que ainda não o envio• Efeito de domino (Domino effect)
• Quando um “rollback” induza outro
ORPHAN MESSAGE E DOMINO EFFECT
X
Y
Z
[
[
[
x1
y1
z1
[
[
[
[x2 x3
y2
z2
Roll back
Y ainda não enviou, mas X recebeu.
: Orphan message
: Domino Effect
LOST MESSAGE
X
Y
Z
[
[
[
x1
y1
z1
[
[
[
x2
y2
z2
[x3
Roll back
X enviou, mas Y não pode recever
: Lost message
LIVE LOCKS
x1
X [
z1
Z [
repeated failure
[ recovery point
MODELISACAO DO GRAFICO DE OCORRENCIA
1
2
53
4
T1
F1
Req F1
Req F2
F2
Especificação do estado de restauração•Representa o comportamento do sistema•O circlo representa uma condição•Um duplo circlo representa um “recovery point”•uma barra representa um evento•os arcos de entrada indicam as circunstâncias necessárias para gerar um evento•Os arcos de saida representam as condições depois do evento•O grafo capta toda a execução do sistema•Este modelo facilita a compreenção do “recovering a consistent state”
3
2 algoritmos para o “asynchronous checkpointing”● Checkpoint periodicamente● O mais recente é o activo● 2 ckpts C e C' dos processos P e P' : C é um “direct
propagator” para C' se, e unicamente se, informação é enviada de P para P' quando C e C' são activos
● “indirect propagator” se 2 processos são “direct propagator” de um tercero processo
1. O sistema deve voltar a um estado consistente se um ou muitos processo iniciam a recuperação
2. Deve suportar a determinação dos ckpts com segurança
PROTOCOLOS
• Cada processo mantem a dia uma “Prop-list” que contem a identidade dos ckpts por os quais os seus ckpts são “direct propagator”
• Quando um processo inicia uma recuperação, ele avisa todos os processo que estão na “Prop-list” do seu ckpt activo, enviando um “recovery control message”
PROTOCOLOS
• O segundo protocolo usa 2 tipos de “logs”• A “volatile log” é guarda na memoria principal
– Mais rápido e menos caro– Mas não persista depois de uma falha
• A “sable storage” é o contrario
PROTOCOLOS
CkPti : o ckpt (stable log) que i “rollback” quando falhou
RCVDi←j (CkPti / e ) :o numero de mensagens que o processo i recebeu do processor j (de acordo com a informação do ckpt i ou de e)
SENTi→j(CkPti / e ) :o numero de mensagens que o processor i envio o processor j (de acordo com a informação do ckpt i ou de e)
PROTOCOLOS
Algoritmo1. Quando um processo falha, recupera o ultimo CkPt.2. Transmite uma mensagem de erro. Outros recebem esta
mensagem, e rollback ao ultimo evento.3. Cada processo emite SENT(CkPt) aos processos vizinhos4. Cada processo espera as mensagens SENT(CkPt) de cada vizinho5. Em receber SENTj?i(CkPtj) de j, se i observar RCVDi?j (CkPti) > SENTj?i(CkPtj), rola para trás ao evento 'e'
tais que RCVDi?j (e) = SENTj?i(e) , 1. repita 3,4,e 5 N vez (N é o número dos processos)
PROTOCOLOS
Asynchronous Recovery
X
Y
Z
Ex0 Ex1 Ex2 Ex3
Ey0 Ey1 Ey2 Ey3
Ez0 Ez1 Ez2
[
[
[
x1
y1
z1
(Y,2)
(Y,1)
(X,2)
(X,0)
(Z,0)
(Z,1)
3 <= 2
RCVDi←j (CkPti) <= SENTj→i(CkPtj)
2 <= 2
X:Y
X:Z
0 <= 0
1 <= 2
Y:X
1 <= 1
Y:Z
0 <= 0
Z:X
2 <= 1
Z:Y
1 <= 1
2.2 SYNCHRONOUS CHECKPOINT
tentative checkpoint : Checkpoint temporario Um candidato para ckpt permanente
permanent checkpoint : Um ckpt local a um processo Uma parte de um ckpt global consistente
2.2.2 SYNCHRONOUS CKPT ALGORITHM
Algoritmo• O process iniciador faz um “tentative checkpoint• Pede aos outros processos fazer um “tentative checkpoint”• Espera a recepção dos outros processos uma msg como o
“tentative checkpoint” foi sucedido • Quando todos os processos sucedem, decide que todos os
ckpts devem ser permanente; se não, deve ser rejeitado.• Informa todos os processos de sua decisão• Os processos que recebem a decisão agem conformemente
Cada mensagem é etiquetada pela ordem da emissão
Labeling Scheme
last_label_rcvdX[Y] : o ultimo mensagem que X recebeu de Y depois X fazer o ultimo ckpt (tentative ou permanente). Se não existe, contem o mais pequeno label
first_label_sentX[Y] : primeira msg que X envia a Y depois do ultimo ckpt (tentative o permanente). Se não existe, contem o mais pequeno label
ckpt_cohortX :conjunto de todos os processos que deverem fazer ckpts quando X faz o checkpoint.
roll_cohortX :conjunto de todos os processos que deverem fazer “rollback” para o ultimo ckpt quando X faz um “rollback”
Y reiniciará a partir do ckpt permanente apenas se
last_label_rcvdY[X] > last_label_sentX[Y]
[
[
X
Y
x2x3
y1 y2y2
x2
2.2.2 SYNCHRONOUS CKPT ALGORITHM
Algorithm1. an initiating process takes a tentative checkpoint2. it requests p ∈ ckpt_cohort to take tentative checkpoints ( this
message includes last_label_rcvd[reciever] of sender )3. if the processes that receive the request need to take a checkpoint,
they do the same as 1.2.; otherwise, return OK messages.4. they wait for receiving OK from all of p ∈ ckpt_cohort5. if the initiator learns all the processes have succeeded, it decides
all tentative checkpoints should be made permanent; otherwise, should be discarded.
6. it informs p ∈ ckpt_cohort of the decision7. The processes that receive the decision act accordingly
2.2.2 SYNCHRONOUS CKPT ALGORITHM
3. IMPLEMENTACAO
• Solução a implementar :– “Asynchronous checkpoint” com varios
processos (mas sem comunicação entre eles)
4. CONCLUSAO
Os erros podem ser corrigidos com metodos de recuperação
Os ckpts sincronisados são mais performente (limitam a quantidade de ckpts) mas são mas difíceis e custam mais (comunicação e sincronisação)
Os ckpt assincronos são menos eficazes (domino effect)