Planear uma implementação do Azure File Sync

  • Artigo

Entrevista e demonstração apresentando o Azure File Sync - clique para jogar!

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 VM na nuvem.

Este artigo apresenta os conceitos e recursos do Azure File Sync. Quando estiver familiarizado com a Sincronização de Ficheiros do Azure, considere seguir o guia de implementação da Sincronização de Ficheiros do Azure para experimentar este 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: montando diretamente esses compartilhamentos de arquivos do Azure (SMB) sem servidor ou armazenando em cache os compartilhamentos de arquivos do Azure no local usando a Sincronização de Arquivos do Azure. A opção de implantação escolhida altera os aspetos 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 no local ou na nuvem usando o cliente SMB padrão disponível no Windows, macOS e Linux. Como os compartilhamentos de arquivos do Azure não têm servidor, a implantação para cenários de produção não requer o gerenciamento de um servidor de arquivos ou dispositivo NAS. Isso significa que você não precisa aplicar patches de software ou trocar discos físicos.

  • Armazenar em cache o compartilhamento de arquivos 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 nos Arquivos do Azure, mantendo a flexibilidade, o desempenho e a compatibilidade de um servidor de arquivos local. O Azure File Sync transforma um Windows Server local (ou na nuvem) em um cache rápido do seu compartilhamento de arquivos do Azure.

Conceitos de gestão

Uma implantação do Azure File Sync tem três objetos de gerenciamento fundamentais:

  • Partilha de ficheiros do Azure: uma partilha de ficheiros do Azure é uma partilha de ficheiros na nuvem sem servidor, que fornece o ponto de extremidade na nuvem de uma relação de sincronização do Azure File Sync. Os arquivos em um compartilhamento de arquivos do Azure podem ser acessados diretamente com o SMB ou o protocolo FileREST, embora incentivemos que você acesse principalmente os arquivos por meio do cache do Windows Server quando o compartilhamento de arquivos do Azure estiver sendo usado com o Azure File Sync. Isso ocorre porque os Arquivos do Azure hoje não têm um mecanismo de deteção de alterações eficiente como o Windows Server, portanto, as alterações no compartilhamento de arquivos do Azure diretamente levarão tempo para se propagar de volta aos pontos de extremidade do servidor.
  • Ponto de extremidade do servidor: o caminho no Windows Server que está sendo sincronizado com um compartilhamento de arquivos do Azure. 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 seus namespaces não se sobrepõem.
  • Grupo de sincronização: o objeto que define a relação de sincronização entre um ponto de extremidade de nuvem ou compartilhamento de arquivos do Azure e um ponto de extremidade de servidor. Os pontos finais num grupo de sincronização são mantidos em sincronia entre si. Se, por exemplo, você tiver dois conjuntos distintos de arquivos que deseja gerenciar com a Sincronização de Arquivos do Azure, criará dois grupos de sincronização e adicionará pontos de extremidade diferentes a cada grupo de sincronização.

Conceitos de gerenciamento de compartilhamento de arquivos do Azure

Os compartilhamentos de arquivos do Azure são implantados em contas de armazenamento, que são objetos de nível superior que representam um pool compartilhado de armazenamento. Esse pool de armazenamento pode ser usado para implantar vários compartilhamentos de arquivos, 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 que se aplicam a essa conta de armazenamento. Para obter os limites atuais da conta de armazenamento, consulte Metas de desempenho e escalabilidade dos Arquivos do Azure.

Há dois tipos principais de contas de armazenamento que você usará para implantações do Azure Files:

  • Contas de armazenamento de uso geral versão 2 (GPv2): as contas de armazenamento GPv2 permitem implantar compartilhamentos de arquivos do Azure em hardware padrão/baseado em disco rígido (baseado em HDD). Além de armazenar compartilhamentos de arquivos 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 implantar compartilhamentos de arquivos do Azure em hardware premium/baseado em disco de estado sólido (baseado em SSD). As contas FileStorage só podem ser usadas para armazenar compartilhamentos de arquivos do Azure; nenhum outro recurso de armazenamento (contêineres blob, filas, tabelas, etc.) pode ser implantado em uma conta FileStorage. Somente contas FileStorage podem implantar compartilhamentos de arquivos SMB e NFS.

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

Conceitos de gerenciamento do Azure File Sync

Os grupos de sincronização são implantados nos Serviços de Sincronização de Armazenamento, que são objetos de nível superior que registram servidores para uso com o Azure File Sync e contêm as relações de grupo de sincronização. O recurso do Serviço de Sincronização de Armazenamento é um par do recurso da conta de armazenamento e também pode 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 arquivos do Azure em várias contas de armazenamento e vários Servidores Windows registrados.

Antes de criar um grupo de sincronização em um Serviço de Sincronização de Armazenamento, você deve primeiro registrar um Windows Server no Serviço de Sincronização de Armazenamento. Isso cria um objeto de 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 de Sincronização de Arquivos do Azure no servidor. Um servidor ou cluster individual pode ser registrado com apenas um Serviço de Sincronização de Armazenamento de cada vez.

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

Importante

Você pode fazer alterações no namespace de qualquer ponto de extremidade de nuvem ou ponto de extremidade de servidor no grupo de sincronização e ter seus arquivos sincronizados com os outros pontos de extremidade no grupo de sincronização. Se você fizer uma alteração no ponto de extremidade da nuvem (compartilhamento de arquivos do Azure) diretamente, as alterações primeiro precisarão ser descobertas por um trabalho de deteção de alterações da Sincronização de Arquivos do Azure. Um trabalho de deteção de alterações é iniciado para um ponto de extremidade na nuvem apenas uma vez a cada 24 horas. Para obter mais informações, consulte Perguntas frequentes sobre Arquivos do Azure.

