06-SDRC-SistemasDistribuídos

(1)

Capítulo

17

Introdução a sistemas

_{distribuídos}

Sumário

17.1 Introdução

17.2 Atributos de sistemas distribuídos 17.2.1 Desempenho e escalabilidade 17.2.2 Conectividade e segurança

17.2.3 Confiabilidade e tolerância a falhas 17.2.4 Transparência

17.2.5 Sistemas operacionais de rede 17.2.6 Sistemas operacionais distribuídos

17.2.6 Sistemas operacionais distribuídos 17.3 Comunicação em sistemas distribuídos

17.3.1 Middleware

17.3.2 Chamada a procedimento remoto (RPC) 17.3.3 Invocação a método remoto (RMI)

17.3.4 CORBA (Common Object Request Broker Architecture) 17.3.5 DCOM (Distributed Component Object Model)

17.3.6 Migração de processos em sistemas distribuídos 17.4 Sincronização em sistemas distribuídos

17.5 Exclusão mútua em sistemas distribuídos 17.5.1 Exclusão mútua sem memória compartilhada

(2)

Capítulo

17

Introdução a sistemas

_{distribuídos}

Sumário

(continuação)

17.5.2 Algoritmo de exclusão mútua distribuída de Agrawala e Ricart 17.6 Deadlock em sistemas distribuídos

17.6.1 Deadlocks distribuídos 17.6.2 Prevenção de deadlock 17.6.3 Detecção de deadlock

17.6.4 Um algoritmo distribuído para deadlock de recurso

17.7 Estudo de caso: O sistema operacional distribuído Sprite 17.8 Estudo de caso: O sistema operacional distribuído Amoeba

(3)

Objetivos

Este capítulo apresenta:

■ A importância da computação distribuída.

■ Propriedades fundamentais e características desejáveis de

sistemas distribuídos.

■ Comunicação remota em sistemas distribuídos.

■ Sincronização, exclusão mútua e deadlock em sistemas

distribuídos.

■ Exemplos de sistemas operacionais distribuídos.

(4)

17.1 Introdução

Sistemas distribuídos

■ Os computadores remotos cooperam via rede de modo que

pareçam uma máquina local.

■ Os usuários têm a impressão de que estão interagindo com uma

única máquina.

■ A computação e o armazenamento são estendidos por toda a

rede de computadores.

■ As aplicações podem executar código em máquinas locais e remotas e compartilhar dados, arquivos e outros recursos entre

remotas e compartilhar dados, arquivos e outros recursos entre essas máquinas.

(5)

17.2 Atributos de sistemas distribuídos

A importância dos sistemas distribuídos foi evidenciada

durante décadas.

A grande difusão da Internet popularizou os sistemas

distribuídos.

Atributos dos sitemas distribuídos:

■ Desempenho

■ Escalabilidade ■ Conectividade

■ Confiabilidade ■ Tolerância a falhas

(6)

17.2.1 Desempenho e escalibilidade

Sistema centralizado

■ Um único servidor gerencia todas as requisições dos usuários.

■

Sistema distribuído

■ As requisições dos usuários podem ser enviadas a diferentes

servidores trabalhando em paralelo para aumentar o desempenho.

■

Escalabilidade

■ Permite que um sistema distribuído expanda-se (isto é,

acrescente mais máquinas ao sistema) sem influir nas

acrescente mais máquinas ao sistema) sem influir nas aplicações e nos usuários existentes.

(7)

17.2.2 Conectividade e segurança

Sistemas distribuídos

■ Suscetíveis a invasões por usuários mal-intencionados quando

eles contam com meios de comunicação inseguros.

Para se proteger mais:

■ Permita que apenas usuários autorizados acessem os recursos. ■ Cuide para que as informações transmitidas pela rede possam

ser lidas apenas pelas pessoas a que se destinam.

■ Ofereça mecanismos para proteger os recursos contra invasões.

(8)

17.2.3 Confiabilidade e tolerância a falhas

Tolerância a falhas

■ Implementada quando se oferece replicação de recursos

através do sistema.

■

Replicação

■ Oferece aos usuários maior confiabilidade e disponibilidade em

relação a implementações em máquinas isoladas.

■ Os projetistas devem desenvolver mecanismos que garantam

consistência entre as informações de estado em diferentes máquinas.

(9)

17.2.4 Transparência

Transparência de acesso

■ Oculta os detalhes dos protocolos de rede que possibilitam a

comunicação entre computadores distribuídos.

Transparência de localização

■ Baseia-se na transparência de acesso para ocultar a localização

