Uma proposta Open Source para Serviço de Escalonamento Tolerante a Falhas SETolF

Transcrição

1 Uma proposta Open Source para Serviço de Escalonamento Tolerante a Falhas SETolF André Fiorin, Victor Alves, Eder Bastiani, Bruno Mozzaquatro, Rogério Turchetti 1 Núcleo de Técnologia e Informática Centro Universitário Franciscano (UNIFRA) Santa Maria RS Brasil {afiorin.ti, victor.ccomp, edersonbastiani, brunomozza, turchetti}@gmail.com Resumo. O grande tempo despendido para o processamento de aplicações complexas em computadores convencionais, faz com que essa atividade se torne inviável em máquinas comuns. A utilização de sistemas em grids para o processamento de aplicações, em sistemas distribuídos, tem apresentado um crescimento significativo nos últimos anos. Porém, a utilização de sistemas distribuídos envolve um custo muito grande, devido ao grande número e distribuição das máquinas do grid, bem como, alto custo de implementação e administração destes sistemas. Neste contexto, o presente trabalho propõe um Serviço para Escalonamento Tolerante a Falhas (SETolF). Este serviço permite ao usuário a execução de suas aplicações de forma distribuída, mesmo na presença de falhas de algum processo. Com base nisso, este trabalho descreve uma ferramenta de código aberto desenvolvida em Java para o gerenciamento de Grids com tolerˆancia à falhas. 1. Introdução A computação, nos últimos anos, vem apresentando grandes evoluções nas mais diversas áreas. Notavelmente, esse progresso ocorre com mais velocidade nas arquiteturas dos computadores e seus componentes [Silva and de Melo 2000]. Em virtude disso, o campo de programação e desenvolvimento de softwares tem apresentado grande avanço impulsionado pela adequação necessária às novas tecnologias de hardware que vêm surgindo. Porém, o avanço tecnológico a nível de hardware está chegando à um limite físico. Logo, o aumento de desempenho nas aplicações computacionais deve ser obtido por meio de softwares. A obtenção desse aumento de desempenho por meio de software envolve grandes recursos computacionais, e isso torna muito complexa a atividade de processar aplicações distribuídas perante falhas. Além disso, quando falhas são tratadas, é interessante a possibilidade de se reaproveitar os recursos já utilizados pelos processadores. Para que esse reaproveitamento seja possível, se faz necessário a utilização de métodos de recuperação por retorno, ou seja, checkpoints. Outro problema é a ociosidade dos processadores em sistemas distribuídos, devido o tamanho dos processos e poder computacional dos processadores. Para que isso não ocorra, é necessário um sistema de balanceamento de cargas para evitar que os processadores que terminam as suas tarefas fiquem parados até que uma nova tarefa seja designada para ser processada. E tudo isso envolve uma grande necessidade de gerenciamento. Uma boa alternativa pra realizar esse gerenciamento, é possuir uma ferramenta adequada, capaz de gerenciar essas funcionalidades.

