Grid Computing – Parte 01

Introdução

Hoje vou entrar em um assunto que não é novo, mas que é pouco explorado devido a complexidade intrínseca de implementação: Grid Computing. Lembrando dos princípios e técnicas de performance e escalabilidade, onde uma delas é procurar obter benefícios de escalabilidade com execução de operações simultaneamente em vários equipamentos (paralelismo).

A computação em grid ou distribuída pode ser vista como um tipo particular de computação distribuída, onde vários equipamentos completos e independentes (não apenas CPUs) são interconectados por uma rede (Ethernet), atuando juntos para processar grandes tarefas.

A definição de computação paralela e distribuída são muito próximas, mas é possível classificá-las independentemente por um critério básico: Em computação paralela, todos os processos têm acesso a uma memória compartilhada para trocar informações entre processos, enquanto na computação distribuída, os processos trocam mensagens entre si, normalmente por uma conexão de rede.

Tamanhos de Grid

Um Grid pode englobar computadores geograficamente próximos ou distantes, e consequentemente ter uma pequena, média ou grande escala. Um dos maiores projetos de Grid colaborativo em larga escala (mundial) foi o projeto SETI@home, da NASA, lançado em 1999, onde cada voluntário fazia o download de um programa para processamento de dados de áudio em seu computador, e quando o equipamento estava IDLE ou na proteção de tela, o programa baixava da internet automaticamente um pacote de áudio para análise, e após o processamento enviava o resultado de volta ao servidor. A capacidade de processamento deste conjunto, com aproximadamente 145 mil equipamentos ativos em 233 países era capaz de processar 668 teraFLOPS!

Onde cabe o uso de Grid

Normalmente Grids de computadores são usados na resolução de problemas matemáticos, científicos e acadêmicos, bem como em empresas para aplicações como descoberta de novos remédios, previsão monetária, análise sísmica, e processamento de retaguarda para comércio eletrônico e Web Services.

Porém, se um problema computacional pode ser adequadamente paralelizável, o uso de uma camada leve de infra-estrutura de grid pode permitir que programas stand-alone recebam partes do processo para serem executadas em várias instâncias de processamento distribuídas em múltiplos equipamentos.

Vale atenção especial na sentença “adequadamente paralelizável”, veremos que atender a esta premissa não é cabível a todos os processos de um sistema, e envolve mais de uma característica de processo, relacionadas a entrada e saída de dados e ao processamento em si. Veremos estes detalhes em profundidade no momento oportuno. Vamos ver primeiro onde ele pode ser aplicado!

Cálculo de Folha de Pagamento

Um cálculo da folha de pagamento dos funcionários de uma empresa, onde cada funcionário possui seu registro de ponto e histórico de exceções em um período. Este é um bom exemplo onde o paralelismo de um grid de processamento serve muito bem.

Em uma aplicação de cálculo de folha de instância única, um programa de cálculo de folha de pagamento é executado em um processo, onde este processo vai calcular, em sequência, a folha de pagamento de cada funcionário no período, um a um. Este programa, em uma única instância sendo executada em um único equipamento, não consegue utilizar todo o poder de processamento deste equipamento.

Logo, em um primeiro momento, podemos ganhar paralelismo alterando o programa para que ele iniciar vários jobs de processamento na mesma máquina, onde cada um deles recebe um código de funcionário diferente para calcular, onde o número de jobs iniciados indica quantos cálculos simultâneos serão feitos. O programa principal pega a lista de códigos ded funcionários a calcular, e passa o código de cada funcionário para o primeiro job livre, até que todos estejam ocupados, e cada job que termina de calcular um funcionário pega ou recebe o código do próximo da lista.

Agora sim, com um número maior de jobs, podemos usar todo o poder de processamento desta máquina, onde aumentamos o número de jobs dedicados até um ponto antes de algum limite computacional ser atingido, como tráfego de rede entre a máquina de processamento e o Banco de Dados, ou as CPUs do equipamento não atingirem 100%.

Se mesmo assim, o uso de uma máquina com jobs não seja suficiente, pois existe por exemplo um tempo curto para o fechamento da folha, e o número de funcionários cresceu com uma fusão de empresas ou absorção do quadro de funcionários de uma empresa do grupo, a solução é usar o processamento de mais de uma máquina. Neste caso, caberia bem o uso de uma infra-estrutura de Grid. Adicionando-se em cada equipamento uma ou mais instâncias de um serviço dedicado ao cálculo dos funcionários, e criando um mecanismo client-server entre o serviço que está solicitando o processamento dos funcionários e todos os jobs disponíveis e dedicados a este cálculo, vários funcionários são processados ao mesmo tempo em equipamentos diferentes, e os resultados de cada cálculo é gravado no Banco de Dados.

