Planejando uma implantação da Sincronização de Arquivos do Azure

A Sincronização de Arquivos do Azure é um serviço que permite armazenar em cache vários compartilhamentos de arquivos do Azure em um Windows Server local ou uma VM na nuvem.

Este artigo apresenta conceitos e recursos da Sincronização de Arquivos do Azure. Depois de conhecer a Sincronização de Arquivos do Azure, considere seguir o Guia de implantação da Sincronização de Arquivos do Azure para experimentar esse serviço.

Os arquivos serão armazenados na nuvem em compartilhamentos de arquivos do Azure. Os compartilhamentos de arquivos do Azure podem ser usados de duas maneiras: ao montar diretamente esses compartilhamentos de arquivos do Azure sem servidor (SMB) ou armazenar em cache os compartilhamentos de arquivos do Azure localmente usando a Sincronização de Arquivos do Azure. A opção de implantação escolhida altera os aspectos que você precisa considerar ao planejar sua implantação.

• Montagem direta de um compartilhamento de arquivos do Azure: como os Arquivos do Azure fornecem acesso SMB, você pode montar compartilhamentos de arquivos do Azure localmente ou na nuvem usando o cliente SMB padrão disponível no Windows, macOS e Linux. Como os compartilhamentos de arquivos do Azure são sem servidor, a implantação para cenários de produção não exige o gerenciamento de um servidor de arquivos ou dispositivo NAS. Isso significa que você não precisa aplicar patches de software nem trocar discos físicos.

• Armazenar em cache o compartilhamento de arquivo do Azure local com a Sincronização de Arquivos do Azure: A Sincronização de Arquivos do Azure permite centralizar os compartilhamentos de arquivos da sua organização no serviço Arquivos do Azure sem abrir mão da flexibilidade, do desempenho e da compatibilidade de um servidor de arquivos local. A Sincronização de Arquivos do Azure transforma um Windows Server local (ou em nuvem) em um cache rápido do compartilhamento de arquivo do Azure.

Conceitos de gerenciamento

Uma implantação da Sincronização de Arquivos do Azure tem três objetos de gerenciamento fundamentais:

• Compartilhamento de arquivos do Azure: Um compartilhamento de arquivo do Azure é um compartilhamento de arquivo em nuvem sem servidor, que fornece o ponto de extremidade na nuvem de uma relação de sincronização da Sincronização de Arquivos do Azure. Os arquivos em um compartilhamento de arquivo do Azure podem ser acessados diretamente com o protocolo SMB ou FileREST, embora recomendemos que você acesse os arquivos principalmente por meio do cache do Windows Server quando o compartilhamento de arquivo do Azure está sendo usado com a Sincronização de Arquivos do Azure. Isso ocorre porque o serviço Arquivos do Azure atualmente não tem um mecanismo de detecção de alteração eficiente, como o Windows Server tem, portanto, as alterações feitas diretamente no compartilhamento de arquivo do Azure levarão tempo para serem propagadas de volta para os pontos de extremidade do servidor.
• Ponto de extremidade do servidor: O caminho no Windows Server que está sendo sincronizado com um compartilhamento de arquivo do Azure. Isso pode ser uma pasta específica em um volume ou a raiz do volume. Vários pontos de extremidade de servidor podem existir no mesmo volume se os seus namespaces não se sobrepuserem.
• Grupo de sincronização: O objeto que define a relação de sincronização entre um ponto de extremidade na nuvem ou compartilhamento de arquivo do Azure e um ponto de extremidade do servidor. Os pontos de extremidade em um grupo de sincronização são mantidos em sincronização entre si. Se, por exemplo, você tiver dois conjuntos distintos de arquivos que deseja gerenciar com a Sincronização de Arquivos do Azure, crie dois grupos de sincronização e adicione pontos de extremidade diferentes a cada grupo de sincronização.

Conceitos de gerenciamento de compartilhamento de arquivo do Azure

Os compartilhamentos de arquivo do Azure são implantados em contas de armazenamento, que são objetos de nível superior que representam um pool de armazenamento compartilhado. Esse pool de armazenamento pode ser usado para implantar vários compartilhamentos de arquivo, bem como outros recursos de armazenamento, como contêineres de blob, filas ou tabelas. Todos os recursos de armazenamento implantados em uma conta de armazenamento compartilham os limites aplicáveis a essa conta de armazenamento. Para obter os limites atuais de uma conta de armazenamento, confira Metas de desempenho e escalabilidade dos Arquivos do Azure.

Há dois tipos principais de contas de armazenamento que serão usadas para implantações dos Arquivos do Azure:

• Contas de armazenamento GPv2 (uso geral versão 2) : as contas de armazenamento GPv2 permitem que você implante compartilhamentos de arquivo do Azure em hardware padrão/baseado em HD (disco rígido). Além de armazenar compartilhamentos de arquivo do Azure, as contas de armazenamento GPv2 podem armazenar outros recursos de armazenamento, como contêineres de blob, filas ou tabelas.
• Contas de armazenamento FileStorage: as contas de armazenamento FileStorage permitem que você implante compartilhamentos de arquivo do Azure em hardware premium/baseado em SSD (disco de estado sólido). As contas FileStorage só podem ser usadas para armazenar compartilhamentos de arquivo do Azure; nenhum outro recurso de armazenamento (contêineres de blob, filas, tabelas etc.) pode ser implantado em uma conta FileStorage. Somente contas FileStorage podem implantar compartilhamentos de arquivo SMB e NFS.

Há vários outros tipos de contas de armazenamento que podem ser incluídos no portal do Azure, no PowerShell ou na CLI. Dois tipos de conta de armazenamento, contas de armazenamento BlockBlobStorage e BlobStorage, não podem conter compartilhamentos de arquivo do Azure. Os outros dois tipos de conta de armazenamento que você pode ver são GPv1 (uso geral versão 1) e contas de armazenamento clássicas; ambos podem conter compartilhamentos de arquivo do Azure. Embora as contas de armazenamento GPv1 e clássicas possam conter compartilhamentos de arquivo do Azure, a maioria dos novos recursos dos Arquivos do Azure está disponível apenas nas contas de armazenamento GPv2 e FileStorage. Portanto, recomendamos que você use apenas contas de armazenamento GPv2 e FileStorage para novas implantações e atualize as contas de armazenamento GPv1 e clássicas se elas já existirem em seu ambiente.

Conceitos de gerenciamento de Sincronização de Arquivos do Azure

Os grupos de sincronização são implantados em Serviços de Sincronização de Armazenamento, que são objetos de nível superior que registram servidores para uso com a Sincronização de Arquivos do Azure e contêm as relações do grupo de sincronização. O recurso Serviço de Sincronização de Armazenamento é um par do recurso de conta de armazenamento e pode, de maneira semelhante, ser implantado em grupos de recursos do Azure. Um Serviço de Sincronização de Armazenamento pode criar grupos de sincronização que contêm compartilhamentos de arquivo do Azure entre várias contas de armazenamento e vários Windows Servers registrados.

Para criar um grupo de sincronização em um Serviço de Sincronização de Armazenamento, primeiro você deve registrar um Windows Server no Serviço de Sincronização de Armazenamento. Isso cria o objeto servidor registrado que representa uma relação de confiança entre seu servidor ou cluster e o Serviço de Sincronização de Armazenamento. Para registrar um Serviço de Sincronização de Armazenamento, você deve primeiro instalar o agente da Sincronização de Arquivos do Azure no servidor. Um servidor individual ou um cluster pode ser registrado apenas em um Serviço de Sincronização de Armazenamento por vez.

