SMARIO 1 INTRODUO..................................................................................................... 2 DESENVOLVIMENTO......................................................................................... 2.1 HISTRICO DO AMOEBA............................................................................... 2.2 O QUE UM SISTEMA DISTRIBUDO?......................................................... 2.3 POR QUE SISTEMA DISTRIBUIDOR?............................................................

. 2.4 OBJETIVOS DA PESQUISA............................................................................ 2.5 INTERFACE PROGRAMADO/USURIO......................................................... 2.6 GERNCIA DE PROCESSOS......................................................................... 2.7 GERENCIADOR DE MEMRIA....................................................................... 2.8 CARACTERSTICAS PARTICULARES............................................................ 2.8.1 Rede.............................................................................................................. 2.8.2 Grfica........................................................................................................... 2.9 RAZES PARA ADERIR O SISTEMA OPERACIONAL AMOEBA.................. 2.10 RAZES PARA ABANDONAR O SISTEMA OPERACIONAL AMOEBA....... 2.11 RESUMINDO.................................................................................................. CONCLUSO......................................................................................................... REFERNCIAS...................................................................................................... 3 4 4 5 5 5 6 9 10 10 10 11 12 12 12 13 14

1 INTRODUO A partir dos anos oitenta, os preos tornaram-se mais acessveis ao ponto que possibilitar que cada usurio possa ter o seu prprio computador. Hoje em dia alguns sistemas tm muitos processadores por usurio, ou na forma de um computador paralelo ou uma grande coleo de CPUs , compartilhada por uma pequena comunidade de usurios. Geralmente estes sistemas so chamados de sistemas paralelos ou de sistemas distribudos. Este desenvolvimento eleva a pergunta de que tipo de software ser necessrio para estas novos sistemas e que caractersticas eles deveram apresentar.

2 DESENVOLVIMENTO 2.1 HISTRICO DO AMOEBA Segundo conceito dos desenvolvedores do projeto em AMOEBA (2008), Amoeba um sistema operacional distribudo de propsito geral. Foi desenvolvido para agregar diversas mquinas e faz-las agir como um nico sistema integrado. Em linhas gerais, os usurios no se do conta de quantos ou onde ficam localizados os processadores que executam seus comandos, nem mesmo o nmero ou localizao dos servidores de arquivos que armazenam seus arquivos. Aos olhos do usurio final, parece-se com um sistema comum de compartilhamento de tempo. Sistema desenvolvido na Universidade Vrije, em Amsterdam, iniciou seu projeto em 1981, primeiramente na rea de computao paralela. Teve como seus criadores, Tanenbaum, A.S., Kaashoek, F., Mullender, S.J. e Renesse, R.. Seu prottipo em 1983 ganhou a verso 1.0. J em sua verso 3.0, baseada em RPCs (Remote Procedure Calls), implementou o primeiro projeto de um sistema distribudo a atingir uma grande regio da Europa. Com essa mesma verso foi possvel a comunicao entre duas cidades remotas, de forma transparente, como um verdadeiro sistema distribudo. Ao contrrio da maioria das iniciativas da poca, segundo Tanenbaum (1995), o Amoeba no foi desenvolvido sobre um core UNIX, nem sobre nenhum outro. O princpio do desenvolvimento do Amoeba era alcanar um sistema operacional livre de qualquer plataforma. Ao passar do tempo, adquiriu por convenincia algumas caractersticas de um pacote de emulao UNIX. Segundo os projetistas, o AMOEBA atualmente visa os seguintes objetivos: - distribuio: conectar diversas mquinas, remotamente localizadas - paralelismo: permitir que tarefas individuais sejam executadas por mais de um processador. - transparncia: Fazendo parecer ao usurio final, que existe apenas um computador por traz de todo o trabalho. - performance: Atingir todos os objetivos descritos acima, de uma maneira eficiente.

2.2 O QUE UM SISTEMA DISTRIBUDO? Um sistema distribudo uma coleo de computadores independentes que parecem um sistema nico para o usurio (TANENBAUM, 1995).

