Transferir do HDFS para o Cloud Storage

O Serviço de transferência do Cloud Storage é compatível com transferências de fontes do Sistema de arquivos distribuídos do Hadoop (HDFS, na sigla em inglês) e na nuvem.

As transferências do HDFS precisam usar o Cloud Storage como destino.

Os casos de uso incluem migração do armazenamento local para o Cloud Storage, arquivamento de dados para liberar espaço de armazenamento no local, replicação de dados no Google Cloud para a continuidade dos negócios ou transferência de dados ao Google Cloud para análise e processamento.

Configurar permissões

Antes de criar uma transferência, você precisa configurar as permissões para as seguintes entidades:

A conta de usuário usada para criar a transferência. Essa é a conta com login no console do Google Cloud ou a conta especificada ao fazer a autenticação na CLI "gcloud". A conta de usuário pode ser uma conta de usuário comum ou uma conta de serviço gerenciado pelo usuário.
A conta serviço gerenciado pelo Google, também conhecida como agente de serviço, usada pelo Serviço de transferência do Cloud Storage. Essa conta geralmente é identificada pelo endereço de e-mail, que usa o formato project-PROJECT_NUMBER@storage-transfer-service.iam.gserviceaccount.com.
A conta de agente de transferência que fornece permissões do Google Cloud para agentes de transferência. As contas de agente de transferência usam as credenciais do usuário que as instala ou as credenciais de uma conta de serviço gerenciado pelo usuário para fazer a autenticação.

Consulte Permissões de transferência baseadas em agente para ver instruções.

Instalar agentes em um pool

As transferências baseadas em agentes usam agentes de software para orquestrar transferências. Esses agentes precisam ser instalados em uma ou mais máquinas com acesso ao sistema de arquivos. Os agentes precisam ter acesso ao namenode, a todos os datanodes, ao servidor de gerenciamento de chaves (KMS) do Hadoop e ao Centro de distribuição de chaves (KDC) do Kerberos.

Os agentes de transferência trabalham juntos em um pool de agentes. O aumento do número de agentes pode melhorar o desempenho geral do job, mas isso depende de vários fatores.

  • Adicionar mais agentes pode ajudar até cerca de metade do número de nós no cluster do HDFS. Por exemplo, com um cluster de 30 nós, aumentar de 5 para 15 agentes deve melhorar o desempenho, mas mais de 15 é improvável que faça muita diferença.

  • Para um cluster do HDFS pequeno, um agente pode ser suficiente.

  • Agentes adicionais tendem a ter um impacto maior no desempenho quando uma transferência inclui um grande número de arquivos pequenos. O Serviço de transferência do Cloud Storage atinge alta capacidade ao carregar tarefas de transferência em paralelo entre vários agentes. Quanto mais arquivos na carga de trabalho, maior será a vantagem de adicionar mais agentes.

Não inclua informações sensíveis, como informações de identificação pessoal (PII, na sigla em inglês) ou dados de segurança no nome do pool de agentes ou no prefixo do ID do agente. Os nomes dos recursos podem ser propagados para os nomes de outros recursos do Google Cloud e podem ser expostos aos sistemas internos do Google fora do seu projeto.

Criar um pool de agentes

Crie um pool de agentes. Use sua conta de usuário Símbolo da conta de usuário para essa ação.

Instalar agentes

Instale agentes no pool de agentes. Use sua conta de agente de transferência para essa ação.

Console do Google Cloud

  1. No Console do Google Cloud, acesse a página Pools de agentes.

    Acessar pools de agentes

  2. Selecione o pool de agentes a que o novo agente será adicionado.

  3. Clique em Instalar agente.

  4. Siga as instruções exibidas para instalar e executar o agente.

    Para mais informações sobre as opções de linha de comando do agente, consulte Opções de linha de comando do agente.

CLI gcloud

Para instalar um ou mais agentes usando a CLI gcloud, execute gcloud transfer agents install:

gcloud transfer agents install --pool=POOL_NAME \
  --count=NUM_AGENTS \
  --mount-directories=MOUNT_DIRECTORIES \
  --hdfs-namenode-uri=HDFS_NAMENODE_URI \
  --hdfs-username=HDFS_USERNAME \
  --hdfs-data-transfer-protection=HDFS_DATA_TRANSFER_PROTECTION \
  --kerberos-config-file=KERBEROS_CONFIG_FILE \
  --kerberos-keytab-file=KERBEROS_KEYTAB_FILE \
  --kerberos-user-principal=KERBEROS_USER_PRINCIPAL \
  --kerberos-service-principal=KERBEROS_SERVICE_PRINCIPAL \

