Minimiser les temps d'arrêt dans MemoryDB avec Multi-AZ - Amazon MemoryDB
Scénarios de défaillance avec réponses multi-AZTest du basculement automatique

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Minimiser les temps d'arrêt dans MemoryDB avec Multi-AZ

Dans un certain nombre de cas, MemoryDB peut avoir besoin de remplacer un nœud principal ; il s'agit notamment de certains types de maintenance planifiée et de l'éventualité peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité.

La réponse à une défaillance d'un nœud dépend du nœud défaillant. Cependant, dans tous les cas, MemoryDB garantit qu'aucune donnée n'est perdue lors du remplacement ou du basculement des nœuds. Par exemple, si une réplique échoue, le nœud défaillant est remplacé et les données sont synchronisées à partir du journal des transactions. En cas de défaillance du nœud principal, un basculement est déclenché vers une réplique cohérente, ce qui garantit qu'aucune donnée n'est perdue pendant le basculement. Les écritures sont désormais effectuées depuis le nouveau nœud principal. L'ancien nœud principal est ensuite remplacé et synchronisé à partir du journal des transactions.

Si un nœud principal tombe en panne sur une partition à nœud unique (pas de répliques), MemoryDB cesse d'accepter les écritures jusqu'à ce que le nœud principal soit remplacé et synchronisé à partir du journal des transactions.

Le remplacement du nœud peut entraîner un certain temps d'arrêt pour le cluster, mais si Multi-AZ est actif, le temps d'arrêt est minimisé. Le rôle du nœud principal basculera automatiquement vers l'une des répliques. Il n'est pas nécessaire de créer et de provisionner un nouveau nœud principal, car MemoryDB gérera cela de manière transparente. Ce basculement et la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.

Dans le cas de remplacements de nœuds planifiés initiés en raison de mises à jour de maintenance ou de mises à jour de service, sachez que les remplacements de nœuds prévus sont terminés pendant que le cluster traite les demandes d'écriture entrantes.

Le multi-AZ sur vos clusters MemoryDB améliore votre tolérance aux pannes. Cela est particulièrement vrai dans les cas où les nœuds principaux de votre cluster deviennent inaccessibles ou tombent en panne pour une raison quelconque. Le mode multi-AZ sur les clusters MemoryDB nécessite que chaque partition possède plusieurs nœuds et est automatiquement activé.

Scénarios de défaillance avec réponses multi-AZ

Si Multi-AZ est actif, un nœud principal défaillant bascule vers une réplique disponible. La réplique est automatiquement synchronisée avec le journal des transactions et devient principale, ce qui est beaucoup plus rapide que la création et le reprovisionnement d'un nouveau nœud principal. Ce processus dure généralement quelques secondes pendant lesquelles vous ne pouvez pas écrire sur le cluster.

Lorsque Multi-AZ est actif, MemoryDB surveille en permanence l'état du nœud principal. En cas de défaillance du nœud principal, l'une des actions suivantes est effectuée selon le type de la défaillance.

Scénarios d'échec lorsque seul le nœud primaire échoue

Si seul le nœud principal tombe en panne, une réplique deviendra automatiquement le nœud principal. Une réplique de remplacement est ensuite créée et mise en service dans la même zone de disponibilité que la réplique principale défaillante.

Lorsque seul le nœud principal tombe en panne, MemoryDB Multi-AZ effectue les opérations suivantes :

  1. Le nœud principal défaillant est mis hors ligne.

  2. Une up-to-date réplique devient automatiquement principale.

    Les écritures peuvent reprendre dès que le processus de basculement est terminé, généralement quelques secondes seulement.

  3. Une réplique de remplacement est lancée et provisionnée.

    La réplique de remplacement est lancée dans la zone de disponibilité dans laquelle se trouvait le nœud principal défaillant afin que la distribution des nœuds soit maintenue.

  4. La réplique est synchronisée avec le journal des transactions.

Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :

 

Scénarios de défaillance en cas de défaillance du nœud principal et de certaines répliques

Si le principal et au moins un réplica échouent, un up-to-date réplica est promu en cluster principal. De nouvelles répliques sont également créées et approvisionnées dans les mêmes zones de disponibilité que les nœuds défaillants.

Lorsque le nœud principal et certaines répliques échouent, MemoryDB Multi-AZ effectue les opérations suivantes :

  1. Le nœud principal défaillant et les répliques défaillantes sont mis hors ligne.

  2. Une réplique disponible deviendra le nœud principal.

    Les écritures peuvent reprendre dès que le basculement est terminé, généralement quelques secondes seulement.

  3. Des réplicas de remplacement sont créés et provisionnés.

    Les réplicas de remplacement sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue.

  4. Tous les nœuds sont synchronisés avec le journal des transactions.

Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :

 

Scénarios d'échec lorsque l'ensemble du cluster tombe en panne

En cas de défaillance générale, tous les nœuds sont recréés et mis en service dans les mêmes zones de disponibilité que les nœuds initiaux.

Il n'y a aucune perte de données dans ce scénario car les données étaient conservées dans le journal des transactions.

