Partilhar via

Migrar do Network Attached Storage (NAS) para uma implantação de nuvem híbrida com o Azure File Sync

  • Artigo

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

  • Fonte de dados: Network Attached Storage (NAS)
  • Rota de migração: NAS ⇒ Windows Server ⇒ carregar e sincronizar com compartilhamentos de arquivos do Azure
  • Armazenamento em cache de arquivos no local: Sim, o objetivo final é uma implantação do Azure File Sync.

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

A Sincronização de Ficheiros do Azure funciona em localizações DAS (Direct Attached Storage) e não suporta a sincronização com localizações NAS (Network Attached Storage). Este facto torna necessária uma migração dos seus ficheiros, e este artigo orienta-o através do planeamento e execução dessa migração.

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 de arquivos SMB em seu dispositivo NAS para um Windows Server e, em seguida, utilizar o Azure File Sync para uma implantação de nuvem híbrida. Geralmente, as migrações precisam ser feitas de forma a garantir a integridade dos dados de produção e sua 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

Conforme mencionado em Migrar para compartilhamentos de arquivos do Azure SMB, usar a ferramenta de cópia e a abordagem corretas é importante. Seu dispositivo NAS está expondo compartilhamentos SMB diretamente em sua rede local. Você pode usar o Azure Storage Mover ou o RoboCopy para mover seus arquivos.

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. Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Você pode ter mais pastas em seus volumes que você atualmente compartilha localmente como compartilhamentos SMB para seus usuários e aplicativos. 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. Se você tiver um número pequeno o suficiente de compartilhamentos, abaixo de 30 para uma única instância do Windows Server, recomendamos um mapeamento 1:1.

Se você tiver mais de 30 compartilhamentos, mapear um compartilhamento local 1:1 para um compartilhamento de arquivos do Azure geralmente é desnecessário. Considere as seguintes opções.

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. O armazenamento de vários compartilhamentos locais em um compartilhamento de arquivos do Azure não impede que você crie os 15 compartilhamentos SMB usuais em sua instância local do Windows Server. Isso significa apenas que você organiza as pastas raiz desses 15 compartilhamentos como subpastas em uma pasta comum. Em seguida, sincronize essa pasta comum com um 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.

Sincronização de volume

O Azure File Sync dá suporte à sincronização da raiz de um volume com um compartilhamento de arquivos do Azure. Se você sincronizar a raiz do volume, todas as subpastas e arquivos irão para o mesmo compartilhamento de arquivos do Azure.

Sincronizar a raiz do volume nem sempre é a melhor opção. Há benefícios em sincronizar vários locais. Por exemplo, isso ajuda a manter o número de itens mais baixo por escopo de sincronização. Testamos as partilhas de ficheiros do Azure e a Sincronização de Ficheiros do Azure com 100 milhões de itens (ficheiros e pastas) por partilha. Mas uma boa prática é tentar manter o número abaixo de 20 milhões ou 30 milhões em uma única ação. Configurar a Sincronização de Ficheiros do Azure com um número mais baixo de itens não é benéfico apenas para a sincronização de ficheiros. Um número menor de itens também beneficia cenários como estes:

  • A verificação inicial do conteúdo da nuvem pode ser concluída mais rapidamente, o que, por sua vez, diminui a espera para que o namespace apareça em um servidor habilitado para a Sincronização de Arquivos do Azure.
  • A restauração do lado da nuvem a partir de um instantâneo de compartilhamento de arquivos do Azure será mais rápida.
  • A recuperação de desastres de um servidor local pode acelerar significativamente.
  • As alterações feitas diretamente em um compartilhamento de arquivos do Azure (fora da sincronização) podem ser detetadas e sincronizadas mais rapidamente.

Gorjeta

Se não sabe quantos ficheiros e pastas tem, consulte a ferramenta TreeSize da JAM Software GmbH.

Uma abordagem estruturada para um mapa de implantação

Antes de implantar o armazenamento em nuvem em uma etapa posterior, é importante criar um mapa entre pastas locais e compartilhamentos de arquivos do Azure. Esse mapeamento informará quantos e quais recursos do grupo de sincronização do Azure File Sync você provisionará. Um grupo de sincronização vincula o compartilhamento de arquivos do Azure e a pasta em seu servidor e estabelece uma conexão de sincronização.

