ISSN: Santa Maria, RS - Outubro, 2013

Transcrição

1

2 XII Simpósio de Informática SIRC 2013 Coordenação Geral Ricardo Giuliani Martini Comissão Organizadora Alessandro André Mainardi de Oliveira Alexandre de O. Zamberlan Ana Paula Canal Guilherme C. Kurtz Gustavo Cantarelli Gustavo Rissetti Henrique Gabriel Gularte Pereira Mirkos Ortiz Martins Reiner F. Perozzo Ricardo Giuliani Martini Sylvio Vieira Tatiele Bolson Moro Tiago Rios da Rocha Comissão Avaliadora Adenauer Yamin (UCPEL e UFPEL) Adriana Pereira (UFSM) Ana Elisa Ferreira Schmidt (Univali - Itajaí) Alex Pinho Magalhães (UFSC) Alexandre Zanatta (UPF) Andre Adami (UCS) Andre Du Bois (UFPEL) Andre Martinotto (UCS) Andre Zanki Cordenonsi (UFSM) Anibal Guedes Bruno Augusti Mozzaquatro (UFSM) Carlos Holbig (UPF) Cristiano Both (UFRGS) Daniel Notari (UCS) Fernando Prass (ULBRA) Giovani Rubert Librelotto (UFSM) Guilherme Dhein (UFSM) Gustavo Cantarelli (UNIFRA) Gustavo Zanini Kantorski (UFRGS) Iara Augustin (UFSM) Leandro Loss (UFSC) Lucio Duarte (UFRGS) Marco Castro Barbosa (UTFPR) Marcos Luís Cassal (UFSM) Osmar Marchi dos Santos (UFSM) Rafael Teodósio Pereira (Uminho-PT) Roberto Wiest (IFSul - Passo Fundo) Roberto Willrich (UFSC) Rodrigo Goulart (FEEVALE) Simone Ceolin (UFSM) Valdir Stumm Junior (IFC) Walter Prienitz Filho (UFSM) 1

3 Sistemas Multiagentes: Comparativo entre Organização Centralizada e Organização Descentralizada Patrícia N. Coutinho, Gustavo S. Cantarelli, Guilherme C. Kurtz, Alexandre de O. Zamberlan Curso de Ciência da Computação Centro Universitário Franciscano Rua dos Andradas, Santa Maria RS patricia-inf@hotmail.com, {gus.cant,guilhermekurtz,alexz}@unifra.br Abstract. This work aims to compare the forms of modeling organizations Multiagent Systems centralized and decentralized, based on two case studies originally modeled using the Prometheus methodology. By tallying case studies to use the methodology Moise+, it were listed the specific characteristics of the two modeling methodologies in order to assist the designer of the MAS to choose the most appropriate system requirements. Resumo. Este trabalho tem por objetivo comparar as formas de modelagem de organizações de Sistemas Multiagentes centralizada e descentralizada, com base em dois estudos de caso originalmente modelados utilizando a metodologia Prometheus. Ao adequar os estudos de caso para utilizar a metodologia Moise+, foram elencadas as particularidades de modelagem características das duas metodologias com o intuito de ajudar o projetista do SMA a escolher a que fique mais adequada aos requisitos do sistema. 1. Introdução Um Sistema Multiagente (SMA) é o resultado da combinação de um grupo de agentes, distintos ou não, que precisam trabalhar juntos na resolução de um problema comum. Na maioria das vezes, cada agente desse sistema é responsável por resolver uma parte do problema geral que o conjunto de agentes precisa resolver, economizando, entre outros, a utilização de recursos disponíveis e o tempo necessário para a resolução do problema. Portanto, há a necessidade de organizar esse SMA para otimizar a resolução do problema [Russel e Norvig 2004], [Hübner, Bordini e Vieira 2004]. Sobre Organização de Sistemas Multiagentes, Hübner e Sichman (2003) definem claramente o significado e o funcionamento desse sistema com organização centrada nos agentes e na organização. Ao desenvolver um SMA, o desenvolvedor precisa conhecer as metodologias de modelagem de organização de SMA, a fim de utilizar a metodologia que melhor se aplique ao problema que o SMA precisa resolver, reduzindo os problemas relacionados à construção do SMA. Este trabalho tem o intuito de auxiliar na escolha da melhor metodologia de modelagem a ser utilizada ao construir um SMA levando em consideração o tipo de organização do sistema e a metodologia de modelagem. Foram trabalhados dois estudos de caso, originalmente modelados em Prometheus, que satisfaçam os tipos de organização centralizada e descentralizada. Foi feita a modelagem em Moise+ dos dois estudos de caso com base nas modelagens em Prometheus. Essa comparação entre os 2

