libcomuna Um framework para o desenvolvimento de aplicações paralelas tolerante a falhas baseado em troca de mensagem.

Transcrição

1 libcomuna Um framework para o desenvolvimento de aplicações paralelas tolerante a falhas baseado em troca de mensagem. Marco Yudi de C. Hirata, Marcelo Soares Souza, Anderson F. V. Boa Morte, Saulo Andrade, Josemar Rodrigues de Souza. CEBACAD Centro Baiano de Computação de Alto Desempenho Universidade Católica do Salvador (UCSal) Avenida Cardeal da Silva 205, Federação Salvador - BA Brasil {anderson, josemar, marcelo, yudi, saulo }@cebacad.net Abstract. This article present a framework for paralell application development, based on message- passing, that aims for diminishing the development complexity and proventing fault tolerance features not available on MPI 1.1 standard. Resumo. Este artigo apresenta um framework para o desenvolvimento de aplicações paralelas, baseado em troca de mensage m, tendo como finalidade imediata diminuir a complexidade do desenvolvimento e adicionar características de tolerância a falha não presentes no padrão MPI Introdução Inspirado no projeto Beowulf os clusters de computa do res baseado em estações de trabalho e redes convencionais, possibilitaram que instituições, com limitados recursos financeiros, viabilizassem a construção e o uso de computa dor es de alto desem pen ho apenas utilizan d o- se de componen tes Off The Self [1]. As arquitetura s de comput ad or es paralelos tem como principal objetivo o aumento da capacidade de processame nto, utilizando o potencial oferecido por um grande número de recursos computacionais [2]. Tradicionalmente, os clusters baseados em troca de mensagens foram constr uídos tendo como principal preocupação o provimento de um ambiente eficiente e portável, relegando a segundo plano a questão da confiabilidade. Pradhan (1996) diz que, apesar da percepção geral de que os sistemas paralelos possue m alta confiabilidade, devido a redundâ ncia dos recursos computacionais, na realidade estes sofrem de uma alta taxa de falhas [3].

2 Um outro empecilho ao desenvolvimento de soluções paralelas baseado em troca de mensagem, seguindo o padrão da indústria MPI (Message Passing Interface ), é a alta complexidade encontra da nesta tarefa. Entre os principais problemas encontrados no desenvolvimento destas aplicações podemos destacar: baixa reutilização de código entre aplicações, dificuldade de aprendiza do de uma nova forma (lógica) de resolução de problemas e a dificuldade de depuração em um ambiente distribuído. Apresenta m o s neste artigo um framework desenvolvido com o intuito de fornecer algumas características de tolerância a falha, tornan d o o ambiente para o processa me n t o de grandes massas de dados mais confiável, e que possibilite o desenvolvimento de aplicações paralelas de forma mais simples e transpa rente ao desenvolvedor. 2. Computadores Paralelos Virtuais Os Computa dore s Paralelos Virtuais, também conhecidos como NoW (Network of Workstation ), são um conjunto heterogêneo ou homogeneo de comput ad o res convencionais, que conectados atráves de uma rede, permitem a paralelização da execução de suas transações. Para tanto, utilizam um middleware que permite que este conjunto heterogêneo de computa d o res (seriais, paralelos ou vetoriais) seja visto como uma única máquina [4]. Os computa d or es que seguem a arquitetura propos ta por Von Neumann já esbarram em alguns limites físicos na busca de máquinas mais velozes, evidenciando a chegada do limite das arquitetur as seqüenciais [5]. Este fato explica, em parte, o crescente interesse nas NoW. Os clusters são de fato uma rede de computa d or es, porém possuindo a particularidade de funcionar como uma máquina paralela, daí o fato desses serem chama dos de máquinas paralelas virtuais. Cada máquina componente de um cluster é chamada de nodo. Conforme aponta do por Tanenbau m (1990), uma NoW é um tipo de cluster e se enquadra dentro do contexto de computa do r paralelo (figura 1) [6].

