Resumo Sistemas distribuídos A1

Prévia do material em texto

Arquitetura de sistemas distribuídos 
 
 A arquitetura de um sistema apresenta a forma como os seus componentes 
estão dispersos e a maneira como eles interagem entre si; 
 As arquiteturas de sistemas distribuídos são classificadas em função da maneira 
na qual ocorre à coordenação entre os processos/recursos participantes. Tal 
classificação é dividida entre Centralizadas e Descentralizadas; 
 É importante ressaltar que todas as arquiteturas de sistemas distribuídos 
podem ser reproduzidas/simuladas por sistemas locais; 
 
1. Arquiteturas Centralizadas 
 
 São aquelas que possuem um elemento responsável por coordenar as ações do 
sistema; 
 Embora o elemento centralizador vá contra os princípios de sistemas 
distribuídos, por apresentar um ponto único de falha, medidas podem ser 
tomadas para contornar eventuais problemas; 
 As principais arquiteturas centralizadas são: 
 
1.1. Arquitetura cliente/servidor: 
 
 Apresenta, no mínimo, dois processos/recursos: um cliente, responsável por 
enviar uma requisição com alguma tarefa a ser processada e um servidor, que 
é responsável por receber, processar e enviar o resultado de volta para o 
cliente; 
 Os processos cliente e servidor possuem diferentes características relacionadas 
a endereçamento e execução que devem ser respeitadas para o correto 
funcionamento do sistema. 
 Exemplo de uma arquitetura cliente/servidor: 
 
 
 
 
 
 
 
envio de requisição endereçamento fixo 
 resposta aguarda 
 
 
endereçamento fixo ou dinâmico 
 
OBS.: TODA A COMUNICAÇÃO EM SISTEMAS DISTRIBUÍDOS É FEITO POR TROCAS DE 
MENSAGENS, INDEPENDENTE DA ARQUITETURA ADOTADA. 
 
 Exemplo 2: 
 
 
Cliente / servidor 
 
 
 servidor 
 
 cliente 
 
 
1.2. Arquitetura mestre/trabalhador: 
 Arquitetura que possui um conjunto de processos considerados idênticos e que 
são capazes de processar uma mesma carga de trabalho em um intervalo de 
tempo praticamente igual; 
 A existência do elemento centralizador se dá pela necessidade de divisão do 
trabalho, coordenação da execução e apresentação do resultado; 
SERVIDOR 
CLIENTE 2 
CLIENTE 
SERVIDOR WEB 
NAVEGADOR 
BANCO DE DADOS 
 Exemplo: 
usuário 
Dados de entrada dados de saída 
 
 Corrdenação 
 
 
 
OBS.: ESTA ARQUITETURA É TAMBÉM AMPLAMENTE UTILIZADA EM SISTEMAS 
 
 
2. Arquiteturas Descentralizadas 
 São arquiteturas que não apresentam uma organização clara dos seus 
componentes e não possuem um padrão específico para as trocas de 
mensagens. São elas: 
 
2.1. Arquitetura Anárquica: 
 Arquitetura que apresenta um conjunto de processos capazes de se comunicar 
com qualquer outro processo no sistema; 
 Não há nenhum nível de hierarquia, o que pode causar um número excessivo 
de trocas de mensagens no sistema; 
 Exemplo: 
 
 
Rotas de comunicação 
entre os processos 
 
 
 
MESTRE 
TR 1
 
TR 2 TR 3 TR 4 
2.2. Arquitetura PEER-TO-PEER (P2P): 
 Surgiu como uma tentativa de organizar e reduzir a quantidade de mensagens 
que ocorrem na arquitetura anárquica; 
 Um SUPER PONTO é eleito dentre um conjunto de processos. Este super ponto 
é responsável por estabelecer a comunicação com os processos de fora do seu 
conjunto; 
 Parte da máxima de que todos os processos do conjunto são iguais. Sendo 
assim, qualquer um deles é capaz de assumir a função de super ponto; 
 Exemplo; 
 
 
 
 
 
 
 
 
 
 
 
 
Sincronização e Ordenação de Eventos 
 
 Como já foi visto, uma das características de um sistema distribuído é a 
ausência de sincronismo. Isso se deve à ausência de um relógio global e à 
heterogeneidade do ambiente; 
 No entanto, existem situações em que se torna necessário que um conjunto de 
processos seja capaz de coordenar trocas de mensagens com um mínimo de 
sincronismo entre si. Em tais situações, é muito comum que haja a 
dependência entre as mensagens; 
 Sendo assim, são estipulados dois protocolos de trocas de mensagens entre os 
