Apresentação

1. Apresentação Cap. 2 - Sistemas Distribuídos e Paralelos

2. Modelos de Sistemas • Um modelo de arquitetura de SD está preocupado com a localização das partes e o relacionamento entre elas. Os exemplos incluem os modelos de processos cliente/servidor e processos ponto a ponto. • Modelos fundamentais estão preocupados com a descrição mais formal das propriedades que são comuns à todos as arquiteturas. É discutidos três modelos fundamentais: • O modelo de interação, negocia com o desempenho e a dificuldade de ajuste de relógio limitado dos SD. Ex: Entrega de msg; • O modelo de falhas, dá uma especificação precisa de falhas que podem ser exibidas pelo processo e canais de comunicações; • O modelo de segurança, discute as possíveis ameaças para os processo e canais de comunicações. É introduzido o conceito de canal seguro.

3. Modelos de Sistemas • Sistemas que têm a intenção de serem usados no mundo real devem ser projetados para funcionar corretamente sob uma grande variedade de circunstâncias, problemas e ameaças possíveis. • Neste capítulo, estudaremos os modelos e suas principais propriedades. • O Sistema de Arquitetura são estruturados em termos de componentes especificados separadamente. Sempre tendo em vista a preocupação de garantir, confiabilidade, desempenho, segurança, gerenciamento a um custo razoável.

4. Modelos de Sistemas • Camadas de Software • Arquiteturade Software, era o termo utilizado para estrutura de camadas ou módulos de software para um único computador. Atualmente é utilizado para definir serviços oferecidos e requisitados entre processos localizados em um mesmo ou diferentes computadores.

5. Modelos de Sistemas • Camadas de Software • Conceito de Plataforma, é o termo utilizado para fazer referência de camadas de baixo nível de hardware e software que dão serviços a camadas superiores. • Normalmente, em termos de computadores, uma plataforma está relacionada ao tipo de arquitetura de processador e o sistema operacional utilizado. Ex: Intel/Windows, Intel/Linux, Sun/Sparc/SunOS, Intel/Solaris, PowerPC/MacOS, etc. • MIDDLEWARE, pode ser representado por processos ou objetos em um conjunto de computadores que interagem entre si para providenciar suporte para comunicação e compartilhamento de recursos para as aplicações distribuídas.

6. Modelos de Sistemas • Camadas de software • Em outras palavras, um Middleware em SD se preocupa em oferecer serviços de forma eficiente de comunicação e de compartilhamento de recursos, simplificando seu uso através da abstração da plataforma de baixo nível, oferecendo um modelo de comunicação em grupo, notificação de eventos, a replicação de dados compartilhados e transmissão de dados multimídia e tempo real. • RPC - Remote Procedure Calling, ou chamada de procedimentos remotos é o termo utilizado para definir o método utilizado por determinado Middleware para fazer chamadas de serviços oferecidos pelos processos ou objetos.

7. Modelos de Sistemas • Camadas de software • Um dos mais conhecidos Middleware que providencia serviços de acesso orientado a objetos é o CORBA - Common Object Request Broker Archicteture. • Outros: • Java-RMI, Java Remote Object Invocation; • DCOM, Microsoft’s Distributed Component Object Model e • RMODP (ISSO/ITU-T’s), Reference Model for Open Distributed Processing.

8. Modelos de Sistemas • Camadas de software • Problemas com o uso de Middleware: • Embora os Middleware tentem sempre oferecer transparência para os programadores, nem sempre isso é bom. • Algumas situações podem exigir que os problemas de comunicação, por exemplo, devam ser tratados no nível da aplicação. Ex: E-mail. • Outra situação é os Middleware o intuito de garantir confiabilidade, traz menos desempenho numa comunicação de rede. Ex: UDP vs TCP.