2.3 POR QUE SISTEMA DISTRIBUIDOR? - Melhoria de Tecnologias. - Redes de Computadores de alta velocidade. - Conectar vrios computadores para resolver um problema.

2.4 OBJETIVOS DA PESQUISA Uma metodologia diferente foi adotada no projeto do Amoeba, ao contrario de outros sistemas, ele comeou do zero, e desenvolveu um novo sistema. A idia bsica era experimentar novos conceitos, sem compromisso de compatibilidade com qualquer outro sistema j existente (TANENBAUM, 1995). O principal objetivo, era a construo de um sistema operacional distribudo, totalmente transparente (TANENBAUM, 1995 e TANENBAUM, 1998). Aps efetuar o seu login no sistema, ele pode editar e compilar, mover arquivos, e por a vai. A diferena que cada uma dessas aes utiliza diversas mquinas da rede, incluindo servidores de processos, servidores de arquivo, de diretrio, etc, sem que o usurio tenha de se preocupar. Uma diferena importante enter o Amoeba e a maioria dos demais sistemas operacionais distribudos reside no fato de o Amoeba no suportar o conceito de "maquina hospedeira" (TANENBAUM, 1995). O objetivo secundrio do Amoeba fornecer um ambiente de teste para experincias em programao paralela e em programao distribuda. O Amoeba aceita dois tipos de usurios. Os que utilizam o sistema da mesma forma que fariam com um sistema tradicional de compartilhamento de tempo, e outros interessados

em experincias com algoritmos distribudos e algoritmos paralelos (TANENBAUM, 1995). 2.5 INTERFACE PROGRAMADO/USURIO conveniente, antes de descrevermos a estrutura do Amoeba, termos uma viso geral do tipo de hardware para o qual foi projetado. O sistema foi projetado segundo as duas seguintes premissa a respeito do hardware: - Os sistemas so compostos por um grande nmero de processadores. - Cada processador est equipado com dezenas de megabytes de memria. A fora motriz por trs da arquitetura do sistema a necessidade de incorporar um grande nmero de processadores ao sistema de uma forma simples, isto , fazendo com que o processamento ocorra de forma distribuda (TANENBAUM, 1995). O Amoeba baseou-se no modelo da Figura 1. Neste modelo todo o poder computacional est localizado em um ou mais grupo de processadores (processor pool), que se compe de um nmero substancial de processadores cada um com sua memria loca e sua conexo a rede, sendo que os processadores de um grupo podem pertencerem a diferentes arquiteturas (TANENBAUM, 1995 e TANENBAUM, 1998), por exemplo num mesmo grupo pode ter processadores baseados no 68030, no VAX, no 386 e no SPARC. Ele foi projetado para trabalhar com mltiplas arquiteturas e com sistemas heterogneos. O sistema possibilitar que filhos de um nico processo rodem em arquiteturas diferentes (TANENBAUM, 1995 e TANENBAUM, 1998). Os processadores de um grupo no pertencem a ningum. Quando digitado um comando, o sistema operacional aloca dinamicamente tantos quantos processadores forem necessrios para executar tal comando, aps o termino da execuo, os processadores so liberados, retornando ao grupo original, espera da prxima alocao (TANENBAUM, 1995 e TANENBAUM, 1998). Se houver escassez de processadores no sistema, os processadores dos grupos podero ser alocados em regime de tempo compartilhado, alocando-se novos processos aos processadores com menos carga de trabalho (TANENBAUM, 1995 e SINHA, 1997).

Outro componente fundamental da configurao do sistema constitudo pelos servidores especializados, como servidores de arquivos, de diretrios e outros, responsveis pelo fornecimento de servios (TANENBAUM, 1995 e SINHA, 1997). FIGURA 1 - PRINCIPAIS COMPONENTES DA ARQUITETURA DO SISTEMA AMOEBA

FONTE: TANENBAUM, A. S.,GREGORY J. S. The Amoeba Distributed Operating System. 1998. Disponvel em <www.cs.unc.edu/~sharma/professional/papers/amoeba/ amoeba.html>. Acessado em: 07 set. 2008.

