Use o Data Box para migrar do Armazenamento Conectado à Rede (NAS) para compartilhamentos de arquivos do Azure

✔️ Aplica-se a: compartilhamentos de arquivos SMB clássicos criados com o provedor de recursos Microsoft.Storage

✖️ Não se aplica a: todos os compartilhamentos de arquivos NFS, incluindo compartilhamentos de arquivos criados com o provedor de recursos Microsoft.FileShares ou compartilhamentos de arquivos clássicos criados com o provedor de recursos Microsoft.Storage

Este artigo sobre migração é um dos vários envolvendo as palavras-chave NAS e Azure Data Box. Verifique se este artigo se aplica ao seu cenário:

  • Fonte de dados: NAS (Armazenamento Conectado à Rede)
  • Rota de migração: NAS ⇒ Data Box ⇒ Azure compartilhamento de arquivos
  • Nenhum arquivo de cache local: como o objetivo final é usar os compartilhamentos de arquivos do Azure diretamente na nuvem, não existe plano para usar a Sincronização de Arquivos do Azure.

Se seu cenário for diferente, analise a tabela de guias de migração.

Observação

O Data Box suporta NFS como protocolo de cópia, então você pode usá-lo para copiar dados de um NAS que atende ao NFS. No entanto, o Data Box não suporta importar dados diretamente para compartilhamentos de arquivos do NFS Azure. Este guia cobre apenas os alvos de compartilhamento de arquivos SMB.

Este artigo orienta você de ponta a ponta nas configurações de planejamento, implantação e rede, necessárias para migrar do seu dispositivo NAS para os compartilhamentos de arquivos funcionais do Azure. Este guia utiliza o Azure Data Box para transporte em massa de dados (transporte de dados offline).

Metas de migração

O objetivo é mover os compartilhamentos em seu dispositivo NAS para o Azure e fazer com que eles se tornem compartilhamentos de arquivos nativos do Azure. Você pode usar compartilhamentos de arquivos nativos do Azure sem a necessidade de um Windows Server. Essa migração precisa ser feita de forma a garantir a integridade dos dados de produção e a disponibilidade durante a migração. O último requer um mínimo de tempo de inatividade, para que ele possa se ajustar ou ter uma janela um pouco maior do que a da manutenção regular.

Visão geral da migração

O processo de migração consiste em várias fases. Primeiro, implante contas de armazenamento Azure e compartilhamentos de arquivos e configure a rede. Depois, migre seus arquivos usando Azure Data Box e RoboCopy para acompanhar as mudanças. Por fim, migre seus usuários e aplicativos para os compartilhamentos de arquivos do Azure recém-criados. As seções a seguir descrevem em detalhes, as fases do processo de migração.

Dica

Ao retornar a este artigo, use a navegação no lado direito para pular para a fase de migração em que você parou.

Fase 1: identificar quantos compartilhamentos de arquivos do Azure você precisa

Determine quantos compartilhamentos de arquivos do Azure você precisa. Você pode ter mais pastas em seus volumes que você compartilha localmente no momento como compartilhamentos SMB para seus usuários e aplicativos. Dependendo do número de compartilhamentos de arquivos que você quer migrar para a nuvem, escolha um mapeamento um-para-um ou um agrupamento de compartilhamentos.

Usar um mapeamento 1:1

Se você tiver poucos compartilhamentos, use um mapeamento um para um. A maneira mais fácil de descrever esse cenário é prever um compartilhamento local que mapeia um compartilhamento individual para um arquivo do Azure.

Usar o agrupamento de compartilhamentos

Se você tem um grande número de compartilhamentos de arquivos, considere o agrupamento de compartilhamentos. Por exemplo, se o departamento de RH (Recursos Humanos) tiver 15 compartilhamentos, considere o armazenamento de todos os dados de RH em um só compartilhamento de arquivo do Azure. Dessa forma, apenas um único compartilhamento de arquivos do Azure na nuvem é necessário para esse grupo de compartilhamentos locais.

Fase 2: implantar recursos de armazenamento do Azure

Nessa fase, provisione as contas de armazenamento do Azure e os compartilhamentos de arquivos dentro delas.

Não esqueça que um compartilhamento de arquivos do Azure é implantado na nuvem em uma conta de armazenamento do Azure. Para compartilhamentos de arquivos HDD (padrão), essa configuração torna a conta de armazenamento um alvo de escala para métricas de desempenho como IOPS e taxa de transferência. Se você colocar vários compartilhamentos de arquivos em apenas uma conta de armazenamento, estará criando um pool compartilhado de IOPS e de taxa de transferência para esses compartilhamentos.

