Виртуализация, контейнеризация, докеризация
Технологии виртуализации и контейнеризации плотно вошли в нашу жизнь, и любой системный администратор сталкивается с ними ежедневно. Но до сих пор бытуют мифы и заблуждения относительно технологий и поэтому давайте разберем их отдельно.
1️⃣ Начнем с виртуализации. Это наиболее старая и зрелая технология, достигшая к современному состоянию дел определенной стабильности и совершенства.
Виртуальная машина предполагает полную развязку гостевой системы от хостовой и предполагает полную эмуляцию виртуального железа, предлагая виртуальной машине полностью отвязанные от физического хоста конфигурации.
Но это влечет за собой максимально высокие накладные расходы, которые зависят от набора эмулируемого железа, в большинстве случаев они не превышают 10-15%, но могут оказаться и более высокими, особенно если нам нужно обеспечить высокую доступность.
Высокая доступность для виртуальных машин давно отработанная технология и виртуальная машина может передаваться между узлами без остановки работы и не прекращая обслуживание пользователей.
Однако, если в кластере используются процессоры разных поколений, с разными наборами инструкций, то виртуальная машина будет ограничена возможностями наиболее слабого узла, что может привести к более серьезной потере производительности на более быстрых нодах.
2️⃣ Контейнеризация LXC на первый взгляд похожа на виртуализацию, вам также предоставляется как бы отдельный экземпляр операционной системы. Но мы не зря сказали «как-бы».
Контейнер LXC не имеет собственного ядра и собственного железа, а также собственных ресурсов, он выполняется прямо на хосте и использует ресурсы и ядро хоста в рамках выделенных ему лимитов.
Но снаружи это выглядит как отдельный экземпляр операционной системы, причем мы можем таким образом запускать самые различные ОС на ядре Linux.
На самом деле контейнер предоставляет нам системное окружение выбранной ОС, работающей на ядре хоста и с ресурсами хоста.
Это эффективно решает задачу, что у нас есть софт, собранный под определенную ОС и нам надо его запустить. Нет проблем, запускаем контейнер с нужным системным окружением и работаем в нем с нашим экземпляром ПО.
ПО думает, что работает в среде нужной ему ОС, для администратора это выглядит также в итоге получаем привычную среду, которая похожа на виртуалку, но виртуалкой не является.
Что касается живой миграции таких контейнеров, то с этим есть определенные проблемы. Сам контейнер привязан к ядру хоста и просто так не может быть передан на другой узел. В рамках Proxmox миграция LXC-контейнеров возможна только с остановкой и перезапуском.
Хотя есть альтернативные решения, которые позволяют передавать контейнер без остановки, но это уже специфика и следует исходить из того, что контейнер без перезапуска не мигрирует.
3️⃣ Теперь перейдем к докеризации. Докер представляет собой контейнер на уровне приложения. Накладные расходы минимальны – докер приложение исполняется на хосте в рамках установленных лимитов.
Также у докер совсем другая философия, контейнер атомарен и неизменяем, по сути, это некоторый черный ящик, к которому мы подключаем свои ресурсы и настройки.
В случае какой-то проблемы мы просто уничтожаем текущий контейнер и запускаем новый. Надо переключиться на другой хост, тушим контейнеры здесь, запускаем там. Балансировщик быстро перекидывает соединения.
При том, что Докер-контейнеры запускаются и перезапускаются крайне быстро, то подобный подход является неплохой альтернативой живой миграции. Точнее сводят необходимость живой миграции к минимуму.
👆 Что в итоге выбрать – смотрите сами. Все указанные технологии достаточно зрелые, каждая их них имеет свои особенности и недостатки. А грамотный администратор всегда умеет играть от сильных сторон решений.
