翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

IPv6 クライアントの例

一般的に使用されるオープンソースのクライアントライブラリで IPv6 対応 ElastiCache リソースを操作するためのベストプラクティスを次に示します。 ElastiCache リソースのクライアント設定に関する推奨事項については、 を操作するための既存のベストプラクティス ElastiCacheを参照してください。ただし、IPv6 対応リソースを操作する際には、注意すべき点がいくつかあります。

検証済みクライアント

ElastiCache は、オープンソースの Redis OSS と互換性があります。つまり、IPv6 接続をサポートするオープンソースの Redis OSS クライアントは、IPv6 対応 ElastiCache (Redis OSS) クラスターに接続できる必要があります。さらに、最も一般的な Python および Java クライアントのいくつかは、サポートされているすべてのネットワークタイプ設定 (IPv4 のみ、IPv6 のみ、およびデュアルスタック) で動作するように特別にテストおよび検証されています。

検証済みクライアント:

デュアルスタッククラスターの優先プロトコルの設定

クラスターモードが有効になっている Redis OSS クラスターの場合、IP Discovery パラメータを使用して、クライアントがクラスター内のノードに接続するために使用するプロトコルを制御できます。IP 検出パラメータは、IPv4 または IPv6 に設定できます。

Redis OSS クラスターの場合、IP 検出パラメータは、クラスタースロット ()、クラスターシャード ()、クラスターノード () の出力で使用される IP プロトコルを設定します。 https://redis.io/commands/cluster-nodes/これらのコマンドは、クライアントがクラスタートポロジを検出するために使用されます。クライアントは、これらのコマンドの IP を使用して、クラスター内の他のノードに接続します。

IP 検出を変更しても、接続しているクライアントのダウンタイムは発生しません。ただし、変更が反映されるまで時間がかかる場合があります。変更が Redis OSS クラスターに完全に伝達されたかどうかを判断するには、 の出力をモニタリングしますcluster slots。cluster slots コマンドによって返されたすべてのノードが新しいプロトコルの IP を報告すると、変更の反映が完了します。

Redis-Py を使った例:

cluster = RedisCluster(host="xxxx", port=6379)
target_type = IPv6Address # Or IPv4Address if changing to IPv4

nodes = set()
while len(nodes) == 0 or not all((type(ip_address(host)) is target_type) for host in nodes):
    nodes = set()

   # This refreshes the cluster topology and will discovery any node updates.
   # Under the hood it calls cluster slots
    cluster.nodes_manager.initialize()
    for node in cluster.get_nodes():
        nodes.add(node.host)
    self.logger.info(nodes)

    time.sleep(1)

Lettuce の例:

RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create("xxxx", 6379));

Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4

Set<String> nodes;
    
do {
   // Check for any changes in the cluster topology.
   // Under the hood this calls cluster slots
    clusterClient.refreshPartitions();
    Set<String> nodes = new HashSet<>();

    for (RedisClusterNode node : clusterClient.getPartitions().getPartitions()) {
        nodes.add(node.getUri().getHost());
    }

    Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
            try {
                return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
            } catch (UnknownHostException ignored) {}
            return false;
}));

TLS 対応デュアルスタック ElastiCache クラスター

ElastiCache クラスターで TLS が有効になっている場合、クラスター検出関数 （cluster slots、cluster shards、および cluster nodes) は IP の代わりにホスト名を返します。 IPs その後、ホスト名は IPs の代わりに ElastiCache クラスターに接続し、TLS ハンドシェイクを実行します。つまり、クライアントは IP 検出パラメータの影響を受けません。TLS が有効なクラスターでは、IP 検出パラメータは優先 IP プロトコルに影響しません。代わりに、使用する IP プロトコルは、DNS ホスト名を解決する際にクライアントがどの IP プロトコルを使用するかによって決まります。

Java クライアント

IPv4 と IPv6 の両方をサポートする Java 環境から接続する場合、後方互換性のために Java はデフォルトで IPv6 よりも IPv4 を優先します。ただし、IP プロトコルプリファレンスは JVM 引数を使用して設定できます。IPv4 を優先するには、JVM は -Djava.net.preferIPv4Stack=true を受け入れ、IPv6 セット -Djava.net.preferIPv6Stack=true を優先します。-Djava.net.preferIPv4Stack=true を設定すると、JVM は IPv6 接続を行わなくなります。これらを他の Redis OSS 以外のアプリケーションに含めます。

ホストレベルの設定

一般に、クライアントまたはクライアントランタイムに IP プロトコルプリファレンスを設定するための構成オプションが提供されていない場合、DNS 解決を実行するとき、IP プロトコルはホストの設定に依存します。デフォルトでは、ほとんどのホストは IPv4 よりも IPv6 を優先しますが、この優先度はホストレベルで設定できます。これは、 ElastiCache クラスターへのリクエストだけでなく、そのホストからのすべての DNS リクエストに影響します。

Linux ホスト

Linux では、gai.conf ファイルを変更して IP プロトコルプリファレンスを設定できます。gai.conf ファイルは /etc/gai.conf の下にあります。gai.conf の指定がない場合は、/usr/share/doc/glibc-common-x.xx/gai.conf に /etc/gai.conf にコピーできるサンプルを用意し、デフォルトの設定をコメント解除する必要があります。 ElastiCache クラスターへの接続時に IPv4 を優先するように設定を更新するには、クラスター IPs を含む CIDR 範囲の優先順位をデフォルトの IPv6 接続の優先順位よりも高く更新します。デフォルトでは、IPv6 接続の優先順位は 40 です。例えば、クラスターが CIDR 172.31.0.0:0/16 のサブネットにあると仮定すると、以下の設定では、クライアントはそのクラスターへの 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

gai.conf の詳細については、Linux のメインページを参照してください。

Windows ホスト

Windows ホストのプロセスも同様です。Windows ホストの場合は netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL を実行できます。これは Linux ホストで gai.conf ファイルを変更するのと同じ効果があります。

これにより、指定された CIDR 範囲の IPv6 接続よりも IPv4 接続を優先するように優先設定ポリシーが更新されます。例えば、クラスターが 172.31.0.0:0/16 CIDR のサブネット内にあると仮定した場合、netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 を実行すると、次の優先順位表になり、クライアントがクラスターに接続する際に 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