Como regra geral, você pode agrupar vários compartilhamentos de arquivos do Azure na mesma conta de armazenamento caso você tenha compartilhamentos de arquivamento ou espere pouca atividade diária nos compartilhamentos. No entanto, se você tem compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e aplicações), implante contas de armazenamento com um compartilhamento de arquivo cada. Essas limitações não se aplicam a contas de armazenamento do FileStorage (SSD), em que o desempenho é explicitamente provisionado e garantido para cada compartilhamento.

Observação

Há um limite de 250 contas de armazenamento por assinatura por região do Azure. Com um aumento de cota, você pode criar até 500 contas de armazenamento por região. Para obter mais informações, confira Aumentar as cotas de conta de Armazenamento do Microsoft Azure.

Outra consideração ao implantar uma conta de armazenamento é a redundância. Confira redundância de Arquivos do Azure.

Se você fizer uma lista dos seus compartilhamentos, associe cada compartilhamento à conta de armazenamento na qual você o criou.

Os nomes de seus recursos também são importantes. Por exemplo, se você agrupar múltiplos compartilhamentos do departamento de RH em uma conta de armazenamento no Azure, nomeie a conta de armazenamento adequadamente. Da mesma forma, ao nomear seus compartilhamentos de arquivos do Azure, use nomes semelhantes aos usados para seus equivalentes locais.

Agora, implante o número apropriado de contas de armazenamento do Azure com o número apropriado de compartilhamentos de arquivos do Azure neles, seguindo as instruções em Criar um compartilhamento de arquivos SMB. Na maioria dos casos, certifique-se de que a região de cada uma das suas contas de armazenamento seja a mesma.

Fase 3: determinar de quantos dispositivos do Azure Data Box você precisa

Comece essa etapa somente quando completar a fase anterior. Neste ponto, você deveria ter criado seus recursos de armazenamento no Azure, incluindo contas de armazenamento e compartilhamentos de arquivos. Durante o pedido do seu Data Box, você precisa especificar para quais contas de armazenamento o Data Box transfere os dados.

Nesta fase, mapeie os resultados do plano de migração da fase anterior até os limites das opções disponíveis de Data Box. Essas considerações ajudam você a planejar quais opções de Data Box escolher e quantas você precisa para mover seus compartilhamentos NAS para compartilhamentos de arquivos do Azure.

Para determinar quantos dispositivos de cada tipo você precisa, considere estes limites importantes:

  • Qualquer Azure Data Box pode mover dados para até 10 contas de armazenamento.
  • Cada opção de Data Box tem sua própria capacidade utilizável. Confira Opções do Data Box.

Consulte seu plano de migração para ver o número de contas de armazenamento que você decidiu criar e os compartilhamentos em cada uma. Em seguida, examine o tamanho de cada um dos compartilhamentos em seu NAS. Combinar essas informações permite que você decida qual appliance deve enviar dados para quais contas de armazenamento. Você pode fazer com que dois dispositivos Data Box movem arquivos para a mesma conta de armazenamento, mas não divida o conteúdo de um único compartilhamento de arquivos entre dois aparelhos Data Box.

Opções do Data Box

Para uma migração padrão, escolha uma ou uma combinação destas duas opções de Data Box:

  • Data Box Esta opção é a mais comum. É um appliance Data Box robusto que funciona de forma semelhante a um NAS. Ele é enviado para você com uma capacidade útil de 80 TiB. Para saber mais, confira a documentação do Data Box Disk.
  • Data Box Heavy Esta opção apresenta um dispositivo Data Box robusto sob rodas que funciona de forma semelhante a um NAS, com capacidade de 1 PiB. A capacidade utilizável é de cerca de 20% menos, devido à sobrecarga do sistema de arquivos e de criptografia. Para saber mais, confira a documentação do Data Box Heavy.

Aviso

O Data Box Disks não é recomendado para migrações para compartilhamentos de arquivos do Azure. O Data Box Disks não preserva metadados de arquivo, como ACLs (permissões de acesso) e outros atributos.

Fase 4: provisionar um Windows Server temporário

Enquanto espera seus appliances Azure Data Box chegarem, você já pode implantar um ou mais servidores Windows necessários para rodar trabalhos RoboCopy. Para requisitos de versão do sistema operacional, veja a nota importante na seção RoboCopy.

  • Use esses servidores para copiar arquivos para a Data Box.
  • Use estes servidores para acompanhar as alterações que ocorrem no aparelho NAS enquanto o Data Box está em transporte. Essa abordagem reduz ao mínimo o tempo de inatividade no lado da origem.

