Sincronização. Fernando Silva DCC-FCUP. Fernando Silva (DCC-FCUP) Sincronização 1 / 45

Transcrição

1 Sincronização Fernando Silva DCC-FCUP Fernando Silva (DCC-FCUP) Sincronização 1 / 45

2 Agenda Slides baseados nos slides de Maarten van Steen e no cap. 6 do seu livro com Andrew Tanenbaum. Fernando Silva (DCC-FCUP) Sincronização 2 / 45

3 Porquê sincronização? Os algoritmos concebidos para um sistema distribuído precisam de realizar tarefas como: comunicar entre as várias entidades do SD aceder a recursos atribuir recursos gerar consensos etc. Estas tarefas requerem sincronização e coordenação para poderem ser realizadas com sucesso pelo SD. Evidentemente, existem tarefas que podem ser concretizadas de forma assíncrona. Fernando Silva (DCC-FCUP) Sincronização 3 / 45

4 Sincronismo vs Assincronismo em SDs A noção de tempo num SD é afectada por muitos aspectos: rapidez de execução dos processos atrasos na comunicação mais do que um relógio - desvios nos relógios falhas (parciais) Fernando Silva (DCC-FCUP) Sincronização 4 / 45

5 SDs Síncronos A variação do tempo está delimitada Execução: delimitar a velocidade e tempo de execução Comunicação: delimitar atrasos de transmissão Relógios: delimitar desvios do relógio (e nas diferenças dos relógios) Efeito: pode-se confiar em timeouts para detectar falhas simplifica o desenho dos SDs mas impõe requisitos muito restritivos: limita a concorrência de processos por processador limita o uso concorrente da rede requer relógios precisos e sincronização Fernando Silva (DCC-FCUP) Sincronização 5 / 45

6 SDs Assíncronos A variação do tempo não é limitada Execução: diferentes passos podem ter variações na sua duração Comunicação: atrasos de transmissão variam muito Relógios: desvios arbitrários do relógio Efeito: nada se pode assumir sobre os intervalos de tempo não se pode confiar em timeouts para detectar falhas a maioria dos problemas assíncronos em SDs são difíceis de resolver uma solução assíncrona é também uma solução para um SD síncrono a maioria dos SDs são híbridos Fernando Silva (DCC-FCUP) Sincronização 6 / 45

7 Avaliação de SDs Desempenho número de mensagens trocadas tempo de espera/resposta atrasos throuput: 1/(delay + executiontime) complexidade: O() Eficiência uso de recursos: memória, CPU, etc. Extensibilidade (scalability) Fiabilidade número de pontos de falha Fernando Silva (DCC-FCUP) Sincronização 7 / 45

8 Sincronização e coordenação Em muitas situações é necessário Fazer a coisa certa no momento certo. Envolve duas questões fundamentais: Coordenação (a coisa certa) Sincronização (no momento certo) Fernando Silva (DCC-FCUP) Sincronização 8 / 45

9 Sincronização Sincronização: Tem a ver com a ordenação de todas as acções: ordenação total dos eventos, das instruções, da comunicação ordenação no acesso aos recursos requer alguma noção de tempo. Coordenação: coordenar acções e concordar nos valores. Coordenar acções: que acções vão ocorrer quem as vai realizar Concordar nos valores: concordar num valor global concordar no estado Fernando Silva (DCC-FCUP) Sincronização 9 / 45

10 Assuntos Principais Tempo e relógios sincronização de relógios e uso do tempo em SDs Estado Global como conhecer o estado global do sistema Controlo da concorrência coordenar o acesso concorrente a recursos Coordenação quando é que os processos precisam de coordenar e como o podem fazer Fernando Silva (DCC-FCUP) Sincronização 10 / 45

11 Tempo Tempo global: Tempo absoluto : Einstein: não existe tempo absoluto Para o nosso propósito é absoluto suficiente Tempo astronómico: baseado na rotação da terra não é estável Tempo Atómico Internacional (IAT): baseado nas oscilações do Celsium-133 Tempo Universal Coordenado (UTC): tempo IAT corrigido (leap seconds) compensar dias estarem a ficar mais longos UTC é propagado por todo o mundo por ondas curtas de rádio e satélite Tempo local: não sincronizado com a fonte global relativo, não absoluto Fernando Silva (DCC-FCUP) Sincronização 11 / 45

