Sistemas Distribuídos

Jorge Surian [email protected]

Sistemas Distribuídos: Tipos de Sistemas Distribuídos, Tipos de Arquiteturas e Sistemas Pervasivos.

Sistemas de Computação Distribuídos



Os sistemas de computação distribuídos são utilizados para tarefas de alto desempenho e podem ser subdivididos em duas classes distintas:

– –

Sistemas de computação de cluster Sistemas de computação em grade



Homogêneo x Heterogêneo

2 2

Sistemas de Computação Distribuídos

  

Sistemas de Computação – Cluster

Hardware consiste em um conjunto de estações de trabalho conectadas e se desenvolveu a partir do barateamento dos computadores pessoais.

Conexão é feita através de uma rede local, e em quase todos os casos, a computação de cluster é usada para programação paralela na qual um único programa e executado em paralelo.

3 3

Sistemas de Computação Distribuídos

 

Sistemas de Computação – Cluster

Exemplo: Sistemas Beowulf baseado em Linux, onde cada cluster consiste em um conjunto de nós de computação controlados e acessados por meio de um único só mestre, cujas tarefas são manipular e alocar determinados programas paralelos.

4 4

Sistemas de Computação Distribuídos

 

Sistema de Computação em Grade

Sistemas Distribuídos montados como federação de computadores, na qual cada sistema pode cair sob um sistema administrativo diferente, e pode ser muito diferente no que tange a hardware, software e tecnologia empregada.  Apresentam alto grau de heterogeneidade.

5 5

Sistemas de Computação Distribuídos

  

Sistema de Computação em Grade

Software usado para permitir acesso a recursos (muitas vezes clusters) de diferentes organizações reunidos para permitir a colaboração de um grupo (conceito de organização virtual).

Foco dirigido para a arquitetura, está dividida em quatro etapas, em acordo ao esquema apresentado a seguir:

6 6

Sistemas de Computação Distribuídos

 

Sistema de Computação em Grade

A camada mais baixa, chamada

camada base,

interfaces para recursos locais em um site específico. Essas interfaces são projetadas para permitir provê compartilhamento de recursos dentro de uma organização virtual. Provê funções para consultar o estado e as capacidades de um recurso, em conjunto com funções para o gerenciamento propriamente dito. Exemplo: Travar um recurso.

7 7

Sistemas de Computação Distribuídos

 

Sistema de Computação em Grade

A camada de

conectividade

consiste em protocolos de comunicação para suportar transações da grade que abranjam a utilização de múltiplos recursos. Exemplo: Protocolos de transferência de dados entre recursos ou para localizar um recurso desde uma localização remota.

8 8

Sistemas de Computação Distribuídos

 

Sistema de Computação em Grade

A camada de

recursos

é responsável pela gestão de um único recurso, utilizando funções fornecidas pela camada de

conectividade

e chama diretamente as interfaces disponibilizadas pela camada

base.

Exemplo: Recursos é responsável pelo acesso, dependendo da autenticação realizada pela camada de conectividade.

9 9

Sistemas de Computação Distribuídos

  

Sistema de Computação em Grade

A camada

coletiva

manipula o acesso a múltiplos recursos e normalmente consiste em serviços para descoberta de recursos, alocação e escalonamento de tarefas para múltiplos recursos, como replicação de dados.

A camada de

aplicação

consiste em aplicações que funcionam dentro de uma organização.

Sistemas de Informação Distribuídos



Exemplo: Portal de Turismo

Sistemas de Informação Distribuídos



Exemplo: Portal de Turismo

– A origem dos sistemas de informação distribuídos está geralmente ligada à organizações que se defrontaram comum grande quantidade de aplicações em rede e que passaram a ter crescentes problemas de interoperabilidade. – Usualmente uma aplicação em rede que era executada num servidor, que também era o servidor de banco de dados, disponibilizando-a para acessos remotos, denominados

clientes.

Sistemas de Informação Distribuídos

 

Exemplo: Portal de Turismo

Toda vez que o cliente envia uma requisição ao servidor, fica aguardando uma resposta depois da execução de uma operação específica. Integração é o processo no qual clientes empacotem várias requisições, em geral para vários servidores, em uma requisição maior como uma

transação distribuída

que será plenamente executada ou então não seria executada.  Todavia, a medida em que os componentes de dados foram se distinguindo dos de processamento, ficou claro que as aplicações se comunicassem entre si.

 

