Criar um endpoint de servidor Azure File Sync

Os pontos finais de servidor representam uma localização específica num servidor registado, como uma pasta num volume do servidor. Um ponto de extremidade de servidor deve atender às seguintes condições:

Um ponto de extremidade de servidor deve ser um caminho num servidor registado (ao invés de uma partilha montada). O armazenamento conectado à rede (NAS) não é suportado.
Embora o ponto de extremidade do servidor possa estar no volume do sistema, os pontos de extremidade do servidor no volume do sistema não podem usar a hierarquização na nuvem.
Não há suporte para alterar o caminho ou a letra da unidade depois de estabelecer um ponto de extremidade do servidor em um volume. Certifique-se de que está a usar um caminho adequado antes de criar o endpoint do servidor.
Um servidor registado pode suportar vários pontos de extremidade de servidor, no entanto, um grupo de sincronização só pode ter um ponto de extremidade de servidor por servidor registado em qualquer momento dado. Outros pontos finais de servidor dentro do grupo de sincronização devem estar em diferentes servidores registados.
Vários pontos de extremidade de servidor podem existir no mesmo volume se seus namespaces não estiverem sobrepostos (por exemplo, F:\sync1 e F:\sync2) e cada ponto de extremidade estiver sincronizando com um grupo de sincronização exclusivo.

Este artigo ajuda-o a compreender as opções e decisões necessárias para criar um novo endpoint de servidor e iniciar a sincronização. Para que isto funcione, tens de ter terminado o planeamento para a tua implementação Azure File Sync e também ter implementado recursos necessários em etapas anteriores para criar um endpoint de servidor.

Prerequisites

Para criar um ponto de extremidade de servidor, você deve primeiro garantir que os seguintes critérios sejam atendidos:

O servidor tem instalado o agente Azure File Sync e está registado. Consulte Registar/desregistar um servidor com Azure File Sync para detalhes sobre como instalar o Agente Azure File Sync.
Verifique se um Serviço de Sincronização de Armazenamento foi implantado. Consulte Como implementar Azure File Sync para detalhes sobre como implementar um Serviço de Sincronização de Armazenamento.
Verifique se um grupo de sincronização foi implantado. Saiba como Criar um grupo de sincronização.
Certifique-se de que o servidor está ligado à internet e que o Azure está acessível. O Azure File Sync utiliza a porta 443 para toda a comunicação entre o servidor e o serviço cloud.
Certifique-se de que está dentro dos limites autorizados para criar pontos de extremidade. Consulte Azure File Sync Scale Targets para detalhes sobre escalabilidade e metas de desempenho.

Criar um ponto final de servidor

Vá para o grupo de sincronização recém-criado.
Em Pontos de extremidade do servidor, selecione +Adicionar ponto de extremidade do servidor.
No painel Adicionar ponto de extremidade do servidor , insira as seguintes informações:
- Servidor Registrado: Selecione o nome do servidor ou cluster onde você deseja criar o ponto de extremidade do servidor.
- Path: Introduza o caminho na instância do Windows Server a ser sincronizado com a partilha de ficheiros Azure. O caminho pode ser uma pasta (por exemplo, D:\Data), raiz do volume (por exemplo, D:\) ou ponto de montagem do volume (por exemplo, D:\Mount).
- Hierarquia na nuvem: esta seção inclui uma opção para habilitar ou desabilitar a hierarquização na nuvem. Com o cloud tiering, ficheiros pouco usados ou acedidos podem ser escalonados para o Ficheiros do Azure. Quando ativas o tiering na cloud, existem duas políticas que podes definir para informar o Azure File Sync quando deves escalonar ficheiros inativos.
  - Política de Espaço Livre de Volume: a quantidade de espaço livre a ser reservada no volume no qual o ponto de extremidade do servidor está localizado. Por exemplo, se o espaço livre no volume for definido para 50% num volume que tem apenas um endpoint de servidor, cerca de metade da quantidade de dados é transferida para os Ficheiros do Azure. Independentemente de a hierarquização na nuvem estar ativada, a partilha de ficheiros do Azure tem sempre uma cópia completa dos dados no grupo de sincronização.
  - Política de data: os arquivos são hierarquizados na nuvem se não forem acessados (ou seja, lidos ou gravados) pelo número de dias especificado. Por exemplo, se você notar que os arquivos que passam mais de 15 dias sem serem acessados são normalmente arquivos de arquivamento, você deve definir sua política de data para 15 dias.
