Quantificação do poder de processamento disponível no domínio Unijui utilizando Web Services

Transcrição

1 Quantificação do poder de processamento disponível no domínio Unijui utilizando Web Services Bruno Batista Boniati, Edson Luiz Padoin 1 Departamento de Tecnologia Universidade Regional do Noroeste do Estado do Rio Grande do Sul Rio Grande do Sul (UNIJUI) Caixa Postal Ijui RS Brazil {bruno,padoin}@unijui.tche.br Abstract. The work in question aims at to apply the technology of Web Services to create a infrastructure of software in order to quantify the existing power of processing and computational resources in domain UNIJUI. To reach such results, a service was developed web to collect information on the one of the machines when these enter in rest way (screen protection). The applicatory one collects the data and transmits in a document XML to a Web Service that persists the information. To leave of these information objective to evaluate the possibility of use of the technology in question for processing distribution and the viability of the implantation of projects with the use of processing distributed in the institution. Resumo. O trabalho em questão visa aplicar a tecnologia de web services para criar uma infra-estrutura de software a fim de quantificar o poder de processamento e os recursos computacionais existentes no domínio UNIJUI. Para alcançar tais resultados, desenvolveu-se um web service para coletar informações sobre o status das máquinas quando estes entram em modo de descanso (proteção de tela). O aplicativo coleta os dados e transmite em um documento XML a um web service que persiste as informações. A partir dessas informações objetiva-se avaliar a possibilidade de utilização da tecnologia em questão para distribuição de processamento e a viabilidade da implantação de projetos com a utilização de processamento distribuído na instituição. 1. Introdução Com o advento da computação pessoal e a constante redução dos custos dos equipamentos, cada vez pode-se adquirir máquinas com um maior poder de processamento e maiores recursos. Boa parte destes recursos (processador, disco rígido e memória principal) não é utilizada a todo o momento, ou pelo menos não tem sua capacidade total explorada. Aliado a estes dados, as tecnologias de processamento distribuído e concorrente têm tido grandes avanços o que nos possibilita pensar em soluções computacionais que venham reunir um grande número de computadores para resolver tarefas durante os períodos em que são menos requisitados. Na prática, o que se sabe é que existem sérias dificuldades na construção de aplicações distribuídas, principalmente quando sistemas heterogêneos (rede, sistema operacional e hardware) precisam interoperar entre si. Quando distribuímos uma carga de

2 processamento entre nodos ociosos de uma rede precisamos considerar uma série de situações que venham a garantir a execução por completa da aplicação, preferencialmente em um tempo menor do que se a mesma estivesse rodando de forma isolada. A aplicação deve apresentar um alto grau de tolerância a falhas, evitando que a queda de um dos nodos processadores faça com que todo o sistema fique inoperante. Uma das melhores alternativas à heterogeneidade das aplicações, que vem sendo utilizada cada vez mais para comunicação e troca de informações entre as empresas, são os Web Services. Eles representam a evolução de alguns padrões e protocolos de larga utilização e utilizados para criar a internet como a conhecemos hoje. A padronização tem sido a chave para o sucesso e aceitação instantânea da tecnologia. Sua infraestrutura é construída sobre os padrões e tecnologias abertas, devidamente definidas e de ampla aceitação, como XML (extensilbe Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) e UDDI (Universal Description, Discovery and Integration). Um web service é uma aplicação publicada, localizada e invocada através da internet. Encapsula e contrata funções de objetos remotos por meio de um protocolo padrão e conhecido. Inicialmente é possível afirmar que os web services são a evolução natural das chamadas a procedimentos remotos. Não representa em si, uma tecnologia muito mais avançada do que um RPC (Remote Procedure Call), porém, com conceitos similares aplicados de novas maneiras, de forma padronizada. A partir desta contextualização, o objetivo do trabalho é de estudar a viabilidade da implementação de projetos que visem a distribuição de processamento em médias e grandes redes coorporativas, como é o caso do domínio UNIJUI, onde o trabalho será desenvolvido. Objetiva-se quantificar a freqüência em que os computadores entram em modo de descanso, bem como qual é o consumo de recursos computacionais nestes momentos. As informações levantadas pelo mesmo podem ser utilizadas para avaliações iniciais de outros projetos semelhantes.[bon03] Para alcançar o objetivo proposto, foram construídas duas aplicações: um container web para hospedar o serviço que fará a coleta dos status enviados pelos computadores. E uma aplicação cliente (proteção de tela), que é automaticamente chamada pelo sistema operacional quando o computador fica inativo após um determinado período. Uma vez ativada, a aplicação cliente (proteção de tela) monitora o status do computador, empacota dados sobre seu status (em um documento XML) e envia para o web service informações pertinentes à pesquisa (utilização da CPU, capacidade de disco, status da memória principal). O servidor recebe os dados enviados pelos clientes, desempacota, filtra e armazena os resumos. A parir destes dados é que são feitos os cruzamentos para obtenção dos resultados do trabalho. 2. Aglomerados e Grades Computacionais Quando o assunto é computação de alto desempenho, geralmente utilizada para fins científicos, gerenciamento de grandes volumes de dados e programação multimídia, uma das soluções para tal demanda são as máquinas com múltiplos processadores ou ainda máquinas paralelas proprietárias fornecidas por grandes empresas. As duas soluções demandam recursos e permitem pouca escalabilidade, pois ficam obsoletas em

