Planejar uma implantação do Azure File Sync

Os arquivos são armazenados na nuvem em compartilhamentos de arquivos do Azure. Você pode usar os compartilhamentos de arquivos do Azure das duas maneiras a seguir. A opção de implantação escolhida altera os aspetos que você precisa considerar ao planejar sua implantação.

• Monte diretamente um compartilhamento de arquivos do Azure usando o protocolo SMB (Server Message Block): como os Arquivos do Azure fornecem acesso SMB, você pode montar compartilhamentos de arquivos do Azure no local ou na nuvem usando o cliente SMB padrão disponível no Windows, macOS e Linux. Como os compartilhamentos de arquivos do Azure não têm servidor, a implantação para cenários de produção não requer o gerenciamento de um servidor de arquivos ou de um dispositivo de armazenamento conectado à rede (NAS). Essa opção significa que você não precisa aplicar patches de software ou trocar discos físicos.

• Armazenar em cache um compartilhamento de arquivos do Azure local usando a Sincronização de Arquivos do Azure: com a Sincronização de Arquivos do Azure, você pode centralizar os compartilhamentos de arquivos da sua organização nos Arquivos do Azure, mantendo a flexibilidade, o desempenho e a compatibilidade de um servidor de arquivos local. O Azure File Sync transforma uma instância do Windows Server local (ou na nuvem) em um cache rápido do seu compartilhamento de arquivos do Azure.

Conceitos de gestão

No Azure, um recurso é um item gerenciável que você cria e configura em suas assinaturas e grupos de recursos do Azure. Os recursos são oferecidos por provedores de recursos, que são serviços de gerenciamento que fornecem tipos específicos de recursos. Para implantar o Azure File Sync, você trabalhará com dois recursos principais:

• Contas de armazenamento, oferecidas pelo provedor de Microsoft.Storage recursos. As contas de armazenamento são recursos de nível superior que representam um pool compartilhado de armazenamento, IOPS e taxa de transferência no qual você pode implantar compartilhamentos de arquivos clássicos ou outros recursos de armazenamento, dependendo do tipo de conta de armazenamento. Todos os recursos de armazenamento implantados em uma conta de armazenamento compartilham os limites que se aplicam a essa conta de armazenamento. Os compartilhamentos de arquivos clássicos dão suporte aos protocolos de compartilhamento de arquivos SMB e NFS, mas você só pode usar o Azure File Sync com compartilhamentos de arquivos SMB.

  Observação

  Os Arquivos do Azure também dão suporte à implantação de compartilhamentos de arquivos como recursos de nível superior do Azure por meio do provedor de Microsoft.FileShares recursos, no entanto, esses compartilhamentos de arquivos suportam apenas o protocolo do sistema de arquivos NFS e não são suportados pela Sincronização de Arquivos do Azure.

• Serviços de sincronização de armazenamento, oferecidos pelo provedor de Microsoft.StorageSync recursos. Os Serviços de Sincronização de Armazenamento atuam como contêineres de gerenciamento que permitem registrar Servidores de Arquivos do Windows e definir as relações de sincronização para a Sincronização de Arquivos do Azure.

Conceitos de gerenciamento de compartilhamento de arquivos do Azure

Os compartilhamentos de arquivos clássicos, ou compartilhamentos de arquivos implantados em contas de armazenamento, são a maneira tradicional de implantar compartilhamentos de arquivos para Arquivos do Azure. Suportam todas as principais funcionalidades suportadas pelos Ficheiros do Azure, incluindo níveis de multimédia SMB e NFS, SSD e HDD, todos os tipos de redundância e em todas as regiões. Para saber mais sobre compartilhamentos de arquivos clássicos, consulte compartilhamentos de arquivos clássicos.

Há dois tipos principais de contas de armazenamento usados para implantações clássicas de compartilhamento de arquivos:

• Contas de armazenamento provisionado: as contas de armazenamento provisionado são distinguidas usando o FileStorage tipo de conta de armazenamento. As contas de armazenamento provisionadas permitem implantar compartilhamentos de arquivos clássicos provisionados em hardware baseado em SSD ou HDD. As contas de armazenamento provisionadas só podem ser usadas para armazenar compartilhamentos de arquivos clássicos e não podem ser usadas para armazenar outros recursos de armazenamento, como contêineres de blob, filas e tabelas. Recomendamos o uso de contas de armazenamento provisionadas para todas as novas implantações clássicas de compartilhamento de arquivos.
• Contas de armazenamento pré-pagas: as contas de armazenamento pré-pagas são distinguidas usando o StorageV2 tipo de conta de armazenamento. As contas de armazenamento pré-pagas permitem-lhe implementar partilhas de ficheiros pré-pagas em hardware baseado em HDD. As contas de armazenamento pré-pagas podem ser usadas para armazenar compartilhamentos de arquivos clássicos e outros recursos de armazenamento, como contêineres de blob, filas ou tabelas.

Conceitos de gerenciamento do Azure File Sync

Em um Serviço de Sincronização de Armazenamento, você pode implantar:

• Servidores registrados, que representam um Servidor de Arquivos do Windows com uma relação de confiança com o Serviço de Sincronização de Armazenamento. Os servidores registrados podem ser um servidor individual ou cluster, no entanto, um servidor/cluster só pode ser registrado com apenas um Serviço de Sincronização de Armazenamento de cada vez.

• Grupos de sincronização, que define a relação de sincronização entre um ponto de extremidade na nuvem e um ou mais pontos de extremidade do servidor. Os pontos finais num grupo de sincronização são mantidos sincronizados entre si. Se, por exemplo, você tiver dois conjuntos distintos de arquivos que deseja gerenciar com a Sincronização de Arquivos do Azure, criará dois grupos de sincronização e adicionará pontos de extremidade diferentes a cada grupo de sincronização.

  • Pontos de extremidade de nuvem, que representam compartilhamentos de arquivos do Azure.
  • Pontos de extremidade de servidor, que representam caminhos em servidores registrados que são sincronizados com os Arquivos do Azure. Um servidor registrado pode conter vários pontos de extremidade de servidor se seus namespaces não se sobrepuserem.

Contagem de serviços de sincronização de armazenamento necessários

Um serviço de sincronização de armazenamento é o recurso raiz do Azure Resource Manager para a Sincronização de Arquivos do Azure. Ele gerencia as relações de sincronização entre suas instalações do Windows Server e os compartilhamentos de arquivos do Azure. Cada serviço de sincronização de armazenamento pode conter vários grupos de sincronização e vários servidores registrados.

