Description de la haute disponibilité et de la reprise après incident pour IBM Cloud® Object Storage

La haute disponibilitéLa capacité d'un service ou d'une charge de travail à résister aux défaillances et à continuer à fournir une capacité de traitement selon un niveau de service prédéfini. (HA) est la capacité d'un service à rester opérationnel et accessible en cas de défaillance inattendue.
La reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception de haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.

IBM Cloud Object Storage est un service global qui vous permet de configurer la résilience des données de stockage tout en maintenant la haute disponibilité. Pour plus d'informations, voir Accord de niveau de service(SLA). Vous pouvez également trouver la région disponible et les emplacements des centres de données dans la documentation sur la disponibilité des services et de l'infrastructure au niveau local.

Architecture à haute disponibilité

Object Storage est un service global et vous avez le choix de configurer la résilience du stockage. La résilience d'un seau est définie par le point d'extrémité utilisé pour le créer, c'est-à-dire interrégional, régional et site unique.

La résilience interrégionale répartira vos données dans plusieurs zones métropolitaines
La résilience régionale permettra de diffuser les données dans une seule zone métropolitaine
La résilience d'un centre de données unique répartit les données entre plusieurs appareils au sein d'un même centre de données

Les baquets régionaux et interrégionaux peuvent maintenir la disponibilité pendant une panne de site ou de zone sans qu'aucune modification de configuration ne soit nécessaire. Il est donc recommandé d'utiliser ces paramètres de résilience des baquets de stockage lors de la configuration de vos charges de travail pour la haute disponibilité. Les données stockées sur un seul site sont toujours réparties sur plusieurs appareils de stockage physiques, mais elles sont contenues dans un seul centre de données sans aucune prise en charge zonale.

Fonctionnalités de haute disponibilité

Object Storage offre les possibilités suivantes pour vous aider à planifier une haute disponibilité en cas de panne :

Caractéristiques de l'AP pour Object Storage
Fonction	Description	Élément à prendre en compte
Résilience des baquets de stockage	Possibilité de configurer un choix de résilience spécifique pour les données des clients.	les buckets Object Storage créés au niveau d'un point de terminaison régional distribuent les données à travers trois zones ou plus qui sont contenues dans une zone métropolitaine. Chacune de ces zones peut subir une panne, voire une destruction, sans que cela ait d'incidence sur la disponibilité. Les compartiments créés au niveau d'un point de terminaison interrégional distribuent les données dans trois régions d'une même zone géographique. L'une de ces régions peut être indisponible ou même détruite sans que cela ne vienne mettre en péril la disponibilité des données. Les demandes sont acheminées vers la zone métropolitaine interrégionale la plus proche grâce à l'équilibrage de la charge du serveur global (GSLB). Pour plus d'informations, reportez-vous à la section Points finaux et emplacements de stockage.
Réplication	La réplication copie les objets nouvellement créés et les mises à jour d'objets d'un godet source vers un godet cible et permet de définir des règles pour la copie automatique et asynchrone des objets.	Pour être sûr de disposer d'une copie de sauvegarde en cas de sinistre, il est recommandé de configurer et d'installer la réplication. En savoir plus sur le suivi des événements de réplication.

Architecture de reprise après sinistre

Les seaux interrégionaux, régionaux et à site unique offrent différents niveaux de tolérance à l'égard de scénarios de catastrophe spécifiques. Choisissez le bon modèle de résilience pour votre godet qui correspond aux exigences de votre entreprise en matière de reprise après sinistre. Pour de nombreux scénarios de catastrophe au niveau du centre de données ou de la région, IBM prévoit un temps de récupération du service et du contenu associé inférieur à 24 heures, avec un RPO d'une heure.

D'autres architectures optionnelles peuvent être mises en œuvre par le client pour améliorer les temps de récupération.

Par exemple, dans le cas improbable d'une panne régionale complète du COS où la restauration des données d'origine n'est pas possible, un seau dupliqué pourrait être créé dans une autre région. Attendre qu' IBM Cloud récupère une région ou un service affecté est également une solution valable, mais n'oubliez pas que cela peut prendre plusieurs heures, voire plus, et qu'il peut y avoir des pertes de données en fonction du scénario du sinistre.

Le seau dupliqué peut être configuré pour refléter le seau de production, mais avec des références actualisées aux services régionaux. Par exemple, si vous utilisez la Key Protect, un seau dupliqué à Madrid doit référencer les clés racines qui sont stockées dans une instance de Key Protect Madrid. Dans le cas d'un sinistre, où il n'est pas possible d'attendre qu' IBM récupère complètement la région, les clients peuvent repeupler ce bac dupliqué avec une copie de sauvegarde des données originales dans le bac source. Les clients peuvent également mettre en place des règles de réplication avant toute interruption afin de maintenir les données synchronisées entre le godet source et le godet dupliqué. Pour un niveau de résilience optimal, un tel godet dupliqué doit être créé avant le fait (avant tout désastre potentiel) et maintenu en synchronisation avec le godet source qui utilise la réplication. L'utilisation de la fonction de réplication d'objets doit être envisagée en fonction du modèle de résilience de votre bac d'origine et de vos objectifs globaux de reprise après sinistre.

