Esempi di client IPv6

Nota

Questa sezione si applica ai cluster Memcached progettati autonomamente.

ElastiCache è compatibile con Memcached open source. Ciò significa che i client open source per Memcached che supportano le connessioni IPv6 dovrebbero essere in grado di connettersi a cluster compatibili con IPv6 (Memcached). ElastiCache Inoltre, i seguenti client sono stati convalidati specificamente per funzionare con tutte le configurazioni di tipi di rete supportate:

Di seguito sono riportate le best practice per interagire con le risorse compatibili con IPv6 con le librerie client open source di uso comune. ElastiCache È possibile visualizzare le best practice esistenti con cui interagire per ottenere consigli sulla configurazione dei ElastiCache client per le risorse. ElastiCache Tuttavia, ci sono alcuni avvertenze che vale la pena segnalare quando si interagisce con risorse abilitate per IPv6.

Clienti convalidati

Clienti convalidati:

• AWS ElastiCache Cluster Client Memcached per Php — versione *3.6.2

• AWS ElastiCache Cluster Client Memcached per Java: master più recente su Github

Configurazione di un protocollo preferito per i cluster dual-stack

Per cluster Memcached 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.

Il parametro IP Discovery controlla il protocollo IP utilizzato nell'output del cluster config get. Il che a sua volta determinerà il protocollo IP utilizzato dai client che supportano l'individuazione automatica per i cluster ElastiCache (Memcached).

La modifica di IP Discovery non comporterà alcun tempo di inattività per i client connessi. Tuttavia, la propagazione delle modifiche richiederà tempo.

Monitorare l'output di getAvailableNodeEndPoints per Java e per Php monitorare l'output di getServerList. Dopo che l'output di queste funzioni segnala gli IP di tutti i nodi del cluster che utilizzano il protocollo aggiornato, la propagazione delle modifiche è terminata.

Esempio di Java

MemcachedClient client = new MemcachedClient(new InetSocketAddress("xxxx", 11211));

Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4

Set<String> nodes;
    
do {
    nodes = client.getAvailableNodeEndPoints().stream().map(NodeEndPoint::getIpAddress).collect(Collectors.toSet());

    Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
            try {
                return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
            } catch (UnknownHostException ignored) {}
            return false;
        }));

Esempio di Php:

$client = new Memcached;
$client->setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE);
$client->addServer("xxxx", 11211);

$nodes = [];
$target_ips_count = 0;
do {
    # The PHP memcached client only updates the server list if the polling interval has expired and a
    # command is sent
    $client->get('test');
 
    $nodes = $client->getServerList();

    sleep(1);
    $target_ips_count = 0;

    // For IPv4 use FILTER_FLAG_IPV4
    $target_ips_count = count(array_filter($nodes, function($node) { return filter_var($node["ipaddress"], FILTER_VALIDATE_IP, FILTER_FLAG_IPV6); }));
 
} while (count($nodes) !== $target_ips_count);

Le eventuali connessioni client esistenti create prima dell'aggiornamento di IP Discovery, verranno comunque connesse utilizzando il vecchio protocollo. Tutti i client convalidati si riconnetteranno automaticamente al cluster utilizzando il nuovo protocollo IP una volta rilevate le modifiche nell'output dei comandi di individuazione del cluster. Tuttavia, ciò dipende dall'implementazione del client.

Cluster dual stack abilitati per TLS ElastiCache

Quando TLS è abilitato per ElastiCache i cluster, le funzioni di rilevamento dei cluster 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.

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 verso i ElastiCache cluster.

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