Cada instância do Windows Server pode ser registrada em apenas um serviço de sincronização de armazenamento. Após o registro, o servidor pode participar de vários grupos de sincronização dentro desse serviço de sincronização de armazenamento usando uma entidade do Gerenciador de Recursos para criar pontos de extremidade de servidor no servidor.

Ao projetar topologias do Azure File Sync, certifique-se de isolar os dados claramente no nível do serviço de sincronização de armazenamento. Por exemplo, se sua empresa exigir ambientes separados do Azure File Sync para duas unidades de negócios distintas e você precisar de isolamento de dados estrito entre esses grupos, crie um serviço de sincronização de armazenamento dedicado para cada grupo. Evite colocar grupos de sincronização para ambos os grupos de negócios no mesmo serviço de sincronização de armazenamento, porque essa configuração não garantiria o isolamento completo.

Para obter mais orientações sobre isolamento de dados usando assinaturas ou grupos de recursos separados no Azure, consulte Tipos e provedores de recursos do Azure.

Planejando topologias de sincronização equilibradas

Antes de implantar quaisquer recursos, é importante planejar o que você sincronizará em um servidor local e com qual compartilhamento de arquivos do Azure. Fazer um plano ajuda a determinar quantas contas de armazenamento, compartilhamentos de arquivos do Azure e recursos de sincronização você precisa. Essas considerações são relevantes mesmo que seus dados não residam atualmente em uma instância do Windows Server ou no servidor que você deseja usar a longo prazo. A seção de migração deste artigo pode ajudá-lo a determinar os caminhos de migração apropriados para sua situação.

Nesta etapa, você determina 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.

É possível que você tenha mais pastas nos seus volumes que partilha localmente como partilhas SMB para os seus utilizadores e aplicações. A maneira mais fácil de visualizarmos este cenário é imaginarmos uma partilha local que corresponde 1:1 a uma partilha de ficheiros 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 partilhas

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, você precisa apenas de um único compartilhamento de arquivos do Azure na nuvem 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 o volume raiz 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 é 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 de uma sincronização) podem ser detetadas e sincronizadas mais rapidamente.

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 informa 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 otimizar seu mapa e decidir quantos compartilhamentos de arquivos do Azure você precisa, revise os seguintes limites e práticas recomendadas:

• 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 transforma a conta de armazenamento num alvo 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, esse mapeamento nem sempre pode ser possível devido a vários limites e restrições, tanto da sua organização quanto do Azure. Quando não for possível implantar apenas um compartilhamento de arquivos em uma conta de armazenamento, considere quais compartilhamentos serão altamente ativos e quais compartilhamentos serão menos ativos. Não junte os compartilhamentos de arquivos mais quentes na mesma conta de armazenamento.

  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.

É possível que, na sua situação, um conjunto de pastas possa sincronizar logicamente com o mesmo compartilhamento de arquivos do Azure (usando a abordagem de raiz comum mencionada anteriormente). Mas ainda pode ser melhor reagrupar pastas para que elas sincronizem com dois compartilhamentos de arquivos do Azure em vez de um. 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 entre mais servidores locais, para adicionar 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

Criar uma tabela de mapeamento

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 a perda de detalhes do seu plano de mapeamento pode acontecer facilmente 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.

Baixe um modelo de mapeamento de namespace.

Considerações para servidores de arquivos do Windows

Para habilitar o recurso de sincronização no Windows Server, você deve instalar o agente baixável do Azure File Sync. O agente do Azure File Sync fornece dois componentes principais:

• FileSyncSvc.exe, o serviço em segundo plano do Windows responsável por monitorar alterações nos pontos de extremidade do servidor e iniciar sessões de sincronização
• StorageSync.sys, um filtro de sistema de arquivos que permite a hierarquização na nuvem e a rápida recuperação de desastres

Requisitos do sistema operacional

O Azure File Sync é suportado com as seguintes versões do Windows Server:

Recomendamos manter todos os servidores que você usa com o Azure File Sync atualizados com as atualizações mais recentes do Windows Update.

Recursos mínimos do sistema

O Azure File Sync requer um servidor, físico ou virtual, com todos estes atributos:

• Pelo menos uma CPU.
• Um mínimo de 2 GiB de memória. Se o servidor estiver sendo executado em uma máquina virtual com memória dinâmica habilitada, configure a VM com um mínimo de 2.048 MiB de memória.
• Um volume anexado localmente formatado com o sistema de arquivos NTFS.

Para a maioria das cargas de trabalho de produção, não recomendamos configurar um servidor de sincronização no Azure File Sync apenas com os requisitos mínimos.

Recursos do sistema recomendados

Assim como qualquer recurso ou aplicativo de servidor, a escala da implantação determina os requisitos de recursos do sistema para a Sincronização de Arquivos do Azure. Implantações maiores em um servidor exigem maiores recursos do sistema.

Para a Sincronização de Arquivos do Azure, o número de objetos nos pontos de extremidade do servidor e a rotatividade no conjunto de dados determinam a escala. Um único servidor pode ter pontos de extremidade de servidor em vários grupos de sincronização. O número de objetos listados na tabela a seguir contabiliza o namespace completo ao qual um servidor está conectado.

Por exemplo, ponto de extremidade do servidor A com 10 milhões de objetos + ponto de extremidade do servidor B com 10 milhões de objetos = 20 milhões de objetos. Para esse exemplo de implantação, recomendamos 8 CPUs, 16 GiB de memória para o estado estacionário e (se possível) 48 GiB de memória para a migração inicial.

Os dados do namespace são armazenados na memória por motivos de desempenho. Devido a essa configuração, namespaces maiores exigem mais memória para manter um bom desempenho. Mais churn requer mais CPUs para processar.

A tabela a seguir fornece o tamanho do namespace e uma conversão em capacidade para compartilhamentos de arquivos típicos de uso geral, onde o tamanho médio do arquivo é de 512 KiB. Se os tamanhos dos seus ficheiros forem menores, considere adicionar mais memória para a mesma quantidade de capacidade. Baseie sua configuração de memória no tamanho do namespace.

*A sincronização de mais de 100 milhões de ficheiros e diretórios não é recomendada. Este é um limite suave com base nos nossos limiares testados. Para obter mais informações, consulte Destinos de escala do Azure File Sync.

Cmdlet de avaliação

