Use a Data Box para migrar do Armazenamento Ligado à Rede (NAS) para partilhas de ficheiros do Azure

✔️ Aplica-se a: Partilhas de ficheiros SMB clássicas criadas com o fornecedor de recursos Microsoft.Storage

✖️ Não se aplica a: Todas as partilhas de ficheiros NFS, incluindo as partilhas de ficheiros criadas com o fornecedor de recursos Microsoft.FileShares ou as partilhas de ficheiros clássicas criadas com o fornecedor de recursos Microsoft.Storage

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

  • Fonte de dados: Network Attached Storage (NAS)
  • Rota de migração: NAS ⇒ Data Box ⇒ Azure partilha de ficheiros
  • Sem armazenamento em cache de arquivos no local: como o objetivo final é usar os compartilhamentos de arquivos do Azure diretamente na nuvem, não há nenhum plano para usar o Azure File Sync.

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

Nota

O Data Box suporta o NFS como protocolo de cópia, por isso pode usá-lo para copiar dados de um NAS que serve o NFS. No entanto, o Data Box não suporta importar dados diretamente para partilhas de ficheiros do NFS Azure. Este guia cobre apenas os alvos de partilha de ficheiros SMB.

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

Objetivos 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. Este último requer manter o tempo de inatividade a um mínimo, para que possa caber ou apenas exceder ligeiramente as janelas de manutenção regulares.

Descrição geral da migração

O processo de migração consiste em várias fases. Primeiro, implemente contas de armazenamento Azure e partilhas de ficheiros e configure a rede. Depois, migre os seus ficheiros usando o Azure Data Box e o RoboCopy para acompanhar as mudanças. Por fim, migre os seus utilizadores e aplicações para as partilhas de ficheiros do Azure recentemente criadas. As seções a seguir descrevem as fases do processo de migração em detalhes.

Gorjeta

Se estiver a voltar a este artigo, use a navegação à direita para ir para a fase de migração onde parou.

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

Determina quantas partilhas de ficheiros Azure precisas. Você pode ter mais pastas em seus volumes que você atualmente compartilha localmente como compartilhamentos SMB para seus usuários e aplicativos. Dependendo do número de partilhas de ficheiros que queres migrar para a cloud, escolhe um mapeamento um-para-um ou um agrupamento de partilhas.

Usar um mapeamento 1:1

Se tiver um pequeno número de partilhas, use um mapeamento um-para-um. A forma mais fácil de visualizar este cenário é conceber uma partilha no local que tenha uma correspondência de um para um com uma partilha de ficheiros do Azure.

Usar agrupamento de compartilhamento

Se você tiver um grande número de compartilhamentos de arquivos, considere o agrupamento de compartilhamentos. Por exemplo, se o seu departamento de recursos humanos (RH) tiver 15 compartilhamentos, você pode considerar armazenar todos os dados de RH em um único compartilhamento de arquivos 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

Nesta fase, provisione as contas de armazenamento do Azure e as partilhas de ficheiros dentro delas.

Lembre-se de que um compartilhamento de arquivos do Azure é implantado na nuvem em uma conta de armazenamento do Azure. Para partilhas de ficheiros HDD (padrão), essa disposição torna a conta de armazenamento um alvo de escala para números de desempenho como IOPS e taxa de transferência. Se você colocar vários compartilhamentos de arquivos em uma única conta de armazenamento, estará criando um pool compartilhado de IOPS e 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 se tiver compartilhamentos de arquivamento ou se esperar baixa atividade diária neles. No entanto, se tiver partilhas altamente ativas (partilhas usadas por muitos utilizadores e aplicações), implemente contas de armazenamento com uma partilha de ficheiros cada. Estas limitações não se aplicam às contas de armazenamento FileStorage (SSD), onde o desempenho é explicitamente provisionado e garantido para cada partilha.

Nota

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, consulte Aumentar as cotas da conta de Armazenamento do Azure.

Outra consideração ao implantar uma conta de armazenamento é a redundância. Consulte Redundância do Ficheiros do Azure.

Se fizeres uma lista das tuas partilhas, mapeia cada partilha para a conta de armazenamento onde a crias.