Considere a contagem de Serviços de Sincronização de Armazenamento necessária

Uma seção anterior discute o recurso principal a ser configurado para a Sincronização de Arquivos do Azure: um Serviço de Sincronização de Armazenamento. Um Windows Server só pode ser registrado em um Serviço de Sincronização de Armazenamento. Por isso, muitas vezes é 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 tiver:

  • conjuntos distintos de servidores que nunca devem trocar dados entre si. Nesse caso, você deseja projetar o sistema para excluir determinados conjuntos de servidores para sincronizar com um compartilhamento de arquivos do Azure que já está em uso como um ponto de extremidade de nuvem em um grupo de sincronização em um Serviço de Sincronização de Armazenamento diferente. Outra maneira de examinar isso é que os servidores Windows registrados em um serviço de sincronização de armazenamento diferente não podem sincronizar 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 suportar. Analise os destinos de escala do Azure File Sync para obter mais detalhes.

Planejar topologias de sincronização equilibradas

Antes de implantar quaisquer recursos, é importante planejar o que você sincronizará em um servidor local, com o qual o 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 que seus dados não residam atualmente em um Windows Server ou no servidor que você deseja usar a 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 arquivos do Azure são necessários. Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Você pode ter mais pastas em seus volumes que você atualmente compartilha localmente como compartilhamentos SMB para seus usuários e aplicativos. A maneira mais fácil de imaginar esse cenário é imaginar um compartilhamento local que mapeia 1:1 para um compartilhamento de arquivos do Azure. Se você tiver um número pequeno o suficiente de compartilhamentos, abaixo de 30 para uma única instância do Windows Server, recomendamos um mapeamento 1:1.

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

Agrupamento de compartilhamentos

Por exemplo, se o seu departamento de recursos humanos (RH) tiver 15 compartilhamentos, você pode considerar armazenar todos os dados de RH em um único compartilhamento de arquivos do Azure. O armazenamento de vários compartilhamentos locais em um compartilhamento de arquivos do Azure não impede que você crie os 15 compartilhamentos SMB usuais em sua instância local do Windows Server. Isso significa apenas que você organiza as pastas raiz desses 15 compartilhamentos como subpastas em uma pasta comum. Em seguida, sincronize essa pasta comum com um compartilhamento de arquivos do Azure. Dessa forma, apenas um único compartilhamento de arquivos do Azure na nuvem é necessário para esse grupo de compartilhamentos locais.

Sincronização de volume

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

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

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

Gorjeta

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

Uma abordagem estruturada para um mapa de implantação

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

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

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

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

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

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

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

Gorjeta

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

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

Importante

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

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

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

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

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

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

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

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

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

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

Criar uma tabela de mapeamento

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

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

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


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

Considerações sobre o servidor de arquivos do Windows

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

Requisitos do sistema operativo

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

Versão SKUs Suportados Opções de implantação suportadas
Windows Server 2022 Azure, Datacenter, Standard e IoT Completo e Núcleo
Windows Server 2019 Datacenter, padrão e IoT Completo e Núcleo
Windows Server 2016 Datacenter, Standard e Servidor de Armazenamento Completo e Núcleo
Windows Server 2012 R2* Datacenter, Standard e Servidor de Armazenamento Completo e Núcleo

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

As versões futuras do Windows Server serão adicionadas à medida que forem lançadas.

Importante

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

Recursos mínimos do sistema

A Sincronização de Ficheiros do Azure requer um servidor, físico ou virtual, com pelo menos uma CPU, um mínimo de 2 GiB de memória e um volume ligado localmente formatado com o sistema de ficheiros NTFS.

Importante

Se o servidor estiver sendo executado em uma máquina virtual com memória dinâmica habilitada, a VM deverá ser configurada com um mínimo de 2048 MiB de memória.

Para a maioria das cargas de trabalho de produção, não recomendamos configurar um servidor de sincronização do Azure File Sync apenas com os requisitos mínimos. Consulte Recursos do sistema recomendados para obter mais informações.

Tal como qualquer aplicação ou funcionalidade de servidor, os requisitos de recursos do sistema do Azure File Sync são determinados pelo dimensionamento da implementação. As implementações maiores num servidor necessitam de mais recursos de sistema. Para o Azure File Sync, o dimensionamento é determinado pelo número de objetos nos pontos finais do servidor e pela taxa de abandono no conjunto de dados. Um único servidor pode ter pontos finais em vários grupos de sincronização e o número de objetos listados nas seguintes contas de tabela para o espaço de nomes completo ao qual um servidor está anexado.

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

Os dados do espaço de nomes são armazenados na memória por motivos de desempenho. Assim, os espaços de nomes maiores requerem mais memória para manter um bom desempenho e uma taxa de abandono superior requer mais CPU para processamento.

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

Tamanho do espaço de nomes - ficheiros 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 (taxa de abandono típica)
5 2.3 2 16 (sincronização inicial)/4 (taxa de abandono típica)
10 4.7 4 32 (sincronização inicial)/8 (taxa de abandono típica)
30 14,0 8 48 (sincronização inicial)/16 (taxa de abandono típica)
50 23,3 16 64 (sincronização inicial)/32 (taxa de abandono típica)
100* 46,6 32 128 (sincronização inicial)/32 (taxa de abandono típica)

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

