Sistemas Distribuídos

(1)

Sistemas Distribu´ıdos

Comunica¸c˜ao em Grupo

(2)

Grupos em Aplica¸c˜

oes Distribu´ıdas

grupos fortemente acoplados:

replica¸c˜ao de servi¸cos confiabilidade tempo de resposta

clientes com estado compartilhado computa¸c˜ao cient´ıfica

...

Primitiva de comunica¸c˜ao em grupo

(3)

Grupos em Aplica¸c˜

oes Distribu´ıdas

grupos fracamente acoplados:

observadores “melhor esfor¸co”

monitoramento de ambientes de execu¸c˜ao consumo de dados: valores de mercados, etc

Primitiva de comunica¸c˜ao em grupo

um processo envia uma mensagem para um grupo de processos e todos os destinat´arios recebem

(4)

Broadcast ou Multicast

em redes: conceito de entrega para todos e para alguns conceitos se confundem em sistemas distribu´ıdos

(5)

Comunica¸c˜

ao em Grupo: Problemas Novos

alguns recebem e outros n˜ao

(6)

Garantias de Entrega

confiabilidade ordena¸c˜ao

Implementa¸c˜ao

(7)

(8)

N´ıveis de garantia de entrega

1 _{Melhor-esfor¸co (best-effort): garantia de entrega entre}

processos corretos

2 _Confi´_{avel (reliable): garantia all-or-nothing mesmo se o}

emissor falhar

(9)

Garantia de entrega: Implementa¸c˜

ao

uso de holdback queue

em geral, mensagens com identificadores ´unicos

o que j´a existe no SO agora em bibliotecas ou middlewares custos de espa¸co e processamento!

(10)

Garantias de entrega: Implementa¸c˜

ao por algoritmos

distribu´ıdos

(11)

Componentes orientados a eventos

nota¸cão baseada em eventos ass´ıncronos. cada componente é identificado por um nome, provê uma interface na forma de eventos que ele trata (requests) ou produz (indications). e garante um conjunto de

propriedades. R. Guerraoui, L. Rodrigues. Reliable Distributed Programming. Springer. 2006.

(12)

Exemplo de c´

odigo nos componentes

upon event <Event1 | att1, att2, ...> do ...faz algo...

trigger <Event2 | att1, att2, ...>;// envia evento

upon event <Event3 | att1, att2, ...> do ...faz algo...

(13)

Exemplo de m´

odulo de impress˜

ao

M´odulo

Module:

Name: Print Events:

Request: <PrintRequest | rqid, str> Indication: <PrintConfirm | rqid>

Algoritmo

Implements: Print

upon event <PrintRequest | rqid, str> do print(str);

(14)

Exemplo de servi¸co de impress˜

ao com n

o

de requisi¸c˜

oes

limitado

M´odulo Module: Name: BoundedPrint Events:

Request: <BoundedPrintRequest | rqid, str> Indication: <PrintStatus | rqid,status>: Ok/Nok Indication: <PrintAlarm>: atingiu o limite

(15)

Exemplo... impress˜

ao com n

o

de requisi¸c˜

oes limitado

Algoritmo

Implements: BoundedPrint Uses: Print

upon event <Init> do bound := Threshold;

upon event <BoundedPrintRequest | rqid, str> do if bound > 0 then

bound := bound - 1;

trigger <PrintRequest | rqid, str>; if bound = 0 then trigger <PrintAlarm>; else

trigger <PrintStatus | rqid, Nok>; upon event <PrintConfirm | rqid> do

(16)

Broadcast do melhor-esfor¸co

Um processo envia uma msg em um passo de comunica¸cão para todos os processos do sistema, incluindo ele mesmo Custo para garantir confiabilidade é apenas do lado do emissor (se ele falhar, nenhuma garantia de entrega é oferecida)

(17)

Interface e propriedades do “Bcast melhor-esfor¸co”

Module:

Name: BestEffortBroadcast (beb). Events:

Request: <bebBroadcast | m>: bcast m

Indication: <bebDeliver | src, m>: entrega m Properties:

BEB1: Validade melhor-esfor¸co: se Pi e Pj

s~ao corretos, toda msg de Pi ´e entregue em Pj

BEB2: N~ao duplica¸c~ao: nenhuma msg ´e entregue mais de uma vez

BEB3: N~ao-cria¸c~ao: se a msg ´e entregue em Pj

(18)

Algoritmo Bcast b´

asico

Implements: BestEffortBroadcast (beb) Uses: PerfectPointToPointLinks (pp2p) upon event <bebBroadcast | m> do

