Partilhar via

Usar o DataBox para migrar do Network Attached Storage (NAS) para compartilhamentos de arquivos do Azure

  • Artigo

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

  • Fonte de dados: Network Attached Storage (NAS)
  • Rota de migração: NAS ⇒ DataBox ⇒ compartilhamento de arquivos do Azure
  • 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.

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 usa o Azure DataBox para transporte de dados em massa (transporte de dados offline).

Aplica-se a

Tipo de partilhas de ficheiros SMB NFS
Partilhas de ficheiros Standard (GPv2), LRS/ZRS Yes No
Partilhas de ficheiros Standard (GPv2), GRS/GZRS Yes No
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS Yes No

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. Você precisará implantar contas de armazenamento do Azure e compartilhamentos de arquivos e configurar a rede. Em seguida, você migrará seus arquivos usando o Azure DataBox e o RoboCopy para acompanhar as alterações. Por fim, você cortará seus usuários e aplicativos para os compartilhamentos de arquivos do Azure recém-criados. As seções a seguir descrevem as fases do processo de migração em detalhes.

Gorjeta

Se você estiver voltando a este artigo, use a navegação no lado direito para ir para a fase de migração de onde parou.

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

Nesta etapa, você determinará quantos compartilhamentos de arquivos do Azure são necessários. 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 compartilhamentos de arquivos que você deseja migrar para a nuvem, você pode optar por usar um mapeamento 1:1 ou compartilhar agrupamento.

Usar um mapeamento 1:1

Se você tiver um número pequeno o suficiente de compartilhamentos, recomendamos um mapeamento 1:1. A maneira mais fácil de imaginar esse cenário é imaginar um compartilhamento local que mapeia 1:1 para um compartilhamento de arquivos 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, você provisionará as contas de armazenamento do Azure e os compartilhamentos de arquivos dentro delas.

Lembre-se de que um compartilhamento de arquivos do Azure é implantado na nuvem em uma conta de armazenamento do Azure. Para compartilhamentos de arquivos padrão, essa disposição torna a conta de armazenamento um destino 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 você tiver compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou aplicativos), convém implantar contas de armazenamento com um compartilhamento de arquivos cada. Essas limitações não se aplicam a contas de armazenamento FileStorage (premium), onde o desempenho é explicitamente provisionado e garantido para cada compartilhamento.

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 de arquivos do Azure.

Se você fez uma lista de seus compartilhamentos, deve mapear cada compartilhamento para a conta de armazenamento em que será criado.

Os nomes dos 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 seus compartilhamentos de arquivos do Azure, você deve usar nomes semelhantes aos usados para suas 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 nelas, seguindo as instruções em Criar um compartilhamento de arquivos SMB. Na maioria dos casos, convém certificar-se de que a região de cada uma das suas contas de armazenamento é a mesma.

Fase 3: Determinar quantos dispositivos Azure DataBox você precisa

Inicie esta etapa somente quando tiver concluído a fase anterior. Seus recursos de armazenamento do Azure (contas de armazenamento e compartilhamentos de arquivos) devem ser criados neste momento. Durante seu pedido de DataBox, você precisa especificar para quais contas de armazenamento o DataBox está movendo dados.

Nesta fase, você precisa mapear os resultados do plano de migração da fase anterior para os limites das opções DataBox disponíveis. Essas considerações ajudarão você a fazer um plano para quais opções de DataBox você deve escolher e quantas delas você precisará para mover seus compartilhamentos NAS para compartilhamentos de arquivos do Azure.

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

  • Qualquer DataBox do Azure pode mover dados para até 10 contas de armazenamento.
  • Cada opção DataBox vem em sua própria capacidade utilizável. Consulte Opções de DataBox.

Consulte seu plano de migração para saber o número de contas de armazenamento que você decidiu criar e os compartilhamentos de cada uma. Em seguida, observe o tamanho de cada uma das ações no seu NAS. A combinação dessas informações permitirá que você otimize e decida qual dispositivo deve enviar dados para quais contas de armazenamento. Você pode fazer com que dois dispositivos DataBox movam arquivos para a mesma conta de armazenamento, mas não divida o conteúdo de um único compartilhamento de arquivos em 2 DataBoxes.

Opções de DataBox

Para uma migração padrão, uma ou uma combinação dessas duas opções de DataBox deve ser escolhida:

  • DataBox Esta é a opção mais comum. Um dispositivo DataBox robusto, que funciona de forma semelhante a um NAS, será enviado para você. Tem uma capacidade utilizável de 80 TiB. Para obter mais informações, consulte a documentação do DataBox.
  • DataBox Heavy Esta opção apresenta um dispositivo DataBox 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 DataBox 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 arquivos, como permissões de acesso (ACLs) e outros atributos.

Fase 4: Provisionar um Windows Server temporário

Enquanto aguarda a chegada da(s) sua(s) DataBox(es) do Azure, você já pode implantar um ou mais Servidores Windows necessários para executar trabalhos do RoboCopy.

  • O primeiro uso desses servidores será copiar arquivos para o DataBox.
  • O segundo uso desses servidores será para recuperar o atraso com as mudanças que ocorreram no dispositivo NAS enquanto DataBox estava 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:

É importante ter em mente os detalhes referenciados ao decidir sobre a RAM e a contagem de threads que você fornecerá ao(s) seu(s) servidor(es) temporário(s) do Windows.

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

Para poupar tempo, deve prosseguir com esta fase enquanto aguarda a chegada da sua DataBox. Com as informações nesta fase, você poderá decidir como seus servidores e usuários no Azure e fora do Azure serão habilitados para utilizar seus compartilhamentos de arquivos do 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 AdConnect e o Domain que ingressam na sua conta de armazenamento permitirão 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 arquivos do Azure permitirão que usuários e grupos do AD acessem um determinado compartilhamento e, dentro de um compartilhamento de arquivos do Azure, as ACLs NTFS nativas assumirão o controle. A autorização baseada em ACLs de arquivo e pasta funciona como para compartilhamentos SMB locais.
  • Continuidade de negócios: a integração de compartilhamentos de arquivos do Azure em um ambiente existente geralmente implica a preservação de endereços de compartilhamento existentes. Se você ainda não estiver usando DFS-Namespaces, considere estabelecer isso em seu ambiente. Você seria capaz de manter os endereços de compartilhamento que seus usuários 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: Copie arquivos para seu DataBox

Quando seu DataBox chegar, você precisa configurar seu DataBox com conectividade de rede desimpedida para seu dispositivo NAS. Siga a documentação de configuração para o tipo DataBox que você encomendou.

Dependendo do tipo DataBox, talvez haja ferramentas de cópia DataBox disponíveis para você. Neste ponto, eles não são recomendados para migrações para compartilhamentos de arquivos do Azure, pois não copiam seus arquivos com total fidelidade para o DataBox. Em vez disso, use o RoboCopy.

Quando seu DataBox chegar, ele terá compartilhamentos SMB pré-provisionados disponíveis para cada conta de armazenamento que você especificou no momento do pedido.

  • Se seus arquivos forem para um compartilhamento de arquivos premium do Azure, haverá um compartilhamento SMB por conta de armazenamento premium de "Armazenamento de arquivos".
  • Se os seus ficheiros forem para uma conta de armazenamento padrão, haverá três partilhas SMB por conta de armazenamento padrão (GPv1 e GPv2). Somente os compartilhamentos de arquivos que terminam com _AzFiles são relevantes para sua migração. Ignore qualquer bloco e compartilhamento de blob de página.

Siga as etapas na documentação do Azure DataBox:

  1. Conectar-se ao Data Box
  2. Copiar dados para o Data Box
  3. Prepare sua DataBox para a partida para o Azure

A documentação DataBox vinculada especifica um comando RoboCopy. No entanto, o comando não é adequado para preservar a fidelidade completa de arquivos e pastas. Em vez disso, use este comando:

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, confira 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, a Data Box criou 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 que seu DataBox relatar que todos os arquivos e pastas foram colocados nos compartilhamentos de arquivos planejados do Azure, você poderá continuar com essa fase. Um RoboCopy de recuperação só é necessário se os dados no NAS podem ter sido alterados desde que a cópia do DataBox foi iniciada. 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 você precisa de um compartilhamento para ser leitura-gravação durante a migração e só pode absorver uma pequena janela de tempo de inatividade, essa etapa de recuperação do RoboCopy será importante concluir antes do failover do acesso do usuário diretamente ao compartilhamento de arquivos do Azure.

Nesta etapa, você executará trabalhos do RoboCopy para recuperar o atraso de seus compartilhamentos na nuvem com as alterações mais recentes em seu NAS desde o momento em que você bifurcou seus compartilhamentos no DataBox. Este RoboCopy de recuperação pode terminar rapidamente ou demorar um pouco, dependendo da quantidade de churn que aconteceu em suas ações 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

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 montar com êxito um compartilhamento de arquivos do Azure em um Windows Server local, você precisa ter concluído a Fase: Preparando-se para usar compartilhamentos de arquivos do Azure!

Quando estiver pronto, revise o artigo de instruções Usar um compartilhamento de arquivos do Azure com o Windows e monte o compartilhamento de arquivos do Azure para o qual você deseja iniciar o RoboCopy de recuperação do NAS.

RoboCopiar

O comando RoboCopy a seguir copiará apenas as diferenças (arquivos e pastas atualizados) do 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>
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 computação disponível vs largura de banda de rede disponível. Nas execuções subsequentes, faça corresponder o valor da contagem de threads a um valor próximo da contagem de núcleos do processador e da contagem 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 arquivo não consiga copiar permanentemente na 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. Escolha nenhuma nova tentativa ou um valor de um se você acredita que o arquivo não conseguiu copiar porque estava ativamente em uso. 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 rápido sem ser prolongada por muitas tentativas que, em última análise, acabam em uma maioria de 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 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 você usar 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 versus 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. Correspondência significa copiar do nível de origem e pasta correto para o nível de pasta correspondente no destino. 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 da ACL pode ser perdida 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 para a 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 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 usado como projetado, todas as informações lá são específicas para o volume exato neste sistema exato e podem ser reconstruídas sob demanda. Copiar essas informações não será útil na nuvem ou quando os dados forem copiados de volta para outro volume do Windows. Deixar este conteúdo para trás não deve ser considerado 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 da cópia devido ao registo 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 ao controlo de pontos de verificação.

