Universidade Estadual Paulista Serviços de Tempo, exclusão mútua, eleição e acordo

Transcrição

1 Universidade Estadual Paulista Serviços de Tempo, exclusão mútua, eleição e acordo Alunos: Anuar Mamede Neto Eduardo Hitoshi Aoki Professor: Norian Marranguello São José do Rio Preto

2 SERVIÇOS DE TEMPO É importante saber a ordenação total de todos os eventos em um sistema, por exemplo para saber qual evento requisitou acesso a algum recurso do sistema primeiro. Para muitas ocasiões é suficiente que todas as máquinas estejam de acordo a respeito de uma determinada marcação de tempo, não sendo importante que este tempo coincida com o tempo real. Nesses algoritmos se refere aos clocks como clock lógico. Se houver uma restrição adicional que exija que os clocks não somente sejam os mesmos mas que também concordem com determinada marcação de tempo a qual não pode diferir do relógio real mais do que um determinado valor. Em sistemas onde o conhecimento do tempo real é importante, utiliza-se clocks físicos. Lamport mostrou que é possível a sincronização dos clocks lógicos para produzir um tempo padrão único e sem ambigüidade, baseado numa relação de acontecimento/anterioridade. A expressão a b é lido como a acontece antes de b e significa que todos os processos concordam que primeiro ocorre o evento a e depois o b. A relação acontecimento/anterioridade definida por Lamport segue: - se a e b são eventos no mesmo processo, e se a ocorre antes de b, então a b é verdadeira - se a é o evento de uma mensagem sendo enviada para um processo, e b é o evento da mesma mensagem sendo recebida por um outro processo, então a relação ab também é verdadeira. Observe que uma mensagem não pode ser recebida antes de Ter sido enviada, pois ela demora um tempo finito para chegar ao destino. Se dois eventos x e y ocorrem em processos diferentes e que não trocam mensagens (nem indiretamente) então nem x y e nem y x são verdadeiras. Eles são eventos concorrentes ou seja nada pode ser dito a eles sobre quem ocorreu antes ou depois. No algoritmo de Lamport, cada processo tem seu próprio clock, rodando em velocidades que não são necessariamente as mesmas. Ele pode ser exemplificado da seguinte maneira: um processo manda uma mensagem P ao processo B no instante 6 marcado pelo relógio do emissor. Ele chega a B no instante 16 marcado pelo relógio do receptor então, tem-se tempo de trânsito igual a 10 unidades de tempo. Se por exemplo uma mensagem T é enviada por A no instante 10 e chega em B no instante 6, ocorre um tempo negativo. E como sabemos que não é possível tratar tempos negativos, e como B sabe que a mensagem saiu de A no instante10 e levou um certo tempo par chegar em B, então B atribui ao seu relógio o valor de 11, correspondendo ao instante de saída da mensagem mais uma unidade de tempo. A partir daí ele volta a incrementar o relógio com seu período normal. Para evitar ambigüidades, se um processo receber mais de uma mensagem ao mesmo tempo, ele associa ao tempo de cada mensagem o número do processo que o originou.