forall pi do

trigger <pp2pSend | pi, m>; upon event <pp2pDeliver> | pi, m> do

(19)

Exemplo de execu¸c˜

ao de Bcast b´

asico

(20)

Interface de comunica¸c˜

ao p2p utilizada...

Interface do enlace

Module:

Name: PerfectP2PLink Events:

Request: < pp2pSend | dest, msg > Indication: < pp2pDeliver | src, msg >

entrega confi´avel: se pi manda para pj e nenhum deles falha,

pj em algum momento recebe

ausência de duplica¸cão de mensagens ausência de cria¸cão de mensagens

(21)

exemplo implementa¸c˜

ao PerfectP2P

1 _{retransmite eternamente (did´}_{atico mas sem bom}

desempenho...)

2 elimina duplicatas

(22)

confiabilidade do broadcast de melhor esfor¸co

1 se transmissor n˜ao falhar, garantia de entrega a todos 2 se transmissor falhar:

processos podem “discordar” sobre entrega de mensagem broadcast de melhor esfor¸co pode não ter transmitido para todos ou falha pode ter ocorrido antes de terem sido feitas as retransmissões necessárias

(23)

Broadcast confi´

avel

todos os processos devem receber (tratar) o mesmo conjunto de mensagens

no¸c˜ao de acordo

(24)

Interface e propriedades do Bcast confi´

avel

Molule:

Name: Reliable Broadcast (rb). Events:

Request: <rbBroadcast | m>: bcast m

Indication: <rbDeliver | src, m>: entrega m Properties:

RB1: Validade: se Pi e Pj

s~ao corretos, toda msg de Pi ´e entregue em Pj

RB2: N~ao duplica¸c~ao: nenhuma msg ´e entregue mais de uma vez

RB3: N~ao-cria¸c~ao: se a msg ´e entregue em Pj

(25)

Algoritmo Bcast confi´

avel regular

Implements: ReliableBroadcast (rb) Uses: BestEffortBroadcast (beb) upon event <Init> do

delivered := {};

upon event <rbBroadcast | m> do delivered := delivered U {m}; trigger <rbDeliver | self, m>;

trigger <bebBroadcast | [DATA,self,m]>;

upon event <bebDeliver> | pi, [DATA,self,m] > do if(m not in delivered) do

delivered := delivered U {m}; trigger <rbDeliver | source_m, m>;

(26)

(27)

Broadcast confi´

avel regular – limita¸c˜

ao

mensagem pode ser tratada no pr´oprio processo emissor antes de chegar a outros, e em seguida emissor falhar

P1 P2 P3 P4

X

(28)

Broadcast confi´

avel uniforme

mensagem só é entregue a aplica¸cão depois que todos os processos no grupo confirmam recebimento

necessidade de detector de falhas perfeito gera alertas de falhas de processos acoplamento fort´ıssimo entre processos

(29)

Broadcast ordenado

As solu¸cões anteriores não garantem ordem de entrega das mensagens enviadas por processos diferentes (pp2p pode garantir ordem de entrega de msgs de 1 mesmo processo) Algumas aplica¸cões precisam de garantias de ordem de entrega.

ordem total ordem causal

(30)

Ordem Total

N˜ao importa a ordem de entrega, mas deve ser a mesma em todos os processos do grupo.

(31)

(32)

(33)

Ordem Causal

poss´ıvel rela¸c˜ao de causalidade

uma mensagem pode ter sido consequencia de outra ainda n˜ao vista

(34)

Causalidade em eventos distribu´ıdos...

a− >b: o evento a ocorre antes do evento b se a ocorre antes de b em um mesmo processo P a=send(m) no processo P e b=receive(m) no processo Q

existe c tal que a precede c e c precede b

a||b: os eventos a e b s˜ao concorrentes

(35)

Interface e propriedades do “Bcast ordem causal”

Molule:

Name: ReliableCausalOrder (rco) Events:

Request: <rcoBroadcast | m>: bcast m

Indication: <rcoDeliver | src, m>: entrega m Properties:

CB: Entrega causal: m2 s´o ´e entregue em Pi

se toda msg mi tal que mi->m2 foram entregues RB1: Validade

RB2: N~ao-duplica¸c~ao RB3: n~ao-cria¸c~ao RB4: Acordo

(36)

Algoritmo Bcast ordem causal

Uses: ReliableBroadcast (rb) upon event <Init> do

delivered := 0; past := 0; upon event <rcoBroadcast | m> do

