Perguntas frequentes sobre o Azure Files

  • Artigo

Os Arquivos do Azure oferecem compartilhamentos de arquivos totalmente gerenciados na nuvem que são acessíveis por meio do Protocolo SMB e do protocolo NFS (Network File System) padrão do setor. Você pode montar compartilhamentos de arquivos do Azure simultaneamente em implantações locais ou na nuvem do Windows, do Linux e do macOS. Também é possível armazenar em cache os compartilhamentos de arquivos do Azure em computadores Windows Server usando a Sincronização de Arquivos do Azure para acesso rápido próximo ao local em que os dados são usados.

Sincronização de Arquivos do Azure

  • É possível ter servidores conectados e não conectados ao domínio no mesmo grupo de sincronização?
    Sim. Um grupo de sincronização pode conter pontos de extremidade de servidor com diferentes associações do Active Directory, mesmo que eles não estejam conectados ao domínio. Embora essa configuração funcione tecnicamente, não a recomendamos como uma configuração típica, pois as ACLs (listas de controle de acesso) que são definidas para arquivos e pastas em um servidor podem não ser impostas por outros servidores no grupo de sincronização. Para obter melhores resultados, recomendamos a sincronização entre servidores que estão na mesma floresta do Active Directory, entre servidores que estão em florestas diferentes do Active Directory, mas que estabeleceram relações de confiança, ou entre servidores que não estão em um domínio. Recomendamos que você evite usar uma mistura dessas configurações.

  • Se eu criar um arquivo diretamente em meu compartilhamento de arquivo do Azure usando o SMB ou no portal, quanto tempo levará para que o arquivo seja sincronizado com os servidores no grupo de sincronização?

    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 sincronizar imediatamente os arquivos alterados no compartilhamento de arquivo do Azure, o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser usado para iniciar manualmente a detecção de alterações no compartilhamento de arquivo do Azure. Esse cmdlet pode ser usado em cenários em que algum tipo de processo automatizado faz alterações no compartilhamento de arquivo do Azure ou as alterações são feitas por um administrador (como mover arquivos e diretórios para o compartilhamento). Para alterações de usuário final, a recomendação é instalar o agente de Sincronização de Arquivos do Azure em uma VM IaaS e permitir que os usuários finais acessem o compartilhamento de arquivos por meio da VM IaaS. Dessa forma, todas as alterações serão rapidamente sincronizadas com outros agentes sem a necessidade de usar o cmdlet Invoke-AzStorageSyncChangeDetection. Para saber mais, confira a documentação Invoke-AzStorageSyncChangeDetection.

    Estamos explorando adicionar detecção de alteração para um compartilhamento de arquivos do Azure semelhante ao USN para volumes no Windows Server. Ajude-nos a priorizar esse recurso para desenvolvimento futuro votando nele em Feedback da Comunidade do Azure.

  • Se o mesmo arquivo é alterado em dois servidores quase ao mesmo tempo, o que acontece?
    Os conflitos de arquivo são criados quando o arquivo no compartilhamento de arquivos do Azure não corresponde ao arquivo no local do ponto de extremidade do servidor (o tamanho e/ou a hora da última modificação é diferente).

    Os seguintes cenários podem causar conflitos de arquivo:

    • Um arquivo é criado ou modificado em um ponto de extremidade (por exemplo, Servidor A). Se o mesmo arquivo for modificado em um ponto de extremidade diferente antes da alteração no Servidor A ser sincronizada com esse ponto de extremidade, um arquivo de conflito será criado.
    • O arquivo existia no compartilhamento de arquivos do Azure e no local do ponto de extremidade do servidor antes da criação do ponto de extremidade do servidor. Se o tamanho do arquivo e/ou a hora da última modificação for diferente entre o arquivo no servidor e o compartilhamento de arquivos do Azure quando o ponto de extremidade do servidor for criado, um arquivo de conflito será criado.
    • O banco de dados de sincronização foi recriado devido à corrupção ou devido ao limite de conhecimento ter sido alcançado. Depois que o banco de dados é recriado, a sincronização entra em um modo chamado reconciliação. Se o tamanho do arquivo e/ou a hora da última modificação for diferente entre o arquivo no servidor e o compartilhamento de arquivos do Azure quando ocorrer a reconciliação, um arquivo de conflito será criado.

    A Sincronização de Arquivos do Azure usa uma estratégia simples de resolução de conflitos: mantemos ambas as alterações nos arquivos que são alterados em dois pontos de extremidade ao mesmo tempo. A alteração gravada mais recentemente mantém o nome do arquivo original. O arquivo mais antigo (determinado por LastWriteTime) tem o nome do ponto de extremidade e o número de conflito acrescentado ao nome do arquivo. Para os pontos de extremidade de servidor, o nome do ponto de extremidade é o nome do servidor. Para os pontos de extremidade na nuvem, o nome do ponto de extremidade é Nuvem. O nome segue esta taxonomia:

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    Por exemplo, o primeiro conflito de CompanyReport.docx se tornaria CompanyReport-CentralServer.docx se CentralServer fosse o local em que a gravação mais antiga ocorreu. O segundo conflito seria nomeado CompanyReport-CentralServer-1.docx. A Sincronização de Arquivos do Azure suporta 100 arquivos de conflito por arquivo. Depois que o número máximo de arquivos em conflito for atingido, o arquivo não será sincronizado até que o número de arquivos em conflito seja menor que 100.

  • Minha camada de nuvem está desabilitada. Por que há arquivos em camadas na localização do ponto de extremidade de servidor?
    Há dois motivos pelos quais os arquivos em camadas podem existir na localização do ponto de extremidade de servidor:

    • Ao adicionar um novo ponto de extremidade de servidor a um grupo de sincronização existente, se você escolher a opção Recuperar namespace primeiro ou Recuperar somente namespace para o modo de download inicial, os arquivos serão exibidos como se estivessem em camadas até serem baixados localmente. Para evitar isso, selecione a opção evitar arquivos em camadas para o modo de download inicial. Para recuperar arquivos manualmente, use o cmdlet Invoke-StorageSyncFileRecall.

    • Se a camada de nuvem foi habilitada no ponto de extremidade de servidor e, depois, desabilitada, os arquivos permanecem em camadas até que sejam acessados.

  • Por que meus arquivos em camadas não estão mostrando miniaturas nem visualizações no Explorador de Arquivos do Windows?
    Para os arquivos em camadas, as miniaturas e as visualizações não estarão visíveis no ponto de extremidade de servidor. Esse comportamento é esperado, pois o recurso de cache de miniatura do Windows ignora intencionalmente a leitura de arquivos com o atributo offline. Com a camada de nuvem habilitada, a leitura de arquivos em camadas fará com que eles sejam baixados (uma nova recuperação).

    Esse comportamento não é específico da Sincronização de Arquivos do Azure. O Explorador de Arquivos do Windows exibe um "X cinza" em todos os arquivos que têm o atributo offline definido. Você verá o ícone X ao acessar arquivos via SMB. Para obter uma explicação detalhada desse comportamento, consulte Por que não consigo obter miniaturas para arquivos que estão marcados como offline?

    Caso tenha dúvidas sobre como gerenciar arquivos em camadas, confira Como gerenciar arquivos em camadas.

  • Por que os arquivos em camadas existem fora do namespace do ponto de extremidade de servidor?
    Antes do agente do Azure File Sync - Sincronização de Arquivos do Azure versão 3, o Azure File Sync bloqueava a movimentação de arquivos em camadas fora do ponto de extremidade do servidor, mas no mesmo volume que o ponto de extremidade do servidor. Operações de cópia, move arquivos não hierárquico e de em camadas para outros volumes foram afetados. O motivo para esse comportamento foi a suposição implícita de que o Explorador de Arquivos e outras APIs do Windows que têm essas operações de movimentação no mesmo volume são operações de renomeação (quase) instantâneas. Isso significa que move fará o Explorador de arquivos ou outros métodos de movimentação (como a linha de comando ou o PowerShell) pode parecer não estar respondendo enquanto a sincronização de arquivos do Azure recupera os dados da nuvem. A partir do agente do Azure File Sync versão 3.0.12.0 , o Azure File Sync permitirá que você mova um arquivo em camadas fora do ponto de extremidade do servidor. Evitamos os efeitos negativos mencionados anteriormente, permitindo que o arquivo em camadas exista como um arquivo em camadas fora do terminal do servidor e, em seguida, recuperando o arquivo em segundo plano. Isso significa que movimentações no mesmo volume são instantâneas e fazemos todo o trabalho para recuperar o arquivo no disco após a conclusão da movimentação.

  • Estou tendo um problema com a Sincronização de Arquivos do Azure no meu servidor (sincronização, camada de nuvem etc.). Devo remover e recriar o ponto de extremidade de servidor?

    Não: remover um ponto de extremidade do servidor não é como reiniciar um servidor! Remover e recriar o ponto de extremidade do servidor quase nunca é uma solução apropriada para corrigir problemas com sincronização, camadas de nuvem ou outros aspectos da Sincronização de Arquivos do Azure. Remover um endpoint do servidor é uma operação destrutiva. Isso pode resultar em perda de dados caso os arquivos em camadas existam fora do namespace do terminal do servidor. Confira Por que os arquivos em camadas existem fora do namespace do ponto de extremidade do servidor para saber mais. Ou pode resultar em arquivos inacessíveis para arquivos em camadas existentes no namespace do terminal do servidor. Esses problemas não serão resolvidos quando o endpoint do servidor for recriado. Arquivos em camadas podem existir em seu ponto de extremidade do servidor, mesmo se você nunca tiver habilitado nuvem em camadas. É por isso que recomendamos que você não remova o ponto de extremidade do servidor, a menos que queira parar de usar a Sincronização de Arquivos do Azure com essa pasta específica ou tenha sido explicitamente instruído a fazê-lo por um engenheiro da Microsoft. Para obter mais informações sobre remover pontos de extremidade do servidor, consulte remover um ponto de extremidade do servidor.

  • Posso mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos, uma assinatura ou um locatário do Microsoft Entra diferente?
    Sim, você pode mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos, uma assinatura ou um locatário do Microsoft Entra diferente. Depois de mover a conta de armazenamento ou o serviço de sincronização de armazenamento, é necessário permitir o acesso do aplicativo Microsoft.StorageSync à conta de armazenamento. Siga estas etapas:

    1. Entre no portal do Azure e selecione Controle de acesso (IAM) na navegação à esquerda.

    2. Selecione a guia Atribuições de função para listar os usuários e aplicativos (entidades de serviço) que têm acesso à sua conta de armazenamento.

    3. Verifique se Microsoft.StorageSync ou Serviço Híbrido Sincronização de Arquivos (nome do aplicativo antigo) aparece na lista com a função de Leitor e Acesso a Dados.

      Se o Microsoft.StorageSync ou o Serviço Híbrido de Sincronização de Arquivos do Azure não aparecer na lista, execute as seguintes etapas:

      • Selecione Adicionar.
      • No campo Função, selecione Leitor e Acesso a Dados.
      • No campo Selecionar, digite Microsoft.StorageSync, selecione a função e selecione Salvar.

      Observação

      Ao criar o ponto de extremidade na nuvem, o serviço de sincronização de armazenamento e a conta de armazenamento devem estar no mesmo locatário do Microsoft Entra. Depois que o ponto de extremidade na nuvem é criado, o serviço de sincronização de armazenamento e a conta de armazenamento podem ser movidos para diferentes locatários do Microsoft Entra.

  • A Sincronização de Arquivos do Azure preserva as ACLs do NTFS no nível de diretório/arquivo, juntamente com os dados armazenados nos Arquivos do Azure?

    A partir de 24 de fevereiro de 2020, as ACLs novas e existentes colocadas em camadas pela Sincronização de Arquivos do Azure serão persistidas no formato NTFS e as modificações de ACL feitas diretamente no Compartilhamento de Arquivos do Azure serão sincronizadas em todos os servidores no grupo de sincronização. As alterações nas ACLs feitas nos Arquivos do Azure serão sincronizadas por meio da Sincronização de Arquivos do Azure. Ao copiar dados para os Arquivos do Azure, use uma ferramenta de cópia que dê suporte à "fidelidade" necessária para copiar atributos, carimbos de data/hora e ACLs em um compartilhamento de arquivo do Azure, via SMB ou REST. Ao usar as ferramentas de cópia do Azure, como o AzCopy, é importante usar a última versão. Verifique a tabela de ferramentas de cópia de arquivo para obter uma visão geral das ferramentas de cópia do Azure e garantir a cópia de todos os metadados importantes de um arquivo.

    Se você tiver habilitado o Backup do Azure nos compartilhamentos de arquivo gerenciados da Sincronização de Arquivos do Azure, as ACLs de arquivo poderão continuar a ser restauradas durante o fluxo de trabalho de restauração de backup. Isso funciona para todo o compartilhamento ou arquivos/diretórios individuais.

    Se estiver usando instantâneos como parte da solução de backup autogerenciado para compartilhamentos de arquivos gerenciados pela Sincronização de Arquivos do Azure, suas ACLs poderão ser restauradas incorretamente para ACLs NTFS se os instantâneos tiverem sido obtidos antes de 24 de fevereiro de 2020. Se isso ocorrer, você pode entrar em contato com o Suporte do Azure.

  • A Sincronização de Arquivos do Azure sincroniza o LastWriteTime para diretórios? Por que o carimbo de data e hora de modificação em um diretório não é atualizado quando os arquivos dentro dele são alterados?
    Não, a Sincronização de Arquivos do Azure não sincroniza o LastWriteTime para os diretórios. Além disso, o Arquivos do Azure não atualiza o carimbo de data e hora da modificação (LastWriteTime) para diretórios quando os arquivos dentro do diretório são alterados. Este comportamento é esperado.