Antes de implantar o Azure File Sync, você deve avaliar se ele é compatível com seu sistema usando o cmdlet de avaliação do Azure File Sync. Este cmdlet verifica possíveis problemas com o sistema de arquivos e o conjunto de dados, como caracteres sem suporte ou uma versão do sistema operacional sem suporte. Essas verificações abrangem a maioria (mas não todos) dos recursos mencionados neste artigo. Recomendamos que você leia o restante desta seção cuidadosamente para garantir que sua implantação ocorra sem problemas.

Você pode instalar o cmdlet evaluation instalando o módulo Az PowerShell. Para obter instruções, consulte Instalar o Azure PowerShell.

Utilização

Você pode invocar a ferramenta de avaliação executando verificações do sistema, verificações do conjunto de dados ou ambas. Para executar verificações do sistema e do conjunto de dados:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Para testar apenas o conjunto de dados:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Para testar apenas os requisitos do sistema:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Para exibir os resultados em um arquivo de .csv:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Compatibilidade do sistema de arquivos

A Sincronização de Ficheiros do Azure é suportada apenas em volumes NTFS diretamente ligados. O armazenamento com conexão direta (DAS) no Windows Server significa que o sistema operacional Windows Server é o proprietário do sistema de arquivos. Você pode fornecer DAS anexando fisicamente discos ao servidor de arquivos, anexando discos virtuais a uma VM de servidor de arquivos (como uma VM hospedada por Hyper-V) ou até mesmo usando iSCSI.

Apenas volumes NTFS são suportados. ReFS, FAT, FAT32 e outros sistemas de arquivos não são suportados.

A tabela a seguir mostra o estado de interoperabilidade dos recursos do sistema de arquivos NTFS:

O Azure File Sync também ignora determinados arquivos temporários e pastas do sistema:

Espaço livre no disco local

Quando você estiver planejando usar a Sincronização de Arquivos do Azure, considere quanto espaço livre você precisa no disco local para seu ponto de extremidade do servidor.

Com a Sincronização de Arquivos do Azure, você precisa levar em conta os seguintes itens que ocupam espaço no disco local:

• Com a hierarquização na nuvem ativada:

  • Pontos de reparsagem para ficheiros escalonados
  • Banco de dados de metadados do Azure File Sync
  • Armazenamento térmico do Azure File Sync
  • Arquivos totalmente baixados em seu hot cache (se houver)
  • Requisitos de política para espaço livre de volume

• Com a hierarquização na nuvem desativada:

  • Arquivos totalmente baixados
  • Armazenamento térmico do Azure File Sync
  • Banco de dados de metadados do Azure File Sync

O exemplo a seguir ilustra como estimar a quantidade de espaço livre necessária no disco local. Digamos que você instalou seu agente do Azure File Sync em sua VM do Windows do Azure e planeja criar um ponto de extremidade de servidor no disco F. Você tem 1 milhão de arquivos (e deseja hierarquizar todos eles), 100.000 diretórios e um tamanho de cluster de disco de 4 KiB. O tamanho do disco é de 1.000 GiB. Você deseja habilitar a hierarquização na nuvem e definir sua política de espaço livre de volume para 20%.

• O NTFS aloca um tamanho de cluster para cada um dos arquivos hierárquicos:

  1 milhão de arquivos * Tamanho do cluster de 4 KiB = 4.000.000 KiB (4 GiB)

  Para se beneficiar totalmente da hierarquização na nuvem, recomendamos que você use tamanhos de cluster NTFS menores (menos de 64 KiB) porque cada arquivo hierárquico ocupa um cluster. Além disso, o NTFS aloca o espaço que os arquivos hierárquicos ocupam. Esse espaço não aparece em nenhuma interface do usuário.

• Os metadados de sincronização ocupam um tamanho de cluster por item:

  (1 milhão de arquivos + 100.000 diretórios) * Tamanho do cluster de 4 KiB = 4.400.000 KiB (4,4 GiB)

• O heatstore do Azure File Sync ocupa 1,1 KiB por ficheiro:

  1 milhão de ficheiros * 1,1 KiB = 1.100.000 KiB (1,1 GiB)

• A política de espaço livre por volume é de 20%:

  1000 GiB * 0,2 = 200 GiB

Nesse caso, o Azure File Sync precisaria de cerca de 209.500.000 KiB (209,5 GiB) de espaço para esse namespace. Adicione esta quantidade a qualquer espaço livre que considere necessitar para este disco.

Clusterização de failover

A Sincronização de Arquivos do Azure dá suporte ao clustering de failover do Windows Server para a opção de implantação do Servidor de Arquivos para uso geral . Para obter mais informações sobre como configurar o Servidor de Arquivos para a função de uso geral em um cluster de failover, consulte Implantar um servidor de arquivos clusterizado de dois nós.

O único cenário que o Azure File Sync suporta é um cluster de failover do Windows Server com discos clusterizados. Não há suporte para clustering de failover em Scale-Out Servidor de Arquivos, Volumes Compartilhados de Cluster (CSVs) ou discos locais.

Para que a sincronização funcione corretamente, o agente do Azure File Sync deve ser instalado em cada nó de um cluster de failover.

Desduplicação de dados

Windows Server 2025, Windows Server 2022, Windows Server 2019 e Windows Server 2016

A Desduplicação de Dados é suportada independentemente de a hierarquização na nuvem estar habilitada ou desabilitada em um ou mais pontos de extremidade de servidor no volume para Windows Server 2025, Windows Server 2022, Windows Server 2019 e Windows Server 2016. Habilitar a desduplicação de dados em um volume com a hierarquização na nuvem habilitada permite armazenar em cache mais arquivos no local sem provisionar mais armazenamento.

Quando você habilita a Desduplicação de Dados em um volume com a hierarquização na nuvem habilitada, os arquivos otimizados para desduplicação no local do ponto de extremidade do servidor são hierarquizados de forma semelhante a um arquivo normal, com base nas configurações de política para hierarquização na nuvem. Depois de hierarquizar os arquivos otimizados para desduplicação, o trabalho de coleta de lixo de Desduplicação de Dados é executado automaticamente. Ele recupera espaço em disco removendo partes desnecessárias que outros arquivos no volume não fazem mais referência.

Em alguns casos em que a Desduplicação de Dados está instalada, o espaço de volume disponível pode aumentar mais do que o esperado depois que a coleta de lixo de desduplicação é acionada. O exemplo a seguir descreve como o espaço de volume funciona:

1. A política de espaço livre para hierarquização na nuvem está definida como 20%.
2. O Azure File Sync é notificado quando o espaço livre está baixo (digamos 19%).
3. A hierarquização determina que 1% mais espaço precisa ser liberado, mas você quer 5% extra, então você hierarquiza até 25% (por exemplo, 30 GiB).
4. Os arquivos são hierarquizados até atingir 30 GiB.
5. Como parte da interoperabilidade com a Desduplicação de Dados, o Azure File Sync inicia a coleta de lixo no final da sessão de hierarquização.

