Контейнеризация на 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
    Метки:
    FASTVPS LLC 35,69
    Хостинг Вашего Успеха с 2006 года.
    Поделиться публикацией
    Комментарии 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
              Это разве это возможно — наложить 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» некорректно =)

                          • –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.

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

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