- Sincronização inicial: esta seção está disponível apenas para o primeiro ponto de extremidade do servidor em um grupo de sincronização. (A seção muda para Download Inicial quando estiver a criar mais do que um endpoint de servidor num grupo de sincronização.) Pode selecionar o comportamento seguinte:
  - Upload Inicial: Como o servidor inicialmente carrega os dados para a Azure partilha de ficheiros. Estão disponíveis duas opções:
    - Mescle o conteúdo deste caminho de servidor com o conteúdo da partilha de ficheiros do Azure. Arquivos com o mesmo nome e caminho levarão a conflitos se seu conteúdo for diferente. Ambas as versões desses arquivos são armazenadas uma ao lado da outra. Se o caminho do teu servidor ou partilha de ficheiros do Azure estiver vazia, escolhe sempre esta opção.
    - Sobrescreva autoritativamente ficheiros e pastas no compartilhamento de arquivos do Azure com o conteúdo no caminho deste servidor. Esta opção evita conflitos de ficheiros.
  Para saber mais, consulte a seção Sincronização inicial.
  - Initial Download: Como o servidor descarrega inicialmente os dados Azure partilha de ficheiros. Esta configuração é importante quando o servidor está a ligar-se a uma partilha de ficheiros do Azure que contém ficheiros. Três opções estão disponíveis:
    - Baixe o namespace primeiro e, em seguida, recupere o conteúdo do arquivo, tanto quanto você pode caber no disco local. Namespace significa a estrutura de arquivos e pastas sem o conteúdo do arquivo.
    - Baixe somente o namespace. O conteúdo do arquivo é recuperado quando é acessado.
    - Evite arquivos hierárquicos. Os ficheiros só aparecem no servidor depois de serem totalmente transferidos. O acesso local ou a política definida recupera os conteúdos dos ficheiros hierarquizados da nuvem para o servidor.
  Para saber mais, consulte a seção Download inicial.
Para concluir a adição do servidor endpoint, selecione Criar. Os seus ficheiros são agora mantidos sincronizados entre a sua partilha de ficheiros do Azure e a instância do Windows Server.

Nota

O Azure File Sync tira um snapshot da partilha de ficheiros do Azure como backup antes de criar o endpoint do servidor. Você pode usar este instantâneo para restaurar o compartilhamento ao estado anterior à criação do ponto final do servidor.

O instantâneo não é removido automaticamente após a criação do endpoint do servidor. Você pode excluí-lo manualmente se não precisar dele.

Pode encontrar os instantâneos que a Azure File Sync criou ao visualizar os instantâneos da partilha de ficheiros Azure e verificar AzureFileSync na coluna Initiator.

Execute os seguintes comandos do PowerShell para criar o endpoint do servidor. Substitua <your-server-endpoint-path> e <your-volume-free-space> com os valores desejados. Verifique as configurações para as políticas opcionais de download inicial e upload inicial.

$serverEndpointPath = "<your-server-endpoint-path>"
$cloudTieringDesired = $true
$volumeFreeSpacePercentage = <your-volume-free-space>
# Optional property. Choose from: [NamespaceOnly], the default when cloud tiering is enabled. [NamespaceThenModifiedFiles], the default when cloud tiering is disabled. [AvoidTieredFiles], available only when cloud tiering is disabled.
$initialDownloadPolicy = "NamespaceOnly"
$initialUploadPolicy = "Merge"
# Optional property. Choose from: [Merge], the default for all new server endpoints. Content is from the server and the cloud merge. This is the right choice if one location is empty or other server endpoints already exist in the sync group. [ServerAuthoritative], the right choice when you seeded the Azure file share (for example, with Azure Data Box) and you're connecting the server location that you seeded from. It enables you to catch up the Azure file share with the changes that happened on the local server since the seeding.

