dm-ioband

Материал из Xgu.ru

Перейти к: навигация, поиск


dm-ioband — драйвер операционной системы Linux, позволяющий управлять скоростью работы с блочными устройствами. Предназначен для использования в виртуализированной среде и с группами процессов (cgroups). В настоящее время dm-ioband работает как драйвер device-mapper.

14 сентября 2009 года вышла версия dm-ioband 1.13.0.


Содержание

[править] Что такое dm-ioband

dm-ioband — это контроллер, регулирующий полосу пропускания при выполнении операций ввода/вывода с блочным устройством, реализованный как драйвер device-mapper. Несколько работ, использующих одно физическое устройство, должны делить между собой его полосу пропускания. dm-ioband выделяет каждой работе полосу пропускания в соответствии с её весом, который может задаваться административно.

В настоящее время работой (job) может быть группа процессов с одинаковым идентификатором pid, pgrp или uid. В будущем планируется сделать поддержку cgroup. Работой также может быть виртуальная машина Xen или KVM.


  +------+ +------+ +------+   +------+ +------+ +------+
  |cgroup| |cgroup| | the  |   | pid  | | pid  | | the  |  работы (jobs)
  |  A   | |  B   | |others|   |  X   | |  Y   | |others|
  +--|---+ +--|---+ +--|---+   +--|---+ +--|---+ +--|---+
  +--V----+---V---+----V---+   +--V----+---V---+----V---+
  | group | group | default|   | group | group | default|  band-группы
  |       |       |  group |   |       |       |  group |
  +-------+-------+--------+   +-------+-------+--------+
  |         band1          |   |         band2          |  band-устройства
  +-----------|------------+   +-----------|------------+
  +-----------V--------------+-------------V------------+
  |                          |                          |
  |          sdb1            |           sdb2           |  физические устройства
  +--------------------------+--------------------------+

[править] Как работает dm-ioband

У каждого band-устройства есть как минимум одна его группа, которая по умолчанию так и называется — default group.

Band-групп у устройства может быть и несколько. У каждой band-группы есть (1) вес и (2) закреплённая за ней работа. dm-ioband выделяет маркеры группе пропорционально её весу.

Если у группы есть в запасе маркеры, запрос ввода/вывода, сделанный её работой, передаётся ниже. Если же маркеров у группы не осталось, обращение блокируется. Когда группа делает запрос ввода/вывода, она тратит один маркер. Когда маркеры заканчиваются у всех групп, работающих с данным устройством, dm-ioband пополняет их запас.

При таком подходе работа, закреплённая за band-группой с большим весом, гарантированно получит возможность сделать большее количество запросов ввода/вывода.

Полоса пропускания (bandwidth) в dm-ioband определяется как отношение времени обработки маркеров данного устройства к времени обработки маркеров всех устройств. Время обработки маркера определяется длительностью цикла ввода/вывода, включающим время поиска (seek latency), задержку на обработку прерывания (interrupt latency) и прочее.

[править] Как его использовать

Ниже показано как управлять полосой пропускания при доступе к дискам. В примере используется один диск с двумя разделами.

Более подробная информация представлена в документации на ядро Linux, в файле Document/device-mapper/band.txt.

[править] Создание и привязка band-устройств

Нужно создать два band-устройства band1 и band2 и привязать их к разделам /dev/sda1 и /dev/sda2 соответственно:

 # echo "0 `blockdev --getsize /dev/sda1` band /dev/sda1 1" | dmsetup create band1
 # echo "0 `blockdev --getsize /dev/sda2` band /dev/sda2 1" | dmsetup create band2

Если команды выполнятся успешно, будут созданы новые файлы устройств /dev/mapper/band1 и /dev/mapper/band2.

[править] Управление полосой пропускания

Назначим band1 и band2 веса 40 и 10 соответственно:

# dmsetup message band1 0 weight 40
# dmsetup message band2 0 weight 10

После этих команд band1 сможет использовать 80% — 40/(40+10)*100 — полосы пропускания к физическому диску /debv/sda, а band2 — оставшиеся 20%.