4 dois estudos de caso e de metodologias foi utilizada como referência no apontamento das características das duas metodologias de modelagem de SMA. Para tanto, o texto foi dividido em quatro seções. A Seção 2 aborda conceitos de sistemas multiagentes. A Seção 3 apresenta a proposta deste trabalho além de expor os estudos de caso e sua modelagem em Prometheus e Moise+. Na Seção 4 estão as conclusões. E, por fim, são apresentadas as referências bibliográficas. 2. Teoria de Agentes De acordo com [Russel e Norvig 2004], um agente é um sistema que possui a capacidade de perceber o que acontece no seu ambiente utilizando sensores e de agir com o ambiente através de atuadores. Russel e Norvig (2004) exemplificam que um agente robótico poderia usar câmeras e detectores da faixa de infravermelho na função de sensores e vários motores como atuadores. Já para um sistema ou um programa ser caracterizado agente, além de perceber a atuar com o ambiente, é necessário apresentar um comportamento fundamentado no raciocínio que possua atitudes como, por exemplo, crenças (o que ele conhece), intenções (suas metas) e desejos (motivação para realizar as metas). Wooldridge e Jennings (1995) dividiram a arquitetura de agentes em arquitetura: cognitiva ou deliberativa, reativa e híbrida. A arquitetura cognitiva ou deliberativa é caracterizada pela complexidade dos agentes que proporcionam mecanismos de inferência robustos, interações sofisticadas e elevado grau de intenção no comportamento [Russel e Norvig 2004]. A base da arquitetura reativa está na proposta de que um agente pode ampliar sua inteligência por meio de interações com o ambiente, não necessariamente precisando de um modelo pré-estabelecido por não usar qualquer tipo de modelo ou raciocínio simbólico. Um agente reativo não possui a habilidade de planejar suas ações, de sincronização de tarefas entre agentes, e, também, não possui ou especifica uma meta. Este agente simplesmente reage a eventos quando eles ocorrem [Teahan 2010]. Já a arquitetura híbrida é a mistura de componentes das duas arquiteturas anteriores de forma a deixar esta arquitetura mais apropriada e funcional para a construção de agentes. Desta forma, os agentes possuem comportamento reativo com os eventos ocorridos no ambiente e comportamento deliberativo quando uma escolha precisa ser feita e há uma definição simbólica do mundo (isto é, a descrição formal dos possíveis estados de um ambiente) [Russel e Norvig 2004]. Um agente pode ser implementado utilizando qualquer linguagem, contudo existem algumas linguagens específicas que facilitam o desenvolvimento dos requisitos demandados pelo agente. Uma das mais utilizadas e importantes é a AgentSpeak(L), mas existem ainda a LALO, Obliq, Python, Smalltalk e Prolog, por exemplo Sistemas Multiagentes Conforme Russel e Norvig (2004), os Sistemas Multiagentes possuem uma sociedade de vários agentes inteligentes que cooperam com o intuito de resolver um problema maior, em conjunto, que não pode ser resolvido com um agente específico. Para tal, os agentes de um SMA precisam ser desenvolvidos de forma a resolverem problemas que não foram previamente especificados. Sistemas Multiagentes são classificados arquiteturalmente de acordo com o tipo dos agentes contidos no sistema, seguindo a mesma arquitetura apresentada para agentes 3

5 (cognitivo, reativo ou híbrido). Um SMA Cognitivo possui agentes complexos que utilizam um modelo de raciocínio em que suas ações são planejadas e suas interações com outros agentes são negociadas (negociação é a comunicação entre agentes que precisam entrar em acordo, que beneficie ambos, num processo de tomada de decisão conjunta) [Young 1991]. Um SMA Reativo é composto por agentes reativos simples que são desprovidos de modelo simbólico ou interno do ambiente agindo de forma estímulo/resposta (o agente recebe um estímulo e produz uma resposta de acordo com o que foi recebido). E o SMA Híbrido que reúne as duas arquiteturas prévias possuindo agentes deliberativos e agentes reativos interagindo em sociedade [Alvares e Sichman 1997] Organização de Sistemas Multiagentes Segundo Romesíne e Garcia (1997 apud Hübner e Sichman 2003), a organização possui a finalidade de manter o propósito do sistema, para que tal continue válido considerando as mudanças que ocorrem em um SMA. Uma definição pertinente a este trabalho é a proposta por Lemaître e Excelence (1998 apud Hübner e Sichman 2003) que propõe a divisão da organização em dois tipos: a centralizada (o grupo de agentes é organizado de forma centrada na organização) e a descentralizada (grupo de agentes com organização centrada nos agentes). Na organização centralizada o organizador pode obter do grupo de agentes uma descrição da organização adotada pelo sistema, sendo que a organização existe de forma objetiva sem a necessidade de analisar o comportamento da organização ou seus agentes. Esta descrição explícita da organização do sistema é chamada de organização institucionalizada [Lemaître, Excelence 1998 apud Hübner e Sichman 2003]. Na organização descentralizada não há uma representação explícita de organização no SMA, ela está distribuída entre seus agentes. Neste tipo de organização, um agente do grupo, ou um observador, pode deduzir uma descrição baseada na observação do comportamento dos agentes da sociedade, tal descrição é chamada de organização observada [Lemaître, Excelence 1998 apud Hübner e Sichman 2003]. 3. Proposta O projetista de software de um sistema multiagente precisa conhecer qual metodologia de modelagem é a ideal para suprir as necessidades do software projetado, minimizando assim os problemas provenientes de sistemas multiagentes com erros em sua modelagem. Sendo assim, a proposta é modelar em Moise+ dois estudos de caso, já modelados em Prometheus, com organizações de sistemas multiagentes distintas e elencar as características e dificuldades encontradas Estudos de Caso O Primeiro Estudo de Caso (Agenda), que possui organização centralizada, tem a finalidade de resolver o problema da alocação de horários de compromissos em agendas compartilhadas ou públicas entre todos os usuários envolvidos. Existe um agente organizador chamado secretária e os outros agentes do sistema são responsáveis pelas agendas dos usuários. Todas as agendas de usuários, quando precisam agendar um compromisso compartilhado, conversam com o agente secretária (o agente centralizador) que negocia com todos os agentes envolvidos e avisa estes agentes em qual horário o compromisso será marcado [Costa 2011]. 4