A velocidade com que seus trabalhos RoboCopy funcionam depende principalmente destes fatores:

Tenha em mente os detalhes referenciados ao decidir a RAM e a contagem de threads que você fornece para seu(s) Windows Server(s) temporário(s).

Fase 5: preparar para usar os compartilhamentos de arquivos do Azure

Para economizar tempo, prossiga com essa fase enquanto espera a chegada da sua Data Box. Com as informações dessa fase, você pode decidir como seus servidores e usuários podem usar seus compartilhamentos de arquivos do Azure. As decisões mais críticas são:

  • Rede: Habilite suas redes para rotear tráfego SMB.
  • Autenticação: Configure contas de armazenamento do Azure para autenticação Kerberos. O Microsoft Entra Connect e a união de domínio à sua conta de armazenamento permitem que seus aplicativos e usuários usem sua identidade AD para autenticação.
  • Autorização: ACLs em nível de compartilhamento para cada compartilhamento de arquivos do Azure permitem que usuários e grupos do AD acessem um determinado compartilhamento, e dentro de um compartilhamento de arquivos do Azure, as ACLs nativas NTFS assumem o controle. A autorização baseada em ACLs de arquivo e pasta funciona como a de compartilhamentos SMB locais.
  • Continuidade dos negócios: A integração de compartilhamentos de arquivos do Azure em um ambiente existente frequentemente envolve preservar endereços de compartilhamento existentes. Se você ainda não estiver usando DFS-Namespaces, considere estabelecer isso em seu ambiente. Você pode manter os endereços de compartilhamento que seus usuários e scripts usam inalterados. Use o DFS-N como um serviço de roteamento de namespace para SMB, redirecionando destinos de DFS-Namespace para compartilhamentos de arquivos do Azure após a migração.

Este vídeo é um guia e uma demonstração de como expor com segurança compartilhamentos de arquivos do Azure diretamente para os operadores de informações e aplicativos em cinco etapas simples.
O vídeo faz referência à documentação específica para os seguintes tópicos. Observe que o Azure Active Directory agora é Microsoft Entra ID. Para obter mais informações, consulte Novo nome para o Azure AD.

Fase 6: Copie arquivos para sua Data Box

Quando sua Data Box chegar, configure-a com conectividade de rede sem restrições para seu dispositivo NAS. Siga a documentação de configuração do tipo de Data Box que você pediu.

Dependendo do tipo de Data Box, você pode ter acesso às ferramentas de cópia do Data Box. Neste ponto, não use eles para migrações para compartilhamentos de arquivos do Azure, pois eles não copiam seus arquivos com fidelidade total para a Data Box. Em vez disso, use o RoboCopy.

Quando seu Data Box chega, ele tem compartilhamentos SMB pré-provisionados disponíveis para cada conta de armazenamento que você especificou no momento do pedido.

  • Se os seus arquivos forem para um compartilhamento de arquivos do Azure em SSD, haverá um compartilhamento SMB por conta de armazenamento "Armazenamento de arquivos" no SSD.
  • Se os seus arquivos são para uma conta de armazenamento em HDD, existem três compartilhamentos SMB por conta de armazenamento de pagamento conforme o uso no HDD. Apenas o compartilhamento de arquivos que termina em _AzFile é relevante para sua migração. Ignore quaisquer compartilhamentos de bloco e de blob de páginas.

Como o Data Box mapeia pastas para compartilhamentos de arquivos do Azure

No compartilhamento de dispositivo <storage-account-name>_AzFile, cada pasta de primeiro nível corresponde a um compartilhamento de arquivos do Azure na conta de armazenamento de destino:

  • O nome da pasta de primeiro nível torna-se o nome do compartilhamento de arquivos do Azure durante a ingestão. Se um compartilhamento com esse nome ainda não existir na conta de armazenamento de destino, o Data Box o cria. Se ele já existir, o Data Box copia os dados nesse compartilhamento existente.

  • Não copie arquivos diretamente para a raiz do _AzFile compartilhamento. Todos os dados devem estar dentro de uma pasta de primeiro nível.

  • Para um mapeamento um a um com suas compartilhamentos SMB de origem, crie uma pasta de primeiro nível para cada compartilhamento de fonte (usando o nome desejado do compartilhamento de arquivo Azure) e copie cada compartilhamento de fonte para sua pasta correspondente. Por exemplo:

    \\<DataBox-IP>\<storage-account-name>_AzFile\Share1
