Usar o RoboCopy para fazer a migração para compartilhamentos de arquivo do Azure

Este artigo de migração descreve o uso do RoboCopy para mover ou migrar arquivos para um compartilhamento de arquivos SMB do Azure. O RoboCopy é um utilitário de cópia de arquivos confiável e conhecido, com um conjunto de recursos adequado para migrações. Ele usa o protocolo SMB, portanto, é amplamente aplicável a qualquer combinação de origem e destino que suporte o SMB.

Há várias rotas de migração diferentes para diferentes combinações de origem e implantação. Consulte a tabela de guias de migração para encontrar a migração mais adequada às suas necessidades.

Aplica-se a

Tipo de compartilhamento de arquivos	SMB	NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS

AzCopy versus. RoboCopy

O AzCopy e o RoboCopy são duas ferramentas de cópia de arquivo fundamentalmente diferentes. O RoboCopy usa qualquer versão do protocolo SMB. AzCopy é uma ferramenta "criada na nuvem" que pode ser usada para mover dados, desde que o destino esteja no Armazenamento do Azure. O AzCopy depende de um protocolo REST.

O RoboCopy, como uma ferramenta de cópia confiável baseada no Windows, tem a vantagem de conhecer o ambiente quando se trata de copiar arquivos com total fidelidade. O RoboCopy dá suporte a vários cenários de migração devido ao conjunto avançado de recursos e à capacidade de copiar arquivos e pastas com total fidelidade. Confira a seção de fidelidade do arquivo no artigo d visão geral da migração para saber mais sobre a importância de copiar arquivos com o máximo possível fidelidade.

O AzCopy, por outro lado, foi expandido só recentemente para dar suporte à cópia de arquivos com certa fidelidade e recebeu os primeiros recursos necessários para ser considerado uma ferramenta de migração. No entanto, ainda existem lacunas e as funcionalidades podem ser facilmente confundidas na comparação dos sinalizadores do AzCopy e os sinalizadores do RoboCopy.

Um exemplo: o RoboCopy /MIR espelha a origem para o destino, ou seja, os arquivos adicionados, alterados e excluídos são considerados. Uma diferença importante no uso do AzCopy -sync é que os arquivos excluídos na origem não são removidos no destino. Considerando isso, ele é um conjunto incompleto de recursos de cópia diferencial. O AzCopy continuará evoluindo. No momento, não recomendamos usar o AzCopy para cenários de migração com compartilhamentos de arquivos do Azure como destino.

Metas de migração

A meta é mover os dados de locais de compartilhamento de arquivo existentes para o Azure. No Azure, você armazenará os dados em compartilhamentos de arquivo nativos do Azure que podem ser usados sem exigir 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 segundo 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, você precisará implantar contas de Armazenamento e compartilhamentos de arquivos do Azure. Em seguida, você vai configurar a rede, considere uma implantação de Namespace do DFS (DFS-N) ou atualize a existente. Quando chegar a hora da cópia de dados real, considere execuções repetidas e diferenciais do RoboCopy para minimizar o tempo de inatividade e, por fim, migrar os usuários para os compartilhamentos de arquivo do Azure recém-criados. As seções a seguir descrevem em detalhes, as fases do processo de migração.

Fase 1: implantar os recursos de armazenamento do Azure

Nesta fase, você vai provisionar as contas de armazenamento do Azure e os compartilhamentos de arquivos SMB do Azure 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 padrão, essa organização faz com que a conta de armazenamento seja uma destino de escala para números 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ê tiver compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou aplicativos), é desejável que você implante contas de armazenamento com um compartilhamento de arquivos cada uma. Essas limitações não se aplicam às contas de armazenamento do FileStorage (Premium), no qual o desempenho é provisionado e garantido explicitamente para cada compartilhamento.

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

Se você já fez uma lista dos seus compartilhamentos, você deve mapear cada um deles para a conta de armazenamento que será criada.

Os nomes de seus recursos também são importantes. Por exemplo, se você agrupar vários compartilhamentos para o departamento de RH em uma conta de armazenamento do Azure, deverá nomear a conta de armazenamento adequadamente. Da mesma forma, ao nomear os compartilhamentos de arquivo do Azure, use nomes semelhantes aos usados para as contrapartes 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, é aconselhável garantir que a região de cada uma das suas contas de armazenamento seja a mesma.

Fase 2: Preparar-se para usar os compartilhamentos de arquivos do Azure

Com as informações desta fase, você poderá decidir como os servidores e usuários dentro e fora do Azure serão habilitados para utilizar seus compartilhamentos de arquivos do Azure. As decisões mais críticas são:

• Rede: habilite suas redes para rotear o tráfego SMB.
• Autenticação: configure as contas de armazenamento do Azure para autenticação Kerberos. Usar a autenticação baseada em identidade e o ingresso no domínio em sua conta de armazenamento permitirá que seus aplicativos e usuários usem sua identidade do AD para autenticação.
• Autorização: As ACLs de nível de compartilhamento para cada compartilhamento de arquivo do Azure permitirão que usuários e grupos do AD acessem um determinado compartilhamento. Em um compartilhamento de arquivos do Azure, as ACLs nativas do NTFS assumirão o comando. 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 geralmente envolve a preservação de endereços de compartilhamento existentes. Se você ainda não estiver usando Namespaces do DFS, considere estabelecê-los no ambiente. Assim você mantém inalterados os endereços de compartilhamento que seus usuários e scripts usam. O DFS-N oferece um serviço de roteamento de namespace para SMB por meio do redirecionamento de clientes para os compartilhamentos de arquivo do Azure.

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.

Quando estiver pronto, revise Usar um compartilhamento de arquivos do Azure com o Windows. Depois, monte o compartilhamento de arquivo do Azure para o qual deseja iniciar o RoboCopy.

Fase 3: RoboCopy

O comando RoboCopy a seguir copia apenas as diferenças (arquivos e pastas atualizados) do armazenamento de origem para o compartilhamento de arquivo 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> 

Fase 4: Migração do usuário

Quando você executa o comando do RoboCopy pela primeira vez, os usuários e os aplicativos ainda estão acessando os arquivos na origem da migração e podem alterá-los. É possível que o RoboCopy processe um diretório, passe para o próximo e, depois, um usuário no local de origem adicione, altere ou exclua um arquivo que agora não será mais 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.

Depois que a execução inicial for concluída, execute o comando novamente.

A segunda execução do RoboCopy para o mesmo compartilhamento é concluído mais rapidamente, pois só precisa transportar as alterações ocorridas desde a última execução. Você pode executar os trabalhos várias vezes para o mesmo compartilhamento.

Depois de considerar a quantidade de tempo de inatividade aceitável, você precisará remover o acesso do usuário aos seus compartilhamentos de origem. 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 o Namespace do DFS para um local não existente ou alterar as ACLs em cada compartilhamento.

Execute uma última rodada do RoboCopy. Ele seleciona todas as alterações que possam ter sido perdidas. 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 inatividade) medindo quanto tempo a execução anterior levou.

Na fase 2, você configurou os usuários para acessar o compartilhamento com as respectivas identidades e deve ter estabelecido uma estratégia para que eles usem os caminhos estabelecidos para os novos compartilhamentos de arquivo do Azure (DFS-N).

Você pode tentar executar algumas dessas cópias entre diferentes compartilhamentos de origem e destino em paralelo. Ao fazer isso, tenha em mente a taxa de transferência da rede e a proporção do núcleo para a contagem de threads para não sobrecarregar o sistema.

Solucionar problemas e otimizar

A taxa de velocidade e êxito de uma determinada execução do RoboCopy dependerá 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.

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. O uso dessa opção pode ajudar a evitar a monopolização de recursos em ambos os dispositivos com restrição de e/s e links de rede lotados.

/IPG:n não pode ser usado para a limitação de rede exata em determinados 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, por exemplo, de cerca de 20 milissegundos (n=20) a múltiplos desse número. Depois de introduzir um atraso, você poderá avaliar se os outros aplicativos agora podem funcionar conforme o esperado. Essa estratégia de otimização permitirá que você encontre a velocidade ideal do RoboCopy em seu ambiente.

Velocidade de processamento

O RoboCopy percorrerá o namespace para o qual ele está apontado e avaliará cada arquivo e pasta para cópia. Cada arquivo será avaliado durante uma cópia inicial e durante as cópias de atualização. Por exemplo, execuções repetidas de RoboCopy/MIR em relação aos mesmos locais de armazenamento de origem e de destino. Essas execuções repetidas são úteis para minimizar o tempo de inatividade de usuários e aplicativos, e para melhorar a taxa geral de êxito dos arquivos migrados.

Geralmente, o padrão é considerar a largura de banda como o fator mais limitador em uma migração, e isso pode ser verdadeiro. Mas a capacidade de enumerar um namespace pode influenciar no tempo total para copiar ainda mais para namespaces maiores com arquivos menores. Considere que a cópia de 1 TiB de arquivos pequenos levará consideravelmente mais tempo do que a cópia de 1 TiB de menos arquivos com um tamanho maior, supondo 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. Este é um comportamento esperado.

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.