12 Relógios Relógios de computador: oscilações a frequências conhecidas de cristais de quartzo oscilações provocam interrupções de um temporizador interrupções do temporizador actualizam o relógio (batimentos do relógio) Desvios dos Relógios: os temporizadores (cristais) em diferentes computadores têm cadencias ligeiramente diferentes os relógios ficam des-sincronizados razão do desvio máximo Timestamps: usadas para marcar o tempo de ocorrência de um evento lógico vs. físico Fernando Silva (DCC-FCUP) Sincronização 12 / 45

13 Relógios físicos (1) Os relógios físicos mantém o tempo físico (real/absoluto). Sincronização com relógios físicos, exemplos: Concretização de eventos num tempo determinado (ligar/desligar luzes, bloquear/desbloquear portas) Registo (logging) de eventos (por segurança, profiling, debugging) Tracking (seguir um objecto móvel com múltiplas separadas) Make (editar num computador e compilar (make) noutro) Fernando Silva (DCC-FCUP) Sincronização 13 / 45

14 Relógios físicos (2) Têm por base o tempo actual: C p (t): tempo corrente (no tempo UTC t) na máquina p Idealmente, tem-se C p (t) = t para cada máquina p (i.e. dc/dt = 1) Na prática: 1 ρ dc dt 1 + ρ (devido aos desvios nos relógios) Necessário sincronizar regularmente com UTC. Fernando Silva (DCC-FCUP) Sincronização 14 / 45

15 Sincronização de relógios físicos Sincronização externa os relógios sincronizam com uma fonte de tempo externa sincronização com UTC cada δ segundos Sincronização interna relógios sincronizam localmente apenas sincronizados entre si Servidor de tempo servidor que tem o tempo correcto servidor que tem de calcular o tempo correcto Fernando Silva (DCC-FCUP) Sincronização 15 / 45

16 Algoritmo de Cristian Tem por base um servidor centralizado de tempo, normalmente com receptor UTC Algoritmo (centralizado): clientes sincronizam o seu relógio periodicamente com o servidor central os relógios nunca podem ser atrasados têm de ser corrigidos, tendo em conta atrasos da comunicação Fernando Silva (DCC-FCUP) Sincronização 16 / 45

17 Algoritmo de Berkeley Não sincroniza com um tempo global, servidor de tempo é activo Algoritmo: servidor de tempo pede o tempo aos clientes faz uma média informa os clientes do ajuste necessário fazer ao seu tempo para atingir o valor médio quando um cliente mostra variações superiores a uma certa tolerância, o seu valor não é usado no cálculo da média Fernando Silva (DCC-FCUP) Sincronização 17 / 45

18 Network Time Protocol (NTP) (1/2) Semelhante ao algoritmo de Cristian, mas é distribuído e de larga escala. Usa uma hierarquia de servidores servidor primário tem o tempo UTC servidor secundário tem ligação ao primário, etc. Modelos de sincronização: Multicast em LANs baixa precisão RPC (cliente-servidor) clientes interrogam servidor precisão razoável Simétrico (peer-to-peer) sincronização entre servidores-peer precisão mais elevada Fernando Silva (DCC-FCUP) Sincronização 18 / 45

19 Network Time Protocol (NTP) (2/2) Sincronização: Estimar diferenças entre relógios e atrasos de transmissão entre dois nós Marcar servidores não confiáveis Precisão 1-50 mseg (dependendo se LAN ou WAN) Exemplo: A pode estimar a sua diferença relativa a B (considerando T 2 T 1 T 4 T 3 ) θ = T 3 (T 2 T 1 ) + (T 4 T 3 ) 2 = (T 2 T 1 ) + (T 3 T 4 ) 2 = dt req dt resp 2 Fernando Silva (DCC-FCUP) Sincronização 19 / 45

20 Relógios Lógicos de Lamport (1/5) Em muitos SDs, a ordem relativa de eventos é mais importante que o tempo real actual. Ordem global: definição com base na relação happens-before de Leslie Lamport. menor relação t.q. 1 Se a e b são eventos do mesmo processo, e a acontece antes de b, então a b (a afecta causalmente b) 2 Se a envia uma mensagem m, e b recebe m, então a b uma mensagem não pode ser recebida antes de ser enviada. 3 Se a b e b c, então a c (transitividade) Esta propriedade define uma relação de ordem parcial estrita (falta-lhe a reflexividade). Dois eventos que não têm ordem entre si, dizem-se concorrentes: Exemplo: a b e b a a b Fernando Silva (DCC-FCUP) Sincronização 20 / 45

21 Relógios Lógicos de Lamport (2/5) Como manter uma visão global no sistema que seja consistente com a relação happens-before? Solução: Usar um contador (software) que calcule localmente a relação happens-before Associar um timestamp L(a) a cada evento a t.q. Se a e b são eventos do mesmo processo e a b, então L(a) < L(b) Se a for uma mensagem enviada, e b uma mensagem recebida, então L(a) < L(b) Fernando Silva (DCC-FCUP) Sincronização 21 / 45

