Disponibilité et durabilité des données (original) (raw)

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, la fonctionnalité de réplication turbo pour les emplacements birégionaux et 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é diffé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 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 régionale, 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.
    Pour en savoir plus sur les considérations spécifiques à la région, consultez la page Zones géographiques et régions.
• 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 une paire de régions 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 réplication 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", les emplacements multirégionaux et birégionaux Cloud Storage fournissent 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 objectif de temps de récupération 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.

Cloud Storage propose également une fonctionnalité de réplication entre buckets qui peut être utilisée pour répliquer des données entre des buckets indépendants afin de répondre à des besoins de réplication de données supplémentaires qui ne sont pas satisfaits par les emplacements birégionaux ou multirégionaux.

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 reprise après sinistre 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 en savoir plus, 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 écrits.
• 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 souhaiter 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 indépendants, chacun avec sa propre configuration (emplacement de stockage, chiffrement, accès et classe de stockage, par exemple). Elle est particulièrement adaptée aux cas suivants :

• 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éger des 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 alertes en cas de modification des buckets source et de destination. Vous pouvez activer la réplication entre buckets sur les nouveaux buckets que vous créez et sur les buckets existants.

Pour les buckets dont le taux de modification des objets est inférieur à 3 000 par seconde et dont les objets sont inférieurs à 1 Gio, la réplication entre buckets prend généralement quelques minutes à quelques dizaines de minutes, mais aucune limite supérieure spécifique n'est acceptée. De plus, les buckets dont les taux de modification sont plus élevés ou qui contiennent des objets plus volumineux peuvent s'attendre à des délais de réplication plus longs.

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

Limites

• La réplication entre buckets n'est pas compatible avec les buckets avec espace de noms hiérarchique.
• 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 de code temporel (par exemple, timeCreated et timeUpdated) 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].
• Étant donné que la réplication entre buckets peut être utilisée pour répliquer des données entre des buckets situés dans n'importe quel emplacement Google Cloud , les performances de la réplication entre buckets varient en fonction des emplacements sélectionnés. Par conséquent, la réplication entre buckets n'offre pas d'objectif de reprise après sinistre.
• Les objets qui se trouvent déjà dans le bucket lorsqu'un job de réplication est créé ne sont pas répliqués automatiquement. Seuls les objets nouveaux et modifiés sont répliqués. Pour répliquer des objets existants, créez un job de transfert ponctuel à l'aide du service de transfert de stockage depuis votre bucket existant vers le nouveau bucket. Pour obtenir des instructions, consultez la section Créer des transferts.

Surveillance des performances

Cloud Storage surveille les objets non répliqués les plus anciens dans les buckets birégionaux et multirégionaux à l'aide de la réplication par défaut ou de la réplication turbo. Si un objet reste non répliqué plus longtemps que la durée de son objectif de reprise après sinistre, il est considéré comme étant en dehors de l'objectif de reprise après sinistre. Chaque minute au cours de laquelle un ou plusieurs objets sont en dehors de l'objectif de reprise après sinistre 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 9 h à 9 h 20 et qu'un autre objet a généré 10 minutes de comportement défaillant de 9 h 15 à 9 h 25, on considère que deux objets sont en dehors de l'objectif de reprise après sinistre pour le mois en question. Le nombre total de minutes de comportement défaillant pour le mois est de 25 minutes car de 9 h à 9 h 25, au moins un objet était en dehors de l'objectif de reprise après sinistre.

• Pour les buckets utilisant la réplication turbo, l'objectif de reprise après sinistre pour les objets est de 15 minutes.
• Pour les buckets utilisant la réplication par défaut, l'objectif de reprise après sinistre 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 d'objectif de reprise après sinistre.

Dans la console Google Cloud , le graphique Pourcentage de minutes en dehors de l'objectif de reprise après sinistre vous permet de surveiller le pourcentage de minutes de comportement défaillant au cours des 30 derniers jours pour votre bucket lorsque vous utilisez la réplication par défaut ou la réplication turbo dans des buckets birégionaux ou multirégionaux. Cet indicateur de niveau de service permet de surveiller la conformité du temps de réplication mensuel du bucket. De même, le graphique Pourcentage d'objets hors cible suit les réplications d'objets qui n'ont pas eu lieu dans l'objectif de reprise après sinistre. 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

• Activez la réplication turbo sur un bucket birégional existant.
• Apprenez-en davantage sur les tarifs de la réplication turbo.
• Déplacez les données vers un autre bucket dans un nouvel emplacement.