\\<DataBox-IP>\<storage-account-name>_AzFile\Share2
\\<DataBox-IP>\<storage-account-name>_AzFile\Share3

Para mais informações, veja Conectar à Data Box.

Siga as etapas da documentação do Azure Data Box:

  1. Conectar-se ao Data Box
  2. Copiar dados para caixa de dados
  3. Revise o arquivo de log RoboCopy em busca de erros para confirmar que todos os arquivos foram copiados com sucesso.
  4. Prepare o seu Data Box para envio ao Azure

A documentação vinculada da Data Box especifica um comando RoboCopy. No entanto, o comando não é adequado para preservar toda a fidelidade de arquivos e pastas. Esse comando usa /MT:32 porque é uma cópia local em LAN para o Data Box com latência insignificante; então, uma contagem maior de threads é mais apropriada aqui do que para a cópia de recuperação baseada em WAN na Fase 7:

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>
  • Para saber mais sobre os sinalizadores individuais do RoboCopy, confira a tabela na próxima seção RoboCopy.
  • Para saber mais sobre como dimensionar adequadamente a contagem de threads /MT:n, otimizar a velocidade do RoboCopy e tornar o RoboCopy um bom vizinho de seu data center, confira a seção Solução de problemas do RoboCopy.

Dica

Como alternativa ao RoboCopy, o Data Box oferece um serviço de cópia de dados. Ele pode ser usado para carregar arquivos em seu Data Box com fidelidade total. Siga este tutorial sobre serviço de cópia de dados e certifique-se de definir o destino correto do compartilhamento de arquivos do Azure.

Fase 7: atualizar o RoboCopy a partir do seu NAS

Depois que o Data Box informar que colocou todos os arquivos e pastas nos compartilhamentos de arquivos do Azure planejados, continue com esta fase. Você só precisará de uma atualização do RoboCopy se os dados no NAS tiverem sido alterados a partir do início da cópia do Data Box. Em determinados cenários em que você usa um compartilhamento para fins de arquivamento, você pode parar as alterações do compartilhamento no seu NAS até que a migração seja concluída. Você também pode atender aos seus requisitos de negócios definindo os compartilhamentos do NAS como somente leitura durante a migração.

Nos casos em que você precisa que um compartilhamento seja de leitura e gravação durante a migração e só disponha de uma pequena janela de inatividade, será importante concluir esta etapa de atualização do RoboCopy antes do failover do acesso do usuário diretamente no compartilhamento de arquivo do Azure.

Nessa etapa, execute tarefas do Robocopy para sincronizar seus compartilhamentos na nuvem com as alterações mais recentes no seu NAS desde o momento em que você copiou seus compartilhamentos para o Data Box. Essa atualização do RoboCopy poderá terminar rapidamente ou demorar, de acordo com a quantidade de rotatividade em seus compartilhamentos NAS.

Execute a primeira cópia local para a pasta de destino do Windows Server:

  1. Identifique o primeiro local em seu dispositivo NAS.
  2. Identifique o compartilhamento de arquivos do Azure correspondente.
  3. Monte o compartilhamento de arquivos do Azure como uma unidade de rede local em seu Windows Server temporário.
  4. Inicie a cópia usando o RoboCopy, conforme descrito.

Monte um compartilhamento de arquivos do Azure

Antes de usar o RoboCopy, você precisa tornar o compartilhamento de arquivos do Azure acessível via SMB. A maneira mais fácil é montar o compartilhamento como uma unidade de rede local para o Windows Server que você está planejando usar para o RoboCopy.

Importante

Antes de montar com êxito um compartilhamento de arquivos do Azure em um Windows Server local, você deve concluir a Fase 5: Preparando-se para usar compartilhamentos de arquivos do Azure.

Quando estiver pronto, analise o artigo Como usar um compartilhamento de arquivos do Azure com o Windows e monte o compartilhamento de arquivos do Azure em que você deseja iniciar a atualização do RoboCopy a partir do NAS.

RoboCopy