Ganho esperado

Esta escalabilidade não é infinita, mais cedo ou mais tarde algum limite computacional do conjunto vai ser atingido, e não necessariamente dobrar o número de máquinas vai dobrar a sua capacidade de processamento, afinal temos que levar em conta uma fatia de tempo do mecanismo de distribuição em trafegar os códigos para o cálculo, e que cada processo pode pedir mais informações ao mesmo tempo e de funcionários diferentes para o Banco de Dados, mas mesmo assim um processo que demorava 10 horas para ser executado em 4 jobs dentro de uma máquina, ao ser divididos em 12 jobs distribuídos em 3 máquinas pode terminar a tarefa completa por exemplo em apenas 4 horas.

Dificuldades intrínsecas

Uma das primeiras dificuldades em um Grid deste tipo é determinar o número ideal jobs dedicados por máquina a serem dedicados para um processamento distribuído. Este número é empirico, e será determinado pela natureza do processamento versus capacidade de tráfego de dados e transações do ambiente computacional. Normalmente um grid busca aproveitar o poder de processamento de um conjunto de máquinas que normalmente estão executando outros processos de outras partes da aplicação, que não consomem todo o recurso computacional da máquina. Porém, um número fixo de jobs de grid executados nesta máquina, junto com outros processos em execução, podem atingir um limite computacional deste equipamento, prejudicando os outros processos desta máquina. A engine de Grid ideal precisaria ser capaz de monitorar as máquinas envolvida, atuando sobre a quantidade de jobs dedicados durante a execução, para atingir a “crista” da onda da curva de desempenho sem esgotar os recursos das máquinas envolvidas.

Determinar quais processos aderem com eficiência à execução em Grid, como eu mencionei anteriormente, é um processo um pouco mais complexo, e envolvem muitas características do processamento, e devido à sua extensão, este tema será abordado com uma lupa em um próximo post.

Deve-se também projetar uma infra-estrutura para distribuição das mensagens de processamento de forma eficiente e o mais leve possível, garantindo ao final do processo que todas as mensagens tenham sido entregues e processadas com sucesso, e em caso de falha ou ausência de retorno — como por exemplo uma queda ou término anormal de um agente de processamento — esta infra-estrutura possa permitir por exemplo o re-envio daquela requisição a outro agente, ou notificar o programa cliente desta ocorrência para que este tome a decisão sobre o que fazer.

ERP Microsiga e Grid de Processamento ADVPL

O ERP Microsiga Protheus possui algumas rotinas que utilizam um mecanismo de processamento em Grid, onde cada máquina virtual servidora do Protheus pode ser configurada como um agente de processamento, e um serviço único é configurado como o coordenador da distribuição dos agentes para processos do Grid ADVPL. Cada funcionalidade que utiliza o Grid compartilha internamente de uma camada comum de abstração “client” do Grid, onde o programador deve implementar uma função de preparação de processo dedicado e uma função de execução de requisição, e a infra-estrutura do grid garante a inicialização dos processos, distribuição de requisições e controle de execução das requisições de um processo que se utiliza do Grid. Não conheço todas as rotinas, mas sei com certeza que o cálculo de folha de pagamento do ERP possui uma opção de processamento para usar o Grid ADVPL.

Este post é a pontinha do iceberg … a cada post deste tema vamos nos aprofundar um pouco mais nas particularidades deste paradigma, que pessoalmente eu acho muito, muito interessante ! Até o próximo post, pessoal 😉

Referências

Wikipedia contributors. Distributed computing. Wikipedia, The Free Encyclopedia. November 20, 2014, 04:59
UTC. Available at: http://en.wikipedia.org/w/index.php?title=Distributed_computing&oldid=634650954.
Accessed November 27, 2014.

Wikipedia contributors. Grid computing. Wikipedia, The Free Encyclopedia. November 23, 2014, 13:50 UTC.
Available at: http://en.wikipedia.org/w/index.php?title=Grid_computing&oldid=635101070. Accessed November
27, 2014.

Wikipedia contributors. SETI@home. Wikipedia, The Free Encyclopedia. November 26, 2014, 13:42 UTC.
Available at: http://en.wikipedia.org/w/index.php?title=SETI@home&oldid=635510528. Accessed November 27,
2014.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s