Dentro desse ambiente, podemos destacar o uso de redes de computadores e formas de avaliar seu desempenho. Assim, o objetivo deste trabalho é apresentar mais um módulo iSPD, o módulo de exportação de modelo para GridSim.
Motiva¸ c˜ ao
Objetivo
Organiza¸ c˜ ao do texto
Este capítulo apresenta os principais conceitos dos simuladores de Grid Computing iSPD e GridSim, bem como uma visão geral dos outros principais simuladores atualmente em uso, além de uma breve revisão dos conceitos de Compiladores e Linguagens Formais.
O iSPD
Intérprete de modelos internos: No iSPD, o modelo icônico é construído a partir daquele projetado na interface gráfica. Também é responsável pelo resultado e pelas métricas de simulação retornadas ao usuário (SILVA, 2012).
GridSim
Finais de semana e feriados podem ser mapeados no momento da criação, o que significa que as variações de carga podem ser modeladas incluindo essas datas. As tarefas podem ser heterogêneas, o que significa que podem exigir muito processamento ou até mesmo muita entrada e saída.
Outros Simuladores
Conceitos de Compiladores e Linguagens Formais
Um tradutor nada mais é do que um software cujo objetivo é traduzir entre diferentes tipos de idiomas. Além disso, em tipos especiais de linguagens de programação, uma das quais é aquela em que o usuário se sente mais confortável, ou seja, as chamadas de alto nível, e a outra, as chamadas de baixo nível, que o computador entende . Mostra que o compilador é dividido em 6 etapas, que são agrupadas em duas fases: análise e síntese.
Na análise é feita uma representação intermediária do programa fonte, e na Síntese é feita a construção do programa alvo (SETHI RAVI; JEFFREY; LAM, 2008).
Considera¸ c˜ oes finais
O objetivo deste capítulo é mostrar tudo o que foi desenvolvido para a implantação do projeto. Desta forma, é apresentado como o iSPD realiza a análise do modelo icônico e como armazena os dados desta análise para serem utilizados posteriormente na criação do modelo externo. E também o mais importante: você pode ver como o Exportador está estruturado e sua relação com o restante do sistema, ou seja, como ocorre a análise do modelo icônico e como seu resultado é utilizado pelo módulo de exportação.
O modelo icˆ onico do iSPD e sua an´ alise
Assim, todos os outros módulos que precisam do modelo de ícone, inclusive o exportador, obtêm tal árvore. Dentro do simulador, conforme mencionado anteriormente na Seção 2.1, caso o usuário opte por simular em iSPD, o modelo de ícone é convertido para o modelo simulável, que é uma próxima linguagem, pronta para ser processada pelo motor de simulação iSPD. Esta seção apresenta as gramáticas de conversão do icônico modelo iSPD para GridSim.
As regras de construção do modelo icônico definem primeiramente todos os elementos contidos no modelo, sejam eles Máquinas, Clusters, Link, Internet ou mesmo Usuário. Para a transformação do icônico modelo iSPD para GridSim, foram construídas diversas regras, ou seja, uma gramática de conversão entre os dois tipos de modelos. Para criar a carga de trabalho, as tarefas no modelo icônico são primeiro identificadas com base nas regras mostradas na Figura 3.6.
Desenvolvimento do Exportador
As primeiras linhas deste arquivo são as bibliotecas necessárias para a correta execução posterior do modelo. A outra classe construída, o Model, é a que contém a maior parte das informações do Grid modelado, sendo as máquinas escravas e instanciação de objetos que representam os mestres, bem como o modo de conexão entre eles. Tal construção pode ser vista na Figura 3.9, que é um diagrama de classes UML de um modelo genérico em GridSim produzido pelo Exportador.
Ou seja, toda exportação feita terá essas duas classes, alterando apenas o conteúdo dos métodos internos de cada classe. Para uma construção completa na classe Model, são utilizadas listas com as informações de cada componente da rede, percorrendo cada um deles. Dentro deste método, para criar recursos, são instanciados objetos da classe GridResource, específicos do GridSim.
Incorpora¸ c˜ ao do Conversor com o Simulador iSPD
A classe AreaDesenho já está feita, mas é necessário apresentá-la, pois é a partir dela que todos os parâmetros do modelo são analisados e transferidos para as demais classes do simulador que forem necessárias. Para isso, um objeto da classe GridSim Executor é instanciado dentro deste método, utilizando seus métodos para receber parâmetros e escrever o arquivo em um modelo no GridSim. É importante ressaltar que tanto a classe JPrincipal quanto a DesignArea contém mais métodos e funcionalidades do que os mostrados na Figura 3.10, mas isso não é necessário para o entendimento ou desenvolvimento deste projeto.
É importante ressaltar que, para utilizar o módulo de exportação, o modelo deve estar completo, ou seja, a configuração de todos os parâmetros das máquinas, dos clusters, dos algoritmos de escalonamento e das cargas de trabalho devem estar totalmente concluídas. Finalmente, a Figura 3.12 mostra os casos de uso de como os modelos são exportados para o GridSim. Como você pode ver, o usuário deve primeiro construir seu próprio modelo ou abrir um modelo existente, após o qual ele pode exportá-lo.
Considera¸ c˜ oes Finais
Caso de uso Quem inicia a ação Descrição do caso de uso Criar novo usuário modelo O usuário acessa o sistema. Resultados do usuário Após a simulação, os resultados são entregues ao usuário. Exportar modelo para o usuário do GridSim A partir do modelo finalizado, o usuário pode exportá-lo para o GridSim.
Neste capítulo são apresentados os testes que validam a exportação de modelos através de tempos de simulação. Para apresentá-los, primeiramente é mostrada uma grade modelada no iSPD, e em seguida é realizado todo o processo de conversão, obtendo-se um modelo no GridSim. Em seguida, todos os modelos são simulados e obtém-se o tempo de simulação, ou seja, o tempo que o sistema proposto levaria para realizar a carga especificada.
Teste com um Modelo Simples
Assim, cada modelo terá um baixo volume de comunicação e computação, depois um baixo volume de comunicação e alta taxa de computação, depois um alto volume de comunicação e baixa taxa de computação e, finalmente, um alto volume de comunicação e computação. Para dar um exemplo do que acontece quando tal processo ocorre, a Figura 4.2 mostra um trecho do código executado. Como é possível observar, o método createResource é chamado sete vezes, visto na Figura 4.2 nas linhas 1 (um) a 7 (sete), que faz a própria criação, a partir de parâmetros como capacidade de processamento.
E então todos esses recursos são adicionados a uma lista de escravos, vista na Figura 4.2 nas linhas 10 (dez) a 16 (dezesseis), que posteriormente serão utilizados na criação do mestre, passando seus escravos como parâmetro para instanciá-lo. Os resultados das médias dos tempos de simulação são apresentados no gráfico da Figura 4.3. E também possui comunicação de 3 Mbit, ou seja, essas tarefas precisam de 3 Mbit para trafegar na rede da rede.
Teste com um Modelo com N´ os Remotos
Observando a Figura 4.9, pode-se verificar a criação de um roteador conectando os recursos icon0 e icon1, via método attachHost. As tarefas neste teste possuem 50 Mflops de computação e também 3 Mbit de comunicação. Os resultados das médias dos tempos de simulação são apresentados no gráfico da Figura 4.10.
Os resultados das médias dos tempos de simulação são apresentados no gráfico da Figura 4.11. Os resultados das médias dos tempos de simulação são apresentados no gráfico da Figura 4.12. A maior diferença entre o resultado do modelo simulado no iSPD e o convertido para GridSim ocorreu em 500 tarefas e foi de 6,7%.
Teste com um Modelo com Dois Servidores
As tarefas neste teste possuem 50 Mflops de computação e também 3 Mbits de comunicação. Os resultados das médias de tempo de simulação são apresentados no gráfico da Figura 4.16. A maior diferença entre o resultado do modelo simulado no iSPD e o convertido para GridSim foi de 1,7%, o que ocorreu em 4000 tarefas.
A diferença máxima entre os resultados do modelo simulado no iSPD e o convertido para o GridSim foi de apenas 2,3%, o que ocorreu com 500 tarefas. Os resultados das médias dos tempos de simulação são apresentados no gráfico da Figura 4.18. A maior diferença entre o resultado do modelo simulado no iSPD e o convertido para o GridSim ocorreu com 250 tarefas e foi de 2,5%.
Considera¸ c˜ oes finais
Este trabalho apresentou os conceitos de análise e conversão de modelos de diferentes simuladores de grid, mais especificamente entre iSPD e GridSim. Além disso, foi realizada uma revisão sobre Linguagens Formais e Compiladores, pois são importantes para o entendimento deste projeto. Assim, a maior contribuição deste trabalho se deve ao aumento da usabilidade do iSPD.
Desta forma, um usuário que já especificou seu modelo no iSPD não precisa construí-lo novamente no GridSim, se assim o desejar, caso queira um segundo resultado de simulação. Ou mesmo se você quiser apenas usar a interface gráfica iSPD para facilitar a modelagem.
Considera¸ c˜ oes
Problemas Encontrados
Dire¸ c˜ oes Futuras
Publica¸ c˜ oes
Desenvolvimento de plataforma de simulação de grid: Módulo para interpretação de modelos externos e módulo para exportação de modelos icônicos. Desenvolvimento de Plataforma de Simulação de Grid: Módulo de Exportação de Modelos Icônicos. Desenvolvimento de uma plataforma de simulação de grade computacional: Módulo para interpretação de modelos externos e módulo de saída para modelos icônicos.
Desenvolvimento de uma plataforma de simulação de rede: Módulo de exportação de modelos icônicos. Assim, a Figura A.5 mostra todo o código do método createResource, a criação dos recursos, através da instanciação de um objeto da classe GridResouce específica do GridSim. E, finalmente, a Figura A.6 mostra como a carga de trabalho é criada, neste caso criando Gridlets.