Para decidir quantos compartilhamentos de arquivos do Azure você precisa, revise os seguintes limites e práticas recomendadas. Isso irá ajudá-lo a otimizar o seu mapa.

  • Um servidor no qual o agente do Azure File Sync está instalado pode sincronizar com até 30 compartilhamentos de arquivos do Azure.

  • Um compartilhamento de arquivos do Azure é implantado em uma conta de armazenamento. Essa disposição torna a conta de armazenamento um destino de escala para números de desempenho, como IOPS e taxa de transferência.

    Preste atenção às limitações de IOPS de uma conta de armazenamento ao implantar compartilhamentos de arquivos do Azure. Idealmente, você deve mapear compartilhamentos de arquivos 1:1 com contas de armazenamento. No entanto, isso nem sempre é possível devido a vários limites e restrições, tanto da sua organização quanto do Azure. Quando não for possível ter apenas um compartilhamento de arquivos implantado em uma conta de armazenamento, considere quais compartilhamentos serão altamente ativos e quais compartilhamentos serão menos ativos para garantir que os compartilhamentos de arquivos mais quentes não sejam colocados na mesma conta de armazenamento juntos.

    Se você planeja elevar um aplicativo para o Azure que usará o compartilhamento de arquivos do Azure nativamente, talvez precise de mais desempenho do seu compartilhamento de arquivos do Azure. Se esse tipo de uso for uma possibilidade, mesmo no futuro, é melhor criar um único compartilhamento de arquivos padrão do Azure em sua própria conta de armazenamento.

  • Há um limite de 250 contas de armazenamento por assinatura por região do Azure.

Gorjeta

Dadas essas informações, muitas vezes torna-se necessário agrupar várias pastas de nível superior em seus volumes em um novo diretório raiz comum. Em seguida, sincronize esse novo diretório raiz e todas as pastas agrupadas nele com um único compartilhamento de arquivos do Azure. Essa técnica permite que você fique dentro do limite de 30 sincronizações de compartilhamento de arquivos do Azure por servidor.

Esse agrupamento sob uma raiz comum não afeta o acesso aos seus dados. Suas ACLs permanecem como estão. Você só precisa ajustar os caminhos de compartilhamento (como compartilhamentos SMB ou NFS) que possa ter nas pastas do servidor local que agora você alterou para uma raiz comum. Nada mais muda.

Importante

O vetor de escala mais importante para o Azure File Sync é o número de itens (arquivos e pastas) que precisam ser sincronizados. Analise os destinos de escala do Azure File Sync para obter mais detalhes.

É uma prática recomendada manter baixo o número de itens por escopo de sincronização. Esse é um fator importante a ser considerado em seu mapeamento de pastas para compartilhamentos de arquivos do Azure. O Azure File Sync é testado com 100 milhões de itens (ficheiros e pastas) por partilha. Mas muitas vezes é melhor manter o número de itens abaixo de 20 milhões ou 30 milhões em uma única ação. Divida seu namespace em vários compartilhamentos se você começar a exceder esses números. Você pode continuar a agrupar vários compartilhamentos locais no mesmo compartilhamento de arquivos do Azure se ficar aproximadamente abaixo desses números. Esta prática proporcionar-lhe-á espaço para crescer.

É possível que, na sua situação, um conjunto de pastas possa sincronizar logicamente com o mesmo compartilhamento de arquivos do Azure (usando a nova abordagem de pasta raiz comum mencionada anteriormente). Mas ainda pode ser melhor reagrupar pastas para que elas sincronizem com duas em vez de um compartilhamento de arquivos do Azure. Você pode usar essa abordagem para manter o número de arquivos e pastas por compartilhamento de arquivos equilibrado no servidor. Você também pode dividir seus compartilhamentos locais e sincronizar em mais servidores locais, adicionando a capacidade de sincronizar com mais 30 compartilhamentos de arquivos do Azure por servidor extra.

Cenários e considerações comuns de sincronização de arquivos

# Cenário de sincronização Suportado Considerações (ou limitações) Solução (ou solução alternativa)
1 Servidor de ficheiros com vários discos/volumes e várias partilhas para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Não Um compartilhamento de arquivos do Azure de destino (ponto de extremidade na nuvem) só dá suporte à sincronização com um grupo de sincronização.