O comando RoboCopy a seguir copia apenas as diferenças (arquivos e pastas atualizados) do seu armazenamento NAS para o compartilhamento de arquivos do Azure.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Opção Significado
/MT:n Permite que o Robocopy execute multithreading. O padrão de n é 8. O máximo é 128 threads. Embora uma alta contagem de threads ajude a saturar a largura de banda disponível, isso não significa que a migração sempre será mais rápida com mais threads. Testes com os Arquivos do Azure indicam que entre 8 e 20 oferecem um desempenho equilibrado para uma execução de cópia inicial. Execuções /MIR subsequentes são afetadas progressivamente pela computação disponível vs. largura de banda de rede disponível. Para as execuções subsequentes, relacione de forma mais aproximada o valor de contagem de threads com a contagem de núcleos do processador e a contagem de threads por núcleo. Considere se os núcleos precisam ser reservados para outras tarefas que um servidor de produção possa ter. Testes com o serviço Arquivos do Azure mostraram que até 64 threads produzem um bom desempenho, mas somente se os processadores puderem mantê-los ativos ao mesmo tempo.
/R:n Contagem máxima de novas tentativas de um arquivo cuja primeira tentativa de cópia falha. O Robocopy tentará n vezes antes que o arquivo falhe permanentemente ao copiar na execução. É possível otimizar o desempenho de sua execução: escolha um valor de dois ou três se você acreditar que os problemas de tempo limite causaram falhas no passado. Isso pode ser mais comum em links de WAN. Escolha não tentar novamente ou um valor de um se você acreditar que o arquivo falhou ao copiar porque estava ativamente em uso. Tentar novamente alguns segundos depois poderá não ser tempo suficiente para que o estado em uso do arquivo seja alterado. Os usuários ou os aplicativos que mantêm o arquivo aberto podem precisar de horas a mais. Nesse caso, aceitar que o arquivo não foi copiado e capturá-lo em uma de suas execuções de Robocopy subsequentes planejadas, pode conseguir eventualmente copiar o arquivo com êxito. Isso ajuda a execução atual a concluir mais rapidamente sem ser prolongada pelo excesso de tentativas que, basicamente, resulta na maioria das falhas de cópia devido a arquivos ainda abertos após o tempo limite de repetição.
/W:n Especifica o tempo que o Robocopy espera para tentar copiar um arquivo que não foi copiado com êxito em uma tentativa anterior. n é o número de segundos a aguardar entre novas tentativas. /W:n é frequentemente usado junto com /R:n.
/B Executa o Robocopy do mesmo modo que um aplicativo de backup faria. Essa opção permite que o Robocopy mova arquivos para os quais o usuário atual não tem permissões. A opção de backup depende da execução do comando do Robocopy em um console elevado de administrador ou janela do PowerShell. Se você usa o Robocopy para Arquivos do Azure, certifique-se de montar o compartilhamento de arquivos do Azure usando a chave de acesso da conta de armazenamento em vez de uma identidade de domínio. Caso contrário, as mensagens de erro podem não levar intuitivamente a uma resolução do problema.
/MIR (Espelhar a origem para o destino.) Permite que o Robocopy copie apenas os deltas entre a origem e o destino. Subdiretórios vazios serão copiados. Itens (arquivos ou pastas) que foram alterados ou que não existem no destino serão copiados. Os itens que existem no destino, mas não na origem, serão eliminados (excluídos) do destino. Ao usar essa opção, faça a correspondência exata das estruturas de pasta de origem e de destino. Correspondência significa copiar da origem e pasta corretas para a pasta correspondente no destino. Somente dessa maneira uma cópia "atualizada" pode ser bem-sucedida. Quando a origem e o destino não corresponderem, o uso de /MIR causará exclusões e novas cópias em grande escala.
/IT Garante que a fidelidade seja preservada em determinados cenários de espelhamento.
Por exemplo, se um arquivo sofrer uma alteração na ACL e uma atualização de atributo entre duas execuções do Robocopy, ele será marcado como oculto. Sem /IT, a alteração de ACL pode não ser percebida pelo Robocopy e não ser transferida para o local de destino.
/COPY:[copyflags] A fidelidade da cópia do arquivo. Padrão: /COPY:DAT. Sinalizadores de cópia: D = Dados, A = Atributos, T = Carimbos de data/hora, S = Segurança = NTFS ACLs, O = Informações do proprietário, U = Informações de auditoria. As informações de auditoria não podem ser armazenadas em um compartilhamento de arquivo do Azure.
/DCOPY:[copyflags] Fidelidade da cópia de diretórios. Padrão: /DCOPY:DA. Sinalizadores de cópia: D = Dados, A = Atributos, = T Carimbos de data/hora.
/NP Especifica que não será exibido o progresso da cópia de cada arquivo e pasta. A exibição do progresso reduz significativamente o desempenho da cópia.
/NFL Especifica que os nomes de arquivo não são registrados. Melhora o desempenho da cópia.
/NDL Especifica que os nomes de diretório não são registrados. Melhora o desempenho da cópia.
/XD Especifica os diretórios a serem excluídos. Ao executar o Robocopy na raiz de um volume, considere excluir a pasta System Volume Information oculta. Se usado conforme projetado, todas as informações serão específicas para o volume exato desse sistema exato e poderão ser reconstruídas sob demanda. Copiar essas informações não ajuda na nuvem nem quando os dados são copiados de volta para outro volume do Windows. Deixar esse conteúdo para trás não é perda de dados.
/UNILOG:<file name> Grava o status no arquivo de log como Unicode. (Substitui o log existente.)
/L Somente para uma execução de teste
Os arquivos devem ser apenas listados. Eles não serão copiados, não excluídos e não terão carimbo de data/hora. Usado com frequência com /TEE para saída do console. Os sinalizadores do script de exemplo, como /NP, /NFL e /NDL, talvez precisem ser removidos para que você possa obter os resultados de teste documentados corretamente.
/Z Usar com cautela
Copia os arquivos no modo de reinicialização. Essa opção é recomendada somente em um ambiente de rede instável. Ela reduz significativamente o desempenho da cópia devido ao registro em log extra.
/ZB Usar com cautela
Usa o modo de reinicialização. Se o acesso for negado, esta opção usa o modo backup. Essa opção reduz significativamente o desempenho da cópia devido ao ponto de verificação.

