Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

ElastiCache mejores prácticas y estrategias de almacenamiento en caché

A continuación, encontrarás las mejores prácticas recomendadas para Amazon ElastiCache. Si observa estos procedimientos, mejorará el rendimiento y la fiabilidad de su caché.

TLS ElastiCache clústeres de doble pila habilitados

Cuando TLS está habilitada para ElastiCache los clústeres, las funciones de detección de clústeres (cluster slotscluster shards, y cluster nodes para Redis) o config get clusterpara Memcached devuelven los nombres de host en lugar de. IPs Luego, los nombres de host se utilizan en lugar de para conectarse IPs al ElastiCache clúster y realizar un apretón de manos. TLS Esto significa que los clientes no se verán afectados por el parámetro de detección de IP. En el caso de los clústeres TLS habilitados, el parámetro IP Discovery no afecta al protocolo IP preferido. En su lugar, el protocolo IP utilizado dependerá del protocolo IP que prefiera el cliente a la hora de resolver DNS los nombres de host.

Clientes de Java

Si se conecta desde un entorno Java compatible con ambos IPv4IPv6, Java preferirá por defecto la compatibilidad IPv4 con IPv6 versiones anteriores. Sin embargo, la preferencia del protocolo IP se puede configurar mediante los JVM argumentos. PreferirIPv4, JVM aceptar -Djava.net.preferIPv4Stack=true y preferir IPv6 establecidos-Djava.net.preferIPv6Stack=true. La configuración -Djava.net.preferIPv4Stack=true significa que ya no JVM realizará ninguna IPv6 conexión. En el caso de Valkey o RedisOSS, esto incluye las aplicaciones a otras aplicaciones que no son de Valkey ni de Redis. OSS

Preferencias de nivel de host

En general, si el cliente o el entorno de ejecución del cliente no proporcionan opciones de configuración para establecer una preferencia de protocolo IP, al realizar la DNS resolución, el protocolo IP dependerá de la configuración del host. De forma predeterminada, la mayoría de los hosts IPv6 lo prefierenIPv4, pero esta preferencia se puede configurar a nivel de host. Esto afectará a todas las DNS solicitudes de ese host, no solo a las dirigidas a los ElastiCache clústeres.

Hosts de Linux

Para Linux, se puede configurar una preferencia de protocolo IP modificando el archivo gai.conf. El archivo gai.conf se encuentra en /etc/gai.conf. Si no se especifica gai.conf, debería haber disponible un ejemplo en /usr/share/doc/glibc-common-x.xx/gai.conf que se pueda copiar a /etc/gai.conf. Además, la configuración predeterminada no debe estar comentada. Para actualizar la configuración que prefiera IPv4 al conectarse a un ElastiCache clúster, actualice la prioridad del CIDR rango que abarca el clúster IPs para que esté por encima de la prioridad de las conexiones predeterminadas. IPv6 De forma predeterminada, IPv6 las conexiones tienen una prioridad de 40. Por ejemplo, suponiendo que el clúster esté ubicado en una subred con CIDR 172.31.0. 0:0 /16, la siguiente configuración provocará que los clientes prefieran las conexiones a ese clúster. 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

Puede encontrar más información disponible sobre gai.conf en la página principal de Linux

Hosts de Windows

El proceso para los hosts de Windows es similar. Para los hosts de Windows puede ejecutar netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL. Esto tiene el mismo efecto que modificar el archivo gai.conf en los hosts de Linux.

Esto actualizará las políticas de preferencias para preferir las conexiones a IPv4 las conexiones del rango especificadoIPv6. CIDR Por ejemplo, netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 si el clúster se encuentra en una subred con 172.31.0. 0:0 /16 en CIDR ejecución, aparecerá la siguiente tabla de prioridad, lo que provocará que los clientes prefieran IPv4 conectarse al clúster.

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