info.info-pf info.info-db info.info-dc info
Rhauani Weber 
  
Aita Fazul 
email: rwfazul@inf.ufsm.br
  
Paulo Vinicius Cardoso 
email: pcardoso@inf.ufsm.br
  
Patricia Pitthan Barcelos 
  
Patricia Pitthan 
email: pitthan@inf.ufsm.br
  
Paulo Vinicius Cardoso 
  
Patrícia Pitthan Barcelos 
  
  
da Replicação de Dados Implementada pelo Apache Hadoop no Balanceamento de Carga

Keywords: 

à 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.

Introduc ¸ão

O conceito de Big Data refere-se a uma enorme quantidade de dados produzidos em uma velocidade extremamente alta, o que faz com que técnicas tradicionais não sejam suficientes para sua manipulac ¸ão efetiva. Os cenários de Big Data, de modo geral, estão relacionados a altas demandas de escalabilidade, distribuic ¸ão de dados, paralelismo de processamento e armazenamento de estruturas heterogêneas.

Ferramentas convencionais, mesmo com constantes melhorias e aprimoramentos, nem sempre são eficientes ao lidar com esse volume de dados massivo. Fortemente consolidado, o Apache Hadoop 1 é uma das principais tecnologias neste meio. Sendo um framework open source baseado em Java, o Hadoop permite o processamento de grandes volumes de dados através de modelos de programac ¸ão simples. Um componente fundamental do Hadoop é o seu sistema de arquivos distribuído (HDFS), um mecanismo confiável para o armazenamento de arquivos em clusters altamente escaláveis.

Um dos requisitos fundamentais para promover alta disponibilidade é a tolerância a falhas. Para tal, o HDFS implementa diversos mecanismos que buscam assegurar a confiabilidade e a disponibilidade do sistema. A replicac ¸ão pode ser considerada um dos principais mecanismos nesse sentido, fazendo com que o HDFS distribua as réplicas dos dados em diversos nós do cluster. Por sua vez, não há garantias de que esta distribuic ¸ão ocorra de forma equilibrada, sendo que alguns fatores, como a adic ¸ão de um novo nó ao cluster ou a ocorrência de falhas, podem tornar o desbalanceamento acentuado.

Este trabalho propõe uma análise experimental da replicac ¸ão de dados adotada pelo Apache Hadoop. Os testes foram efetuados de modo a examinar o comportamento do HDFS envolvendo o balanceamento na distribuic ¸ão de blocos no cluster. Além disso, comparac ¸ões de desempenho foram realizadas em cenários com e sem balanceamento de carga, de modo a evidenciar benefícios de uma distribuic ¸ão de dados equilibrada.

O artigo está organizado em cinco sec ¸ões. O framework Apache Hadoop e seus principais mecanismos de tolerância a falhas, concentrando-se na replicac ¸ão de dados realizada pelo HDFS, são apresentados na Sec ¸ão 2. A Sec ¸ão 3 descreve a metodologia adotada nos experimentos. A Sec ¸ão 4 exibe e discute os resultados obtidos. Por fim, a Sec ¸ão 5 apresenta as considerac ¸ões finais e direciona os trabalhos futuros.

Apache Hadoop

Surgido como uma plataforma voltada ao armazenamento e ao processamento de dados em larga escala, o framework Apache Hadoop é uma tecnologia amplamente difundida e consolidada, tanto em termos comerciais quanto no ambiente acadêmico. A simplicidade de configurac ¸ão e de uso da ferramenta, aliada a uma estrutura de desenvolvimento opensource, oferecem às organizac ¸ões alta flexibilidade na manipulac ¸ão de Big Data.

Conectando equipamentos de baixo custo para operar em paralelo, o Hadoop provê alta escalabidade em sistemas distribuídos. Seu modelo de programac ¸ão MapReduce foi projetado para processar grandes volumes de dados, dividindo o trabalho em tarefas independentes, que podem ser executadas paralelamente em diferentes nós do cluster.

Entre os principais componentes do Hadoop, compondo a camada de gerenciamento de dados da ferramenta, estão o Another Resource Negotiator (YARN) e o Hadoop Distributed File System (HDFS) [START_REF] White | Hadoop: The Definitive Guide[END_REF]]. O YARN foi introduzido a partir da versão 2 do Hadoop como uma plataforma de processamento de dados de uso geral, responsável por atribuir recursos computacionais para a execuc ¸ão de aplicac ¸ões dentro do framework.

