ElastiCache meilleures pratiques et stratégies de mise en cache

Vous trouverez ci-dessous les meilleures pratiques recommandées pour Amazon ElastiCache. La mise en œuvre de ces bonnes pratiques améliore les performances et la fiabilité de votre cache.

Rubriques

• Bonnes pratiques générales
• Commandes Valkey, Redis et Memcached prises en charge OSS et restreintes
• OSSConfiguration et limites de Valkey et Redis
• IPv6exemples de clients pour Valkey, Redis et Memcached OSS
• Meilleures pratiques pour les clients (Valkey et RedisOSS)
• Bonnes pratiques pour les clients (Memcached)
• TLS ElastiCache clusters à double pile activés
• Gestion de la mémoire réservée pour Valkey et Redis OSS
• Meilleures pratiques lors de l'utilisation de clusters conçus par Valkey et Redis OSS
• Stratégies de mise en cache pour Memcached

TLS ElastiCache clusters à double pile activés

Lorsqu'elle TLS est activée pour les ElastiCache clusters, les fonctions de découverte de clusters (cluster slots,cluster shards, et cluster nodes pour Redis) ou config get cluster pour Memcached renvoient des noms d'hôte au lieu de. IPs Les noms d'hôtes sont ensuite utilisés au lieu de se IPs connecter au ElastiCache cluster et d'effectuer une TLS poignée de main. Cela signifie que les clients ne seront pas affectés par le paramètre de découverte d’adresses IP. Pour les clusters TLS activés, le paramètre IP Discovery n'a aucun effet sur le protocole IP préféré. Au lieu de cela, le protocole IP utilisé sera déterminé par le protocole IP que le client préfère lors de la résolution des DNS noms d'hôtes.

Clients Java

Lorsque vous vous connectez à partir d'un environnement Java qui prend en charge IPv4 les deuxIPv6, Java IPv4 privilégiera par défaut IPv6 la rétrocompatibilité. Toutefois, la préférence du protocole IP est configurable par le biais des JVM arguments. PréférerIPv4, JVM accepter -Djava.net.preferIPv4Stack=true et préférer IPv6 définir-Djava.net.preferIPv6Stack=true. Le réglage -Djava.net.preferIPv4Stack=true signifie qu'il n'JVMétablira plus aucune IPv6 connexion. Pour Valkey ou RedisOSS, cela inclut celles destinées à d'autres applications non-Valkey et non-Redis. OSS

Préférences au niveau de l'hôte

En général, si le client ou l'environnement d'exécution du client ne fournit pas d'options de configuration pour définir une préférence de protocole IP, lors de la DNS résolution, le protocole IP dépendra de la configuration de l'hôte. Par défaut, la plupart des hôtes IPv6 préfèrent, IPv4 mais cette préférence peut être configurée au niveau de l'hôte. Cela affectera toutes les DNS demandes de cet hôte, et pas seulement celles adressées aux ElastiCache clusters.

Hôtes Linux

Pour Linux, une préférence de protocole IP peut être configurée en modifiant le fichier gai.conf. Le fichier gai.conf se trouve sous /etc/gai.conf. Si gai.conf n'est pas spécifié, un exemple doit être disponible sous /usr/share/doc/glibc-common-x.xx/gai.conf. Vous pouvez le copier sur /etc/gai.conf et la configuration par défaut doit être sans commentaire. Pour mettre à jour la configuration à privilégier IPv4 lors de la connexion à un ElastiCache cluster, mettez à jour la priorité de la CIDR plage englobant le cluster IPs afin qu'elle soit supérieure à la priorité des connexions par défaut. IPv6 Par défaut, IPv6 les connexions ont une priorité de 40. Par exemple, en supposant que le cluster est situé dans un sous-réseau avec le CIDR 172.31.0. 0:0 /16, la configuration ci-dessous incitera les clients à préférer les connexions à ce cluster. IPv4

label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
label fec0::/10     5
label fc00::/7      6
label 2001:0::/32   7
label ::ffff:172.31.0.0/112 8
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
precedence ::ffff:0:0/96  10
precedence ::ffff:172.31.0.0/112 100

Plus de détails sur gai.conf sont disponibles sur la Linux main page (Page principale de Linux).

Hôtes Windows

Le processus pour les hôtes Windows est similaire. Pour les hôtes Windows, vous pouvez exécuter netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL. Cela a le même effet que la modification du fichier gai.conf sur les hôtes Linux.

Cela mettra à jour les politiques de préférence afin de préférer IPv4 les IPv6 connexions aux connexions pour la CIDR plage spécifiée. Par exemple, en supposant que le cluster se trouve dans un sous-réseau avec le 172.31.0. 0:0 /16 en cours d'CIDRexécution, le tableau de priorité suivant netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 se produira, ce qui incitera les clients à préférer se connecter au cluster. IPv4

C:\Users\Administrator>netsh interface ipv6 show prefixpolicies
Querying active state...

Precedence Label Prefix
---------- ----- --------------------------------
100 15 ::ffff:172.31.0.0:0/112
20 4 ::ffff:0:0/96
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96