A economia de volume se aplica apenas ao servidor. Seus dados no compartilhamento de arquivos do Azure não são desduplicados.

Windows Server 2012 R2

A Sincronização de Ficheiros do Azure não suporta a Eliminação de Duplicação de Dados e a hierarquização na nuvem no mesmo volume no Windows Server 2012 R2. Se você habilitar a Desduplicação de Dados em um volume, deverá desabilitar a hierarquização na nuvem.

Observações

• Se você instalar a Desduplicação de Dados antes de instalar o agente do Azure File Sync, uma reinicialização será necessária para dar suporte à Eliminação de Duplicação de Dados e à hierarquização na nuvem no mesmo volume.

• Se você habilitar a Desduplicação de Dados em um volume depois de habilitar a hierarquização na nuvem, o trabalho inicial de otimização da desduplicação otimizará os arquivos no volume que ainda não estão hierarquizados. Este trabalho tem o seguinte impacto na hierarquização da nuvem:

  • A política de espaço livre continua a hierarquizar os arquivos de acordo com o espaço livre no volume usando o mapa de calor.
  • A política de data ignora a hierarquização de arquivos que, de outra forma, poderiam ser qualificados para hierarquização porque o trabalho de otimização de desduplicação está acessando os arquivos.

• Para trabalhos contínuos de otimização de desduplicação, a configuração Data Deduplication MinimumFileAgeDays atrasa a hierarquização da nuvem com a política de dados, se o arquivo ainda não estiver hierárquico.

  • Por exemplo, se a configuração for de MinimumFileAgeDays 7 dias e a política de dados para hierarquização na nuvem for de 30 dias, a política de data será arquivada após 37 dias.
  • Depois que o Azure File Sync hierarquiza um arquivo, o trabalho de otimização de desduplicação ignora o arquivo.

• Se um servidor que executa o Windows Server 2012 R2 com o agente de Sincronização de Arquivos do Azure instalado for atualizado para o Windows Server 2025, Windows Server 2022, Windows Server 2019 ou Windows Server 2016, você deverá executar as seguintes etapas para dar suporte à Eliminação de Duplicação de Dados e à hierarquização na nuvem no mesmo volume:

  1. Desinstale o agente de Sincronização de Arquivos do Azure para Windows Server 2012 R2 e reinicie o servidor.
  2. Baixe o agente do Azure File Sync para a nova versão do sistema operacional do servidor (Windows Server 2025, Windows Server 2022, Windows Server 2019 ou Windows Server 2016).
  3. Instale o agente do Azure File Sync e reinicie o servidor.

  O servidor mantém suas definições de configuração do Azure File Sync quando o agente é desinstalado e reinstalado.

Distributed File System

A Sincronização de Ficheiros do Azure suporta a interoperabilidade com Espaços de Nomes DFS (DFS-N) e Replicação DFS (DFS-R).

DFS-N

O Azure File Sync é totalmente suportado com a implementação DFS-N. Você pode instalar o agente do Azure File Sync em um ou mais servidores de arquivos para sincronizar dados entre os pontos de extremidade do servidor e o ponto de extremidade da nuvem e, em seguida, usar DFS-N para fornecer serviço de namespace. Para obter mais informações, consulte Visão geral de Namespaces DFS e Namespaces DFS com Arquivos do Azure.

DFS-R

Como o DFS-R e o Azure File Sync são soluções de replicação, recomendamos substituir DFS-R pelo Azure File Sync na maioria dos casos. Mas você deve usar o DFS-R e o Azure File Sync juntos nos seguintes cenários:

• Você está migrando de uma implantação do DFS-R para uma implantação do Azure File Sync. Para obter mais informações, consulte Migrar uma implantação de DFS-R para o Azure File Sync.
• Nem todos os servidores locais que precisam de uma cópia dos dados do arquivo podem ser conectados diretamente à Internet.
• Os servidores de filial consolidam dados em um único servidor de hub, para o qual você deseja usar a Sincronização de Arquivos do Azure.

Para que o Azure File Sync e o DFS-R trabalhem lado a lado:

• A hierarquização na nuvem do Azure File Sync deve ser desativada em volumes que contenham pastas replicadas DFS-R.
• Os endpoints do servidor não devem ser configurados em pastas de replicação de apenas leitura DFS-R.
• Apenas um único ponto de extremidade de servidor pode sobrepor-se a um local de DFS-R. Vários pontos de extremidade de servidor que se sobrepõem a outros locais de DFS-R ativos podem levar a conflitos.

Para obter mais informações, consulte Visão geral de Namespaces DFS e Replicação DFS.

Sysprep

O uso do Sysprep em um servidor que tenha o agente do Azure File Sync instalado não é suportado e pode levar a resultados inesperados. A instalação do agente e o registro do servidor devem ocorrer após a implantação da imagem do servidor e a conclusão da miniconfiguração do Sysprep.

Windows Search

Se a hierarquização na nuvem estiver habilitada em um ponto de extremidade do servidor, o Windows Search ignorará os arquivos hierárquicos e não os indexará. O Windows Search indexa arquivos não hierárquicos corretamente.

Os clientes Windows causam recalls quando pesquisam o compartilhamento de arquivos se a configuração Sempre pesquisar nomes de arquivo e conteúdo estiver habilitada na máquina cliente. Essa configuração está desabilitada por padrão.

Outras soluções HSM

Você não deve usar nenhuma outra solução de gerenciamento de armazenamento hierárquico (HSM) com o Azure File Sync.

Desempenho e Escalabilidade   

Como o agente do Azure File Sync é executado em uma máquina Windows Server que se conecta aos compartilhamentos de arquivos do Azure, o desempenho de sincronização eficaz depende desses fatores em sua infraestrutura:

• Windows Server e a configuração de disco subjacente
• Largura de banda de rede entre o servidor e o armazenamento do Azure
• Tamanho do ficheiro
• Tamanho total do conjunto de dados
• Atividade no conjunto de dados

O Azure File Sync funciona no nível do arquivo. As características de desempenho de uma solução baseada no Azure File Sync são melhor medidas no número de objetos (arquivos e diretórios) processados por segundo.

Para obter mais informações, consulte Métricas de desempenho do Azure File Sync e Destinos de escala do Azure File Sync

Identidade

