Migração de Elasticsearch para Opensearch na AWS

O que é o RFS

O RFS (Reindex from Snapshot) é um processo de migração de dados entre versões de Elasticsearch e Opensearch, ou até mesmo entre versões de Opensearch, que vem para facilitar o processo completo de migração, incluindo até mesmo um processo de proxy para migração in flight!

Iniciando o processo de migração

Para iniciar o processo de migração, é importante ter um setup preparado para evitar problemas durante a migração, para o começo é importante ter o cdk na conta configurado (o RFS utiliza bastante o cdk da AWS), e para isso segue o primeiro passo:

Para configurar o cdk, rodar no seu terminal local:

cdk bootstrap aws://id_da_conta/região_do_opensearch

Agora com o cdk configurado, é possivel continuar com o passo a passo, o próximo ponto importante é importar no cloudformation o template migration-assistant-for-amazon-opensearch-service.template (ele vai automaticamente para o cloudformation já com a stack), ponto para consideração ao subir a stack:

• Se atentar ao stage que vai ser indicado ao Stack, ele vai ser utilizado em outros passos da migração!

Ao final do processo da stack, será criada uma EC2, assim que possível se conecte a ela via SSM, ao entrar na EC2 (algo do tipo bootstrap-instance-STAGE-REGION), rodar o seguinte comando:

sudo su
cd /opensearch-migrations #entrar na pasta correta para dar inicio ao bootstrap que ajudará na migração
./initBootstrap.sh && cd deployment/cdk/opensearch-service-migration

Esse processo geralmente, leva algo em torno de 15 minutos (é bem demorado, mas configura partes importantes a migração)

Agora, ao fim do processo, na pasta atual (opensearch-migrations/deployment/cdk/opensearch-service-migration) existe um arquivo cdk.context.json, ele é o responsável sobre como a migração vai se comportar (guia de configuração), para uma migração com o assistente via console, o arquivo deve ser parecido com algo do tipo a seguir :

{
    "NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT": {
      "stage": "STAGE",
      "targetCluster": {
        "endpoint": "TARGET_CLUSTER_URL",
        "auth": {
          "type": "sigv4",
          "region": "us-east-1",
          "serviceSigningName": "es"
        }
      },
      "sourceCluster": {
        "endpoint": "SOURCE_CLUSTER_URL",
        "version": "ES_7.1", 
        "auth": {
          "type": "sigv4",
          "region": "us-east-1",
          "serviceSigningName": "es"
        }
      },
      "vpcId": "VPC_ID",
      "reindexFromSnapshotServiceEnabled": true, //habilita o RFS
      "artifactBucketRemovalPolicy": "RETAIN", // ou DESTROY Após utilizar o snapshot de dados via s3, mantém os arquivos no bucket
      "migrationConsoleServiceEnabled": true, // assistente de migração ativo
      "migrationAssistanceEnabled": true, // assistente de migração ativo
      "reindexFromSnapshotExtraArgs": "--s3-repo-uri s3://migration-artifacts-ACCOUNT_ID-STAGE-REGION/rfs-snapshot-repo --s3-region REGION --snapshot-name rfs-snapshot",
      "managedServiceSourceSnapshotEnabled": true // Configuração para que seja possivel usar o comando de snapshot
    }
  }

OBS: Para substituir o arquivo, pode ser usado o seguinte comando:

vi cdk.context.json
# Dentro do arquivo usando o VIM, usar a seguinte combinação de teclas:
# g g D Shift G # após isso pressionar i (para entrar em modo de edição no Vim)
# assim todo o arquivo antigo sera apagado e será mais fácil de colar sua nova configuração

Após a nova configuração adicionada, será necessário rodar os comandos de bootstrap:

cdk bootstrap --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT
cdk deploy "*" --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT --require-approval never --concurrency 3

OBS2: É importante garantir que o arquivo cdk.context.json esteja devidamente configurado, de maneira que se não estiver, será um problema futuro na migração via RFS

Agora será iniciada a criação das stacks necessárias para rodar os comandos de migração de dados, após a finalização do último comando (lembre do stage configurado no cloudformation!):

./accessContainer.sh migration-console STAGE REGION

Rodando a migração - Etapa de verificação da configuração

