Quelle est la marche à suivre pour mettre en œuvre la reprise après sinistre ou la tolérance aux pannes pour mon cluster Redis Amazon ElastiCache ?

Dernière mise à jour : 15/09/2020

Je dois mettre en œuvre la reprise après sinistre ou la tolérance aux pannes pour mes données de cluster Redis Amazon ElastiCache. Quelles sont les options disponibles ?

Solution

Les solutions de tolérance aux pannes disponibles disposent chacune de leur propre équilibre entre durabilité des données, impact sur les performances et coût. Choisissez celle qui convient le mieux à votre cas d'utilisation :

Déploiement multi-AZ

Le déploiement multi-AZ est la meilleure option lorsque la conservation des données, les interruptions minimales et les performances des applications constituent une priorité.

  • Potentiel de perte de données – Faible. Le déploiement multi-AZ présente une tolérance aux pannes pour chaque scénario, y compris les problèmes matériels.
  • Impact sur les performances - Faible. Parmi les options disponibles, le déploiement multi-AZ présente le temps de récupération le plus court, étant donné qu'il n'existe aucune procédure manuelle à suivre une fois que le processus est mis en œuvre.
  • Coût – Faible à élevé. Le déploiement multi-AZ constitue l'option la moins onéreuse. Appuyez-vous sur le déploiement multi-AZ lorsque vous ne pouvez pas prendre le risque de perdre des données en raison d'une défaillance matérielle ou vous permettre de faire face au temps d'arrêt requis par d'autres options lorsque vous réagissez à une interruption de service.

Pour plus d'informations sur le déploiement multi-AZ, consultez Minimiser les temps d'arrêt dans ElastiCache pour Redis avec le déploiement multi-AZ.

Sauvegardes automatiques quotidiennes

Vous pouvez planifier des sauvegardes automatiques quotidiennes à un moment où vous prévoyez une faible utilisation des ressources pour votre cluster. ElastiCache crée une sauvegarde du cluster, puis écrit toutes les données du cache dans un fichier RDB Redis. Les versions 2.8.22 et ultérieures de Redis mettent en œuvre une sauvegarde sans fonction fork susceptible d'améliorer les performances.

Remarque : la sauvegarde et la restauration Redis ne sont pas prises en charge sur les nœuds cache.t1.micro pour des clusters en mode Cluster désactivé.

  • Potentiel de perte de données - Élevé (jusqu'à concurrence d'une journée). Les sauvegardes automatiques quotidiennes sont conservées jusqu'à 35 jours.
  • Impact sur les performances - Moyen à élevé. L'exécution de plusieurs sauvegardes de fichiers tout au long de la journée a une incidence sur les performances. Pour améliorer les performances, envisagez d'activer des instantanés RDB sur un nœud secondaire à persistance seule désigné. Ensuite, désactivez les instantanés RDB et les fichiers en ajout uniquement (AOF) Redis sur le nœud principal et tous les autres nœuds secondaires.
  • Coût – Faible à moyen. Le coût du stockage augmente avec le nombre de sauvegardes et la durée de conservation des données.

Avant de mettre en œuvre la sauvegarde et la restauration, prenez en considération les limitations causées par les contraintes inhérentes à la sauvegarde. Pour obtenir des informations détaillées sur la mise en œuvre des sauvegardes pour les clusters ElastiCache exécutant Redis, consultez Sauvegarde et restauration ElastiCache pour Redis. Pour plus d'informations, consultez Réalisation de sauvegardes manuelles.

Sauvegardes manuelles à l'aide de fichiers en ajout uniquement (AOF) Redis

Les sauvegardes manuelles utilisant AOF sont conservées indéfiniment et sont utiles à des fins de test et d'archivage. Les sauvegardes manuelles peuvent aussi être planifiées de manière à se produire jusqu'à 20 fois par nœud sur une période de 24 heures.

Pour activer la fonctionnalité AOF pour un cluster Redis, créez un groupe de paramètres avec le paramètre appendonly défini sur yes (oui). Ensuite, affectez le groupe de paramètres à votre cluster.

Lorsque vous utilisez la fonctionnalité AOF, tenez compte des points suivants :

  • Pour améliorer les performances, envisagez d'activer des instantanés RDB sur un nœud secondaire à persistance seule désigné. Ensuite, désactivez les instantanés RDB et AOF sur le nœud principal et tous les autres nœuds secondaires.
  • Pour améliorer les performances, définissez la valeur du paramètre appendfsync sur everysec ou no (non) pour écrire sur le disque toutes les secondes ou lorsque cela est nécessaire.
  • La fonctionnalité AOF est prise en charge uniquement pour une utilisation avec Redis 2.8.21 et version antérieure.
  • La fonctionnalité AOF est soumise aux limitations décrites dans Atténuation des défaillances : Fonctionnalité AOF Redis.
  • La fonctionnalité AOF n'est pas prise en charge pour les nœuds cache.t1.micro et cache.t2.*, ainsi que pour les groupes de réplication multi-AZ. Pour les nœuds de ces types, la valeur du paramètre appendonly est ignorée.

L'utilisation de sauvegardes manuelles à l'aide de la fonctionnalité AOF, native dans Redis 2.8.21 et version antérieure, est une option appropriée pour conserver un niveau de persistance de données élevé pour un coût relativement faible.

  • Potentiel de perte de données – Faible à moyen. Bien que la fonctionnalité AOF fournisse une mesure de tolérance aux pannes, elle ne peut pas protéger vos données contre une défaillance du nœud de cache lié au matériel. Il y a donc un risque de perte de données.
  • Impact sur les performances – Faible à élevé. L'impact des performances de la fonctionnalité AOF est étroitement lié à la valeur du paramètre appendfsync, qui contrôle la fréquence à laquelle le tampon de sortie AOF est écrit sur disque. Plus la fréquence à laquelle le buffer de sortie est écrit sur disque est importante, plus l'impact sur les performances est élevé. Si vous choisissez l'option always (toujours) pour ce paramètre, le buffer est vidé à chaque fois que les données de cache sont modifiées. Cette option n'est donc pas recommandée. La taille du fichier AOF pouvant augmenter rapidement, il est recommandé de vérifier vos exigences en matière d'espace disque. Le temps requis pour relire un fichier AOF constitue également une autre considération relative aux performances. Remplir les nœuds Redis avec les données de cache peut prendre plusieurs minutes. Pendant ce temps, votre application peut satisfaire des requêtes uniquement pour des données non mises en cache en interrogeant directement votre base de données.
  • Coût – Faible à moyen. Le coût AOF est fortement lié aux exigences en matière de temps et aux considérations sur les performances lorsque vous devez relire un fichier AOF. Les exigences liées à l'espace disque sont plus importantes que les options d'instantané décrites précédemment.

Pour plus d'informations, consultez Fichiers AOF ElastiCache pour Redis.