FastVPS LLC
Компания
36,84
рейтинг
21 января 2014 в 10:07

Разное → Контейнеризация на Linux в деталях — LXC и OpenVZ Часть 2

Данная статья является продолжением серии, начатой в публикациях Контейнеры — это будущее облаков и Контейнеризация на Linux в деталях — LXC и OpenVZ. Часть 1.

Если публикацию про будущее можно пропустить, то статья «часть 1» будет обязательна к прочтению, чтобы понять, про что мы тут говорим.



Техническая реализация подсистемы лимитирования аппаратных ресурсов контейнеров


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

Какие ресурсы нам нужно делить между пользователями:
  • Процессор
  • Жесткий диск (нагрузка на него)
  • Память (объем)

Для всех подобных ограничений используется подсистема cgroups. Нагрузку на ввод/вывод можно фиксировать с помощью подсистемы cgroups blkio, причем, важно отметить, что есть как возможность задания жестких лимитов в байтах/секунду и операциях в секунду (IOPS), так и возможность задания весовых коэффициентов (то есть, например, 10% от всего сервера). Память лимитируется посредством memory cgroup, тут все довольно просто — указываем объем ОЗУ, если контейнер его превышает — процесс испытывает сообщение OOM. Для процессора допустима только возможность указания нагрузки в процентах, что объясняется особенностями реализации планировщика на Linux.

Итого, для реализации разграничения использования ресурсов мы воспользовались следующими cgroups:
  • cpu
  • memory
  • blkio


Общие проблемы при использовании контейнеров


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

Итак, поехали:
  1. В Linux upstream containers есть проблемы с изоляцией файловой системы /proc между контейнерами. В OpenVZ данная проблема решена.
  2. В Linux upstream containers невозможно ограничить объем диска доступный контейнеру без использования полностью отдельных файловых систем (что в свою очередь неудобно и очень неудобно в поддержке). Как перспективно решение данной проблемы в будущем стоит отметить функциональность subvolume файловой системы Btrfs, которая позволяет создать полностью изолированный участок (с фиксированным объемом) в пределах одной файловой системы.
  3. В качестве клиентской ОС при использовании контейнеризации может использоваться только та же самая ОС, что запущена на физическом сервере. Это не недостаток в техническом контексте, это особенность реализации. То есть на физической машине с Linux можно запустить только Linux. В случае необходимость запустить иную ОС очень хорошую услугу окажет KVM, который отлично поддерживается как на OpenVZ ядрах, так и на Linux upstream (к чести сказать — там он лучше).
  4. Меньший уровень безопасности по сравнению с полной виртуализацией. Создание эксплоита, который из контейнера приведет к выходу из строя самой аппаратной ноды потенциально возможно. В случае использования контейнеров из ядра Linux количество способов, чтобы вывести аппаратный сервер из строя решительно выше, так как в OpenVZ изоляция сделана намного лучше (за счет гранулированных UBC лимитов, а также за счет дополнительных проверок отсутствующих в upstream ядре).
  5. Для стабильного использования (но мы опять же не говорим о продакшене!) Linux upstream containers готовы начиная с ядра примерно 3.8 (в идеале, 3.10), в то время как во многих стабильных на данный момент дистрибутивах ядра младше и нет возможности использовать весь функционал. Довольно хороший вариант для работы с Linux upstream containers — это ядро от Oracle, оно как раз версии 3.8 и заявляет готовность контейнеров к промышленному использованию.
  6. Нет поддержки со стороны производителей дистрибутивов, например, стандартными средствами даже Fedora 20 нельзя поставить внутрь контейнера, а в виртуальную машину — можно. В вопросе установки попроще стоит вопрос у Debian и пакет debootstrap может с легкостью установить требуемый дистрибутив. В случае OpenVZ вопрос решается использование заранее собранных разработчиками образов ОС.
  7. Проблема с утилитами управления. Так как это крайне важный пункт, на мой взгляд, я решил остановиться на нем подробнее и расписал его отдельно в конце статьи.
  8. Отсутствие встроенного решения для лимитированию скорости сетевого соединения — эта проблема затрагивает как Linux upstream containers, так и OpenVZ. Разумеется, возможно создание собственных решений на базе tc, но настолько полезная функция просто обязана быть.




