http://simgrid.gforge.inria.fr/doc/index.html Estudo sobre SimGrid Visão Geral sobre a ferramenta SimGrid O SimGrid possui basicamente três camadas: Camada do ambiente de programação (Programmation environments layer) SimGrid fornece vários ambientes de programação construídos no topo do kernel de simulação único. Cada ambiente foca um público específico e constitui um paradigma diferente. Para escolher um deles é necessário que você pense sobre o que você quer fazer e o que deve ser o resultado do seu trabalho. 1. Se você quer estudar um problema teórico e comparar várias heurísticas, você provavelmente usará o MSG. Ele deve permitir construir facilmente simulações multi-agentes bastante realista. No entanto, o realismo não é o principal objetivo deste ambiente e as questões técnicas mais incômodas da plataforma real são mascaradas aqui. 2. Se você quer estudar o comportamento de aplicações MPI usando técnicas de emulação, você deveria olhar ambiente de programação SMPI (Simulated MPI). Este ambiente ainda está em desenvolvimento. 3. Se você quer desenvolver uma aplicação distribuída real, então você achará o GRAS (Grid Reality And Simulation) muito útil. Além disso, existem duas implementações dessa API: uma no topo do SURF (SimUlation artifact) (permitindo desenvolver e testar sua aplicação no siimulador) e outra adaptada para implantação (deployment) em plataformas reais (permitindo que o resultado da aplicação seja altamente portável e extremamente eficiente). Mesmo se você não planeja executar seu código real, você pode querer escolher o GRAS se você pretende usar o MSG de uma forma muito intensiva (e.g. para simular um ambiente peer-to-peer). Camada de simulação do kernel (Simulation kernel layer) O núcleo das funcionalidades para simular uma plataforma virtual são fornecidos pelo módulo chamado SURF. Ele é muito baixo nível e não se destina a ser usado pelos usuários finais. Ao invés disso, ele servirá como base para uma camada de alto nível. As princípais características do SURF são uma rápida solução linear de max-min e a habilidade de alterar transparentemente o modelo usado para descrever a plataforma. Isto facilita enormemente a comparação de vários modelos existentes na literatura. Camada básica (Base layer) A base de todo o kit de ferramenta (toolkit) é constituída pelo XBT (extended Bundle of Tools). Ele é uma biblioteca portável fornecendo algumas características básicas como Logging Support, Exception
Support e Configuration Support. XBT também abrange as seguintes estruturas de dados convenientes: Dynar (generic dynamic array), Fifo (generic workqueue), Dict (generic dictionary), Heap (generic heap data structure), Set (generic set datatype) e Swag (0 ou 1 set datatype). http://simgrid.gforge.inria.fr/doc/group MSG C.html#MSG_examples MSG Native Se você quer usar a linguagem de programação C, você deve usar o MSG. Para usar a linguagem de programação Java, você deve usar o jmsg. Funcionalidades Oferecidas: Management Functions of Agents: corresponde a estrutura do agente de MSG (m_process_t) e as funções para gerenciá-los. Precisamos simular muitas decisões de escalonamento independentes, de modo que o conceito de processo seja o coração do simulador. Um processo pode ser definido como um código, com alguns dados privados, executando em um local (ver funções no site). MSG Data Types: fornece os diferentes tipos de dados encontrados no MSG (ver tipos no site). Management functions of Hosts: corresponde a estrutura do host do MSG (m_host_t) e as funções para gerenciá-lo. Uma localização (ou host) é qualquer lugar possível onde um processo pode rodar. Assim ele pode ser representado por um recurso físico com capacidades computacionais, alguns maiboxes (caixa de correio) para permitir a execução de processos que se comuniquem com outro remoto e alguns dados privados que podem ser acessados somente pelo processo local (ver funções no site). Managing functions of Tasks: descreve a estrutura das tarefas do MSG (m_task_t) e as funções para gerenciá-la. Dado que a maioria dos algoritmos de escalonamento invocam um conceito de tarefa que pode ser computado localmente ou transferido para outro processador, ele parece ser o nível correto de abstração para o nosso propósito. Uma tarefa pode então ser definida por um montante de computação, o tamanho de uma mensagem e alguns dados privados (ver as funções no site). MSG Operating System Functions: descreve as funções que podem ser usadas por um agente para manipular alguma tarefa (ver funções no site). Understanding channels: breve descrição da idéia de canal do MSG (m_channel_t). Por conveniência, o simulador fornece a noção de canal que fica próxima a noção de tag em MPI. Um canal não é uma socket. Ele não precisa ser aberto nem fechado. Ele corresponde especialmente as portas abertas em diferentes máquinas (ver funções no site). Platform and Application management: descreve as funções para gerenciar a criação da plataforma e a implantação da aplicação (ver funções no site). MSG simulation Functions: descreve as funções que você deveria conhecer para criar uma simulação (ver funções no site). Master/Slave Application Simulação de uma aplicação master-slave usando uma plataforma real e uma descrição interna de deployment (codificação no arquivo master_slave.c). O mestre possui algumas tarefas e as distribui, alguns escravos que processam tarefas sempre que as recebem e alguns agentes direcionadores (forwarder) que simplesmente passam as tarefas que recebem a alguns escravos.
Preliminary declarations: alguns includes e alguns protótipos de funções; Master code: essa função tem de ser atribuída ao m_process_t que se comportará como mestre. Ele não deve ser chamado diretamente, mas deve ser passado como parâmetro para MSG_process_create() ou registrado como uma função pública através de MSG_function_register() e então automaticamente atribuído ao processo através de MSG_launch_application(). Argumentos estilo o C (argc/argv) são interpretados como: o número de tarefas para distribuir; o tamanho da computação de cada tarefa; o tamanho dos arquivos associados a cada tarefa; a lista de hosts que aceitará essas tarefas. Tarefas dumbly são enviadas no estilo round-robin. Slave code: essa função tem de ser atribuída ao m_process_t que se comportará como escravo. Assim como a função mestre, ele não deve ser chamada diretamente. Essa função continua aguardando por tarefas e as executa assim que as recebe. Forwarder code: essa função tem de ser atribuída ao m_process_t que se comportará como um encaminhador (forwarder). Assim como a função master, ele não deve ser chamado diretamente. Argumentos no estilo C (argc/argv) são interpretados como uma lista de host que aceitará essas tarefas. Essa função continua aguardando por tarefas e as despacha aos escravos. Simulation core: essa função é o núcleo da simulação e está dividido em 3 partes graças ao MSG_create_environment() e MSG_launch_application(). Configuração da simulação: MSG_create_environment() cria um ambiente real; Implantação da aplicação: cria os agentes nos locais corretos com MSG_launch_application(); A simulação é executada com MSG_main(). Esses argumentos são: platform_file: o nome do arquivo contendo a descrição de uma plataforma válida surfxml; application_file: o nome do arquivo contendo a descrição de uma aplicação válida surfxml. Main function: isto inicializa MSG, executando a simulação, e libera todas as estruturas de dados criadas por MSG. Helping files: exemplo de arquivo de aplicação, exemplo de arquivo de plataforma (master_slave.xml). Quais as diferenças entre MSG, SimDag e GRAS? Todas elas permitem construir um protótipo da aplicação na qual você pode executar dentro do simulador. Todas compartilham o mesmo kernel de simulação, o qual é o núcleo do projeto SimGrid. Eles são diferentes na forma que você expressa sua aplicação. Com SimDag, você expressa seu código como uma coleção de tarefas paralelas interdependentes. Nesse modelo, as aplicações podem ser vistas como um DAG de tarefas. Esta é a interface de escolha para pessoas que querem portar seu antigo código desenvolvido para SimGrid v1 ou v2 para o último framework. Com ambos GRAS e MSG, sua aplicação é vista como um conjunto de processos de comunicação, trocando dados na forma de mensagens e executando computação por conta própria. A diferença entre ambos é que MSG é mais fácil de usar, mas GRAS não é limitado ao simulador. Uma vez escrito o código GRAS, ele pode ser executado tanto no simulador quanto em plataformas reais. Desta forma, GRAS fornece duas interfaces de implementação, uma para simulação e outra para execução real. Sendo assim, só é necessário relinkar o código para escolher um dos dois mundos. Visualizando e analisando os resultados Algumas vezes é conveniente ver como os agentes estão se comportando. Para isso, pode ser usado tools/msg_visualization/colorize.pl como um filtro para a saída MSG. Exemplo de linha de comando: #./msg_test platform.xml deployment.xml 2>&1 /home/legere/simgrid-3.2/tools/msg_visualization/colorize.pl Com isso teremos uma saída mais gráfica, Ele gera uma entrada para Paje.
Exemplo de Estrutura de Simulação Suponha a simulação com a seguinte estrutura (em /home/alan/simgrid/myfirstscheduler/): sched.h: descrição do núcleo do scheduler (i.e., com funções que podem ser usadas pelos agentes. Por exemplo, poderíamos encontrar as funções master, slave e forwarder; sched.c: um arquivo C incluindo sched.h e implementando o núcleo do escalonador. A maioria dessas funções usam funções MSG; masterslave.c: um arquivo C com a função main. i.e., a inicialização MSG (MSG_global_init()), a criação da plataforma (e.g., com MSG_create_environment()), a fase de deployment (e.g., com MSG_function_register() e MSG_launch_application()) e a chamada a MSG_main(). Para compilar esse programa, é sugerido o uso de um arquivo Makefile, ele é um arquivo genérico e pode ser encontrado em /media/dados/simegrid/makefile. Instalação da SimGrid Depois de baixar a versão mais atual e descompactar o pacote, você precisa digitar os seguintes comandos para a instalação: #./configure --prefix=$home configura a instalação para a arquitetura da máquina # make compila o programa # make check verifica os arquivos criados pela compilação e pela config. # make install instala o software Para desisntalar o SimGrid: # make uninstall # make clean Os arquivos serão instalados no diretório home do usuário, no meu caso foram criadas 4 pastas no diretório /root (bin doc include lib). SimGrid não é um binário, ele é uma biblioteca. Ambas versões estáticas e dinâmicas são disponibilizadas. Assim sendo, existem duas formas de linkar seu programa com SimGrid: ou você usa a versão estática, e.g. (neste caso, todas as funções do SimGrid são diretamente incluídas no MainProgram (um binário maior): # gcc libsimgrid.a -o MainProgram MainProgram.c ou você pode usar a versão dinâmica (neste caso, as funções da SimGrid não serão incluídas no MainProgram e você precisará definir sua variável de ambiente de tal forma que libsimgrid.so será encontrada no tempo de execução. Isso pode ser feito pela adição da seguinte linha em seu.bashrc): gcc -lsimgrid -o MainProgram MainProgram.c export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH Handling Very Large Platforms with the New S IM Grid Platform Description Formalism Marc-Eduard Frincu Martin Quinson Frédéric Suter INRIA Institut National de Recherche em Informatique et em Automatique A primeira versão do SimGrid tinha o objetivo de simular heurísticas de escalonamento em plataformas heterogêneas como redes de workstations. O SimGrid v.3.3 permite que os usuários definam suas próprias rotas explicitamente e una vários recursos das máquinas como memória, capacidade de disco, sistema operacional, placa de rede, número de núcleos da cpu, etc. Também algum grau de aleatoriedade pode ser adicionado ao poder computacional de cada host do custer. Os arquivos de plataforma da SimGrid usam a linguagem XML a fim de prover uma
semântica clara e nomes intuitivos para eles. A semântica definida oferece suporte para definir ambas máquinas únicas e clusters, para conectá-las usando rota fixa e para relacionar a traços extraídos de máquinas reais ou definidas pelo usuário. SimGrid utiliza arquivos de deployment externos para especificar a forma com que os processos são implantados na plataforma. Quanto a descrição da plataforma em si, SimGrid usa um formalismo baseado em XML. Na SimGrid 3.2 e 3.3 algumas tags e atributos foram renomeados. Por exemplo, as tags <platform_description> e <network_link> foram renomeadas como <platform> e <link> para reduzir sua verbosidade. Outra que teve o nome trocado como a tag <cpu> virou <host>. O nome attribute usado pela maioria das tags é agora id e nós contamos com: ctn como variante da tag <link> para substituir a tag <route_element>. As unidades usadas na SimGrid são: o poder computacional do host é expressado em um número de operações de ponto flutuante por segundo (flop/s) enquanto a largura de banda e a latência do link da rede são respectivamente medidos em bytes por segundo e segundos. power bandwidth latency Floating operations per second (flop/s) Bytes per second (B/s) Seconds (s) 3. SimGrid 3.2 DTD Aqui será apresentado a sintaxe e a semântica de diferentes tags declaradas no SimGrid DTD, como eles estavam disponíveis no release 3.2. 3.1. Especificando hosts Aqui é apresentado um exemplo de uma plataforma mínima compreendida de um único host chamado BOB onde sua CPU pode computar 500.000.000 flop/s (500Mflop/s). Especificando um host <?xml version= 1.0?> <!DOCTYPE platform SYSTEM "simgrid.dtd"> <platform version="1"> <host id="bob" power="500000000"/> A seguir, é visto os atributos opcionais da tag <host>. Expressing dynamicity: também é possível declarar discretamente um host cuja disponibilidade muda ao longo do tempo usando o atributo availability-file e um arquivo de texto separado cuja sintaxe é exemplificada abaixo: Adicionando um trace file <?xml version='1.0'?> <!DOCTYPE platform SYSTEM simgrid.dtd > <platform version= 1 > <host id= BOB power= 500000000 availability_file= bob.trace />
Exemplo de arquivo bob.trace PERIODICITY 1.0 0.0 1.0 11.0 0.5 20.0 0.8 No tempo 0, nosso host irá entregar 500Mflop/s. No tempo 11.0, ele entregará metade, isso é 250Mflop/s até o tempo 20.0, onde ele começara entregando 80% de sua capacidade (power), ou seja, 400Mflop/s. Finalmente, no tempo 21.0 (20.0 mais a periodicidade 1.0), nós voltamos ao início do loop e o host cederá novamente 500Mflop/s. Changing initial state: também é possível especificar se o host estará up ou down pela configuração do atributo state para qualquer ON (valor padrão) ou OFF. Explicitando o valor padrão ON <?xml version='1.0'?> <!DOCTYPE platform SYSTEM simgrid.dtd > <platform version= 1 > <host id= BOB power= 500000000 state= ON /> Expressing churn: para expressar o fato que um host pode alterar o estado ao longo do tempo (como em sistemas P2P), é possível usar um arquivo descrevendo o tempo no qual o host irá ligar ou desligar, conforme exemplo abaixo: Adicionando um arquivo de estado <?xml version='1.0'?> <!DOCTYPE platform SYSTEM simgrid.dtd > <platform version= 1 > <host id= BOB power= 500000000 state_file= bob.fail /> Exemplo de arquivo bob.fail PERIODICITY 10.0 1.0-1.0 2.0 1.0 Um valor negativo significa desligado enquanto um valor positivo significa ligado e executando. Do tempo 0.0 ao tempo 1.0, o host está ligado. No tempo 1.0, ele é desligado e no tempo 2.0, ele é ligado novamente até o tempo 12.0 (2.0 mais a periodicidade 10.0). Ele será ligado novamente no tempo 13.0 até o tempo 23.0, e assim por diante. 3.2. Especificando conexões de rede entre-hosts Para criar uma plataforma mais complexa com vários hosts, nós temos que especificar uma rede de conexão entre os diferentes hosts usando as tags <link>, <route> e <link:ctn>. 3.2.1. Declarando links de rede Links de rede representam um salto (one-hop) na conexão de rede. Eles são caracterizados por ambos
id e bandwidth. A latency é opcional com um valor padrão de 0.0. Por exemplo, nós podemos declarar um link de rede nomeado de LINK1 tendo largura de banda de 1Gb/s e uma latência de 50us. Exemplo de link <link id= LINK1 bandwidth= 125000000 latency= 5E-5 /> Expressando política de compartilhamento: por padrão, o link de rede é compartilhado (SHARED), isso se mais que um fluxo passa através do link, cada um obtêm uma parte igual da largura de banda disponível. De modo oposto, se um link é definido como FATPIPE, cada fluxo passa através desse link obtendo toda a largura de banda disponível, para qualquer número de fluxos. O comportamento do FATPIPE permite descrever switches ou Internet backbones. <link id= LINK1 bandwidth= 125000000 latency= 5E-5 sharing_policy= FATPIPE /> Expressando dynamicity e falhas: tal como para os hosts, é possível declarar links cujo estado, largura de banda ou latência mudem ao longo do tempo. Nesse caso, os atributos bandwidth e a latency são respectivamente substituídos pelos atributos bandwidth_file e latency_file e os correspondentes arquivos de texto. <link id="link1 state_file="link1.fail" bandwidth="80000000" latency=".0001" bandwidth_file="link1.bw" latency_file="link1.lat" /> Mesmo se a sintaxe for a mesma, a semântica dos trace files (arquivos de rastreamento) de bandwidth e latency diferem dos arquivos de disponibilidade de host. Esses arquivos não expressam a disponibilidade como uma fração da capacidade disponível mas diretamente em bytes por segundo para a largura de banda e em segundos para a latência. Exemplo de arquivo link1.bw PERIODICITY 12.0 4.0 40000000 8.0 60000000 Exemplo de arquivo link1.lat PERIODICITY 5.0 1.0 0.001 2.0 0.01 3.0 0.001 Nesse exemplo, a largura de banda varia com um período de 12 segundo enquanto a latência varia com um período de 5 segundos. No início da simulação, a largura de banda do link é de 80.000.000 B/s. Depois de 4 segundos, ele cai para 40MB/s e sobe para 60MB/s depois de 8 segundos. Isso é mantido até 12 segundos (até o final do período), ponto no qual o comportamento é um loop (segundos 12-16 com 80MB/s, 16-20 com 40MB/s e assim por diante). Do mesmo modo, os valores de latência são 100us (valor inicial) no intervalo de 0 a 1, 1ms no intervalo de 1 a 2, 10ms no intervalo de 2-3, 1ms no intervalo de 3 a 5 (até o final do período). Então o loop volta, começando com 100us por 1 segundo. 3.2.2. Declarando rotas Rotas representam o caminho na rede entre hosts. Eles correspondem a um salto no link de um host
origem para um host destino. Uma rota é definida pelos nomes de origem (atributo src) e destino (atributo dst) e compreende os links. No exemplo a seguir, nós temos somente um link na rota. A ordem dos links no caminho não são relevantes na maioria dos modelos usados no SimGrid. Exemplo de plataforma com dois hosts <platform version="1"> <host id="bob" power="1000000000"/> <host id="alice" power="500000000"/> <link id="link1 bandwidth="125000000" latency="5e-5"/> <route src="bob" dst="alice"> <link:ctn id="link1 /> <route src="alice" dst="bob"> <link:ctn id="link1"/> Expressando rotas multi-hop: rotas entre hosts podem ser mais complexas. Por exemplo, se ambos BOB e ALICE tem suas próprias conexões para um switch comum, a rota entre eles comprenderá três links de rede distintos. Exemplo de plataforma com roteamento multi-path <platform version="1"> <host id="bob" power="1000000000"/> <host id="alice" power="500000000"/> <link id="link_bob bandwidth="125000000" latency="5e-5"/> <link id="link_alice bandwidth="125000000" latency="5e-5"/> <link id="switch bandwidth="125000000" latency="5e-5"/> Sharing_policy= FATPIPE /> <route src="bob" dst="alice"> <link:ctn id="link_bob /> <link:ctn id="switch /> <link:ctn id="link_alice /> <route src="alice" dst="bob"> <link:ctn id="link_alice /> <link:ctn id="switch /> <link:ctn id="link_bob />
Expressando rotas não-simétricas: no exemplo anterior, a rota entre BOB e ALICE é simétrica, isto é, o link usado pelo fluxo de dados entre BOB e ALICE não depende da direção. No entanto, é possível escrever rotas não-simétricas como segue: Exemplo de plataforma com rotas não-simétricas <platform version="1"> <host id="bob" power="1000000000"/> <host id="alice" power="500000000"/> <host id="trudy" power="250000000"/> <link id="link1 bandwidth="125000000" latency="5e-5"/> <link id="link2" bandwidth="125000000" latency="5e-5"/> <link id="link3" bandwidth="125000000" latency="5e-5"/> <route src="bob" dst="alice"> <link:ctn id="link1"/> <route src="alice" dst="bob"> <link:ctn id="link2"/> <link:ctn id="link3"/> <route src="bob" dst="trudy"> <link:ctn id="link2"/> <route src="trudy" dst="bob"> <link:ctn id="link2"/> <route src="trudy" dst="alice"><link:ctn id="link3"/> <route src="alice" dst="trudy"><link:ctn id="link3"/> Isso assegura que os dados de ALICE para BOB vão através dos links LINK3 e LINK2 enquanto dados de BOB para ALICE vão diretamente através de LINK1. 3.2.3. Especificando roteadores Especificar roteadores na SimGrid é algo muito raro. A maioria das descrições da plataforma SimGrid não contém qualquer roteador e roteadores entre hosts são modelados como um conjunto de links individuais. No entanto, expressar roteadores torna-se necessário quando usamos bindings (ligações) do simulador de nível de pacotes GTNetS ao invés do modelo de rede analítica nativa implementada na SimGrid. Roteadores são naturalmente um importante conceito em GTNetS devido a forma que eles executam os algoritmos de roteamento de pacotes. Reconstruindo um grafo representando somente informações da rota passa a ser uma tarefa muito difícil, devido a informação perdida sobre como as rotas se cruzam. A tag <router> é simplesmente usada para expressar esses pontos de intersecção. O único atributo aceito por essa tag é o id. Sendo usada somente para fornecer informação topológica.
No exemplo a seguir, os caminhos AB e CD não compartilham qualquer recurso e deste modo não impacta em qualquer outro, a menos quando usado bindings GTNetS. <route src= A dst= B > <link:ctn id= l1 /><router id= r1 /><link:ctn id= l2 /> <route src= C dst= D > <link:ctn id= l3 /><router id= r2 /><link:ctn id= l4 /> 3.3. Implementação O SimGrid XML parser é implementado usando o kit de ferramentas FlexML. Como tal, segue a abordagem SAX e depende de eventos durante o processo de análise. Essa abordagem apresenta uma vantagem sobre o padrão de análise estilo-dom porque ele não necessita carregar toda a árvore XML na memória antes de analisar isso. Ele conduz assim para um consumo menor de memória e rápidos procedimentos de análise. A especificidade do FlexML sobre soluções de análise baseadas em SAX é que ele não constitui sua própria biblioteca de análise. Ao invés disso, ele converte o arquivo DTD em uma especificação interna de um parser utilizável com o clássico gerador de parser Flex. O gerador altera a especificação interna em um parser altamente eficiente C induzindo a nenhuma dependência extra no momento da execução. Isso é importante em nosso contexto devido a parte da SimGrid poder ser usada como um middleware para grid, e dependencias tem então de serem evitadas para facilitar a instalação do kit de ferramentas. (...) 3.4. Limitações Verbosidade: a principal limitação do lançamento DTD 3.2 é a alta verbosidade de produzir arquivos XML. Isso torna-se necessário para descrever qualquer rota única da plataforma. Por exemplo, no caso de um grupo compreendido de 100 hosts, a descrição necessita de 9.900 definições de rotas (100 x 99). Inefficient parsing (análise ineficiente): apesar do uso do gerador de parser rápido e otimizado do FlexML, SimGrid faz parse de um arquivo de plataforma quatro vezes, pois o host e a rede são modelados por diferentes sub-módulos. Na versão 3.2, cada sub-módulo analisa uma vez todo o arquivo procurando por informações relevantes. É necessário conhecer cada link existente antes de analisar (parsing) informações de roteamento. Conclusão A descrição de plataformas para simulação requer um certo formalismo que precisa respeitar as seguintes propriedades: Expressividade: o formalismo poderia não ser limitado somente a recursos simulados pelo ambiente mas também permitir declarar dados arbitrários adicionais que podem ser úteis a usuários finais. Readability: arquivos de descrição de plataformas podem ser fáceis de analisar por computadores mas também fáceis de ler ou modificar por seres humanos. Reusabilidade: poderia ser possível usar o mesmo arquivo de descrição de plataforma para várias simulações. Compactness (solidez, firmeza): o arquivo de descrição da plataforma deve ser compacto o suficiente
(acima de centenas de KB) para permitir a geração de múltiplos arquivos representando uma grande faixa de cenários em um espaço razoável. Uma das questões chave da SimGrid é o uso de memória. Toda a tabela de roteamento é armazenada dentro da memória, a maior plataforma que pode ser descrita com o formalismo proposto compreende no máximo alguns milhares de hosts completamente interconectados. Essa limitação de memória pode ser facilmente superada pela compactação da tabela de roteamento como fizemos com o arquivo XML, ou seja, alterando a forma com que a tag <cluster> é tratada.