O Amoeba e um sistema baseado em objetos, no qual o software inteiro est estruturado como objeto (TANENBAUM, 1995). Sendo que um objeto um conjunto de dados encapsulados, sobre os quais so realizadas certas operaes muito bem definidas. O objeto em sua essncia um tipo abstrato de dados. Os objetos Amoeba so passivos, no tendo nenhuma entidade capaz de "fazer" que coisas aconteam (TANENBAUM, 1995 e TANENBAUM, 1998). Ao contrrio, cada objeto gerenciado por um processo servidor (TANENBAUM, 1995). Para realizar uma operao sobre determinado objeto, o cliente deve executar uma chamada remota a procedimento para um servidor, especificando o objeto, a operao a ser realizada, e caso queira, alguns parmetros que julgue necessrio. O servidor faz o trabalho requisitando e retorna a resposta ao cliente, as operaes so realizadas de forma sncrona (TANENBAUM, 1995). Os usurios no precisam se preocupar com o aspecto relativo a localizao dos objetos que tiverem usando, a to pouco com os servidores que manipulam tais objetos, somente quando julgarem necessrio podem determinar o local onde os objetos sero armazenados.

Cada objetos em Amoeba identificados e protegidos da mesma forma, por uma capacidade (TANENBAUM, 1995). Para criar um objeto, o usurio deve fazer uma chamada remota a procedimento com o servidor apropriado, especificando tudo o que ele deseja. O servidor cria ento o objeto e retorna uma capacidade ao usurio. Nas operaes seguintes, o usurio precisa apenas apresentar a capacidade para identificar o objeto. A capacidade um nmero binrio usado para identificar e proteger um objeto (TANENBAUM, 1995). No Amoeba 5.0 o seu formato o seguinte, mostrado na figura 2. FIGURA 2 CAPACIDADE NO AMOEBA N de Bits Campos 48 Porta do Servidor 24 Numero do Objeto 8 Direitos 48 Verificao

FONTE: TANENBAUM, A. S. Distributed operating systems. New Jersey: Prentice Hall, 1995.

Quando um usurio deseja realizar uma operao sobre um objeto, ele deve chamar um procedimento stub, que vai construir uma mensagem que contenha a capacidade do objeto e interromper o kernel. Este extrai da capacidade o campo porta do servidor, e procura em sua cache a identidade da mquina onde reside tal servidor. Se no houver informaes sobre essa porta armazenada na cache, a identidade da mquina localizada por broadcast. A porta efetivamente um endereo lgico onde se pode encontrar um servidor. Portas de servidores so ento associadas a um servidor particular (ou a um conjunto e servidores), e no a uma mquina em especfico. Se um servidor se transferir para outra mquina, levar consigo sua porta. As demais informaes da capacidade so ignoradas pelo kernel, e passadas ao servidor (TANENBAUM, 1995): Porta de Servidor: A porta um endereo lgico com 48 bit, que identifica o servidor que administra o objeto referido pela capacidade, no so associados a uma mquina em particular, sendo assim se um servidor se transferir para outra mquina, levar consigo sua porta. Objeto: usado pelo servidor para identificar o objeto especfico em questo, possibilitando que um servidor de arquivos possa gernciar milhares de arquivos, que so identificados pelo nome do objeto. Direitos: um mapa de bit que informa as operaes que o detentor da capacidade pode realizar.

