Какой планировщик нужно изменить в LVM для работы с виртуальными машинами
Когда у вас есть LVM, у вас есть запись для планировщика в /sys/block для ваших физических томов, но также для каждого отдельного логического тома и необработанного устройства.
У нас есть система Debian 6 LTS x64, ядро 2.6.32, работающая под гипервизором Xen 4.0 (аппаратный RAID 3 3Ware 9650 SE). При запуске виртуальных машин на каждом логическом томе, на каком из них вам нужно установить планировщик, если вы хотите повлиять на то, как они планируются ОС? Если вы установите логический том в deadlineбудет ли что-либо делать, когда физический том установлен на cfq? И если вы установите его в качестве крайнего срока на логическом томе, будут ли соблюдены эти сроки, даже когда диск замедляется из-за ввода-вывода на других LV, для которых установлено значение cfq?
Вопрос касается ввода-вывода на виртуальных машинах, которые слишком сильно замедляют работу других виртуальных машин. Все гости используют noop как планировщик внутри.
Редактировать: в соответствии с этим, в среде с многолучевым распространением будет действовать только планировщик DM. Так что, если я хочу обрабатывать ввод-вывод между виртуальными машинами в deadline Таким образом, я должен установить путь DM физического тома (дм-1 в моем случае) в deadline, Это правильно? Есть также планировщик для sdc, который является исходным блочным устройством моего dm-1. Почему бы не сделать это на этом?
edit2: но потом кто-то говорит в комментариях, что dm-0/1 не имеет планировщика в более новых ядрах:
famzah@VBox:~$ cat /sys/block/dm-0/queue/scheduler
none
В моей системе (Debian 6, ядро 2.6.32) у меня есть:
cat /sys/block/dm-1/queue/scheduler
noop anticipatory [deadline] cfq
Вопрос также, есть ли у меня настройка многолучевого распространения? pvs показывает:
# pvs
PV VG Fmt Attr PSize PFree
/dev/dm-0 universe lvm2 a- 5,41t 3,98t
/dev/dm-1 alternate-universe lvm2 a- 1,82t 1,18t
Но они были созданы с помощью /dev/sd[bc]. Означает ли это, что у меня есть многолучевое распространение, хотя это стандартная настройка LVM?
Думаю, главный вопрос заключается в том, нужно ли мне устанавливать планировщик на sdc или dm-1? Если я делаю iostat, я вижу много доступа на обоих:
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdc 0,00 0,00 13,02 25,36 902,71 735,56 42,68 0,08 2,17 0,73 2,79
dm-1 82,25 57,26 12,97 25,36 902,31 735,56 42,72 0,18 4,73 0,84 3,23
Итак, что же такое и кто в доме хозяин? Если это sdc, я могу вам сказать, что установка этого срока не влияет на производительность моих виртуальных машин. Глядя на разницу в столбцах "запросы объединены" (первые два), я бы сказал, что именно dm-1 контролирует планирование.
3 ответа
Таким образом, ответ оказался простым: базовое устройство. Более новые ядра имеют только "нет" в /sys/block/*/queue/scheduler когда нет планировщика для настройки.
Однако по неизвестной мне причине устройства на этом сервере создаются как устройства с многолучевым распространением, поэтому моя работа с планировщиком включена /dev/sd[bc] никогда ничего не делал в прошлом. Теперь я установил dm-1 а также dm-0 в срок с read_expire=100 а также write_expire=1500 (гораздо более строгий, чем обычно), и результаты кажутся очень хорошими.
На этом графике показано влияние задержки диска в виртуальной машине, вызванное другой виртуальной машиной с ежечасной задачей:
Вы можете ясно видеть момент, когда я изменил параметры планировщика.
Хм, Debian...
Хорошо, я могу поделиться тем, как Redhat подходит к этому с их настроенной структурой. Есть профили для "виртуального хоста" и "виртуального гостя". Описания профилей подробно объясняются здесь, а в следующем отрывке показано, какие устройства подвержены воздействию. Устройства "dm-*" и "sdX" изменили свои планировщики.
# This is the I/O scheduler ktune will use. This will *not* override anything
# explicitly set on the kernel command line, nor will it change the scheduler
# for any block device that is using a non-default scheduler when ktune starts.
# You should probably leave this on "deadline", but "as", "cfq", and "noop" are
# also legal values. Comment this out to prevent ktune from changing I/O
# scheduler settings.
ELEVATOR="deadline"
# These are the devices, that should be tuned with the ELEVATOR
ELEVATOR_TUNE_DEVS="/sys/block/{sd,cciss,dm-,vd,zd}*/queue/scheduler"
Также см:
Настроенный эквивалент CentOS для Debian и понимание рекомендуемых настроенных профилей RedHat
Как рекомендует vmware, лучше использовать планировщик noop, если ваш гость использует файл как виртуальный диск, таким образом, ваш гость передает IO на ваш хост напрямую, без реорганизации IO дважды в вашем госте и на вашем физическом хосте.