if ($cloudTieringDesired) {
    # Ensure that the endpoint path is not the system volume
    $directoryRoot = [System.IO.Directory]::GetDirectoryRoot($serverEndpointPath)
    $osVolume = "$($env:SystemDrive)\"
    if ($directoryRoot -eq $osVolume) {
        throw [System.Exception]::new("Cloud tiering cannot be enabled on the system volume")
    }

    # Create the server endpoint
    New-AzStorageSyncServerEndpoint `
        -Name $registeredServer.FriendlyName `
        -SyncGroup $syncGroup `
        -ServerResourceId $registeredServer.ResourceId `
        -ServerLocalPath $serverEndpointPath `
        -CloudTiering `
        -VolumeFreeSpacePercent $volumeFreeSpacePercentage `
        -InitialDownloadPolicy $initialDownloadPolicy `
        -InitialUploadPolicy $initialUploadPolicy
} else {
    # Create the server endpoint
    New-AzStorageSyncServerEndpoint `
        -Name $registeredServer.FriendlyName `
        -SyncGroup $syncGroup `
        -ServerResourceId $registeredServer.ResourceId `
        -ServerLocalPath $serverEndpointPath `
        -InitialDownloadPolicy $initialDownloadPolicy
}

Use o comando az storagesync sync-group server-endpoint para criar um novo ponto de extremidade do servidor:

# Create a new sync group server endpoint 
az storagesync sync-group server-endpoint create --resource-group myResourceGroupName \
                                                 --name myNewServerEndpointName
                                                 --registered-server-id 91beed22-7e9e-4bda-9313-fec96c286e0
                                                 --server-local-path d:\myPath
                                                 --storage-sync-service myStorageSyncServiceNAme
                                                 --sync-group-name mySyncGroupName

# Create a new sync group server endpoint with additional optional parameters
az storagesync sync-group server-endpoint create --resource-group myResourceGroupName \
                                                 --storage-sync-service myStorageSyncServiceName \
                                                 --sync-group-name mySyncGroupName \
                                                 --name myNewServerEndpointName \
                                                 --registered-server-id 91beed22-7e9e-4bda-9313-fec96c286e0 \
                                                 --server-local-path d:\myPath \
                                                 --cloud-tiering on \
                                                 --volume-free-space-percent 85 \
                                                 --tier-files-older-than-days 15 \
                                                 --initial-download-policy NamespaceOnly [OR] NamespaceThenModifiedFiles [OR] AvoidTieredFiles
                                                 --initial-upload-policy Merge [OR] ServerAuthoritative

Seção de tierização na nuvem

Ao criar um novo endpoint de servidor, pode optar pela funcionalidade cloud tiering do Azure File Sync. As opções na secção Cloud tiering podem ser alteradas mais tarde. No entanto, diferentes opções na seção a seguir estão disponíveis com base em ter a hierarquização na nuvem habilitada ou não para seu novo ponto de extremidade de servidor.

Consulte o artigo sobre hierarquização na nuvem que aborda as noções básicas, as políticas e as práticas recomendadas em detalhes.

Seção de sincronização inicial

A seção Sincronização inicial está disponível apenas para o primeiro ponto de extremidade do servidor em um grupo de sincronização. Para qualquer endpoint de servidor adicional, consulte a secção de transferência inicial.

Há dois comportamentos de sincronização inicial fundamentalmente diferentes:

Mesclar

Carregamento autorizado

Mesclar é a opção padrão e está selecionada automaticamente. Você deve deixar a seleção em Mesclar, exceto em certos cenários de migração.

Ao ingressar em um local de servidor, na maioria dos cenários, o local do servidor ou o compartilhamento de nuvem está vazio. Nestes casos, Merge é o comportamento certo e levará aos resultados esperados.
Quando ambos os locais contiverem arquivos e pastas, os namespaces serão mesclados. Se houver nomes de arquivos ou pastas no servidor que também existam no compartilhamento de nuvem, haverá um conflito de sincronização. Os conflitos são resolvidos automaticamente.

Dentro da opção Merge, pode selecionar como o conteúdo da partilha de ficheiros Azure chegará inicialmente ao servidor. Esta seleção não tem impacto se a partilha de ficheiros do Azure estiver vazia. Você pode encontrar mais detalhes na seção Download inicial.

O carregamento autoritativo é uma opção de sincronização inicial reservada para um cenário de migração específico. Sincroniza o mesmo caminho do servidor que também foi usado para iniciar a partilha de cloud com, por exemplo, o Azure Data Box. Neste caso, a nuvem e os locais do servidor têm basicamente os mesmos dados, mas o servidor é um pouco mais novo. Os usuários continuaram fazendo alterações enquanto o Data Box estava em transporte. Esse cenário de migração exige a atualização da nuvem de forma transparente com as alterações recentes no servidor, sem produzir conflitos. Assim, o servidor é a autoridade sobre a estrutura do namespace e o Data Box foi usado para evitar um grande carregamento inicial para o servidor. O carregamento autorizado do servidor permite uma adoção da nuvem sem interrupções, mesmo quando um mecanismo de transporte de dados fora de linha foi usado para iniciar o armazenamento em nuvem.

Um ponto de extremidade de servidor só terá sucesso no provisionamento com a opção de carregamento autoritativo quando o local do servidor contiver dados. Este bloco é para proteger contra configurações incorretas acidentais. O upload autorizado funciona como RoboCopy /MIR. Este modo espelha a origem para o destino. A origem é o servidor AFS e o destino é o compartilhamento de nuvem. O carregamento autorizado moldará o alvo na imagem da fonte.

Arquivos e pastas novos ou atualizados serão carregados do servidor.
Os ficheiros e pastas que já não existem no servidor (mais) serão eliminados da partilha na nuvem.
As alterações somente de metadados em arquivos e pastas no servidor serão movidas de forma eficiente para o compartilhamento de nuvem como atualizações somente de metadados.
Podem existir ficheiros e pastas no servidor e na partilha na nuvem. Mas alguns ficheiros ou pastas podem ter mudado o diretório principal no servidor desde a criação da partilha de ficheiros do Azure. Esses arquivos e pastas serão removidos do compartilhamento na nuvem e carregados novamente. Por isso, é melhor evitar a reestruturação do namespace em uma escala maior durante uma migração.

Seção de download inicial

A seção Download inicial está disponível para o segundo e quaisquer outros pontos de extremidade de servidor em um grupo de sincronização. O primeiro servidor endpoint num grupo de sincronização tem opções extra relacionadas com a migração para Azure Data Box. Essas opções não se aplicam se esse ponto de extremidade do servidor não for o primeiro do seu grupo de sincronização.

Nota

Selecionar uma opção de download inicial não tem impacto se a partilha de ficheiros do Azure estiver vazia.

Como parte desta secção, escolhe como o conteúdo da partilha de ficheiros do Azure chegará inicialmente ao servidor.

	Baixe o namespace primeiro	Baixe somente o namespace	Evite arquivos hierárquicos
Descrição	Baixa o namespace inteiro primeiro. O conteúdo do ficheiro é recuperado da nuvem como uma atividade em segundo plano para o servidor com base no mapa de calor, que recupera mais rapidamente os dados acedidos recentemente. Se o espaço livre no volume do servidor for inferior a 10%, os arquivos restantes permanecerão em camadas.	Somente o namespace (estrutura de arquivos e pastas) é baixado. Nenhum conteúdo de arquivo é trazido para o servidor.	Baixa cada arquivo em sua totalidade antes que o arquivo apareça na pasta no servidor. Essa opção evita que um arquivo hierárquico exista no servidor. Um item de namespace e o conteúdo do arquivo estão sempre presentes ao mesmo tempo.
Configurações padrão	Padrão se a hierarquização na nuvem não estiver ativada para este endpoint de servidor.	Padrão se a hierarquização na nuvem estiver habilitada para esse ponto de extremidade do servidor.	Não selecionado como uma opção padrão. Esta opção só está disponível quando a hierarquização na nuvem não está ativada.
Comportamento quando a hierarquização está habilitada	Quando a hierarquização na nuvem estiver ativada, a recuperação em segundo plano dos arquivos hierárquicos será interrompida assim que atender aos critérios da política de hierarquização de nuvem especificada (respeita a política livre de volume e a política de data também, se houver).	Somente o namespace (estrutura de arquivos e pastas) é baixado. Nenhum conteúdo de arquivo é trazido para o servidor.	Opção não disponível.
Comportamento quando a hierarquização não está habilitada	Quando a hierarquização na nuvem não está habilitada, a intenção é recuperar todos os dados para o ponto de extremidade do servidor por meio da recuperação em segundo plano. Você precisaria provisionar um volume grande o suficiente para acomodar todos os dados. Se o volume não tiver espaço livre suficiente, alguns arquivos serão deixados como hierárquicos mesmo quando a hierarquização na nuvem estiver desativada.	Somente o namespace (estrutura de arquivos e pastas) é baixado. Nenhum conteúdo de arquivo é trazido para o servidor.	Baixa cada arquivo em sua totalidade antes que o arquivo apareça na pasta no servidor.
Quando utilizar	Quando os utilizadores precisam de acesso rápido a ficheiros recentes logo após o namespace ser descarregado, e a maioria dos dados está presente na partilha de ficheiros do Azure no momento do provisionamento. Os clientes com baixa largura de banda também podem se beneficiar do recall em segundo plano após o provisionamento inicial. Para mais detalhes sobre a recuperação de ficheiros em camadas, veja How to manage Azure File Sync layered files. Mais indicado para cenários de recuperação de desastres do lado do servidor Azure File Sync, onde o caminho do servidor começa como uma pasta vazia, por exemplo, um novo endpoint de servidor numa agência filial.	Ideal para aplicativos que precisam recuperar dados com menos frequência ou apenas uma pequena quantidade de dados sob demanda.	Quando todos os dados devem estar sempre disponíveis localmente sem depender de hierarquização. Ideal para aplicações que requerem acesso a todos os ficheiros em todos os momentos. Útil em servidores de baixa largura de banda onde não queremos arquivos hierárquicos para problemas de desempenho de acesso a dados.
Implicações	A CPU/memória deve ser dimensionada com base na escala do namespace e no recurso necessário para evitar problemas de desempenho de E/S. Para detalhes, veja Recursos do Sistema Recomendados para Azure File Sync	-	O volume deve ter espaço suficiente para armazenar todos os dados. O download inicial provavelmente levará muito mais tempo devido à necessidade de baixar todo o conteúdo do arquivo. Não é adequado para recuperação rápida de desastres, pois é mais lento do que as duas primeiras opções.

Depois de selecionar uma opção de download inicial, não é possível alterá-la depois de confirmar a criação do ponto de extremidade do servidor.

Nota

Ao adicionar um endpoint servidor e os ficheiros existem na partilha de ficheiros do Azure, se optar por descarregar primeiro o namespace, os ficheiros aparecerão como escalonados até serem descarregados localmente. Os arquivos são baixados usando um único thread por padrão para limitar o uso da largura de banda da rede. Para melhorar o desempenho do download de arquivos, use o cmdlet Invoke-StorageSyncFileRecall com uma contagem de threads maior que 1.

Comportamento de download de arquivo após a conclusão do download inicial

A forma como os ficheiros aparecem no servidor após a conclusão da transferência inicial depende da sua utilização da funcionalidade de hierarquização na nuvem e de ter ou não optado por recuperar proativamente as alterações na nuvem. Este último é um recurso útil para grupos de sincronização com vários pontos finais de servidor em diferentes localizações geográficas.

A hierarquização na nuvem está ativada
Arquivos novos e alterados de outros pontos de extremidade do servidor aparecerão como arquivos hierárquicos nesse ponto de extremidade do servidor. Estas alterações só serão transferidas como ficheiros completos se optou por recall proativo das alterações na partilha de ficheiros do Azure por outros endpoints de servidor.
A hierarquização na nuvem está desativada
Arquivos novos e alterados de outros pontos de extremidade do servidor aparecerão como arquivos completos nesse ponto de extremidade do servidor. Eles não aparecerão como arquivos hierárquicos primeiro e depois recuperados. Os arquivos hierárquicos com hierarquização na nuvem são um recurso rápido de recuperação de desastres e aparecem apenas durante o provisionamento inicial.

Etapas de provisionamento

Quando um novo ponto de extremidade do servidor é criado usando o portal ou o PowerShell, o ponto de extremidade do servidor não está pronto para ser usado imediatamente. Dependendo da quantidade de dados presentes no compartilhamento de arquivos correspondente na nuvem, pode levar alguns minutos a horas para que o ponto de extremidade do servidor esteja funcional e pronto para uso.

No passado, se você quisesse verificar o status do status de provisionamento do ponto de extremidade do servidor e se o servidor está pronto para os usuários acessarem os dados, era necessário fazer login no ponto de extremidade do servidor e ver se todos os dados tinham sido baixados. Com os passos de provisionamento, pode perceber se um endpoint do servidor está pronto a usar ou não e se a sincronização está totalmente funcional diretamente do portal do Azure, no painel de visão geral do endpoint do servidor.

Para cenários com suporte, a guia Etapas de provisionamento fornece informações sobre o que está acontecendo no ponto de extremidade do servidor, incluindo quando o ponto de extremidade do servidor está pronto para acesso do usuário.

Cenários suportados

Atualmente, as etapas de provisionamento só são exibidas quando o novo ponto de extremidade do servidor adicionado não possui dados no caminho selecionado para esse ponto de extremidade. Em outros cenários, a guia Etapas de provisionamento não está disponível.

Status de provisionamento

Aqui estão os diferentes estados que são apresentados quando o provisionamento do endpoint do servidor está em andamento e qual o seu significado:

Em progresso: o ponto de extremidade do servidor não está pronto para acesso do usuário.
Pronto (sincronização não funcional): os usuários podem acessar dados, mas as alterações não serão sincronizadas com o compartilhamento de arquivos na nuvem.
Pronto (sincronização funcional): os usuários podem acessar dados e as alterações serão sincronizadas com o compartilhamento de nuvem, tornando o endpoint totalmente funcional.
Falha: Falha no provisionamento devido a um erro.

O separador de passos de provisionamento só é visível no portal do Azure para cenários suportados. Ele não estará disponível ou visível para cenários sem suporte.

Próximos passos

Há mais para descobrir sobre partilhas de ficheiros no Azure e Azure File Sync. Os artigos seguintes vão ajudá-lo a compreender opções avançadas, boas práticas e resolução de problemas.

Visão geral da migração
Planear a implantação do Azure File Sync
Criar uma partilha de ficheiros
Resolução de problemas Azure File Sync

Comentários

Esta página foi útil?

Last updated on 2026-04-09

Partilhar via

Criar um endpoint de servidor Azure File Sync

Prerequisites

Criar um ponto final de servidor

Seção de tierização na nuvem

Seção de sincronização inicial

Seção de download inicial

Comportamento de download de arquivo após a conclusão do download inicial

Etapas de provisionamento

Cenários suportados

Status de provisionamento

Próximos passos

Comentários

Recursos adicionais