9. Modelos de Sistemas • Arquitetura de sistemas • Modelo Cliente-Servidor: • É a arquitetura mais comum e frequentemente utilizada como exemplo de SD; • Os processos clientes invocam serviços aos servidores. Neste modelo, um servidor pode se tornar um cliente para solicitar serviços de outro servidor.

10. Modelos de Sistemas • Arquitetura de sistemas • Ex: • Um servidor web pode se tornar um cliente para o sistema de arquivos do S.O, para os servidores DNS;

11. Modelos de Sistemas • Arquitetura de sistemas • Serviços providenciados por Múltiplos Servidores: • Nesta categoria, os serviços são implementados em vários servidores que interagem entre si para oferecerem os serviços solicitados pelos processos clientes. • Ex: Servidores Web, BDs, DNS e etc.

12. Modelos de Sistemas • Arquitetura de sistemas • Servidores Proxy e de Caches • A técnica de cache é recente, e é utilizada em servidores que mantêm cópias de dados solicitados anteriormente. Quando um cliente faz uma solicitação a um proxy, primeiro ele verifica se os dados estão presente localmente, caso contrário ele busca a informação efetivamente na rede. • Ex: Servidores de Proxy Web.

13. Modelos de Sistemas • Arquitetura de sistemas • Servidores Proxy e de Caches • A técnica de cache permite criar servidores Proxy Web, o que permite que dados em cache possam ser compartilhados para muitos clientes; • a técnica de cache pode ser inserida nos clientes, de modo que possa beneficiar as várias aplicações no acesso aos dados. • O propósito geral é garantir desempenho e disponibilidade de dados sem aumentar a carga ou tráfego na rede utilizada.

14. Modelos de Sistemas • Arquitetura de sistemas • Processo Ponto a Ponto • Nesta arquitetura todos os processo interagem com regras semelhantes. Trabalham de forma cooperativa para desempenhar atividades computacionais. Não há processo clientes ou servidoras. Cada processo mantêm controle de seus recursos e o modo de interação com outros processos. • Ex: games.

15. Modelos de Sistemas • Variações no modelo Cliente Servidor • Algumas variações deste modelo decorrem de razões listadas abaixo: • Uso de Códigos Móveis e Agentes Móveis; • Possibilidade de baixar cursos de recursos de hardware; • Flexibilidade para adicionar e remover dispositivos móveis.

16. Modelos de Sistemas • Variações no modelo Cliente Servidor • Códigos Móveis • Os applets são bom exemplo de códigos móveis. Seu funcionamento é baseado de modo a permitir que os códigos sejam transferidos do servidor Web para os browsers, onde são executados. • Vantagens: • Sem delay; • sem tráfego;

17. Modelos de Sistemas • Variações no modelo Cliente Servidor • Através de códigos móveis é possível oferecer serviços que não podem ser dado normalmente pela Web. • Ex: • Serviços de mensagens do tipo Push; • Atualização do relógio por parte do servidor; • HomeBrokers; • Interação automática com outros servidores.

18. Modelos de Sistemas • Variações no modelo Cliente Servidor • Agentes Móveis • São programas executáveis (códigos e dados) que trafegam de um computador ao outro para executar alguma tarefa. • Ex: Aplicações que necessitem coletar diversas informações em muitas máquinas. A vantagem é a redução do tráfego de rede, devido a redução de número de chamadas remotas por parte de códigos fixos; • Deve ter alta preocupação em relação a segurança. O Ambiente deve preocupar em como e quais recursos ele poderá dar aos códigos móveis. Por outro lado, os agentes tb podem sofrer problemas e não completarem duas tarefas, pois não conseguiram ter acesso autorizado aos recursos necessários.

19. Modelos de Sistemas • Variações no modelo Cliente Servidor • Computadores de Rede • “Network Computers” tem arquitetura baseado de modo que o sistema operacional, aplicativos e dados são sempre armazenados em servidores, porém sua execução é realizados nos computadores clientes. • A premissa é que o gerenciamento dos recursos é feita sempre pelos servidores, trazendo como vantagem a facilidade de utilização desses computadores por parte dos usuários, pois desta forma eles não tem que se preocupar com espaço em disco, atualização, instalação e remoção de aplicativos. • Outra vantagem é que os computadores de rede tem preço muito baixo, pois eles não precisam manter grande espaço em disco.

