Sistemas Distribuídos

Apresentação em tema: "Sistemas Distribuídos"— Transcrição da apresentação:

1 Sistemas Distribuídos
Jorge Surian Sistemas Distribuídos: Exclusão Mútua, Eleição do Líder, Replicação e Consistência

2 Exclusão Mútua Problema: Conjunto de processos, em um sistema distribuído, que necessitam garantir acesso exclusivo a um recurso. Soluções básicas: Servidor Centralizado. Completamente distribuído, sem topologia específica. Completamente distribuído, com uma topologia lógica em anel. 2

3 Exclusão Mútua Solução em Servidor Centralizado

4 Exclusão Mútua Algoritmo Token Ring Como funciona?
Organiza os processos em um anel lógico e um token circula entre os processos que fazem parte do sistema distribuído. O processos que está com o token é permitido utilizar o recurso 'crítico', caso queira usá-lo.

5 Exclusão Mútua Algoritmo Token Ring
Como existe um número N de processos (N > 1) que desejam acessar o mesmo arquivo para escrita, é necessário garantir acesso exclusivo ao arquivo. Na nossa implementação, criamos um anel lógico, por onde circula um token (arquivo utilizado em redes tipo anel que quando lançado na rede , informa que um determinado micro deseja falar com outro , evitando assim colisões de informações), que quando obtido por um processo, garante a este o acesso exclusivo ao arquivo de dados. Ao obter acesso ao token, o processo realiza a escrita de todos os pedidos recebidos.

6 Exclusão Mútua Algoritmo Token Ring
Vamos imaginar um típico arquivo de pedidos com campos convencionais. Cada pedido de escrita é composto pelos seguintes campos: contador_pedidos, id_agente_solicitante, valor. Estes campos são armazenados em uma tabela até o momento da chegada do token, quando então são armazenados em arquivo. Além dos campos citados, no momento da escrita dos pedidos no arquivo, é acrescentado o identificador do agente que está realizando a escrita. Então, para cada pedido realizado temos a seguinte linha armazenada no arquivo: id_agente, contador_pedidos, id_agente_solicitante, valor, por exemplo.

7 Exclusão Mútua Algoritmo Token Ring
A linha abaixo mostra um exemplo de um pedido atendido: Agente: Maxwell Smart; Requisicão No: 6. Requisitante: Chefe; Valor: 99. Agente: Obi-wan; Requisição No: 1. Requisitante: Mestre Yoda; Valor: 432. Após processar todos os pedidos armazenados, o processo envia o token para o próximo processo na lista e somente poderá realizar o processamento das novas requisições quando receber o token novamente. Caso o processo que recebe o token não possua registros para armazenar, o token é imediatamente enviado para o próximo processo da lista.

8 Exclusão Mútua Algoritmo Distribuído (Ricart e Agrawala)
Como funciona? Processo necessita acessar uma região ”crítica”: Envia uma mensagem a todos os outros processos: nome do recurso, número do processo, tempo corrente. Todas as mensagens devem ser confirmadas. Processo recebe uma requisição: Ação depende do estado no qual se encontra o processo ao receber a requisição: Se o processo não está acessando o recurso e nem pretende fazê-lo, envia uma OK. Se estiver na região critica, requisição é enviada a uma fila. Se não está acessando o recurso, mas pretende fazê-lo, comparação entre os tempos de geração dos pedidos. O menor ganha o acesso.

9 Exclusão Mútua Algoritmo Distribuído (Ricart e Agrawala)
Como funciona?

10 Exclusão Mútua Resumo Como gerenciar os recursos que podem ser considerados como “regiões críticas”? Algoritmos Centralizados: Um nó é responsável por controlar se um determinado processo está ou não acessando a região crítica. Algoritmo Distribuído: Todos os processos (nós) trocam mensagens entre si para verificar se a região critica está sendo acessada. O processo acessa a região crítica somente se todos os processos enviarem um OK

