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.

Argomenti

• Le migliori pratiche generali
• Comandi Valkey, Redis e Memcached supportati OSS e limitati
• OSSConfigurazione e limiti di Valkey e Redis
• IPv6esempi di client per Valkey, Redis OSS e Memcached
• Le migliori pratiche per i clienti (Valkey e RedisOSS)
• Le migliori pratiche per i clienti (Memcached)
• TLScluster dual stack ElastiCache abilitati
• Gestione della memoria riservata per Valkey e Redis OSS
• Le migliori pratiche per lavorare con cluster progettati autonomamente da Valkey e Redis OSS
• Strategie di caching per Memcached

TLScluster dual stack ElastiCache abilitati

Quando TLS è abilitato per ElastiCache i cluster cluster slots, cluster shards le funzioni di rilevamento del cluster (e cluster nodes per Redis) o config get cluster per Memcached restituiscono nomi di host anziché. IPs I nomi host vengono quindi utilizzati anziché per connettersi al cluster ed IPs eseguire una stretta di mano. ElastiCache TLS Ciò significa che i client non sono interessati dal parametro Individuazione IP. Per i cluster TLS abilitati, il parametro IP Discovery non ha alcun effetto sul protocollo IP preferito. Invece, il protocollo IP utilizzato sarà determinato dal protocollo IP preferito dal client per la risoluzione dei nomi host. DNS

Client Java

Quando ci si connette da un ambiente Java che supporta entrambi IPv4 eIPv6, IPv6 per impostazione predefinita Java preferisce la compatibilità con le IPv4 versioni precedenti. Tuttavia, la preferenza del protocollo IP è configurabile tramite gli JVM argomenti. PreferireIPv4, JVM accettare -Djava.net.preferIPv4Stack=true e preferire IPv6 impostati-Djava.net.preferIPv6Stack=true. L'impostazione -Djava.net.preferIPv4Stack=true significa che non JVM effettueranno più alcuna IPv6 connessione. Per Valkey o RedisOSS, 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 del client non forniscono opzioni di configurazione per impostare una preferenza del protocollo IP, quando si esegue la DNS risoluzione, il protocollo IP dipenderà dalla configurazione dell'host. Per impostazione predefinita, la maggior parte degli host IPv6 preferisce questa preferenza, IPv4 ma questa preferenza può essere configurata a livello di host. Ciò influirà su tutte DNS le richieste 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 che preferisci IPv4 quando ti connetti a un ElastiCache cluster, aggiorna la precedenza per l'CIDRintervallo 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

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