20. Compute server Network computer or PC Application network Thin Process Client Modelos de Sistemas • Variações no modelo Cliente Servidor • Thin Clients • O termo “thin Client” é o termo utilizado para fazer referência a uma arquitetura que providencia através de camada de software, suporte a uma interface gráfica aos aplicativos que estão sendo executados em um Servidor Remoto.

21. Modelos de Sistemas • Variações no modelo Cliente Servidor • Thin Clients • Características: • Os servidores devem ser poderosos, capazes de executar diversos processos em paralelo para atender inúmeros clientes; • Diferente da arquitetura de computadores de rede, os aplicativos são todos executados nos servidores; • Sua principal desvantagem é quando se utiliza aplicativos gráficos. Ex: CADs e processamento de imagens; • Exemplo de sistema: X11 (UNIX).

22. Modelos de Sistemas • Variações no modelo Cliente Servidor • Conexão espontânea • Trata de um conceito importante para utilização de dispositivos móveis. Ela se preocupa na forma como devem ser integrados os diversos dispositivos móveis com outros dispositivos não móveis com a infra-estrutura de rede disponível. • A idéia básica é oferecer facilidade de conexão de dispositivos para os usuários, de modo que eles não tenham que configurar ou instalar novos softwares para acessar um serviço.

23. Music service Alarm gateway service Internet Hotel wireless network Discovery service Camera TV/PC Guests Laptop PDA devices Modelos de Sistemas • Variações no modelo Cliente Servidor • Conexão espontânea

24. Modelos de Sistemas • Variações no modelo Cliente Servidor • Exemplo de Cenário para Conexão espontânea: • Providenciar facilidades no acesso de Serviços, tais como: • Serviços de Música; • Sistema de alarme; • Acesso a Web, via TV/PC; • Serviço de Impressão de Fotos via TV ou Impressora; • Controle Remoto via PDA, para controlar o ambiente; • Fax; • etc.

25. Modelos de Sistemas • Variações no modelo Cliente Servidor • Desafios para a Conexão espontânea: • Facilidade para conexão para Rede Local, deve permitir a capacidade de não ficar limitado a uma localidade; • Facilidade para integração e acesso aos serviços Locais, deve ter a capacidade de descobrir automaticamente quais serviços um determinado ambiente possui; • Conectividade Limitada, deve ter a capacidade de continuar trabalhando mesmo que a conexão seja interrompida momentaneamente; • Segurança e Privacidade, deve evitar que o ambiente e o usuário sejam atacados ou tenham sua privacidade invadida de alguma maneira.

26. Modelos de Sistemas • Variações no modelo Cliente Servidor • Descobrindo Serviços • A primeira idéia é colocar em um PDA ou outro dispositivo qualquer, um processo que monitora constantemente os ambientes que visita. Mas como garantir que os diferentes dispositivos se comuniquem adequadamente para que possam passar os serviços que o usuário realmente necessita?

27. Modelos de Sistemas • Variações no modelo Cliente Servidor • Descobrindo Serviços • O mecanismo de descoberta de serviços deve ter duas interfaces definidas: • Um serviço de Registro, para conseguir o aceite do acesso por parte do servidor e obter os serviços disponíveis no seu banco de dados; • Um Serviço de Pesquisa, para permitir acesso detalhado e padronizado aos dados através de um mecanismo definido de pesquisa; • Ex: Conseguir ver através do seu PDA, quantas TVs um apartamento tem e quais canais ele pode sintonizar;