O administrador que registra o servidor e cria o ponto de extremidade na nuvem deve ser membro da função de gerenciamento Administrador, Proprietário ou Colaborador do Azure File Sync para o serviço de sincronização de armazenamento. Você pode configurar essa função em Controle de Acesso (IAM) na página do portal do Azure para o serviço de sincronização de armazenamento.

A Sincronização de Ficheiros do Azure funciona com a sua identidade padrão baseada no Ative Directory sem qualquer configuração especial para além da configuração da sincronização. Quando você estiver usando o Azure File Sync, a expectativa geral é que a maioria dos acessos passe pelos servidores de cache do Azure File Sync, em vez de pelo compartilhamento de arquivos do Azure. Como os pontos de extremidade do servidor estão no Windows Server e o Windows Server oferece suporte ao Ative Directory e a ACLs no estilo do Windows, você não precisa de nada além de garantir que os servidores de arquivos do Windows registrados no serviço de sincronização de armazenamento ingressem no domínio. O Azure File Sync armazena ACLs nos arquivos no compartilhamento de arquivos do Azure e replica essas ACLs para todos os pontos de extremidade do servidor.

Embora as alterações feitas diretamente no compartilhamento de arquivos do Azure levem mais tempo para sincronizar com os pontos de extremidade do servidor no grupo de sincronização, você também pode querer garantir que você possa impor suas permissões do Ative Directory em seu compartilhamento de arquivos diretamente na nuvem. Para fazer essa configuração, você deve associar sua conta de armazenamento à sua instância do Ative Directory local, assim como os servidores de arquivos do Windows são associados ao domínio. Para saber mais sobre como associar sua conta de armazenamento a uma instância do Ative Directory de propriedade do cliente, consulte Visão geral da autenticação baseada em identidade dos Arquivos do Azure para acesso SMB.

Redes

O agente do Azure File Sync se comunica com seu serviço de sincronização de armazenamento e compartilhamento de arquivos do Azure usando o protocolo REST do Azure File Sync e o protocolo FileREST. Ambos os protocolos sempre usam HTTPS pela porta 443. O SMB nunca é usado para carregar ou baixar dados entre sua instância do Windows Server e o compartilhamento de arquivos do Azure. Como a maioria das organizações permite o tráfego HTTPS pela porta 443 como um requisito para visitar a maioria dos sites, uma configuração de rede especial geralmente não é necessária para implantar o Azure File Sync.

Com base na política da sua organização ou nos requisitos regulamentares exclusivos, poderá necessitar de uma comunicação mais restritiva com o Azure. A Sincronização de Arquivos do Azure fornece vários mecanismos para você configurar redes. Com base em suas necessidades, você pode:

• Sincronização de túnel e tráfego de carregamento/download de arquivos pelo Azure ExpressRoute ou uma rede virtual privada (VPN) do Azure.
• Faça uso dos Arquivos do Azure e dos recursos de rede do Azure, como pontos de extremidade de serviço e pontos de extremidade privados.
• Configure o Azure File Sync para dar suporte ao seu proxy em seu ambiente.
• Acelere a atividade de rede a partir da Sincronização de Ficheiros do Azure.

Se você quiser se comunicar com seu compartilhamento de arquivos do Azure pelo SMB, mas a porta 445 estiver bloqueada, considere usar o SMB sobre QUIC. Esse método oferece uma VPN de configuração zero para acesso SMB aos seus compartilhamentos de arquivos do Azure por meio do protocolo de transporte QUIC pela porta 443. Embora o Azure Files não ofereça suporte direto ao SMB sobre QUIC, você pode criar um cache leve de seus compartilhamentos de arquivos do Azure em uma VM do Windows Server 2022 Azure Edition usando a Sincronização de Arquivos do Azure. Para saber mais sobre essa opção, consulte SMB sobre QUIC.

Para saber mais sobre o Azure File Sync e redes, consulte Considerações de rede para o Azure File Sync.

Encriptação

O Azure File Sync oferece três camadas de criptografia: criptografia no armazenamento em repouso do Windows Server, criptografia em trânsito entre o agente do Azure File Sync e o Azure e criptografia em repouso para seus dados no compartilhamento de arquivos do Azure.

Criptografia do Windows Server em repouso

Duas estratégias para criptografar dados no Windows Server funcionam geralmente com a Sincronização de Arquivos do Azure:

• Encriptação por baixo do sistema de ficheiros, de modo a que o sistema de ficheiros e todos os dados nele gravados sejam encriptados
• Encriptação dentro do próprio formato de ficheiro

Esses métodos não são mutuamente exclusivos. Você pode optar por usá-los juntos porque a finalidade da criptografia é diferente.

Para fornecer criptografia sob o sistema de arquivos, o Windows Server fornece uma caixa de entrada do BitLocker. O BitLocker é totalmente transparente para a Sincronização de Arquivos do Azure. Os principais motivos para usar um mecanismo de criptografia como o BitLocker são:

• Impeça a exfiltração física de dados do seu datacenter local por alguém roubando os discos
• Impeça o sideload de um sistema operacional não autorizado para executar leituras e gravações não autorizadas em seus dados

Para saber mais, consulte Visão geral do BitLocker.

Os produtos de parceiros que funcionam de forma semelhante ao BitLocker, na medida em que ficam abaixo do volume NTFS, devem funcionar de forma total e transparente com a Sincronização de Ficheiros do Azure.

O outro método principal para criptografar dados é criptografar o fluxo de dados do arquivo quando o aplicativo salva o arquivo. Alguns aplicativos podem fazer essa tarefa nativamente, mas geralmente não fazem.

Exemplos de métodos para criptografar o fluxo de dados do arquivo são a Proteção de Informações do Azure, o Azure Rights Management (Azure RMS) e o Ative Directory Rights Management Services. A principal razão para usar um mecanismo de criptografia como a Proteção de Informações do Azure ou o Azure RMS é impedir a exfiltração de dados do seu compartilhamento de arquivos por pessoas que os copiam para locais alternativos (como uma unidade flash) ou os enviam por e-mail para uma pessoa não autorizada. Quando o fluxo de dados de um arquivo é criptografado como parte do formato de arquivo, esse arquivo continua a ser criptografado no compartilhamento de arquivos do Azure.

A Sincronização de Ficheiros do Azure não interopera com o Sistema de Ficheiros Encriptados NTFS ou com soluções de encriptação de parceiros que ficam acima do sistema de ficheiros, mas abaixo do fluxo de dados do ficheiro.

Encriptação em trânsito