6 No Segundo Estudo de Caso (Gerenciamento de Tráfego Urbano), com organização descentralizada, Baccin (2011) apresenta um sistema que auxilie na configuração dos componentes envolvidos no gerenciamento de tráfego urbano. Esse sistema tem o intuito de gerenciar o número de veículos nas ruas usando semáforos inteligentes e sistemas informatizados otimizando o tráfego de veículos nos cruzamentos. O sistema possui três agentes principais. O agente Veículo verifica principalmente a condição do semáforo avançando na Via ou parando conforme sinalizado. O agente Via faz o controle do número de veículos que existem em um determinado trajeto e, quando solicitado, informa o número ao agente Semáforo. E, por fim, o agente Semáforo faz a sinalização de quais ruas possuem permissão para avanço de veículos [Baccin 2011] Modelagem Os estudos de caso utilizados neste trabalho são provenientes de dois trabalhos realizados na área de Sistemas Multiagentes em que a organização não foi considerada como parte do trabalho mesmo apresentando, implicitamente, uma organização. Para a Organização Centralizada de Sistemas Multiagentes, Costa (2011) define um sistema com agentes agenda e um agente secretária responsável por gerenciar os conflitos de horários de atividades compartilhadas entre as agendas. Baccin (2011) apresenta um sistema de cruzamento entre vias com agentes reativos (veículo, via e semáforo) representando a Organização Descentralizada de Sistemas Multiagentes Prometheus Utilizando inicialmente a tecnologia Prometheus, a modelagem dos dois estudos de caso foi feita e possui três etapas, sendo a primeira a especificação do sistema onde são especificadas a visão geral das metas do sistema. Em um segundo momentos são definidos os cenários do sistema. E, finalmente, o diagrama de funções do sistema que possui os papéis que o sistema irá assumir são mostrados, para os dois estudos de caso, nas Figuras 1 e 2. Figura 1. Diagrama de Funções do Sistema Agenda. Adaptado de [Costa 2011] Moise+ Com base nos estudos de caso, foi feita a modelagem, utilizando a metodologia Moise+. Da mesma forma como Prometheus, Moise+ possui três etapas de modelagem, chamadas de dimensões organizacionais. Essas dimensões são referentes à estrutura da organização, às suas funcionalidades e a terceira dimensão, a deôntica, tem a função de 5

7 ligar as duas primeiras. As Figuras 3 e 4 mostram a estruturação inicial e principal da metodologia Moise+. Finalmente, sugere-se consultar [Coutinho 2012] para detalhes do trabalho e metodologia. Figura 2. Funcionalidade do Sistema de Gerenciamento de Tráfego Urbano. Adaptado de [Baccin 2011]. Figura 3. Especificação Estrutural do Sistema Agenda. Figura 4. Especificação Estrutural do Sistema de Tráfego Urbano. 6

8 4. Conclusão Prometheus e Moise+ possuem abordagens de modelagem diferentes e, portanto, é necessário entender como o sistema a ser modelado (neste caso em Prometheus) funciona e com base nesse entendimento modelar o novo sistema (em Moise+) apenas com o que foi compreendido de seu comportamento esperado. Assim, pode haver erros nessa compreensão do sistema e, consequentemente, na sua modelagem. As etapas necessárias para a modelagem em Prometheus não explicitam como os papéis são organizados dentro da organização. Por não levar em consideração a organização do SMA, Prometheus não se preocupa em estruturar melhor o sistema, o que pode tornar o entendimento do mesmo confuso, principalmente em sistemas mais complexos como, por exemplo, o do segundo estudo de caso (Gerenciamento de Tráfego Urbano). Assim, a metodologia Prometheus pode ser utilizada facilmente em sistemas mais simples (poucos papéis e poucas interações) e possuam uma organização de SMA centralizada. A metodologia Moise+ possui a vantagem de ser melhor estruturada ao ser utilizado em trabalhos com muitas interações entre papéis e que o SMA possua organização descentralizada. É sugerido para trabalhos futuros o envolvimento do interpretador Jason com Moise+, principalmente o sistema de Gerenciamento de Tráfego Urbano por ser um sistema mais complexo, e relatar como o processo de desenvolvimento desse sistema se comporta em relação a um sistema modelado em Prometheus. Ainda, pode-se realizar uma comparação de modelagem via Prometheus e Moise+ do princípio e relatar o tempo e complexidade da tarefa. Referências Bibliográficas ALVARES, L. O. e SICHMAN, J. S. (1997), Introdução aos Sistemas Multiagentes, Universidade Federal do Rio Grande do Sul, Porto Alegre. BACCIN, J. P. (2011), Sistema Multiagente Reativo para Tráfego de Veículos com Gerenciamento de Semáforos, Centro Universitário Franciscano, Santa Maria. COSTA, C. V. D. (2011), Agente para Atuação no Google Agenda, Centro Universitário Franciscano, Santa Maria. COUTINHO, P. N. (2012), Sistemas Multiagentes: comparativo entre organização centralizada e descentralizada, Centro Universitário Franciscano, Santa Maria. HÜBNER, J. F.; BORDINI, R. H. e VIEIRA, R. (2004), Introdução ao Desenvolvimento de Sistemas Multiagentes com Jason, Universidade Regional de Blumenau, Blumenau. HÜBNER, J. F. e SICHMAN, J. S. (2003) Organização de Sistemas Multiagentes, III Jornada de Mini-Cursos de Inteligência Artificial, Campinas, p RUSSEL, S. J. e NORVIG, P. (2004), Inteligência Artificial, Rio de Janeiro: Elsevier, 2ª Edição. TEAHAN, W. J. (2010), Artificial Intelligence - Agent Behavior I, Willian John Teahan & Ventus Publishing ApS. WOOLDRIDGE, M. e JENNINGS, N. R. (1995) Inteligent Agents: Theory and Practice, The Knowledge Engineering Review, v. 10, n. 2, p YOUNG, H. P. (1991), Negotiation Analysis, Michigan: Michigan Press. 7

