Description de la haute disponibilité et de la reprise après incident pour IBM Cloud Logs

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. Pour les services, la disponibilité est définie dans l'accord de niveau de service. La disponibilité comprend à la fois les événements planifiés et non planifiés, tels que la maintenance, les pannes et les catastrophes. (HA) est la capacité d'un service à rester opérationnel et accessible en présence de pannes imprévues. 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 haute disponibilité à le gérer. est le processus de restauration de l'instance de service à un état de fonctionnement.

IBM Cloud Logs est un service régional multi-locataires à haute disponibilité. Vous trouverez les régions et les centres de données disponibles dans la documentation relative aux sites. En tant que service régional, IBM Cloud Logs remplit les objectifs de niveau de service(SLO ) définis avec le plan Standard. Les objectifs de niveau de service ne sont pas une garantie et IBM n'accordera pas de crédits pour non-respect d'un objectif.

Les objectifs de niveau de service (SLO) décrivent les points de conception que les services IBM Cloud sont conçus pour respecter. IBM Cloud Logs est conçu pour atteindre l'objectif de disponibilité suivant.

SLO pour IBM Cloud Logs
Objectif de disponibilité Valeur cible
% de disponibilité 99.99%

Architecture à haute disponibilité

Schéma présentant l'architecture haute disponibilité d' IBM Cloud Logs
Architecture haute disponibilité

Une zone de disponibilité est un emplacement isolé logiquement et physiquement dans une région IBM Cloud où vos données sont traitées et hébergées.

  • Une zone de disponibilité possède des infrastructures indépendantes d'alimentation, de refroidissement et de réseau, isolées des autres zones afin de renforcer la tolérance aux pannes en évitant les points de défaillance uniques entre les zones.
  • Une zone de disponibilité offre une bande passante élevée et un faible temps d'attente inter-zone au sein d'une région.

Une région (emplacement) est un groupe distinct géographiquement et physiquement d'une ou de plusieurs zones de disponibilité avec des infrastructures électriques et de réseau indépendantes, isolées des autres régions.

  • Les régions sont conçues pour supprimer les points de défaillance uniques partagés avec d'autres régions et garantir un faible temps d'attente inter-zone au sein de la région.
  • Chaque région dispose de 3 centres de données (DC) différents pour la redondance.

Fonctions de haute disponibilité

IBM Cloud Logs prend en charge les fonctionnalités de haute disponibilité suivantes :

Fonctionnalités HA pour IBM Cloud Logs
Fonction Description
Déploiement régional multi-zones IBM Cloud Logs est déployé uniquement dans les régions multizones (MZR) et, au sein d'une MZR, le cluster de plan de données couvre les trois zones, garantissant que la perte d'une zone n'a pas d'impact sur la disponibilité du service.
IBM Cloud Logs réplication des ressources entre les zones Toutes les ressources d' IBM Cloud Logs, telles que les alertes, les mesures et les journaux, sont répliquées dans trois zones au sein des MZR. Cela garantit la conservation des données en cas de perte de zone.
Contrôle de la présence de tension / de l'état de fonctionnement Tous les microservices sont surveillés par des sondes de vivacité et de disponibilité ( Kubernetes ).

Architecture de reprise après sinistre

Schéma de l'architecture de reprise d'activité d' IBM Cloud
Architecture de reprise d'activité

IBM Cloud Logs est construit sur l' Red Hat OpenShift on IBM Cloud, sur VPC, qui utilise des régions multizones et répartit tous les nœuds de travail sur trois zones. Les équilibreurs de charge VPC traitent le trafic entrant et le transmettent au maillage de services fonctionnant dans le cluster.

Il n'y a pas de basculement automatique interrégional ni de reprise après sinistre interrégionale. Si toutes les zones de disponibilité d'une région tombent en panne, IBM Cloud Logs devient indisponible dans cette région.

Fonctions de reprise après sinistre

IBM Cloud Logs prend en charge les fonctionnalités de reprise après sinistre suivantes :

Fonctionnalités de DR pour IBM Cloud Logs
Fonction Description
Autre région Le service fonctionnant sur une région alternative peut être utilisé, indépendamment du service principal
Sauvegarde de base de données Une copie de l'ensemble de données actuel est stockée

Planification de la reprise après sinistre

Les étapes de la RD doivent être pratiquées régulièrement. Lorsque vous élaborez votre plan, tenez compte des scénarios de défaillance et des solutions suivantes.

