Replicação de objeto para blob de blocos

A replicação de objeto copia de maneira assíncrona os blob de blocos entre uma conta de armazenamento de origem e uma conta de destino. Alguns cenários com suporte da replicação de objeto incluem:

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

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

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

Pré-requisitos e restrições para replicação de objeto

A replicação de objeto exige que os seguintes recursos de Armazenamento do Microsoft Azure também estejam habilitados:

• Feed de alterações: deve estar habilitado na conta de origem. Para saber como habilitar o feed de alterações, consulte Habilitar e desabilitar o feed de alterações.
• Controle de versão do blob: deve estar habilitado nas contas de origem e de destino. Para saber como habilitar o controle de versão, confira Habilitar e gerenciar o controle de versão de blobs.

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

Há suporte para replicação de objetos em contas de armazenamento v2 de uso geral e contas de blob de blocos premium. As contas de origem e de destino devem ser contas de blob de blocos de uso geral v2 ou premium. Não há suporte para replicação de objetos apenas a blobs de blocos. Não há suporte para blobs de acréscimo e blobs de páginas.

Há suporte para replicação de objeto para contas criptografadas com chaves gerenciadas pela Microsoft ou chaves gerenciadas pelo cliente. Para obter mais informações, confira Chaves gerenciadas pelo cliente para criptografia do Armazenamento do Azure.

Não há suporte para replicação de objeto para blobs na conta de origem que são criptografados com uma chave fornecida pelo cliente. Para saber mais sobre chaves fornecidas pelo cliente, confira Fornecer uma chave de criptografia em uma solicitação para o armazenamento de blobs.

Não há suporte a failover gerenciado pelo cliente para a conta de origem ou a conta de destino em uma política de replicação de objeto.

A replicação de objeto ainda não tem suporte em contas que têm um namespace hierárquico habilitado.

Não há suporte para replicação de objeto para blobs carregados usando APIs do Data Lake Storage .

Como funciona a replicação de objeto

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

Importante

Como os dados do blob de blocos são replicados de forma assíncrona, a conta de origem e a conta de destino não ficam em sincronização imediatamente.

O OR agora dá suporte à replicação de prioridade, que prioriza a replicação de todas as operações em uma política OR. Quando a replicação de prioridade OR está habilitada, o desempenho de replicação de todas as operações é aprimorado. Quando a conta de origem e a de destino de uma política de replicação estão no mesmo continente, a replicação prioritária OR também replica 99,0% dos objetos em até 15 minutos para cargas de trabalho com suporte. O desempenho do recurso é garantido com um SLA (contrato de nível de serviço). Para obter mais informações, visite os termos do SLA e o artigo Replicação por Prioridade de Replicação de Objeto.

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

Controle de versão de blobs

A replicação de objeto requer que o controle de versão de blob seja 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. A versão atual e todas as 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 Controle de versão em operações de gravação.

Se sua conta de armazenamento tiver políticas de replicação de objeto em vigor, você não poderá desabilitar o controle de versão de blob para essa conta. Você precisa excluir as políticas de replicação de objeto na conta antes de desabilitar o controle de versão do blob.

Observação

Somente os blobs são copiados para o destino. O identificador de versão de um blob não é copiado. Depois que um blob é colocado no local de destino, uma nova ID de versão é atribuída.

Exclusão de 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 a versão anterior deixa de existir. Todas as versões anteriores do blob são preservadas. Esse estado é replicado para a conta de destino. Para obter mais informações sobre como as operações de exclusão afetam as versões de blob, confira Controle de versão em operações de exclusão.

Instantâneos

A replicação de objeto não dá suporte a instantâneos de blob. Os instantâneos em um blob na conta de origem não são replicados para a conta de destino.

Marcas de índice de blob

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

Camadas de Blobs

Há suporte para a replicação de objeto quando as contas de origem e de destino estão em qualquer camada online (frequente, esporádica ou fria). As contas de origem e de destino podem estar em camadas diferentes. Contudo, a replicação de objeto 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, confira Camadas de acesso para dados de blob.

Blobs imutáveis

As políticas de imutabilidade do Armazenamento de Blobs do Azure incluem retenções legais e políticas baseadas em tempo. Quando uma política de imutabilidade está em vigor na conta de destino, a replicação de objeto pode ser afetada. Para obter mais informações sobre as políticas de imutabilidade, confira Armazenar dados de blobs comercialmente críticos com o armazenamento imutável.

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 que tem como escopo um contêiner, confira Cenários com escopo de nível de contêiner.

Se a versão de blob de uma conta de destino tiver uma política de imutabilidade ativa no nível da versão, uma operação de exclusão ou atualização executada na versão de blob do contêiner de origem correspondente poderá ser bem-sucedida. 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 que tem como escopo um contêiner, confira Cenários com escopo de nível de versão.