Преимущества OpenVZ над стандартной контейнеризацией в Linux


Мы уже обсудили, что OpenVZ и Linux upstream containers очень сходные технологии с похожей архитектурой и реализацией, но у них при этом очень много отличий. Часть отличий вызвана тем, что актуальная версия OpenVZ поддерживается для ядра 2.6.32 RHEL. Стоп! Вы видите тоже что и я? 2.6.32 ядро, really? Но прошу не пугаться, что это ядро старо — это не так, потому что Red Hat выполняет колоссальный объем работ по бэкпортированию кода из новых веток и это ядро функционально очень близко к 3.x и при этом крайне далеко от стандартного «ванильного» 2.6.32.

Таким образом если сравнивать мы будем ядра RHEL6 OpenVZ и текущую версию upstream ядра (3.12). Уровень изоляции процессорных и дисковых ресурсов у них на одном уровне, но есть ряд тонкостей, на которые стоит обратить внимание, о них ниже.

Что именно у нас есть в OpenVZ, чего нет в upstream Linux ядре:
  1. Используется система vSwap, которая позволяет настраивать overcommit для контейнера, а также позволяет выдать виртуальный (потому что замедление выполняет искусственно и на скорости около 100 мегабайт/секунду) SWAP
  2. Более точный подсчет оперативной памяти, потребляемый контейнерами за счет более гранулированных UBC счетчиков, можно посчитать занятую память ядра, память сокетов, выделенную память и реально занятую, число страниц shm памяти и многое-многое другое
  3. Возможность учета потребления страничного кэша каждым из контейнеров
  4. Система хранения с возможностью ограничения места доступного контейнера, построенная на базе ploop с функционалом аналогичным LVM, с возможностью создания снапшотов, возможностью увеличения/уменьшения в online режиме. Данная файловая система в свою очередь предоставляет уровень изоляции на уровне систем полной виртуализации.
  5. Поддержка live миграции с сервера-на сервер с нулевым даунтаймом (потеря 1 пинга) и использование очень эффективного алгоритма

Как можно заметить, почти все преимущества OpenVZ идут с упором на реальную эксплуатацию решения, а не на предоставление механизмов для реализации той или иной возможности, как поступают в Linux upstream containers.


Проблема со стороны user space


К сожалению, нет унифицированного способа управления контейнерами. В OpenVZ для этого используется vzctl, который, к слову, также может управлять контейнерами даже на обычном, upstream ядре начиная с версий 3.x, а еще он включен в поставку Fedora-20 и может быть установлен и использован без привлечения внешних зависимостей вообще. Также существуют LXC и docker (который в свою очередь тоже основан на LXC), но они также не покрывают полностью весь функционал, который может потребоваться пользователям контейнеров. Кроме этого, Linux Upstream Containers используются в весьма нестандартном месте — в системе инициализации systemd, используемой во многих дистрибутивах, функционале systemd-nspaw.

Поэтому вопрос в реализации удобного, грамотного, гибкого и отлично спроектированного фреймворка для управления контейнерами в Linux открыт и Вы можете изменить мир, написав его (smile) Также очень много полезного по вопросу утилит управления контейнерами Вы можете почерпнуть из презентации Кирилла Колышкина с конференции Linux Plumbers 2013.



Выводы


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

Также хотелось бы поблагодарить Andrey Wagin avagin за помощь в редактуре особо сложных технических вопросов.