Um grupo de sincronização suporta apenas um ponto de extremidade de servidor por servidor registrado.		 1) Comece com a sincronização de um disco (seu volume raiz) para o compartilhamento de arquivos do Azure de destino. Começar com o maior disco/volume ajudará com os requisitos de armazenamento no local. Configure a hierarquização da nuvem para hierarquizar todos os dados na nuvem, liberando espaço no disco do servidor de arquivos. Mova dados de outros volumes/compartilhamentos para o volume atual que está sincronizando. Continue as etapas, uma a uma, até que todos os dados sejam hierarquizados para a nuvem/migrados.
2) Segmente um volume raiz (disco) de cada vez. Use a hierarquização na nuvem para hierarquizar todos os dados para o compartilhamento de arquivos do Azure de destino. Remova o ponto de extremidade do servidor do grupo de sincronização, recrie o ponto de extremidade com o próximo volume/disco raiz, sincronize e repita o processo. Nota: A reinstalação do agente pode ser necessária.
3) Recomende o uso de vários compartilhamentos de arquivos do Azure de destino (conta de armazenamento igual ou diferente com base nos requisitos de desempenho)
2 Servidor de ficheiros com volume único e várias partilhas para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Sim Não é possível ter vários pontos de extremidade de servidor por servidor registrado sincronizando com o mesmo compartilhamento de arquivos do Azure de destino (o mesmo que acima) Sincronize a raiz do volume que contém vários compartilhamentos ou pastas de nível superior. Consulte Conceito de agrupamento de compartilhamento e Sincronização de volume para obter mais informações.
3 Servidor de ficheiros com várias partilhas e/ou volumes para várias partilhas de ficheiros do Azure numa única conta de armazenamento (mapeamento de partilha 1:1) Sim Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Uma conta de armazenamento é um destino de escala para desempenho. IOPS e taxa de transferência são compartilhadas entre compartilhamentos de arquivos.

Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. O ideal é ficar abaixo de 20 ou 30 milhões por ação.		 1) Use vários grupos de sincronização (número de grupos de sincronização = número de compartilhamentos de arquivos do Azure para sincronizar).
2) Apenas 30 compartilhamentos podem ser sincronizados neste cenário de cada vez. Se você tiver mais de 30 compartilhamentos nesse servidor de arquivos, use o conceito de agrupamento de compartilhamento e a sincronização de volume para reduzir o número de pastas raiz ou de nível superior na origem.
3) Use servidores de sincronização de arquivos adicionais no local e divida / mova dados para esses servidores para contornar as limitações no servidor Windows de origem.
4 Servidor de arquivos com vários compartilhamentos e/ou volumes para vários compartilhamentos de arquivos do Azure em conta de armazenamento diferente (mapeamento de compartilhamento 1:1) Sim Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure (conta de armazenamento igual ou diferente).

Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. O ideal é ficar abaixo de 20 ou 30 milhões por ação.		 Mesma abordagem que acima
5 Vários servidores de arquivos com um único (volume raiz ou compartilhamento) para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Não Um grupo de sincronização não pode usar o ponto de extremidade de nuvem (compartilhamento de arquivos do Azure) já configurado em outro grupo de sincronização.

Embora um grupo de sincronização possa ter pontos de extremidade de servidor em servidores de arquivos diferentes, os arquivos não podem ser distintos.		 Siga as orientações no Cenário # 1 acima com consideração adicional de segmentar um servidor de arquivos de cada vez.

Criar uma tabela de mapeamento

Diagrama que mostra um exemplo de uma tabela de mapeamento. Transfira o seguinte ficheiro para experimentar e utilizar o conteúdo desta imagem.

Use as informações anteriores para determinar quantos compartilhamentos de arquivos do Azure você precisa e quais partes de seus dados existentes acabarão em qual compartilhamento de arquivos do Azure.

Crie uma tabela que registre seus pensamentos para que você possa consultá-la quando precisar. Manter-se organizado é importante porque pode ser fácil perder detalhes do seu plano de mapeamento quando você provisiona muitos recursos do Azure de uma só vez. Baixe o seguinte arquivo do Excel para usar como um modelo para ajudar a criar seu mapeamento.


Ícone do Excel que define o contexto para o download. Baixe um modelo de mapeamento de namespace.

