Jornada de pesquisa do Hadoop, ao Bare Metal - Episódio 3

Anteriormente, em nosso segundo episódio da trilogia “ Jornada de pesquisa do Hadoop, ao Bare Metal - Episódio 2 ”, cobrimos o POC que tínhamos.

Neste episódio, focaremos na própria migração, criar um ambiente de POC é fácil e agradável; no entanto, migrar 2 PB (a parte bruta dos 6 PB que incluem a replicação) de dados se tornou um novo desafio. Mas antes de abordarmos questões técnicas, vamos começar com a metodologia.

A grande migração

 

Aprendemos com a nossa experiência passada que, para que um projeto desse tipo seja bem-sucedido, como em muitos outros casos, é tudo sobre as pessoas - você precisa se preocupar com os usuários e garantir a adesão deles.

Além disso, queríamos concluir a migração em quatro meses, pois renovávamos o espaço do nosso datacenter e queríamos obter ganhos com a redução de espaço como resultado da migração.

Tendo essas duas considerações em mente, decidimos que teríamos as mesmas tecnologias que são Hadoop e Hive no ambiente de nuvem, e somente após a migração, poderíamos aproveitar as novas tecnologias disponíveis no GCP.

Agora que a decisão foi tomada, começamos a planejar a migração do cluster de pesquisa para o GCP, analisando diferentes aspectos como:

  • Crie a topologia de rede (VPN, VPC etc.)
  • Copie os dados históricos
  • Crie o esquema de dados (Hive)
  • Ativar a entrega de dados de tempo de execução
  • Integrar nossos sistemas internos (monitoramento, alertas, provisão etc.)
  • Migrar os fluxos de trabalho
  • Colha o cluster bare metal (com todos os seus sistemas de suporte)

Tudo com o objetivo de produzir a solução e torná-la com qualidade de produção, com base em nossos padrões. Fizemos um esforço especial para alavancar as mesmas ferramentas de gerenciamento e controle de configuração que usamos em nossos datacenters internos (como Chef, Prometheus etc.) - para que tratássemos esse ambiente como apenas mais um datacenter.

Copiando os dados

Soa como uma atividade simples - você precisa copiar seus dados do local A para o local B.

Bem, acontece que quando você precisa copiar 2 PB de dados, enquanto o sistema ainda está ativo na produção, existem alguns desafios envolvidos.

A primeira restrição que tivemos foi que a cópia dos dados não afetará o uso do cluster - pois o trabalho de pesquisa ainda precisa ser realizado.

Segundo, depois que os dados são copiados, também precisamos ter validação de dados.

 

Começando com cópia de dados

  • Opção 1 - Copie os dados usando algum Transfer Appliance

Transfer Appliance pode enviar seu dispositivo de transferência (com base na localização do seu datacenter), que você anexaria ao Hadoop Cluster e seria usado para copiar os dados. Envie-o de volta ao server e faça o download dos dados do dispositivo para o GCS.

Infelizmente, da perspectiva da capacidade, precisaríamos ter várias iterações desse processo para copiar todos os dados e, além disso, a versão da comunidade Cloudera que estávamos usando era tão antiga - não era suportada.

  • Opção 2 - Copie os dados pela rede

Ao seguir esse caminho, a principal restrição é que a rede seja usada para o ambiente de produção (veiculação) e para a cópia, e não podemos permitir que a cópia crie congestionamento de rede nas linhas.

No entanto, se restringirmos o processo de cópia, o tempo que levará para copiar todos os dados será muito longo e não poderemos cumprir nossos cronogramas.

Configure a rede

Como parte de nossa infraestrutura de rede, por data center, temos 2 ISPs, cada um com 2 linhas de 10G para backup e redundância.

Decidimos aproveitar essas linhas de backup e criar um túnel nessas linhas, para ser dedicado apenas à cópia de dados do Hadoop. Isso nos permitiu copiar os dados em um tempo relativamente curto, por um lado, e garantir que eles não afetariam nosso tráfego de produção, pois estavam contidos em linhas específicas.

Quando a rede ficou pronta, começamos a copiar os dados para o GCS.

Como você deve se lembrar dos episódios anteriores, nosso cluster foi criado há mais de 6 anos e, como tal, adquiriu muitas dívidas de tecnologia em torno dele, também nos dados nele contidos. Decidimos tirar proveito da situação e alavancar a migração também para fazer alguns dados e limpeza da carga de trabalho.

Investimos tempo no mapeamento de quais dados precisamos e quais dados podem ser limpos, apesar de não reduzir significativamente o tamanho dos dados que conseguimos excluir 80% das tabelas, mas também conseguimos excluir 80% da carga de trabalho.

Data de validade

Ao migrarmos os dados, tivemos que ter validação de dados, certificando-nos de que não há corrupção / falta de dados.

Mais desafios nos aspectos de validação de dados a serem levados em consideração -

  • O cluster migrado é um cluster ativo - portanto, novos dados são adicionados a ele e dados antigos excluídos
  • Com o cluster interno do Hadoop, todas as tabelas são armazenadas como arquivos, enquanto no GCS são armazenadas como objetos.

Ficou claro que precisamos automatizar o processo de validação de dados e criar painéis para nos ajudar a monitorar nosso progresso.

Acabamos implementando um processo que cria dois catálogos, um para o cluster Hadoop interno bare metal e outro para o ambiente GCP, comparando esses catálogos e alertando-nos sobre quaisquer diferenças.

Paralelamente à migração de dados, trabalhamos na construção do ecossistema Hadoop no GCP, incluindo os esquemas de tabelas com suas partições no Hive, nossos sistemas de entrega de dados em tempo de execução adicionando novos dados ao ambiente GCP em paralelo ao cluster interno do Hadoop, nosso sistemas de monitoramento, sistemas de retenção de dados etc.

O novo ambiente no GCP estava finalmente pronto e estávamos prontos para migrar as cargas de trabalho. Inicialmente, duplicamos os trabalhos para execução paralela nos dois clusters, garantindo a conclusão da validação e não afetando o trabalho de produção.

Após um mês de validação, trabalho paralelo e ajustes necessários, fomos capazes de desativar o cluster de pesquisa interno.

O que conquistamos nessa jornada

  • Atualizou a tecnologia
  • Melhore a utilização e obtenha a elasticidade necessária que desejávamos
  • Redução do custo total
  • Introduziu novas ferramentas e tecnologias GCP

Epílogo

Essa incrível jornada durou quase 6 meses de trabalho focado. Conforme planejado, a primeira etapa foi usar as mesmas tecnologias que tínhamos no cluster bare metal, mas, assim que terminamos a migração para o GCP, agora podemos começar a planejar como aproveitar ainda mais as novas oportunidades que surgem ao aproveitar as tecnologias e ferramentas do GCP.

 

Máxima comunicação com proteção ao extremo? Avance Network: A verdadeira rede social junte-se a nós


Strong

5136 Blog Mesajları

Yorumlar