Lorsque l'ensemble du cluster échoue, MemoryDB Multi-AZ effectue les opérations suivantes :

  1. Le nœud principal défaillant et les répliques sont mis hors ligne.

  2. Un nœud principal de remplacement est créé et provisionné, synchronisé avec le journal des transactions.

  3. Des répliques de remplacement sont créées et approvisionnées, synchronisées avec le journal des transactions.

    Les remplacements sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue.

Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :

Test du basculement automatique

Vous pouvez tester le basculement automatique à l'aide de la console MemoryDB, de l'API MemoryDB et de l' AWS CLI API MemoryDB.

Lors du test, tenez compte des points suivants :

  • Vous pouvez utiliser cette opération jusqu'à cinq fois par période de 24 heures.

  • Si vous appelez cette opération sur des partitions de différents clusters, vous pouvez effectuer les appels simultanément.

  • Dans certains cas, vous pouvez appeler cette opération plusieurs fois sur différentes partitions du même cluster MemoryDB. Dans de tels cas, le premier remplacement de nœud doit se terminer avant qu'un appel ultérieur puisse être effectué.

  • Pour déterminer si le remplacement du nœud est terminé, vérifiez les événements à l'aide de la console MemoryDB, de l'API MemoryDB ou de l' AWS CLI API MemoryDB. Recherchez les événements suivants liés àFailoverShard, listés ici par ordre d'occurrence probable :

    1. message du cluster : FailoverShard API called for shard <shard-id>

    2. message du cluster : Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. message du cluster : Recovering nodes <node-id>

    4. message du cluster : Finished recovery for nodes <node-id>

    Pour plus d’informations, consultez les ressources suivantes :

  • Cette API est conçue pour tester le comportement de votre application en cas de basculement de MemoryDB. Elle n’a pas été conçue pour être un outil opérationnel permettant de lancer un basculement pour résoudre un problème avec le cluster. De plus, dans certaines conditions, telles que des événements opérationnels à grande échelle, cette API AWS peut être bloquée.

Test du basculement automatique à l'aide du AWS Management Console

Utilisez la procédure suivante pour tester le basculement automatique avec la console.

  1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/memorydb/.

  2. Cliquez sur le bouton radio situé à gauche du cluster que vous souhaitez tester. Ce cluster doit comporter au moins un nœud de réplication.

  3. Dans la zone Détails vérifiez que la fonctionnalité Multi-AZ est activée pour ce cluster. Si tel n'est pas le cas, choisissez un autre cluster ou modifiez-le afin d'activer Multi-AZ. Pour plus d’informations, consultez Modification d'un cluster MemoryDB.

  4. Choisissez le nom du cluster.

  5. Sur la page Partitions et nœuds, choisissez le nom de la partition sur laquelle vous souhaitez tester le basculement.

  6. Pour le nœud, choisissez Failover Primary.

  7. Choisissez Continuer pour basculer le nœud principal, ou sur Annuler pour annuler l'opération et ne pas basculer le nœud principal.

    Au cours du processus de basculement, la console continue à afficher le statut available du nœud. Pour suivre l'avancement du test de basculement, choisissezÉvénements dans le volet de navigation de la console. Sous l'onglet Événements, recherchez les événements indiquant que le basculement a commencé (FailoverShard API called) et est terminé (Recovery completed).

 

Test du basculement automatique à l'aide du AWS CLI

Vous pouvez tester le basculement automatique sur n'importe quel cluster compatible Multi-AZ à l'aide de l' AWS CLI opération failover-shard.

Paramètres

  • --cluster-name : obligatoire. Le cluster qui doit être testé.

  • --shard-name : obligatoire. Nom de la partition sur laquelle vous souhaitez tester le basculement automatique. Vous pouvez tester un maximum de cinq partitions sur une période continue de 24 heures.

L'exemple suivant utilise l'appel AWS CLI to failover-shard sur le shard 0001 du cluster MemoryDB. my-cluster

Pour Linux, macOS ou Unix :

aws memorydb failover-shard \
   --cluster-name my-cluster \
   --shard-name 0001

Pour Windows :

aws memorydb failover-shard ^
   --cluster-name my-cluster ^
   --shard-name 0001

Pour suivre la progression de votre basculement, utilisez l' AWS CLI describe-eventsopération.

Il renverra la réponse JSON suivante :

{
    "Events": [
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Failover to replica node my-cluster-0001-002 completed",
            "Date": "2021-08-22T12:39:37.568000-07:00"
        },
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Starting failover for shard 0001",
            "Date": "2021-08-22T12:39:10.173000-07:00"
        }
    ]
}

Pour plus d’informations, consultez les ressources suivantes :

 

Test du basculement automatique à l'aide de l'API MemoryDB

L'exemple suivant fait FailoverShard appel à la partition 0003 du clustermemorydb00.

Exemple Test du basculement automatique
https://memory-db.us-east-1.amazonaws.com/
    ?Action=FailoverShard
    &ShardName=0003
    &ClusterName=memorydb00
    &Version=2021-01-01
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20210801T192317Z
    &X-Amz-Credential=<credential>

Pour suivre la progression de votre basculement, utilisez l'opération d'API MemoryDB. DescribeEvents

Pour plus d’informations, consultez les ressources suivantes :