Várias aplicações comerciais e científicas exigem cada vez mais poder de computação, poder esse possibilitado pelo barateamento dos computadores de alto desempenho. Atualmente existe uma crescente demanda pelo uso de computadores de alto desempenho, tanto aplicados no meio científico (processamento genômico, física de partículas, simulações de física e engenharia, entre outros) quanto na indústria (prospecção de petróleo, animação gráfica ou e-commerce, por exemplo).
Motivação
Objetivo
Organização do texto
Este capítulo apresenta a plataforma de simulação de grid iSPD desktop, que é o objeto de trabalho deste projeto, apresentando uma visão geral da mesma, e destacando a descrição de como lidar com a criação e gerenciamento de cargas de trabalho nesta ferramenta.
Visão geral da plataforma de simulação de grades com- putacionais iSPD
Interface icônica
A Figura 2.4 mostra a janela de configuração do payload aleatório, onde é possível ver primeiro o campo do número da tarefa, seguido pelos campos de configuração do tamanho da computação e tamanho da comunicação e por último o campo de entrada do parâmetro de tempo de chegada. A Figura 2.5 mostra a janela de configuração de carga para o nó de computação, onde o nó principal no qual o conjunto de tarefas é aplicado, o número de tarefas a serem criadas e o usuário que as possui são selecionados nos campos, juntamente com os campos de entrada para o tamanho do cálculo e tamanho da comunicação.
Interpretador de modelos
Motor de simulação
Gerador de políticas de escalonamento
Considerações finais
Este capítulo fornece uma introdução às cargas de trabalho e sua importância, com foco maior em cargas de trabalho realistas extraídas de execuções de aplicativos reais.
Cargas de trabalho
Traces de aplicações de alto desempenho
Para o iSPD, um banco de rastreamento de cargas de trabalho realistas foi fornecido, mas não implementado. No entanto, há alguma dificuldade em encontrar formatos de rastreamento de alta qualidade disponíveis, com boa documentação e em boa quantidade. O formato de rastreamento SWF (PWA, 2012g) é gerenciado pelo PWA (Parallel Workloads Archive) (PWA, 2012c), sob a coordenação do Prof.
Latência: A diferença em segundos entre o tempo de despacho da tarefa e o tempo em que ela começa a ser executada efetivamente. O valor 0 indica falha na execução da tarefa, o valor 1 significa que a execução da tarefa está concluída, o valor 2 significa execução parcial da tarefa que será continuada, o valor 3 representa a última execução parcial, com o tarefa concluída, o valor 4 a última execução parcial da tarefa, mas falhou e, finalmente, o valor de status 5 significa que a tarefa foi cancelada por algum motivo;. ID da tarefa: um contador que identifica a tarefa, correspondente ao número da tarefa do padrão SWF;.
Considerações finais
Seguindo a fundamentação teórica apresentada nos capítulos 2 e 3, este capítulo tem como objetivo descrever o desenvolvimento deste trabalho e apresentar toda a estrutura desenvolvida para inclusão de banco próprio de cargas reais. Assim, este capítulo abrange desde o processo de identificação e especificação de um padrão para o iSPD e conversão de padrões externos de trilha para o padrão iSPD, até a identificação do processo de inserção de cargas no iSPD, desenvolvendo o processo. simulação de carga obtida a partir de traces e por fim o processo de extração de traces das simulações realizadas. A Figura 4.1 mostra um diagrama de casos de uso para iSPD em termos de manipulação de cargas de trabalho de rastreamento.
Esses casos de uso guiaram todo o projeto para incluir cargas reais e os elementos a serem descritos neste capítulo.
Especificação do padrão de trace próprio para o iSPD
Status da tarefa: Indica o status de execução da tarefa, de acordo com os padrões de formato SWF e GWF, no estado atual da implementação do mecanismo de simulação iSPD, representa um valor que indica a execução completa da tarefa; Proprietário da Tarefa: Campo que se refere ao usuário proprietário da tarefa, indicado pela cadeia de caracteres ;. Hora de chegada: informa a hora de envio da tarefa no sistema, medida em segundos e relativa à chegada da primeira tarefa a ser executada.
Considerando a descrição das características necessárias para o arquivo trace, foi definido que o arquivo utilizado para a composição do banco de cargas realistas seguiria um documento padrão construído por XML, seguindo o mesmo conceito para construção do modelo IMS (Iconic Model de Simulação) usado para modelagem de grade através da interface icônica descrita na seção 2.2. A Figura 4.2 mostra a seção de verificação de conformidade padrão WMS do arquivo "iSPDcarga.dtd" para rastreamento de cargas. Pode-se ver que uma carga útil de rastreamento iSPD consiste em dois elementos, o formato de origem e as tarefas contidas no rastreamento.
Construção de componente conversor de arquivos de trace
A Figura 4.4 apresenta um diagrama do processo de conversão, focando no funcionamento do método convert() da classe Interpretador.java, que na verdade é responsável por converter os formatos externos para o padrão WMS, que ao final do processo são incluídos no banco de dados de cargas reais, enquanto a figura 4.5 apresenta o fluxo de execução deste método. A Figura 4.6 mostra um pequeno exemplo de arquivo no padrão SWF, destacando os campos utilizados durante a conversão. Assim, após o processo de conversão descrito nesta seção, o arquivo criado pelo exemplo mostrado na Figura 4.6 é mostrado na Figura 4.7.
No caso de conversão de arquivos GWF para o padrão WMS, o processo é semelhante à conversão de arquivos SWF, pois esse padrão de arquivo de rastreamento é uma extensão do padrão SWF. Para resolver esta diferença, no caso de um trace extraído de um padrão GWF, o valor do horário de chegada é recalculado em relação à primeira tarefa. A Figura 4.9 mostra o arquivo WMS gerado a partir do exemplo descrito na Figura 4.8, onde os valores dos campos extraídos são marcados com o mesmo padrão de cores.
Adaptação do iSPD para utilização de cargas de tra- balho obtidas de traces
Conversão de arquivo externo: se o padrão de arquivo selecionado for externo, o objeto Interpreter chama o método convert(), que retornará um arquivo de carga WMS extraído do arquivo trace original, além de informações sobre a origem (formato ) e o número de tarefas contidas em tal arquivo. Lendo um arquivo WMS já existente: Neste caso, o objeto Interpreter chama o método LerCargaWMS(), que verifica a integridade do arquivo WMS, retorna o arquivo selecionado, sua origem (formato) e a quantidade de tarefas contidas. Ao final do processo de leitura, com a confirmação do usuário, a ferramenta é configurada para gerar a carga a ser simulada a partir do modelo de carga da via gerado.
Desta forma, o esquema de abertura e configuração do arquivo a ser carregado do banco de arquivos trace é apresentado na Figura 4.11. Ao incluir a opção de usar arquivos de rastreamento como modelos de carga de trabalho, é interessante que o iSPD também possa gerar rastreamentos. Dessa forma, ao final da execução do iSPD, você pode salvar a carga de trabalho simulada em um arquivo.
Simulando cargas de trabalho reais
As subseções a seguir discutem o processo de geração de carga a ser simulado a partir de cada formato de rastreamento. Dado que o formato de rastreamento de geração de carga SWF ou GWF é selecionado, as tarefas no arquivo são divididas entre os principais (agendadores) presentes no ambiente de rede modelado e um objeto Task da classe Task é criado a partir de cada linha de descrição no arquivo .java contido no pacote ispd.motor.filas e adicionado à lista de tarefas a serem simuladas. Job ID: recebe como parâmetro o valor do atributo "id" do job lido no arquivo WMS;
O usuário proprietário: recebe como parâmetro o valor do atributo "usr" do job lido no arquivo WMS; Ao final deste processo, uma lista de tarefas é compilada e o processo de simulação ocorre normalmente, permitindo a criação de uma trilha de simulação da trilha selecionada e simulada. Após gerar a lista de tarefas para o padrão iSPD, o processo de simulação é executado normalmente e, finalmente, os resultados da simulação são exibidos.
Especificação da interface usuário-aplicação para uso do banco de cargas
Opção de Conversão de Upload Extraído: Nesta opção, quando o usuário clicar no botão "Abrir", o caminho do arquivo selecionado é exibido em uma caixa retangular ao lado do botão.
Considerações finais
Um primeiro teste apresenta um estudo de custo temporal e espacial para a conversão de trilhas externas para o padrão WMS. Esses testes são considerados úteis apenas no desenvolvimento do aplicativo, que só é útil se você fizer a conversão corretamente.
Teste de custo de conversão de trace
Para o padrão SWF, 5 amostras foram selecionadas dos 30 arquivos disponíveis no PWA (PWA, 2012c), e tais amostras foram selecionadas com base na variedade de tamanhos de arquivo e número de tarefas. Com relação aos custos de tempo de conversão, a Figura 5-2 mostra uma relação entre o número de tarefas que compõem o rastreamento e o tempo necessário para convertê-lo para o padrão WMS. Pode-se observar uma progressão linear dos custos de conversão, o que se justifica pelo fato de o método utilizado passar apenas uma vez linearmente pelo arquivo, para que o processo de conversão seja realizado.
Observa-se que no caso da conversão de um arquivo GWF, o arquivo WMS resultante fica aproximadamente entre 40% e 50% do tamanho do arquivo GWF original. Com relação aos custos de tempo de conversão, a Figura 5.4 mostra a relação entre o número de tarefas de rastreamento GWF e o tempo gasto na conversão para o padrão WMS. Como no exemplo anterior, pode-se observar uma tendência linear dos custos de conversão.
Cargas de trabalho reais aplicadas ao estudo de políti- cas de escalonamento
Job Queuing: Este é um algoritmo estático, como Round-Robin, mas em que o escalonamento ocorre sob uma política de enfileiramento simples, onde dado que uma máquina é capaz de executar a tarefa, tal tarefa será atribuída a esta máquina; . Os resultados obtidos para as métricas apresentadas mostram pouca diferença entre os algoritmos Workqueue e Round-Robin, o que era esperado devido à pequena diferença entre essas políticas. Já o DynFPLTF apresenta maior ociosidade de processamento, o que também era esperado por utilizar mais informações que os outros dois.
As Figuras 5.6, 5.7 e 5.8 apresentam gráficos de utilização de recursos para cada política de escalonamento, destacando cada nó no ambiente experimental. Esta demonstração mostra mais claramente as diferenças no comportamento de execução entre diferentes políticas de agendamento. Pode-se observar que no escalonamento Round-Robin, as tarefas foram distribuídas uniformemente entre os recursos.
Considerações finais
Este trabalho apresentou uma visão geral de conceitos fundamentais em avaliação de desempenho, simulação de eventos discretos e principalmente caracterização de carga de trabalho. Por fim, a principal contribuição deste trabalho foi o desenvolvimento e validação de toda a estrutura necessária para a inclusão de um banco de cargas flexível e realista, através da possibilidade de obtenção de cargas de trabalho extraídas de rastros de aplicações poderosas para esta plataforma de simulação, além da capacidade de gerar cargas derivadas de run traces de simulações executadas pelo usuário.
Considerações finais
Problemas encontrados
Direções futuras
Publicações
Dissertação de Mestrado, Instituto de Biociências, Letras e Ciências Exatas (IBILCE), Universidade Estadual Paulista "Júlio de Mesquita Filho" (UNESP), Campus São José do Rio Preto, São José do Rio Preto.
