Replicação de objetos para blobs de bloco
A replicação de objetos copia de forma assíncrona blobs de bloco entre uma conta de armazenamento de origem e uma conta 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 outras regiões.
- 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 replica blobs de bloco 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 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:
- Alterar feed: Deve estar habilitado na conta de origem. Para saber como ativar o feed de alterações, consulte Ativar e desativar o feed de alterações.
- Controle de versão de Blob: deve ser habilitado nas contas de origem e de destino. Para saber como habilitar o controle de versão, consulte Habilitar e gerenciar o controle de versão de blob.
Habilitar o feed de alterações e o controle de versão de blob 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 de blob de bloco premium. As contas de origem e de destino devem ser contas v2 de uso geral ou contas de blob de bloco premium. A replicação de objetos suporta apenas blobs de bloco; Não há suporte para blobs de acréscimo e 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.
Não há suporte para replicação de objetos para blobs na conta de origem 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.
A ativação pós-falha gerida pelo cliente não é suportada 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 não é suportada para blobs carregados usando APIs do Data Lake Storage Gen2 .
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. Atualmente, não há SLA sobre quanto tempo leva para replicar dados para a conta de destino. Você 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 Controle de versão em operações de gravação.
Se sua conta de armazenamento tiver políticas de replicação de objetos em vigor, você não poderá 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 controle de versão de blob.
Nota
Apenas os blobs são copiados para o destino. O ID de versão de um blob não é copiado. O blob colocado no local de destino recebe um novo ID de versão.
Excluindo 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 excluir operações que afetam versões de blob, consulte Controle de versão em operações de exclusão.
Instantâneos
A replicação de objetos não oferece suporte a instantâneos de blob. Quaisquer instantâneos em um blob na conta de origem não são replicados para a 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 na camada quente 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 tiver sido 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 Armazenar dados de blob críticos para os negócios com 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 com escopo para um contêiner, consulte Cenários com escopo no nível do contêiner.
Se uma política de imutabilidade no nível de 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 executada 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 com escopo para um contêiner, consulte Cenários com escopo no 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 um contêiner de destino e indicam quais blobs de bloco no contêiner de origem serão replicados.
Depois de configurar a replicação de objetos, o Armazenamento do Azure verifica o feed de alterações da conta de origem periodicamente 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 a conta de destino, no máximo, para 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 conta de origem/conta de destino.
Regras de replicação
As regras de replicação especificam como o Armazenamento do Azure replicará blobs de um contêiner de origem para um contêiner de destino. Você pode especificar até 1000 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 1000 contêineres de origem e 1000 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, apenas novos blobs de bloco que são adicionados subsequentemente ao contêiner de origem são copiados. Você pode especificar que os blobs de bloco novos e existentes sejam copiados ou pode definir um escopo de cópia personalizado que copie blobs de bloco criados a partir de 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 especificar um prefixo, apenas os blobs correspondentes ao prefixo no contentor de origem serão copiados para o contentor 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 para o qual uma regra de replicação está configurada, você deve excluir a regra configurada para esse contêiner ou remover 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.
Você pode chamar a operação Definir Camada de Blob em um blob no contêiner de destino para movê-la 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 alterará a camada de acesso desse blob na conta de destino.
Ficheiro 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 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 mínimo de criação 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 de recursos completos para as contas de origem e de 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 ainda haja suporte para fornecer apenas o nome da conta quando a replicação entre locatários é permitida para uma conta de armazenamento, a Microsoft recomenda sempre fornecer a ID completa do recurso 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 a seguir descreve o que acontece quando você cria uma política de replicação com a ID de recurso completa especificada, em comparação com o nome da conta, nos cenários em que a replicação entre locatários é permitida 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 completo do recurso | Podem ser criadas políticas de mesmo inquilino. Políticas entre locatários podem ser criadas. |
Podem ser criadas políticas de mesmo inquilino. Não é possível criar políticas entre locatários. |
| Apenas nome da conta | Podem ser criadas políticas de mesmo inquilino. Políticas entre locatários podem ser criadas. |
Nem políticas de mesmo locatário nem de locatário 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 IDs de política e 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 de caracteres padrão. O Armazenamento do Azure criará o valor da ID da política para você. | Uma cadeia de caracteres vazia. O Armazenamento do Azure criará 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 definição de 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 locatário do Microsoft Entra é uma instância dedicada do Microsoft Entra ID que representa uma organização para 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 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 você não permite a replicação de objeto entre locatários para uma conta de armazenamento, para qualquer política de replicação de objeto configurada com essa conta de armazenamento como a conta de origem ou de destino, o Armazenamento do Azure exige que as contas de origem e de destino residam no mesmo locatário do 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 efeito deny para 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.
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 está 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:
- 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 está em processo de exclusão ou se não foi excluído. 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 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 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. Isso inclui 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 objetos incorre em custos 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 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 registro de feed de alterações |
| Custo de armazenamento do blob e de cada versão do blob1 | Custo de transação para ler as versõesde blob e blob 2 |
| Custo para adicionar um registro de feed de alterações | Custo de transação para escrever as versõesde blob e blob 2 |
| Custo de armazenamento do blob e de cada versão do blob1 | |
| Custo da saídada rede 3 |
1 Na conta de origem, se você não alterou um blob ou a camada da versão, você será cobrado por blocos exclusivos de dados nesse blob, suas versões. Consulte 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 um pequeno número de objetos. Em seguida, meça o impacto no custo antes de habilitar o recurso em uma configuração de produção.