1.5. etcd 관련 권장 사례
etcd는 디스크에 데이터를 쓰고 디스크에 제안을 유지하므로 디스크 성능에 따라 성능이 달라집니다. etcd는 특별히 I/O 집약적이 아니지만 성능과 안정성을 최적화하려면 대기 시간이 짧은 블록 장치가 필요합니다. etcd의 비관성 프로토콜은 메타데이터를 로그에 영구적으로 저장하는 데 따라 달라지므로 etcd는 디스크 쓰기 대기 시간에 민감합니다. 디스크 속도가 느리고 다른 프로세스의 디스크 활동이 길어지면 fsync 대기 시간이 길어질 수 있습니다.
이러한 대기 시간 동안 etcd가 하트비트를 놓치고 새 제안을 제때 디스크에 커밋하지 않고 궁극적으로 요청 시간 초과 및 임시 리더 손실이 발생할 수 있습니다. 또한 쓰기 대기 시간이 길면 OpenShift API 속도가 느려 클러스터 성능에 영향을 미칩니다. 이러한 이유로 I/O 민감하거나 집약적이며 동일한 기본 I/O 인프라를 공유하는 컨트롤 플레인 노드에서 다른 워크로드를 배치하지 마십시오.
대기 시간에서는 블록 장치 위에서 etcd를 실행하여 8000바이트 이상의 IOPS를 순차적으로 작성할 수 있습니다. 즉, 대기 시간이 20ms인 경우 fdatasync를 사용하여 WAL의 각 쓰기를 동기화하는 것을 염두에 두십시오. 로드된 클러스터의 경우 8000바이트(2ms)의 순차적 500 IOPS를 사용하는 것이 좋습니다. 이 숫자를 측정하려면 fio와 같은 벤치마킹 도구를 사용할 수 있습니다.
이러한 성능을 얻으려면 대기 시간이 짧고 처리량이 높은 SSD 또는 NVMe 디스크가 지원되는 머신에서 etcd를 실행하십시오. 메모리 셀당 1 비트를 제공하고, 내구성이 있고 신뢰할 수 있으며 쓰기 집약적인 워크로드에 이상적입니다.
etcd의 로드는 노드 및 Pod 수와 같은 정적 요인과 Pod 자동 스케일링, Pod 재시작, 작업 실행 및 기타 워크로드 관련 이벤트로 인한 끝점 변경 등 동적 요인에서 발생합니다. etcd 설정의 크기를 정확하게 조정하려면 워크로드의 특정 요구 사항을 분석해야 합니다. etcd의 로드에 영향을 미치는 노드, 포드 및 기타 관련 요인을 고려하십시오.
다음 하드 디스크 기능은 최적의 etcd 성능을 제공합니다.
- 빠른 읽기 작업을 지원하기 위한 짧은 대기 시간.
- 높은 대역폭은 더 빠른 압축 및 조각 모음을 위한 쓰기입니다.
- 대역폭이 높아지면 오류로부터 보다 신속하게 복구할 수 있습니다.
- Solid state drives as a minimum selection, however NVMe 드라이브가 선호됩니다.
- 안정성을 높이기 위해 다양한 제조 업체의 서버 수준 하드웨어.
- 성능 향상을 위한 RAID 0 기술.
- etcd 전용 드라이브 로그 파일 또는 기타 과도한 워크로드를 etcd 드라이브에 배치하지 마십시오.
NAS 또는 SAN 설정 및 회전 드라이브를 사용하지 마십시오. Ceph Rados Block Device(RBD) 및 기타 유형의 네트워크 연결 스토리지로 인해 네트워크 대기 시간이 예측할 수 없습니다. 대규모 etcd 노드에 빠른 스토리지를 제공하려면 PCI 패스스루를 사용하여 NVM 장치를 노드에 직접 전달합니다.
항상 fio와 같은 유틸리티를 사용하여 벤치마크를 수행합니다. 이러한 유틸리티를 사용하여 증가에 따라 클러스터 성능을 지속적으로 모니터링할 수 있습니다.
NFS(Network File System) 프로토콜 또는 기타 네트워크 기반 파일 시스템을 사용하지 마십시오.
배포된 OpenShift Container Platform 클러스터에서 모니터링하기 위한 몇 가지 주요 메트릭은 etcd 디스크 미리 쓰기 시 미리 쓰기 시간 및 etcd 리더 변경 횟수입니다. 이러한 지표를 추적하려면 Prometheus를 사용하십시오.
etcd 멤버 데이터베이스 크기는 일반 작업 중에 클러스터에서 다를 수 있습니다. 이 차이점은 리더 크기가 다른 멤버와 다른 경우에도 클러스터 업그레이드에는 영향을 미치지 않습니다.
OpenShift Container Platform 클러스터를 생성하기 전이나 후에 etcd 하드웨어를 확인하려면 fio를 사용할 수 있습니다.
사전 요구 사항
- Podman 또는 Docker와 같은 컨테이너 런타임은 테스트 중인 머신에 설치됩니다.
-
데이터는
/var/lib/etcd경로에 작성됩니다.
절차
Fio를 실행하고 결과를 분석합니다.
Podman을 사용하는 경우 다음 명령을 실행합니다.
$ sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
Docker를 사용하는 경우 다음 명령을 실행합니다.
$ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
실행에서 캡처된 fsync 지표의 99번째 백분위수를 비교하여 20ms 미만인지 확인하여 디스크 속도가 etcd를 호스팅하기에 충분한지 여부를 출력에서 보고합니다. I/O 성능의 영향을 받을 수 있는 가장 중요한 etcd 지표 중 일부는 다음과 같습니다.
-
etcd_disk_wal_fsync_duration_seconds_bucket지표가 etcd의 WAL fsync 기간 보고 -
etcd_disk_backend_commit_duration_seconds_bucket지표에서 etcd 백엔드 커밋 대기 시간 보고 -
etcd_server_leader_changes_seen_total지표에서 리더 변경을 보고
etcd는 모든 멤버 간에 요청을 복제하므로 성능은 네트워크 입력/출력(I/O) 대기 시간에 따라 크게 달라집니다. 네트워크 대기 시간이 길면 etcd 하트비트가 선택 시간 초과보다 오래 걸리므로 리더 선택이 발생하여 클러스터가 손상될 수 있습니다. 배포된 OpenShift Container Platform 클러스터에서 모니터링되는 주요 메트릭은 각 etcd 클러스터 멤버에서 etcd 네트워크 피어 대기 시간의 99번째 백분위 수입니다. 이러한 메트릭을 추적하려면 Prometheus를 사용하십시오.
histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m]) 지표에서 etcd가 멤버 간 클라이언트 요청을 복제하기 위한 왕복 시간을 보고합니다. 50ms보다 작은지 확인하십시오.