Os nomes dos seus recursos também são importantes. Por exemplo, se agrupares múltiplas partilhas do departamento de RH numa conta de armazenamento no Azure, nomeia a conta de armazenamento de forma adequada. De forma semelhante, ao nomear as suas partilhas de ficheiros Azure, use nomes semelhantes aos usados nos 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 nelas, 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 é a mesma.

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

Começa este passo apenas quando completares a fase anterior. Neste ponto, deverias ter criado os teus recursos de armazenamento no Azure, incluindo contas de armazenamento e partilhas de ficheiros. Durante a sua encomenda da Data Box, precisa de especificar para que contas de armazenamento a Data Box transfere os dados.

Nesta fase, mapear os resultados do plano de migração da fase anterior para os limites das opções disponíveis de Data Box. Estas considerações ajudam-no a planear que opções de Data Box escolher e quantas precisa para mover as suas partilhas NAS para partilhas de ficheiros Azure.

Para determinar quantos dispositivos de que 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 a sua própria capacidade utilizável. Consulte Opções da Caixa de Dados.

Consulte o seu plano de migração para saber o número de contas de armazenamento que decidiu criar e as partilhas em cada uma. Em seguida, observe o tamanho de cada uma das partilhas no seu NAS. Combinar esta informação permite-lhe decidir qual o dispositivo que deve enviar dados para que contas de armazenamento. Pode ter dois dispositivos Data Box a mover ficheiros para a mesma conta de armazenamento, mas não divida o conteúdo de uma única partilha de ficheiros entre dois dispositivos 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. É enviado para si com uma capacidade útil de 80 TiB. Para obter mais informações, consulte a documentação do Data Box.
  • Data Box Heavy Esta opção inclui um dispositivo Data Box robusto sobre rodas que funciona de forma semelhante a um NAS, com uma capacidade de 1 PiB. A capacidade utilizável é cerca de 20% menor, devido à criptografia e sobrecarga do sistema de arquivos. Para obter mais informações, consulte a documentação do Data Box Heavy.

Aviso

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

Fase 4: Provisionar um Windows Server temporário

Enquanto espera que os seus dispositivos Azure Data Box cheguem, já pode instalar um ou mais servidores Windows Server dos quais necessita para executar tarefas do RoboCopy. Para requisitos de versão do sistema operativo, consulte a nota importante na secção RoboCopy.

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

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

Tenha em mente os detalhes mencionados ao decidir quanta RAM e quantas threads atribuir aos seus servidores Windows temporários.

Fase 5: Preparando-se para usar compartilhamentos de arquivos do Azure

Para poupar tempo, prossiga com esta fase enquanto espera que a sua Data Box chegue. Com a informação desta fase, pode decidir como os seus servidores e utilizadores podem usar as suas partilhas de ficheiros no Azure. As decisões mais críticas são:

  • Rede: permita que suas redes roteiem o tráfego SMB.
  • Autenticação: configure as contas de armazenamento do Azure para autenticação Kerberos. O Microsoft Entra Connect e a união ao domínio da sua conta de armazenamento permitem que as suas aplicações e utilizadores usem a sua identidade AD para autenticação.
  • Autorização: As ACLs ao nível de partilha para cada partilha de ficheiros Azure permitem que utilizadores e grupos AD acedam a uma determinada partilha, e dentro de uma partilha de ficheiros Azure, as ACLs NTFS nativas assumem o controlo. A autorização baseada em ACLs de arquivos e pastas funciona, assim como ocorre para partilhas SMB no local.
  • Continuidade do negócio: A integração de partilhas de ficheiros Azure num ambiente existente envolve frequentemente a preservação de endereços de partilha existentes. Se ainda não estás a usar DFS-Namespaces, considera estabelecer isso no teu ambiente. Podes manter os endereços de partilha que os teus utilizadores e scripts usam inalterados. Você usaria o DFS-N como um serviço de roteamento de namespace para SMB, redirecionando destinos DFS-Namespace para compartilhamentos de arquivos do Azure após sua migração.

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

Fase 6: Copiar ficheiros para a sua Data Box

Quando a sua Data Box chegar, configure-a com conectividade de rede sem restrições ao seu equipamento NAS. Siga a documentação de configuração do tipo de Data Box que encomendou.

