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.

Composants de cluster DAX

Un cluster Amazon DynamoDB Accelerator (DAX) est composé de composants d'infrastructure. AWS Cette section décrit ces composants et explique comment ils fonctionnent ensemble.

Nœuds

Un nœud est le bloc de construction le plus petit d'un cluster . Chaque nœud exécute une instance du logiciel DAX, et gère un réplica unique des données mises en cache.

Vous pouvez mettre à l'échelle votre cluster DAX de deux manières :

Chaque nœud au sein d'un cluster est de type identique et exécute le même logiciel de mise en cache DAX. Pour accéder à la liste des types de nœuds disponibles, consultez Tarification Amazon DynamoDB.

Clusters

Un cluster est un groupement logique d'un ou plusieurs nœuds que DAX gère en tant qu'unité. L'un des nœuds du cluster est désigné en tant que nœud principal, tandis que les autres nœuds sont des réplicas en lecture (le cas échéant).

Le nœud principal est responsable des éléments suivants :

Lorsque des modifications sont apportées aux données mises en cache sur le nœud primaire, DAX les propage à tous les nœuds de réplica en lecture à l'aide des journaux de réplication. Une fois la confirmation reçue de tous les réplicas en lecture, DynamoDB supprime les journaux de réplication du nœud primaire.

Un cluster DAX peut prendre en charge jusqu'à 11 nœuds par cluster (le nœud primaire, plus jusqu'à 10 réplicas en lecture).

Les réplicas en lecture traitent les opérations suivantes :

Cependant, contrairement au nœud principal, les réplicas en lecture n'écrivent pas sur DynamoDB.

Les réplicas en lecture remplissent deux fonctions supplémentaires :

Régions et zones de disponibilité

Un cluster DAX situé dans une AWS région ne peut interagir qu'avec les tables DynamoDB situées dans la même région. Pour cette raison, vous devez veiller à lancer votre cluster DAX dans la région appropriée. Si vous avez des tables DynamoDB dans d'autres régions, vous devez également lancer des clusters DAX dans celles-ci.

Chaque région est conçue pour être complètement isolée des autres régions . Chaque région dispose de plusieurs zones de disponibilité. En lançant vos nœuds dans différentes zones de disponibilité, vous pouvez obtenir la plus grande tolérance aux pannes possible.

Groupes de paramètres

Des groupes de paramètres sont utilisés pour gérer les paramètres d'exécution des clusters DAX. DAX propose plusieurs paramètres permettant d'optimiser les performances, par exemple, en définissant une politique TTL pour les données mises en cache. Un groupe de paramètres est une collection nommée de paramètres que vous pouvez appliquer à un cluster. En faisant cela, vous vous assurez que tous les nœuds du cluster sont configurés exactement de la même manière.

Groupes de sécurité

Un cluster DAX s'exécute dans un environnement Amazon Virtual Private Cloud (Amazon VPC). Cet environnement est un réseau virtuel dédié à votre AWS compte et isolé des autres VPCs. Un groupe de sécurité agit en tant que pare-feu virtuel pour votre VPC, vous permettant de contrôler le trafic réseau entrant et sortant.

Lorsque vous lancez un cluster dans votre VPC, vous ajoutez une règle d'entrée à votre groupe de sécurité afin d'autoriser le trafic réseau entrant. La règle d'entrée spécifie le protocole (TCP) et le numéro de port (8111) pour votre cluster. Une fois cette règle ajoutée à votre groupe de sécurité, les applications s'exécutant dans votre VPC peuvent accéder au cluster DAX.

ARN de cluster

Un Amazon Resource Name (ARN) est attribué à chaque cluster DAX. Le format de l'ARN est le suivant.

arn:aws:dax:region:accountID:cache/clusterName

Vous utilisez l'ARN du cluster dans une politique IAM pour définir les autorisations pour des opérations d'API DAX. Pour de plus amples informations, veuillez consulter Contrôle d'accès à DAX.

Point de terminaison de cluster

