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
    Copy to Clipboard Toggle word wrap
  2. 다른 컨트롤 플레인 노드에 연결하고 다음 명령을 입력하여 UDP 클라이언트 모드에서 iPerf를 실행합니다.

    # podman run -ti --rm --net host <iperf_image> iperf3 -u -c <node_iperf_server> -t 300
    Copy to Clipboard Toggle word wrap

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

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

    # oc debug node/m1
    Copy to Clipboard Toggle word wrap

    출력 예

    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.
    Copy to Clipboard Toggle word wrap

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

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap
    sh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -u -c m0
    Copy to Clipboard Toggle word wrap

    출력 예

    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.
    Copy to Clipboard Toggle word wrap

  5. iPerf 서버에서 출력에 1초 간격마다 지터가 표시됩니다. 평균은 끝에 표시됩니다. 이 테스트의 목적을 위해 잘못된 측정이 포함될 수 있으므로 첫 번째 초의 출력을 무시하고 테스트 중에 경험하는 최대 지터를 식별하려고 합니다. 다음 명령을 실행합니다.

    # oc debug node/m0
    Copy to Clipboard Toggle word wrap

    출력 예

    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.
    Copy to Clipboard Toggle word wrap

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

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap
    sh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -s
    Copy to Clipboard Toggle word wrap

    출력 예

    -----------------------------------------------------------
    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
    -----------------------------------------------------------
    Copy to Clipboard Toggle word wrap

  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 소개

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

Theme

© 2025 Red Hat