Dependendo do tipo de Data Box, poderá ter acesso às ferramentas de cópia do Data Box. Neste momento, não os uses para migrações para partilhas de ficheiros do Azure, pois não copiam os teus ficheiros com total fidelidade para a Data Box. Em vez disso, use o RoboCopy.

Quando a sua Data Box chega, tem partilhas SMB pré-provisionadas disponíveis para cada conta de armazenamento que especificou no momento da encomenda.

  • Se os seus ficheiros forem colocados numa partilha de ficheiros do Azure em SSD, existe uma partilha SMB por cada conta de armazenamento SSD "File storage".
  • Se os seus ficheiros ficarem armazenados numa conta de armazenamento em HDD, existem três partilhas SMB por cada conta de armazenamento em HDD de pagamento consoante a utilização. Só a partilha de ficheiros que termina em _AzFile é relevante para a sua migração. Ignore qualquer bloco e compartilhamento de blob de página.

Como o Data Box mapeia pastas para partilhas de ficheiros no Azure

Na partilha de dispositivos <storage-account-name>_AzFile, cada pasta de primeiro nível corresponde a uma partilha de ficheiros do Azure na conta de armazenamento de destino:

  • O nome da pasta de primeiro nível torna-se o nome da partilha de ficheiros do Azure durante a ingestão. Se uma partilha com esse nome ainda não existir na conta de armazenamento alvo, a Data Box cria-a. Se existir, o Data Box copia os dados para essa partilha existente.

  • Não copie ficheiros diretamente para a raiz da _AzFile partilha. Todos os dados devem ir para uma pasta de primeiro nível.

  • Para um mapeamento um-para-um com as suas partilhas SMB de origem, crie uma pasta de primeiro nível para cada partilha de origem (usando o nome desejado de partilha de ficheiros Azure) e copie cada partilha de origem para a 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, consulte Ligar à Caixa de Dados.

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

  1. Conectar-se ao Data Box
  2. Copiar dados para o Data Box
  3. Revise o ficheiro de registo RoboCopy para encontrar erros e confirmar que todos os ficheiros foram copiados com sucesso.
  4. Prepare a sua Data Box para partir para o Azure

A documentação associada do Data Box especifica um comando RoboCopy. No entanto, o comando não é adequado para preservar toda a fidelidade dos ficheiros e pastas. Este comando é usado /MT:32 porque é uma cópia local em LAN para a Data Box com latência negligenciável, por isso um número de threads mais elevado é apropriado 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 detalhes dos sinalizadores RoboCopy individuais, consulte a tabela na próxima Seção RoboCopy.
  • Para saber mais sobre como dimensionar adequadamente a contagem /MT:nde threads, otimizar a velocidade do RoboCopy e tornar o RoboCopy um bom vizinho em seu data center, consulte a seção de solução de problemas do RoboCopy.

Gorjeta

Como alternativa ao RoboCopy, o Data Box fornece um serviço de cópia de dados. Pode utilizar este serviço para carregar ficheiros na sua Data Box com total fidelidade. Siga este tutorial do serviço de cópia de dados e certifique-se de definir o destino correto de compartilhamento de arquivos do Azure.

Fase 7: Recuperar o RoboCopy do seu NAS

Depois de a sua Data Box reportar que colocou todos os ficheiros e pastas nas partilhas de ficheiros Azure planeadas, continue com esta fase. Só precisas de um RoboCopy de recuperação se os dados no NAS puderem ter mudado desde que a cópia da Data Box começou. Em determinados cenários em que você usa um compartilhamento para fins de arquivamento, talvez seja possível interromper as alterações no compartilhamento em seu NAS até que a migração seja concluída. Você também pode ter a capacidade de atender aos seus requisitos de negócios definindo compartilhamentos NAS como somente leitura durante a migração.

Nos casos em que precisa que uma partilha esteja em modo de leitura e escrita durante a migração e só pode tolerar uma pequena janela de indisponibilidade, é importante concluir este passo de sincronização final com o RoboCopy antes da comutação do acesso dos utilizadores diretamente para a partilha de ficheiros do Azure.

Neste passo, execute tarefas do Robocopy para atualizar as suas partilhas na cloud com as alterações mais recentes no seu NAS desde o momento em que copiou as suas partilhas para a Data Box. Este RoboCopy de atualização pode terminar rapidamente ou demorar algum tempo, dependendo da quantidade de alterações que ocorreram nas suas partilhas 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. Monta a partilha de ficheiros Azure como um disco de rede local no teu Windows Server temporário.
  4. Inicie a cópia usando o RoboCopy conforme descrito.