Importante

Recomendamos o uso de um Windows Server 2022. Ao usar um Windows Server 2019, verifique se o nível de patch mais recente ou, pelo menos , o KB5005103 de atualização do sistema operacional está instalado. Ele contém correções importantes para determinados cenários do Robocopy.

Gorjeta

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

Transferência 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 é sobre como mover a maior parte dos dados alterados para 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.

Quando a execução inicial estiver concluída, execute o comando novamente.

Uma segunda vez que você executar o RoboCopy para o mesmo compartilhamento, ele terminará mais rápido, porque ele só precisa transportar as alterações que aconteceram desde a última execução. Você pode executar trabalhos repetidos 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. Ele vai pegar quaisquer mudanças, que poderiam ter sido perdidas. Quanto tempo demora este passo 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.

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 você tinha um NAS ingressado em domínio de classe empresarial, os SIDs de usuário corresponderão automaticamente à medida que os usuários existirem no Ative Directory e o RoboCopy copia arquivos e metadados com total fidelidade. 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.

Você terminou de migrar um compartilhamento / grupo de compartilhamentos para uma raiz ou volume comum.

Você pode tentar executar algumas dessas cópias em paralelo. Recomendamos processar o escopo de um compartilhamento de arquivos do Azure de cada vez.

Resolver problemas

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

O RoboCopy pode inserir atrasos entre pacotes especificando o switch onde n é medido /IPG:n em milissegundos entre os pacotes RoboCopy. O uso desse switch pode ajudar a evitar a monopolização de recursos em dispositivos restritos de E/S e links de rede lotados.

/IPG:n não pode ser usado para limitação de rede precisa para um determinado 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. Teste vários valores, por exemplo, de cerca de 20 milissegundos (n=20) para múltiplos desse número. Depois de introduzir um atraso, você pode avaliar se seus 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 foi apontado e avaliará cada arquivo e pasta para cópia. Cada ficheiro será avaliado durante uma cópia inicial e durante as cópias de recuperação. Por exemplo, execuções repetidas do RoboCopy /MIR nos mesmos locais de armazenamento de origem e destino. Essas execuções repetidas são úteis para minimizar o tempo de inatividade de usuários e aplicativos e para melhorar a taxa de sucesso geral dos arquivos migrados.

Muitas vezes, consideramos a largura de banda como o fator mais limitante em uma 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 arquivos pequenos levará consideravelmente mais tempo do que copiar 1 TiB de arquivos menores, mas maiores, supondo que todas as outras variáveis permaneçam as mesmas. Portanto, você pode enfrentar uma transferência lenta se estiver migrando um grande número de arquivos pequenos. Este é um comportamento esperado.

A causa para essa diferença é o poder de processamento necessário para percorrer um namespace. O RoboCopy suporta cópias multi-threaded através do /MT:n parâmetro onde n significa o número de threads a serem usados. 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 /MT:n multi-thread você deve especificar. Considere também quantos trabalhos do RoboCopy você planeja executar em paralelo em uma determinada máquina.

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 de recursos extras em nossos 1 TiB de arquivos maiores pode não produzir benefícios proporcionais. Uma alta contagem de threads tentará copiar mais dos arquivos grandes pela rede simultaneamente. Essa atividade de rede extra aumenta a probabilidade de ser restringida por IOPS de taxa de transferência ou 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 progressivamente afetadas 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 combinar a contagem de threads do RoboCopy com os threads realmente 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 estendido do trabalho RoboCopy porque cada arquivo e pasta afetados por uma alteração de ACL precisa ser atualizado
  • A reutilização de dados movidos anteriormente pode precisar ser recopiada. Por exemplo, mais dados precisarão ser copiados quando as estruturas de pastas mudarem depois que os arquivos já tiverem sido copiados anteriormente. 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. Com o script RoboCopy recomendado, você criará e salvará um arquivo de log para erros. Erros de cópia podem ocorrer - 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, digamos, de um NAS para 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 rodadas do RoboCopy em um determinado escopo de namespace. As execuções sucessivas terminarão mais rapidamente, pois têm menos para copiar, mas são cada vez mais limitadas pela velocidade de processamento do namespace. Quando você executa várias rodadas, você pode acelerar cada rodada não fazendo com que o RoboCopy tente copiar tudo em uma determinada execução. 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, os ficheiros que falharam porque estão a ser utilizados ou devido a problemas de tempo limite podem eventualmente ser copiados com êxito desta forma.

Próximos passos

Há mais para descobrir sobre compartilhamentos de arquivos do Azure. Os artigos a seguir ajudam a entender as opções avançadas, as práticas recomendadas e também contêm ajuda para solução de problemas. Estes artigos estão vinculados à documentação de compartilhamento de arquivos do Azure, conforme apropriado.