Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Exemples de client IPv6
Vous trouverez ci-dessous les meilleures pratiques pour interagir avec les ElastiCache ressources compatibles IPv6 avec les bibliothèques clientes open source couramment utilisées. Vous pouvez consulter les meilleures pratiques existantes en matière d'interaction pour ElastiCache obtenir des
Clients validés
ElastiCache est compatible avec Redis open source. Cela signifie que les clients Redis open source qui prennent en charge les connexions IPv6 devraient être en mesure de se connecter à IPv6 activé ElastiCache pour les clusters Redis. En outre, plusieurs clients Python et Java parmi les plus populaires ont été spécifiquement testés et validés pour fonctionner avec toutes les configurations de type de réseau prises en charge (IPv4 uniquement, IPv6 uniquement et double pile).
Clients validés :
Configuration d'un protocole préféré pour les clusters à double pile
Pour les clusters Redis activés en mode cluster, vous pouvez contrôler le protocole que les clients utiliseront pour se connecter aux nœuds du cluster à l'aide du paramètre de découverte d'adresses IP. Le paramètre de découverte d'adresses IP peut être défini sur IPv4 ou IPv6.
Pour les clusters Redis, le paramètre de découverte d'adresses IP définit le protocole IP utilisé dans les emplacements de cluster ()
La modification de la découverte d'adresses IP n'entraînera aucune interruption de service pour les clients connectés. Cependant, la propagation des modifications prendra un certain temps. Pour déterminer quand les modifications se sont complètement propagées pour un cluster Redis, surveillez la sortie des cluster slots. Une fois que tous les nœuds renvoyés par la commande emplacements de cluster ont indiqué les adresses IP avec le nouveau protocole, la propagation des modifications est terminée.
Exemple avec 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)
Exemple avec 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; }));
Clusters à double pile ElastiCache compatibles TLS
Lorsque le protocole TLS est activé pour les ElastiCache clusters, les fonctions de découverte des clusters (cluster slots,cluster shards, etcluster nodes) renvoient des noms d'hôtes plutôt que des adresses IP. Les noms d'hôtes sont ensuite utilisés à la place des adresses IP pour se connecter au ElastiCache cluster et effectuer une prise de contact TLS. Cela signifie que les clients ne seront pas affectés par le paramètre de découverte d’adresses IP. Pour les clusters prenant en charge TLS, le paramètre de découverte d'adresses IP 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 noms d'hôtes DNS.
Clients Java
Lorsque vous vous connectez à partir d'un environnement Java prenant en charge à la fois IPv4 et IPv6, Java préfère par défaut IPv4 à IPv6 pour des raisons de rétrocompatibilité. Toutefois, les arguments JVM permettent de configurer la préférence de protocole IP. Pour préférer IPv4, la JVM accepte -Djava.net.preferIPv4Stack=true et pour préférer IPv6, -Djava.net.preferIPv6Stack=true. Le paramètre -Djava.net.preferIPv4Stack=true signifie que la JVM n'établira plus de connexions IPv6. Y compris celles destinées à d'autres applications autres que Redis.
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 permettant de définir une préférence de protocole IP, lors de la résolution DNS, le protocole IP dépendra de la configuration de l’hôte. Par défaut, la plupart des hôtes préfèrent IPv6 à IPv4, mais cette préférence peut être configurée au niveau de l'hôte. Cela affectera toutes les demandes DNS 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 afin de préférer IPv4 lors de la connexion à un ElastiCache cluster, mettez à jour la priorité de la plage d'adresses CIDR comprenant les adresses IP du cluster afin qu'elle soit supérieure à la priorité des connexions IPv6 par défaut. Les connexions IPv6 ont par défaut une priorité de 40. Par exemple, en supposant que le cluster se trouve dans un sous-réseau avec l'adresse CIDR 172.31.0.0:0/16, la configuration ci-dessous inciterait les clients à préférer les connexions IPv4 à ce cluster.
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
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 les connexions IPv4 aux connexions IPv6 pour la plage CIDR spécifiée. Par exemple, en supposant que le cluster se trouve dans un sous-réseau avec l'adresse CIDR 172.31.0.0:0/16 exécutant netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15, le tableau de priorité suivant inciterait les clients à préférer IPv4 lors de la connexion au cluster.
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