Gorjeta

A sincronização inicial de um namespace é uma operação intensiva e recomendamos alocar mais memória até que a sincronização inicial seja concluída. Isso não é necessário, mas pode acelerar a sincronização inicial.

A taxa de abandono típica é de 0,5% do espaço de nomes alterado por dia. Para níveis de taxa de abandono mais elevados, considere adicionar mais CPU.

Cmdlet de avaliação

Antes de implantar o Azure File Sync, você deve avaliar se ele é compatível com seu sistema usando o cmdlet de avaliação do Azure File Sync. Este cmdlet verifica possíveis problemas com o sistema de arquivos e o conjunto de dados, como caracteres sem suporte ou uma versão do sistema operacional sem suporte. Estas verificações abrangem a maioria, mas não todas, as características mencionadas abaixo; Recomendamos que você leia o restante desta seção cuidadosamente para garantir que sua implantação ocorra sem problemas.

O cmdlet de avaliação pode ser instalado instalando o módulo Az PowerShell, que pode ser instalado seguindo as instruções aqui: Instalar e configurar o Azure PowerShell.

Utilização

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

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Para testar apenas o conjunto de dados:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Para testar apenas os requisitos do sistema:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Para exibir os resultados em 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

O Azure File Sync só tem suporte em volumes NTFS conectados diretamente. O armazenamento com conexão direta, ou DAS, no Windows Server significa que o sistema operacional Windows Server é o proprietário do sistema de arquivos. O DAS pode ser fornecido através da conexão física de discos ao servidor de arquivos, anexando discos virtuais a uma VM de servidor de arquivos (como uma VM hospedada pelo Hyper-V) ou até mesmo por meio de iSCSI.

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

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

Caraterística Estado do suporte Notas
Listas de controlo de acesso (ACL) Totalmente suportado As listas de controle de acesso discricionário no estilo do Windows são preservadas pela Sincronização de Arquivos do Azure e impostas pelo Windows Server nos pontos de extremidade do servidor. As ACLs também podem ser impostas ao montar diretamente o compartilhamento de arquivos do Azure, no entanto, isso requer configuração adicional. Consulte a seção Identidade para obter mais informações.
Ligações fixas Omitida
Ligações simbólicas Omitida
Pontos de montagem Parcialmente suportado Os pontos de montagem podem ser a raiz de um ponto de extremidade do servidor, mas são ignorados se estiverem contidos no namespace de um ponto de extremidade do servidor.
Entroncamentos Omitida Por exemplo, as pastas DfrsrPrivate e DFSRoots do Sistema de Arquivos Distribuído.
Pontos de reanálise Omitida
Compressão NTFS Parcialmente suportado O Azure File Sync não oferece 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 Totalmente suportado Arquivos esparsos sincronizam (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.
Fluxos de dados alternativos (ADS) Preservado, mas não sincronizado Por exemplo, as tags de classificação criadas pela Infraestrutura de Classificação de Arquivos não são sincronizadas. As marcas de classificação existentes em arquivos em cada um dos pontos de extremidade do servidor são deixadas intocadas.

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

Ficheiro/pasta Nota
pagefile.sys Arquivo específico do sistema
Desktop.ini Arquivo específico do sistema
thumbs.db ficheiro temporário para miniaturas
ehthumbs.db Arquivo temporário para miniaturas de mídia
~$*.* ficheiro temporário do Office
*.tmp ficheiro temporário
*.laccdb ficheiro de bloqueio de bases de dados do Access
635D02A9D91C401B97884B82B3BCDAEA.* ficheiro de sincronização interno
\Informações de volume do sistema Pasta específica para o volume
$RECYCLE. COMPARTIMENTO Pasta
\SyncShareState pasta para sincronização
. SystemShareInformation Pasta para sincronização no compartilhamento de arquivos do Azure

Nota

Embora o Azure File Sync ofereça 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 o Azure File Sync) porque os arquivos de log e os bancos de dados precisam ser sincronizados juntos e podem ficar fora de sincronia por vários motivos que podem levar à corrupção do banco de dados.

Considere quanto espaço livre você precisa em seu disco local

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

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

  • Com a hierarquização na nuvem ativada:

    • Pontos de análise para arquivos hierárquicos
    • Banco de dados de metadados do Azure File Sync
    • Heatstore do Azure File Sync
    • Arquivos totalmente baixados em seu hot cache (se houver)
    • Requisitos da política de espaço livre de volume

  • Com a hierarquização na nuvem desativada:

    • Arquivos totalmente baixados
    • Heatstore do Azure File Sync
    • Banco de dados de metadados do Azure File Sync

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

  1. O NTFS aloca um tamanho de cluster para cada um dos arquivos hierárquicos. 1 milhão de arquivos * Tamanho do cluster de 4 KiB = 4.000.000 KiB (4 GiB)

    Nota

    Para se beneficiar totalmente da hierarquização na nuvem, recomenda-se o uso de tamanhos de cluster NTFS menores (menos de 64 KiB), uma vez que cada arquivo hierárquico ocupa um cluster. Além disso, o espaço ocupado por arquivos hierárquicos é 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 heatstore do Azure File Sync ocupa 1,1 KiB por arquivo. 1 milhão de ficheiros * 1,1 KiB = 1.100.000 KiB (1,1 GiB)
  4. A política de espaço livre de volume é de 20%. 1000 GiB * 0,2 = 200 GiB

