Uma Categoria de Plataformas Virtuais para Cluster Computing

A Figura 36 representa a assinatura contextual de uma categoria de plataformas virtuais, chamada CLUSTER, que representa clusters constituídos de um conjunto homogêneo de nós de processamento equipados com 1 ou mais processadores de múltiplos núcleos. Cada nó pode estar equipado com 1 ou mais aceleradores computacionais, de mesmo tipo para todos os nós, bem como um armazenamento local de tamanho uniforme. O cluster possui ainda um

Figura 37 – Assinatura Contextual de NODE NODE         count :> 1 : INT↑, processor :> PROCESSOR, accelerator :> ACCELERATOR, memory :> MEMORY, storage :> STORAGE,

operating_system :> OPERATINGSYSTEM

       

Fonte: Próprio Autor

armazenamento global, que pode ser acessado por cada nó de processamento a partir da rede de interconexão. Vale ressaltar que a categoria CLUSTERrepresenta uma arquitetura particular para

uma plataforma de cluster computing, que consideramos representativo. Em uma implementação real da HPC Shelf, várias categorias poderiam ser definidas, representando projetos alternativos de um cluster.

A assinatura contextual da categoria de plataformas virtuais CLUSTERpossui um

conjunto parâmetros de contexto que descrevem as principais suposições que desenvolvedores de componentes devem fazer a respeito da arquitetura de um cluster que ela representa. Os parâmetros são descritos nos próximos parágrafos.

O parâmetro maintainer serve para especificar o mantenedor, e portanto o serviço Backend, responsável pela instanciação da plataforma virtual. O parâmetro virtual serve para especificar se o cluster é instanciado usando serviço de virtualização ou constituem máquinas físicas, completas ou partições. Para isso, o qualificador BOOLEAN, com subtipos TRUEe FALSE, é usado como restrição contextual. Por sua vez, o parâmetro dedicated, também restringido por BOOLEAN, especifica se o hardware sobre o qual o cluster encontra-se instanciado é dedicado a executar uma única aplicação ou é de locação múltipla4, ou seja, compartilhado entre várias aplicações.

Cada nó é do tipo restringido pelo tipo NODE, através do parâmetro node. A assina-

tura contextual do componente abstrato NODEestá na Figura 37. O parâmetro count restringe o número de nós de processamento distribuído do cluster. Por sua vez, parâmetros processor, accelerator, memory, storage e operating_system permitem restringir propriedades que dizem respeito aos processadores, aceleradores, memória principal, armazenamento persistente (lo- cal) e sistema operacional do nó de processamento, respectivamente através dos qualificadores PROCESSOR, ACCELERATOR, MEMORY, STORAGE e OPERATINGSYSTEM, cujas assinatu-

Figura 38 – Assinatura Contextual de ACCELERATOR ACCELERATOR*         count :> 1 : INT↑,

manufacturer :> ACCELERATORMANUFACTURER, type :> ACCELERATORTYPE,

architecture :> ACCELERATORARCHITECTURE, model :> ACCELERATORMODEL,

memory_size :> 0 : INT↑,(MB)        

Fonte: Próprio Autor

Figura 39 – Assinatura Contextual de MEMORY

MEMORY*   size :> 0 : INT↑,(MB) latency :> INT↓,(ns) bandwidth :> 0 : INT↑(Mb/s)  

Fonte: Próprio Autor

Figura 40 – Assinatura Contextual de STORAGE

STORAGE*   size :> 0 : INT↑,(GB) latency :> INT↓,(ns) bandwidth :> 0 : INT↑(Mb/s)  

Fonte: Próprio Autor

ras contextuais estão nas figuras 30, 38, 39 e 40, com exceção de OPERATINGSYSTEM, cuja assinatura é vazia nesse nível.

A assinatura contextual de PROCESSOR já foi discutida na seção anterior (Seção 5.1.3). Em relação à assinatura ACCELERATOR, há parâmetros para restringir o número de unida-

des do acelerador (count), o seu fabricante (manufacturer), o seu tipo5(type), a sua arquitetura dentro de um mesmo tipo de acelerador (architecture), o seu modelo (model) e sua capacidade de memória própria (memory_size). Dependendo do tipo de acelerador, outros parâmetros podem ser incluídos na assinatura de componentes abstratos derivados de ACCELERATOR, tais

como representando o número de núcleos internos de processamento, que é de caracterização bastante diversa entre aceleradores de diferentes tipos. Por sua vez, os contratos de MEMORYe

STORAGEpermitem restringir o tamanho (size) e desempenho dos sistemas de memória volátil e armazenamento persistente, de modo que o desempenho desses sistemas é caracterizado pela sua latência (latency) e sua largura de banda (bandwidth). Embora possuam o mesmo conjunto 5 _{e.g. GPU, FPGA, MIC, etc}

Figura 41 – Assinatura Contextual de INTERCONNECT INTERCONNECT*     startup_time :> INT↓,(ns) node_latency :> INT↓,(ns) bandwidth :> 0 : INT↑(Mb/s), topology :> NETWORKTOPOLOGY

   

Fonte: Próprio Autor

Figura 42 – Assinatura Contextual de PERFORMANCE