Verificao: usada na verificao da capacidade. As capacidades so manipuladas diretamente por processos de usurios, no havendo forma de proteo, no h como se evitarem falsificaes de capacidades (TANENBAUM, 1995 e TANENBAUM, 1998). 2.6 GERNCIA DE PROCESSOS Processo nada mais do que um espao de endereamento e um conjunto de uma ou mais linhas de controle (threads) que rodam nesse espao normalmente em paralelo, no Amoeba isto nada mais do que um objeto. A gerncia de processos no Amoeba e manipulada em trs diferentes nveis (TANENBAUM, 1995 e TANENBAUM, 1990). No nvel mais baixo, encontra-se os servidores de processos, que so linhas de controle do servidor rodando em cada uma das mquinas. Para criar um processo em determinada mquina, um outro processo executa uma chamada remota a procedimento para a mquina com o servidor de processo, fornecendo-lhe todas as informaes necessrias criao do processo. No nvel seguinte, existe um conjunto de procedimentos de bibliotecas que apresentam aos programas de usurio uma interface mais conveniente, onde os programas de usurios podem fazer seu trabalho atravs de chamadas a procedimentos de interface de baixo nvel. O prximo nvel a forma mais simples de criar um processo com o auxlio do servidor de processamento, que realiza a maior parte do trabalho de determinar onde rodar o novo processo. As linhas de controle (threads) no Amoeba, na inicializao de um processo existe no mnimo uma ou mais, podendo ser criadas novas linhas durante a execuo do processo e tambm podem ser finalizadas. Quando da sua criao, os parmetros para a chamada especificam o procedimento as ser executado e o tamanho de sua pilha de execuo, mesmo que todas as linhas de controle compartilhem cdigo e dados globais, cada uma tem sua prpria pilha e seu apontador e tambm uma cpia dos registradores da mquina. So usados trs mtodos para as linhas de controle se sincronizem: sinais, variveis mutex e semforos. Os sinais so interrupes assncronas enviadas de uma linha de controle para outra, do mesmo processo, e eles podem ser elevados, capturados ou ignorados. As variveis de mutex, so idnticas a um semforo binrio, podendo

assumir dois estados bloqueados e desbloqueado. A terceira e ltima forma de comunicao entre linhas so os semforos, so mais lentos que as variveis mutex, mas em determinadas ocasies so necessrios. O gerenciamento das linhas de controle e realizado pelo kernel, tendo como conseqncia deste gerenciamento, quando uma linha de controle executa uma chamada remota a procedimento, o kernel pode bloquea-la e escalonar uma outra dentro do prprio processo, caso haja alguma pronta para execuo, o escalonamento realizado usando prioridades, tendo as linhas do kernel sempre prioridade maior que as linhas de controle de usurios (TANENBAUM, 1995).

2.7 GERENCIADOR DE MEMRIA A memria do amoeba esta baseada em segmentos de tamanho varivel, um espao de endereamento virtual composto por um conjunto de segmentos, eles podem ser mapeados para o disco ou para a memria principal. Cada segmento e controlado por uma capacidade, um processo que remoto que tenha a capacidade para segmento de outros processos pode ler e escrever nesses segmentos partir que qualquer outra mquina. O Amoeba no suporta paginao por demanda, isto , quando um processo est rodando todos os seus segmentos devem estar na memria. O sistema tambm suporta compartilhamento de memria distribuda, os objetos compartilhados so replicados em todas mquinas que os utilizam. Os objetos porem ser de qualquer tamanho e podem suportar qualquer operao, sendo que as leituras so feitas localmente e as escritas feitas com o uso de protocolo de broadcat confivel do Amoeba.

2.8 CARACTERSTICAS PARTICULARES 2.8.1 Rede O principal objetivo era construo de um sistema operacional distribudo, totalmente transparente.

10

Aps efetuar o seu login no sistema ele pode editar e compilar, mover, arquivar e por ai vai. A diferena que cada uma dessas aes utiliza diversas mquinas da Rede, incluindo servidores de processos, servidores de arquivo, de diretrio, etc., sem que o usurio tenha de se preocupar. Uma diferena importante a se ater, o Amoeba e a maioria dos demais sistemas operacionais distribudos reside no fato de o Amoeba no suportar o conceito de mquina hospedeira O amoeba no suporta o conceito de mquina hospedeira. Quando um usurio se loga no Amoeba, ele no visto pelo sistema como uma mquina especfica, pois as mquinas Amoeba no tem dono. O shell inicia, ativado quando do login, roda em alguma mquina arbitrria, mas os comandos submetidos ao shell, em geral, no rodam na mesma mquina que ele. Quando h submisso de um comando, o sistema procura automaticamente a mquina com menor carga de trabalho corrente e lhe entrega a execuo do novo comando. Os processos que rodam sob determinado usurio, sero distribudos de maneira mais ou menos uniforme por todas as mquinas do sistema, dependendo naturalmente da carga de cada uma delas. Todos os recursos pertencem ao sistema como um todo, so gerenciados por ele. Os recursos estaro a disposio de processos individuais, salvo por certos intervalos de tempo. Tentando implementar a transparncia. O objetivo secundrio do Amoeba fornecer um ambiente de teste para experincias em programao paralela e em programao distribuda. Enquanto muitos usurios utilizam o Amoeba da mesma forma que fariam com um sistema tradicional de compartilhamento de tempo, outros esto especialmente interessados em experincias com algoritmos distribudos e algoritmos paralelos, usando linguagens, ferramentas e aplicaes voltadas para tais fins. O amoeba aceita esses dois tipos de usurios, tornando o paralelismo disponvel a quem queira fazer uso dele. 2.8.2 Grfica Os principais componentes que fazem parte da arquitetura do software do sistema Amoeba, so as seguintes: Microkernel: um modulo bsico que roda em todos os processadores do sistema Amoeba, provendo apoio de administrao de memria de baixo nvel, gerenciamento de processos e linhas de controle, suporte a comunicao entre

