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à.

ElastiCache migliori pratiche e strategie di caching

Di seguito puoi trovare le best practice consigliate per Amazon ElastiCache. Queste best practice consentono di migliorare prestazioni e affidabilità della cache.

Cluster dual ElastiCache stack abilitati per TLS

Quando TLS è abilitato per ElastiCache i cluster, le funzioni di rilevamento del cluster (cluster slotscluster shards, e cluster nodes per Redis) o config get clusterper Memcached restituiscono nomi di host anziché. IPs I nomi host vengono quindi utilizzati anziché per connettersi al cluster ed eseguire IPs un handshake TLS. ElastiCache 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 ci si connette da un ambiente Java che supporta entrambi IPv4 e IPv6, IPv6 per impostazione predefinita Java preferisce la compatibilità con le IPv4 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 impostato. IPv6 -Djava.net.preferIPv6Stack=true L'impostazione -Djava.net.preferIPv4Stack=true significa che la JVM non effettuerà più alcuna connessione. IPv6 Per Valkey o Redis OSS, ciò include quelle verso altre applicazioni non Valkey e non Redis OSS.

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 questa IPv6 preferenza, IPv4 ma questa preferenza può essere configurata a livello di host. Ciò influirà su tutte le richieste DNS provenienti dall'host, non solo su quelle ai 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 da preferire IPv4 quando ci si connette a un ElastiCache cluster, aggiorna la precedenza per l'intervallo CIDR che comprende il cluster in modo che sia superiore IPs alla precedenza per le connessioni predefinite. IPv6 Per impostazione predefinita, IPv6 le connessioni hanno una precedenza di 40. Ad esempio, supponendo che il cluster si trovi in una sottorete con CIDR 172.31.0. 0:0 /16, la configurazione seguente farebbe sì che i client preferiscano le connessioni a quel cluster. IPv4

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

Maggiori dettagli su sono disponibili nella pagina man di Linux gai.conf

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 politiche di preferenza per preferire IPv4 le connessioni alle IPv6 connessioni per l'intervallo CIDR specificato. Ad esempio, supponendo che il cluster si trovi in una sottorete con esecuzione CIDR 172.31.0. 0:0 /16, netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 risulterebbe la seguente tabella di precedenza che farebbe sì che i client preferiscano la connessione al cluster. IPv4

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