Um grupo de sincronização contém um ponto de extremidade na nuvem ou um compartilhamento de arquivo do Azure e pelo menos um ponto de extremidade do servidor. O objeto de ponto de extremidade do servidor contém as configurações que definem a funcionalidade de camada de nuvem, que fornece a funcionalidade de cache da Sincronização de Arquivos do Azure. Para sincronizar com um compartilhamento de arquivo do Azure, a conta de armazenamento que contém o compartilhamento de arquivo do Azure deve estar na mesma região do Azure que o Serviço de Sincronização de Armazenamento.

Considere a contagem de Serviços de Sincronização de Armazenamentos necessários

Uma seção anterior aborda o recurso principal para configurar a Sincronização de Arquivos do Azure: um Serviço de Sincronização de Armazenamento. Um Windows Server só pode ser registrado em um único Serviço de Sincronização de Armazenamento. Portanto, geralmente, é melhor implantar apenas um único Serviço de Sincronização de Armazenamento e registrar todos os servidores nele.

Crie vários Serviços de Sincronização de Armazenamento somente se você tiver:

• conjuntos distintos de servidores que nunca devem trocar dados entre si. Nesse caso, é melhor projetar o sistema para excluir determinados conjuntos de servidores para a sincronização com um compartilhamento de arquivos do Azure que já está em uso como ponto de extremidade de nuvem em um grupo de sincronização de um Serviço de Sincronização de Armazenamento diferente. Outra maneira de olhar para isso é quando observamos que os Windows Servers registrados em um serviço de sincronização de armazenamento diferente não podem ser sincronizados com o mesmo compartilhamento de arquivos do Azure.
• a necessidade de ter mais servidores registrados ou grupos de sincronização do que um único Serviço de Sincronização de Armazenamento pode dar suporte. Examine os destinos de escala de Sincronização de Arquivos do Azure para obter mais detalhes.

Planejar topologias de sincronização balanceada

Antes de implantar qualquer recurso, é importante planejar o que você sincronizará em um servidor local e com qual compartilhamento de arquivos do Azure. Fazer um plano ajudará você a determinar quantas contas de armazenamento, compartilhamentos de arquivos do Azure e recursos de sincronização serão necessários. Essas considerações ainda são relevantes mesmo se os dados não residem atualmente em um Windows Server ou no servidor que você deseja usar em longo prazo. A seção de migração pode ajudar a determinar os caminhos de migração apropriados para sua situação.

Nesta etapa, você determinará quantos compartilhamentos de arquivo do Azure são necessários. Uma única instância do Windows Server (ou cluster) pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Você pode ter mais pastas em seus volumes que você compartilha localmente no momento como compartilhamentos SMB para seus usuários e aplicativos. A maneira mais fácil de descrever esse cenário é prever um compartilhamento local que mapeia 1:1 para um compartilhamento de arquivos do Azure. Se você tem um número pequeno suficiente de compartilhamentos, ou seja, menos de 30 para uma só instância do Windows Server, é recomendado um mapeamento de 1:1.

Se você tem mais de 30 compartilhamentos, geralmente não é necessário fazer o mapeamento de 1:1 de um compartilhamento local para um compartilhamento de arquivo do Azure. Considere as opções a seguir.

Agrupamento de compartilhamentos

Por exemplo, se o departamento de RH (Recursos Humanos) tiver 15 compartilhamentos, considere o armazenamento de todos os dados de RH em um só compartilhamento de arquivo 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

A Sincronização de Arquivos do Azure dá suporte à sincronização da raiz de um volume para um compartilhamento de arquivos do Azure. Se você sincronizar a raiz do volume, todas as subpastas e arquivos vão para o mesmo compartilhamento de arquivos do Azure.

A sincronização da raiz do volume nem sempre é a melhor opção. Há benefícios em sincronizar várias localizações. Por exemplo, isso ajuda a manter um menor número de itens por escopo de sincronização. Testamos os compartilhamentos de arquivo do Azure e a Sincronização de Arquivos do Azure com 100 milhões de itens (arquivos e pastas) por compartilhamento. Mas a prática recomendada é tentar manter o número abaixo de 20 ou 30 milhões em um só compartilhamento. A configuração da Sincronização de Arquivos do Azure com um número menor de itens traz benefícios não só para a sincronização de arquivos, mas também para cenários como estes:

• O exame inicial do conteúdo da nuvem pode ser concluído com mais rapidez, o que 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 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 arquivo do Azure (fora da sincronização) podem ser detectadas e sincronizadas com mais rapidez.

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 da Sincronização de Arquivos do Azure você provisionará. Um grupo de sincronização vincula o compartilhamento de arquivos do Azure e a pasta em seu servidor em conjunto e estabelece uma conexão de sincronização.

Para decidir de quantos compartilhamentos de arquivo do Azure você precisa, examine os limites e as práticas recomendadas a seguir. Isso ajudará você a otimizar seu mapa.

• Um servidor no qual o agente da Sincronização de Arquivos do Azure está instalado pode ser sincronizado com até 30 compartilhamentos de arquivo do Azure.

• Um compartilhamento de arquivo do Azure é implantado em uma conta de armazenamento. Essa organização faz com que a conta de armazenamento seja uma meta 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 arquivo do Azure. O ideal seria mapear os compartilhamentos de arquivo um a um com as contas de armazenamento. No entanto, isso nem sempre é possível devido a vários limites e restrições, tanto da organização quanto do Azure. Quando não for possível ter apenas um compartilhamento de arquivo implantado em uma conta de armazenamento, considere quais compartilhamentos serão altamente ativos e quais serão menos ativos para garantir que os compartilhamentos de arquivos mais frequentes não sejam colocados na mesma conta de armazenamento.

  Se você planeja transferir para o Azure um aplicativo que usará o compartilhamento de arquivo do Azure de modo nativo, talvez seja necessário mais desempenho no compartilhamento de arquivo do Azure. Se esse tipo de uso for uma possibilidade, mesmo que futura, é melhor criar um só compartilhamento de arquivo Standard do Azure na respectiva conta de armazenamento.

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

É uma prática recomendada manter o número de itens por escopo de sincronização baixo. Esse é um fator importante a ser considerado no mapeamento de pastas para compartilhamentos de arquivos do Azure. Sincronização de Arquivos do Azure é testado com 100 milhões itens (arquivos e pastas) por compartilhamento. Mas geralmente é melhor manter o número de itens abaixo de 20 ou 30 milhões em um só compartilhamento. Divida o 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 mais abaixo desses números. Essa prática fornecerá espaço para crescer.

Na sua situação, é possível que um conjunto de pastas seja sincronizado logicamente com o mesmo compartilhamento de arquivo do Azure (usando a nova abordagem de pasta raiz comum já mencionada). Mas talvez ainda seja melhor reagrupar as pastas para que elas sejam sincronizadas com dois compartilhamentos de arquivo do Azure em vez de um. Você pode usar essa abordagem para manter o número de arquivos e pastas por compartilhamento de arquivos balanceados pelo servidor. Você também pode dividir os compartilhamentos locais e sincronizá-los entre mais servidores locais adicionando a capacidade de sincronização com mais 30 compartilhamentos de arquivo do Azure por servidor extra.

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

