Práticas recomendadas e estratégias de armazenamento em cache do ElastiCache
Abaixo, é possível encontrar práticas recomendadas para o Amazon ElastiCache. Seguir essas práticas melhora o desempenho e aumenta a confiabilidade do cache.
Tópicos
Clusters do ElastiCache de pilha dupla habilitados para TLS
Quando o TLS está habilitado para clusters do ElastiCache, as funções de descoberta de cluster (cluster slots, cluster shards, e cluster nodes para o Redis) ou config get cluster para o Memcached 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 cluster do ElastiCache e realizar um handshake de 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. Para Valkey ou Redis OSS, isso inclui aquelas para outras aplicações não Valkey e não Redis OSS.
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 clusters do ElastiCache.
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 cluster do ElastiCache, 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
