Replicação na mesma região entre contas - Object Storage Service: Central de Documentação do Alibaba Cloud

A replicação na mesma região entre contas copia objetos automática e assincronamente (quase em tempo real) de um bucket de origem para um bucket de destino na mesma região, pertencente a outra conta Alibaba Cloud. Esse recurso ajuda a implementar recuperação de desastres, criar backups isolados entre contas ou atender a requisitos de conformidade de residência de dados.

Para configurar a replicação na mesma região entre contas, execute ações tanto na conta de origem quanto na de destino. O processo envolve três etapas principais:

Conta de origem: Crie uma função RAM dedicada à replicação de dados e conceda a ela as permissões mínimas necessárias para ler dados do bucket de origem.
Conta de destino: Modifique a política do bucket de destino para conceder acesso de gravação à função RAM da conta de origem.
Conta de origem (retorno): Crie uma regra de Same-Region Replication para vincular os buckets de origem e de destino e iniciar a tarefa de replicação.

Etapa 1: Criar e autorizar uma função RAM

Crie uma função RAM: Na página Create RAM Role, selecione Cloud Service para Principal Type e Object Storage para Principal Name.
Conceda permissões à função RAM para acessar o bucket de origem. Crie uma política personalizada que inclua apenas as permissões necessárias para a replicação ler dados do bucket de origem e iniciar a tarefa.
1. Na página Create Policy, clique em na aba JSON Editor. Cole o seguinte conteúdo no editor de políticas e substitua src-bucket pelo nome real do bucket de origem.
```
{
   "Version": "1",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "oss:ReplicateList",
            "oss:ReplicateGet"
         ],
         "Resource": [
            "acs:oss:*:*:src-bucket",
            "acs:oss:*:*:src-bucket/*"
         ]
      }
   ]
}
```
2. Após criar a política, retorne à página Roles. Localize a função, clique em Add Permissions e, no painel exibido, selecione a política personalizada recém-criada em Permissions Policy. Clique em OK. O principal é selecionado automaticamente.
Para replicar dados criptografados com KMS, conceda também à função RAM permissão para acessar o KMS.
1. Na página Roles, localize a função criada e clique em Add Permissions.
2. No painel, selecione AliyunKMSCryptoUserAccess em Permissions Policy e clique em OK. O principal é selecionado automaticamente.
Anote o ARN da função para uso posterior. Na página Roles, localize a função RAM criada e acesse sua página Basic Information. O formato é acs:ram::{Source-Account-ID}:role/{Role-Name}.

Etapa 2: Conceder permissões e preparar recursos

Conceda à função RAM permissão para gravar no bucket de destino. Na conta de destino, modifique a política do bucket de destino para permitir acesso de gravação à função RAM da conta de origem.
1. Faça login na conta de destino, acesse a página Bucket List e clique em no bucket de destino.
2. No painel de navegação à esquerda, escolha Permissions > Bucket Policy.
3. Clique em na aba Visual Editor e, em seguida, em Authorize to Receive Replicated Objects.
4. No painel exibido, configure os seguintes parâmetros:
  - Method to Obtain UID and RAM Role: Selecione Obtain from the RAM role ARN of the source.
  - Source RAM Role ARN: Insira o ARN da função RAM da conta de origem anotado na Etapa 1.
  - Authorization Purpose: Selecione Cross-account same-region replication.
5. Clique em Generate Policy e, em seguida, em Save.
(Opcional) Configure uma chave KMS na conta de destino. Para replicar objetos criptografados com KMS, configure primeiro uma chave KMS na conta de destino.
1. Faça login na página Instance Management do console KMS e, na mesma região do bucket da conta de origem, compre e ative uma instância KMS. Ao adquirir a instância KMS, certifique-se de que a Access Management Quota seja maior ou igual a 2 e mantenha os demais parâmetros com as configurações padrão.
  
  Nota
  A replicação entre contas de objetos criptografados com KMS depende do KMS. As regiões suportadas são limitadas pela disponibilidade do serviço. Para mais informações sobre as regiões suportadas, consulte Regiões e endpoints suportados para gerenciamento de chaves de software.
