Perguntas frequentes sobre os Arquivos do Azure e a Sincronização de Arquivos do Azure

  • Artigo

O Azure Files oferece compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio do protocolo SMB (Server Message Block) padrão do setor e do protocolo NFS (Network File System). Você pode montar compartilhamentos de arquivos do Azure simultaneamente em implantações na nuvem ou locais do Windows, Linux e macOS. Você também pode armazenar em cache compartilhamentos de arquivos do Azure em máquinas Windows Server usando a Sincronização de Arquivos do Azure para acesso rápido perto de onde os dados são usados.

Azure File Sync

  • Posso ter servidores que ingressaram e não ingressaram no 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 ao Ative Directory, mesmo que não tenham ingressado no domínio. Embora essa configuração funcione tecnicamente, não recomendamos isso como uma configuração típica porque as listas de controle de acesso (ACLs) 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 Ative Directory, entre servidores que estão em florestas diferentes do Ative Directory, mas estabeleceram relações de confiança, ou entre servidores que não estão em um domínio. Recomendamos que você evite usar uma combinação dessas configurações.

  • Criei um arquivo diretamente no meu compartilhamento de arquivos do Azure usando o SMB ou no portal. Quanto tempo leva para o arquivo ser sincronizado com os servidores do grupo de sincronização?

    As alterações efetuadas à partilha de ficheiros do Azure no portal do Azure ou SMB não são imediatamente detetadas e replicadas como alterações ao ponto final do servidor. Os Ficheiros do Azure ainda não têm notificações de alteração ou diário, pelo que não é possível iniciar automaticamente uma sessão de sincronização quando os ficheiros são alterados. No Windows Server, o Azure File Sync utiliza o diário USN do Windows para iniciar automaticamente uma sessão de sincronização quando os ficheiros são alterados.

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

    Para sincronizar imediatamente os ficheiros que são alterados na partilha de ficheiros do Azure, o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser utilizado para iniciar manualmente a deteção de alterações na partilha de ficheiros do Azure. Este cmdlet destina-se a cenários em que algum tipo de processo automatizado está fazendo alterações no compartilhamento de arquivos 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 do Azure File Sync em uma VM IaaS e fazer com que os usuários finais acessem o compartilhamento de arquivos por meio da VM IaaS. Dessa forma, todas as alterações serão sincronizadas rapidamente com outros agentes sem a necessidade de usar o cmdlet Invoke-AzStorageSyncChangeDetection. Para saber mais, consulte a documentação Invoke-AzStorageSyncChangeDetection.

    Estamos explorando a adição de deteção de alterações 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 Comentários da Comunidade do Azure.

  • O que acontece se o mesmo ficheiro for alterado em dois servidores aproximadamente ao mesmo tempo?
    Os conflitos de ficheiros são criados quando o ficheiro na partilha de ficheiros do Azure não corresponde ao ficheiro na localização do ponto final do servidor (o tamanho e/ou a hora da última modificação é diferente).

    Os cenários a seguir podem causar conflitos de arquivo:

    • Um ficheiro é criado ou modificado num ponto final (por exemplo, Servidor A). Se o mesmo ficheiro for modificado num ponto final diferente antes de a alteração no Servidor A ser sincronizada com esse ponto final, é criado um ficheiro de conflito.
    • O ficheiro existia na partilha de ficheiros do Azure e na localização do ponto final do servidor antes da criação do ponto final do servidor. Se o tamanho do ficheiro e/ou a hora da última modificação for diferente entre o ficheiro no servidor e a partilha de ficheiros do Azure quando é criado o ponto final do servidor, é criado um ficheiro de conflito.
    • A base de dados de sincronização foi recriada devido a danos ou limite de conhecimento atingido. Assim que a base de dados for recriada, a sincronização entra num modo chamado reconciliação. Se o tamanho do ficheiro e/ou a hora da última modificação for diferente entre o ficheiro no servidor e a partilha de ficheiros do Azure quando ocorre a reconciliação, é criado um ficheiro de conflito.

    Quando o carregamento inicial para o compartilhamento de arquivos do Azure estiver concluído, a Sincronização de Arquivos do Azure não substituirá nenhum arquivo em seu grupo de sincronização. Em vez disso, ele usa uma estratégia simples de resolução de conflitos: mantém ambas as alterações em arquivos que são alterados em dois pontos de extremidade ao mesmo tempo. A alteração escrita mais recentemente mantém o nome de ficheiro original. O arquivo mais antigo (determinado por LastWriteTime) tem o nome do ponto de extremidade e o número do conflito anexados ao nome do arquivo. Para pontos finais do servidor, o nome do ponto final é o nome do servidor. Para pontos de extremidade de nuvem, o nome do ponto de extremidade é Cloud. O nome segue esta taxonomia:

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

    Por exemplo, o primeiro conflito de CompanyReport.docx tornar-se-ia CompanyReport-CentralServer.docx se CentralServer for a localização onde ocorreu a escrita mais antiga. O segundo conflito seria denominado CompanyReport-CentralServer-1.docx. O Azure File Sync suporta 100 ficheiros de conflito por ficheiro. Assim que o número máximo de ficheiros em conflito for atingido, o ficheiro não será sincronizado até que o número de ficheiros em conflito seja inferior a 100.

  • Tenho a hierarquização na nuvem desativada, por que há arquivos em camadas no local do ponto de extremidade do servidor?
    Há duas razões pelas quais os arquivos hierárquicos podem existir no local do ponto de extremidade do 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 namespace somente para o modo de download inicial, os arquivos aparecerão como hierárquicos até que sejam baixados localmente. Para evitar isso, selecione a opção evitar arquivos hierárquicos para o modo de download inicial. Para recuperar arquivos manualmente, use o Invoke-StorageSyncFileRecall cmdlet.

    • Se a hierarquização na nuvem tiver sido ativada no ponto de extremidade do servidor e, em seguida, desativada, os arquivos permanecerão hierarquizados até serem acessados.

  • Porque é que os meus ficheiros hierárquicos não mostram miniaturas ou pré-visualizações no Explorador de Ficheiros do Windows?
    Para arquivos hierárquicos, miniaturas e visualizações não serão visíveis no ponto de extremidade do servidor. Esse comportamento é esperado porque o recurso de cache de miniaturas no Windows ignora intencionalmente a leitura de arquivos com o atributo offline. Com o Cloud Tiering ativado, a leitura de arquivos em camadas faria com que eles fossem baixados (lembrados).

    Esse comportamento não é específico do Azure File Sync. O Explorador de Ficheiros do Windows apresenta um "X cinzento" para todos os ficheiros que tenham o atributo offline definido. Você verá o ícone X ao acessar arquivos pelo SMB. Para obter uma explicação detalhada desse comportamento, consulte Por que não obtenho miniaturas para arquivos marcados como offline?

    Para perguntas sobre como gerenciar arquivos hierárquicos, consulte Como gerenciar arquivos hierárquicos.

  • Por que os arquivos hierárquicos existem fora do namespace do ponto de extremidade do servidor?
    Antes do agente do Azure File Sync versão 3, o Azure File Sync bloqueava a movimentação de arquivos hierárquicos fora do ponto de extremidade do servidor, mas no mesmo volume que o ponto de extremidade do servidor. As operações de cópia, as movimentações de arquivos não hierárquicos e as movimentações de arquivos hierárquicos para outros volumes não foram afetadas. A razão para esse comportamento foi a suposição implícita de que o Explorador de Arquivos e outras APIs do Windows têm que mover operações no mesmo volume são operações de renomeação (quase) instantâneas. Isso significa que as movimentações farão com que o Explorador de Arquivos ou outros métodos de movimentação (como linha de comando ou PowerShell) pareçam não responder enquanto o Azure File Sync recupera os dados da nuvem. A partir da versão 3.0.12.0 do agente do Azure File Sync, o Azure File Sync permitirá que você mova um arquivo hierárquico para 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 ponto de extremidade do servidor e, em seguida, recuperando o arquivo em segundo plano. Isso significa que as movimentações no mesmo volume são instantâneas e fazemos todo o trabalho para recuperar o arquivo para o disco após a conclusão da movimentação.

  • Estou a ter um problema com a Sincronização de Ficheiros do Azure no meu servidor (sincronização, hierarquização na nuvem, etc.). Devo remover e recriar meu ponto de extremidade do 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, hierarquização na nuvem ou outros aspetos da Sincronização de Arquivos do Azure. Remover um ponto de extremidade do servidor é uma operação destrutiva. Isso pode resultar em perda de dados no caso de existirem arquivos em camadas fora do namespace do ponto de extremidade do servidor. Para obter mais informações, consulte Por que os arquivos hierárquicos existem fora do namespace do ponto de extremidade do servidor para obter mais informações. Ou pode resultar em arquivos inacessíveis para arquivos hierárquicos que existem dentro do namespace do ponto de extremidade do servidor. Esses problemas não serão resolvidos quando o ponto de extremidade do servidor for recriado. Arquivos hierárquicos podem existir no namespace do ponto de extremidade do servidor, mesmo que você nunca tenha habilitado a hierarquização na nuvem. É por isso que recomendamos que você não remova o ponto de extremidade do servidor, a menos que deseje parar de usar o Azure File Sync 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 como 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 diferente, uma assinatura ou um locatário do Microsoft Entra?
    Sim, você pode mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos diferente, assinatura ou locatário do Microsoft Entra. Depois de mover o serviço de sincronização de armazenamento ou a conta de armazenamento, você precisa conceder ao aplicativo Microsoft.StorageSync acesso à conta de armazenamento. Siga estes passos:

    1. Entre no portal do Azure e selecione Controle de acesso (IAM) no menu de serviço.

    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 de Sincronização de Ficheiros Híbridos (nome antigo da aplicação) aparece na lista com a função Acesso de Dados e Leitor.

      Se Microsoft.StorageSync ou Hybrid File Sync Service não aparecer na lista, execute as seguintes etapas:

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

      Nota

      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.

  • O Azure File Sync preserva ACLs NTFS de nível de diretório/arquivo junto com os dados armazenados nos Arquivos do Azure?

    A partir de 24 de fevereiro de 2020, as ACLs novas e existentes hierarquizadas pela sincronização de arquivos do Azure serão mantidas no formato NTFS e as modificações de ACL feitas diretamente no compartilhamento de arquivos do Azure serão sincronizadas com todos os servidores no grupo de sincronização. Quaisquer alterações em ACLs feitas em compartilhamentos de arquivos do Azure serão sincronizadas por meio da Sincronização de Arquivos do Azure. Ao copiar dados para os Arquivos do Azure, certifique-se de usar uma ferramenta de cópia que ofereça suporte à "fidelidade" necessária para copiar atributos, carimbos de data/hora e ACLs em um compartilhamento de arquivos do Azure - via SMB ou REST. Ao usar ferramentas de cópia do Azure, como AzCopy, é importante usar a versão mais recente. Verifique a tabela de ferramentas de cópia de arquivo para obter uma visão geral das ferramentas de cópia do Azure para garantir que você possa copiar todos os metadados importantes de um arquivo.

    Se você habilitou o Backup do Azure em seus compartilhamentos de arquivos gerenciados do Azure File Sync, as ACLs de arquivo podem continuar a ser restauradas como parte do fluxo de trabalho de restauração de backup. Isso funciona para todo o compartilhamento ou arquivos/diretórios individuais.

    Se você estiver usando instantâneos como parte da solução de backup autogerenciado para compartilhamentos de arquivos gerenciados pelo Azure File Sync, suas ACLs podem não ser restauradas corretamente para ACLs NTFS se os instantâneos tiverem sido tirados antes de 24 de fevereiro de 2020. Se isso ocorrer, considere entrar em contato com o Suporte do Azure.

  • O Azure File Sync sincroniza o LastWriteTime para diretórios? Por que o carimbo de data/hora modificado em um diretório não é atualizado quando os arquivos dentro dele são alterados?
    Não, o Azure File Sync não sincroniza o LastWriteTime para diretórios. Além disso, os Arquivos do Azure não atualizam o carimbo de data/ hora modificado (LastWriteTime) para diretórios quando os arquivos dentro do diretório são alterados. Este comportamento está previsto.

  • Porque é que o software antivírus no servidor AFS está a recuperar ficheiros em camadas?
    Quando os utilizadores acedem a ficheiros em camadas, alguns softwares antivírus (AV) podem causar recuperações não intencionais de ficheiros. Isso ocorre se o software AV não estiver configurado para ignorar arquivos hierárquicos (aqueles com o atributo RECALL_ON_DATA_ACCESS). Veja o que acontece:

    1. Um usuário tenta acessar um arquivo em camadas.
    2. O software AV bloqueia a alça de leitura.
    3. Em seguida, o aplicativo AV executa sua própria leitura para verificar o arquivo em busca de vírus.

    Esse processo pode parecer como se o software AV estivesse recuperando os arquivos em camadas, mas na verdade é acionado pela tentativa de acesso do usuário. Para evitar esse problema, certifique-se de que seu fornecedor de AV configure seu software para ignorar a verificação de arquivos hierárquicos com o atributo RECALL_ON_DATA_ACCESS.

  • O software de inspeção SSL pode bloquear o acesso aos servidores AFS? Certifique-se de que o seu software de inspeção SSL (como Zscaler ou FortiGate) permite que os pontos finais do servidor Azure File Sync (AFS) acedam ao Azure. Essas ferramentas de inspeção SSL podem substituir as configurações do firewall e permitir o tráfego seletivamente. Entre em contato com o administrador da rede para resolver esse problema. Use o comando "testnet" para determinar se o servidor AFS está enfrentando esse problema.

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

  • Como posso auditar o acesso a arquivos e as alterações nos Arquivos do Azure?

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

    • Se os usuários estiverem acessando o compartilhamento de arquivos do Azure diretamente, você poderá usar os logs do Armazenamento do Azure para controlar as alterações de arquivos e o acesso do usuário para fins de solução de problemas. As solicitações são registradas com base no melhor esforço.
    • Se os usuários estiverem acessando o compartilhamento de arquivos do Azure por meio de um Windows Server que tenha 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 da Enumeração Baseada em Acesso (ABE) para controlar a visibilidade dos arquivos e pastas nos compartilhamentos de arquivos do Azure SMB?

    O uso do ABE com Arquivos do Azure não é suportado no momento, mas você pode usar o DFS-N com compartilhamentos de arquivos do Azure SMB.

