108 lines
6.2 KiB
Markdown
108 lines
6.2 KiB
Markdown
---
|
|
id: 77aa0188-5c2b-4f47-bda7-7c66b084968d
|
|
kind: QUESTION
|
|
slug: host-io-scheduler
|
|
title: 이 호스트의 I/O Scheduler 는 무엇인가
|
|
topic: storage-virtualization
|
|
topicName: 스토리지 가상화
|
|
project: virtualization
|
|
status: 초안
|
|
questionStatus: OPEN
|
|
studio: "https://hyeonworks.com/studio/documents/77aa0188-5c2b-4f47-bda7-7c66b084968d/edit"
|
|
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
|
|
source:
|
|
- final/document.md#175-실제-테스트-서버에서-확인할-open-questions-oq-6
|
|
- final/document.md#161-i-o-scheduler
|
|
- final/document.md#162-none
|
|
- final/document.md#163-실제-i-o-scheduler-확인
|
|
- final/document.md#160-blk-mq-multi-queue-block-layer
|
|
---
|
|
|
|
# 이 호스트의 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. 호스트의 블록 장치를 전부 훑어 값을 함께 적는다
|
|
|
|
장치마다 같은 파일을 읽어 한 표로 만들면 이미지가 놓인 장치의 값이 이 호스트에서 예외인지 아닌지도 함께 보인다. 이미지가 여러 장치에 나뉘어 있는 구성이면 어차피 여러 장치를 읽어야 한다.
|
|
|
|
지금 판단에 쓰이지 않는 장치의 값까지 남게 된다.
|
|
|
|
## 다음 검증
|
|
|
|
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 와 같은 모양이다.
|
|
3. 대괄호가 붙은 값을 현재 선택된 스케줄러로 적고, 대괄호 밖의 이름은 선택지로 함께 적는다.
|
|
4. 이미지가 놓인 장치가 여럿이면 장치마다 되풀이한다.
|
|
|
|
닫는 조건 : 장치마다 현재 스케줄러와 선택지가 출력으로 적히면 닫는다. none 이면 §162 의 서술이 이 호스트에 적용된다고 적는다. mq-deadline 이나 bfq 면 dispatch 정책이 개입한다는 사실을 VM1 부하와 VM2 지연을 재는 물음의 해석 조건으로 넘긴다.
|