9 Implantação De Um Cluster Failover Utilizando Software Proprietário Rodrigo Ferreira Gonçalves 1, Carlos Michel Betemps 1, Sandro da Silva Camargo 1 1 Universidade Federal do Pampa Campus Bagé (UNIPAMPA) Travessa 45, n Bairro Malafaia - CEP: Bagé, RS Brasil rodrigo@urcamp.edu.br, {carlos.betemps,sandro.camargo}@unipampa.edu.br Abstract. Provide services without interruption is a critical requirement, because a failure can cause financial damage to the company and its reputation. In this scenario, this work aimed to deploy a high-availability solution using proprietary software. As research hypothesis will be examined whether the deployment of Cluster Failover provides high availability of information in the distributed servers. The methodology was a literature review on the topic, deployment and experimentation of a Cluster Failover and display of results. It was concluded that the equipment used in the deployment responded to most of the tests, providing high availability of information and applications. Resumo. Fornecer serviços sem interrupção é um requisito crítico, pois uma falha pode gerar danos financeiros à empresa, bem como a sua reputação. Neste cenário, este trabalho teve por objetivo implantar uma solução de Alta Disponibilidade utilizando software proprietário. Como hipótese de pesquisa, será analisado se a implantação do Cluster Failover provê alta disponibilidade das informações distribuídas nos servidores. A metodologia de trabalho foi a revisão bibliográfica sobre o tema, implantação e experimentação de um Cluster Failover e exposição de resultados. Concluiu-se que os equipamentos utilizados na implantação responderam à maioria dos testes aplicados, provendo alta disponibilidade das informações e aplicações. 1. Introdução Devido à necessidade de atender diferentes requisitos do negócio, muitas organizações estão migrando seus sistemas do ambiente de rede local para o ambiente Web. Nesta nova realidade, fornecer serviços sem interrupção é um requisito crítico, pois uma falha pode ser significante tanto na geração de impactos financeiros, em curto prazo, quanto na geração de danos à reputação empresarial, em longo prazo [Zhang, Abdelzaher and Stankovic 2004]. Uma solução viável para aumentar a disponibilidade dos serviços é a utilização de clusters. Os clusters surgiram com o objetivo de suprir algumas dificuldades dos sistemas centralizados e também para aumentar o desempenho das aplicações, redes e ferramentas padronizadas para computação distribuída de alto desempenho. A composição de um cluster abrange questões complexas de pesquisa em computação tais como escalabilidade, disponibilidade, tolerância a falhas e alto desempenho [Alecrim 2013]. A fim de tornar a falha de um nó imperceptível ao usuário, a técnica de failover é 8

10 uma solução que permite o redirecionamento das requisições para outro nó. No contexto de Banco de Dados, um Cluster Failover é útil se um nó falha ou mesmo se ocorre qualquer manutenção planejada nos recursos de um Sistema de Banco de Dados. Com o avanço tecnológico e econômico, várias empresas necessitam cada vez mais manipular informações de maneira segura e contínua. Para isso, necessitam de servidores que possam disponibilizar dados armazenados de forma rápida e eficaz com alta disponibilidade aos usuários. A motivação que levou à realização deste trabalho se deve a relevância do tema para as organizações que utilizam software proprietário para o gerenciamento de dados. Outro fator considerável foi que no ambiente corporativo onde ocorreu esta implantação há preferência pela utilização da plataforma Windows para servidores e para Banco de Dados. Neste ambiente, a cultura do uso de software proprietário é antiga e também são levados em consideração todos os riscos envolvidos na migração para uma plataforma de distribuição livre. Neste contexto, a implantação do Cluster Failover propõe garantir alta disponibilidade dos recursos e aplicações entre os servidores. Este artigo está estruturado da seguinte forma: na seção 2 são apresentados alguns conceitos relacionados ao tema do trabalho; na seção 3 são descritos o ambiente onde foi implantado o cluster failover e como se deu a experimentação deste cluster, apontando detalhes da metodologia de trabalho; por fim, a seção 4 apresenta algumas considerações finais, seguidas da indicação de trabalhos futuros. 2. Clusters Cluster é um sistema que compreende dois ou mais computadores ou subsistemas (nós). Estes elementos executam aplicações ou realizam tarefas específicas de tal maneira que os usuários tenham a noção de um sistema único e homogêneo. A comunicação é feita através de polling, que são pedidos contínuos de informações, permitindo que um servidor saiba que existem outros nós do cluster em funcionamento [Rocha 2004] Cluster Failover O Cluster Failover é um cluster de Alta Disponibilidade. É muito utilizado em Data Centers de bancos e sites de e-commerce, uma vez que tais exemplos necessitam manter-se 24 horas online. Também são utilizados em empresas que desejam incrementar sua escalabilidade, gerenciamento de recursos, disponibilidade ou processamento de forma supercomputacional a um preço moderado [Pitanga 2013]. O processo de failover é o modelo de recuperação em cluster. Este processo pode ser entendido como a troca, através de transações, para um nó alternativo ou um nó de backup, devido a uma situação simples de falha em um dos nós do cluster. O processo de failover deve ser totalmente transparente e automático, sem a intervenção de um administrador de sistema computacional e, principalmente, sem a necessidade de reconexão manual do cliente da aplicação crítica. Para algumas aplicações não críticas, que podem suportar um tempo maior até a recuperação da falha, pode-se utilizar failover manual. Além do tempo entre a falha e a sua detecção, existe também o tempo entre a detecção e o restabelecimento da disponibilidade da aplicação e dos recursos envolvidos no sistema computacional. Grandes Bancos de Dados podem exigir um considerável período de tempo, após uma falha, até que sejam ajustadas suas tabelas. 9

