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 prácticas recomendadas para Amazon ElastiCache. Si observa estos procedimientos, mejorará el rendimiento y la fiabilidad de su caché.
Temas
Clústeres de doble pila ElastiCache compatibles con TLS
Cuando se habilita el TLS para ElastiCache los clústeres, las funciones de detección de clústeres (cluster slotscluster shards, y cluster nodes para Redis) o config get cluster para Memcached devuelven los nombres de host en lugar de los nombres de servidor. IPs A continuación, los nombres de host se utilizan en lugar de utilizarse IPs para conectarse al ElastiCache clúster 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
Cuando se conecta desde un entorno Java compatible con ambos IPv4 IPv6, Java preferirá de forma predeterminada la compatibilidad IPv4 con versiones anteriores IPv6 . Sin embargo, la preferencia del protocolo IP se puede configurar mediante los argumentos de JVM. Si prefiere IPv4, la JVM acepta -Djava.net.preferIPv4Stack=true y prefiere el IPv6 conjunto-Djava.net.preferIPv6Stack=true. La configuración -Djava.net.preferIPv4Stack=true significa que la JVM ya no realizará ninguna IPv6 conexión. 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 IPv6 prefieren IPv4 no hacerlo, pero esta preferencia se puede configurar a nivel de host. Esto afectará a todas las solicitudes de DNS 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 preferida IPv4 al conectarse a un ElastiCache clúster, actualice la prioridad del rango CIDR 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 el 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 las IPv4 conexiones del rango CIDR IPv6 especificado. 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 el CIDR 172.31.0. 0:0 /16 en ejecución, se generará la siguiente tabla de prioridad, lo que provocará que los clientes prefieran conectarse al clúster. 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