PERFORMANCE   peak_flops :> 0 : INT↑,(GFlops) hpl_flops :> 0 : INT↑,(GFlops) hpcg_flops :> 0 : INT↑(GFlops)   Fonte: Próprio Autor

de parâmetros de contexto, optou-se por separá-los em qualificadores distintos, uma vez que parâmetros mais específicos podem ser incluídos em categorias derivadas de CLUSTERpara

representar propriedades particulares de seus sistemas de memória e armazenamento.

O parâmetro network permite restringir características da rede de interconexão entre os nós de processamento do cluster, através de um contrato de INTERCONNECT, cuja assinatura está na Figura 41. Além de parâmetros descrevendo o tempo de startup (startup_time), a latência de nó (node_latency) e largura de banda (bandwidth) da rede, há o parâmetro topology, permitindo fazer restrições a respeito da topologia de interconexão da rede. Na assinatura NETWORKTOPOLOGY, embora a princípio com um conjunto vazio de parâmetros de contexto para os propósitos desta Tese, poderiam ser incluídos parâmetros que descrevem características da topologia que frequentemente são relevantes para implementação de operações de comunicação, tais como diâmetro, conectividade, largura do canal, taxa do canal, tamanho da bisseção, largura de banda da bisseção, dentre outros (GRAMA, 2003).

O parâmetro storage restringe características do armazenamento persistente global, acessível aos nós do cluster através da rede de interconexão. A assinatura do seu tipo, STORAGE

(Figura 40), foi discutida anteriormente.

Os parâmetros performance e power permitem fazer suposições a respeito do de- sempenho e da eficiência energética do cluster, usando os benchmarks consolidados pelo ranque Top500: HPL (High Performance Linpack) e HPCG (High Performance Conjugate Gradients). Portanto, um contrato de PERFORMANCE, cuja assinatura está apresentada na Figura 42, possui

Figura 43 – Assinatura Contextual de POWER POWER     hpl_total :> INT↓,(Watt) hpcg_total :> INT↓,(Watt) hpl_efficiency :> 0 : INT↑,(GFlops/Watt) hpcg_efficiency :> 0 : INT↑(GFlops/Watt)    

Fonte: Próprio Autor

parâmetros que permitem fazer restrições sobre a capacidade de processamento em termos de operações de ponto-flutuante por unidade de tempo. Enquanto peak_flops representa o pico de desempenho teórico do cluster, os parâmetros hpl_flops e hpcg_flops representam, respectiva- mente, o desempenho medido através dos benchmarks HPL e HPCG. Por sua vez, um contrato de POWER, cuja assinatura encontra-se na Figura 43, possui parâmetros para os valores absolutos

(hpl_total e hpcg_total) e relativos (hpl_efficiency e hpcg_efficiency) do custo energético do cluster tanto para o HPL quanto para ao HPCG. O valor relativo é uma medida de eficiência energética, em termos de GFlops/Watt. Essa medida é usada na classificação do ranque Green500

6_{, que classifica as máquinas classificadas no Top500 de acordo com a eficiência energética.}

Finalmente, o parâmetro cost representa o custo monetário de uso do cluster pela aplicação, desde o momento em que é instanciado até o momento quando é liberado. Como discutido antes, esse valor deve ser calculado em um componente sistema a partir do modelo de desempenho do componente computação sobre a plataforma virtual.

Na Figura 44, é apresentado um perfil de plataforma virtual que representa a menor instância da HPC Shelf possível para um mantenedor hipotético associado ao CENAPAD- UFC, e que possui um único acelerador computacional. Admite-se, portanto, que CENAPAD- UFC-MICRO-GPU é declarado nominalmente como um subtipo de CLUSTERno catálogo de componentes. Admite-se ainda que PROCESSORINTELXEON-2470, LINUXREDHAT, GPU- TESLA-K20M, NETWORK-HCA-400EX-D-GS são contratos contextuais de componentes concretos que representam o processador, sistema operacional, tipo de acelerador e tipo de interconexão do cluster em questão, com argumentos de contexto definidos, muito embora omitidos deste texto.

Assim como os usuários especialistas podem utilizar os recursos de plataformas de execução expostos por mantenedores por meio da HPC Shelf, também podem utilizar seus próprios recursos, bastando instalar um Backend da HPC Shelf e assumir o papel de mantenedor, 6 _{<http://www.green500.org>}

Figura 44 – Contrato contextual CENAPAD-UFC-MICRO-GPU

CENAPAD-UFC-MICRO-GPU                    node-count = 2, node-processor-count = 2, node-memory-size = 96000, node-storage = 250000,

node-processor = PROCESSORINTELXEON-2470, node-operating_system = LINUXREDHAT, node-accelerator = GPU-TESLA-K20M, network =NETWORK-HCA-400EX-D-GS,

locale = FORTALEZA, virtualized = FALSE, dedicated = FALSE                   

Fonte: Próprio Autor

criando um ou mais perfis de plataformas virtuais para representar seus próprios recursos computacionais. Vale ressaltar que, atualmente, existe uma implementação de um Backend capaz de instanciar plataformas virtuais em uma máquina local baseada em Linux, porém sem usar recurso de virtualização, além de outras três, respectivamente voltadas a instanciação de plataformas virtuais em um cluster com suporte a tecnologia OpenStack, bem como sobre os serviços Amazon EC2 e Google Cloud Platform.