#	Cenário de sincronização	Com suporte	Considerações (ou limitações)	Solução (ou solução alternativa)
1	Servidor de arquivos com vários discos/volumes e vários compartilhamentos para o mesmo compartilhamento de arquivos do Azure de destino (consolidação)	No	Um compartilhamento de arquivos do Azure de destino (ponto de extremidade de nuvem) dá suporte apenas à sincronização com um grupo de sincronização. Um grupo de sincronização dá suporte apenas a um ponto de extremidade de servidor por servidor registrado.	1) Comece sincronizando um disco (seu volume raiz) para direcionar o compartilhamento de arquivos do Azure. Começar com o maior disco/volume ajudará com os requisitos de armazenamento local. Configure a camada de nuvem para colocar todos os dados em camadas na nuvem, liberando assim espaço no disco do servidor de arquivos. Mova dados de outros volumes/compartilhamentos para o volume atual que está sendo sincronizado. Continue as etapas uma a uma até que todos os dados estejam em camadas para nuvem/migrados. 2) Direcione um volume raiz (disco) por vez. Use a camada de nuvem para colocar todos os dados em camadas para direcionar o compartilhamento de arquivos do Azure. 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. Observação: a reinstalação do agente pode ser necessária. 3) Recomendar 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 arquivos com volume único e vários compartilhamentos para o mesmo compartilhamento de arquivos do Azure de destino (consolidação)	Yes	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)	Raiz de sincronização 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 arquivos com vários compartilhamentos e/ou volumes para vários compartilhamentos de arquivos do Azure em uma única conta de armazenamento (mapeamento de compartilhamento 1:1)	Sim	Uma única instância do Windows Server (ou cluster) 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 compartilhados entre compartilhamentos de arquivos. Mantenha o número de itens por grupo de sincronização em 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 com os quais sincronizar). 2) Somente 30 compartilhamentos podem ser sincronizados neste cenário por vez. Se você tiver mais de 30 compartilhamentos nesse servidor de arquivos, use Conceito de agrupamento de compartilhamento e Sincronização de volume para reduzir o número de pastas raiz ou de nível superior na origem. 3) Use servidores adicionais de Sincronização de Arquivos 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 diferentes contas de armazenamento (mapeamento de compartilhamento 1:1)	Sim	Uma única instância do Windows Server (ou cluster) pode sincronizar até 30 compartilhamentos de arquivos do Azure. Mantenha o número de itens por grupo de sincronização em 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 a mencionada 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 diretrizes no Cenário nº 1 acima com consideração adicional sobre como direcionar um servidor de arquivos por vez.

Criar uma tabela de mapeamento

Use as informações anteriores para determinar quantos compartilhamentos de arquivo do Azure são necessários e quais dos dados existentes serão enviados para qual compartilhamento de arquivo do Azure.

Crie uma tabela para registrar suas conclusões que possa ser consultada sempre que necessário. Manter-se organizado é importante porque pode ser fácil perder detalhes do seu plano de mapeamento quando você estiver provisionando muitos recursos do Azure de uma vez. Baixe o arquivo do Excel a seguir para usá-lo como um modelo na criação do mapeamento.

Baixe um modelo de mapeamento de namespace.

Considerações sobre servidor de arquivos do Windows

Para habilitar a funcionalidade de sincronização no Windows Server, você deve instalar o agente Sincronização de Arquivos do Azure para baixar. O agente de Sincronização de Arquivos do Azure fornece dois componentes principais: FileSyncSvc.exe, o serviço Windows em segundo plano responsável por monitorar alterações nos pontos de extremidade do servidor e iniciar sessões de sincronização e StorageSync.sys, um filtro do sistema de arquivos que permite a camada de nuvem e uma rápida recuperação de desastre.

Requisitos do sistema operacional

A Sincronização de Arquivos do Azure é compatível com as seguintes versões do Windows Server:

Versão	SKUs com suporte	Opções de implantação com suporte
Windows Server 2025	Azure, Datacenter, Essentials, Standard e IoT	Completo e Core
Windows Server 2022	Azure, Datacenter, Essentials, Standard e IoT	Completo e Core
Windows Server 2019	Datacenter, Essentials, Standard e IoT	Completo e Core
Windows Server 2016	Datacenter, Essentials, Standard e Servidor de Armazenamento	Completo e Core
Windows Server 2012 R2*	Datacenter, Essentials, Standard e Servidor de Armazenamento	Completo e Core

*Requer baixar e instalar o Windows Management Framework (WMF) 5.1. O pacote apropriado para baixar e instalar o Windows Server 2012 R2 é Win8.1AndW2K12R2-KB*******-x64.msu.

Versões futuras do Windows Server serão adicionadas à medida que forem liberadas.

Recursos mínimos do sistema

A Sincronização de Arquivos do Azure requer um servidor, físico ou virtual, com pelo menos uma CPU, no mínimo 2 GiB de memória e 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 da Sincronização de Arquivos do Azure com apenas os requisitos mínimos. Confira Recursos do sistema recomendados para obter mais informações.

Recursos de sistema recomendados

Assim como qualquer recurso de servidor ou aplicativo, os requisitos de recursos de sistema para a Sincronização de Arquivos do Azure são determinados pela escala da implantação; implantações maiores em um servidor exigem mais recursos do sistema. Na Sincronização de Arquivos do Azure, a escala é determinada pelo número de objetos entre os pontos de extremidade do servidor e a variação no conjunto de dados. Um servidor pode ter pontos de extremidade de servidor em vários grupos de sincronização e o número de objetos listados nas contas de tabela a seguir para o namespace completo ao qual um servidor está anexado.

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 essa implantação de exemplo, recomendamos 8 CPUs, 16 GiB de memória para o estado estável e (se possível) 48 GiB de memória para a migração inicial.

Os dados de namespace são armazenados na memória por questões de desempenho. Por causa disso, namespaces maiores exigem mais memória para manter o bom desempenho e mais variação requer mais CPU para processar.

Na tabela a seguir, fornecemos o tamanho do namespace, bem como uma conversão em capacidade para compartilhamentos de arquivos de uso geral típicos, em que o tamanho médio do arquivo é de 512 KiB. Se os tamanhos do arquivo forem menores, considere adicionar mais memória para a mesma quantidade de capacidade. Baseie sua configuração de memória no tamanho do namespace.

Tamanho do namespace – arquivos e diretórios (milhões)	Capacidade típica (TiB)	Núcleos de CPU	Memória recomendada (GiB)
3	1.4	2	8 (sincronização inicial)/ 2 (variação típica)
5	2.3	2	16 (sincronização inicial)/ 4 (variação típica)
10	4.7	4	32 (sincronização inicial)/ 8 (variação típica)
30	14.0	8	48 (sincronização inicial)/ 16 (variação típica)
50	23,3	16	64 (sincronização inicial)/ 32 (variação típica)
100*	46,6	32	128 (sincronização inicial)/ 32 (variação típica)

*Não é recomendável sincronizar mais de 100 milhões de arquivos e diretórios. Esse é um limite flexível com base em limites testados. Para obter mais informações, confira Destinos de escala da Sincronização de Arquivos do Azure.

Cmdlet de avaliação

Antes de implantar a Sincronização de Arquivos do Azure, você deve avaliar se ela é compatível com o seu sistema usando o cmdlet de avaliação da Sincronização de Arquivos do Azure. Esse cmdlet verifica se há possíveis problemas com seu sistema de arquivos e conjunto de dados, como caracteres sem suporte ou uma versão do sistema operacional não compatível. Essas verificações abrangem a maioria, mas não todos os recursos mencionados abaixo; recomendamos que você leia o restante desta seção com cuidado para garantir que sua implantação fique tranquila.

O cmdlet de avaliação pode ser instalado por meio do módulo Az PowerShell, que pode ser instalado seguindo as instruções aqui: Instale e configure o Azure PowerShell.

Uso

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

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Para testar apenas o conjunto de dados:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Para testar somente os requisitos do sistema:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Para exibir os resultados em 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 Arquivos do Azure só é compatível com volumes NTFS anexados diretamente. O armazenamento com conexão direta (ou DAS) no Windows Server significa que o sistema operacional do Windows Server é proprietário do sistema de arquivos. O DAS pode ser fornecido por meio da anexação física de discos ao servidor de arquivos, anexando discos virtuais a uma VM do servidor de arquivos (como uma VM hospedada pelo Hyper-V) ou até mesmo por meio do iSCSI.

Há suporte apenas para volumes NTFS; não há suporte para ReFS, FAT, FAT32 e outros sistemas de arquivos.

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

