Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beispiele für IPv6-Clients

ElastiCache ist mit Open-Source-Memcached kompatibel. Das bedeutet, dass Open-Source-Clients für Memcached, die IPv6-Verbindungen unterstützen, in der Lage sein sollten, eine Verbindung zu IPv6-fähigen (Memcached) Clustern herzustellen. ElastiCache Darüber hinaus wurden die folgenden Clients speziell für die Verwendung mit allen unterstützten Netzwerktypkonfigurationen validiert:

Im Folgenden finden Sie bewährte Methoden für die Interaktion mit IPv6-fähigen ElastiCache Ressourcen mit häufig verwendeten Open-Source-Clientbibliotheken. Empfehlungen zur Konfiguration von Clients für Ressourcen finden Sie in den vorhandenen bewährten Methoden ElastiCache für die Interaktion mit. ElastiCache Bei der Interaktion mit IPv6-fähigen Ressourcen gibt es jedoch einige Vorbehalte, die es zu beachten gilt.

Validierte Clients

Validierte Clients:

Konfigurieren eines bevorzugten Protokolls für Dual-Stack-Cluster

Bei Memcached-Clustern können Sie mit dem IP-Discovery-Parameter das Protokoll steuern, das Clients für die Verbindung mit den Knoten im Cluster verwenden. Der IP-Discovery-Parameter kann entweder auf IPv4 oder IPv6 festgelegt werden.

Der IP-Erkennungsparameter steuert das IP-Protokoll, das in der Cluster-Ausgabe der Konfiguration verwendet wird. Dies wiederum bestimmt das IP-Protokoll, das von Clients verwendet wird, die Autodiscovery für ElastiCache (Memcached-) Cluster unterstützen.

Eine Änderung vom IP-Discovery führt zu keinen Ausfallzeiten für verbundene Clients. Die Weiterleitung der Änderungen wird jedoch einige Zeit dauern.

Überwachen Sie die Ausgabe von getAvailableNodeEndPoints für Java und für Php überwachen Sie die Ausgabe von getServerList. Sobald die Ausgabe dieser Funktionen IPs für alle Knoten im Cluster meldet, die das aktualisierte Protokoll verwenden, wurden die Änderungen vollständig übertragen.

Java-Beispiel:

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

Php-Beispiel:

$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);

Alle vorhandenen Client-Verbindungen, die vor der Aktualisierung von IP Discovery erstellt wurden, werden weiterhin mit dem alten Protokoll verbunden. Alle validierten Clients stellen mithilfe des neuen IP-Protokolls automatisch wieder eine Verbindung mit dem Cluster her, sobald die Änderungen in der Ausgabe der Cluster-Erkennungsbefehle erkannt wurden. Dies hängt jedoch von der Implementierung des Clients ab.

TLS-fähige Dual-Stack-Cluster ElastiCache

Wenn TLS für ElastiCache Cluster aktiviert ist, geben die Cluster-Erkennungsfunktionen Hostnamen statt IPs config get clusterzurück. Die Hostnamen werden dann anstelle von IPs verwendet, um eine Verbindung zum ElastiCache Cluster herzustellen und einen TLS-Handshake durchzuführen. Das bedeutet, dass Clients nicht vom IP-Discovery-Parameter betroffen sind. Bei TLS-fähigen Clustern hat der IP Discovery-Parameter keine Auswirkung auf das bevorzugte IP-Protokoll. Stattdessen wird das verwendete IP-Protokoll dadurch bestimmt, welches IP-Protokoll der Client bei der Auflösung von DNS-Hostnamen bevorzugt.

Java-Clients

Bei der Verbindung von einer Java-Umgebung aus, die sowohl IPv4 als auch IPv6 unterstützt, bevorzugt Java aus Gründen der Abwärtskompatibilität standardmäßig IPv4 gegenüber IPv6. Die IP-Protokollpräferenz ist jedoch über die JVM-Argumente konfigurierbar. Wenn IPv4 bevorzugt werden soll, akzeptiert die JVM IPv6 -Djava.net.preferIPv4Stack=true. Legen Sie -Djava.net.preferIPv6Stack=true fest, damit IPv6 bevorzugt wird. Die Einstellung -Djava.net.preferIPv4Stack=true bedeutet, dass die JVM keine IPv6-Verbindungen mehr herstellt.

Einstellungen auf Host-Ebene

Wenn vom Client oder von der Client-Laufzeit keine Konfigurationsoptionen zum Festlegen einer IP-Protokollpräferenz bereitgestellt wird, hängt das IP-Protokoll bei der DNS-Auflösung im Allgemeinen von der Konfiguration des Hosts ab. Standardmäßig bevorzugen die meisten Hosts IPv6 gegenüber IPv4, aber diese Präferenz kann auf Host-Ebene konfiguriert werden. Dies wirkt sich auf alle DNS-Anfragen von diesem Host aus, nicht nur auf diejenigen an ElastiCache Cluster.

Linux-Hosts

Für Linux kann eine IP-Protokollpräferenz konfiguriert werden, indem die gai.conf-Datei geändert wird. Sie finden die gai.conf-Datei unter /etc/gai.conf. Wenn keine gai.conf angegeben ist, sollte ein Beispiel davon /usr/share/doc/glibc-common-x.xx/gai.conf verfügbar sein, das nach /etc/gai.conf kopiert werden kann. Die Standardkonfiguration sollte dann unkommentiert sein. Um die Konfiguration so zu aktualisieren, dass IPv4 bei der Verbindung zu einem ElastiCache Cluster bevorzugt wird, aktualisieren Sie die Priorität für den CIDR-Bereich, der die Cluster-IPs umfasst, so dass sie über der Priorität für Standard-IPv6-Verbindungen liegt. Standardmäßig haben IPv6-Verbindungen eine Priorität von 40. Angenommen, der Cluster befindet sich beispielsweise in einem Subnetz mit dem CIDR 172.31.0. 0:0 /16, die folgende Konfiguration würde dann dazu führen, dass Clients IPv4-Verbindungen mit diesem Cluster vorziehen.

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

Weitere Informationen zu gai.conf finden Sie auf der Linux-Hauptseite.

Windows-Hosts

Der Prozess für Windows-Hosts ist ähnlich. Für Windows-Hosts können Sie netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL ausführen. Dies hat den gleichen Effekt wie das Ändern der gai.conf-Datei für Linux-Hosts.

Dadurch werden die Präferenzrichtlinien aktualisiert, damit IPv4-Verbindungen gegenüber IPv6-Verbindungen für den angegebenen CIDR-Bereich bevorzugt werden. Gehen wir beispielsweise davon aus, dass sich der Cluster in einem Subnetz mit der CIDR 172.31.0. 0:0 /16 befindet, würde das Ausführen von netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 die folgende Prioritätstabelle ergeben. Das würde dazu führen, dass Clients IPv4 bevorzugen, wenn sie eine Verbindung mit dem Cluster herstellen.

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