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

Interview and demo introducing Azure File Sync - click to play!

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

Este artigo apresenta conceitos e recursos da Sincronização de Arquivos do Azure. Quando estiver familiarizado com a Sincronização de Arquivos do Azure, siga o guia de implantação da Sincronização de Arquivos do Azure para experimentar esse serviço.

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

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

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

Conceitos de gerenciamento

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

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

Conceitos de gerenciamento de compartilhamento de arquivo do Azure

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

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

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

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

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

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

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

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

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. Se você fizer uma alteração diretamente no Ponto de extremidade de nuvem (compartilhamento de Arquivos do Azure), observe que as alterações devem primeiro ser descobertas por um trabalho de detecção de alteração de sincronização de arquivos do Azure. Um trabalho de detecção de alteração é iniciado para um ponto de extremidade da nuvem apenas uma vez a cada 24 horas. Para obter mais informações, consulte Perguntas frequentes sobre os Arquivos do Azure.

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

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

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

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

Planejar topologias de sincronização balanceada

Antes de implantar qualquer recurso, é importante planejar o que será sincronizado em um servidor local, com 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 se os dados não residem atualmente em um Windows Server ou no servidor que você deseja usar em longo prazo. A seção de migração pode ajudar a determinar os caminhos de migração apropriados para sua situação.

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

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

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

Agrupamento de compartilhamentos

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

Sincronização de volume

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

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

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

Dica

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

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

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

  • Um compartilhamento de arquivo do Azure é implantado em uma conta de armazenamento. Essa organização faz com que a conta de armazenamento seja uma meta de escala para números de desempenho, como IOPS e taxa de transferência.

    Um compartilhamento de arquivos padrão do Azure pode teoricamente saturar o desempenho máximo que uma conta de armazenamento pode fornecer. Se você colocar vários compartilhamentos em uma só conta de armazenamento, estará criando um pool compartilhado de IOPS e de taxa de transferência para esses compartilhamentos. Se você planeja anexar apenas Sincronização de Arquivos do Azure a esses compartilhamentos de arquivos, o agrupamento de vários compartilhamentos de arquivos do Azure na mesma conta de armazenamento não criará um problema. Examine as metas de desempenho do compartilhamento de arquivo do Azure para obter mais insights sobre as métricas relevantes. Essas limitações não se aplicam ao Armazenamento Premium, no qual o desempenho é provisionado e garantido explicitamente para cada compartilhamento.

    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

Considerando essas informações, geralmente é necessário agrupar várias pastas de nível superior dos volumes em um novo diretório raiz comum. Em seguida, você sincroniza esse novo diretório raiz e todas as pastas que você agrupou para ele 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 os caminhos dos compartilhamentos (como compartilhamentos SMB ou NFS) que estão nas pastas do servidor local que foram alteradas 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.

É uma prática recomendada manter o número de itens por escopo de sincronização baixo. Esse é um fator importante a ser considerado no mapeamento de pastas para compartilhamentos de arquivos do Azure. Sincronização de Arquivos do Azure é testado com 100 milhões itens (arquivos e pastas) por compartilhamento. Mas geralmente é melhor manter o número de itens abaixo de 20 ou 30 milhões em um só compartilhamento. Divida o namespace em vários compartilhamentos se você começar a exceder esses números. Você pode continuar a agrupar vários compartilhamentos locais no mesmo compartilhamento de arquivos do Azure se ficar mais abaixo desses números. Essa prática fornecerá espaço para crescer.

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

Criar uma tabela de mapeamento

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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

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


Excel icon that sets the context for the download. Baixe um modelo de mapeamento de namespace.

Considerações sobre servidor de arquivos do Windows

Para habilitar a funcionalidade de sincronização no Windows Server, você deve instalar o agente Sincronização de Arquivos do Azure para baixar. O agente de Sincronização de Arquivos do Azure fornece dois componentes principais: FileSyncSvc.exe, o serviço Windows em segundo plano 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 do sistema de arquivos que habilita a camada de nuvem e a rápida recuperação de desastre.

Requisitos do sistema operacional

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

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

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

Importante

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