Recurso	Status de suporte	Observações
ACLs (listas de controle de acesso)	suporte completo	As listas de controle de acesso condicional de estilo do Windows são preservadas pela Sincronização de Arquivos do Azure e são impostas pelo Windows Server em pontos de extremidade de servidor. As ACLs também podem ser impostas ao montar diretamente o compartilhamento de arquivo do Azure, no entanto, isso requer configuração adicional. Confira a Seção identidade para obter mais informações.
Links físicos	Ignorado
Links simbólicos	Ignorado
Pontos de montagem	Suporte parcial	Pontos de montagem podem ser a raiz de um Ponto de Extremidade de Servidor, mas serão ignorados se estiverem contidos no namespace de um ponto de extremidade de servidor.
Junções	Ignorado	Por exemplo, as pastas DFSRoots e DfrsrPrivate do Sistema de Arquivos Distribuído.
Pontos de nova análise	Ignorado
Compactação NTFS	Com suporte parcial	A Sincronização de Arquivos do Azure não dá suporte a pontos de extremidade de servidor localizados em um volume que tenha o diretório de informações de volume do sistema (SVI) compactado.
Arquivos esparsos	suporte completo	Os arquivos esparsos são sincronizados (não são bloqueados), mas são sincronizados com a nuvem como um arquivo completo. Se o conteúdo do arquivo for alterado na nuvem (ou em outro servidor), o arquivo não será mais esparso quando a alteração for baixada.
ADS (Fluxos de Dados Alternativos)	Preservados, mas não sincronizados	Por exemplo, as marcas de classificação criadas pela Infraestrutura de Classificação de Arquivos não são sincronizadas. As marcas de classificação em arquivos existentes em cada um dos pontos de extremidade do servidor são mantidas.

A Sincronização de Arquivos do Azure também ignorará determinados arquivos temporários e pastas do sistema:

Arquivo/pasta	Observação
pagefile.sys	Arquivo específico do sistema
Desktop.ini	Arquivo específico do sistema
thumbs.db	Arquivo temporário para miniaturas
ehthumbs.db	Arquivo temporário para miniaturas de mídia
~$*.*	Arquivo temporário do Office
*.tmp	Arquivo temporário
*.laccdb	Arquivo de bloqueio do banco de dados do Access
635D02A9D91C401B97884B82B3BCDAEA.*	arquivo de sincronização interno
\SystemVolumeInformation	Pasta específica do volume
$RECYCLE.BIN	Pasta
\SyncShareState	pasta para sincronização
.SystemShareInformation	Pasta para sincronização no compartilhamento de arquivo do Azure

Considere a quantidade de espaço livre que você precisa no disco local

Ao planejar usar a Sincronização de Arquivos do Azure, considere quanto espaço livre você precisa no disco local em que planeja ter um ponto de extremidade de servidor.

Com a Sincronização de Arquivos do Azure, você precisará levar em conta o seguinte espaço no disco local:

• Com a camada de nuvem habilitada:

  • Pontos de nova análise para arquivos em camadas
  • Banco de dados de metadados da Sincronização de Arquivos do Azure
  • Armazenamento frequente da Sincronização de Arquivos do Azure
  • Arquivos totalmente baixados no cache de camada de acesso frequente (se houver)
  • Requisitos da política de espaço livre do volume

• Com a camada de nuvem desabilitada:

  • Arquivos totalmente baixados
  • Armazenamento frequente da Sincronização de Arquivos do Azure
  • Banco de dados de metadados da Sincronização de Arquivos do Azure

Vamos usar um exemplo para ilustrar como estimar a quantidade de espaço livre necessário no disco local. Digamos que você instalou o agente de Sincronização de Arquivos do Azure na VM do Azure Windows e planeja criar um ponto de extremidade do servidor no disco F. Você tem 1 milhão de arquivos e gostaria de transferir 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 camada de nuvem e definir a política de espaço livre de volume como 20%.

1. O NTFS aloca um tamanho de cluster para cada um dos arquivos em camadas. 1 milhão de arquivos * tamanho de cluster de 4 KiB = 4.000.000 KiB (4 GiB)

   Observação

   Para se beneficiar totalmente da camada de nuvem, é recomendável usar tamanhos de cluster NTFS menores (menos de 64 KiB), pois cada arquivo em camadas ocupa um cluster. Além disso, o espaço ocupado por arquivos em camadas é alocado pelo NTFS. Portanto, ele não aparecerá em nenhuma interface do usuário.

2. 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)
3. O armazenamento frequente da Sincronização de Arquivos do Azure ocupa 1,1 KiB por arquivo. 1 milhão de arquivos * 1,1 KiB = 1.100.000 KiB (1,1 GiB)
4. A política de espaço livre do volume é de 20%. 1\.000 GiB * 0,2 = 200 GiB

Nesse caso, a Sincronização de Arquivos do Azure precisaria de cerca de 209.500.000 KiB (209,5 GiB) de espaço para esse namespace. Adicione esse valor a qualquer espaço livre adicional desejado para descobrir quanto espaço livre é necessário para esse disco.

Clustering de failover

1. O clustering de failover do Windows Server tem suporte pela Sincronização de Arquivo do Azure para a opção de implantação “Servidor de Arquivos de uso geral”. Para obter mais informações sobre como configurar o "Servidor de Arquivos para função de uso geral" em um Cluster de Failover, confira Implantar um servidor de arquivos clusterizado de dois nós.
2. O único cenário com suporte pelo Sincronização de Arquivos do Azure é o Cluster de Failover do servidor do Windows com discos clusterizados
3. O clustering de failover não tem suporte no "Servidor de Arquivos de Escalabilidade Horizontal para dados de aplicativo" (SOFS) ou em Volumes Compartilhados Clusterizados (CSVs) ou discos locais.

Eliminação de duplicação de dados

Windows Server 2025, Windows Server 2022, Windows Server 2019 e Windows Server 2016
A Eliminação de Duplicação de Dados tem suporte, independentemente de a camada de nuvem estar habilitada ou desabilitada em um ou mais pontos de extremidade de servidor no volume para o Windows Server 2016, o Windows Server 2019, o Windows Server 2022 e o Windows Server 2025. Habilitar a Eliminação de Duplicação de Dados em um volume com camada de nuvem habilitada permite armazenar em cache mais arquivos localmente sem ter que provisionar mais armazenamento.

Quando a Eliminação de Duplicação de Dados é habilitada em um volume com camada de nuvem habilitada, os arquivos otimizados para eliminação de duplicação na localização do ponto de extremidade do servidor serão colocados em camadas semelhantes a um arquivo normal com base nas configurações de política de camada de nuvem. Depois que os arquivos otimizados para eliminação de duplicação estiverem em camadas, o trabalho de coleta de lixo da Eliminação de Duplicação de Dados será executado automaticamente para recuperar espaço em disco removendo partes desnecessárias que não são mais referenciadas por outros arquivos no volume.

Observe que a economia de volume só se aplica ao servidor; seus dados no compartilhamento de arquivos do Azure não passarão pela eliminação de duplicação.

Windows Server 2012 R2
A Sincronização de Arquivos do Azure não dá suporte à Eliminação de Duplicação de Dados e à camada de nuvem no mesmo volume no Windows Server 2012 R2. Se a Eliminação de Duplicação de Dados estiver habilitada em um volume, a camada de nuvem deverá ser desabilitada.

Observações

• Se a Eliminação de Duplicação de Dados for instalada antes da instalação do agente da Sincronização de Arquivos do Azure, uma reinicialização será necessária para dar suporte à Eliminação de Duplicação de Dados e à camada de nuvem no mesmo volume.

• Se a Eliminação de Duplicação de Dados estiver habilitada em um volume depois que a camada de nuvem estiver habilitada, o trabalho de otimização de eliminação de duplicação inicial otimizará os arquivos do volume que ainda não estiverem em camadas e terá o seguinte impacto na camada de nuvem:

  • A política de espaço livre continuará a colocar arquivos em camada de acordo com o espaço livre no volume usando o mapa de calor.
  • A política de data ignorará a camada de arquivos que, de outra forma, poderia ter sido qualificada para camada devido ao trabalho de otimização da eliminação de duplicação que acessa os arquivos.