Planifier le rétablissement dans une région de rétablissement. Le bac répliqué doit s'aligner sur les approches de reprise après sinistre de la charge de travail au sein d' IBM Cloud Si le sinistre n'a pas d'incidence sur la configuration ou la disponibilité du seau source de production (par exemple, une simple perte de données), il peut être possible pour un client de réparer les données du seau source en place. Dans le cas où le basculement vers un seau répliqué est nécessaire, l'application client devra être reconfigurée pour appeler le point de terminaison du seau répliqué cible.

Fonctionnalités de reprise après sinistre

IBM COS propose les fonctions de reprise après sinistre suivantes, qui peuvent être configurées par les clients :

Caractéristiques du DR pour Object Storage
Fonction	Description	Élément à prendre en compte
Réplication d'objets	La réplication copie les objets nouvellement créés et les mises à jour d'objets d'un godet source vers un godet cible et permet de définir des règles pour la copie automatique et asynchrone des objets.	Pour vous assurer de disposer d'une deuxième copie en cas de sinistre, vous pouvez configurer la réplication entre un seau de production et un seau de récupération cible. En fonction des exigences de résilience de votre entreprise, la réplication peut ne pas être nécessaire si vous utilisez des seaux interrégionaux ou régionaux. En savoir plus sur le suivi des événements de réplication.
Gestion des versions d'objet	Activer le versionnage des objets pour conserver les versions antérieures des objets qui peuvent être restaurées en cas de corruption ou de suppression des données.	Les clients peuvent activer le versionnage des objets sur les buckets et restaurer les anciennes versions en cas de corruption des données. Le seau doit être disponible pour effectuer la récupération de la version. En savoir plus
Verrouillage d'objet	Le verrouillage des objets empêche la suppression des versions d'objets pendant une période de conservation donnée.	Activer le verrouillage des objets pour les protéger contre les suppressions ou les écrasements accidentels ou non autorisés. S'assurer que des versions sûres des objets sont disponibles pour la récupération. En savoir plus

D'autres options de reprise après sinistre sont créées et prises en charge par le client.

Caractéristiques du DR client pour Object Storage
Fonction	Description	Élément à prendre en compte
Sauvegarde et restauration	Utilisez des scripts ou des applications de sauvegarde tierces pour sauvegarder les données des compartiments source dans une région de récupération.	Le client doit héberger et gérer tout script ou solution de sauvegarde tierce afin de sauvegarder les données stockées dans les compartiments COS.

Planification du désamorçage

Les étapes du DR doivent être pratiquées régulièrement. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec et les résolutions suivants.

Scénarios de DR pour Object Storage
Echec	Résolution
Défaillance du matériel (point unique)	les buckets Object Storage sont résistants aux défaillances matérielles ponctuelles au sein d'une zone. Aucune configuration n'est requise.
Défaillance du centre de données	Les buckets de COS interrégionaux et régionaux résistent aux défaillances des centres de données individuels. Aucune configuration ou basculement n'est requis par le client. Les clients disposant de compartiments dans des zones de centre de données uniques peuvent configurer la réplication ou utiliser des solutions de sauvegarde tierces afin de garantir la disponibilité d'une copie sécurisée des données en dehors de la zone. Attendre qu' IBM Cloud rétablisse une région ou un service affecté est également une solution valable, mais n'oubliez pas que cela peut prendre plusieurs heures, voire plus, selon la nature de la panne du centre de données.
Altération de données	Utilisez le versionnage des objets, la réplication des objets ou des solutions de sauvegarde tierces pour vous assurer qu'il existe des versions non corrompues des objets à partir desquelles effectuer une restauration en cas de corruption des données ou de suppression accidentelle.
Défaillance régionale	Les seaux COS interrégionaux résistent aux défaillances régionales. Certains services régionaux intégrés, comme Key Protect peuvent nécessiter des étapes de basculement supplémentaires pour les données interrégionales. Les clients disposant de buckets régionaux ou de buckets COS d'un seul centre de données doivent suivre les étapes de reprise après sinistre décrites ci-dessus en cas de défaillance totale d'un centre régional. Attendre qu' IBM Cloud rétablisse une région ou un service affecté est également une solution valable, mais n'oubliez pas que cela peut prendre plusieurs heures, voire plus, en fonction de la nature de la panne régionale.

Utilisation d' IBM Cloud Key Management Service pour l'ajout d'un chiffrement :

Si vous utilisez une autre intégration de service IBM Cloud, par exemple IBM Cloud Key Management Service comme Key Protect ou Hyper Protect, pour ajouter le chiffrement, vous devrez vous assurer que le plan de configuration approprié pour la réplique des clés est utilisé. Cette fonction est essentielle lors de l'utilisation d'une configuration interrégionale, qui garantit la disponibilité d'une clé de réplique en cas de panne. Reportez-vous à la documentation Key Protect pour la haute disponibilité et la reprise après sinistre.

Vos responsabilités en matière d'HA et de DR