Segurança, autenticação e controle de acesso

  • Como posso auditar o acesso aos arquivos e às alterações nos Arquivos do Azure?

    Há duas opções que fornecem funcionalidade de auditoria para os Arquivos do Azure:

    • Se os usuários estiverem acessando diretamente o compartilhamento de arquivos Azure, você pode usar os logs do Armazenamento do Microsoft Azure para rastrear as mudanças nos arquivos e o acesso do usuário para fins de solução de problemas. As solicitações são registradas em uma base de melhor esforço.
    • Se os usuários estiverem acessando o compartilhamento de arquivo do Azure por meio de um Windows Server com o agente de Sincronização de Arquivos do Azure instalado, use uma política de auditoria ou um produto de terceiros para controlar as alterações de arquivos e o acesso do usuário no Windows Server.

  • Os Arquivos do Azure dão suporte ao uso ABE (Access-Based Enumeração) para controlar a visibilidade dos arquivos e pastas nos compartilhamentos de arquivos do Azure SMB?

    Atualmente, o uso da ABE com Arquivos do Azure não tem suporte, mas você pode usar DFS-N com compartilhamentos de arquivos SMB do Azure.

Autenticação baseada em identidade

  • O Microsoft Entra Domain Services dá suporte ao acesso SMB usando as credenciais do Microsoft Entra de dispositivos ingressados ou registrados com o Microsoft Entra ID?

    Não, não há suporte para esse cenário.

  • Posso usar o nome canônico (CNAME) para montar um compartilhamento de arquivos do Azure enquanto uso a autenticação baseada em identidade?

    Sim, agora há suporte para esse cenário em ambientes de floresta única e de várias florestas para compartilhamentos de arquivos SMB do Azure. No entanto, os Arquivos do Azure só dão suporte à configuração do CNAMES usando o nome da conta de armazenamento como um prefixo de domínio. Se você não quiser usar o nome da conta de armazenamento como prefixo, considere o uso de Namepaces DFS.

  • Posso acessar compartilhamentos de arquivo do Azure com credenciais do Microsoft Entra de uma VM em uma assinatura diferente?

    Se a assinatura sob a qual o compartilhamento de arquivos foi implantado estiver associada ao mesmo locatário do Microsoft Entra como a implantação do Microsoft Entra Domain Services para o qual a VM ingressou no domínio, você poderá acessar os compartilhamentos de arquivos do Azure usando as mesmas credenciais do Microsoft Entra. A limitação é imposta não na assinatura, mas no locatário associado do Microsoft Entra.

  • Posso habilitar o Microsoft Entra Domain Services ou a autenticação de AD DS local para compartilhamentos de arquivos do Azure usando um locatário do Microsoft Entra que seja diferente do locatário principal do compartilhamento de arquivos do Azure?

    Não. Os Arquivos do Azure só oferecem suporte à integração do Microsoft Entra Domain Services ou do AD DS local com um locatário do Microsoft Entra que reside na mesma assinatura do compartilhamento de arquivos. Uma assinatura só pode ser associada a um locatário do Microsoft Entra. Ao usar AD DS locais para autenticação, a credencial do AD DS deve ser sincronizada com o Microsoft Entra ID ao qual a conta de armazenamento está associada.

  • A autenticação do AD DS local para compartilhamentos de arquivo do Azure dá suporte à integração a um ambiente do AD DS usando várias florestas?

    A autenticação do AD DS local dos Arquivos do Azure se integra apenas com a floresta do serviço de domínio em que a conta de armazenamento está registrada. Para dar suporte à autenticação de outra floresta, seu ambiente precisar ter uma relação de confiança de floresta configurada corretamente. Para ver instruções detalhadas, confira Usar os Arquivos do Azure com várias florestas do Active Directory.

    Observação

    Em uma configuração de várias florestas, não use o Explorador de Arquivos do Windows para configurar permissões de ACLs/NTFS do Windows no nível raiz, do diretório ou do arquivo. Em vez disso,use icacls.

  • Há alguma diferença na criação de uma conta de computador ou de conta de logon de serviço para representar minha conta de armazenamento no AD?

    Não há diferença entre criar uma conta de computador (padrão) ou uma conta de logon de serviço quanto ao funcionamento da autenticação com os Arquivos do Azure. Você pode escolher como representar uma conta de armazenamento como uma identidade em seu ambiente do AD. A configuração DomainAccountType padrão no cmdlet Join-AzStorageAccountForAuth é uma conta de computador. No entanto, o tempo de expiração de senha configurado em seu ambiente AD para contas de computador ou de logon de serviço pode ser diferente e você precisa levar isso em consideração para Atualizar a senha da sua identidade de conta de armazenamento no AD.

  • Como remover as credenciais armazenadas em cache com a chave da conta de armazenamento e excluir as conexões SMB existentes antes de inicializar uma nova conexão com as credenciais do Microsoft Entra ID ou do AD?

    Siga o processo de duas etapas abaixo para remover a credencial salva associada à chave da conta de armazenamento e remover a conexão SMB:

    1. Execute o comando a seguir em um prompt de comando do Windows para remover a credencial. Se você não encontrar nenhuma, isso indicará que você não persistiu a credencial e poderá ignorar esta etapa.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Exclua a conexão existente com o compartilhamento de arquivo. Você pode especificar o caminho de montagem como a letra da unidade montada ou o caminho storage-account-name.file.core.windows.net.

      net use <letra-da-unidade/caminho-do-compartilhamento> /delete

  • É possível exibir o UPN (userPrincipalName) de um proprietário de arquivo/diretório no Explorador de Arquivos em vez do SID (identificador de segurança)?

    O Explorador de Arquivos chama uma API RPC diretamente para o servidor (Arquivos do Azure) para traduzir o SID em um UPN. Os Arquivos do Azure não dão suporte para essa API, portanto, no Explorador de Arquivos, o SID do proprietário de um arquivo/diretório é exibido em vez do UPN para arquivos e diretórios hospedados nos Arquivos do Azure. No entanto, a partir de um cliente ingressado no domínio, você pode usar o seguinte comando do PowerShell para exibir todos os itens em um diretório e seu proprietário, incluindo o UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

