Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira.

Transcrição

1 Período letivo: 4 Semestre. Quinzena: 5ª. Faculdades Santa Cruz - Inove Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Unidade Curricular Sistemas Distribuídos Processos No plano de aula anterior, nos concentramos na comunicação em sistemas distribuídos. Para organizar eficientemente sistemas cliente-servidor, é freqüentemente conveniente fazer uso de técnicas multithread. Como discutimos no primeiro plano de aula, as organizações cliente-servidor são importantes em sistemas distribuídos. Um assunto importante, especialmente em sistemas distribuídos através de grandes distâncias geográficas, é mover processos entre máquinas diferentes. Threads Embora os processos sejam os tijolos da construção de sistemas distribuídos, a prática indica que a granularidade de processos como fornecidos pelos sistemas operacionais sobre os quais os sistemas distribuídos são construídos, não é suficiente. A partir de agora, daremos uma olhada mais de perto no papel das threads em sistemas distribuídos e explanaremos porque elas são tão importantes. Introdução às threads Para compreender o papel das threads em sistemas distribuídos, é importante entender o que é um processo, e como processos e threads se relacionam. Para executar um programa, um sistema operacional cria um certo número de processadores virtuais, cada um para executar um programa diferente; para controlar esses processadores virtuais, o sistema operacional tem uma tabela de processos, contendo entradas para armazenar os valores de registradores da CPU, os arquivos abertos, os privilégios, etc; um processo é freqüentemente definido como um programa em execução, um programa que está correntemente sendo executado em um dos processadores virtuais do sistema operacional. Uma thread é muito similar a um processo no sentido de que ela também pode ser vista como a execução de um (pedaço de um) programa em um processador virtual. A proteção de dados contra acesso inapropriado por outras threads dentro do mesmo processo é deixada inteiramente para os desenvolvedores da aplicação. Infelizmente, a prática corrente não demonstra que esse princípio seja suficientemente bem compreendido.

2 Uso de threads em sistemas não distribuídos Implementação de threads Threads em Sistemas Distribuídos Uma propriedade importante das threads é que elas podem fornecer um meio conveniente de permitir chamadas de sistema bloqueantes sem bloquear o processo inteiro no qual a thread está executando. Ilustraremos este ponto dando uma olhada mais de perto em clientes e servidores multithread, respectivamente. Clientes multithread Para estabelecer um alto grau de transparência na distribuição, os sistemas distribuídos que operam em redes através de grandes distâncias geográficas podem precisar tratar longos tempos de propagação das mensagens entre processos. A forma usual de esconder as latências da comunicação é iniciar a comunicação e imediatamente proceder à execução de alguma outra atividade. Um navegador Web freqüentemente começa buscando a página HTML e subseqüentemente exibindo-a. Para esconder as latências da comunicação ao máximo possível, alguns navegadores começam a exibir os dados assim que eles vão chegando; dessa forma, parece que o navegador Web está fazendo várias tarefas simultaneamente. Existe um outro benefício importante em usar navegadores Web multithread nos quais várias conexões podem ser abertas simultaneamente.

3 Os servidores Web costumam ser replicados em múltiplas máquinas; quando uma requisição de uma página Web chega, freqüentemente é utilizada uma estratégia de rodízio ou alguma outra técnica de balanceamento de carga. Esta abordagem é possível apenas se o cliente puder lidar verdadeiramente com fluxos paralelos de dados entrantes; threads são ideais para esse propósito. Servidores multithread Clientes Nos planos de aula anteriores discutimos o modelo cliente-servidor, os papéis de clientes e servidores, e as formas como eles interagem. A partir de agora discutiremos a anatomia dos clientes. Interfaces de usuário A mais importante tarefa da maioria dos clientes é interagir com um usuário humano e um servidor remoto. Uma classe importante é formada pelas interfaces gráficas de usuário. A partir de agora, daremos uma olhada mais de perto no sistema X-window como um exemplo de uma interface gráfica de usuário mais tradicional.

4 O sistema X-Window

5 Atividade Prática Pesquisa e orientação quanto ao trabalho da primeira atividade prática valendo nota do segundo bimestre.

6 Servidores Agora vamos examinar mais de perto a organização de servidores. Nas seções seguintes, primeiro vamos nos concentrar em várias questões gerais de projeto para servidores, seguidas de uma discussão de clusters de servidores. Questões gerais de projeto

7 Clusters de servidores Na primeira quinzena discutimos brevemente cluster de computadores como uma das muitas formas de apresentação de sistemas distribuídos. Agora vamos examinar mais de perto a organização de clusters de servidores com questões relevantes de projeto. Organização geral

8 Servidores distribuídos Gerenciamento de clusters de servidores Um cluster de servidores deve se apresentar ao mundo exterior como um único computador, como muitas vezes é, de fato, o caso. Contudo, quando se trata de gerenciar um cluster, a situação muda drasticamente. Várias tentativas foram feitas para facilitar o gerenciamento de clusters de servidores, como discutirmos a seguir. Abordagens comuns De longe, a abordagem mais comum para o gerenciamento de um cluster de servidores é estender as tradicionais funções de gerenciamento de um único computador para um cluster. Em sua forma mais primitiva, isso significa que um administrador pode se registrar em um nó com base em um cliente remoto e executar comandos locais de gerenciamento para monitorar, instalar e trocar componentes. Um pouco mais avançado é ocultar o fato de que você precisa se registrar em um nó e, em vez disso, fornecer uma interface em uma máquina administradora que permita colher informações de um mais servidores, atualizar componentes, adicionar e remover nós, etc. Contudo, tão logo os clusters cresçam e passem de várias dezenas de nós, esse tipo de gerenciamento não serve mais. Ocorre que suporte para clusters de servidores muito grandes é quase sempre ad hoc. O gerenciamento de cluster ainda está em sua infância, embora seja de esperar que chegará a hora em que soluções de auto-gerenciamento como as discutidas na quinzena anterior avançarão nessa área, após ganharmos mais experiência com elas.

9 Exemplo: PlanetLab Há várias questões que fazem do gerenciamento do PlanetLab um problema especial; três evidentes são: 1. Nós pertencem a diferentes organizações. 2. Há várias ferramentas de monitoração disponíveis, mas todas elas admitem uma combinação muito específica de hardware e software. 3. Programas de fatias diferentes, mas que executam no mesmo nó, não devem interferir um com o outro.

10 Atividade Prática Entrega do artigo da primeira atividade prática valendo nota do segundo bimestre.