dos recursos no sistema distribuído.

Transparência de falha

■ Método pelo qual um sistema distribuído oferece tolerância a

falhas.

■ Ponto de verificação

● Armazena periodicamente o estado de um objeto de modo que possa

ser restaurado se uma falha no sistema distribuído causar a perda desse objeto.

■ Replicação

(10)

17.2.4 Transparência

Transparência de replicação

■ Oculta que diversas cópias de um recurso estão disponíveis no

sistema.

Transparência de persistência

■ Oculta a informação sobre onde o recurso está armazenado —

memória ou disco.

Transparência de migração e relocação

■ Oculta a movimentação de componentes de um sistema

distribuído.

■ Transparência de migração

● Mascara a movimentação de um objeto de uma localização para

● Mascara a movimentação de um objeto de uma localização para outra no sistema.

■ Transparência de relocação

● Mascara a relocação de um objeto de outros objetos que se comunicam com ele.

Transparência de transação

■ Permite que um sistema obtenha consistência mascarando a

coordenação entre um conjunto de recursos.

■ Oculta a implementação de pontos de verificação e outros

(11)

17.2.5 Sistemas operacionais de rede

Sistema operacional de rede

■ Acessa recursos em computadores remotos que executam

sistemas operacionais independentes.

■ Não é responsável pelo gerenciamento de recursos em locais

remotos.

■ As funções distribuídas são explícitas, em vez de transparentes.

● Um usuário ou processo tem de especificar explicitamente a

localização do recurso para recuperar um arquivo em rede ou executar remotamente uma aplicação.

■ Falta de transparência em sistemas operacionais de rede.

● Desvantagem: não oferece alguns dos benefícios dos sistemas operacionais distribuídos.

● Vantagem: é mais fácil de implementar que o sistema operacional distribuído.

(12)

17.2.6 Sistemas operacionais distribuídos

Sistemas operacionais distribuídos

■ Gerenciam os recursos localizados em diversos computadores

em rede.

■ Empregam vários dos mesmos métodos de comunicação,

estruturas de sistema de arquivo e outros protocolos encontrados em sistemas operacionais de rede.

■ Comunicação transparente

● Os objetos no sistema não têm conhecimento dos computadores independentes que oferecem o serviço (diferentemente dos sistemas operacionais de rede).

■ É raro encontrar sistemas distribuídos “verdadeiros” porque é

(13)

17.3 Comunicação em sistemas distribuídos

Os projetistas devem estabelecer a

interoperabilidade entre computadores e aplicações

heterogêneos.

Interoperabilidade

● Permite que componentes de software interajam entre diferentes

→ plataformas de hardware e software;

→ linguagens de programação;

→ protocolos de comunicação.

Interface padronizada

● Permite que cada par de cliente/servidor comuniquem-se usando uma única interface comum, compreendida por ambas as partes.

(14)

17.3.1 Middleware

O software, nos sistemas distribuídos, ajudam a

oferecer:

■ Portabilidade

● Possibilita a mudança de um sistema ou componente (incluindo

ambos, software e hardware) de um ambiente para outro sem alterar o sistema ou componente que está sendo transferido.

■ Transparência ■ Interoperabilidade

Fornece interfaces de programação padronizadas para

possibilitar a comunicação interprocessos entre

computadores remotos.

(15)

17.3.2 Chamada a procedimento

remoto (RPC)

RPC

■ Permite que um processo em execução em um computador

chame um procedimento em um processo em execução em outro computador.

■ Meta da RPC

● Simplificar o processo de escrita de aplicações distribuídas

preservando a sintaxe de uma chamada a procedimento local e, ao mesmo tempo, iniciando de modo transparente uma comunicação de rede.

(16)

17.3.2 Chamada a procedimento

remoto (RPC)

Para emitir uma RPC:

■ O processo do cliente faz uma chamada ao procedimento no

stub do cliente.

■ O stub do cliente faz a montagem de dados para empacotar

argumentos de procedimento com o nome do procedimento em uma mensagem para transmissão via rede.

■ O stub do cliente transfere a mensagem ao servidor. ■ O servidor transmite a mensagem ao stub do servidor.

(17)

17.3.2 Chamada a procedimento

remoto (RPC)

Para emitir uma RPC (continuação):

■ A mensagem é desmontada.

■ O stub envia os parâmetros ao procedimento local apropriado. ■ Ao concluir o procedimento, o stub do servidor monta o

resultado e o envia de volta ao cliente.

■ Finalmente, o stub do cliente desmonta o resultado, notifica o

processo e transfere o resultado a ele.

(18)