Nesse caso, o Azure File Sync precisaria de cerca de 209.500.000 KiB (209,5 GiB) de espaço para esse namespace. Adicione essa quantidade a qualquer espaço livre adicional desejado para descobrir quanto espaço livre é necessário para este disco.

Clustering de Ativação Pós-falha

  1. O Clustering de Failover do Windows Server é suportado pela Sincronização de Arquivos do Azure para a opção de implantação "Servidor de Arquivos para uso geral". Para obter mais informações sobre como configurar a função "Servidor de arquivos para uso geral" em um cluster de failover, consulte Implantando um servidor de arquivos clusterizado de dois nós.
  2. O único cenário suportado pela Sincronização de Ficheiros do Azure é o Cluster de Ativação Pós-falha do Windows Server com Discos Clusterizados
  3. O Clustering de Failover não é suportado em "Servidor de Arquivos de Expansão para Dados de Aplicativos" (SOFS) ou em Volumes Compartilhados Clusterizados (CSVs) ou discos locais.

Nota

O agente do Azure File Sync deve ser instalado em cada nó de um Cluster de Failover para que a sincronização funcione corretamente.

Eliminação de Dados Duplicados

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

Quando a Desduplicação de Dados é habilitada em um volume com a hierarquização na nuvem habilitada, os arquivos otimizados para Dedup no local do ponto de extremidade do servidor serão hierarquizados de forma semelhante a um arquivo normal com base nas configurações da política de hierarquização na nuvem. Depois que os arquivos otimizados do Dedup tiverem sido hierarquizados, o trabalho de coleta de lixo da Desduplicaçã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 serão defraudados.

Nota

Para dar suporte à Eliminação de Duplicação de Dados em volumes com a hierarquização na nuvem habilitada no Windows Server 2019, o Windows Update KB4520062 - outubro de 2019 ou uma atualização de rollup mensal posterior deve ser instalada.

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

Notas

  • Se a Desduplicação de Dados for instalada antes da instalação do agente do Azure File Sync, será necessária uma reinicialização para dar suporte à Desduplicação de Dados e à hierarquização na nuvem no mesmo volume.

  • Se a Desduplicação de Dados estiver habilitada em um volume após a habilitação da hierarquização na nuvem, o trabalho inicial de otimização da Desduplicação otimizará os arquivos no volume que ainda não estão hierárquicos e terá o seguinte impacto na hierarquização da nuvem:

    • A política de espaço livre continuará a hierarquizar os arquivos de acordo com o espaço livre no volume usando o mapa de calor.
    • A política de data ignorará a hierarquização de arquivos que, de outra forma, poderiam ter sido qualificados para hierarquização devido ao trabalho de otimização de desduplicação acessando os arquivos.

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

    • Exemplo: Se a configuração MinimumFileAgeDays for de sete dias e a política de data de hierarquização na nuvem for de 30 dias, a política de data hierarquizará os arquivos após 37 dias.
    • Observação: depois que um arquivo for hierarquizado pela Sincronização de Arquivos do Azure, o trabalho de otimização de Desduplicação ignorará o arquivo.

  • Se um servidor que executa o Windows Server 2012 R2 com o agente de Sincronização de Arquivos do Azure instalado for atualizado para o Windows Server 2016, Windows Server 2019 ou Windows Server 2022, as etapas a seguir deverão ser executadas para dar suporte à Desduplicação de Dados e à hierarquização na nuvem no mesmo volume:

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

    Observação: as definições de configuração do Azure File Sync no servidor são mantidas quando o agente é desinstalado e reinstalado.

Sistema de ficheiros distribuídos (DFS)

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

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

Replicação DFS (DFS-R): Como o DFS-R e a Sincronização de Arquivos do Azure são soluções de replicação, na maioria dos casos, recomendamos substituir o DFS-R pela Sincronização de Arquivos do Azure. No entanto, há vários cenários em que você gostaria de usar o DFS-R e a Sincronização de Arquivos do Azure juntos:

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

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

  1. A hierarquização na nuvem do Azure File Sync deve ser desabilitada em volumes com pastas replicadas do DFS-R.
  2. Os pontos de extremidade do servidor não devem ser configurados em pastas de replicação somente leitura do DFS-R.
  3. Apenas um único ponto de extremidade de servidor pode sobrepor-se a uma localização DFS-R. Vários pontos de extremidade de servidor sobrepostos a outros locais DFS-R ativos podem levar a conflitos.

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

Sysprep

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

Se a hierarquização na nuvem estiver habilitada em um ponto de extremidade do servidor, os arquivos hierárquicos serão ignorados e não serão indexados pelo Windows Search. Os arquivos não hierárquicos são indexados corretamente.

Nota

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

Outras soluções de HSM (Hierarchical Storage Management, gerenciamento de armazenamento hierárquico)

Nenhuma outra solução HSM deve ser usada com o Azure File Sync.

Desempenho e Escalabilidade   

Uma vez que o agente do Azure File Sync é executado numa máquina Windows Server que se liga às partilhas de ficheiros do Azure, o desempenho real da sincronização depende de vários fatores na sua infraestrutura: Windows Server e a configuração de disco subjacente, a largura de banda de rede entre o servidor e o armazenamento do Azure, o tamanho do ficheiro, o tamanho total do conjunto de dados e a atividade no conjunto de dados. Como o Azure File Sync funciona no nível de arquivo, as características de desempenho de uma solução baseada no Azure File Sync são melhor medidas no número de objetos (arquivos e diretórios) processados por segundo.

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

