Disponibilité et durabilité des données

Cette page traite des concepts liés à la disponibilité et à la durabilité des données dans Cloud Storage, y compris la manière dont Cloud Storage stocke les données de manière redondante, le comportement de réplication par défaut pour les emplacements birégionaux et multirégionaux, ainsi que la fonctionnalité de réplication entre buckets.

Concepts clés

  • Cloud Storage est conçu pour offrir une durabilité annuelle de 99,999999999 % (onze fois le chiffre 9).

    • Pour ce faire, Cloud Storage utilise un codage d'effacement et stocke les données de manière redondante sur plusieurs appareils situés dans différentes zones de disponibilité.

    • Cloud Storage stocke de manière redondante les objets qui y sont écrits dans au moins deux zones de disponibilité diférentes avant de considérer l'écriture comme réussie.

    • Les sommes de contrôle sont stockées et régulièrement revalidées afin de vérifier de manière proactive l'intégrité de toutes les données au repos ainsi que de détecter toute corruption des données en transit. Si nécessaire, des corrections sont appliquées automatiquement grâce aux données redondantes.

  • La disponibilité mensuelle des données stockées dans Cloud Storage dépend de la classe de stockage des données et du type d'emplacement du bucket. Pour en savoir plus, consultez la section Classes de stockage disponibles.

  • Les objets stockés dans un bucket birégional ou un multirégional sont stockés de manière redondante dans au moins deux zones géographiques distinctes.

    • Pour les emplacements birégionaux, vous sélectionnez les régions spécifiques dans lesquelles vos objets sont stockés.

    • Pour les emplacements multirégionaux, les centres de données spécifiques utilisés pour le stockage des données sont déterminés par Cloud Storage si nécessaire, mais sont situés dans la limite géographique de l'emplacement multirégional et sont séparés par au moins 100 miles. Cela permet une redondance entre les régions pour un coût de stockage inférieur à celui des emplacements birégionaux.

    • Dans le cas peu probable d'une panne à l'échelle de la région, due par exemple à une catastrophe naturelle, les buckets birégionaux et multirégionaux restent disponibles, sans qu'il soit nécessaire de modifier les chemins de stockage.

  • Les objets stockés dans des buckets birégionaux et multirégionaux sont généralement répliqués sur plusieurs zones géographiques à l'aide de la réplication par défaut.

    • Si l'un des emplacements où un objet est stocké devient indisponible après son importation, mais avant sa réplication dans le deuxième emplacement, la cohérence forte de Cloud Storage garantit que les versions obsolètes de l'objet ne sont pas diffusées et les écrasements ultérieurs ne sont pas annulés lorsque la région redevient disponible.

    • Les objets stockés dans des emplacements birégionaux peuvent éventuellement utiliser la réplication turbo pour obtenir une réplication plus rapide et plus prévisible entre les régions.

  • Pour obtenir une redondance entre région d'appairage non disponible en tant que zone birégionale, envisagez de créer un bucket distinct dans chaque région et d'utiliser des transferts basés sur des événements du service de transfert de stockage ou la reproduction entre buckets pour conserver les buckets synchronisés.

Redondance entre les régions

Là où les modèles de stockage traditionnels s'appuient souvent sur une approche active-passive avec des emplacements géographiques "principaux" et "secondaires", Cloud Storage fournit une architecture en mode actif/actif basée sur un bucket unique avec redondance entre les régions. Cela simplifie le processus de reprise après sinistre en éliminant la nécessité de faire répliquer les données d'un bucket à un autre par les utilisateurs ou de basculer manuellement vers le bucket secondaire en cas de temps d'arrêt de la région principale.

Cloud Storage comprend toujours l'état actuel d'un bucket et diffuse de manière transparente les objets d'une région disponible selon les besoins. Par conséquent, les buckets birégionaux et multirégionaux sont conçus pour avoir un RTO de zéro et les défaillances régionales temporaires sont normalement invisibles pour utilisateurs ; En cas de panne régionale, les buckets birégionaux continuent de diffuser automatiquement toutes les données ayant été répliquées entre les régions.

Cependant, la redondance entre les régions se produit de manière asynchrone. Par conséquent, toutes les données dont la réplication entre les régions n'est pas achevée avant l'indisponibilité d'une région sont inaccessibles jusqu'à ce que la région en panne soit de nouveau en ligne. Des données risquent d'être perdues dans le cas très peu probable de destruction physique de la région.

La réplication par défaut dans Cloud Storage est conçue pour assurer une redondance entre les régions pour 99,9 % des objets nouvellement écrits dans un délai d'une heure et pour 100 % des objets nouvellement écrits dans un délai de 12 heures. Les nouveaux objets incluent les importations, les réécritures, les copies et les compositions.

Réplication turbo

La réplication turbo permet d'accélérer la redondance entre les régions pour les données de vos buckets birégionaux, ce qui réduit le risque d'exposition aux pertes de données et permet d'assurer la continuité des services à la suite d'une panne régionale. Lorsqu'elle est activée, la réplication turbo est conçue pour répliquer 100% des objets nouvellement écrits dans les deux régions qui constituent l'emplacement birégional dans l'objectif de point de reprise de 15 minutes, quelle que soit la taille de l'objet.