Outro componente chave do Apache Hadoop é o seu sistema de arquivos distribuído. O HDFS é um mecanismo confiável e tolerante a falhas para o armazenamento de arquivos em clusters altamente escaláveis, que permite que inúmeras aplicac ¸ões -coordenadas pelo YARN -manipulem dados simultaneamente de forma segura e confiável. O HDFS emprega uma arquitetura mestre-escravo baseada em dois tipos de nós: N ameN ode (NN) e DataN ode (DN). O N ameN ode é o servidor mestre que gerencia o namespace (metadados) do sistema e controla o acesso e a distribuic ¸ão dos arquivos. Enquanto isso, os DataN odes realizam efetivamente o armazenamento dos dados no HDFS. Múltiplas instâncias de DataN odes possibilitam que a distribuic ¸ão de dados ocorra em diferentes máquinas do cluster, conectadas por rede.

A alta escabilidade do Hadoop torna possível que os clusters possuam milhares de nós trabalhando em conjunto, responsáveis tanto por computac ¸ão quanto por armazenamento de dados. Mesmo que alguns componentes de hardware falhem, é importante que o sistema mantenha sua consistência. O ecossistema do Hadoop possui diversos mecanismos voltados para a detecc ¸ão e recuperac ¸ão de falhas. Este artigo é focado nos mecanismos de tolerância a falhas implementados pelo HDFS.

Tolerância a Falhas no HDFS

Sendo voltado a cenários de Big Data, o HDFS oferece suporte ao armazenamento de dados na escala de petabytes. Para lidar com a quantidade massiva de dados, definiu-se um processo padrão para o uso do sistema de arquivos do Hadoop, ilustrado na Figura 1.

Ao armazenar algum arquivo no HDFS, ele é automaticamente dividido em arquivos menores (blocos). Todos os blocos (exceto o último) possuem o mesmo tamanho, o que possibilita calcular o número exato de blocos que podem ser armazenados em cada nó do sistema. A partir da versão 2 adotou-se 128MB como tamanho de bloco padrão. Conforme exibe a Figura 1, os blocos são armazenados em um conjunto de nós escravos (DNs) determinado pelo NN. Se possível, cada parte do arquivo será armazenada em um DN diferente, o que permite um maior paralelismo na escrita e na leitura dos dados. Mesmo com a distribuic ¸ão dos blocos, cabe ao HDFS assegurar confiabilidade e disponibilidade, de modo que nenhum dado seja perdido ou comprometido.

Os mecanismos de tolerância a falhas mais expressivos (i.e. estratégias que possibilitam recuperac ¸ão automática) no HDFS são o envio de mensagens Heartbeat, o estabelecimento de checkpoints e a replicac ¸ão de blocos [START_REF] White | Hadoop: The Definitive Guide[END_REF]].

Durante o funcionamento normal do HDFS, os DNs enviam mensagens periódicas ao NN, indicando que estão ativos. Estas mensagens, denominadas Heartbeats, possibilitam a comunicac ¸ão entre os dois nodos, além de permitirem a detecc ¸ão de falhas no HDFS. Se o NN não receber nenhuma mensagem de um determinado DN dentro de um limite de tempo previamente estipulado, o nó em questão será dado como inativo. Um DN inativo não recebe mais instruc ¸ões de leitura ou escrita de dados.

Vale ressaltar que as mensagens Heartbeat também carregam informac ¸ões sobre a capacidade e a utilizac ¸ão de disco dos DNs. Conjuntamente, é enviada a quantidade de transferências de dados ativas que estão sendo executadas pelo nodo em questão no momento do envio da mensagem. Estes dados são utilizados pelo NN para decisões envolvendo gerência de espac ¸o e balanceamento de carga nos DNs que compõem o cluster.

Além das mensagens Heartbeat, o HDFS implementa um mecanismo de checkpoint and recovery. Este mecanismo salva o contexto do sistema em intervalos de tempo predefinidos, criando um checkpoint. Em caso de falha, utiliza-se o último checkpoint salvo como base para o roolback, i.e. recuperac ¸ão do sistema para o último estado seguro.

