fiabilidade de sistemas informáticos acções atómicas trabalho realizado por: luís almeida nº...

44
Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Upload: internet

Post on 21-Apr-2015

103 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Fiabilidade de Sistemas Informáticos

Acções Atómicas

Trabalho realizado por:

Luís Almeida nº 15101

Page 2: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Acções Atómicas

Serviço tolerante a falhas Objectivo:

Fazer com que algumas operações pareçam atómicas mesmo que ocorram falhas no sistema.

Isto é, o serviço a ser preservado quando existem falhas é a atomicidade das operações.

Page 3: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Acções Atómicas

Uma acção “user-defined” pode ser considerada como uma sequência de acções primitivas ou passos que são executados indivisivelmente pelo sistema.

Isto é, ou uma acção completa com sucesso, ou o sistema mantêm-se inalterado, não havendo qualquer efeito da acção primitiva sobre o estado deste.

A própria acção “user-defined” não é executada atomicamente pelo hardware.

O objectivo de suportar acções atómicas é executar a acção “user-defined” atomicamente.

Page 4: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Acções Atómicas e Serialização Uma acção atómica é um mecanismo que permite

ao utilizador especificar uma operação como sendo atómica.

Uma acção atómica goza das mesmas propriedades da atomicidade: Indivisibilidade; Não-interferência; Sequênciamento estrito.

O objectivo é fornecer uma máquina abstracta que execute as acções “user-defined” atomicamente.

Page 5: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Acções Atómicas e Serialização Uma acção é atómica se durante a execução desta,

o processo que a está a executar não sabe da existência de outra actividade e não pode ver qualquer mudança de estado que possa ocorrer fora da acção.

Para mais, nenhum outro processo sabe da acção deste processo, e as suas mudanças de estado são escondidas fora da acção.

Uma acção é atómica se poder ser considerada, tanto quanto outros processos, como indivisível e instantânea.

Page 6: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Acções Atómicas e Serialização Apenas o estado inicial ou o estado final da

acção pode ser visualizado, e nenhum estado interno é visível .

Propriedade “tudo-ou-nada”: Ou uma acção atómica faz a sua computação

completamente ou não faz nada (ou faz com que pareça que não fez nada).

Page 7: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Acções Atómicas e Serialização Num sistema uni-processo é relativamente simples

suportar atomicidade (utilizando checkpoints). Num sistema distribuído, já que se pode aceder aos

dados concorrentemente através de processos diferentes, suportar acções atómicas torna-se mais complicado.

Acesso concorrente a dados partilhados pode causar inconsistência no estado dos dados, a não ser que o acesso concorrente seja correctamente coordenado.

Page 8: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Transacções

Embora as acções atómicas formem uma primitiva geral para construir aplicações distribuídas confiáveis e tolerantes a falhas, têm um interesse particular na construção de bases de dados.

Consideramos uma base de dados como sendo um conjunto de dados ou objectos.

Podem ser efectuadas duas operações básicas sobre os dados: leitura e escrita.

Assumimos que ler ou escrever um dado é atómico, e é efectuado de uma maneira indivisível pelo hardware.

Isto é, operações de leitura e escrita sobre dados particulares são sempre feitas de uma maneira sequencial, e uma nova operação apenas começa depois da prévia ter sido acabada.

Page 9: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Transacções

Num contexto de bases de dados, a acção a ser executada atomicamente chama-se transacção.

Uma transacção é uma operação “logical user” que efectua uma sequência de leituras e escritas sobre entidades.

Transacções são a unidade lógica fundamental de computação num sistema de bases de dados.

Se a base de dados for consistente, então é garantido que uma execução isolada bem sucedida de qualquer transacção vai deixar a base de dados num estado consistente

Executar transacções concorrentemente pode violar a consistência se as suas operações não estiverem coordenadas.

Page 10: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Transacções

Exemplo de transacção: “transferir algum dinheiro da conta A para a conta B”.

Uma transacção típica começa sempre com um comando begin-of-transaction (BOT), e acaba com um comando end-of-transaction (EOT).

Um EOT é muitas vezes precedido por um comando commit, o qual assegura que os efeitos da transacção são guardados permanentemente na base de dados.

Page 11: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Transacções

É necessário que a propriedade “tudo-ou-nada” seja satisfeita mesmo na presença de falhas.

Um requerimento para as acções atómicas é a durabilidade.

Durabilidade significa que se uma acção concluiu com sucesso (i.e., a acção é “committed”), então os seus efeitos nunca se perdem.

Page 12: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Transacções

Tanto o acesso concorrente como as falhas podem violar a atomicidade.

Para suportar acções atómicas, têm de ser fornecidos mecanismos para lidar com ambos.

No contexto das bases de dados, os métodos de sincronização utilizados para lidar com acesso concorrente são chamados muitas vezes Protocolos de Controlo de Concorrência.