Figura 17.1 Modelo de comunicação da RPC.

17.3.2 Chamada a procedimento

remoto (RPC)

(19)

Slide 18

BH1 Capturar figura!

(20)

17.3.3 Invocação a método

remoto (RMI)

RMI

■ Permite que um processo Java em execução e um computador

chame um método de um objeto em um computador remoto usando a mesma sintaxe como uma chamada a método local.

■ Semelhante à RPC, os detalhes da montagem de parâmetros e

do transporte de mensagems por RMI são transparentes ao programa que emite a chamada.

■ A camada de stub/esqueleto da RMI contém estruturas de montagem de parâmetros análogas aos stubs de cliente e servidor da RPC.

servidor da RPC.

■ O stub emprega serialização de objeto.

● Isso permite que os programas passem objetos Java como parâmetros e recebam objetos como valores de retorno.

(21)

17.3.3 Invocação a método

remoto (RMI)

RMI (continuação)

■ A camada remota de transferência (RRL) e a camada de

transporte da RMI trabalham juntas para enviar a mensagem montada entre o cliente e o servidor.

■ O esqueleto desmonta os parâmetros, identifica o objeto no

qual o método deve ser chamado e chama esse método.

■ Ao concluir o método, o esqueleto monta o resultado e o

devolve ao cliente via RRL e stub.

(22)

17.3.4 CORBA (Common Object Request Broker Architecture)

CORBA

■ Padrão aberto desenvolvido para permitir a interoperação entre

programas em sistemas heterogêneos e homogêneos.

■ Suporta objetos como parâmetros ou valores de retorno em

procedimentos remotos durante a comunicação interprocessos.

(23)

17.3.4 CORBA (Common Object Request Broker Architecture)

Implementação CORBA

■ O processo do cliente passa a chamada a procedimento e os

argumentos necessários ao stub do cliente.

■ O stub do cliente monta os parâmetros e envia a chamada a

procedimento por meio de seu agente de solicitação de objetos (ORB), que se comunica com o ORB no servidor.

■ CORBA oferece aos programadores independência de linguagem

por meio da linguagem de definição de interface (IDL), que lhes permite definir estritamente os procedimentos que podem ser chamados no objeto.

(24)

17.3.5 DCOM (Distributed Component Object Model)

DCOM

■ Desenvolvido para possibilitar que os componentes de software

residentes em computadores remotos interajam entre si.

■ Como em CORBA, no DCOM os objetos são acessados por meio

de interfaces.

■ Diferentemente de CORBA, entretanto, no DCOM os objetos

podem ter diversas interfaces.

■ Quando um cliente solicita um objeto DCOM de um servidor, o

cliente deve também solicitar uma interface específica do objeto.

(25)

17.3.6 Migração de processos

em sistemas distribuídos

Migração de processos

■ Transfere um processo entre dois computadores em um sistema

distribuído.

■ Permite que os processos utilizem um recurso remoto. ■ Tarefa complexa que em geral reduz o desempenho do

processo que está sendo migrado.

Clonagem de processos

■ Semelhante à migração de processos.

■ Em vez de transferir um processo para uma localização remota,

(26)

17.4 Sincronização em sistemas distribuídos

É difícil determinar a ordem segundo a qual um

evento ocorre.

■ Os atrasos de comunicação, em uma rede distribuída, são

imprevisíveis.

Ordenação causal

■ Assegura que todos os processos reconheçam que um evento

causalmente dependente deve ocorrer apenas após o evento do qual é dependente.

■ É implementada pela relação acontece-antes:

● Se os eventos a e b pertencerem ao mesmo processo, então a → b

se a ocorrer antes de b.

● Se o evento a é o emissor de uma mensagem e o evento b é o receptor da mensagem, então a → b.

● Essa relação é transitiva.

■ Apenas uma ordenação parcial

● Os eventos em relação aos quais não é possível determinar qual

(27)

17.4 Sincronização em sistemas distribuídos

Ordenação total

■ Possibilita que todos os eventos sejam ordenados e que a

causalidade seja preservada.

■ Pode ser implementada por meio de um relógio lógico que

atribui uma marca de tempo (timestamp) a cada evento que ocorre no sistema.

■ Os relógios lógicos escalares sincronizam os relógios lógicos nos

hospedeiros remotos e garantem a causalidade.

(28)

17.5 Exclusão mútua em sistemas distribuídos

Vários métodos de sincronização são implementados

para impor a exclusão mútua nos sistemas

distribuídos.

■ Passagem de mensagem.

■ Algoritmo de exclusão mútua distribuída de Agrawala e Ricart.

