Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Esempi di client IPv6
Di seguito sono riportate le migliori pratiche per interagire con risorse compatibili con IPv6 con librerie client open source di uso comune. ElastiCache È possibile visualizzare le best practice esistenti con cui interagire per
Clienti convalidati
ElastiCache è compatibile con Redis open source. Ciò significa che i client Redis open source che supportano le connessioni IPv6 dovrebbero essere in grado di connettersi a IPv6 abilitati per i cluster Redis. ElastiCache Inoltre, molti dei client Python e Java più diffusi sono stati collaudati e convalidati specificamente per funzionare con tutte le configurazioni di tipi di rete supportate (solo IPv4, solo IPv6 e dual-stack)
Clienti convalidati:
Configurazione di un protocollo preferito per i cluster dual-stack
Per cluster Redis (modalità cluster abilitata), puoi controllare il protocollo che verrà utilizzato dai client per connettersi ai nodi del cluster con il parametro IP Discovery. Il parametro IP Discovery può essere impostato su IPv4 o IPv6.
Per i cluster Redis, il parametro IP Discovery imposta il protocollo IP utilizzato nell'output slot del cluster ()
La modifica di IP Discovery non comporterà alcun tempo di inattività per i client connessi. Tuttavia, la propagazione delle modifiche richiederà tempo. Per determinare quando la propagazione delle modifiche è terminata per un cluster Redis, monitorare l'output di cluster slots. Dopo che tutti i nodi restituiti dal comando slot del cluster segnalano IP con il nuovo protocollo, la propagazione delle modifiche è terminata.
Esempio 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)
Esempio 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; }));
Cluster dual stack abilitati per TLS ElastiCache
Quando TLS è abilitato per ElastiCache i cluster, le funzioni di rilevamento dei cluster (cluster slotscluster shards, ecluster nodes) restituiscono nomi host anziché IP. I nomi host vengono quindi utilizzati al posto degli IP per connettersi al ElastiCache cluster ed eseguire un handshake TLS. Ciò significa che i client non sono interessati dal parametro Individuazione IP. Per i cluster abilitati per TLS, il parametro Individuazione IP non ha alcun effetto sul protocollo IP preferito. Invece, il protocollo IP utilizzato verrà determinato in base a quello preferito dal client durante la risoluzione dei nomi host DNS.
Client Java
Quando si esegue la connessione da un ambiente Java che supporta sia IPv4 che IPv6, per impostazione predefinita Java preferirà IPv4 rispetto a IPv6 per la compatibilità con le versioni precedenti. Tuttavia, la preferenza del protocollo IP è configurabile tramite gli argomenti JVM. Per preferire IPv4, la JVM accetta -Djava.net.preferIPv4Stack=true e per preferire IPv6 imposta -Djava.net.preferIPv6Stack=true. Se si imposta -Djava.net.preferIPv4Stack=true, significa che la JVM non effettuerà più connessioni IPv6. Inclusi quelli per altre applicazioni non Redis.
Preferenze a livello di host
In generale, se il client o il runtime client non forniscono opzioni di configurazione per l'impostazione di una preferenza del protocollo IP, quando si esegue la risoluzione DNS, il protocollo IP dipenderà dalla configurazione dell'host. Per impostazione predefinita, la maggior parte degli host preferisce IPv6 rispetto a IPv4, ma questa preferenza può essere configurata a livello di host. Ciò influirà su tutte le richieste DNS provenienti da quell'host, non solo su quelle ai cluster. ElastiCache
Host Linux
Per Linux, una preferenza protocollo IP può essere configurata modificando il file gai.conf. Il file gai.conf è disponibile in /etc/gai.conf. Se non è specificato alcun gai.conf, uno di esempio deve essere disponibile in /usr/share/doc/glibc-common-x.xx/gai.conf che può essere copiato in /etc/gai.conf; è quindi necessario rimuovere i commenti dalla configurazione predefinita. Per aggiornare la configurazione in modo da preferire l'IPv4 durante la connessione a un ElastiCache cluster, aggiorna la precedenza per l'intervallo CIDR che comprende gli IP del cluster in modo che sia superiore alla precedenza per le connessioni IPv6 predefinite. Per impostazione predefinita, alle connessioni IPv6 viene assegnata una priorità di 40. Ad esempio, presupponendo che il cluster si trovi in una sottorete con il CIDR 172.31.0.0:0/16, la configurazione sottostante porterebbe i client a preferire le connessioni IPv4 a tale 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
Ulteriori dettagli su gai.conf sono disponibili nella pagina principale di Linux
Host Windows
Il processo per gli host Windows è simile. Per gli host Windows è possibile eseguire netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL. L'effetto è identico alla modifica del file gai.conf su host Linux.
Ciò aggiornerà le policy di preferenza in modo da preferire le connessioni IPv4 rispetto alle connessioni IPv6 per l'intervallo CIDR specificato. Ad esempio, presupponendo che il cluster si trovi in una sottorete con il CIDR 172.31.0.0:0/16, l'esecuzione di netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 genererebbe la seguente tabella di priorità che porterebbe i client a preferire IPv4 durante la connessione al 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