Em que:

  • --hdfs-namenode-uri especifica um cluster do HDFS, incluindo um esquema, namenode e porta, no formato de URI. Exemplo:

    • rpc://my-namenode:8020
    • http://my-namenode:9870

    Use HTTP ou HTTPS para WebHDFS. Se nenhum esquema for fornecido, vamos presumir a RPC. Se nenhuma porta for fornecida, o padrão será 8020 para RPC, 9870 para HTTP e 9871 para HTTPS. Por exemplo, a entrada my-namenode se torna rpc://my-namenode:8020.

    Se o cluster estiver configurado com vários namenodes, especifique o principal atual. Consulte Clusters com vários namenodes para mais informações.

  • --hdfs-username é o nome de usuário para conexão com um cluster do HDFS com autenticação simples. Omita essa flag se você estiver fazendo a autenticação com o Kerberos ou se estiver se conectando sem nenhuma autenticação.

  • --hdfs-data-transfer-protection (opcional) é a configuração de qualidade de proteção (QOP) do lado do cliente para clusters Kerberizados. O valor não pode ser mais restritivo do que o valor de QOP do lado do servidor. Os valores válidos são: authentication, integrity e privacy.

Se você estiver autenticando com o Kerberos, também inclua as seguintes flags:

  • --kerberos-config-file é o caminho para um arquivo de configuração do Kerberos. Por exemplo, --kerberos-config-file=/etc/krb5.conf.

  • --kerberos-user-principal é o principal do usuário do Kerberos a ser usado. Por exemplo, --kerberos-user-principal=user1.

  • --kerberos-keytab-file é o caminho para um arquivo Keytab que contém o principal do usuário especificado com a flag --kerberos-user-principal. Por exemplo, --kerberos-keytab-file=/home/me/kerberos/user1.keytab.

  • --kerberos-service-principal é o principal de serviço do Kerberos a ser usado, no formato <primary>/<instance>. O realm é mapeado do arquivo de configuração do Kerberos. Qualquer realm fornecido é ignorado. Se essa flag não for especificada, o padrão será hdfs/<namenode_fqdn>, em que <namenode_fqdn> é o nome de domínio totalmente qualificado especificado no arquivo de configuração.

    Por exemplo, --kerberos-service-principal=hdfs/my-namenode.a.example.com.

A ferramenta mostrará as etapas necessárias para instalar os agentes. Esse comando instala o(s) agente(s) NUM_AGENTS na sua máquina, mapeado para o nome do pool especificado como POOL_NAME e autentica o agente usando as credenciais do gcloud. O nome do pool precisa existir ou um erro é retornado.

A sinalização --mount-directories é opcional, mas altamente recomendada. O valor dela é uma lista de diretórios separados por vírgulas no sistema de arquivos aos quais o agente concede acesso. A omissão dessa sinalização monta todo o sistema de arquivos no contêiner do agente. Consulte a referência gcloud para mais detalhes.

docker run

Antes de usar o docker run para instalar agentes, siga as instruções para instalar o Docker.

O comando docker run instala um agente. Para aumentar o número de agentes no pool, execute esse comando quantas vezes forem necessárias.

As flags de comando necessárias dependem do tipo de autenticação que você está usando.

Kerberos

Para autenticar no seu sistema de arquivos usando o Kerberos, use o seguinte comando:

sudo docker run -d --ulimit memlock=64000000 --rm \
  --network=host \
  -v /:/transfer_root \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --enable-mount-directory \
  --project-id=${PROJECT_ID} \
  --hostname=$(hostname) \
  --creds-file="service_account.json" \
  --agent-pool=${AGENT_POOL_NAME} \
  --hdfs-namenode-uri=cluster-namenode \
  --kerberos-config-file=/etc/krb5.conf \
  --kerberos-user-principal=user \
  --kerberos-keytab-file=/path/to/folder.keytab

Em que:

  • Se você estiver executando mais de um agente nesta máquina, omita --network=host.
  • --hdfs-namenode-uri: um esquema, um namenode e uma porta, no formato de URI, que representam um cluster do HDFS. Exemplo:

    • rpc://my-namenode:8020
    • http://my-namenode:9870

Use HTTP ou HTTPS para WebHDFS. Se nenhum esquema for fornecido, vamos presumir a RPC. Se nenhuma porta for fornecida, o padrão será 8020 para RPC, 9870 para HTTP e 9871 para HTTPS. Por exemplo, a entrada my-namenode se torna rpc://my-namenode:8020.

Se o cluster estiver configurado com vários namenodes, especifique o principal atual. Consulte Clusters com vários namenodes para mais informações.

  • --kerberos-config-file: caminho para um arquivo de configuração do Kerberos. O padrão é /etc/krb5.conf.
  • --kerberos-user-principal: o principal do usuário do Kerberos.
  • --kerberos-keytab-file: caminho para um arquivo Keytab que contém o principal do usuário especificado com --kerberos-user-principal.
  • --kerberos-service-principal: principal de serviço do Kerberos a ser usado, no formato "serviço/instância". O realm é mapeado do arquivo de configuração do Kerberos. Qualquer realm fornecido é ignorado. Se essa flag não for especificada, o padrão será hdfs/<namenode_fqdn>, em que fqdn é o nome de domínio qualificado.

