info.info-pf info.info-db info.info-dc info
Paulo Vinicius Cardoso 
  
Rhauani Weber 
  
Aita Fazul 
  
Patricia Pitthan Barcelos 
  
Patricia Pitthan 
  
Arquitetura para Elaboração de um Histórico de Atributos Relacionados à Técnica de Checkpoint and Recovery

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Arquitetura para Elaborac ¸a ˜o de um Histo ´rico de Atributos

Relacionados a ` Te ´cnica de Checkpoint and Recovery Paulo V. M. Cardoso 1 , Rhauani Weber Aita Fazul 2 , Patr´ıcia Pitthan Barcelos 1

1 Po ´s-Graduac ¸a ˜o em Cie ˆncia da Computac ¸a ˜o (PGCC) 2 Laborato ´rio de Sistema de Computac ¸a ˜o (LSC) Universidade Federal de Santa Maria (UFSM) Santa Maria -RS -Brasil pcardoso@inf.ufsm.br, rwfazul@inf.ufsm.br, pitthan@inf.ufsm.br

Abstract. Optimal attributes for checkpoint and recovery technique are hard to find due to system distinct behaviours over the time. This work proposes an architecture to store system elements usage on a historical record structure. The goal of historic is to provide statistical informations about system usage, in order to help on checkpoint period taking decisions. In this way, the architecture already proposed for dynamic checkpoint configuration will be able to use approximations for setting proper checkpoint attributes.

Introduc ¸a ˜o

A te ´cnica de Checkpoint and Recovery (CR) e ´ amplamente usada como uma soluc ¸a ˜o tolerante a falhas, devido a sua eficie ˆncia em recuperac ¸o ˜es de falhas em sistemas computacionais [START_REF] Egwutuoha | A survey of fault tolerance mechanisms and checkpoint/restart implementations for high performance computing systems[END_REF]. Seu funcionamento consiste em duas fases: o estabelecimento de checkpoints e a recuperac ¸a ˜o, que acontece apo ´s uma falha e consiste em recuperar o andamento normal do sistema a partir do seu estado esta ´vel mais recente.

Pore ´m, a configurac ¸a ˜o de atributos relacionados ao checkpoint pode ser um grande desafio. Ferramentas de processamento distribu´ıdo, como o Apache Hadoop e o Apache Spark, foram criadas para suportar aplicac ¸o ˜es com grandes quantidades de dados. Os dois frameworks possuem suas variac ¸o ˜es da te ´cnica de checkpoint implementadas para garantir confiabilidade de execuc ¸a ˜o. Pore ´m, a eficie ˆncia dessas implementac ¸o ˜es depende de estabelecimentos eficientes de checkpoints, para que a confiabilidade na ˜o prejudique o desempenho do sistema e das aplicac ¸o ˜es.

Nas verso ˜es padra ˜o do Hadoop, a determinac ¸a ˜o do período entre checkpoints e ´ essencial para o desempenho e para a confiabilidade do sistema. O estabelecimento frequente de checkpoints acelera o procedimento de recuperac ¸a ˜o po ´s-falha, mas adiciona intrusividade pela grande quantidade de operac ¸o ˜es de I/O envolvida. Enquanto isso, períodos mais longos entre checkpoints tornam a recuperac ¸a ˜o mais lenta ao mesmo tempo em que diminuem a intrusividade.

Ja ´ no Spark, as políticas de selec ¸a ˜o de datasets para checkpoint tambe ´m interferem no comportamento da ferramenta. Neste caso, um checkpoint elimina a linha do tempo de um dataset e o salva em um reposito ´rio seguro. Em caso de falha, a recuperac ¸a ˜o inicia a partir do dataset salvo em checkpoint, tornando sua reconstruc ¸a ˜o mais ra ´pida. Pore ´m, o estabelecimento ineficiente de checkpoints tambe ´m adiciona intrusividade ao sistema. Como a política de selec ¸a ˜o depende do desenvolvedor, escolhas inapropriadas tendem a prejudicar o desempenho do sistema e o uso de checkpoints perde seu propo ´sito.

Em ambos os sistemas, alterac ¸o ˜es nos atributos da te ´cnica de CR em tempo real sa ˜o invia ´veis. Isto e ´, deve-se interromper todos os servic ¸os ativos para que uma modificac ¸a ˜o de atributo (ou de política) tenha efeito. Uma soluc ¸a ˜o para este problema e ´ o uso de um mecanismo de configurac ¸a ˜o dina ˆmica para atributos de checkpoint baseado em me ´tricas de monitoramento, atrave ´s das variac ¸o ˜es do Hadoop e do Spark propostas em [START_REF] Cardoso | Dynamic checkpoint architecture for reliability improvement on distributed frameworks[END_REF].

A arquitetura para configurac ¸a ˜o dina ˆmica dos atributos de checkpoint possui dois elementos principais: o supervisor, capaz de identificar o comportamento dos nodos e de fatores do sistema em tempo real, e o coordenador que fornece uma interface entre os frameworks e o supervisor. Pore ´m, a definic ¸a ˜o das me ´tricas de monitoramento pode se tornar uma tarefa complexa a ` medida que informac ¸o ˜es sobre o ambiente computacional sa ˜o desconhecidas. Aproximac ¸o ˜es para períodos ideais requerem um conhecimento apriori de fatores do sistema que geralmente sa ˜o desconhecidos do desenvolvedor.

Soluc ¸a ˜o Proposta