Scénarios de DR pour IBM Cloud Logs
Echec Résolution
Défaillance matérielle (point unique) IBM fournit une base de données résiliente à partir d'un point unique de défaillance matérielle au sein d'une zone - aucune configuration n'est requise.
défaillance de zone IBM Cloud Logs utilise un déploiement de région multizone qui résiste à une défaillance ponctuelle de zone.
Altération de données En cas de corruption des données, la base de données sera restaurée à son dernier état stable disponible sur le site de sauvegarde. Nous utilisons des sauvegardes d' IBM Cloud Object Storage s pour la récupération, voir Sauvegardes
Échec régional Suivez les étapes indiquées dans Vos responsabilités en matière de HA et DR

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

IBM Cloud dispose de plans de continuité des activitésPossibilité pour une entreprise de prendre en charge les pannes et d'exécuter ses services critiques normalement et sans interruption, conformément à des accords de niveau de service prédéfinis. permettant de rétablir les services dans les heures qui suivent la survenance d'une catastrophe. Vous êtes responsable de la sauvegarde des données et de la récupération de votre contenu.

Dans le cas d'une catastrophe régionale majeure, comme un tremblement de terre, une inondation ou une tornade, une région entière peut être touchée.

Pour récupérer une instance d' IBM Cloud Logs, vous devez provisionner une nouvelle instance d' IBM Cloud Logs et recréer les ressources d' IBM Cloud Logs. Vous devez également disposer d'une stratégie de récupération des données (DR) pour les compartiments d' IBM Cloud Object Storage s associés à l'instance et l'instance d' IBM Cloud Event Notifications s que vous avez peut-être configurée pour déclencher des alertes de notification.

Pour vous assurer que vos charges de travail résistent à de tels événements, suivez les étapes suivantes :

  1. Définir la stratégie régionale où vous pouvez restaurer la configuration qui est en panne.

    Vérifiez la localisation de vos données et les exigences de conformité lors du choix de la région de récupération.

    Pour plus d'informations sur les sites, voir :

  2. Si vous avez des configurations qui n'utilisent pas Terraform, sauvegardez vos configurations actuelles en utilisant l'API. Si vous utilisez Terraform, enregistrez vos scripts Terraform pour vous aider à recréer la région qui est en panne. Envisagez d'utiliser un système de contrôle de version pour stocker les fichiers de sauvegarde ou les scripts Terraform.

    Vous pouvez utiliser Terraform pour créer des instances d' IBM Cloud Logs. Voir Gestion des ressources Terraform resources.

    Vous pouvez utiliser Terraform pour créer les ressources d' IBM Cloud Logs. Voir IBM Cloud Logs Ressources Terraform.

    Vous pouvez utiliser Terraform pour créer votre compartiment de données, votre compartiment de métriques, ou les deux, avec la résilience interrégionale pour stocker et accéder aux données dans plusieurs régions géographiques et garantir une haute disponibilité, une durabilité et des capacités de reprise après sinistre. Voir IBM Cloud Object Storage Ressources Terraform.

    Vous pouvez utiliser Terraform pour créer vos ressources d' IBM Cloud Event Notifications. Voir IBM Cloud Event Notifications Ressources Terraform.

    Vous pouvez utiliser Terraform pour créer vos autorisations et permissions IAM. Voir les ressources IAM Terraform.

    Testez toujours que vous pouvez restaurer la configuration de sauvegarde dans une autre région.

En cas de sinistre régional, vous devez suivre les étapes suivantes pour récupérer votre instance dans une nouvelle région :

  1. Identifier une autre région où restaurer l'instance d' IBM Cloud Logs.

  2. Créer la nouvelle instance d' IBM Cloud Logs. Pour plus d'informations, voir Mise à disposition d'une instance.

  3. Si votre instance a des compartiments de données ou de métriques configurés, procédez comme suit :

    Si votre instance dans la région touchée par la catastrophe n'était pas configurée avec des compartiments d' IBM Cloud Object Storage, les journaux et les données de métriques seront perdus.

  4. Si votre instance a des alertes configurées, procédez comme suit :

  5. Recréez les ressources dans la nouvelle instance d' IBM Cloud Logs.

    Créer des vues.

    Il peut créer des tableaux de bord.

    Créer des alertes.

    Créer des politiques de coût total de possession.

    Créer des règles d'analyse.

    Créer des événements pour les métriques.

    Activer l'utilisation des données.

    Configurer les règles de données.

    Configurer les politiques d'enrichissement des données.

Pour faciliter la récupération d'une instance d' IBM Cloud Logs, utilisez Terraform pour gérer vos instances, vos configurations et l'accès IAM. L'utilisation de Terraform éliminera le besoin d'étapes manuelles lors de la configuration d'instances dans une autre région.