[править] Дополнительные возможности

В этом примере будут созданы две дополнительные band-группы для band1. В первую группу входят все процессы с user-id 1000, а во вторую — процессы с user-id 2000. Их веса соответственно 30 и 20.

Сначала тип band-групп band1 устанавливается равным user. Затем группы с user-id 1000 и 2000 присоединяются к band1. И последнее, назначаются веса для групп с user-id 1000 и 2000.

 # dmsetup message band1 0 type user
 # dmsetup message band1 0 attach 1000
 # dmsetup message band1 0 attach 2000
 # dmsetup message band1 0 weight 1000:30
 # dmsetup message band1 0 weight 2000:20

Теперь процессы в группе с user-id 1000 могут использовать 30% — 30/(30+20+40+10)*100 — доступной физической полосы пропускания диска.

 Band Device    Band Group                     Weight
  band1         user id 1000                     30
  band1         user id 2000                     20
  band1         default group(the other users)   40
  band2         default group                    10

[править] Удаление band-устройств

Удалить band-устройства, которые больше не используются, можно так:

 # dmsetup remove band1
 # dmsetup remove band2

[править] Планы на будущее

Что можно было бы сделать в будущих версиях:

  • Добавить поддержку Cgroup;
  • Управлять скоростью записи и чтения по отдельности;
  • Добавить поддержку WRITE_BARRIER;
  • Оптимизировать;
  • Добавить дополнительные инструменты для настройки (или хватит одного dmsetup'?);
  • Создать новые политики планировщика BIOs (или достаточно уже существующей, весовой?).

[править] Замеры

Ниже представлены результаты замеров, которые выполнил разработчик dm-ioband, Ryo Tsuruta. Они подтверждают то, что dm-ioband работает так, как и ожидалось. В ходе экспериментов создаётся несколько band-групп на нескольких физических разделах и выполняется интенсивный ввод/вывод на эти устройства.

[править] Железо для испытаний

  DELL Dimention E521:

  Linux kappa.local.valinux.co.jp 2.6.23.14 #1 SMP
    Thu Jan 24 17:24:59 JST 2008 i686 athlon i386 GNU/Linux
  Detected 2004.217 MHz processor.
  CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
  Memory: 966240k/981888k available (2102k kernel code, 14932k reserved,
    890k data, 216k init, 64384k highmem)
  scsi 2:0:0:0: Direct-Access     ATA      ST3250620AS     3.AA PQ: 0 ANSI: 5
  sd 2:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB)
  sd 2:0:0:0: [sdb] Write Protect is off
  sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
  sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
    doesn't support DPO or FUA
  sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14
    sdb15 >

[править] Результаты тестирования управления полосой пропускания для разделов

Конфигурация для эксперимента #1:

  • Создать три раздела sdb5, sdb6 и sdb7.
  • Назначить веса 40, 20 и 10 соответственно для sdb5, sdb6 и sdb7.
  • Запустить 128 процессов, выполняющих одновременно случайные операции прямого чтения и прямой записи блоков размером 4KB
  • Подсчитать количество выполненных операций в течение 60 секунд.
                результат эксперимента #1
 ---------------------------------------------------------------------------
|     device      |       sdb5        |       sdb6        |      sdb7       |
|     weight      |    40 (57.0%)     |     20 (29.0%)    |    10 (14.0%)   |
|-----------------+-------------------+-------------------+-----------------|
|   I/Os (r/w)    |  6640( 3272/ 3368)|  3434( 1719/ 1715)|  1689( 857/ 832)|
|  sectors (r/w)  | 53120(26176/26944)| 27472(13752/13720)| 13512(6856/6656)|
|  ratio to total |       56.4%       |       29.2%       |      14.4%      |
 ---------------------------------------------------------------------------

Конфигурация для эксперимента #2:

  • в точности такая же как для эксперимента #1, за исключением того, что не запускаются процессы, работающие с sdb6
                результаты эксперимента #2
 ---------------------------------------------------------------------------