28. Modelos de Sistemas • Modelos Fundamentais • Qualquer modelo de sistema por mais diferente que possa parecer, irá apresentar algumas propriedades fundamentais; • Todos eles são composto por processos que se comunicam entre si através da troca de mensagens pela rede. • Nesta seção estudaremos mais especificamente as propriedades fundamentais e os problemas relacionadas com falhas e riscos de segurança

29. Modelos de Sistemas • Modelos Fundamentais • Um modelo apresenta apenas as características básicas de um sistemas, normalmente ele deve responder as seguintes perguntas: • Quais são as principais entidades envolvidas; • Como eles se interagem; • Quê características podem afetar seus comportamentos individuais e coletivos? • Um propósito de qualquer modelo deve: • Fazer ser explicito toda as premissas relevantes sobre o sistema que está sendo modelado; • Fazer generalizações que sejam capazes de dizer o que é ou não é possível fazer com o modelo. Essa generalização garante a manter forma e as propriedades desejáveis para um modelo.

30. Modelos de Sistemas • Modelos Fundamentais • Saber com funciona um modelo é importante pois nos ajuda melhor a definir como nosso sistema deverá funcionar. Através do modelo é possível definir o que é possível e o que não é. • Além disso, um modelo permite abstrair os detalhes do hardware e software, apresentando apenas as propriedades mais importantes do sistema para uma análise.

31. Modelos de Sistemas • Modelos Fundamentais • A definição de um modelo de SD pode nos ajudar em verificar propriedades comuns, tais como: • Interação, A computação ocorre nos processos e os processos se comunicam-se através da troca de mensagem para coordenar suas ações. Desta forma, atrasos de comunicação podem atrapalhar a coordenação entre os processos. Dependendo da aplicação do SD, o nível de precisão de tempo será mais ou menos importante em um projeto. Neste sentido, um modelo pode ajudar na análise de qual modelo é mais adequado para o desenvolvimento de um SD. • Falhas, Uma falha ocorrida em qualquer das máquinas ou software que estão distribuído um sistema, pode ameaçar o funcionamento de um SD. Portanto, um modelo pode definir e até classificar os tipos de falhas que poderão ocorrer em seu sistema. • Segurança, Um SD pode sofrer ataques tanto de agentes externos como internos. Através de um modelo, é possível fazer uma análise das fragilidades e projetar um sistema resistente aos problemas conhecidos para cada modelo.

32. Modelos de Sistemas • Modelos Fundamentais • Modelo de Interação • O modelo de interação informa de que maneira é realizada a interação entre os processo com vista a complexidade que envolve um SD. • Essa complexidade envolve: • Trabalhar com algoritmos Distribuídos; • Delays na troca de mensagens; • Complexidade no acesso aos dados dos processo. • Há dois fatores significantes que afetam a interação entre processos em SDs: • Desempenho na Comunicação; • Impossibilidade de manter uma noção global de tempo sincronizado.

33. Modelos de Sistemas • Modelos Fundamentais • Canal de Desempenho de Comunicação • Um canal de comunicação pode ser implementado de várias formas: através de stream ou de simples pacotes de mensagens. • Normalmente um canal de comunicação enfrenta os seguintes e característicos problemas: • Latência; • Langura de Banda; • Jitter.

34. Modelos de Sistemas • Modelos Fundamentais • Latência: é o tempo levado por uma mensagem para sair do transmissor até chegar ao receptor. • A latência pode ocorrer por vários motivos, os principais são: • Da infra-estrutura de rede utilizada. Ex comunicação de satélites. A latência neste caso é o tempo levado pelo sinal de onda para chegar e retornar do satélite; • Do tipo da rede. Ex: A rede Ethernet trabalha com uma tecnologia que retarda o envio de mensagem quando há outras comunicações em andamento no meio compartilhado; • Atrasos no software. Ex: aplicativos, protocolos e S.O. precisam de tempo para processarem as informações antes de enviarem as informações.