Chaque cluster DAX fournit un point de terminaison de cluster que votre application peut utiliser. En accédant au cluster à l'aide de ce point de terminaison, votre application n'a pas besoin de connaître les noms d'hôte et les numéros de port des nœuds individuels du cluster. Votre application « connaît » automatiquement tous les nœuds du cluster, même si vous ajoutez ou supprimez des réplicas en lecture.

Voici un exemple de point de terminaison de cluster dans la région us-east-1 qui n'est pas configuré pour utiliser le chiffrement en transit.

dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Voici un exemple de point de terminaison de cluster dans la même région qui est configuré pour utiliser le chiffrement en transit.

daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Points de terminaison de nœud

Chacun des nœuds dans un cluster DAX a ses propres nom d'hôte et numéro de port. Voici un exemple de point de terminaison d'un nœud.

myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

Votre application peu accéder directement à un nœud à l'aide de son point de terminaison. Cependant, nous vous recommandons de traiter le cluster DAX en tant qu'unité unique, et d'y accéder en utilisant le point de terminaison de cluster à la place. Le point de terminaison de cluster permet à votre application de ne pas maintenir une liste de nœuds et de garder cette liste à jour lorsque vous ajoutez ou supprimez des nœuds dans le cluster.

Groupes de sous-réseaux

L'accès aux nœuds du cluster DAX est limité aux applications exécutées sur des EC2 instances Amazon au sein d'un environnement Amazon VPC. Vous pouvez utiliser des groupes de sous-réseaux pour accorder l'accès au cluster à partir d' EC2 instances Amazon exécutées sur des sous-réseaux spécifiques. Un groupe de sous-réseaux est un ensemble de sous-réseaux (généralement privés) que vous pouvez utiliser pour vos clusters fonctionnant dans un environnement de VPC Amazon.

Lorsque vous créez un cluster DAX, vous devez spécifier un groupe de sous-réseaux. DAX utilise ce groupe de sous-réseaux de cache pour sélectionner un sous-réseau et des adresses IP au sein de celui-ci à associer à vos nœuds.

Événements

DAX enregistre les événements importants qui se produisent au sein de vos clusters, tels que l'échec ou la réussite de l'ajout d'un nœud, ou des modifications apportées à des groupes de sécurité. En surveillant ces événements clés, vous pouvez connaître l'état actuel de vos clusters et, selon l'événement, vous pouvez prendre une mesure corrective. Vous pouvez accéder à ces événements à l'aide de l'action AWS Management Console ou de l'DescribeEventsaction dans l'API de gestion DAX.

Vous pouvez également demander l'envoi de ces notifications à une rubrique Amazon Simple Notification Service (Amazon SNS) spécifique. Vous serez alors immédiatement informé de tout événement se produisant dans votre cluster DAX.

Fenêtre de maintenance

Chaque cluster dispose d'une fenêtre de maintenance hebdomadaire pour appliquer les modifications du système. Au fur et à mesure que les modifications sont appliquées de manière séquentielle, un nœud existant est remplacé et un nouveau nœud contenant les modifications appliquées est ajouté au cluster. Au cours de cette période, votre application peut être confrontée à des erreurs ou à des ralentissements transitoires. Par conséquent, nous vous recommandons de planifier la période de maintenance pendant la période d'utilisation la plus faible et de modifier ce calendrier périodiquement selon les besoins. Vous pouvez spécifier une plage de temps de 24 heures au cours de laquelle toutes les opérations de maintenance demandées doivent avoir lieu.

Si vous ne spécifiez pas de fenêtre de maintenance préférée lorsque vous créez ou modifiez un cluster de cache, DAX attribue une fenêtre de maintenance de 60 minutes un jour de semaine aléatoire. Cette fenêtre de maintenance de 60 minutes est sélectionnée au hasard parmi une période de 8 heures pour chacune d'entre elles. Région AWS Le tableau suivant répertorie pour les différentes régions les blocs de temps à partir desquels les créneaux de maintenance par défaut sont alloués.