Replicação de objeto para blob de blocos

Artigo
12/08/2023

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. É possível processar ou analisar dados em um único local e, em seguida, replicar apenas os resultados em regiões adicionais.
Otimização dos custos. Após a replicação dos dados, você poderá reduzir os custos movendo-os para a camada de arquivo 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.

Diagrama mostrando como funciona a replicação de objeto

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.

A habilitação do feed de alterações e do controle de versão 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.

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

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. Atualmente, não há SLA sobre o tempo necessário para replicar dados para a conta de destino. Você pode verificar o status de 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 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 do 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.

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 objetos 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 do 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

A replicação de objeto tem suporte quando as contas de origem e de destino estão na camada de acesso frequente ou esporádica. As contas de origem e de destino podem estar em camadas diferentes. No entanto, a replicação de objeto falhará se um blob na conta de origem ou de destino tiver sido movido para a camada de armazenamento de arquivos. 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 objetos 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 uma política de imutabilidade no nível do contêiner estiver em vigor para um contêiner na conta de destino e um objeto no contêiner de origem for atualizado ou excluído, a operação no contêiner de origem poderá ser bem-sucedida, mas a replicação dessa operação para o contêiner de destino falhará. 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 uma política de imutabilidade no nível da versão estiver em vigor para uma versão de blob na conta de destino e uma operação de exclusão ou atualização for realizada na versão de blob no contêiner de origem, a operação no objeto de origem poderá ser bem-sucedida, mas a replicação dessa operação para o objeto de destino falhará. 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 um contêiner de destino e indicam quais blobs de blocos no contêiner de origem serão replicados.

Depois de configurar a replicação de objeto, o Armazenamento do Azure verifica periodicamente o feed de alterações da conta de origem e replica de forma assíncrona quaisquer operações de gravação ou exclusão na 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. Elas também podem estar na mesma assinatura ou em assinaturas diferentes. Opcionalmente, as contas de origem e destino podem estar em locatários do Microsoft Entra. Somente 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 replicará os 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, o que significa que 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.

Quando você cria uma regra de replicação, por padrão, somente os novos blobs de blocos adicionados subsequentemente ao contêiner de origem são copiados. É possível especificar que os blobs de blocos novos e existentes sejam copiados, ou você pode definir um escopo de cópia personalizado que copia blob de blocos criados a partir de um tempo especificado em diante.

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 que correspondem a esse prefixo no contêiner de origem serã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 para o qual uma regra de replicação está configurada, você deve excluir a regra que está configurada para esse contêiner ou remover 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 alterará a camada de acesso desse blob na conta de destino.

Arquivo de definição de política

Uma política de replicação de objeto é definida pelo arquivo JSON. Você pode obter o arquivo de definição de política a partir de uma política de replicação de objeto existente. Você também 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 única regra que corresponde ao prefixo b, e define o tempo de criação mínimo para blobs que devem ser replicados. 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 do recurso completas para as contas de origem e 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 exista suporte para fornecer apenas o nome da conta quando a replicação entre locatários for permitida para uma conta de armazenamento, a Microsoft recomenda sempre fornecer a ID do recurso completa como uma melhor prática. 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 descreve o que acontece quando você cria uma política de replicação com a ID do recurso completa especificada, em comparação ao nome da conta, nos cenários em que a replicação entre locatários é ou não 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 Azure criará o valor da ID da política para você.	Uma cadeia de caracteres vazia. O Armazenamento do Azure criará o valor da 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ê não permite a replicação de objeto entre locatários para uma conta de armazenamento, então, para qualquer política de replicação de objeto configurada com essa conta de armazenamento como a conta de origem ou destino, o Armazenamento do Azure requer que as contas de origem e de destino residam dentro do 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 efeito negar para impedir que um usuário crie uma conta de armazenamento em que a propriedade AllowCrossTenantReplication seja definida como true ou modificar uma conta de armazenamento existente para alterar o valor da propriedade para true.

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 de dados que foram 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á em processo de exclusão ou não foi excluído apenas. 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 tiver sido 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 arquivos. Blobs arquivados não podem ser replicados por meio da replicação de objeto. Para saber mais sobre a camada de arquivos, consulte Camada de acesso aos dados de blob.
Verifique se o contêiner de destino ou 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. Isso inclui a tarefa de habilitar o feed de alterações, habilitar o controle de versão, bem como adicionar políticas de replicação. No entanto, a replicação de objeto gera custos adicionais em transações de leitura e gravação nas contas de origem e de destino, bem como encargos de saída para a replicação de dados da conta de origem para a conta de destino e encargos de leitura para processar o 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 blob¹	Custo da transação para ler as versões de blob e blob²
Custo para adicionar um registro de feed de alterações	Custo da transação para gravar as versões de blob e blob²
	Custo de armazenamento do blob e de cada versão do blob¹
	Custo da saída de rede³

¹ Na conta de origem, caso não tenha alterado nenhuma camada de blob ou de versão, você será cobrado por blocos exclusivos de dados nesse blob, nas versões dele. 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 cobrança inesperada, habilite a replicação de objeto em uma conta que contenha apenas um pequeno número de objetos. Em seguida, meça o impacto sobre o custo antes de habilitar o recurso em uma configuração de produção.