|     device      |       sdb5        |       sdb6        |      sdb7       |
|     weight      |    40 (57.0%)     |     20 (29.0%)    |    10 (14.0%)   |
|-----------------+-------------------+-------------------+-----------------|
|   I/Os (r/w)    |  9566(4815/  4751)|     0(    0/    0)|  2370(1198/1172)|
|  sectors (r/w)  | 76528(38520/38008)|     0(    0/    0)| 18960(9584/9376)|
|  ratio to total |       76.8%       |        0.0%       |     23.2%       |
 ---------------------------------------------------------------------------

[править] Результаты тестирования управления полосой пропускания для band-групп

Конфигурация для эксперимента #3:

  • Создать два раздела sdb5 и sdb6
  • Создать две дополнительные band-группы на sdb5, первая для user1 и вторая для user2.
  • Назначить веса 40, 20, 10 и 10 для band-групп user1, user2, default-групп разделов sdb5 и sdb6 соответственно
  • Запустить 128 процессов, выполняющих одновременно случайные операции прямого чтения и прямой записи блоков размером 4KB
  • Подсчитать количество выполненных операций в течение 60 секунд.
                результаты эксперимента #3
 ---------------------------------------------------------------------------
|dev|                          sdb5                        |      sdb6      |
|---+------------------------------------------------------+----------------|
|usr|     user1        |      user2       |  other users   |   all users    |
|wgt|   40 (50.0%)     |    20 (25.0%)    |   10 (12.5%)   |   10 (12.5%)   |
|---+------------------+------------------+----------------+----------------|
|I/O| 5951( 2940/ 3011)| 3068( 1574/ 1494)| 1663( 828/ 835)| 1663( 810/ 853)|
|sec|47608(23520/24088)|24544(12592/11952)|13304(6624/6680)|13304(6480/6824)|
| % |     48.2%        |       24.9%      |      13.5%     |      13.5%     |
 ---------------------------------------------------------------------------

Конфигурация для эксперимента #4:

  • в точности такая же как для эксперимента #3, за исключением того, что не запускаются процессы, работающие с band-группой user2
                результаты эксперимента #4
 ---------------------------------------------------------------------------
|dev|                          sdb5                        |     sdb6       |
|---+------------------------------------------------------+----------------|
|usr|     user1        |      user2       |  other users   |   all users    |
|wgt|   40 (50.0%)     |    20 (25.0%)    |   10 (12.5%)   |   10 (12.5%)   |
|---+------------------+------------------+----------------+----------------|
|I/O| 8002( 3963/ 4039)|    0(    0/    0)| 2056(1021/1035)| 2008( 998/1010)|
|sec|64016(31704/32312)|    0(    0/    0)|16448(8168/8280)|16064(7984/8080)|
| % |     66.3%        |        0.0%      |      17.0%     |      16.6%     |
 ---------------------------------------------------------------------------

[править] Выводы

dm-ioband работает хорошо при выполнении случайных операций чтение/запись. В будущем планируется провести тестирование на реальных приложениях, таких как СУБД и файловые серверы.

[править] Почему нельзя было просто доработать CFQ?

В Linux есть механизмы для приоритезации дискового ввода/вывода. Почему нельзя было использовать их?

Ниже перевод письма одного из соавторов dm-ioband Хироказу Такаши (Hirokazu Takashi) в список рассылки Xen-devel[1], в котором он отвечает на этот вопрос.

From: Hirokazu Takahashi <taka@valinux.co.jp>

Доработать стандартный планировщик ввода/вывода, который есть в ядре,
это самый простой подход. Действительно, планировщик CFQ
можно было бы научить управлять полосой пропускания путём 
относительного небольшой модификации кода.
Оба подхода (использовать device-mapper и модифицировать CFQ)
имеют свои плюсы и минусы.

В настоящее время мы выбрали вариант с device-mapper по следующим причинам:
* он может работать с любым планировщиком. Некоторые хотят использовать планировщик NOOP
  для работы с high-end хранилищами;