11 Durante este tempo a aplicação ainda não estará disponível. Para realizar o failover de uma aplicação crítica é necessário que os nós do cluster envolvidos na utilização deste mecanismo possuam recursos equivalentes. Um recurso pode ser uma interface de comunicação de rede ou um disco, onde os dados existentes no disco são elementos necessários à prestação de um determinado serviço para a aplicação crítica em questão. Dependendo da natureza da aplicação e do sistema de computação, executar um failover significa interromper as transações em andamento, perdendo-as, sendo necessário reiniciá-las após o failover. Em outros casos, significa apenas um retardo até que a aplicação e os serviços oferecidos pela aplicação estejam novamente disponíveis [Technet 2013]. 3. Implantação do Cluster Failover O procedimento de implantação do Cluster Failover desenvolvido neste trabalho teve como objetivo implantar e experimentar este tipo de mecanismo, visando oferecer melhorias em termos de alta disponibilidade de recursos. A seguir são descritos o ambiente de implantação do Cluster Failover e os experimentos realizados Ambiente de Implantação O ambiente organizacional onde estão localizados os servidores que foram configurados como fazendo parte do cluster failover não contava com uma estrutura redundante de Banco de Dados e de Sistema Operacional. Existem, no ambiente de implantação, dois servidores, sendo que um faz o gerenciamento dos usuários e é utilizado como servidor de arquivos e controlador de domínio (para aplicativos preexistentes); e o outro servidor atua apenas como Banco de Dados. Então, neste contexto, foi implantado um cluster de alta disponibilidade para que os dois servidores fiquem com a mesma versão de Banco de Dados instalado e, logo após, seja clusterizado o Sistema Operacional e a base de dados. O ambiente corporativo de implantação do Cluster Failover conta com um parque de trinta computadores (estações desktop) e dois servidores (acima mencionados). Os equipamentos estão interligados por uma rede Gigabit Ethernet através de um switch gerenciável de marca 3Com modelo 2952 com 48 portas, que utiliza cabeamento de rede modelo Categoria 6. Este switch faz a ligação e distribuição da Internet para os componentes ativos que compõem a estrutura da rede, conforme mostrado na Figura 1. Foram utilizados dois servidores, de marca DELL, com a seguinte configuração: Processadores Intel Xeon CPU 2.40GHz, 8Gb de memoria RAM, 4 (Quatro) HDs de 500Gb de espaço de armazenamento. O Sistema Operacional utilizado foi o Windows Server 2008 e como Banco de Dados o SQL Server O servidor nomeado SRVGRAFICA-1 foi utilizado como nó 1 e responsável por controlar o domínio e replicar as informações dos sistemas para o servidor SRVGRAFICA-2 (nó 2). Este último ficou com a cópia de todas as informações inseridas, alteradas e excluídas do Banco de Dados do Servidor 1. O tempo de replicação das informações entre os servidores foi configurado através do assistente de replicação do SQL Server Este método foi adotado porque, caso ocorresse uma 10