O serviço Sincronização de Arquivos do Azure requer um servidor, físico ou virtual, com pelo menos uma CPU e um mínimo de 2 GiB de memória.

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 a configuração de um servidor de sincronização da Sincronização de Arquivos do Azure somente com os requisitos mínimos. Confira Recursos do sistema recomendados para obter mais informações.

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

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

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

Na tabela a seguir, fornecemos o tamanho do namespace, bem como uma conversão para capacidade para compartilhamentos de arquivos de uso geral típicos, em que o tamanho médio do arquivo é 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 & 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 8 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)

*A sincronização de mais de 100 milhões arquivos & diretórios não é recomendada neste momento. 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 e é recomendável 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 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 CPU.

  • Um volume anexado localmente formatado com o sistema de arquivos NTFS.

Cmdlet de avaliação

Antes de implantar a Sincronização de Arquivos do Azure, você precisa avaliar se ela é compatível com 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. As verificações abrangem a maioria dos recursos mencionados abaixo, mas não todos eles. É recomendável que você leia o restante desta seção com cuidado para garantir que sua implantação seja perfeita.

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

Uso

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

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Para testar apenas o conjunto de dados:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Para testar somente os requisitos do sistema:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Para exibir os resultados em CSV:

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

Compatibilidade do sistema de arquivos

A Sincronização de Arquivos do Azure só é compatível com volumes NTFS anexados diretamente. O armazenamento com conexão direta (ou DAS) no Windows Server significa que o sistema operacional do Windows Server é proprietário do sistema de arquivos. O DAS pode ser fornecido 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 por meio de ISCSI.

Somente volumes NTFS são compatíveis; ReFS, FAT, FAT32 e outros sistemas de arquivos não são compatíveis.

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

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

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

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

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

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

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

  • Com a camada de nuvem habilitada:

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

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

Vamos usar um exemplo para ilustrar como estimar a quantidade de espaço livre necessário no disco local. Digamos que você instalou o agente de Sincronização de Arquivos do Azure na VM do Azure Windows e planeja criar um ponto de extremidade do servidor no disco F. Você tem 1 milhão de arquivos e gostaria de transferir todos eles, 100.000 diretórios e um tamanho de cluster de disco de 4 KiB. O tamanho do disco é de 1.000 GiB. Você deseja habilitar a camada de nuvem e definir a política de espaço livre de volume como 20%.

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

Observação

O espaço ocupado pelos arquivos transferidos é alocado pelo NTFS. Portanto, ele não vai aparecer em nenhuma interface do usuário. 3. Os metadados de sincronização ocupam um tamanho de cluster por item. (1 milhão de arquivos + 100 mil diretórios) * 4 KB de tamanho de cluster = 4.400.000 KiB (4,4 GiB) 4. O repositório de calor 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) 5. A política de espaço livre de volume é de 20%. 1\.000 GiB * 0,2 = 200 GiB

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

Clustering de failover

  1. O clustering de failover do Windows Server tem suporte pela Sincronização de Arquivo do Azure para a opção de implantação “Servidor de Arquivos de uso geral”.
  2. O único cenário com suporte pelo Sincronização de Arquivos do Azure é o Cluster de Failover do servidor do Windows com discos clusterizados
  3. Não há suporte para o Clustering de Failover em "SOFS (Servidor de Arquivos de Escalabilidade Horizontal) para dados de aplicativos" ou CSVs (Volumes Compartilhados Clusterizados) ou discos locais.

Observação

O agente de Sincronização de Arquivos do Azure deve ser instalado em cada nó em um Cluster de Failover para a sincronização funcionar corretamente.

Eliminação de duplicação de dados

Windows Server 2016 e Windows Server 2019
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 do servidor no volume para o Windows Server 2016 e o Windows Server 2019. Habilitar a Eliminação de Duplicação de Dados em um volume com camada de nuvem habilitada permite armazenar em cache mais arquivos localmente sem ter que provisionar mais armazenamento.

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

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

Observação

Para dar suporte à Eliminação de Duplicação de Dados em volumes com a camada de nuvem habilitada no Windows Server 2019, o Windows Update KB4520062 - Outubro de 2019, ou uma atualização cumulativa mensal posterior, deve ser instalado e o agente da Sincronização de Arquivos do Azure versão 12.0.0.0 ou mais recente é necessário.

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