* его должны использовать только те, кому нужно управление пропускной способностью I/O;
* он независим от других планировщиков и его легко поддерживать;
* не усложняется сопровождение CFQ.

У сегодняшней реализации планировщика CFQ есть некоторые ограничения,
которые мешают использовать его для управления полосой пропускания так,
как хотелось бы. У планировщика есть только 7 уровней приоритета,
что означает, что у него есть только 7 классов ввода/вывода.
Если назначить один и тот же приоритет A нескольким виртуальным машинам,
эти машины должны будут поровну делить полосу ввода/вывода,
выделенную классу A. Если при этом есть машина, работающая с приоритетом B, 
более низким чем A, и она такая одна, может так получится, что у неё будет
большая полоса пропускания чем у машин класса A.

Вообще, я думаю, что нужно чтобы в CFQ был планировщик с двумя уровнями.
Один уровень используется для выбора лучшей группы cgroup или работы (job),
а второй — для выбора класса с наивысшим приоритетом ввода/вывода.

Второй минус подхода с использованием существующего планировщика в том, 
что у него приоритеты ввода/вывода глобальны, 
и они распространяются на все диски, к которым осуществляется доступ.
Нельзя сделать так, чтобы у задачи были разные приоритеты при доступе к разным дискам.

У подхода с использованием device-mapper тоже есть свои минусы.
Сложно получить информацию о возможностях и конфигурации нижележащих устройств, 
такую, например, как информацию о разделах и LUN. И возможно, потребуется разрабатывать 
дополнительные инструменты для настойки.

[править] Дополнительные скрипты

From: Ryo Tsuruta <ryov@valinux.co.jp>

I've uploaded two scripts here:                                                                                                  
http://people.valinux.co.jp/~ryov/dm-ioband/scripts/xdd-count.sh                                                                 
http://people.valinux.co.jp/~ryov/dm-ioband/scripts/xdd-size.sh                                                                  
                                                                                                                                 
xdd-count.sh controls bandwidth based on the number of I/O requests,                                                             
and xdd-size.sh controls bandwidth based onthe number of I/O sectors.                                                            
Theses scritpts require xdd disk I/O testing tool which can be                                                                   
downloaded from here:                                                                                                            
http://www.ioperformance.com/products.htm 

[править] См. также

[править] Дополнительная информация

Xentaur
Дисковая подсистема
Linux | FreeBSD

Диски и разделы
Файлы устройств: Блочное устройство | Символьное устройство | Raw-устройство | loop-устройство
Диски: IDE | SATA (SATA hotplug) | SCSI | USB
RAID-массивы: Аппаратный RAID | Linux RAID | FreeBSD RAID
Дисковые разделы: Раздел | MBR | fdisk | parted | disklabel | GPT

Управление томами
Логический том | Физический том | Группа томов | Снимок | Клон
device-mapper | dm-ioband | dm-crypt | dm-userspace | multipath
Системы управления томами: LVM | CLVM | EVMS | Btrfs* | ZFS* | AdvFS* | Zumastor

Сетевые хранилища и репликация
Отказоустойчивость: DRBD | Xen + DRBD | ggate + gmirror | HAST
Сетевые хранилища: AoE | iSCSI | FCoE | GNBD

Файловые системы
Монтирование | Проверка целостности | Дефрагментация | Суперблок | inode | Журнал | Кэш | VFS | UUID | FUSE
Локальные: ext3 | ext3cow | ext4 | JFS | Reiser4 | XFS | ZFS | Btrfs | AdvFS | ISO | aufs
Сетевые: NFS | CIFS | AFS | POHMELFS
Кластерные: GFS | OCFS2 | CXFS | VMFS | GPFS
Распределенные: Lustre | PVFS | Ceph | Coda

* Btrfs, ZFS и AdvFS — это файловые системы с возможностями управления томами
Источник — «http://xgu.ru:81/wiki/dm-ioband»