Autenticação baseada em identidade

  • Os Serviços de Domínio do Microsoft Entra suportam o acesso SMB usando credenciais do Microsoft Entra de dispositivos associados ou registrados com o ID do Microsoft Entra?

    Não, este cenário não é suportado.

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

    Sim, esse cenário agora é suportado em ambientes de floresta única e de várias florestas para compartilhamentos de arquivos do Azure SMB. No entanto, os Arquivos do Azure só dão suporte à configuração de 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 um prefixo, considere usar Namespaces DFS .

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

    Se a assinatura sob a qual o compartilhamento de arquivos é implantado estiver associada ao mesmo locatário do Microsoft Entra que a implantação dos Serviços de Domínio Microsoft Entra na 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 não é imposta à assinatura, mas ao locatário associado do Microsoft Entra.

  • Posso habilitar os Serviços de Domínio do Microsoft Entra ou a autenticação do AD DS local para compartilhamentos de arquivos do Azure usando um locatário do Microsoft Entra diferente do locatário principal do compartilhamento de arquivos do Azure?

    N.º Os Arquivos do Azure dão suporte apenas aos Serviços de Domínio do Microsoft Entra ou à integração do AD DS local com um locatário do Microsoft Entra que reside na mesma assinatura que o compartilhamento de arquivos. Uma assinatura só pode ser associada a um locatário do Microsoft Entra. Ao usar o AD DS local para autenticação, a credencial do AD DS deve ser sincronizada com a ID do Microsoft Entra à qual a conta de armazenamento está associada.

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

    A autenticação do AD DS local dos Arquivos do Azure só se integra à floresta do serviço de domínio no qual a conta de armazenamento está registrada. Para dar suporte à autenticação de outra floresta, seu ambiente deve ter uma relação de confiança de floresta configurada corretamente. Para obter instruções detalhadas, consulte Usar arquivos do Azure com várias florestas do Ative Directory.

    Nota

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

  • Existe alguma diferença na criação de uma conta de computador ou de início de sessão de serviço para representar a minha conta de armazenamento no AD?

    Criar uma conta de computador (padrão) ou uma conta de logon de serviço não tem diferença em como a autenticação funciona com os Arquivos do Azure. Você pode fazer sua própria escolha sobre como representar uma conta de armazenamento como uma identidade em seu ambiente do AD. O DomainAccountType padrão definido no Join-AzStorageAccountForAuth cmdlet é conta de computador. No entanto, a idade de expiração da senha configurada em seu ambiente do AD pode ser diferente para contas de logon de computador ou serviço, e você precisa levar isso em consideração para Atualizar a senha da identidade da sua conta de armazenamento no AD.

  • Como remover credenciais armazenadas em cache com chave de conta de armazenamento e excluir conexões SMB existentes antes de inicializar nova conexão com credenciais do Microsoft Entra ID ou 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 seguinte comando a partir de um prompt de comando do Windows para remover a credencial. Se não conseguir encontrar uma, significa que não persistiu a credencial e pode ignorar este passo.

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

    2. Elimine a ligação existente à partilha de ficheiros. Você pode especificar o caminho de montagem como a letra da unidade montada ou o storage-account-name.file.core.windows.net caminho.

      net use <drive-letter/share-path> /delete

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

    O Explorador de Arquivos chama uma API RPC diretamente para o servidor (Arquivos do Azure) para traduzir o SID para um UPN. Os Arquivos do Azure não dão suporte a essa API, portanto, no Explorador de Arquivos, o SID de um proprietário de 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 UPN:

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

Sistema de arquivos de rede (NFS v4.1)

Compartilhar instantâneos

Criar instantâneos de partilha

  • Os meus snapshots de partilha são redundantes geograficamente?
    Os instantâneos de compartilhamento têm a mesma redundância que o compartilhamento de arquivos do Azure para o qual foram tirados. Se você selecionou armazenamento com redundância geográfica para sua conta, seu instantâneo de compartilhamento também será armazenado de forma redundante na região emparelhada.

Limpar instantâneos de compartilhamento

  • Posso excluir meu compartilhamento, mas não excluir meus instantâneos de compartilhamento?
    N.º O fluxo de trabalho de compartilhamento de arquivos de exclusão excluirá automaticamente os instantâneos quando você excluir o compartilhamento.

Faturação 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, aplicativo, script ou 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ê pode perceber como uma única operação podem, na verdade, envolver várias transações. Para compartilhamentos de arquivos padrão do Azure cobrados em um modelo de pagamento conforme o uso, diferentes tipos de transações têm preços diferentes com base em seu impacto no compartilhamento de arquivos. As transações não afetam o faturamento de compartilhamentos de arquivos premium, que são cobrados usando um modelo provisionado. Para obter mais informações, consulte Noções básicas sobre cobrança.

  • Quanto custam os snapshots compartilhados?
    Os instantâneos de compartilhamento são incrementais por natureza. O instantâneo de compartilhamento base é o próprio compartilhamento. Todos os snapshots de compartilhamento subsequentes são incrementais e armazenam apenas a diferença do instantâneo de compartilhamento anterior. Você será cobrado apenas pelo conteúdo alterado. Se você tiver um compartilhamento com 100 GiB de dados, mas apenas 5 GiB tiver sido alterado desde o último instantâneo de compartilhamento, o instantâneo de compartilhamento consome apenas 5 GiB adicionais e você será cobrado por 105 GiB. Para obter mais informações sobre transações e encargos de saída padrão, consulte a página Preços.

Interoperabilidade com outros serviços

  • Posso usar meu compartilhamento de arquivos do Azure como uma Testemunha de Compartilhamento de Arquivos para meu Cluster de Failover do Windows Server?
    Esta configuração não é suportada atualmente para os Arquivos do Azure. Para saber como configurar isso usando o armazenamento de Blob do Azure, consulte Implantar uma testemunha de nuvem para um cluster de failover.

Consulte também