2. Na instância KMS, crie uma chave de software. O tipo deve ser uma chave não padrão (recomenda-se chave de software). Após a criação, anote o Key ARN na seção Configure Basic Information para usar posteriormente ao criar a regra de replicação.
3. Defina uma política para a chave criada. Adicione o ARN da função RAM criado pela conta de origem como Cross-account User. Este é o ARN da função criado nas etapas anteriores. Para mais informações, consulte Definir uma política de chave.
  
  Por padrão, essa operação concede à função as permissões necessárias, como Decrypt ( kms:Decrypt ) e GenerateDataKey ( kms:GenerateDataKey ), permitindo que a função use essa chave para criar objetos criptografados no bucket de destino. O assistente do console inclui as permissões necessárias por padrão, mas se você definir uma política de chave personalizada usando a OpenAPI, confirme manualmente se essas permissões foram adicionadas corretamente.

Etapa 3: Criar uma regra de Same-Region Replication

Após conceder as permissões necessárias, retorne ao console da conta de origem para criar uma regra de replicação e iniciar a tarefa.

Faça login na conta de origem, acesse a página Bucket List e clique em no bucket de origem.
No painel de navegação à esquerda, escolha Data Management > SRR.
Clique em SRR. Na caixa de diálogo exibida, configure os seguintes parâmetros:
1. Set Destination Bucket: Selecione Specify a bucket in another account, escolha a região do bucket de destino e insira o nome do bucket.
  - Objects to Replicate: Selecione Synchronize all files ou Objects with Specified Prefix. Os objetos no bucket de origem com os prefixos especificados serão replicados para o bucket de destino. Por padrão, é possível adicionar até 10 prefixos. Para aumentar esse limite, entre em contato com o . O limite máximo é 100.
  - Object Tagging:
    Nota
    Para configurar este parâmetro, atenda às seguintes condições:
    
    Você já definiu tags de objeto.
    
    As opções Replicate delete markers e Replicate deletes of specific versions não estão selecionadas.
    Ao marcar a caixa de seleção Configure Rules, é possível copiar objetos com tags específicas para o bucket de destino. É permitido adicionar até 10 tags (pares chave-valor). Após adicionar as tags, selecione as seguintes políticas de filtragem:
    - Include all tags: Um objeto é replicado se todas as suas tags estiverem incluídas no conjunto de tags especificado na regra de filtro.
    - Include any one tag: Um objeto é replicado se qualquer uma de suas tags estiver no conjunto de tags especificado na regra de filtro.
  - Replicate KMS-encrypted objects: Se o objeto de origem estiver criptografado com KMS e você quiser manter a criptografia na réplica, selecione Replicate e forneça a chave KMS configurada na conta de destino na Etapa 2. Caso selecione Do not replicate, o OSS não replica arquivos criptografados com KMS.
    
    Nota
    Use as operações HeadObject e GetBucketEncryption para verificar o status de criptografia do objeto de origem e do bucket de destino, respectivamente.
  - Role for Authorization: Na lista suspensa, selecione a função RAM criada na conta de origem na Etapa 1.