As técnicas para preservar a atomicidade na presença de falhas são frequentemente chamadas “recovery protocols”.

Page 13: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Definimos uma transacção T como uma sequência de n passos.

T = ((T,ai,ei))ni=1, onde T é o nome da

transacção, ai é a operação feita no passo i (uma operação ou é R (read) ou W (write)), e ei é a entidade de dados sobre a qual a operação é feita.

Page 14: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Considere m transacções concorrentes T1, T2, …, Tm.

Qualquer sequência de operações obtida por ordenamento das operações das diferentes transacções chama-se “schedule”.

Numa “schedule”, a ordem das operações de uma transacção é mantida.

Uma “schedule” representa uma execução possível de transacções, na qual operações de processos diferentes podem alternar.

Page 15: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Uma “schedule” é chamada “serial schedule” se todas as operações de uma transacção ocorrerem em simultâneo (i.e., contiguamente) na “schedule”.

Uma “serial schedule” representa uma execução em série das transacções nas quais a execução de uma nova transacção é iniciada somente quando a execução da transacção anterior tiver completado.

Uma “serial schedule” nunca irá levar a nenhuma inconsistência, uma vez que uma nova transacção apenas começa quando a execução da transacção prévia tiver completado e nunca nenhuma transacção vê o estado interno de outra transacção.

Page 16: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

O problema da consistência ocorre quando a alternância de operações entre diferentes transacções é permitida (“Non-serial schedules”).

“Non-serial schedules” têm o potencial de levar a colecção das entidades de dados para um estado inconsistente, mas também permitem acesso concorrente a dados partilhados.

Page 17: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Critério de serialização: Duas transacções não podem parecer

concorrentes e o resultado de executar transacções diferentes deve ser como se as transacções fossem executadas em série por uma dada ordem.

Serialização significa que a “schedule” de transacções deve ser tal que seja equivalente a uma “schedule” em série.

Page 18: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Equivalência de “schedules”: Numa “schedule” S, definimos uma relação de

dependência DEP(S) como uma relação ternária T * E * T, onde T é o conjunto de transacções e E é o conjunto de entidades.

Um valor (T1,e,T2) DEP(S) se para qualquer i < j: S = (…, (T1,ai,e), …, (T2,aj,e), …)

e não existe nenhum k tal que i < k < j e ek = e, e um de (ou os dois) ai ou aj é uma operação de escrita.

Page 19: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

A relação DEP captura a dependência entre operações de diferentes transacções.

Uma operação depende de outra operação que tenha ocorrido anteriormente a ela se a operação anterior for sobre a mesma entidade que esta operação é.

Exemplo: Se (T1,e,T2) então T1 pode ser escrever um valor em e, o

qual irá ser lido mais tarde por T2. Desde que uma leitura anterior de uma entidade não

afecte uma leitura posterior, não é incluída na definição de DEP.

Page 20: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Duas “schedules” S1 e S2 são equivalentes se DEP(S1) = DEP(S2).

Uma “schedule” S é serializável se DEP(S) for a mesma que a DEP de outra “schedule” em série.

Com transacções, requer-se que a “schedule” seja serializável. Se a “schedule” de um conjunto de transacções é serializável,

isso implica que cada transacção vê o mesmo estado que veria numa outra qualquer execução de transacções em série.

Desde que se assuma que a execução em série de transacções leva a um estado consistente do sistema, uma “schedule” em série também irá levar a um estado consistente.

Page 21: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Para uma “schedule” em série S : se (Ti,e1,Tj) DEP(S) para uma qualquer entidade e1,

então isso implica que (Tj,em,Ti) DEPS(S) para qualquer entidade em.

Esta condição implica que podemos definir uma relação binária < sobre o conjunto de transacções, tal que Ti < Tj se (Ti,e1, Tj) DEP(S) para qualquer entidade e1.

Desde que uma “shedule” serializável seja equivalente a uma “schedule” em série, isso implica que as condições também se mantêm para uma “schedule” serializável.

Page 22: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Atomicidade e Serialização

Se a serialização for preservada, então o estado da base de dados depois de executar um conjunto de transacções é consistente.

A serialização restringe essencialmente o conjunto de execuções válidas possíveis sobre um subconjunto de todas as execuções possíveis numa execução concorrente geral.

Page 23: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolos Commit

O objectivo do comando commit é assegurar que todos os efeitos da transacção se reflectem na base de dados, e que eles nunca serão desfeitos no futuro.

O “protocolo commit” assegura essencialmente que o log redo da transacção é escrito antes do commit.

LOG: Dados do log são informação redundante, que é guardada para

ser restaurada caso haja falhas. REDO:

Resultados de algumas das transacções completadas podem ainda não ter sido guardadas na altura da falha. Essas transacções têm de ser refeitas “redone”, para que os seus efeitos apareçam na base de dados.