11 Algoritmos de Eleição Muitos Sistemas Distribuídos precisam que um processo aja como coordenador ou tenha um papel especial. Em geral, não importa qual processo assume essa responsabilidade. Existem algoritmos para se eleger coordenador. Em geral, tentam localizar processo com maior ID. Assume-se que todos os processos conhecem os IDs dos demais processos. Não se sabe se estes processos estão disponíveis/indisponíveis. Meta: quando eleição começa, termina com todos concordando com quem é o novo coordenador.

12 Algoritmos de Eleição Algoritmo do Valentão (Bully)
Quando processo nota que cooordenador não está mais respondendo requisições, inicia uma eleição. O Processo P convoca uma eleição: P envia uma mensagem de eleição para todos os processos com IDs maiores. Se ninguém responde, P vence eleição e torna-se coordenador Se algum processo com ID maior responde, ele desiste. Quando processo recebe mensagem de eleição de membros com ID mais baixa que ele. Envia OK para remetente para indicar que está vivo e assume a coordenação.

13 Algoritmos de Eleição Algoritmo do Valentão (Bully)
Eventualmente todos os processos desistem menos um: novo coordenador. Se processo que estava indisponível volta, inicia nova eleição. Se for processo com maior ID, vence e toma coordenação. Maior “cara da cidade” sempre vence: algoritmo do valentão. Algoritmo Chuck Norris

14 Algoritmos de Eleição Algoritmo do Valentão (Bully)

15 Algoritmos de Eleição Uso de um anel, sem token
Processos fisicamente ou logicamente ordenados. Conhecem sucessor Processo verifica que coordenador não funciona Envia mensagem de eleição para sucessor Mensagem contém seu ID. Se sucessor indisponível, manda para próximo, e sim sucessivamente. A cada passo, processo que recebe mensagem adiciona seu ID e repassa para sucessor.

16 Algoritmos de Eleição Uso de um anel, sem token
Eventualmente a mensagem volta para quem começou eleição Reconhece ser sua mensagem porque ela contém seu ID, convocando uma eleição. Neste ponto muda a mensagem para coordenador e a circula novamente para informar a todos: 1. Novo coordenador: processo com maior ID 2. Nova configuração do anel Quando a mensagem do coordenador volta para processo que iniciou eleição, é removida e todos voltam a trabalhar.

17 Algoritmos de Eleição Uso de um anel, sem token

18 Replicação Replicação: Conceitos e Técnicas Razões para Replicação
Replicação como técnica de escalabilidade Modelos de Consistência centrados em dados Gerenciamento de Réplicas

19 Replicação Razões para Replicação Confiabilidade:
Garante comportamento correto, apesar de alguns tipos de erros acontecerem. Exemplo: dados corrompidos Enquanto ao menos um servidor estiver funcionando, o serviço continua disponível. Desempenho É importante quando um sistema distribuído precisa ser ampliado em quantidade e em área geográfica. No caso de ampliação em quantidade espera-se que diversos servidores web com o mesmo DNS, cujos servidores serão selecionados alternadamente. No caso de ampliação geográfica as requisições são repassadas para o servidor mais próximo geograficamente.

20 Replicação Vantagens da Replicação
Réplicas permitem que alguns servidores continuem a funcionar mesmo em ocasião de falhas. É possível proteger contra corrupção de dados . Réplicas permitem que dados fiquem mais perto de onde serão acessados → diminuição da latência.

21 Replicação Replicação e a Escalabilidade
Replicação e cache para melhorar desempenho são amplamente utilizados para tratar os problemas de escalabilidade: Ao se colocar cópias de dados próximas aos processos que as estão usando, reduzindo o tempo de acesso. Problemas? Garantia da consistência dos dados entre as várias réplicas.

22 Replicação Problemas:
No caso da utilização de caches em um servidor Web... Browsers costumam armazenar na estação local uma cópia das páginas Web que anteriomente foram usadas. Se um usuário requisitar aquela página mais uma vez, o browser automaticamente retornará a cópia local. Vantagem: Tempo de acesso excelente Problema: E se o usuário quiser ter a versão mais recente da página?

23 Replicação Problemas: No caso de um Banco de Dados...
Vantagem: Tempo de acesso excelente Problema: E se o usuário quiser dados de “agora”?