• Para trabalhos contínuos de otimização de eliminação de duplicação, a camada de nuvem com a política de data será atrasada pela configuração MinimumFileAgeDays de Eliminação de Duplicação de Dados, se o arquivo ainda não estiver em camadas.

  • Exemplo: Se a configuração MinimumFileAgeDays for de sete dias e a política de data da camada de nuvem for de 30 dias, a política de data colocará os arquivos em camada após 37 dias.
  • Observação: Quando um arquivo é colocado em camadas pela Sincronização de Arquivos do Azure, o trabalho de otimização da eliminação de duplicação ignorará o arquivo.

• Se um servidor que executa o Windows Server 2012 R2 com o agente da Sincronização de Arquivos do Azure instalado for atualizado para o Windows Server 2016, o Windows Server 2019, o Windows Server 2022 ou o Windows Server 2025, as seguintes etapas precisarão ser executadas para dar suporte à Eliminação de Duplicação de Dados e à camada de nuvem no mesmo volume:

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

  Observação: As definições de configuração de Sincronização de Arquivos do Azure no servidor são mantidas quando o agente é desinstalado e reinstalado.

DFS (Sistema de Arquivos Distribuído)

A Sincronização de Arquivos do Azure fornece suporte para interoperabilidade com Namespaces de DFS (DFS-N) e Replicação do DFS (DFS-R).

DFS-N (DFS Namespaces): há total suporte para a Sincronização de Arquivos do Azure na implementação do DFS-N. Você pode instalar o agente de Sincronização de Arquivos do Azure em um ou mais servidores de arquivos para sincronizar dados entre os pontos de extremidade do servidor e o ponto de extremidade de nuvem e, em seguida, usar DFS-N para fornecer o serviço de namespace. Para obter mais informações, confira Visão geral de DFS Namespaces e DFS Namespaces com Arquivos do Azure.

DFS-R (Replicação do DFS) : Quando tanto DFS-R como a Sincronização de arquivos do Azure forem soluções de replicação, na maioria dos casos é recomendável substituir DFS-R pela Sincronização de Arquivos do Azure. No entanto, existem vários cenários em que você deseja usar DFS-R e Sincronização de arquivos do Azure em conjunto:

• Você está migrando de uma implantação do DFS-R para uma implantação de Sincronização de Arquivos do Azure. Para obter mais informações, consulte Migrar uma implantação de DFS-R (Replicação do DFS) para Sincronização de arquivos do Azure.
• Nem todo servidor local que precisa de uma cópia dos dados do seu arquivo pode ser conectado diretamente à Internet.
• Os servidor de ramificação consolidam dados em um servidor de hub único, para o qual você gostaria de usar a Sincronização de arquivos do Azure.

Para que a Sincronização de Arquivos do Azure e o DFS-R trabalharem lado a lado:

1. A camada de nuvem da Sincronização de arquivos do Azure deve ser desabilitada em volumes com pastas replicadas DFS-R.
2. Os pontos de extremidade do servidor não devem ser configurados em pastas de replicação somente leitura DFS-R.
3. Somente um único ponto de extremidade do servidor pode se sobrepor a um local DFS-R. Vários pontos de extremidade de servidor sobrepostos com outros locais ativos do DFS-R podem levar a conflitos.

Para obter mais informações, consulte Visão geral da Replicação do DFS.

Sysprep

Não há suporte para o uso do sysprep em um servidor com o agente de Sincronização de Arquivos do Azure instalado, e isso pode levar a resultados inesperados. A instalação do agente e o registro do servidor devem ocorrer depois da implantação da imagem do servidor e da conclusão da mini-instalação do sysprep.

Windows Search

Se a camada de nuvem estiver habilitada em um ponto de extremidade do servidor, os arquivos em camadas serão ignorados e não serão indexados pelo Windows Search. Arquivos sem camadas são indexados corretamente.

Outras soluções de HSM (Gerenciamento de Armazenamento Hierárquico)

Nenhuma outra solução de HSM deve ser usada com a Sincronização de Arquivos do Azure.

Desempenho e escalabilidade

Como o agente do Azure File Sync é executado em um computador Windows Server que se conecta aos compartilhamentos de arquivos do Azure, o desempenho de sincronização efetivo depende de vários fatores em sua infraestrutura: Windows Server e a configuração de disco subjacente, largura de banda de rede entre o servidor e o Azure armazenamento, tamanho do arquivo, tamanho total do conjunto de dados e atividade no conjunto de dados. Desde que a sincronização de arquivos do Azure funciona no nível de arquivo, as características de desempenho de uma solução de sincronização de arquivos do Azure melhor é medido em número de objetos (arquivos e diretórios) processado por segundo.

As alterações feitas no compartilhamento de arquivos do Azure usando o portal do Azure ou o SMB não são detectadas e replicadas imediatamente como alterações no ponto de extremidade do servidor. Os Arquivos do Azure não têm notificações de alteração ou diário, portanto, não há como iniciar automaticamente uma sessão de sincronização quando os arquivos são alterados. No Windows Server, a sincronização de Arquivos do Azure usa o diário de USN do Windows para iniciar automaticamente uma sessão de sincronização quando os arquivos são alterados.

Para detectar alterações para o compartilhamento de arquivos do Azure, a sincronização de arquivos do Azure tem um trabalho agendado chamado um alterar o trabalho de detecção. Um trabalho de detecção de alteração enumera todos os arquivos no compartilhamento de arquivos e, em seguida, compara a versão de sincronização para esse arquivo. Quando o trabalho de detecção de alteração determina que os arquivos foram alterados, a sincronização de Arquivos do Azure inicia uma sessão de sincronização. O trabalho de detecção de alteração é iniciado a cada 24 horas. Como o trabalho de detecção de alteração funciona enumerando todos os arquivos no compartilhamento de Arquivos do Azure, a detecção de troca demora mais nos namespaces grandes do que namespaces menores. Para esses namespaces, pode levar mais de uma vez a cada 24 horas para determinar quais arquivos foram alterados.

Para obter mais informações, consulte Métricas de desempenho da Sincronização de Arquivos do Azure e Destinos de escala da Sincronização de Arquivos do Azure

Identidade

A Sincronização de Arquivos do Azure trabalha com sua identidade padrão baseada em AD sem qualquer configuração especial além da configuração da sincronização. Quando você estiver usando a Sincronização de Arquivos do Azure, a expectativa geral é que a maioria dos acessos passe pelos servidores de cache da Sincronização de Arquivos do Azure, em vez de pelo compartilhamento de arquivos do Azure. Como os pontos de extremidade do servidor estão localizados no Windows Server e o Windows Server é compatível com ACLs de estilo do AD e do Windows há muito tempo, não é necessário nada além de garantir que os servidores de arquivo do Windows registrados com o Serviço de Sincronização de Armazenamento sejam ingressados no domínio. A Sincronização de Arquivos do Azure armazenará ACLs nos arquivos do compartilhamento de arquivo do Azure e os replicará para todos os pontos de extremidade do servidor.

Embora as alterações feitas diretamente no compartilhamento de arquivos do Azure levem mais tempo para serem sincronizadas com os pontos de extremidade do servidor no grupo de sincronização, talvez você também queira garantir que você possa impor suas permissões do AD no compartilhamento de arquivos diretamente na nuvem. Para fazer isso, você precisa ingressar no domínio em sua conta de armazenamento no AD local, assim como os servidores de arquivos do Windows são ingressados no domínio. Para saber mais sobre o ingresso no domínio com sua conta de armazenamento em um Active Directory de propriedade do cliente, confira Visão geral sobre Active Directory no serviço Arquivos do Azure.