3 um período de tempo muito curto e sua manutenção/atualização é quase proibitiva pelo alto custo. Uma das alternativas para tal situação é a distribuição de processamento entre máquinas de pequeno/médio porte, a fim conseguir aglomerar o maior número de processadores, distribuindo e gerenciando tarefas entre os mesmos. Segundo, Foster, citado em [BAR02], um grid pode ser definido então como uma infraestrutura de software e hardware para a integração de recursos computacionais, instrumentos científicos, dados e pessoas geograficamente dispersas de modo a formar um ambiente colaborativo de trabalho. Seu emprego pode ser considerado como um novo paradigma para a concepção de sistemas paralelos e distribuídos, uma vez que aproxima e reúnem avanços recentes de ambas as áreas. 3. Proteção de Tela Protótipo InfoMaq O protótipo InfoMaq é uma proteção de tela que foi construída aos moldes do projeto SETI@Home que visa estudar a viabilidade da utilização da tecnologia de web services em aplicações de processamento distribuído, bem como avaliar a aplicabilidade de tal tecnologia no domínio UNIJUI.INTRANET. [JES01] O objetivo principal da construção do aplicativo não é realizar em si a distribuição de processamento, mas sim coletar informações sobre o status dos computadores do domínio no momento em que os mesmos entram em modo de descanso. Um segundo objetivo, não menos importante é o de aplicar na prática uma solução computacional utilizando web services para testar a confiabilidade e resposta da aplicação O Web Service Inicialmente foi necessário especificar e escrever a aplicação servidora, responsável por recolher e fornecer informações aos nodos clientes. Para tanto foi escrito um web service, para ser hospedado em um servidor IIS (Internet Information Service). A escolha por tal servidor deve-se à simplicidade e praticidade do mesmo, bem como um maior conhecimento sobre tal aplicativo. O web service foi projetado para ser abrigado em um container web do tipo ISAPI (Internet Server API). Este tipo de container permite que sejam escritas DLLs (Dinamic Link Library) que são carregadas pelo servidor web em seu próprio espaço de endereço, onde são mantidos na memória por um determinado tempo. Uma vez solicitada, a DLL é carregada e o servidor passa a executar solicitações individuais através de processamento dentro do processo principal, ao invés de carregar ou ativar outra DLL ou EXE novamente, como é feito com outras tecnologias. Quando o servidor recebe uma solicitação, ele carrega a DLL (se isso ainda não tiver sido feito) e executa o código apropriado. Quando uma outra solicitação é feita o servidor tem condições de manter o mesmo processo na memória apenas duplicando o contexto e o contador de instruções do mesmo. De forma que a nova solicitação ocorre somente dentro da memória, característica essa que faz com que os containers ISAPI sejam muito mais rápidos do que aplicações CGI tradicionais. O principal inconveniente (e também principal vantagem) das DLLs de API do servidor é sua forte integração com o mesmo. Por um lado isso é bom porque o ganho em