Notez que même pour la réplication par défaut, la réplication de la plupart des objets se termine en quelques minutes.

Tandis que la redondance entre régions et la réplication turbo contribuent à assurer la continuité des activités et la reprise après sinistre (BCDR), les administrateurs doivent planifier et mettre en œuvre une architecture BCDR complète qui est adaptée à leur charge de travail.

Pour plus d'informations, consultez le guide par étapes sur la conception de la reprise après sinistre pour les applications dans Google Cloud.

Limites

  • La réplication turbo n'est disponible que pour les buckets situés dans des emplacements birégionaux.

  • La réplication turbo ne peut pas être gérée via l'API XML, y compris pour la création d'un bucket avec la réplication turbo activée.

  • Lorsque la réplication turbo est activée sur un bucket, un délai de 10 secondes peut être nécessaire avant qu'elle ne s'applique aux nouveaux objets.

  • Les écritures d'objets qui ont commencé avant l'activation de la réplication turbo sur un bucket sont répliquées sur plusieurs régions au taux de réplication par défaut.

    • La composition d'objets qui utilise des objets sources écrits à l'aide de la réplication par défaut au cours des 12 dernières heures crée un objet composite qui utilise également la réplication par défaut.

Réplication entre buckets

Dans certains cas, vous pouvez conserver une copie de vos données dans un deuxième bucket. La réplication entre buckets copie de manière asynchrone les objets nouveaux et mis à jour d'un bucket source vers un bucket de destination.

La réplication entre buckets diffère de la réplication par défaut et de la réplication turbo, car vos données existent dans deux buckets, chacun avec ses propres configurations (emplacement de stockage, chiffrement, accès et classe de stockage, par exemple). Par conséquent, il offre la récupération et la disponibilité des données, mais il convient également pour :

  • Souveraineté des données : conservez les données dans des régions géographiquement éloignées.
  • Gérer des versions de développement et de production distinctes : créez des buckets et des espaces de noms distincts pour que le développement n'affecte pas votre charge de travail de production.
  • Partager des données : répliquer des données dans un bucket appartenant à un fournisseur ou à un partenaire.
  • Agrégation de données : combinez les données de différents buckets dans un seul bucket pour exécuter des charges de travail d'analyse.
  • Gérer les coûts, la sécurité et la conformité : conservez vos données sous différentes propriétés, classes de stockage et périodes de conservation.

La réplication entre buckets utilise le service de transfert de stockage pour répliquer les objets et Pub/Sub pour recevoir des notifications en cas de modification des buckets source et de destination. La réplication interbuckets peut être activée sur les buckets que vous créez et sur les buckets existants. La plupart des objets peuvent être répliqués en quelques minutes, tandis que les objets de plus d'un gigaoctet peuvent prendre plusieurs heures.

Pour savoir comment utiliser la réplication entre buckets, consultez la section Utiliser la réplication entre buckets.

Limites

  • Les suppressions d'objets dans le bucket source ne sont pas répliquées dans le bucket de destination.

  • Les configurations du cycle de vie des objets ne sont pas répliquées.

  • Lorsque des objets sont répliqués, les métadonnées d'horodatage (timeCreated et timeUpdated, par exemple) ne sont pas conservées. Pour en savoir plus sur la conservation des métadonnées, consultez la section Transferts entre des buckets Cloud Storage.

Surveillance des performances

Cloud Storage surveille les objets non répliqués les plus anciens. Si un objet reste non répliqué plus longtemps que la durée de son RPO (objectif de point de récupération), il est considéré comme étant hors RPO. Chaque minute au cours de laquelle un ou plusieurs objets sont hors RPO est comptabilisée comme une minute de comportement défaillant.

Par exemple, si un objet a généré 20 minutes de comportement défaillant de 9h00 à 9h20 et qu'un autre objet a généré 10 minutes de comportement défaillant de 9h15 à 9h25, on considère que deux objets sont hors RPO pour le mois en question. Le nombre total de minutes de comportement défaillant pour le mois est de 25 minutes car de 9h00 à 9h25, au moins un objet était hors RPO.

  • Pour les buckets utilisant la réplication turbo, le RPO pour les objets est de 15 minutes.

  • Pour les buckets utilisant la réplication par défaut, le RPO pour les objets est de 12 heures.

    • Pour les buckets qui utilisent la réplication par défaut, les objets sont généralement répliqués en une heure ou moins.

  • La réplication entre buckets ne fournit pas de RPO.

Dans la console Google Cloud, le graphique Pourcentage de minutes hors RPO vous permet de surveiller le pourcentage de minutes de comportement défaillant au cours des 30 derniers jours pour votre bucket. Cet indicateur de niveau de service permet de surveiller la conformité du temps de réplication mensuel du bucket. De même, le pourcentage d'objets hors cible suit les réplications d'objets qui n'ont pas eu lieu dans le RPO. Cet indicateur de niveau de service permet de surveiller la conformité du volume de réplication mensuel du bucket. Pour en savoir plus, consultez les pages Surveillance Cloud Storage et Contrat de niveau de service Cloud Storage.

Étapes suivantes