Data Online Migration:Migration FAQ

Como estimar a velocidade e a duração da migração

Sobre a velocidade de migração:

• Por padrão, o Data Online Migration atribui a cada tarefa uma largura de banda de pico teórica fixa e QPS. Para obter detalhes, consulte Task bandwidth and QPS. Defina a largura de banda de pico teórica e o QPS conforme as necessidades do seu negócio para evitar competição entre o tráfego de migração e o de produção, o que poderia afetar as operações normais.

• A velocidade de migração não necessariamente atinge a largura de banda de pico teórica e o QPS. Os principais fatores incluem:

  • Largura de banda e qualidade do link de rede entre origem e destino. Links de longa distância com alta latência ou altas taxas de perda de pacotes (como transferências via rede pública internacional) podem reduzir a eficiência ou causar falhas frequentes na transferência de arquivos. Use uma linha dedicada ou um link de aceleração, como um endpoint de aceleração do oss, para obter melhor desempenho.

  • Capacidades de leitura/gravação da origem e do destino e tamanho médio dos arquivos. O service de migração percorre diretórios, lê metadados e conteúdo da origem e grava metadados e conteúdo no destino, além de reler metadados. A capacidade de percurso da origem afeta a velocidade de varredura. O desempenho de leitura/gravação em ambas as extremidades influencia a velocidade de migração, especialmente ao migrar milhões de arquivos pequenos com menos de 200 KB. Estime o tamanho médio do arquivo dividindo o volume total de dados da origem pelo número total de arquivos.

  • Número de diretórios de origem e distribuição de arquivos. Em sistemas de arquivos que suportam diretórios (como LocalFS ou FTP), o Data Online Migration verifica os diretórios simultaneamente, nível por nível. O excesso de diretórios ou uma distribuição esparsa de arquivos torna a varredura mais lenta.

  • Configuração de software e hardware e número de instâncias de proxy. Se o endereço de dados de origem ou destino usar um proxy, ele poderá se tornar um gargalo. Para orientações sobre a seleção de proxy, consulte Proxy selection.

• Devido a esses fatores, o Data Online Migration não garante a velocidade de migração. Antes de executar uma migração completa, valide sua configuração com uma prova de conceito (PoC) em pequena escala para estimar com precisão o desempenho real.

Sobre a duração da migração:

• Após estimar uma velocidade de migração razoável, calcule o tempo de migração usando o volume total de dados e a contagem total de arquivos. Estime a menor duração possível usando armazenamento total ÷ largura de banda e contagem total de arquivos ÷ QPS e considere o maior valor.

• A duração calculada da migração é teórica. Considere flutuações de largura de banda, novas tentativas após falhas e outras variáveis. Sempre prepare planos de contingência e reserve uma margem de tempo, especialmente para migrações de produção que exigem tempo de inatividade.

• O Data Online Migration impõe limites superiores na alocação de recursos por tarefa. Para obter detalhes, consulte Task bandwidth and QPS.

A seguir, apresentamos um exemplo de avaliação abrangente:

• Cenário 1:

  • Pergunta: A origem é S3 com cerca de 1 TB de dados e 10 milhões de arquivos. O destino é o oss. A tarefa é criada na região Beijing. Quanto tempo levará a migração?

  • Resposta: De acordo com Task bandwidth and QPS, a velocidade teórica de tarefa única em Beijing é de 2 Gbps e 2.000 arquivos/segundo. Cálculos:

    • Duração por volume de armazenamento: 1 TB ÷ 2 Gbps ≈ 1,1 horas.

    • Duração por contagem de arquivos: 10.000.000 ÷ 2.000 arquivos/segundo ≈ 1,4 horas.

    • Duração teórica da migração: Considere o maior valor: 1,4 horas.

• Cenário 2:

  • Pergunta: A origem é o oss com cerca de 1 TB de dados e 100.000 arquivos. O destino é o Alibaba Cloud NAS. A tarefa é criada na região Singapore. Quanto tempo levará a migração?

  • Resposta: De acordo com Task bandwidth and QPS, a velocidade teórica de tarefa única em Singapore é de 1 Gbps e 2.000 arquivos/segundo. No entanto, como o destino é LocalFS, o limite teórico de QPS é de 200 arquivos/segundo. Cálculos:

    • Duração por volume de armazenamento: 1 TB ÷ 1 Gbps ≈ 2,3 horas.

    • Duração por contagem de arquivos: 100.000 ÷ 200 arquivos/segundo ≈ 500 segundos.

    • Duração teórica da migração: Considere o maior valor: 2,3 horas.

O proxy apresenta status anormal no console

As instâncias de proxy do Data Online Migration devem ser implantadas para funcionar corretamente. Se o status do proxy ainda mostrar Connection Abnormal após a implantação correta, verifique os seguintes itens:

• Conectividade de rede. Consulte o parâmetro Network type em Use a proxy for migration para verificar a conectividade da máquina do proxy aos domínios do service Data Online Migration.

• Credenciais incorretas ou permissões insuficientes, tais como:

  • Erros de digitação. Por exemplo, um accesskeyid ou SecretAccessKey incompleto ou corrompido devido a erros ao copiar e colar.

  • Permissões insuficientes. O accesskeyid deve ter uma das seguintes permissões, e o Resource scope deve estar definido como Account level:

    • mgw:VerifyAgentTunnel

    • AliyunOSSImportReadOnlyAccess

    • AliyunOSSImportFullAccess

  • Incompatibilidade de conta. O accesskeyid não pertence ao usuário RAM atual ou a outro usuário RAM na mesma conta Alibaba Cloud. Independentemente da migração entre contas, use credenciais de um usuário RAM na conta Alibaba Cloud atual. Esse usuário RAM deve ter uma das três permissões listadas acima.

• Credenciais restritas pelas Network access control policies do RAM. O Data Online Migration exige que o accesskeyid permita acesso de todos os segmentos de rede. Para permitir o acesso à rede pública, acesse a página AccessKey-level network access control policy, selecione Enable, clique em Allow all public network access (o sistema adiciona automaticamente ::/0 e 0.0.0.0/0), clique em OK na tabela de políticas de rede pública e, em seguida, clique em Submit na parte inferior da página.

• Credenciais restritas pelas access policies do RAM. Se você atribuiu uma política personalizada a este usuário RAM que inclui restrições de endereço IP, o proxy poderá falhar ao executar.

• Relógio do sistema impreciso na máquina do proxy. O horário não deve divergir do horário real em mais de 5 minutos.

• Comando de implantação modificado ou incompleto. Copie e cole o comando de implantação gerado automaticamente pelo console exatamente como mostrado. Não o modifique.

Se o status do proxy estiver instável, as possíveis causas incluem:

• Rede instável. A baixa qualidade da rede entre o proxy e o service Data Online Migration causa problemas intermitentes de conexão. Se o ambiente de rede do proxy mudar, verifique novamente a conectividade conforme descrito em Use a proxy for migration.

• Alta carga no proxy. Uma tarefa de migração em execução pode causar anomalias ocasionais de conexão. Se a tarefa for executada normalmente, isso é esperado. Caso a máquina apresente alta média de carga, escale horizontalmente as instâncias de proxy ou reduza a configuração Maximum files migrated per second.

• Limitação de taxa ativada na instância de canal associada. As verificações de integridade do proxy consomem uma pequena quantidade de QPS do canal, o que pode competir com as solicitações de migração e causar rejeição. Aumente o limite de Requests per second do canal ou desative a limitação de taxa no nível do canal.

• O processo do proxy foi encerrado. Consulte View, start, and stop proxy processes para verificar o status do processo. Se o tipo de instância da máquina do proxy estiver abaixo das especificações recomendadas, o processo poderá ser encerrado devido à falta de memória. Para obter as especificações recomendadas, consulte Proxy selection.

• Implantação duplicada. Cada instância de proxy deve ser executada em apenas uma máquina. Implantar a mesma instância em várias máquinas causa conflitos e instabilidade. Para trocar de máquina, interrompa primeiro o processo do proxy antigo e, em seguida, implante novamente.

A tarefa de migração não apresenta progresso

• Agendamento em segundo plano. As tarefas geralmente aguardam de 10 a 15 minutos na fila antes de iniciar. Aguarde.

• Arquivos filtrados. Se a tarefa usar um filtro de arquivos e poucos arquivos de origem corresponderem aos critérios, as atualizações de progresso serão lentas.

• Tempo de pré-processamento do manifesto. Se a origem for um endereço de dados do tipo manifesto, o tempo de pré-processamento aumentará conforme o número total de arquivos no manifesto.

• Migração simultânea de arquivos grandes. Se o gráfico de largura de banda na página de detalhes da tarefa corresponder às tendências esperadas, o comportamento é normal.

• Outras causas possíveis:

  • Para origens LocalFS ou FTP, muitos diretórios ou distribuição esparsa de arquivos tornam a varredura mais lenta. Erros de permissão ou corrupção de diretório também podem interromper a varredura.

  • Para destinos LocalFS, a migração de muitos arquivos com tamanho na casa dos gigabytes pode atrasar as atualizações de progresso. Verifique a largura de banda real na máquina do proxy (por exemplo, via ECS cloud Monitor).

  • Se qualquer uma das extremidades usar um proxy, alta carga ou problemas de conexão na máquina do proxy afetam o progresso da tarefa.

Como visualizar arquivos com falha na migração

Durante a migração, alguns arquivos podem falhar devido a permissões insuficientes na origem, problemas de rede ou outros erros. Use um destes métodos para identificar os arquivos com falha e suas causas:

• Método 1: Envio de relatório de migração

Ao criar uma tarefa, ative a entrega de relatórios de migração. Também é possível modificar essa configuração posteriormente. Após a conclusão da tarefa, o Data Online Migration grava um registro completo de migração em um local especificado no endereço de dados de destino. Revise este relatório para identificar arquivos com falha e os motivos.

• Método 2: Envio de logs de migração

Ao criar uma tarefa de migração, ative a entrega de logs de migração. O Data Online Migration envia logs em tempo real para o Simple Log Service (SLS). Analise esses logs no SLS para encontrar arquivos com falha e detalhes específicos do erro.

Motivos comuns de falha na migração

A tabela a seguir lista palavras-chave de códigos de erro (parciais) para falhas de migração. Esses códigos podem aparecer em:

• Mensagens de erro quando a criação de um endereço de dados falha.

• Mensagens de erro no histórico de tarefas quando uma tarefa falha durante a execução.

• Campo Failure reason nos relatórios de migração.

underscoreUserMetaDropOrSkipUids=<UID>,drop;

Incompatibilidade de volume de dados após a migração

Se os volumes de dados de origem e destino diferirem após a conclusão da migração, investigue os seguintes pontos.

Se o volume de dados de destino for menor, as possíveis causas incluem:

• Dados alterados durante a migração. A origem pode ter recebido novas gravações ou o destino pode ter tido exclusões (manuais ou via políticas de ciclo de vida).

• A origem contém várias versões (como lixeira do oss, S3 ou NAS). O Data Online Migration migra apenas a versão mais recente.

• Atraso nas estatísticas. As métricas de destino podem ter um atraso de horas ou dias. Consulte a documentação relevante ou use ferramentas como ossutil para verificação manual.

• Alguns dados foram ignorados. Por exemplo, um arquivo de 1 GB na origem e um arquivo de 100 MB no destino podem ser ignorados com base nas configurações de substituição da tarefa.

• A origem contém fragmentos. O Data Online Migration não migra objetos incompletos ou fragmentos.

• Configuração incorreta do filtro de arquivos. Se os filtros estiverem ativados, verifique as regras quanto a espaços não intencionais ou caracteres especiais.

• Prefixo de origem incorreto. Especificar um Prefixo migra apenas os dados sob aquele Prefixo.

• Diferenças no tipo de armazenamento. Sistemas de arquivos como NAS contam diretórios no uso de armazenamento. Armazenamentos de objetos como oss não possuem o conceito de diretório, e objetos vazios não são contabilizados.

• Falhas parciais na montagem do NAS. Se a origem for LocalFS com vários proxies e algumas montagens do NAS estiverem quebradas, os arquivos acessados por meio desses proxies poderão ser ignorados devido a erros NotFound, reduzindo o total de dados migrados.

Se o volume de dados de destino for maior, as possíveis causas incluem:

• Dados alterados durante a migração. A origem pode ter tido exclusões (manuais ou via políticas de ciclo de vida) ou o destino pode ter recebido novas gravações.

• O destino tem o recurso de multiversão ativado (como lixeira do oss ou NAS). O Data Online Migration usa APIs sem multiversão. Se a multiversão estiver ativada, cada gravação cria uma nova versão.

• Alguns dados foram ignorados. Por exemplo, um arquivo de 100 MB na origem e um arquivo de 1 GB no destino podem ser ignorados com base nas configurações de substituição.

• Fragmentos residuais ou arquivos temporários no destino. Se uma tarefa falhar (devido a ação do usuário, erros graves ou problemas de rede), fragmentos ou arquivos temporários podem permanecer.

• Configuração incorreta do filtro de arquivos. Verifique as regras de filtro quanto a espaços não intencionais ou caracteres especiais.

• Dados existentes sob o Prefixo de destino. Se o Prefixo de destino já continha dados antes da migração, esses dados permanecem (embora arquivos com o mesmo nome possam ser substituídos com base nas configurações da tarefa).

• Diferenças no tipo de armazenamento. Sistemas de arquivos como NAS contam diretórios no uso de armazenamento. Armazenamentos de objetos como oss não possuem o conceito de diretório, e objetos vazios não são contabilizados.

• Sobrecarga de armazenamento do relatório de migração. Se você ativou a entrega de relatórios de migração, o próprio relatório consome espaço proporcional ao total de arquivos migrados.

Tráfego de saída excessivo na origem ou migração repetida de arquivos

Normalmente, o Data Online Migration baixa cada arquivo de origem uma vez. Se você observar um tráfego de saída da origem maior do que o esperado após a migração, as possíveis causas incluem:

• Novas tentativas internas. Desconexões transitórias de rede, limitação de leitura/gravação ou gargalos de proxy acionam novas tentativas automáticas limitadas.

• Acesso de sistemas externos. Outros sistemas (como sua aplicação ou busca de origem CDN) acessando a origem durante a migração aumentam o tráfego de saída.

Se arquivos migrados anteriormente forem migrados novamente em vez de serem ignorados nas execuções subsequentes, as possíveis causas incluem:

• Overwrite mode incorreto. Se definido como Force overwrite, o Data Online Migration sempre substituirá os arquivos de destino, independentemente do conteúdo existente.

• Políticas de ciclo de vida do destino. Se você selecionou Preserve last modified time durante a criação da tarefa, os carimbos de data/hora do arquivo de origem serão aplicados ao destino. Se o destino tiver uma política de ciclo de vida que exclui arquivos, os arquivos migrados poderão ser removidos logo em seguida.

• Atualizações frequentes na origem. Se o modo de substituição for Overwrite based on last modified time, qualquer atualização de carimbo de data/hora na origem (mesmo sem alteração de conteúdo) acionará uma nova migração na próxima execução.

Problemas de migração entre contas no oss

Existem três cenários entre contas: outra conta para sua conta, sua conta para outra conta e outra conta para outra conta (complexo e não recomendado — converta para os dois primeiros). Podem surgir problemas de autorização. Resumo:

• Etapas principais de autorização:

  • Crie uma função RAM na sua conta através do console RAM. Consulte Create a RAM role for data migration.

  • Compartilhe o RoleName com o administrador da outra conta. O administrador concede permissões no Bucket de destino. Consulte Source Bucket authorization ou Destination Bucket authorization.

  • A autorização agora está completa. Ao criar o endereço de dados para o Bucket no Data Online Migration, insira o RoleName no campo Authorization role.

• Após a autorização entre contas, erros de "permissões insuficientes" podem persistir se o RoleName contiver letras maiúsculas. Mesmo que o RoleName original no RAM inclua letras maiúsculas (por exemplo, MyOssImportRole), use apenas letras minúsculas (por exemplo, myossimportrole) na política ACL do Bucket.

Problemas de migração entre contas no NAS

• Ao usar o Data Online Migration, a migração de instâncias NAS entre diferentes contas Alibaba Cloud não envolve cenários entre contas. O service usa E/S POSIX padrão para ler/gravar diretórios especificados e não reconhece o armazenamento subjacente como NAS ou sua propriedade.

• Implante um proxy e monte o NAS no proxy, tratando-o então como um endereço de dados LocalFS. Preste muita atenção ao mapeamento de diretórios para evitar leitura ou gravação em caminhos de disco não intencionais.

• Exemplo: Migrar NAS da Conta A para o NAS da sua conta.

  • Monte o NAS da Conta A na máquina M1. M1 pode ser uma instância ECS na Conta A (recomendado) ou qualquer máquina que suporte a montagem do NAS da Conta A.

  • No console do Data Online Migration, crie a instância de proxy agent1 e implante-a em M1.

  • Monte o NAS da sua conta na máquina M2. M2 pode ser uma instância ECS na sua conta (recomendado) ou qualquer máquina compatível.

  • No console do Data Online Migration, crie a instância de proxy agent2 e implante-a em M2.

  • Após confirmar que ambos os proxies mostram status "Normal", siga Migrate between LocalFS systems para criar endereços de dados e tarefas de migração.

O oss suporta migração entre contas internacionais e da China da Alibaba Cloud?

Sim. Para obter detalhes, consulte Migrate between Alibaba Cloud OSS instances.