Observações

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

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

    • A política de espaço livre continuará a colocar arquivos em camada de acordo com o espaço livre no volume usando o mapa de calor.
    • A política de data ignorará a camada de arquivos que, de outra forma, poderia ter sido qualificada para camada devido ao trabalho de otimização da eliminação de duplicação que acessa os arquivos.
  • Para trabalhos de otimização de eliminação de duplicação em andamento, a camada de nuvem com a política de data será atrasada pela configuração MinimumFileAgeDays da Eliminação de Duplicação de Dados, se o arquivo ainda não estiver em camada.

    • Exemplo: Se a configuração MinimumFileAgeDays for de sete dias e a política de data da camada de nuvem for de 30 dias, a política de data colocará os arquivos em camada após 37 dias.
    • Observação: Quando um arquivo é colocado em camadas pela Sincronização de Arquivos do Azure, o trabalho de otimização da eliminação de duplicação ignorará o arquivo.
  • Se um servidor que executa o Windows Server 2012 R2 com o agente da Sincronização de Arquivos do Azure instalado for atualizado para o Windows Server 2016 ou o Windows Server 2019, as seguintes etapas deverão ser executadas para dar suporte à Eliminação de Duplicação de Dados e à camada de nuvem no mesmo volume:

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

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

DFS (Sistema de Arquivos Distribuído)

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

DFS-N (Namespaces de DFS) : A Sincronização de Arquivos do Azure é totalmente suportada em servidores DFS-N. É possível instalar o agente Sincronização de arquivos do Azure em um ou mais membros DFS-N para sincronizar dados entre os pontos de extremidade de servidor e o ponto de extremidade da nuvem. Para obter mais informações, consulte visão geral de Namespaces de DFS.

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

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

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

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

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

Sysprep

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

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

Observação

Clientes Windows causarão 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. Por padrão, essa configuração é desabilitada.

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

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

Desempenho e escalabilidade

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

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

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

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

Identidade

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

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

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 êxito. Essa é uma etapa estritamente 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.

Rede

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

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

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

Importante

A Sincronização de Arquivos do Azure não dá suporte ao roteamento da Internet. A opção de roteamento de rede padrão, Roteamento da Microsoft, é compatível com a Sincronização de Arquivos do Azure.

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

Criptografia

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

Criptografia em repouso do Windows Server

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

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

Os produtos de terceiros que funcionam de maneira semelhante ao BitLocker, no que ficam subjacente ao volume NTFS, devem funcionar de maneira totalmente transparente com a Sincronização de Arquivos do Azure.

O outro método principal para criptografar dados é criptografar o fluxo de dados do arquivo quando o aplicativo salva o arquivo. Alguns aplicativos podem fazer isso nativamente, no entanto, geralmente esse não é o caso. Um exemplo de um método para criptografar o fluxo de dados do arquivo é a AIP (Proteção de Informações do Azure)/o Azure RMS (Azure Rights Management Services)/o RMS do Active Directory. O principal motivo para usar um mecanismo de criptografia como o AIP/RMS é impedir a exfiltração dos dados do seu compartilhamento de arquivo por pessoas que os copiam para locais alternativos, como em uma unidade flash ou os enviam por email para uma pessoa não autorizada. Quando o fluxo de dados de um arquivo é criptografado como parte do formato de arquivo, esse arquivo continuará a ser criptografado no compartilhamento de arquivo do Azure.

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

Criptografia em trânsito

Observação

O serviço Sincronização de Arquivos do Azure removerá 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. O uso de uma versão anterior do TLS poderia ocorrer se o TLS 1.2 fosse desabilitado no servidor ou um proxy fosse usado. Se você estiver usando um proxy, recomendamos que verifique a configuração do proxy. As regiões do serviço Sincronização de Arquivos do Azure adicionadas após 01/05/2020 serão compatíveis apenas com o TLS 1.2 e a compatibilidade com TLS 1.0 e 1.1 será removida das regiões existentes em 1º de agosto de 2020. Para obter mais informações, confira o guia de solução de problemas.