Fase 2: Provisionar um Windows Server local adequado

  • Crie uma máquina virtual Windows Server 2022 ou Windows Server 2019 ou implante um servidor físico. Um cluster de failover do Windows Server também é suportado.

  • Provisione ou adicione armazenamento com conexão direta (DAS em comparação com o NAS, que não é suportado).

    A quantidade de armazenamento provisionada pode ser menor do que a que você está usando atualmente em seu dispositivo NAS. Essa opção de configuração requer que você também use o recurso de hierarquização na nuvem do Azure File Sync. No entanto, quando você copia seus arquivos do espaço NAS maior para o volume menor do Windows Server em uma fase posterior, você precisará trabalhar em lotes:

    1. Mover um conjunto de ficheiros que se encaixa no disco
    2. Permita que a sincronização de arquivos e a hierarquização na nuvem interajam
    3. Quando mais espaço livre for criado no volume, prossiga com o próximo lote de arquivos. Como alternativa, revise o comando RoboCopy na seção RoboCopy deste artigo para usar o novo /LFSM switch. O uso /LFSM pode simplificar significativamente seus trabalhos do RoboCopy, mas não é compatível com alguns outros switches do RoboCopy dos quais você pode depender. Use o /LFSM switch somente quando o destino da migração for armazenamento local. Não há suporte quando o destino é um compartilhamento SMB remoto.

    Você pode evitar essa abordagem de envio em lote provisionando o espaço equivalente no Windows Server que seus arquivos ocupam no dispositivo NAS. Considere a desduplicação em NAS/Windows. Se você não quiser comprometer permanentemente essa grande quantidade de armazenamento no Windows Server, poderá reduzir o tamanho do volume após a migração e antes de ajustar as políticas de hierarquização na nuvem. Isso cria um cache local menor de seus compartilhamentos de arquivos do Azure.

A configuração de recursos (computação e RAM) do Windows Server implantado depende principalmente do número de itens (arquivos e pastas) que você sincronizará. Recomendamos optar por uma configuração de desempenho mais alto se você tiver alguma preocupação.

Saiba como dimensionar um Windows Server com base no número de itens (arquivos e pastas) que você precisa sincronizar.

Nota

O artigo vinculado anteriormente apresenta uma tabela com um intervalo para memória do servidor (RAM). Você pode se orientar para o número menor do seu servidor, mas espera que a sincronização inicial possa levar muito mais tempo.

Fase 3: Implantar o recurso de nuvem do Azure File Sync

Para concluir esta etapa, você precisa de suas credenciais de assinatura do Azure.

O recurso principal a ser configurado para o Azure File Sync é chamado de Serviço de Sincronização de Armazenamento. Recomendamos que você implante apenas um para todos os servidores que estão sincronizando o mesmo conjunto de arquivos agora ou no futuro. Crie vários Serviços de Sincronização de Armazenamento somente se você tiver conjuntos distintos de servidores que nunca devem trocar dados. Por exemplo, você pode ter servidores que nunca devem sincronizar o mesmo compartilhamento de arquivos do Azure. Caso contrário, usar um único Serviço de Sincronização de Armazenamento é a prática recomendada.

Escolha uma região do Azure para o seu Serviço de Sincronização de Armazenamento que esteja perto da sua localização. Todos os outros recursos de nuvem devem ser implantados na mesma região. Para simplificar o gerenciamento, crie um novo grupo de recursos em sua assinatura que hospede recursos de sincronização e armazenamento.

Para obter mais informações, consulte a seção sobre a implantação do Serviço de Sincronização de Armazenamento no artigo sobre a implantação do Azure File Sync. Siga apenas esta seção do artigo. Haverá links para outras seções do artigo em etapas posteriores.

Fase 4: Implantar recursos de armazenamento do Azure

Nesta fase, consulte a tabela de mapeamento da Fase 1 e use-a para provisionar o número correto de contas de armazenamento do Azure e compartilhamentos de arquivos dentro delas.

Um compartilhamento de arquivos do Azure é armazenado na nuvem em uma conta de armazenamento do Azure. Outro nível de considerações de desempenho se aplica aqui.

Se você tiver compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou aplicativos), dois compartilhamentos de arquivos do Azure podem atingir o limite de desempenho de uma conta de armazenamento.

Uma prática recomendada é implantar contas de armazenamento com um compartilhamento de arquivos cada. 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.

Essas considerações se aplicam mais ao acesso direto à nuvem (por meio de uma VM do Azure) do que à Sincronização de Arquivos do Azure. Se você planeja usar apenas o Azure File Sync nesses compartilhamentos, agrupar vários em uma única conta de armazenamento do Azure é bom.

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