Autenticação simples

Para autenticar no seu sistema de arquivos usando uma autenticação simples:

sudo docker run -d --ulimit memlock=64000000 --rm \
  --network=host \
  -v /:/transfer_root \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --enable-mount-directory \
  --project-id=${PROJECT_ID} \
  --hostname=$(hostname) \
  --creds-file="${CREDS_FILE}" \
  --agent-pool="${AGENT_POOL_NAME}" \
  --hdfs-namenode-uri=cluster-namenode \
  --hdfs-username="${USERNAME}"

Em que:

  • --hdfs-username: nome de usuário a ser usado na conexão com um cluster do HDFS usando autenticação simples.
  • --hdfs-namenode-uri: um esquema, um namenode e uma porta, no formato de URI, que representam um cluster do HDFS. Por exemplo:
    • rpc://my-namenode:8020
    • http://my-namenode:9870

Use HTTP ou HTTPS para WebHDFS. Se nenhum esquema for fornecido, vamos presumir a RPC. Se nenhuma porta for fornecida, o padrão será 8020 para RPC, 9870 para HTTP e 9871 para HTTPS. Por exemplo, a entrada my-namenode se torna rpc://my-namenode:8020.

Se o cluster estiver configurado com vários namenodes, especifique o principal atual. Consulte Clusters com vários namenodes para mais informações.

Sem autenticação

Para se conectar ao sistema de arquivos sem autenticação:

sudo docker run -d --ulimit memlock=64000000 --rm \
  --network=host \
  -v /:/transfer_root \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --enable-mount-directory \
  --project-id=${PROJECT_ID} \
  --hostname=$(hostname) \
  --creds-file="${CREDS_FILE}" \
  --agent-pool="${AGENT_POOL_NAME}" \
  --hdfs-namenode-uri=cluster-namenode \

Em que:

  • --hdfs-namenode-uri: um esquema, um namenode e uma porta, no formato de URI, que representam um cluster do HDFS. Por exemplo:
    • rpc://my-namenode:8020
    • http://my-namenode:9870

Use HTTP ou HTTPS para WebHDFS. Se nenhum esquema for fornecido, vamos presumir a RPC. Se nenhuma porta for fornecida, o padrão será 8020 para RPC, 9870 para HTTP e 9871 para HTTPS. Por exemplo, a entrada my-namenode se torna rpc://my-namenode:8020.

Se o cluster estiver configurado com vários namenodes, especifique o principal atual. Consulte Clusters com vários namenodes para mais informações.

Opções de transferência

Os seguintes recursos do Serviço de transferência do Cloud Storage estão disponíveis para transferências do HDFS para o Cloud Storage.

Os arquivos transferidos do HDFS não mantêm os metadados.

Criar uma transferência

Não inclua informações sensíveis, como informações de identificação pessoal (PII, na sigla em inglês) ou dados de segurança no nome do job de transferência. Os nomes dos recursos podem ser propagados para os nomes de outros recursos do Google Cloud e podem ser expostos aos sistemas internos do Google fora do seu projeto.

O Serviço de transferência do Cloud Storage oferece várias interfaces para criar uma transferência.

Console do Google Cloud

  1. Acesse a página Serviço de transferência do Cloud Storage no Console do Google Cloud.

    Acessar o Serviço de transferência do Cloud Storage

  2. Clique em Criar job de transferência. Será exibida a página Criar um job de transferência.

  3. Selecione Hadoop Distributed File System como o Source type. O destino precisa ser o Google Cloud Storage.

    Clique em Próxima etapa.

Configurar sua fonte

  1. Especifique as informações necessárias para esta transferência:

    1. Selecione o pool de agentes configurado para esta transferência.

    2. Insira o Caminho de origem da transferência, em relação ao diretório raiz.

  2. Opcionalmente, especifique filtros a serem aplicados aos dados de origem.

  3. Clique em Próxima etapa.

Configurar o coletor

  1. No campo Bucket ou pasta, insira o bucket de destino e, opcionalmente, o nome da pasta ou clique em Procurar para selecionar um bucket de uma lista de buckets no seu projeto atual. Para criar um novo bucket, clique em Ícone do bucket Criar novo bucket.

  2. Clique em Próxima etapa.

Programar a transferência

É possível programar a execução da transferência apenas uma vez ou configurar uma transferência recorrente.

Clique em Próxima etapa.