O agente de Sincronização de Arquivos do Azure se comunica com o Serviço de Sincronização de Armazenamento e o compartilhamento de arquivo do Azure usando o protocolo REST e o protocolo FileREST da Sincronização de Arquivos do Azure e ambos sempre usam HTTPS pela porta 443. A Sincronização de Arquivos do Azure não envia solicitações não criptografadas por HTTP.

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

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

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

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

Criptografia de compartilhamento de arquivo do Azure em repouso

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

Por padrão, os dados armazenados nos Arquivos do Azure são criptografados com as chaves gerenciadas pela Microsoft. Com as chaves gerenciadas pela Microsoft, a Microsoft mantém as chaves para criptografar/descriptografar os dados e é responsável pela rotação regular delas. Você também pode optar por gerenciar as próprias chaves, o que dá controle a você sobre o processo de rotação. Se você optar por criptografar seus compartilhamentos de arquivo com chaves gerenciadas pelo cliente, os Arquivos do Azure terão autorização para acessar suas chaves para atender a solicitações de leitura e gravação de seus clientes. Com as chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento, mas isso significa que o compartilhamento de arquivo do Azure não estará mais acessível pelo SMB ou pela API FileREST.

Os Arquivos do Azure usam o mesmo esquema de criptografia que os outros serviços de armazenamento do Azure, como o Armazenamento de Blobs do Azure. Para saber mais sobre a SSE (Criptografia do Serviço de Armazenamento) do Azure, confira Criptografia do armazenamento do Azure para dados em repouso.

Camadas de armazenamento

Os Arquivos do Azure oferecem quatro camadas diferentes de armazenamento: premium, transação otimizada, quente e fria para permitir que você personalize seus compartilhamentos conforme os requisitos de desempenho e preço de seu cenário:

  • Premium: os compartilhamentos de arquivo Premium contam com SSDs (unidades de estado sólido) e fornecem alto desempenho consistente e baixa latência, em milissegundos de dígito único para a maioria das operações de E/S e para cargas de E/S intensivas. Compartilhamentos de arquivo Premium são adequados para uma ampla variedade de cargas de trabalho, como bancos de dados, hospedagem de websites e ambientes de desenvolvimento. Os compartilhamentos de arquivo Premium podem ser usados com protocolos SMB e NFS (Network File System).
  • Transação otimizada: Compartilhamentos de arquivos com transação otimizada permitem cargas de trabalho pesadas de transação que não precisam da latência oferecida por compartilhamentos de arquivos Premium. Os compartilhamentos de arquivo com transação otimizada são oferecidos no hardware de armazenamento padrão apoiado por HDs (unidades de disco rígido). A transação otimizada tem sido, historicamente, chamada de "padrão". No entanto, isso se refere ao tipo de mídia de armazenamento, não à camada em si (as camadas quente e fria também são "padrão", pois estão no hardware de armazenamento padrão).
  • Frequente: os compartilhamentos de arquivo frequentes oferecem armazenamento otimizado para cenários de compartilhamento de arquivos de uso geral, como compartilhamentos de equipe. Os compartilhamentos de arquivo quentes são oferecidos no hardware de armazenamento padrão apoiado por HDs.
  • Esporádico: Os compartilhamentos de arquivos frios oferecem armazenamento econômico otimizado para cenários de armazenamento de arquivos online. Os compartilhamentos de arquivo frios são oferecidos no hardware de armazenamento padrão apoiado por HDs.

Os compartilhamentos de arquivo Premium são implantados no tipo de conta de armazenamento do FileStorage e só estão disponíveis em um modelo de cobrança provisionado. Para obter mais informações sobre o modelo de cobrança provisionado para compartilhamentos de arquivos premium, confira Noções básicas sobre provisionamento de compartilhamentos de arquivos premium. Os compartilhamentos de arquivo padrão, incluindo compartilhamentos de arquivo com transação otimizada, quentes e frios, são implantados no tipo de conta de armazenamento GPv2 (uso geral versão 2) e estão disponíveis por meio da cobrança de pagamento conforme o uso.

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

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