Après avoir récupéré l'instance, vous devez reconfigurer vos sources de données pour envoyer les journaux à la nouvelle instance :

  1. Si la nouvelle région dispose d'un locataire d' IBM Cloud Logs Routing, vous devez utiliser la cible actuelle associée à cette région pour afficher et surveiller les journaux de la plate-forme. Si la nouvelle région ne dispose pas d'un tenant d' IBM Cloud Logs Routing, créez un tenant d' IBM Cloud Logs Routing qui référence votre nouvelle instance d' IBM Cloud Logs. Voir Création d'un tenant d' IBM Cloud Logs Routing, et Comprendre la haute disponibilité et la reprise après sinistre pour IBM Cloud Logs Routing.

  2. Si la nouvelle région dispose d'une configuration d' IBM Cloud Activity Tracker Event Routing s qui collecte les événements de suivi d'activité de la région qui est en panne, vous pouvez utiliser la configuration existante pour afficher et gérer les événements. Si la nouvelle région ne dispose pas d'une configuration d' IBM Cloud Activity Tracker Event Routing s qui collecte les événements de suivi d'activité de la région en panne, vous devez ajouter une règle pour indiquer où et comment vous souhaitez collecter les événements. Pour plus d'informations, voir Création d'une configuration de routage résiliente à une catastrophe régionale.

  3. Reconfigurez votre serveur d' Agent de journalisation s ( ) pour qu'il pointe vers le point de terminaison d'ingestion de la région de récupération d' IBM Cloud Logs.

Pour en savoir plus sur la responsabilité de propriété entre vous et IBM Cloud pour l'utilisation de IBM Cloud Logs, consultez Comprendre vos responsabilités lors de l'utilisation de IBM Cloud Logs.

Objectif de temps de récupération (RTO) et objectif de point de récupération (RPO)

IBM Cloud Logs fournit des moyens de protéger vos données et de rétablir les fonctions du service. Des plans de continuité des activités sont en place pour atteindre les objectifs de point de récupérationDans la planification de la reprise après sinistre, le délai de restauration des données est mesuré en temps (secondes, minutes, heures) à partir de l'instance récupérée et jusqu'au point du sinistre. (RPO) et de temps de récupérationDans le cadre de la planification de la reprise après sinistre, le temps nécessaire à la restauration d'un processus d'entreprise après un sinistre. (RTO) pour le service. Le tableau suivant présente les objectifs pour IBM Cloud Logs.

RPO et RTO pour IBM Cloud Logs
Objectif de reprise après incident Valeur cible
RPO Sous 4 heures
RTO Sous 24 heures

Gestion des modifications

La gestion des modifications comprend des tâches telles que les mises à niveau, les changements de configuration et la suppression.

Il est recommandé d'attribuer aux utilisateurs et aux processus les rôles et les actions IAM avec le moins de privilèges requis pour leur travail. Voir Comment puis-je empêcher la suppression accidentelle de services?.

Envisagez de créer une sauvegarde à l'aide de l'API avant de passer à une nouvelle version d' IBM Cloud Logs, si vous avez des configurations qui n'utilisent pas Terraform.

Comment IBM® soutient la planification de la reprise après sinistre

  • IBM® effectue des tests annuels de divers scénarios de catastrophe et améliore continuellement notre documentation de reprise d'activité en fonction des résultats obtenus lors de ces tests.

  • une assistance mondiale 24 heures sur 24 et 7 jours sur 7 est disponible pour les clients avec des experts en la matière d' IBM®, qui sont disponibles pour aider en cas de catastrophe.

    Tous les experts en la matière d' IBM® sont formés chaque année aux politiques et procédures de continuité des activités et de reprise après sinistre afin d'assurer la préparation en cas de catastrophe.

IBM Cloud Logs est un service régional à haute disponibilité.

  • Pour plus d'informations sur les régions où IBM Cloud Logs est disponible, consultez la rubrique Emplacements.
  • Chaque région dispose de trois centres de données différents pour la redondance, qui sont configurés en mode active/active.
  • Si tous les centres de données d'un emplacement tombent en panne, IBM Cloud Logs devient indisponible à cet emplacement.
  • Dans chaque région prise en charge, le trafic est équilibré en termes de charge sur l'ensemble de l'infrastructure dans plusieurs zones de disponibilité, sans point de défaillance unique.

Le tableau suivant répertorie le statut haute disponibilité (HA) des régions (emplacements) où le service IBM Cloud Logs est disponible :