3 Figura 1: Extensão da taxonomia de Flynn Uma das vantagens evidentes das NoWs é a alta disponibilidade e expansabilidade do sistema [6]. Sendo um conjunto de máquinas independen tes, conectados por uma rede local, com o espaço de endereço de memória isolado, torna- se trivial adicionar ou substituir um novo recurso caso seja necessário. Patterson (2003), contudo demons tra que os clusters baseados em troca de mensage m possue m um custo de propriedade maior quando compara do aos comput ad ore s multiprocessados de memória compar tilha da [7]. A administração de um cluster de N máquinas se aproxima do custo de administração de N máquinas independente s, enquanto o custo de administração de um multiprocessa do de espaço de endereços compar tilha do com N processadores está perto do custo da administração de uma única máquina de grande porte [7]. 3. Tolerância a Falhas em Clusters As técnicas de tolerância a falhas tem como objetivo obter sistemas comput acionais confiáveis e com uma maior dependabilidade (dependabilty ). Dependabilidade engloba diversos conceitos, que servem de medida para confiabilidade (reliability ), disponibilidade (availability ), segurança (safety ), mantenabilidade (maintainability ), compro metime nt o do desempe nho (perfor mability ), e testabilidade (testability ) [3].

4 O termo "tolerância a falhas" foi apresen t a d o originalme n t e por Avizienis em Entretan t o estratégias para constr ução de sistema s mais confiáveis já eram usad as desde a construção dos primeiros computadores. Apesar de envolver técnicas e estratégias tão antigas, a tolerância a falhas ainda não é uma preocu p ação rotineira de projetistas e usuários, ficand o sua aplicação quase semp r e restrita a sistemas críticos e mais recentemente a sistemas de missão crítica. (Weber, 2003) Apesar disso, em seu trabalho Batchu (2003), demons tra que o padrão MPI apenas se preocupa em fornecer alta performa nce, escalabilidade e portabilidade entre arquiteturas [8]. A implementação de características que tragam uma maior confiabilidade ao padrão implica em custos adicionais, o que compro mete as metas do Fórum MPI. Tornou- se claro que a ênfase em alta performa nce levou o padrão a um modelo limitado, com pouca capacidade de manipulação de erros. Gropp (2004), criador de umas das principais implementações do MPI, o MPICH, garante que o padrão cobre funcionalidades tais como comunicação confiável, tratadores de erros e ainda provê flexibilidade na definição de um conjunto de erros, tornando - o apropriado para a tolerância a falhas [9]. 3.1 Fases de aplicação das técnicas de Tolerância a Falhas A aplicação das técnicas de tolerância a falhas podem ser dividida em quatro fases: detecção, confinamento, recuperação e tratament o [10]. A detecção de um erro ocorre apenas quando uma falha se manifesta como um erro. Uma falha pode encontrar - se latente antes de se manifestar como um erro, sem nunca comprome ter o sistema. Os mecanismos de detecção de erros baseiam- se geralmente em redun d â ncia. O conceito de redun d ân cia implica na adição de informação, recursos, ou tempo além do necessário para o funcionamento normal do sistema. A fase de confinamento estabelece limites para a propagação do dano causado, mas está ligada diretamente com decisões estabelecidas na especificação de cada projeto. A recuperação de erros ocorre após a detecção deste, e também envolve especificações do projeto. Geralmente isso envolve o custo de refazer totalmente a tarefa perdida após a detecção do erro. A última fase, tratament o de falhas, consiste em localizar a origem do problema, reparar a falha e recuperar o restante do sistema. Após a localização da origem do erro, o componente com problema deve ser isolado para que este não gere mais erros para o restante do sistema, como procura m os utilizar técnicas dinâmicas, o processo de isolamento passa a ser de forma lógica, sem o isolamento físico.