3 EXCLUSÃO MÚTUA Algoritmo de Passagem de Ficha ou Token Ring Podemos demonstrar este algoritmo através de uma rede em anel onde cada processo sabe quem é o próximo da seqüência. Depois de inicializado o anel, o primeiro processo pega a ficha (token) e vê se ele está tentando entrar na Região Crítica (R.C.). Se estiver, entra na R.C., faz todo o trabalho na R.C. e a deixa (não é permitido entrar em uma 2ª R.C. usando o mesmo token). Senão passa o token para o próximo processo. Como conseqüência, quando nenhum processo precisa executar qualquer R.C., a ficha circula ao longo da rede em alta velocidade. O token circula pelos processos numa ordem bem definida então não existe chance de ocorrer starvation. O pior que pode ocorrer quando um processo decidir entrar numa R.C. é ter que esperar que todos os processos que receberem o token antes dele executem uma R.C. Problemas: - perda do token (desaparecimento) é difícil detectar seu desaparecimento pois o fato de ele não aparecer por um certo tempo não significa que ele sumiu, ás vezes um processo ainda está com posse dele, executando uma R.C. - algum processo pára se resolve o problema obrigando todo o processo acusar o recebimento do token. Se um processo estiver morto, ele será identificado quando um vizinho seu tentar e não conseguir passar o token, aí o processo morto pode ser removido do anel e o que está de posse do token passar o token para o próximo processo pulando aquele processo morto. Exclusão Mútua por disputa Este algoritmo de Ricard e Agrawala requer que haja uma ordenação total de todos os eventos no sistema. Isto é, para qualquer par de eventos, como mensagens, não deve haver ambigüidade na qual quem ocorre primeiro. O algoritmo de Lamport apresentado antes, é um modo de alcançar esta ordenação e pode ser usada para fornecer timestamp para a exclusão mútua distribuída. O algoritmo funciona da seguinte maneira: quando um processo quer entrar na região crítica, ele constrói uma mensagem contendo o nome da região crítica que está interessado, o número do seu processo, e o tempo corrente. Ele envia a mensagem para todos os outros processos, inclusive ele próprio. Assume-se que o envio das mensagens é feito de forma confiável, isto é, toda mensagem é reconhecida pelo receptor. Quando um processo recebe uma requisição de outro processo, a ação que esse processo toma depende do seu estado com relação à região crítica nomeada na mensagem. Devem ser identificados três casos: 1 - Se o receptor não está executando a região crítica e não quer entrar na região crítica, ele retorna um OK para o transmissor. 2 - Se o receptor estiver na região crítica, ele não responderá. Ele coloca numa fila a requisição. 3 - Se o receptor quiser entrar na região crítica mas não o fez ainda, ele deve comparar o timestamp da mensagem que ele acabou de receber com o timestamp da

4 mensagem que ele enviou para todos. O menor timestamp ganha. Se a mensagem que chegar tiver timestamp menor, o receptor envia uma mensagem de OK. Se sua própria mensagem tiver um timestamp inferior, o receptor enfileira a mensagem e não envia nada. Depois de enviar as requisições pedindo autorização para entrar na região crítica, um processo espera até que todos lhe dêem a permissão para executa-la. Assim que todas as permissões chegarem, ele poderá entrar na região crítica. Quando ele sai da região crítica, ele envia um OK para todos os processos da sua fila e deleta-os de sua fila. Se no caso de dois processos tentarem entrar na mesma região crítica ao mesmo tempo, os dois processos interessados em entrar na R.C. verificam o timestamp das mensagens. Quando o processo de maior timestamp reconhece que perdeu, manda uma mensagem de OK para o de menor timestamp, enquanto que o de menor timestamp coloca a requisição do perdedor numa fila em vez de enviar uma resposta. Quando o processo que ganhou a disputa termina de executar a R.C., ele retira da fila a requisição que havia perdido a disputa anteriormente e envia a este uma mensagem de OK, permitindo-lhe entrar na região crítica. Votação Um processo pode receber várias requisições de processos que querem entrar na R.C. mas ele concede voto (manda mensagem de OK) a apenas um processo. Para evitar bloqueios (cada processo com um voto), existe a possibilidade de mudança de voto caso o processo receba um pedido de um processo que tenha um timestamp menor daquele que ele concedeu o voto. Neste caso, ele manda uma mensagem de desistência ao processo em que votou. Se o processo que ele tinha votado não estiver executando a R.C., ele envia uma mensagem de confirmação de desistência, caso contrário ele termina de executar a R.C. e envia uma mensagem que já utilizou a R.C. Se o processo receber a mensagem de confirmação de desistência ele pode confirmar a mudança de voto, enviando seu voto a um processo com mais atrativo. Ao receber uma mensagem que já utilizaram a R.C., o processo remove aquele que enviou a mensagem da fila de pendências e vota no próximo da fila, isto é, o mais antigo. Um processo usa o recurso quando tiver a maioria dos votos. Exclusão Mútua Controlada Tem como objetivo evitar a sobrecarga de mensagens das abordagens de exclusão mútua por disputa. Poder ser realizada segundo uma das seguintes estruturas topológicas a seguir: Estrutura em Anel Organiza is processos segundo um anel ordenado logicamente. Esta estrutura é simples, não sujeita a bloqueios e justa, pois o recurso é mantido circulando na rede se estiver livre. Mas também gera tráfego por causa desta contínua circulação e pode demorar pois o anel pode ser grande e/ou todos os processos queiram usar o recurso. Para uma tentativa de correção, na mensagem de controle pode haver um status contendo níveis de prioridade e marcação de tempo.

