Sistemas Distribuidos

Prévia do material em texto

CIÊNCIA DA COMPUTAÇÃO
SISTEMAS DISTRIBUIDOS 
Mach e Amoeba
MACH
O projeto Mach é originário da Universidade Carnegie-Mellon e tem como base um sistema chamado RIG (Rochester Intelligent Gateway) da Universidade de Rochester em 1975. Na sua primeira versão (1986) o Mach foi desenvolvido para um VAX 11/784 com 4 processadores, sendo compatível com UNIX. Embora tivesse facilidades de rede nesta época o Mach foi concebido para uma única máquina ou multiprocessador ao invés de um sistema operacional distribuído para uma coleção de máquinas em uma LAN. Em 1988, a versão Mach 2.5 era grande e monolítica devido a quantidade de código Unix Berkeley no kernel, este código foi removido do kernel e colocado em espaço de usuário. A partir daí o que permaneceu foi um microkernel Mach 3, e um emulador BSD Unix.
As principais metas do sistema Mach são as seguintes: 
1. Prover uma base para construção de outros sistemas operacionais: para suportar emulação binária do UNIX e outros SO’s, o Mach permite redirecionamento de chamadas de SO para uma biblioteca de emulação que depois são enviadas para servidores de SO no nível de usuário. 
2. Suporte de espaços de endereçamento esparsos e grandes. 
3. Permitir acesso transparente aos recursos de rede: para suportar programas distribuídos, Mach adota um modelo de comunicação independente de localização a partir da utilização de portas. Entretanto, todo o tratamento de rede fica a cargo dos servidores de rede que ficam no nível de usuário. 
4. Explorar paralelismo a nível de sistema e de aplicação: Mach foi projetado para executar em multiprocessador de forma que tantos threads do kernel quanto de usuário poderiam executar em qualquer processador. 
5. Possibilitar portabilidade para grande coleção de máquinas: código dependente de máquina foi isolado tanto quanto possível. Por exemplo, código que trata de memória virtual foi dividido em parte independente e parte dependente de máquina.
Como outros microkernels, o Mach kernel, é composto por serviços de gerência de processos, gerência de memória, comunicação e de E/S. Sistema de arquivos e outras funções de SO são tratados no espaço de usuário. A ideia é fornecer os mecanismos necessários para que o sistema funcione, deixando para o nível de usuário as políticas. O kernel é responsável por 5 principais abstrações: 
1. Processos – Um processo Mach (task) é um ambiente de execução e é composto de um espaço de endereçamento protegido e uma coleção de capacidades, gerenciadas pelo kernel, usadas para acessar portas. 
2. Threads – Processos podem conter vários threads, sendo que threads de um mesmo processo podem executar em paralelo em um multiprocessador. 
3. Objetos de memória – Cada região de um espaço de endereçamento virtual de um processo Mach corresponde a um objeto de memória. Operações como busca e armazenamento de dados são parte destes objetos. 
4. Portas – Uma porta em Mach é um canal de comunicação unicast e unidirecional com uma fila associada.
5. Mensagens – Uma mensagem no Mach pode conter além de dados, direitos de acesso a portas (capabilities). O kernel utiliza técnicas de gerência de memória para transferir dados de forma eficiente entre os processos (tasks).
O Mach identifica recursos individuais com portas (ports). Para acessar um recurso, é necessário enviar uma mensagem para a porta correspondente. Os servidores em geral gerenciam várias portas, uma para cada recurso. Por exemplo, um servidor UNIX utiliza cerca de 2000 portas. Proteger um recurso de acessos ilegais é comparado a proteger uma porta de envios ilegais. 
Para conseguir tratar com estes problemas no Mach, o kernel controla a aquisição das capacidades para as portas e também o servidor de rede controla as mensagens que chegam na rede. A capacidade para uma porta tem um campo que especifica os direitos de acesso da porta pertencentes ao processo que de posse da mesma. Os direitos de acesso das portas Fila de execu çã o local 0 3 1 Count: 6 H int: 3 Fila de execu çã o global 0 3 1 Livre Count: 8 H int: 4 84 podem ser: 
1) direito de envio, permite enviar mensagens para a porta correspondente; 
2) direito de 1 envio, permite apenas 1 envio depois anula os direitos; 
3) direito de recepção, permite a recepção de mensagens da porta correspondente (pelo menos 1 processo). As comunicações no Mach são do tipo N-para-1. 
Os direitos de acesso a portas são conseguidos pelos (threads) processos a partir da criação de portas ou recebendo direitos enviados por mensagens (exeção bootstrap port). Direitos de acesso a portas no Mach são armazenados e protegidos pelo kernel. 
Os processos referem-se a direitos de portas através de identificadores locais que são válidos apenas no espaço de nomes de porta local. Isto permite (implementadores do kernel) a escolha de representações eficientes para estas capacidades (apontador para filas de mensagens) e a escolha de nomes locais convenientes para o kernel procurar a capacidade pelo nome. 
Na verdade, assim como descritores de arquivos do UNIX, identificadores locais são inteiros usados para indexar uma tabela do kernel contendo as capacidades do processo. O esquema de nomeação e proteção do Mach permite rápido acesso a filas locais de mensagens a partir de um identificador de nível de usuário. 
Para isto, é preciso que o kernel processe quaisquer direitos transmitidos em mensagens entre processos. No mínimo, associar nomes locais e espaço nas tabelas do kernel a direitos de envio. Além disto, em um ambiente seguro, a transmissão de direitos de acesso a portas requer alguma forma de criptografia para se proteger contra formas de ataque a segurança.
AMOEBA
O sistema Amoeba é originário da Universidade de Vrije em Amsterdam em um projeto de pesquisa em computação paralela e distribuída em 1981 ( Andrew S. Tanenbaum e estudantes de doutorado). Várias versões foram desenvolvidas desde então.
A abordagem do projeto Amoeba foi diferente de outros projetos em sistemas operacionais distribuídos, adicionar novas características a sistemas existentes (rede, sistema de arquivos compartilhado) para torná-los mais distribuídos. 
O Amoeba optou por desenvolver o sistema desde o zero sem se importar com compatibilidade e usando ideias novas para sua implementação. A meta importante do projeto era construir um sistema operacional distribuído transparente, ou seja, o usuário usa o Amoeba como se fosse um sistema operacional timesharing tradicional, a diferença é que as ações realizadas pelo sistema envolvem a participação de várias máquinas, incluindo servidores de processos, servidores de arquivos, servidores de diretórios, etc, sem que o usuário saiba disto. 
No Amoeba não existe o conceito de máquina própria, ou seja, quando o usuário entra ele o faz no sistema como um todo e não em uma máquina específica. Todos os recursos pertencem ao sistema como um todo e são gerenciados desta forma. Uma segunda meta do sistema é fornecer um ambiente apropriado para programação paralela e distribuída.
Como metas básicas de projeto o Amoeba apresenta: 
1. Transparência de Rede – Todos os acessos a recursos devem ser transparentes de rede. Em particular, a existência de um sistema de arquivos para o sistema como um todo, e os processos executam em processadores escolhidos pelo sistema sem o conhecimento do usuário. 
2. Gerência de recursos baseado em Objetos – O sistema foi projetado para ser baseado em objetos. Cada recurso é considerado como um objeto e todos os objetos, independente do seu tipo, são acessados por um esquema de nomes uniforme. Os objetos são gerenciados por um servidor e o acesso a eles é feito enviando mensagens para os servidores, mesmo localmente. 
3. Servidores a nível de usuário – O sistema foi construído, tanto quanto possível, como uma coleção de servidores executando, no nível de usuário, em cima de um microkernel padrão que roda em todas as máquinas do sistema. Atenção particular foi dada ao problema de proteção, o microkerneldo Amoeba utiliza um modelo uniforme para acesso aos recursos através de capacidades.
O Amoeba foi projetado com duas asserções em mente: 
1) Os sistemas terão um grande número de CPUs e, 
2) Cada CPU terá dezenas de megabytes de memória. Provavelmente, no futuro, a maioria das instalações será compatível com estas asserções. 
A idéia da arquitetura do sistema é suportar a necessidade de incorporar um grande número de CPUs de uma forma não complexa. Suponha que você possa prover para 67 cada usuário um sistema multiprocessador com 10 ou 100 processadores, o que você faria? Provavelmente a solução seria dar um destes sistemas para cada usuário. 
Entretanto, talvez esta não seria a melhor forma e nem efetiva de gastar o orçamento, principalmente porque a maior parte do tempo os processadores estariam ociosos para a maioria dos usuários, enquanto que alguns precisariam executar programas necessitando um grande poder computacional.
O modelo de software adotado pelo Amoeba apresenta duas partes fundamentais: o microkernel, que executa em cada processador e uma coleção de servidores que fornecem a maioria das funções tradicionais de um sistema operacional.
O microkernel Amoeba executa em todas as máquinas do sistema (conjunto de processadores, terminal ou servidor). As funções básicas do microkernel são: 
1. Gerenciamento de processos e threads 
2. Fornecer suporte para gerenciamento de memória (alocação/lib segmentos) 
3. Suporte a comunicação (ponto a ponto, em grupo) 
4. Tratamento de I/O de baixo nível ( device driver)
Gerência de processos no Amoeba Um processo no Amoeba é basicamente um espaço de endereçamento e uma coleção de threads que executam neste espaço. 
Processos. Um processo é um objeto no Amoeba. Quando um processo é criado, o processo pai recebe uma capacidade para o filho. Através desta capacidade, o filho pode ser suspenso, reiniciado, sinalizado e destruído. 
A criação de processos no Amoeba é diferente do UNIX (muito overhead, FORK, EXEC) e é mais parecido com o MS-DOS (com a imagem de memória que se quer desde o início) só que é permitido ao processo pai continuar em paralelo com o filho e assim por diante. 
O gerenciamento de processos é tratado em 3 níveis: 
- Servidores de processos (nível mais baixo): são threads do kernel que executam em cada uma das máquinas. Para criar um processo em uma determinada máquina, outro processo executa um RPC com o servidor de processos da máquina desejada e fornece as informações necessárias. 
- Conjunto de procedimentos de biblioteca que fornecem uma interface mais conveniente para programas de usuário. 
- Servidor de execução que é a maneira mais simples para criar um processo, utilizado para realizar a maior parte do trabalho na determinação de onde executar um novo processo. 
As chamadas de gerenciamento de processos utilizam uma estrutura de dados chamada descritor de processo para fornecer informações sobre o processo a executar. Esta estrutura está descrita a seguir. Um campo do descritor fornece informação sobre que arquitetura (x86, Sparc, etc) o processo pode executar. 
Outro campo contém a capacidade do dono do processo, quando o processo termina esta capacidade é usada para fazer RPCs informando o evento. O descritor também inclui descritores para todos os segmentos do processo que juntos formam o espaço de endereçamento do mesmo, assim como descritores para as todas as threads do processo. O descritor de thread, dependente de arquitetura, contém no mínimo o PC e o SP. 
Os procedimentos importantes da interface de baixo nível dos processos incluem exec, getload, stun. O primeiro procedimento tem 2 parâmetros, a capacidade do processo servidor e um descritor de processo, sua função é realizar um RPC com o processo servidor especificado pedindo para o mesmo executar o processo. Se a chamada é completada com sucesso, uma capacidade para o novo processo é retornada para o chamador. O segundo procedimento retorna informações a respeito da velocidade da CPU, carga atual e quantidade de memória livre, é usado pelo servidor de execução para determinar o melhor lugar para executar um processo novo. 
O terceiro procedimento pode ser usado pelo pai de um processo para suspende-lo tirando-lhe a consciência. Existem duas formas de stun : normal e emergência. A diferença básica diz respeito ao que acontece se o processo está bloqueado em 1 ou mais RPCs. No normal, o processo envia uma mensagem para o servidor que ele está esperando para informar o evento (eu preciso que termine o trabalho e me envie uma resposta). Na emergência, o processo é parado instantaneamente.
 REFERÊNCIAS
(TAN95) TANENBAUM, Andrew S.. Sistemas operacionais modernos. Rio de Janeiro: Prentice-Hall do Brasil, 1995.
SISTEMA OPERACIONAL DISTRIBUIDO MACH
Disponível em: https://es.wikipedia.org/wiki/Mach_(n%C3%BAcleo)
SISTEMA OPERACIONAL DISTRIBUÍDO AMOEBA
Disponível em: http://www.inf.ufrgs.br/gppd/disc/cmp134/trabs/T1/991/Amoeba/index.htm