Description de la haute disponibilité et de la reprise après incident pour Event Streams
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 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 haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.
IBM® Event Streams for IBM Cloud® est un service mondial et vous pouvez 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 par emplacement. En tant que service global, Event Streams remplit les objectifs de niveau de service(SLO) définis avec les plans Standard et Enterprise. Le SLO n'est pas une garantie et IBM® ne délivrera pas de crédits en cas de non-respect d'un objectif.
Architecture à haute disponibilité
Fonctionnalités de haute disponibilité
Event Streams prend en charge les fonctions de haute disponibilité suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Déploiement de régions multizones | Distribué dans trois zones de disponibilité pour une tolérance aux pannes et une haute disponibilité | Dans Event Streams, les données de chaque partition sont réparties sur trois zones de disponibilité (pour les déploiements MZR) afin d'assurer la continuité de l'activité en cas de perte des données d'une zone de disponibilité. |
| Nombre minimal de répliques synchrones | Un minimum de deux répliques synchronisées est requis à tout moment | Event Streams surveille en permanence et veille à ce qu'au moins deux répliques soient synchronisées en fonction de la disponibilité pour s'assurer que les messages ne sont pas perdus en cas de défaillance d'un courtier ou d'une zone, garantissant ainsi la pérennité des données critiques. |
Architecture de reprise après sinistre
Fonctionnalités de reprise après sinistre
Event Streams prend en charge les fonctions de reprise après sinistre suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Mise en miroir | Miroir pour la réplication des clusters | Event Streams offre une fonction de miroir qui permet aux messages d'une instance de Event Streams d'être copiés en continu dans une seconde instance. Vous pouvez utiliser la fonction Event Streams Ou choisir de gérer votre propre solution de mise en miroir. |
Miroir pour Event Streams
La mise en miroir permet aux messages d'une instance de service Event Streams d'être copiés en continu sur une deuxième instance. La résilience des applications peut être améliorée par l'utilisation d'un miroir, de sorte que si la première instance de service devient indisponible, les applications peuvent se reconnecter à la seconde instance et poursuivre leur fonctionnement normal.
Cette fonctionnalité fait partie du service entièrement géré et ne peut être utilisée qu'entre les instances de service qui utilisent le Event Streams Enterprise plan.
- Caractéristiques de la mise en miroir :
- Miroir de sujets, de données de messages et de décalages de groupes de consommateurs entre deux instances de service Event Streams, qui peuvent être fournies dans différents comptes IBM Cloud®
- SLA de 99.99 disponibilité, cohérent avec le service Event Streams
- Peut être surveillé à l'aide de IBM Cloud® Monitoring
- Limites de la mise en miroir :
- Unidirectionnel : Les données ne peuvent être dupliquées que dans une seule direction à la fois entre deux instances de service. Cela signifie que la mise en miroir offre un style "actif-passif" de haute disponibilité, et non un style "actif-actif".
- Asynchrone : les messages doivent être produits avec succès dans l'instance source avant d'être mis en miroir dans l'instance cible. Cela signifie qu'en cas de panne, certaines données du message peuvent être perdues.
- Consommation de messages au moins une fois : Lorsqu'un consommateur passe d'une instance à l'autre, il peut être amené à retraiter des messages qu'il a déjà traités.
Planification de la reprise après incident
Les étapes de la reprise après sinistre 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.
| Echec | Résolution |
|---|---|
| Défaillance du matériel (point unique) | Event Streams résiste à un seul point de défaillance matérielle dans une zone - aucune configuration n'est requise. |
| défaillance de zone | Une instance Event Streams déployée dans une région multizone résiste à la défaillance d'une seule zone - aucune configuration n'est requise. Pour les déploiements sur une seule zone, configurez un autre cluster Event Streams en tant que paire en miroir afin d'atténuer les risques de défaillance d'une zone. |
| Altération de données | Event Streams n'inclut aucun mécanisme intégré de récupération des données corrompues. Vous êtes tenu de prévoir de telles circonstances dans le cadre d'un plan de reprise après sinistre et vous devrez peut-être utiliser la fonction de mise en miroir ou configurer une nouvelle instance. |
| Défaillance régionale | Si vous avez configuré votre instance Event Streams dans une région multizone, un désastre régional est peu probable. En cas de défaillance régionale, vous devez configurer une nouvelle instance dans une autre région. Pour plus d'informations, voir Comprendre vos responsabilités. |
Vos responsabilités en matière d'HA et de DR
Les informations suivantes peuvent vous aider à élaborer et à mettre en pratique en permanence votre plan pour l'AH et le DR.
Il est important de comprendre les responsabilités de gestion et les conditions générales qui s'appliquent lorsque vous utilisez Event Streams La page sur les responsabilités du client sert de point de départ à l'élaboration d'un plan de haute disponibilité et de reprise après sinistre.
Dans le cadre de la reprise après sinistre, il est recommandé d'accorder aux utilisateurs et aux processus les rôles et actions IAM avec le moins de privilèges possible. Pour plus d'informations, voir Comment empêcher la suppression accidentelle de services ?
Tous les plans Event Streams (à l'exception de Satellite ) peuvent récupérer une instance supprimée dans un délai de réclamation de trois jours, après quoi les données sont irréversiblement détruites. Vous pouvez vérifier l'état d'une récupération et forcer ou annuler une récupération programmée en utilisant l'interface CLI d' IBM Cloud
Si Event Streams ne peut pas restaurer l'instance de service, vous devez la restaurer comme décrit dans la section Mise en miroir dans un scénario de reprise après sinistre.
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 mis en œuvre 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 le suivi des notifications et de l'état de la maintenance planifiée, des annonces et des notes de version qui ont un impact sur les Event Streams