12 falha de um dos servidores, o nó ativo assumiria o controle e continuaria disponível aos usuários sem que estes percebessem a ocorrência de alguma falha. Figura 1. Parque de Computadores do Ambiente Corporativo. A replicação aplicada de forma assíncrona propiciou que o servidor que ficou indisponível (off-line), devido a algum evento de falha, recebesse as informações atualizadas após a sincronização com o servidor ativo. Durante as instalações do cluster foi desabilitado o firewall do Windows de cada um dos servidores, através do painel de controle, pois habilitado causou bloqueios de portas de rede que o Cluster Failover usa durante a instalação. A instalação do cluster foi feita através do gerenciador de servidores do Windows Server e foi selecionado o Framework.NET, que é um recurso que possui as funções necessárias para funcionamento dos programas sob qualquer Sistema Operacional da plataforma Windows. Após a instalação do cluster nos servidores, foi configurada a replicação dos Bancos de Dados, através da Replicação Merge, que por função replicou as 250 tabelas do Banco e qualquer informação alterada foi aplicada para o outro servidor, mesmo este tendo ficado temporariamente fora de sincronismo. Quando a sincronização ocorreu com o servidor que ficou indisponível (off-line), este enviou os dados para todos os locais especificados. Depois foi necessário configurar as publicações e assinaturas locais dos servidores de Banco de Dados SRVGRAFICA-1 e SRVGRAFICA-2. Quando o SQL Server foi instalado no servidor SRVGRAFICA-2, foram configurados os metadados que compõem as suas estruturas lógicas e de controle. Dentre esses, as estruturas mais importantes são: Master, Model, Tempdb e Msdb, que fazem parte do Sistema de Gerenciamento de Banco de Dados. Nesta etapa definiu-se que os dois servidores teriam a função de Distribuidor/Publicador, que tem por função a distribuição e armazenagem dos metadados e dados de histórico para todos os tipos de replicação. 11

13 3.1. Experimentação do Cluster Failover Para analisar o desempenho da implantação foram utilizadas ferramentas nativas que estavam pré-instaladas nos servidores. A ferramenta Windows MMC (Microsoft Management Console) foi utilizada para gerenciar os recursos dos servidores, pois possui vários serviços que podem ser adicionados e tem por função gerenciar os aplicativos instalados no sistema operacional. Foi executada a ferramenta de validação dos clusters através do gerenciador de Cluster Failover, que analisa todas as configurações de hardware e software instalados nos servidores. Verificou-se que os processos de instalação do cluster do Sistema Operacional foram bem-sucedidos. Após, desconectou-se um dos servidores através do desligamento do cabo de rede da interface. A desconexão foi executada propositalmente (no servidor SRVGRAFICA-2) no momento que acontecia uma atualização de um dos Bancos de Dados, a fim de testar o Cluster Failover e verificar como iria se comportar a replicação após a falha. O servidor SRVGRAFICA-1 assumiu o controle automaticamente de todos os serviços que estavam sendo fornecidos pelo servidor 2. Esta ação foi visualizada através da ferramenta de gerenciamento de clusters do servidor. Todas as aplicações e sistemas ficaram disponíveis aos usuários sem que eles percebessem a falha de um dos servidores. A desconexão foi de 5 minutos, tempo suficiente para visualizar como o cluster iria se comportar após o sincronismo. Para testar o tempo de resposta de alguns comandos executados nos Bancos de Dados foi realizada a instalação em conjunto de três pacotes: (Sql Cmd LnUtils),(Shared Management Objects),(Power Shell Tools) 1. Estes pacotes foram instalados e executados nos dois servidores, a fim de avaliar o desempenho de tempo de resposta de cada. Figura 2: Análise de processos executados nos servidores. Os referidos pacotes usam scripts que executam os comandos dentro de cada Banco de Dados (criação de tabela, escrita dos dados, atualização, leitura, exclusão dos dados e exclusão de tabelas). Estes comandos mostraram o tempo de resposta de cada operação, desta forma podendo ser analisado o desempenho obtido por cada Banco de 1 Disponível em: < 12

14 Dados. Todas as operações executadas, mostradas na figura 2 (Creating Table, Writing Data, Updating Data, Reading Data, Deleting Data e Dropping Table), estão no mesmo intervalo de tempo, possuindo desempenho equivalente em tempo de resposta. 4. Considerações Finais e Trabalhos Futuros Esta implantação foi realizada utilizando a plataforma Windows Server 2008 e SQL Server 2008, porém podem ser utilizadas outras configurações, como Linux e distribuições livres de Banco de Dados. A implantação do Cluster Failover em software proprietário pode possuir um custo elevado para as organizações, porém, quando estes softwares estão disponíveis, contar com um tipo de aplicação deste porte traz uma maior disponibilidade e segurança das aplicações. Para validar os testes foram utilizadas ferramentas do próprio Sistema Operacional e outras conforme foi citado anteriormente. As ferramentas de verificação/validação avaliaram os seguintes itens: Armazenamento: onde foi feita à validação dos discos do cluster; Configuração do Sistema: foi realizada a checagem dos drives do sistema, configurações do Active Directory e atualizações de software; Inventário: onde foram listadas as informações sobre drives do sistema, informações da BIOS e processos em execução; Rede: onde foi validada a comunicação de rede, nós do cluster, endereços IPs e configurações do firewall do Windows. Após as verificações citadas acima, foram utilizadas as ferramentas Sql Cmd Ln Utils, Shared Management Objects e Power Shell Tools para avaliar o desempenho do Cluster Failover do SQL Server. Foram executados comandos de criação de tabelas, escrita de dados, atualização, leitura, exclusão de dados e de tabelas. Analisou-se que os servidores responderam aos testes aplicados, propiciando uma alta disponibilidade dos dados entre os servidores e suas aplicações. Como trabalhos futuros é sugerido um estudo mais aprofundando sobre o tema, expandindo, assim, a possibilidade para a execução de mais trabalhos científicos que necessitam de um ambiente desse porte para gerar dados mais significativos como, por exemplo, a utilização de mais e diferentes testes para avaliar o desempenho e comportamento dos sistemas. Pode-se aplicar a arquitetura descrita neste estudo para incitar novas configurações para a utilização de Clusters Failover. Referências Alecrim, Emerson. Clusters: Conceitos e Características. Disponível em: < Acesso em: 23 Jun Pitanga, Marcos J. Computação em Cluster. Disponível em: < Acesso em: 03 Set Rocha, Lidiane Lins. Cluster Visão Geral, Artigo, Brasília: UCB, Technet, Microsoft. Cluster Failover. Disponível em: < Acesso em: 27 Abril Zhang, R., Abdelzaher, T. F., and Stankovic, J. A. (2004). Efficient TCP connection failover in web server clusters. In Proceedings of the IEEE InfoCom Conference. Vol. 2,

