6.2 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 | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 77aa0188-5c2b-4f47-bda7-7c66b084968d | QUESTION | host-io-scheduler | 이 호스트의 I/O Scheduler 는 무엇인가 | storage-virtualization | 스토리지 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/77aa0188-5c2b-4f47-bda7-7c66b084968d/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
이 호스트의 I/O Scheduler 는 무엇인가
여러 가상 머신과 호스트 프로세스가 낸 입출력은 같은 호스트 블록 계층으로 들어와 장치로 dispatch 되는데, 그 순서를 정하는 정책이 스케줄러다. 정책이 무엇인지에 따라 부하 구간의 지연을 읽는 조건이 달라진다. 값을 읽는 데는 파일 하나를 보면 되고, 그 파일 이름에 넣을 장치는 이미지 아래를 따라 내려간 물음이 확정한다.
관계
- VM 아래에 한 번 더 있는 Host block stack — blk-mq · I/O Scheduler · NVMe 스케줄러가 그 스택의 어디에서 무엇을 정하는지를 그 개념이 설명한다.
- disk image 는 최종적으로 어느 Host block device 위에 있는가 그 물음이 확정한 장치 이름을 넣어야 이 확인 명령이 완성된다.
- VM1 의 storage 부하가 VM2 의 지연을 실제로 밀어 올리는가 여기서 읽은 정책이 그 실험의 결과를 읽는 조건이 된다.
- 지연 원인을 CPU 로 읽기 전에 storage 계층을 따로 잰다 그 기준이 요구하는 스토리지 쪽 조건 가운데 하나를 이 값이 채운다.
사실
§161 은 여러 입출력 요청이 있다고 해서 항상 들어온 순서 그대로 장치에 전달되지는 않고 I/O Scheduler 가 dispatch 정책을 갖는다고 적었다. 대표적으로 볼 수 있는 것으로 셋을 들었다.
none mq-deadline bfq
스케줄러마다 목적과 정책이 다르다.
§162 는 none 을 복잡한 스케줄링 정책을 최소화해 비교적 직접 장치 쪽으로 dispatch 하는 방향으로 설명했다. NVMe 처럼 장치 자체가 강한 병렬성과 큐 기능을 가진 경우 이런 단순한 정책이 적합할 수 있다. 다만 none 이 블록 계층이 아무 일도 하지 않는다는 상태를 뜻하지는 않는다.
§160 은 blk-mq 를 CPU 마다 큐를 두어 여러 CPU 가 병렬로 블록 입출력을 처리하는 구조로 그렸고, 스토리지 처리도 CPU 스케줄링과 완전히 독립된 세계는 아니라고 덧붙였다.
§163 은 호스트 확인 명령으로 cat /sys/block/nvme0n1/queue/scheduler 를 들고 예시 출력을 이렇게 보였다.
[none] mq-deadline
대괄호 안이 현재 선택된 스케줄러다. SATA/SCSI device 라면 cat /sys/block/sda/queue/scheduler 처럼 확인한다.
§175 OQ-6 은 같은 파일을 장치 이름을 넣어 읽으라고 했다.
이 호스트의 값은 개념 문서에 없다. §163 의 nvme0n1 과 sda 는 명령의 모양을 보이려고 든 예시 이름이다.
가정
호스트에 붙어 sysfs 아래의 파일을 읽을 수 있다고 본다.
이미지를 담은 장치 이름이 앞 물음에서 확정되어 있다고 보고 그 이름을 명령에 넣는다.
읽는 시점의 값이 부하를 걸 때도 같다고 전제하는데, 측정 사이에 누가 값을 바꾸면 이 전제가 깨진다.
미지수
이미지를 담고 있는 장치의 현재 스케줄러가 무엇인지.
그 장치에서 선택할 수 있는 목록에 무엇이 들어 있는지. §161 이 든 셋과 같은지도 확인해야 안다.
이미지가 놓인 장치가 여럿일 때 장치마다 값이 다른지.
제약
스케줄러를 바꿀지 말지는 이 물음이 정하지 않고, 바꾼 전후를 비교한 측정이 나온 뒤에 결정으로 넘긴다.
읽기만 한다. 값을 바꾸면 지금 구성에서 부하가 어떻게 처리되는지 못 본다.
§163 의 예시 이름을 이 호스트의 장치 이름으로 옮겨 적지 않고, 앞 물음이 확정한 이름을 넣는다.
개념 문서가 명령과 출력 읽는 법을 다 적어 두어서 비어 있는 것은 이 호스트의 값 하나다. 그래서 이 물음이 정할 것은 어느 장치에 그 명령을 돌릴지뿐이고, 그 이름은 이 물음이 스스로 내지 않는다.
선택지
1. 이미지를 담은 장치만 읽는다
이 물음이 필요한 것은 가상 머신의 입출력이 지나는 장치의 정책 하나여서, 파일 하나를 읽고 대괄호 안의 값을 적으면 끝난다.
호스트의 다른 장치가 다른 정책으로 돌고 있어도 그 사실은 안 보인다.
2. 호스트의 블록 장치를 전부 훑어 값을 함께 적는다
장치마다 같은 파일을 읽어 한 표로 만들면 이미지가 놓인 장치의 값이 이 호스트에서 예외인지 아닌지도 함께 보인다. 이미지가 여러 장치에 나뉘어 있는 구성이면 어차피 여러 장치를 읽어야 한다.
지금 판단에 쓰이지 않는 장치의 값까지 남게 된다.
다음 검증
- 이미지 아래를 따라 내려간 물음이 확정한 장치 이름을 가져온다.
- 그 이름을 넣어 /sys/block 아래의 queue/scheduler 파일을 읽고 출력을 그대로 적는다 (§175 OQ-6). NVMe 면 cat /sys/block/nvme0n1/queue/scheduler 와 같은 모양이고, SATA/SCSI device 면 cat /sys/block/sda/queue/scheduler 와 같은 모양이다.
- 대괄호가 붙은 값을 현재 선택된 스케줄러로 적고, 대괄호 밖의 이름은 선택지로 함께 적는다.
- 이미지가 놓인 장치가 여럿이면 장치마다 되풀이한다.
닫는 조건 : 장치마다 현재 스케줄러와 선택지가 출력으로 적히면 닫는다. none 이면 §162 의 서술이 이 호스트에 적용된다고 적는다. mq-deadline 이나 bfq 면 dispatch 정책이 개입한다는 사실을 VM1 부하와 VM2 지연을 재는 물음의 해석 조건으로 넘긴다.