Montando um compartilhamento de arquivos do Azure

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

Importante

Antes de conseguir montar com sucesso uma partilha de ficheiros Azure num Windows Server local, deve completar a Fase 5: Preparação para usar partilhas de ficheiros Azure.

Quando estiveres pronto, consulta o artigo de procedimentos "Utilizar uma partilha de ficheiros do Azure com o Windows" e monta a partilha de ficheiros do Azure para a qual pretendes iniciar o RoboCopy catch-up do NAS.

RoboCopy

O comando RoboCopy seguinte copia apenas as diferenças (ficheiros e pastas atualizados) do armazenamento NAS para a partilha de ficheiros 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>
Comutador Significado
/MT:n Permite ao Robocopy ser executado com vários threads. O padrão para n é 8. O máximo é de 128 threads. Embora uma alta contagem de threads ajude a saturar a largura de banda disponível, isso não significa que sua migração será sempre mais rápida com mais threads. Os testes com os Arquivos do Azure indicam que entre 8 e 20 mostram um desempenho equilibrado para uma execução de cópia inicial. As execuções subsequentes /MIR são progressivamente afetadas pela disponibilidade de computação em comparação com a largura de banda de rede disponível. Nas execuções subsequentes, ajuste o valor da contagem de threads para que fique mais próximo do número de núcleos do processador e do número de threads por núcleo. Considere se os núcleos precisam de ser reservados para outras tarefas que um servidor de produção possa ter. Testes com Arquivos do Azure mostraram que até 64 threads produzem um bom desempenho, mas somente se seus processadores puderem mantê-los ativos ao mesmo tempo.
/R:n Contagem máxima de novas tentativas para um ficheiro cuja cópia falhou na primeira tentativa. O Robocopy tentará n vezes antes que o ficheiro falhe definitivamente na cópia durante a execução. Você pode otimizar o desempenho de sua execução: escolha um valor de dois ou três se acreditar que problemas de tempo limite causaram falhas no passado. Isso pode ser mais comum em links WAN. Não escolha tentar novamente ou um valor de 1 se acreditar que o ficheiro não conseguiu ser copiado porque estava em uso ativo. Tentar novamente alguns segundos depois pode não ser tempo suficiente para que o estado em uso do arquivo mude. Os usuários ou aplicativos que mantêm o arquivo aberto podem precisar de horas a mais de tempo. Nesse caso, aceitar que o arquivo não foi copiado e capturá-lo em uma de suas execuções subsequentes planejadas do Robocopy pode ter sucesso em eventualmente copiar o arquivo com sucesso. Isso ajuda a execução atual a terminar mais rapidamente sem ser prolongada por muitas tentativas que, em última análise, acabam numa maioria de falhas de cópia devido a arquivos ainda abertos após o tempo limite de tentativa.
/W:n Especifica o tempo que o Robocopy aguarda antes de tentar copiar um ficheiro que não foi copiado com êxito na tentativa anterior. n é o número de segundos de espera entre as tentativas. /W:n é frequentemente utilizado em conjunto com /R:n.
/B Executa o Robocopy no mesmo modo que uma aplicação de cópia de segurança utilizaria. Esta opção permite que o Robocopy mova os ficheiros para os quais o atual utilizador não tem permissões. A opção de backup depende da execução do comando Robocopy em um console elevado do administrador ou em uma janela do PowerShell. Se usares o Robocopy para Ficheiros do Azure, certifica-te de montar a partilha de ficheiros do Azure usando a chave de acesso à conta de armazenamento em vez de uma identidade de domínio. Se não o fizer, as mensagens de erro poderão não o levar intuitivamente a uma resolução do problema.
/MIR (Espelhar origem para destino.) Permite que o Robocopy copie apenas os detalhes entre a origem e o destino. Os subdiretórios vazios serão copiados. Os itens (ficheiros ou pastas) que tenham sido alterados ou não existam no destino serão copiados. Os itens que existam no destino, mas não na origem, serão removidos (eliminados) do destino. Quando utilizar esta opção, faça corresponder exatamente as estruturas das pastas de origem e de destino. Correspondente significa copiar do nível e pasta de origem corretos para o nível correspondente da pasta no destino pretendido. Só, assim, é que uma cópia “atualizada” pode ter êxito. Quando a origem e o destino são incompatíveis, o uso /MIR levará a exclusões e recópias em grande escala.
/IT Garante que a fidelidade é preservada em determinados cenários de espelhamento.
Por exemplo, se um arquivo tiver uma alteração de ACL e uma atualização de atributo entre duas execuções do Robocopy, ele será marcado como oculto. Sem /ITo, a alteração de ACL pode ser ignorada pelo Robocopy e não transferida para o local de destino.
/COPY:[copyflags] A fidelidade da cópia do ficheiro. Padrão: /COPY:DAT. Sinalizadores de cópia: D= Dados, A= Atributos, T= Carimbos de data/hora, S= Segurança = ACLs NTFS, O= Informações do proprietário, U= Auditing information. As informações de auditoria não podem ser armazenadas numa partilha de ficheiros do Azure.
/DCOPY:[copyflags] Fidelidade na 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 o progresso da cópia de cada ficheiro e pasta não será apresentado. A apresentação do progresso reduz significativamente o desempenho da operação de cópia.
/NFL Especifica que os nomes de ficheiro não estão registados. Melhora o desempenho da cópia.
/NDL Especifica que os nomes de diretório não estão registados. 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 oculta System Volume Information . Se utilizado conforme o projeto, toda a informação presente é específica para o volume exato neste sistema exato e pode ser reconstruída a pedido. Copiar esta informação não é útil na cloud nem quando os dados são alguma vez copiados de volta para outro volume do Windows. Deixar este 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 listados somente. Não serão copiados, nem eliminados e não terão nenhum carimbo de data/hora. Muitas vezes usado com /TEE para saída de console. Os sinalizadores do script de exemplo, como /NP, /NFLe /NDL, podem precisar ser removidos para obter resultados de teste devidamente documentados.
/Z Use com cautela
Copia arquivos no modo de reinicialização. Esta opção só é recomendada num ambiente de rede instável. Reduz significativamente o desempenho ao copiar devido aos registos extra.
/ZB Use com cautela
Usa o modo de reinicialização. Se o acesso for negado, esta opção utilizará o modo de cópia de segurança. Esta opção reduz significativamente o desempenho da cópia devido aos pontos de verificação.

