Object Storage Service:Cross-account cross-region replication

La configuration de la réplication inter-comptes nécessite des actions sur les comptes source et de destination. Elle se déroule en trois étapes :

1. Compte source : Créez un rôle RAM pour la réplication des données et accordez-lui le privilège minimum nécessaire pour lire les données du bucket source.

2. Compte de destination : Modifiez la Bucket Policy du bucket de destination afin d'accorder des permissions d'écriture au rôle RAM du compte source.

3. Compte source : Retournez sur le compte source pour créer une règle de réplication interrégionale (CRR) liant les buckets source et de destination, puis lancez la tâche de réplication.

Étape 1 : Créer et autoriser un rôle RAM

1. Créez un rôle RAM. Accédez à la page Create Role. Définissez le paramètre Principal Type sur Cloud Service et le paramètre Principal Name sur OSS.

2. Accordez au rôle RAM les permissions d'accès au bucket source : créez une politique personnalisée incluant uniquement les permissions nécessaires à la lecture des données du bucket source pour leur réplication.

   1. Sur la page Create Policy, cliquez sur l'onglet JSON Editor. Collez la politique suivante dans l'éditeur et remplacez src-bucket par le nom de votre bucket source.

      {
         "Version": "1",
         "Statement": [
            {
               "Effect": "Allow",
               "Action": [
                  "oss:ReplicateList",
                  "oss:ReplicateGet"
               ],
               "Resource": [
                  "acs:oss:*:*:src-bucket",
                  "acs:oss:*:*:src-bucket/*"
               ]
            }
         ]
      }

   2. Une fois la politique créée, accédez à la page Roles, recherchez le rôle créé, puis cliquez sur Grant Permission. Dans le panneau qui s'affiche, le principal est automatiquement renseigné. Pour la politique, sélectionnez la politique personnalisée créée à l'étape précédente, puis cliquez sur Confirm Grant.

3. (Facultatif) Accordez au rôle RAM les permissions d'accès à Key Management Service (KMS). Si vous utilisez KMS pour chiffrer les données répliquées dans le bucket de destination, donnez au rôle RAM l'accès à KMS.

   Sur la page Roles, localisez le rôle créé et cliquez sur Grant Permission. Le principal se remplit automatiquement dans le panneau affiché. Sous Policy, sélectionnez AliyunKMSCryptoUserAccess, puis cliquez sur Confirm Grant.

4. Notez l'ARN du rôle. Sur la page Roles, trouvez le rôle RAM créé, accédez à sa page Basic Information, puis copiez l'ARN du rôle. L'ARN suit le format acs:ram::{source-account-uid}:role/{role-name}.

Étape 2 : Autoriser le rôle RAM et préparer les ressources

1. Autorisez le rôle RAM à écrire des données dans le bucket de destination : sur le compte de destination, modifiez la Bucket Policy du bucket cible pour accorder l'accès en écriture au rôle RAM du compte source.

   1. Connectez-vous au compte de destination et accédez à la page Buckets. Cliquez sur le bucket de destination.

   2. Dans le volet de navigation de gauche, choisissez Access Control > Bucket Policy.

   3. Cliquez sur l'onglet Add in GUI, puis sur Receive Objects to Replicate.

   4. Dans le panneau qui s'affiche, configurez les paramètres suivants :

      • Obtain UID and RAM Role From : Sélectionnez Source RAM role ARN for replication.

      • Source RAM Role ARN for Replication : Saisissez l'ARN du rôle RAM du compte source noté à l'étape 1.

      • Purpose : Choisissez Cross-account replication.

   5. Cliquez sur Generate Policy, puis sur Save.