Sistemas de Informação Distribuídos Sistemas de Processamento de Transações

A partir do conhecimento de que as operações num banco de dados são feitas sob a forma de

transações

, fica natural pensarmos num processo que tem em algum ponto um início (BEGIN_TRANSACTION) e num outro local um término (END_TRANSACTION). Supõe-se que se todo processo ocorrer como se espera inicialmente a transação será realizada, de forma integral, no banco de dados (COMMIT). Todavia, se por qualquer que seja o motivo alguma parte dessa transação não puder ser executada, toda a transação é desfeita (ROLLBACK). Em geral, chama se a esse processo de

ACID

. Vejamos o porquê disso...

Sistemas de Informação Distribuídos



Sistemas de Processamento de Transações

–

Atômicas:

Para todo restante do sistema, a transação acontece como se fosse indivisível.

–

Consistente:

A transação não viola invariantes de sistema. [Notar que invariantes podem ser violados por breves instantes] –

Isoladas:

Transações concorrentes não interferem entre si. [Serializáveis] –

Duráveis:

Uma vez comprometida uma transação, as alterações serão permanentes.

Exemplo 1 - SOA

 Todas as operações realizadas em um sistemas são, ou deveriam ser, fracamente acopladas entre si, quando se pensa em criar uma Arquitetura Orientada a Serviços. Mais do que desejável, este nível de acoplamento deve ser perseguido.

 Imagine que você vá ao Shopping com sua namorada ver um filme e lanchar na praça de alimentação, no restaurante preferido de vocês. Imagine agora que o filme que você deseja assistir não esteja passando no Shopping favorito. Naturalmente é grande a chance de vocês irem noutro Shopping e acabarem lanchando noutro local.

Exemplo 1 - SOA

  As operações de “ver um filme" e “lanchar no Shopping" não possuem um relacionamento rígido. E é assim que a maioria esmagadora de atividades humanas se comporta: são fracamente acopladas umas às outras. É muito comum o requerimento de "Transação" quando o assunto é SOA. É muito comum ainda o termo "Transação" ser usado como sinônimo de "Atomicidade" de operações distribuídas. Aquele "tudo-ou-nada" normalmente implementado por Gerenciadores de Bancos de Dados. Com "Rollbacks" mágicos desfazendo operações previamente realizadas, ou ao menos uma parte indesejável delas, dependendo do Banco de Dados em si.

Exemplo 1 - SOA

  Primeiramente vamos compreender que é errado pensar que "Transação" trata-se de sinônimo de "Atomicidade". Na verdade, esta característica é uma das diversas que uma Transação pode ter.

Atomicidade é uma das características que uma “Transação” pode ter, mas não que isso seja obrigatório, pois uma “Transação” sem “Atomicidade” ainda é uma “Transação”...

Exemplo 1 – SOA (continuação)

 A definição de transações distribuídas com “Atomicidade”, na grande maioria dos casos reais, acaba não sendo desejável. Francamente, é uma má ideia! SOA encaixa ser evitado.

se em uma situação como essa. Em termos de aplicações, “Atomicidade” promove um nível de acoplamento alto que, por definição, é ruim e deve

Exemplo 1 – SOA (continuação)

 O engano reside no uso de Atomicidade em Transações de um Gerenciador de Bancos de Dados. Como temos esse recurso nativamente oferecido pelo produto, também deveriam usá-lo em outros níveis de abstração. Como por exemplo, SOA. Nada mais enganoso. Transações com Atomicidade são razoáveis e necessárias para Bancos de Dados. Não são razoáveis para aplicações. São níveis de abstração diferentes e, por conta disso, não possuem requerimentos iguais.

Exemplo 1 – SOA (continuação)

 Um dos modelos ou padrões de desenho usados quando estamos lidando com aplicações distribuídas (e SOA é um bom exemplo disso) é aquele baseado em "Ações de Compensação". Isto é, se algo sai errado com uma operação, aplicamos outras operações que funcionalmente compensam aquelas que tiveram sucesso. As operações de compensação fariam com que aquelas sem erro voltassem ao seu estado original.

Exemplo 1 – SOA (continuação)

  Supondo que exista uma situação onde uma transação distribuída com Atomicidade seja requerida. Em SOA talvez não seja possível implementá-la ou seu custo de implementação provavelmente será proibitivo. Suponha que um Serviço tenha como responsabilidade operações em dois legados distintos: Um sistemas de SAC e um ERP qualquer. A operação do SAC transcorre sem problemas, mas, por qualquer razão, a operação com o ERP não consegue ser concluída. Em um Transação com Atomicidade, a operação do SAC seria "desfeita" e voltaríamos à situação original.