11

processos

manipulao

das

entradas/sadas

(TANENBAUM,

1995

TANENBAUM, 1990). Servidores: um conjunto de procedimentos stub, definidos em linguagem C, e mais recentemente em AIL (Amoeba Interface Language), colocados na biblioteca, permitindo que clientes os utilizem. Alguns servidores so padro no Amoeba como os servidor bala, que gerncia o armazenamento as informaes, servidor de diretrio, que trata da identificao de arquivos e da gerncia dos diretrios, e o servidor de replicao, que resolve a questo da replicao de arquivos (TANENBAUM, 1995).

2.9 RAZES PARA ADERIR O SISTEMA OPERACIONAL AMOEBA - Compartilhamento de dados; - Compartilhamento de perifricos; - Economia; - Comunicao; - Correio Eletrnico; - Flexibilidade; - Melhor aproveitamento dos Recursos.

2.10 RAZES PARA ABANDONAR O SISTEMA OPERACIONAL AMOEBA - Desvantagem do Sistema Distribudo; - Pouco Software disponvel; - A rede pode causar problemas; - Falta de segurana.

2.11 RESUMINDO Amoeba um Sistema Operacional distribuda baseado em Microkernel e de cdigo aberto, criado por Andreu S. Tanenbaum e outros na Univerdidade Vrize na

12

Holanda. O objetivo do projeto era construir um sistema operacional de tempo

compartilhado que fizesse um conjunto de computadores em rede comportar-se como uma nica ao usurio. CONCLUSO O sistema Amoeba, tem demonstrado que possvel construir um sistema operacional distribudo, eficiente de alto desempenho em hardware atual. Fazendo o Kernel to pequeno quanto possvel, sendo a maioria das caractersticas chaves so implementados como processos de usurios, o que significa que o sistema pode evoluir gradualmente conforme a necessidade. O Amoeba tem operado durante vrios anos satisfatoriamente e apresentado um bom desempenho, segundo seus autores, e como todo o sistema operacional nunca est totalmente pronto, ele tambm est em constante evoluo.

13

REFERNCIAS AMOEBA. Release Notes. Disponvel em: manuals/rel.pdf>. Acessado em: 07 set. 2008. <http://www.cs.vu.nl/pub/amoeba/

TANENBAUM, A. S., Robbert van Renesse, Hans van Staveren, Gregory J. Sharp. Experience with the The Amoeba Distributed Operating System. 1990. Disponvel em < http://www.cs.vu.nl/vakgroepen/cs/amoeba_papers.html > Acessado em: 07 set. 2008. TANENBAUM, A. S. Distributed operating systems. New Jersey: Prentice Hall, 1995. TANENBAUM, A. S.,GREGORY J. S. The Amoeba Distributed Operating System. 1998. Disponvel em <www.cs.unc.edu/~sharma/professional/papers/amoeba/ amoeba.html>. Acessado em: 07 set. 2008. SINHA, Pradeep K.. Distributed operating systems concept and desing. New York: IEEE, 1997.