2. (Facultatif) Préparez une clé KMS dans le compte de destination : pour répliquer des objets chiffrés par KMS, créez d'abord une clé KMS dans le compte de destination.

   1. Connectez-vous à la console KMS et accédez à la page Instance Management. Dans la même région que le bucket source, achetez et activez une instance KMS. Lors de l'achat, assurez-vous que la valeur Access Management Quantity est supérieure ou égale à 2. Conservez les paramètres par défaut pour les autres options.

      Remarque

      La réplication inter-comptes d'objets chiffrés par KMS dépend de ce service. Les régions prenant en charge cette fonctionnalité sont donc limitées par la disponibilité de KMS. Pour plus d'informations sur les régions compatibles, consultez la rubrique Régions et endpoints pris en charge pour la gestion des clés logicielles.

   2. Sous l'instance KMS, créez une clé logicielle. Le type de clé doit être non par défaut (une clé logicielle est recommandée). Une fois la clé créée, notez son ARN dans la section Basic Information ; vous en aurez besoin lors de la création de la règle de réplication.

   3. Définissez une politique de clé pour la clé créée. Lors de la configuration, spécifiez pour le paramètre Cross-account User l'ARN du rôle RAM créé par le compte source, c'est-à-dire l'ARN obtenu lors des étapes précédentes. Pour plus de détails, reportez-vous à la rubrique Définir une politique de clé.

      Par défaut, cette opération accorde au rôle les permissions nécessaires, telles que le déchiffrement ( kms:Decrypt ) et la génération de clés de données ( kms:GenerateDataKey ), lui permettant ainsi d'utiliser cette clé pour créer des objets chiffrés dans le bucket de destination. Bien que l'assistant de la console inclue généralement les permissions requises, si vous définissez une politique de clé personnalisée via une API, assurez-vous manuellement que ces permissions sont correctement ajoutées.

Étape 3 : Créer une règle de réplication interrégionale

Après avoir accordé les permissions requises, retournez sur la console du compte source pour créer une règle de réplication et démarrer la tâche.

1. Connectez-vous au compte source et accédez à la page Buckets. Cliquez sur le bucket source.

2. Dans le volet de navigation de gauche, choisissez Data Management > Cross-Region Replication.