processos: um síncrono e outro assíncrono; 
 
 
1. TROCA SÍNCRONA (BLOQUEANTE) DE MENSAGENS: 
 Um processo (EMISSOR) envia uma mensagem iniciando a 
comunicação com um segundo processo (RECEPTOR); 
 Ao enviar a mensagem, o processo emissor fica aguardando, 
voltando a processar somente a pós receber a resposta do 
receptor; 
 O processo receptor, por padrão é capaz de atender a apenas 
uma solicitação por vez; 
 Esta forma de troca de mensagens também é chamada de 
BLOQUEANTE; 
 
Exemplo: 
 EMISSOR request RECEPTOR EMISSOR2 
 
 indisponível 
 reply seção crítica 
t t 
obs.: A linha em azul é referente ao tempo de espera (bloqueado). 
 
 É importante ressaltar que a comunicação síncrona garante a 
consistência das mensagens entre os processos. 
 
 
2. TROCA DE MENSAGEM ASSÍSNCRONA: 
 O processo emissor inicia o processo ao enviar uma requisição 
para o receptor; 
 Imediatamente após a confirmação de que a mensagem chegou 
ao receptor, o processo emissor é liberado para continuar 
executando. Portanto, essa forma de mensagens é chamada de 
NÃO BLOQUEANTES; 
 Assim como na confirmação síncronas, o receptor, por padrão 
atente a apenas uma solicitação por vez; 
 
Exemplo: 
 EMISSOR request RECEPTOR 
 
 indisponível 
 reply seção crítica 
t t 
obs.: A linha em azul é referente ao tempo de espera (bloqueado). 
 
 Apesar de ser, não BLOQUEANTE, a comunicação assíncrona 
também admite um tempo de bloqueio que embora, que maior 
do que na comunicação síncrona, existe; 
 Nesta forma de comunicação não há garantia de consistência 
entre as mensagens e o processamento do emissor. 
 
 
Ordenação de Eventos 
(controle de acesso a recursos compartilhados) 
 Assim como ocorre em sistemas locais, muitas vezes um sistema distribuído 
trabalha com recursos compartilhados entre os processos tais recursos podem 
ser desde endereços de memória, até dispositivos físicos; 
 Para evitar que problemas comuns nestas situações ocorram, tais como 
DEADLOCKS e STARVATION (Inanição) torna-se necessário o uso de técnicas 
específicas; 
 A adoção de EXCLUSÃO MÚTUA através de SEMÁFOROS é a solução mais 
simples e eficiente para prevenir esses problemas; 
 
1. A exclusão mútua por semáforos pode ser implementada de duas formas: 
 FICHAS (TOKENS): Existe uma variável MUTEX que inicialmente 
encontra-se com valor 1. Um processo que pega a ficha modifica 
MUTEX para 0 para indicar que está usando o recurso 
compartilhado. Neste momento, o sistema encontra-se em 
SEÇÃO CRÍTICA; 
 PERMISSÕES: Um processo solicita e comunica aos demais que 
está tomando posse ou liberando o recurso compartilhado. 
Neste caso, cada processo possui uma variável MUTEX que 
indica se o sistema está ou não em seção crítica. 
 Em ambos os casos, torna-se necessária à adoção de prioridades 
para que processos não aguardem indefinidamente para 
executar (Inanição). 
 
 
 
 
 
Pesquisar: 
PROTOCOLO NTP (NETWORK TIME PROTOCOL) - NTPDATE 
 
Problema do produtor/consumidor com semáforos 
 
BUFFER SIZE = N; 
SEMAPHORE MUTEX = 1; 
SEMAPHORE EMPTY = BUFFER SIZE; 
SEMAPHOREFULL = 0; 
 
CONSUMER() { 
 INT WIDGET; 
 WHILE (TRUE) { 
 --- 
 DOWN (MUTEX); momento em que o servidor entra em seção critica 
 DOWN (FULL); 
 REMOVE_ITEN (WIDGET); 
 UP (EMPTY); 
 UP (MUTEX); momento de saida da seção critica 
 --- 
 } 
} 
 
PRODUCER () { 
 INT WIDGET; 
 WHILE (TRUE) { 
 --- 
 DOWN (MUTEX); entra em seção crítica 
 DOWN (EMPTY); 
 REMOVE_ITEN (WIDGET); 
 UP (FULL); 
 UP (MUTEX); ainda está em seção crítica 
 --- 
 } 
} 
 
OBSERVAÇÃO: Somente um processo do sistema, por vez, pode entrar em seção 
crítica. 
 
Chamadas de procedimentos remotes (RPCs) 
OBSERVAÇÃO: SEÇÃO 4.2 
 
 Decorrente da necessidade de obter transparência no acesso a sistemas 