Rede

O agente de Sincronização de Arquivos do Azure se comunica com o Serviço de Sincronização de Armazenamento e o compartilhamento de arquivo do Azure usando o protocolo REST e o protocolo FileREST da Sincronização de Arquivos do Azure e ambos sempre usam HTTPS pela porta 443. O SMB nunca é usado para carregar nem baixar dados entre o Windows Server e o compartilhamento de arquivo 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, normalmente a configuração de rede especial não é necessária para implantar a Sincronização de Arquivos do Azure.

Com base na política da sua organização ou em requisitos regulatórios exclusivos, você pode exigir uma comunicação mais restritiva com o Azure e, nesse sentido, a Sincronização de Arquivos do Azure fornece vários mecanismos para configurar a rede. Com base em seus requisitos, você pode:

• Passar tráfego de sincronização e upload/download de arquivos por túnel em seu ExpressRoute ou na VPN do Azure.
• Fazer uso de Arquivos do Azure e recursos de Rede do Azure, como pontos de extremidade de serviço e pontos de extremidade privados.
• Configurar a Sincronização de Arquivos do Azure para compatibilidade com o proxy em seu ambiente.
• Restringir a atividade de rede da Sincronização de Arquivos do Azure.

Para saber mais sobre a Sincronização de Arquivos do Azure e rede, confira Considerações de rede da Sincronização de Arquivos do Azure.

Criptografia

Ao usar a Sincronização de Arquivos do Azure, há três camadas diferentes de criptografia a serem consideradas: criptografia no armazenamento em repouso do Windows Server, criptografia em trânsito entre o agente de Sincronização de Arquivos do Azure e o Azure e a criptografia em repouso dos dados no compartilhamento de arquivo do Azure.

Criptografia em repouso do Windows Server

Há duas estratégias para criptografar dados no Windows Server que funcionam geralmente com a Sincronização de Arquivos do Azure: criptografia subjacente do sistema de arquivos de modo que o sistema de arquivos e todos os dados gravados nele sejam criptografados e criptografia no próprio formato de arquivo. Esses métodos não são mutuamente exclusivos; eles podem ser usados juntos, se desejado, porque a finalidade da criptografia é diferente.

Para fornecer criptografia subjacente ao sistema de arquivos, o Windows Server oferece a caixa de entrada do BitLocker. O BitLocker é totalmente transparente para a Sincronização de Arquivos do Azure. O principal motivo para usar um mecanismo de criptografia como o BitLocker é impedir a exfiltração física de dados do datacenter local por alguém que está roubando os discos e impedir o sideload de um sistema operacional não autorizado para executar leituras/gravações não autorizadas em seus dados. Para saber mais sobre o BitLocker, confira Visão geral do BitLocker.

Os produtos de terceiros que funcionam de maneira semelhante ao BitLocker, no que ficam subjacente ao volume NTFS, devem funcionar de maneira totalmente transparente com a Sincronização de Arquivos 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 isso nativamente; no entanto, isso geralmente não é o caso. Um exemplo de um método para criptografar o fluxo de dados do arquivo é a AIP (Proteção de Informações do Azure)/o Azure RMS (Azure Rights Management Services)/o RMS do Active Directory. O principal motivo para usar um mecanismo de criptografia como o AIP/RMS é impedir a exfiltração dos dados do seu compartilhamento de arquivo por pessoas que os copiam para locais alternativos, como em uma unidade flash ou os enviam por email para uma pessoa não autorizada. Quando o fluxo de dados de um arquivo é criptografado como parte do formato de arquivo, esse arquivo continuará a ser criptografado no compartilhamento de arquivo do Azure.

A Sincronização de Arquivos do Azure não interopera com o NTFS Encrypted File System (NTFS EFS) ou soluções de criptografia de terceiros que ficam acima do sistema de arquivos, mas abaixo do fluxo de dados do arquivo.

Criptografia em trânsito

O agente de Sincronização de Arquivos do Azure se comunica com o Serviço de Sincronização de Armazenamento e o compartilhamento de arquivo do Azure usando o protocolo REST e o protocolo FileREST da Sincronização de Arquivos do Azure e ambos sempre usam HTTPS pela porta 443. A Sincronização de Arquivos do Azure 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, que é habilitada por padrão. Mesmo que a opção no nível da conta de armazenamento esteja desabilitada, o que significa que as conexões não criptografadas com os compartilhamentos de arquivo do Azure são possíveis, a Sincronização de Arquivos do Azure ainda usará canais criptografados para acessar seu compartilhamento de arquivo.

O principal motivo para desabilitar a criptografia em trânsito para a conta de armazenamento é a compatibilidade com um aplicativo herdado que deva ser executado em um sistema operacional mais antigo, como o Windows Server 2008 R2 ou a distribuição mais antiga do Linux, que converse com um compartilhamento de arquivo do Azure diretamente. Se o aplicativo herdado se comunicar com o cache do Windows Server do compartilhamento de arquivo, mudar essa configuração não terá nenhum efeito.

É altamente recomendável garantir que a criptografia de dados em trânsito esteja habilitada.

Para obter mais informações sobre criptografia em trânsito, consulte Exigir transferência segura no armazenamento do Azure.

Criptografia de compartilhamento de arquivo do Azure em repouso

Todos os dados armazenados nos Arquivos do Azure são criptografados em repouso usando a SSE (Criptografia do Serviço de Armazenamento) do Azure. A criptografia do serviço de armazenamento funciona de maneira semelhante ao BitLocker no Windows: os dados são criptografados abaixo do nível do sistema de arquivos. Como os dados são criptografados abaixo do sistema de arquivos do compartilhamento de arquivo do Azure, pois eles são codificados no disco, você não precisa ter acesso à chave subjacente no cliente para fazer a leitura ou gravação no compartilhamento de arquivo 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 as chaves gerenciadas pela Microsoft. Com as chaves gerenciadas pela Microsoft, a Microsoft mantém as chaves para criptografar/descriptografar os dados e é responsável pela rotação regular delas. Você também pode optar por gerenciar as próprias chaves, o que dá controle a você sobre o processo de rotação. Se você optar por criptografar seus compartilhamentos de arquivo com chaves gerenciadas pelo cliente, os Arquivos do Azure terão autorização para acessar suas chaves para atender a solicitações de leitura e gravação de seus clientes. Com as chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento, mas isso significa que o compartilhamento de arquivo do Azure não estará mais acessível pelo SMB ou pela 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 a SSE (Criptografia do Serviço de Armazenamento) do Azure, confira Criptografia do armazenamento do Azure para dados em repouso.

Camadas de armazenamento

Os Arquivos do Azure oferecem duas camadas de armazenamento de mídia diferentes, SSD e HDD, que permitem adaptar as ações aos requisitos de desempenho e preço específicos do cenário:

• SSD (Premium): os compartilhamentos de arquivo Premium contam com SSDs (unidades de estado sólido) e fornecem alto desempenho consistente e baixa latência, com milissegundos de um dígito para a maioria das operações de E/S e para cargas de trabalho de uso intensivo de E/S. Compartilhamentos de arquivo Premium são adequados para uma ampla variedade de cargas de trabalho, como bancos de dados, hospedagem de websites e ambientes de desenvolvimento. Os compartilhamentos de arquivo Premium podem ser usados com protocolos SMB e NFS (Network File System). Os compartilhamentos de arquivo Premium são implantados no tipo de conta de armazenamento do FileStorage e só estão disponíveis em um modelo de cobrança provisionado. Para obter mais informações sobre o modelo de cobrança provisionado para compartilhamentos de arquivos premium, confira Noções básicas sobre provisionamento de compartilhamentos de arquivos premium. Os compartilhamentos de arquivos Premium oferecem um SLA de disponibilidade mais alta do que os compartilhamentos de arquivos Standard (confira “Camada Premium de Arquivos do Azure”).

