🥇etcd에 대한 충분한 성능을 위해 fio로 디스크를 확인하는 방법

메모. 번역: 이 기사는 etcd 데이터베이스 운영과 관련된 실제 문제에 대한 솔루션을 찾기 위해 IBM Cloud 엔지니어가 수행한 소규모 연구 결과입니다. 비슷한 작업이 우리와 관련이 있었지만 저자의 반성과 행동 과정은 더 넓은 맥락에서 흥미로울 수 있습니다.

전체 문서에 대한 간략한 요약: fio 및 etcd

etcd 클러스터의 성능은 기본 스토리지의 속도에 크게 의존합니다. etcd는 성능을 모니터링하기 위해 다양한 Prometheus 지표를 내보냅니다. 그들 중 하나는 wal_fsync_duration_seconds. etcd에 대한 설명서에서 그것은 말한다이 메트릭의 99번째 백분위수가 10ms를 초과하지 않으면 스토리지가 충분히 빠른 것으로 간주될 수 있습니다.

Linux 시스템에서 etcd 클러스터 설정을 고려 중이고 드라이브(예: SSD)가 충분히 빠른지 확인하려는 경우 널리 사용되는 I/O 테스터를 사용하는 것이 좋습니다. fio. 다음 명령을 실행하면 충분합니다(디렉토리 test-data 테스트 드라이브의 마운트된 파티션에 있어야 함):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

출력을 보고 99번째 백분위수가 맞는지 확인하는 것만 남아 있습니다. fdatasync 10ms 후. 그렇다면 드라이브가 충분히 빠르게 작동하고 있는 것입니다. 다음은 출력 예입니다.

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

몇 가지 메모 :

위의 예에서 매개변수를 조정했습니다. --size и --bs 특정 경우. 에서 의미 있는 결과를 얻으려면 fio, 사용 사례에 적합한 값을 지정하십시오. 선택 방법은 아래에서 설명합니다.
테스트 중에만 fio 디스크 하위 시스템을 로드합니다. 실생활에서는 다른 프로세스가 디스크에 기록할 가능성이 높습니다( wal_fsync_duration_seconds). 이 추가 부하는 증가할 수 있습니다. wal_fsync_duration_seconds. 즉, 테스트에서 99번째 백분위수가 fio, 10ms보다 약간 작은 경우 스토리지 성능이 충분하지 않을 가능성이 높습니다.
테스트를 위해서는 버전이 필요합니다 fio 3.5 이상, 이전 버전은 결과를 집계하지 않기 때문입니다. fdatasync 백분위 수의 형태로.
위의 결론은 일반적인 결론에서 일부만 발췌한 것입니다. fio.

fio 및 etcd에 대한 추가 정보

WAL etcd에 대한 몇 마디

일반적으로 데이터베이스는 능동적 로깅 (미리 쓰기 로깅, WAL). etcd도 영향을 받습니다. WAL에 대한 논의는 이 기사의 범위를 벗어나지만 우리의 목적을 위해 알아야 할 것은 각 etcd 클러스터 구성원이 WAL을 영구 저장소에 저장한다는 것입니다. etcd는 일부 키-값 저장 작업(예: 업데이트)을 실행하기 전에 WAL에 기록합니다. 스냅샷 사이에 노드가 충돌하고 다시 시작되면 etcd는 WAL의 내용을 기반으로 이전 스냅샷 이후 트랜잭션을 복구할 수 있습니다.

따라서 클라이언트가 KV 저장소에 키를 추가하거나 기존 키 값을 업데이트할 때마다 etcd는 영구 저장소의 일반 파일인 WAL에 작업 설명을 추가합니다. etcd는 진행하기 전에 WAL 항목이 실제로 저장되었는지 100% 확신해야 합니다. Linux에서 이를 달성하려면 시스템 호출을 사용하는 것만으로는 충분하지 않습니다. write, 물리적 미디어에 대한 쓰기 작업 자체가 지연될 수 있기 때문입니다. 예를 들어 Linux는 WAL 항목을 인메모리 커널 캐시(예: 페이지 캐시)에 얼마 동안 보관할 수 있습니다. 데이터가 미디어에 기록되도록 하려면 쓰기 후에 시스템 호출을 호출해야 합니다. fdatasync - 이것은 정확히 etcd가 하는 일입니다(다음 출력에서 볼 수 있듯이). strace; 여기 8 - WAL 파일 설명자):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