(29)

17.5.1 Exclusão mútua

sem memória compartilhada

Em ambientes sem memória compartilhada, a

exclusão mútua tem de ser implementada por meio

da passagem de mensagem.

Para sincronizar o sistema, os sistemas de passagem

de mensagem usam conceitos de sincronização de

relógio para empregar:

■ Difusão FIFO

● Garante que, quando duas mensagens são enviadas de um processo para outro, a mensagem enviada primeiro chegará primeiro.

■ Difusão causal

● Garante que, quando a mensagem m₁ é causalmente dependente da mensagem m₂, nenhum processo enviará m₁ antes de enviar m_2. ■ Difusão atômica

● Garante que todas as mensagens em um sistema sejam recebidas na mesma ordem em cada processo.

(30)

17.5.2 Algoritmo de exclusão mútua distribuída de

Agrawala e Ricart

Para que um processo possa entrar em sua seção

crítica:

■ O processo deve primeiro enviar uma mensagem de solicitação

a todos os outros processos no sistema.

■ O processo deve receber uma resposta de cada um desses

processos.

Quando um processo receber uma solicitação para

entrar em uma seção crítica e não tiver enviado uma

solicitação própria, ele enviará uma resposta.

(31)

17.5.2 Algoritmo de exclusão mútua distribuída de

Agrawala e Ricart

Se o processo tiver enviado sua própria solicitação,

comparará a marca de tempo das duas solicitações.

■ Se a marca de tempo de sua própria solicitação for posterior à

da outra solicitação, o processo enviará uma resposta.

■ Se a marca de tempo de sua própria solicitação for anterior à

da outra solicitação, o processo atrasará sua resposta.

■ Finalmente, se a marca de tempo das solicitações forem iguais,

o processo comparará seu número de processo com o do processo requisitante.

processo requisitante.

● Se o seu próprio número for superior, enviará uma resposta; do

(32)

17.6 Deadlock em sistemas distribuídos

Deadlock distribuído

■ Ocorre quando os processos espalhados por diferentes

computadores em uma rede aguardam eventos que não ocorrerão.

(33)

17.6.1 Deadlocks distribuídos

Existem três tipos de deadlock distribuído:

■ Deadlock de recurso

● Como discutido no Capítulo 7.

■ Deadlock de comunicação

● Espera circular de sinais de comunicação. ■ Deadlock fantasma

● Em decorrência dos atrasos de comunicação associados com a

computação distribuída, é possível que o algoritmo de detecção de deadlock detecte um deadlock (denominado deadlock fantasma, um deadlock percebido) que não existe.

● Embora essa forma de deadlock não possa causar uma falha

● Embora essa forma de deadlock não possa causar uma falha imediata no sistema, é uma fonte de ineficácia.

(34)

17.6.2 Prevenção de deadlock

Dois algoritmos foram desenvolvidos para evitar

deadlocks.

■ Contam com processos de ordenação que se baseiam no

momento em que o processo foi iniciado.

■ Estratégia ferir-esperar

● Rompe o deadlock recusando a condição de não-preempção.

● Um processo aguardará outro processo se o primeiro tiver sido criado antes do outro.

● Um processo ferirá (reiniciará) outro se o primeiro tiver sido criado após o outro.

■ Estratégia esperar-morrer

● Rompe o deadlock recusando a condição esperar-por.

● Um processo aguardará outro se o primeiro tiver sido criado após o

outro.

● Um processo morrerá (reiniciará) se tiver sido criado antes do outro

(35)

Figura 17.2 Estratégia ferir-esperar.

17.6.2 Prevenção de deadlock

(36)

Slide 34

(37)

Figura 17.3 Estratégia esperar-morrer.

17.6.2 Prevenção de deadlock

(38)

Slide 35

(39)

17.6.3 Detecção de deadlock

Detecção central de deadlock

■ Todo o sistema é monitorado por um único nodo.

■ Sempre que um processo solicita ou libera um recurso, informa

o nodo central, que verifica continuamente o sistema em busca de ciclos.

■ Os DDAs de detecção central são fáceis de implementar e são

eficazes para LANs.

■ Desvantagens:

● O desempenho do sistema pode ser prejudicado (o nodo central

torna-se um gargalo).

● Não há tolerância a falhas — o nodo central torna-se o único ponto de falha do sistema.

(40)

17.6.3 Detecção de deadlock

■

Detecção hierárquica de deadlock

■ Organiza cada nodo no sistema como um nodo em uma árvore. ■ Cada nodo, exceto as folhas, coleta informações de alocação de