Vos responsabilités en matière d'HA et de DR
Responsibilité	Description
Résilience	Fournir des godets de Object Storage avec l'option de résilience appropriée, la classe de stockage, la localité des données et les configurations optionnelles nécessaires pour la charge de travail spécifique et le cas d'utilisation.
Sauvegarde des données	Assurer la sauvegarde des données des clients, si nécessaire, conformément aux exigences de votre organisation.
Réseau	Surveiller et gérer les ressources réseau IBM IBM pour assurer un accès approprié aux points d'extrémité du service IBM Cloud, y compris la capacité et la disponibilité.
Utilisation d' IBM Cloud KMS pour ajouter le chiffrement de l'enveloppe	Si vous utilisez IBM Cloud Key Protect ou Hyper Protect Crypto Services pour ajouter le chiffrement, veillez à consulter la documentation relative à la haute disponibilité et à la reprise après sinistre pour bien comprendre les implications. Vous pouvez être amené à utiliser un emplacement d'instance de clé qui dispose d'une réplique de clé pouvant être utilisée en cas de basculement. Veillez également à consulter les informations relatives à la licence et au plan.

Pour en savoir plus sur la répartition des responsabilités entre le client et Object Storage, reportez-vous à [Vos responsabilités lors de l'utilisation de Object Storage (/docs/cloud-object-storage?topic=cloud-object-storage-responsibilities).]

Objectif de délai de rétablissement (RTO) et objectif de point de rétablissement (RPO)

L'offre IBM Cloud Object Storage a mis en place des plans pour assurer la récupération du service en nuage et du contenu associé, ce qui se produit en quelques heures en cas de sinistre.

Caractéristiques RTO/RPO pour Object Storage
Fonction	RTO et RPO
Récupération en cas de défaillance matérielle (point unique)	RTO = 0, RPO = 0 pour tous les modèles de résilience
Récupération après une panne du centre de données	RTO = 0, RPO = 0 pour les modèles de résilience interrégionale et régionale
Rétablir la version précédente de l'objet	RTO = secondes, RPO = proche de 0
Récupération sur un godet dans une région séparée avec réplication active	RTO = minutes, l'utilisation de scripts peut encore améliorer le temps et prendre en compte le temps nécessaire pour ajuster les charges de travail afin de cibler le seau de récupération, RPO = près d'une heure
Récupération sur une nouvelle base de données dans une nouvelle région sans réplication active	RTO = de quelques minutes à quelques jours. Il s'agit du temps nécessaire pour reconfigurer un nouveau godet et pour adapter les charges de travail afin de cibler le nouveau point d'extrémité du godet. Il faut également tenir compte du temps nécessaire pour remplir le seau avec une copie des données d'origine. Le RPO est soumis au plan de sauvegarde et de récupération du client

Gestion des modifications

La gestion des changements comprend des tâches telles que les mises à niveau, les modifications de configuration et les suppressions. Afin de s'assurer que les utilisateurs reçoivent un accès conforme aux exigences de leur rôle, veuillez consulter la rubrique "Getting Started with IAM"(Démarrer avec IAM).

Il est recommandé d'accorder aux utilisateurs et aux processus les rôles et les actions IAM avec le moins de privilèges possible. Voir Comment puis-je éviter la suppression accidentelle de services?

Comment IBM® assure la reprise après sinistre

en cas de sinistre, IBM® prend des mesures de récupération spécifiques.

Récupération en cas de défaillance d'une zone ou d'une région
En cas de défaillance d'une zone, IBM Cloud résoudra la panne de la zone et, lorsque la zone sera à nouveau en ligne, l'équilibreur de charge global recommencera à envoyer des requêtes API au nœud d'instance restauré, sans qu'aucune action du client ne soit nécessaire.
IBM® effectue des tests annuels de divers scénarios de catastrophe et affine continuellement sa documentation de récupération sur la base des constatations faites lors de ces tests.
une assistance mondiale 24 × 7 est disponible pour les clients avec IBM® Qui sont prêts à intervenir en cas de sinistre.
Tous les IBM® Les experts en la matière sont formés chaque année aux politiques et procédures de continuité des activités et de reprise après sinistre afin d'être prêts en cas de catastrophe.

Comment IBM maintient les services

Toutes les mises à niveau suivent les meilleures pratiques de service IBM et disposent d'un plan de reprise et d'un processus de retour en arrière. Des mises à jour régulières pour les nouvelles fonctionnalités et la maintenance sont effectuées dans le cadre des opérations normales. Cette maintenance peut occasionnellement provoquer de courts intervalles d'interruption qui sont gérés par la logique de relance de la disponibilité du client. Les changements sont introduits de manière séquentielle, région par région et zone par zone à l'intérieur d'une région. Les mises à jour sont annulées au premier signe de défaut.

Les modifications complexes sont activées et désactivées à l'aide d'indicateurs de caractéristiques afin de contrôler l'exposition.

Les changements qui ont un impact sur les charges de travail des clients sont détaillés dans les notifications. Pour plus d'informations, voir les notifications de suivi et l'état de la maintenance planifiée, les annonces et les notes de version qui ont un impact sur ce service.