Para auxiliar na definic ¸a ˜o das me ´tricas de monitoramento, este trabalho propo ˜e e define uma arquitetura para o armazenamento do histo ´rico de utilizac ¸a ˜o de elementos do ambiente computacional. O histo ´rico e ´ criado em uma estrutura de a ´rvore, onde seus nodos representam os elementos a serem monitorados. Assim, tem-se uma visa ˜o do comportamento do sistema no decorrer do tempo, a partir de fatores relacionados a falhas como o tempo me ´dio entre falhas (Mean Time Between Failures, ou MTBF) [START_REF] Egwutuoha | A survey of fault tolerance mechanisms and checkpoint/restart implementations for high performance computing systems[END_REF]]. Tambe ´m pode-se observar os custos do procedimento de checkpoint, ale ´m do uso de elementos de hardware, como CPU, disco e memo ´ria RAM.

O objetivo da manutenc ¸a ˜o de um histo ´rico de atributos e ´ possibilitar uma ana ´lise de características do sistema que seriam invia ´veis em uma abordagem a-priori. Desta forma, a aplicac ¸a ˜o de aproximac ¸o ˜es para a definic ¸a ˜o de atributos ideais de checkpoint e ´ facilitada e pode ser anexada a ` arquitetura de configurac ¸a ˜o dina ˆmica. Com informac ¸o ˜es atualizadas sobre o comportamento do sistema, a aplicac ¸a ˜o dessas soluc ¸o ˜es pode auxiliar na tomada de deciso ˜es sobre modificac ¸o ˜es em tempo real dos atributos de checkpoints.

O histo ´rico foi desenvolvido com o auxílio da ferramenta Apache Zookeeper: um projeto open-source com funcionalidades para facilitar a coordenac ¸a ˜o de sistemas dis-tribu´ıdos [START_REF] Hunt | Zookeeper: Wait-free coordination for internet-scale systems[END_REF]. A arquitetura do Zookeeper e´ formada por servidores que realizam operac ¸o ˜es requisitadas por clientes em um namespace compartilhado, cuja estrutura e ´ composta por uma a ´rvore de nodos chamados zN odes.

Para cada elemento monitorado, um zN ode pode ser definido com um caminho específico na estrutura de a ´rvore do Zookeeper. Nessa estrutura, um elemento possui tre ˆs nodos descendentes: um para armazenar o u ´ltimo elemento adicionado (last), um nodo para armazenar os valores obtidos por observac ¸o ˜es (values) e outro para o armazenamento de ana ´lises estatísticas (analysis).

Para que se obtenha uma visa ˜o a respeito do comportamento de um elemento, e ´ necessa ´rio armazenar uma quantidade suficiente de informac ¸o ˜es. Por isso, o nodo values e ´ composto por um nu ´mero ma ´ximo de N descendentes, que corresponde a ` janela de observac ¸a ˜o. Logo, o histo ´rico armazena os u ´ltimos N valores observados. A atualizac ¸a ˜o e ´ baseada no conceito de Round Robin Database (RRD), de modo que os valores sa ˜o atualizados nos descendentes de value a partir de 1 ate ´ N e, apo ´s N , a partir de 1 novamente.

Uma importante func ¸a ˜o do Zookeeper e ´ o mecanismo de watcher, que permite o envio de alertas para qualquer sistema que observe um zN ode assim que este nodo e ´ modificado. Nesse caso, o nodo last e ´ usado para observac ¸a ˜o externa, de modo que qualquer ferramenta tenha a noc ¸a ˜o de quando um elemento tem seus dados atualizados. O elemento last e´ essencial para o controle de ordenamento da base de valores, de modo que este nodo armazena o ´ındice do zN ode com o atributo coletado mais recentemente.

Assim, tem-se uma noc ¸a ˜o de onde inicia e termina a ordem temporal dos valores armazenados. Essa característica e ´ importante para ana ´lises sobre o histo ´rico quando informac ¸o ˜es mais recentes devem apresentar uma influe ˆncia diferente das mais antigas. Ale ´m disso, o nodo last serve como suporte para sua observac ¸a ˜o via watchers, ja ´ que cada mudanc ¸a no histo ´rico reflete na mudanc ¸a do índice atual.

A ana ´lise dos dados coletados no histo ´rico pode ser armazenada em descendentes do nodo analysis, de modo a criar atalhos para informac ¸o ˜es ja ´ processadas. No contexto deste trabalho, a construc ¸a ˜o de ana ´lises sobre atributos e ´ feita no elemento supervisor do mecanismo de configurac ¸a ˜o dina ˆmica. A partir da modificac ¸a ˜o de um zN ode correspondente ao nodo last de um elemento, o supervisor recebe o alerta do Zookeeper indicando que uma nova ana ´lise pode ser realizada com os dados obtidos.

O supervisor estabelece me ´tricas de avaliac ¸a ˜o dos dados observados e coleta ana ´lises de custos. A me ´trica escolhida pode ser adaptada de acordo com a necessidade de monitoramento. Neste trabalho, tre ˆs abordagens foram definidas. A me ´dia aritme ´tica dos valores armazenados descreve uma abordagem simples. Ja ´ a me ´dia ponderada pode ser usada para valorizar observac ¸o ˜es mais recentes. Ana ´lises mais apuradas podem envolver uma soluc ¸a ˜o baseada em modelos auto-regressivos (autoregressive-moving-average).

Considerac ¸o ˜es Finais

Este trabalho apresentou uma abordagem para o armazenamento das estat´ısticas de uso de elementos em um sistema computacional, baseado em um histo ´rico de observac ¸o ˜es. Essa arquitetura pode ser u ´til para a definic ¸a ˜o de fatores de utilizac ¸a ˜o do sistema que seriam invia ´veis em observac ¸o ˜es a-priori. Nos pro ´ximos passos, o histo ´rico sera ´ validado junto ao mecanismo de configurac ¸a ˜o dina ˆmica de checkpoint, de modo a encontrar soluc ¸o ˜es ideais para a te ´cnica de acordo com a estatística de uso dos elementos observados.