1.2. etcd 성능 이해

복제된 노드의 클러스터로 작동하는 일관된 분산 키-값 저장소로서 etcd는 하나의 노드를 리더로 선택하고 다른 노드를 리더로 선택하여 Raft 알고리즘을 따릅니다. 리더는 시스템 현재 상태의 현재 상태를 유지하고 맹인을 최신 상태로 유지합니다.

리더 노드는 로그 복제를 담당합니다. 클라이언트에서 들어오는 쓰기 트랜잭션을 처리하고 팔로우에게 브로드캐스트한 Raft 로그 항목을 작성합니다.

kube-apiserver 와 같은 etcd 클라이언트가 쿼럼이 필요한 작업을 요청하는 etcd 멤버(예: etcd 멤버가 follower인 경우)에 연결하면 트랜잭션이 리더로 이동해야 함을 나타내는 메시지를 반환합니다.

etcd 클라이언트가 값 작성과 같이 쿼럼이 필요한 리더의 작업을 요청하면 리더는 로컬 Raft 로그를 쓰는 동안 클라이언트 연결을 열린 상태로 유지 관리하고, 팔로우에게 로그를 브로드캐스트하고, 대다수가 실패 없이 로그를 커밋하도록 승인할 때까지 기다립니다. 리더는 승인을 etcd 클라이언트에 전송하고 세션을 종료합니다. 실패 알림은 미용사로부터 수신되고 합의가 충족되지 않으면 리더는 클라이언트에게 오류 메시지를 반환하고 세션을 종료합니다.

- name: ETCD_ELECTION_TIMEOUT 
  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL 
  value: "100"

- name: ETCD_ELECTION_TIMEOUT 

  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL 

  value: "100"

이러한 매개변수는 컨트롤 플레인 또는 etcd에 대한 모든 정보를 제공하지 않습니다. etcd 클러스터는 디스크 대기 시간에 민감합니다. etcd는 로그에 대한 제안을 유지해야 하므로 다른 프로세스의 디스크 작업으로 인해 fsync 대기 시간이 길어질 수 있습니다. 그 결과 etcd에서 하트비트가 누락되어 요청 시간 초과 및 일시적으로 리더 손실이 발생할 수 있습니다. 리더 손실 및 복원 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.

다음 예와 같이 최종 보고서가 etcd에 대해 디스크를 적절하게 분류하는지 확인합니다.

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the suggested threshold: - 20 ms, the disk can be used to host etcd

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the suggested threshold: - 20 ms, the disk can be used to host etcd

대기 시간이 긴 디스크를 사용하는 경우 다음 예와 같이 etcd에 대한 디스크가 권장되지 않음을 알리는 메시지가 표시됩니다.

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the suggested value which is 20 ms, faster disks are suggested to host etcd for better performance

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the suggested value which is 20 ms, faster disks are suggested to host etcd for better performance

클러스터 배포가 제안된 대기 시간을 충족하지 않는 etcd에 디스크를 사용하는 많은 데이터 센터에 걸쳐 있으면 서비스 영향을 미치는 오류가 발생할 수 있습니다. 또한 컨트롤 플레인에서 유지할 수 있는 네트워크 대기 시간이 크게 단축됩니다.

하트비트 간격의 값은 멤버 간의 평균 Round-trip 시간 (RTT)의 최대 값이어야 합니다. 일반적으로 왕복 시간보다 약 1.5 배입니다. OpenShift Container Platform의 기본 하트비트 간격이 100ms인 경우 컨트롤 플레인 노드 간 제안된 RTT는 33ms 미만이며 최대 66ms(66ms x 1.5 = 99ms)입니다. 더 큰 네트워크 대기 시간으로 인해 서비스 영향을 미치는 이벤트 및 클러스터 불안정성이 발생할 수 있습니다.

네트워크 대기 시간은 구리, 광섬유, 무선 또는 Satellite와 같은 전송 네트워크의 기술, 전송 네트워크의 네트워크 장치의 수 및 품질 및 기타 요소를 포함하는 요인에 의해 결정됩니다.