4 velocidade de resposta é considerável, por outro lado, porém, uma eventual falha em uma DLL que viesse a produzir um vazamento de memória poderia fazer com que todo o Servidor Web ficasse indisponível. Outro inconveniente é que pelo fato da DLL estar constantemente na memória do servidor, uma eventual atualização da mesma somente seria necessária mediante uma desativação temporária do servidor [CAN99]. Uma dificuldade encontrada na construção do web service em um container foi que após um certo tempo de utilização do serviço pelas aplicações clientes, o mesmo ficava indisponível, impossibilitando inclusive o acesso remoto ao servidor web. A estratégia adotada foi a substituição da ISAPI por um web service dentro de um CGI (Common Gateway Interface). CGI é um protocolo padrão para comunicação entre um cliente web (navegador, por exemplo) e o servidor web. É amplamente utilizado embora sua eficiência possa ser questionada sobre vários aspectos. Ele permite que o navegador solicite e envie dados, tendo por base a saída padrão de linha de comando de um aplicativo de console. Quando o servidor detecta uma solicitação de página do aplicativo CGI, ele ativa o aplicativo, passa os dados de linha de comando da solicitação de página e depois envia a saída padrão do aplicativo de volta para o computador cliente. Aplicativos avançados acabam sendo complexos de especificar utilizando CGIs, mas no caso do nosso aplicativo, essa tecnologia apenas vai servir como container web, uma vez que todas as regras estarão especificadas no web service. A WSDL é uma especificação da linguagem XML usada para descrever serviços da rede. Permite que uma aplicação descreva suas funcionalidades e atributos em um formato padrão de tal forma que outra aplicação possa compreendê-la. É considerado como um dos fundamentos que possibilita a especificação consistente de um web service [FER02] As informações enviadas Documento XML O objetivo da pesquisa é de coletar informações sobre o status dos computadores quando entram em modo de descanso, de forma que para a pesquisa não é necessário identificar usuários ou a utilização dos computadores. A informação enviada da aplicação cliente para o web service é descrita em XML, um padrão aberto para descrição de dados. Existem dois tipos de informações que são enviadas e armazenadas. A primeira delas é referente às Informações do Computador. Estes dados são enviados uma única vez sempre que a máquina executar pela primeira vez a proteção de tela ou então no ato da instalação utilizando o seu instalador próprio. Neste momento são persistidas as seguintes informações: Endereço MAC (MAC Address) e endereço IP; Data, hora e fuso horário da máquina local, bem como data e hora e recebimento dos dados pelo servidor; Dados do sistema operacional (plataforma, versão, compilação, idioma, atualizações); Dados do(s) processador(es) (tipo, modelo, velocidade); Resolução de vídeo e número de cores utilizadas pelo usuário; Existência ou não de placa de som; Existência ou não de conexão com energia (no caso de notebooks); Nome da proteção de tela padrão da máquina e tempo de espera da mesma;

5 Já a segunda é referente às Informações do Status Computador. Estas que são enviadas a cada 5 minutos de inatividade do mesmo bem como no ato de uma re-instalação acidental (quando já existe uma cópia da proteção de tela na máquina do usuário). Sempre que é feito o envio de dados sobre a máquina, as informações sobre seu status também são persistidas. As quais são: Data, hora e fuso horário da máquina local, bem como data e hora e recebimento dos dados pelo servidor; Tempo de espera da proteção de tela; Indicativo de início de conexão (indicando que foi o primeiro envio ou não de uma seqüência); Dados sobre o status da memória (memória física total e disponível, memória virtual total e disponível e tamanho máximo da área de swap bem como percentual disponível); Dados sobre o status da CPU (percentual de utilização); Dados sobre os discos (unidades disponíveis, e para as unidades fixas: capacidade total e disponível); Não existe armazenamento local das informações. Quando um documento XML é construído para ser enviado e devido a alguma falha de comunicação o mesmo não possa ser enviado as informações capturadas são destruídas em tempo de memória Modelo e Persistência de Dados Para persistir as informações coletadas pelos computadores participantes da pesquisa foi utilizado o SGBD DB2 v.8.2, o mesmo utilizado administrativamente pela instituição onde o trabalho foi realizado. O modelo de dados teve de ser pensado de forma a garantir a concorrência entre as demais aplicações bem como evitar mecanismos que viessem a tornar o mecanismo de persistência mais pesado A aplicação cliente A aplicação cliente, que faz o envio dos dados ao web service foi inicialmente desenvolvida para os sistemas operacionais MS Windows. Essa escolha deve-se às características da instituição onde o software seria testado, onde a grande maioria das estações utiliza este sistema operacional. Mas isso não impede, porém, que outras aplicações clientes sejam construídas uma vez que a interface do serviço esta disponível para ser utilizada através de padrões abertos. A proteção de tela InfoMaq (o aplicativo cliente) foi construída utilizando-se várias técnicas de tolerância a falhas para evitar que o usuário se sinta prejudicando em um eventual indisponibilidade/problema com o web service que viesse a trancar a máquina do usuário ou leva-lo a tomar outras providências que não um simples toque no mouse ou teclado. Para tanto todas as ações dentro da mesma (animação, envio de informações, empacotamento do status ) foram feitas através de linhas de execução ou threads. Onde as ações acontecem de forma paralela evitando que o aplicativo fique bloqueado esperando a conclusão de determinado processo. 4. Resultados Preliminares O protótipo foi testado por alguns voluntários até o momento em que foi realizada a instalação em massa da proteção de tela em todos os laboratórios de uso acadêmico. A partir deste momento os resultados dos status enviados pelos computadores foram sendo analisados, de forma a produzir alguns resultados preliminares. A Tabela 1 demonstra a quantidade de registros em um mês de avaliação:

6 MAQUINAS (considerando somente as ativas) STATUS_MAQUINA STATUS_DISCOS STATUS_CPU STATUS_MEMORIA Tabela 1 Número de registros avaliados 399 registros registros registros registros registros A seguir serão levantados alguns dados considerando os aspectos principais aos que o trabalho se destina a estudar Utilização de CPU O consumo de CPU é uma das principais medidas a que o trabalho destina-se a observar. Essas informações podem embasar projetos e trabalhos futuros na criação de regras de escalonamento baseando-se nos históricos computados, classificando os computadores como de baixa ou alta exigência de CPU. A partir do levantamento de dados, temos status válidos enviados, sobre os quais se obtém uma média de utilização de CPU de 4,18%, com picos que vão aos extremos de subutilização e superutilização (0,01% e 99,99%). Considerando as faixas de horário, conforme a tabela 2, observamos que a exigência maior de consumo de CPU (com o computador em modo de espera) se dá no período da tarde. E a menor, durante a madrugada. As variações entre a menor e a maior utilização dentro dos horários determinados é quase insignificante. Tabela 2 Consumo médio de CPU por horário Horário Média Máx. Min. (Mhz) (Mhz) (Mhz) Status Enviados 06:00:00 as 11:59:59 4,63 99,99 0, :00:00 as 23:59:59 3,93 99,99 0, :00:00 as 17:59:59 5,00 99,99 0, :00:00 as 05:59:59 3,26 99,86 0, Ao observamos a média da velocidade dos processadores que participam da pesquisa temos um resultado bastante surpreendente: mais de 1Ghz. Também é preciso considerar os limites, onde o computador de menor velocidade apresentou-se com 233 Mhz enquanto que a máquina de maior poder de processamento tinha 2.8Ghz. Novamente nos surpreendemos com o poder de processamento disponível, considerando a capacidade máxima de todos os computadores da pesquisa, que fica em torno de 506,8 Ghz Utilização de Memória Tão importante quanto o poder de processamento, a utilização e a capacidade disponível de memória são características importantes a serem consideradas no projeto dos sistemas distribuídos. Novamente os resultados obtidos são positivos. Tem-se em média 235,56Mb de memória RAM por computador, com valores de extremos que chegam a 1535,48Gb e 55,48Mb. Totalizando a quantidade física de memória disponível, o total de recursos seria de 93,99 Gb de memória física total.