3. Cliquez sur Cross-Region Replication. Dans la boîte de dialogue qui s'affiche, configurez les paramètres suivants :

   1. Configure Destination Bucket : Sélectionnez Specify a bucket that belongs to another Alibaba Cloud account, choisissez la région où se trouve le bucket de destination, puis saisissez son nom.

      • Objects to Replicate : Choisissez Synchronize all files ou Objects with Specified Prefix. Les objets du bucket source possédant le préfixe spécifié seront répliqués vers le bucket de destination. Par défaut, vous pouvez ajouter jusqu'à 10 préfixes. Pour augmenter cette limite à 100, contactez le .

      • Object Tagging :

        Remarque

        Pour configurer ce paramètre, remplissez les conditions suivantes :

        • Vous avez configuré des tags d'objet.

        • Les cases Replicate delete markers et Replicate permanent deletions of specific versions ne sont pas cochées.

        Cochez la case Configure Rules pour répliquer les objets portant des tags spécifiques vers le bucket de destination. Vous pouvez ajouter jusqu'à 10 tags (paires clé-valeur). Après l'ajout des tags, sélectionnez l'une des politiques de filtrage suivantes :

        • Include all tags : OSS réplique un objet uniquement si tous ses tags correspondent à ceux spécifiés dans la règle de filtrage.

        • Include any one tag : OSS réplique un objet si au moins l'un de ses tags correspond à un tag spécifié dans la règle de filtrage.

      • Replicate KMS Encrypted Objects : Si les objets sources sont chiffrés avec KMS et que vous souhaitez qu'ils restent chiffrés à destination, sélectionnez Replicate et fournissez l'ARN de la clé KMS du compte de destination préparée à l'étape 2. Si vous choisissez Do not replicate, les objets chiffrés par KMS ne seront pas répliqués vers le bucket de destination.

        Remarque

        Vous pouvez vérifier l'état de chiffrement de l'objet source et du bucket de destination en appelant respectivement les opérations HeadObject et GetBucketEncryption.

      • RAM Role : Dans la liste déroulante, sélectionnez le rôle RAM créé dans le compte source à l'étape 1.

   2. Configure Replication Policy :

      • Replicate Delete Operations (cette option apparaît lorsque le versioning est désactivé pour le bucket source) : Indiquez si vous souhaitez synchroniser les suppressions d'objets du bucket source vers le bucket de destination.

        • Yes : Synchronise les opérations de création, de modification et de suppression pour maintenir la cohérence entre le bucket de destination et le bucket source. Cette option convient aux environnements multi-utilisateurs ou applicatifs nécessitant le partage et l'accès au même jeu de données. Toutefois, avec cette politique, lorsqu'un objet du bucket source est supprimé manuellement ou automatiquement par une règle de cycle de vie, l'objet correspondant dans le bucket de destination est également supprimé et ne peut pas être récupéré.

        • No : Synchronise uniquement les nouveaux objets et les objets modifiés. Les suppressions d'objets dans le bucket source n'affectent pas le bucket de destination. Dans les scénarios de reprise après sinistre, sélectionnez No pour éviter que des suppressions accidentelles dans le bucket source ne soient répliquées vers le bucket de sauvegarde, renforçant ainsi la sécurité des données.

      • Replicate Historical Data : Décidez s'il faut répliquer les données présentes dans le bucket source avant l'entrée en vigueur de la règle. Cette opération écrase les objets portant le même nom dans le bucket de destination. Pour éviter toute perte de données, nous vous recommandons d'activer le versioning sur les buckets source et de destination.

      • Replicate delete markers (cette option apparaît lorsque le versioning est activé pour le bucket source) : Choisissez de répliquer ou non les marqueurs de suppression du bucket source vers le bucket de destination.

        • Replicate : Lorsqu'un objet est supprimé du bucket source sans qu'un ID de version soit spécifié, OSS synchronise le marqueur de suppression vers le bucket de destination. Cela convient aux scénarios exigeant le partage et l'accès au même jeu de données, garantissant la cohérence entre les buckets source et de destination.

          Important

          Si vous configurez cette politique, lorsqu'un objet du bucket source est supprimé manuellement ou automatiquement par une règle de cycle de vie, un marqueur de suppression est également synchronisé vers le bucket de destination, rendant les données inaccessibles dans ce dernier.

        • Do not replicate (recommandé pour les scénarios de reprise après sinistre) : Les marqueurs de suppression créés dans le bucket source ne sont pas répliqués vers le bucket de destination. Cela empêche efficacement la perte de données dans le bucket de destination due à des suppressions accidentelles ou automatiques par des règles de cycle de vie dans le bucket source.

      • Replicate permanent deletions of specific versions (cette option apparaît lorsque le versioning est activé pour le bucket source) : Déterminez s'il faut répliquer les suppressions définitives de versions d'objets spécifiques du bucket source vers le bucket de destination.

        • Replicate : Lorsque vous supprimez définitivement une version spécifique d'un objet source (version actuelle ou non), OSS supprime également de manière permanente la version correspondante dans le bucket de destination. Cette option est adaptée aux scénarios nécessitant une cohérence totale des données entre les buckets source et de destination.

          Important

          Avec cette politique, les versions d'objets supprimées définitivement du bucket source ne peuvent pas être récupérées dans le bucket de destination. Utilisez cette option avec prudence.

        • Do not replicate (recommandé pour les scénarios de reprise après sinistre) : La suppression définitive d'une version spécifique d'un objet source n'entraîne pas la synchronisation de la suppression de la version correspondante dans le bucket de destination. Cela évite que les opérations de suppression définitive dans le bucket source ne compromettent la sécurité des données dans le bucket de destination.

   3. (Facultatif) Configure Replication Acceleration :

      • Transfer Acceleration : Si une tâche de réplication implique des régions situées à la fois en Chine continentale et hors de Chine continentale, activez cette fonctionnalité pour améliorer les vitesses de transfert. Des frais Transfer Acceleration supplémentaires s'appliquent.

      • Replication Time Control (RTC) : Une fois activé, RTC maintient la latence de réplication pour la plupart des données incrémentielles sous les 10 minutes. Cette fonctionnalité n'est prise en charge qu'entre certaines régions et entraîne des frais RTC de réplication interrégionale supplémentaires. Pour plus d'informations, consultez la rubrique Présentation de RTC.

4. Après avoir confirmé l'exactitude de toutes les configurations, cliquez sur OK, puis sur Confirm Enable.

   La tâche de réplication démarre quelques minutes après la création de la règle. La réplication des données est un processus asynchrone. Le temps nécessaire dépend de la taille des objets, de leur nombre et de la latence réseau interrégionale ; il peut varier de quelques minutes à plusieurs heures. Vous pouvez suivre la progression de la réplication, y compris l'état de synchronisation des données historiques et incrémentielles, sous l'onglet Cross-Region Replication du bucket source.

FAQ

Pourquoi les changements de classe de stockage ou d'heure d'accès ne sont-ils pas répliqués ?

