FIABILIDADE DE SISTEMAS INFORMÁTICOS

1. FIABILIDADE DE SISTEMAS INFORMÁTICOS Recovering a consistent state Trabalho elaborado por : Nelson De Sousa n° 20825

2. RECOVERING A CONSISTENT STATE • Introdução • Estudo da arte • Asynchronous Checkpoint • Rollback and Domino effect • Protocolos • Synchronous Checkpoint • Distributed snapshot • Checkpoint using synchronised clocks • Implementação futura • 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. 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

12. 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

13. 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

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

15. 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) > 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) PROTOCOLOS

16. Asynchronous Recovery X:Y X:Z x1 Ex0 Ex1 Ex2 Ex3 [ 2 <= 2 3 <= 2 0 <= 0 X (X,2) (Z,0) (Y,2) Y:X Y:Z y1 Ey0 Ey1 Ey2 Ey3 [ 1 <= 2 1 <= 1 (X,0) Y (Z,1) (Y,1) Z:X Z:Y Ez1 Ez2 Ez0 [ 0 <= 0 2 <= 1 1 <= 1 Z z1 RCVDi←j (CkPti) <= 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. 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 :conjuntode 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] 2.2.2 SYNCHRONOUS CKPT ALGORITHM [ X x3 x2 y1 y2 y2 [ Y x2

20. Algorithm an initiating process takes a tentative checkpoint it requests p ∈ ckpt_cohort to take tentative checkpoints ( this message includes last_label_rcvd[reciever] 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 2.2.2 SYNCHRONOUS CKPT ALGORITHM

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)