Composants de cluster DAX

Un cluster Amazon DynamoDB Accelerator (DAX) est constitué 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 :

• En ajoutant des nœuds supplémentaires au cluster. Cela a pour effet d'accroître le débit de lecture global du cluster.

• En utilisant un type de nœud plus grand. Les types de nœuds de plus grande taille offrent une capacité supérieure et peuvent accroître le débit. (Vous devez créer un nouveau cluster avec le nouveau type de nœud.)

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 :

• Réponse aux demandes d'application pour les données mises en cache.

• Gestion des opérations d'écriture sur DynamoDB.

• Élimination des données du cache, selon la stratégie d'éviction du cluster.

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.

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

• Réponse aux demandes d'application pour les données mises en cache.

• Élimination des données du cache, selon la stratégie d'éviction du cluster.

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 :

• Scalabilité. Si un grand nombre de clients d'application doivent accéder à DAX simultanément, vous pouvez ajouter des réplicas pour la mise à l'échelle de la lecture. DAX répartit uniformément la charge sur tous les nœuds dans le cluster. (Une autre méthode permettant d'accroître le débit consiste à utiliser des types de nœud de cache supérieurs.)

• Haute disponibilité. En cas d'échec du nœud principal, DAX bascule automatiquement vers un réplica en lecture et le désigne en tant que nouveau nœud principal. En cas d'échec d'un nœud réplica, d'autres nœuds dans le cluster DAX peuvent encore servir les demandes jusqu'à la récupération du nœud en échec. Pour bénéficier d'une tolérance aux pannes maximale, vous devez déployer les réplicas en lecture dans des zones de disponibilité distinctes. Cette configuration garantit que votre cluster DAX peut continuer à fonctionner, même si une zone de disponibilité entière devient indisponible.

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

Important

Pour une utilisation en production, nous vous recommandons vivement d'utiliser DAX avec au moins trois nœuds, chacun d'eux étant placé dans des zones de disponibilité différentes. Trois nœuds sont requis pour qu'un cluster DAX soit tolérant aux défaillances.

Un cluster DAX peut être déployé avec un ou deux nœuds pour des charges de travail de développement ou de test. Un cluster à un ou deux nœuds n'est pas tolérant aux défaillances ; nous recommandons au moins trois nœuds pour une utilisation en production. Si un cluster à un ou deux nœuds rencontre des erreurs logicielles ou matérielles, il peut devenir indisponible ou perdre des données mises en cache.

Régions et Zones de disponibilité

Un cluster DAX situé dans une région AWS déterminée ne peut interagir qu'avec des 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.

Important

Ne placez pas tous les nœuds de votre cluster dans une seule zone de disponibilité. Dans cette configuration, votre cluster DAX devient indisponible en cas d'échec d'une zone de disponibilité.

Pour une utilisation en production, nous vous recommandons vivement d'utiliser DAX avec au moins trois nœuds, chacun d'eux étant placé dans des zones de disponibilité différentes. Trois nœuds sont requis pour qu'un cluster DAX soit tolérant aux défaillances.

Un cluster DAX peut être déployé avec un ou deux nœuds pour des charges de travail de développement ou de test. Un cluster à un ou deux nœuds n'est pas tolérant aux défaillances ; nous recommandons au moins trois nœuds pour une utilisation en production. Si un cluster à un ou deux nœuds rencontre des erreurs logicielles ou matérielles, il peut devenir indisponible ou perdre des données mises en cache.

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 compte AWS et isolé d'autres VPC. 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 d'un cluster DAX est limité aux applications s'exécutant sur des instances Amazon EC2 au sein d'un environnement de VPC Amazon. Vous pouvez utiliser des groupes de sous-réseaux pour accorder l'accès au cluster à partir d'instances Amazon EC2 s'exécutant 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 DescribeEvents 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 a un créneau de maintenance hebdomadaire au cours duquel toutes les modifications systèmes seront appliquées. Si vous ne spécifiez pas de fenêtre de maintenance souhaitée lors de la création ou de la modification d'un cluster de cache, DAX affecte une fenêtre de maintenance de 60 minutes sur un jour de la semaine pris au hasard.

Cette fenêtre de maintenance de 60 minutes est sélectionnée de manière aléatoire sur un bloc de temps de 8 heures par 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.

Code région	Nom de la région	Fenêtre de maintenance
ap-northeast-1	Région Asie-Pacifique (Tokyo)	13:00–21:00 UTC
ap-southeast-1	Région Asia Pacific (Singapore)	14:00–22:00 UTC
ap-southeast-2	Région Asia Pacific (Sydney)	12:00–20:00 UTC
ap-south-1	Région Asia Pacific (Mumbai)	17:30–1:30 UTC
cn-northwest-1	Région Chine (Ningxia)	23:00–07:00 UTC
cn-north-1	Région Chine (Pékin)	14:00–22:00 UTC
eu-central-1	Région Europe (Frankfurt)	23:00–07:00 UTC
eu-west-1	Région Europe (Ireland)	22:00–06:00 UTC
eu-west-2	Région Europe (London)	23:00–07:00 UTC
eu-west-3	Région Europe (Paris)	23:00–07:00 UTC
sa-east-1	Région South America (São Paulo)	01:00–09:00 UTC
us-east-1	Région US East (N. Virginia)	03:00–11:00 UTC
us-east-2	Région US East (Ohio)	23:00–07:00 UTC
us-west-1	Région US West (N. California)	06:00–14:00 UTC
us-west-2	Région US West (Oregon)	06:00–14:00 UTC

Le créneau de maintenance doit intervenir au moment où l'utilisation est la plus faible et peut donc nécessiter d'être modifié de temps en temps. 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.