35. Modelos de Sistemas • Modelos Fundamentais • Largura de Banda • Largura de banda é a quantidade de dados que pode ser transmitido em um dado tempo; • Em uma mesma rede, o aumento de canais acaba compartilhando a largura de banda, o efeito disso é a redução da quantidade de dados que é trafegado por canal; • Jitter • É a variação na taxa de entrega de dados durante uma transmissão de dados. Em outras palavras é a variação na velocidade de entrega de dados. Este parâmetro é importante para transmissões multimídia.

36. Modelos de Sistemas • Modelos Fundamentais • Relógio de CPU e sincronização de Eventos • Para tratar eventos entre processos é importante, por exemplo, determinar qual evento ocorreu primeiro. Mas a diferença existente entre os relógios dificulta bastante saber com que precisão de quando um evento ocorreu. • Todo computador tem um relógio que pode ser consultado pelas aplicações. Mesmo em SD cada processo pode fazer suas consultas locais para ver a hora. Porém, quando os processos fazem a consulta, sempre existirá um diferença de tempo entre computadores. Mesmo que você ajuste até o último picossegundo, os processos tenderão a apresentar diferenças ao longo do tempo devido a clock drift rate.

37. Modelos de Sistemas • Modelos Fundamentais • Clock Drift Rate • É a diferença apresentada por qualquer relógio real em relação a um relógio perfeito. O Clock Drift Rate define que qualquer relógio irá funcionar mais lento ou mais rápido de modo que ficará diferente do tempo real. • Alguns estudos mais promissores para tentar resolver este problema está sendo feito através da sincronização de tempo por GPS. Através de ondas de rádio, computadores podem possuir antenas de rádio para sincronizar com diferença de apenas 1 microsegundos. O único problema é o custo para equipar cada computador com GPS.

38. Modelos de Sistemas • Modelos Fundamentais • Duas variantes para o Modelo de Interação • Modelo de SD Síncrono; • Modelo de SD Assíncrono. • O Modelo de SD Síncrono • Foi definido pelo Hadzilacos e Touegs [1994] e apresenta um modelo onde segue alguns limites bem definidos: • Deve ser conhecido o tempo máximo e mínimo de execução de cada passo ou etapa de um processo; • Cada mensagens transmitida deve chegar em um tempo tolerável conhecido dentro do sistema; • Devemos conhecer o cada Clock Drift Rate dos processos envolvido no sistema.

39. Modelos de Sistemas • Modelos Fundamentais • Na prática é muito difícil definir os valores limites sugeridos em um SD síncrono. A menos que possamos garantir que os valores estipulado estejam corretos, qualquer projeto não teria a menor confiabilidade. • De qualquer forma, este modelo é útil para estudarmos como um SD síncrono deverá funcionar e verificarmos os desafios que serão enfrentadas para implementá-lo.

40. Modelos de Sistemas • Modelos Fundamentais • Os SD Assíncronos • Os SD assíncronos por sua vez apresentam um modelo muito comum no mundo real. Um bom exemplo é a Internet, onde diversos serviços úteis podem ser implementadas sem a necessidade de se preocupar muito com a sincronização e precisão de tempo entre processos. • Neste modelo não há limites definidos: • Os processos podem ter diferentes velocidades; • Permite que atrasos arbitrários possam ocorrer na transmissão de dados • Não se importa com os Drift rate dos processos.

41. Modelos de Sistemas • Modelos Fundamentais • Usando essa premissas de modelo SD assíncrono, é possível resolver muitos dos problemas do mundo real. • Desta forma, como exemplo, sistemas de FTP podem funcionar apesar dos atrasos na comunicação. Os e-mail podem ser entregues até com dias de atraso. O ponto é que permitem que as aplicações possam tratar os problemas inerentes de atraso e sincronização. • Ex: Um browser pode demorar bastante para apresentar uma página, porém ele permitirá que o usuário possa fazer outras coisas enquanto espera.