2 Para tirar maior proveito dos recursos computacionais ociosos, surgiu a computação em grid. Sistemas distribuídos compostos por processadores independentes, heterogêneos e que se diferenciam de computadores paralelos pelo fraco acoplamento entre os processadores [Weber 2000]. A grande vantagem desse tipo de sistema é o aproveitamento máximo dos recursos computacionais existentes no grid, eliminando o problema de eventuais ociosidades que podem existir em computadores convencionais. Assim, este trabalho tem o objetivo de apresentar um ambiente para grids denominado de Serviço de Escalonamento Tolerante a Falhas SETolF de código aberto, desenvolvido em Java, para escalonar processos em grids visando manter o funcionamento normal do sistema mesmo na presença de falhas. Além disso, ele tem como objetivo abordar detalhes sobre novas funcionalidades que estão sendo implementadas, tais como: a execução de checkpoints distribuídos, uma ferramenta para facilitar o gerenciamento dos processos no grid, satisfazer requisitos de segurança, entre outros. Ressalta-se que o projeto, apesar de estar com várias tarefas já implementadas (Seção 3), ainda está em fase embrionária, pois pretende-se adicionar as novas funcionalidades ao serviço (Seção 4). Um ponto importante quanto a utilização do SETolF que deve ser destacado, é a distribuição das tarefas nos peers do grid. O balanceamento das cargas nos peers está diretamente ligado com o problema de ociosidade que pode ocorrer em sistemas distribuídos. Para previnir este problema se faz necessário o uso de uma ferramenta de escalonamento que ao distribuir os processos, tenha em vista o balanceamento das tarefas nos peers. A utilização de sistemas distribuídos para o processamento de aplicações possui um problema latente que é a ocorrência de falhas ou eventos imprevistos, pois muitos recursos computacionais estão envolvidos com os mais variados tipos de software, hardware, usuários e configurações [SETolF 2008]. Essas falhas provocam resultados incorretos, inesperados ou até mesmo com que o sistema fique inoperante com uma espera infinita por resultados. Para isso, o SETolF trabalha com um Serviço de Detecção de Defeitos Adaptativo (AFDService) proposto por Nunes [Nunes 2003], para fazer o monitoramento das máquinas que compõem o ambiente. Este serviço visa garantir que, em caso de falha de alguma das máquinas, o recurso escalonado seja notificado e o sistema continue operando mesmo na presença de falhas. Este artigo está organizado da seguinte forma: na seção 2 serão abordadas algumas características dos grids e exemplos de trabalhos relacionados. Na seção 3 é apresentada a estrutura e a arquitetura do SETolF. Na seção 4 serão apresentadas as propostas para o aperfeiçoamento do SETolF, e por fim, a conclusão desse trabalho. 2. Grids Segundo Foster [Foster 2004], o termo grid denota uma proposta de infra-estrutura de software e hardware para a integração de recursos computacionais, dados e pessoas geograficamente dispersos de modo a formar um ambiente colaborativo de trabalho. Para Krauter [Krauter et al. 2002], é um sistema computacional de rede que pode escalar ambientes do tamanho da Internet com máquinas distribuídas através de múltiplas organizações e domínios administrativos. Esta arquitetura tem se mostrado bastante produtiva, pois procura por recursos computacionais que estariam ociosos em locais geo-

3 graficamente distribuídos, com o intuito de utilizá-los de forma a maximizar o poder de processamento de tarefas. Geralmente, os grids funcionam com um nó central, denominado máquina base (master) que coordena o escalonamento, e as máquinas que executam as tarefas, denominadas máquinas do grid (peers). Como trabalhos relacionados, podemos citar o MyGrid, uma ferramenta que tem como objetivo principal simplificar o máximo a implantação de uma grade computacional para que usuários comuns possam criar a sua própria grade com os recursos que ele dispõe [Goldchenger 2004]. A estrutura da arquitetura do MyGrid é composta por dois tipos de máquinas: a máquina base e as máquinas do grid [Chiao and Silva 2004]. O MyGrid é instalado na máquina base. Esta, além de gerenciar a grade do usuário, armazena os programas que serão executados remotamente, os dados de entrada das tarefas e recolhe os resultados das tarefas computadas. O escalonamento, gerenciamento de tarefas e o monitoramento das máquinas do grid são as principais responsabilidades deste tipo de máquina da arquitetura. Geralmente a máquina base é aquela que o usuário utiliza diariamente, configurada como um ambiente de trabalho confortável. Já as máquinas do grid são as máquinas que compõem a grade computacional, sendo disponibilizadas para o usuário efetuar a execução de suas tarefas. No entanto é necessário que usuário tenha livre acesso a essas máquinas. São elas que recebem os dados passados pela máquina base e os executa [Silva et al. 2006] para que depois a máquina base recolha os resultados computados. Apesar de vários ambientes em grids não comentarem sobre a forma como é feita a detecção de falhas, alguns, como por exemplo o MyGrid, tratam as falhas somente em ambiente lan [Figueiredo et al. 2006]. Na próxima seção será apresentada a arquitetura do SETolF e seu funcionamento. 3. Estado Atual do SETolF O Serviço de Escalonamento Tolerante a Falhas (SETolF) proporciona ao usuário diversas funcionalidades para o processamento de aplicações distribuídas. Através do ambiente de programação distribuído fornecido pelo SETolF o usuário tem a disponibilidade de enviar suas aplicações para serem processadas de forma distribuída. peer. A arquitetura do SETolF é formada por três dispositivos: cliente, escalonador e O cliente é a máquina onde o usuário irá implementar a aplicação e poderá submete-la ao escalonador para efetuar o processamento. O Escalonador é responsável por gerenciar as aplicações submetidas pelo cliente, e escalonar as tarefas para serem executadas pelos peers. Por fim, os peers são as maquinas que o cliente tem à disposição para executar suas aplicações. É importante salientar que até o momento, não são consideradas falhas no escalonador. A figura 1 apresenta um exemplo do ambiente do SETolF. A comunicação do ambiente de programação distribuído com o AFDService,

