Fiabilidade de Sistemas Informáticos Acções Atómicas

Apresentação em tema: "Fiabilidade de Sistemas Informáticos Acções Atómicas"— Transcrição da apresentação:

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

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

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

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

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

6 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32 Protocolo Commit das Duas Fases

33 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”).

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

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

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

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

38 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).

39 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”.

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

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

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

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

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