9.3 KiB
id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source
| id | kind | slug | title | topic | topicName | project | status | questionStatus | studio | sourceRevision | source | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ed64d4ff-aa01-48cc-ae68-6a683b025cde | QUESTION | vm1-storage-load-vs-vm2-latency | VM1 의 storage 부하가 VM2 의 지연을 실제로 밀어 올리는가 | storage-virtualization | 스토리지 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/ed64d4ff-aa01-48cc-ae68-6a683b025cde/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
VM1 의 storage 부하가 VM2 의 지연을 실제로 밀어 올리는가
한 물리 NVMe 를 나눠 쓰는 구성에서 VM1 이 I/O 를 쏟아내면 VM2 의 지연이 오를 수 있다고 개념 문서가 적었다. 개념 문서가 적은 것은 거기까지이고, 이 호스트에서 재 본 값은 없다. 그래서 이 물음은 VM1 에 controlled I/O load 를 걸고 VM2 의 애플리케이션 지연과 Host storage 지표를 같은 시간축에 놓아, 그 경쟁이 이 구성에서 실제로 관측되는지를 가른다.
관계
- VM 아래에 한 번 더 있는 Host block stack — blk-mq · I/O Scheduler · NVMe 두 가상 머신의 I/O 가 어디서 만나는지를 그 개념이 설명한다.
- 지연 원인을 CPU 로 읽기 전에 storage 계층을 따로 잰다 부하 구간에 CPU 와 스토리지 지표를 함께 찍는 이유가 그 기준이다.
- disk image 는 최종적으로 어느 Host block device 위에 있는가 두 가상 머신이 같은 장치를 쓰는지가 이 실험의 전제이고, 그 물음이 그것을 확정한다.
- 이 호스트의 I/O Scheduler 는 무엇인가 dispatch 정책이 무엇인지가 부하 구간의 값을 읽는 조건이 된다.
- Guest 의 fsync() 지연과 Host storage 지연은 같이 오르는가 같은 호스트 지표를 보지만 그쪽은 Guest 가 요구한 durability 가 전달되는지를 묻는다.
- 가상 머신 두 대에 동시에 부하를 주면 이 호스트에서 vCPU 경쟁이 실제로 생기는가 부하를 거는 모양이 닮았지만 재는 자원이 CPU 라 같은 측정으로 닫히지 않는다. 그래서 하나로 합치지 않고 관계로만 이었다.
사실
§159 는 VM1 QEMU 와 VM2 QEMU 와 Nginx 와 Host 기타 프로세스가 같은 Host Block Layer queue 로 들어와 device 로 dispatch 된다고 그렸다. VM1 의 WRITE X · READ Y · WRITE Z 와 VM2 의 READ A · WRITE B 와 Host process 의 READ C 가 그 queue 에서 함께 관리된다.
§167 은 여러 가상 머신이 동일한 Physical NVMe 를 사용하면 storage resource 경쟁이 발생할 수 있고, VM1 에서 대량 I/O 가 발생하면 VM2 의 storage latency 가 증가할 수 있다고 적었다. 그러면서 두 경쟁을 이렇게 갈랐다.
CPU Contention : Host logical CPU 실행 시간 경쟁 Storage Contention : IOPS / bandwidth / queue / device 처리시간 경쟁
§168 은 PostgreSQL 이 storage completion 을 기다리는 동안 CPU usage 가 높지 않을 수 있다고 적고, CPU 30% 인데 Request latency 2초 인 상황을 들었다. 그래서 CPU 지표만으로 지연의 원인을 판단하면 안 된다고 했다.
§169 는 device I/O 관측으로 iostat -xz 1 을, 어떤 프로세스가 I/O 를 발생시키는지 볼 때는 iotop 을 들었다. iostat 에서 볼 대상으로 read/write throughput, IOPS, request latency, queue 상태, device utilization 성격의 지표를 적었다.
§175 OQ-7 이 적은 실험은 한 문장이다. VM1 에서 별도의 테스트 파일이나 디스크로 controlled I/O load 를 발생시키고 VM2 의 애플리케이션 지연과 Host storage 지표를 동시에 본다. 부하를 무엇으로 만들지, 얼마나 크게 얼마나 오래 걸지는 그 한 문장에 없어서 재는 쪽이 정한다.
이 호스트에서 그렇게 재 본 결과는 개념 문서에 없다. §168 의 30% 와 2초 도 CPU 와 지연이 어긋날 수 있다는 것을 보이려고 든 예시 값이다.
가정
두 가상 머신의 이미지가 같은 block device 위에 있다고 보고 실험을 짠다. 앞 물음이 서로 다른 장치라고 확정하면 이 전제가 없어진다.
VM1 에 controlled I/O load 를 걸었다가 걷을 수 있고, 걷은 뒤 상태가 부하 이전의 기준 구간으로 돌아온다고 본다. 돌아오는지는 세 번째 구간에서 확인한다.
VM2 의 애플리케이션 지연을 세 구간에서 같은 방법으로 잴 수 있다고 전제한다.
호스트와 두 게스트의 시계가 맞아서 지연과 iostat 값을 같은 시간축에 놓을 수 있다고 본다.
부하를 거는 동안 가상 머신 구성과 VM2 의 워크로드가 바뀌지 않는다고 두고 세 구간을 견준다.
호스트 쪽 Nginx 와 다른 프로세스도 같은 장치를 쓰는데, 부하 구간의 스토리지 지표를 전부 VM1 몫으로 읽으면 이 전제가 깨진다. 그래서 어느 프로세스가 I/O 를 내는지 iotop 으로 함께 찍는다.
미지수
VM1 에 부하를 걸었을 때 VM2 의 애플리케이션 지연이 기준 구간과 달라지는지.
달라진다면 같은 구간의 Host storage 지표 — IOPS, throughput, request latency, queue 상태 — 가 같은 방향으로 움직이는지.
그 변화가 CPU 쪽 지표와 무관한지. §168 은 CPU 가 한가해도 지연이 커질 수 있다고 적었다.
어느 정도의 부하에서 VM2 의 지연이 움직이기 시작하는지. 개념 문서는 부하의 크기와 지속 시간을 적지 않았다.
부하를 걷은 뒤 VM2 의 지연이 기준 구간으로 돌아오는지, 돌아온다면 얼마나 걸리는지.
제약
controlled I/O load 는 VM1 안의 별도 테스트 파일이나 디스크에 건다 (§175 OQ-7). VM1 의 운영 데이터에 걸면 부하를 되돌릴 수 없다.
세 구간 모두 같은 명령으로 찍는다. 구간마다 다른 도구로 재면 값이 달라진 것인지 도구가 다른 것인지 갈리지 않기 때문이다.
지연이 올랐다는 관측만으로 원인을 스토리지 경쟁으로 확정하지 않는다. 같은 구간의 CPU 지표를 함께 놓고 §167 이 가른 두 경쟁 가운데 어느 쪽인지 본다.
장치를 나눌지, 스케줄러를 바꿀지, I/O 를 제한할지는 이 물음이 정하지 않는다. 재고 나온 표가 그 결정의 근거가 된다.
측정하는 동안 다른 실험을 같은 장치 위에서 돌리지 않는다. 시간을 나눈다.
선택지
1. 기준 · 부하 · 회복 세 구간을 한 번에 돌린다
VM2 의 애플리케이션 지연과 호스트의 iostat -xz 1 과 CPU 를 기준 구간에서 한 번 찍고, VM1 에 부하를 건 구간에서 다시 찍고, 부하를 걷은 뒤 세 번째로 찍는다. 세 구간이 한 표에 들어가면 지연이 어느 지표와 함께 움직였는지 그 표에서 읽힌다. §175 OQ-7 이 적은 순서 그대로다.
부하를 만드는 방법과 크기를 먼저 정해야 하고, VM2 에 같은 부하를 세 번 거는 준비가 필요하다.
2. 부하를 단계로 올리며 지연을 따라 찍는다
부하를 한 단계씩 올려 가며 같은 셋을 반복해 찍으면 VM2 의 지연이 어느 지점에서 움직이기 시작하는지까지 나온다. 개념 문서가 부하 크기를 적지 않았으므로 한 번의 부하로는 그 크기가 적절했는지 알 수 없다.
실행 횟수가 늘고, 단계마다 같은 시간을 유지해야 값을 견줄 수 있다.
3. 제외 — 호스트에서 직접 I/O 부하를 만들어 대신한다
VM1 대신 호스트 프로세스로 부하를 만들면 준비가 짧다. §159 는 Host process 의 I/O 도 같은 queue 로 들어온다고 그렸으므로 장치 쪽 경쟁은 비슷하게 만들 수 있다. 그러나 이 물음이 묻는 것은 VM1 의 부하가 VM2 로 이어지는지이고, 호스트에서 만든 부하는 QEMU 를 지나지 않아서 같은 경로가 아니다.
다음 검증
- 두 가상 머신의 이미지가 같은 block device 를 쓰는지 먼저 확정한다.
- 기준 구간에서 VM2 의 애플리케이션 지연과 호스트의 iostat -xz 1 과 CPU 를 같은 시각에 기록한다.
- VM1 에서 별도의 테스트 파일이나 디스크로 controlled I/O load 를 발생시킨다. 무엇으로 어느 정도의 부하를 얼마나 오래 걸었는지 함께 적는다 (§175 OQ-7).
- 부하 구간에서 2번의 셋을 같은 방법으로 다시 기록하고, 어느 가상 머신이 I/O 를 내는지 iotop 으로 함께 남긴다 (§169).
- 부하를 걷고 회복 구간을 세 번째로 찍는다.
닫는 조건 : 세 구간 표에서 부하 구간에만 VM2 의 지연과 Host storage 지표가 함께 오르면 §167 이 그린 경쟁이 이 환경에서 이어진다는 것을 확인한 것이고, 그 시계열이 Case 가 된다. VM1 부하 중에도 VM2 의 지연이 기준 구간과 다르지 않으면 이 구성과 이 부하 수준에서는 경쟁이 관측되지 않는다고 적고 닫는다. 장치를 나눌지 · 스케줄러를 바꿀지 · I/O 를 제한할지는 그 Case 가 나온 뒤 결정으로 넘긴다.