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)