Importante

Se possível, use o Windows Server 2022 ou versões posteriores. Ao usar Windows Server 2019, certifique-se de que o nível mais recente do patch ou pelo menos o KB5005103 de atualização do sistema operacional esteja instalado. Ele contém correções importantes para determinados cenários do Robocopy.

Dica

Consulte a seção de Solução de Problemas se o RoboCopy estiver afetando seu ambiente de produção, relatando muitos erros ou não estiver progredindo tão rápido quanto o esperado.

Migração do usuário

Quando você executa o comando do RoboCopy pela primeira vez, seus usuários e aplicativos ainda estão acessando os arquivos no NAS e possivelmente os alteram. É possível que o RoboCopy tenha processado um diretório, passe para o próximo e, em seguida, um usuário no local de origem (NAS) adicione, altere ou exclua um arquivo que agora não será processado nesta execução do RoboCopy. O comportamento é esperado.

A primeira execução é feita para movimentação em massa dos dados alterados para o compartilhamento de arquivos do Azure. Esta cópia inicial pode demorar. Confira a seção de Solução de problemas para obter mais informações sobre o que pode afetar as velocidades do RoboCopy.

Após a primeira execução, execute o comando novamente.

Na segunda vez que você executa o RoboCopy para o mesmo compartilhamento, ele termina mais rápido, porque só precisa copiar as alterações que ocorreram desde a última execução. Você pode executar os trabalhos várias vezes para o mesmo compartilhamento.

O tempo de inatividade sendo aceitável, você precisa remover o acesso dos usuários aos seus compartilhamentos no NAS. Você pode fazer isso em qualquer etapa para impedir que os usuários alterarem o conteúdo e a estrutura dos arquivos e pastas. Um exemplo é apontar seu DFS-Namespace para um local não existente ou alterar as ACLs raiz no compartilhamento.

Execute uma última rodada do RoboCopy. Ele capta quaisquer mudanças que possam ter sido ignoradas. A duração desta etapa final depende da velocidade da verificação do RoboCopy. Você pode estimar o tempo (que é igual ao seu tempo de indisponibilidade) medindo quanto tempo a execução anterior levou.

Crie um compartilhamento na pasta do Windows Server e ajuste sua implantação do DFS-N para apontar para ele. Não esqueça de definir as mesmas permissões de nível de compartilhamento que estão em seu compartilhamento SMB do NAS. Se você tiver um NAS de classe corporativa conectado ao domínio, os SIDs do usuário correspondem automaticamente aos usuários existentes no Active Directory, e o RoboCopy copia arquivos e metadados com total fidelidade. Se você usou usuários locais em seu NAS, precisa recriar esses usuários como usuários locais do Windows Server, e mapear os SIDs existentes que o RoboCopy moveu para o Windows Server para os SIDs dos novos usuários locais do Windows Server.

Você concluiu a migração de um compartilhamento ou grupo de compartilhamentos para um volume ou raiz comum.

Tente executar algumas dessas cópias em paralelo. Processe o escopo de um compartilhamento de arquivos do Azure por vez.