5 O elemento controlador (Mestre) passa a desconsiderar qualquer informação gerada pela fonte problemas [10]. 3.2 Técnicas para a recuperação de falhas Checkpoint e log são as técnicas de recuperação de falhas mais comu men te utilizadas. Checkpoint registra durante a execução de dado processo todas as informações sobre o estado deste, em um local de armazena me n t o confiável [3]. A qualquer instantes estas informações poderão ser utilizadas pelo sistema para que este possa retornar a um destes pontos e ser reiniciado na ocorrência de uma falha. Outra técnica amplamente utilizada é a de log, esta técnica consiste em um histórico armazena d o dos eventos associados ao estado do processo, para que se possa executá- los a partir do log localizados entre o último checkpoint dos processos falhos e o momento da falha [3]. 3.3 Impleme ntação de Tolerância a Falhas no MPI Grupos de pesquisa propusera m e desenvolveram soluções de tolerância a falhas para o padrão MPI, aplicando algumas das técnicas mais utilizadas. CoCheck utiliza a técnica de checkpoint, implementa d a através de um coordena dor central, mas que incorre em um grande overhead devido ao registros dos checkpoints. Egida baseia- se na técnica de log de mensagens com recuperação trans parente, mas também incorre em um excessivo overhead [11]. O FT- MPI é uma das soluções que não implementa as técnicas tradicionais de tolerância a falha, esta foi desenvolvido por Batchu (2003) e traz fortes mudanças a semântica do padrão MPI, e por isso é amplamente criticado por Gropp. O FT- MPI implementa um gerenciador de falhas através da manipulação da estrut ur a do padrão MPI comm u nicator [8]. Um processo só pode comunicar - se diretame nte com um outro, caso ambos pertença m a um mesmo comm unicator. Quando uma falha ocorre, todos os processos no com m u nicator são informados sobre a sua ocorrência (falha da mensagem ou do nodo). Esta informação é trans mitida para a aplicação através de um código de retorno. Essa soluçao tem como principal vantagem a perfor mance, pois não implementa checkpoints ou log de mensagens [11]. MPICH- V é uma solução escalável e que provê checkpoint completo e log de mensagens [9]. Tem como incoveniente a necessidade de um subsistema dedicado e confiável para o armazena me n t o dos checkpoints e log de mensagens.

6 Entre os problemas encontrados nas soluções propostas estão a existência de alto overhead ou ainda modificações não previstas ao padrão MPI. 4. Solução Proposta: Framework libcomuna Buscou- se inicialmente no desenvolvimento do framework libcomuna trazer características de Orientação a Objetos ao desenvolvimento baseado no padrão MPI 1.1, objetivando a diminuição da complexidade no desenvolvimento de aplicações paralelas e uma maior reutilização de código. O framework foi desenvolvido em C/C+ + e é composto de onze classes tendo como base funções do MPI 1.1 encapsuladas, proporcionan do assim uma interface mais intuitiva para o desenvolvimento de aplicativos e algoritmos paralelos. Por fazer uso de t hreads no gereciamento de nós a libcomuna herdar funcionalidades do Framework GNU Common C+ + em duas de suas classes. Apenas enfatiza mo s neste artigo as características de tolerância a falha deste framework, inexistente nativamente no padrão MPI Tolerância a Falha no libcomuna A solução proposta e desenvolvida para o provimento de tolerância a falhas implementa um relógio de ponto responsável pela verificação dos nós pertencente ao clusters. Uma área comum de memória secundária é compar tilhada atráves do sistema de arquivos distribuídos NFS (Network File System ), e é utilizada com a finalidade de arma zena me n t o de uma estrutur a que possui três colunas (rank, status e key) que representa m as informações básicas do processo de um trabalhador. Ressaltamos que a maneira adotada para compartilhar estes dados está se tornando comum na construção de clusters baseado em estações de trabalho diskless, inclusive trazendo grandes avanços na área de sistemas de arquivos distribuídos. O rank representa a posição e o id do trabalhador dentro do cluster. Status deter mina o estado atual em que se encontra o trabalhador, podendo assumir os valores: Stop, Working, End e Fail. Key é uma chave única gerada pelo Mestre a cada turno de assinatur a do relógio de ponto, que juntamente com o estado poderá julgar a operabilidade do trabalhador dentro do cluster. Ao iniciar o processamen to, o mestre envia uma mensagem a cada trabalhador, contendo uma chave (key ) única gerada aleatoriamente, confor me demonst ra d o na figura 2.