Page 24: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolos Commit

Num sistema distribuído, a situação é mais complexa.

Os dados estão distribuídos por vários nós. Cada nó gere algumas entidades de dados, e

apenas esse nó pode aceder a essas entidades. Um processo (transacção) que queira fazer uma

operação sobre uma entidade tem de pedir ao nó que gere essa entidade para efectuar essa operação.

Daqui, operações diferentes de uma transacção podem ser efectuadas em nós diferentes.

Page 25: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolos Commit

Ao contrário de um sistema centralizado, onde uma falha significa falha completa (i.e., nenhum dado está disponível), num sistema distribuído, a falha de um nó não pára toda a computação da transacção.

Apenas as partes da transacção que eram para ser executadas no nó que falhou são afectadas.

Desde que uma transacção é uma operação “tudo-ou-nada”, se algumas partes da transacção não poderem ser efectuadas, então todas as actividades da transacção têm de ser desfeitas para dar a parecer que nada foi feito pela transacção.

Page 26: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolos Commit

Num sistema distribuído, é possível que um nó possa “abortar” a parte da transacção que está a ser efectuada nesse nó.

Esse aborto pode ocorrer devido à falha de um nó, ou por outra razão qualquer.

Se isto acontecer, então mesmo que os outros nós possam efectuar as suas partes da transacção, a transacção inteira têm de ser abortada.

Apenas se todos os nós que fazem parte da transacção quiserem fazer commit, a transacção pode fazer commit.

Page 27: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolos Commit

Para assegurar isto, um protocolo commit é necessário.

Um protocolo commit assegura que ou que toda a transacção faz commit, i.e., todos os nós que fazem parte da transacção fazem commit, ou toda a transacção aborta, i.e., todos os nós que fazem parte da transacção abortam.

Chama-se a isto a propriedade do commit atómico.

Page 28: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases Neste trabalho, iremos assumir que existe um processo em cada

nó que participa na transacção que efectua as actividades da transacção nesse nó (incluindo a execução das actividades do protocolo commit).

O mais simples e mais popular protocolo commit é o protocolo commit das duas fases (2PC).

Neste protocolo, o nó onde a transacção é iniciada (ou o processo a executar a transacção) é chamado coordenador.

Os outros nós (ou processos nesses nós) que participam na acção chamam-se participantes.

O protocolo das duas fases é um protocolo mestre-escravo .

Page 29: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases O protocolo funciona em duas fases. Na primeira fase:

O coordenador envia uma mensagem “commit-request” a todos os participantes.

Cada participante envia então o seu voto ao coordenador acerca da sua vontade para fazer commit.

Se por uma qualquer razão um participante não consegue executar a sua parte da transacção localmente, ele envia uma mensagem NÃO (i.e., abort), senão envia uma mensagem SIM (i.e., commit).

Isto reflecte a decisão local de cada nodo.

Page 30: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases Na segunda fase:

O coordenador reúne as respostas de todos os participantes.

Se todas elas forem SIM (e a do próprio coordenador também for SIM), o coordenador envia uma mensagem COMMIT a todos os participantes.

De outro modo, o coordenador decide abortar e envia uma mensagem ABORT a todos os participantes que votaram SIM (os que votaram NÃO já decidiram localmente abortar a transacção).

Cada participante espera pela decisão do coordenador. Quando recebe a mensagem, age de acordo com ela.

Page 31: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases Este protocolo, tal como outros protocolos

commit, pode ser modelado por um conjunto de autómatos finitos (FSA), com um FSA representando um estado.

O FSA para o coordenador e para o participante no 2PC é mostrado na figura seguinte.

Page 32: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases

Page 33: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases O estado de um FSA representa o estado do protocolo num nó

em particular. Uma transacção num FSA consiste em receber uma ou mais

mensagens, (fazer alguma computação) e enviar zero ou mais mensagens.

Estes FSA’s são normalmente não deterministas, e têm dois estados finais possíveis (representando os dois resultados possíveis para um protocolo commit): o estado commit c, e o estado abort a.

Nos FSA’a para o 2PC, cada FSA tem 4 estados: um estado inicial (q), um estado wait (w), um estado abort (a) e um estado commit (c).

Cada transição no FSA está marcada pelas condições nas mensagens recebidas (o “numerador”) que causam a transição, e as mensagens que o FSA envia (o “denominador”).

Page 34: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Acções Timeout

O protocolo 2PC é muito vulnerável a falhas. Em muitos estados do protocolo, um processo (participante ou o

coordenador) está à espera que algumas mensagens cheguem. Se as mensagens não chegarem devido a uma falha na rede ou

falha de envio, os processos permanecerão bloqueados. Para evitar isto, são adicionadas acções timeout ao protocolo. Quando o processo está à espera de mensagens, ele move-se