5 Estrutura em Árvore Organiza os processos como uma árvore dinâmica lógica, onde os processos contêm uma fila FIFO, que armazena as requisições dos processos abaixo na árvore, e um ponteiro para o antecessor, para o qual requisita um recurso caso não esteja com a mensagem de controle. Já na árvore, no processo raiz é sempre mantido o processo que contêm a mensagem de controle para que todos possam chegar até ela. Compressão de Caminho Em uma requisição de um recurso em uma árvore, está requisição pode passar por vários processos acima dela, assim percorrendo um grande caminho até a raiz. Na compressão de caminho os processos pelos quais a requisição passou, armazenam em uma variável local que este recurso estará no processo que o requisitou (processo A), assim não tendo que percorrer todo caminho acima novamente quando requisitar o recurso. Mas como o processo A receberá várias requisições deste recurso, os processos que o requisitaram armazenarão um mapa dos outros processos que também requisitaram o recurso, pois o processo A poderá fornecer o recurso a apenas um dos processos, o que tornaria sem sentido a indicação do recurso no processo A pelos outros processos que também fizeram a requisição do recurso. Portanto quando A repassa o recurso a um processo, os outros que tam bem requisitaram devem atualizar tal indicação. ELEIÇÃO Em um sistema distribuído precisa-se de um processo para coordenar certas atividades como por exemplo o acesso a certos recursos para garantir a exclusividade de uso, mecanismos para a detecção de impasses e a sincronização de processos. A falha do coordenador pode impedir o funcionamento correto do sistema. Resolve-se este problema com o desenvolvimento de algoritmos que possibilitam a eleição de um novo coordenador, logo após a falha do atual seja detectada. O algoritmo de eleição tem como objetivo assegurar que todos os processos saibam quem é o novo coordenador após a eleição. Topologia Completa Cada processo pode chegar a outro do mesmo grupo sem passar por nenhum outro nó, com contato direto entre cada um dos nós do grupo. Para esta topologia assumimos três suposições: - cada ID de processos é único e conhecido por todos. - A comunicação na rede é confiável (não tem perda de mensagem, nunca é mandado duas vezes e sempre é ordenado) mas o processo pode falhar. - Preocupa-se com as falhas do processo