Solucionar problemas

A velocidade e a taxa de sucesso de uma execução RoboCopy dependem de vários fatores:

  • IOPS no armazenamento da origem e do destino
  • a largura de banda de rede disponível entre a origem e o destino
  • a capacidade de processar rapidamente arquivos e pastas em um namespace
  • o número de alterações entre as execuções do RoboCopy
  • o tamanho e o número de arquivos que você precisa copiar

Considerações sobre IOPS e largura de banda

Nessa categoria, você precisa considerar as capacidades do armazenamento de origem, do armazenamento de destinoe da rede que os conecta. A taxa de transferência máxima possível é determinada pelos três componentes mais lentos. Verifique se sua infraestrutura de rede está configurada para dar suporte a velocidades de transferência ideais em suas melhores capacidades.

Atenção

Embora copiar o mais rápido possível seja geralmente o mais desejável, considere utilizar sua rede local e o dispositivo NAS para outras tarefas, muitas vezes essenciais para os negócios.

Copiar o mais rápido possível pode não ser desejável quando há um risco de que a migração possa monopolizar os recursos disponíveis.

  • Considere quando é melhor executar migrações em seu ambiente: durante o dia, fora do horário de expediente ou durante os fins de semana.
  • Considere também a rede QoS em um Windows Server para limitar a velocidade do RoboCopy.
  • Evite o trabalho desnecessário para as ferramentas de migração.

O RoboCopy pode inserir atrasos entre pacotes especificando a opção /IPG:n, em que n é medido em milissegundos entre os pacotes do RoboCopy. Usar essa opção pode ajudar a evitar a monopolização de recursos tanto em dispositivos limitados por E/S quanto em links de rede congestionados.

/IPG:n não pode ser usado para limitar com precisão a velocidade da rede a um determinado valor em Mbps. Em vez disso, use a QoS de rede do Windows Server. O RoboCopy conta totalmente com o protocolo SMB para todas as necessidades de rede. Usar o SMB é o motivo pelo qual o RoboCopy não pode influenciar a taxa de transferência da rede em si, mas pode retardar seu uso.

Uma linha de pensamento semelhante se aplica ao IOPS observado no NAS. O tamanho do cluster no volume do NAS, os tamanhos de pacotes e uma série de outros fatores influenciam o IOPS observado. A introdução do atraso entre pacotes geralmente é a maneira mais fácil de controlar a carga no NAS. Teste vários valores, como valores entre cerca de 20 milissegundos (n=20) e múltiplos desse valor. Depois de introduzir um atraso, você pode avaliar se seus outros aplicativos agora funcionam como esperado. Essa estratégia de otimização ajuda você a encontrar a velocidade ideal do RoboCopy no seu ambiente.

Velocidade de processamento

O RoboCopy percorre o namespace que você especifica e avalia cada arquivo e pasta para cópia. Ele avalia cada arquivo durante uma cópia inicial e durante cópias de recuperação. Por exemplo, execuções repetidas de RoboCopy /MIR nos mesmos locais de armazenamento de origem e destino. Essas execuções repetidas minimizam o tempo de inatividade para usuários e aplicativos, e melhoram a taxa geral de sucesso dos arquivos migrados.

A largura de banda é frequentemente considerada o fator mais limitante em uma migração, e isso pode ser verdade. Mas a capacidade de enumerar um namespace pode influenciar no tempo total para copiar ainda mais para namespaces maiores com arquivos menores. Considere que copiar 1 TiB de arquivos pequenos leva consideravelmente mais tempo do que copiar 1 TiB de arquivos menores, mas maiores, assumindo que todas as outras variáveis permaneçam iguais. Portanto, você poderá ter uma transferência lenta se estiver migrando um grande número de arquivos pequenos. Essa diferença é esperada.

A causa dessa diferença é a capacidade de processamento necessária para percorrer um namespace. O RoboCopy dá suporte a cópias em vários threads por meio do parâmetro /MT:n, em que n significa o número de threads a serem usados. Portanto, ao provisionar um computador especificamente para o RoboCopy, considere o número de núcleos de processador e sua relação com a contagem de threads que eles fornecem. O mais comum são dois threads por núcleo. O núcleo e a contagem de threads de um computador são pontos de dados importantes para decidir quais valores de vários threads /MT:n devem ser especificados. Considere também quantos trabalhos do RoboCopy você planeja executar em paralelo em um determinado computador.