O agente do Azure File Sync se comunica com seu serviço de sincronização de armazenamento e compartilhamento de arquivos do Azure usando o protocolo REST do Azure File Sync e o protocolo FileREST. Ambos os protocolos sempre usam HTTPS pela porta 443. O Azure File Sync não envia solicitações não criptografadas por HTTP.

As contas de armazenamento do Azure contêm uma opção para exigir criptografia em trânsito. Esta opção está ativada por padrão. Mesmo que a mudança no nível da conta de armazenamento esteja desabilitada e conexões não criptografadas com seus compartilhamentos de arquivos do Azure sejam possíveis, a Sincronização de Arquivos do Azure ainda usa apenas canais criptografados para acessar seu compartilhamento de arquivos.

O principal motivo para desabilitar a criptografia em trânsito para a conta de armazenamento é dar suporte a um aplicativo herdado que se comunica diretamente com o compartilhamento de arquivos do Azure. Esse aplicativo deve ser executado em um sistema operacional mais antigo, como o Windows Server 2008 R2 ou uma distribuição Linux mais antiga. Se o aplicativo herdado se conectar ao cache do Windows Server do compartilhamento de arquivos, alterar essa configuração não terá efeito.

É altamente recomendável que você habilite a criptografia de dados em trânsito. Para obter mais informações sobre criptografia em trânsito, consulte Exigir transferência segura para garantir conexões seguras.

Criptografia de compartilhamento de arquivos do Azure em repouso

Todos os dados armazenados nos Arquivos do Azure são criptografados em repouso por meio da criptografia do lado do serviço (SSE) do Armazenamento do Azure. O SSE funciona de forma semelhante ao BitLocker no Windows: os dados são criptografados abaixo do nível do sistema de arquivos.

Como os dados são criptografados sob o sistema de arquivos do compartilhamento de arquivos do Azure, como são codificados no disco, você não precisa acessar a chave subjacente no cliente para ler ou gravar no compartilhamento de arquivos do Azure. A criptografia em repouso aplica-se aos protocolos SMB e NFS.

Por padrão, os dados armazenados nos Arquivos do Azure são criptografados com chaves gerenciadas pela Microsoft. Com chaves gerenciadas pela Microsoft, a Microsoft detém as chaves para criptografar e descriptografar os dados. A Microsoft é responsável por girar essas chaves regularmente.

Também pode optar por gerir as suas próprias chaves, o que lhe dá controlo sobre o processo de rotação. Se você optar por criptografar seus compartilhamentos de arquivos com chaves gerenciadas pelo cliente, os Arquivos do Azure estarão autorizados a acessar suas chaves para atender às solicitações de leitura e gravação de seus clientes. Com chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento. Mas, sem essa autorização, seu compartilhamento de arquivos do Azure não está mais acessível por meio do SMB ou da API FileREST.

Os Arquivos do Azure usam o mesmo esquema de criptografia que os outros serviços de Armazenamento do Azure, como o Armazenamento de Blobs do Azure. Para saber mais sobre o Azure Storage SSE, consulte Criptografia do Armazenamento do Azure para dados em repouso.

Camadas de armazenamento

O Azure Files oferece duas camadas de armazenamento de mídia: disco de estado sólido (SSD) e unidade de disco rígido (HDD). Esses níveis permitem que você adapte suas ações aos requisitos de desempenho e preço do seu cenário:

• SSD (premium): As partilhas de ficheiros SSD proporcionam um elevado desempenho consistente e baixa latência, em milissegundos de um dígito para a maioria das operações de E/S, para cargas de trabalho intensivas de E/S. Os compartilhamentos de arquivos SSD são adequados para uma ampla variedade de cargas de trabalho, como bancos de dados, hospedagem de sites e ambientes de desenvolvimento.

  Você pode usar compartilhamentos de arquivos SSD com os protocolos SMB e NFS. Os compartilhamentos de arquivos SSD estão disponíveis nos modelos de faturamento provisionados v2 e v1 provisionados . As partilhas de ficheiros SSD oferecem um SLA de maior disponibilidade do que as partilhas de ficheiros HDD.

• HDD (padrão): As partilhas de ficheiros HDD fornecem uma opção de armazenamento económica para partilhas de ficheiros de uso geral. As partilhas de ficheiros HDD estão disponíveis com os modelos de faturação v2 epré-pago consoante a utilização , embora recomendemos o modelo v2 provisionado para novas implementações de partilhas de ficheiros. Para obter informações sobre o SLA, consulte a página do SLA do Azure para serviços online.

Ao selecionar uma camada de mídia para sua carga de trabalho, considere seus requisitos de desempenho e uso. Se a sua carga de trabalho exigir latência de um dígito, ou se estiver a utilizar meios de armazenamento SSD nas suas instalações, as partilhas de ficheiros SSD são provavelmente a melhor opção. Se a baixa latência não for tão preocupante, as partilhas de ficheiros HDD podem ser mais adequadas do ponto de vista dos custos. Por exemplo, a baixa latência pode ser menos preocupante com compartilhamentos de equipe montados no local a partir do Azure ou armazenados em cache no local por meio da Sincronização de Arquivos do Azure.

Depois de criar um compartilhamento de arquivos em uma conta de armazenamento, não é possível movê-lo diretamente para uma camada de mídia diferente. Por exemplo, para mover uma partilha de ficheiros HDD para o nível de multimédia SSD, tem de criar uma nova partilha de ficheiros SSD e copiar os dados da partilha original para a nova partilha de ficheiros.

Pode encontrar mais informações sobre os níveis de multimédia SSD e HDD em Compreender os modelos de faturação dos Ficheiros do Azure e Compreender e otimizar o desempenho da partilha de ficheiros do Azure.

Disponibilidade da região do Azure File Sync

Para disponibilidade regional, consulte Disponibilidade do produto por região e pesquise Contas de armazenamento.

As seguintes regiões exigem que você solicite acesso ao Armazenamento do Azure antes de poder usar a Sincronização de Arquivos do Azure:

• Sul de França
• Oeste da África do Sul
• E.A.U. Central

Para solicitar acesso para essas regiões, siga o processo neste artigo.

Redundância

Para ajudar a proteger os dados em seus compartilhamentos de arquivos do Azure contra perda ou corrupção de dados, os Arquivos do Azure armazenam várias cópias de cada arquivo à medida que são gravados. Dependendo de suas necessidades, você pode selecionar graus de redundância. Atualmente, o Azure Files dá suporte às seguintes opções de redundância de dados:

• LRS (armazenamento com redundância local): com redundância local, cada arquivo é armazenado três vezes em um cluster de armazenamento do Azure. Essa abordagem ajuda a proteger contra perda de dados devido a falhas de hardware, como uma unidade de disco defeituosa. No entanto, se ocorrer um desastre, como incêndio ou inundação, no datacenter, todas as réplicas de uma conta de armazenamento que usa o LRS poderão ser perdidas ou irrecuperáveis.

• Armazenamento com redundância de zona (ZRS): com redundância de zona, três cópias de cada arquivo são armazenadas. No entanto, essas cópias são fisicamente isoladas em três clusters de armazenamento distintos nas zonas de disponibilidade do Azure. As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona consiste em um ou mais datacenters equipados com energia, resfriamento e rede independentes. Uma gravação no armazenamento não é aceita até que seja gravada nos clusters de armazenamento em todas as três zonas de disponibilidade.

• Armazenamento com redundância geográfica (GRS): com a redundância geográfica, você tem uma região primária e uma região secundária. Os arquivos são armazenados três vezes em um cluster de armazenamento do Azure na região primária. As escritas são replicadas de forma assíncrona para uma região secundária definida pela Microsoft.

  A redundância geográfica fornece seis cópias dos seus dados distribuídos entre as duas regiões do Azure. Se ocorrer um desastre de grandes proporções, como a perda permanente de uma região do Azure devido a um desastre natural ou outro evento semelhante, a Microsoft executará um failover. Neste caso, o secundário torna-se o primário e serve todas as operações.

  Como a replicação entre as regiões primária e secundária é assíncrona, se ocorrer um desastre grave, os dados ainda não replicados para a região secundária serão perdidos. Você também pode executar um failover manual de uma conta de armazenamento com redundância geográfica.

• Armazenamento com redundância de zona geográfica (GZRS): com a redundância de zona geográfica, os arquivos são armazenados três vezes em três clusters de armazenamento distintos na região primária. Todas as escritas são então replicadas de forma assíncrona para uma região secundária definida pela Microsoft. O processo de failover para redundância de zona geográfica funciona da mesma forma que para redundância geográfica.

As partilhas de ficheiros HDD suportam os quatro tipos de redundância. As partilhas de ficheiros SSD suportam apenas LRS e ZRS.

As contas de armazenamento pré-pagas fornecem duas outras opções de redundância que os Arquivos do Azure não suportam: armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e armazenamento redundante de zona geográfica de acesso de leitura (RA-GZRS). Você pode provisionar compartilhamentos de arquivos do Azure em contas de armazenamento com essas opções definidas, mas o Azure Files não oferece suporte à leitura da região secundária. Os compartilhamentos de arquivos do Azure implantados em contas de armazenamento RA-GRS ou RA-GZRS são cobrados como redundantes geográficos ou redundantes de zona geográfica, respectivamente.

Migração

Se você tiver um servidor de arquivos existente no Windows Server 2012 R2 ou mais recente, poderá instalar diretamente o Azure File Sync no local. Não é necessário mover dados para um novo servidor.

Se você planeja migrar para um novo servidor de arquivos do Windows como parte da adoção do Azure File Sync, ou se seus dados estão atualmente localizados no NAS, há várias abordagens de migração possíveis para usar o Azure File Sync com esses dados. A abordagem de migração que você deve escolher depende de onde seus dados residem atualmente.

Para obter orientações detalhadas, consulte Migrar para compartilhamentos de arquivos do Azure SMB.

Antivírus

Como o antivírus funciona verificando arquivos em busca de código mal-intencionado conhecido, um produto antivírus pode causar a recuperação de arquivos em camadas e altas taxas de saída. Os arquivos hierárquicos têm o atributo FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS seguro do Windows definido. Recomendamos consultar seu fornecedor de software para saber como configurar sua solução para ignorar a leitura de arquivos que tenham esse atributo definido. (Muitos fazem-no automaticamente.)

As soluções antivírus da Microsoft Windows Defender e System Center Endpoint Protection ignoram automaticamente a leitura de arquivos que têm esse atributo definido. Nós os testamos e identificamos um pequeno problema: quando você adiciona um servidor a um grupo de sincronização existente, arquivos menores que 800 bytes são recuperados (baixados) no novo servidor. Esses arquivos permanecem no novo servidor e não são hierarquizados porque não atendem ao requisito de tamanho de hierarquização (mais de 64 KiB).

Os fornecedores de antivírus podem verificar a compatibilidade entre seus produtos e o Azure File Sync usando o Azure File Sync Antivirus Compatibility Test Suite no Centro de Download da Microsoft.

Backup

Se você habilitar a hierarquização na nuvem, não use soluções que façam backup direto do ponto de extremidade do servidor ou de uma VM que contenha o ponto de extremidade do servidor.

A hierarquização na nuvem faz com que apenas um subconjunto dos seus dados seja armazenado no ponto de extremidade do servidor. O conjunto de dados completo reside em seu compartilhamento de arquivos do Azure. Dependendo da solução de backup usada, os arquivos hierárquicos são:

• Ignorado e sem backup, porque eles têm o FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS atributo definido
• Recolhido ao disco, o que resulta em altas cargas de saída

Recomendamos usar uma solução de backup na nuvem para fazer backup do compartilhamento de arquivos do Azure diretamente. Para obter mais informações, consulte Sobre o backup de arquivos do Azure. Ou pergunte ao seu provedor de backup se ele oferece suporte ao backup de compartilhamentos de arquivos do Azure.

Se preferir usar uma solução de backup local, execute os backups em um servidor do grupo de sincronização que tenha a hierarquização na nuvem desabilitada. Certifique-se de que não existem ficheiros em camadas.

Ao executar uma restauração, use a opção de restauração no nível do volume ou no nível do arquivo. Os ficheiros restaurados através da opção de restauro ao nível de ficheiro são sincronizados com todos os pontos finais no grupo de sincronização. Os ficheiros existentes são substituídos pela versão restaurada a partir da cópia de segurança. As restaurações no nível de volume não substituem versões de arquivo mais recentes no compartilhamento de arquivos do Azure ou em outros pontos de extremidade do servidor.

Classificação dos dados

Se você tiver um software de classificação de dados instalado, habilitar a hierarquização na nuvem aumentou os custos por dois motivos:

• Com a hierarquização na nuvem ativada, seus arquivos mais quentes são armazenados em cache localmente. Seus arquivos mais legais são hierarquizados para o compartilhamento de arquivos do Azure na nuvem. Se sua classificação de dados verifica regularmente todos os arquivos no compartilhamento de arquivos, os arquivos hierarquizados na nuvem devem ser recuperados sempre que forem verificados.
• Se o software de classificação de dados usar os metadados no fluxo de dados de um arquivo, o arquivo deve ser totalmente recuperado para que o software detete a classificação.