• HDD (Standard): os compartilhamentos de arquivos Standard usam HDDs (unidades de disco rígido) e fornecem uma opção de armazenamento econômica para compartilhamentos de arquivos de uso geral. Os compartilhamentos de arquivos Standard são implantados no tipo de conta de armazenamento de GPv2 (uso geral versão 2). Saiba mais sobre o SLA na página de contratos de nível de serviço do Azure (confira “Contas de Armazenamento”). Os compartilhamentos de arquivos Standard usam um modelo pré-pago que fornece preços com base no uso. A camada de acesso de um compartilhamento de arquivos permite ajustar os custos de armazenamento com relação ao custo de IOPS para otimizar a fatura total:

  • Os compartilhamentos de arquivos otimizados para transações oferecem o menor preço de transação para cargas de trabalho com transações pesadas que não precisam da baixa latência oferecida pelos compartilhamentos de arquivos Premium. Recomendado ao migrar dados para os Arquivos do Azure.
  • Os compartilhamentos de arquivos frequentes oferecem preços equilibrados de armazenamento e transação para cargas de trabalho que contam com uma boa medida de ambos.
  • Os compartilhamentos de arquivos esporádicos oferecem o preço de armazenamento mais econômico para cargas de trabalho com uso intensivo de armazenamento.

Ao selecionar uma camada de mídia para a carga de trabalho, considere seus requisitos de desempenho e uso. Se a carga de trabalho exigir latência de um dígito ou você estiver usando uma mídia de armazenamento SSD local, o nível Premium será provavelmente a melhor opção. Se a baixa latência não for muito importante, por exemplo, com compartilhamentos de equipe montados localmente no Azure ou armazenados em cache no local usando a Sincronização de Arquivos do Azure, o armazenamento padrão poderá ser uma melhor opção da perspectiva de custo.

Depois de criar um compartilhamento de arquivos em uma conta de armazenamento, não será possível movê-lo para camadas exclusivas de diferentes tipos de contas de armazenamento. Por exemplo, para mover um compartilhamento de arquivo com transação otimizada para a camada Premium, você precisará criar um compartilhamento de arquivo em uma conta de armazenamento do FileStorage e copiar os dados do compartilhamento original para um novo compartilhamento de arquivo na conta do FileStorage. Recomendamos usar o AzCopy para copiar dados entre compartilhamentos de arquivo do Azure, mas você também pode usar ferramentas como o robocopy no Windows ou o rsync no macOS e no Linux.

Confira Noções básicas sobre a cobrança dos Arquivos do Azure para saber mais.

Disponibilidade de região da Sincronização de Arquivos do Azure

Para disponibilidade regional, confira Produtos disponíveis por região.

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

• Sul da França
• Oeste da África do Sul
• EAU Central

Para solicitar acesso a essas regiões, siga o processo neste documento.

Redundância

Para proteger os dados em seus compartilhamentos de arquivos do Azure contra perda ou corrupção de dados, o Arquivos do Azure armazena várias cópias de cada arquivo à medida que eles são gravados. Dependendo de seus requisitos, você pode selecionar diferentes graus de redundância. No momento, os Arquivos do Azure são compatíveis com as seguintes opções de redundância de dados:

• LRS (armazenamento com redundância local) : com o LRS, cada arquivo é armazenado três vezes em um cluster de armazenamento do Azure. Isso fornece proteção 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 use o LRS poderão ser perdidas ou irrecuperáveis.
• Armazenamento com redundância de zona (ZRS): com ZRS, 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 em diferentes zonas de disponibilidade do Azure. As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais data centers equipados com energia, resfriamento e rede independentes. Uma gravação no armazenamento não será aceita até que seja gravada nos clusters de armazenamento de todas as três zonas de disponibilidade.
• Armazenamento com redundância geográfica (GRS): com o GRS, você tem duas regiões, 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 gravações são replicadas de maneira assíncrona para uma região secundária definida pela Microsoft. O GRS fornece seis cópias de seus dados difundidos entre duas regiões do Azure. No caso de um grande desastre, como a perda permanente de uma região do Azure devido a um desastre natural ou outro evento semelhante, a Microsoft executará um failover. Nesse caso, o secundário se torna o primário, atendendo a todas as operações. Como a replicação entre as regiões primária e secundária é assíncrona, no caso de um grande desastre, os dados ainda não replicados para a região secundária serão perdidos. Também será possível executar um failover manual de uma conta de armazenamento com redundância geográfica.
• Armazenamento com redundância de zona geográfica (GZRS): você pode pensar em GZRS como ZRS, mas com redundância geográfica. Com o GZRS, os arquivos são armazenados três vezes em três clusters de armazenamento distintos na região primária. Todas as gravações depois são replicadas de maneira assíncrona para uma região secundária definida pela Microsoft. O processo de failover para GZRS funciona da mesma forma que o GRS.

Os compartilhamentos de arquivos padrão do Azure de até 5 TiB dão suporte a todos os quatro tipos de redundância. Os compartilhamentos de arquivos padrão maiores que 5 TiB dão suporte apenas a LRS e ZRS. Os compartilhamentos de arquivo premium do Azure dão suporte apenas a LRS e ZRS.

As contas de armazenamento de uso geral versão 2 (GPv2) fornecem duas outras opções de redundância que os Arquivos do Azure não dão suporte: armazenamento com redundância geográfica com acesso de leitura(RA-GRS) e armazenamento com redundância de zona geográfica com acesso de leitura (RA-GZRS). Você pode provisionar compartilhamentos de arquivos do Azure em contas de armazenamento com essas opções definidas, no entanto, os Arquivos do Azure não dão 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 GRS ou GZRS, respectivamente.

Migração

Se você tiver um servidor de arquivos existente do Windows 2012R2 ou mais recente, a Sincronização de Arquivos do Azure poderá ser instalada diretamente no local, sem a necessidade de mover dados para um novo servidor. Se você estiver planejando migrar para um novo servidor de arquivos do Windows como parte da adoção da Sincronização de Arquivos do Azure ou se os dados estiverem localizados atualmente no NAS (armazenamento conectado à rede), haverá várias abordagens de migração possíveis para usar a Sincronização de Arquivos do Azure com esses dados. Qual abordagem de migração você deve escolher depende de onde seus dados residem atualmente.

Confira o artigo Visão geral de migração do compartilhamento de arquivo do Azure e da Sincronização de Arquivos do Azure para obter diretrizes detalhadas.

Antivírus

Como os antivírus funcionam com o exame de arquivos em busca de códigos mal-intencionados conhecidos, um antivírus pode causar o recall de arquivos em camadas, resultando em altos encargos de saída. Os arquivos em camadas têm o conjunto FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS de atributos seguros do Windows, e recomendamos consultar seu fornecedor de software para saber como configurar a solução para ignorar a leitura de arquivos com esse conjunto de atributos (muitas fazem isso automaticamente).

As soluções antivírus internas da Microsoft, o Windows Defender e o System Center Endpoint Protection (SCEP), ignoram automaticamente a leitura de arquivos que possuem esse atributo definido. Nós os testamos e identificamos um problema menor: quando você adiciona um servidor a um grupo de sincronização existente, os arquivos com menos de 800 bytes são recuperados (feitos o download) no novo servidor. Esses arquivos permanecerão no novo servidor e não serão organizados em camadas porque não atendem ao requisito de tamanho de camada (>64 kb).

Backup