6 As últimas duas suposições possibilitam a detecção de erros e a reentrada de nós no grupo que estavam falhos anteriormente. Topologia em anel Ela é fácil de ser construída e toda mensagem que sai de um nó, sempre volta nele depois. Para a escolha de um líder numa rede em anel, assumimos que os processos estão ordenados e cada um sabe quem é o seu sucessor. Quando um processo nota que o coordenador está inativo, ele manda para seu sucessor uma mensagem de convocação de eleições contendo seu número de identificação. Se seu sucessor estiver inativo, o transmissor pula seu sucessor e tenta o próximo processo do anel até achar um que esteja ativo. A cada passo, o transmissor coloca seu próprio número de identificação na lista de mensagem. A mensagem volta ao processo que o enviou pela primeira vez. Ele reconhece o fato ao receber uma mensagem contendo seu próprio número de identificação. Agora, uma nova mensagem vai circular pela rede está, dizendo quem é o novo coordenador (o processo da lista com o maior número de identificação), cuja identificação consta da mensagem. Dois processos podem notar a falta de um coordenador e convocar eleições ao mesmo tempo, isso acarretará numa circulação extra de mensagens mas não traz nenhum prejuízo relacionado à escolha do líder. Topologia em árvore Uma árvore é um grafo acíclico com N nós interligados por N-1 canais de comunicação de forma que o custo de comunicação entre cada par de nós é o mínimo possível. O nó coordenador é a raiz da árvore. Para escolher um coordenador um ou mais processos enviam para todos os nós da árvore uma mensagem de campanha para líder (CPL), incluindo o instante que a mensagem foi mandada. Quando um nó-folha recebe esta mensagem, ela responde ao nópai com um reconhecimento do CPL (um voto para determinado CPL). Os nós só podem votar uma única vez e depois ficam aguardando o anúncio de novo coordenador. Pode ocorrer que um nó receba mais de uma mensagem CPL, ele vota naquele mais antigo (de menor tempo). Caso haja empate, o de maior pid é o escolhido. Quando todos os nós filhos tiverem votado, o nó-pai envia seu voto para o nó-avô, e assim por diante. O algoritmo escolhe como coordenador aquele que iniciou o processo de eleição primeiro (de tempo menor) pois, ele será o único nó que receberá os votos de todos os seus filhos. Algoritmo de Bully Cada processo tem a sua identidade como sua prioridade, e o de maior prioridade é o coordenador. Quando um processo nota que o coordenador não está atendendo as solicitações, ele inicia uma eleição. Este processo P convoca uma eleição aos processos com prioridades maiores que o seu. Os processos que receberam a convocação de eleição mandam de volta um OK indicando que está ativo e estão dispostos a assumir a condição de coordenador. O trabalho de P acaba quando recebe está mensagem. Os processos que estão dispostos a assumir a condição de coordenador continuam convocando eleições até que

7 sobrem dois processos, aí se escolhe como coordenador aquele com a prioridade mais alta. O processo que ganhar anuncia ao restante que a partir de agora ele é o novo coordenador Algoritmo do convite O algoritmo do convite é um algoritmo assíncrono assim ele é melhor que o algoritmo de bully quando existem pequenas falhas de contagem de tempo. Este algoritmo funciona da seguinte maneira: quando se nota que o líder não responde aos processos, um processo P1 envia uma mensagem de convite para os outros processos, que respondem com a mensagem de aceitação do convite. Então o processo P1 envia uma mensagem de pronto para estes processos que agora são coordenados pelo processo P1. ACORDO O problema fundamental dos sistemas distribuídos é o acordo. Um acordo deve fazer que um conjunto de processadores cheguem a um consenso sobre alguma informação. Formalmente, tem-se um conjunto de M processadores P = {p1, p2,..., pm}, um subconjunto F dos quais não estão funcionando adequadamente F={f1, f2,..., fn}. Cada processador pi armazena um conjunto de valores V, baseado nos quais é calculado um valor de acordo Ai. Para cada par de processadores pi e pj, funcionando normalmente, Ai=Aj é o valor de consenso. Um adversário é usado para testar os algoritmos que resolvem este problema. O objetivo de um adversário é criar situações não esperadas por um protocolo para testá-lo (como por exemplo destruindo ou modificando mensagens). O poder que o adversário tem, somos nós quem damos, assim controlando até que ponto nosso protocolo pode ser testado, mas nunca criaremos um adversário que gere situações impossíveis e ou irreais. Falhas Bizantinas O problema de consenso pode ser resolvido a partir do acordo bizantino explicado a seguir: Um turco liderou uma invasão à cidade de Bizâncio. O imperador de Bizâncio reuniu seus exércitos (cada um comandado pelo seu general) e foram ao encontro do turco e tinham força o bastante para resistir se agissem coordenadamente, isto é, ou todos atacassem ou todos recuassem. Depois de alguns dias, os generais pretendiam atacar os turcos ao amanhecer mas como cada general tinha sua própria opinião sobre o poderio turco e de quando atacar e quando defender que eles deveriam tomar uma decisão de consenso para definir se e quando atacar. Os generais mandariam mensageiros durante a noite para tomar a decisão de consenso mas este esquema tinha dois problemas. O primeiro relacionado ao risco dos mensageiros serem assassinados e a mensagem nunca chegar, e o segundo pelo risco dos generais bizantino fossem corrompidos pelos turcos, que podem enviar mensagem erradas tentando evitar que os parceiros cheguem a um acordo. A partir dos problemas, os generais concordaram em tomar como decisão de consenso à opinião da maioria, depois de serem analisados todas as mensagens recebidas. No caso de empate a decisão seria de defender.