24 Replicação O problema da consistência
Maior dificuldade: como sincronizar TODAS as réplicas? Todas as réplicas precisam chegar a um acordo sobre quando uma atualização deve ser realizada Em geral, requer uma sincronização global A única solução real é relaxar as restrições de consistência → evitar que atualizações sejam executadas como operações atômicas

25 Consistência O que é e como implementar consistência?
Em depósitos de dados distribuído Um depósito de dados pode ser distribuído fisicamente por várias máquinas Cada processo que pode acessar dados do depósito tem uma cópia local (ou próxima) do depósito Dois tipos de operações: escrita → altera os dados leitura → caso contrário Operações de escrita são propagadas para outras cópias

26 Consistência Em depósito de dados distribuído

27 Modelos de Consistência
Definição: Contrato entre processos e o depósito de dados Se os processos concordarem em obedecer certas regras, o depósito promete funcionar de maneira correta Exemplo: Um processo que executa uma operação de leitura sobre um item de dados espera que a operação retorne um valor que mostre os resultados da última operação de escrita executada sobre aqueles dados.

28 Modelos de Consistência
Na ausência de um relógio global, é difícil definir com precisão qual operação de escrita é a última, como vimos anteriormente. Modelos de consistência restringem de maneira direta os valores que uma operação de leitura sobre um “item de dados” pode efetivamente retornar. Para obter soluções eficientes para o problema de consistência, deve-se 'relaxar' o conceito de consistência. Assim, o que se pode tolerar de inconsistência depende rigorosamente de cada aplicação e de suas regras efetivas de negócio e de funcionamento.

29 Consistência Contínua
Três eixos independentes para definir inconsistências Diferenças dos valores numéricos entre réplicas Diferenças das idades entre réplicas Diferença em relação à ordenação de operações de atualização Referem-se a estes desvios como se formassem faixas de consistência contínua.

30 Consistência Contínua
Desvios Numéricos Dados possuem semântica numérica Exemplo 1: Registros que contêm preços do mercado de ações Exemplo 2: Número de atualizações que foram aplicadas a uma determinada réplica, mas que ainda não foram vistas pelas outras.

31 Consistência Contínua
Desvios de Idade Estão relacionados com a última vez que uma réplica foi atualizada Algumas aplicações podem tolerar que uma réplica forneça dados antigos, contanto que não sejam tão antigos Exemplo: Previsões de tempo, em geral, permanecem razoavelmente exatas durante algum tempo. Servidor principal pode receber atualizações e tempos oportunos

32 Consistência Contínua
Desvios em relação à ordenação de operações Em algumas aplicações, é permitido que a ordenação das atualizações seja diferente nas várias réplicas, dentro de um limite Atualizações são aplicadas provisoriamente a uma cópia local, à espera de um acordo global de todas as réplicas Em alguns casos, algumas atualizações podem precisar voltar atrás e serem aplicadas em uma ordem diferente antes de se tornarem permanentes

