etcd에 적합한 저장 속도? 피오에게 물어보자

fio 및 etcd에 대한 짧은 이야기

클러스터 성능 등 스토리지의 성능에 크게 좌우됩니다. etcd는 일부 메트릭을 다음으로 내보냅니다. 프로 메테우스원하는 스토리지 성능 정보를 제공합니다. 예를 들어 wal_fsync_duration_seconds 지표입니다. etcd에 대한 설명서에 따르면: 스토리지가 충분히 빠른 것으로 간주되려면 이 지표의 99번째 백분위수가 10ms 미만이어야 합니다. Linux 시스템에서 etcd 클러스터를 실행할 계획이고 스토리지가 충분히 빠른지(예: SSD) 평가하려는 경우 다음을 사용할 수 있습니다. fio I/O 작업을 테스트하는 데 널리 사용되는 도구입니다. 다음 명령을 실행합니다. 여기서 test-data는 스토리지 마운트 지점 아래의 디렉터리입니다.

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

결과를 보고 기간의 99번째 백분위수를 확인하기만 하면 됩니다. fdatasync 10ms 미만. 그렇다면 합리적으로 빠른 스토리지가 있습니다. 다음은 결과의 예입니다.

  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를 구성하는 방법을 배운 방법.
• 테스트하는 동안 모든 I/O 로드는 fio에서 발생합니다. 실제 시나리오에서는 wal_fsync_duration_seconds와 관련된 쓰기 요청 외에 다른 쓰기 요청이 스토리지에 들어올 수 있습니다. 추가 부하는 wal_fsync_duration_seconds 값을 증가시킵니다. 따라서 99번째 백분위수가 10ms에 가까우면 스토리지 속도가 부족한 것입니다.
• 버전 가져오기 fio 3.5 이상 (이전 항목은 fdatasync 기간 백분위수를 표시하지 않음).
• 위는 fio의 결과 스니펫입니다.

fio 및 etcd에 대한 긴 이야기

etcd에서 WAL이란 무엇입니까?

일반적으로 데이터베이스는 미리 쓰기 로그; etcd도 사용합니다. 여기서는 미리 쓰기 로그(WAL)에 대해 자세히 설명하지 않습니다. etcd 클러스터의 각 구성원이 이를 영구 스토리지에 유지한다는 사실만 알면 충분합니다. etcd는 저장소에 적용하기 전에 각 키-값 작업(예: 업데이트)을 WAL에 기록합니다. 스토리지 구성원 중 하나가 충돌하고 스냅샷 간에 다시 시작되면 WAL 콘텐츠에 의해 마지막 스냅샷 이후 로컬에서 트랜잭션을 복원할 수 있습니다.

클라이언트가 키-값 저장소에 키를 추가하거나 기존 키의 값을 업데이트하면 etcd는 영구 저장소의 일반 파일인 WAL에 작업을 기록합니다. etcd는 처리를 계속하기 전에 WAL 항목이 실제로 발생했는지 완전히 확인해야 합니다. Linux에서는 하나의 시스템 호출만으로는 충분하지 않습니다. 쓰다, 물리적 스토리지에 대한 실제 쓰기가 지연될 수 있기 때문입니다. 예를 들어 Linux는 한동안 커널 메모리의 캐시(예: 페이지 캐시)에 WAL 항목을 저장할 수 있습니다. 그리고 데이터가 영구 저장소에 정확하게 쓰여지기 위해서는 쓰기 후 fdatasync 시스템 호출이 필요하며, etcd는 그냥 사용합니다(작업 결과에서 볼 수 있듯이) 추적하다, 여기서 8은 WAL 파일 디스크립터임):

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

불행히도 영구 저장소에 쓰는 것은 즉시 발생하지 않습니다. fdatasync 호출이 느리면 etcd 시스템의 성능이 저하됩니다. etcd에 대한 설명서에 따르면99번째 백분위수에서 fdatasync 호출이 WAL 파일에 쓰는 데 10ms 미만이면 스토리지가 충분히 빠른 것으로 간주됩니다. 스토리지에 대한 다른 유용한 메트릭이 있지만 이 게시물에서는 이 메트릭에 대해서만 설명합니다.

fio로 스토리지 예측

스토리지가 etcd에 적합한지 평가해야 하는 경우 매우 인기 있는 I/O 로드 테스트 도구인 fio를 사용하십시오. 디스크 작업은 동기식과 비동기식, 많은 시스템 호출 클래스 등 매우 다를 수 있음을 기억해야 합니다. 결과적으로 fio는 사용하기가 매우 어렵습니다. 여기에는 많은 매개변수가 있으며 값의 조합이 다르면 매우 다른 I/O 워크로드가 생성됩니다. etcd에 대한 적절한 수치를 얻으려면 WAL 파일을 작성할 때 fio의 테스트 쓰기 로드가 etcd의 실제 로드에 최대한 근접하도록 해야 합니다.

따라서 fio는 최소한 파일에 일련의 순차적 쓰기 로드를 생성해야 하며 각 쓰기는 시스템 호출로 구성됩니다. 쓰다fdatasync 시스템 호출이 뒤따릅니다. fio에 대한 순차적 쓰기에는 --rw=write 옵션이 필요합니다. fio가 쓸 때 쓰기 시스템 호출을 사용하려면 쓰다, --ioengine=sync 매개변수를 지정해야 합니다. 마지막으로 각 쓰기 후에 fdatasync를 호출하려면 --fdatasync=1 매개변수를 추가해야 합니다. 이 예제의 다른 두 옵션(--size 및 -bs)은 스크립트에 따라 다릅니다. 다음 섹션에서는 설정 방법을 보여 드리겠습니다.

