A apresentação do laboratório considerará os seguintes aspectos: Descrição do hardware utilizado
Descrição do Sistema Operacional utilizado
Descrição da configuração do Cluster Kerrighed implementada
Descrição dos aplicativos utilizados para análise do ambiente em cluster e standalone, de acordo com a proposta desse trabalho.
Descrição do hardware utilizado
Segue um esquema lógico do laboratório proposto:
165
Segue uma imagem dos equipamentos do laboratório:
166
Descrição dos itens que compõe o laboratório:
Switch Catalyst 3750E – 24 Portas 10/100/1000 e 2 Portas 10 Gigabit Ethernet Desempenho:
Capacidade de switching fabric – 160 Gbps Taxa de transmissão – 65,5 Mpps Principais funcionalidades: IEEE 802.1s IEEE 802.1w IEEE 802.1x IEEE 802.3ad IEEE 802.3af
IEEE 802.3x full duplex on 10BASE-T, 100BASE-TX e 1000BASE-T IEEE 802.1D Spanning Tree Protocol
IEEE 802.1p CoS Prioritization IEEE 802.1Q VLAN
IEEE 802.3 10BASE-T IEEE 802.3u 100BASE-TX IEEE 802.3ab 1000BASE-T IEEE 802.3z 1000BASE-X 100BASE-FX
1000BASE-T 1000BASE-SX 1000BASE-LX/LH
167
ComputadoresPara facilitar a identificação passaremos a designar os computadores utilizados no laboratório como Nó 00 e Nó 01 do cluster.
Nó 00
Processador Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
Memória 2075 MB
Sistema Operacional Debian GNU/Linux 5.0.4
Controladora de Disco Intel Corporation 82801GB/GR/GH
Disco ATA SAMSUNG HD322HJ
Kernel Linux 2.6.20-krg (i686)
168
Nó 01:
Processador Intel(R) Core(TM)2 CPU E7500 @ 2.93GHz
Memória 2334 MB
Sistema Operacional Debian GNU/Linux 5.0.4
Controladora de Disco Marvell Technology Group Ltd. 88SE6145 SATA II PCI-E controller
Disco Seagate Barracuda ST340014A 40GB
Kernel Linux 2.6.20-krg (i686)
Interface de Rede 2 x Broadcom Corporation NetXtreme BCM5700 Gigabit Ethernet
Descrição do Sistema Operacional utilizado
O Sistema Operacional utilizado é o Linux na distribuição Debian na versão do GNU/Linux 5.0.4 com kernel 2.6.20 modificado para suporte ao Kerrighed.
A escolha da distribuição Debian deu-se por a mesma ter uma melhor compatibilidade com Kerrighed e especialmente na instalação do mesmo. O Debian também se mostrou muito estável e resiliente durante a implementação e testes do cluster.
Seguem algumas características que contribuíram para escolha do Debian: É mantido por seus próprios usuários.
Se alguma funcionalidade precisa ser aperfeiçoada, a própria comunidade atua na melhoria.
Suporte eficiente pela própria comunidade.
Mensagens enviadas às listas de discussão frequentemente são respondidas em cerca 15 minutos.
169
Pacotes bem integrados
O Debian supera todas as outras distribuições no que se refere à qualidade de integração de seus pacotes. Já que todo software é organizado em grupos coerentes, não apenas pode-se encontrar todos os pacotes em um única fonte, mas pode-se assegurar de que já foram tratados os problemas no que tange às dependências complexas. Apesar de o formato deb ter algumas vantagens sobre o rpm , é a integração entre os pacotes que faz o sistema Debian mais robusto.
Código fonte
Quantidade significativa de ferramentas de desenvolvimento, facilitando a inclusão de funcionalidades ao sistema operacional.
Estabilidade
Os desenvolvedores do Debian afirmam que existe uma quantidade significativa de caso em que computadores executam a distribuição por um longo tempo, sem nenhuma indisponibilidade do sistema operacional. Pudemos verificar isso durante a implementação no laboratório.
Rápido e leve com a memória
Por ser baseado em GNU/Linux o Debian mostra-se confiável e leve no que concerne ao uso de memória.
Drivers para a maioria do hardware são escritos pelos usuários de GNU/Linux, não pelos fabricantes.
Embora se possa considerar como uma deficiência o tempo para que os novos dispositivos sejam suportados ou mesmo a falta de suporte para alguns deles, isso permite que o suporte ao hardware seja mantido até bem depois da parada de produção pelo fabricante ou da saída do mesmo do mercado. A experiência tem mostrado que drivers livres são normalmente melhores que os proprietários.
170
Descrição da configuração do Cluster Kerrighed implementada Histórico do Kerrighed
O projeto Kerrighed foi iniciado por Christine Morin19 em 1999 no INRIA, laboratório
nacional francês para pesquisa em ciência da computação. Até 2006, o projeto foi desenvolvido no INRIA (Institut National de Recherche en Informatique et en Automatique) como protótipo de pesquisa com pessoas do INRIA, EDF e Universidade de Rennes 1. Desde 2006, o Kerrighed é o fruto do projeto na comunidade PARIS, desenvolvido pelo Kerlabs, INRIA, parceiros do consórcio XtreemOS e um número crescente de colaboradores.
Instalação do Kerrighed
O Kerrighed foi instalado em dois nós através das instruções publicadas em www.kerrighed.org . Basicamente os fontes do Kerrighed e do kernel 2.6.20 são obtidos no GForge do INRIA, ambos são configurados e compilados. Os seguintes diretórios e arquivos precisam ser criados para que a instalação tenha sido exitosa: /boot/vmlinuz-2.6.20-krg kernel do Kerrighed
/boot/System.map Tabela de símbolos do kernel do Kerrighed /lib/modules/2.6.20-krg Módulos do Kerrighed
/etc/init.d/kerrighed Script de serviços do Kerrighed /etc/default/kerrighed Configuração de Serviços /usr/local/share/man Páginas Man
/usr/local/bin/krgadm Ferramenta de administração do cluster /usr/local/bin/krgcapset Ferramenta verificação de funcionalidades /usr/local/bin/krgcr-run Ativação checkpoint/restart dos processos /usr/local/bin/migrate Ferramenta de migração de processos /usr/local/lib/libkerrighed-* Biblioteca do Kerrighed
/usr/local/include/kerrighed Cabeçalhos da Biblioteca do Kerrighed Tabela 1
Depois da instalação basta editar o arquivo /etc/kerrighed.nodes para identificar ou ativar os nós dentro do cluster automaticamente no momento da inicialização.
19
Cientista Sênior do Rennes - Bretagne Atlantique. Líder do grupo de pesquisa Myriads. Co- fundadora do Kerlabs empresa criada para fornecer serviços comerciais na tecnologia Kerrighed. Coordenadora científica do projeto europeu do XtreemOS.
171
O Kerrighed cria uma nova imagem de sistema que pode ser escolhida no momento da inicialização do Linux.
Com o comando “krgadm” o cluster pode ser inicializado manualmente, podendo-se verificar se o mesmo está funcional e reconhecendo os nós.
Descrição dos aplicativos para testes PovRay
Uma atividade computacional intensa é a criação de imagens em três dimensões em computadores. As empresas cinematográficas têm usado cada vez mais esse recurso, seja para criar produções totalmente animadas digitalmente, seja para criar alguma imagem que seria dispendiosa ou mesmo impossível de ser gerada, utilizando a criação tradicional de cenários.
Apesar dos sistemas em cluster em geral não serem, via de regra, apropriados para execução aplicações em tempo real, como por exemplo, VoD ou IPTV, eles são muito utilizados nos processos de renderização de imagens, pois os mesmos necessitam de sistemas de grande poder de computação que podem ser provido pelos clusters. Iremos verificar se o Kerrighed apresenta bons resultados utilizando a aplicação de renderização de imagens PovRay (Persistence of Vision Ray Tracer) que é uma ferramenta com recursos interessantes, com uma baixa complexidade no manuseio e apresentando imagens de ótima qualidade em termos de cores, detalhes e iluminação, muito próximas de imagens reais.
O ray-tracing é um método de gerar imagens a partir de uma descrição geométrica de objetos. Ele é uma técnica de renderização que calcula uma imagem de alguma cena através da simulação de raios de luz que viajam no mundo real. Entretanto esse trabalho é feito de trás para frente. No mundo real a luz é emitida de uma fonte e ilumina os objetos. A luz reflete nos objetos e passa através de objetos transparentes. Essa luz refletida atinge nossos olhos ou a lente de uma câmera, por exemplo. Como a vasta maioria dos raios nunca atinge um observador, gerar uma cena desse modo levaria um enorme tempo.
172
Programas como o PovRay simulam os raios de luz saindo por detrás da cena. O usuário especifica a localização da câmera, as fontes de luz, os objetos, a textura das superfícies dos mesmos, seu interior (caso forem transparentes) e qualquer atmosfera como neblina, bruma ou fogo.
Para cada pixel da imagem final, um ou mais raios visíveis são disparados da câmera na cena, para verificar se eles interceptam algum objeto na mesma. Esses raios visíveis originados pelo observador, representados por uma câmera, passam através de um espaço visível, gerando a imagem final.
Em cada momento que um objeto é atingido, a cor da superfície do mesmo é calculada. Por esse motivo raios são enviados de trás para frente, de cada fonte luz para determinar a quantidade de luminosidade vinda dessas fontes. Raios representando sombras são gerados para determinar se o ponto está nas sombras ou não. Se a superfície é reflexiva ou transparente, novos raios são configurados e traçados para determinar a contribuição de luz refletida e refratada para cor final da superfície.
Para funcionalidades especiais como reflexão interdifusa, efeitos atmosféricos e áreas de luz, faz-se necessário disparar um número maior de raios na cena para cada pixel. Uma das verificações que serão realizadas no laboratório será a renderização de uma imagem e o consumo de tempo e recursos para realizar esse tipo de operação computacional.
Naturalmente existem outros métodos e ferramentas para renderização de imagens. Podemos mencionar como métodos rasterization e ray casting e como ferramentas “Mental Ray” e “RenderMan”.
Segundo os desenvolvedores do PovRay a versão 3.7 (Beta) já suporta de maneira nativa processamento paralelo. Iniciaremos o nosso laboratório com a versão 3.6 por ser a versão oficialmente consolidada.
Após fazer um download do arquivo binário do PovRay em www.PovRay.org basta seguir as instruções para instalação apresentada no mesmo WEB site.
173
Breve: Um ambiente 3D para Simulação de Sistemas Descentralizados e Vida Artificial O Breve é um ambiente em 3D destinado a simulação de sistemas descentralizados e de vida artificial. Enquanto ele é conceitualmente similar aos sistemas já existentes tais como o Swarn e o StarLogo, sua implementação, que simula tanto tempo contínuo e espaço contínuo em 3D, é significamente diferente dos sistemas citados, tanto que o ambiente do Breve é adequado para diferentes classes de simulações. O Breve inclui uma linguagem interpretada orientada a objeto, a OpenGL, dispositivo de detenção de colisão, suporte experimental para corpos físicos articulados e resolução de colisão com fricção estática e dinâmica. O principal objetivo desse sistema é permitir a implementação rápida e fácil de simulações descentralizadas ao mesmo tempo em que provê uma estrutura com muitos recursos que facilitam a construção de simulações de vida artificial avançadas.
O Breve é um ambiente integrado de simulação o qual objetiva simplificar grandemente a implementação de sistemas descentralizados e simulações avançadas de vida artificial. Ele é destinado tanto para usuários que não programam como usuários com experiência em linguagem de programação, bibliotecas e programas. As simulações do Breve são escritas numa linguagem simplificada orientada a objeto chamada steve. A linguagem steve, especialmente designada para simulações em 3D, incluem coletores de lixo (garbage collection), suporte a listas, vetores de 3D nativos assim como grupo de classes que fazem interface com funcionalidades de simulação do sistema central (engine) do Breve. Ele também oferece uma arquitetura de plugin simples com a qual os usuários podem estabelecer interfaces com bibliotecas externas ou linguagens, acessando as mesmas através do steve.
O steve é uma linguagem procedural e muitas de suas funcionalidades parecerão familiar aos usuários da linguagem C. A diferença é que a sintaxe do método de chamadas é mais parecida com o Objetive-C. No steve, cada argumento de um método de chamada é associado a uma palavra chave. Isso significa que os argumentos não são identificados por sua ordem, mas por suas palavras chaves. O fato de steve ser uma linguagem interpretada que retém muitos tipos de verificações e métodos de busca até o momento da execução do código, pode causar algum problema de desempenho, mas na prática, os gargalos das simulações do Breve estão mais relacionadas a simulação física e a renderização das imagens do que na execução do código do steve.
174
Classes hierárquicas gerais
A interação com as funcionalidades nativas do Breve é realizada da através de classes hierárquicas gerais. No topo dessa hierarquia temos a classe chamada Object que é o pai de todos os objetos criados no Breve. A hierarquia é dividida em classe Abstract e classe Real. A classe Abstract é definida como classes que não possuem uma representação física no mundo simulado, enquanto a classe Real está associada a alguns tipos de objetos físicos.
A classe Real inclui objetos móveis e os objetos estacionários. As funções dessas classes são simples: objetos móveis representam agentes que se movem durante o curso da simulação, enquanto os objetos estacionários representam entidades que são imóveis durante o curso da simulação, tais como o piso e obstáculos.
Os membros mais importantes da hierarquia Abstract são as classes Control e Data. A primeira que provê uma interface com o engine do Breve, controlando funcionalidades como câmera, ajuste de luminosidade, renderização gráfica e interface com usuário. A classe Data é uma classe especial pode ser salva em disco ou em rede.
Eventos e Escalonamento
O comportamento dos agentes são escritos no steve como parte da definição de um objeto. Cada ação que o agente pode tomar pode ser escrita como um método separado que é chamado em resposta a certos eventos. Há muitos modos de disparar eventos dentro de uma simulação no Breve:
Eventos chamados por interação
Eventos escalonados para um momento específico Eventos disparados por notificações
Eventos disparados por colisões