Escolher configurações de transferência

  1. No campo Descrição, insira uma descrição da transferência. Como prática recomendada, insira uma descrição significativa e exclusiva para que você possa distinguir os jobs.

  2. Em Opções de metadados, selecione a classe de armazenamento do Cloud Storage e se quer salvar a hora de criação de cada objeto. Consulte Preservação de metadados para mais detalhes.

  3. Em Quando substituir, selecione uma destas opções:

    • Nunca: não substitua os arquivos de destino. Se um arquivo existir com o mesmo nome, ele não será transferido.

    • Se diferente: substitui os arquivos de destino se o arquivo de origem com o mesmo nome tiver valores de ETags ou de soma de verificação diferentes.

    • Sempre: sempre grava arquivos de destino quando o arquivo de origem tem o mesmo nome, mesmo que sejam idênticos.

  4. Em Quando excluir, selecione uma destas opções:

    • Nunca: nunca exclua arquivos da origem ou do destino.

    • Excluir arquivos do destino se eles não estiverem na origem: se os arquivos no bucket do Cloud Storage de destino também não estiverem na origem, exclua os arquivos do Cloud Storage. bucket.

      Essa opção garante que o bucket de destino do Cloud Storage corresponda exatamente à sua origem.

  5. Selecione se você quer ativar a geração de registros de transferência e/ou as notificações do Pub/Sub.

Clique em Criar para criar o job de transferência.

CLI da gcloud

Para criar um novo job de transferência, use o comando gcloud transfer jobs create. A criação de um novo job inicia a transferência especificada, a menos que uma programação ou --do-not-run seja especificado.

gcloud transfer jobs create \
  hdfs:///PATH/ gs://BUCKET_NAME/PATH/
  --source-agent-pool=AGENT_POOL_NAME

Em que:

  • PATH é um caminho absoluto da raiz do cluster do HDFS. O nome do nó e a porta do cluster são configurados no nível do agente. Portanto, o comando de criação de jobs só precisa especificar o caminho (opcional) e o pool de agentes.

  • --source-agent-pool especifica o pool de agentes de origem a ser usado para esta transferência.

As opções adicionais incluem:

  • --do-not-run impede que o Serviço de transferência do Cloud Storage execute o job após o envio do comando. Para executar o job, atualize-o para adicionar uma programação ou use jobs run para iniciá-lo manualmente.

  • --manifest-file especifica o caminho para um arquivo CSV no Cloud Storage contendo uma lista de arquivos a serem transferidos da sua origem. Para formatar o arquivo de manifesto, consulte Transferir arquivos ou objetos específicos usando um manifesto.

  • Informações do job: é possível especificar --name e --description.

  • Programação: especifique --schedule-starts, --schedule-repeats-every e --schedule-repeats-until ou --do-not-run.

  • Condições de objeto: use condições para determinar quais objetos são transferidos. Elas incluem --include-prefixes e --exclude-prefixes, além das condições baseadas em tempo em --include-modified-[before | after]-[absolute | relative]. Se você especificou uma pasta com a origem, os filtros de prefixo são relativos a essa pasta. Consulte Filtrar objetos de origem por prefixo para mais informações.

  • Opções de transferência: especifique se você quer substituir os arquivos de destino (--overwrite-when=different ou always) e se quer excluir determinados arquivos durante ou após a transferência (--delete-from=destination-if-unique ou source-after-transfer). Além disso, opcionalmente, defina uma classe de armazenamento em objetos transferidos (--custom-storage-class).

  • Notificações: configure as notificações de Pub/Sub para transferências com --notification-pubsub-topic, --notification-event-types e --notification-payload-format.

Para ver todas as opções, execute gcloud transfer jobs create --help ou consulte a documentação de referência de gcloud.

API REST

Para criar uma transferência de uma fonte HDFS com API REST usando a API REST, crie um objeto JSON semelhante ao exemplo a seguir.

POST https://storagetransfer.googleapis.com/v1/transferJobs
{
  ...
  "transferSpec": {
    "source_agent_pool_name":"POOL_NAME",
    "hdfsDataSource": {
      "path": "/mount"
    },
    "gcsDataSink": {
      "bucketName": "SINK_NAME"
    },
    "transferOptions": {
      "deleteObjectsFromSourceAfterTransfer": false
    }
  }
}

Consulte a referência transferJobs.create para saber mais sobre outros campos aceitos.

Clusters com vários namenodes

Os agentes do Serviço de transferência do Cloud Storage só podem ser configurados com um único namenode. Se o cluster do HDFS estiver configurado com vários namenodes ("alta disponibilidade") e houver um evento de failover que resulte em um novo namenode principal, será necessário reinstalar os agentes com o namenode correto.

Para excluir os agentes antigos, consulte Excluir um agente.

O namenode ativo do cluster pode ser recuperado executando:

hdfs haadmin -getAllServiceState