para outro estado se ocorrer um timeout. Nos FSA’s dos processos, isto reflecte-se como transições

timeout.

Page 35: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Acções Timeout Consideremos diferentes sítios onde o processo

está à espera de uma mensagem, e acontecem falhas de transição.

A primeira situação é quando um participante se encontra no estado inicial q, onde está à espera pela mensagem “request-commit”. Desde que isto aconteça antes do participante ter dado o

seu voto ao coordenador, e desde que nesse estado cada participante possa decidir localmente fazer abort ou commit, se ocorrer um timeout, o participante pode decidir abortar, com segurança.

Page 36: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Acções Timeout

A segunda situação é quando o coordenador está à espera no estado w por votos dos participantes. Desde que nesse estado o coordenador ainda

não tenha chegado a uma decisão final (e não tenha informado nenhum participante sobre ela), ele pode decidir abortar, com segurança, se ocorrer um timeout.

Page 37: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Acções Timeout A última situação é quando um participante termina

e, depois de votar SIM, está à espera no estado w pela decisão final do coordenador. Por agora assumimos que se isso acontece porque o

coordenador falhou. Uma consequência do 2PC é que se um processo votou

NÃO, ele sabe que a decisão final será abortar, mas se votou SIM, não sabe qual será a decisão final.

Ao contrário dos outros dois casos, neste caso o participante deve consultar os outros participantes par decidir o que fazer.

Page 38: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Acções Timeout As actividades que devem ser executadas para

tomar a decisão são executadas por um protocolo de terminação.

Um protocolo de terminação é executado por um “sítio” quando a execução continuada do protocolo commit não é possível devido à falha de outros “sítios”.

O objectivo de um protocolo de terminação é assegurar que todos os “sítios” operacionais chegam ao mesmo estado final (commit ou abort).

Page 39: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Acções Timeout Um protocolo possível é:

Quando um participante P termina no estado w, pergunta aos outros participantes sobre qual a decisão que eles receberam.

Se existir um participante operacional Q que tenha recebido uma decisão commit (e tenha votado SIM), ou tenha votado NÃO (e depois saiba que a decisão final será abortar), ele pode dizer ao processo P qual a é decisão final acerca do commit da transição.

No entanto, na situação em que o coordenador tenha falhado depois de apenas ter sido capaz de enviar a sua decisão a alguns dos participantes, se todos esses processos que tenham votado NÃO ou tenham recebido a decisão final do coordenador também tenham falhado, não há nada que P possa fazer a não ser esperar até que um processo, que conheça a decisão final, recupere.

O 2PC está sujeito a bloqueios mesmo com a utilização de transições timeout, mesmo que só ocorram falhas de “sítio”.

Page 40: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Recuperação (Recovery) Vamos considerar o segundo aspecto das falhas de

sítio: um sítio “falhado” que está a recuperar. Assumimos que um sítio guarda o seu estado

corrente numa memória estável. Assim recuperá-lo pode determinar o estado em

que falhou. Durante o período em que o sítio esteve

inoperacional, outros sítios podem ter chegado a uma decisão “visando o commit”.

O estado recuperado tem de se assegurar que toma uma decisão que é consistente com as decisões dos outros.

Page 41: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Recuperação (Recovery) É claramente desejável que o protocolo seja

tal que o estado recuperado possa decidir o estado final, baseado no seu estado local.

Isto dá pelo nome de recuperação independente (independent recovery).

Nem sempre é possível ter um protocolo que suporte recuperação indepente.

Page 42: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Recuperação (Recovery) No 2PC, vamos considerar a falha de um

processo participante P: Se P falha no estado q, desde que ainda não

tenha votado SIM, e desde que saibamos que um timeout, faz com que a decisão do coordenador seja abortar, devido à sua falha, P pode abortar em segurança a transacção depois de recuperar.

De modo similar, se P falhar depois de enviar uma mensagem ABORT, ele pode abortar em segurança.

Page 43: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Recuperação (Recovery) No entanto, se P falha no estado de espera

w, depois da recuperação não pode decidir sozinho se faz abort ou commit, uma vez que a decisão final pode ter sido ou abort ou commit.

Esta situação é exactamente similar ao caso em que P apanha um timeout no estado w.

Assim P pode chegar a uma decisão usando o protocolo de terminação discutido anteriormente.

Page 44: Fiabilidade de Sistemas Informáticos Acções Atómicas Trabalho realizado por: Luís Almeida nº 15101

Protocolo Commit das Duas Fases – Recuperação (Recovery) O protocolo commit das duas fases requer

um total de 3n mensagens na ausência de falhas, se existirem n participantes no sistema.

Existem algumas variações do protocolo para reduzir a sobrecarga de mensagens.

Por exemplo o protocolo presumed commit e o protocolo early prepare.