Atuando como um importante mecanismo de tolerância a falhas e como uma estratégia para suprir altas demandas de disponibilidade, a replicac ¸ão de dados também está presente no HDFS. Sendo esta soluc ¸ão o foco do presente trabalho, a Sec ¸ão 2.1.1 detalha como o processo de replicac ¸ão de blocos ocorre no HDFS.

Replicac ¸ão de Blocos

A replicac ¸ão de blocos é um mecanismo crucial para o funcionamento do HDFS. A ideia baseia-se na criac ¸ão de cópias dos blocos de dados presentes no sistema (réplicas), de modo a aumentar a confiabilidade e a disponibilidade de dados com base em redundância.

A criac ¸ão de uma réplica pode ocorrer em diferentes momentos no ciclo de vida de um arquivo, sendo o NN o responsável pelas decisões que dizem respeito à replicac ¸ão. Como abordado anteriormente, os arquivos inseridos no HDFS são divididos em blocos de tamanho fixo e, posteriormente, armazenados em diferentes DNs. Caso uma falha ocorra, deve-se preservar a integridade e a consistência dos dados, de forma que, caso necessário, seja possível acessar o bloco a partir de outros nós.

Ao ser armazenado no HDFS, um bloco é replicado com base em um fator de replicac ¸ão previamente definido (por padrão utiliza-se 3 réplicas por bloco). O fator pode ser especificado no momento da criac ¸ão de cada arquivo, sendo possível alterá-lo posteriormente. A Figura 2 ilustra o processo de replicac ¸ão de blocos considerando o armazenamento de um arquivo, dividido em 5 blocos e com um fator de replicac ¸ão fixado em 3, em um cluster com 2 racks contendo 3 DNs cada. A política de posicionamento de réplicas atual do HDFS (Apache Hadoop versão 2), baseada em um fator de replicac ¸ão de 3, é armazenar a primeira réplica no mesmo nó onde a aplicac ¸ão do cliente está executando (considerando que o cliente esteja dentro de um DN, caso contrário um DN é escolhido aleatoriamente). Como a chance de falha de um rack é menor que a chance de falha de um nodo, a segunda e a terceira réplicas são armazenadas em um mesmo rack remoto (diferente do local da primeira réplica), porém em dois DNs distintos. Essa distribuic ¸ão pode ser observada na Figura 2.

Embora a replicac ¸ão resulte em maior gasto no armazenamento, o HDFS tira proveito da redundância espacial dos dados para suprir altas demandas de acesso. Se um cluster HDFS estiver disposto em múltiplos data centers, as requisic ¸ões de leitura serão atendidas a partir do data center mais próximo da origem da solicitac ¸ão. De todo modo, as políticas de posicionamento de réplicas ainda estão sendo aprimoradas e a estratégia atual ainda é vista como um trabalho em desenvolvimento [START_REF] Foundation | Replica Placement: The First Baby Steps[END_REF]].

Em relac ¸ão à sobrecarga no processo de armazenamento das réplicas, o HDFS usa uma técnica de pipeline na escrita das cópias. A partir do momento que o NN definir a lista dos três DNs que irão receber a cópia de um determinado bloco e o primeiro DN receber seu bloco de dados, este irá armazená-lo em seu disco local e transferi-lo para o segundo nó da lista, que irá transferi-lo para o terceiro DN e assim sucessivamente, conforme exemplificado no bloco b5 da Figura 2. Dessa forma, um DN pode, simultaneamente, receber e encaminhar dados para os demais nós que compõem o pipeline.

Mesmo com estes aprimoramentos, a replicac ¸ão inicial dos blocos no momento da escrita de um arquivo não é suficiente para garantir alta confiabilidade e alta disponibilidade. Em um sistema como o HDFS, que foi projetado para ser executado em hardware comum (i.e. não confiável), falhas de dados e de nodos são frequentes. Para realizar a replicac ¸ão, pelo menos uma cópia do bloco deve existir. Logo, o NN precisa monitorar e controlar ativamente o número de réplicas de cada bloco presente no HDFS, de forma a proteger e manter a integridade do sistema em cenários onde ocorram falhas consecutivas em um curto intervalo de tempo.