Se a camada de nuvem estiver habilitada, as soluções que fazem backup diretamente do ponto de extremidade do servidor ou de uma VM na qual o ponto de extremidade do servidor está localizado não deverão ser usadas. A camada de nuvem faz com que apenas um subconjunto de seus dados seja armazenado no ponto de extremidade do servidor, com o conjunto de dados completo que reside em seu compartilhamento de arquivos do Azure. Dependendo da solução de backup usada, os arquivos em camadas serão ignorados e não serão armazenados em backup (porque eles têm o atributo FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS definido) ou serão recuperados para o disco, resultando em altos encargos de saída. É recomendável usar uma solução de backup de nuvem para fazer backup do compartilhamento de arquivos do Azure diretamente. Para obter mais informações, consulte Sobre o backup do compartilhamento de arquivos do Azure ou contate seu provedor de backup para ver se ele dá suporte ao backup de compartilhamentos de arquivos do Azure.

Se preferir usar uma solução de backup local, os backups devem ser realizados em um servidor do grupo de sincronização que tenha a camada de nuvem desabilitada, e certifique-se de que não haja arquivos em camadas. Ao executar uma restauração, use as opções de restauração no nível do volume ou no nível do arquivo. Os arquivos restaurados usando a opção de restauração no nível do arquivo serão sincronizados com todos os pontos de extremidade no grupo de sincronização e os arquivos existentes serão substituídos pela versão restaurada do backup. As restaurações no nível do volume não substituirão versões de arquivo mais recentes no compartilhamento de arquivos do Azure ou em outros pontos de extremidade do servidor.

Classificação de dados

Se você tiver um software de classificação de dados instalado, habilitar a camada de nuvem poderá resultar em um custo maior por dois motivos:

1. Com a camada de nuvem habilitada, seus arquivos mais quentes são armazenados em cache localmente e seus arquivos mais frios são colocados em camadas para o compartilhamento de arquivos do Azure na nuvem. Se a classificação de dados verificar regularmente todos os arquivos no compartilhamento de arquivos, os arquivos em camadas para a nuvem deverão ser chamados novamente (recall) sempre que forem verificados.

2. Se o software de classificação de dados usar os metadados no fluxo de dados de um arquivo, o arquivo deverá ser totalmente chamado de volta (recall) para que o software veja a classificação.

Esses aumentos tanto no número de recalls quanto na quantidade de dados que estão sendo chamados novamente pode aumentar os custos.

Política de atualização do agente de Sincronização de Arquivo do Azure

O agente de Sincronização de arquivos do Azure é atualizado regularmente para adicionar novos recursos e resolver problemas. É recomendável atualizar o agente Sincronização de Arquivos do Azure à medida que novas versões ficam disponíveis.

Versões do agente principal versus secundário

• As versões do agente principal geralmente contêm novos recursos e têm um número crescente como a primeira parte do número da versão. Por exemplo: 17.0.0.0
• As versões do agente secundário também são chamadas de "patches" e são lançadas com mais frequência do que as versões do principal. Geralmente contêm correções de bug e pequenas melhorias, mas sem novos recursos. Por exemplo: 17.2.0.0

Caminhos de atualização

Há quatro maneiras aprovadas e testadas para instalar as atualizações do agente de Sincronização de Arquivos do Azure.

1. Usar o recurso de atualização automática do agente de Sincronização de Arquivos do Azure para instalar atualizações do agente. O agente Sincronização de Arquivos do Azure será atualizado automaticamente. Você pode selecionar para instalar a versão mais recente do agente quando disponível ou atualizar quando o agente atualmente instalado estiver próximo do término. Para saber mais, confira Gerenciamento automático do ciclo de vida do agente.
2. Configurar o Microsoft Update para baixar e instalar automaticamente as atualizações do agente. É recomendado instalar todas as atualizações de Sincronização de Arquivos do Azure para garantir que você tenha acesso às últimas correções para o Server Agent. O Microsoft Update simplifica esse processo, baixando e instalando atualizações automaticamente para você.
3. Use AfsUpdater.exe para baixar e instalar atualizações de agente. O AfsUpdater.exe está localizado no diretório de instalação do agente. Clique duas vezes no executável para baixar e instalar atualizações de agente. Dependendo da versão, talvez seja necessário reiniciar o servidor.
4. Corrigir um agente existente de Sincronização de arquivos do Azure utilizando um arquivo de patch do Microsoft Update ou um executável .msp. O último pacote de atualização da Sincronização de Arquivos do Azure pode ser baixado no Catálogo do Microsoft Update. O uso de um executável .msp atualizará a instalação da Sincronização de Arquivos do Azure com o mesmo método usado automaticamente pelo Microsoft Update. A aplicação de um patch do Microsoft Update realizará uma atualização no local de uma instalação e Sincronização de arquivos do Azure.
5. Baixe o instalador mais recente do agente da Sincronização de Arquivos do Azure no Centro de Download da Microsoft. Para fazer upgrade de uma instalação existente do agente de Sincronização de Arquivos do Azure, desinstale a versão mais antiga e então instale a última versão do instalador baixado. O registro do servidor, os grupos de sincronização e outras configurações são mantidos pelo instalador de Sincronização de arquivos do Azure.

Gerenciamento automático do ciclo de vida do agente

O agente Sincronização de Arquivos do Azure será atualizado automaticamente. Você pode selecionar um dos dois modos e especificar uma janela de manutenção na qual a atualização deve ser tentada no servidor. Esse recurso foi projetado para ajudá-lo com o gerenciamento do ciclo de vida do agente, fornecendo uma proteção que impede o agente de expirar ou permitindo uma configuração atual sem complicações.

1. A configuração padrão tentará impedir que o agente expire. Dentro de 21 dias a partir da data de expiração publicada de um agente, o agente tentará fazer o upgrade automaticamente. Ele iniciará uma tentativa de atualização uma vez por semana dentro de 21 dias antes da expiração e na janela de manutenção selecionada. Essa opção não elimina a necessidade de obter patches regulares do Microsoft Update.
2. Opcionalmente, você pode selecionar que o agente será atualizado automaticamente assim que uma nova versão do agente se tornar disponível (atualmente não aplicável a servidores em cluster). Essa atualização ocorrerá durante a janela de manutenção selecionada e permitirá que seu servidor se beneficie de novos recursos e melhorias assim que estiverem disponíveis. Esta é a configuração recomendada e sem preocupações que fornecerá as principais versões do agente, bem como patches de atualização regulares para o seu servidor. Cada agente liberado é de qualidade GA. Se você selecionar esta opção, a Microsoft enviará a você a versão mais recente do agente. Os servidores em cluster são excluídos. Assim que o período de veiculação for concluído, o agente também estará disponível no Microsoft Update e no Microsoft Download Center.

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 e navegue até o diretório em que você instalou o agente de sincronização e importe os cmdlets do servidor. Por padrão, seria algo assim:

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 da política atual para a faixa de atualização imediata, você pode usar:

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

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

A Sincronização de Arquivos do Azure é um serviço de nuvem que apresenta continuamente novos recursos e aprimoramentos. Isso significa que uma versão específica do agente de Sincronização de arquivos do Azure somente poderá ter suporte por um tempo limitado. Para facilitar sua implantação, as seguintes regras garantem que você tenha tempo e notificação suficientes para acomodar atualizações/upgrades de agente em seu processo de gerenciamento de mudança:

• As versões do agente principal terão suporte por pelo menos seis meses, a partir da data da versão inicial.
• Garantimos que há uma sobreposição de pelo menos três meses entre o suporte das versões do agente principal.
• Avisos para servidores registrados que utilizam um agente que expirará em breve serão emitidos pelo menos três meses antes da expiração. É possível verificar se um servidor registrado está usando uma versão mais antiga do agente na seção de servidores registrados de um Serviço de Sincronização de Armazenamento.
• O tempo de vida de uma versão do agente secundário está associado à versão principal associada. Por exemplo, quando a versão 17.0.0.0 do agente estiver configurada para expirar, as versões 17.*.*.* do agente serão todas configuradas para expirar juntas.

Próximas etapas

• Considere as configurações de firewall e proxy
• Implantar os Arquivos do Azure
• Implantar a Sincronização de Arquivos do Azure
• Monitorar a Sincronização de Arquivos do Azure