Description de la haute disponibilité et de la reprise après incident pour Databases for Elasticsearch
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 de la haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.
Databases for Elasticsearch est un service régional qui remplit les objectifs de niveau de service(SLO) définis avec le plan standard.
Pour plus d'informations, voir Accord de niveau de service(SLA). IBM Cloud Pour plus d'informations sur les régions et les centres de données disponibles pour Databases for Elasticsearch, voir Disponibilité des services et de l'infrastructure par emplacement.
Architecture à haute disponibilité
Databases for Elasticsearch 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 doté de trois membres de données. Elasticsearch utilise des index pour stocker les données et chaque index dispose d'un shard primaire et d'un shard réplique. Elasticsearch utilise un modèle de réplication des données basé sur le modèle primaire-sauvegarde. Le shard primaire sert de point d'entrée principal pour les opérations d'indexation, tandis que les autres copies sont appelées "shards répliques". La réplication asynchrone est utilisée pour maintenir les répliques à jour. Elasticsearch assure la stabilité de l'état de la grappe et facilite le basculement. En cas d'indisponibilité du nœud maître, un nouveau maître est élu et les répliques sur le nouveau maître sont promues au rang de maître. Le leader et les répliques sont répartis géographiquement dans différentes zones du cluster afin d'atténuer le risque de défaillances simultanées.
Vous pouvez étendre la haute disponibilité en ajoutant des répliques aux index, mais cela entraîne des coûts de stockage supplémentaires qu'il convient de prendre en considération.
Consultez la documentation Elasticsearch sur les techniques de réplication pour comprendre les contraintes et les compromis associés à la stratégie de réplication asynchrone déployée par défaut.
Fonctions de haute disponibilité
Databases for Elasticsearch 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ésilient en cas de défaillance d'une zone ou d'un seul membre. | |
Nombre de membres | Minimum 3 membres. Par défaut, il s'agit d'un déploiement standard à trois. | |
Mise à l'échelle horizontale | Il est possible de faire évoluer votre déploiement IBM Cloud Databases for Elasticsearch horizontalement en ajoutant des nœuds Elasticsearch (également appelés membres). L'ajout de nœuds supplémentaires augmente la capacité et la fiabilité. |
Architecture de reprise après sinistre
Fonctionnalités de reprise après sinistre
Databases for Elasticsearch 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 précédemment créée. Pour plus d'informations, 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. |
Mise à l'échelle horizontale | Il est possible de faire évoluer votre déploiement IBM Cloud Databases for Elasticsearch horizontalement en ajoutant des nœuds Elasticsearch (également appelés membres). L'ajout de nœuds supplémentaires rendra votre base de données plus résistante aux défaillances de plusieurs zones. | |
Instantanés | Vous pouvez stocker des instantanés dans un référentiel d'instantanés accessible à partir de plusieurs régions. Cependant, les instantanés ne sont pas en temps réel et sont généralement utilisés à des fins de sauvegarde et de restauration plutôt que pour un basculement immédiat. En cas de défaillance, vous devez restaurer manuellement à partir d'un instantané. |
Planification du désamorçage
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) | 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. |
défaillance de zone | Basculement automatique. Les membres de la base de données sont répartis entre les zones. La configuration de trois membres offre une résilience supplémentaire en cas de défaillance de plusieurs 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. |
Défaillance régionale | Restauration de la sauvegarde. Utiliser la base de données restaurée en production. |
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. Concevez vos applications de manière à ce qu'elles tentent à nouveau de se connecter lorsque les erreurs sont dues à une perte temporaire de connectivité à votre déploiement ou à IBM Cloud.
Comme Databases for Elasticsearch 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 une reprise en ligne gracieuse de la base de données, une nouvelle tentative et une reconnexion. 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 des interruptions temporaires de connexion à la base de données, implémenter le traitement d'erreurs pour les commandes de base de données qui échouent et implémenter une logique de relance pour effectuer une reprise après une interruption temporaire.
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 Elasticsearch n'a pas de restrictions sur le nombre de connexions que vous ouvrez à la base de données car il utilise l'API REST pour interagir avec la base de données. Elasticsearch les paramètres par défaut du logiciel offrent une bonne expérience pour les opérations de base, telles que la recherche en texte intégral, la mise en évidence, les agrégations et l'indexation.
Si vous souhaitez que notre base de données soit plus performante, consultez la page Optimiser Elasticsearch pour plus d'informations.
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. Veiller à ce que ces services et d'autres existent dans la région récupérée :
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
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, consultez la documentation de la FAQ sur les sauvegardes pour obtenir des détails spécifiques sur les procédures de récupération des bases de données.
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.
- Planifiez 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. Veuillez envisager des stratégies pour minimiser 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 Elasticsearch, 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.