O HDFS também usa o conceito de re-replicac ¸ão, que pode ser motivada pelos seguintes fatores: o aumento do fator de replicac ¸ão de um arquivo, a corrupc ¸ão de uma réplica já existente, a ocorrência de uma falha de disco em um DN ou a indisponibilidade total de um nó [START_REF] Foundation | Replica Placement: The First Baby Steps[END_REF]]. Em todos os casos, o NN deve agir e reiniciar o processo de replicac ¸ão em outros DNs para manter a conformidade com o fator mínimo de replicac ¸ão definido. A estratégia desse processo é simples: para cada bloco que necessite de mais réplicas, o NN irá selecionar um DN que contenha uma das cópias originais do bloco e, em seguida, arbitrariamente definir um DN como destino do bloco re-replicado. Ambos os processos de replicac ¸ão e de re-replicac ¸ão são realizados de forma transparente pelo HDFS. É natural que alguns DNs possuam mais blocos de dados em comparac ¸ão com o restante dos nós do cluster, tendo em vista que não há nenhuma garantia de que a distribuic ¸ão dos dados pelo NN seja uniforme. Ainda assim, falhas que resultem na re-replicac ¸ão de blocos podem agravar a sobrecarga em DNs específicos e, com o passar do tempo, esse desbalanceamento pode se tornar ainda mais acentuado.

Metodologia

Com o objetivo de analisar o balanceamento na distribuic ¸ão de dados dentro do HDFS, foram coletadas informac ¸ões e estatísticas de uso do sistema de arquivos a partir da execuc ¸ão de um benchmark. Os experimentos foram realizados considerando a configurac ¸ão do Hadoop em dois modos: pseudo-distribuído e totalmente distribuído.

No modo pseudo-distribuído (único nó), a interac ¸ão entre os nodos é executada sobre a Máquina Virtual Java (JVM), onde cada daemon do Hadoop roda em uma instância distinta da JVM, simulando um cluster em pequena escala. Já em um modo totalmente distribuído, a execuc ¸ão é realizada em um cluster real, com múltiplos nós interconectados.

O contexto do ambiente deu-se por uma configurac ¸ão do Hadoop (versão 2.9.1) com 1 NN e 10 DNs. Em ambos os modos, tomaram-se como base cenários com e sem a ocorrência de falhas de DataN ode. As falhas de DN -representando nós com defeito no cluster -foram induzidas através do comando kill do Linux aos processos responsáveis pela gerência dos DNs selecionados em cada teste. A descoberta das falhas de DN é feita a partir de um dos mecanismos apresentados na Sec ¸ão 2.1, as mensagens Heartbeat.

O NN considera inativos os DNs que não se comunicam dentro de um determinado intervalo. Um nó inativo acarreta na diminuic ¸ão do fator de replicac ¸ão dos blocos nele armazenados. Para prevenir a perda de dados, o NN responde as mensagens Heartbeat de algum DN que possua cópias destes blocos, enviando instruc ¸ões para realizar uma nova replicac ¸ão em outros nós, restaurando assim o fator de replicac ¸ão e retornando o sistema para um estado seguro. Nos testes realizados, definiu-se que os DNs fossem marcados como inativos após aproximadamente 20 segundos sem o envio de mensagens Heartbeat.

Para analisar o balanceamento de carga no HDFS foram realizados testes de estresse por meio de um benchmark presente na distribuic ¸ão do Hadoop. A aplicac ¸ão usada foi o TestDFSIO [START_REF] White | Hadoop: The Definitive Guide[END_REF]], que permite medir o desempenho do sistema a partir de operac ¸ões de entrada e saída (i.e. escrita e leitura de dados). O benchmark foi usado para escrita de 15 arquivos. Os parâmetros de configurac ¸ão referentes ao tamanho dos blocos de cada arquivo e do fator de replicac ¸ão mínimo foram 128MB e 3, respectivamente.

Ao executar o Hadoop em um único nó, limita-se o paralelismo na execuc ¸ão das aplicac ¸ões. Em contrapartida, no modo distribuído, com múltiplos nós trabalhando em conjunto, é possível manipular maiores quantidades de dados. Desta forma, por questões de limitac ¸ões de hardware, o tamanho dos arquivos escritos durante os testes no modo pseudo-distribuído e totalmente distribuído foram distintos. Como o objetivo dos experimentos é avaliar a proporcionalidade na distribuic ¸ão de dados nos DNs (independente de carga), os resultados não são afetados por essa disparidade.