Importante

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

Gorjeta

Consulte a secção Solução de Problemas se o RoboCopy estiver a afetar o seu ambiente de produção, relatar muitos erros ou não estiver a progredir tão rápido quanto o esperado.

Transição de utilizadores

Quando você executa o comando RoboCopy pela primeira vez, seus usuários e aplicativos ainda estão acessando arquivos no NAS e potencialmente 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 atual do RoboCopy. Este comportamento é esperado.

A primeira execução consiste em mover a maior parte dos dados processados para o seu compartilhamento de arquivos do Azure. Esta primeira cópia pode demorar um pouco. Consulte a secção Resolução de problemas para obter mais informações sobre o que pode afetar as velocidades do RoboCopy.

Depois da primeira execução, execute novamente o comando.

Na segunda vez que executas o RoboCopy para a mesma partilha, termina mais rapidamente, porque só precisa de transferir as alterações que ocorreram desde a última execução. Você pode executar tarefas repetidas para o mesmo compartilhamento.

Quando você considera o tempo de inatividade aceitável, então você precisa remover o acesso do usuário aos seus compartilhamentos baseados em NAS. Você pode fazer isso por qualquer etapa que impeça os usuários de alterar a estrutura e o conteúdo de 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. Detecta quaisquer alterações que possam ter sido ignoradas. O tempo que esta etapa final demora depende da velocidade da verificação do RoboCopy. Você pode estimar o tempo (que é igual ao seu tempo de inatividade) medindo quanto tempo a execução anterior levou.