C уважением, Павел Одинцов
CTO FastVPS LLC
Автор: @pavelodintsov
FastVPS LLC
рейтинг 36,84
Компания прекратила активность на сайте

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

  • –2
    Буду рад ответить на все возникшие вопросы, не стесняемся и идем в комментарии! :)
  • +3
    Цикл статей очень интересный, но исходный тезис совершенно неверен. Будущее облаков — и не полная виртуализация, и не контейнерная. Мне нужно развернуть wordpress — я думаю поставить его в OpenVZ или в KVM, и понимаю что в обоих случаях мне придётся ещё одну полноценную linux машину администрировать. А мне всего-то нужен wordpress. Соответственно от облака нужно только wordpress+mysql — и всё, без остального мусора. Вот когда в контейнере останется только wordpress, всем будет глубоко наплевать что там только linux — потому что линукс будет только в host системе.
    • –2
      Спасибо за позиивнй фидбэк!

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

      Как в случае Upstream Linux Containers, так и в случае OpenVZ как раз можно запереть Wordpress в определенной папке, изолировать его IPc и сеть, а также обрезать память, диск и процессор не создавая полноноценного контейнера, а просто наложив лимиты поверх текущей конфигурации. Примерно так, например, работает CloudLinux (к слову, есть идея его препарировать по аналогии с OpenVZ).
      • +1
        можно запереть Wordpress в определенной папке, изолировать его IPc и сеть, а также обрезать память, диск и процессор не создавая полноноценного контейнера, а просто наложив лимиты поверх текущей конфигурации

        Вся идея облаков в том, чтобы дать пользователю возможность решать его проблемы не тратя время на поддержку серверов. А тут — какой-то ад админский. Это конечно весело, когда заняться нечем, но лучше использовать инструменты по прямому назначению, а не пытаться из куска хлеба соорудить троллейбус.
        image
        • +1
          Почему ад? Посмотрите, например, на Python uWSGI, там можно в конфигурации приложения настроить его помещение в отдельные namecpas'ы с наложением требуемых cgroups.

          В итоге Вы получаете:
          • Настройку в три клика, все что нужно — указать пару параметров и иметь ядро выше 3.8
          • Изолированное по ресурсам приложение (да, теперь утечка в памяти не приведет к смерти сервера)
          • Полностью изолированное от хостовой системы приложение (да, теперь взлом одного окружения не приведет ни к каким проблемам соседнего приложения)
          • 0
            Да конечно можно. Просто человеку, который хочет раздеплоить wordpress в облако рассказывать про Python uWSGI, указывание параметров, проверку и обновление ядра Linux немного не правильно. Понятно например зачем это делать, если вы хотите запереть воркер от билд-сервера, но для wordpress есть гораздо более простые и удобные пути в 1 клик.
            • +1
              Тут я, конечно, соглашусь, что с нуля собирать контейнеризацию для любого софта — задача нетривиальная. В этом плане — контейнеры — лишь вспомогательный механизм, но не конечный продукт. До того, как они превратятся в конечный продукт — потребуется по меньшей мере пару лет (да и то, лишь в случае, если будет активная поддержка со стороны дистрибутивов), если не больше.

            • 0
              Я же правильно понимаю, что у вас там под капотом запускается полноценный контейнер?
              • 0
                конечно
      • 0
        Это разве это возможно — наложить by OpenVZ/LXC какие-то ограничения на что-то запускаемое в отдельной папке? Только же на контейнер (со всеми кишками, системой, вебсервером) целиком. А CL решает эту проблему совсем не этими контейнерами, а хитрыми эвристиками на уровне апача («псевдоконтейнеры»).
    • 0
      Это называется application container. Есть еще OSv, которая в ту же сторону двигается. В первом есть контейнеры, а во втором гипервизор. Так что на счет «в корне», хочу не согласиться.
      • +1
        Забавно так, сейчас платформа на которой пилим биллинг и несколько других продуктов в основе своей имеет app-контейнеры (отдельно личный кабинет, отдельно сама считалка бабла + ещё несколько аппов) и при этом инициалы идеолога — ОСВ. Надо будет поспрашивать, не причастен ли он к OSv. :)
        • 0
          В нашем мире все возможно :)
        • 0
          могу даже сказать наверняка, что за «считалка»? Вообще, создатели OSv пришли из Red Hat и до этого занимались разработкой KVM и QEMU. Собственно они KVM изобрели
    • +1
      Если быть ещё точнее, то вам нужен wordpress и вся инфраструктура для обработки запросов, балансировки нагрузки, хранения логов и мониторинги. С технической точки зрения именно контейнеры хорошо подходят для этой задачи, так что тут статья очень даже актуальна, но, в данном контексте, для разработчиков PaaS систем. А вам же уже нужны готовые решения, GAE, OpenShift, Heroku, Cocaine. Мне не раз приходилось рассказывать людям, что им не нужны виртуалки, и очень здорово, что вы сами поднимаете такие вопросы.
      • 0
        Спасибо за отличное дополнение!
    • 0
      это уже PaaS, а тут разговор об IaaS
    • –5
      Проблема уже решена:) Администрировать ОС не нужно! Идеально для вашего сценария. Все необходимое ставится в 1 клик http://infobox.ru/jelastic/ (и PHP, и база и все, что только пожелаете. Можно даже Wordpress в 1 клик поставить из раздела «приложения». При этом внутри будет OpenVZ и куча автоматизации, но пользователя это все волновать не будет). А зарегистрировавшись по следующей ссылке можно получить еще и 201.4 руб на счет после перехода в коммерческий режим http://infobox.ru/promo/tryjelastic2014/. Будут вопросы — пишите в комменты или на trukhinyuri@infoboxcloud.com P.S. Извините, коллеги. Отличная статья, не собирался делать тут рекламу, но помочь человеку нужно.
      • +2
        Вот мой первый опыт.
        """
        Notice: unserialize(): Error at offset 35 of 39 bytes in variable_initialize() (line 916 of /var/www/webroot/ROOT/includes/bootstrap.inc).

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

        Необходимо обновление вручную
        Обновления ядра Drupal в настоящее время не поддерживаются.
        """

        Как обновлять в ручную не понятно. Как вы изолируете пользователей друг от друга. Вы пришли в технический топик, вывалили рекламу, а технические моменты своей платформы не прояснили.
        • 0
          Потому что это — не их платформа, Jelastic — суровый проприетарный black box, построенный на морально устаревшей Virtuozz'a (и это при живом Parallels Cloud Server) :)
          • 0
            «морально устаревшей Virtuozz'a» — что в ней морально устарело?
            • 0
              На этот вопрос сложно ответить без привлечения маркетинга, но кратко — по всей публичной информации, что есть в сети, четко видно, что будущее в Linux виртуализации от Parallels в продукте PCS, там много инновационных вещей — поддержка гипервизоров, поддержка облачного стораджа, общие оптимизации производительности.

              Но это все для Jelastic, конечно же, не нужно. А нужно лишь — срок «жизни» платформы, а для PCS он на порядки больше и можно надеяться на по меньшей мере лет 5-7 апдейтов без реинсталла =)

              А если ударяться в технику, то страница 34 вот этой презентации красноречиво отвечает на этот вопрос из самого авторитетного источника — от авторов системы.

              Привожу ее здесь:

              • +1
                Да, старая версия немного медленнее. Но как еластик привязан к виртуозе? PCS — это практически виртуоза на рхеле, т е еластик должен без проблем на нем подниматься.
                Ну и виртуоза не устарела и официально поддерживается. Может переезд на более свежую версию не оправдывает себя пока финансово.
                • –2
                  PCS конечно гораздо больше, чем Virtuozzio на RHEL, если смотреть на него в полном боекомплекте вместе с PACI и Parallels Cloud Storage. Jelastic — PaaS, насколько эффективно он использует ресурсы — точно не проблема пользователей (использует эффективно), пользователь получает ровно столько ресурсов, сколько заказал и мыслит в контексте окружений, а не ОС. При этом Jelastic – не панацея, есть много случаев когда IaaS лучше (например если необходима сложная настройка нетипичных приложений). Просто в конкретном сценарии он работал бы идеально и не заставлял пользователя думать о настройке ОС.
                • 0
                  PCS во времена релиза Jelastic был «с пылу с жару, неделя после релиза», так что просто выбора в те времена не было.

                  Вообще интересный вопрос, почему она (PVC 4.7) медленнее, чем PCS, ведь ядро поидее тоже самое. Единственное на что есть подозрения — отличия в userspace, которые могут давать такой провал в скорости. Но кроме numabalanced и pfcache ничего в голову не приходит.

                  • 0
                    PCS во времена релиза Jelastic был «с пылу с жару, неделя после релиза»

                    Если бы у нас стоял Jelastic версии 0.1, то это был бы сильный аргумент. Однако со времен первого релиза платформа постоянно совершенствовалась и технология развивается. Поэтому не стоит пытаться в качестве аргумента приводить Jelastic «со времен первого релиза».
                    • +1
                      Так не, речь немного об ином. Я исправляю сам себя и указываю на то, что когда Jelastic вышел в продакшен, то PCS буквально недавно вышел и пытаться второпях переехать на него — было бы не лучшей идеей. Поэтому мое замечание по поводу «а что у них не PCS» некорректно =)

                      • –1
                        а, ок:) like:)
        • –2
          Напишите пожалуйста на trukhinyuri@infoboxcloud.com свой логин в Jelastic и мы посмотрим, в чем дело с drupal при обновлении и решим проблему. Jelastic – не blackbox. Фактически это автоматизация над контейнерной виртуализацией, позволяющая пользователю не думать о настройке серверов, а мыслить в категории стандартных окружений с автоскейлингом и абстракцией гораздо высокого уровня, чем IaaS. И конечно у нас в компании используется Parallels Cloud Server :)
          • 0
            Вы можете создать новую установку друпала и собрать те же проблемы. Я создал только, чтоб глянуть как это работает, пользоваться не собирался. Спасибо.
            • –2
              Обязательно исследуем вопрос и починим. Спасибо. В будущем сразу при таких проблемах можно писать в саппорт. Если какая-то проблема не решена — скорее всего мы о ней просто не знаем.
            • –1
              Тем временем проблема с Drupal в Jelastic исправлена. Спасибо за фидбек.
  • +1
    Да, кстати, забыл упомянуть наше решение по реализации кастомного шейпера для OpenVZ, может быть кому пригодится. Правда, до «красивого» двухстороннего шейпинга нашему решению далеко.
  • 0
    Поэтому вопрос в реализации удобного, грамотного, гибкого и отлично спроектированного фреймворка для управления контейнерами в Linux открыт и Вы можете изменить мир, написав его

    Поддержка и lxc и openvz есть в libvirt что там плохо?
    • 0
      Там плохо почти все, поддерживаются лишь базовые операции — создание, удаление. Ни о какой серьезной кастомизации, например, о пробросе устройств, рисайзе диска наживую, гранулярной настройки лимитов памяти речи просто не идет, к сожалению.
      • +1
        для LXC будут допиливать все, это стратегическое направление.
        • 0
          Не думаю, за 2+ года ситуация не поменялась ни на шаг, честно говоря, при огромное шаге в развитии Linux Containers. Нужен другой инструмент :)
          • +1
            были другие приоритеты. red hat не такая уж и огромная фирма, и им надо поддерживать и развивать уже существующее портфолио продуктов, которых немало. Не буду вдаваться в детали — во первых это не этично, а во вторых я ушел оттуда почти год назад, и многое могло измениться, но я знаю наверняка что LXC будет среди приоритетных направлений на определенных этапах развития RHEL7.

            ну а то что RHT, когда берутся за проект, делают из него конфетку, я думаю секретом не является
            • 0
              Да, RH задает вектор развития Linux по очень многим пунктам и это отлично, когда есть в индустрии такие столпы! :) Будем надеяться, что будет как Вы и говорите, контейнеры — очень и очень нужная технология во многом сильно меняющая облик современных дистрибутивов.
              • 0
                будем надеяться :) во всяком случае я вижу очень много коммитов в openstack nova вокруг интеграции с LXC, так что что-то явно происходит
  • +1
    У вас пункт 2 и пункт 8 в списке проблем контейнеров про одно и то же.
    • 0
      Да, спасибо, Ваша правда, при правке решил добавить пару слов про BTRFS и светлое его будущее в контексте контейнеров, но в итоге скопировал почти полностью другой пункт. FIXED!
  • 0
    Давно уже не пользовался контейнерами, может мой вопрос будет не актуален.
    Как обстоят дела с shared memory? Раньше, помнится, одна гостевая машина на ноде могла исчерпать весь лимит. В результате страдали соседние контейнеры. Часто проявлялось как отказ apache запускаться со странной ошибкой: «port already in use».

    • 0
      Сейчас этой проблемы нет. Лимиты отдельно на каждый контейнер и вся эта память аккаунтится в память контейнера.
      • 0
        «port already in use» — по-моему, редко связано с конкретно памятью, обычно это проблемы сети (корректно не освобожденный ранее сокет). Также Apache использует семафоры для своих внутренних задач, а они в свою очередь также отлично изолируются силами ipc namespace.

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

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