Para ambos os modos de execuc ¸ão do Hadoop, foram realizados seis Casos de Teste (C.T.). Em cada teste, o número de falhas de DN induzidas durante a execuc ¸ão do benchmark TestDFSIO foi incrementada. A Tabela 1 demonstra a quantidade de falhas induzidas em cada C.T., onde o primeiro C.T. (cenário A) representa uma execuc ¸ão sem falhas de DN e o último (cenário F) uma execuc ¸ão com ocorrência de 50% de falhas, ou seja, execuc ¸ão com falhas em 5 dos 10 DNs inicialmente configurados. Além disso, para cada cenário, foi definido o valor ideal de ocupac ¸ão de cada DN. Sendo DN t o número total de DataN odes configurados e DN o o número de DataN odes inativos, a fórmula para calcular os valores ideias (média para o balanceamento) é definida como: Ideal(%) = 100/(DN t -DN o ). O valor obtido representa a porcentagem de dados a serem salvos em cada DN em relac ¸ão ao volume total armazenado no sistema de arquivos, de modo que a distribuic ¸ão de dados possa ser considerada homogênea.

Experimentac ¸ão

Esta Sec ¸ão apresenta os experimentos realizados nos dois modos de execuc ¸ão do Apache Hadoop, conforme a metodologia descrita na Sec ¸ão 3. Para aumentar a confiabilidade dos valores, em cada C.T. foi calculada a porcentagem de ocupac ¸ão de disco de cada DN considerando a média aritmética de 10 execuc ¸ões distintas. Por fim, na Sec ¸ão 4.3 são apresentados os resultados alcanc ¸ados após o balanceamento do cluster.

Modo pseudo-distribuído

No modo de operac ¸ão pseudo-distribuído do Apache Hadoop, utilizou-se uma máquina com a seguinte configurac ¸ão: processador Intel Core 2 Quad com frequência de 2.33GHz, 4GB de memória RAM e 750GB de disco rígido, executando um sistema operacional Ubuntu 16.04.1 com Kernel GNU/Linux 4.13.0-45-generic.

A execuc ¸ão do benchmark TestDFSIO deu-se pela escrita de 15 arquivos de 350MB cada. Sendo o fator de replicac ¸ão definido como 3, 124 blocos de dados ((15×350×3)÷128) foram escritos no HDFS em cada teste no modo pseudo-distribuído. A Tabela 2 apresenta os resultados referentes às porcentagens de ocupac ¸ão de cada DN (em relac ¸ão ao total armazenado no sistema de arquivos) após a execuc ¸ão do benchmark. De modo a evidenciar os valores discrepantes em relac ¸ão a baseline estabelecida (valores ideais apresentados na Tabela 1), os valores mínimos e máximos de ocupac ¸ão dos DNs durante cada Caso de Teste foram destacados em negrito. Como pode ser observado, há uma variac ¸ão significativa na quantidade de dados armazenada em cada DN. Dessa forma, a política de posicionamento de réplicas empregada pelo HDFS fez com que, em cada teste, as operac ¸ões de escrita de blocos realizadas ocorressem com uma frequência diferente em certos DNs, ocasionando em um desbalanceamento de carga.

Modo totalmente distribuído

Para a execuc ¸ão do Apache Hadoop no modo totalmente distribuído, foram configurados 10 nós na plataforma Grid'5000 2 , cada um com dois processadores Intel Xeon E5520 (quatro cores por CPU) com frequência de 2.27GHz, 32GB de memória RAM e 557GB de disco rígido, com uma distribuic ¸ão Debian 9.5 com Kernel 4.9.0-8-amd64. Neste modo de execuc ¸ão, cada um dos 10 nós foi responsável pela execuc ¸ão de um DN, já o NN foi configurado para executar no mesmo nó que o primeiro DN.

A execuc ¸ão do benchmark TestDFSIO consistiu na escrita de 15 arquivos de 10GB cada. Considerando o fator de replicac ¸ão definido como 3, foram escritos 3.600 blocos de dados ((15 × 10240 × 3) ÷ 128) no HDFS em cada C.T.. A Tabela 3 exibe os resultados relacionados às porcentagens de ocupac ¸ão de cada DN após a experimentac ¸ão. Os valores em negrito destacam os valores extremos (mínimos e máximos) obtidos em cada cenário. Percebe-se que, assim como no modo pseudo-distribuído, há um desequilíbrio considerável no que diz respeito à distribuic ¸ão de dados entre os DNs. Logo, para se aproximar dos valores ideais para uma distribuic ¸ão homogênea (vide Tabela 1), surge a necessidade do balanceamento do cluster.