Na fase anterior, você determinou o número apropriado de ações. Nesta etapa, você tem um mapeamento de contas de armazenamento para compartilhamentos de arquivos. Agora, implante o número apropriado de contas de armazenamento do Azure com o número apropriado de compartilhamentos de arquivos do Azure nelas.

Verifique se a região de cada uma das suas contas de armazenamento é a mesma e corresponde à região do recurso do Serviço de Sincronização de Armazenamento que você já implantou.

Atenção

Se você criar um compartilhamento de arquivos do Azure que tenha um limite de 100 TiB, esse compartilhamento poderá usar apenas armazenamento com redundância local ou opções de redundância de armazenamento com redundância de zona. Considere suas necessidades de redundância de armazenamento antes de usar compartilhamentos de arquivos de 100 TiB.

Os compartilhamentos de arquivos do Azure ainda são criados com um limite de 5 TiB por padrão. Siga as etapas em Criar um compartilhamento de arquivos do Azure para criar um compartilhamento de arquivos grande.

Outra consideração ao implantar uma conta de armazenamento é a redundância do Armazenamento do Azure. Consulte Opções de redundância do Armazenamento do Azure.

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.

Fase 5: Implantar o agente do Azure File Sync

Nesta seção, você instala o agente do Azure File Sync em sua instância do Windows Server.

O guia de implantação explica que você precisa desativar a Configuração de Segurança Reforçada do Internet Explorer. Esta medida de segurança não é aplicável ao Azure File Sync. Desativá-lo permite que você se autentique no Azure sem problemas.

Abra o PowerShell. Instale os módulos necessários do PowerShell usando os seguintes comandos. Certifique-se de instalar o módulo completo e o provedor NuGet quando for solicitado.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Se você tiver algum problema para acessar a internet a partir do seu servidor, agora é a hora de resolvê-los. A Sincronização de Ficheiros do Azure utiliza qualquer ligação de rede disponível à Internet. Exigir um servidor proxy para acessar a Internet também é suportado. Você pode configurar um proxy em toda a máquina agora ou, durante a instalação do agente, especificar um proxy que somente o Azure File Sync usará.

Se configurar um proxy significa que você precisa abrir seus firewalls para o servidor, essa abordagem pode ser aceitável para você. No final da instalação do servidor, depois de concluir o registro do servidor, um relatório de conectividade de rede mostrará as URLs de ponto de extremidade exatas no Azure com as quais a Sincronização de Arquivos do Azure precisa se comunicar para a região selecionada. O relatório também explica por que razão é necessária comunicação. Você pode usar o relatório para bloquear os firewalls ao redor do servidor para URLs específicas.

Você também pode adotar uma abordagem mais conservadora, na qual você não abre os firewalls amplamente. Em vez disso, você pode limitar o servidor para se comunicar com namespaces DNS de nível superior. Para obter mais informações, consulte Configurações de proxy e firewall do Azure File Sync. Siga suas próprias práticas recomendadas de rede.

No final do assistente de instalação do servidor, um assistente de registro do servidor será aberto. Registre o servidor no recurso do Azure do Serviço de Sincronização de Armazenamento a partir de antes.

Essas etapas são descritas com mais detalhes no guia de implantação, que inclui os módulos do PowerShell que você deve instalar primeiro: Instalação do agente do Azure File Sync.

Use o agente mais recente. Você pode baixá-lo do Centro de Download da Microsoft: Azure File Sync Agent.

Após uma instalação bem-sucedida e o registro do servidor, você pode confirmar que concluiu esta etapa com êxito. Vá para o recurso Serviço de Sincronização de Armazenamento no portal do Azure. No menu à esquerda, vá para Servidores registrados. Você verá seu servidor listado lá.

Fase 6: Configurar a Sincronização de Arquivos do Azure no Windows Server

Seu Windows Server local registrado deve estar pronto e conectado à Internet para esse processo.

