Хостинг Вашего Успеха с 2006 года.
35,70
рейтинг
10 января 2014 в 15:10

Разное → Контейнеры — это будущее облаков

Ола, Хабрасообщество!

Введение


Данный доклад изначально был подготовлен для выступления на конференции компании FastVPS ROCK IT 2013, прошедшей 24-25 августа 2013 года в Городе Tallinn, Estonia.

Возможно, кто-то слышал его лично (спасибо!), но все равно рекомендую ознакомиться, так как данная публикация является более подробной и рассматривает намного больше опущенных в докладе деталей (smile)

Публикация имеет целью провести краткий обзор имеющихся на рынке open source средств для развертывания нескольких виртуальных окружений на базе физического сервера с Linux на борту, а также рассказать о преимуществах использования контейнеров для создания облаков :)

Open source решения на базе Linux для создания виртуальных окружений


Встречайте героев сегодняшнего рассказа!





Поименно:
  • KVM
  • Xen
  • Linux VServer
  • OpenVZ
  • LXC (Linux Containers)

Таблица: сравнение имеющихся технологий для реализации виртуальных окружений в Linux



Хотелось бы отметить, что Oracle VirtualBox был не включен в таблицу осознанно, так как не является полностью открытым, а в статье мы рассматриваем только открытые технологии.

Данная таблица позволяет легко сделать выводы, что готовых для промышленного использования технологий на сегодняшний день всего три: KVM, Xen и OpenVZ. Также очень активными темпами развивается технология LXC и по этой причине мы просто обязаны ее рассмотреть. Все четыре технологии в свою очередь реализуют два подхода к изоляции — полная виртуализация и контейнеризация, о них мы и поговорим.

Полная виртуализация


Давайте отойдем от сугубо теоретических описаний и посмотрим наглядную схему на примере KVM.



Как Вы видите, у нас имеется три уровня:
  • Аппаратное обеспечение (Disk, NIC, CPU, Memory на изображении — система хранения, сетевые устройства, процессор и память)
  • Linux ядро (совершенно любое, из любого более-менее современного дистрибутива, но рекомендуется 2.6.32 и выше; для определенности назовем его HWN, HardWare Node)
  • Виртуальные машины (клиентские ОС), работающие как обычные процессы в Linux системе рядом с обычными Linux демонами

Все взаимодействие здесь довольно прозрачно — базовое ядро Linux (HWN) взаимодействует с железом (процессор, память, ввод-вывод), и в свою очередь обеспечивает возможность работы процессов, в которых и крутятся с помощью специального модуля ядра полноценные ядра Linux, FreeBSD или даже Windows. Стоит обратить внимание, что это не совсем обычные процессы, работа виртуальных машин обеспечивается посредством модуля ядра (KVM) осуществляющего трансляцию системных вызовов из клиентской операционной системы к HWN. Данное описание работы нельзя считать полностью корректным, но оно полностью передает смысл данного подхода.Самое важное на что стоит обратить внимание, что трансляция из вызовов клиентской ОС в вызовы HWN осуществляется с помощью специальной технологии процессора (AMD-V, Intel VT).

Недостатки данного типа изоляции сводятся к дополнительным задержкам в работе дисковой подсистемы, сетевой подсистемы, памяти, процессора из-за использования дополнительного аппаратно-программного слоя абстракции между реальным железом и виртуальной средой. Силами различных технологий и подходов (например, программный virtio, аппаратный VT-d) эти задержки сводятся к минимуму, но устранить их полностью не удастся никогда (разве что виртуализацию встроят в железо) по причине того, что это дополнительный слой абстракции, за который нужно платить.

Затраты на реализацию полной виртуализации


Согласно недавним исследованиям IBM оверхед (это разница между производительностью приложения внутри виртуального окружения и того же приложения работающего без использования виртуализации вообще) технологии KVM при вводе-выводе составляет около 15% при тестировании на SUSE Linux Enterprise Server 11 Service Pack 3.

Также есть очень интересное тестирование, представленное в Journal of Physics: Conference 219 (2010), в котором озвучиваются цифры: 3-4% оверхед для процессора, и 20-30% для дискового ввода-вывода.

В это же время в презентации RedHat за 2013й год озвучивается цифра в 12% (то есть 88% производительности конфигурации работающей без виртуализации).

Разумеется, эти тесты проведены в разных конфигурациях ПО, для разных паттернов нагрузки, для разного оборудования и я даже допускаю, что часть из них проведены некорректно, но суть их сводится к одному — накладные расходы (оверхед) при использовании как KVM, так и Xen достигают 5-15% в зависимости от типа используемого по и конфигурации системы. Согласитесь, немало?

Контейнеризация


Поступим аналогично, воспользуемся иллюстрацией.



Сразу хочется оговорится, что все сказанное ниже справедливо как для OpenVZ, так и для LXC. Эти технологии очень и очень похожи и являются крайне близкими родственниками (эту тему я постараюсь раскрыть в следующей своей публикации).

Хоть и изображение нарисовано в немного ином стиле, сразу же бросается в глаза ключевое отличие — ядро используется лишь одно и никаких виртуальных машин (VM) нет в помине! Но как же оно работает? На низком уровне все происходит аналогично — Linux ядро HWN взаимодействует с аппаратным обеспечение и выполняет все запросы, касающиеся обращения к аппаратной части, из виртуальных окружений. Но как же виртуальные окружения отделены друг от друга? Они отделены с помощью встроенных в Linux ядро механизмов!

В первую очередь это видоизмененный аналог chroot (видоизменения касаются в первую очередь защиты, чтобы не было возможности вырваться из chroot'нутого окружения в корневую файловую систему), который всем нам хорошо знаком, он позволяет создать изолированные друг от друга иерархии внутри одной файловой системы. Но chroot не позволяет, например, запустить свой собственный init процесс (pid 1, так как на HWN уже существует init процесс с данными PID), а это обязательное требование, если мы хотим иметь полностью изолированную клиентскую ОС внутри контейнера. Для этого используется механизм PID namespaces, который внутри каждого chroot окружения создает полностью независимую от HWN систему идентификаторов процессов, где мы можем иметь свой собственный процесс с PID 1 даже если на самом сервере уже запущен init процесс. В общем случае, мы можем создать сотни и даже тысячи отдельных контейнеров, никак не связанных друг с другом.

Как же при этом ограничивается память, нагрузка на процессор и жесткий диск? Они ограничиваются также посредством механизма cgroups, который, к слову, также используется и для точь-в-точь тех же самых целей в технологии KVM.

Затраты на реализацию контейнеризации


Как мы обсуждали ранее, любая технология изоляции имеет оверхед, хотим мы этого или не хотим. Но в случае контейнеризации этот оверхед ничтожно мал (0.1-1%) за счет того, что используются очень простые преобразования, который зачастую можно объяснить буквально на пальцах. Например, изоляция PID процессов и пространств сокетов осуществляется посредством добавления дополнительного 4-х байтного идентификатора, обозначающего, к какому контейнеру принадлежит процесс. С памятью все немного сложнее и происходит ее определенная потеря (из-за особенностей выделения памяти), но на скорость выделения и работы с памятью это почти не влияет. С дисковой системой и подсистемой ввода вывода ситуация аналогична. В цифрах оценки оверхеда для OpenVZ приводятся в работах — инженеров HP и исследователей из Университета Бразилии для HPC и они находятся в районе 0.1-1% в зависимости от типа нагрузки и методики тестирования.

Контейнеризация против виртуализации


Вот мы и подошли к теме заявленной в самом начале! Мы обсудили оверхед технологий полной виртуализации и технологий контейнеризации, теперь самое время сравнить их напрямую между собой. Обращаю внимание, что в некоторых тестах вместо OpenVZ используется его коммерческая версия PCS, это имеет минимальное влияние на тесты, так как ядро используемое как в открытой, так и коммерческой ОС полностью идентично.

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

Я довольно долго думал как этого добиться и мне в руки попался чудесный документ, в котором KVM, XEN и OpenVZ/PCS тестируются на основе тестовой методологии разработанной компанией Intel — vConsolidate, а также стандартизированного LAMP теста, что позволяет проверить все результаты в домашних условиях и убедиться в их истинности.



Так как данный тест сугубо в попугаях, я не стал приводить его промежуточных графиков и вывел итоговые результаты. Как можно видеть — преимущество OpenVZ на лицо. Разумеется, компания Intel учла многое в своем тесте, но все же очень сложно интерпретировать эти цифры.

Поэтому предлагаю более понятный LAMP тест, из того же документа от Parallels, он тестирует производительность LAMP приложения в зависимости от числа запущенных виртуальных окружений:



Тут все намного понятнее и четко виден почти 2-х кратный прирост в суммарном числе транзакций выполняемых LAMP приложением! Чего же еще можно пожелать? :)