15 Paralelização de Ray Tracing utilizando Intel Cilk Plus Júlio C. Vieira 1, Guilherme W. Cassales 1, Fernando Faé 1, Andrea S. Charão 1 1 Curso de Ciência da Computação Universidade Federal do Santa Maria (UFSM) {julioc, cassales, fae, andrea}@inf.ufsm.br Abstract. This paper discusses the parallelization of an algorithm of Ray Tracing by the use of an extension of the C and C++ programming languages, the Intel Cilk Plus. This extension allows data and task parallelism by inserting keywords at certain points of the code. Although it is simple, it is necessary to understand the code that will be parallezide to find the best point to insert the keywords, increasing the maximum parallel performance. Resumo. Este artigo trata da paralelização de um algoritmo de Ray Tracing fazendo o uso da uma extensão das linguagens C e C++, o Intel Cilk Plus. Essa extensão possibilita paralelismo de dados e de tarefas através da inserção de keywords (palavras-chaves) em determinados pontos do código. Apesar de simples, é necessário ter compreensão do código a ser paralelizado para encontrar o melhor ponto de inserção das keywords, aumentando ao máximo o desempenho em paralelo. 1. Introdução Programação Paralela é uma área da computação de alto desempenho que estuda maneiras de agilizar processos utilizando a estratégia de dividir grandes processamentos de dados em processamentos menores. Ao dividir a carga em diversos processadores (cores), cria-se um fluxo maior de dados sendo processados simultaneamente, gerando um speed-up. Existem diversas formas de explorar o processamento paralelo, tanto em termos arquiteturais, como de comunicação: distribuído e paralelo (mais de uma máquina processando em paralelo), utilizando memória compartilhada, GPU, entre outros. Este artigo mostrará o funcionamento da ferramenta Intel Cilk Plus e seu uso em um algoritmo de ray tracing. Será abordada a nova sintaxe estabelecida e o que é necessário para executar programas que a contenha. Após isso, apresenta-se um processo de profiling utilizado para determinar os pontos que poderiam ser paralelizados e, então, é feita uma avaliação dos resultados produzidos após a adaptação do código. O processador utilizado foi um Intel Core i3-3110m, com dois núcleos físicos de 2.40GHz. A escolha de paralelizar um algoritmo de ray tracing deve-se ao fato de que estes algoritmos demandam muito processamento, pois dependem da complexidade da imagem e números de pixels. Por ser um método que não é necessariamente serial, com a paralelização é possível diminuir consideravelmente o tempo de processamento. 14

16 2. Fundamentação A primeira tarefa foi entender como funciona e como utilizar o Intel Cilk Plus, conhecimento que encontra-se de forma resumida nesta seção Funcionamento O Intel Cilk Plus é um framework de desenvolvimento que fornece uma interface de programação simples e intuitiva [Camargo, C. Araújo, A. Cavalheiro, G. (2012)] para criações e sincronizações explícitas e aninhadas de threads. Ele adiciona três keywords à sintaxe da linguagem C: cilk_for, cilk_spawn e cilk_sync; Para desenvolver programas com este framework, há duas opções: a) Instalar um compilador da Intel (Inter Composer XE, Inter Parallel Studio XE ou Intel C++ Compiler) e o Intel Cilk++ SDK; b) Configurar o compilador próprio do Intel Cilk Plus juntamente com o gcc/g++ do Linux. A filosofia por trás do desenvolvimento Cilk é fazer da linguagem dela uma verdadeira extensão paralela da linguagem C [Robert D. Blumofe, et al. (1996)] Utilização O Intel Cilk Plus utiliza basicamente três keywords para tornar a execução do programa paralela [Introducing Intel Cilk Plus]. São elas: cilk_for: utilizado para paralelizar loops; cilk_spawn: essa keyword define que a função chamada pode executar em paralelo com a origem da chamada, desde que essa função não tenha dependências. Por exemplo, um loop que chama uma função que não tem dependências pode ser executado várias vezes paralelamente, sem causar problemas de sincronização. É importante salientar que cilk_spawn não ordena que seja executado em paralelo, somente cria a oportunidade do plano de execução criar novos threads, ou seja, o Intel Cilk Plus analisa se é viável a paralelização que está sendo proposta. Se for, o cilk_spawn é realizado. Caso não seja, a execução continua serialmente. O próprio plano de execução determina se é possível a paralelização; cilk_sync: determina que todos os threads criadas pelo cilk_spawn devem terminar antes de continuar a execução. Para exemplificar a paralelização de loops for, é necessário comparar a utilização de somente cilk_for no lugar de for e cilk_spawn e cilk_sync nas chamadas de funções dentro do loop [Introducing Intel Cilk Plus], como visto nas Figuras 1 e 2. 15

