Avaliação da Nuvem Pública Microsoft Azure para

 Avaliação da Nuvem Pública Microsoft Azure para Integração com um Sistema de Gerenciamento e Execução de Algoritmos 1,2​
1​
2
Daltro Simões Gama​
, Maria Julia Lima​
, Noemi Rodriguez​
1​
Instituto Tecgraf – Pontifícia Universidade Católica do Rio de Janeiro (PUC­Rio) Caixa Postal 38.097 – 22451­900 – Rio de Janeiro – RJ – Brazil 2​
Departamento de Informática – Pontifícia Universidade Católica do Rio de Janeiro Caixa Postal 38.097 – 22451­900 – Rio de Janeiro – RJ – Brazil {daltro,mjulia}@tecgraf.puc­rio.br, [email protected]­rio.br Abstract. Cloud computing is in vogue and appeals for those who need many machines to run their programs, attracted by low maintenance costs and the easy configuration. However, the prospect of performance impacts inherent in cloud environments has reduced the use of these infrastructures by the HPC scientific community. In this work we are interested in contributing to a better understanding of this impact. For this purpose, we present some performance measures in the case of CSGrid's use of Microsoft Azure public cloud, with regard to costs on data transfers and provisioning of virtual machines. Resumo. A computação em nuvem está em voga e traz apelos para quem precisa de muitas máquinas para executar seus programas, como a redução de custos de manutenção e facilidade de configuração. Porém, a perspectiva de impactos no desempenho inerentes ao ambientes de nuvens tem afastado o uso dessas infraestruturas pela comunidade científica de HPC. Neste trabalho estamos interessados em contribuir para um conhecimento mais preciso sobre este impacto. Com esse propósito, apresentamos algumas medidas de desempenho para o caso de uso da nuvem pública Microsoft Azure pelo sistema CSGrid, no que se refere a custos de transferência de dados e provisionamento de máquinas virtuais. 1. Introdução1 Em essência fruto das tecnologias emergentes de virtualização, o paradigma de computação em nuvem veio para criar abstrações convenientes para quem procura elasticidade em hardware para processamento científico ou comercial. A possibilidade de se terceirizar tal infra­estrutura, e ainda ter a comodidade de facilmente controlá­la desperta o interesse de uma grande gama de usuários. Com padrões de desempenho compatíveis com aplicações transacionais (servidores web, serviços, sistemas de informação), o uso de servidores virtualizados em nuvem vem crescendo regularmente. Neste trabalho estamos interessados no uso do paradigma de computação em nuvens combinado a sistemas de submissão de programas. Ferramentas de submissão de 1
Relatório Técnico 3, 2015, Instituto Tecgraf, PUC­Rio. programas para execução são comuns quando se trabalha com computação de alto desempenho ou HPC. Como exemplo, podemos citar o PBS [Bayucan, 1999], com sua implementação Torque ou HTCondor [Thain, 2005], que distribuem execuções de programas em máquinas remotas, monitoram seus recursos e a própria execução. Aplicações HPC, tipicamente científicas, são projetadas para tirar proveito de processadores de alta capacidade e usufruir de uma infra­estrutura de rede de alta velocidade. Aplicações HPC são normalmente executadas em supercomputadores ou clusters de máquinas próprias de quem os executa, e consequentemente as ferramentas tradicionais de submissão também são projetadas levando isso em conta. Com o hardware dimensionado e dedicado especificamente para os requisitos das aplicações, o desempenho das aplicações HPC tem atendido as expectativas de seus usuários. Utilizar computação em nuvem para executar programas tradicionalmente submetidos em clusters HPC tem sido um desafio devido às perdas de desempenho que a computação em nuvem traz se comparada com os clusters dedicados. Alguns trabalhos têm proposto ambientes híbridos que unem as vantagens de clusters dedicados de alto desempenho com recursos de nuvem [Mateescu, 2011; Tröger, 2014]. Neste trabalho vamos focar na utilização de recursos computacionais da nuvem Microsoft Azure pelo sistema CSGrid [Lima, 2006], apresentando algumas métricas envolvidas na submissão de programas nesse cenário de integração. Nosso objetivo é fornecer informações sobre os custos de comunicação e provisionamento que ajudem o projetista de um ambiente híbrido a tomar decisões sobre a arquitetura a ser utilizada. A avaliação da nuvem Azure para execução de programas será apresentada da seguinte forma: Na Seção 2 será apresentado o CSGrid e os fundamentos necessários para compreensão do cenário. Na Seção 3 será discutido o paradigma de nuvem e então, na Seção 4, serão apresentadas medidas de desempenho de provisionamento de máquinas virtuais, de transferência de arquivos via SSH, e também uma medição para avaliar o desempenho de transferências de dados na nuvem usando diferentes técnicas. 2. O CSGrid O CSGrid é um sistema construído como uma instância do framework CSBase, desenvolvido ao longo dos últimos dez anos no Instituto Tecgraf, da PUC­Rio. Trata­se de um sistema para gestão e integração de aplicações em um ambiente computacional distribuído e heterogêneo, abstraindo a infra­estrutura para que usuários possam compartilhar recursos em seus projetos. O framework CSBase é utilizado por 5 sistemas diferentes, sendo o CSGrid um deles e, em particular, aquele que se caracteriza como representativo na família dos sistemas CSBase e de submissão de programas HPC em geral. O CSGrid apresenta um repositório destes programas que o usuário pode selecionar para execução em máquinas automaticamente designadas. Sua abstração de áreas de projetos para compartilhamento, organização de recursos e os programas executáveis fornecem um grande apelo para os usuários de sua infra­estrutura. Na nomenclatura do CSGrid, os programas executáveis são denominados "algoritmos". Todos estes recursos do sistema contam também com a possibilidade de gestão de autenticação e autorização, podendo assim serem usados por organizações que lidam com dados sensíveis ou sistemas com propriedade intelectual. Nas áreas de projeto, o usuário disponibiliza e compartilha com outros usuários arquivos a serem usados como entrada para um programa. Este programa, quando em execução, terá acesso apenas aos arquivos de dentro da área de projeto designada pelo usuário e, de forma análoga, arquivos de saída após a execução poderão ser recuperados pelo usuário na mesma área de projeto. Na arquitetura CSGrid, um módulo servidor é responsável pela gerência das áreas de projetos e de algoritmos, e pela submissão desses algoritmos a nós de execução. Um outro módulo, denominado Sistema de Gerência de Algoritmos (SGA), é executado em um processo independente, possivelmente em outra máquina. O SGA pode fazer o papel do próprio nó de execução, disparando os processos que executam o algoritmo propriamente dito, ou pode ser uma fachada para outro sistema de escalonamento, distribuindo tarefas em algum cluster ou sistema terceiro como PBS/Torque ou HTCondor. O Sistema de Gerência de Algoritmos (SGA) é um processo ​
daemon que tem como finalidade disparar e gerenciar comandos na máquina em que está executando. O protocolo utilizado para a comunicação entre o servidor CSGrid e o SGA é CORBA. Em sua forma mais pura, um SGA se limita a receber pedidos de execução de comandos e a enviar o status da máquina (memória, CPU) durante a execução para o servidor CSGrid. Em alguns cenários, o SGA pode atuar como um intermediário, integrando­se a escalonadores terceiros como PBS/Torque ou HTCondor. Nesse trabalho, só vai nos interessar o cenário em que o SGA atua como o nó de execução propriamente dito. Um aspecto importante na arquitetura do CSGrid é o acesso dos nós de execução aos arquivos da área de projetos dos usuários e aos binários dos algoritmos que serão executados. Todo esse repositório fica armazenado no disco local do servidor CSGrid. O sistema oferece duas formas alternativas do SGA ter acesso aos executáveis e dados: 1) Através de NFS [Shepler, 2003], onde todas as máquinas envolvidas possuem acesso aos mesmos diretórios servidos pelo servidor CSGrid; 2) Através de CSFS [Santos, 2006], que é uma implementação própria para transferir arquivos entre as máquinas através de protocolos escolhidos por configuração, sendo padrão a utilização de COBRA tanto para dados como para controle. No segundo caso, há processos CSFS dedicados tanto ao servidor CSGrid como ao SGA, e é o SGA quem declara necessitar do CSFS ao CSGrid. Uma vez em uso, sempre que a execução de um comando for demandada, o servidor CSGrid envia todos os arquivos de entrada e os executáveis do algoritmo para o SGA para só então executar o comando de fato. Ao término da execução do comando, os arquivos modificados e gerados no SGA são copiados de volta para o servidor CSGrid. As duas formas de compartilhamento de dados oferecem prós e contras: Uma vez em NFS, um comando de uso muito intenso de I/O pode permanecer durante bastante tempo bloqueado aguardando envio e recebimento de dados pela rede. Porém, se o volume de dados é menor, ou o comando tem um perfil de uso mais intensivo de CPU, a sobrecarga pode não ser significativa. O uso do CSFS, por sua vez, faz com que os dados necessários para a execução do comando fiquem disponíveis diretamente no disco local da máquina SGA. Em contrapartida, como todos os dados de entrada são enviados para o SGA antes do início da execução do comando, caso vários nós de execução sejam iniciados para execuções sobre os mesmos dados simultaneamente, a concorrência para a cópia massiva de dados do servidor CSGrid acarreta uma queda substancial de desempenho. 3. O Paradigma de Computação em Nuvem Com os custos de hardware cada vez menores, faz­se economicamente viável a substituição de um supercomputador servidor por vários servidores de capacidade mediana. Em grande quantidade e com a aplicação adequada, a capacidade total pode superar a do único supercomputador. De olho nesta possibilidade de se escalar serviços em termos da quantidade de hardware que os executa, a computação em nuvem apareceu como sendo uma forma de fornecer hardware sob demanda. Através da internet, usuários podem alugar servidores para disponibilizar aplicações online ou armazenar dados. Com facilidades para alocar e desalocar várias máquinas, e pagando apenas pelo tempo das máquinas alocadas, este modelo conquistou vários segmentos por seu apelo econômico. A computação em nuvem está diretamente relacionada às tecnologias de virtualização, onde se emula um computador inteiro dentro de outro. Tecnologias como a da VMWare ou o VirtualBox provêem soluções para desktops, onde seu sistema operacional é denominado "hospedeiro", e outra máquina completa é simulada internamente, rodando outra instância de sistema operacional. As tecnologias de virtualização evoluíram para o ponto onde os próprios fabricantes de hardware contemplaram instruções assembly dedicadas à virtualização, visando garantir o máximo desempenho e mínima sobrecarga com um ou mais sistemas operacionais executando dentro de suas ​
sandboxes​
. Assim, a computação em nuvem nada mais é do que a possibilidade de se alugar uma máquina virtual na internet para instalar qualquer sistema operacional ou aplicação, com a garantia de que ela estará logicamente isolada das outras e da própria máquina hospedeira. Paralelamente, provedores de computação em nuvem também oferecem serviços de armazenamento dedicados de forma independente do aluguel de máquinas virtuais, além de outros serviços para customização de infra­estrutura como firewalls e balanceadores de carga. O provimento de tais serviços é denominado IaaS (infrastructure as a service). Nos interessará neste estudo o serviço IaaS de armazenamento de dados, conhecido como ​
blob storage​
. 3.1. A Nuvem Azure Foi oferecido pela Microsoft para o departamento de informática da PUC­Rio um convênio acadêmico que permitia o uso da nuvem Azure para experimentações diversas. Tendo a facilidade de utilizar uma das plataformas de computação em nuvem mais difundidas da atualidade, resolvemos avaliar seus aspectos de desempenho convenientes para a integração com o CSGrid. A nuvem Azure provê todos os serviços básicos previstos como IaaS como armazenamento, gestão de máquinas virtuais e firewalls e também serviços específicos aderentes ou não à produtos de suas plataformas, como SQL Server. Apesar disso, o serviço é totalmente aderente ao uso de softwares livres e sistemas operacionais Linux, que é o caso que nos interessa. O mecanismo de armazenamento em sua camada IaaS possui uma única forma de transferir dados, que é através de uma API HTTP. Um serviço chamado Azure Drive para mapeamento direto do serviço de armazenamento para um sistema de arquivos remoto via SMB ainda está em fase de testes e não será levado em consideração aqui. 4. Medições de Desempenho Dadas as vantagens da computação em nuvem, é interessante que o CSGrid possa trabalhar em servidores virtuais alugados em uma nuvem. Com um uso básico, já é possível utilizar o CSGrid e o SGA em um ambiente de nuvem: Ao se alugar uma máquina virtual para executar o servidor CSGrid e outra máquina virtual para se executar um SGA, o procedimento para configuração e uso é o mesmo do que se usando máquinas reais e dedicadas em uma infra­estrutura própria. Serão apresentadas nas Seções 4.1 e 4.2 resultados de medições que não dependem de uma instalação de ambiente CSGrid, mas sim do uso direto dos recursos da nuvem Azure. Em 4.3, já serão apresentados resultados de medições que envolvem uma instalação CSGrid e vários SGAs na nuvem Azure. 4.1. Provisionamento de Máquinas Virtuais Uma das principais vantagens do uso de nuvens é a possibilidade de criar e destruir máquinas virtuais sob demanda, pagando apenas pelo tempo em que as máquinas forem usadas. Porém, o provisionamento de uma nova máquina virtual leva tempo e, para aplicações HPC, este tempo pode ser relevante. Não é possível executar provisionamentos simultâneos na nuvem Azure. Assim, qualquer provisionamento de máquinas em lote deverá ser sequencial. Esta premissa provê uma importância adicional ao o tempo em que o provisionamento de uma máquina demora. A nuvem Azure provê um catálogo fixo de tamanhos de máquinas virtuais, com preços distintos por hora de funcionamento. A Tabela 1 apresenta configurações e preços de máquinas disponíveis. Todas as máquinas apresentam o preço em relação ao do tamanho A1, considerando o data center do leste dos EUA. Assim, por exemplo, sabemos que a máquina A4 custa oito vezes mais do que a A1. Os valores exatos, em moeda, podem ser obtidos no site do serviço Azure. As máquinas da série D (D1, D2, etc...) se diferenciam das máquinas da séria A (A0, A1, etc…) devido ao fato de possuírem discos SSD e núcleos virtuais cerca de 60% mais rápidos do que os da séria A. Tabela 1: Relação das máquinas disponíveis para provisionamento
Nome Núcleos RAM Disco Preço Relativo A0 1 0.75 GB 20 GB 0,33 A1 1 1.75 GB 70 GB 1,00 A2 2 3.5 GB 135 GB 2,00 A3 4 7 GB 285 GB 4,00 A4 8 14 GB 605 GB 8,00 A5 2 14 GB 135 GB 4,17 A6 4 28 GB 285 GB 8,33 A7 8 56 GB 605 GB 16,67 D1 1 3.5 GB 50 GB 1,57 D2 2 7 GB 100 GB 3,13 D3 4 14 GB 200 GB 6,27 D4 8 28 GB 400 GB 12,53 D11 2 14 GB 100 GB 3,97 D12 4 28 GB 200 GB 7,93 D13 8 56 GB 400 GB 14,28 D14 16 112 GB 800 GB 25,70 A Tabela 2 apresenta os tempos em que a criação de máquinas virtuais demoraram em diferentes medições ao longo de um dia. É notável que o tamanho da máquina não influi no tempo de criação, cujo término indica que a máquina está criada e ligada, pronta para uso. O tempo médio de 40 segundos observado para criação de uma máquina, juntamente com o fato de não podermos criar máquinas simultaneamente, indica que o tempo esperado para a criação de um cluster de n máquinas é de 40n segundos, o que representa um tempo acima do tolerável a ser considerado na execução de programas HPC em um ambiente onde a máquina é criada sob­demanda. Tabela 2: Tempos medidos para criação e deleção das máquinas, em segundos Tamanho Média Desvio Padrão A0 41,7 2,8 A1 40,8 2,6 A2 40,8 2,0 A3 41,6 2,3 A4 42,6 3,7 A5 41,4 2,7 A6 41,1 2,6 A7 39,9 1,1 D1 40,3 1,3 D2 40,2 0,9 D3 41,7 3,0 D4 42,0 2,2 D11 40,5 1,9 D12 42,4 2,9 D13 40,3 1,3 D14 40,1 1,2 4.2. Transferência de Arquivos entre Máquinas e Data Centers Desconsiderando o cenário mais caro, onde não foi contratado um barramento de rede dedicado no provedor de nuvem apenas para o cluster, foram monitoradas as taxas de transferência de arquivos através de SSH levando em conta os seguintes cenários: 1) Entre a PUC­Rio e os data centers da Azure distribuídos pelo globo; 2) Entre duas máquinas virtuais dentro do mesmo data center; 3) Entre data centers distintos. Para ilustrar como amostra representativa de transferências, não foram feitas medições levando em conta todas as combinações possíveis de data centers, mas sim algumas cujo desempenho pudesse representar as demais. Como se trata de um ambiente compartilhado, um valor mais exato está sujeito às condições de cada momento. Cada medição levou em conta a média de três cópias de um arquivo de 256MB com conteúdo aleatório. As máquinas virtuais alocadas para tal foram de tamanho A1 ou small​
, que possuem um núcleo de processamento e 1.75GB de RAM. A sobrecarga de entrada e saída para o disco das máquinas virtuais também foi levada em conta, pois as cópias envolvem escritas em disco. A Tabela 3 apresenta as taxas de transferência citadas. Tabela 3: Medidas de tempo para transferência SSH entre diferentes localidades
Origem Destino Taxa média PUC­Rio East­US 5,0MB/s East­US PUC­Rio 3,0MB/s PUC­Rio West­US 4,3MB/s West­US PUC­Rio 1,9MB/s PUC­Rio North­EU 3,7MB/s East­US West­US 8.3MB/s East­US North­EU 4,1MB/s West­EU North­EU 9,1MB/s North­EU PUC­Rio 2,1MB/s PUC­Rio West­EU 3,3MB/s West­EU PUC­Rio 1,8MB/s East­US East­US 11,0MB/s West­EU West­EU 9,9MB/s Podemos observar que as taxas de transferência quando dentro do mesmo data center permeiam os 10MB/s. Quando as transferências são entre data centers do mesmo continente, o desempenho cai cerca de 1MB/s, e transferências entre data centers da Azure em continentes distintos apresenta queda de quase 50%. Quando se trata de enviar dados do campus da PUC­Rio para a Azure, o desempenho se mostrou superior ao de trazer dados para o Rio de Janeiro, o que pode se dar pelas características do link oferecido pela universidade que privilegia o upload de dados ao download. 4.3. Medição de Desempenho com Algoritmo de Teste O objetivo aqui é comparar o desempenho de um cluster montado em um ambiente de nuvem com máquinas virtuais alugadas em três cenários viáveis: ● Rede NFS, que é o caso mais comum de clusters CSGrid, onde as áreas de projeto e os algoritmos são compartilhadas entre o servidor CSGrid e os SGAs através de diretórios compartilhados via NFS. Utilizando esta configuração, todos os SGAs instanciados serão clientes NFS do servidor CSGrid ou todas as máquinas serão clientes NFS de um outro servidor dedicado a servir arquivos; ● CSFS, que é implementado quando não é viável ter o compartilhamento NFS. Tal impedimento ocorre tipicamente devido à firewalls ou limitações por escolha do sistema operacional do SGA; ● Azure Blob Storage: Neste cenário, não é utilizado nem NFS e nem CSFS. Para recuperar os arquivos da área de projeto e executar comandos, o SGA recorre ao serviço de armazenamento provido pela infraestrutura do Windows Azure. Assim como o CSFS, os arquivos são recuperados do serviço da Azure antes da execução do comando, e depois são enviados de volta. Em todos os cenários, todas as máquinas citadas estão hospedadas na nuvem, em um mesmo site. Como o CSGrid é um sistema cliente­servidor, seu servidor foi hospedado na nuvem, assim como todos os SGAs para o experimento. A idéia deste experimento é comparar o desempenho de um algoritmo cujo objetivo é tentar comprimir um arquivo de 100Mb de conteúdo aleatório. Devido à entropia do arquivo, é esperado que a compressão não reduza em nada o tamanho original, mas o esforço computacional será levado em conta. Nota­se, no entanto, que o procedimento deve exigir um bom desempenho de rede para carregar a área de projeto no SGA. Trata­se de um caso específico onde um arquivo grande deve ser enviado e trazido do SGA (io­bound), portanto este experimento não visa retratar casos onde a quantidade de computação e muito grande perante o uso de I/O (cpu­bound). Para comparar o desempenho na nuvem, o algoritmo foi executado inicialmente em um só SGA, depois em dois SGAs simultaneamente, depois em três, e assim por diante. Quanto mais SGAs simultâneos, maior a concorrência na rede para transferir o arquivo de 100Mb para o SGA e trazê­lo de volta. Excepcionalmente para a implementação do cenário Azure, o algoritmo de cópia e compressão foi feito utilizando o SDK Java da Azure para interação com o serviço de storage. Os demais são constituídos de um script shell Linux que executa um comando "tar" com fator de compressão gzip. As execuções na modalidade Azure e NFS foram feitas 10 vezes, e os tempos reportados são a média aritmética das execuções. No caso do CSFS, apenas uma execução foi feita devido a falhas não determinísticas apresentadas pela implementação no cenário dinâmico da nuvem. O mecanismo CSFS se mostrou instável em situações onde a máquina SGA é reiniciada ou SGAs são removidos ou inseridos sem que o servidor CSGrid seja reiniciado junto. Assim, desalocar e alocar máquinas para o experimento constantemente para a realização dos testes causou falhas que impediram a execução fluída dos testes em massa. Todavia, os resultados abaixo ilustram que não seriam necessárias mais execuções para se tirar as conclusões, dada a distância entre as curvas apresentadas na Figura 1. Figura 1. Medição do tempo total de execução simultânea do algoritmo de
compressão de 100Mb. Figura 2. Medição do tempo de execução simultânea do algoritmo de
compressão de 100Mb. Na Figura 1, o tempo é contado a partir do início da execução do primeiro SGA até o término total da execução do último SGA. Por exemplo, disparando 30 SGAs realizando a compressão simultaneamente em um cluster NFS, todos os 30 SGAs completaram totalmente a tarefa depois de cerca de um minuto e quarenta segundos (100 segundos). Este é o tempo visível para o usuário final, que vai desde quando os comandos foram submetidos até o momento em que se vê todos os comandos totalmente concluídos na interface gráfica do CSGrid. Na Figura 2, os tempos relatados já são relativos apenas à fase de execução do algoritmo, sem levar em conta a transferência inicial do servidor CSGrid para o SGA e nem a transferência de volta. Note que o tempo da execução propriamente dita do modelo NFS cresce conforme o número de SGAs concorrendo pelo arquivo. Isto porque a compressão neste cenário ocorre ao mesmo tempo em que o arquivo é recuperado. No caso do CSFS ou azure, independente do tempo de download ou upload, o tempo isolado da compressão permanece estável. A diferença na curva do Azure para a curva do CSFS vêm em consequência da diferença da implementação dos algoritmos utilizados. Vale, assim, analisar o comportamento da curva ao invés dos valores absolutos. Pode ser observado, principalmente na Figura 1, que o desempenho do modelo NFS e do Azure é semelhante, mostrando que até o limite de 30 SGAs concorrendo pelo mesmo dado impactam o desempenho geral de forma semelhante. Porém, pouco se pode concluir da tendência para o caso de mais SGAs. 5. Conclusão Nuvens públicas como a Microsoft Azure podem representar um ganho significativo de custo de manutenção e relacionado à manutenção de hardware. Pode ser a diferença entre viabilizar ou não um projeto. Porém, paga­se um preço no desempenho do sistema. Para casos em que muitas máquinas virtuais devem ser provisionadas, paga­se o preço de se aguardar cerca de quarenta segundos vezes o número de máquinas desejadas. Pode­se também optar pelo provisionamento de menos máquinas, porém de tamanho maior, pois o tempo de provisionamento é o mesmo independente do tamanho da máquina. Mas, nesse último caso paga­se um preço maior por cada minuto em que as máquinas existirem no sistema. Estratégias de pré­alocação visam alcançar uma economia do tempo de provisionamento de máquinas virtuais em ambientes de execução de programas e são importantes nos cenários de uso onde a elasticidade da nuvem deve ser balanceada em função desse custo envolvido [Chu, 2013]. O tráfego de rede entre as máquinas virtuais obedece o desempenho comparável ao de uma rede 100Mbit/s, o que pode atender bem a muitas aplicações HPC. Para o caso de requisitos mais exigentes, a nuvem pública oferece serviços com desempenho superior, a um preço bem mais alto. Com relação às transferências de dados e concorrência, observou­se que é bom usar a infraestrutura provida pela nuvem pública em detrimento de uma estrutura própria de armazenamento instanciada em máquinas virtuais, pois em maior escala, os serviços IaaS apresentam melhor desempenho. Nesse trabalho, nosso objetivo foi identificar e avaliar alguns parâmetros onde a computação em nuvem pode trazer um impacto de desempenho na execução de programas que tipicamente utilizam uma infraestrutura de HPC. Como isso, esperamos contribuir para decisões que envolvem as adaptações no sistema CSGrid para uso de recursos computacionais da nuvem na execução dos programas de usuários cujos requisitos permitam tirar proveito desse tipo de infraestrutura mesmo tendo que pagar por possíveis perdas de desempenho no resultado final. Esse cenário de uso do CSGrid, em particular, é explorado como parte do projeto EUBrazilCC [Blanquer, 2014] do qual a PUC­Rio e o Instituto Tecgraf participam. a​
Agradecimentos​
. Gostaríamos de agradecer a Prof​
Ana Lúcia de Moura (Departamento de Informática, PUC­Rio) e Cassio Arruda Gondim (Instituto Tecgraf, PUC­Rio) pela ajuda na revisão deste documento. Referências Albeaus Bayucan, Robert L Henderson, Casimir Lesiak, Bhroam Mann, Tom Proett, and Dave Tweten. Portable batch system: External reference specification. Technical report, Technical report, MRJ Technology Solutions, 1999. Patrick Armstrong, Ashok Agarwal, A Bishop, Andre Charbonneau, R Desmarais, K Fransham, N Hill, Ian Gable, S Gaudet, S Goliath, et al. Cloud scheduler: a resource manager for distributed compute clouds. ​
arXiv preprint arXiv:1007.0050​
, 2010. Douglas Thain, Todd Tannenbaum, and Miron Livny. Distributed computing in practice: the condor experience. ​
Concurrency ­ Practice and Experience​
, 17(2­4):323–356, 2005. Gabriel Mateescu, Wolfgang Gentzsch, and Calvin J. Ribbens. Hybrid computing—where HPC meets grid and cloud computing. ​
Future Generation Computer Systems​
, 27(5):440 – 453, 2011. Peter Tröger and Andre Merzky. Towards standardized job submission and control in infrastructure clouds. ​
Journal of Grid Computing​
, 12(1):111–125, 2014. Maria Julia de Lima, Cristina Ururahy, Ana Lúcia de Moura, Taciana Melcop, Carlos Cassino, MN Santos, Bruno Silvestre, Valeria Reis, and Renato Cerqueira. Csbase: A framework for building customized grid environments. In ​
Enabling Technologies: Infrastructure for Collaborative Enterprises, 2006. WETICE’06. 15th IEEE International Workshops on​
, pages 187–194. IEEE, 2006. Marcelo Nery dos Santos. GridFS ­ um servidor de arquivos para grades e ambientes distribuídos heterogênos. Master’s thesis, PUC­Rio, 2006. Spencer Shepler, Mike Eisler, David Robinson, Brent Callaghan, Robert Thurlow, David Noveck, and Carl Beame. Network file system (NFS) version 4 protocol. Network​
, 2003. Chu, Hsuan­Yi, and Yogesh Simmhan. Resource allocation strategies on hybrid cloud for resilient jobs. ​
Small​
1005.1 (2013): 0­065. Blanquer, Ignacio. EU­Brazil Cloud Connect: Integrating services for heterogeneous infrastructures. In ​
Porting new applications to EGI​
. ​
EGI CF​
. 2014.