Exemplos de cliente de IPv6

nota

Esta seção se aplica a clusters do Memcached autoprojetados.

ElastiCache é compatível com o Memcached de código aberto. Isso significa que os clientes de código aberto do Memcached que oferecem suporte a conexões IPv6 devem ser capazes de se conectar a clusters habilitados para IPv6 (Memcached). ElastiCache Além disso, os seguintes clientes foram especificamente validados para funcionar com todas as configurações de tipo de rede compatíveis:

A seguir estão as melhores práticas para interagir com ElastiCache recursos habilitados para IPv6 com bibliotecas cliente de código aberto comumente usadas. Você pode ver as melhores práticas existentes para interagir ElastiCache para obter recomendações sobre como configurar clientes para ElastiCache recursos. No entanto, há algumas ressalvas que vale a pena observar ao interagir com recursos habilitados para IPv6.

Clientes validados

Clientes validados:

• AWS ElastiCache Cliente de cluster Memcached para PHP — Versão *3.6.2

• AWS ElastiCache Cluster Client Memcached para Java — Master mais recente no Github

Configurar um protocolo preferencial para clusters de pilha dupla

Para clusters Memcached, você pode controlar o protocolo que os clientes usarão para se conectar aos nós no cluster com o parâmetro de descoberta de IP. O parâmetro de descoberta de IP pode ser definido como IPv4 ou IPv6.

O parâmetro de descoberta de IP controla o protocolo IP usado na saída do cluster config get. O que, por sua vez, determinará o protocolo IP usado pelos clientes que oferecem suporte à descoberta automática para clusters ElastiCache (Memcached).

Alterar a descoberta de IP não resultará em nenhum tempo de inatividade para os clientes conectados. No entanto, as alterações levarão algum tempo para se propagar.

Monitore a saída de getAvailableNodeEndPoints para Java e para Php monitore a saída degetServerList. Depois que a saída dessas funções relata IPs de todos os nós do cluster que usam o protocolo atualizado, as alterações terminam de se propagar.

Exemplo de 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;
        }));

Exemplo de 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);

Qualquer conexão de cliente existente que tenha sido criada antes da atualização da descoberta de IP ainda será conectada usando o protocolo antigo. Todos os clientes validados se reconectarão automaticamente ao cluster usando o novo protocolo IP assim que as alterações forem detectadas na saída dos comandos de descoberta do cluster. No entanto, isso depende da implementação do cliente.

Clusters de ElastiCache pilha dupla habilitados para TLS

Quando o TLS está habilitado para ElastiCache clusters, as funções de descoberta de cluster retornam nomes de host em vez de IPs. Os nomes de host são então usados em vez de IPs para se conectar ao ElastiCache cluster e realizar um handshake TLS. Isso significa que os clientes não serão afetados pelo parâmetro de descoberta de IP. Para clusters habilitados para TLS, o parâmetro de descoberta de IP não tem efeito no protocolo IP preferencial. Em vez disso, o protocolo IP usado será determinado pelo protocolo IP que o cliente prefere ao resolver nomes de host DNS.

Clientes Java

Ao se conectar de um ambiente Java que oferece suporte a IPv4 e IPv6, o Java, por padrão, prefere IPv4 em vez de IPv6 para compatibilidade com versões anteriores. No entanto, a preferência do protocolo IP é configurável por meio dos argumentos da JVM. Para preferir IPv4, a JVM aceita -Djava.net.preferIPv4Stack=true e prefere o conjunto IPv6 -Djava.net.preferIPv6Stack=true. A configuração -Djava.net.preferIPv4Stack=true significa que a JVM não fará mais nenhuma conexão IPv6.

Preferências de nível de host

Em geral, se o runtime do cliente ou o cliente não fornecer opções de configuração para definir uma preferência de protocolo IP, ao executar a resolução de DNS, o protocolo IP dependerá da configuração do host. Por padrão, a maioria dos hosts prefere IPv6 em vez de IPv4, mas essa preferência pode ser configurada no nível do host. Isso afetará todas as solicitações de DNS desse host, não apenas aquelas para ElastiCache clusters.

Hosts Linux

Para Linux, uma preferência de protocolo IP pode ser configurada modificando o arquivo do gai.conf. O arquivo do gai.conf pode ser encontrado em /etc/gai.conf. Se não houver gai.conf especificado, um exemplo deve estar disponível em /usr/share/doc/glibc-common-x.xx/gai.conf, o qual pode ser copiado em /etc/gai.conf, e a configuração padrão não deverá ser comentada. Para atualizar a configuração para preferir IPv4 ao se conectar a um ElastiCache cluster, atualize a precedência do intervalo CIDR que abrange os IPs do cluster para estar acima da precedência das conexões IPv6 padrão. Por padrão, as conexões IPv6 têm uma precedência de 40. Por exemplo, supondo que o cluster esteja localizado em uma sub-rede com o CIDR 172.31.0.0:0/16, a configuração abaixo faria com que os clientes preferissem conexões IPv4 a esse 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

Mais detalhes sobre gai.conf estão disponíveis na página principal do Linux

Hosts do Windows

O processo para hosts do Windows é semelhante. Para hosts do Windows, você pode executar netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL. Isso tem o mesmo resultado que modificar o arquivo gai.conf em hosts Linux.

Isso atualizará as políticas de preferência para preferir conexões IPv4 em vez de conexões IPv6 para o intervalo CIDR especificado. Por exemplo, supondo que o cluster esteja em uma sub-rede com o CIDR 172.31.0.0:0/16, a execução de netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 resultaria na seguinte tabela de precedência, o que faria com que os clientes preferissem IPv4 ao se conectarem ao 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