Estes aumentos, tanto no número de recolhas como na quantidade de dados recolhidos, podem aumentar os custos.

Política de atualização do agente do Azure File Sync

O agente do Azure File Sync é atualizado regularmente para adicionar novas funcionalidades e resolver problemas. Recomendamos atualizar o agente do Azure File Sync à medida que novas versões estiverem disponíveis.

Versões de agentes principais vs. secundários

• As versões principais do agente geralmente contêm novas funcionalidades e apresentam um número inicial crescente como a primeira parte do número da versão. Por exemplo: 18.0.0.0.
• As versões secundárias do agente também são chamadas de patches e são lançadas com mais frequência do que as versões principais. Eles geralmente contêm correções de bugs e melhorias menores, mas sem novos recursos. Por exemplo: 18.2.0.0.

Caminhos de atualização

Há cinco maneiras aprovadas e testadas de instalar as atualizações do agente do Azure File Sync:

• Use o recurso de atualização automática do Azure File Sync para instalar atualizações do agente: o agente do Azure File Sync é atualizado automaticamente. Você pode optar por instalar a versão mais recente do agente quando ela estiver disponível ou atualizar quando o agente atualmente instalado estiver perto da expiração. Para saber mais, consulte a próxima seção, Gerenciamento automático do ciclo de vida do agente.
• Configurar o Microsoft Update para baixar e instalar automaticamente as atualizações do agente: recomendamos instalar todas as atualizações do Azure File Sync para garantir que você tenha acesso às correções mais recentes para o agente do servidor. O Microsoft Update torna esse processo perfeito baixando e instalando automaticamente atualizações para você.
• Use AfsUpdater.exe para baixar e instalar atualizações do agente: o AfsUpdater.exe arquivo está localizado no diretório de instalação do agente. Clique duas vezes no arquivo executável para baixar e instalar as atualizações do agente. Dependendo da versão de lançamento, talvez seja necessário reiniciar o servidor.
• Corrigir um agente existente do Azure File Sync usando um arquivo de patch do Microsoft Update ou um arquivo executável .msp: você pode baixar o pacote de atualização mais recente do Azure File Sync do Catálogo do Microsoft Update. A execução de um arquivo executável .msp atualiza sua instalação do Azure File Sync com o mesmo método que o Microsoft Update usa automaticamente. A aplicação de um patch do Microsoft Update executa uma atualização in-loco de uma instalação do Azure File Sync.
• Baixe o instalador mais recente do agente do Azure File Sync: você pode obter o instalador no Centro de Download da Microsoft. Para atualizar uma instalação existente do agente do Azure File Sync, desinstale a versão mais antiga e instale a versão mais recente a partir do instalador baixado. As configurações do agente (por exemplo, registro do servidor e pontos de extremidade do servidor) são mantidas quando o agente do Azure File Sync é desinstalado.

Gerenciamento automático do ciclo de vida do agente

O agente do Azure File Sync é atualizado automaticamente. Você pode selecionar um dos seguintes modos e especificar uma janela de manutenção na qual a atualização é tentada no servidor. Esse recurso foi projetado para ajudá-lo com o gerenciamento do ciclo de vida do agente, fornecendo um guardrail que impede a expiração do agente ou permitindo uma configuração sem problemas e de permanência atual.

• A configuração padrão tenta impedir que o agente expire. Dentro de 21 dias da data de expiração publicada de um agente, o agente tenta se autoatualizar. Ele inicia uma tentativa de atualização uma vez por semana dentro de 21 dias antes da expiração e na janela de manutenção selecionada. Observe que essa opção não elimina a necessidade de usar patches regulares do Microsoft Update.

• Você pode selecionar que o agente se atualize automaticamente assim que uma nova versão do agente estiver disponível. Atualmente, essa capacidade não é aplicável a servidores clusterizados.

  Esta atualização ocorre durante a janela de manutenção selecionada e permite que o servidor se beneficie de novos recursos e melhorias assim que estiverem disponíveis ao público. Esta configuração recomendada e sem preocupações fornece versões principais do agente e patches de atualização regulares para o seu servidor. Cada agente lançado está em qualidade GA.

  Se você selecionar essa opção, a Microsoft enviará a versão mais recente do agente para você. Os servidores clusterizados são excluídos. Após a conclusão do voo, o agente também fica disponível no Microsoft Update e no Centro de Download da Microsoft.

Alterar a configuração de atualização automática

As instruções a seguir descrevem como alterar as configurações depois de concluir o instalador, se você precisar fazer alterações.

Abra um console do PowerShell, vá para o diretório onde você instalou o agente de sincronização e importe os cmdlets do servidor. Por padrão, essa ação se parece com o exemplo a seguir:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Você pode executar Get-StorageSyncAgentAutoUpdatePolicy para verificar a configuração de política atual e determinar se deseja alterá-la.

Para alterar a configuração de política atual para a faixa de atualização atrasada, você pode usar:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Para alterar a configuração de política atual para a faixa de atualização imediata, você pode usar:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Garantias de ciclo de vida do agente e gerenciamento de alterações

O Azure File Sync é um serviço de nuvem que introduz continuamente novos recursos e melhorias. Uma versão específica do agente do Azure File Sync pode ter suporte por apenas um tempo limitado. Para facilitar sua implantação, as regras a seguir garantem que você tenha tempo e notificação suficientes para acomodar as atualizações do agente em seu processo de gerenciamento de alterações:

• As principais versões do agente são suportadas por pelo menos 12 meses a partir da data de lançamento inicial.
• Há uma sobreposição de pelo menos 3 meses entre o suporte das versões principais do agente.
• Os avisos são emitidos para servidores registrados por meio de um agenteto-be expirado em breve pelo menos 3 meses antes da expiração. Você pode verificar se um servidor registrado está usando uma versão mais antiga do agente na seção sobre servidores registrados em um serviço de sincronização de armazenamento.
• A duração de uma versão menor de um agente está ligada à versão principal associada. Por exemplo, quando a versão 18.0.0.0 do agente está definida para expirar, as versões do agente 18.*.*.* expiram juntas.

Conteúdo relacionado

• Configurações de proxy e firewall do Azure File Sync
• Criar um compartilhamento de arquivos do Azure SMB
• Implantar o Azure File Sync
• Monitorar a sincronização de arquivos do Azure