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 툴을 사용할 수 있습니다.

사전 요구 사항

프로세스

  1. 컨트롤 플레인 노드 중 하나에 연결하고 호스트 네트워크 모드에서 iPerf 컨테이너를 iPerf 서버로 실행합니다. 서버 모드에서 실행 중이면 툴에서 TCP 및 UDP 테스트를 허용합니다. < iperf_image>를 i Perf 이미지로 교체하려면 다음 명령을 입력합니다.

    # podman run -ti --rm --net host <iperf_image> iperf3 -s
  2. 다른 컨트롤 플레인 노드에 연결하고 다음 명령을 입력하여 UDP 클라이언트 모드에서 iPerf를 실행합니다.

    # podman run -ti --rm --net host <iperf_image> iperf3 -u -c <node_iperf_server> -t 300

    기본 테스트는 10초 동안 실행되며, 클라이언트 출력은 클라이언트 관점에서 평균 지터를 표시합니다.

  3. 다음 명령을 입력하여 디버그 노드 모드를 실행합니다.

    # 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.

  4. 다음 명령을 입력합니다.

    sh-4.4# chroot /host
    sh-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.

  5. 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.

  6. 다음 명령을 입력합니다.

    sh-4.4# chroot /host
    sh-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
    -----------------------------------------------------------

  7. 계산된 jitter를 네트워크 대기 시간에 페널링합니다. 예를 들어, 네트워크 대기 시간이 80ms이고 지터가 30ms인 경우 컨트롤 플레인을 위해 110ms의 효과적인 네트워크 대기 시간을 고려하십시오. 이 예에서 해당 값은 100 ms 임계값을 초과하면 시스템은 하트비트를 놓치게 됩니다.
  8. etcd의 네트워크 대기 시간을 계산할 때 다음 식의 합계인 유효한 네트워크 대기 시간을 사용합니다.

    RTT + 지터

    평균 jitter 값을 사용하여 페널티를 계산할 수 있지만 etcd 하트비트 타이머가 다음 식의 합계보다 작으면 클러스터에서 하트비트를 급증할 수 있습니다.

    RTT + max(jitter)

    대신 보다 유연한 배포를 위해 99번째 백분위 또는 최대 jitter 값을 사용하는 것이 좋습니다.

    효과적인 네트워크 대기 시간 = RTT + max(jitter)

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동