Com mais threads, o exemplo de 1 TiB de arquivos pequenos é copiado consideravelmente mais rápido do que com menos threads. Ao mesmo tempo, o investimento extra de recursos no 1 TiB de arquivos maiores pode não gerar benefícios proporcionais. Uma alta contagem de threads tenta copiar mais arquivos grandes pela rede ao mesmo tempo. Essa atividade extra de rede aumenta a probabilidade de se restringir pela taxa de transferência ou pelo IOPS de armazenamento.

Durante um primeiro RoboCopy em um destino vazio ou em uma execução diferencial com muitos arquivos alterados, você provavelmente será restringido pela taxa de transferência de rede. Comece com uma alta contagem de threads para uma execução inicial. Uma alta contagem de threads, mesmo além dos threads disponíveis no momento no computador, ajuda a saturar a largura de banda de rede disponível. As execuções /MIR subsequentes são impactadas progressivamente pelo processamento de itens. Menos alterações em uma execução diferencial significam menos transporte de dados pela rede. Sua velocidade agora é mais dependente de sua capacidade de processar itens de namespace do que movê-los no link de rede. Para as execuções subsequentes, relacione o valor de contagem de threads com a contagem de núcleos do processador e a contagem de threads por núcleo. Pondere se os núcleos precisam ser reservados para outras tarefas que um servidor de produção possa ter.

Dica

Regra geral: o provisionamento em excesso da contagem de threads (/MT:n) é útil para a primeira execução do RoboCopy, que vai transferir muitos dados de uma rede de maior latência. As execuções seguintes terão menos dados diferentes a copiar, e é mais provável que você queira alterar de taxa de transferência de rede restrita para computação restrita. Nessas circunstâncias, geralmente é melhor corresponder a contagem de threads do RoboCopy aos threads disponíveis de fato no computador. O excesso de provisionamento nesse cenário pode levar a mais mudanças de contexto no processador, e provavelmente vai retardar a cópia.

Evitar trabalho desnecessário

Evite alterações em grande escala em seu namespace. Por exemplo, mover arquivos entre diretórios, alterar propriedades em grande escala ou alterar permissões (ACLs de NTFS). As alterações de ACL, especialmente, podem ter um alto impacto, porque elas têm em geral um efeito de alteração em cascata em arquivos inferiores na hierarquia de pastas. As consequências podem ser:

  • tempo de execução do trabalho do RoboCopy estendido porque cada arquivo e pasta afetados por uma alteração de ACL precisam ser atualizados
  • o reuso de dados movidos antes deve precisar ser copiado novamente. Por exemplo, mais dados precisam ser copiados quando as estruturas das pastas mudam após os arquivos já terem sido copiados. Um trabalho de RoboCopy não pode "reproduzir" uma alteração de namespace. O próximo trabalho deve limpar os arquivos transportados anteriormente para a estrutura de pastas antiga e carregar os arquivos na nova estrutura de pastas mais uma vez.

Outro aspecto importante é usar a ferramenta RoboCopy com eficiência. Usando o script recomendado do RoboCopy, você cria e salva um arquivo de log para erros. Erros de cópia podem ocorrer e isso é normal. Esses erros geralmente tornam necessário executar várias vezes uma ferramenta de cópia, como o RoboCopy. Por exemplo, uma execução inicial, digamos de um NAS para Data Box ou de um servidor para um compartilhamento de arquivos do Azure, e uma ou mais execuções extras com o /MIR switch para capturar e tentar novamente arquivos que não foram copiados.

Esteja preparado para rodar várias rodadas de RoboCopy contra um determinado escopo de namespace. Execuções sucessivas terminam mais rápido, pois têm menos para copiar, mas são cada vez mais limitadas pela velocidade de processamento do namespace. Quando você executa várias vezes, é possível acelerar cada rodada fazendo com que o RoboCopy não tente copiar tudo em uma determinada execução. Essas opções do RoboCopy podem fazer uma diferença significativa:

  • /R:n n = quantas vezes você tenta copiar um arquivo com falha e
  • /W:n n = quantos segundos esperar entre as novas tentativas

/R:5 /W:5 é uma configuração razoável que você pode ajustar de acordo com sua sua preferência. Neste exemplo, um arquivo com falha será repetido cinco vezes, com tempo de espera de cinco segundos entre as repetições. Se o arquivo ainda não for copiado, o próximo trabalho do RoboCopy tentará novamente. Muitas vezes, os arquivos que falharam porque estão em uso ou devido a problemas de tempo limite podem eventualmente ser copiados com êxito dessa maneira.

Consulte também

  • Last updated on