sistemas distribuídos jorge surian [email protected] sistemas distribuídos: tipos de sistemas...

Sistemas DistribuídosJorge [email protected]

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

22

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

33


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.

44


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

55


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.

66


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:

77


Sistema de Computação em Grade A camada mais baixa, chamada camada base,

provê interfaces para recursos locais em um site específico. Essas interfaces são projetadas para permitir 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.

88


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.

99


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.

1010


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.

1111

Sistemas de Informação Distribuídos

Exemplo: Portal de Turismo

1212


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.

1313


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.

1414

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...

1515


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.

1616

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.

1717

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.

1818

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”...

1919

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-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 ser evitado.

2020


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.

2121


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.

2222


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.

2323


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.

2424

Exemplo 2 – Transação Bancária Transação Atômica

quantia já retirada

Dinheiro desaparece???

depósito(conta1, quantia)

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

saque(conta1, quantia)

e se forem 2 saques!!!

2525

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.

2626

Exemplo 3 – Inventário de Bobinas

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

2727

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.

2828

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.

2929

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;

3030

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;

3131

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).

3232

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 ad hoc (expressão latina

que indica "para um fim específico". Em software a expressão ad hoc é 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.

3333

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.

3434

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

3535

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

3636

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.

3737

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.

3838

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

3939

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

4040


Centralizadas– Modelo cliente-servidor– Comportamento de requisição-resposta

4141


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

4242


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.

4343


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

4444


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.

4545

Arquitetura de Sistema Centralizadas

– Exemplo:

4646

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

4747

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

4848

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.

Fonte:

Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribuídos, São Paulo: Prentice Hall, 2008.

sistemas distribuídos jorge surian [email protected] sistemas distribuídos: tipos de sistemas...

Documents