기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
IPv6 클라이언트 예시
참고
이 섹션의 내용은 자체 설계 Memcached 클러스터에 적용됩니다.
ElastiCache 오픈 소스 Memcached와 호환됩니다. 즉, IPv6 연결을 지원하는 Memcached용 오픈 소스 클라이언트는 Memcached 클러스터에 사용할 수 있는 IPv6에 연결할 수 있어야 합니다. ElastiCache 또한 다음 클라이언트는 지원되는 모든 네트워크 유형 구성에서 작동한다고 특별 검증되었습니다.
다음은 일반적으로 사용되는 오픈 소스 클라이언트 라이브러리를 사용하여 IPv6 지원 리소스와 상호 작용하는 모범 사례입니다. ElastiCache 상호 작용에 대한 기존 모범 사례에서 리소스용 클라이언트 구성에 ElastiCache
검증된 클라이언트
검증된 클라이언트:
듀얼 스택 클러스터에 선호되는 프로토콜 구성
Memcached 클러스터의 경우, 클라이언트가 클러스터 내 노드에 연결하는 데 사용할 프로토콜을 IP Discovery 파라미터로 제어할 수 있습니다. IP Discovery 파라미터는 IPv4 또는 IPv6로 설정할 수 있습니다.
IP Discovery 파라미터는 config get 클러스터 출력에 사용되는 IP 프로토콜을 제어합니다. 그러면 Memcached 클러스터의 자동 검색을 지원하는 클라이언트가 사용하는 IP 프로토콜이 결정됩니다. ElastiCache
IP Discovery를 변경해도 연결된 클라이언트는 가동 중지되지 않습니다. 하지만 변경 사항이 전파되려면 다소 시간이 소요됩니다.
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 Discovery가 업데이트되기 전에 생성된 기존 클라이언트 연결은 업데이트 전의 프로토콜을 사용하여 연결됩니다. 클러스터 검색 명령의 출력에서 변경 사항이 감지되면, 검증된 모든 클라이언트가 새 IP 프로토콜을 사용하여 자동으로 클러스터에 재연결됩니다. 하지만, 클라이언트 구현에 따라 달라질 수 있습니다.
TLS를 지원하는 이중 스택 클러스터 ElastiCache
ElastiCache 클러스터에 TLS가 활성화된 경우 클러스터 검색 함수 는 IP 대신 호스트 이름을 config get cluster반환합니다. 그러면 IP 대신 호스트 이름을 사용하여 ElastiCache 클러스터에 연결하고 TLS 핸드셰이크를 수행합니다. 따라서 클라이언트가 IP Discovery 파라미터의 영향을 받지 않습니다. TLS 활성화 클러스터의 경우, IP Discovery 파라미터는 선호 IP 프로토콜에 영향을 끼치지 않습니다. 대신 클라이언트가 DNS 호스트 이름을 확인할 때 어떤 IP 프로토콜을 선호하는지에 따라, 사용되는 IP 프로토콜이 결정됩니다.
Java 클라이언트
IPv4와 IPv6를 모두 지원하는 Java 환경에서 연결할 때, Java는 기본적으로 이전 버전과의 호환성을 위해 IPv6보다 IPv4를 선호합니다. 하지만 JVM 인수를 통해 IP 프로토콜 기본 설정을 구성할 수 있습니다. IPv4를 선호하려면 JVM에 -Djava.net.preferIPv4Stack=true를, IPv6를 선호하려면 -Djava.net.preferIPv6Stack=true를 설정합니다. -Djava.net.preferIPv4Stack=true를 설정하면 JVM이 더 이상 IPv6 연결을 만들지 않습니다.
호스트 수준 기본 설정
일반적으로 클라이언트 또는 클라이언트 런타임에 IP 프로토콜 기본 설정을 위한 구성 옵션이 제공되지 않으면, DNS 확인을 수행할 때 IP 프로토콜은 호스트의 구성을 기반으로 작동합니다. 기본적으로, 대부분의 호스트는 IPv4보다 IPv6를 선호하지만 이 기본 설정은 호스트 수준에서 구성할 수 있습니다. 이는 클러스터에 대한 요청뿐 아니라 해당 호스트의 모든 DNS 요청에도 영향을 미칩니다. ElastiCache
Linux 호스트
Linux의 경우, gai.conf 파일을 수정하여 IP 프로토콜 기본 설정을 구성할 수 있습니다. gai.conf 파일은 /etc/gai.conf에서 찾을 수 있습니다. 지정된 gai.conf가 없으면 예제를 /usr/share/doc/glibc-common-x.xx/gai.conf에서 찾을 수 있는데, 이를 /etc/gai.conf에 복사하면 기본 구성의 주석을 제거할 수 있습니다. 클러스터에 연결할 때 IPv4를 선호하도록 구성을 업데이트하려면 ElastiCache 클러스터 IP를 포함하는 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 연결을 선호하도록 기본 설정 정책이 업데이트됩니다. 예를 들어, 클러스터가 CIDR이 172.31.0.0:0/16인 서브넷에 위치할 때 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