Para detetar alterações à partilha de ficheiros do Azure, o Azure File Sync tem um trabalho agendado denominado trabalho de deteção de alterações. Um trabalho de deteção de alterações enumera todos os ficheiros na partilha de ficheiros e, em seguida, compara-os com a versão de sincronização desses ficheiros. Quando o trabalho de deteção de alterações determina que ficheiros foram alterados, o Azure File Sync inicia uma sessão de sincronização. O trabalho de deteção de alterações é iniciado a cada 24 horas. Uma vez que o trabalho de deteção de alterações funciona ao enumerar todos os ficheiros na partilha de ficheiros do Azure, a deteção de alterações demora mais tempo em espaços de nomes maiores do que em espaços de nomes mais pequenos. Para espaços de nomes grandes, pode demorar mais do que uma vez a cada 24 horas para determinar que ficheiros que foram alterados.

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

Identidade

O Azure File Sync funciona com sua identidade padrão baseada em AD sem nenhuma configuração especial além da configuração da sincronização. Quando você estiver usando o Azure File Sync, a expectativa geral é que a maioria dos acessos passe pelos servidores de cache do Azure File Sync, em vez de pelo compartilhamento de arquivos do Azure. Como os pontos de extremidade do servidor estão localizados no Windows Server e o Windows Server oferece suporte a ACLs no estilo AD e Windows há muito tempo, nada é necessário além de garantir que os servidores de arquivos do Windows registrados no Serviço de Sincronização de Armazenamento ingressem no domínio. A Sincronização de Arquivos do Azure armazenará ACLs nos arquivos no compartilhamento de arquivos do Azure e as 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 sincronizar com os pontos de extremidade do servidor no grupo de sincronização, você também pode querer garantir que você possa impor suas permissões do AD em seu compartilhamento de arquivos diretamente na nuvem. Para fazer isso, você deve associar sua conta de armazenamento ao seu AD local, assim como seus servidores de arquivos do Windows são associados ao domínio. Para saber mais sobre como associar sua conta de armazenamento a um Ative Directory de propriedade do cliente, consulte Visão geral do Ative Directory dos Arquivos do Azure.

Importante

A associação de domínio à sua conta de armazenamento ao Ative Directory não é necessária para implantar com êxito a Sincronização de Arquivos do Azure. Esta é uma etapa estritamente opcional que permite que o compartilhamento de arquivos do Azure imponha ACLs locais quando os usuários montam o compartilhamento de arquivos do Azure diretamente.

Rede

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

Importante

O Azure File Sync não suporta o encaminhamento da Internet. A opção de encaminhamento de rede predefinida, o encaminhamento da Microsoft, é suportada pelo Azure File Sync.

Com base na política da sua organização ou nos requisitos regulatórios exclusivos, você pode precisar de uma comunicação mais restritiva com o Azure e, portanto, o Azure File Sync fornece vários mecanismos para você configurar a rede. Com base em suas necessidades, você pode:

  • Sincronização de túneis e tráfego de upload/download de arquivos em sua Rota Expressa ou VPN do Azure.
  • Utilize os Ficheiros do Azure e as funcionalidades de Rede do Azure, tais como pontos de extremidade de serviço e pontos de extremidade privados.
  • Configure o Azure File Sync para dar suporte ao seu proxy em seu ambiente.
  • Acelere a atividade de rede a partir da Sincronização de Ficheiros do Azure.

Gorjeta

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

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

Encriptação

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 do Azure File Sync e o Azure e criptografia em repouso de seus dados no compartilhamento de arquivos do Azure.

Criptografia do Windows Server em repouso

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

Para fornecer criptografia sob o sistema de arquivos, o Windows Server fornece a caixa de entrada do BitLocker. O BitLocker é totalmente transparente para a Sincronização de Arquivos do Azure. A principal razão para usar um mecanismo de criptografia como o BitLocker é impedir a exfiltração física de dados do seu datacenter local por alguém 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, consulte Visão geral do BitLocker.

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

O outro método principal para criptografar dados é criptografar o fluxo de dados do arquivo quando o aplicativo salva o arquivo. Alguns aplicativos podem fazer 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 Proteção de Informações do Azure (AIP)/Azure Rights Management Services (Azure RMS)/Ative Directory RMS. A principal razão para usar um mecanismo de criptografia como AIP/RMS é impedir a exfiltração de dados do seu compartilhamento de arquivos por pessoas copiando-os para locais alternativos, como uma unidade flash ou enviando-os por e-mail para uma pessoa não autorizada. Quando o fluxo de dados de um ficheiro é encriptado como parte do formato de ficheiro, este ficheiro continuará a ser encriptado na partilha de ficheiros do Azure.

O Azure File Sync 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.

Encriptação em trânsito

Nota

O serviço Azure File Sync removeu o suporte para TLS1.0 e 1.1 em 1º de agosto de 2020. Todas as versões suportadas do agente do Azure File Sync já usam TLS1.2 por padrão. O uso de uma versão anterior do TLS pode ocorrer se o TLS1.2 estiver desabilitado no servidor ou se um proxy for usado. Se você estiver usando um proxy, recomendamos que verifique a configuração do proxy. As regiões do serviço Azure File Sync adicionadas após 01/05/2020 suportam apenas TLS1.2. Para obter mais informações, consulte o guia de solução de problemas.