Разумеется, можно было охватить еще больше тестов, но, к сожалению, мы итак сильно вышли за рамки типовой Хабра-статьи, поэтому милости прошу вот сюда.

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

Контейнеризация — это будущее облаков!


В данной статье мы попробовали доказать, что эффективность использования аппаратных ресурсов при использовании контейнеризации вместо полной виртуализации позволяет экономить до 10% (мы берем среднюю оценку) всех вычислительных ресурсов сервера. Довольно сложно судить в процентах, намного проще представить, что у Вас было 100 серверов и они решали некую задачу с использованием полной виртуализации, то внедрив контейнеризацию можно освободить почти 10 полноценных серверов, которые потребляют много электричества, занимают место (которое стоит очень дорого в случае современных ЦОД), стоят сами по себе много денег, а также требуют персонала для их обслуживания.

Как же уйти от абстрактных «дорого» к реальным цифрам? Наиболее весомую экономию нам дает экономия на электричестве. Затраты на электричество, по данным Intel, составляют почти 10% всех операционных затрат на эксплуатацию Дата Центров. Которые в свою очередь, по данным Агентства Защиты Окружающей среды, US EPA, потребляют суммарно почти 1.5% всего электричества вырабатываемого в США. Таким образом, мы не просто экономим средства компаний, но и вносим значительный вклад в сохранение экологии за счет меньшего потребления электричества и более эффективного его использования!

Также стоит отметить, что самые крупные системы вычислений в мире — собственные облака Google, Yandex, Heroku и многих-многих других построены именно с использование технологии LXC, что еще раз доказывает преимущество контейнеризации в облачных вычислениях и показывает на примере реальных компаний.

Кроме того, обе озвученные технологии контейнеризации — OpenVZ и LXC имеют свободные лицензии и крайне активно развиваются и LXC (пусть, частично) есть на почти любом Linux сервере установленном в последние год-полтора. Открытые лицензии и активное сообщество разработчиков — залог успеха технологии в ближайшем будущем.

В ближайших публикациях мы остановимся на технологиях OpenVZ и LXC, а также обязательно проведем их сравнительный анализ :)

Update, продолжение серии публикаций:
  • Контейнеризация на Linux в деталях — LXC и OpenVZ. Часть 1


Отдельно хотелось бы поблагодарить Василия Аверина (Parallels) за объяснение особо сложных аспектов технологии LXC.

C уважением, Павел Одинцов
CTO FastVPS LLC
Автор: @pavelodintsov
FASTVPS LLC
рейтинг 35,70
Хостинг Вашего Успеха с 2006 года.