8 O consenso é atingido quando o número total de generais seja no mínimo igual ao triplo de generais corrompidos mais um. Com isso pode se chegar a um consenso mas o volume de informações transmitidas é grande pois cada general além de enviar sua opinião aos demais deve transmitir as informações que recebeu dos demais a todos os outros. Imaginando que se têm M generais, N dos quais foram corrompidos. Cada general tem sua opinião Oi e recebe dos demais as respectivas opiniões Oj, j diferente de i. Cada general forma um conjunto de decisões da seguinte maneira: Di={di1, di2,...,dim}. Dii = Oi Dij = Oj, se os valores recebidos do j-ésimo general forem majoritariamente Oj, caso contrário fazem dij = recuar Finalmente a decisão com maior número de votos em Di é tomada. Para transformar este problema num aspecto computacional, se troca os generais por processadores. Pode se reduzir o custo computacional fazendo restrições que reduzam o número de mensagens em trânsito. De qualquer forma, processadores que não funcionam corretamente não costumam atuar com tanta eficiência para obstruir o bom funcionamento do sistema. Portanto não se compensa tentar tornar imune o sistema contra falhas bizantinas. Vale mais a pena para tanto na melhoria dos componentes do sistema e ainda assim o estudo dos protocolos dos generais bizantinos é interessante devido ao grande volume de trabalho desenvolvido para torná-lo eficiente. Impossibilidade de Consenso Pelas falhas bizantinas mostramos que é possível os processadores entrarem em um acordo. Mas na falha bizantina admitíamos que se tratava de um sistema síncrono onde todos os processadores passavam informações dentro de um tempo pré-estabelecido. Em sistemas distribuídos assíncronos não se tem a resposta por um tempo anteriormente definido. Não existe algoritmo que garanta que todos os processadores cheguem a um consenso num tempo finito demonstrando assim a impossibilidade de um sistema assíncrono chegar a um consenso mesmo sem falhas bizantinas. Demonstra-se isso provando que existem casos onde o protocolo fica impedido de chegar a um consenso. Apesar disto os sistemas distribuídos assíncronos são bastante desenvolvidos e utilizados. Esses sistemas reais não garantem 100% de funcionamento correto e admitem que falham em casos raros. A intervenção humana é usada para detectar e corrigir o problema. Consenso Distribuído aleatório Várias pesquisas recentes estão sendo feitas para o desenvolvimento de protocolos que incorporam não determinismo na busca pelo consenso. Estes processadores não aguardam indefinidamente pelas respostas dos seus pares, param após um certo número de passos. O mais simples destes protocolos usa o conceito de memória compartilhada. Tem-se M processadores, nos quais N podem falhar. Tem-se um vetor V como a preferência de cada processador. Se em algum instante vi for igual para todos os processadores, tem-se um consenso. Se não houver um consenso, o i-ésimo processador escolhe um aleatoriamente. Eventualmente todos vão concordar com o mesmo valor.

9 Existem problemas neste algoritmo: admite que o sistema é síncrono (cada um aguarda sua vez de testar V e decidir sobre o consenso). Para tornar o sistema assíncrono, associa-se a vi o número de ciclos que o processador pi já executou. Quando todos entrarem no mesmo ciclo e preferirem a mesma coisa, o consenso foi atingido. O segundo problema acontece quando um processador falhar e assim não atualizará seu número de ciclos, inviabilizando o acordo. Resolve-se isso se concentrando nos processadores mais rápidos, onde se admite que apenas os de processadores mais rápidos discordem enquanto que os mais lentos são obrigados a concordarem com os mais rápidos.