7 Figura 2: Distribuição de Chaves aos Trabalhadores. Em seguida o processamen to é distribuído pelo mestre seguindo critérios de balanceame nto estáticos, descrito no código- fonte. É determinada previamente quais os dados que cada trabalhador irá processar. Dessa forma, caso haja alguma falha em algum nó os dados poderão ser escalonado a um outro trabalhador disponível. O balanceament o estático deve ser feito atráves de uma caracterização prévia do ambiente. Em seguida inicia- se o processa me nt o dos dados, cada trabalhador assina o relógio de ponto com a chave (key) recebida do mestre. Transcorrido um deter mina do tempo de processame nt o, estabelecido pelo desenvolvedor, um thread de gerencia no mestre é ativado verificando o estado dos trabalhadores, checando se todos os nós do cluster assinara m o ponto com a chave distribuída inicialmente. Todos as chaves (key) são renovadas pelo mestre e os trabalhadores devem novamente assinar o ponto. Caso, ao assinar o relógio de ponto, o trabalhador não possuir a chave correta de acordo com a chave do turno, entende - se que houve algum problema e o número de faltas deste trabalhador é incrementad o. Se o trabalhador voltar a responder antes de ser considerado inoperante (atráves de um tempo pré- estabelecido pelo desenvolvedor) o contado r de faltas do mesmo é zerad o. Essa medida foi tomada levando em consideração o fato de que, cada rede possui suas particularidades e até mesmo os processos concorrentes no nó do cluster podem atrasar a assinatur a do relógio de ponto pelo trabalhador.

8 O trabalhador é considerado em estado errôneo caso o número de faltas seja alcançado, este número é determinado pelo desenvolvedor da solução. Detectado o estado de falha, o Status do trabalha dor, no relógio de ponto, é definido como falho (Fail) e sua tarefa é escalonado ao primeiro trabalhador que se encontre disponível. 5. Metodologia utilizada nos experimentos O experimento conduzido se deu no cluster da Universidade Católica do Salvador (UCSal). O ambiente utilizado consistiu de um ambiente heterogêneo descrito nas tabela 1 utilizando - se do Sistema Operacional GNU/Linux, kernel , mpich que implementa todo o padrão MPI 1.1 e o compilador gnu gcc A rede de conexão utilizada é baseada no padrão Ethernet utilizando um hub de 10 mb/s. Para os experimentos foi desenvolvido uma livre adaptação do algoritmo de multiplicação de matrizes Fox [12] em C++ utilizando do framework libcomuna. O paradigma Mestre/Trabalha dor (MT) foi utilizado para o desenvolvimento da solução. O ambiente foi previamente caracterizado e as matrizes de ordem 1000, 1500 e 2000 foram geradas aleatoriamente antes da primeira execução. Tabela 1: Especificação do cluster local UCSal host Função Processador Memória Balanceamento infoquir3 mestre Pentium III 500 Mhz 64 MB 59.00% infoquir2 trabalhador Pentium 166 Mhz 32 MB 10.00% infoquir5 trabalhador Pentium 133 Mhz 32 MB 8.00% infoquir6 trabalhador Pentium 133 Mhz 32 MB 8.00% infoquir7 trabalhador Pentium 133 Mhz 32 MB 8.00% infoquir8 trabalhador Pentium 133 Mhz 32 MB 8.00% Houve a inserção de uma falha atráves da desconexão física de um nó do cluster. Esperou- se o término da execução do algoritmo para a validação da solução, sem que este ficasse bloqueado (blocking ) e da verificação final do número de pacotes processados, a solução mostrou - se eficaz na tolerância desta falha. Para análise foram levantados dados relativos a execução do algoritmo de forma serial, paralelizada sem presença da falha e com a presença da falha. 6. Resultados Obtidos O resultado é sintetizado na tabela 2 e demonstr ad o na figura 3 onde se nota claramente que testes sem a presença de falha ficaram muito próximo aos testes realizados com falha. Tabela 2: Resultados Obtidos em Tempo de Execução (seg.) Ordem (n) Paralelo com falha Paralelo sem falha Serial