4 Figura 1. Ambiente do SETolF. ocorre antes mesmo da inicialização do serviço, para que seja feito ajustes nas configurações, como: o tipo de algoritmo de detecção; o tipo de algoritmo de predição; o suporte a algoritmo de consenso; entre outros. A classe AppMaster, é considerada a mais importante do SETolF, pois tem como responsabilidade o gerenciamento de todo o ambiente. Para que o SETolF utilize o AFDService, a classe AppMaster registra um objeto da classe FDManager que cria uma instância do detector, permitindo que o ambiente defina configurações necessárias antes da inicialização, como o algoritmo de detecção, entre outras. Assim o ambiente utiliza funcionalidades do AFDService, como por exemplo iniciar o monitoramento através do método startmonitoring(). Para um peer ser notificado como suspeito, o SETolF implementa uma interface Notifiable para que possa ser consultado o estado de algum peer, de maneira síncrona, através dos métodos isitalive() e aretheyalive() do objeto da classe FDManager. Depois de inicializado o ambiente, a classe AppMaster aguarda a chegada de aplicações de clientes para serem processadas. Para a operação de recebimento das mensagens, tanto para ações de monitoramento quanto para comunicação entre os processos, é gerada uma thread receptora pela classe ReceiveServer. Assim que as mensagens são recebidas, elas são repasssadas à classe DeliveryBoy. A classe DeliveryBoy tem como responsabilidade de identificar, no campo MsgType, os tipos de mensagens recebidas. Mensagens do tipo teste são mensagens que o ambiente irá receber, por exemplo, uma requisição de conexão de um cliente ou um retorno de um processamento efetuado por um peer. A submissão das aplicações dos clientes são feitas através da classe ReceiveFile. Essa classe utiliza sockets para efetuar as transferências. O endereço do cliente (endereço IP) e uma porta padrão do SETolF são necessários para que seja estabelecida uma conexão, logo a transferência da aplicação é efetuada. A cada aplicação que é recebida pela classe AppMaster, é adicionada uma posição na Hashtable [Hashtable 2008] da classe MatrizAplicacao, que contém um índice e um