Liste des lieux où le service est disponible
Zone géographique Région Soutenu par l'Union Européenne Statut de haute disponibilité
Asie Pacifique Osaka (jp-osa) Non applicable MZR
Asie Pacifique Sydney (au-syd) Non applicable MZR
Asie Pacifique Tokyo (jp-tok) Non applicable MZR
Europe Francfort (eu-de) OUI MZR
Europe Londres (eu-gb) NON MZR
Europe Madrid (eu-es) OUI MZR
Amérique du Nord Toronto (ca-tor) Non applicable MZR
Amérique du Nord Montréal (ca-mon) Non applicable MZR
Amérique du Nord Dallas (us-south) Non applicable MZR
Amérique du Nord Washington (us-east) Non applicable MZR
Amérique du Sud Sao Paulo (br-sao) Non applicable MZR

Où

  • Un Géographie est une zone géographique ou un corps politique plus grand qui contient une ou plusieurs régions.
  • Une Région est un territoire géographique défini.
  • Une région peut être une zone de code postal spécifique, une ville, un État, un groupe d'États ou même un groupe de pays.
  • Une région contient plusieurs zones de disponibilité pour répondre aux exigences d'accès local, de faible latence et de sécurité de la région.
  • MZR désigne une région multizone. En savoir plus.

Pour plus d'informations sur la disponibilité des services dans les régions et les centres de données, voir Disponibilité des services et de l'infrastructure par emplacement.

Les données gérées par IBM Cloud Logs dans une région sont conservées dans les centres de données proches de cette région.

Une région multizone (MZR) se compose de 3 zones de disponibilité ou plus qui sont indépendantes les unes des autres afin de garantir qu'une défaillance n'affecte qu'une seule zone.

Par défaut, IBM Cloud Logs est déployé sur 3 zones. Chaque zone est configurée avec l active/active/active:

  • Chaque zone se trouve dans un centre de données différent de la région.
  • Les données de chaque zone sont automatiquement répliquées dans les autres zones avec une faible latence. Vous ne devez rien faire pour activer la réplication.
  • Le service est conçu pour résister à une panne dans une seule zone sans entraîner d'interruption.

L'architecture MZR offre un basculement automatique entre les zones au sein de la région et une haute disponibilité pour le déploiement de IBM Cloud Logs au sein d'une région.

Les métadonnées gérées par l' IBM Cloud Logs, comprennent les métadonnées client telles que les informations sur les paramètres critiques - clés, définitions d'alertes, définitions d' e2m s, données de métriques, etc.

IBM Cloud Logs sauvegarde régulièrement les données dans chaque région :

  • Des sauvegardes régulières sont effectuées quotidiennement et conservées pendant 30 jours, puis stockées dans des compartiments d' IBM Cloud Object Storage s interrégionaux
  • Les sauvegardes incrémentielles continues sont conservées pendant les 7 derniers jours.

En cas de panne totale d'une région, les données de sauvegarde restent disponibles et sont ensuite restaurées dans le cadre de la restauration du service d' IBM Cloud Logs.

Comment l' IBM e récupère des pannes de zone

En cas de panne de zone, IBM Cloud résoudra la panne de zone. Étant donné que le plan de données s'étend sur les trois zones d'une région, il n'y aura aucun impact sur la disponibilité du service et l'équilibreur de charge global recommencera à envoyer des données vers la zone restaurée. Aucune action n'est requise de la part des clients pour le moment.

Comment l' IBM e se remet des échecs régionaux

Lorsqu'une région est restaurée après une panne, IBM tentera de restaurer l'instance de service à partir de l'état régional. Si l'état régional est corrompu, le service est restauré à l'état de la dernière sauvegarde interne, qui est continuellement transmise à un site de données alternatif dans un compartiment d' IBM Cloud Object Storage s interrégional géré par le service. Si les données de sauvegarde ont été corrompues, il est possible que les données des dernières 24 heures aient été perdues. Ces sauvegardes ne sont pas disponibles pour la reprise après sinistre gérée par le client.

Si IBM ne parvient pas à restaurer l'instance de service, le client doit procéder à la restauration comme décrit dans l'architecture de reprise après sinistre.

Comment l' IBM e maintient ses services

Toutes les mises à niveau suivent les meilleures pratiques de service d' IBM, et un plan de reprise et un processus de restauration sont en place. Les mises à niveau régulières pour les nouvelles fonctionnalités et la maintenance font partie des opérations normales. Une telle maintenance peut occasionnellement entraîner de courts intervalles d'interruption qui sont gérés par la logique de relance de disponibilité du client. Les changements sont déployés de manière séquentielle, région par région et zone par zone au sein d'une région. Les mises à jour sont annulées au premier signe de défaut.

Les changements qui ont un impact sur les charges de travail des clients sont détaillés dans les notifications. Pour plus d'informations, consultez 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.