Ao executar o comando mencionado acima, será redirecionado para o console do assistente de migração, onde o primeiro passo importante é executar:

console clusters connection-check #comando que checa a conexão com o cluster de source e de target

Se o comando retornar a conexão com sucesso, então é possível seguir para a criação do snapshot (Tome cuidado, pois a criação afeta diretamente o consumo de CPU do cluster de Source):

Criação do Snapshot

Agora para dar inicio ao snapshot:

#AFETA PERFORMANCE DO CLUSTER (Se for snapshot total do cluster ou parcial com maior parte dos indexes)
console snapshot create #inicia a criação do snapshot do cluster completo de source

# para criar apenas o snapshot de um index usar --index-allowlist index
# para checar o status do snapshot em progresso

console snapshot status --deep-check

OBS3: Antes de seguirmos, é importante que todos os shards do snapshot estejam completos!

O retorno do comando de status será algo do tipo (algumas informações podem estar discrepantes, mas é apenas um bug do terminal)

Ao finalizar a criação do snapshot, será possível iniciar o metadata migration (que é importante para migração prévia de metadados dos indexes e aliases do cluster de source):

console metadata evaluate # importante para checar se todos os indices vão ser migrados
console metadata migrate # migração de metadados | --index-allowlist index  # para migrar metadata de apenas um indice

Rodando a migração - Etapa de migração dos dados

Para darmos inicio à migração de dados é necessário executar o seguinte comando:

console backfill start # inicio da migração
#Para checar o status da migração:

console backfill status --deep-check
#Para escalar o número de tasks do ECS*:

console backfill scale NUM_DESEJADO_DE_TASKS

OBS*: Tome cuidado ao elevar o número de tasks, pois, a depender do número de data nodes e da capacidade do cluster de target, isso pode causar erro 429 no cluster e atrapalhar a migração por completo!

A migração via RFS não para sozinha ao finalizar todas as shards disponíveis no snapshot, para isso, é muito importante que seja parada via execução de comando humano, que segue abaixo:

console backfill stop
# caso precise pausar a migração
console backfill pause

Finalizando a migração - Limpando o ambiente

Agora que tudo foi concluído (tome cuidado e confira se todas as shards foram finalizadas com sucesso), chega ao fim a migração !

Para evitar gastos e limpar o ambiente, execute os seguintes passos, mas primeiro no console, fora da venv:

cdk destroy "*" --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT
# é necessário o aceite no console para remover!

Ao terminar a exclusão via cdk destroy, é necessário ir ao cloudformation e deletar a stack referente ao RFS!

---

Troubleshooting

Nessa seção será disponibilizados algumas maneiras de debuggar os possíveis erros da solução:

• Erro de token ‘Too’ (Erro 429 Too many requests)

  • Nesse caso é necessário regular a quantidade de documentos por bulk request da solução, pois, o cluster não está aguentando o número de requisições da solução

• Erro de versão do cluster

  • Será necessário criar novamente o cluster

• Erro de conexão aos clusters

  • Esse erro é interessante analizar a VPC que foi cadastrada no cdk.context.json, onde é necessário que os domínios estejam dentro da vpc (Ambos), se ao menos 1 dos domínios estiver fora da VPC, será necesário conceder acesso a ele com um NatGateway.
  • Se ambos domínios estiverem fora da VPC, a solução do RFS cria uma VPC para uso, que possibilita o uso para o desenvolver da migração

• Como rodar a solução após algum ajuste necessário no arquivo cdk.context.json ?

  • Para tal sera necessário rodar novamente o comando:
  • Onde será refeito o deploy de todas as stacks necessárias para a migração.

cdk deploy "*" --c contextId=NOME_DO_OBJETO_PRINCIPAL_DO_CDK_CONTEXT --require-approval never --concurrency 3

• Erro de total de shards

  • Para ajustar é necessário no domínio de target rodar o seguinte comando:

PUT /_cluster/settings
{
  "persistent": {
    "cluster.max_shards_per_node": NUM_DESEJADO
  }
}

Caso algum erro esteja fora deste guia:

Entre em contato com Rudney Eduardo Souza Vieira ou também abra uma issue direta no github do projeto do RFS (o projeto será migrado para utilizar k8s, então dependendo da data que você está lendo o guia serão necessários outros ajustes)