42. Modelos de Sistemas • Modelos Fundamentais • Uma das razões para que a maioria dos SD estejam utilizando o modelo assíncrono é devido a necessidade dos processo compartilharem os recursos. O que implica que os recursos tais como: CPUs e Redes de dados respondam cada vez mais devagar as solicitações à medida que aumenta o número de usuários. • Porém, este modelo não consegue atender bem as aplicações que requeiram executar a transmissão de dados multimídia em tempo real.

43. Modelos de Sistemas • Modelos Fundamentais • Ordenando Eventos • Em muitos casos é importante sabermos em que ordem ocorreram os eventos. Um exemplo interessante é quando um usuário X envia uma msg para os usuários Y, Z e A. Neste exemplo, Y recebe a mensagem e responde primeiro que os outros, mandando cópias para X e Z e A. Devido à atrasos na rede, o processo A poderá receber as mesg da seguinte forma:

44. Modelos de Sistemas • Modelos Fundamentais • Se considerarmos que os relógios, de alguma forma, estejam sincronizados, é fácil verificar qual mensagem foi enviado primeiro, bastando para isso verificar as horas em que foram enviadas. Mas como isso nem sempre é possível, existem outras técnicas que permitem descobrir utilizando apenas a lógica. • Conforme a figura, podemos verificar a ordem apenas usando a lógica: • X envia m1 antes de Y receber m1 • Y envia m2 antes de X receber m2

45. Modelos de Sistemas • Modelos Fundamentais • Conforme a figura, podemos verificar a ordem da seguinte forma: • X envia m1 antes de Y receber m1 • Y envia m2 antes de X receber m2 Sabemos também que as respostas são enviadas depois de receberem as mensagens, portanto nós temos a seguinte ordem lógica para Y: • Y recebe m1 antes enviar m2 Algumas deduções são possíveis para perceber quais ordem realmente as mensagem foram enviadas.

46. Modelos de Sistemas • Modelo de falhas • O modelo de falhas pode ser extremamente útil para nos ajudar a prever como as falhas poderão ocorrer em um dado sistema. • Hadzilacos e Toueg providenciaram uma taxonomia para classificar as várias formas de falhas que podem ocorrer nos processos e nas comunicações. Eles classificaram como: • falhas por omissão • falhas arbitrárias • falhas de sincronização

47. Modelos de Sistemas • Modelo de falhas • Falhas por omissão • As falhas por omissão são chamados assim quando os processos ou os canais de comunicações falham na execução das ações que eles deveriam desempenhar. • É dividido em: • Falhas por omissão do processo • Falhas por omissão da comunicação

48. Modelos de Sistemas • Modelo de falhas • Falhas por omissão do Processo • Uma das falhas mais conhecidas é a ocorrência do crash. Quando um sistema entra em crash, ele pára totalmente de desempenhar qualquer de suas funções, permanecendo assim por um tempo indeterminado. Em outras palavras, um sistema que sofre um crash não executa nenhuma atividade a mais;

49. Modelos de Sistemas • Modelo de falhas • Um crash é fácil de ser detectado em sistemas síncronos apenas verificando se o mesmo consegue responder antes de um time out especificado; • Mas em sistemas assíncronos, o fato de um processo externo não responder a uma eventual chamada não significa que este sistema esteja em crash. De fato, ele pode estar apenas sofrendo de um lentidão muito grande no envio de uma reposta; • Um processo em crash pode ser chamado de fail-stop se um processo externo for capaz de detectar seguramente que o sistema está totalmente parado. Ex: uso de timeout em sistemas síncronos com msg com entrega garantida.

50. Modelos de Sistemas • Modelo de falhas • Podemos identificar três tipos de falhas por omissão de comunicação: • Falha por omissão por perda de mensagem “dropping messages” , ocorre devido ao canal de comunicação que apresenta problemas no buffer de entradas de msg, erros de transmissão ou devido a problemas nos Gateways.