Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A Sincronização de Arquivos do Azure é um serviço que você poderá usar para armazenar em cache vários compartilhamentos de arquivos do Azure em uma instância do Windows Server local ou VM (máquina virtual) de 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 são armazenados na nuvem em compartilhamentos de arquivos do Azure. É possível usar compartilhamentos de arquivos do Azure das duas maneiras a seguir. A opção de implantação escolhida altera os aspectos que você precisa considerar ao planejar sua implantação.
Monte diretamente um compartilhamento de arquivos do Azure usando o protocolo SMB (Bloco de Mensagem de Servidor): como os Arquivos do Azure fornecem acesso AMB, 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 os cenários de produção não exige o gerenciamento de um servidor de arquivos ou dispositivo de NAS (servidor de acesso à rede). Esta escolha significa que você não precisa aplicar patches de software nem trocar discos físicos.
Armazenar em cache um compartilhamento de arquivo do Azure local usando a Sincronização de arquivos do Azure: com a Sincronização de Arquivos do Azure, você poderá centralizar os compartilhamentos de arquivo da organização nos Arquivos do Azure, mantendo a flexibilidade, o desempenho e a compatibilidade de um servidor de arquivos local. A Sincronização de Arquivos do Azure transforma uma instância do Windows Server local (ou em nuvem) em um cache rápido do compartilhamento de arquivo do Azure.
Conceitos de gerenciamento
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 a Sincronização de Arquivos do Azure, você trabalhará com dois recursos principais:
Contas de armazenamento, oferecidas pelo provedor de recursos
Microsoft.Storage. As contas de armazenamento são recursos de nível superior que representam um pool compartilhado de armazenamento, IOPS e taxa de transferência em que 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 aplicáveis 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 a Sincronização de Arquivos do Azure com compartilhamentos de arquivos SMB.Observação
Os Arquivos do Azure também oferecem suporte à implantação de compartilhamentos de arquivos como um recurso de nível superior do Azure por meio do
Microsoft.FileSharesprovedor de recursos. No entanto, como esses compartilhamentos de arquivos atualmente dão suporte apenas ao protocolo NFS, eles não são compatíveis com a Sincronização de Arquivos do Azure.Serviços de Sincronização de Armazenamento, oferecidos pelo provedor de recursos
Microsoft.StorageSync. 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 arquivo do Azure
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 os Arquivos do Azure. Eles dão suporte a todos os principais recursos que os Arquivos do Azure dão suporte, incluindo camadas de mí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 usadas para implantações de compartilhamento de arquivos clássico:
-
Contas de armazenamento provisionadas: as contas de armazenamento provisionadas são distinguidas usando o tipo de conta de armazenamento
FileStorage. 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. É recomendável usar contas de armazenamento provisionadas para todas as novas implantações de compartilhamento de arquivos clássicos. -
Contas de armazenamento de pagamento conforme o uso: as contas de armazenamento de pagamento conforme o uso são distinguidas usando o tipo de conta de armazenamento
StorageV2. As contas de armazenamento de Pagamento Conforme o Uso permitem que você implante compartilhamentos de arquivos de Pagamento Conforme o Uso no hardware baseado em HD. As contas de armazenamento de pagamento conforme o uso 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 de Sincronização de Arquivos do Azure
Em um Serviço de Sincronização de Armazenamento, você poderá 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 ou cluster individual, no entanto, um servidor/cluster só pode ser registrado com apenas um Serviço de Sincronização de Armazenamento por vez.
Sincronizar grupos, que definem a relação de sincronização entre um ponto de extremidade de nuvem e um ou mais pontos de extremidade de 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.
- Pontos de extremidade de nuvem, que representam compartilhamentos de arquivos do Azure.
- Pontos de extremidade do servidor, que representam caminhos em servidores registrados que são sincronizados com os Arquivos do Azure. Um servidor registrado poderá conter vários pontos de extremidade de servidor se seus namespaces não se sobrepõem.
Importante
Você pode fazer alterações ao namespace de qualquer ponto de extremidade de nuvem ou de servidor no grupo de sincronização e ter seus arquivos sincronizados com os outros pontos de extremidade no grupo de sincronização. Caso faça uma alteração diretamente no Ponto de extremidade de nuvem (compartilhamento de Arquivos do Azure), um trabalho de detecção de alteração de Sincronização de Arquivos do Azure precisará primeiro descobrir as alterações. Um trabalho de detecção de alterações para um ponto de extremidade de nuvem é iniciado apenas uma vez a cada 24 horas. Para obter mais informações, consulte Perguntas frequentes sobre os Arquivos do Azure e a Sincronização de Arquivos do Azure.
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 Sincronização de Arquivos do Azure. Ele gerencia as relações de sincronização entre as 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 principal do Resource Manager para criar pontos de extremidade de servidor no servidor.
Ao projetar topologias de Sincronização de Arquivos do Azure, isole os dados claramente no nível do serviço de sincronização de armazenamento. Por exemplo, se sua empresa exigir ambientes separados de Sincronização de Arquivos do Azure para duas unidades de negócios distintas e você precisar de isolamento de dados estrito entre esses grupos, você deverá criar 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, pois essa configuração não garantiria o isolamento completo.
Para obter mais diretrizes sobre o isolamento de dados usando assinaturas ou grupos de recursos separados no Azure, consulte os Provedores e tipos de recursos do Azure.
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 ajuda você a determinar quantas contas de armazenamento, compartilhamentos de arquivos do Azure e recursos de sincronização são necessários. Essas considerações são relevantes mesmo se os dados não residem atualmente em uma instância do Windows Server ou no servidor que você deseja usar em longo prazo. A seção de migração deste artigo pode ajudar você a determinar os caminhos de migração apropriados para sua situação.
Nesta etapa, você determina quantos compartilhamentos de arquivos do Azure você precisa. 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, você precisa apenas de um único compartilhamento de arquivos do Azure na nuvem 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. Caso sincronize 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:
- A verificação inicial do conteúdo da nuvem pode terminar mais rápido, o que, por sua vez, diminui a espera para que o namespace apareça em um servidor habilitado para Sincronização de Arquivos do Azure.
- A restauração do lado da nuvem 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.
- Alterações feitas diretamente em um compartilhamento de arquivos do Azure (fora de uma sincronização) podem ser detectadas e sincronizadas mais rapidamente.
Dica
Se você não souber quantos arquivos e pastas você tem, confira a ferramenta TreeSize do Software JAM.
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. Este mapeamento informa 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 otimizar seu mapa e decidir quantos compartilhamentos de arquivos do Azure você precisa, examine os seguintes limites e práticas recomendadas:
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 arquivos do Azure. O ideal seria mapear os compartilhamentos de arquivo um a um com as contas de armazenamento. No entanto, esse mapeamento pode nem sempre ser possível devido a vários limites e restrições, tanto da sua organização quanto do Azure. Quando você não puder implantar apenas um compartilhamento de arquivo em uma conta de armazenamento, considere quais compartilhamentos serão altamente ativos e quais compartilhamentos serão menos ativos. Não coloque os compartilhamentos de arquivos mais quentes juntos 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.
Dica
Com base nessas informações, geralmente se torna necessário agrupar várias pastas de nível superior em seus volumes em um novo diretório raiz comum. Em seguida, você sincroniza esse novo diretório raiz e todas as pastas que agrupou nele para um único compartilhamento de arquivos do Azure. Essa técnica permite que você permaneça dentro do limite de 30 sincronizações de compartilhamento de arquivos do Azure por servidor.
Esse agrupamento em uma raiz comum não afeta o acesso aos dados. As ACLs continuam como estão. Você só precisa ajustar quaisquer caminhos de compartilhamento (como compartilhamentos SMB ou NFS) que você possa ter nas pastas do servidor local que você alterou para uma raiz comum. Nada mais muda.
Importante
O vetor de escala mais importante da Sincronização de Arquivos do Azure é o número de itens (arquivos e pastas) que precisam ser sincronizados. Examine os destinos de escala de Sincronização de Arquivos do Azure para obter mais detalhes.
É possível que, em sua situação, um conjunto de pastas possa sincronizar logicamente com o mesmo compartilhamento de arquivos do Azure (usando a abordagem 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 balanceados pelo 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.
Importante
O vetor de escala mais importante da Sincronização de Arquivos do Azure é o número de itens (arquivos e pastas) que precisam ser sincronizados. Para obter mais detalhes, examine os destinos de escala da Sincronização de Arquivos do Azure.
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) |
|---|---|---|---|
| Servidor de arquivos com vários discos/volumes e vários compartilhamentos para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) | Não | Um compartilhamento de arquivos do Azure de destino (ponto de extremidade de nuvem) dá suporte à sincronização com apenas um grupo de sincronização. Um grupo de sincronização dá suporte a apenas um ponto de extremidade de servidor por servidor registrado. |
1) Comece com a sincronização de um disco (seu volume raiz) para um compartilhamento de arquivos do Azure de destino. Começar com o maior disco/volume ajudará com os requisitos de armazenamento locais. Configure a camada de nuvem para colocar todos os dados em camadas na nuvem, para que você possa liberar 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 um a um até que todos os dados sejam em camadas até a nuvem ou migrados. 2) Direcione um volume raiz (disco) por vez. Use a camada de nuvem para colocar todos os dados em camadas para o compartilhamento de arquivos do Azure de destino. Remova o ponto de extremidade do servidor do grupo de sincronização, crie novamente o ponto de extremidade com o próximo volume/disco raiz, sincronize e, em seguida, repita o processo. Observe que talvez seja necessário reinstalar o agente. 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). |
| Servidor de arquivos com um único volume e vários compartilhamentos para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) | Sim | Não é possível ter vários pontos de extremidade de servidor por servidor registrado sincronizando com o mesmo compartilhamento de arquivos do Azure de destino (igual ao cenário anterior). | Sincronize a raiz do volume que contém vários compartilhamentos ou pastas de nível superior. |
| 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 compartilhadas entre compartilhamentos de arquivos. Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. É melhor 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 por vez podem ser sincronizados neste cenário. Caso tenha mais de 30 compartilhamentos nesse servidor de arquivos, use o agrupamento de compartilhamento e a sincronização de volume para reduzir o número de pastas raiz ou de nível superior na origem. 3) Use servidores adicionais de Sincronização de Arquivos do Azure local e divida ou mova dados para esses servidores para contornar as limitações na instância do Windows Server de origem. |
| Servidor de arquivos com vários compartilhamentos e/ou volumes para vários compartilhamentos de arquivos do Azure em uma conta de armazenamento diferente (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 dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. É melhor ficar abaixo de 20 ou 30 milhões por ação. |
O mesmo que a abordagem anterior. |
| 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 um ponto de extremidade de nuvem (compartilhamento de arquivos do Azure) que já está 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 primeiro cenário, com a consideração adicional de direcionar um servidor de arquivos por vez. |
| Topologia entre locatários (utilizando identidade gerenciada entre diferentes locatários) | Não | O Serviço de Sincronização de Armazenamento, o recurso de servidor (servidor habilitado para Azure Arc ou VM do Azure), a identidade gerenciada e as atribuições de RBAC na conta de armazenamento devem estar todos no mesmo locatário do Microsoft Entra. Não há suporte para topologias interlocatárias. | As configurações entre locatários falham na autenticação e na autorização e o servidor não pode se conectar. Para continuar, verifique se todos os recursos (Serviço de Sincronização, servidor, identidade gerenciada e atribuições RBAC) são criados no mesmo locatário do Microsoft Entra. |
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 que registra seus pensamentos para que você possa se referir a ela quando precisar. Manter-se organizado é importante, pois a perda de detalhes do seu plano de mapeamento pode acontecer facilmente ao estar provisionando muitos recursos do Azure ao mesmo tempo. 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 para servidores 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 de servidor e iniciar as sessões de sincronização -
StorageSync.sys, um filtro do sistema de arquivos que habilita a camada de nuvem e a recuperação de desastres rápida
Requisitos do sistema operacional
A Sincronização de Arquivos do Azure é compatível com as seguintes versões do Windows Server:
| Versão | Versão RTM | Edições com suporte | Opções de implantação com suporte |
|---|---|---|---|
| Windows Server 2025 | 26100 | Azure, Datacenter, Essentials, Standard e IoT | Completo e Core |
| Windows Server 2022 | 20348 | Azure, Datacenter, Essentials, Standard e IoT | Completo e Core |
| Windows Server 2019 | 17763 | Datacenter, Essentials, Standard e IoT | Completo e Core |
| Windows Server 2016 | 14393 | Datacenter, Essentials, Standard e Servidor de Armazenamento | Completo e Core |
Recomendamos manter todos os servidores usados com a Sincronização de Arquivos do Azure atualizados com as últimas atualizações do Windows Update.
Recursos mínimos do sistema
A Sincronização de Arquivos do Azure requer um servidor, físico ou virtual, com todos esses 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 na Sincronização de Arquivos do Azure com apenas os requisitos mínimos.
Recursos de sistema recomendados
Assim como qualquer recurso de servidor ou aplicativo, 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 mais recursos do sistema.
Na Sincronização de Arquivos do Azure, o número de objetos entre os pontos de extremidade do servidor e a variação no conjunto de dados determinam a escala. Um único servidor pode ter pontos de extremidade do servidor em vários grupos de sincronização. 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. Devido a essa configuração, namespaces maiores exigem mais memória para manter um bom desempenho. Mais variação requer mais CPUs para processar.
A tabela a seguir fornece o tamanho do namespace e 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 (rotatividade típica) |
| 30 | 14.0 | oito | 48 (sincronização inicial)/ 16 (variação típica) |
| 50 | 23,3 | 16 | 64 (sincronização inicial)/ 32 (rotatividade 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.
Dica
A sincronização inicial de um namespace é uma operação intensiva. Recomendamos alocar mais memória até que a sincronização inicial seja concluída. Esta abordagem não é necessária, mas pode acelerar a sincronização inicial.
A variação típica é de 0,5% da alteração de namespace por dia. Para níveis mais altos de variação, considere adicionar mais CPUs.
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) dos recursos mencionados neste artigo. Recomendamos que você leia o restante desta seção com cuidado para garantir que sua implantação fique tranquila.
Você poderá instalar o cmdlet de avaliação instalando o módulo do Az PowerShell. Para obter instruções, confira Instalar o Azure PowerShell.
Uso
Você poderá invocar a ferramenta de avaliação executando verificações do 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 um arquivo .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 (DAS) no Windows Server significa que o sistema operacional do Windows Server é proprietário do sistema de arquivos. Você poderá fornecer DAS anexando discos físicos ao servidor de arquivos, anexando discos virtuais a uma VM do servidor de arquivos (como uma VM hospedada pelo Hyper-V) ou até mesmo usando a Internet SCSI.
Há suporte para apenas os volumes NTFS. ReFS, FAT, FAT32 e outros sistemas de arquivos não têm suporte.
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 | A Sincronização de Arquivos do Azure preserva ACLs discricionárias no estilo Windows. O Windows Server impõe essas ACLs em pontos de extremidade do servidor. Também é possível impor ACLs ao montar diretamente o compartilhamento de arquivos do Azure, mas esse método requer configuração adicional. Para obter mais informações, consulte a seção Identidade mais adiante neste artigo. |
| 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 o namespace de um ponto de extremidade de servidor os contiver. |
| Junções | Ignorado | Exemplos são DFS (Sistema de Arquivos Distribuído) DfrsrPrivate e pastas DFSRoots. |
| Pontos de nova análise | Ignorado | |
| Compactação NTFS | Suporte parcial | A Sincronização de Arquivos do Azure não dá suporte a pontos de extremidade de servidor localizados em um volume que compacta o diretório de informações de volume do sistema (SVI). |
| 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. |
Observação
Compactação NTFS com hierarquização na nuvem
O uso da compactação NTFS em arquivos em camadas pode causar um impacto significativo no desempenho. Não é recomendado usar classificação em nuvem com arquivos compactados.
Se os arquivos compactados já tiverem sido colocados em camadas, eles deverão ser descompactados depois de recuperar os dados da nuvem executando:
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>
O uso da compactação NTFS em arquivos em camadas pode causar um impacto significativo no desempenho. Não é recomendado usar classificação em nuvem com arquivos compactados.
Você pode descompactar arquivos usando o comando compacto .
No Windows Server 2019 ou posterior, o comando compacto ignora arquivos em camadas, portanto, você deve cancelar o arquivo primeiro antes de descompactá-lo.
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>
Se a recuperação de arquivos resultar em problemas de pouco espaço em disco, você deve aguardar que o armazenamento em camadas em segundo plano entre em ação e armazene o arquivo em camadas novamente antes de recuperar mais arquivos, ou armazene o arquivo em camadas novamente após a descompactação executando o cmdlet.
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path <path>
A Sincronização de Arquivos do Azure também ignora determinados arquivos temporários e pastas do sistema:
| Arquivo/pasta | Observação |
|---|---|
pagefile.sys |
Arquivo específico de um sistema |
Desktop.ini |
Arquivo específico de um 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 |
Acessar o arquivo de bloqueio de banco de dados |
635D02A9D91C401B97884B82B3BCDAEA.* |
Arquivo de sincronização interna |
\System Volume Information |
Pasta específica de um volume |
$RECYCLE.BIN |
Pasta |
\SyncShareState |
Pasta para sincronização |
.SystemShareInformation |
Pasta para sincronização em um compartilhamento de arquivo do Azure |
Observação
Embora a Sincronização de Arquivos do Azure dê suporte à sincronização de arquivos de banco de dados, os bancos de dados não são uma boa carga de trabalho para soluções de sincronização (incluindo a Sincronização de Arquivos do Azure). Os arquivos de log e os bancos de dados precisam ser sincronizados juntos e podem sair da sincronização por vários motivos que podem levar à corrupção do banco de dados.
Espaço livre em seu disco local
Ao planejar usar a Sincronização de Arquivos do Azure, considere quanto espaço livre você precisa no disco local para o 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 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
O exemplo a seguir ilustra como estimar a quantidade de espaço livre que você precisa em seu 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 deseja 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%.
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)
Para se beneficiar totalmente da camada de nuvem, recomendamos que você use tamanhos de cluster NTFS menores (menos de 64 KiB) porque cada arquivo em camadas ocupa um cluster. Além disso, o NTFS aloca o espaço que os arquivos em camadas 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 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)
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 que você considere necessário para esse disco.
Clustering de failover
A Sincronização de Arquivos do Azure oferece suporte ao clustering de failover do Windows Serve 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.
O único cenário que a Sincronização de Arquivos do Azure suporta é o cluster de failover do servidor do Windows com discos clusterizados. Não há suporte para clustering de failover em Servidor de Arquivos de Escalabilidade Horizontal, CSVs (Volumes Compartilhados clusterizados) ou discos locais.
Para que a sincronização funcione corretamente, o agente de Sincronização de Arquivos do Azure deve ser instalado em cada nó em um cluster de failover.
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 2025, o Windows Server 2022, o Windows Server 2019 e o Windows Server 2016. 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.
Ao habilitar a Eliminação de Duplicação de Dados em um volume com camadas de nuvem habilitadas, arquivos com otimização de eliminação de duplicação no local do ponto de extremidade do servidor são colocados em camadas de forma semelhante a um arquivo normal, com base nas configurações de política para camadas de nuvem. Depois de colocar os arquivos otimizados para eliminação de duplicação em camadas, o trabalho de GC de Eliminação de Duplicação de Dados será executado automaticamente. Ele recupera o 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 Eliminação de Duplicação de Dados está instalado, o espaço de volume disponível pode aumentar mais do que o esperado depois que o GC de eliminação de duplicação é disparado. O exemplo a seguir descreve como o espaço em volume funciona:
- A política de espaço livre para a camada de nuvem esteja definida como 20%.
- A Sincronização de Arquivos do Azure é notificada quando o espaço livre é baixo (digamos 19%).
- A camada determina que 1% mais espaço precisa ser liberado, mas você deseja 5% extra, portanto, você pode colocar em camadas até 25% (por exemplo, 30 GiB).
- Os arquivos são em camadas até você chegar a 30 GiB.
- Como parte da interoperabilidade com a Eliminação de Duplicação de Dados, a Sincronização de Arquivos do Azure inicia o GC no final da sessão em camadas.
A economia de volume se aplica somente ao servidor. Seus dados no compartilhamento de arquivos do Azure não são duplicados.
Observação
Para dar suporte à Eliminação de Duplicação de Dados em volumes com a camada de nuvem habilitada no Windows Server 2019, você deve instalar o Windows Update KB4520062 - Outubro de 2019, ou uma atualização cumulativa mensal posterior.
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. Caso habilite a Eliminação de Duplicação de Dados em um volume, deverá desabilitar a camada de nuvem.
Observações
Caso instale a Eliminação de Duplicação de Dados for instalada antes de instalar o 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.
Caso habilite a Eliminação de Duplicação de Dados em um volume depois de habilitar a camada de nuvem, o trabalho inicial de otimização de eliminação de duplicação otimizará os arquivos no volume que ainda não estão em camadas. Este trabalho tem o seguinte impacto na camada de nuvem:
- A política de espaço livre continua a colocar arquivos em camadas de acordo com o espaço livre no volume usando o mapa de calor.
- A política de data ignora a camada de arquivos que podem ser qualificados para camadas porque o trabalho de otimização de eliminação de duplicação está acessando os arquivos.
Para trabalhos contínuos de otimização de eliminação de duplicação, a configuração MinimumFileAgeDays de Eliminação de Duplicação de Dados, atrasa a camada de nuvem com a política de dados, se o arquivo ainda não estiver em camadas.
- Por exemplo, se a configuração
MinimumFileAgeDaysfor de 7 dias e a política de dados para camadas de nuvem for de 30 dias, a política de data colocará os arquivos em camadas após 37 dias. - Depois que a Sincronização de Arquivos do Azure nivela um arquivo, o trabalho de otimização de eliminação de duplicação ignora o arquivo.
- Por exemplo, se a configuração
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 2025, o Windows Server 2022, o Windows Server 2019 ou o Windows Server 2016, você deverá executar as seguintes etapas 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 2025, Windows Server 2022, Windows Server 2019 ou Windows Server 2016).
- Instale o agente de Sincronização de Arquivos do Azure e reinicie o servidor.
O servidor mantém suas configurações de Sincronização de Arquivos do Azure quando o agente é desinstalado e reinstalado.
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
A Sincronização de Arquivos do Azure tem suporte total com a 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
Como o DFS-R e a Sincronização de arquivos do Azure são soluções de replicação, é recomendável substituir DFS-R pela Sincronização de Arquivos do Azure na maioria dos casos. Mas você deve usar DFS-R e Sincronização de Arquivos do Azure em conjunto nos seguintes cenários:
- 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 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 deseja 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:
- A camada de nuvem da Sincronização de arquivos do Azure deve ser desabilitada em volumes com pastas replicadas DFS-R.
- Os pontos de extremidade do servidor não devem ser configurados em pastas de replicação somente leitura DFS-R.
- 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 a Visão geral dos Namespaces do DFS e 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 que você implantar a imagem do servidor e concluir a mini-instalação do Sysprep.
Windows Search
Se a camada de nuvem estiver habilitada em um ponto de extremidade do servidor, o Windows Search ignorará os arquivos em camadas e não os indexará. O Windows Search indexa arquivos não em camadas corretamente.
Clientes Windows causam recalls ao pesquisar 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 é desabilitada por padrão.
Outras soluções de HSM
Você não deve usar outras soluções de HSM (gerenciamento de armazenamento hierárquico) com a Sincronização de Arquivos do Azure.
Desempenho e escala
Como o agente de Sincronização de Arquivos do Azure é executado em um computador Windows Server que se conecta aos compartilhamentos de arquivos do Azure, o desempenho de sincronização em vigor depende destes 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 arquivo
- Tamanho total do conjunto de dados
- Atividade no conjunto de dados
A Sincronização de Arquivos do Azure funciona no nível do arquivo. As características de desempenho de uma solução com base na Sincronização de Arquivos do Azure 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 da Sincronização de Arquivos do Azure e Destinos de escala da Sincronização de Arquivos do Azure
Identidade
O administrador que registra o servidor e cria o ponto de extremidade de nuvem deve ser um membro das funções Administrador de Sincronização de Arquivos do Azure, Proprietário ou Colaborador para o serviço de sincronização de armazenamento fornecido. É possível configurar essa função no IAM (Controle de Acesso) na página do portal do Azure para o serviço de sincronização de armazenamento.
Ao atribuir a função de Administrador de Sincronização de Arquivos do Azure, siga estas etapas para garantir privilégios mínimos.
Na guia Condições, selecione Permitir que os usuários atribuam perfis selecionados apenas a principais selecionados, com menos privilégios.
Clique em Selecionar Funções e Entidades e selecione Adicionar Ação em Condição #1.
Selecione Criar atribuição de função e clique em Selecionar.
Selecione Adicionar expressão e, em seguida, selecione Solicitação.
Em Origem do Atributo, selecione ID de Definição de Função em Atributoe, em seguida, selecione ForAnyOfAnyValues:GuidEquals em Operador.
Selecione Adicionar Funções. Adicione as funções Leitor e Acesso a Dados, Colaborador Privilegiado de Dados de Arquivo de Armazenamento e Colaborador da Conta de Armazenamento e, em seguida, selecione Salvar.
A Sincronização de Arquivos do Azure trabalha com sua identidade padrão baseada em Active Directory sem 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 arquivo do Azure. Como os pontos de extremidade do servidor estão no Windows Server e o Windows Server dá suporte a ACLs no estilo Active Directory e Windows, você não precisa de nada além de garantir que os servidores de arquivos do Windows registrados com o serviço de sincronização de armazenamento sejam ingressados no domínio. A Sincronização de Arquivos do Azure 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 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 Active Directory no compartilhamento de arquivos diretamente na nuvem. Para fazer essa configuração, você deve ingressar sua conta de armazenamento na sua instância do Active Directory local, assim como os servidores de arquivos do Windows são ingressados no domínio. Para saber mais sobre como ingressar o domínio em sua conta de armazenamento em uma instância do Active Directory de propriedade do cliente, consulte Visão geral da autenticação baseada em identidade dos Arquivos do Azure para acesso SMB.
Importante
Não é necessário ingressar sua conta de armazenamento no domínio do Active Directory para implantar a Sincronização de Arquivos do Azure com sucesso. É uma etapa opcional que permite que o compartilhamento de arquivo do Azure imponha ACLs locais quando os usuários montam o compartilhamento de arquivo do Azure diretamente.
Redes
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. Esses dois protocolos sempre usam HTTPS pela porta 443. O SMB nunca é usado para carregar nem baixar dados entre a instância do 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 uma configuração de rede especial não é necessária para implantar a Sincronização de Arquivos do Azure.
Importante
A Sincronização de Arquivos do Azure não dá suporte ao roteamento da internet. A Sincronização de Arquivos do Azure dá suporte à opção de roteamento de rede padrão, Roteamento da Microsoft.
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. A Sincronização de Arquivos do Azure fornece vários mecanismos para você configurar redes. Com base em seus requisitos, você pode:
- Sincronização de túnel e tráfego de upload/download de arquivos no Azure ExpressRoute ou em uma VPN (rede virtual privada) 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.
Caso queira se comunicar com o compartilhamento de arquivos do Azure por SMB, mas a porta 445 estiver bloqueada, considere o uso de SMB sobre QUIC. Esse método oferece uma VPN de configuração zero para acesso SMB aos compartilhamentos de arquivos do Azure por meio do protocolo de transporte QUIC pela porta 443. Embora os Arquivos do Azure não ofereçam suporte diretamente ao SMB via QUIC, você pode criar um cache leve de seus compartilhamentos de arquivo 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, veja SMB via QUIC.
Para saber mais sobre a Sincronização de Arquivos do Azure e rede, confira Considerações de rede para a Sincronização de Arquivos do Azure.
Criptografia
A Sincronização de Arquivos do Azure oferece três camadas de criptografia: 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 inativa para os dados no compartilhamento de arquivo do Azure.
Criptografia em repouso do Windows Server
Duas estratégias para criptografar dados no Windows Server geralmente funcionam com a Sincronização de Arquivos do Azure:
- Criptografia abaixo do sistema de arquivos, de modo que o sistema de arquivos e todos os dados gravados nele sejam criptografados
- Criptografia dentro do próprio formato de arquivo
Esses métodos não são mutuamente exclusivos. É possível optar por usá-los juntos porque a finalidade da criptografia é diferente.
Para fornecer criptografia subjacente ao sistema de arquivos, o Windows Server oferece 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:
- Impedir a exfiltração física de dados do datacenter local por alguém roubando os discos
- Impedir o sideload de um sistema operacional não autorizado para executar leituras e gravações não autorizadas em seus dados
Para saber mais, veja Visão geral do BitLocker.
Os produtos de parceiros que funcionam de maneira semelhante ao BitLocker, no que ficam subjacente ao volume NTFS, devem funcionar de maneira completa e 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 essa tarefa nativamente, mas geralmente não fazem isso.
Os métodos de exemplo para criptografar o fluxo de dados do arquivo são a Proteção de Informações do Azure, o Azure RMS (Azure Rights Management) e o Active Directory Rights Management Services. O principal motivo 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 compartilhamento de arquivos por pessoas que os copiam para locais alternativos (como uma unidade flash) ou envie-os 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 continua 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 ou soluções de criptografia de parceiros 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. Esses dois protocolos 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. Essa opção está habilitada por padrão. Mesmo que a opção no nível da conta de armazenamento esteja desabilitada e as conexões não criptografadas com os compartilhamentos de arquivo do Azure sejam possíveis, a Sincronização de Arquivos do Azure ainda usa apenas canais criptografados para acessar seu compartilhamento de arquivo.
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 mais antiga do Linux. 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 habilitar 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.
Observação
O serviço de Sincronização de Arquivos do Azure removeu o suporte para TLS 1.0 e 1.1 em 1º de agosto de 2020. Todas as versões de agente da Sincronização de Arquivos do Azure compatíveis já usam o TLS 1.2 por padrão. Você pode estar usando uma versão anterior do TLS se tiver desabilitado o TLS 1.2 no servidor ou se usar um proxy.
Caso use um proxy, recomendamos que você verifique a configuração do proxy. As regiões de serviço de Sincronização de Arquivos do Azure adicionadas após 1º de maio de 2020 dão suporte apenas ao TLS 1.2. Para obter mais informações, confira o guia de solução de problemas.
Criptografia de compartilhamento de arquivo do Azure em repouso
Todos os dados armazenados nos Arquivos do Azure são criptografados em repouso por meio da SSE (Criptografia do Serviço de Armazenamento) do Azure. A 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 abaixo do sistema de arquivos do compartilhamento de arquivo do Azure, enquanto são codificados no disco, não é necessário ter acesso à chave subjacente no cliente para ler ou gravar 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 contém as chaves para criptografar e descriptografar os dados. A Microsoft é responsável por girar essas chaves regularmente.
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 chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento. Mas sem essa autorização, o compartilhamento de arquivo 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 a SSE do Armazenamento do Azure, confira Criptografia do Armazenamento do Azure para obter dados inativos.
Camadas de armazenamento
Os Arquivos do Azure oferecem duas camadas de mídia de armazenamento: SSD (unidade de estado sólido) e HDD (unidade de disco rígido). Essas camadas permitem que você adapte seus compartilhamentos aos requisitos de desempenho e preço do seu cenário:
SSD (premium): os compartilhamentos de arquivos SSD fornecem alto desempenho consistente e baixa latência, dentro de milissegundos de dígito único para a maioria das operações de E/S, para cargas de trabalho com uso intensivo 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 cobrança provisionados v2 e provisionados v1. Os compartilhamentos de arquivos SSD oferecem um SLA de maior disponibilidade do que os compartilhamentos de arquivos HDD.
HDD (padrão): os compartilhamentos de arquivos em HDD oferecem uma opção de armazenamento econômica para compartilhamentos de arquivos de uso geral. Os compartilhamentos de arquivos HDD estão disponíveis nos modelos de cobrança provisionados v2 e de pagamento conforme o uso, embora recomendemos o modelo provisionado v2 para novas implantações de compartilhamentos de arquivos. Para obter informações sobre o SLA, confira a página 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 carga de trabalho exigir latência de dígito único ou se você estiver usando a mídia de armazenamento SSD localmente, os compartilhamentos de arquivos SSD provavelmente serão os mais adequados. Se a baixa latência não for uma grande preocupação, os compartilhamentos de arquivos HDD poderão ser mais adequados de uma perspectiva de custo. Por exemplo, a baixa latência pode ser menos preocupante em compartilhamentos de equipe montados localmente a partir do Azure ou armazenados em cache localmente por meio da Sincronização de Arquivos do Azure.
Depois de criar um compartilhamento de arquivo em uma conta de armazenamento, você não poderá movê-lo diretamente para uma camada de mídia diferente. Por exemplo, para mover um compartilhamento de arquivo HDD para a camada de mídia SSD, você deve criar um novo compartilhamento de arquivo SSD e copiar os dados do compartilhamento original para o novo compartilhamento de arquivo.
Você pode encontrar mais informações sobre as camadas de mídia SSD e HDD em Entenda os modelos de cobrança dos Arquivos do Azure e Entenda e otimize o desempenho do compartilhamento de arquivo do Azure.
Disponibilidade de região da Sincronização de Arquivos do Azure
Para obter informações sobre a disponibilidade regional, confira 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 usar a Sincronização de Arquivos do Azure:
- Sul da França
- Oeste da África do Sul
- EAU Central
Para solicitar acesso a 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 conforme eles são gravados. Dependendo de seus requisitos, você pode selecionar graus de redundância. Atualmente, os Arquivos do Azure dão 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 do Armazenamento do Azure. Essa abordagem ajuda a proteger contra perda de dados devido a falhas de hardware, como uma unidade de disco inválido. 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 LRS poderão ser perdidas ou irrecuperáveis.
ZRS (armazenamento com redundância de zona): com redundância de zona, três cópias de cada arquivo são armazenadas. No entanto, essas cópias são isoladas fisicamente em três clusters de armazenamento distintos em 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 datacenters 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.
GRS (armazenamento com redundância geográfica): com 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 gravações são replicadas de maneira assíncrona para uma região secundária definida pela Microsoft.
A redundância geográfica fornece seis cópias de seus dados distribuídos entre as duas regiões do Azure. Se ocorrer um grande desastre, como a perda permanente de uma região do Azure devido a uma catástrofe natural ou outro evento semelhante, a Microsoft executará um failover. Nesse caso, o secundário se torna o primário e atende a todas as operações.
Como a replicação entre as regiões primária e secundária é assíncrona, em caso de um grande desastre, os dados que ainda não foram 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.
GZRS (armazenamento com redundância de zona geográfica):: com 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 gravações depois são replicadas de maneira 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 funciona para redundância geográfica.
Os compartilhamentos de arquivos HDD dão suporte a todos os quatro tipos de redundância. Os compartilhamentos de arquivos SSD dão suporte apenas a LRS e ZRS.
As contas de armazenamento de pagamento conforme o uso fornecem duas outras opções de redundância que os Arquivos do Azure não dão suporte: armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e armazenamento com redundância 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 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 com redundância geográfica ou com redundância de zona geográfica, respectivamente.
Importante
O armazenamento com redundância geográfica e com redundância de zona geográfica pode fazer failover manualmente do armazenamento para a região secundária. Não recomendamos essa abordagem (exceto em caso de desastre) quando estiver usando a Sincronização de Arquivos do Azure devido à maior probabilidade de perda de dados. Se ocorrer um desastre e você quiser iniciar um failover manual de armazenamento, será necessário abrir um caso de suporte com a Microsoft para que a Sincronização de Arquivos do Azure retome a sincronização com o ponto de extremidade secundário.
Migração
Caso tenha um servidor de arquivos existente no Windows Server 2012 R2 ou mais recente, poderá instalar diretamente a Sincronização de Arquivos do Azure no local. Você não precisa mover dados para um novo servidor.
Caso planeje 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, 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.
Para obter diretrizes detalhadas, consulte Migrar para compartilhamentos de arquivos do Azure SMB.
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 e altos encargos de saída. Os arquivos em camadas têm o conjunto de atributos FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS seguros do Windows. Recomendamos consultar seu fornecedor de software para saber como configurar sua solução para ignorar arquivos de leitura que têm esse atributo definido. Muitos fazem isso automaticamente.
Durante as verificações sob demanda, as soluções antivírus Microsoft 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 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 permanecem no novo servidor e não são organizados em camadas porque não atendem ao requisito de tamanho de camada (mais de 64 KiB).
Observação
Microsoft Defender e System Center Endpoint Protection ignoram apenas a leitura durante varreduras sob demanda. Isso não se aplica à RTP (proteção em tempo real).
Os fornecedores de antivírus podem verificar a compatibilidade entre seus produtos e a Sincronização de Arquivos do Azure usando o Conjunto de testes de compatibilidade de antivírus da Sincronização de Arquivos do Azure no Centro de Download da Microsoft.
Backup
Caso habilite a camada de nuvem, não use soluções que fazem backup diretamente do ponto de extremidade do servidor ou de uma VM que contenha o ponto de extremidade do servidor.
A camada de nuvem faz com que apenas um subconjunto de seus dados seja armazenado no ponto de extremidade do servidor. O conjunto de dados completo reside no compartilhamento de arquivos do Azure. Dependendo da solução de backup que você usa, os arquivos em camadas são:
- Ignorado e sem backup, porque eles têm o conjunto de atributos
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS - Chamado novamente (recall) para disco, o que resulta em altas cobranças 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 de Arquivos do Azure. Ou pergunte ao provedor de backup se ele dá suporte ao backup de compartilhamentos de arquivos do Azure.
Caso prefira usar uma solução de backup local, execute os backups em um servidor no grupo de sincronização que tenha a camada de nuvem desabilitada. Verifique se não há 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 por meio da opção de restauração no nível do arquivo são sincronizados com todos os pontos de extremidade no grupo de sincronização. Os arquivos existentes são substituídos pela versão restaurada do backup. As restaurações no nível do volume não substituem versões de arquivo mais recentes no compartilhamento de arquivos do Azure ou em outros pontos de extremidade do servidor.
Observação
Restauração bare-metal, restauração de VM, restauração do sistema (restauração interna do sistema operacional do Windows) e restauração em nível de arquivo com sua versão em camadas podem causar resultados inesperados. (A restauração no nível do arquivo ocorre quando o software de backup faz backup de um arquivo em camadas em vez de um arquivo completo.) No momento, não há suporte para eles quando a camada de nuvem está habilitada.
Os Instantâneos do VSS (Serviço de Cópias de Sombra de Volume), incluindo a guia Versões Anteriores, são compatíveis com volumes que têm a camada de nuvem habilitada. No entanto, você deve habilitar a compatibilidade de versão anterior por meio do PowerShell. Saiba como.
Classificação de dados
Caso tenha um software de classificação de dados instalado, a habilitação da camada de nuvem aumentará os custo por dois motivos:
- Com a camada de nuvem habilitada, seus arquivos mais quentes são armazenados em cache localmente. Seus arquivos mais legais são 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.
- Se o software de classificação de dados usar os metadados no fluxo de dados de um arquivo, o arquivo deverá ser totalmente chamado novamente (recall) para que o software detecte 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 novas funcionalidades 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: 18.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: 18.2.0.0.
Atualize caminhos
Há quatro maneiras aprovadas e testadas para instalar as atualizações do agente de Sincronização de Arquivos do Azure:
- Use o recurso de atualização automática da Sincronização de Arquivos do Azure para instalar atualizações do agente: o agente de Sincronização de Arquivos do Azure é atualizado automaticamente. É possível 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 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 da Sincronização de Arquivos do Azure para garantir que você tenha acesso às correções mais recentes do agente do servidor. O Microsoft Update simplifica esse processo, baixando e instalando atualizações automaticamente para você.
-
Use AfsUpdater.exe para baixar e instalar atualizações do agente: o arquivo
AfsUpdater.exeestá localizado no diretório de instalação do agente. Clique duas vezes no arquivo executável para baixar e instalar atualizações de agente. Dependendo da versão, talvez seja necessário reiniciar o servidor. - Corrija um agente de sincronização de arquivos do Azure existente usando um arquivo de patch do Microsoft Update ou um arquivo executável .msp: você pode baixar o pacote de atualização mais recente da Sincronização de Arquivos do Azure no Catálogo do Microsoft Update. A execução de um arquivo executável .msp atualiza a instalação da Sincronização de Arquivos do Azure com o mesmo método que o Microsoft Update usa automaticamente. A aplicação de um patch do Microsoft Update realiza uma atualização in-loco de uma instalação da Sincronização de Arquivos do Azure.
- Baixe o instalador mais recente do agente de Sincronização de Arquivos do Azure: você pode obter o instalador no Centro de Download da Microsoft. Para atualizar 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. As configurações do agente (por exemplo, registro do servidor e pontos de extremidade do servidor) são mantidas quando o agente de Sincronização de Arquivos do Azure é desinstalado.
Observação
Não há suporte para o downgrade do agente da Sincronização de Arquivos do Azure. As novas versões geralmente incluem alterações interruptivas quando comparadas às versões antigas, tornando o processo de downgrade não suportado. Caso encontre problemas com a versão atual do agente, entre em contato com o suporte ou atualize para a versão mais recente disponível.
Gerenciamento automático do ciclo de vida do agente
O agente de Sincronização de Arquivos do Azure é atualizado automaticamente. É possível 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 ajudar você no 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.
A configuração padrão tenta impedir que o agente expire. Dentro de 21 dias da data de validade publicada de um agente, o agente tentará se atualizar. 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. Essa opção não elimina a necessidade de obter patches regulares do Microsoft Update.
É possível selecionar se o agente se atualiza automaticamente assim que uma nova versão do agente estiver disponível. Atualmente, essa capacidade não é aplicável a servidores clusterizados.
Essa atualização ocorre durante a janela de manutenção selecionada e permite que seu servidor se beneficie de novos recursos e melhorias assim que estiverem disponíveis. Esta configuração recomendada e sem preocupações fornece as versões principais do agente e 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. Após a conclusão da liberação de versões de pré-lançamento, 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, caso precise fazer alterações.
Abra um console do PowerShell e acesse o diretório onde você instalou o agente de sincronização e importe os cmdlets do servidor. Por padrão, essa ação é semelhante ao 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 da política atual para a faixa de atualização imediata, você pode usar:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>
Observação
Se a liberação de versões de pré-lançamento já estiver concluída para a versão mais recente do agente e a política de atualização automática do agente for alterada para InstallLatest, o agente não será atualizado automaticamente até que a próxima versão do agente seja liberada. Para atualizar para uma versão do agente que terminou a liberação de versões de pré-lançamento, use o Microsoft Update ou AfsUpdater.exe. Para verificar se uma versão do agente está em liberação de versões de pré-lançamento no momento, verifique a seção de versões suportadas nas notas de versão.
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 melhorias. Uma versão específica do agente de Sincronização de Arquivos do Azure pode ter suporte apenas 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 de agente em seu processo de gerenciamento de mudança:
- As versões principais do agente terão suporte 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 agente expirado em breve, 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 sobre servidores registrados em 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 18.0.0.0 do agente estiver definida para expirar, as versões 18.*.*.* expiraram juntas.
Observação
A instalação de uma versão do agente expirada exibe um aviso, mas é bem-sucedida. Não há suporte para a tentativa de instalar ou conectar uma versão do agente expirada e ela é bloqueada.