Мифические тормоза диска на Xen

    Часто при обсуждении различных способов виртуализации, сторонники Virtuozzo (обычно, хостеры на OpenVZ) вспоминают про услышенное когда-то и где-то утверждение типа «Xen тормозит при работе с диском». Заблуждение это имеет корни, связанные с радикально отличающимися механизмами кэширования диска у виртуальных машин Xen и контейнеров Виртуоззо. Как следствие, сильно отличаются при различных условиях характеристики производительности дисковой системы. Но заблуждение оседает в сознании крепко и надолго.

    Чтобы закрыть тему «тормозов диска у Xen» и показать с цифрами, что тормозов нет, вот результаты unixbench, bonnie++ и упаковки исходников линуксовского ядра на одной и той же машине, на одном и том же разделе диска.


    Процессор: Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz. Диск — какой-то SATA Samsung.

    Native — замер на физической машине: 1 CPU, 256 Mb RAM. Kernel: 2.6.18-164.6.1.el5
    Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации: 1 CPU, 256 Mb RAM. DomU kernel: 2.6.18-164.el5xen. Dom0 kernel: 2.6.18-164.el5xen. Диск в виртуальную машину отдается как phy.

    Unixbench.


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

    Native

    File Copy 1024 bufsize 2000 maxblocks 3960.0 529094.5 1336.1
    File Copy 256 bufsize 500 maxblocks 1655.0 153098.5 925.1
    File Copy 4096 bufsize 8000 maxblocks 5800.0 1208281.0 2083.2


    Xen PV

    File Copy 1024 bufsize 2000 maxblocks 3960.0 542862.3 1370.9
    File Copy 256 bufsize 500 maxblocks 1655.0 153684.5 928.6
    File Copy 4096 bufsize 8000 maxblocks 5800.0 1212533.2 2090.6


    Жирным текстом выделены итоговые числа — чем больше, тем лучше. Видно, что на физическом железе, и в виртуальной машине, числа почти равны, в виртуальной машине даже немного больше. Казалось бы, нарушение закона сохранения энергии, но объясняется просто — небольшую часть нагрузки (около процента) принимает на себя подсистема ввода-вывода, которая находится снаружи виртуальной машины, в dom0 и выполняется на другом ядре.

    bonnie++


    Native

    Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
    Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
    Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
    dev.home 1G 575 99 64203 13 29238 5 1726 96 68316 6 144.5 1
    Latency 14923us 1197ms 483ms 60674us 16858us 541ms
    Version 1.96 ------Sequential Create------ --------Random Create--------
    dev.home -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
    files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
    256 47219 67 304464 100 23795 31 51813 73 378017 100 6970 9
    Latency 575ms 846us 673ms 416ms 22us 1408ms


    Xen PV

    Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
    Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
    Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
    CentOS_5_4 1G 815 99 65675 4 29532 0 1739 92 68298 0 134.1 0
    Latency 10028us 200ms 242ms 122ms 15356us 627ms
    Version 1.96 ------Sequential Create------ --------Random Create--------
    CentOS_5_4 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
    files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
    256 53015 61 325596 99 25157 23 58020 68 404162 99 6050 5
    Latency 605ms 771us 686ms 406ms 49us 2121ms


    Более разносторонняя оценка, но опять же, немного странный результат — в некоторых случаях опять Xen PV быстрее.

    Архивирование

    А можно посмотреть на результат нормальной, реальной задачи. Упаковка в архив* исходников ядра линукса — задача с интенсивным чтением диска. Суммарный размер — около 320 Мб, почти 24 тыс. файлов. Перед упаковкой дисковый кэш очищался через vm.drop_caches.

    Native
    $ time (find linux-2.6.26 | cpio -o > /dev/null)
    530862 blocks

    real 0m30.247s
    user 0m0.605s
    sys 0m2.411s


    Xen PV
    $ time (find linux-2.6.26 | cpio -o > /dev/null)
    530862 blocks

    real 0m32.396s
    user 0m0.052s
    sys 0m0.120s


    Разница во времени — чуть меньше 7%, достаточно обычный оверхед на виртуализацию. Это и есть та потеря производительности, которая распространяется на большинство паттернов работы с диском. Если у вас задача уперлась в диск, плюс или минус 7% существенно ситуацию не изменят.

    * Использовать cpio вместо tar приходится из-за того, что tar настолько хитроумен, что обнаружив вывод в /dev/null, он включает dry run и ничего не архивирует.
    TrueVDS
    37,00
    Виртуальные серверы с гарантированными ресурсами
    Поделиться публикацией

    Комментарии 33

      0
      Для полноты картины еще бы Virtuozzo сюда :)
        +4
        Это пока на VDS вы одни. Именно на это жалуются, подразумевая «тормоза» — что соседи тоже хотят iops, и побольше, побольше :)
          +1
          Всегда, когда есть соседи, они хотят iops — при любой виртуализации;)
          0
          Это не измерение а сферический конь в вакууме. В каком виде хранятся данные DomU в Dom0 и не указали какой драйвер используется в DomU для доступа к диску, работает ли DomU в HVM или нет. Я замечал проблемы с вводом-выводом при малом выделении памяти Dom0.
            +1
            > Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации: 1 CPU, 256 Mb RAM. Kernel: 2.6.18-164.el5xen

            Какой такой HVM?
              0
              Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации

              И? Какая версия ядра была использована внутри DomU? Какая версия ядра на Dom0? В каком виде предоставлялось блочное устройство DomU?

              Какой такой HVM?

              Аппаратная виртуализация. Была она использована или нет не указано. Не указано какая версия Xen используется. Не проведено тестирование с двумя виртуальными машинами.
                +1
                Вы слово «паравиртуализация» видите? Это исключает HVM. Это не аппаратная виртуализация, это модификация ядра гостевой ОС, так, что оно работает не в ring 0, а в ring 1. (userspace не меняется — как работало в ring 3, так и работает). Этот процесс модификации — портирование в Xen; именно поэтому портированы только открытые системы (напр. Linux).

                Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.
                  –2
                  Вы слово «паравиртуализация» видите? Это исключает HVM.

                  С какого перепуга? К примеру существуют паравиртуализационные драйвера для Windows и он работает именно в HVM.

                  Это не аппаратная виртуализация, это модификация ядра гостевой ОС, так, что оно работает не в ring 0, а в ring 1. (userspace не меняется — как работало в ring 3, так и работает). Этот процесс модификации — портирование в Xen; именно поэтому портированы только открытые системы (напр. Linux).

                  Извините меня, но кто вам сказал, что программная реализация будет работать быстрее и надежнее аппаратной? Термин «паравиртуализация» подразумевает знание виртуализируемой системы о том что она работает в виртуальной среде. Это может выражаться или в модификации ядра, чтобы система использовала API гипервизора или в использовании специальных драйверов ввода-вывода, так-как использование в виртуальной машине драйвера для реальных устройств добавляет «overhead».

                  Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.

                  Кстати говоря он таким является потому что раньше поддержки виртуализации небыло. К примеру KVM работает только при наличии аппаратной виртуализации.
                    +1
                    Вы в теме? Вы вообще понимаете, как Xen устроен и работает?

                    А то создаётся впечатление, что знаете только понаслышке.

                    > Кстати говоря он таким является потому что раньше поддержки виртуализации небыло. К примеру KVM работает только при наличии аппаратной виртуализации.

                    Мы про KVM говорим или про Xen? Да, KVM не умеет работать в режиме паравируализации, и ему это и не нужно — он как раз задумывался для того, чтобы использовать именно аппаратные возможности, которые к этому времени уже существовали.

                    Xen же задумывался как раз именно для паравиртуализации. Тогда не было никакой виртуализации, для запуска виртуальной машины нужно было имитировать CPU, что и является самой дорогостоящей операцией (представляете, весь абсолютно код сканировать и подменять некоторые инструкции?). В Xen виртуальные машины выполняются на реальных CPU, и заранее модифицированы так, чтобы вообще не было лишних инструкций, а все их функции заменены обращениями к гипервизору. Вот отсюда и его знаменитый малый overhead (по сравнению с полной виртуализацией).

                    > Извините меня, но кто вам сказал, что программная реализация будет работать быстрее и надежнее аппаратной? Термин «паравиртуализация» подразумевает знание виртуализируемой системы о том что она работает в виртуальной среде. Это может выражаться или в модификации ядра, чтобы система использовала API гипервизора или в использовании специальных драйверов ввода-вывода, так-как использование в виртуальной машине драйвера для реальных устройств добавляет «overhead».

                    Боже, как наивно. Конечно, паравиртуализация означает знание системы, что она не там есть что-то ещё. В HVM-режиме domU-система видит «как бы настоящие» CPU (именно этим занимается аппаратура), виртуальную эмулируемую шину PCI (какие бы драйверы не стояли!), и либо использует эмулируемые диски, сети и пр., либо через специальное эмулированное PCI-устройство «xenbus» (pci-id не помню наизусть) общается с гипервизором на предмет сетей, дисков и прочего. В Xen HVM гостевая система вообще всегда способна определить, что работает в Xen HVM, а не на bare metal, просто проверив наличие этого устройства.

                    В случае «полной паравиртуализации» с модифицированной гостевой ОС никакое специальное PCI-устройство xenbus не эмулируется. В этом режиме гостевая система видит сами настоящие CPU, вообще нет никакой шины PCI (если специально не сделать), а устройство xenbus — это прямое обращение к PV, просто вызов syscall (впрочем, как и для всех остальных устройств).

                    В общем, вы для начала просто сделайте и поиграйтесь с паравиртуальным линуксом, взгляните, что там, а потом и спорьте.
                      +1
                      Кстати и с аппаратной виртуализацией почти все устройства можно паравертуализовать, у kvm уже есть диск и сеть. Но по моим субъективным тестам, xen пока рвёт kvm.
                        0
                        А там собственно по сути и надо только диск и сеть. Как правило, если требуется работа с особо странным оборудованием, то это мультимедиа-оборудование. (1С не в счёт: HASP USB-ключики пробрасываются в Xen, на xgu.ru писали)
                          0
                          в kvm с пробросом USB и PCI устройств проблем тоже не возникнет. Как раз пару дней назад пробовал.
                        0
                        Он явно не в теме :)
                          0
                          Вы в теме? Вы вообще понимаете, как Xen устроен и работает?

                          Конечно. я знаю как он работает.

                          В Xen виртуальные машины выполняются на реальных CPU, и заранее модифицированы так, чтобы вообще не было лишних инструкций, а все их функции заменены обращениями к гипервизору. Вот отсюда и его знаменитый малый overhead (по сравнению с полной виртуализацией).

                          Извините меня, но overhead в KVM еще меньше так как нет переключения между гипервизором и dom0.

                          Боже, как наивно.

                          Да вы что?

                          Конечно, паравиртуализация означает знание системы, что она не там есть что-то ещё. В HVM-режиме domU-система видит «как бы настоящие» CPU (именно этим занимается аппаратура), виртуальную эмулируемую шину PCI (какие бы драйверы не стояли!), и либо использует эмулируемые диски, сети и пр., либо через специальное эмулированное PCI-устройство «xenbus» (pci-id не помню наизусть) общается с гипервизором на предмет сетей, дисков и прочего.

                          А в случае паравиртуализации у вас ВНЕЗАПНО нет CPU и устройств? Они никуда не деваются, просто путь попрямее.

                          В случае «полной паравиртуализации» с модифицированной гостевой ОС никакое специальное PCI-устройство xenbus не эмулируется. В этом режиме гостевая система видит сами настоящие CPU, вообще нет никакой шины PCI (если специально не сделать), а устройство xenbus — это прямое обращение к PV, просто вызов syscall (впрочем, как и для всех остальных устройств).

                          Вообще вызов syscall происходти следующим образом:
                          DomU syscall -> hypervisor -> Dom0 и только потом уже идет обращение к устройству. Причем виртуальное устройство в DomU ядре есть. В случае HVM и отсутствия паравиртуализационного драйвера путь длиннее
                          DomU -> hypervisor -> Dom0 (эмуляция устройства ) -> Dom0 (доступ)
                          В случае если у нас есть паравиртуализационный драйвер то путь выглядит так:
                          DomU -> hypervisor -> Dom0
                          т.е. приходим к тому что имеем выше.

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

                          Извините, но я использовал и Xen и с HVM и без HVM, и KVM, а так же OpenVZ и lxc. Так что давайте вы четко распишите что и как было сделано, а потом будете возмущаться. Опять же вы тут мифические тормоза диска в Xen не развеяли. Если вы сходите и почитаете когда они возникают, то увидите что большинство этих жалоб касаются HVM. И я считаю использование HVM и паравиртуализированных драйверов более перспективно нежели использование модифицированных ядер. Этому есть причины:
                          Переключение контекста происходит в любом случае.
                          Аппаратная виртуализированая среда обеспечивает лучшую изоляцию и быстродействие.
                          Не требуется модифицировать ядро, что позволяет запускать те операционные системы, что не могут быть подвергнуты модификации.
                            0
                            Добрый день, у меня есть вопрос к специалисту, у меня возник вопрос виртуализации серверов телефонии, телефония плого работает в виртуальном пронстранстве из за отсутствия точного источника часов «Timer source» оно служит для синхронизации голоса от разный источников, например при конференции, если таймер прохой голоса выходят из «фазы» и получается дисторсия, у меня есть такие ключики Usb которые можно воткнуть в систему дла точного тайминга, а можно ли один ключик распределить на все виртуальные машины?
                  –4
                  Тест без графиков — негодный тест. Нужны графики замеров на ovz и xen, чтоб визуально сравнить.
                    0
                    Ну, поясните, какие графики — зависимость чего от чего имеется ввиду?
                      0
                      Например, от количества соседних виртуальных машин, постоянно выполняющих дисковые бенчмарки.
                    0
                    Вы же запускали тесты «в одно лицо»?
                    Запустите 10 гостевых систем и одновременно запустите в них тесты.
                      0
                      Зачем? И так понятно, что 10 гостей замедлят друг друга. Если запустить в native OS десять dd, читающих диск, или запустить в 10 гостях по одному такому dd, они будут тормозить друг друга в обоих случаях, вне зависимости от наличия Xen.

                      Тест проверял только то, сколько теряется именно на самом Xen, как прослойке между виртуальной машиной и физическим диском.
                        0
                        Часто при обсуждении различных способов виртуализации, сторонники Virtuozzo (обычно, хостеры на OpenVZ) вспоминают про услышенное когда-то и где-то утверждение типа «Xen тормозит при работе с диском»

                        Может быть, стоило тестировать по 10 гостей в XEN и OpenVZ?
                          0
                          Может быть и стоило бы. Этот тест проверяет оверхед по сравнению с нативной ОС, показывает 7% и мне этого достаточно. Не думаю, что OpenVZ покажет лучший результат, чем нативная ОС и из-за этого оторвется от 7%. Поэтому сравнение с OpenVZ мне не настолько интересно, чтобы тратить время еще и не тестирование его. Но если это сделаете вы, я с удовольствием посмотрю результаты.
                      0
                      Попробуйте с PV ядром гостя, производительность относительно HVM либо не изменится, либо увеличится. Разница там около пары процентов, но, думаю, поймать на кучке тестов можно.
                        0
                        Оу, не заметил, что было изначально PV.
                        0
                        Нормальный тест должен выполняться так: ставим XEN, запускаем одну машину, две машины, и 10 машин и меряем в трёх вариантах. Потом на ту же машину ставим OpenVZ, и повторяем тест. Это даст результат. А измерение в идеальных несуществующих в природе условиях даст непонятно кому полезные данные.
                          –1
                          Для фулл- в этом случае должен быть подобран оптимальный шедулер в хосте, а для пара- просто одинаковые ведра у гостей.
                            0
                            А чтобы провести тест что надо сделать? Ответ прост — надо провести тест.
                          –1
                          в Ксене видел проблемы с дисками не на линейном чтении блоками, а на конкурентности.
                          попробуйте читать в 5 потоков в ядре ксена и без него. в ксене iowait будет 100% и ввод/вывод и вообще система у меня тормозится. без ксена все ок
                            0
                            Хабравчане юзающие xen, как может прокомментировать эти ссылки:
                            www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf
                            www.fridu.org/hosting/52-openvz-virtualization
                              +1
                              Здесь ксен и опенвз ставят на одну ступеньку, меж тем это цели у них немного различны. OpenVZ замечательно подходит для массового хостинга, не забирая лишних ресурсов, правда, там есть ограничения, упомянутые по ссылкам — нет полноценного управления машиной в смысле классического ребута или шатдауна, минимальный уровень абстракции — фс, а не голый диск, такая модель очень хороша, когда вы хотите воткнуть впс и запустить на нем кучу обычных сервисов. Xen применим в тех случаях, когда а) нужно использовать свое ядро или полную виртуализацию б) для более гибкого управления, когда всему domU выделяется один lv в виде физ. диска и он делает с ним что хочет + возможность ребутов. Ксен обеспечивает такую штуку, как живая миграция, благодаря которой его можно использовать в отказоустойчивых системах. Я применяю следующую схему: common xen pv -> common xen vg > много uniquie xen domain lv -> pv -> uniquie xen domain vg -> lv (разделы)
                                0
                                Не совсем понял про схему. vg и lv это про lvm-разделы и pv-в смысле домен в паравиртулизации?
                                  0
                                  Может еще по-этому подскажите community.livejournal.com/ru_root/1924149.html не могу с vlanaми разобратся.
                                    +1
                                    Отвечу сразу по двум вопросам: lv, vg, pv в строчке выше — logical volume, volume group и physical volume группы LVM. Двухслойный пирог необходим для следующего: я подключаю iscsi диск к машине, с которой производится миграция, делаю vgextend vg второго уровня на этот диск, затем pvmove physical vol. второго уровня туда (без разницы, на какой уровень, это временное хранилище, по-хорошему, опять же на второй), переносятся все разделы в онлайне, потом vgreduce локального pv, далее на целевой машине подключаю тот же iscsi и запускаю горячую миграцию — поскольку пути к блочным устройствам не менялись, использую тот же конфиг. Далее создаю такой же уникальный lv, как был на первом, завожу в нем pv, расширяю vg на iscsi на него, делаю pvmove && vgreduce как в первой части, только уже на локальный диск. Плюс такой схемы, в отличие от валяющихся в сети, в том, что она может использовать конечной точкой не iscsi target, а физ. диск той машины, на которой будет исполняться виртуалка.

                                    Про вланы и мосты — я после довольно большого опыта работы с ксеном считаю, что всю настройку сети, отличную от создания одиночного бриджа, следует производить в оси, а гости подключать к уже существующим бриджам, то есть, следует создать нужный набор вланов и лепить их в бриджи самописным скриптом и уже в конце цеплять к ним гостей.

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

                              Самое читаемое