Heterogeneous Cloud Computing Rodrigo Shizuo Yasuda RA 074358 1
Índice Autores Introdução Motivação OpenStack RabbitMQ Modificação Resultados Comentários Referências 2
Autores Steve Crago Diretor Assistente da divisão de Sistemas Computacionais e Tecnologia do Instituto de Ciência da Informação na University of Southern California s, onde é professor desde 1997. Líder do grupo de pesquisa Adaptive Parallel Execution (APEX). Faz pesquisa em multi processamento, cloud computing, computação baseada em FPGA, sistemas wireless, etc. Atualmente lidera uma pesquisa em infraestrutura para clouds privadas para sistemas computacionais heterogêneos de alta performance 3
Autores Lorin Hochstein PhD em ciência da computação pela University of Maryland (2006). Atualmente é Arquiteto Líder na Nimbis Services (empresa da área de HPC). Faz pesquisa no uso de recursos computacionais de larga escala para aplicações científicas e de engenharia, com foco em cloud computing. Participa do projeto OpenStack. 4
Introdução O uso de Cloud Computing tem se tornado cada vez mais comum. O uso da Cloud é excelente para usuários com conhecimento técnico computacional, como cientistas. Entretanto, como a computação em nuvem evoluiu da comunidade de TI, ela pode não satisfazer as necessidades de usuários de computação de alto desempenho (HPC). Provedores de serviços de Cloud como a Amazon e o Rackspace disponibilizam aos usuários acesso a um conjunto homogêneo de hardware commodity Os detalhes de hardware físico ficam invisíveis ao usuário graças ao uso de máquinas virtuais. Pouco ou nenhum controle sobre localidade. 5
Motivação Os usuários podem necessitar de acesso a um conjunto de recursos heterogêneos, como máquinas com diferentes arquiteturas, diferentes aceleradores e interconexão de rede específica. A estrutura da Cloud atualmente não satisfaz as necessidades dos usuários HPC, mas o modelo atual tem algumas vantagens com relação ao modelo tipicamente usado em centros HPC (batch-scheduled model). Como extender a infraestrutura tradicional da Cloud para dar suporte aos usuários que necessitam do acesso a um conjunto de recursos computacionais heterogêneos? Resposta dos autores: extender o framework OpenStack para suportar clouds heterogêneas 6
Porquê a Cloud heterogênea? Centros de computação e dados são limitados por: densidade de potência, eficiência e densidade computacional. Sim, os fabricantes estão sempre melhorando a eficiência dos processadores e outros equipamentos de hardware, mas o uso de recursos heterogêneos pode aumentar ainda mais essa eficiência. Por exemplo, dispositivos específicos podem ser otimizados para certos tipos de computação, e essa otimização pode ser feita com o objetivo de melhorar a eficiência. Exemplos: DSPs, processadores de pacotes de rede, GPUs, etc. A Amazon possui clusters de GPUs, porém com foco em hardware commodity e sem controle sobre as arquiteturas. Existe apenas a possibilidade de escolher quantidade de memória, CPU e disco. 7
Amazon EC2 Escolhe de VMs com opções limitadas: Quantidade de memória Quantidade de núcleos de processamento Quantidade de espaço em disco Plataforma x86 ou x86_64 Existe a necessidade de suportar mais configurações, com o objetivo de suprir a necessidade que alguns usuários possuem de recursos específicos. A heterogeneidade existe não somente entre diferentes arquiteturas de processadores, como também entre processadores da mesma arquitetura. Exemplo: SSE4.2, que surgiu na família Nehalem dos Intel x86 8
Vantagens A introdução da heterogeneidade na Cloud a tornará competitiva com relação aos sistemas distribuídos tradicionais. When combined with economies of scale, dynamic provisioning and comparatively lower capital expenditures, the benefits of heterogeneous clouds are numerous. 9
Como prover Cloud heterogênea? Para dar ao usuário a possibilidade de escolher um recurso baseado em uma necessidade específica, é necessário que o software que lida com a infraestrutura da cloud seja capaz de reconhecer e lidar com essa heterogeneidade. A computação em grade por exemplo é usada para computações em larga escala. Já a computação em nuvem prove uma forma diferente de alocar recursos diferente das grades e dos batch schedulers. Por exemplo, o EC2 (Amazon) é equipado para lidar com uma grande quantidade de pequenas requisições (grande quantidade de alocação de pequenos recursos), enquanto que na grade geralmente se lida com uma pouca quantidade de grandes requisições (pequena quantidade de alocação de grandes recursos). 10
OpenStack Figura 1: Componentes do OpenStack Coleção de pacotes de software open-source feitos com o propósito de criar ambientes de cloud públicos e privados. Utilizado pela NASA (Nebula) e U.S. Department of Energy OpenStack Compute é um conjunto de serviços feitos em Python que se comunicam pelo uso de filas de mensagens e banco de dados. 11
Arquitetura do OpenStack: OpenStack Compute (escuro) OpenStack Glance (claro) Figura 2: Arquitetura de serviços do OpenStack 12
OpenStack: Serviços Foco dos autores: IaaS (OpenStack Compute, ou Nova) Alguns serviços: Nova-schedule: responde por pedidos de escalonamento de recursos Nova-compute: responsável por iniciar/parar VMs Nova-network: controla endereços IP e VLANs nas VMs Nova-volume: gerencia drives de rede Queue: fila de mensagens (RabbitMQ), usada para implementar RPC entre serviços Database: banco de dados relacional (MySQL) Dashboard: interface web 13
RabbitMQ Message Broker Sistema de fila distribuída Figura 3: Fluxo de dados de uma RPC no RabbitMQ Funcionamento simples: aceita e redireciona mensagens Utilizado para distribuir tarefas que consomem tempo entre diversos workers. RPC worker (server) se registra na fila e espera por requisições. Quando recebe uma requisição, realiza a chamada e envia uma mensagem com o resultado de volta ao cliente. No OpenStack Compute todas requisições são tratadas através de uma fila, geralmente implementada pelo RabbitMQ 14
Modificação O suporte foi implementado pela adição de parâmetros na sintaxe da string que diz o tipo de instância a ser utilizada: Exemplo: t1.small; cpu_arch=tilepro64 Alguns possíveis parâmetros: xpus: quantidade de aceleradores (GPU, por exemplo) xpu_arch: arquitetura do acelerador (Fermi, por exemplo) cpu_arch: arquitetura da CPU (x86_64, TILEPro64) hypervisor_type: hypervisor da VM (Xen, KVM) Implementação feita pela adição de uma tabela (onde o scheduler busca informações das instâncias disponíveis) listando as características novas. 15
Modificação Modificação da Libvirt, para retornar não somente as características mais comuns como também as mais específicas de cada CPU. Adição da flag cpuhost ao commando que roda o qemukvm, para garantir que a máquina virtual consiga fazer uso dos recursos da CPU host. 16
Desafio 1: Suporte a GPUs O modelo de computação das GPUs é o inverso das CPUs. GPUs tem um throughput muito alto para executar muitas threads concorrentemente, mas lentamente, enquanto que CPUs executam uma thread muito rápido. O grande desafio encontrado foi o fato de que o uso de aceleradores nunca foi cogitado na virtualização. Algumas soluções suportam o uso de GPUs da NVIDIA através de PCI-passthrough, como o Xen e o Parallels Desktop. Já o KVM não possui tal suporte. Solução encontrada: gvirtus e vcuda, que utilizam um modelo de driver que permite a separação de cada VM e uma camada de interposição intercepta as chamadas ao CUDA, as agrega e faz forward para a biblioteca do CUDA da máquina Host. 17
Arquitetura do gvirtus Figura 4: Arquitetura do gvirtus 18
gvirtus O gvirtus, por exemplo, prove uma API CUDA e a biblioteca compartilhada libcudart.so, que permite que se compile programas que fazem uso do gvirtus nas VMs e binários pré-compilados que usam a biblioteca compartilhada. E na máquina Host, provê o marshalling dos dados para as chamadas à biblioteca do CUDA. O gvirtus possui uma camada de comunicação (VMShm) que faz uso do QEMU para compartilhar segmentos de memória entre as VMs. 19
Solução para suporte a GPUS: gvirtus Ao adicionar o gvirtus ao OpenStack, ou seja, criar uma VM que possui a shared library do gvirtus em um host com suporte a gvirtus, temos uma VM com suporte a CUDA. Problema: o gvirtus permite que cada VM acesse qualquer GPU na máquina Host, o que vai contra a idéia de virtualização. Isso foi corrigido através de uma modificação no backend, permitindo acesso exclusive a uma VM somente àquela GPU alocada a ela. Problema 2: Os processos do gvirtus que rodam no backend consomem recursos da máquina Host quando estão provendo acesso à VM. Geralmente o uso de CPU é baixo, mas no caso de crash do processo CUDA dentro da VM, em algumas situações o uso de CPU subia para 100%. O problema 2 foi corrigido através de um mecanismo de heartbeat que matava os processos do backend no caso de crash. 20
Desafio 2: Suporte a arquiteturas não-x86 Algumas arquiteturas possuem péssimo suporte a virtualização. Em alguns casos, nenhum suporte. O Tilera, por exemplo, ainda não possui suporte a KVM ou Xen. Para dar suporte ao Tilera, foi desenvolvido um proxy que lida com a máquina física, ao invés de utilizar VMs. Esse proxy faz deploy, gerência de recursos e autenticação em máquinas físicas e pode utilizar recursos como PXE (Preboot Execution Environment) boot e IPMI (Intelligent Platform Management Interface) ou TILEmpower, caso não exista suporte a PXE/IPMI. 21
Tilera Figura 5: Arquitetura Proxy para máquinas não-virtualizáveis O proxy permite que o usuário conecte-se à máquina através de SSH e atua como servidor tftp, de forma que a máquina com a placa TILEmpower realiza seu boot através de um tftp-boot, que transfere a imagem do proxy à máquina. O proxy só volta a atuar para controle: ligar/desligar a máquina. 22
Figura 6: Funcionamento do TILEmpower com Proxy 23
Deploy O deploy inicial dessa versão modificada do OpenStack foi feito no cluster da USC/ISI (University of Southern California/Information Sciences Institute) Estudos mostram que a cloud pode ser uma boa opção para HPC em comparação aos clusters locais. Provedores de cloud estão equipando seus serviços com hardware HPC. A Amazon EC2 já possui clusters de GPUs, por exemplo. 24
Resultados e Trabalhos futuros É possível prover acesso a recursos computacionais heterogêneos na cloud. Os autores pretendem, na próxima fase da pesquisa, focar na melhoria de performance da solução criada. As possíveis melhorias mencionadas são: Melhoria da performance na comunicação de rede para aplicações multinode Incorporar frameworks de workflow científico (Pegasus, por exemplo) Incorporar frameworks de alocação dinâmica de recursos de redes e engenharia de tráfego (DRAGON, por exemplo) Suporte a outras arquiteturas, além do TILEmpower 25
Comentários O uso da computação heterogênea limita a mobilidade das VMs. A disponibilidade do recurso requisitado pode ser bastante limitada. A computação heterogênea traz diversas vantagens para quem faz uso dos recursos extras de hardware 26
Referências OpenStack. [Online]. Available at: http://www.openstack.org Amazon Elastic Compute Cloud (Amazon EC2). [Online]. Available at: http://aws.amazon.com/ec2/ RabbitMQ. [Online]. Available at: http://www.rabbitmq.com/ NEBULA Cloud Computing Platform. [Online]. Available at: http://nebula.nasa.gov/ CUDA Parallell Computing Platform. [Online]. Available at: http://www.nvidia.com/object/cuda_home_new.html Steve Crago, D. Kyle, P. Eads, L. Hochstein, D. Kang, M. Kang, D. Modium, K. Singh, J. Suh, J. P. Walters, Heterogeneous cloud computing, in 2011 IEEE International Conference on Cluster Computing 27
Perguntas? 28