9 É notável que o processa men t o de matrizes de ordem inferior a 1000 não apresenta m qualquer ganho significativo de perfor ma nce quand o paralelizado, ocorrendo em deter minad o s momento s até uma discreta diminuição do desempen h o. Este fato ocorre devido as características da rede e do alto custo ligado a comunicação entre os nós em uma rede baseada em Ethernet e TCP/IP. Serial x Paralelo x Paralelo com falha Tempo (seg) Ordem das matrizes(n) Paralelo com falha Paralelo Serial Figura 3: Resultado Paralelo Sem Falha x Paralelo com Falha x Serial O algoritmo de multiplicação de matrizes é considerado um paralelismo de dados, sendo muito dependen te da latência e largura de banda do barrament o de comunicação em que se encontra. Dessa forma o processa me nt o de forma serial de matrizes de pequena ordem não apresenta m o alto custo de comunicação dos dados, assim proporcionan do uma performa nce melhor em relação ao algoritmo paralelizado. 7. Conclusõe s Os resulta dos obtidos demonst ra m a eficácia da solução apresentada em provê aspectos de tolerância a falha, sem no entanto constatar diminuição significativa do desempe nh o no comput o geral. Os aspectos de tolerância a falha implementa do s no framework não se baseiam diretamente em nenhu m a das técnicas propostas, por outros projetos de pesquisa, que se dispusera m a implementar técnicas de recuperação de falhas no MPI, tais como checkpoint ou log. O algoritmo proposto terminou sua execução mesmo na ocorrência da falha, que se deu através de desconexão física de um nó do cluster. Os custos envolvidos na implementação de características de tolerância a falha diminuem a medida que se aumenta a demanda por poder computacional, conforme apresenta do nos experimentos atráves do aumento da ordem das matrizes utilizadas.

10 Muitas melhorias e acréscimos ao framework libcomuna vem sendo planejadas tais como a remoção da necessidade do uso do sistema de arma ze na me n t o distribuído, tornando o algoritmo mais trans parente e menos dependente do ambiente utilizado. Outras melhorias em planejamen to é a capacidade de caracterização e balanceament o dinâmica do ambiente e aumento de trans parência entre o processame nt o e o gerenciamento do clusters, fazend o com que o algoritmo possa suportar de forma mais simples outras variações de algoritmos de cálculo. 8. Referências [1]Beowulf. What makes a cluster a Beowulf?. Disponivel na Internet via WWW. URL: / overview/index.ht ml. Arquivo Capturado em 30 de Dezembro de [2] Sterling, Thomas L. Salmon, John. Becker, Donald J. e Savaresse, Daniel F. How to build a Beowulf: a guide to the implementation and aplication of PC clusters. Massachusett s Institute of Technology [3] Pradhan, Dhiraj K. Fault Tolerant System Design. Prentice Hall, New Jersey, [4] Souza, Josemar; Souza, Marcelo; Micheli, Milena. Influência da comunicação no rendiment o de uma máquina paralela virtual baseada em Redes ATM I Workshop Aplicações Internet2, MetroPOA PUCRS, Porto Alegre, Rio Grande do Sul, Brasil. Anais [5] Akl, Selim G. The Design and Analysis of Parallel Algorithms. Englewood Cliffs, New Jersey: Prentice Hall, [6] Tanenbau m, Andrew S. Organização Estrutura da de Computa dor es. 3. ed. Rio de Janeiro: LTC Livros Técnicos e Científicos Editora, p. [7] Patterson, David A., HENNESSY, John. - Arquitetura de Computa dor : Uma Abordagem Quantitativa; tradução de Vandenberg D. de Souza. - Rio de Janeiro : Campus, [8] Batchu, Rajanikanth Reddy. Incorpora ting Fault- Tolerant Features into Message- Passing Middleware. Maio de f. Dissertação de Mestrado. Department of Computer Science and Engineering, Faculty of Mississippi State University, Mississippi, [9] Gropp, William; LUSK, Ewing. Fault Tolerance in MPI Programs. International Journal of High Performance Computing Applications, August 2004, vol. 18, no. 3, pp [10] Weber, Taisy Silva. Um roteiro para exploração dos conceitos básicos de tolerância a falhas. Apostila do Programa de Pós- Graduação Instituto de Informática - UFRGS. Porto Alegre, 2003.

11 . Tolerância a Falhas: Conceitos e exemplos. Apostila do Programa de Pós- Graduação Instituto de Informática - UFRGS. Porto Alegre, ; Jansch- Pôrto, I.; Weber, R. Fundamentos de tolerância a falhas. Vitória: SBC/UFES, (apostila preparada para o IX JAI Jornada de Atualização em Informática, no X Congresso da Sociedade Brasileira de Computação). [11] Bosilca, George et al. MPICH- V Toward a Scalable Fault Tolerant MPI for Volatile Nodes, IEEE, Junho de [12] Pacheco, Peter. Parallel Program ming with MPI. 1 ed. Morgan Kaufmann Publishers, 1996.