2. Set Replication Policy:
  - Replicate delete operations (Esta opção aparece quando o versionamento está desativado para o bucket de origem): Escolha se deseja sincronizar operações de exclusão do bucket de origem para o de destino.
    - Yes: Replica operações de criação, atualização e exclusão para manter o bucket de destino consistente com o de origem. Indicado para ambientes onde vários usuários ou aplicativos precisam compartilhar e acessar o mesmo conjunto de dados. No entanto, com essa configuração, quando um objeto é excluído do bucket de origem (manualmente ou por regra de ciclo de vida), o OSS também exclui o objeto correspondente no bucket de destino, sem possibilidade de recuperação.
    - No: Replica apenas objetos novos e atualizados. A exclusão de um objeto no bucket de origem não afeta o bucket de destino. Em cenários de recuperação de desastres, selecionar No evita a replicação de exclusões acidentais da origem, aumentando a segurança dos dados.
  - Replicate historical data: Escolha se deseja replicar objetos existentes no bucket de origem antes da criação da regra de replicação. Essa operação sobrescreve objetos com o mesmo nome no bucket de destino. Para evitar perda de dados, recomendamos ativar o versionamento tanto no bucket de origem quanto no de destino.
  - Replicate delete markers (Esta opção aparece quando o versionamento está ativado para o bucket de origem): Escolha se deseja replicar marcadores de exclusão do bucket de origem para o de destino.
    - Replicate: Quando um objeto é excluído do bucket de origem sem especificar um ID de versão, o OSS replica o marcador de exclusão criado na origem para o bucket de destino. Adequado para cenários que exigem compartilhamento e acesso ao mesmo conjunto de dados, garantindo a consistência do estado dos dados entre os buckets.
      
      Importante
      Se você configurar essa política, quando um objeto for excluído do bucket de origem (manualmente ou por regra de ciclo de vida), o OSS também criará um marcador de exclusão no bucket de destino, tornando os dados nele inacessíveis.
    - Do not replicate (Recomendado para cenários de recuperação de desastres): O OSS não replica marcadores de exclusão criados no bucket de origem para o de destino. Isso evita efetivamente a perda de dados no bucket de destino devido a exclusões acidentais ou automatizadas por regras de ciclo de vida na origem.
  - Replicate deletes of specific versions (Esta opção aparece quando o versionamento está ativado para o bucket de origem): Escolha se deseja replicar a exclusão permanente de uma versão específica de objeto do bucket de origem para o de destino.
    - Replicate: Quando uma versão específica de um objeto de origem (incluindo versões atuais e anteriores) é excluída permanentemente, o OSS também exclui permanentemente a versão correspondente no bucket de destino. Recomendado para cenários que exigem identidade total entre os dados de origem e de destino.
      
      Importante
      Com essa configuração, não é possível recuperar no bucket de destino as versões de objetos excluídas permanentemente da origem. Use esta opção com cautela.
    - Do not replicate (Recomendado para cenários de recuperação de desastres): Quando uma versão específica de um objeto de origem é excluída permanentemente, o OSS não exclui a versão correspondente no bucket de destino. Isso impede que operações de exclusão permanente na origem afetem a segurança dos dados no destino.
    Se um objeto for carregado no bucket de origem via upload multipartido, o OSS replica cada operação de upload de parte para o bucket de destino. O OSS também replica o objeto final gerado após a operação CompleteMultipartUpload. Para mais informações sobre o comportamento de replicação com versionamento ativado, consulte Same-Region Replication com versionamento.
Nota
Uma vez criada, uma regra de Same-Region Replication não pode ser modificada ou excluída. Revise todas as configurações cuidadosamente antes de clicar em OK. Para interromper a replicação, desative a tarefa de replicação.
Após confirmar que todas as configurações estão corretas, clique em OK e depois em Confirm Enable.

A tarefa de replicação inicia de 3 a 5 minutos após a configuração da regra. Acompanhe o progresso na aba SRR do bucket de origem. Como a replicação na mesma região é um processo assíncrono (quase em tempo real), o tempo necessário para replicar dados depende do volume e geralmente varia de alguns minutos a várias horas.

Perguntas frequentes

Posso usar uma política JSON para permissões de bucket?

Sim. Selecione Add Policy by Syntax na página de política do bucket de destino para obter uma configuração mais flexível. Observe os seguintes pontos ao usar uma política JSON:

Uma nova política sobrescreve qualquer política de bucket existente. Certifique-se de que a nova política inclua todas as regras de autorização necessárias.
Defina o campo Principal na política como o ARN da função RAM na conta de origem.
Se o nome da função contiver letras maiúsculas, converta-as para minúsculas na política. Por exemplo, uma função chamada AliyunOssDrsRole deve ser escrita como aliyunossdrsrole na política.
Forneça com precisão os UIDs das contas de origem e de destino, bem como o nome do bucket de destino.

Veja abaixo um exemplo de política:

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:ReplicateList",
                "oss:ReplicateGet",
                "oss:ReplicatePut",
                "oss:ReplicateDelete"
            ],
            "Principal": {
                "RAM": [
                    "acs:ram::{Source-Account-ID}:role/{role-name}"
                ]
            },
            "Resource":[
                "acs:oss:*:{Destination-Account-ID}:{Destination-Bucket-Name}",
                "acs:oss:*:{Destination-Account-ID}:{Destination-Bucket-Name}/*"
            ]
        }
    ]
}

Object Storage Service:Replicação na mesma região entre contas