Crie um compartilhamento na pasta do Windows Server e, possivelmente, ajuste sua implantação do DFS-N para apontar para ele. Certifique-se de definir as mesmas permissões de nível de compartilhamento que em seu compartilhamento SMB NAS. Se tivesse um NAS de classe empresarial ligado a um domínio, visto que os utilizadores existem no Active Directory, os SIDs de utilizador corresponderão automaticamente e o Robocopy copia os arquivos e metadados com fidelidade total. Se você tiver usado usuários locais em seu NAS, precisará recriar esses usuários como usuários locais do Windows Server e mapear os SIDs existentes RoboCopy movidos para o Windows Server para os SIDs de seus novos usuários locais do Windows Server.

Terminou de migrar uma partilha ou grupo de partilhas para uma raiz ou volume comum.

Você pode tentar executar algumas dessas cópias em paralelo. Processe o âmbito de uma partilha de ficheiros do Azure de cada vez.

Resolver problemas

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

  • IOPS no armazenamento de origem e de 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

Nesta categoria, você precisa considerar as habilidades do armazenamento de origem, do armazenamento de destino e da rede que os conecta. O rendimento máximo possível é determinado pelo mais lento destes três componentes. Certifique-se de que a sua infraestrutura de rede está configurada para suportar velocidades de transferência ideais para as suas melhores capacidades.

Atenção

Embora copiar o mais rápido possível seja muitas vezes mais desejável, considere a utilização de sua rede local e dispositivo NAS para outras tarefas, muitas vezes críticas para os negócios.

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

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

RoboCopy pode inserir atrasos entre pacotes especificando o comutador /IPG:n, onde o n é medido em milissegundos entre pacotes RoboCopy. A utilização deste switch pode ajudar a evitar a monopolização dos recursos tanto em dispositivos com restrição de I/O como em ligações de rede saturadas.

/IPG:n não pode ser usado para controlo exato da largura de banda da rede a uma velocidade específica em Mbps. Em vez disso, use a QoS de rede do Windows Server. O RoboCopy depende inteiramente do protocolo SMB para todas as necessidades de rede. Usar o SMB é a razão pela 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 às IOPS observadas no NAS. O tamanho do cluster no volume NAS, os tamanhos dos pacotes e uma série de outros fatores influenciam as IOPS observadas. A introdução do atraso entre pacotes é muitas vezes a maneira mais fácil de controlar a carga no NAS. Testar múltiplos valores, como desde cerca de 20 milissegundos (n=20) até múltiplos desse número. Depois de introduzir um atraso, pode avaliar se as suas outras aplicações funcionam agora como esperado. Esta estratégia de otimização ajuda-o a encontrar a velocidade ótima do RoboCopy no seu ambiente.

Velocidade de processamento

O RoboCopy percorre o espaço de nomes que especifica e avalia cada ficheiro e pasta para cópia. Avalia cada ficheiro durante uma cópia inicial e durante as cópias de recuperação. Por exemplo, execuções repetidas de RoboCopy /MIR nas mesmas localizações de armazenamento de origem e de destino. Estas execuções repetidas minimizam o tempo de inatividade para utilizadores e aplicações, e melhoram a taxa global de sucesso dos ficheiros migrados.

A largura de banda é frequentemente considerada o fator mais limitativo numa migração, e isso pode ser verdade. Mas a capacidade de enumerar um namespace pode influenciar o tempo total para copiar ainda mais para namespaces maiores com arquivos menores. Considere que copiar 1 TiB de ficheiros pequenos demora consideravelmente mais tempo do que copiar 1 TiB de ficheiros menores, mas maiores, assumindo que todas as outras variáveis permanecem iguais. Por isso, pode experienciar transferência lenta se estiver a migrar um grande número de ficheiros pequenos. Esta diferença é de esperar.

A causa para essa diferença é o poder de processamento necessário para percorrer um namespace. RoboCopy suporta cópias multi-threaded através do parâmetro /MT:n onde n significa o número de threads a usar. Portanto, ao provisionar uma máquina especificamente para o RoboCopy, considere o número de núcleos do processador e sua relação com a contagem de threads que eles fornecem. O mais comum são dois threads por núcleo. A contagem de núcleos e threads de uma máquina é um ponto de dados importante para decidir quais valores de multithreading devem ser especificados. Considere também quantos trabalhos do RoboCopy você planeja executar em paralelo em uma determinada máquina.