7 Em relação à memória disponível, tem-se que em média os computadores que participaram da pesquisa apresentam 116,23 Mb livres, o que representa algo em torno de 50% da memória total disponível nos computadores. Observando os horários de inatividade dos computadores, percebemos uma situação bastante diferente em relação à utilização do processador: durante a madrugada a quantidade de memória disponível é maior do que o existente no período da tarde (onde a exigência de processador é maior). Essa situação pode ser evidenciada a partir da tabela 3: Tabela 3 Memória física disponível por horário Horario Média (Mb) Max. (Mb) Mín. (Mb) 06:00:00 as 11:59:59 113,22 151,11 52,70 00:00:00 as 05:59:59 109,61 148,48 7,29 18:00:00 as 23:59:59 112,68 149,56 5,27 12:00:00 as 17:59:59 113,83 151,11 5, Capacidade de Armazenamento Para realizar a distribuição e processamento, o espaço em disco não é tão importante, porém, existem iniciativas que estudam a possibilidade de utilizar a capacidade não utilizada dos discos para construção de aglomerados distribuídos para persistência de informações, uma espécie de sistema de arquivos virtual. A partir dos status recebidos observa-se que em média os computadores possuem 19,8 Gb de espaço total. Sendo que a maior unidade lógica encontrada tinha uma capacidade total de 72 Gb e a menor de 20 Mb (possivelmente uma partição). Considerando o espaço disponível, os dados são interessantes: em média tem-se 14,42 Mb de espaço livre, o que representa 72 % do espaço dos discos/unidades lógicas (em média). O sistema de arquivos predominante nos computadores é o NTFS, com 95% de predominância em relação ao FAT32, que ainda é utilizado em alguns computadores. Também foi possível determinar que praticamente todos os computadores possuem unidades de disco flexível e que 75% dos computadores que participaram da pesquisa apresentam unidades para leitura de discos óticos. A capacidade total de armazenamento, considerando as unidades lógicas dos discos fixos é de 8,83 Tb, sendo que deste total, temos em média cerca de 72% do espaço disponível Outras Informações Outra informação importante a ser destacada é que a grande maioria dos computadores que fizeram uso da proteção de tela utilizam o sistema operacional Windows 2000, cerca de 80%. O idioma predominante, como era de se esperar é o português, embora existam exceções que fazem uso de idiomas como Inglês (Estados Unidos) e Italiano (Itália). Também é importante destacar um certo empate técnico entre as resoluções de vídeo 800x600 e 1024x768, o que demonstra um crescimento significativo desta última, que até pouco tempo atrás era tida como de pouca utilização.

8 6. Conclusões e Trabalhos Futuros Foi uma grande satisfação o fato de conseguir concretizar o trabalho e poder avaliar os dados coletados. Considerando os cruzamentos e análises sobre os dados, a conclusão a que se chega é de que existe uma grande quantidade de recursos computacionais que poderiam ser aproveitados para distribuição de processamento. A tecnologia utilizada também se apresentou portável e aplicável para a distribuição de processamento. Embora apresente uma performance baixa, a portabilidade e independência de softwares adicionais fazem com que web services sejam uma alternativa interessante para troca de mensagens em ambientes heterogêneos como a internet. A partir do volume dos dados coletados é possível avaliar de forma positiva uma implementação para distribuição de processamento utilizando web services. Pela característica cliente/servidor da tecnologia em questão, a implementação de uma solução computacional com a utilização da mesma deveria considerar a existência de um escalonador para distribuir de forma balanceada o processamento bem como um mecanismo de coleta das respostas de forma centralizada. Como trabalho futuro, a idéia é criar uma espécie de protocolo ou sub-linguagem baseada em XML para enviar aos nodos processadores um conjunto de instruções (também codificadas em XML) e um conjunto de dados sobre os quais o processamento seria aplicado. Após o processamento do documento recebido, a aplicação cliente se encarrega de devolver um outro documento XML com o resultado obtido. É importante destacar também que a tecnologia aplicada dificilmente poderia ser utilizada em processamento de alto desempenho, uma vez que os gargalos de decodificação são muito grandes. Por outro lado, a utilização de padrões baseados em XML garante um alto grau de flexibilidade e padronização para o desenvolvedor. 7. Referências Bibliográficas BAR02 BARRETO, Marcos E. Estudo sobre Computação baseada em Clusters e Grids. Exame de Qualificação EQ-071 PPGC-UFRGS. Porto Alegre, Disponível em < Acesso em Maio/2004. BON03 BONIATI, Bruno B.; PADOIN, Edson L. Web Services como Middlewares para Interoperabilidade em Sistemas. Revista da URCAMP (ISSN ), volume 7, número 12, Agosto/2003. Bagé - RS: Editora EDIURCAMP. CAN99 CANTÙ, Marco. Dominando o Delphi 5. São Paulo: Makron Books, FER02 FERNANDES, Bruno V.; VALENTE, Eduardo V.; FERNANDES, Ricardo J. Web Services. Campinas, Disponível em: < Acesso: em Maio/2003. JES01 JESDANUN, Anick. Três milhões buscam vida extraterrestre. Associated Press. Disponível em: < Acesso em Junho/2004.