Heterogeneous

Cloud ComputingRodrigo 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 maiscomum.

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 necessidadesde 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áriograç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 densidadecomputacional.

Sim, os fabricantes estão sempre melhorando a eficiênciados processadores e outros equipamentos de hardware, mas o uso de recursos heterogêneos pode aumentar ainda maisessa eficiência. Por exemplo, dispositivos específicospodem ser otimizados para certos tipos de computação, e essa otimização pode ser feita com o objetivo de melhorara eficiência.

Exemplos: DSPs, processadores de pacotes de rede, GPUs, etc.

A Amazon possui clusters de GPUs, porém com foco emhardware 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áriospossuem de recursos específicos.

A heterogeneidade existe não somente entre diferentesarquiteturas de processadores, como também entre processadores da mesma arquitetura. Exemplo: SSE4.2, quesurgiu 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 recursobaseado em uma necessidade específica, é necessário queo software que lida com a infraestrutura da cloud sejacapaz 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 nuvemprove 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 (grandequantidade de alocação de pequenos recursos), enquantoque na grade geralmente se lida com uma poucaquantidade de grandes requisições (pequena quantidade de alocação de grandes recursos).

10

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 emPython que se comunicam pelo uso de filas de mensagens e banco de dados.

11

Figura 1: Componentes do OpenStack

Arquitetura do OpenStack:

OpenStack Compute (escuro)

OpenStack Glance (claro)

12Figura 2: Arquitetura de serviços do OpenStack

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

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 porrequisiçõ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 tratadasatravés de uma fila, geralmente implementada peloRabbitMQ

14

Figura 3: Fluxo de dados de uma RPC no RabbitMQ

Modificação

O suporte foi implementado pela adição de parâmetrosna sintaxe da string que diz o tipo de instância a serutilizada:

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 qemu-

kvm, 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 muitasthreads concorrentemente, mas lentamente, enquanto queCPUs 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 aoCUDA, as agrega e faz forward para a biblioteca do CUDA da máquina Host.

17

Arquitetura do gVirtuS

18Figura 4: Arquitetura do gVirtuS

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 qualquerGPU na máquina Host, o que vai contra a idéia de virtualização. Isso foi corrigido através de uma modificaçãono 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ãoprovendo acesso à VM. Geralmente o uso de CPU é baixo, mas no caso de crash do processo CUDA dentro da VM, emalgumas 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

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 5: Arquitetura Proxy para máquinas não-virtualizáveis

23Figura 6: Funcionamento do TILEmpower com Proxy

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 computacionaisheterogê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 recursosde 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