翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
IPv6 クライアントの例
注記
このセクションは、独自設計型 Memcached クラスターに適用されます。
ElastiCache はオープンソースの Memcached と互換性があります。つまり、IPv6 接続をサポートする Memcached のオープンソースクライアントは、IPv6 対応 ElastiCache (Memcached) クラスターに接続できる必要があります。さらに、以下のクライアントは、サポートされているすべてのネットワークタイプ設定で動作することが具体的に検証されています。
一般的に使用されるオープンソースのクライアントライブラリで IPv6 対応 ElastiCache リソースを操作するためのベストプラクティスを次に示します。 ElastiCache リソースのクライアント設定に関する推奨事項については、 を操作するための既存のベストプラクティス ElastiCache
検証済みクライアント
検証済みクライアント:
デュアルスタッククラスターの優先プロトコルの設定
Memcached クラスターでは、IP 検出パラメータを使用して、クライアントがクラスター内のノードに接続するために使用するプロトコルを制御できます。IP 検出パラメータは、IPv4 または IPv6 に設定できます。
IP 検出パラメータは、config get クラスター出力で使用される IP プロトコルを制御します。これにより、 ElastiCache (Memcached) クラスターの自動検出をサポートするクライアントが使用する IP プロトコルが決まります。
IP 検出を変更しても、接続しているクライアントのダウンタイムは発生しません。ただし、変更が反映されるまで時間がかかる場合があります。
Java の場合は getAvailableNodeEndPoints の出力をモニタリングし、PHP の場合は getServerList の出力をモニタリングします。これらの関数の出力で、更新されたプロトコルを使用するクラスター内のすべてのノードの IP が報告されると、変更の反映が完了します。
Java の例:
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 の例:
$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);
IP 検出が更新される前に作成された既存のクライアント接続は、引き続き古いプロトコルを使用して接続されます。クラスター検出コマンドの出力で変更が検出されると、検証されたすべてのクライアントは新しい IP プロトコルを使用してクラスターに自動的に再接続します。ただし、これはクライアントの実装によって異なります。
TLS 対応デュアルスタック ElastiCache クラスター
ElastiCache クラスターで TLS が有効になっている場合、クラスター検出関数 は IP の代わりにconfig get clusterホスト名を返します。 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 接続を行わなくなります。
ホストレベルの設定
一般に、クライアントまたはクライアントランタイムに 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
