3.11. 컨트롤 플레인 노드 간 네트워크 지터 측정
하트비트 간격의 값은 멤버 간 평균 RTT(Round-trip time)의 최대값이어야 합니다. 일반적으로 왕복 시간(약 1.5배)입니다. OpenShift Container Platform의 기본 하트비트 간격이 100ms인 경우 컨트롤 플레인 노드 간 권장 RTT는 약 33ms보다 적고 최대 66ms(66ms가 99ms를 곱한 값)입니다. 자세한 내용은 " etcd에 대한 튜닝 매개변수 설정"을 참조하십시오. 네트워크 대기 시간이 길면 서비스 영향을 미치는 이벤트 및 클러스터 불안정성을 유발할 수 있습니다.
네트워크 대기 시간은 다음 요소를 포함하여 여러 요인의 영향을 받습니다.
- 구리, 광섬유, 무선 또는 Satellite와 같은 전송 네트워크의 기술
- 전송 네트워크에서 네트워크 장치의 수 및 품질
좋은 평가 참조는 월간 IP 대기 시간 통계와 같이 통신 공급자가 게시한 상용 대기 시간과 조직의 네트워크 대기 시간을 비교합니다.
보다 정확한 계산을 위해 네트워크 지터로 네트워크 대기 시간을 고려하십시오. 네트워크 지터 는 네트워크 대기 시간 또는 특히 수신된 패킷 지연의 변형입니다. 이상적인 네트워크 조건에서는 지터가 가능한 한 0에 가깝습니다. 네트워크 지터는 시간이 지남에 따라 실제 네트워크 대기 시간이 RTT + 또는 - jitter이므로 etcd의 네트워크 대기 시간 계산에 영향을 미칩니다. 예를 들어, 최대 대기 시간이 80ms이고 30ms의 지터가 있는 네트워크는 110ms의 대기 시간을 경험하므로 etcd가 하트비트가 누락되어 요청 시간 초과 및 임시 리더 손실이 발생합니다. 리더 손실 및 복원 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.
모든 컨트롤 플레인 노드 간에 네트워크 지터를 측정하는 것이 중요합니다. 이렇게 하려면 UDP 모드에서 iPerf3 툴을 사용할 수 있습니다.
사전 요구 사항
자체 iPerf 이미지를 빌드했습니다. 자세한 내용은 다음 Red Hat 지식베이스 문서를 참조하십시오.
프로세스
컨트롤 플레인 노드 중 하나에 연결하고 호스트 네트워크 모드에서 iPerf 컨테이너를 iPerf 서버로 실행합니다. 서버 모드에서 실행 중이면 툴에서 TCP 및 UDP 테스트를 허용합니다. <
iperf_image>를 iPerf 이미지로 교체하려면 다음 명령을 입력합니다.# podman run -ti --rm --net host <iperf_image> iperf3 -s다른 컨트롤 플레인 노드에 연결하고 다음 명령을 입력하여 UDP 클라이언트 모드에서 iPerf를 실행합니다.
# podman run -ti --rm --net host <iperf_image> iperf3 -u -c <node_iperf_server> -t 300기본 테스트는 10초 동안 실행되며, 클라이언트 출력은 클라이언트 관점에서 평균 지터를 표시합니다.
다음 명령을 입력하여 디버그 노드 모드를 실행합니다.
# oc debug node/m1출력 예
Starting pod/m1-debug ... To use host binaries, run `chroot /host` Pod IP: 198.18.111.13 If you don't see a command prompt, try pressing enter.다음 명령을 입력합니다.
sh-4.4# chroot /hostsh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -u -c m0출력 예
Connecting to host m0, port 5201 [ 5] local 198.18.111.13 port 60878 connected to 198.18.111.12 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 2.00-3.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 3.00-4.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 5.00-6.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 7.00-8.00 sec 129 KBytes 1.05 Mbits/sec 91 [ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 90 [ 5] 9.00-10.00 sec 129 KBytes 1.05 Mbits/sec 91 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/906 (0%) sender [ 5] 0.00-10.04 sec 1.25 MBytes 1.05 Mbits/sec 1.074 ms 0/906 (0%) receiver iperf Done.iPerf 서버에서 출력에 1초 간격마다 지터가 표시됩니다. 평균은 끝에 표시됩니다. 이 테스트의 목적을 위해 잘못된 측정이 포함될 수 있으므로 첫 번째 초의 출력을 무시하고 테스트 중에 경험하는 최대 지터를 식별하려고 합니다. 다음 명령을 실행합니다.
# oc debug node/m0출력 예
Starting pod/m0-debug ... To use host binaries, run `chroot /host` Pod IP: 198.18.111.12 If you don't see a command prompt, try pressing enter.다음 명령을 입력합니다.
sh-4.4# chroot /hostsh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -s출력 예
----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 198.18.111.13, port 44136 [ 5] local 198.18.111.12 port 5201 connected to 198.18.111.13 port 60878 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 124 KBytes 1.02 Mbits/sec 4.763 ms 0/88 (0%) [ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 4.735 ms 0/90 (0%) [ 5] 2.00-3.00 sec 129 KBytes 1.05 Mbits/sec 0.568 ms 0/91 (0%) [ 5] 3.00-4.00 sec 127 KBytes 1.04 Mbits/sec 2.443 ms 0/90 (0%) [ 5] 4.00-5.00 sec 129 KBytes 1.05 Mbits/sec 1.372 ms 0/91 (0%) [ 5] 5.00-6.00 sec 127 KBytes 1.04 Mbits/sec 2.769 ms 0/90 (0%) [ 5] 6.00-7.00 sec 129 KBytes 1.05 Mbits/sec 2.393 ms 0/91 (0%) [ 5] 7.00-8.00 sec 127 KBytes 1.04 Mbits/sec 0.883 ms 0/90 (0%) [ 5] 8.00-9.00 sec 129 KBytes 1.05 Mbits/sec 0.594 ms 0/91 (0%) [ 5] 9.00-10.00 sec 127 KBytes 1.04 Mbits/sec 0.953 ms 0/90 (0%) [ 5] 10.00-10.04 sec 5.66 KBytes 1.30 Mbits/sec 1.074 ms 0/4 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.04 sec 1.25 MBytes 1.05 Mbits/sec 1.074 ms 0/906 (0%) receiver ----------------------------------------------------------- Server listening on 5201 ------------------------------------------------------------ 계산된 jitter를 네트워크 대기 시간에 페널링합니다. 예를 들어, 네트워크 대기 시간이 80ms이고 지터가 30ms인 경우 컨트롤 플레인을 위해 110ms의 효과적인 네트워크 대기 시간을 고려하십시오. 이 예에서 해당 값은 100 ms 임계값을 초과하면 시스템은 하트비트를 놓치게 됩니다.
etcd의 네트워크 대기 시간을 계산할 때 다음 식의 합계인 유효한 네트워크 대기 시간을 사용합니다.
RTT + 지터
평균 jitter 값을 사용하여 페널티를 계산할 수 있지만 etcd 하트비트 타이머가 다음 식의 합계보다 작으면 클러스터에서 하트비트를 급증할 수 있습니다.
RTT + max(jitter)
대신 보다 유연한 배포를 위해 99번째 백분위 또는 최대 jitter 값을 사용하는 것이 좋습니다.
효과적인 네트워크 대기 시간 = RTT + max(jitter)