Комментарии (125)

  • +4
    LXC — это уже имя собственное. На сколько мне известно Google использует свою реализацию контейнеров.

    «видоизмененный аналог chroot» — это mount namespace для LXC и по историческим причинам своя реализация для OpenVZ. Для изоляции сети, IPC, UTS так же используются соответствующие пространства имен.

    Из свободных реализаций так же можно упомянуть unshare, nsenter из util-linux, systemd-nspawn.

    Ну, и не плохо было бы описать недостатки контейнеров.
    • +5
      Спасибо за дополнения! По mnt-namespaces сходу документацию найти не удалось, сейчас исправим этот момент.

      Недостатки контейнеров (как OpenVZ, так и LXC) я, честно говоря, заготовил на следующую статью, их нужно предметно обсуждать и объяснять, как обойти каждый :)
      • +2
        Тогда ждем. Пишите скорее!
        • +1
          Спасибо за интерес, буду писать еще быстрее, статья планируется тоже очень массивная.
  • +3
    Будущее облаков — это когда пофигу на чём работают инстансы. И на сами инстансы пофигу, важно только чтобы вовремя спанились.
    • +2
      Во многом благодаря таким проектам как CoreOS, OSv мы движемся к этому. Но еще очень-очень многое стоит сделать, пока это станет явью. Самые большие проблемы со стороны дистрибутивов и дистрибуции (имеются в виду образы для установки) в целом.

      Мы уже буквально 4 года мигрируем виртуальные окружения между Xen, KVM, OpenVZ и bare metal во всех мыслимых направлениях, но делается это все вручную, часто через даунтайм (малый, но все же) и не сказать, что особо надежно, каждый раз что-то приходится модицифироваться из-за той или иной фичи системы изоляции.
  • +2
    Xen в ядре Linux 3.* поддерживается в качестве Dom0: wiki.xen.org/wiki/Dom0_Kernels_for_Xen для подтверждения. Или имелось что-то другое?
    • +1
      Спасибо за вопрос, постараюсь расшифровать, что имелось в виду.

      Dom0 — это тоже клиентская VM по своей сути, только для управления виртуализацией.

      Что Dom0, что DomU все равно работают поверх гипервизора Xen, который к Linux отношение имеет весьма отдаленное и не поддерживается в контексте kernel.org. Отсюда и не совместимость с железом, на котором отлично работает чистый Linux.

      Про это очень хорошо написано вот в этой публикации: chucknology.com/2012/02/02/kvm-is-linux-xen-is-not/
      • 0
        Спасибо, почитаю.
      • +1
        Прочёл. Это описание очень старое и связно лишь с 3.0. Если я правильно понял, там написано, в картинке xen после 3.0 и три части: DomU, Dom0 и гипервизор? Я всегда думал, что гипервизор в Dom0. Ещё там было сообщение о pv-ops. Кажется, это вновь переписанная часть Xen, чтобы иметь возможность добавить в майнстрим. Если мне не изменяет память, OpenSuse до сих пор форвардпортирует xenlinux из 2.6.18, в обход pv-ops.
        • 0
          Не, в том и дело, что гипервизор сам по себе. Вот посмотрите актуальные слайды от разработчиков Xen: www.xenproject.org/developers/teams/hypervisor.html на 12 странице:



          Я честно говоря не особый спец по Xen, но все было примерно так:

          1) Изначально DomU (клиентские виртуалки) требовали модицифированного Linux ядра. Это было исправлено путем патчей в ядро, они вошли в основное ядро и модификация более не потребовалась
          2) Изначально Dom0 также требовал модифицированного/патченного Linux ядра. Это требовалось даже когда DomU уже не требовали модификации
          3) Теперь ни для Dom0, ни для DomU никаких телодвижений не требуется (в слуае новых ядер), но все равно это дело крутится поверх гипервизора, имеющего совершенно отличню от Linux архитектуру.

          А вот по поводу паравиртулизации вряд ли что скажу, не работал.
          • +3
            Немного добавлю:
            Все верно, XEN работает уровнем ниже чем ядро операционной системы (т.е. является гипервизором первого типа), причем XEN появился раньше чем в x86 появилcя VT-x (кстати по этому поводу в таблице не совсем правильно написано). Данный режим работы был назван паравиртуализацией. Если коротко, ядро переносится в RING1(если x86) или RING3(если x86-64, как раз тот редкий случай когда еще один уровень привилегий был полезным), все привилегированные инструкции в ядре заменяются на гипервызовы, меняется код начальной загрузки, устанавливается механизм обмена сообщений между гипервизором и ядром. Вместо эмуляции устройств, XEN использовал собственный backend — frontend механизм. Такую модификацию необходимо произвести как в Dom0 так и в DomU. Грубо говоря, xen с точки зрения ядра является еще одной архитектурой. Такой подход позволил получить неплохую производительность виртуальных машин даже без VT-x, но естественно данный подход применим только для операционных систем с открытым исходным кодом.

            С появлением VT-x и аналогов у AMD в XEN появился режим аппаратной виртуализации HVM, который уже не требовал модификации гостевых ОС для работы. Однако поскольку эмуляция устройств является достаточно дорогой, то пришла необходимость в использовании паравиртуальных драйверов, для минимизации расходов на эмуляцию оборудования.

            Однако, на сегодняшний день, Dom0 должен быть паравиртуализован полностью (отсюда вылезают неприяные моменты на x86-64, вроде невозможности эффективно выполнять системные вызовы через syscall). Однако в сообществе XEN есть идеи как сделать dom0 аппаратно виртуализованным )))
            • 0
              Спасибо! Потрясающее описание! :) Но, к сожалению, табличка сделана картинкой и поправить ее сложно :( Так что оставим просто восстановление справедливости в комментариях.
  • +3
    Алоха, коллега.

    Первая же схема, которую вы привели, напомнила о том, как мы саппорту на пальцах объясняли как работает контейнер относительно ВМки. Не поленился, вытащил из откопанного дока картинку:

    Что же касается вопроса «за чем будущее» — не соглашусь что сугубо за контейнерами. Не смотря на на плюсы в виде производительности, сквозного управления с хост-машины и возможности ставить пакеты глобально с хоста же — контейнеры в силу технологии плохо дружат с другими типами осей. Если всю инсталляцию надо иметь под чем-нибудь одним (к примеру, кластер debian-серверов) — тогда, конечно, да. Если же задачи потребуют иметь группу машин на FreeBSD, да еще и, скажем, рабочие станции сотрудникам на виртуалках организовать — не избежать винегрета из гипервизоров (что вместе с винегретом из ОСей вызывает желание пойти и напиться). Либо, как в нашем с вами случае — можно ограничиться продажей только vps под linux, но тогда те же форексоизвращенцы пройдут к конкурентам.

    Потому я убежден — будущее за продуктами, сочетающими в себе разные типы виртуализации единовременно. Яркий пример — как раз PCS6, который на приведенных графиках отмечен. Тут вам и контейнеры и ВМки под любой ОСью и все в рамках однотипных хост-машин с одним и тем же продуктом. По-моему, прекрасно :)
    • 0
      А картинка не прикрепилась :(

      Да, PCS6 интересная в плане подхода штука, но мы от него используем только контейнеры, надобности в VM особенной не возникало, честно говоря, даже тесты провести руки не доходят. Аналогичный подход предоставляет Proxmox.

      Но проблема подобных решений, что все сделано сильно «по-разному». Здесь я имею в виду унификацию управления VM и контейнерами в одном инструменте. В свое время даже RedHat пыталась (вроде бы уже перестали) в libvirt совместить управление KVM, Xen с управлением OpenVZ, LXC, получалось это весьма отвратно. Контейнеризация даже на объектную модель (виртуальные сетевые, жесткие диски, виртуальные процессоры) полной виртуализации ложится крайне плохо и поэтому очень сложно скрещивать ужа с ежом. В Proxmox как раз так получается :(

      Если у кого и получится — это будет прорыв :)
  • –18
    Это ж насколько нужно… быть чтоб откинуть бесплатный VMware ESXI, Hyper-V, Virtualbox только потому-что они видите ли не открыли исходники. У меня тупой вопрос. А вы часто в эти исходники лезли? Может закладку от АНБ нашли? Весь код просмотрели? Давайте так же начхаем на Solaris Containers. Чото тоже не айсс. Вам дают лучшие!!! продукты даром!!! а вы лезете копаться в том за что все равно однажды придется платить. Можете минусовать, но все это напоминает историю с геями. Те тоже первоначально хотели равных прав. Им дали(эти коммерческие продукты сделали бесплатными). Потом они посмотрели что блин всем на них начхать и им захотелось особых прав(исходники). Только им тонко объяснили что они не правы. Тут так же. нужно то барзометр притормаживать. Если начали писать про бесплатное… так будь любезен не вставлять заепшие примечания типо «Хотелось бы отметить, что Oracle VirtualBox был не включен в таблицу осознанно, так как не является полностью открытым». А делайте полностью взрослый обзор.
    • –1
      Не люблю геев.
    • +4
      Вы ишите заговор там, где его нету — мы изначально сузили круг исследуемых технологий open source решения и только ими. VirtualBox отчасти является открытым решением, но часть их наработок требует установки бинарной версии, поэтому он и был исключен. Рассмотрение ESXi, Hyper-V и Solaris Zones, а также IBM System z не входило в изначальные планы :)

      Но, в ряде указанных мной источников, кто проводил тесты, есть много упоминаний ESXi, например и Hyper-V. Пройдитесь по ссылкам на PDF'ки, если интересно.

      Но я не обладаю компетенцией для написания обобщенного поста «сравнение всех-всех-всех» систем виртуализации :)
    • +4
      Но вообще — например, бесплатный ESXi (к слову, бесплатен он лишь до 32 гб озу, что сейчас весьма мало) откровенно проигрывает во многих тестах технологиям Xen и KVM.

      Так что если Вы обобщаете вопрос «Разве не за проприетарной виртуализации будущее?». Я могу ответить — нет, не за ней. Будущее — за открытыми, свободными и при этом качественными open source разработками.
      • +1
        У вас старая информация — VmWare ESXi не имеет больше ограничений на 32GB оперативной памяти.
        • 0
          Ого, круто! Спасибо за информацию! Помню как сначала объявили vRam до 8Gb, потом увеличили до 32Gb, а вот полное снятие ограничений, видимо, я пропустил.
        • –1
          Но это кажется не решает проблемы «бесплатно и коммерческое» использование.
          Hyper-V тоже есть в бесплатном варианте.
          • 0
            А есть какая-то проблема при коммерческом использовании ESXi?
            • 0
              Визуально пробежался по их условиям лицензирования и вроде никаких подводных камней нету.

              Но есть проблемы в том плане, что многие фичи, без которых жить почти нереально (бэкапы там, управление шаблонами и прочее) там недоступны, вот тут забейте www.virtualizationmatrix.com/ сравнение между ESXi hypervisor free и standard. К сожалению, прямую ссылку дать не могу, не нашел есть ли там вообще такая возможность.
              • 0
                Управление шаблонами из гипервизора и т.п. фишки гипервизора не нужны очень многим пользователям, т.к. у них обычно 1 или 2 сервера под виртуализацию. От гипервизора требуется только качественное выполнение его базовых функций. Все остальные вещи, типа бекапов, должны делать специализированные решения. Например бекапы прекрасно делаются средствами, типа veeam free edition (бекапит контейнеры машин) или bacula (бекапится содержимое машинок). А все фишки, которые есть в платных версиях, всё равно не доступны на бесплатных аналогах, которые представлены в данном обзоре.
                • 0
                  Честно говоря затрудняюсь ответить на вопрос предметно, но веб-интерфейса для управления виртуализацией и правда, пожалуй, никто из рассматриваемых игроков не предоставляет.

                  Я уверен, на Хабре будет очень полезен пост-обзор всех средств виртуализации, а не только открытых, которыми ограничился я.

                  Кто возьмется?
                  • 0
                    web интерфейс можно к virtualbox прикрутить sourceforge.net/projects/phpvirtualbox/ но это всё игрушки )
                    • 0
                      Мало того, у VirtualBox есть приличный cli-интерфейс, который даже работает :)
      • +1
        Можно ссылки на тесты?
        Просто я не могу поверить, что ставший почти стандартом инструмент для виртуализации ( исключая хостеров ) может «откровенно» проигрывать открытым технологиям.
        • +1
          Вот, пожалуйста: rhsummit.files.wordpress.com/2013/06/sarathy_t_1040_kvm_hypervisor_roadmap_and_overview.pdf

          Графики оттуда:

          И еще вот очень наглядный с процентами график оттуда же:

          Вот исследование от Parallels, там про их платформу, но есть и графики про KVM vs ESXi:
          www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pvc/whitepapers/Performance_Comparison_White_Paper.pdf

          Вот, пожалуйста:


          Вроде больше нету, но даже по графикам от RedHat можно четко сказать, что KVM сейчас сильнее ESXi. А контейнеры быстрее их обоих, но имеют ограничения.
          • 0
            Довольно странно видеть сравнение текущей версии KVM с древним ESXi 4.1, у которого уже наступил EOL.
          • 0
            Странные сравнения, мало того что сравнивают на разных серверах так еще сравнивают esx 4.1 с KVM.
            А я спрашивал про ESXi с KVM (на одинаковом железе)
            • 0
              Разные конфигурации лишь на первом графике, на втором сравнивается идентичное железо. Откройте pdf, там все описано подробно :)
            • +1
              есть нюанс — вмварь запрещает публикацию бенчмарков, если те не показывают их в позитивном свете. поэтому они не опубликовали тесты на 8 ядер вообще, а последний опубликованный спеквирт делали на 4.1, ДО того как стало понятно что через такой открытый тест можно будет делать сравнения в обход EULA. потом видать стыдно сталo, и они вообще перестали публиковать тесты, хотя проводятся они регулярно — спеквирт разрабатывался собственно вмварью с партнерами, чтоб показать систему в позитивном свете.

              так что объективное сравнение с вмварью найти очень трудно — оно или чисто маркетинговое, подстроенное под особые ситуации где из вмвари можно выжать больше чем из других систем, или просто не будет опубликовано.
              • 0
                Ого, какие интересные подробности! Все упирается в качественное проведение тестирование третьими лицами, до которых не доберется VmWare в случае проигрыша :)
                • 0
                  пока я во всем этом крутился, я просто предлагал клиентам провести тесты самим, разница иногда доходила до абсурда, причем не в пользу дорогих, закрытых решений
              • 0
                С этими ясно, но почему нет сравнения с Hyper-V? В последней версии допилили поддержку Linux, так что местами она превосходит VMware.
                И как насчёт TPC-VMS?
              • 0
                Что правда трудно? :)
                www.spec.org/virt_sc2013/results/specvirt_sc2013_perf.html
                • 0
                  конечно трудно, если выкладываются только причесанные, выбранные заранее результаты, а не чистый эксперимент сделанный независимым тестировщиком
                  • 0
                    Так, давай определимся что такое spec — классическая пузомерка но
                    1. Она требует опубликования использованого железа.
                    2. Она одинакова для всех.
                    3. Доступны подробные отчеты, что как конфигурировалось и как делалось.
                    При желании каждый желающий может повторить тест дома на кофеварке :)
                    Это блин один из самых объективный тестов, насколько тесты сами по себе могут быть объективны мы умолчим.
                    • +1
                      есть нюанс :) сколько таких спеков оказались не в пользу вмвари мы не узнаем никогда, они _разрешат_ опубликовать только те которые выгодны им. Все остальные ничем не ограничивают эти публикации, что приводит к изрядному дисбалансу в результатах, и заставляет сильно сомневаться в объективности данных результатов.

                      Если никто еще не догадался, вмварь сегодня это микрософт конца 90х — главный хищник в своей нише, доящий клиентов по максимуму, и не чурающийся любых методов. Это не хорошо и не плохо, это просто факт, и война за рынок идет нешуточная — сейчас не 90-е, и конкурентов хоть отбавляй. Пузомерки — это инструмент для маркетинга, и там где RHT и, кстати, даже майкрософт, не особо парятся насчет результатов — и у тех и у других достаточно аргументов в свою пользу, лояльных клиентов, и что самое важное — плюс полноценный стек от ОС до аппликаций, вмварь живет за счет виртуализации и ничего другого у них нет, так что для них каждая такая публикация критична.
                      • 0
                        Если никто еще не догадался, вмварь сегодня это микрософт конца 90х — главный хищник в своей нише, доящий клиентов по максимуму, и не чурающийся любых методов.

                        После смены CEO стало получше, но процесс разработки они так и не смогли построить… Ядром пока занимаются нормальные спецы, а вот вся обвязка написана рукожопыми индусами и не проходит QA, если судить по качеству конечных продуктов.
                        • 0
                          глубоко я вникал последний раз в 5.1, и после работы в RHT у меня просто руки чесались открыть баг на каждый глюк который я видел. Сотрудник вмвари который присутствовал при этом процессе чего-то мямлил о том что так и должно быть :)
                      • 0
                        Ну это так сказать дело вендора, публиковать и показывать или не публиковать и гнать булшит на презентахах.
                        Некоторые успешно совмещают оба подхода одновременно :)
                        Все остальные ничем не ограничивают эти публикации,
                        Остальные это кто? С опенсурсами все понятно, там нет возможности запрещать.
                        Оракл имеет такую же политику по апруву тестов их ВМ
                        Майкрософт тоже не одобряе честную конкуренцию.
                        В мире корпораций так принято. Так что не надо рассказывать какие остальные пушистые.

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

                        • 0
                          > Остальные это кто? С опенсурсами все понятно, там нет возможности запрещать.

                          там есть возможность доказать свою «белость и пушистость» делом — сделав на самом деле хорошо, так что не подкопаешься.

                          > Майкрософт тоже не одобряе честную конкуренцию

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

                          > В мире корпораций так принято. Так что не надо рассказывать какие остальные пушистые.

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

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

                          чушь. у вмвари и их папика ЕМС денег побольше будет.
                          • 0
                            Они потому в свое время и зимбру купили, и потому все давно ждут когда они Новелл захапают

                            Не совсем, Зимбру и Шавлика они купили когда у главного поехала крыша в качестве замены Exchange и System Center, тогда же начали продвигать vCenter под Linux. Сейчас эту хрень сплавили и развивают профильные направления.
                            • 0
                              они еще много чего купили — digital fuel (в котором я тогда чуть не оказался) например. Дело не в поехавшей крыше а в попытке набрать под крыло технологий, которые потенциально позволят развивать бизнес в дополнительных направлениях, Что не сработало
                          • 0
                            чушь. у вмвари и их папика ЕМС денег побольше будет.
                            Не, я к тому что объявляешь тендер, набигают интергаторы вендораторами и начинается цирк :) Результаты показательных метаний какашек и тестов на твоих задачах можешь хоть в переходах раздавать.
                            • 0
                              в частном порядке можно делаь что угодно, лишь бы публикаций не было. мы всегда так и работали — делали демо специально для заказчика
      • –8
        Боюсь для вас это будет шоком, а для меня очередным минусом к карме. Но я вам открою тайну. Open source это девушка легкого поведения. Она дает любому, лишь бы ей было бабло. И вот однажды… эта девушка находит богатенького папененьку и начхав на всех своих поклонников… продается ему с потрохами. Такова судьба любого сколь значимого проекта. Раздвинуть ноги чтоб заработать побольше.

        Вот как могут развиваться события:

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

        Есть и другие схемы чтоб сосать деньги с пользователей. К чему я веду? Да всё просто. За любой продукт нужно платить. Вы просто это не замечаете. Наиболее частая схема оплаты это обратная связь с пользователем. Который выступает тестером. Тратя время на борьбу с багами, их отловом, классификацией, решением… вы вносите свою плату за пользование продуктом. Продукт потом правят и продают уже коммерческую версию организациям. Но есть одна проблемка. При такой схеме всё меньше организаций готовы платить за эти продукты. Им нужна полная халява. А пользователь не готов тратить время на отлов багов. Жизнь не резиновая.

        Теперь к вопросу того что будущее за халявой. Боюсь что нет. =) Как бы вам попроще… объяснить. На данном витке истории мы занимаемся тем что переливаем ПО из пустого в порожнее. Это может делать даже школьник. Но уже сейчас!!! возникает проблема с кадрами. Точнее с уровнем специалистов. Нужны высококлассные математики которые рождаются раз в сто лет. Нужны гениальные кодеры для оптимизации кода. Нужны ресурсы для инвентаризации уже написанного. А на подходе квантовые компы и другие процессорные логики. Будет новый виток. Во главу таких компьютеров станут математики, которые будут пытаться извлечь максимальный кпд из них. Системы будут архисложными!!! Для того чтоб всё это развивать потребуется консолидация ресурсов. А все эти люди хотят регулярно кушать, а не на кикстарах по тысченке-другой выбивать. Начнется укрупнение уже имеющихся продуктов. Поглощение мелочи.

        Так что выводы делаем сами. Ах да… мы отвлеклись от нашей девушки легкого поведения. ЕЕ судьба проста.
        — она умерла от болезней на лечение которых не нашла деньги (болезни то все профессиональные)
        — ее спонсирует папик. который ее пялит в свободное время (АНБ к примеру =))
        — она умерла с голоду(ей бы шпалы носить, а не на панелях стоять).
        — она стала респектабельной дамой и чмырит всех тех с кем раньше работала вместе.
        — она начала мыть полы. так как на панели появились уже более симпотишные девушки и помладше.
        Но она не может стать нормальной семьянинкой!!! Ибо нормальные девушки зарабатывают по другому.

        Вот судьба открытого ПО. Очень мало кто работает в этой области для души. Большинство начинает с рассказов что он такой убогий и ему нужна поддержка пользователей. Потом монетизация и новый формат. Не люблю двуличия. Поэтому не люблю и все эти гнилые разговоры о опен соусе. Но при этом я уважаю тех кто реально работает за идею! Пусть даже в программе из 2000 строк. Но много ли таких найдется?

        p.s. Хотелось бы назвать еще одну причину почему все лучшие продукты платные. Юзабилити!!! Для того чтоб сделать хороший продукт… как все это известно… нужно не дать кодерам участвовать в разработке интерфейса. В коммерческом продукте нанимаются психологи, специалисты по юзабилити и прочие няшные профессии. Дабы они занимались тем с чем работает обычный юзверь. И в этих профессиях нет больных опенсоурс психологов, опенсоурс проектировщиков, опенсоурс дизайнеров. Такого нет в природе!!! Это противоестественно и не приносит денег. А значит свободное ПО не дотянет никогда до уровня коммерческого. ИМХО.

        А знаете к чему я всё это вел? Если тебе нравится секс, то трахайся с кем хочешь. Это твое право. И это твой кайф. Но если ты работаешь девушкой легкого поведения и это твоя профа… не корчи из себя мать Терезу. Признайся что это твоя профессия и что ты хочешь от нее как можно больше бабла(или просто чонибудь покушать). Признайся, не потом когда у тебя уже армия поклонников, а сразу. Будь честен с людьми и собой.

        В завершение у меня вот какой вопрос. Я хочу чтоб большинство из вас честно на него ответили для себя. Если бы лицензия опенсоурс была жоще. И запрещала любую из вышеописанных форм монетизации. Решились ли бы вы делать такой продукт? Я думаю я знаю ответ для 99% людей на хабре. Так кому после этого признания нужно сливать карму? =)
        • +2
          Ограничусь тем, что скажу, что в корне с Вами не согласен и искренее уверен, что будущее именно в open source виртуализации.

          Все возможные ситуации «кинут» / «закроют проект» / «продадутся» в случае KVM, Xen решились в итоге тем, что были созданы консорциумы из десятков компаний для поддержки и коллективного управления данными проектами.

          Для KVM это Open Virtualization Alliance, в который в свою очередь входят: Intel, HP, IBM, RedHat, NetApp, Intel, Acronis, AMD и прочие. (полный список тут)

          А для Xen это Xen Project, в который входят Amazon, AMD, Google, Intel, Samsung и прочи. (полный список участников тут)

          Про ядро Linux (то есть lxc в своей сути) я говорить даже не буду, честно говоря, там примерно такой же список в несколько тысяч компаний.

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

  • +2
    Спасибо за статью. А особое спасибо за указание ссылок на полезные исследования.
    Жду статью о недостатках контейнеров.
    • 0
      Вам спасибо за позитивный отзыв:) Статья будет не о недостатках, конечно же, а просто про OpenVZ и контейнеры из ядра.
  • +1
    При использовании KVM накладные расходы на сеть становятся заметно ниже при использовании vhost для сети. Я бы сказал, что это только расходы на поддержку сетевого моста и tap-устройства, то есть то же самое, что и в openvz при использовании veth.
    Для диска OpenVZ сейчас предлагает использовать ploop, у которого накладные расходы сравнимы с дисковыми накладными расходами от xen/kvm+virtio, так как принцип работы тот же.
    Пользовательский код выполняется что на kvm, что на openvz абсолютно одинаково без оверхеда (если не считать лишнего уровня косвенности при обращении к таблице страниц (но его почти убирает TLB) и возможных тонкостей с вытеснением нужной информации из кеша). Проблема остается только с системными вызовами, но тут у каждой из виртуализаций свои проблемы.
    Но KVM проще и обеспечивает больший уровень изоляции.
    • 0
      Честно говоря, я бы не сравнивал ploop и проброс блочного устройства/файла как диска виртуальной машины. У ploop есть ряд неоспоримых преимуществ — не нужно заботится о целостности файловой системы и беспокоится о fsck, также есть ploop compact, который может сжать излишне распухший образ диска до размеров файловой системы. Аналогов такой фичи, по моей инфорации, в KVM пока нет и есть лишь попытки частичной реализации этого подхода. Но и да — ploop не лишен проблем, но их я уточню в следующей публикации, потому что в двух словах сложно сформулировать да и без контекста будет не понятно.

      По поводу vhost — тут сказать ничего не могу, на скорость сети при использовании virtio даже без vhost на KVM мы вовсе не жаловались :)

      А вот про простоту KVM не согласен, на фоне virsh vzctl из OpenVZ просто мана небесная по части юзабилити и удобства — никакого XML и никаких странных огромных конфигов :)
      • +1
        По поводу фич Вы правы, подход, который разделяет управление дисковыми устройствами и виртуализацией, затрудняет реализацию таких вещей. Но если говорить о производительности, sparse-файл со своей ФС внутри явно проиграет проброшенному LV или блочному устройству.

        Под простотой я имел в виду внутреннее устройство. OpenVZ лезет почти во все подсистемы ядра, и переносить в осн. ветку эти воздействия начали относительно недавно. А чем больше объем системы, тем больше в ней ошибок. На ядре 2.6.18, которое совсем не использовало LXC, иногда возникали очень печальные баги (вроде проседания сети в 1.5 раза) даже без запущенных контейнеров, просто после перезагрузки в OpenVZ-ядро. Сейчас, как я понимаю, должно стать лучше.
        А XML это не минус, а плюс. Все равно при продаже VPS или облаков клиентам нужно писать им панель/биллинг, и тут перекидываться xml-ками с libvirt будет удобнее, чем текстом с vzctl.
        • 0
          Да, тут со всем соглашусь кроме медленности ploop. Но вот подкрепить свое несогласие мне, к сожалению, нечем :( Если кто-то из Parallels нас читает — может подкинете тесты ploop?

          Да, 2.6.18 вела себя странно во многих случаях. А с numa там вообще ад творился. Но в 2.6.32 все уже намного стабильнее, а в RHEL7 (ядро 3.2) будет вообще-вообще чудесно.

          Ничего личного, не люблю XML :) У KVM скорее преимущество в самом протоколе libvirt, мы в свое время отправляли свои патчи в libvirt-php, чтобы саспенд добавить, было очень удобно.

          Но мучения «как сгенерировать xml блок для активации вот такой фичи» иногда длились неделями и вынуждали делать это черещ virt-manager и потом разгребать что же за код он сконструктировал :)
        • 0
          Зачем текстом, можно в json формате. Ну и к libvirt есть модуль для OpenVZ.
          • 0
            В json формате можно только читать выдачу vzlist -j, а вот vzctl ни принимать, ни отдавать данные в json не умеет. Впрочем, мы тут сделали кое-что для решения этой проблемы, возможно, в скором будущем будут новости.

            Модуль libvirt для openvz на тот момент когда я его изучал (около 2х лет назад) не умел почти ничего кроме создания впски с заданным объемом диска/памяти, о рулеже vswap, вторичными UBC там и речи не было. Так что, к сожалению, тут libvirt пока не подходит для реализации задачи рулежа openvz.
      • +1
        У ploop есть ряд неоспоримых преимуществ… Аналогов такой фичи, по моей инфорации, в KVM

        QEMU не занимается хранением данных, за поддержку конкретного формата хранения или конкретной СХД отвечает драйвер (драйверов у QEMU штук 10, в том числе всякие под vmdk, ceph и прочие). Ну а sparse режим хранения поддерживают если не все, то большинство из них. Можно было бы написать драйвер, который поддерживает формат хранения ploop, другое дело непонятно кому и зачем это может понадобиться, т.к. ploop решает чисто контейнерные проблемы, которых в мире полной виртуализации нет (вернее проблемы есть, но и решений полно).
        • 0
          А ploop — это вовсе не sparse файл, вот тут даже откровенно говорится, что нельзя делать ploop файл spars'ным: openvz.org/Ploop/sparse

          Как раз в KVM очень остро (могу сказать лишь от лица провайдеров) стоит проблема с тем, что место выделяется не по мере заполнения, а сразу. То есть если нам нужен контейнер на 100 Гб, а в нем реально используется от силы 1-2 Gb в случае KVM он будет занимать сразу же 100Gb, а в случае ploop будет заниматься объем файловой системы + 10-20%, то есть около 2х гб.

          Для решения этого в KVM есть LVM thin provisioning, но для vzctl compact/ploop compact ему, на мой взгдяд, еще несколько лет в развитии да и вообще подход используемый в thin provision мне не нравится чисто архитектурно.
          • 0
            А ploop — это вовсе не sparse файл

            Я не говорил, что ploop это sparse файл. Я писал, что для решения вашей проблемы достаточно выбрать любой формат/СХД, которая поддерживает sparse хранение данных, то есть не аллоцирует нули при создании волюма.

            Как раз в KVM очень остро стоит проблема с тем, что место выделяется не по мере заполнения, а сразу.

            Еще раз: QEMU/KVM не занимается хранением данных в каком-то одном формате а имеет множество драйверов для различных форматов и систем хранения данных и оставляет вам возможность выбора. Поэтому проблема в данном случае исключительно ваша, причем такая, которую надо целенаправленно создавать, потому что в режиме по умолчанию (raw образ, хранимый в sparse режиме) этой проблемы нет. Возможно какие то ваши действия привели к аллокации нулей в образах, ну тогда сделайте над образами cp --sparse=always file1 file1_sparsed и все у вас будет ок.

            То есть если нам нужен контейнер на 100 Гб, а в нем реально используется от силы 1-2 Gb в случае KVM он будет занимать сразу же 100Gb, а в случае ploop будет заниматься объем файловой системы + 10-20%, то есть около 2х гб.


            Вот я создал 10Тб образ в дефолтном raw формате на разделе размером 8Гб. Что я делаю не так?

            root@node04:~# qemu-img create disk-image 10000000000000 Formatting 'disk-image', fmt=raw size=10000000000000 root@node04:~# ls -la disk-image -rw-r--r-- 1 root root 10000000000000 Jan 11 18:32 disk-image root@node04:~# df -H Filesystem Size Used Avail Use% Mounted on rootfs 12G 8.0G 3.1G 73% /

            • 0
              Ок, давайте для определенности спора (и более убедительного принятия преимуществ ploop) сформулируем методолгию.

              1. Аллоцируйте виртаульной машине 100 Гб
              2. Установите Linux ОС, допустим, она займет 1 Гб
              3. Залейте в виртуальную машину 99 Гб данных, чтобы диск на 100 Гб был забит полностью
              4. Удалите все 99 Гб данных, чтобы осталась только чистая ОС, то есть 1 Гб
              5. Сообщите, сколько места будет занимать образ диска данной виртуальной машины
              6. Любыми средствами без ребута машины и опасности для данных добейтесь сжатия образа хотя бы до 2-5 Гб вместо 100.

              В случае ploop пункты 5 и 6 будут такие:
              5. Образ будет занимать 100 Гб
              6. Запускаем vzctl compact или ploop compact и без даунтайма, повреждений фс сжимаем объем образа до объема файловой системы, то есть до где-то 1 Гб (+ 10-15% за счет накладных расходов)

              В случае же KVM вы будете хранить 99 Гб до скончания веков даже если клиент/разработчик/сотрудник никогда не будет ими пользоваться.
              • 0
                С qcow можно сделать через заранее приготовленный костыль:
                — имеем 1 qcow образ, над ним vg, там допустим полностью зааллоцированный /,
                — дискардим байтики в /, подключаем новый образ того же размера, перевозим vg на него,
                — отключаем-подключаем первый, предварительно пересоздав,
                — перевозим vg обратно и отключаем и удаляем своп-диск.
                Все это применимо к virtio-pci/virtio-scsi/scsi в случае qemu.

                Немного непонятны причины того, что а) я заранее не предусмотрел отдельное отключаемое блочное устройство на этот случай, б) не могу выключить машину, на мой взгляд, это честная плата за возможность дискарднуть в онлайне без подготовки, в) cow образ вряд ли будет показывать хорошие результаты по производительности, вне зависимости от вендора.
                • 0
                  Тут позвольте дополнить — чем именно дискардить байтики. Есть чудесная тулза от GuestFS: http://libguestfs.org/virt-sparsify.1.html

                  Конечно, хотелось бы получить такую фичу нэтивно где-нибудь в Qcow 3, чтобы избежать подобных комплексных операций.
                  • 0
                    Ну можно использовать zerofree или ддшнуть+удалить файл с нулями в фс гостя. В целом кейс очень редкий, поскольку либо можно использовать энтерпрайз хранилище и thin provisioning(о маргинальных вариантах типа lvm для тех же целей лучше не упоминать), либо просто смириться — такие случаи будут редки, оверселлить хранилище в случае qcow образов вы всяко сможете многократно, плюс этот компакт даст со стапроцентной вероятностью усаживание характеристик блочного устройства гостя как минимум на порядок.
                • 0
                  Я правильно понимаю, что это все через даунтайм? В ploop сжатие онлайн.
                  • 0
                    Нет, в онлайне. С даунтаймом можно воспользоваться либо компакшеном у vdi, либо дискардом + копированием в случае qcow.
              • 0
                А давай вспомним еще simfs (фича OpenVZ, чем-то похожа на sub-volume в btrfs). Там ваша задача места просто отсутствует, т е там нет накладных расходов по месту бай дизаин.
                • 0
                  Кстати, получается, что vzfs в mainline — это mnt namespace + доп фичи?
                  • 0
                    vzfs отдельно, изоляция файловых систем отдельно. vzfs — это кеширование файлов между контейнерами + квота. simfs — только квота.
                    • 0
                      Так кэширования в openvz не было никогда, это просто платформа для его реализации?
                      • 0
                        Ты хотел сказать vzfs в OpenVZ не было никогда;)
                        • 0
                          Ну, в документации simfs вы зовете vzfs kb.parallels.com/en/119015 =)
                          • +1
                            Нет, там про vzfs говорят. Там же об Virtuozzo речь.
          • 0
            вот это уже очень странно, на фоне грамотного обзора. KVM во первых вообще к форматам дисков никак не относится, а QEMU поддерживает множество форматов, многие из которых «тонкие»
            • 0
              Почему странно? Ведь, когда речь идет о KVM/Xen/OpenVZ обычно всех интересуют не чистые абстрактные характеристики конкретно слоя виртуализации, но и весь стек, то есть и система хранения в первую очереь.

              Если уж совсем рассматриваться формально, К OpenVZ ploop тоже не сильно относится — это тоже только один формат хранения, так как можно использовать и ploop и simfs и даже обычные блочные (и, конечно же, LVM) разделы.
              • 0
                вот в том-то и дело, KVM — часть линукса, и работает на любом хранилище которое поддерживает линукс, вплоть до совсем экзотичных (morgan-stanley например, емнип на AFS гоняют несколько тысяч хостов)
                • +1
                  Так и lxc и OpenVZ работают точно также! Диск контейнера на OpenVZ — это всего-лишь папка в файловой иерархии Linux, не более того.

                  А папка может быть и примонтированной флешкой, и iSCSI устройством размещенным за тысячи километров, и сложным проприетарным СХД и еще тысячей других вариантов реализации СХД.

                  То есть тут получается гибкость ровно на том же уровне, как и у KVM. Но, разумеется, не без ложки дегтя. Взять и подключить блочное устройство к контейнеру «совсем красиво» (под этим я подразумеваю поддержку такой фичи в официальной поставке) нельзя, нужно его грамотно монтировать через спец-скрипты.
                  • 0
                    Это все про simfs. У ploop-а есть ограничения. Он работает только на ext4 и nfs. В скором времени и эти ограничения будут сняты.
                    • 0
                      Почему? Я как раз описывал вне контекста ploop/simfs, ведь /vz/CTID/root — это лишь точка монтирования и не более, будь то simfs, будь то ploop или что-то третье.
                      • 0
                        Да, все верное. Просто ploop — это фича OpenVZ и я уточнил.
                  • 0
                    отлично, значит в плане фичеров на уровне хранения данных разницы нет, так?
        • 0
          ploop — это loop девайс «нового поколения». Через некоторое время он (или почти он) появится в мейнстримном ядре. У него нет двойного кеширования, он поддерживает разные форматы дисков, есть возможность делать снапшоты.
          А вот формат дисков — это уже другое. По понятным причинам OpenVZ использует формат, который используется для виртуальных машин в PCS. Этот формат по фичам и структуре аналогичен форматам используемым в KVM, т е ваше рассуждение о проблемах связанных с форматами в корне не верное. Проблемы в этом месте у всех одинаковые.
          • 0
            А чем ploop будет отличаться от выброшенного в систему хоста с помощью qemu-nbd qcow2 образа по функциональности и производительности?
            • 0
              * будет быстрее, просто потому что nbd не очень быстро работает.
              * qcow2 очень похож на формат ploop-а. Какая функциональность вам интересует. ploop формат поддерживает снапшоты, балунинг, умеет сжиматься, расширяться. Мог что-то забыть.
              • 0
                То есть, за исключением возможности эскпозиться в хост, что актуально только для чрутов/контейнеров, плуп не отличается от существующих форматов CoW? Ballooning подразумевает онлайн расширение-сжатие?
                • 0
                  Да, подразумевает сжатие и расширение наживую. Но лишь для ext4, разумеется, используется обычный resize2fs.
                  • 0
                    Для ресайза вниз в онлайне вешаются хуки или это не возможно все же?
                    • 0
                      Через балун возможно. Балуном рулят снаружи (из хоста).
                      • 0
                        Мм, а как это согласуется с возможностями ext4? Понятно, что гостю можно послать нотифай об изменении геометрии, но обойти ограничения фс тривиально нельзя.
                        • 0
                          OpenVZ использует кастомное ядро. Балун — это файл на файловой системе, которые видно не всем. Ну и когда показывают статистику по файловой системе, берут во внимание размеры этого файла. Т е надули балун на 1Gb, объем файловой системы на 1Gb сократился. Это как KVM балун для памяти, только для диска.
                          • 0
                            А, то есть это не характеристика блочного устройства, а просто эквивалент control group. Спасибо за пояснение, я подумал, что это неведомая ракетная наука.
                  • 0
                    Чет я не понял, о чем это ты. Есть расширение и сжатие через балун, а есть через средства файловой системы.
  • 0
    Еще одна opensource VM это Proxmox. вроде бы вполне интересная, если у когото был опыт интересно было бы почитать о минусах.
    • +2
      Proxmox – это оркестровка, под капотом там те же KVM и OpenVZ.
      • 0
        Да, у них используется почти стандартное OpenVZ ядро с openvz.org, которое в свою очередь само по себе отлично поддерживает и KVM и OpenVZ изоляцию. Proxmox добавляет веб-управление, некоторые драйверы и платную поддержку.

        Но после перехода этого проекта в режим «платные обновления», он опять же выходит за рамки «свободного решения по виртулизации», хотя проект, безусловно, достойный.
      • 0
        спасибо, не знал.
  • 0
    А как обстоят дела с живыми миграциями в мире LXC/OpenVZ, дело движется?
    • 0
      В lxc, вроде бы, пока ее не существует в чистом виде.

      Но есть вот такой чудесный проект: criu.org/Main_Page с полной поддержкой со стороны Upstream ядра, который уже включен в 20ю Федору и почти промышленно стабилен. Он позволяет сериализовать/десериализовать любой Linux процесс.

      А в OpenVZ живая миграция уже года 4, можете подробнее прочесть вот тут: openvz.org/Man/vzmigrate.8 А около года назад когда появился ploop, живая миграция в OpenVZ стала совсем-совсем-совсем крутой за счет ploop write tracker: openvz.livejournal.com/41835.html
  • 0
    Спасибо за статью, очень интересно! Только не совсем понятно как контейнерный вариант будет соперничать! Я не спорю что действительно overhead маленький, больше ресурсов для клиентов, но, на мой взгляд подобное решение не совсем для промышленного сектора. VmWare к примеру может предоставить миграцию, FT, HA, тут же все реализовано в куче как я понял и таким образом будет страдать отказоустойчивость. К тому же вряд ли клиент, желающий получить свои мощности, захочет сидеть на одной оси с еще десятком. Но бесспорно решение интересное!
    • 0
      Спасибо за спасибо :) А OpenVZ умеет Live миграцию, а также недавно была доведена до стабильной фазы разработка фреймворка CRIU, который дает возможность сделать Live миграцию и на апстрим ядре, но пока в готовом виде ее нет.

      FT, HA в свою очередь требуют поддержки со стороны системы хранения, в принципе HA «в лоб» реализуется доволньо просто силами централизованного хранилища + 2 рабочие машины с OpenVZ и keepalived.

      Но, опять же, для контейнеров из ядра — этого пока нет.
    • 0
      FT тоже не для промышленного использования. Во всяком случае я не представляю себе рабочий сервер, достаточно важный для использования дорогущей фичи из дорогущего комплекта, но при этом чтоб ему хватало одного ядра. А все остальное можно делать и в контейнерах.

      Если же смотреть на такие решения как опенстак, то там хоть HA и миграция в принципе бывают, подход к поддержанию ВМ (или контейнеров — не важно) на плаву там совсем другой. см. pets vs cattle in the cloud.
      • 0
        Ой, а уточните фразу «при этом чтоб ему хватало одного ядра». Честно говоря, не понял, почему одного ядро.
        • 0
          Текущая версия FT от VMware ограничена одним ЦП. Они обещают реализовать поддержку мультипроцессорных конфигураций уже на протяжении трёх лет, но дальше демок пока не продвинулись.
          • 0
            А, я думал вы про контейнеры. Тогда получается, что красивого HA толком ни у кого и нету-то…
            • 0
              HA есть практически у всех, а вот FT толкает только вмварь. в принципе это можно сделать и на KVM и на Xen (мы делали, эксперимента ради) но с ограничением в один процессор, плюс еще кучка не менее жестких рамок остается, и продавать такое просто нет смысла. FT на сегодня — чисто маркетинговая штука у вмварей, типа «смотрите как еще мы можем»
      • 0
        Там где нужно FT, чаще всего достаточно одного ядра. Обещание сделать поддержку мультипроцессорности, может быть вызовом придти и занести денег. Я думаю не для кого не секрет, что некоторые фичи делаются по заказу конкретных кастомеров или группы кастомеров.
        • 0
          Полценный FT мог бы стать хорошим конкурентным преимуществом, а пока заказчики используют Stratus.
        • 0
          > Там где нужно FT, чаще всего достаточно одного ядра

          ой ли? а можно пример? а то пока что из примеров где FT таки нужен, и нельзя обойтись простым HA мне пришло в голову только про терминальные серверы. А они, с одним процессором, мало чего стОят
          • 0
            Вот сижу дума и на самом деле не понимаю, когда FT нужен не в real-time системе. Зачем оно на терминальном сервере? Если пользовательский ввод и чтоб пользователь не повторял свои действия с непонятной точки, то не ясно зачем тут больше 1 cpu.
            • 0
              > Зачем оно на терминальном сервере? Если пользовательский ввод и чтоб пользователь не повторял свои действия с непонятной точки, то не ясно зачем тут больше 1 cpu

              потому что терминалы не кластеризуются, а с HA будет даунтайм и потеря сессии. А больше чем один CPU нужен потому что терминал с одним процессором не потянет кучу пользователей, а если он их не потянет, то зачем он нужен? с одним юзером это уже VDI

              > Вот сижу дума и на самом деле не понимаю, когда FT нужен не в real-time системе

              под рукой нет линков, но на vmworld 2012 был задан вопрос лектору, на одной из сессий по compute — когда они начнут поддерживать хоть какие нибудь RTOS. Oтвет был «никогда, виртуализация не для того»
              • 0
                Обрабатывать ввод юзеров и считать то что они попросили можно на разных серверах. Юзеров можно хендлить из нескольких вмок с одним процессором с FT. А на тех мощностях, где происходит реальная обработка запросов юзеров FT не нужен. Там можно делать итеративные снапшоты раз в несколько секунд и в случая сбоя восстанавливаться и проигрывать юзеровский ввод с определенной точки.
                • 0
                  очень сложно, если так тянуть — уши оторвутся :) вообще плохо себе представляю такое на обычной RDS ферме
    • 0
      Контейнеры тоже предоставляют миграцию и HA. То что более оптимальная система, чаще оказывается сложнее, это обычное явление.

      > К тому же вряд ли клиент, желающий получить свои мощности, захочет сидеть на одной оси с еще десятком.

      Если эти оси друг на друга не влияют, то проблем никаких нет. С этой точки зрения контейнеры не сильно отличаются от виртуальных машин.
      • 0
        А как обстоят дела со стабильностью Windows-контейнеров? Или это не к вам вопрос?
        • 0
          Вы можете попробовать самостоятельно их: www.parallels.com/products/parallels-containers-windows/

          Но это исключительно коммерческий закрытый продукт, так что какие-то особенности реализации можно найти разве что в технической сопроводительной документации.
        • 0
          Я ими не занимаюсь. Надо понимать особенность технологии. Если в Linux все открыто и разработчик всегда четко понимает, что он делает. То в Windows все закрыто и там приходится делать разные трюки.

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

Самое читаемое Разное