Modo totalmente distribuído com balanceamento de carga

Conforme já citado (e atestado pelos resultados apresentados anteriormente), não há garantias de que uma distribuic ¸ão de dados homogênea entre os DNs seja realizada de forma automática pelo HDFS. De todo modo, o balanceamento do cluster é um aspecto importante a ser considerado. A medida que o desbalanceamento fica acentuado, DNs com mais dados podem ficar sobrecarregados devido a um maior número de operac ¸ões de E/S sendo realizadas em seus nodos e, consequentemente, DNs com menos dados podem ficar subutilizados. Sendo assim, espera-se que uma distribuic ¸ão uniforme dos blocos de arquivos pelo cluster otimize o uso do HDFS [START_REF] White | Hadoop: The Definitive Guide[END_REF]]. Um cluster é dado como balanceado quando o uso interno de seus DNs estiver dentro do limite (threshold) estipulado no início da execuc ¸ão do balanceador. Esse limite define a diferenc ¸a máxima que a carga dos DNs (espac ¸o utilizado no nodo em relac ¸ão a sua capacidade total de armazenamento) e a carga total do cluster (espac ¸o utilizado no cluster em relac ¸ão a sua capacidade total) pode assumir para que o cluster possa ser classificado como equilibrado. Isto proporciona certa flexibilidade no balanceamento de dados dentro do HDFS, permitindo que os DNs armazenem quantidades similares de dados, mas que ainda podem diferir moderadamente entre si.

O algoritmo do balanceador utiliza uma série de técnicas durante o deslocamento de dados entre DNs. Seu detalhamento pode ser encontrado em [Hortonworks 2018]. Para os fins deste trabalho, basta notar que a distribuic ¸ão de blocos gerada a partir do balanceador adere à política de posicionamento de réplicas do HDFS apresentada na Sec ¸ão 2.1.1.

Com o objetivo de medir o desempenho proporcionado pelo balanceamento do HDFS, realizou-se a execuc ¸ão do benchmark TestDFSIO em modo leitura antes e após o uso do balanceador. Tendo em vista que os possíveis benefícios de desempenho de um cluster balanceado originam-se ao explorar o paralelismo de operac ¸ões em múltiplos nodos computacionais (otimizando a utilizac ¸ão dos recursos), os experimentos foram executados exclusivamente no Hadoop em modo de execuc ¸ão totalmente distribuído. Para ilustrar os resultados obtidos, foram escolhidos dois dos C.T. apresentados anteriormente.

A Figura 3a apresenta a porcentagem de uso de cada DN, antes e após a execuc ¸ão do balanceador e com um threshold definido em 3, em um cenário sem falhas (C.T. A). Observa-se que a disparidade de carga entre os DNs foi reduzida, com a ocupac ¸ão aproximando-se do valor considerado ideal para cada DN (10% para este Caso de Teste). Baseando-se neste cenário, foram medidos os tempos para a conclusão do benchmark em 20 operac ¸ões de leitura distintas. Os resultados alcanc ¸ados podem ser observados na Figura 3b. A média aritmética dos tempos com o cluster em seu estado padrão (sem balanceamento) foi de 501,15 segundos. Após o balanceamento, o valor médio foi reduzido para 411,6 segundos. Isto representa um ganho de aproximadamente 18% no desempenho durante a leitura dos dados armazenados.

Para ilustrar um cenário com falhas, a Figura 4a apresenta a porcentagem de uso de cada DN antes e após o balanceamento, considerando um cenário com duas falhas (C.T. C). Com a execuc ¸ão do balanceador, o cluster é equilibrado com um valor que aproxima-se do ideal para cada DN (12.5% para este Caso de Teste).

A Figura 4b exibe os valores obtidos neste teste. Com o balanceador, o tempo médio de execuc ¸ão diminuiu de 445,4 para 394,25 segundos, proporcionando um ganho de desempenho de aproximadamente 11% durante a leitura dos dados armazenados. 

Considerac ¸ões Finais