Com mais threads, o exemplo de ficheiros pequenos de 1 TiB é copiado consideravelmente mais depressa do que com menos threads. Ao mesmo tempo, o investimento extra de recursos no 1 TiB de ficheiros maiores pode não trazer benefícios proporcionais. Um alto número de threads tenta copiar simultaneamente mais ficheiros grandes pela rede. Essa atividade de rede extra aumenta a probabilidade de ser limitada pela taxa de transferência ou pelos IOPS de armazenamento.

Durante um primeiro RoboCopy em um destino vazio ou uma execução diferencial com muitos arquivos alterados, você provavelmente será limitado pela taxa de transferência da rede. Comece com uma contagem de threads elevada na execução inicial. Uma alta contagem de threads, mesmo além dos threads atualmente disponíveis na máquina, ajuda a saturar a largura de banda de rede disponível. As execuções subsequentes /MIR são afetadas de forma progressiva pelo processamento de itens. Menos alterações em uma execução diferencial significam menos transporte de dados pela rede. Sua velocidade agora depende mais de sua capacidade de processar itens de namespace do que movê-los pelo link de rede. Para execuções subsequentes, faça corresponder o valor da contagem de threads à contagem de núcleos do processador e à 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.

Gorjeta

Regra geral: A primeira execução do RoboCopy, que moverá muitos dados de uma rede de latência mais alta, se beneficia do provisionamento excessivo da contagem de threads (/MT:n). As execuções subsequentes copiarão menos diferenças e é mais provável que você mude de taxa de transferência de rede restrita para computação restrita. Nessas circunstâncias, muitas vezes é melhor alinhar o número de threads do RoboCopy com os threads efetivamente disponíveis na máquina. O provisionamento excessivo nesse cenário pode levar a mais mudanças de contexto no processador, possivelmente retardando sua cópia.

Evite 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 NTFS). Especialmente as alterações de ACL podem ter um alto impacto porque geralmente têm um efeito de alteração em cascata em arquivos mais baixos na hierarquia de pastas. As consequências podem ser:

  • tempo de execução prolongado da tarefa RoboCopy porque cada ficheiro e pasta afetados por uma alteração de ACL precisam ser atualizados
  • Ao reutilizar dados movidos anteriormente, poderá ser necessário copiá-los novamente. Por exemplo, é necessário copiar mais dados quando as estruturas das pastas mudam depois de os ficheiros já terem sido copiados. Um trabalho do RoboCopy não pode "reproduzir" uma alteração de namespace. O próximo trabalho deve limpar os arquivos anteriormente transportados para a estrutura de pastas antiga e carregar os arquivos na nova estrutura de pastas novamente.

Outro aspeto importante é usar a ferramenta RoboCopy de forma eficaz. Ao usar o script recomendado do RoboCopy, cria e guarda um ficheiro de registo para erros. Podem ocorrer erros de cópia, e isso é normal. Esses erros geralmente tornam necessário executar várias rodadas de uma ferramenta de cópia como o RoboCopy. Por exemplo, uma execução inicial, de um NAS para a Data Box ou de um servidor para uma partilha de ficheiros do Azure, e uma ou mais execuções adicionais com a opção /MIR para detetar e tentar copiar novamente os ficheiros que não foram copiados.

Esteja preparado para executar várias rondas de RoboCopy contra um determinado escopo de namespace. As execuções sucessivas terminam mais depressa, pois têm menos para copiar, mas são cada vez mais limitadas pela velocidade de processamento do namespace. Quando se executam múltiplas iterações, pode-se torná-las mais rápidas ao impedir que o RoboCopy se esforce de forma desnecessária para copiar tudo numa execução específica. Estes comutadores RoboCopy podem fazer uma diferença significativa:

  • /R:n n = a frequência com que tenta copiar novamente um ficheiro com falha e
  • /W:n n = quantos segundos esperar entre novas tentativas

/R:5 /W:5 é uma configuração razoável que você pode ajustar ao seu gosto. Neste exemplo, um arquivo com falha será repetido cinco vezes, com tempo de espera de cinco segundos entre as tentativas. Se o arquivo ainda não conseguir copiar, o próximo trabalho do RoboCopy tentará novamente. Muitas vezes, ficheiros que falharam por estarem em uso ou devido a problemas de timeout podem eventualmente ser copiados com sucesso desta forma.

Consulte também

  • Last updated on