fio가 필요한 이유와 설정 방법

이 게시물에서는 실제 사례를 설명합니다. 클러스터가 있습니다. Kubernetes Prometheus로 모니터링한 v1.13. etcd v3.2.24는 SSD에서 호스팅되었습니다. Etcd 메트릭은 클러스터가 아무 작업도 수행하지 않는 경우에도 fdatasync 대기 시간이 너무 높은 것으로 나타났습니다. 메트릭이 이상했고 우리는 그것이 의미하는 바를 실제로 알지 못했습니다. 클러스터는 가상 머신으로 구성되었으므로 물리적 SSD 또는 가상화 계층에서 문제가 무엇인지 이해해야 했습니다. 또한 하드웨어 및 소프트웨어 구성을 자주 변경했으며 그 결과를 평가할 방법이 필요했습니다. 모든 구성에서 etcd를 실행하고 Prometheus 메트릭을 볼 수 있지만 너무 번거롭습니다. 우리는 특정 구성을 평가하는 상당히 간단한 방법을 찾고 있었습니다. 우리는 etcd의 Prometheus 메트릭을 올바르게 이해하고 있는지 확인하고 싶었습니다.

그러나 이를 위해서는 두 가지 문제를 해결해야 했다. 첫째, WAL에 쓸 때 etcd가 생성하는 I/O 로드는 어떤 모습입니까? 어떤 시스템 호출이 사용됩니까? 레코드의 크기는 얼마입니까? 둘째, 이러한 질문에 답하면 fio를 사용하여 유사한 워크로드를 재현하는 방법은 무엇입니까? fio는 많은 옵션이 있는 매우 유연한 도구라는 점을 잊지 마십시오. 명령을 사용하여 하나의 접근 방식으로 두 가지 문제를 모두 해결했습니다. 이소프 и 추적하다. lsof는 프로세스 및 관련 파일에서 사용하는 모든 파일 설명자를 나열합니다. 그리고 strace를 사용하면 이미 실행 중인 프로세스를 검사하거나 프로세스를 시작하고 검사할 수 있습니다. strace는 검사 중인 프로세스(및 하위 프로세스)의 모든 시스템 호출을 인쇄합니다. 후자는 etcd가 비슷한 접근 방식을 취하고 있기 때문에 매우 중요합니다.

클러스터에 부하가 없을 때 먼저 strace를 사용하여 Kubernetes용 etcd 서버를 탐색했습니다. 우리는 거의 모든 WAL 레코드의 크기가 2200~2400바이트로 거의 동일하다는 것을 확인했습니다. 따라서 게시물 시작 부분의 명령에서 -bs=2300 매개변수를 지정했습니다(bs는 각 fio 항목의 바이트 크기를 의미합니다). etcd 항목의 크기는 etcd 버전, 분포, 매개변수 값 등에 따라 달라지며 fdatasync 기간에 영향을 줍니다. 유사한 시나리오가 있는 경우 strace로 etcd 프로세스를 검사하여 정확한 숫자를 찾으십시오.

그런 다음 etcd 파일 시스템이 수행하는 작업에 대한 좋은 아이디어를 얻기 위해 strace 및 -ffttT 옵션으로 시작했습니다. 그래서 우리는 하위 프로세스를 검사하고 각 프로세스의 출력을 별도의 파일에 기록하고 각 시스템 호출의 시작 및 기간에 대한 자세한 보고서를 얻으려고 했습니다. lsof를 사용하여 strace 출력 분석을 확인하고 어떤 파일 설명자가 어떤 용도로 사용되었는지 확인했습니다. 그래서 strace의 도움으로 위와 같은 결과를 얻었다. 동기화 시간 통계는 etcd의 wal_fsync_duration_seconds가 WAL 파일 디스크립터를 사용한 fdatasync 호출과 일치함을 확인했습니다.

우리는 fio에 대한 문서를 살펴보고 fio가 etcd와 유사한 로드를 생성하도록 스크립트 옵션을 선택했습니다. 또한 etcd와 유사하게 strace에서 fio를 실행하여 시스템 호출과 지속 시간을 확인했습니다.

우리는 fio의 전체 I/O 로드를 나타내기 위해 --size 매개변수의 값을 신중하게 선택했습니다. 이 경우 스토리지에 기록된 총 바이트 수입니다. 이는 쓰기(및 fdatasync) 시스템 호출 수에 정비례하는 것으로 나타났습니다. bs의 특정 값에 대해 fdatasync 호출 수 = size/bs입니다. 우리는 백분위수에 관심이 있었기 때문에 확실히 하기 위해 충분한 샘플이 있어야 했고 10^4가 우리에게 충분할 것이라고 계산했습니다(즉, 22메비바이트). --size가 더 작은 경우 이상값이 발생할 수 있습니다(예: 여러 fdatasync 호출이 평소보다 오래 걸리고 99번째 백분위수에 영향을 미침).

직접 해보기

우리는 fio를 사용하는 방법과 스토리지가 etcd가 잘 작동할 만큼 충분히 빠른지 확인하는 방법을 보여 주었습니다. 이제 예를 들어 SSD 스토리지가 있는 가상 머신을 사용하여 직접 사용해 볼 수 있습니다. IBM Cloud.

출처 : habr.com