O agente do Azure File Sync se comunica com seu Serviço de Sincronização de Armazenamento e compartilhamento de arquivos do Azure usando o protocolo REST do Azure File Sync e o protocolo FileREST, que sempre usam HTTPS pela porta 443. O Azure File Sync não envia solicitações não criptografadas por HTTP.

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

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

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

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

Criptografia de compartilhamento de arquivos do Azure em repouso

Todos os dados armazenados nos Arquivos do Azure são criptografados em repouso usando a criptografia do serviço de armazenamento do Azure (SSE). A criptografia do serviço de armazenamento funciona de forma semelhante ao BitLocker no Windows: os dados são criptografados abaixo do nível do sistema de arquivos. Como os dados são criptografados sob o sistema de arquivos do compartilhamento de arquivos do Azure, como são codificados em disco, você não precisa ter acesso à chave subjacente no cliente para ler ou gravar no compartilhamento de arquivos do Azure. A criptografia em repouso aplica-se aos protocolos SMB e NFS.

Por padrão, os dados armazenados nos Arquivos do Azure são criptografados com chaves gerenciadas pela Microsoft. Com chaves gerenciadas pela Microsoft, a Microsoft detém as chaves para criptografar/descriptografar os dados e é responsável por girá-las regularmente. Também pode optar por gerir as suas próprias chaves, o que lhe dá controlo sobre o processo de rotação. Se você optar por criptografar seus compartilhamentos de arquivos com chaves gerenciadas pelo cliente, os Arquivos do Azure estarão autorizados a acessar suas chaves para atender às solicitações de leitura e gravação de seus clientes. Com chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento, mas isso significa que seu compartilhamento de arquivos do Azure não estará 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 Blob do Azure. Para saber mais sobre a criptografia do serviço de armazenamento do Azure (SSE), consulte Criptografia de armazenamento do Azure para dados em repouso.

Camadas de armazenamento

O Azure Files oferece duas camadas diferentes de armazenamento de mídia, SSD e HDD, que permitem que você adapte seus compartilhamentos aos requisitos de desempenho e preço do seu cenário:

  • SSD (Premium): As partilhas de ficheiros Premium são utilizadas por unidades de estado sólido (SSD) e proporcionam um elevado desempenho consistente e baixa latência, em milissegundos de um dígito para a maioria das operações de E/S, para cargas de trabalho com utilização intensiva de E/S. Os compartilhamentos de arquivos premium são adequados para uma ampla variedade de cargas de trabalho, como bancos de dados, hospedagem de sites e ambientes de desenvolvimento. Os compartilhamentos de arquivos Premium podem ser usados com os protocolos SMB (Server Message Block) e NFS (Network File System). Os compartilhamentos de arquivos Premium são implantados no tipo de conta de armazenamento FileStorage e só estão disponíveis em um modelo de cobrança provisionado. Para obter mais informações sobre o modelo de faturamento provisionado para compartilhamentos de arquivos premium, consulte Noções básicas sobre provisionamento para compartilhamentos de arquivos premium. Os compartilhamentos de arquivos Premium oferecem um SLA de disponibilidade mais alto do que os compartilhamentos de arquivos padrão (consulte "Nível Premium do Azure Files").

  • HDD (padrão): As partilhas de ficheiros padrão utilizam unidades de disco rígido (HDD) e fornecem uma opção de armazenamento económica para partilhas de ficheiros de uso geral. Os compartilhamentos de arquivos padrão são implantados no tipo de conta de armazenamento GPv2 (versão 2) de uso geral. Para obter informações sobre o SLA, consulte a página de contratos de nível de serviço do Azure (consulte "Contas de armazenamento"). Os compartilhamentos de arquivos padrão usam um modelo de pagamento conforme o uso que fornece preços baseados no uso. A camada de acesso de um compartilhamento de arquivos permite ajustar os custos de armazenamento em relação ao custo de IOPS para otimizar sua fatura total:

    • Os compartilhamentos de arquivos otimizados para transações oferecem o preço de transação de menor custo para cargas de trabalho pesadas de transações que não precisam da baixa latência oferecida pelos compartilhamentos de arquivos premium. Recomendado durante a migração de dados para Arquivos do Azure.
    • Os compartilhamentos de arquivos ativos oferecem preços equilibrados de armazenamento e transação para cargas de trabalho que têm uma boa medida de ambos.
    • Os compartilhamentos de arquivos interessantes oferecem os preços de armazenamento mais econômicos para cargas de trabalho com uso intensivo de armazenamento.

Ao selecionar uma camada de mídia para sua carga de trabalho, considere seus requisitos de desempenho e uso. Se sua carga de trabalho exigir latência de um dígito ou se você estiver usando mídia de armazenamento SSD local, a camada premium é provavelmente a melhor opção. Se a baixa latência não for tão preocupante, por exemplo, com compartilhamentos de equipe montados no local a partir do Azure ou armazenados em cache no local usando o Azure File Sync, o armazenamento padrão pode ser mais adequado do ponto de vista do custo.

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

Consulte Noções básicas sobre cobrança de arquivos do Azure para obter mais informações.

Disponibilidade regional