NFS v4.1 (Sistema de arquivos de rede)

Instantâneos de compartilhamento

Criar instantâneos de compartilhamento

  • Meus instantâneos de compartilhamento têm redundância geográfica?
    O instantâneo de compartilhamento tem a mesma redundância que o compartilhamento de arquivos do Azure para o qual ele foi criado. Caso tenha selecionado o armazenamento com redundância geográfica para sua conta, o instantâneo de compartilhamento também será armazenado de forma redundante na região emparelhada.

Limpar instantâneos de compartilhamento

  • Posso excluir meu compartilhamento sem excluir os instantâneos de compartilhamento?
    Caso tenha instantâneos de compartilhamento ativos no compartilhamento, não será possível excluí-lo. Você pode usar uma API para excluir compartilhamentos de instantâneos, juntamente com o compartilhamento. Você também pode excluir os instantâneos de compartilhamento e o compartilhamento no Portal do Azure.

Cobrança e preços

  • O que são transações nos Arquivos do Azure e como elas são cobradas? As transações de protocolo ocorrem sempre que um usuário, um aplicativo, um script ou um serviço interage com compartilhamentos de arquivos do Azure (gravação, leitura, listagem, exclusão de arquivos etc.). É importante lembrar que algumas ações que você percebe como uma só operação, na verdade podem envolver várias transações. Para compartilhamentos de arquivo Standard do Azure cobrados em um modelo pago conforme o uso, diferentes tipos de transações têm preços diferentes com base no impacto no compartilhamento de arquivo. As transações não afetam a cobrança de compartilhamentos de arquivo Premium, que são cobrados usando um modelo provisionado. Para obter mais informações, confira Noções básicas sobre cobrança.

  • Qual é o valor dos instantâneos de compartilhamento?
    Os instantâneos de compartilhamento são incrementais por natureza. O instantâneo de compartilhamento base é o próprio compartilhamento. Todos os instantâneos de compartilhamento subsequentes são incrementais e armazenam somente a diferença do instantâneo de compartilhamento anterior. Você será cobrado somente pelo conteúdo alterado. Se você tiver um compartilhamento com 100 GiB de dados, mas apenas 5 GiB foram alterados após o último instantâneo de compartilhamento, este consumirá apenas 5 GiB adicionais e você será cobrado por 105 GiB. Para obter mais informações sobre encargos de transações e de saída Standard, consulte a Página de preços.

Interoperabilidade com outros serviços

  • É possível usar o compartilhamento de arquivos do Azure como uma Testemunha de Compartilhamento de Arquivos para o Cluster de Failover do Windows Server?
    Atualmente, não há suporte para essa configuração para Arquivos do Azure. Para saber como configurar isso para o Armazenamento de Blobs do Azure, confira Implantar uma testemunha de nuvem em um cluster de failover.

Confira também