trigger <rbBroadcast | [DATA,past,m]>; past := past U {(self,m)};

upon event <rbDeliver> | pi, [DATA,past_m,m] > do if(m n~ao-pertence a delivered) then

forall (s_n, n) in past_m do if(n n~ao-pertence delivered) then

trigger <rcoDeliver | s_n, n>; delivered := delivered U {n}; past := past U {(s_n,n)}; trigger <rcoDeliver | pi, m>; delivered := delivered U {m}; past := past U {(pi,m)};

(37)

Rel´

ogio L´

ogico (Lamport)

conceito de relógio lógico modela ordena¸cão (parcial) de eventos

cada evento associado a um valor r (ei) de forma que

(38)

Rel´

ogio L´

ogico — Implementa¸c˜

ao

cada processo P mant´em um contador, inicialmente RLP = 0

a cada evento e, P associa um valor RLP(e) e incrementa seu

contador

se evento e ´e envio de mensagem, P acrescenta campo timestamp com valor RLP(e)

ao receber mensagem M com timestamp TS , processo Q faz RLQ = max (RLQ, TS ) + 1

(39)

Broadcast causal com espera

uso de relógio lógico e timestamps: funciona se tempo de entrega de mensagens tem limite máximo

(40)

Broadcast causal

uso de mensagens “posteriores” para validar mensagens com timestamp TS

tempo de quarentena (dependente de latˆencia da rede) em fila de holdback

(41)

Vetor de timestamps

Vetor de timestamps: id´eia b´asica

Dados N processos, usa-se um vetor de N elementos (ao inv´es de um valor escalar)

A cada evento “e”, associa-se um vetor de timestamps cujo i-´esimo elemento indica quantos mensagens do processo i j´a foram vistas

(42)

Vetor de timestamp

Defini¸c˜ao da rela¸c˜ao <

Sejam a e b dois eventos quaisquer VT (a) < VT (b):

1 ∀i , VT (a)[i ] ≤ VT (b)[i ] 2 ∃j, VT (a)[j] < VT (b)[j]

Note que < ´e uma ordem parcial, existem eventos que n˜ao podem ser comparados por serem concorrentes

Ex., x = [0, 0, 1, 0] e y = [1, 0, 0, 0], pois VT (x ) 6= VT (y ) e n˜ao vale VT (x ) < VT (y ) nem VT (y ) < VT (x )

(43)

Vetor de timestamp

Funcionamento

Cada processo mant´em seu VT que come¸ca com 0 em todas

as posi¸c˜oes

Para cada evento “e” local e de envio de msg, incrementa o componente do processo local no VT e associa VTp ao evento

“e”: VTp[p] = VTp[p] + 1 e VT (e) = VTp

Quando Q recebe uma mensagem, atualiza cada campo do seu VT:

VTq[i ] = VTq[i ] + 1, i = q

VTq[i ] = max (VTq[i ], VTm[i ]), i 6= q

Esta ´ultima parte garante que tudo que acontecer depois em Pq

passa a ser causalmente relacionado com tudo o que aconteceu antes em Pi

(44)

Exemplo de uso de VT para ordena¸c˜

ao de eventos

r2

r3

r1

1 0 0

0 0 0

1 0 0 1 0 0

(45)

VT para ordena¸c˜

ao causal

´

e necess´ario n˜ao apenas estabelecer ordem mas garantir que foram vistas todas as mensagens que precedem causalmente determinada mensagem!

(46)

Exemplo de entrega em ordem causal

r2 r3 r1 1 0 0 0 0 0 0 0 0 1 0 0 1 0 0

(47)

Exemplo de entrega em ordem causal

r2 r3 r1 1 0 0 0 0 0 0 0 0 X 1 0 0

(48)

Exemplo de entrega em ordem causal

r2 r3 r1 1 0 0 0 0 0 1 0 0

(49)

Exemplo de entrega em ordem causal

r2 r3 r1 1 0 0 0 0 0 1 1 0 1 1 0 1 1 0

(50)

Exemplo de entrega em ordem causal

r2 r3 r1 1 0 0 0 0 0 1 1 0 1 1 0 1 1 0

pode ser entregue à aplicação!

não pode ser entregue à aplicação!

(51)

Gerˆ

encia de Grupos

algoritmos de ordena¸c˜ao sup˜oem que cada participante conhece os membros do grupo

grupos estáticos x dinâmicos (falhas, adesões, etc)

servi¸co de membership

(52)

Referˆ

encia

R. Guerraoui and L. Rodrigues. Introduction to Reliable Distributed Programming Springer, 2006