Description de la haute disponibilité et de la reprise après incident pour Databases for Redis
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.
Databases for Redis est un service régional qui remplit les objectifs de niveau de service(SLO) définis avec le plan standard.
IBM Cloud Pour plus d'informations sur les régions et les centres de données disponibles pour Databases for Redis, voir Disponibilité des services et de l'infrastructure par emplacement.
Architecture à haute disponibilité
Databases for Redis offre des fonctions de réplication, de basculement et de haute disponibilité pour protéger vos bases de données et vos données de la maintenance de l'infrastructure, des mises à niveau et de certaines pannes. Les déploiements contiennent un cluster avec deux membres de données dans une configuration primaire plus réplique. La réplique est maintenue à jour à l'aide d'une réplication asynchrone. La haute disponibilité est surveillée et gérée par trois sentinelles Redis
Par défaut, la persistance des données est activée sur tous les déploiements et vos données sont écrites sur le disque. Databases for Redis utilise une combinaison d' instantanés RDB et d'AOF(Append Only File) pour persister les données sur le disque. L'intervalle entre Databases for Redis et l'écriture sur disque (fsync) est fixé à une fois par seconde afin d'équilibrer la durabilité et les performances.
Vous pouvez désactiver la persistance des données, ce qui est utile pour configurer Redis en tant que cache.
Fonctionnalités de haute disponibilité
Databases for Redis prend en charge les fonctions de haute disponibilité suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Basculement automatique | Standard sur tous les clusters et résilience en cas de défaillance d'une zone ou d'un seul membre | |
| Nombre de membres | Minimum - 2 membres. La valeur par défaut est un cluster standard à deux membres dans une configuration primaire et réplique. Un cluster à deux membres se rétablit automatiquement en cas de défaillance d'une seule instance ou d'une seule zone (avec une perte de données jusqu'au seuil de décalage). | Trois nœuds Sentinel pour surveiller l'état de santé du cluster et coordonner les basculements. |
| Réplication asynchrone | Permet la réplication du primaire vers le réplica sans bloquer le chemin d'écriture, assurant ainsi une haute disponibilité avec une faible latence. Reportez-vous à la section Réplication asynchrone. | Peut entraîner une perte de données lors du basculement en raison du retard de réplication (RPO > 0). Ne convient pas lorsque la durabilité des données doit être stricte. |
Réplication asynchrone pour Databases for Redis
Par défaut, Databases for Redis utilise une réplication asynchrone, dans laquelle le nœud principal n'attend pas que le réplica accuse réception des écritures. Cela garantit une faible latence et un débit élevé, ce qui rend Databases for Redis idéal pour la mise en cache et les charges de travail sensibles aux performances. Toutefois, en cas de défaillance d'un système primaire, le décalage de la réplication peut entraîner une perte de données, car la réplique peut ne pas avoir reçu les écritures les plus récentes.
Databases for Redis la réplication est conçue pour une haute disponibilité, et non pour une durabilité stricte. Un basculement est automatiquement déclenché si le primaire devient inaccessible, promouvant le réplica au rang de leader. La réplication étant asynchrone, certaines écritures validées peuvent être perdues au cours de ce processus. Ce délai de réplication définit l'objectif de point de récupération (RPO) des déploiements de Databases for Redis.
Pour réduire le risque de perte de données, Databases for Redis prend en charge des mécanismes de persistance tels que les snapshots RDB et AOF(Append Only File), qui écrivent les données sur le disque indépendamment du processus de réplication. Ceux-ci doivent être configurés avec soin en fonction des exigences de la charge de travail.
La réplication asynchrone dans Databases for Redis garantit des performances rapides mais n'élimine pas la possibilité de perte de données lors d'événements de basculement. Il est recommandé pour les charges de travail où la vitesse et la disponibilité l'emportent sur une cohérence stricte des données.
Architecture de reprise après sinistre
La stratégie générale de reprise après sinistre consiste à créer une nouvelle base de données, comme la base de données Restore ci-dessous. Le contenu de la nouvelle base de données peut être une sauvegarde de la base de données
source créée avant le sinistre.
Fonctionnalités de reprise après sinistre
Databases for Redis prend en charge les fonctions de reprise après sinistre suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Restauration de la sauvegarde | Créer une base de données à partir d'une sauvegarde créée précédemment; voir Gestion des sauvegardes Cloud Databases. | Les nouvelles chaînes de connexion pour la base de données restaurée doivent être référencées dans l'ensemble de la charge de travail. |
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) | (Exemple) IBM fournit une base de données qui résiste à un seul point de défaillance matérielle au sein d'une zone. Aucune configuration n'est requise de la part du client. |
| défaillance de zone | Basculement automatique. Les membres de la base de données sont répartis entre les zones. |
| Altération de données | Restauration de la sauvegarde. Utilisez la base de données restaurée en production ou comme source de données pour corriger la corruption dans la base de données restaurée. |
Haute disponibilité au niveau de l'application
Les applications qui communiquent par le biais de réseaux et de services cloud sont sujettes à des pannes de connexion transitoires. Vous souhaitez concevoir vos applications de telle manière que les connexions soient relancées lorsque des erreurs se produisent à cause d'une perte temporaire de connectivité avec votre déploiement ou avec IBM Cloud.
Comme Databases for Redis est un service géré, les mises à jour régulières et la maintenance de la base de données font partie des opérations normales. Cela peut parfois entraîner de courts intervalles pendant lesquels votre base de données n'est pas disponible. Cela peut également provoquer le déclenchement d'une séquence normale de basculement, relance et reconnexion par la base de données. Il faut peu de temps à la base de données pour déterminer quel membre est une réplique et quel membre est le maître, par conséquent, il se peut aussi que vous constatiez une courte interruption de connexion. Les basculements ne durent généralement pas plus de 30 secondes.
Vos applications doivent être conçues pour gérer les interruptions temporaires de la base de données, mettre en œuvre une gestion des erreurs en cas d'échec des commandes de la base de données et mettre en œuvre une logique de réessai pour récupérer après une interruption temporaire interruption.Use IOREDIS, NODEREDIS ou tout autre paquet de votre choix pour assurer la continuité de votre application.For Pour plus d'informations, voir l'article de blog sur la détection et la gestion des erreurs à l'aide de Redis.
Une interruption de connexion ou une non-disponibilité de la base de données pendant plusieurs minutes n'est pas censée se produire. Ouvrez un dossier d'assistance avec des détails si vous avez des périodes de plus d'une minute sans connectivité afin que nous puissions enquêter.
limites de connexion
Databases for Redis fixe un maximum de 10 000 connexions simultanées par déploiement. Cette limite garantit la stabilité des performances et la gestion des ressources dans votre environnement Redis. Cependant, les 10 000 connexions ne sont pas toutes disponibles pour les clients - une partie est réservée en interne pour les opérations qui maintiennent l'état et l'intégrité du déploiement. Une fois la limite de connexion atteinte, toute tentative d'établissement d'une nouvelle connexion aboutit à une erreur. Pour plus d'informations, voir Gestion des connexions Redis.
Vos responsabilités en matière d'HA et de DR
Les informations suivantes peuvent vous aider à créer et à mettre en pratique en permanence votre plan pour l'AH et le DR.
Lors de la restauration d'une base de données à partir de sauvegardes ou d'une restauration ponctuelle, une nouvelle base de données est créée avec de nouvelles chaînes de connexion. Les charges de travail et les processus existants doivent être adaptés pour utiliser les nouvelles chaînes de connexion.
Une base de données récupérée peut également avoir besoin des mêmes dépendances créées par le client que la base de données sinistrée. S'assurer que ces services et d'autres existent dans la région récupérée :
- IBM® Key Protect for IBM Cloud®
N'oubliez pas que la suppression d'une base de données entraîne également la suppression des sauvegardes qui lui sont associées. Toutefois, les bases de données supprimées peuvent être récupérées dans un délai limité. Pour plus d'informations, voir la FAQ sur les sauvegardes.
Il n'est pas possible de copier des sauvegardes à partir du site IBM Cloud, il faut donc envisager d'utiliser les outils spécifiques à la base de données pour effectuer des sauvegardes supplémentaires. Il peut être nécessaire de récupérer une base de données malveillante supprimée, suivie d'une réclamation-suppression de la base de données. Une gestion rigoureuse de l'accès IAM aux bases de données peut contribuer à réduire l'exposition à ce problème.
La liste de contrôle suivante, associée à chaque caractéristique, peut vous aider à créer et à mettre en pratique votre plan.
- Restauration de la sauvegarde
- Vérifier que les sauvegardes sont disponibles à la fréquence souhaitée pour répondre aux exigences du RPO. La gestion des sauvegardes sur Cloud Databases documente la fréquence des sauvegardes.
- Il existe certaines restrictions sur les régions de restauration des bases de données - vérifiez que vos objectifs de restauration peuvent être atteints en lisant la rubrique gestion des sauvegardes du site Cloud Databases.
- Vérifiez que la durée de conservation des sauvegardes est conforme à vos exigences.
- Planifier régulièrement des restaurations de test pour vérifier que les temps de restauration réels respectent le RTO défini. N'oubliez pas que la taille de la base de données a un impact significatif sur le temps de restauration. Envisagez des stratégies pour réduire les temps de restauration, par exemple en divisant les grandes bases de données en unités plus petites et plus faciles à gérer et en purgeant les données inutilisées.
- Vérifiez le service Key Protect.
Pour en savoir plus sur la répartition des responsabilités entre le client et IBM Cloud pour l'utilisation de Databases for Redis, voir Partage des responsabilités pour Cloud Databases.
Restez informé : IBM notifications
Les mises à jour affectant les charges de travail des clients sont communiquées par le biais de notifications à l'adresse IBM Cloud. Pour rester informé de la maintenance planifiée, des annonces et des notes de version relatives à ce service, consultez la page Notifications de surveillance et état d'avancement. En outre, consultez régulièrement la page consacrée à la politique en matière de versions pour connaître les dernières mises à jour concernant les versions et les dates de fin de vie.