recursos de todos os seus filhos.

■ A estrutura em árvore ajuda a aumentar a tolerância a falhas. ■ É mais eficaz.

● Pelo fato de a detecção de deadlock ser dividida em hierarquias e grupos, os nodos que não apresentam a possibilidade de deadlock para um recurso não têm de participar da detecção de deadlock para esse recurso.

(41)

17.6.3 Detecção de deadlock

Detecção de deadlock distribuída

■ Atribui a responsabilidade de detecção de deadlock a cada

nodo.

■ Cada nodo no sistema consulta todos os outros nodos para

verificar se qualquer outro nodo tem a ver com o deadlock.

■ Esse é o método mais tolerante a falhas da detecção de

deadlock.

● A falha de um nodo não provocará falha em outro nodo.

(42)

17.6.4 Um algoritmo distribuído

para deadlock de recurso

Johnston et al apresentaram um algoritmo simples

para detecção de deadlock em sistemas distribuídos:

■ Cada processo monitora o grafo de transação esperar-por

(TWFG) com o qual está associado.

■ Quando um processo solicita um recurso retido por um outro

processo, o processo requisitante é bloqueado e o TWFG atualizado.

■ Enquanto isso, nenhum deadlock é detectado e removido.

(43)

Figura 17.4 Sistemas sem deadlocks.

17.6.4 Um algoritmo distribuído

para deadlock de recurso

(44)

Slide 40

(45)

Figura 17.5 Deadlock é introduzido no sistema.

17.6.4 Um algoritmo distribuído

para deadlock de recurso

(46)

Slide 41

(47)

Figura 17.6 Sistema após a eliminação do deadlock.

17.6.4 Um algoritmo distribuído

para deadlock de recurso

(48)

Slide 42

(49)

17.7 Estudo de caso: O sistema operacional

distribuído Sprite

Sprite

■ Inúmeras estações de trabalho pessoais estão conectadas e

diversos computadores podem estar ociosos em um determinado momento.

■ As estações de trabalho ociosas permitem que o Sprite use a

migração de processos para equilibrar a carga de trabalho do sistema.

■ Quando o servidor central de migração é notificado de que uma

estação de trabalho está ociosa, migra um processo para esse computador.

■ Quando o usuário do computador-alvo retorna, a estação de

trabalho notifica o servidor central de migração sobre o retorno, e o processo é migrado de volta para o computador nativo.

(50)

17.7 Estudo de caso: O sistema operacional

distribuído Sprite

Sprite (continuação)

■ O núcleo Sprite oferece mais chamadas independentes de

localização fornecendo exatamente a mesma visualização do sistema de arquivo para cada estação de trabalho.

■ Quando é solicitada uma chamada dependente de localização:

● O sistema encaminha a chamada ao computador nativo para avaliação

→ ou

● O sistema transfere a informação de estado do processo do computador nativo para o computador-alvo.

computador nativo para o computador-alvo.

■ Além disso, o sistema de arquivo do Sprite adiciona os arquivos

(51)

17.8 Estudo de caso: O sistema operacional

distribuído Amoeba

Amoeba:

■ Os usuários compartilham processadores em um ou mais

reservatórios de processadores.

■ Quando um usuário emite um comando para executar um

processo, o reservatório de processadores aloca dinamicamente os processadores para o usuário.

■ Quando o processo do usuário é concluído, o usuário retorna os

processadores alocados ao reservatório de processadores.

(52)

17.8 Estudo de caso: O sistema operacional

distribuído Amoeba

Amoeba (continuação)

■ Oferece transparência ocultando do usuário o número e a

localização dos processadores.

■ Amoeba suporta duas formas de comunicação:

● Comunicação ponto-a-ponto

→ O stub do cliente envia uma mensagem de solicitação ao stub do servidor e bloqueia-se, aguardando a resposta do servidor.

● Comunicação de grupo

→ As mensagens são enviadas a todos os receptores exatamente na mesma ordem.

(53)

17.8 Estudo de caso: O sistema operacional

distribuído Amoeba

O sistema de arquivo do Amoeba

■ Tem um servidor de arquivos padronizado denominado servidor

de munição, cuja memória primária é grande.

■ Os arquivos armazenados no servidor de munição são

imutáveis.

■ Se um arquivo for modificado, um novo arquivo será criado

para substituir o antigo, e o antigo será deletado do servidor.

■ O servidor de munição também armazena arquivos

contiguamente no disco, de modo que pode transferir arquivos

contiguamente no disco, de modo que pode transferir arquivos mais rápido que o Sprite.