Sumário 1. Aspectos gerais de um projecto de sistemas distribuído (que devem ser considerados) ...................................................................................................................... 2

1.1. Heterogeneidade ................................................................................................. 2 1.2. Flexibilidade ....................................................................................................... 3 1.3. Segurança............................................................................................................ 3 1.4. Escalabilidade ..................................................................................................... 3 1.5. Confiabilidade..................................................................................................... 4 1.6. Disponibilidade ................................................................................................... 5 1.7. Concorrência ....................................................................................................... 5 1.8. Desempenho........................................................................................................ 5 1.9. Transparência...................................................................................................... 6

Página 1 de 6

1. Aspectos gerais de um projecto de sistemas distribuído (que devem ser considerados)

1.1. Heterogeneidade • Capacidade do SD ser utilizado com diversos tipos de redes, hardware, sistema

operacional, linguagem de programação e implementação.

o Redes: utilização de protocolos que são utilizados em diversos tipos de

redes (Por exemplo, a comunicação na Internet é realizada através de

protocolos da Internet).

o Hardware: diferentes arquitecturas representam tipos de dados de formas

diferentes (Por exemplo, representação do inteiro apresentam "byte

orderings" diferentes em arquitecturas diferentes).

o Sistema operacional: as APIs (Appication Programming Interface –

Interface de Programação de Aplicativos) dos sistemas operacionais

existentes para os protocolos da Internet podem ser bem diferentes (Por

exemplo, chamadas para troca de mensagens UNIX versus Windows).

o Linguagem de Programação: as linguagens possuem diferentes

representações para as suas estruturas de dados (Por exemplo, tipo char

nas linguagens Java e ANSI C)

o Implementação: implementações realizadas por programadores diferentes

necessitam respeitar um padrão comum para representação das

mensagens, a fim de que seja possível a comunicação entre os processos.

(Por exemplo, Web Servers e browsers)

o Middleware: camada de software que provê uma abstracção na

programação, pois "mascara" a heterogeneidade do sistema. Por exemplo,

Java RMI.

o Código-móvel: código que é enviado a outro computador e executado no

destino. Por exemplo, Java Applets.

Página 2 de 6

1.2. Flexibilidade o Possibilidade de estender e/ou reimplementar um sistema possibilitando a

inclusão de novos serviços

o Necessidade de documentação, utilização de padrões, interfaces abertas,

documentos técnicos

o Acordo entre desenvolvedores

o Permite a integração de sistemas desenvolvidos por vendedores diferentes

seguindo um padrão

o Permitir implementação de novo serviço (futuro)

1.3. Segurança o Baseado no "valor" das informações/recursos aos usuários.

o Componentes:

Confidencialidade: protecção contra acesso de pessoas não

autorizadas

Integridade: protecção contra alterações, corrupção

Disponibilidade: protecção contra interferência no acesso

Utilização de técnicas de criptografia para garantir a identificação

do emissor/receptor.

o Outros desafios:

DOS (denial of service attack): ataque que tem como objetivo tirar

um serviço do ar "bombardeando-o" com requisições.

Segurança em código-móvel: execução de programas impróprios;

pode abrir brechas para invasão (vírus).

1.4. Escalabilidade o Capacidade de um sistema continuar operando após o aumento do número

de recursos e/ou usuários.

o Prevê que o custo de adição de um usuário seja proporcional a adição de

recursos

Página 3 de 6

1.5. Confiabilidade o O SD deve ser projectado para aumentar a confiabilidade do sistema

utilizando de forma adequada os recursos disponíveis

o A existência de diversos recursos não garante a confiabilidade em um SD

o Falha – defeito mecânico ou algorítmico que pode gerar um erro

ocasionando a falha do sistema

fail-stop: após a falha o sistema para de funcionar

Byzantine: após a falha o sistema gera resultados incorrectos (mais

complicado para tratar!)

o SD deve ser projectado para

Evitar falhas: minimizar falhas

Utilização de componentes altamente confiáveis (testes)

Tolerar falhas: sistema continua operando corretamente, mesmo

com menor desempenho, após uma falha parcial

• Técnicas de redundância: replicação de componentes

• Mecanismos de controle distribuído: servidores

independentes provendo o mesmo serviço

• Objetivo principal: evitar ponto único de falha!

Detectar e recuperar falhas: existem diversas técnicas para tornar a

recuperação de falhas mais simples:

• Transacções atómicas: colecção de operações indivisíveis,

isto é, tudo acontece ou nada acontece

• Servidores stateless: servidor não armazena informações

históricas sobre as operações dos clientes

• Acknowledgements e retransmissões baseadas em timeout:

o Detecção de perda de mensagens (timeout para

receber ack) e retransmissão; é necessário um

mecanismo de detecção e tratamento de mensagens

duplicadas

Página 4 de 6

1.6. Disponibilidade o Fracção de tempo no qual o sistema distribuído está disponível para ser

utilizado. Por exemplo:

4 Servidores – disponibilidade 95% cada

Probabilidade dos 4 estarem parados

• 0.054 = 0.000006

• Probabilidade de pelo menos 1 estar disponível 1 – (0.054)

= 0.999994

Exercício: 1 servidor – disponibilidade 75%. Quantos servidores

para disponibilidade de pelo menos 99%?

1.7. Concorrência o Possibilidade de diversos clientes acederem simultaneamente um serviço

ou recurso em um SD.

o Serviços e aplicações aceitam diversos usuários por vez, e devem garantir

que os recursos compartilhados sejam operados correctamente no

ambiente concorrente.

o Sincronização de estruturas de dados e objectos

1.8. Desempenho o O sistema deve ter maior desempenho do que se executado em uma única

máquina.

o Utilização de métricas de desempenho

o Benchmarks – são testes padronizados que são usados para medir a

performance de diferentes processadores em tipos específicos de

aplicação. Tipicamente, os benchmarks medem a performance em tarefas

como: produtividade, Internet, codificação de vídeo e edição de imagens,

jogos e processamento intensivo.

Página 5 de 6

1.9. Transparência Existem cinco tipos de transparência em sistemas distribuídos:

1. Transparência à localização – os usuários não devem saber onde os recursos se

encontram;

2. Transparência à replicação – os usuários não devem saber quantas cópias existem;

3. Transparência à concorrência – vários usuários podem compartilhar

automaticamente os recursos; e

4. Transparência ao paralelismo – podem ocorrer actividades paralelas sem que os

usuários venham a saber.

Página 6 de 6