불행히도 영구 저장소에 쓰는 데는 시간이 걸립니다. fdatasync 호출을 장기간 실행하면 etcd의 성능에 영향을 줄 수 있습니다. 저장소 문서에서 표시됨, 충분한 성능을 위해서는 모든 호출 기간의 99번째 백분위수가 필요합니다. fdatasync WAL 파일에 쓰는 시간이 10ms 미만일 때. 다른 스토리지 관련 메트릭이 있지만 이 문서에서는 해당 메트릭에 중점을 둘 것입니다.

fio로 스토리지 평가

유틸리티를 사용하여 특정 스토리지가 etcd와 함께 사용하기에 적합한지 여부를 평가할 수 있습니다. fio — 인기 있는 I/O 테스터. 디스크 I/O는 동기/비동기, 다양한 시스템 호출 클래스 등 다양한 방식으로 발생할 수 있음을 명심하십시오. 동전의 다른 면은 fio 사용하기 매우 어렵습니다. 이 유틸리티에는 많은 매개 변수가 있으며 해당 값의 조합이 다르면 결과가 완전히 달라집니다. etcd에 대한 합리적인 추정치를 얻으려면 fio에 의해 생성된 쓰기 로드가 가능한 한 etcd의 WAL 파일 쓰기 로드에 가까운지 확인해야 합니다.

이는 생성된 fio 로드는 적어도 파일에 대한 일련의 연속 쓰기여야 하며 각 쓰기는 시스템 호출로 구성됩니다. write다음에 fdatasync.
순차 쓰기를 활성화하려면 플래그를 지정해야 합니다. --rw=write.
그 fio 호출을 사용하여 작성 write (다른 시스템 호출이 아닌 - 예를 들어, pwrite), 플래그 사용 --ioengine=sync.
마지막으로 국기 --fdatasync=1 모든 write 해야 fdatasync.
예제의 다른 두 매개변수는 다음과 같습니다. --size и --bs - 특정 사용 사례에 따라 다를 수 있습니다. 다음 섹션에서는 해당 구성에 대해 설명합니다.

우리가 fio를 선택한 이유와 설정 방법을 배운 방법

이 메모는 우리가 만난 실제 사례에서 나온 것입니다. Prometheus에서 모니터링하는 Kubernetes v1.13에 클러스터가 있었습니다. SSD는 etcd v3.2.24의 스토리지로 사용되었습니다. Etcd 메트릭이 너무 높은 대기 시간을 나타냄 fdatasync, 클러스터가 유휴 상태인 경우에도 마찬가지입니다. 우리에게 이러한 지표는 매우 모호해 보였고 정확히 무엇을 나타내는지 확신할 수 없었습니다. 또한 클러스터가 가상 머신으로 구성되어 있어 지연이 가상화로 인한 것인지 아니면 SSD의 책임인지 알 수 없었습니다.

또한 하드웨어 및 소프트웨어 구성의 다양한 변경 사항을 고려했기 때문에 이를 평가할 방법이 필요했습니다. 물론 각 구성에서 etcd를 실행하고 해당 Prometheus 메트릭을 볼 수 있지만 상당한 노력이 필요합니다. 우리에게 필요한 것은 특정 구성을 평가하는 간단한 방법이었습니다. 우리는 etcd에서 오는 Prometheus 메트릭에 대한 이해를 테스트하고 싶었습니다.

이를 위해서는 두 가지 문제를 해결해야 했습니다.

첫째, WAL 파일에 쓸 때 etcd가 생성하는 I/O 로드는 어떤 모습입니까? 어떤 시스템 호출이 사용됩니까? 레코드 블록의 크기는 얼마입니까?
둘째, 위의 질문에 대한 답변이 있다고 가정해 보겠습니다. 해당 하중을 재현하는 방법 fio? 결국 fio — 풍부한 매개변수가 있는 매우 유연한 유틸리티 (예를 들어 확인하기 쉽습니다. 여기에 - 약. 번역.).

동일한 명령 기반 접근 방식으로 두 가지 문제를 모두 해결했습니다. lsof и strace:

과 lsof 프로세스에서 사용하는 모든 파일 디스크립터와 이들이 참조하는 파일을 볼 수 있습니다.
과 strace 이미 실행 중인 프로세스를 분석하거나 프로세스를 실행하고 관찰할 수 있습니다. 이 명령은 이 프로세스에서 수행한 모든 시스템 호출과 필요한 경우 해당 하위 항목을 표시합니다. 후자는 포크하는 프로세스에 중요하며 etcd는 그러한 프로세스 중 하나입니다.

우리가 가장 먼저 한 일은 사용하는 것이었습니다. strace 유휴 상태인 Kubernetes 클러스터의 etcd 서버를 검사합니다.

따라서 WAL 레코드 블록은 매우 조밀하게 그룹화되어 있으며 대부분의 크기는 2200-2400바이트 범위에 있었습니다. 이것이 이 기사의 시작 부분에 있는 명령이 플래그를 사용하는 이유입니다. --bs=2300 (bs 각 쓰기 블록의 바이트 크기입니다. fio).

etcd 쓰기 블록의 크기는 버전, 배포, 매개변수 값 등에 따라 다를 수 있습니다. - 지속 시간에 영향을 미칩니다. fdatasync. 유사한 사용 사례가 있는 경우 strace 최신 값을 얻기 위한 etcd 프로세스.

그런 다음 etcd가 파일 시스템에서 작동하는 방식에 대한 명확하고 포괄적인 아이디어를 얻기 위해 아래에서 시작했습니다. strace 플래그와 함께 -ffttT. 이를 통해 자식 프로세스를 캡처하고 각각의 출력을 별도의 파일에 쓸 수 있습니다. 또한 각 시스템 호출의 시작 시간과 지속 시간에 대한 자세한 정보를 얻었습니다.

우리는 또한 명령을 사용했습니다 lsof출력에 대한 이해를 확인하기 위해 strace 어떤 파일 디스크립터가 어떤 목적으로 사용되었는지에 관한 것입니다. 나는 결론을 얻었다 strace, 위와 유사합니다. 동기화 시간에 대한 통계적 조작을 통해 메트릭이 wal_fsync_duration_seconds etcd에서 일치하는 호출 fdatasync WAL 파일 설명자와 함께.

로 생성하려면 fio etcd의 워크로드와 유사한 워크로드, 유틸리티 문서를 연구하고 작업에 적합한 매개변수를 선택했습니다. 올바른 시스템 호출이 진행 중임을 확인했으며 다음을 실행하여 지속 시간을 확인했습니다. fio 으로 strace (etcd의 경우와 같이).

매개변수의 값을 결정하는 데 특별한 주의를 기울였습니다. --size. fio 유틸리티에서 생성된 총 I/O 로드를 나타냅니다. 우리의 경우 이것은 미디어에 기록된 총 바이트 수입니다. 호출 수에 정비례합니다. write (그리고 fdatasync). 특정 bs 통화 수 fdatasync 같음 size / bs.

우리는 백분위수에 관심이 있었기 때문에 샘플 수가 통계적으로 유의미할 만큼 충분히 많기를 원했습니다. 그리고 결정 10^4 (22MB 크기에 해당)이면 충분합니다. 더 작은 매개변수 값 --size 더 뚜렷한 소음을 냈습니다(예: 통화 fdatasync, 평소보다 훨씬 오래 걸리고 99번째 백분위수에 영향을 미칩니다.

그것은 당신에게 달려 있습니다

이 기사는 사용 방법을 보여줍니다 fio etcd와 함께 사용할 미디어가 충분히 빠른지 판단할 수 있습니다. 이제 당신에게 달렸습니다! 서비스에서 SSD 기반 스토리지로 가상 머신을 탐색할 수 있습니다. IBM Cloud.

번역가의 추신

기성 사용 사례 fio 다른 작업에 대해서는 다음을 참조하십시오. 선적 서류 비치 또는 직접 프로젝트 저장소 (문서에 언급된 것보다 더 많은 것들이 있습니다).

번역가의 PPS

블로그에서도 읽어보세요.

출처 : habr.com

etcd에 대한 충분한 성능을 위해 fio로 디스크를 확인하는 방법