distribuídos. Tal transparência não ocorre com o uso SEND/RECEIVE; 
 Criação de um RPC para que um processo da máquina A chame (execute) um 
procedimento em uma máquina B; 
 Por padrão, uma RPC é síncrona, isto é, processo de A é suspenso enquanto o 
procedimento é executado em B; 
 Nenhum aspecto da troca de mensagens é visível para o programador, havendo 
total transparência na comunicação; 
 Principais problemas: 
 Processo faz a chamada e o procedimento remoto está em 
máquinas diferentes, executando em espaços de memória 
diferentes; 
 Necessidade de passar parâmetros e resultados (retornos). 
 Tipos de chamada; 
 POR VALOR: Um valor é passado explicitamente como 
argumento; 
 POR REFERENCIA: O parâmetro é um ponteiro para uma 
variável. Problema a ser tratado devido aos diferentes escopos 
de memória. 
 Uma RPC deve manter a transparência também em relação aos aspectos 
heterogêneos do sistema. Para isso, existe um componente chamado 
APÊNDICE; 
 O APÊNDICE é o responsável por realizar a serialização dos dados e por 
executar as chamadas de SEND e RECEIVE; 
 Afinal, como saber se uma chamada de procedimento é local ou remota? Como 
exemplo, imagine a seguinte situação hipotética. Um processo cliente (servidor 
web) precisa fazer uma consulta no servidor de banco de dados. Para isso, o 
S.W. envia a Query para o SBD, que realiza a consulta nesta situação, há RPC? 
Justifique? Não há RPC. Uma vez que o servidor web não é capaz de executar a 
consulta diretamente. O que ele faz é SOLICITAR ao servidor de banco de dados 
que execute a consulta. 
 
 
CURIOSIDADES: 
 RPC – também é conhecido como JAVA RMI (invocação remota de métodos) 
 
 
Algoritmos de eleição de processos coordenadores 
 
 Em situações nas um processo exerce função centralizadora, isto é, quando 
tem a responsabilidade de coordenar o sistema ou parte dele, existe a 
necessidade de nunca deixar o sistema sem tal processo, caso alguma falha 
venha a ocorrer; 
 Para essas situações, podem ser empregados os algoritmos de eleição de 
processo coordenador; 
 
 
 Algoritmo do valentão (BULLY) 
o Quando qualquer processo dentro de um sistema distribuído identifica 
que o coordenador falhou, ele é responsável por iniciar uma eleição que 
se segue da seguinte forma: 
1. O processo P ( que identificou a falha) envia uma mensagem 
eleição para todos os processos com número identificador mais 
alto que o seu próprio; 
2. Se nenhum processo responder, P vence a eleição e se torna o 
novo coordenador; 
3. Se um processo com ID mais alto responder, ele assume controle 
da eleição e o trabalho de P está concluído. 
o É importante observar que cada processo deve possuir um identificador 
único e que, para o algoritmo de valentão, cada processo deve conhecer 
todos os demais; 
o Em qualquer situação de eleição, somente um processo pode ser eleito 
como coordenador; 
o Se um processo que estava fora retornar, uma nova eleição é 
convocada, podendo ele se tornar o novo coordenador, caso possua o 
maior identificador. 
o Após o novo coordenador ser eleito é enviada uma mensagem a todos 
os demais processos indicando qual é o novo coordenador. 
EXEMPLO: 
 
 
 
 
 
 
 
 
 
 
 
 
 Algoritmo do Anel (RING): 
o Algoritmo que também possui o requisito de todos os processos 
possuírem um identificador. Além disso, é necessário também que cada 
0 
3 
6 
1 4 
5 
2 
P 
0 
3 
6 
1 4 
5 
2 
P 
P’ 
processo conheça o seu sucessor. Isso ocorre através de uma ordenação 
entre os processos, seja ela física ou lógica; 
1. O processo P, que identificou a falha do coordenador envia uma 
mensagem de eleição para o seu sucessor, contendo o seu 
próprio ID; 
2. O sucessor de P encaminha a mensagem ao processo seguinte, 
incluindo o seu ID na mensagem; 
3. Em dado momento, a mensagem retornaria para P. Então é 
responsável por procurar o maior ID na lista e comunicar aos 
demais qual é o novo coordenador. 
 
EXEMPLO: 
 
 
 
 
 
 
 
 
 
 
 
 
0 
6 
1 
4 
5 
3 
2 
0 
1|0 
2|1|0 
3|2|1|0 
4|3|2|1|0 
5|4|3|2|1|0 
P