2장. etcd 관련 권장 사례

etcd는 디스크에 데이터를 작성하고 디스크에 제안을 유지하므로 성능은 디스크 성능에 따라 다릅니다. etcd는 특히 I/O 집약적이지만 최적의 성능과 안정성을 위해 짧은 대기 시간 블록 장치가 필요합니다. etcd의 개념화 프로토콜은 메타데이터를 로그(WAL)에 지속적으로 저장하는 데 따라 달라지므로 etcd는 디스크 쓰기 대기 시간에 민감합니다. 다른 프로세스의 디스크 및 디스크 활동이 느리면 fsync 대기 시간이 길어질 수 있습니다.

이러한 대기 시간으로 인해 etcd가 하트비트를 놓치고 새 제안을 제 시간에 디스크에 커밋하지 않고 궁극적으로 요청 시간 초과 및 임시 리더 손실이 발생할 수 있습니다. 쓰기 대기 시간이 길어지면 OpenShift API 속도가 느려서 클러스터 성능에 영향을 미칩니다. 이러한 이유로 I/O 민감하거나 집약적이며 동일한 기본 I/O 인프라를 공유하는 컨트롤 플레인 노드에서 다른 워크로드를 배치하지 마십시오.

10ms 미만의 fdatasync를 포함하여 순차적으로 50KB의 IOPS를 쓸 수 있는 블록 장치에서 etcd를 실행합니다. 로드가 많은 클러스터의 경우 8000바이트(2ms)의 순차적 500 IOPS를 권장합니다. 이러한 숫자를 측정하려면 fio 명령과 같은 벤치마킹 툴을 사용할 수 있습니다.

이러한 성능을 달성하려면 대기 시간이 짧고 처리량이 높은 SSD 또는 NVMe 디스크에서 지원하는 머신에서 etcd를 실행합니다. 메모리 셀당 1비트를 제공하는 SSD(Single-level cell) SSD(Solid-State Drive)는 Cryostat 및 reliable이며 쓰기 집약적인 워크로드에 이상적입니다.

다음 하드 드라이브 사례는 최적의 etcd 성능을 제공합니다.

배포된 OpenShift Container Platform 클러스터에서 모니터링할 몇 가지 주요 지표는 etcd 디스크 쓰기 전 로그 기간과 etcd 리더 변경 횟수입니다. 이러한 지표를 추적하려면 Prometheus를 사용하십시오.