정확한 계산을 위해 네트워크 지터가 있는 네트워크 대기 시간을 고려하십시오. 네트워크 지터 는 네트워크 대기 시간 또는 수신된 패킷 지연의 차이입니다. 효율적인 네트워크 조건에서는 지터가 0이어야 합니다. 네트워크 지터는 시간이 지남에 따라 실제 네트워크 대기 시간이 RTT + 또는 - Jitter이므로 etcd의 네트워크 대기 시간 계산에 영향을 미칩니다.

예를 들어, 최대 대기 시간이 80ms이고 30ms의 지터가 있는 네트워크는 110ms의 대기 시간을 경험하므로 etcd는 하트비트를 놓치게 됩니다. 이 조건으로 인해 요청 시간 초과 및 임시 리더 손실이 발생합니다. 리더 손실 및 재지정 중에 Kubernetes API는 클러스터에 영향을 미치는 이벤트 및 불안정성을 유발하는 요청을 처리할 수 없습니다.

etcdctl CLI를 사용하면 etcd에서 경험한 대로 지연 시간에 도달할 수 있습니다. etcd pod 중 하나를 확인한 다음 엔드포인트 상태를 검색해야합니다.

etcd 피어 트립 시간은 모든 etcd 멤버 간에 클라이언트 요청을 복제하기 위해 etcd의 대기 시간을 보여주는 메트릭입니다. OpenShift Container Platform 콘솔은 다양한 etcd 지표를 시각화하는 대시보드를 제공합니다. 콘솔에서 모니터링 대시보드 를 클릭합니다. 드롭다운 목록에서 etcd 를 선택합니다.

etcd 피어 라운드 트립 시간을 요약하는 플롯은 etcd 대시보드 페이지 끝에 있습니다.

etcd 데이터베이스의 크기는 네트워크 파티션이 일정 기간 동안 컨트롤 플레인 노드를 격리할 때 고려해야 할 요소이며 통신을 다시 설정한 후 컨트롤 플레인을 동기화해야 합니다.

시스템의 Operator 및 애플리케이션에 따라 다르기 때문에 etcd 데이터베이스의 크기를 제어하기 위한 최소 옵션이 있습니다. 시스템이 작동하는 대기 시간 범위를 고려할 때 etcd 데이터베이스의 크기당 동기화 또는 조각 모음의 영향을 설명하십시오.

영향의 크기는 배포에 따라 다릅니다. etcd 멤버는 조각 모음 프로세스 중 업데이트를 수락할 수 없으므로 조각 모음을 완료하는 시간으로 인해 트랜잭션 속도 저하가 발생합니다. 마찬가지로 변경 속도가 높은 대규모 데이터베이스의 etcd 재동기화 시간은 시스템의 트랜잭션 속도 및 트랜잭션 대기 시간에 영향을 미칩니다. 계획할 영향 유형에 대해 다음 두 가지 예를 고려하십시오.

데이터베이스 크기에 따른 etcd 조각 모음의 첫 번째 예는 1GB의 etcd 데이터베이스를 초당 80Mb에서 느린 7200 RPM 디스크에 작성하는 데 약 1분 40초가 걸리는 것입니다. 이러한 시나리오에서는 조각 모음 프로세스를 완료하는 데 최소한 이 시간이 걸립니다.

etcd 동기화에 데이터베이스 크기가 미치는 영향의 두 번째 예는 컨트롤 플레인 노드 중 하나의 연결을 끊는 동안 etcd 데이터베이스의 10%가 변경되면 동기화에서 최소 100MB를 전송해야 한다는 것입니다. 1Gbps 링크를 통해 100MB를 전송하는 데는 800ms가 걸립니다. Kubernetes API를 사용한 일반 트랜잭션이 있는 클러스터에서 etcd 데이터베이스 크기가 클수록 네트워크 불안정으로 인해 컨트롤 플레인 불안정성이 발생합니다.

OpenShift Container Platform에서 etcd 대시보드에는 etcd 데이터베이스의 크기를 보고하는 플롯이 있습니다. 또는 etcdctl 툴을 사용하여 CLI에서 데이터베이스 크기를 가져올 수 있습니다.

oc get pods -n openshift-etcd -l app=etcd

# oc get pods -n openshift-etcd -l app=etcd

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h

oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4

# oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB