Replicação de objeto para blob de blocos

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

• Minimizar a latência. A replicação de objetos reduz a latência para requisições de leitura ao permitir que os clientes consumam dados de uma região mais 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.
• Otimize a distribuição dos dados. Você pode processar ou analisar dados em um único local e replicar apenas os resultados para regiões extras.
• Otimize custos. Depois que seus dados são replicados, você pode reduzir custos transferindo-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.

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 requer que os seguintes recursos de Armazenamento do Azure também estejam habilitados:

• Alterar o feed: Ativar na conta de origem. Para saber como habilitar o feed de alterações, consulte Abilitar e desabilitar o feed de alterações.
• Controle de versão de blobs: Ative-o 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, consulte a página de preços Armazenamento do Azure.

A replicação de objetos suporta contas de armazenamento v2 de uso geral e contas blob premium em bloco. As contas de origem e de destino devem ser contas de blob de blocos de uso geral v2 ou premium. A replicação de objetos suporta apenas blobs de bloco; não suporta blobs de anexação nem blobs de página.

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

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

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.

Replicação de objetos não é suportada em contas que têm um namespace hierárquico ativado.

Não há suporte para replicação de objeto para blobs carregados usando APIs 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 serviço copia o conteúdo do blob, quaisquer versões associadas ao blob, e os metadados e propriedades do blob 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.

A replicação de objetos (OR) agora suporta 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 é ativada, o desempenho de replicação de todas as operações melhora. 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 mais informações, veja os termos do SLA e o artigo Replicação prioritária para replicação de objetos.

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 objetos exige que você ative a versão de blob tanto na conta de origem quanto na de destino. Quando você modifica um blob replicado na conta fonte, o serviço cria uma nova versão do blob 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. O serviço replica tanto a versão atual quanto quaisquer versões anteriores na 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 versionamento 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 serviço não copia o ID de versão de um blob. Após o serviço colocar um blob no local de destino, ele atribui um novo ID de versão.

Exclusão de um blob na conta de origem

Quando você exclui um blob na conta de origem, a versão atual do blob se torna uma versão anterior, e não existe mais uma versão atual. O serviço preserva todas as versões anteriores existentes do blob. O serviço replica esse estado para a conta de destino. Para mais informações sobre como as operações de exclusão afetam as versões do blob, veja Versionamento nas operações de exclusão.

Instantâneos

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

Marcas de índice de blob

Agora a replicação de objetos suporta a cópia de tags de índice de blobs de origem para blobs de destino. Você pode configurar essa funcionalidade como parte de uma regra de replicação nova ou existente. Para obter mais informações, consulte Configurar replicação de objeto.

Importante

A replicação da marca está atualmente em versão prévia. Consulte os Termos Suplementares de Uso para Microsoft Azure Previews para termos legais que se aplicam a recursos do Azure em versão beta, versão de visualização, ou que ainda não foram liberados para disponibilidade geral.

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. Reidratar um blob arquivado não aciona a replicação de objetos. A replicação de objeto é disparada somente quando os dados de blob são atualizados novamente após a reidratação. 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 Armazenamento de Blobs do Azure incluem políticas de retenção baseadas em tempo e retenções legais. 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 uma versão, 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 storage 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, 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

Quando você configura a replicação de objetos, cria uma política de replicação na conta de destino através do provedor de recursos do Armazenamento do Azure. Depois que você cria a política de replicação, o Armazenamento do Azure atribui a ela um ID de política. Em seguida, você deve associar essa política de replicação à conta de origem usando a ID de política. O ID da política nas contas de origem e destino deve ser o mesmo 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 Microsoft Entra diferentes. Você pode criar apenas uma política de replicação para cada par de conta de origem e destino.

Regras de replicação

As regras de replicação especificam como 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 desativar a regra excluindo-a para aquele 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 access de um blob na conta de origem não altera a camada access desse blob na conta de destino.

Arquivo de definição de política

Use um arquivo JSON para definir uma política de replicação de objetos. 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>",
    "metrics": {
		  "enabled": false
    },
    "priorityReplication": "false",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Filtros personalizados

Você pode personalizar filtros com diferentes opções em um arquivo JSON:

• Combine blobs por prefixo — replique apenas blobs cujos nomes começam com a letra b.

"filters": {
          "prefixMatch": [
            "b"
          ],
        }

• Corresponder blobs pela data/hora de criação — replique apenas blobs criados na ou após a data/hora especificada.

"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}

• Replicar todos os blobs — definir o tempo mínimo de criação para o valor mais antigo possível.

"filters": {
  "minCreationTime": "1601-01-01T00: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 completas do recurso 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 de uma conta de storage, consulte Get the resource ID for a storage account.

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 anteriormente exigia apenas o nome da conta, em vez da ID de recurso completa para a conta storage. Com a introdução da propriedade de segurança AllowCrossTenantReplication na versão 2021-02-01 da API REST do provedor de recursos do Armazenamento do Azure, agora você deve fornecer o ID completo de recurso para quaisquer políticas de replicação de objetos que criar quando a replicação entre locatários for proibida para uma conta de armazenamento que participe da política de replicaçã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 impedir políticas de replicação entre locatários, consulte Impedir 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, Microsoft recomenda usar a ID de recurso completa como uma prática recomendada. Todas as versões anteriores da API REST do provedor de recursos Armazenamento do Azure usam o caminho completo da ID do recurso 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 de 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 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 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 Microsoft Entra. Para obter mais informações, consulte O que é 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 as políticas de segurança exigirem que você restrinja a replicação de objetos a contas de armazenamento que residem somente no mesmo locatário, é possível impedir a replicação entre locatários definindo a propriedade de segurança AllowCrossTenantReplication (prévia). Quando você desativa a replicação de objetos entre locatários para uma conta de armazenamento, o Armazenamento do Azure estabelece 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 Microsoft Entra. Para obter mais informações sobre como impedir a replicação de objeto entre locatários do Microsoft Entra, 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 storage, defina a propriedade AllowCrossTenantReplication como false. Se a conta storage atualmente não participar 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 storage como origem ou destino.

Se a conta storage atualmente participar de uma ou mais políticas de replicação de objeto entre locatários, a definição da propriedade AllowCrossTenantReplication como false não será permitida. 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 storage 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 de uma conta de armazenamento for null ou true, então os usuários autorizados podem configurar políticas de replicação de objeto entre locatários com essa conta como a origem ou o 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 Azure Policy para auditar um conjunto de contas de armazenamento para garantir que a propriedade AllowCrossTenantReplication esteja definida para impedir a replicação de objeto entre locatários. Você também pode usar Azure Policy para impor a governança para um conjunto de contas de armazenamento. Por exemplo, você pode criar uma política com o efeito deny para impedir que um usuário crie uma conta storage em que a propriedade AllowCrossTenantReplication está definida como true, ou de modificar uma conta storage 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 o destino, emitidas por intervalos 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

Enquanto a replicação está em andamento, não há como determinar a porcentagem de dados replicados.

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

• Certifique-se de que a política de replicação de objetos esteja 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 obter mais informações sobre chaves fornecidas pelo cliente, consulte Provide uma chave de criptografia em uma solicitação para Blob storage.
• 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. 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 pela habilitação de Data Lake Storage Gen2, protocolo NFS (Sistema de Arquivos de Rede) 3.0 ou protocolo SFTP (Protocolo de Transferência de Arquivo SSH). Se você habilitou qualquer um desses recursos, consulte suporte a recursos do Armazenamento de Blobs em contas do Armazenamento do Azure para verificar sua compatibilidade.

Cobrança

Não há custo para configurar a replicação de objetos, incluindo ativar políticas de fluxo de mudanças, versionamento e 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. As taxas de saída para a 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 fluxo de alterações.

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

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 a camada de um blob ou de uma versão não for alterada, você será cobrado pelos blocos de dados exclusivos nesse blob e em suas versões. Consulte Preços de controle de versão de blob e cobrança. Na conta de destino, para uma versão, você é cobrado por todos os blocos de uma versão, independentemente de esses blocos serem únicos ou não.

² Esse custo inclui apenas versões em blob criadas desde a última replicação 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. Consulte os 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
• Prevenir a replicação de objetos entre locatários do Microsoft Entra
• Versionamento de blobs
• Suporte ao feed de alterações no Armazenamento de Blobs do Azure