Exemplo 1 – SOA (continuação)

 Ora, como o SAC não possui capacidades para tornar-se uma unidade de execução de uma transação distribuída, simplesmente não entende comandos como "rollback" ou "desfaça tal operação".   O mesmo ocorre para o ERP e na grande maioria das aplicações caseiras e pacotes de mercado. Isto não é exatamente um problema, pois, como disse anteriormente, uma Transação com Atomicidade entre SAC e ERP não seria desejável.

Basicamente, em sistemas distribuídos precisamos entender contextos, antes de mais nada.

Exemplo 2 – Transação Bancária



Transação Atômica

saque(conta1, quantia) e se forem 2 saques!!!

Dinheiro desaparece???

Se depósito não consegue ser efetuado...

depósito(conta1, quantia) quantia já retirada

Decorrências dos Exemplo...

    Saque por duas vezes, não pode jamais ser feito!

Consultar o saldo duas vezes, não há problema algum! Essa operação é

idempotente

, pois pode ser feita várias vezes sem afetar os resultados (não causa danos).

Quando se quer uma comunicação confiável, é necessário ter-se uma conexão

antes

de se enviar os dados, como ocorre no protocolo TCP/IP usado na Internet.

Quanto menor a mensagem a ser enviada, pior é a estratégia de uso de protocolo orientado à conexão.

Exemplo 3 – Inventário de Bobinas

 A atualização do inventário só é efetuada se tudo deu certo, senão rebobinar as fitas.

Sistemas de Informação Distribuídos

 

Sistemas de Processamento de Transações

O monitor de TP (Monitor de Processamento de Transação) permite que uma aplicação acesse vários servidores de banco de dados simultaneamente, dando a impressão de um processo único. Basta pensar que cada banco da figura abaixo represente algo distinto, como o banco da cia. Aérea, o banco do hotel e o banco do receptivo, para somente em caso de possibilidade simultânea nos três bancos, uma transação de turismo seja realizada.

Sistemas Pervasivos

  Nos sistemas pervasivos, os equipamentos costumam a ser caracterizados por seu pequeno tamanho, pela alimentação por bateria, por sua mobilidade e por terem somente uma conexão sem fio, se bem que nem todas essas características se aplicam a todos dispositivos.

A essência da educação pervasiva consiste em perceber este conhecimento e relacionar os processos educacionais com o contexto do aprendiz, levando em consideração seu modelo de mobilidade.

Sistemas Pervasivos

 Alguns novos elementos computacionais para suporte à educação em ambientes pervasivos são necessários, tais como: – Mobilidade: os sistemas educacionais devem dar suporte à mobilidade do aprendiz e o acesso aos recursos educacionais. Esses devem estar disponíveis em vários formatos, distribuídos em uma rede educacional, e não mais localizados em um único local;

Sistemas Pervasivos

– Adaptação: a mobilidade e a capacidade do aprendiz de acesso aos recursos educacionais utilizando diferentes recursos computacionais trazem a necessidade de adaptação a estes recursos. Os objetivos, preferências, modelos de aprendizagem, de mobilidade e de contexto do aprendiz devem ser considerados;

Sistemas Pervasivos

– Consciência do contexto: a mobilidade do aprendiz traz a possibilidade do mesmo aprender em diferentes cenários e situações, onde diferentes recursos e oportunidades de aprender podem estar disponíveis. É importante pró – ativamente sugerir e indicar ao aprendiz elementos presentes no contexto virtual e não-virtual e que são de interesse dele. Com isto, as informações sobre o local onde se encontra o aprendiz (por exemplo, um evento que está ocorrendo ou vai ocorrer) podem ser relacionadas com seus objetivos educacionais (o aprendiz pode estar interessado no tópico do evento).

Sistemas Pervasivos

 Três requisitos são básicos para se identificar um sistema pervasivo, a saber: – Adoção de mudanças contextuais.

– Incentivar composição indica "para um fim específico". Em software a expressão

ad hoc ad hoc

(expressão latina que é utilizada para designar ciclos completos de construção de um software não devidamente projetado como forma de atender alguma necessidade específica).

– Reconhecer compartilhamento como padrão.

