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.
# ElastiCache composants et fonctionnalités
Vous trouverez ci-dessous un aperçu des principaux composants d'un ElastiCache déploiement Amazon.
**Topics**
+ [ElastiCache nœuds](#WhatIs.Components.Nodes)
+ [ElastiCache éclats](#WhatIs.Components.Shards)
+ [ElastiCache clusters](#WhatIs.Components.Clusters)
+ [ElastiCache réplication](#WhatIs.Components.ReplicationGroups)
+ [ElastiCache points de terminaison](#WhatIs.Components.Endpoints)
+ [ElastiCache groupes de paramètres](#WhatIs.Components.ParameterGroups)
+ [ElastiCache sécurité](#WhatIs.Components.Security)
+ [ElastiCache groupes de sous-réseaux](#WhatIs.Components.SubnetGroups)
+ [ElastiCache sauvegardes](#WhatIs.Components.Snapshots)
+ [ElastiCache événements](#WhatIs.Components.Events)
## ElastiCache nœuds
Un *nœud* est le plus petit élément constitutif d'un ElastiCache déploiement. Un nœud peut exister par lui-même ou en relation avec d'autres nœuds.
Un nœud est un bloc de RAM sécurisée, de dimension fixe et attachée à un réseau. Chaque nœud exécute une instance du moteur et de la version choisis quand vous avez créé le cluster. Si nécessaire, vous pouvez faire évoluer les nœuds d'un cluster vers une instance d'un type différent. Pour de plus amples informations, veuillez consulter [Dimensionnement ElastiCache](Scaling.md).
Chaque nœud d'un cluster est du même type d'instance et exécute le même moteur de cache. Chaque nœud de cache a son propre nom DNS et son propre port. Plusieurs types de nœuds de cache sont pris en charge, chacun avec différentes tailles de mémoire associée. Pour obtenir une liste des types d'instances de nœuds pris en charge, consultez [Types de nœuds pris en charge](CacheNodes.SupportedTypes.md).
Vous pouvez acheter des nœuds sur une pay-as-you-go base où vous ne payez que pour l'utilisation d'un nœud. Ou bien vous pouvez acquérir des nœuds réservés à un coût horaire beaucoup plus avantageux. Si votre taux d'utilisation est élevé, vous pouvez faire des économies en achetant des nœuds réservés. Imaginons que votre cluster est utilisé en permanence et que vous ajoutez des nœuds pour faire face aux pics d'utilisation. Dans ce cas, vous pouvez acheter un certain nombre de nœuds réservés à exécuter la plupart du temps. Vous pouvez ensuite acheter pay-as-you-go des nœuds pour les moments où vous devez parfois ajouter des nœuds. Pour plus d'informations sur les nœuds réservés, consultez [Nœuds réservés](CacheNodes.Reserved.md).
Pour plus d'informations sur les nœuds, consultez [Gestion des nœuds dans ElastiCache](CacheNodes.md).
## ElastiCache éclats
Une partition Valkey ou Redis *OSS* (appelée *groupe de nœuds* dans l'API et la CLI) est un regroupement de un à six nœuds connexes. Un cluster Valkey ou Redis OSS avec le mode cluster activé possède toujours au moins une partition.
Le sharding est une méthode de partitionnement de bases de données qui sépare les grandes bases de données en parties plus petites, plus rapides et plus faciles à gérer, appelées fragments de données. Cela peut améliorer l'efficacité de la base de données en répartissant les opérations entre plusieurs sections distinctes. L'utilisation de partitions peut offrir de nombreux avantages, notamment une amélioration des performances, de l'évolutivité et de la rentabilité.
Les clusters Valkey et Redis OSS avec le mode cluster activé peuvent contenir jusqu'à 500 partitions, vos données étant partitionnées entre les partitions. La limite de nœuds ou de partitions peut être augmentée jusqu'à un maximum de 500 par cluster si la version du moteur Valkey ou Redis OSS est 5.0.6 ou supérieure. Par exemple, vous pouvez choisir de configurer un cluster de 500 nœuds compris entre 83 (un principal et 5 réplicas par partition) et 500 partitions (un principal et aucun réplicas). Assurez-vous qu’il y ait suffisamment d’adresses IP disponibles pour faire face à l’augmentation. Les pièges courants incluent les sous-réseaux du groupe de sous-réseaux avec une plage CIDR trop petite ou les sous-réseaux partagés et fortement utilisés par d’autres clusters. Pour de plus amples informations, veuillez consulter [Création d'un groupe de sous-réseaux](SubnetGroups.Creating.md). Pour les versions antérieures à 5.0.6, la limite est de 250 par cluster.
Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et sélectionnez le type de limite **Nœuds par cluster par type d'instance**.
Une *partition avec plusieurs nœuds* implémente la réplication avec un nœud principal en lecture/écriture et de 1 à 5 nœuds de réplica. Pour de plus amples informations, veuillez consulter [Haute disponibilité avec les groupes de réplication](Replication.md).
Pour plus d'informations sur les partitions, consultez [Utilisation de fragments dans ElastiCache](Shards.md).
## ElastiCache clusters
Un *cluster* est un regroupement logique d'un ou de plusieurs [nœuds](CacheNodes.md). Les données sont partitionnées entre les nœuds d'un cluster Memcached et entre les partitions d'un cluster Valkey ou Redis OSS dont le mode cluster est activé.
De nombreuses ElastiCache opérations ciblent les clusters :
+ Création d’un cluster
+ Modification d’un cluster
+ Réalisation d'instantanés d'un cluster (toutes les versions de Redis)
+ Suppression d’un cluster
+ Affichage des éléments d'un cluster
+ Ajout ou suppression des balises de répartition des coûts vers et depuis un cluster
Pour en savoir plus, consultez les rubriques connexes suivantes :
+ [Gestion des clusters dans ElastiCache](Clusters.md) et [Gestion des nœuds dans ElastiCache](CacheNodes.md)
Informations sur les clusters, les nœuds et les opérations connexes.
+ [AWS limites de service : Amazon ElastiCache](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elasticache)
Informations sur ElastiCache les limites, telles que le nombre maximum de nœuds ou de clusters. Pour dépasser certaines de ces limites, vous pouvez faire une demande à l'aide du [formulaire de demande de nœud de ElastiCache cache Amazon](https://aws.amazon.com/contact-us/elasticache-node-limit-request/).
+ [Atténuation des défaillances](disaster-recovery-resiliency.md#FaultTolerance)
Informations sur l'amélioration de la tolérance aux pannes de vos clusters et de vos groupes de réplication Valkey ou Redis OSS.
### Configurations de clusters classiques
Voici des configuration de cluster classiques.
#### Clusters Valkey ou Redis OSS
Les clusters Valkey ou Redis OSS dont le mode cluster est désactivé contiennent toujours une seule partition (dans l'API et la CLI, un groupe de nœuds). Une partition Valkey ou Redis OSS contient un à six nœuds. S'il y a plus d'un nœud dans une partition, celle-ci prend en charge la réplication. Dans ce cas, un nœud est le nœud read/write principal et les autres sont des nœuds de réplication en lecture seule.
Pour une meilleure tolérance aux pannes, nous recommandons d'avoir au moins deux nœuds dans un cluster Valkey ou Redis OSS et d'activer le mode multi-AZ. Pour de plus amples informations, veuillez consulter [Atténuation des défaillances](disaster-recovery-resiliency.md#FaultTolerance).
À mesure que la demande de votre cluster Valkey ou Redis OSS change, vous pouvez augmenter ou diminuer. Pour ce faire, déplacez votre cluster vers un autre type d'instance de nœud. Si votre application est gourmande en lecture, nous vous recommandons d'ajouter des répliques en lecture seule au cluster. En faisant cela, vous pouvez répartir les lectures sur un nombre plus approprié de nœuds.
Vous pouvez également utiliser la hiérarchisation des données. Les données les plus fréquemment consultées sont stockées en mémoire et les données les moins fréquemment consultées sont stockées sur disque. L'avantage de l'utilisation de la hiérarchisation des données est qu'elle réduit les besoins en mémoire. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
ElastiCache permet de changer dynamiquement le type de nœud d'un cluster Valkey ou Redis OSS en un type de nœud plus grand. Pour plus d'informations sur le dimensionnement, consultez [Mise à l'échelle pour les clusters Valkey ou Redis OSS (mode cluster désactivé)](scaling-redis-classic.md#Scaling.RedisStandalone) ou [Dimensionnement des nœuds de réplication pour Valkey ou Redis OSS (mode cluster désactivé)](Scaling.RedisReplGrps.md).
#### Configurations de cluster typiques pour Memcached
Memcached prend en charge jusqu'à 300 nœuds par client pour chaque AWS région, chaque cluster comportant de 1 à 60 nœuds. Vous partitionnez vos données sur plusieurs nœuds dans un cluster Memcached.
Lorsque vous exécutez le moteur Memcached, les clusters peuvent être composés de 1 à 60 nœuds. Vous partitionnez votre base de données sur plusieurs nœuds. Votre application a un accès en lecture et en écriture sur le point de terminaison de chaque nœud. Pour plus d’informations, consultez [Découverte automatique](AutoDiscovery.md).
Pour améliorer la tolérance aux pannes, localisez vos nœuds Memcached dans différentes zones de disponibilité (AZs) au sein de la région du AWS cluster. Ainsi, une défaillance dans une zone de disponibilité a un impact minimal sur l'ensemble du cluster et de l'application. Pour de plus amples informations, veuillez consulter [Atténuation des défaillances](disaster-recovery-resiliency.md#FaultTolerance).
Au fur et à mesure que votre cluster Memcached change, vous pouvez le faire évoluer en ajoutant ou supprimant des nœuds, qui répartissent vos données sur le nouvel ensemble de nœuds. Lorsque vous partitionnez vos données, nous vous recommandons d'utiliser le hachage cohérent. Pour plus d'informations sur le hachage cohérent, consultez [Configuration de votre ElastiCache client pour un équilibrage de charge efficace (Memcached)](BestPractices.LoadBalancing.md).
## ElastiCache réplication
Pour Valkey et Redis OSS, la réplication est mise en œuvre en regroupant de deux à six nœuds dans un shard (dans l'API et la CLI, appelé groupe de nœuds). L'un de ces nœuds est le nœud principal en lecture/écriture. Tous les autres nœuds sont des nœuds de réplica en lecture seule. Les réplications ne sont disponibles que ElastiCache pour Valkey et Redis OSS, et non pour ElastiCache Memcached.
Chaque nœud de réplica conserve une copie des données du nœud principal. Les nœuds de réplica utilisent des mécanismes de réplication asynchrones pour maintenir les réplicas en lecture synchronisés avec le nœud principal. Les applications peuvent lire à partir de n'importe lequel des nœuds du cluster, mais peuvent écrire uniquement dans le cluster principal. Les réplicas en lecture améliorent l'adaptabilité en répartissant les lectures sur plusieurs points de terminaison. Les réplicas en lecture améliorent également la tolérance aux pannes en conservant plusieurs copies des données de Le fait de répartir les réplicas en lecture sur plusieurs Zones de disponibilité permet d'améliorer davantage la tolérance aux pannes. Pour plus d'informations sur la tolérance aux pannes, consultez [Atténuation des défaillances](disaster-recovery-resiliency.md#FaultTolerance).
Les clusters Valkey ou Redis OSS prennent en charge une partition (dans l'API et la CLI, appelée groupe de *nœuds*).
La réplication du point de vue de l'API et de la CLI utilise une terminologie différente pour assurer la compatibilité avec les versions antérieures, mais les résultats sont identiques. Le tableau suivant présente les termes employés par l'API et la CLI pour l'implémentation de la réplication.
**Comparaison de la réplication : Valkey ou Redis OSS (mode cluster désactivé) et Valkey ou Redis OSS (mode cluster activé) --> Cluster Valkey ou Redis OSS avec le mode cluster activé par rapport au cluster Valkey ou Redis OSS avec le mode cluster désactivé**
Dans le tableau suivant, vous trouverez une comparaison des fonctionnalités des groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) et des groupes de réplication Valkey ou Redis OSS (mode cluster activé).
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/WhatIs.Components.html)
Toutes les partitions (dans l'API et la CLI, groupes de nœuds) et tous les nœuds doivent résider dans la même région AWS. Cependant, vous pouvez approvisionner les nœuds individuels dans plusieurs zones de disponibilité au sein de cette AWS région.
Les réplicas en lecture évitent les pertes de données potentielles car les données sont répliquées sur deux ou plusieurs nœuds, le principal et un ou plusieurs réplicas en lecture. Pour une plus grande fiabilité et une récupération plus rapide, nous vous recommandons de créer une ou plusieurs répliques de lecture dans différentes zones de disponibilité.
Vous pouvez également tirer parti des banques de données mondiales. En utilisant la fonctionnalité Global Datastore pour Redis OSS, vous pouvez utiliser une réplication entièrement gérée, rapide, fiable et sécurisée entre les régions AWS. Grâce à cette fonctionnalité, vous pouvez créer des clusters de répliques de lecture entre régions afin de permettre des lectures ElastiCache à faible latence et une reprise après sinistre dans toutes les régions AWS. Pour plus d'informations, voir [Réplication entre AWS régions à l'aide de banques de données globales](Redis-Global-Datastore.md).
**Réplication : limites et exclusions**
+ Multi-AZ n'est pas pris en charge sur les types de nœuds T1.
## ElastiCache points de terminaison
Un *point de terminaison* est l'adresse unique que votre application utilise pour se connecter à un ElastiCache nœud ou à un cluster.
### Points de terminaison à nœud unique pour Valkey ou Redis OSS avec le mode cluster désactivé
Le point de terminaison d'un cluster Valkey ou Redis OSS à nœud unique est utilisé pour se connecter au cluster pour les lectures et les écritures.
### Points de terminaison à nœuds multiples pour Valkey ou Redis OSS avec le mode cluster désactivé
Un cluster Valkey ou Redis OSS à plusieurs nœuds dont le mode cluster est désactivé possède deux types de points de terminaison. Le point de terminaison principal se connecte toujours au nœud principal du cluster, même si le rôle du nœud spécifique dans le principal change. Utilisez le point de terminaison principal pour toutes les écritures dans le cluster.
Utilisez le Point de terminaison du lecteur pour répartir également les connexions entrantes vers le point de terminaison entre toutes les réplicas lues. Utilisez les points de terminaison de nœud individuels pour les opérations de lecture (ils API/CLI sont appelés points de terminaison de lecture).
### Points de terminaison Valkey ou Redis OSS (mode cluster activé)
Un cluster Valkey ou Redis OSS avec le mode cluster activé possède un point de terminaison de configuration unique. En se connectant au point de terminaison de configuration, votre application est en mesure de découvrir les points de terminaison principal et de lecture pour chaque partition du cluster.
Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md).
### ElastiCache pour les points de terminaison Memcached
Chaque nœud d'un cluster Memcached a son propre point de terminaison. Le cluster a également un point de terminaison appelé le *configuration endpoint* (point de terminaison de la configuration). Si vous activez La découverte automatique et que vous vous connectez au point de terminaison de configuration, votre application *découvre* automatiquement le point de terminaison de chaque nœud, même après l'ajout ou la suppression des nœuds du cluster. Pour plus d’informations, consultez [Découverte automatique](AutoDiscovery.md).
Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md).
## ElastiCache groupes de paramètres
Les groupes de paramètres de cache sont un moyen simple de gérer les paramètres d'exécution pour le logiciel de moteur pris en charge. Les paramètres permettent de contrôler l'utilisation de la mémoire, les règles d'expulsion, la taille des objets, etc. Un groupe de ElastiCache paramètres est un ensemble nommé de paramètres spécifiques au moteur que vous pouvez appliquer à un cluster. En faisant cela, vous vous assurez que tous les nœuds de ce cluster sont configurés exactement de la même manière.
Pour une liste des paramètres pris en charge, leurs valeurs par défaut et ceux qui peuvent être modifiés, consultez [DescribeEngineDefaultParameters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEngineDefaultParameters.html) (CLI : [describe-engine-default-parameters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-engine-default-parameters.html)).
Pour des informations plus détaillées sur les groupes de ElastiCache paramètres, consultez[Configuration des paramètres du moteur à l'aide de groupes de ElastiCache paramètres](ParameterGroups.md).
## ElastiCache sécurité
Pour renforcer la sécurité, l'accès aux ElastiCache nœuds est limité aux applications exécutées sur les EC2 instances Amazon que vous autorisez. Vous pouvez contrôler les EC2 instances Amazon qui peuvent accéder à votre cluster à l'aide de groupes de sécurité.
Par défaut, tous les nouveaux ElastiCache clusters sont lancés dans un environnement Amazon Virtual Private Cloud (Amazon VPC). Vous pouvez utiliser des *groupes de sous-réseaux* pour accorder l'accès au cluster à partir d' EC2instances Amazon exécutées sur des sous-réseaux spécifiques.
Outre la restriction de l'accès aux nœuds, ElastiCache prend en charge le protocole TLS et le chiffrement sur place pour les nœuds exécutant des versions spécifiées de. ElastiCache Pour plus d’informations, consultez les ressources suivantes :
+ [Sécurité des données sur Amazon ElastiCache](encryption.md)
+ [Authentification avec la commande Valkey et Redis OSS AUTH](auth.md)
## ElastiCache groupes de sous-réseaux
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.
Si vous créez un cluster dans un Amazon VPC, vous devez spécifier un groupe de sous-réseaux. ElastiCache utilise ce groupe de sous-réseaux de cache pour choisir un sous-réseau et les adresses IP au sein de ce sous-réseau à associer à vos nœuds de cache.
Pour plus d'informations sur l'utilisation du groupe de sous-réseaux de cache dans un environnement Amazon VPC, consultez les ressources suivantes :
+ [Amazon VPCs et la ElastiCache sécurité](VPCs.md)
+ [Étape 3. Autoriser l'accès au cluster](SubnetGroups.designing-cluster-pre.valkey.md#GettingStarted.AuthorizeAccess.valkey)
+ [Sous-réseaux et groupes de sous-réseaux](SubnetGroups.md)
## ElastiCache sauvegardes
Une *sauvegarde* est une point-in-time copie d'un cluster Valkey ou Redis OSS ou d'un cache sans serveur, ou d'un cache sans serveur Memcached. Les sauvegardes peuvent être utilisées pour restaurer un cluster existant ou pour amorcer un nouveau cluster. Les sauvegardes sont constituées de toutes les données d'un cluster, plus quelques métadonnées.
Selon la version de Valkey ou Redis OSS exécutée sur votre cluster, le processus de sauvegarde nécessite différentes quantités de mémoire réservée pour réussir. Pour plus d’informations, consultez les ressources suivantes :
+ [Instantané et restauration](backups.md)
+ [Implémentation de la sauvegarde et de la synchronisation](Replication.Redis.Versions.md)
+ [Impact sur les performances des sauvegardes de clusters basés sur des nœuds](backups.md#backups-performance)
+ [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md)
## ElastiCache événements
Lorsque des événements importants se produisent sur un cluster, ElastiCache envoie une notification à une rubrique Amazon SNS spécifique. Ces événements peuvent inclure des éléments tels que l'échec ou la réussite de l'ajout d'un nœud, une modification du groupe de sécurité, etc. En surveillant les événements clés, vous pouvez connaître l'état actuel de vos clusters et, dans de nombreux cas, prendre des actions correctives.
Pour plus d'informations sur ElastiCache les événements, consultez[Surveillance des événements par Amazon SNS ElastiCache](ECEvents.md).