5 vetor. O índice é o endereço IP da máquina do cliente, já o vetor é um conjunto de informações fornecidas pelo cliente, através da mensagem enviada, no momento de envio da aplicação. Na classe FilaEspera as aplicações são colocada em uma fila conforme a ordem de chegada, que através de um repositório de algoritmos de escalonamento de tarefas serão escalonadas para os peers disponíveis no ambiente, para então serem processadas. Atualmente o SETolF faz o escalonamento de tarefas utilizando o algoritmo backfilling [Oliveira and Turchetti 2007] com base no algoritmo FIFO, ou seja, implementa uma fila de tarefas a serem executadas. A máquina escalonadora faz o monitoramento dos peers, identificando quem se encontra operacional. No caso de falha em algum dos peers que estão processando, o escalonador é notificado e reescalona a tarefa para que seja novamente processada. Na próxima seção serão apresentadas as propostas do trabalho realizado. 4. Novas Funcionalidades para o SETolF Este trabalho apresenta um novo serviço de processamento de aplicações distribuídas utilizando técnicas de tolerância a falhas. Novo porque trata o problema de explosão de mensagens em sistemas escalares e possibilita o escalonamento otimizado das tarefas através do aperfeiçoamento do algoritmo backfilling. Sua contribuição permite que novos estudos sejam realizados sobre o mesmo. Atualmente estuda-se a implementação de um sistema integrado para o gerenciamento dos peers com um monitor de ociosidade, um escalonador que utiliza a técnica de backfilling para tirar o máximo de proveito dos peers do sistema, e um mecanismo de checkpoint para a recuperação do sistema para eventuais falhas que possam ocorrer. O sistema de monitoramento e gerência do grid terá como objetivo analisar o consumo de banda por peer, fazer o monitoramento de ociosidade e o controle de peers ativos no grid. Para isso será desenvolvido um sistema de administração em PHP que será integrado às funções do SETolF. Assim tem-se uma ferramenta simples e que acompanha o grau de necessidade do trabalho. Para o escalonador, será utilizado o algoritmo backfilling, que é uma otimização do algoritmo FIFO (First-InFirst-Out) e permite que tarefas menores sejam deslocadas para frente na fila, e assim maximizar o throughput do sistema. Para utilizar este algoritmo, o escalonador deve levar em conta três fatores que podem afetar diretamente seu desempenho: a ordem de chegada da tarefa, o número de processos requisitados, e a estimativa de término do processamento. Além disto, para que funcione de maneira adequada será necessário a implementação de threads. Sua utilização é justificada pelo fato de que é preciso manter um monitoramento paralelo de cada tarefa lançada para processamento, assim é possível gerenciá-las da melhor maneira. Através das informações enviadas pelas threads para o módulo de escalonamento, este pode decidir se deve reescalonar alguma tarefa em decorrência de falha do peer ou se sinaliza a tarefa como processada com sucesso. Para alcançar um processamento com alto desempenho em sistemas distribuídos, devido a grande quantidade de processos, fica evidente a necessidade de aproveitamento máximo dos recursos de cada elemento pertencente ao sistema. A identificação dessa atribuição ideal de tarefas caracteriza o problema do balanceamento de carga.

6 Assume-se que, devido ao uso do AFDService, o escalonador está livre de falhas. Porém, a máquina base (cliente) ainda está vulnerável a falhas. Isso pode acarretar na perda de todo o processamento já efetuado e nas tarefas que estão sendo processadas pelos peers. Para contornar esse problema é necessário fazer com que, após a ocorrência de uma falha, a máquina que controla o grid retorne a um estado seguro, fazendo com que o processamento ocorrido até o momento da falha não seja perdido. Isso faz com que o nível de essencialidade da máquina base seja reduzido ao mesmo nível de um peer do grid. Para atingir esse objetivo, serão implementados mecanismos de checkpoint no cliente, contendo as informações necessárias para que seja possível fazer a recuperação das tarefas já processadas na máquina base e seja possível reescalonar as tarefas que estavam em execução nos peers para que possam ser concluídas. Estas propostas tem o objetivo de aprimorar o funcionamento do SETolF tendo em vista que o mesmo seja disseminado em outras comunidades para que possa ter suas funcionalidades incrementadas por outras pessoas. 5. Conclusão A utilização de grids fornece ao usuário uma gama de funcionalidades que permitem a implementação e execução de aplicações distribuídas com o máximo de aproveitamento dos recursos computacionais envolvidos. Neste trabalho foi apresentado um Serviço de Escalonamento para execução de tarefas em grid, com tolerância a falhas. Tais falhas não comprometem o serviço pois as tarefas atribuídas aos processos falhos, são destinadas novamente a processos ociosos. Essa funcionalidade possibilita que usuários criem aplicações distribuídas confiáveis. Além disso, observa-se que grande parte dos ambientes em grids não apresentam soluções para tratamento de falhas. O Mygrid detalhado na Seção 2, aprensenta um detector de defeitos para ambientes fechados, isto é, para redes locais. A proposta apresentada neste trabalho está apoiada sobre um serviço de detecção de defeitos projetado para ambientes escalares, pois o mesmo preocupa-se na economia de mensagens, sendo que este é um dos principais problemas nestes ambientes [Turchetti and Nunes 2006]. Também destaca-se o uso de técnicas de escalonamento de tarefas backfilling que permite a utilização máxima dos processos que compõem o sistema. O backfilling é um escalonador que não possui tolerância a falhas em seu estado nativo, neste trabalho uma nova variação deste algoritmo (está sendo) foi implementado com o objetivo de adicionar tal funcionalidade. Como a ferramenta, no atual estado, já trata falhas, é possível obter ganho de desempenho a ambientes de programação distribuídos convencionais, pois mesmo que um peer falhe, a aplicação é executada. Atualmente a feramenta está em fase terminal da parte do escalonador backfilling. Salienta-se que propostas ainda estão em fase de implementação, tais como: a implementação de checkpoint distribuído, para evitar que, em caso de falha, parte do processamento concluído seja perdido; e um sistema de monitoramento para gerenciar quais peers do grid são mais adequados para o processamento de cada tarefa, tendo em vista o balanceamento das cargas dos processadores para que se obtenha o mínimo de ociosidade possível nos recursos disponíveis do grid.