Políticas e regras da replicação de objeto

Ao configurar a replicação de objeto, 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 objeto, o Armazenamento do Azure verifica o feed de alterações da conta de origem periodicamente e replica as operações de gravação ou exclusão de forma assíncrona para a conta de destino. A latência de replicação depende do tamanho do blob de blocos que está sendo replicado.

Políticas de replicação

Ao configurar a replicação de objeto, você cria uma política de replicação na conta de destino por meio do provedor de recursos do 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 de política. A ID de política nas contas de origem e de destino devem ser a mesma para que a replicação ocorra.

Uma conta de origem pode replicar para não mais do que duas contas de destino, com uma política para cada conta de destino. Da mesma forma, uma conta pode servir como a conta de destino para não mais do que 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 locatários diferentes do Microsoft Entra. Apenas uma política de replicação pode ser criada para cada par de conta de origem/conta de 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 pré-existentes são ignorados; somente os 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 são copiados. Você também pode definir um escopo de cópia personalizado que copia quaisquer blobs de bloco criados após um horário especificado.

Você também pode especificar um ou mais filtros como parte de uma regra de replicação para filtrar blobs de blocos 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 para 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 gravar no contêiner de destino falha com o código de erro 409 (conflito).

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

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

Você pode chamar a operação Definir Camada de Blob em um blobs no contêiner de destino para movê-lo para a camada de arquivos. Para saber mais sobre a camada de arquivos, consulte Camada de acesso aos dados de blob.

Observação

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.

Arquivo 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 completas de recursos para contas de origem e de destino

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

A ID do recurso completa está no seguinte formato:

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

O arquivo de definição de política exigia apenas o nome da conta, em vez da ID do recurso completa da 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 Microsoft Azure, agora você deve fornecer a ID do recurso completa para todas as políticas de replicação de objeto criadas quando a replicação entre locatários não for permitida para uma conta de armazenamento que participa da política de replicação. O Armazenamento do Microsoft Azure usa a ID do recurso completa para verificar se as contas de origem e 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 ainda haja suporte para usar apenas o nome da conta para replicação entre locatários, a Microsoft recomenda usar a ID de recurso completa como uma prática recomendada. Todas as versões anteriores do provedor de recursos API REST do Armazenamento do Microsoft Azure dão suporte ao uso do caminho de ID do recurso completo nas políticas de replicação de objeto.

A tabela a seguir mostra como o comportamento da política de replicação difere quando você usa uma ID de recurso completa versus um nome de conta. A comparação depende se a replicação entre locatários é permitida para a conta de armazenamento.

Identificador de conta de armazenamento na definição de política	Replicação entre locatários permitida	Replicação entre locatários não permitida
ID do recurso completa	Políticas de mesmo locatário podem ser criadas. Políticas entre locatários podem ser criadas.	Políticas de mesmo locatário podem ser criadas. Políticas entre locatários não podem ser criadas.
Somente nome da conta	Políticas de mesmo locatário podem ser criadas. Políticas entre locatários podem ser criadas.	Não podem ser criadas políticas de mesmo locatário e nem políticas entre locatários. Ocorre um erro porque o Armazenamento do Microsoft 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 a ID do recurso completa para as entradas sourceAccount e destinationAccount no arquivo de definição de política.

Especificar a política e a regra das IDs

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 você estiver criando o arquivo de definição de política para essa conta...	Definir a ID da política para esse valor	Definir IDs de regra para esse valor
Conta de destino	O valor da cadeia de caracteres default. O Armazenamento do Microsoft Azure cria para você o valor do ID da política.	Uma cadeia de caracteres vazia. O Armazenamento do Microsoft Azure cria os valores de ID da regra para você.
Conta de origem	O valor da ID da política retornada quando você baixa o arquivo de política de definição na conta de destino.	Os valores das IDs da regra retornada quando você baixa o arquivo de política de definição na conta de destino.

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

Um locatário do Microsoft Entra é uma instância dedicada do Microsoft Entra ID que representa uma organização de gerenciamento de identidade e acesso. Cada assinatura do Azure tem uma relação de confiança com um único locatário do Microsoft Entra. Todos os recursos em uma assinatura, incluindo contas de armazenamento, sã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 está 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 objeto para contas de armazenamento que residem 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 (versão prévia). Quando você desabilita a replicação de objeto entre locatários para uma conta de armazenamento, a Azure Storage impõe um requisito adicional. Para qualquer política de replicação de objeto que use essa conta de armazenamento como a origem ou o destino, ambas as contas devem pertencer ao mesmo locatário do Microsoft Entra. Para obter mais informações sobre como não permitir a replicação de objeto entre locatários, consulte Impedir a replicação de objeto entre locatários do Microsoft Entra.

Para não permitir a replicação de objeto entre locatários para uma conta de armazenamento, definir 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 das políticas de replicação de objeto entre locatários com essa conta de armazenamento como a origem ou destino.

Se a conta de armazenamento participa no momento 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 entre locatários existentes 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 for nulo ou verdadeiro, os usuários autorizados poderão 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 objeto para blobs de blocos.

Você pode usar o Azure Policy para auditar um conjunto de contas de armazenamento e garantir que a propriedade AllowCrossTenantReplication seja definida para evitar a replicação de objeto entre locatários. Você também pode usar a Azure Policy para impor a governança em um conjunto de contas de armazenamento. Por exemplo, você pode criar uma política com o deny efeito para impedir que um usuário crie uma conta de armazenamento em que a propriedade AllowCrossTenantReplication seja 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 objeto dá suporte a duas métricas para fornecer insights sobre o progresso da replicação:

• Operações pendentes para replicação: número total de operações pendentes de replicação da conta de armazenamento de origem para destino emitida pelos buckets de tempo
• Bytes pendentes para replicação: soma de bytes pendentes de replicação de contas de armazenamento de origem para destino emitidas por buckets de tempo

Cada uma das métricas listadas anteriormente pode ser exibida com a dimensão de intervalos de tempo. Esta subdivisão proporciona insights sobre quantos bytes ou operações estão pendentes de replicação por intervalos de tempo da seguinte maneira:

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

A imagem de exemplo a seguir mostra as métricas de operações pendentes e bytes dos últimos 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.

Status 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.

Observação

Embora a replicação esteja em andamento, não há como 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:

• Não deixe de verificar se a política de replicação de objeto 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 está 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 objeto.
• 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 saber mais sobre chaves fornecidas pelo cliente, confira Fornecer uma chave de criptografia em uma solicitação para o armazenamento de blobs.
• Verifique se o blob de origem ou de destino foi movido para a camada de arquivamento. Blobs arquivados não podem ser replicados por meio da replicação de objetos. Para saber mais sobre a camada de arquivos, consulte Camada de acesso aos dados de blob.
• Verifique se o contêiner de destino ou o blob não está protegido por uma política de imutabilidade. Tenha em mente 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 a recursos

O suporte para esse recurso pode ser afetado ao habilitar o Data Lake Storage Gen2, o protocolo NFS (Sistema de Arquivos de Rede) 3.0 ou o protocolo SFTP (Protocolo de Transferência de Arquivo SSH). Se você tiver habilitado qualquer um desses recursos, consulte o Suporte a recursos de Armazenamento de Blobs nas contas de Armazenamento do Azure para avaliar o suporte para esse recurso.

Cobrança

Não há custo para configurar a replicação de objeto, incluindo a tarefa de habilitar o feed de alterações, habilitar o controle de versão e adicionar políticas de replicação. No entanto, a replicação de objeto incorre em custos em transações de leitura e gravação nas contas de origem e de destino. Os encargos de saída para a replicação de dados da conta de origem para a conta de destino também geram custo, assim como os encargos de leitura durante o processamento do feed de alterações.

Aqui está um detalhamento dos custos. Para localizar o preço de cada componente de custo, confira Preços de Armazenamento de Blobs do Azure.

Custo para atualizar um blob na conta de origem	Custo para replicar dados na conta de destino
Custo da transação de uma operação de gravação	Custo da transação para ler um registro de feed de alterações
Custo de armazenamento do blob e de cada versão do blob1	Custo da transação para ler as versões de blob e blob2
Custo para adicionar um registro de feed de alterações	Custo da transação para gravar as versões de blob e blob2
Custos de recuperação de dados em camadas fresca e fria	Custo de armazenamento do blob e de cada versão do blob1
	Custo da saída de rede3

¹ Na conta de origem, se o nível de um blob ou versão permanecer inalterado, você será cobrado por blocos de dados exclusivos entre esse blob e suas versões. Consulte Preços de controle de versão de blob e cobrança. Na conta de destino, todos os blocos de uma versão são cobrados, independentemente de eles serem exclusivos ou não.

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

³ A replicação de objeto copia a versão inteira para o destino (não apenas os blocos exclusivos da versão). Essa transferência incorre no custo da saída da rede. Confira Preços de largura de banda.

Dica

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

Próximas etapas

• Configurar a replicação de objeto
• Impedir a replicação de objeto entre locatários do Microsoft Entra
• Controle de versão de blobs
• Suporte ao feed de alterações no armazenamento de blobs do Azure