Procedimientos recomendados y estrategias de almacenamiento en caché de ElastiCache
A continuación, puede encontrar los procedimientos recomendados para Amazon ElastiCache. Si observa estos procedimientos, mejorará el rendimiento y la fiabilidad de su caché.
Temas
Clústeres de ElastiCache de doble pila compatibles con TLS
Cuando se habilita TLS para los clústeres de ElastiCache, las funciones de detección de clústeres (cluster slots, cluster shards y cluster nodes para Redis) o config get cluster para Memcached devuelven nombres de host en lugar de IP. A continuación, se utilizan los nombres de host en lugar de las IP para conectarse al clúster de ElastiCache y realizar un protocolo de enlace 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 habilitados para TLS, el parámetro de detección de IP no tiene ningún efecto en el protocolo IP preferido. En cambio, el protocolo IP utilizado se determinará según el protocolo IP que prefiera el cliente al resolver los nombres de host de DNS.
Clientes de Java
Al conectarse desde un entorno de Java que admite IPv4 e IPv6, Java preferirá de forma predeterminada IPv4 en lugar de IPv6 por motivos de compatibilidad con versiones anteriores. Sin embargo, la preferencia del protocolo IP se puede configurar mediante los argumentos de JVM. Para preferir IPv4, JVM acepta -Djava.net.preferIPv4Stack=true y para preferir IPv6 establece -Djava.net.preferIPv6Stack=true. La configuración de -Djava.net.preferIPv4Stack=true significa que JVM ya no realizará ninguna conexión IPv6. En el caso de Valkey o Redis OSS, esto incluye 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 ofrecen opciones de configuración para establecer una preferencia de protocolo IP, al realizar la resolución de DNS, el protocolo IP dependerá de la configuración del host. De forma predeterminada, la mayoría de los hosts prefieren IPv6 en lugar de IPv4, pero esta preferencia se puede establecer en el nivel de host. Esto afectará a todas las solicitudes de DNS de ese host, no solo a las dirigidas a los clústeres de ElastiCache.
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. Si desea actualizar la configuración para preferir IPv4 al conectarse a un clúster de ElastiCache, actualice la prioridad del rango de CIDR que abarca las IP del clúster para que esté por encima de la prioridad de las conexiones IPv6 predeterminadas. De forma predeterminada, las conexiones IPv6 tienen una prioridad de 40. Por ejemplo, suponiendo que el clúster esté ubicado en una subred con el CIDR 172.31.0.0:0/16, la siguiente configuración haría que los clientes prefirieran las conexiones IPv4 a ese clúster.
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, de modo que se prefieran las conexiones IPv4 en lugar de las conexiones IPv6 para el rango de CIDR especificado. Por ejemplo, suponiendo que el clúster esté en una subred con el CIDR 172.31.0.0:0/16, ejecutar netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 generaría la siguiente tabla de prioridades, lo que haría que los clientes prefirieran IPv4 al 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