7 Referências Chiao, C. M. and Silva, H. (2004). Obtenção de tolerância a falhas na ferramenta de computação mygrid. In ERRC 2004 II Escola Regional de Redes de Computadores. Canoas RS. Figueiredo, F., Brasileiro, F., and Brito, A. (2006). Implementing a distributed execution service for a grid broker. In SBRC o Simpósio Brasileiro de Redes de Computadores. Curitiba - PR. Foster, I. (2004). In The grid 2: Blueprint for a new computing infrastructure. Goldchenger, A. (2004). Integrade: Um sistema de middleware para computação em grade oportunista. In Dissertação de Mestrado em Ciḙncia da Computação. Universidade de São Paulo (USP) São Paulo SP. Hashtable, W. (2008). Hash table documentation. In - Acesso em setembro de Krauter, K., Buyya, R., and Maheswaran, M. (2002). A taxonomy and survey of grid resource management systems for distributed computing. In Software: Practice and Experience (SPE) - Wiley Press - USA. Nunes, R. C. (2003). Adaptação dinâmica do timeout de detectores de defeitos através do uso de séries temporais. In Tese de Doutorado em Ciḙncia da Computação - Universidade Federal do Rio Grande do Sul. Oliveira, G. M. and Turchetti, R. C. (2007). Proposta de implementação de um escalonador de processos tolerante a falhas. In WSCAD VIII Workshop em Sistemas Computacionais de Alto Desempenho. SETolF, W. (2008). Serviço de escalonamento tolerante a falhas setolf. In turchetti/ - Acesso em Abril de Silva, A. M. and de Melo, A. C. (2000). Sistemas de memória distribuída compartilhada tolerantes à falhas baseados em checkpoint coordenado. In LAICO Workshop Grupo de Sistemas Computacionais - Universidade de Brasília. Silva, H. A., Pôrto, I. J., and Weber, T. S. (2006). Implementação de um mecanismo de recuperação por retorno para o ambiente de computação ourgrid. In WTF VII Workshop de Testes e Tolerˆancia a Falhas - Universidade Federal do Paraná, Curitiba - PR. Turchetti, R. C. and Nunes, R. (2006). Uma nova abordagem para otimizar a comunicação entre detectores de defeitos não confiáveis. In WSCAD VII Workshop em Sistemas Computacionais de Alto Desempenho. Weber, T. S. (2000). Arquiteturas tolerantes a falhas. In WTF II Workshop de Testes e Tolerˆancia a Falhas., Universidade Federal do Paraná, Curitiba - PR.