33 Consistência Contínua x Relógio Vetorial
Réplica A recebeu a operação 5,B: x←x+2 e a tornou permanente A tem 3 operações de atualização provisórias: 8,A; 12,A; 14,A Desvio de ordenação = 3; vetor lógico = (15,5) Desvio numérico = 1 (# atualizações não vistas); y = 5 para a atualização feita em B no valor de y e não vista por A

34 Consistência Sequencial e Causal
Modelos de consistência sequencial e causal ampliam os modelos de consistência contínua No entanto, quando for preciso efetivar atualizações provisórias em réplicas, estas terão que chegar a um acordo sobre uma ordenação global dessas atualizações Concordar com uma ordenação consistente das atualizações Assim, os modelos de consistência sequencial e causal visam chegar a tais ordenações consistentes

35 Consistência Sequencial e Causal
Exemplo (1) P1 executa uma escrita para um item de dados x, modificando o seu valor para a. Esta operação é feita localmente e depois propagada para os outros processos (2) Mais tarde P2 lê o valor NIL e, pouco tempo depois, lê a. Existe um retardo para propagar a atualização de x para P2.

36 Gerenciamento de Réplicas
Problemas: Decidir onde, quando e por quem as réplicas devem ser posicionadas Mecanismos para manter as réplicas consistentes

37 Gerenciamento de Réplicas
Problema de Posicionamento Pode ser subdividido em dois subproblemas: Posicionar servidores de réplicas Posicionar conteúdo Posicionar servidores de réplicas: refere-se a achar as melhores localizações para colocar um servidor que pode hospedar um depósito de dados (ou parte dele) Posicionamento de conteúdo: refere-se a achar os melhores servidores para colocar conteúdo. Antes de decidir o posicionamento do conteúdo, é preciso que os servidores de réplicas já tenham sido posicionados

38 Posicionamento do Servidor de Réplicas
Alguns tipos de Solução Distância entre clientes e localizações Pode ser medida em termos de latência ou largura de banda A posição é definida baseada na métrica que a distância média entre o servidor e os seu clientes é mínima Ignorar a posição dos clientes e apenas considerar que a topologia da Internet é formada pelos sistemas autônomos (AS) Rede no qual os nós executam o mesmo protocolo de roteamento, que é gerenciada por uma única organização

39 Posicionamento do Servidor de Réplicas
Alguns tipos de Solução Ignorar a posição dos clientes Consideram o maior AS e colocam um servidor no roteador com maior número de enlaces Os ASs são escolhidos em ordem de tamanho Szymaniak e outros, em 2006, desenvolveram um método pelo qual pode-se identificar rapidamente uma região para o posicionamento de réplicas Uma região é identificada como um conjunto de nós que acessam o mesmo conteúdo, com uma latência baixa entre os nós Primeiramente, seleciona-se as regiões com o maior número de nós, e permite que um dos nós aja como servidor de réplicas

40 Replicação e Posicionamento de Conteúdo
Três tipos diferentes de réplicas organizadas logicamente Replicas permanentes Replicas iniciadas por servidor Replicas iniciadas por cliente

41 Replicação e Posicionamento de Conteúdo
Réplicas Permanentes Conjunto inicial de réplicas que constituem um depósito de dados distribuído. Número de réplicas permanentes e pequeno Exemplo: Site Web, onde... Arquivos são replicados para um número limitado de servidores que estão em uma única localização. Espelhamento: site Web e copiado para um número limitado de servidores, sites espelhados, que estão geograficamente espalhados pela Internet.

42 Replicação e Posicionamento de Conteúdo
Réplicas Iniciadas por Servidor Cópias de um depósito de dados que existem para aprimorar desempenho e que são criadas por iniciativa do (proprietário do) depósito de dados Exemplo: Considere um servidor na região da Paulista, em São Paulo. Imaginemos uma rajada de requisições que vêm de uma localização inesperada, por exemplo, na região de Bauru. Ora, essa localidade é longe do servidor e não mapeada como região com características de exigência de alto nível. Em casos assim, vale a pena instalar uma quantidade de réplicas temporárias na região de onde se originam tais requisições, até que cesse o movimento atípico.

43 Réplicas Iniciadas por Cliente
São mais conhecidas como caches (de cliente) Recurso de armazenamento local, usado por um cliente para armazenar temporariamente uma cópia dos dados que ele acabou de requisitar. Gerenciamento cabe inteiramente ao cliente: Depósito de dados de onde os dados foram trazidos nada tem a ver com a manutenção da consistencia dos dados em cache. Caches são usadas para melhorar o tempo de acesso aos dados.

44 Réplicas Iniciadas por Cliente
São mais conhecidas como caches (de cliente) Quando um cliente quer acessar alguns dados, se conecta com a cópia do depósito de dados mais próxima Quando a maioria das operações envolve somente ler dados, o desempenho pode ser melhorado, dado que o cliente pode armazenar dados requisitados em uma cache mais próxima. Cache pode estar localizada na máquina do cliente, ou em uma outra máquina separada dentro da mesma rede local Dados são mantidos por um período limitado de tempo

45 Fonte: Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribuídos, São Paulo: Prentice Hall, 2008. Copyright © Prof. Jorge Surian Todos direitos reservados. Reprodução ou divulgação total ou parcial deste documento é expressamente proíbido sem o consentimento formal, por escrito, do Professor Surian.