22 Relógios Lógicos de Lamport (3/5) Implementação: Cada processo p i mantém um contador local L i e ajusta-o de acordo com as seguintes regras: 1 Antes de atribuir o timestamp a um evento, p i executa L i := L i + 1 (i.e. incrementa o contador entre eventos sucessivos) 2 Quando uma mensagem m é enviada pelo processo p i, a mensagem recebe o timestamp ts(m) = L i 3 Quando m é recebida por um processo p j, este ajusta o seu contador L j := max(l j, ts(m)) + 1, marcando m com o novo L j. Propriedades: a b L(a) < L(b) L(a) < L(b) não implica necessariamente que a b E se se verificarem eventos simultâneos? Desempatar com os process-ids. Fernando Silva (DCC-FCUP) Sincronização 22 / 45

23 Exemplo: Relógios Lógicos de Lamport (4/5) (a) relógios não sincronizados (b) relógios sincronizados pelo algoritmo de Lamport. Fernando Silva (DCC-FCUP) Sincronização 23 / 45

24 Relógios Lógicos Lamport (5/5) O middleware é responsável pelos ajustes aos contadores de Lamport: Fernando Silva (DCC-FCUP) Sincronização 24 / 45

25 Exemplo: Multicast Totalmente Ordenado (1/2) Por vezes precisamos de garantir que actualizações concorrentes em bases de dados replicadas são realizadas pela mesma ordem em todo o lado. Considere-se o exemplo: P 1 adiciona $100 a uma conta, com um valor inicial de $1000 P 2 actualiza a conta, acreditando-a com juros de 1% Existem duas réplicas da conta em servidores diferentes Na ausência de sincronização efectiva: replica #1 $1111 enquanto replica #2 $1110. Fernando Silva (DCC-FCUP) Sincronização 25 / 45

26 Exemplo: Multicast Totalmente Ordenado (2/2) Solução: O processo P i envia uma mensagem timestamped msg i para todos os outros. A mensagem é também colocada na fila local queue i. Qualquer mensagem que chegue a P j é colocada na fila queue j, por ordem da sua timestamp, e uma confirmação é enviada para todos os processos. P j entrega uma mensagem msg i à sua aplicação se: (1) msg i estiver na cabeça da fila queue j (2) existem na fila todas confirmações desta mensagem enviadas pelos outros processos (têm timestamps maiores). Note: estamos a assumir que a comunicação é fiável e ordenada-fifo. O multicast totalmente ordenado assegura consistência de réplicas, pois as mesmas operações são executadas pela mesma ordem em todo o lado. Fernando Silva (DCC-FCUP) Sincronização 26 / 45

27 Vectores de Relógios (vector clocks) (1/4) Os relógios de Lamport não garantem que se L(a) < L(b) então a precede causalmente b: T rcv (m 1 ) < T snd (m 2 ), mas não podemos concluir que m 1 precede causalmente m 2. Os relógios de Lamport não capturam causalidade. Teremos de usar os vectores de relógios. Fernando Silva (DCC-FCUP) Sincronização 27 / 45

