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.
Ejemplos de cliente de IPv6
Las siguientes son las mejores prácticas para interactuar con ElastiCache recursos habilitados para IPv6 con bibliotecas de clientes de código abierto que se utilizan habitualmente. Puede consultar las prácticas recomendadas actuales con las que interactuar y obtener
Clientes validados
ElastiCache es compatible con Redis de código abierto. Esto significa que los clientes de Redis de código abierto que admiten conexiones IPv6 deberían poder conectarse a IPv6 habilitados para los clústeres de Redis. ElastiCache Además, varios de los clientes de Python y Java más populares se han probado y validado específicamente para que funcionen con todas las configuraciones de tipos de red compatibles (solo IPv4, solo IPv6 y doble pila).
Clientes validados:
Configuración de un protocolo preferido para clústeres de doble pila
En el caso de los clústeres de Redis habilitados para el modo de clúster, puede controlar el protocolo que los clientes utilizarán para conectarse a los nodos del clúster con el parámetro de detección de IP. El parámetro de detección de IP se puede establecer en IPv4 o IPv6.
Para los clústeres de Redis, el parámetro de detección de IP establece el protocolo IP utilizado en la salida de las ranuras del clúster ()
Cambiar la detección de IP no provocará ningún tiempo de inactividad para los clientes conectados. Sin embargo, los cambios tardarán algún tiempo en propagarse. Para determinar cuándo los cambios se han propagado por completo para un clúster de Redis, monitoree la salida de cluster slots. Una vez que todos los nodos devueltos por el comando de ranuras del clúster registren las IP con el nuevo protocolo, los cambios terminarán de propagarse.
Ejemplo con Redis-Py:
cluster = RedisCluster(host="xxxx", port=6379) target_type = IPv6Address # Or IPv4Address if changing to IPv4 nodes = set() while len(nodes) == 0 or not all((type(ip_address(host)) is target_type) for host in nodes): nodes = set() # This refreshes the cluster topology and will discovery any node updates. # Under the hood it calls cluster slots cluster.nodes_manager.initialize() for node in cluster.get_nodes(): nodes.add(node.host) self.logger.info(nodes) time.sleep(1)
Ejemplo con Lettuce:
RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create("xxxx", 6379)); Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4 Set<String> nodes; do { // Check for any changes in the cluster topology. // Under the hood this calls cluster slots clusterClient.refreshPartitions(); Set<String> nodes = new HashSet<>(); for (RedisClusterNode node : clusterClient.getPartitions().getPartitions()) { nodes.add(node.getUri().getHost()); } Thread.sleep(1000); } while (!nodes.stream().allMatch(node -> { try { return finalTargetProtocolType.isInstance(InetAddress.getByName(node)); } catch (UnknownHostException ignored) {} return false; }));
Clústeres de doble pila compatibles con TLS ElastiCache
Cuando el TLS está habilitado para ElastiCache los clústeres, las funciones de detección de clústeres (cluster slotscluster shards, ycluster nodes) devuelven nombres de host en lugar de direcciones IP. A continuación, se utilizan los nombres de host en lugar de las IP 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
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. Incluidas las de otras aplicaciones que no son de Redis.
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. 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. Para actualizar la configuración para que prefiera el IPv4 al conectarse a un ElastiCache clúster, actualice la prioridad del rango 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