Atualmente, os compartilhamentos de arquivos padrão com compartilhamentos de arquivos grandes habilitados (capacidade de até 100 TiB) têm certas limitações.

  • Somente contas de armazenamento com redundância local (LRS) e de armazenamento com redundância de zona (ZRS) são suportadas.
  • Depois de habilitar compartilhamentos de arquivos grandes em uma conta de armazenamento, você não poderá converter a conta de armazenamento para usar armazenamento com redundância geográfica (GRS) ou armazenamento com redundância de zona geográfica (GZRS).
  • Depois de ativar compartilhamentos de arquivos grandes, você não pode desativá-lo.

Se você quiser usar GRS ou GZRS com compartilhamentos de arquivos SMB padrão do Azure, consulte Redundância geográfica do Azure Files para visualização de compartilhamentos de arquivos grandes.

Disponibilidade da região de sincronização de arquivos do Azure

Para saber a disponibilidade regional, consulte Produtos disponíveis por região.

As seguintes regiões exigem que você solicite acesso ao Armazenamento do Azure antes de poder usar o Azure File Sync com elas:

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

Para solicitar acesso para 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, os Arquivos do Azure armazenam várias cópias de cada arquivo à medida que são gravados. Dependendo de suas necessidades, você pode selecionar diferentes graus de redundância. Atualmente, os Arquivos do Azure dão suporte às seguintes opções de redundância de dados:

  • Armazenamento com redundância local (LRS): com o LRS, cada arquivo é armazenado três vezes em um cluster de armazenamento do Azure. Isso protege contra a 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 data center, todas as réplicas de uma conta de armazenamento usando o LRS poderão ser perdidas ou irrecuperáveis.
  • Armazenamento com redundância de zona (ZRS): com o 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 dentro de uma região do Azure. Cada zona é composta por um ou mais centros de dados equipados com alimentação, arrefecimento e rede independentes. Uma gravação no armazenamento não é aceita até que seja gravada nos clusters de armazenamento nas 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 forma assíncrona para uma região secundária definida pela Microsoft. O GRS fornece seis cópias de seus dados distribuídos entre duas regiões do Azure. No caso de um desastre de grandes proporções, como a perda permanente de uma região do Azure devido a um desastre natural ou outro evento semelhante, a Microsoft executará um failover. Neste caso, o secundário torna-se o primário, servindo todas as operações. Como a replicação entre as regiões primária e secundária é assíncrona, no caso de um desastre de grandes proporções, os dados ainda não replicados para a região secundária serão perdidos. Você também pode executar um failover manual de uma conta de armazenamento com redundância geográfica.
  • Armazenamento com redundância de zona geográfica (GZRS): Você pode pensar no 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 são replicadas de forma 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. Compartilhamentos de arquivos padrão maiores que 5 TiB suportam apenas LRS e ZRS. Os compartilhamentos de arquivos Premium do Azure suportam apenas 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 suportam: armazenamento com redundância geográfica acessível de leitura (RA-GRS) e armazenamento com redundância de zona geográfica acessível 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 oferecem 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.

Importante

O armazenamento redundante com redundância geográfica e por zona geográfica tem a capacidade de fazer failover manual do armazenamento para a região secundária. Recomendamos que você não faça isso fora de um desastre quando estiver usando a Sincronização de Arquivos do Azure devido à maior probabilidade de perda de dados. No caso de um desastre em que você gostaria de iniciar um failover manual de armazenamento, você precisará abrir um caso de suporte com a Microsoft para que o Azure File Sync retome a sincronização com o ponto de extremidade secundário.

Migração

Se você tiver um servidor de arquivos do Windows 2012R2 existente 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 do Azure File Sync, ou se seus dados estiverem atualmente localizados no Network Attached Storage (NAS), há várias abordagens de migração possíveis para usar o Azure File Sync com esses dados. A abordagem de migração que você deve escolher depende de onde seus dados residem atualmente.

Consulte o artigo Visão geral da Sincronização de Arquivos do Azure e da migração de compartilhamento de arquivos do Azure para obter orientações detalhadas.

Antivírus

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

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

Nota

Os fornecedores de antivírus podem verificar a compatibilidade entre o seu produto e o Azure File Sync utilizando o Azure File Sync Antivirus Compatibility Test Suite, que está disponível para transferência no Centro de Transferências da Microsoft.

Backup

Se a hierarquização na nuvem estiver habilitada, as soluções que fazem backup direto do ponto de extremidade do servidor ou de uma VM na qual o ponto de extremidade do servidor está localizado não devem ser usadas. A hierarquização na nuvem faz com que apenas um subconjunto dos seus dados seja armazenado no ponto de extremidade do servidor, com o conjunto de dados completo residindo em seu compartilhamento de arquivos do Azure. Dependendo da solução de backup usada, os arquivos hierárquicos serão ignorados e não serão copiados (porque têm o atributo definido) ou serão recuperados para o FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS disco, resultando em altas taxas de saída. Recomendamos usar uma solução de backup na nuvem para fazer backup do compartilhamento de arquivos do Azure diretamente. Para obter mais informações, consulte Sobre o backup de compartilhamento de arquivos do Azure ou entre em contato com seu provedor de backup para ver se eles oferecem suporte ao backup de compartilhamentos de arquivos do Azure.

Se você preferir usar uma solução de backup local, os backups devem ser executados em um servidor no grupo de sincronização que tenha a hierarquização na nuvem desabilitada e verifique se não há arquivos hierárquicos. 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 de 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 de volume não substituirão as versões de arquivo mais recentes no compartilhamento de arquivos do Azure ou em outros pontos de extremidade do servidor.

Nota

