​​Монолит против виртуализации

Сегодня завершили трехдневную эпопею с переносом инфраструктуры одного заказчика на новый сервер в виртуальную среду. Процесс прошел сравнительно мягко, как для нас, так и для заказчика как раз благодаря тому, что виртуализация позволяет «есть слона по частям».

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

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

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

Кто-то скажет, а какая разница, сервер все равно один, только добавляется лишняя прослойка в лице виртуализации.

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

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

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

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

Оптимально: один сервис – одна виртуальная машина (контейнер).

Далее – считаем ресурсы, как дисковые, так и по оперативной памяти. И то и другое можно выделять с превышением суммарной наличной емкости, но понимать, что этот момент придется постоянно контролировать.

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

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

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

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

Виртуалка – это совсем иное дело, это отдельный хост, со своим набором виртуального железа, виртуальной ОС и для заключенных внутри нее служб она ничем не отличается от обычного ПК.

Что выбрать? Смотрите сами. Контейнер дает минимальную потерю по производительности, фактически вы работаете на железе хоста. Также контейнеры используют память хоста и то, то вы им выделили – это лимиты.

Но они имеют свои особенности эксплуатации и это надо читать документацию к гипервизору.

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

Что выбрать – смотреть по ситуации. Но в любом случае такая структура будет более гибкой и управляемой, нежели монолит.