Partilhar via

Replicação de objetos em blobs de blocos

A replicação de objetos copia blobs de bloco de forma assíncrona entre uma conta de armazenamento de origem e uma de destino. Alguns cenários suportados pela replicação de objetos incluem:

  • Minimização da latência. A replicação de objetos pode reduzir a latência de solicitações de leitura, permitindo que os clientes consumam dados de uma região que esteja mais próxima fisicamente.
  • Aumente a eficiência das cargas de trabalho de computação. Com a replicação de objetos, as cargas de trabalho de computação podem processar os mesmos conjuntos de blobs de bloco em diferentes regiões.
  • Otimização da distribuição de dados. Você pode processar ou analisar dados em um único local e, em seguida, replicar apenas os resultados para regiões extras.
  • Otimização de custos. Depois que os dados forem replicados, você poderá reduzir os custos movendo-os para a camada de arquivamento usando políticas de gerenciamento do ciclo de vida.

O diagrama a seguir mostra como a replicação de objetos efetua a replicação de blocos de blobs de uma conta de armazenamento de origem numa região para contas de armazenamento de destino em duas regiões diferentes.

Diagrama que mostra como funciona a replicação de objetos.

Para saber como configurar a replicação de objetos, consulte Configurar a replicação de objetos.

Pré-requisitos e advertências para replicação de objetos

A replicação de objetos requer que os seguintes recursos de Armazenamento do Azure também estejam habilitados:

Ativar o feed de alterações e o versionamento de blobs pode incorrer em custos adicionais. Para obter mais informações, consulte a página de preços do Armazenamento do Azure.

A replicação de objetos é suportada para contas de armazenamento v2 de uso geral e contas premium de blobs de blocos. As contas de origem e de destino devem ser contas v2 de uso geral ou contas premium de blocos de blobs. A replicação de objetos suporta apenas blobs de bloco; não há suporte para os blobs de acréscimo e os blobs de página.

A replicação de objetos é suportada para contas criptografadas com chaves gerenciadas pela Microsoft ou chaves gerenciadas pelo cliente. Para obter mais informações sobre chaves gerenciadas pelo cliente, consulte Chaves gerenciadas pelo cliente para criptografia do Armazenamento do Azure.

A replicação de objetos não é suportada para blobs na conta de origem que estão criptografados com uma chave fornecida pelo cliente. Para obter mais informações sobre chaves fornecidas pelo cliente, consulte Fornecer uma chave de criptografia em uma solicitação para armazenamento de Blob.

O failover gerido pelo cliente não é suportado nem para a conta de origem nem para a conta de destino numa política de replicação de objetos.

A replicação de objetos ainda não é suportada em contas que têm um namespace hierárquico habilitado.

A replicação de objetos não é suportada para blobs carregados usando APIs Data Lake Storage.

Como funciona a replicação de objetos

A replicação de objetos copia de forma assíncrona blobs de bloco em um contêiner de acordo com as regras que você configurar. O conteúdo do blob, todas as versões associadas ao blob e os metadados e propriedades do blob são copiados do contêiner de origem para o contêiner de destino.

Importante

Como os dados de blob de bloco são replicados de forma assíncrona, a conta de origem e a conta de destino não estão imediatamente sincronizadas.

O OR agora oferece suporte à replicação prioritária, que prioriza a replicação de todas as operações em uma política de OR. Quando a replicação de prioridade OR está ativada, o desempenho de replicação de todas as operações é melhorado. Quando a conta de origem e de destino de uma política de replicação está dentro do mesmo continente, a replicação prioritária de OR também replica 99,0% de objetos em 15 minutos para cargas de trabalho suportadas. O desempenho das funcionalidades é garantido através de um acordo de nível de serviço (SLA). Para obter mais informações, visite os termos do SLA e o artigo Prioridade de Replicação de Objetos.

Você também pode verificar o status da replicação no blob de origem para determinar se a replicação foi concluída. Para obter mais informações, consulte Verificar o status de replicação de um blob.

Controle de versão de Blob

A replicação de objetos requer que o controle de versão de blob esteja habilitado nas contas de origem e de destino. Quando um blob replicado na conta de origem é modificado, uma nova versão do blob é criada na conta de origem que reflete o estado anterior do blob, antes da modificação. A versão atual na conta de origem reflete as atualizações mais recentes. Tanto a versão atual quanto quaisquer versões anteriores são replicadas para a conta de destino. Para obter mais informações sobre como as operações de gravação afetam as versões de blob, consulte Versionamento em operações de gravação.

Se sua conta de armazenamento tiver políticas de replicação de objetos em vigor, não será possível desabilitar o controle de versão de blob para essa conta. Você deve excluir todas as políticas de replicação de objeto na conta antes de desabilitar o versionamento de blob.

Nota

Apenas os blobs são copiados para o destino. O ID de versão de um blob não é copiado. Depois que um blob é colocado no local de destino, um novo ID de versão é atribuído.

Eliminando um blob na conta de origem

Quando um blob na conta de origem é excluído, a versão atual do blob se torna uma versão anterior e não há mais uma versão atual. Todas as versões anteriores existentes do blob são preservadas. Esse estado é replicado para a conta de destino. Para obter mais informações sobre como as operações de eliminação afetam as versões de blob, consulte Versionamento em operações de eliminação.

Instantâneos

A replicação de objetos não oferece suporte a instantâneos de blocos de dados. Quaisquer instantâneos num blob da conta de origem não são replicados na conta de destino.

Tags de índice de Blob

A replicação de objetos não copia as tags de índice do blob de origem para o blob de destino.

Hierarquização de Blob

A replicação de objetos é suportada quando as contas de origem e de destino estão em qualquer camada online (quente, fria ou fria). As contas de origem e de destino podem estar em níveis diferentes. No entanto, a replicação de objetos falhará se um blob na conta de origem ou de destino for movido para a camada de arquivamento. Para obter mais informações sobre camadas de blob, consulte Camadas de acesso para dados de blob.

Blobs imutáveis

As políticas de imutabilidade para o Armazenamento de Blobs do Azure incluem políticas de retenção baseadas no tempo e retenções legais. Quando uma política de imutabilidade está em vigor na conta de destino, a replicação de objetos pode ser afetada. Para obter mais informações sobre políticas de imutabilidade, consulte Armazenamento Imutável para Dados de Blob Críticos para Negócios.

Se o contêiner de destino tiver uma política de imutabilidade no nível do contêiner em vigor, as alterações nos objetos no contêiner de origem, como atualizações ou exclusões, ainda poderão ser bem-sucedidas. No entanto, essas alterações podem não ser replicadas para o contêiner de destino devido à restrição de imutabilidade. Para obter mais informações sobre quais operações são proibidas com uma política de imutabilidade aplicável a um contentor, consulte Cenários com escopo ao nível do contentor.

Se a versão blob de uma conta de destino tiver uma política ativa de imutabilidade ao nível da versão, uma operação de eliminação ou atualização realizada na versão blob do contentor de origem correspondente pode ter sucesso. No entanto, a replicação dessa operação para o objeto de destino falha. Para obter mais informações sobre quais operações são proibidas com uma política de imutabilidade associada a um âmbito definido para um contentor, consulte Cenários com âmbito ao nível da versão.

Políticas e regras de replicação de objetos

Ao configurar a replicação de objetos, você cria uma política de replicação que especifica a conta de armazenamento de origem e a conta de destino. Uma política de replicação inclui uma ou mais regras que especificam um contêiner de origem e de destino e indicam quais blobs de origem são replicados.

Depois de configurar a replicação de objetos, o Armazenamento do Azure verifica periodicamente o feed de alterações da conta de origem e replica de forma assíncrona todas as operações de gravação ou exclusão para a conta de destino. A latência de replicação depende do tamanho do blob de bloco que está sendo replicado.

Políticas de replicação

Ao configurar a replicação de objetos, você cria uma política de replicação na conta de destino por meio do provedor de recursos de Armazenamento do Azure. Depois que a política de replicação é criada, o Armazenamento do Azure atribui a ela uma ID de política. Em seguida, você deve associar essa política de replicação à conta de origem usando a ID da política. O ID da política nas contas de origem e de destino deve ser o mesmo para que a replicação ocorra.

Uma conta de origem pode ser replicada, no máximo, em duas contas de destino, com uma política para cada conta de destino. Da mesma forma, uma conta pode servir como conta de destino para no máximo duas políticas de replicação.

As contas de origem e de destino podem estar na mesma região ou em regiões diferentes. Eles também podem residir na mesma assinatura ou em assinaturas diferentes. Opcionalmente, as contas de origem e de destino podem residir em diferentes locatários do Microsoft Entra. Apenas uma política de replicação pode ser criada para cada par de contas de origem/destino.

Regras de replicação

As regras de replicação especificam como o Armazenamento do Azure replica blobs de um contêiner de origem para um contêiner de destino. Você pode especificar até 1.000 regras de replicação para cada política de replicação. Cada regra de replicação define um único contêiner de origem e destino, e cada contêiner de origem e destino pode ser usado em apenas uma regra. Como resultado, um máximo de 1.000 contêineres de origem e 1.000 contêineres de destino podem participar de uma única política de replicação.

Depois de criar uma regra de replicação, os blobs preexistentes são ignorados; Somente novos blobs de bloco adicionados após a criação da regra são copiados por padrão. No entanto, você pode especificar que os blobs de bloco novos e existentes sejam copiados. Você também pode definir um escopo de cópia personalizado que copie todos os blobs de bloco criados após um tempo especificado.

Você também pode especificar um ou mais filtros como parte de uma regra de replicação para filtrar blobs de bloco por prefixo. Quando você especifica um prefixo, somente os blobs correspondentes a esse prefixo no contêiner de origem são copiados para o contêiner de destino.

Os contêineres de origem e de destino devem existir antes que você possa especificá-los em uma regra. Depois de criar a política de replicação, as operações de gravação no contêiner de destino não são permitidas. Qualquer tentativa de escrever no contentor de destino falhará com o código de erro 409 (Conflito).

Para gravar em um contêiner de destino com uma regra de replicação, você deve primeiro desabilitar a replicação. Você pode desabilitar a regra excluindo-a desse contêiner ou removendo toda a política de replicação.

As operações de leitura e exclusão no contêiner de destino são permitidas quando a política de replicação está ativa.

Pode executar a operação Definir Camada de Blob num blob no contêiner de destino para movê-lo para a camada de arquivamento. Para obter mais informações sobre a camada de arquivamento, consulte Camadas de acesso para dados de BLOB.

Nota

Alterar a camada de acesso de um blob na conta de origem não altera a camada de acesso desse blob na conta de destino.

Ficheiro de definição de política

Um arquivo JSON é usado para definir uma política de replicação de objeto. Você pode obter o arquivo de definição de política de uma política de replicação de objeto existente ou pode criar uma política de replicação de objeto carregando um arquivo de definição de política.

Exemplo de arquivo de definição de política

O exemplo a seguir define uma política de replicação na conta de destino com uma regra. A regra destina-se a blobs com o prefixo b e especifica um tempo mínimo de criação para replicação. Lembre-se de substituir os valores entre colchetes angulares pelos seus próprios valores:

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-028T00:00:00Z"
        }
      }
    ]
  }
}

Especificar IDs de recursos completos para contas de origem e destino

Ao criar o arquivo de definição de política, especifique as IDs de recurso completas do Azure Resource Manager para as entradas sourceAccount e destinationAccount , conforme mostrado no exemplo da seção anterior. Para saber como localizar o ID do recurso para uma conta de armazenamento, consulte Obter o ID do recurso para uma conta de armazenamento.

O ID completo do recurso está no seguinte formato:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

O arquivo de definição de política anteriormente exigia apenas o nome da conta, em vez do ID de recurso completo para a conta de armazenamento. Com a introdução da propriedade de segurança AllowCrossTenantReplication na versão 2021-02-01 da API REST do provedor de recursos de Armazenamento do Azure, agora você deve fornecer a ID de recurso completa para todas as políticas de replicação de objeto criadas quando a replicação entre locatários não é permitida para uma conta de armazenamento que participa da política de replicação. O Armazenamento do Azure usa a ID de recurso completa para verificar se as contas de origem e de destino residem no mesmo locatário. Para saber mais sobre como não permitir políticas de replicação entre locatários, consulte Impedir a replicação entre locatários do Microsoft Entra.

Embora o uso apenas do nome da conta ainda seja suportado para replicação entre locatários, a Microsoft recomenda o uso da ID de recurso completa como prática recomendada. Todas as versões anteriores da API REST do provedor de recursos de Armazenamento do Azure suportam o uso do caminho de ID de recurso completo nas políticas de replicação de objetos.

A tabela seguinte mostra como o comportamento da política de replicação difere quando se usa um ID de recurso completo em comparação com um nome de conta. A comparação depende de a replicação entre entidades ser permitida para a conta de armazenamento.

Identificador da conta de armazenamento na definição da política Replicação entre locatários permitida Replicação entre locatários não permitida
ID completo do recurso Podem ser criadas políticas de mesmo locatário.

Políticas interlocatárias podem ser criadas.		 Podem ser criadas políticas de mesmo locatário.

Não é possível criar políticas interlocatárias.
Apenas nome da conta Podem ser criadas políticas de mesmo locatário.

Políticas interlocatárias podem ser criadas.		 Nem políticas de mesmo inquilino nem de inquilino cruzado podem ser criadas. Ocorre um erro porque o Armazenamento do Azure não pode verificar se as contas de origem e de destino estão no mesmo locatário. O erro indica que você deve especificar o ID de recurso completo para as entradas sourceAccount e destinationAccount no arquivo de definição de política.

Especificar os identificadores de política e de regra

A tabela a seguir resume quais valores usar para as entradas policyId e ruleId no arquivo de definição de política em cada cenário.

Quando estiver a criar o ficheiro de definição de política para esta conta... Defina o ID da política para este valor Definir IDs de regra para este valor
Conta de destino O valor da cadeia default. O Armazenamento do Azure cria o valor da ID da política para você. Uma cadeia de caracteres vazia. O Armazenamento do Azure cria os valores de ID da regra para você.
Conta de origem O valor da ID de política retornado quando baixas o ficheiro de definição da política para a conta de destino. Os valores das IDs de regra retornados quando você baixa o arquivo de definição de política para a conta de destino.

Impedir a replicação entre locatários do Microsoft Entra

Um tenant do Microsoft Entra é uma instância dedicada do Microsoft Entra ID que representa uma organização para gestão de identidades e acessos. Cada subscrição do Azure tem uma relação de confiança com um único inquilino do Microsoft Entra. Todos os recursos de uma assinatura, incluindo contas de armazenamento, estão associados ao mesmo locatário do Microsoft Entra. Para obter mais informações, consulte O que é o Microsoft Entra ID?

Por padrão, a replicação entre locatários é desabilitada para novas contas criadas a partir de 15 de dezembro de 2023. Se suas políticas de segurança exigirem que você restrinja a replicação de objetos a contas de armazenamento que residam apenas no mesmo locatário, você poderá não permitir a replicação entre locatários definindo uma propriedade de segurança, a propriedade AllowCrossTenantReplication (visualização). Quando desativa a replicação de objetos entre inquilinos para uma conta de armazenamento, o Azure Storage impõe um requisito adicional. Para qualquer política de replicação de objetos que utilize esta conta de armazenamento como origem ou destino, ambas as contas devem pertencer ao mesmo inquilino Microsoft Entra. Para obter mais informações sobre como não permitir a replicação de objetos entre locatários, consulte Impedir a replicação de objetos entre locatários do Microsoft Entra.

Para não permitir a replicação de objeto entre locatários para uma conta de armazenamento, defina a propriedade AllowCrossTenantReplication como false. Se a conta de armazenamento não participar atualmente de nenhuma política de replicação de objeto entre locatários, definir a propriedade AllowCrossTenantReplication como false impedirá a configuração futura de políticas de replicação de objeto entre locatários com essa conta de armazenamento como origem ou destino.

Se a conta de armazenamento atualmente participar de uma ou mais políticas de replicação de objeto entre locatários, não é permitido definir a propriedade AllowCrossTenantReplication como false . Você deve excluir as políticas existentes entre locatários antes de não permitir a replicação entre locatários.

Por padrão, a propriedade AllowCrossTenantReplication é definida como false para uma conta de armazenamento criada a partir de 15 de dezembro de 2023. Para contas de armazenamento criadas antes de 15 de dezembro de 2023, quando o valor da propriedade AllowCrossTenantReplication para uma conta de armazenamento é nulo ou verdadeiro, os usuários autorizados podem configurar políticas de replicação de objeto entre locatários com essa conta como origem ou destino. Para obter mais informações sobre como configurar políticas entre locatários, consulte Configurar a replicação de objetos para blobs de bloco.

Você pode usar a Política do Azure para auditar um conjunto de contas de armazenamento para garantir que a propriedade AllowCrossTenantReplication esteja definida para impedir a replicação de objetos entre locatários. Você também pode usar a Política do Azure para impor a governança de um conjunto de contas de armazenamento. Por exemplo, você pode criar uma política com o deny efeito de impedir que um usuário crie uma conta de armazenamento onde a propriedade AllowCrossTenantReplication esteja definida como true ou modifique uma conta de armazenamento existente para alterar o valor da propriedade para true.

Métricas de replicação

A replicação de objetos oferece suporte a duas métricas para fornecer informações sobre o progresso da replicação:

  • Operações pendentes de replicação: número total de operações pendentes de replicação da conta de armazenamento de origem para a de destino, emitidas por intervalos de tempo.
  • Bytes pendentes para replicação: Soma de bytes pendentes de replicação das contas de armazenamento de origem para o destino, distribuída por intervalos de tempo.

Cada uma das métricas listadas anteriormente pode ser visualizada com a dimensão de intervalos de tempo. Esta divisão permite perceber quantos bytes ou operações estão pendentes de replicação por intervalos de tempo, da seguinte forma:

  • 0-5 minutos
  • 5-10 minutos
  • 10-15 minutos
  • 15-30 minutos
  • 30 minutos-2 horas
  • 2-8 horas
  • 8-24 horas
  • >24 horas

A imagem de exemplo a seguir mostra a operação pendente e a métrica de bytes dos sete dias anteriores:

Métricas de replicação de objetos mostrando operações pendentes e bytes pendentes durante uma duração de sete dias

Você pode habilitar métricas de replicação na conta de origem para monitorar bytes pendentes e operações pendentes. Para obter mais informações, consulte Configurar métricas de replicação.

Estado de replicação

Você pode verificar o status de replicação de um blob na conta de origem. Para obter mais informações, consulte Verificar o status de replicação de um blob.

Nota

Enquanto a replicação estiver em andamento, não é possível determinar a porcentagem ou os dados replicados.

Se o status de replicação de um blob na conta de origem indicar falha, investigue as seguintes causas possíveis:

  • Verifique se a política de replicação de objetos está configurada na conta de destino.
  • Verifique se a conta de destino ainda existe.
  • Verifique se o contêiner de destino ainda existe.
  • Verifique se o contêiner de destino não foi excluído e se não está em processo de exclusão. A exclusão de um contêiner pode levar até 30 segundos.
  • Verifique se o contêiner de destino ainda está participando da política de replicação de objetos.
  • Se o blob de origem for criptografado com uma chave fornecida pelo cliente como parte de uma operação de gravação, a replicação de objeto falhará. Para obter mais informações sobre chaves fornecidas pelo cliente, consulte Fornecer uma chave de criptografia em uma solicitação para armazenamento de Blob.
  • Verifique se o blob de origem ou destino foi movido para a camada de arquivamento. Os blobs arquivados não podem ser replicados por meio da replicação de objetos. Para obter mais informações sobre a camada de arquivamento, consulte Camadas de acesso para dados de BLOB.
  • Verifique se o contêiner ou blob de destino não está protegido por uma política de imutabilidade. Lembre-se de que um contêiner ou blob pode herdar uma política de imutabilidade de seu pai. Para obter mais informações sobre políticas de imutabilidade, consulte Visão geral do armazenamento imutável para dados de blob.

Suporte de funcionalidades

O suporte para esse recurso pode ser afetado pela habilitação do Data Lake Storage Gen2, do protocolo NFS (Network File System) 3.0 ou do SSH File Transfer Protocol (SFTP). Se você habilitou qualquer um desses recursos, consulte Suporte ao recurso de Armazenamento de Blob nas contas de Armazenamento do Azure para avaliar o suporte para esse recurso.

Faturação

Não há custo para configurar a replicação de objetos, incluindo a tarefa de ativar o feed de alterações, ativar a versão e adicionar políticas de replicação. No entanto, a replicação de objetos implica custos nas transações de leitura e escrita contra as contas de origem e destino. As taxas de saída pela replicação de dados da conta de origem para a conta de destino também geram custos, assim como as taxas de leitura durante o processamento do feed de alterações.

Aqui está um detalhamento dos custos. Para encontrar o preço de cada componente de custo, consulte Preços do Armazenamento de Blob do Azure.

Custo para atualizar um blob na conta de origem Custo para replicar dados na conta de destino
Custo de transação de uma operação de gravação Custo de transação para ler um registo de fluxo de alterações
Custo de armazenamento do blob e de cada versão do blob1 Custo de transação para ler o blob e as versões de blob2
Custo para adicionar um registo de feed de alterações Custo de transação para escrever o blob e as versões de blob2
Custos de recuperação de dados em níveis fresco e frio Custo de armazenamento do blob e de cada versão do blob1
Custo da saídada rede 3

1 Na conta de origem, se a camada de um blob ou de uma versão não for alterada, será cobrado(a) por blocos de dados únicos nesse blob e nas suas versões. Consulte os preços e faturamento do controle de versão de Blob. Na conta de destino, para uma versão, você é cobrado por todos os blocos de uma versão, independentemente de esses blocos serem exclusivos ou não.

2 Isso inclui apenas versões de blob criadas desde a última replicação concluída.

3 A replicação de objetos copia toda a versão para o destino (não apenas os blocos exclusivos da versão). Esta transferência incorre no custo de saída da rede. Consulte Preços de largura de banda.

Gorjeta

Para reduzir o risco de uma fatura inesperada, habilite a replicação de objetos em uma conta que contenha apenas alguns objetos. Em seguida, meça o impacto no custo antes de habilitar o recurso em uma configuração de produção.

Próximos passos

  • Last updated on