Mais threads copiarão nosso exemplo de 1 TiB de arquivos pequenos consideravelmente mais rápido do que menos threads. Ao mesmo tempo, o investimento extra de recursos em nossos 1 TiB de arquivos maiores pode não produzir benefícios proporcionais. Uma alta contagem de threads tentará copiar mais arquivos grandes pela rede simultaneamente. Essa atividade extra de rede aumenta a probabilidade de se restringir pela taxa de transferência ou pelo IOPS de armazenamento.

Durante um primeiro trabalho do RoboCopy em um destino vazio ou uma execução diferencial com muitos arquivos alterados, é provável que você se depare com uma restrição causada pela taxa de transferência da sua 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.

Evitar trabalho desnecessário

Evite alterações em larga escala em seu namespace, como mover arquivos entre diretórios, alterar propriedades em grande escala ou alterar o diretório e as permissões de nível de arquivo (ACLs 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 pode precisar ser copiado novamente. Por exemplo, mais dados precisarão ser copiados quando as estruturas de pasta forem alteradas depois que os arquivos já tiverem sido copiados anteriormente. 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. Com o script RoboCopy recomendado, você criará e salvará um arquivo de log para erros. Erros de cópia podem ocorrer e isso é normal. Esses erros geralmente tornam necessário executar várias rodadas de uma ferramenta de cópia, como o RoboCopy: uma execução inicial, por exemplo, de um NAS para o DataBox ou um servidor para um compartilhamento de arquivos do Azure e uma ou mais execuções extras com a opção /MIR para capturar e repetir arquivos que não foram copiados.

Você deve estar preparado para executar várias vezes o RoboCopy em um determinado escopo de namespace. As execuções sucessivas terminarão mais rapidamente, pois elas têm menos a ser copiado, mas são restritas cada vez mais 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 = com que frequência você tenta copiar um arquivo com falha e
• /W:n n = quantos segundos aguardar entre repetições

/R:5 /W:5 é uma configuração razoável que você pode ajustar para 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. Em geral, arquivos que falharam porque estão em uso ou devido a problemas de tempo limite podem eventualmente ser copiados com êxito dessa forma.

Como estimar os custos da transação de armazenamento

À medida que você inicia a migração para os Arquivos do Azure, o RoboCopy copia os arquivos e as pastas para o Azure. Poderão ser aplicados custos de transação de acordo com o modelo de cobrança para os Arquivos do Azure. Confira Entender a cobrança.

Ao usar um modelo de cobrança pré-pago para compartilhamentos de arquivos Standard do Azure, pode ser difícil estimar o número de transações geradas pela migração.

• Não é possível estimar o número de transações com base na capacidade de armazenamento utilizada da origem. O número de transações aumenta com o número de itens do namespace (arquivos e pasta) e com as respectivas propriedades que são migradas, não com o tamanho. Por exemplo, são necessárias mais transações para migrar 1 GiB de arquivos pequenos do que 1 GiB de arquivos maiores.
• Para minimizar o tempo de inatividade, talvez seja necessário executar operações de cópia diversas vezes da origem para o destino. Todos os itens de origem e de destino são processados durante cada operação de cópia, embora as execuções posteriores sejam concluídas mais rapidamente. Após as operações iniciais, somente as diferenças introduzidas entre as execuções de cópia são transportadas pela rede. É importante compreender que o número de transações necessárias pode permanecer igual, mesmo que sejam transportados menos dados.
• A cópia do mesmo arquivo duas vezes talvez não resulte no mesmo número de transações. O processamento de um item migrado em uma cópia anterior pode resultar em apenas algumas transações de leitura. Por outro lado, alterações nos metadados ou no conteúdo entre as execuções de cópias podem exigir um número maior de transações para atualizar o destino. Cada arquivo no namespace pode ter requisitos exclusivos, o que resulta em um número diferente de transações.

É recomendado realizar alguns testes iniciais em seus próprios dados para entender melhor quantas transações são incorridas. Isso ajuda você a entender melhor o número total de transações que uma migração de arquivo pode gerar.

Próximas etapas

Os artigos a seguir ajudarão você a entender as opções avançadas e as práticas recomendadas.

• O que são os Arquivos do Azure?
• Visão geral da migração
• Backup: instantâneos sobre compartilhamento de arquivos do Azure
• Como usar Namespaces do DFS com os Arquivos do Azure