Este trabalho analisou o comportamento do HDFS durante a distribuic ¸ão de blocos replicados entre DNs. Os experimentos atestaram que o desbalanceamento de carga é uma realidade presente no sistema de arquivos. Para resolver este problema, utilizou-se uma ferramenta disponibilizada pelo Hadoop, o HDFS Balancer, que oferece uma soluc ¸ão reativa ao desbalanceamento. Com o uso do balanceador, demonstrou-se que melhorias significativas de desempenho podem ser alcanc ¸adas mediante o equilíbrio de carga.

Trabalhos futuros envolvem a explorac ¸ão de abordagens alternativas que eliminem a necessidade de execuc ¸ão de ferramentas remediadoras como o balanceador. Exemplos conhecidos, como [START_REF] Shwe | A data re-replication scheme and its improvement toward proactive approach[END_REF]Aritsugi 2018, Dai et al. 2016], partem da criac ¸ão de uma nova política de posicionamento de réplicas para o HDFS, focada em otimizar a distribuic ¸ão dos blocos replicados com métricas de uso do cluster. Já [START_REF] Lin | A load-balancing algorithm for hadoop distributed file system[END_REF] criam o papel de um novo nodo no sistema, dedicado exclusivamente ao balanceamento. Estudos adicionais, compreendendo a execuc ¸ão de novos benchmarks e a análise do comportamento do HDFS mediante o aumento de carga (stress testing), serão conduzidos.

Figura 1 .

 1 Figura 1. Processo de armazenamento de arquivos no HDFS.

Figura 2 .

 2 Figura 2. Mecanismo de Replicac ¸ão de Dados ao armazenar um arquivo no HDFS.

  Em geral, o sistema de arquivos do Hadoop precisa lidar com um alto fluxo de dados constantemente, o que faz do balanceamento uma tarefa complexa. Para auxiliar neste processo, o Hadoop disponibiliza uma ferramenta que realiza o balanceamento do cluster, o HDFS Balancer [Hortonworks 2018]. Este balanceador analisa como os blocos estão posicionados entre os DNs e, até que o cluster possa ser considerado balanceado, move os dados dos DNs superutilizados para os DNs subutilizados.

Figura 3 .

 3 Figura 3. Uso do balanceador em um cen ário sem falhas.

( a )

 a Balanceamento de carga.

Figura 4 .

 4 Figura 4. Uso do balanceador em um cen ário com falhas.

Tabela 1. Casos de Teste adotados nos experimentos.

  

	C.T.	Falhas	Ideal (%)
	A B C D E F	0 1 2 3 4 5	10 11.11 12.5 14.28 16.67 20

Tabela 2. Porcentagem de ocupac ¸ão dos DNs no modo pseudo-distribuído.

  

	DN	A	B	C	C.T.	D	E	F
	1 2 3 4 5 6 7 8 9 10 Total	9.55 4.88 5.63 9.89 11.56 10.77 8.58 12.94 15.77 10.43	X 12.85 12.13 10.47 8.48 11.79 4.26 13.52 11.85 14.65	X X 9.99 9.12 7.24 10.39 15.06 9.74 19.71 18.75	100	X X X 16.65 12.93 18.27 9.47 14.8 15.46 12.42	X X X X 14.63 18.78 19.5 17.51 16.02 13.56	X X X X X 16.18 20.65 19.64 19.74 23.79

Tabela 3. Porcentagem de ocupac ¸ão dos DNs no modo totalmente distribuído.

  

	DN	A	B	C	C.T.	D	E	F
	1 2 3 4 5 6 7 8 9 10 Total	17.38 16.17 14.76 7.46 7.58 7.37 6.92 7.4 7.35 7.61	X 8.71 10.27 9.3 11.88 14.6 14.85 9.02 13.71 7.66	X X 10.08 14 17.49 9.1 13.25 12.62 10.55 12.91	100	X X X 10.95 18.58 15.24 13.91 10.76 11.36 19.2	X X X X 15.4 21.25 15.82 15.45 17.92 14.16	X X X X X 25.35 21.16 18.7 16.87 17.92

https://hadoop.apache.org/

Grid'5000 é uma plataforma para experimentos apoiada por um grupo de interesses científicos hospedado por Inria e incluindo CNRS, RENATER e diversas Universidades, bem como outras organizac ¸ões (mais detalhes em https://www.grid5000.fr).