A restauração bare-metal (BMR), a restauração de VM, a restauração do sistema (restauração do sistema operacional integrado do Windows) e a restauração no nível de arquivo com sua versão hierárquica (isso acontece quando o software de backup faz backup de um arquivo em camadas em vez de um arquivo completo) podem causar resultados inesperados e não são suportados atualmente quando a hierarquização na nuvem está ativada. Os instantâneos VSS (incluindo a guia Versões Anteriores) são suportados em volumes que têm a hierarquização na nuvem habilitada. No entanto, você deve habilitar a compatibilidade de versões anteriores por meio do PowerShell. Saiba como.

Classificação de Dados

Se você tiver um software de classificação de dados instalado, habilitar a hierarquização na nuvem pode resultar em aumento de custo por dois motivos:

  1. Com a hierarquização na nuvem habilitada, seus arquivos mais quentes são armazenados em cache localmente e seus arquivos mais interessantes são hierarquizados para o compartilhamento de arquivos do Azure na nuvem. Se sua classificação de dados verifica regularmente todos os arquivos no compartilhamento de arquivos, os arquivos hierarquizados na nuvem devem ser recuperados sempre que forem verificados.

  2. Se o software de classificação de dados usar os metadados no fluxo de dados de um arquivo, o arquivo deve ser totalmente recuperado para que o software veja a classificação.

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

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

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

Versões de agentes principais vs. secundários

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

Caminhos de atualização

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

  1. Use o recurso de atualização automática do agente do Azure File Sync para instalar atualizações do agente. O agente do Azure File Sync será atualizado automaticamente. Você pode optar por instalar a versão mais recente do agente quando disponível ou atualizar quando o agente atualmente instalado estiver perto da expiração. Para saber mais, consulte Gerenciamento automático do ciclo de vida do agente.
  2. Configure o Microsoft Update para baixar e instalar automaticamente as atualizações do agente. Recomendamos instalar todas as atualizações do Azure File Sync para garantir que você tenha acesso às correções mais recentes para o agente do servidor. O Microsoft Update torna esse processo perfeito baixando e instalando automaticamente atualizações para você.
  3. Use AfsUpdater.exe para baixar e instalar atualizações do 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 do agente. Dependendo da versão de lançamento, talvez seja necessário reiniciar o servidor.
  4. Corrija um agente existente do Azure File Sync usando um arquivo de patch do Microsoft Update ou um executável .msp. O pacote de atualização mais recente do Azure File Sync pode ser baixado do Catálogo do Microsoft Update. A execução de um executável .msp atualizará sua instalação do Azure File Sync com o mesmo método usado automaticamente pelo Microsoft Update. A aplicação de um patch do Microsoft Update executará uma atualização in-loco de uma instalação do Azure File Sync.
  5. Transfira o mais recente instalador do agente do Azure File Sync a partir do Centro de Transferências da Microsoft. Para atualizar uma instalação existente do agente do Azure File Sync, desinstale a versão mais antiga e instale a versão mais recente a partir do instalador baixado. O registro do servidor, os grupos de sincronização e quaisquer outras configurações são mantidos pelo instalador do Azure File Sync.

Nota

Não há suporte para o downgrade do agente do Azure File Sync. As novas versões geralmente incluem alterações de quebra quando comparadas com as versões antigas, tornando o processo de downgrade sem suporte. Caso você encontre algum problema 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 do Azure File Sync será atualizado automaticamente. Você pode selecionar qualquer 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 um guardrail impedindo que seu agente expire ou permitindo uma configuração sem problemas e atual.

  1. A configuração padrão tentará impedir a expiração do agente. Dentro de 21 dias a partir da data de expiração publicada de um agente, o agente tentará se autoatualizar. 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. Esta opção não elimina a necessidade de usar patches regulares do Microsoft Update.
  2. Opcionalmente, você pode selecionar que o agente se atualizará automaticamente assim que uma nova versão do agente estiver disponível (atualmente não aplicável a servidores clusterizados). 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 ao público. 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 está na qualidade GA. Se você selecionar essa opção, a Microsoft enviará a versão mais recente do agente para você. Os servidores clusterizados são excluídos. Quando o voo estiver concluído, o agente também ficará disponível no Centro de Download da Microsoft aka.ms/AFS/agent.
Alterando 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 onde você instalou o agente de sincronização e, em seguida, importe os cmdlets do servidor. Por padrão, isso seria mais ou menos 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 de política atual para a faixa de atualização imediata, você pode usar:

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

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

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

  • As versões principais do agente são suportadas por pelo menos seis meses a partir da data de lançamento inicial.
  • Garantimos que existe uma sobreposição de pelo menos três meses entre o suporte das versões dos principais agentes.
  • Os avisos são emitidos para servidores registrados usando um agente prestes a expirar pelo menos três meses antes da expiração. Você pode verificar se um servidor registrado está usando uma versão mais antiga do agente na seção servidores registrados de um Serviço de Sincronização de Armazenamento.
  • O tempo de vida de uma versão secundária do agente está vinculado à versão principal associada. Por exemplo, quando a versão 14.0.0.0 do agente estiver definida para expirar, as versões do agente 14.*.*.* serão todas definidas para expirar juntas.

Nota

A instalação de uma versão do agente com um aviso de expiração exibirá um aviso, mas será bem-sucedida. A tentativa de instalar ou conectar-se a uma versão expirada do agente não é suportada e será bloqueada.

Próximos passos