FIABILIDADE DE SISTEMAS INFORM

1
FIABILIDADE DE SISTEMAS INFORMÁTICOS

• Recovering a consistent state
• Trabalho elaborado por
• Nelson De Sousa
• n 20825

2
RECOVERING A CONSISTENT STATE

1. Introdução
2. Estudo da arte
3. Asynchronous Checkpoint
4. Rollback and Domino effect
5. Protocolos
6. Synchronous Checkpoint
7. Distributed snapshot
8. Checkpoint using synchronised clocks
   
9. Implementação futura
   
10. Conclusão

3
1. INTRODUÇÃO

• 2 métodos de acordo com o tipo de sistema
• 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

4
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

5
2. ESTUDO DA ARTE

• 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)

6
2.1 ASYNCHRONOUS CHECKPOINT

• 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

7
ORPHAN MESSAGE E DOMINO EFFECT
x1
x2
x3



X
Y ainda não enviou, mas X recebeu.
y1
y2


Orphan message
Y
Roll back
z1
z2


Z
Domino Effect
8
LOST MESSAGE
x1
x2
x3



X
X enviou, mas Y não pode recever
y1
y2


Lost message
Y
Roll back
z1
z2


Z
9
LIVE LOCKS

• x1
• X
• z1
• Z
• repeated failure
• recovery point

10
MODELISACAO DO GRAFICO DE OCORRENCIA
1

• 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

F1
Req F1
4
3
3
Req F2
5
T
1
2
F2
11
PROTOCOLOS

• 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

12
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

13
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

14
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)

15
PROTOCOLOS

• Algoritmo
• Quando um processo falha, recupera o ultimo CkPt.
• Transmite uma mensagem de erro. Outros recebem
  esta mensagem, e rollback ao ultimo evento.
• Cada processo emite SENT(CkPt) aos processos
  vizinhos
• Cada processo espera as mensagens SENT(CkPt) de
  cada vizinho
• Em receber SENTj?i(CkPtj) de j, se i observar
• RCVDi?j (CkPti) gt SENTj?i(CkPtj), rola para
  trás ao evento 'e' tais que RCVDi?j (e)
  SENTj?i(e) ,
• repita 3,4,e 5 N vez (N é o número dos
  processos)

16
Asynchronous Recovery
XY
XZ
x1
Ex0
Ex1
Ex2
Ex3

3 lt 2
2 lt 2
0 lt 0
X
(X,2)
(Z,0)
(Y,2)
YX
YZ
y1
Ey0
Ey1
Ey2
Ey3

1 lt 2
1 lt 1
(X,0)
Y
(Z,1)
(Y,1)
ZX
ZY
Ez1
Ez2
Ez0

0 lt 0
2 lt 1
1 lt 1
Z
z1
RCVDi?j (CkPti) lt SENTj?i(CkPtj)
17
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

18
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

19
2.2.2 SYNCHRONOUS CKPT ALGORITHM

• Cada mensagem é etiquetada pela ordem da emissão
• Labeling Scheme
• last_label_rcvdXY 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_sentXY 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_rcvdYX gt last_label_sentXY

X
x3
x2
y1
y2
y2

Y
x2
20
2.2.2 SYNCHRONOUS CKPT ALGORITHM

• Algorithm
• an initiating process takes a tentative
  checkpoint
• it requests p ? ckpt_cohort to take tentative
  checkpoints ( this message includes
  last_label_rcvdreciever of sender )
• if the processes that receive the request need to
  take a checkpoint, they do the same as 1.2.
  otherwise, return OK messages.
• they wait for receiving OK from all of p ?
  ckpt_cohort
• if the initiator learns all the processes have
  succeeded, it decides all tentative checkpoints
  should be made permanent otherwise, should be
  discarded.
• it informs p ? ckpt_cohort of the decision
• The processes that receive the decision act
  accordingly

21
3. IMPLEMENTACAO

• Solução a implementar
• Asynchronous checkpoint com varios processos
  (mas sem comunicação entre eles)

22
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)