View
225
Download
0
Category
Preview:
Citation preview
Prof. Luiz Fernando Bittencourt IC - UNICAMP
MC714 Sistemas Distribuídos 2° semestre, 2013
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas descentralizadas • Arquiteturas multidivididas: conseqüência da divisão de
aplicação em interface/processamento/dados. • Em muitos ambientes, organização de aplicações cliente-
servidor é feita em arquiteturas multidivididas: distribuição vertical. • Componentes logicamente diferentes em máquinas diferentes. • Relação com fragmentação vertical: tabelas de BD subdivididas
em colunas e distribuídas. • Divisão lógica e física: cada máquina executa grupo específico de
funções • Distribuição horizontal
• Servidor/cliente divididos em partes logicamente equivalentes. • Cada parte operando sobre seu próprio conjunto de dados. • Distribuição de carga.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas descentralizadas • Peer-to-peer (P2P): distribuição horizontal. • Não há servidor sempre ligado. • Sistemas finais comunicam-se diretamente. • Peers intermitentemente conectados e mudam de
endereço. • Ex: distribuição de arquivos (bitTorrent), streaming
(KanKan), VoIP (Skype).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cliente servidor versus P2P • Quanto tempo para distribuir arquivo de tamanho F para
N clientes: cliente-servidor versus P2P. • Fig. 37. • Cliente-servidor: envia sequencialmente N cópias.
• Servidor: • tempo para enviar 1 cópia: F/us • tempo para enviar N cópias: NF/us
• Cliente: cada cliente faz o download • dmin = taxa de download mínima entre os clientes. • Tempo de download do cliente mais lento: F/dmin
Tempo para distribuir F para N clientes usando
cliente-servidor Dc-s > max{NF/us,,F/dmin}
Aumenta linearmente em N
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cliente servidor versus P2P • P2P:
• Servidor: upload de pelo menos uma cópia – tempo F/us • Cliente: cada cliente faz o download de uma cópia
• Tempo de download do cliente mais lento: F/dmin
• Clientes: download agregado de NF bits • Taxa máxima de upload: us + Σui
Tempo para distribuir F para N clientes usando
P2P DP2P > max{F/us,,F/dmin,,NF/(us + Σui)}
Aumentam linearmente em N
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Cliente servidor versus P2P • Upload cliente = u, F/u = 1 hora, us = 10u, dmin ≥ us
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
Min
imum
Dis
tribu
tion
Tim
e P2PClient-Server
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas descentralizadas • Peer-to-peer (P2P): distribuição horizontal. • Processos que constituem o sistema são todos iguais.
• Funções necessárias são executadas por todos. • Interação simétrica: cliente e servidor ao mesmo tempo.
• Como organizar os peers? Rede de sobreposição (overlay). • Nós são processos; enlaces são canais de comunicação lógicos. • Em geral, processo não pode se comunicar diretamente com outro
processo arbitrário: deve obedecer overlay. • Redes de sobreposição: estruturadas e não estruturadas.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas descentralizadas • Arquiteturas P2P estruturadas:
• Rede de sobreposição é construída com a utilização de um procedimento determinístico.
• Mais utilizado: tabela hash distribuída (distributed hash table – DHT).
• Ex.: Chord, CAN, Pastry, Tapestry
• Arquiteturas P2P não estruturadas: • Algoritmos aleatorizados para construir a rede de sobreposição. • Idéia é que cada nó mantenha lista de vizinhos, mas que essa lista
seja construída de modo que envolva alguma aleatorização. • Localização de item pode depender de inundação da rede.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas P2P estruturadas • Rede de sobreposição construída com procedimento
determinístico. • Mais comum: Distributed Hash Table (DHT) • Itens de dados recebem identificador (128, 160 bits...). • Nós do sistema também recebem identificador, no mesmo
espaço de identificadores. • Ponto crucial: implementar um esquema eficiente e
determinístico de mapeamento de chaves para identificadores de nós.
• Consulta a um item deve retornar o endereço do nó responsável pelo item.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas P2P estruturadas • Como atribuir chaves aos peers? • Idéia básica:
• Converter cada chave em um inteiro. • Atribuir inteiro a cada peer. • Colocar par (chave, valor) no peer mais próximo à chave.
• Atribuir identificador inteiro para cada peer no intervalo [0,2n-1] para algum n. • Cada identificador de nó tem n bits.
• Requer que cada chave esteja no mesmo intervalo. • Para obter chave, usar função hash.
• Ex.: chave = hash (“Pink Floyd – Dark Side of the Moon”). • Daí vem o nome de tabela hash distribuída.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Chord (Stoica et al., 2003) • Nós organizados logicamente em um anel - DHT circular. • Regra: atribuir chave ao peer com ID mais próximo. • Item de dado com chave k mapeado em nó com menor
identificador id >= k. • Denominado nó sucessor da chave k: suc(k).
• Consulta: Lookup(k) deve retornar endereço de suc(k). • Cada peer conhece sucessor e predecessor imediatos
em uma rede de sobreposição. • Fig. 38. • Outras: CAN, Pastry, Tapestry, Kademlia, Ulysses, Koorde
(grafos de DeBruijn)
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Chord (Stoica et al., 2003)
• O(N) mensagens na média para resolver consulta.
0001
0011
0100
0101
1010
1100
1111
Responsável pela chave 1110 ?
Eu
1110
1110
1110
1110
1110
1110
Prof. Luiz Fernando Bittencourt IC - UNICAMP
DHT Circular com atalhos
• Cada peer conhece sucessor, predecessor e atalhos. • Redução de 6 para 2 mensagens. • É possível desenhar atalhos para que existam O(log(n))
vizinhos, O(log(n)) mensagens em consultas.
1
3
4
5
8 10
12
15
Responsável pela chave 1110?
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Peer churn • Peers entram e saem da rede (churn). • Cada peer conhece seus dois sucessores. • Cada peer “pinga” seus dois sucessores para verificar se
continuam online. • Se o sucessor imediato sai, realoca segundo sucessor
como imediato.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Peer churn • Peer 5 sai. • Peer 4 transforma 8 em seu sucessor imediato e pergunta ao 8 qual
é seu sucessor. • Peer 4 torna sucessor de 8 (10) seu segundo sucessor.
1
3
4
5
8 10
12
15
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Peer churn • Peer 13 quer entrar: gera um identificador (aleatório) id. • Consulta algum nó qual ponto da rede deve entrar: quem será seu
sucessor e predecessor. • Transferência das responsabilidades de dados de 15 para 13.
1
3
4 13
8 10
12
15
Prof. Luiz Fernando Bittencourt IC - UNICAMP
CAN – Content Addressable Network • Espaço de coordenadas cartesianas de d dimensões
particionado entre os nós. • Fig 48. • Espaço bidimensional [0,1]x[0,1] dividido entre 6 nós. • Cada nó tem uma região associada. • Cada item de dados em CAN é atribuído um único ponto
desse espaço, vinculando um nó responsável pelo dado.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
CAN – Content Addressable Network • Entrada de um nó P em CAN:
• Escolhe ponto arbitrário no espaço de coordenadas; • Pesquisa o nó Q “dono” daquela região (utilizando roteamento
baseado em posicionamento); • Nó Q subdivide sua região em duas metades e atribui metade a P;
• Nós monitoram seus vizinhos, responsáveis por regiões adjacentes.
• Na subdivisão, P sabe quem são seus vizinhos perguntado a Q.
• Itens de dados são transferidos de Q para P. • Fig. 49
Prof. Luiz Fernando Bittencourt IC - UNICAMP
CAN – Content Addressable Network • Saída de nó de CAN:
• Saída do nó (0,6; 0,7). • Região é designada a um de seus vizinhos, por exemplo (0,9; 0,9). • Vizinho escolhido toma conta da região do nó que saiu. • Torna repartição menos simétrica: repartição do espaço inteiro por
um processo de fundo.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Redes P2P não estruturadas • Dependem, em grande parte, de algoritmos aleatórios para construir overlay.
• Idéia: cada nó tem uma lista de vizinhos construída de modo (mais ou menos) aleatório.
• Itens podem ser colocados aleatoriamente nos nós – Balls and bins.
• Encontrar item = inundar a rede com consulta de busca.
• Rede parecida com grafo aleatório. • Ex.: Gnutella, Freenet
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Redes P2P não estruturadas • Cada nó mantém uma lista de vizinhos vivos (visão parcial).
• Nós podem trocar regularmente entradas de suas visões parciais.
• Pode-se usar 2 threads, uma de “modo ativo” (push) e uma de “modo passivo” (pull). • Modo ativo: empurra entradas para peers vizinhos
selecionados. • Modo passivo: aguarda nó enviar as entradas.
• Só ativo ou só passivo pode resultar em redes desconexas.
• É preciso também apagar entradas velhas.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Redes P2P não estruturadas • Pull ou push isoladamente podem resultar em redes desconectadas. • Melhor que nós troquem entradas de suas visões parciais.
• Nó quer se juntar ao grupo: contata nó arbitrário, possivelmente de lista de nós bem conhecidos e com alta disponibilidade.
• Saída de nó, caso haja troca de visões parciais: nó sai sem informar qualquer nó. É removido das visões parciais dos seus vizinhos na próxima atualização.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Redes P2P não estruturadas
Prof. Luiz Fernando Bittencourt IC - UNICAMP
• Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Redes P2P não estruturadas
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Gerenciamento de topologia • Estruturado e não estruturado podem não ser estritamente independentes.
• Troca e seleção cuidadosa de entradas de visões parciais pode levar a topologias específicas.
• Adoção de abordagem de duas camadas. • Fig 50. Camada inferior: p2p não estruturado com troca de visões parciais.
• Camada superior: seleção adicional de entradas para gerar topologia desejada.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Gerenciamento de topologia • Por exemplo, camada superior: função de ordenação onde nós são ordenados de acordo com certo critério. • Ordenar conjunto de nós em ordem crescente de distância em
relação a um determinado nó P. • Nó P gradativamente montará uma lista de seus vizinhos mais
próximos, desde que a camada inferior continue enviando nós selecionados aleatoriamente.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Gerenciamento de topologia • Jelasity e Babaoglu [2005]. • Grade lógica NxN, um nó em cada ponto. • Lista de c vizinhos mais próximos por nó, onde distância
entre nó (a1,a2) e (b1,b2) é d1+d2, com di = min (N-|ai-bi|, |ai – bi|).
• Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Redes P2P não estruturadas • Podem ser usadas funções de ordenação de diversas maneiras.
• Ex.: funções com captura de proximidade semântica de nós.
• Construção de redes semânticas de sobreposição. • Algoritmos de busca eficientes em P2P não
estruturados.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Superpeers • Busca em P2P não estruturado pode ser ineficiente e não escalável. • Não há modo determinístico de rotear requisições: inundação.
• Alternativa é usar superpares. • Nós especiais que mantém um índice de itens de dados
e/ou agem como intermediários
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Superpeers • Há outras situações em que convém abandonar simetria de sistemas P2P. • Rede colaborativa de entrega de conteúdo (Content Delivery
Network – CDN) - armazenamento de páginas por nós para permitir acesso rápido a páginas próximas.
• Nó que coleta informações sobre nós das proximidades permite seleção de quem tem recursos suficientes para armazenar conteúdo acessado.
• Nós como os que mantêm um índice, ou agem como intermediários, em geral são denominados super-pares (superpeers).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Superpeers • Superpares podem ser organizados em uma rede P2P à organização hierárquica.
• Fig. 39. • Par comum conectado a superpar. • Relação cliente-superpar fixa, em geral: conecta-se a um superpar e permanece até sair da rede. • Superpares: longa vida com alta disponibilidade.
• Associação fixa pode não ser melhor abordagem • Melhor cliente se ligar a um superpar com índices que sejam
próximos ao seu interesse. • Garbacki et al. (2005) à nós associam-se preferencialmente a
superpares que retornam um resultado de consulta para o nó.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Superpeers • Novo problema: como selecionar nós para serem superpares.
• Estreita relação com eleição de líder em sistemas distribuídos.
• Exemplo: Skype/NAT
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas híbridas • Combinam mais de um tipo de arquitetura, por ex. cliente-servidor e P2P
• Exemplo: sistemas de servidor de borda • “Borda da rede” – fronteira entre as redes corporativas e a Internet,
como fornecido por um provedor de serviço de Internet (ISP). • Fig. 51. • Servem conteúdo e otimizam distribuição de conteúdo e de
aplicação.
• Também comum em sistemas distribuídos colaborativos. • Cliente-servidor utilizado para nós conectarem-se ao sistema,
depois utilizam esquema descentralizado.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas híbridas • Ex.: BitTorrent – sistema de download de arquivos.
• Fig. 40. • Transfere pedaços (chunks - 256kb) de arquivos até completar o arquivo.
• Importante garantir colaboração. • Usuário acessa diretório global – sites web – referências aos arquivos torrent.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
BitTorrent • Torrent contém informações sobre rastreador (tracker). • Servidor que mantém lista de nós ativos que tem o arquivo
requisitado. • Ativo = transferindo algum arquivo para outro nó.
• Peer entrando em um torrent: • Não possui pedaços, mas obtém com o tempo. • Recebe do rastreador lista de peers daquele torrent e se conecta a
alguns (vizinhos). • Enquanto baixa, também faz upload. • Pode trocar os peers com quem realiza transferências. • Peer pode sair da rede assim que obtém arquivo inteiro.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
BitTorrent • Requisição de pedaços:
• Peers diferentes têm subconjuntos diferentes de pedaços. • Periodicamente, usuário requisita lista de pedaços de seus
vizinhos. • Em seguida, requisita pedaços faltantes de seus vizinhos – mais
raro primeiro.
• Enviando pedaços – “tit-for-tat” • Usuário envia pedaços a vizinhos que estão enviando a ele com a
maior taxa. • Outros peers param de receber dados desse usuário. • Re-avalia os “top 4” a cada 10 segundos.
• A cada 30 segundos seleciona aleatoriamente outro peer e começa a enviar pedaços. • “Desafoga” de forma otimista esse peer. • Novo peer pode se juntar ao “top 4”.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
BitTorrent • Versões atuais suportam DHTs
• Mainline DHT – baseado em Kademlia • rede “sem” trackers (ou com tracker distribuído).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas versus Middleware
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas versus Middleware • Middleware é uma camada entre aplicações e
plataformas distribuídas. • Proporcionar transparência de distribuição: ocultar das aplicações,
até certo ponto, a distribuição de dados, processamento e controle.
• Sistemas de middleware, na prática, adotam estilo arquitetônico específico. • CORBA – objetos • TIB/Rendezvous – eventos
• Simplifica o projeto de aplicações. • Por outro lado, pode não ser o ideal para determinada
aplicação.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas versus Middleware • CORBA oferecia somente objetos que podiam ser
invocados por clientes remotos. • Muito restritivo. • Foram adotados outros padrões de interação, como mensagens.
• Acrescentar características pode resultar em soluções inchadas. • Melhor ter soluções específicas adaptáveis a requisitos das
aplicações.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Arquiteturas versus Middleware • Middlewares simples de configurar, adaptar e
personalizar conforme necessidade da aplicação são desejáveis. • Sistemas atuais com separação mais estrita entre políticas e
mecanismos. • Vários mecanismos com os quais pode-se modificar
comportamento do middleware
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Interceptadores • Interceptadores: pedaço de software que interrompe o
fluxo de controle usual e permite que outro código seja executado.
• Idéia básica de invocação remota em SDs com objetos: • Objeto A pode chamar método de um objeto B quando este está
em uma máquina diferente de A. • Objeto A enxerga interface local que é a mesma oferecida por B;
objeto A chama essa interface local. • Chamada por A é transformada em invocação a objeto genérico
através de uma interface geral de invocação oferecida pelo middleware.
• Invocação do objeto genérico é transformada em mensagem, que é enviada pela interface de rede do sistema local de A.
• Fig. 52.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Interceptadores • Chamada B.faz_alguma_coisa(valor) é transformada em
uma chamada genérica invoke(B, &faz_alguma_coisa, valor).
• Se B for replicado, interceptação pode ajudar • Interceptador de nível de requisição. • Interceptador chama invoke para cada uma das réplicas. • A não precisa estar ciente da replicação de B. • Middleware não precisa de componentes para tratar da chamada
replicada. • Apenas o interceptador de nível de requisição, que pode ser
adicionado ao middleware, precisa saber da replicação de B.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Interceptadores • Após invoke, uma chamada a objeto remoto deverá ser
enviada pela rede. • Interface do sistema deve ser invocada para envio de mensagem. • Interceptador de nível de mensagem pode ajudar na transferência
da invocação ao objeto visado. • Ex.: valor é um conjunto grande de dados, melhor fragmentar. • Middleware não precisa estar ciente da fragmentação.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Software adaptativo • Interceptadores são na verdade um meio de adaptar o
middleware. • ambiente dinâmico (mobilidade, variância no QoS, problemas de
hardware, bateria) à necessidade de adaptação. • Peso da adaptação colocado no middleware ao invés de em toda
aplicação.
• Software adaptativo no middleware para tratar influências do ambiente. • Menos sucesso que o esperado. • Entretanto, considerado um aspecto importante em SDs
modernos.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Software adaptativo • Três técnicas para adaptação de software:
• Separação de interesses. • Reflexão computacional. • Projeto baseado em componente.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Software adaptativo • Separação de interesses:
• Modo tradicional de modularizar: separar partes que implementam funcionalidade das que cuidam de outras coisas (funcionalidades extras – confiabilidade, desempenho, segurança, etc.
• Middleware é em grande parte um manipulador de funcionalidades extras.
• Problema: não é fácil separar essas funcionalidades por meio de modularização. • Segurança em módulo separado não funciona. • Como isolar tolerância a falhas em serviço independente? • Software orientado a aspecto: separar e entrelaçar esses
interesses cruzados em um sistema distribuído.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Software adaptativo • Reflexão computacional:
• Capacidade de um programa inspecionar a si mesmo e, se necessário, adaptar seu comportamento.
• Embutida em linguagens de programação.
• Alguns middlewares oferecem meios para aplicar técnicas reflexivas.
• Assim como orientação a aspecto, ainda não é largamente implantado em sistemas distribuídos.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Software adaptativo • Projeto baseado em componentes:
• Permite que sistema seja configurado de forma estática ou em tempo de execução.
• Configuração dinâmica requer suporte a ligação tardia.
• Permite selecionar automaticamente melhor implementação de um componente em tempo de execução.
• Ainda complexo para sistemas distribuídos. • Substituição de um componente implica saber que efeito terá
sobre outros componentes distribuídos.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Software adaptativo • Busca continua por software adaptativo em SDs: não há
método ou implementação amplamente aceita. • Argumento para suportar software adaptativo em
sistemas distribuídos: muitos SDs não podem ser desligados. • SDs devem ser capazes de reagir a mudanças em seu ambiente,
como trocar dinamicamente políticas de alocação de recursos.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Autogerenciamento em Sistemas Distribuídos
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Autogerenciamento em SDs • Para suportar maior quantidade de aplicações, SDs
devem blindá-las aspectos indesejáveis das redes. • Necessidade de adaptação do comportamento (não de
seus componentes) de SDs em tempo de execução. • Organização dos componentes:
• Fazer monitoração. • Ajustes automáticos. • Decidir onde são executados processos que manipulam a
adaptação.
• Computação autonômica (ou sistemas auto): sistemas de realimentação de controle de alto nível que permitam adaptação automática a mudanças.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Autogerenciamento em SDs • Sistemas auto:
• Auto-gerenciador • Auto-reparador • Auto-configurador • Auto-otimizador
• Auto-gerenciador: termo genérico para englobar suas variantes.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Realimentação de controle • Existem diversas visões de sistemas auto-gerenciadores. • Em comum: adaptação ocorre através de um ou mais
laços de realimentação de controle. • Fig. 53. • Núcleo: componentes a serem gerenciados.
• Guiados por parâmetros de entrada que podem ser controlados. • Porém, podem também ser influenciados por perturbações ou
ruídos, i. e., entradas não controláveis. • Perturbações: frequentemente advindas do ambiente do SD, mas
podem vir de interações não previstas de componentes.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Realimentação de controle • Três elementos que formam o laço de realimentação de
controle. • 1. O sistema a ser monitorado
• Vários aspectos do sistema precisam ser medidos. • Dados: medição e estimação. Medição pode ser difícil ou pode
acarretar interferência na própria medição (p.ex. princípio da incerteza de Heisenberg / Gato de Schrödinger).
• 2. Componente de análise de realimentação • Analisa medições e as compara com valores de referência. • Algoritmos que decidem possíveis adaptações.
• 3. Mecanismos para influenciar o comportamento do sistema. • Colocação de réplicas, mudança de prioridade de escalonamento,
troca dinâmica de serviços, movimentação de dados, redirecionamento, etc.
• Acionados pelo componente de análise (este, ciente dos mecanismos e seus efeitos).
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Realimentação de controle • Obs: laço de realimentação de controle também se ajusta
ao gerenciamento manual. • Diferença é, justamente, a automatização do componente de
análise.
• De uma forma ou outra, precisa-se de monitoração decente, assim como mecanismos decentes para controlar comportamento do sistema.
• Algoritmos para análise dos dados e ações corretas são dificuldade no desenvolvimento de sistemas auto-gerenciadores.
• Organização lógica (Fig. 53) pode ser diferente da organização física. • Componente de análise pode ser distribuído, por exemplo. • Monitoração em cada máquina.
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Resumo
Prof. Luiz Fernando Bittencourt IC - UNICAMP
Resumo • Arquitetura de software e arquitetura de sistema
• Organização lógica • Organização física
• Estilo arquitetônico (software) • Princípio básico que é seguido na organização da interação entre
os componentes • Camadas, orientação a objetos, orientação a eventos, orientação a
espaço de dados
• Organização física • Cliente-servidor: certo grau de centralização. • Arquiteturas descentralizadas: P2P/rede de sobreposição
estruturada ou não estruturada. • Sistemas auto-gerenciadores: até certo ponto fundem idéias de
arquitetura de sistema e software. Laços de realimentação e controle e ajuste automático do comportamento.
Recommended