Esta etapa reúne todos os recursos e pastas que você configurou em sua instância do Windows Server durante as etapas anteriores.

  1. Inicie sessão no portal do Azure.
  2. Localize o recurso do Serviço de Sincronização de Armazenamento.
  3. Crie um novo grupo de sincronização dentro do recurso do Serviço de Sincronização de Armazenamento para cada compartilhamento de arquivos do Azure. Na terminologia do Azure File Sync, o compartilhamento de arquivos do Azure se tornará um ponto de extremidade de nuvem na topologia de sincronização que você está descrevendo com a criação de um grupo de sincronização. Ao criar o grupo de sincronização, dê-lhe um nome familiar para que você reconheça qual conjunto de arquivos sincroniza lá. Certifique-se de fazer referência ao compartilhamento de arquivos do Azure com um nome correspondente.
  4. Depois de criar o grupo de sincronização, uma linha para ele aparecerá na lista de grupos de sincronização. Selecione o nome (um link) para exibir o conteúdo do grupo de sincronização. Você verá seu compartilhamento de arquivos do Azure em Pontos de extremidade de nuvem.
  5. Localize o botão Adicionar ponto de extremidade do servidor. A pasta no servidor local que você provisionou se tornará o caminho para esse ponto de extremidade do servidor.

Importante

A hierarquização na nuvem é o recurso de Sincronização de Arquivos do Azure que permite que o servidor local tenha menos capacidade de armazenamento do que a armazenada na nuvem, mas tenha o namespace completo disponível. Dados localmente interessantes (quentes) também são armazenados em cache localmente para desempenho de acesso rápido. A hierarquização na nuvem é um recurso opcional por "ponto de extremidade do servidor" do Azure File Sync.

Aviso

Se você provisionou menos armazenamento no(s) volume(s) do servidor Windows do que os dados usados no dispositivo NAS, a hierarquização na nuvem é obrigatória. Se você não ativar a hierarquização na nuvem, seu servidor não liberará espaço para armazenar todos os arquivos. Defina sua política de hierarquização, temporariamente para a migração, para 99% de espaço livre de volume. Certifique-se de retornar às configurações de hierarquização da nuvem após a conclusão da migração e defini-la para um nível útil de mais longo prazo.

Repita as etapas de criação do grupo de sincronização e adição da pasta do servidor correspondente como um ponto de extremidade do servidor para todos os compartilhamentos de arquivos/locais de servidor do Azure que precisam ser configurados para sincronização.

Após a criação de todos os pontos de extremidade do servidor, a sincronização está funcionando. Você pode criar um arquivo de teste e vê-lo sincronizar do local do servidor para o compartilhamento de arquivos do Azure conectado (conforme descrito pelo ponto de extremidade de nuvem no grupo de sincronização).

Ambos os locais, as pastas do servidor e os compartilhamentos de arquivos do Azure, estão vazios e aguardando dados em qualquer local. Na próxima etapa, você começará a copiar arquivos para o Windows Server for Azure File Sync para movê-los para a nuvem. Caso você tenha ativado a hierarquização na nuvem, o servidor começará a hierarquizar os arquivos, caso você fique sem capacidade no(s) volume(s) local(is).

Fase 7: Copiar dados usando o Azure Storage Mover ou o RoboCopy

Agora você pode usar o Azure Storage Mover ou RoboCopy para copiar dados do seu dispositivo NAS para o Windows Server e usar o Azure File Sync para mover os dados para compartilhamentos de arquivos do Azure. Este guia usa o RoboCopy para a cópia inicial. Para usar o Azure Storage Mover em vez disso, consulte Migrar para compartilhamentos de arquivos do Azure SMB usando o Azure Storage Mover.

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

  • Identifique o primeiro local em seu dispositivo NAS.
  • Identifique a pasta correspondente no Windows Server que já tem a Sincronização de Arquivos do Azure configurada.
  • Inicie a cópia.

O comando RoboCopy a seguir copiará arquivos do armazenamento NAS para a pasta de destino do Windows Server. O Windows Server irá sincronizá-lo com o(s) compartilhamento(s) de arquivos do Azure.

Se você provisionou menos armazenamento no Windows Server do que os arquivos ocupam no dispositivo NAS, então você configurou a hierarquização na nuvem. À medida que o volume local do Windows Server fica cheio, a hierarquização na nuvem entra em ação e hierarquiza os arquivos que já foram sincronizados com êxito. A hierarquização na nuvem gerará espaço suficiente para continuar a cópia do dispositivo NAS. A hierarquização da nuvem verifica uma vez por hora o que foi sincronizado e para liberar espaço em disco para atingir os 99% de espaço livre de volume.