Os compartilhamentos de arquivo implantados em contas de armazenamento GPv2 podem ser movidos entre as camadas Standard (com transação otimizada, quente e fria) sem criar uma conta de armazenamento e migrar os dados, mas você vai gerar custos de transações quando alterar a camada. Ao mover um compartilhamento de uma camada mais quente para uma camada mais fria, você vai gerar um custo de transação de gravação da camada mais fria para cada arquivo do compartilhamento. A movimentação de um compartilhamento de arquivo de uma camada mais fria para uma camada mais quente vai gerar um custo de transação de leitura da camada fria para cada arquivo do compartilhamento.

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

Disponibilidade regional

Os compartilhamentos de arquivo padrão com capacidade de 100 TiB têm certas limitações.

  • Atualmente, há suporte somente para as contas LRS (armazenamento com redundância local) e ZRS (armazenamento com redundância de zona).
  • Depois de habilitar grandes compartilhamentos de arquivo, você não poderá converter contas de armazenamento em GRS (armazenamento com redundância geográfica) ou GZRS (armazenamento com redundância de zona geográfica).
  • Depois de habilitar grandes compartilhamentos de arquivo, você não poderá desabilitá-los.

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

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

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

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

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

Redundância

Para proteger os dados em seus compartilhamentos de arquivo do Azure contra perda ou corrupção de dados, todos os compartilhamentos de arquivos do Azure armazenam várias cópias de cada arquivo conforme eles são gravados. Será possível selecionar graus adicionais de redundância dependendo dos requisitos de sua carga de trabalho. No momento, os Arquivos do Azure são compatíveis com as seguintes opções de redundância de dados:

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

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

As contas GPv2 (armazenamento de uso geral versão 2) fornecem duas opções adicionais de redundância que não são compatíveis com os Arquivos do Azure: o armazenamento com redundância geográfica com acesso de leitura, geralmente chamado de RA-GRS, e o armazenamento com redundância de zona geográfica com acesso de leitura, geralmente chamado de RA-GZRS. Será possível provisionar compartilhamentos de arquivo do Azure em contas de armazenamento com essas opções definidas. No entanto, os Arquivos do Azure não são compatíveis com a leitura da região secundária. Os compartilhamentos de arquivo do Azure implantados em contas de armazenamento com redundância geográfica ou de zona geográfica com acesso de leitura serão cobrados como um armazenamento com redundância geográfica ou um armazenamento com redundância de zona geográfica, respectivamente.

Importante

O armazenamento com redundância geográfica e redundância de zona geográfica tem a capacidade de fazer failover manual do armazenamento na região secundária. É recomendável 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 do armazenamento, será necessário abrir um caso de suporte com a Microsoft para fazer com que a Sincronização de Arquivos do Azure retome a sincronização com o ponto de extremidade secundário.

Migração

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

Confira o artigo Visão geral da migração da Sincronização de Arquivos do Azure e do compartilhamento de arquivos do Azure, no qual você pode encontrar diretrizes detalhadas para seu cenário.

Antivírus

Como os antivírus funcionam com o exame de arquivos em busca de códigos mal-intencionados conhecidos, um antivírus pode causar o recall de arquivos em camadas, resultando em altos encargos de saída. Nas versões 4.0 e acima do agente de Sincronização de Arquivo do Azure, arquivos em camadas têm o conjunto FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS de atributo seguro do Windows. Recomendamos consultar o fornecedor do software para saber como configurar a 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, o Windows Defender e o System Center Endpoint Protection (SCEP), ignoram automaticamente a leitura de arquivos que possuem esse atributo definido. Nós os testamos e identificamos um problema menor: quando você adiciona um servidor a um grupo de sincronização existente, os arquivos com menos de 800 bytes são recuperados (feitos o download) no novo servidor. Esses arquivos permanecerão no novo servidor e não serão colocados em camadas, pois não atendem ao requisito de tamanho de camadas (>64kb).

Observação

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, que está disponível para download no Centro de Download da Microsoft.

Backup

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

