Os sistemas em clusters serão mais plenamente aproveitados se as aplicações que forem executadas pelos mesmos suportarem processamento paralelo que seria dividir tarefas e funções da aplicação entre os processadores que os compõe.
Em sistemas paralelos as principais métricas são ganho de velocidade (speedup) e a capacidade de crescimento ou escalabilidade, visando sempre executar as aplicações num tempo menor, se estamos tratando de HPC (High Performance computing). Quando falamos de escalabilidade estamos considerando o quanto uma determinada aplicação será beneficiada com o aumento de nós num cluster, pois na maioria dos casos existe um ponto de saturação, quando a inserção de um novo nó no cluster passa a não corresponder a um aumento de desempenho. De fato, podemos ter casos em que o aumento de nós pode vir a degradar o desempenho da aplicação. Essa resposta em termos de desempenho dependerá de parâmetros como velocidade de clock, tamanho do problema (granularidade), tempo de utilização de CPU, uso do canal de comunicação, demanda por operações de memória e E/S, dentre outros itens.
Existem diversas abordagens e componentes para avaliação de desempenho de clusters, analisaremos algumas delas:
Performance teórica de pico
Esse valor representa o máximo de operações em ponto-flutuante por segundo, calculado pela seguinte fórmula:
P=N * C* F * R
Fórmula 2 Onde:
P representa o desempenho medido em Mflops ou Gflops N é o número de nós do cluster
C identifica o número de CPU’s por nó
F é o número de operações em ponto-flutuante por ciclos de clock R é a velocidade de clock medido em ciclos por segundo
178
Performance das Aplicações
É o número de operações realizadas quando se está executando uma determinada aplicação, dividido pelo tempo de execução. Esse tipo de medida é feita através de programas de benchmark não correspondendo pelo menos em sua plenitude a uma aplicação de uso prático.
Execução de Aplicações
Seria a medição do tempo de execução de determinada aplicação numa condição predeterminada. No nosso caso utilizaremos essa abordagem ao analisar o PovRay. Ganho de velocidade
Podemos medir o ganho de velocidade de uma determinada aplicação num cluster comparando o seu tempo de execução com tempo de execução da mesma aplicação num computador standalone. Segue a fórmula:
Fórmula 3 Lei de Amdahl20
A programação de aplicações que utilizem o processamento paralelo ainda está num estágio incipiente, assim existem aplicações que apenas parte das tarefas é executada paralelamente e algumas em que as tarefas são totalmente serializadas.
Amdahl criou uma expressão para medir a porção de processamento paralelo e a porção de processamento serializado numa dada aplicação.
20 Gene Myron Amdahl (16 de novembro de 1922) é um projetista de computadores e empreendedor no ramo da alta tecnologia, mais conhecido por seu trabalho com mainframes na International Business Machines (IBM) e posteriormente por suas próprias empresas, particularmente a Amdahl Corporation. Ele talvez seja mais lembrado por ter formulado a Lei de Amdahl, uma teoria fundamental da computação paralela.
179
A fórmula é trivial:
Fórmula 4 Onde:
p representa o desempenho da porção serial em porcentagem T é o tempo em segundos
(1-p) representa a porção paralelizável N é o número dos nós do cluster
Somente a porção paralelizável do programa que se beneficia com os processadores dos nós do cluster. Assim o ganho de processamento seria:
Fórmula 5
Quanto mais a aplicação tiver tarefas que são processadas de modo paralelizado e quanto maior a quantidade de nós no cluster, maior será o ganho de processamento segundo Amdahl.
Performance da rede
As conexões de rede são também um item essencial no desempenho do cluster como um todo. Seguem alguns quesitos importantes no que tange às redes que conectam os nós que compõe um cluster:
180
Vazão (throughput): A quantidade efetiva de dados em bits por segundo que são transmitidos entre os nós. Apesar velocidade das interfaces de rede e do elemento onde elas estão conectadas (usualmente um switch) serem determinantes para o desempenho da rede, existem outros fatores que precisam ser considerados como, por exemplo, o desempenho dos nós em geral em termos de CPU, memória, cache, etc, assim como o barramento em que estão conectadas as interfaces de rede, os drivers dessas interface e latência do sistema como um todo, dentre de outros fatores. Eficiência do protocolo TCP-IP: O protocolo TCP-IP comporta-se de maneira diferente em relação aos diferentes aplicativos e os parâmetros que o mesmo utiliza. Por exemplo, o protocolo NFS (Network File System) tende a ter uma melhor performance que o CIFS (Common Internet File System) em condições normais, sem nenhum ajuste de parâmetros de TCP-IP nesses aplicativos.
Overhead do TCP-IP e das camadas de rede inferiores: Existem uma quantidade significativa da banda das conexões de rede que são utilizadas para endereçamento, multiplexação, detecção e correção de erros que não será efetivamente utilizada para o tráfego de dados e manutenção do cluster. Esse overhead impede de utilizarmos capacidade total de banda disponível para tráfego efetivo de dados.
Abordagem e ferramentas de análise do desempenho do cluster
A nossa abordagem e estratégia de medição da performance será a seguinte: Medição e análise do throughput real das conexões de rede.
Estresse do cluster e análise, para confirmar a efetiva funcionalidade do mesmo. Teste e medição de memória.
Medição e análise do sistema em cluster e monoprocessado em ferramentas tradicionais de benchmark apresentadas no aplicativo hardinfo.
Medição e análise do sistema monoprocessado e em cluster utilizando um aplicativo de Design Digital (PovRay).
Medição e análise do sistema monoprocessado e em cluster utilizando um aplicativo de Inteligência Artificial (Breve).
181
Análise geral dos resultados
Medição e análise do throughput real das conexões de rede.
Utilizamos o aplicativo iperf para medir o throughput real das conexões de rede e como esperado não foi alcançada a banda passante de 1 Gigabits/sec que é a velocidade das interfaces de redes, pelos motivos explanados no início desse capítulo. Seguem as medições:
Figura 20
Percebemos que na transmissão unidirecional de pacotes obtemos a taxa de 644 Mbits/sec, 64% da banda nominal das interfaces de rede que são de 1 Gigabit Ethernet. Na transmissão bi-direcional obtemos os valores de 279 Mbits/sec num sentido e 411 Mbits/sec no outro. Isso é um indicativo que um dos computadores tem um melhor throughput, que seria aquele que tem uma configuração de hardware superior, que confirma o fato que esse quesito pode ser determinante na taxa de transferência de um sistema.
182
Consideramos uma taxa de transferência de 644 Mbits/sec adequada para um cluster com apenas dois nós, não sendo um impedimento para a utilização plena do mesmo. Essa afirmação será verificada nas próximas medições e análises.
Estresse do cluster e análise para confirmar a efetiva funcionalidade do mesmo
Para verificar o comportamento do cluster numa situação de estresse, estabelecemos o seguinte cenário: Nó 00 Aplicações executadas: Breve – Creature.tz PovRay – benchmark.pov Nó 01 Aplicação executada: Breve – Gatherers.tz PovRay – benchmark.pov
Utilizaremos a aplicação system monitor para medir a utilização de CPU, memória e consumo de banda do cluster.
183
Telas Nó 00:
Figura 21 – Execução das aplicações Breve e PovRay no Nó 00
184
Figura 23 – Medições de utilização CPU, Memória e Rede no Nó 00
185
Tela Nó 01
Figura 25 – Execução da aplicação Breve no Nó 01
186
Percebemos que apenas quando iniciamos a execução da renderização do arquivo benchmark.pov que a utilização de CPU em ambos os computadores chegou a 100%, porém a utilização de memória e o consumo de banda se mantiveram estáveis e em níveis baixos. Podemos afirmar nessa primeira análise que a renderização de imagens pelo menos em se tratando do PovRay possui uma tendência para utilização intensa de CPU. O tempo total de renderização do arquivo Benchmark.pov no nó 01 foi de 3 minutos e 58 segundos numa condição de saturação das CPU’s. A título de esclarecimento, como os processadores dos nós são Core Duo, os mesmos são apresentados como 4 processadores pelo system monitor. Podemos também afirmar que nas condições de testes estabelecidas o consumo de banda foi muito baixo, como uma sinalização que esse componente não será um fator de estrangulamento no ambiente proposto. Pela utilização consideravelmente baixa de memória durante a execução dos aplicativos no teste de estresse proposto, decidimos fazer um teste específico de memória para verificar o comportamento desse componente num cluster Kerrighed.
Teste e medição de memória
Utilizamos o aplicativo memtester para verificar as condições da memória do cluster, pois o seu uso durante a execução das aplicações PovRay e Breve foi muito reduzido. Esse aplicativo destina-se a verificar a integridade de memória RAM em Linux, realizando uma série de verificações. O comportamento do cluster Kerrighed nesse teste foi positivo, tendo em vista que o compartilhamento e a integridade da memória num cluster, uma DSM (Distributed Shared Memory), é um dos grandes desafios dessa tecnologia. Porém não foi possível utilizar 4.6 Gbytes nesse teste, apenas 2.4 Gbytes. Ao ultrapassarmos esse limite o cluster deixa de operar, necessitando-se uma reinicialização do mesmo. Seguem os resultados.
187
Telas Nó 01:
Figura 26 – Medição do uso da memória durante a execução do memtester
188
Tela Nó 00:
Figura 28 – Medição do uso da memória durante a execução do memtester
Concluímos em primeiro lugar que o cluster Kerrighed realiza a agregação das memórias físicas dos nós que o compõe. Temos o nó 00 com 2.075 MBytes de memória e o nó 01 com o 2.594 MBytes e o system monitor indicou uma memória total de cerca 4.600 MBytes (4.6 Gbytes). Esse agregado de memória passou pelos testes do memtester sem apresentar nenhum erro, indicando consumo de memória configurado ao executar-se o comando, que foi de 2.3 Gbytes. Assim podemos concluir que as aplicações PovRay e Breve nas condições em que foi realizado o teste de estresse do cluster realmente não demandam uma quantidade de memória significativa. Outra observação foi novamente a utilização baixíssima dos recursos de rede, em torno de 10 Kbps.
Medição e análise do sistema em cluster e nos nós com ferramentas de benchmark apresentadas no aplicativo hardinfo
Executamos as rotinas de benchmark do aplicativo hardinfo em cada nó separadamente e no próprio cluster, seguem os resultados:
189
Gráfico 1
O valor maior indica um melhor desempenho.
Gráfico 2
Menor valor indica um melhor desempenho.
Gráfico 3
190
Gráfico 4
Maior valor indica um melhor desempenho.
Gráfico 5
Menor valor indica um melhor desempenho.
Gráfico 6
191
Segue uma breve descrição dos testes de benchmark realizado pelo hardinfo:
CPU Zlib - compressão de dados utilizando o algoritmo Zlib em 64 MBytes de dados. CPU Fibonacci - cálculo do número 42 de Fibonacci.
CPU MD5 - Geração de hashing em MD5 para 312MB de dados. CPU SHA1- Geração de hashing em SHA1 para 312MB de dados. CPU Blowfish – Execução do algoritmo de criptografia Blowfish
FPU Raytracing – Programa para renderização de imagens utilizando a mesma técnica do PovRay.
Constatamos, mediante os valores levantados, que o desempenho do cluster é menor (apesar de ser muito próximo) ao desempenho do Nó 00 que é computador com a maior capacidade no cluster, pelo menos nas aplicações utilizadas no benchmark do hardinfo. Baseado nessas informações, podemos afirmar que o cluster SSI Kerrighed não seria uma infraestrutura viável pelo menos no que concerne ao desempenho, para os testes realizados pela aplicação hardinfo.
Ao discutir com a comunidade do Kerrighed o resultado dos testes realizados até esse momento do nosso trabalho, os profissionais ou pesquisadores (dentre eles profissionais da Kerlabs) que contribuíram com suas experiências com o cluster Kerrighed, elencaram as seguintes considerações:
Apenas aplicações desenvolvidas para processamento paralelo irão se beneficiar em termos de desempenho ao utilizarem o Kerrighed.
O Kerrighed irá apenas apresentar resultados práticos significativos quando executarmos vários processos simultaneamente em todos os nós que compõe o cluster.
Quanto ao memtester, um dos pesquisadores disse que ao fazer testes em memórias non-ECC utilizando essa ferramenta em nós individuais de seu cluster, como o memtester faz um locking de memória no espaço de usuário, ele não conseguiu testar toda a extensão da memória RAM. Ele sugeriu executar o memtester em todos os nós que compõe o cluster simultaneamente.
192
Para obtermos uma constatação definitiva da viabilidade do cluster Kerrighed, dentro das premissas propostas em nosso trabalho, como uma opção para o processamento de aplicações de Inteligência e Design Digital, no nosso caso o Breve e o PovRay, executaremos essas aplicações em ambiente standalone, verificando o comportamento das mesmas em relação ao ambiente em cluster, considerando os resultados e conhecimento adquiridos através dos testes e medições realizadas até esse estágio do trabalho.
Medição e análise do sistema em cluster e monoprocessado utilizando um aplicativo de Design Digital (PovRay)
Medir o desempenho do aplicativo PovRay foi relativamente simples, pois o mesmo apresenta o tempo de execução, ao finalizar uma renderização. Assim executamos o arquivo benchmark.pov em cada nó cluster em separado, executando o mesmo arquivo com cluster em operação. Executamos num primeiro momento o arquivo benchmark.pov em apenas um nó do cluster, após isso, executamos simultaneamente o arquivo nos dois nós que compõe o mesmo. Utilizamos o menor tempo de execução da renderização entre os dois nós como referência nessa medição.
Algo digno de nota ao realizarmos a execução do arquivo benchmark.pov em apenas um nó do cluster, foi que o shell (terminal) foi aberto e executado num nó do cluster e a imagem renderizada surgiu no outro nó que compõe o mesmo, comprovando a capacidade do cluster de migrar processos.
Gráfico 7 0 50 100 150 200 250 300 350 Nó 00 Nó 01 Execução em 1 Nó Execução em 2 Nós Execução em 2 Nós com alta Utilização
193
Constatamos que o tempo de execução do arquivo do PovRay é maior para cluster do que para o computador standalone com maior poder computacional que compõe o mesmo. Percebemos também, que ao executarmos o arquivo benchmark.pov concorrentemente nos dois nós, houve uma diminuição do tempo de execução, confirmando a tese que o cluster Kerrighed apresenta um melhor desempenho quando executamos vários processos simultâneos. Para reforçar a validade dessa hipótese, executamos em ambos os nós a simulação do Breve Gatherers.tz, assim como o benchmark.pov. O desempenho do Kerrighed, ao executar esses processos simultaneamente, melhorou significantemente, atingindo o mesmo tempo do execução do computador com melhor hardware que compõe o cluster. Porém em nenhum momento o Kerrighed obteve um melhor desempenho que o nó com a melhor configuração de hardware executando o mesmo arquivo do PovRay, trabalhando em modo standalone.
Concluímos que o cluster Kerrighed executando renderizações na aplicação PovRay, não provê um aumento de desempenho linearmente proporcional a quantidade de nós que compõe o cluster, mas apenas nos beneficiamos dos recursos do Kerrighed quando executamos vários processos ao mesmo tempo, podendo assim renderizar vários arquivos numa mesma plataforma virtual de hardware. Ao também discutirmos o tema com Marcos Pitanga, um dos profissionais especializados em cluster Linux no Brasil, autor de livros abordando essa tecnologia, o mesmo também confirmou que clusters SSI (Single System Image), realmente teriam esse comportamento, de utilizarem todos os recursos de um nó, até que os mesmos sejam exauridos, para que utilizem os recursos dos outros nós que compõe o cluster.
194
Medição e análise do sistema em cluster e monoprocessado utilizando um aplicativo de Inteligência Artificial (Breve)
A comparação entre o sistema em cluster e um nó que compõe o mesmo em modo standalone, utilizando o Breve, não foi tão direta e simples como a abordagem utilizada com o PovRay, pois as simulações do Breve são de execução contínua. Assim a proposta para essa avaliação foi baseada na medição do consumo de processador e memória RAM que cada instância do Breve consumiria no ambiente monoprocessado e em cluster, e por extrapolação verificar o aumento de capacidade de execução de simulações baseadas em IA realizadas pelo Breve no cluster. Ao iniciar os testes e medições, percebeu-se que como o Breve gera imagens em movimento no ambiente gráfico do Linux (GNOME), muito do processamento era consumido por esse processo como se pode verificar no resultado do comando “ps -eo pmem,pcpu,args | sort -k 1 -r | less” abaixo:
Figura 29 - Resultado do comando “ps” em ambiente monoprocessado
195
No ambiente com um computador standalone com 6 instâncias do Breve sendo executadas tivemos 68,6% do processamento para a interface gráfica e no cluster Kerrighed também com 6 instâncias de Breve, tivemos 90,3% do processamento consumido para esse mesmo fim. Mesmo com essa utilização acentuada de processador para a interface gráfica, percebemos que a utilização de processador para a execução do Breve no cluster é menor que a utilização de processador no ambiente monoprocessado, indicando numa primeira análise, uma maior capacidade execução de instâncias do Breve pelo cluster, pois esse percentual é calculado sobre a capacidade total de processamento do cluster. Como se pode verificar nas figuras acima, temos uma média de 0,2% da utilização total de processador para uma instância do Breve no cluster contra 0,5% de utilização total de processador no ambiente monoprocessado. Isso significa uma capacidade 150% maior de processamento de instâncias Breve pelo cluster em relação ao computador standalone. Seguindo a mesma linha de raciocínio, ao analisar o consumo da capacidade total de memória nos dois ambientes, percebe-se que a capacidade de memória para execução de instâncias do Breve no cluster é exatamente o dobro da capacidade do computador standalone.
A realização e a análise dos testes corroboraram para a constatação que o cluster Kerrighed em relação ao computador standalone possui um maior poder de processamento e capacidade de memória, podendo assim realizar ao mesmo tempo mais instâncias dessa aplicação, porém o tempo de resposta, isto é, o tempo de execução do Breve, foi praticamente o mesmo nos dois ambientes de teste.