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 Checkpoint 1. Rollback and Domino effect 2. Protocolos 2. Synchronous Checkpoint 1. Distributed snapshot 2. 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 [ [ [ x1x1 y1y1 z1z1 [ [ [ [ x2x2 x3x3 y2y2 z2z2 Roll back Y ainda não enviou, mas X recebeu. : Orphan message : Domino Effect

LOST MESSAGE X Y Z [ [ [ x1x1 y1y1 z1z1 [ [ [ x2x2 y2y2 z2z2 [ x3x3 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 T 1 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

CkPt i : o ckpt (stable log) que i “rollback” quando falhou RCVD i←j (CkPt i / 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) SENT i→j (CkPt i / 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

Algoritmo 1. 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 vizinhos 4. Cada processo espera as mensagens SENT(CkPt) de cada vizinho 5. 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 Ex0Ex1Ex2Ex3 Ey0Ey1Ey2 Ey3 Ez0 Ez1Ez2 [ [ [ 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_rcvd X [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_sent X [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_cohort X : conjunto de todos os processos que deverem fazer ckpts quando X faz o checkpoint. roll_cohort X : 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_rcvd Y [X] > last_label_sent X [Y] [ [ X Y x2 x3 y1y2 x SYNCHRONOUS CKPT ALGORITHM

Algorithm 1. an initiating process takes a tentative checkpoint 2. 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_cohort 5. 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 decision 7. The processes that receive the decision act accordingly 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)