Se você preferir usar uma solução de backup local, os backups deverão ser executados em um servidor no grupo de sincronização que tenha a camada de nuvem desabilitada. Ao executar uma restauração, use as opções de restauração no nível do volume ou no nível do arquivo. Os arquivos restaurados usando a opção de restauração no nível do arquivo serão sincronizados com todos os pontos de extremidade no grupo de sincronização e os arquivos existentes serão substituídos pela versão restaurada do backup. As restaurações no nível 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.

Aviso

Se você precisar usar o Robocopy /B com um agente de Sincronização de Arquivos do Azure em execução no servidor de origem ou de destino, atualize para o agente de Sincronização de Arquivos do Azure versão v12.0 ou superior. Usar o Robocopy /B com versões de agente inferiores a v12.0 resultará em corrupção de arquivos em camadas durante a cópia.

Observação

A restauração bare-metal (BMR) pode causar resultados inesperados e não é atualmente suportada.

Observação

Com a versão 9 do agente de Sincronização de Arquivos do Azure, os instantâneos do VSS (incluindo a guia Versões Anteriores) não são compatíveis com volumes com 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

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

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

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

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

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

O agente de Sincronização de arquivos do Azure é atualizado regularmente para adicionar novos recursos e resolver problemas. Recomendamos que você configure o Microsoft Update para obter atualizações para o agente de Sincronização de arquivos do Azure à medida que elas ficarem 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: *2.*.**
  • 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: **.3.**

Caminhos de atualização

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

  1. (Preferencial) Configure o Microsoft Update para baixar e instalar automaticamente as atualizações do agente.
    É sempre recomendável executar todas as atualizações de Sincronização de arquivos do Azure para garantir que você tenha acesso às últimas correções para o Server Agent. O Microsoft Update simplifica esse processo, baixando e instalando atualizações automaticamente para você.
  2. Use AfsUpdater.exe para baixar e instalar atualizações de agente.
    O AfsUpdater.exe está localizado no diretório de instalação do agente. Clique duas vezes no executável para baixar e instalar atualizações de agente.
  3. Corrigir um agente existente de Sincronização de arquivos do Azure utilizando um arquivo de patch do Microsoft Update ou um executável .msp. O último pacote de atualização da Sincronização de Arquivos do Azure pode ser baixado no Catálogo do Microsoft Update.
    Executar um executável .msp atualizará a instalação de Sincronização de arquivos do Azure com o mesmo método usado automaticamente pelo Microsoft Update no caminho de atualização anterior. A aplicação de um patch do Microsoft Update realizará uma atualização no local de uma instalação e Sincronização de arquivos do Azure.
  4. Baixe o mais recente instalador do agente de Sincronização de Arquivos do Azure do Centro de Download da Microsoft.
    Para fazer upgrade de uma instalação existente do agente de Sincronização de Arquivos do Azure, desinstale a versão mais antiga e então instale a última versão do instalador baixado. O registro do servidor, os grupos de sincronização e outras configurações são mantidos pelo instalador de Sincronização de arquivos do Azure.

Gerenciamento automático do ciclo de vida do agente

Com a versão 6 do agente, a equipe de sincronização de arquivos introduziu um recurso de atualização automática do agente. Você pode selecionar um dos dois modos e especificar uma janela de manutenção na qual a atualização deve ser tentada no servidor. Esse recurso foi projetado para ajudá-lo com o gerenciamento do ciclo de vida do agente, fornecendo uma proteção que impede o agente de expirar ou permitindo uma configuração atual sem complicações.

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

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

Abra um console do PowerShell e navegue até o diretório onde você instalou o agente de sincronização e importe os cmdlets do servidor. Por padrão, seria algo assim:

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

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

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

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

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

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

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. Isso significa que uma versão específica do agente de Sincronização de arquivos do Azure somente poderá ter suporte por um tempo limitado. Para facilitar sua implantação, as seguintes regras garantem que você tenha tempo e notificação suficientes para acomodar atualizações/upgrades de agente em seu processo de gerenciamento de mudança:

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

Observação

A instalação de uma versão do agente com um aviso de expiração exibirá um aviso, porém com êxito. A tentativa de instalar ou conectar uma versão do agente expirada não tem suporte e será bloqueada.

Próximas etapas