17 Figura 1. Loop for com o uso de cilk_for. Figura 2. Exemplo de um loop for com o uso de cilk_spawn e cilk_sync. 3. Desenvolvimento Após entender como utilizar corretamente a nova sintaxe fornecida pelo Intel Cilk Plus, era necessário determinar qual ou quais seriam os melhores pontos do algoritmo que gerariam uma taxa de speed-up considerada proveitosa para a utilização da ferramenta. 3.1 Estratégias e uso de ferramentas Utilizou-se a ferramenta Performance Analysis, do Microsoft Visual Studio 2012, para gerar um profiling da execução. Um profiler serve para verificar quais são as partes do algoritmo que mais consomem tempo de execução e, portanto, mais propensas a gerar uma alta taxa de speed-up ao ser paralelizado. Por exemplo, na Figura 3, é possível ver que 99,98% do tempo de execução do algoritmo concentra-se dentro da função main, sendo 95,85% deste tempo consumido em chamadas da função ray_trace. Através da ferramenta Performance Analysis, é possível percorrer as funções chamadas e observar em que parte do código dentro delas consome mais tempo de execução naquela função. Explorando mais a fundo os resultados do profiling, podemos ver as funções mais chamadas dentro da função intersect, conforme pode ser visto na Figura 4. O compilador da Intel escolhido com o Intel Composer XE, versão trial de 30 dias. Figura 3. Resultado do profiling. 16

18 Figura 4. Visualização do profiling da função intersect. 4. Avaliação Para facilitar a execução de testes com e sem o framework Intel Cilk Plus, foram realizadas pequenas alterações no código original do algoritmo escolhido, incluindo um novo argumento para definir a utilização ou não das keywords do framework. A sintaxe de execução do programa é a seguinte: <executável> <level> <cilk on/off> > fig.ppm O argumento level estabelece a quantidade de objetos que formarão a imagem e, por tanto, quanto mais alto o level, maior a quantidade de objetos para ser realizado o ray tracing. A parte da sintaxe > fig.ppm faz com que a saída do programa vá para um arquivo com extensão.ppm, que é o formato que os dados são gerados. Para executar no Windows, o programa foi compilado utilizando o Visual Studio 2012 e executado através do Prompt de Comando. Após análise do resultado gerado pela ferramenta Performance Analysis, concluiuse que a paralelização deveria envolver as chamadas de função ray_trace na main e/ou intersect na função ray_trace. Foram criadas duas versões diferentes do código paralelizado. Na primeira, foram adicionadas keywords somente nas chamadas da função ray_trace, na main. Já na segunda, além destas, foram adicionadas também na chamada da função intersect, dentro da função ray_trace. Ambas as versões foram testadas, obtendo resultados similares, apresentados na Tabela 1. 17

19 Tabela 1. Tempo médio em segundos das execuções do programa nas três versões. Level Versão original Versão Cilk Plus I Versão Cilk Plus II 1 2,71 8,758 9,8 2 26,931 28,477 29, ,224 53,523 55, ,543 75,155 79, ,086 91,433 93, , , , ,819 96,544 10, , , , , , , , , , , , ,615 Como podemos ver no gráfico da Figura 5, o desempenho sem o uso de Intel Cilk Plus com um e dois levels é superior ao de quando o framework é usado. À medida que o grau de complexidade (level) aumenta, o uso de Intel Cilk Plus torna-se vantajoso, diminuindo consideravelmente o tempo de execução em levels altos. Esse baixo desempenho do framework nos levels menores deve-se ao trabalho em segundo plano necessário para criação, distribuição e gerenciamento dos threads decorrentes do uso das keywords. O trabalho em segundo plano é o responsável pelo particionamento, comunicação, aglomeração e mapeamento, princípios básicos da paralelização. Cilk I Cilk II 1,6 1,4 1,2 1 0,8 0,6 0,4 0, Figura 5. Gráfico do speed-up com as duas versões de uso do Intel Cilk Plus. 18

20 5. Conclusão Ao finalizar este trabalho, chega-se à conclusão de que o Intel Cilk Plus é uma ferramenta com incrível capacidade e facilidade de paralelização. Além de ter aumentando o desempenho em taxas de speed-up de até 1,5, o processo de paralelização pode ser feito mesmo sem o uso de profiling, pois as alterações no código são mínimas, o que facilita os experimentos à medida que modificações são feitas. O Intel Cilk Plus foi, de fato, uma ferramenta com ótimos resultados na relação desempenho obtido/dificuldade encontrada. Referências Robert D. Blumofe, Christopher F. Joerg, Bradley C. Kuszmaul, Charles E. Leiserson, Keith H. Randall, and Yuli Zhou. (1996) Cilk: An efficient multithreaded runtime system Introducing Intel Cilk Plus: Extensions to simplify task and data parallelism. Available on the internet from Camargo, C. Araújo, A. Cavalheiro, G. (2012) Uma revisão sobre ferramentas de programação multithreads comerciais e acadêmicas. Frigo, M. Leiserson, C. Randall, K. (1998) The implementation of the Cilk-5 Multithread Language. 19