La réplication des données n'est déclenchée que par des modifications du contenu des objets, comme la création, la suppression ou la modification d'un objet. Les changements de classe de stockage effectués via une règle de cycle de vie ou une opération CopyObject, ainsi que les mises à jour de l'heure du dernier accès (LastAccessTime), n'impliquent pas l'écriture de nouveau contenu d'objet. Par conséquent, ces actions ne déclenchent pas de nouvelle tâche de réplication et OSS ne met pas à jour la réplique de l'objet dans le bucket de destination.

Solutions :

• Synchroniser la classe de stockage : Configurez une règle de cycle de vie identique sur le bucket de destination pour garantir les mêmes transitions de classe de stockage.

• Mettre à jour LastAccessTime : Pour actualiser l'heure du dernier accès d'un objet de destination, accédez directement à cet objet dans le bucket de destination (par exemple, en effectuant une requête GetObject) afin de déclencher la mise à jour de son champ LastAccessTime.

Les objets chargés via un chargement multipart sont-ils répliqués ?

Lorsque vous chargez un objet via un chargement multipart, OSS réplique chaque partie vers le bucket de destination. Une fois qu'une opération CompleteMultipartUpload fusionne les parties dans le bucket source, OSS réplique ensuite l'objet complet en tant qu'entité unique vers le bucket de destination.

Autorisation simplifiée du rôle RAM

Oui. Pour une autorisation rapide, accordez directement la politique système AliyunOSSFullAccess fournie par Alibaba Cloud au rôle RAM créé. Cependant, cette politique accorde toutes les permissions sur toutes les ressources OSS de votre compte. En raison de son périmètre étendu, elle n'est pas recommandée pour les environnements de production.

Utilisation d'une politique JSON pour les permissions

Oui. Sur la page Bucket Policy du bucket de destination, sélectionnez Add Rule by Syntax pour une configuration plus flexible. Gardez les points suivants à l'esprit lors de l'utilisation d'une politique JSON :

• Une nouvelle politique remplace toute Bucket Policy existante. Assurez-vous que la nouvelle politique inclut toutes les règles d'autorisation requises.

• Le champ Principal de la politique doit contenir l'ARN du rôle RAM du compte source.

• Si le nom du rôle contient des majuscules, convertissez-les en minuscules dans la politique. Par exemple, le rôle AliyunOssDrsRole doit s'écrire aliyunossdrsrole dans la politique.

• Saisissez avec précision l'UID du compte source, le nom du bucket de destination et l'UID du compte de destination.

Le code suivant fournit un exemple de politique :

{
    "Version":"1",
    "Statement":[
        {
            "Effect":"Allow",
            "Action":[
                "oss:ReplicatePut",
                "oss:ReplicateDelete"
            ],
            "Principal": [
                "arn:ram::{source-account-uid}:role/{role-name}"
            ],
            "Resource":[
                "acs:oss:*:{destination-account-uid}:{destination-bucket-name}",
                "acs:oss:*:{destination-account-uid}:{destination-bucket-name}/*"
            ]
        }
    ]
}

Résolution des échecs de création de règles de réplication inter-comptes

Si vous ne parvenez pas à créer une règle de réplication inter-comptes avec le rôle de service par défaut ou un rôle RAM personnalisé, l'échec ne provient généralement pas du rôle lui-même. Dans la plupart des cas, le champ Principal de la Bucket Policy du bucket de destination n'est pas défini sur l'ARN de rôle assumé STS du rôle RAM du compte source. Par conséquent, le compte de destination n'a pas réellement autorisé le rôle. Vérifiez si le champ Principal utilise le format arn:sts::{source-account-uid}:assumed-role/{role-name}/*.

Les erreurs courantes incluent :

• UID du compte source incorrect : L'UID doit appartenir au compte source, et non au compte de destination.

• Non-concordance du nom de rôle : Le nom du rôle doit correspondre exactement au rôle RAM créé à l'étape 1. Si le nom contient des majuscules, convertissez-les en minuscules.

• Type d'ARN incorrect : Le champ Principal requiert l'ARN de rôle assumé STS commençant par arn:sts::, et non un ARN de rôle RAM commençant par acs:ram: ou arn:ram:.

Pour éviter les erreurs lors de la rédaction manuelle de la politique JSON, accédez à la page Bucket Policy du bucket de destination, cliquez sur l'onglet Add in GUI, puis sur Receive Objects to Replicate pour laisser la console générer la politique.