28 Vectores de Relógios (vector clocks) (2/4) Vectores de relógios: Cada P i mantém um vector V i [1..N] com o relógio de todos processos. V i [j] denota o que o processo P i conhece do relógio do processo P j. Implementação: inicialmente V i [j] := 0, i, j 1,..., N Antes de P i associar o timestamp ao evento, executa V i [i] := V i [i] + 1 Quando uma mensagem m é enviada de P i para P j : Pi executa V i [i] := V i [i] + 1 e envia o vector V i com m Pj recebe V i com m e faz a junção dos vectores V i e V j : V j [k] := { max(vj [k], V i [k]) + 1 se j = k, max(v j [k], V i [k]) se j k. Fernando Silva (DCC-FCUP) Sincronização 28 / 45

29 Vectores de Relógios (vector clocks) (3/4) Propriedades: i, j, V i [i] V j [i] (P i tem o valor mais actualizado do seu relógio) a b sse V (a) < V (b), onde V = V sse V [i] = V [i], i 1,..., N V V sse V [i] V [i], i 1,..., N V > V sse V V V V V V sse V V V V Podemos assim assegurar que uma mensagem é entregue quando todas as mensagens causalmente precedentes tiverem sido entregues. Ou seja: P j adia a entrega de m até que: ts(m)[i] = V j [i] + 1 (ts(m)[i] é o timestamp V i [i]) ts(m)[k] V j [k], para k i Fernando Silva (DCC-FCUP) Sincronização 29 / 45

30 Vectores de Relógios (vector clocks) (4/4) Exemplo 1: Exemplo 2: Consideremos VC 2 = [0, 2, 2], ts(m) = [1, 3, 0] de P 0. Que informação tem P 2 e que fará quando receber m (vindo de P 0 )? Fernando Silva (DCC-FCUP) Sincronização 30 / 45

31 Concorrência num Sistema Não-Distribuído Alguns dos problemas colocados pela concorrência de processos ou threads num sistema não-distribuído são: evitar competição entre processos (race conditions) identificar e proteger secções críticas assegurar exclusão mútua no acesso a zonas críticas locks semáforos monitores necessário uso correcto de soluções para evitar encravamentos (deadlocks) inanição (starvation) Fernando Silva (DCC-FCUP) Sincronização 31 / 45

32 Concorrência num Sistema Distribuído A concorrência em SDs introduz mais desafios: não existem recursos directamente partilhados (e.f. memória) não existe estado global não existe relógio global algoritmos centralizados não servem mais concorrência Fernando Silva (DCC-FCUP) Sincronização 32 / 45

33 Exclusão Mútua Distribuída Problema: Como assegurar acesso concorrente a recursos distribuídos? Necessário prevenir competição em zonas críticas. Requisitos: apenas um processo de cada vez pode executar na zona crítica. eventualmente os pedidos para entrar ou sair da zona crítica sucedem. os pedidos são processados por ordem de acordo com a relação happens-before. Soluções básicas para assegurar acesso exclusivo a recursos distribuídos: centralizando o acesso num servidor. completamente descentralizado, usando um sistema peer-to-peer completamente distribuído, sem se impor uma topologia completamente distribuído através de um anel lógico. Fernando Silva (DCC-FCUP) Sincronização 33 / 45

34 Exclusão Mútua: solução centralizada A solução centralizada é muito simples: (a) P 1 pede ao coordenador para aceder ao recurso; permissão concedida. (b) P 2 pede acesso ao mesmo recurso; o coordenador não responde. (c) Quando P 1 liberta o recurso, o coordenador responde ao P 2. Propriedades: fácil de implementar não escala bem o servidor central pode falhar Fernando Silva (DCC-FCUP) Sincronização 34 / 45

35 Exclusão Mútua: solução descentralizada (por maioria de votação) Princípio: Assumir que cada recurso está replicado n vezes cada réplica tem o seu coordenador o acesso a um recurso é garantido quando se tem a maioria dos votos de m > n/2 coordenadores. um coordenador responde sempre e de imediato quando o coordenador avaria (crash), recupera rápido mas pode dar permissões incorrectas. Quanto robusta é a estratégia? Seja p = t/t a probabilidade de um coordenador avariar e recuperar num período t quando o seu tempo de vida é T A probabilidade de k dos m coordenadores façam reset: n ( ) m P[violação] = p v = p k (1 p) m k k k=2m n Com p = 0.001, n = 32, e m = 0.75n, temos que pv < Fernando Silva (DCC-FCUP) Sincronização 35 / 45

36 Exclusão Mútua: Ricart & Agrawala (1/2) requer ordem total de todos os eventos no sistema (Lamport) o processo que quer aceder ao recurso envia pedido para todos processos com indicação do recurso e o seu timestamp. o processo que recebe um pedido, actua do seguinte modo: se não está e não pretende aceder ao recurso, responde com OK. se está a aceder ao recurso, não responde, deixa o pedido em fila. se também pretende aceder ao recurso, compara o timestamp que recebeu com o que ele tinha enviado para os outros. O timestamp menor ganha. Responde com OK só se tiver recebido uma com timestamp menor. um processo ganha acesso quando receber o OK de todos os outros. quando termina o acesso envia OK para todos os outros. Fernando Silva (DCC-FCUP) Sincronização 36 / 45

37 Exclusão Mútua: Ricart & Agrawala (2/2) Sobre o algoritmo: é distribuído e assegura exclusão mútua sem deadlock ou starvation requer 2(n 1) mensagens, em que n é o número de processos. em vez de 1 ponto de falha, tem n. Se qualquer dos processos não responder, o seu silêncio é interpretado como não permissão de acesso e todas tentativas de acesso a zonas críticas serão bloqueadas. este algoritmo mostra que envolver todos os processos numa decisão é excessivo. Fernando Silva (DCC-FCUP) Sincronização 37 / 45

38 Exclusão Mútua: anel de tokens (token ring) Algoritmo: todos os processos estão organizados num anel lógico um token é passado pelo anel antes de entrar na zona crítica, um processo espera até que tenha o token. Só passa o token quando sair. (a) processos não estruturados; (b) processos estruturados em anel. Propriedades: tempo médio de espera pelo token n/2 (limita expansibilidade) passagem do token gasta largura de banda falha de nós quebra a estrutura do anel (detecção difícil) Fernando Silva (DCC-FCUP) Sincronização 38 / 45

39 Exclusão Mútua: comparação dos 4 métodos Algorithm # msgs Delay Problems Centralized 3 2 Coordinator crash Decentralized 3mk, k = 1,2,... 2 m Starvation, low eff. Distributed 2 (n 1) 2 (n 1) Crash of any process Token ring 1 to 0 to n 1 Lost token, proc. crash Fernando Silva (DCC-FCUP) Sincronização 39 / 45

40 Algoritmos de Eleição de Líder Muitos SDs têm por base o modelo cliente-servidor, com um servidor/coordenador (líder) e muitos clientes. Questão: Como seleccionar o líder dinamicamente? Outras questões/observações: se o líder for fixo, indicado manualmente, temos uma solução centralizada, com um único ponto de falha. falhando um líder, se tivermos um método para eleger dinamicamente um novo líder, será esta solução centralizada ou distribuída? será que uma solução inteiramente distribuída, i.e. sem coordenador, sempre mais robusta que qualquer solução centralizada/coordenada? Para determinar o coordenador: assumir que todos os nós têm um ID único necessário concordar qual dos processos activos tem o maior ID. Fernando Silva (DCC-FCUP) Sincronização 40 / 45

41 Eleição por Bullying (1/2) Ideia base: Cada processo tem uma prioridade (peso) associada e o processo com prioridade mais elevada deve ser sempre eleito coordenador. Existem três tipos de mensagens: ELECTION: anúncio de eleição ANSWER: resposta à eleição COORDINATOR: anúncio do coordenador eleito Algoritmo: 1 verificando por timeout que o coordenador falhou, P inicia uma eleição enviando uma mensagem ELECTION para os processos com identificadores maiores que o seu. 2 Se ninguém responde (msg ANSWER), então P ganha a eleição e anuncia-se como líder (envia msg COORDINATOR a todos processos). 3 Se pelo menos um processo responder, esse inicia nova eleição. A tarefa de P termina. Fernando Silva (DCC-FCUP) Sincronização 41 / 45

42 Eleição por Bullying (2/2) Fernando Silva (DCC-FCUP) Sincronização 42 / 45

43 Algoritmo de Eleição em Anel (1/2) Ideia base: Processos organizados num anel lógico. O processo com maior identificador deve ser eleito coordenador. Existem dois tipos de mensagens: ELECTION: anúncio de eleição COORDINATOR: anúncio do coordenador eleito Algoritmo: 1 verificando por timeout que o coordenador falhou, P inicia uma eleição enviando uma mensagem ELECTION, com o seu ID, para o seu sucessor. Se o sucessor estiver em baixo, envia ao seguinte. 2 Cada processo adiciona o seu ID à mensagem ELECTION e encaminha-a para o processo seguinte do anel. 3 A eleição termina quando a mensagem chega novamente a P. Este envia de seguida uma mensagem CORDINATOR através do anel com informação sobre todos processos activos. O coordenador é o processo com maior identificador. Fernando Silva (DCC-FCUP) Sincronização 43 / 45

44 Algoritmo de Eleição em Anel (2/2) o algoritmo funciona mesmo se dois processos iniciarem a eleição quase em simultaneo. Fernando Silva (DCC-FCUP) Sincronização 44 / 45

45 Algoritmo de Eleição de Superpeer Ideia base: Orientado para sistemas de grande escala com base em redes peer-to-peer. A ideia é ter vários superpeers a actuarem como coordenadores. Seleccionar superpeers tal que: nós normais tenha latência baixa no acesso a superpeers os superpeers estão distribuídos pela camada de rede os superpeers são apenas uma fracção pré-definida dos peers cada superpeer não deverá precisar de servir mais do que um número determinado de nós normais Solução baseada em DHT: fixar parte do espaço de ID para superpeers. caso se use identificadores de m-bits, reserva-se os k = ln2 S bits mais à esquerda para os superpeers. roteamento para um superpeer: enviar mensagem para a chave p para o nó responsável por pand Fernando Silva (DCC-FCUP) Sincronização 45 / 45