Sistemas Pervasivos

     Instabilidade é o comportamento esperado destes sistemas Costumam estar em nosso entorno.

Há ausência de controle administrativo humano Integram equipamentos domésticos como aparelhos de TV, áudio e vídeo, dispositivos para jogos, smart phones e outros equipamentos pessoais.

Em algum momento todos os tipos de equipamentos eletrodomésticos, relógios, dispositivos para vigilância estarão totalmente integrados.

Arquiteturas

 Sistemas distribuídos, em geral, são complexa peças de software cujos componentes estão, espalhados por várias máquinas.

 Os principais estilos arquitetônicos são: –

Em camada

–

Baseadas em Objeto

–

Centradas em Dados

–

Baseadas em Eventos

Arquiteturas



Em Camadas

– Componentes são organizados em

camadas

– Componente da camada N tem permissão de chamar componentes na camada N-1 – Comum em redes de computadores

Arquiteturas



Baseadas em Objeto

– Objeto → Componente – Objetos são conectados por meio de uma chamada de procedimento (remota).

– Amplamente utilizada para sistemas de software de grande porte.

Arquiteturas



Centradas em Dados

– Processos se comunicam por meio de um repositório comum.

– Sistemas distribuídos baseados na Web, em grande parte, são centrados em dados.

Arquiteturas



Baseadas em Eventos

– Sistemas publicar/subscrever – Processos publicam eventos e o

middleware

assegura que somente os processos que se subscreveram para esses eventos os receberão – Processos fracamente acoplados: processos não se referem explicitamente uns aos outros

Arquitetura de Sistema

 Decisões a respeito de componentes de software, sua interação e sua colocação em máquinas reais.

 Três tipos: – Centralizadas – Descentralizadas – Hibridas

Arquitetura de Sistema



Centralizadas

– Modelo

cliente-servidor

– Comportamento de requisição-resposta

Arquitetura de Sistema



Centralizadas

– Como estabelecer a comunicação?

1.

Protocolo sem conexão:

 Protocolo simples, que funciona bem em redes locais  Cliente empacota uma mensagem para o servidor diretamente  Eficiente se NÃO ocorrem problemas   Exemplo: Falhas → Transferências bancarias Operações podem ser repetidas sem causar danos: idempotentes

Arquitetura de Sistema



Centralizadas

– Como estabelecer a comunicação?

2. Protocolo orientado a conexão

– Solução funciona bem em sistemas de longa distância.

– Sempre que um cliente requisita um serviço, primeiro se estabelece conexão com o servidor e depois se envia a requisição.

Arquitetura de Sistema



Centralizadas

–

Camadas de Aplicação

» Como distinguir entre cliente e servidor?

–Exemplo: Servidor de banco de dados distribuído → repassa requisições a servidores de arquivos. Assim, age como cliente continuamente.

» Como muitas aplicações cliente-servidor visam dar suporte ao acesso de usuários a banco de dados é conveniente que sejam divididas em três níveis distintos: –

Nível de interface de usuário

–

Nível de processamento

–

Nível de dados

Arquitetura de Sistema



Centralizadas

–

Nível de interface de usuário.

» Consiste em programas que permitam aos usuários finais interagir com aplicações.

» Diversos níveis de complexidade.

–

Nível de processamento

» Normalmente contem as aplicações » Exemplo: Análise de dados financeiros que pode exigir métodos e técnicas sofisticados de estatística –

Nível de dados

» Na sua forma mais simples, consiste em um sistema de arquivos.

» Mais comum utilizar um banco de dados.

» Normalmente implementado no lado servidor.

» Mantém os dados consistentes.

» Dados costumam ser persistentes.

Arquitetura de Sistema



Centralizadas

– Exemplo:

Arquitetura de Sistema

 

Arquiteturas Multidivididas

Três Níveis lógicos → várias possibilidades para a distribuição física de uma aplicação cliente-servidor por várias maquinas

Interface caracter Interface gráfica Preenchimento de formulário

Arquitetura de Sistema



Arquiteturas Multidivididas

– Gerenciamento de sistema: » Clientes gordos (

fat clients

) » Clientes magros (

thin clients

) – Servidor pode também agir como clientes:

arquitetura de três divisões

Fonte: Tanenbaum, Andrew S. e Steen, Marteen Van.

Sistemas Distribuídos, São Paulo: Prentice Hall, 2008.

Copyright © 2010 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.