É possível que o RoboCopy mova arquivos mais rápido do que você pode sincronizar com a nuvem e hierarquizar localmente, ficando assim sem espaço em disco local. Nesse caso, o RoboCopy falhará. Recomendamos que você trabalhe nos compartilhamentos em uma sequência que impeça isso - por exemplo, não iniciar trabalhos de cópia para todos os compartilhamentos ao mesmo tempo ou apenas mover compartilhamentos que se encaixem na quantidade atual de espaço livre no Windows Server.

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.
/LFSM Só para destinos com armazenamento escalonado. Não há suporte quando o destino é um compartilhamento SMB remoto.
Especifica que o Robocopy opera no "modo de pouco espaço livre". Essa opção é útil apenas para destinos com armazenamento hierárquico que podem ficar sem capacidade local antes que o Robocopy termine. Foi adicionado especificamente para utilização com um destino ativado para o arrumo na cloud do Azure File Sync. Pode ser utilizado independentemente do Azure File Sync. Neste modo, o Robocopy será colocado em pausa sempre que a cópia de um ficheiro possa fazer com que o espaço livre num volume de destino fique abaixo do valor “limite”. Este valor pode ser especificado pela /LFSM:n forma da bandeira. O parâmetro n é especificado na base 2: nKB, nMB, ou nGB. Se /LFSM for especificado sem valor de piso explícito, o piso será definido como 10% do tamanho do volume de destino. O modo de pouco espaço livre não é compatível com /MT, /EFSRAWou /ZB. O suporte para /B foi adicionado no Windows Server 2022. Consulte a seção Windows Server 2022 e RoboCopy LFSM abaixo para obter mais informações, incluindo detalhes sobre um bug relacionado e solução alternativa.
/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.

Fase 8: 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 podem alterá-los. É 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 para o Windows Server e para a nuvem através da Sincronização de Ficheiros do Azure. Esta primeira cópia pode demorar muito tempo, dependendo de:

  • sua largura de banda de download
  • a largura de banda de upload
  • a velocidade da rede local e o número ideal de threads do RoboCopy
  • o número de itens (arquivos e pastas) que precisam ser processados pelo RoboCopy e pelo Azure File Sync

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

Na segunda vez vai terminar mais rápido, porque só precisa de transportar mudanças que aconteceram desde a última corrida. Durante esta segunda execução, novas alterações ainda podem se acumular.

Repita esse processo até ter certeza de que o tempo necessário para concluir um RoboCopy para um local específico está dentro de uma janela aceitável para tempo de inatividade.

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 possam ter sido perdidas. 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 você tiver um NAS ingressado em domínio de classe empresarial, os SIDs do usuário corresponderão automaticamente, pois os usuários existem 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. (Dependendo do seu mapeamento da Fase 1)

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

Aviso

Depois de mover todos os dados do NAS para o Windows Server e a migração estiver concluída: retorne a todos os grupos de sincronização no portal do Azure e ajuste o valor percentual de espaço livre do volume hierárquico na nuvem para algo mais adequado para a utilização do cache, por exemplo, 20%.

A política de espaço livre de volume hierárquico na nuvem atua em um nível de volume com potencialmente vários pontos de extremidade de servidor sincronizados a partir dela. Se você esquecer de ajustar o espaço livre em até mesmo um ponto de extremidade do servidor, a sincronização continuará a aplicar a regra mais restritiva e tentará manter 99% de espaço livre em disco, fazendo com que o cache local não tenha o desempenho esperado. A menos que seu objetivo seja ter apenas o namespace para um volume que contenha apenas dados de arquivamento raramente acessados e você esteja reservando o restante do espaço de armazenamento para outro cenário.

Resolver problemas

O problema mais provável que você pode encontrar é que o comando RoboCopy falha com "Volume cheio" no lado do Windows Server. A hierarquização na nuvem atua uma vez a cada hora para evacuar o conteúdo do disco local do Windows Server sincronizado. Seu objetivo é atingir seus 99% de espaço livre no volume.

Permita que o progresso da sincronização e a hierarquização da nuvem liberem espaço em disco. Você pode observar isso no Explorador de Arquivos no seu Windows Server.

Quando o Windows Server tiver capacidade disponível suficiente, executar novamente o comando resolverá o problema. Nada quebra quando você entra nessa situação, e você pode avançar com confiança. O inconveniente de executar o comando novamente é a única consequência.

Verifique o link na seção a seguir para solucionar problemas do Azure File Sync.

Próximos passos

Os artigos a seguir ajudarão você a entender as opções de implantação, as práticas recomendadas e as etapas de solução de problemas.