Экономика консолидации: сколько реально даёт виртуализация на своём железе

MAATRIX

После разбора антипаттерна «один сервер под всё» логично спросить: а как тогда правильно? Ответ известен десятилетия — виртуализация. Вместо того чтобы валить почту, базу и сайт в одну ОС без границ, вы поднимаете на одном физическом сервере несколько виртуальных машин, каждая со своей ОС, своими ресурсами и своим отказом, который не тянет за собой соседей. Вопрос в другом: сколько эта консолидация реально экономит и на чём именно, а где экономия — самообман, потому что часть работы просто переехала с уровня «железа» на уровень «каждой ВМ отдельно».

Что экономит консолидация, а что нет

Экономия консолидации — это не «в пять раз дешевле», а конкретный список статей расходов, которые схлопываются на один физический сервер вместо пяти:

• Капитальные затраты на железо. Один сервер с 2×32 ядра и 256+ ГБ RAM дешевле в пересчёте на ядро и гигабайт, чем пять серверов среднего класса — экономия за счёт масштаба на процессорах, материнских платах, блоках питания.
• Место в стойке, колокейшн, электричество и охлаждение. Один сервер вместо пяти — это 1U-2U вместо 5U-10U, один комплект вентиляторов и БП вместо пяти. Счёт за размещение и энергопотребление падает пропорционально числу физических единиц.
• IPMI/iDRAC/iLO и сетевая инфраструктура. Один комплект портов управления, один аплинк с резервированием — меньше портов на свитче, меньше кабелей, меньше точек отказа физического уровня.
• Административное время на уровне железа. Прошивки BIOS/IPMI, мониторинг SMART и температур, замена дисков и памяти — всё это делается один раз для одного сервера, а не пять раз для пяти.

Это экономия на железе и его обслуживании, а не на администрировании сервисов. Если сервисы разнесены по отдельным ВМ правильно (а не свалены в одну ОС, как в антипаттерне «всё в одном»), никуда не девается:

• Пять операционных систем для патчинга. Обновления безопасности, ядро, пакеты — на каждой ВМ отдельно, потому что это отдельная система со своим жизненным циклом.
• Пять наборов бэкапов и точек мониторинга. Снапшот диска ВМ не заменяет согласованный бэкап базы или почты на уровне приложения — он нужен для каждой ВМ отдельно, как и мониторинг диска, памяти, процессов внутри неё.
• Пять поверхностей управления доступом. SSH-ключи, firewall-правила, пользователи — конфигурируются на уровне каждой ОС отдельно. Это и есть цена изоляции, и платить её приходится осознанно.

Виртуализация не уменьшает объём работы «внутри» сервисов — она убирает дублирование работы «вокруг» физического железа. Если экономия консолидации в вашей голове означает «теперь администрирую впятеро меньше систем» — это ошибка, которая аукнется при планировании своего времени или штата.

Пример расчёта: пять задач на одном хосте

Возьмём условный набор из предыдущей статьи про антипаттерн: веб-сайт, почтовый сервер, база данных, VPN-шлюз и файловое хранилище с бэкапами. Разложим их по ресурсам, которые реально нужны каждой задаче с запасом:

Сумма «в лоб»: 11 vCPU, 22 ГБ RAM, ~740 ГБ диска. Пять отдельных физических серверов под эти профили — это пять комплектов CPU/RAM/диска, каждый взят с запасом «на всякий случай», потому что заранее непонятно, сколько реально понадобится. На практике это означает избыточность: пять физических серверов начального уровня (условно 4 ядра/8 ГБ каждый) дают суммарно 20 ядер и 40 ГБ RAM — почти вдвое больше, чем реально требуется по сумме профилей, просто потому что минимальная конфигурация редко бывает меньше 4/8.

Один сервер на 16-24 физических ядра (с HT/SMT — 32-48 потоков) и 64-128 ГБ RAM с NVMe и HDD-массивом под холодные данные закрывает те же пять ВМ с адекватным запасом на каждую, без пятикратного дублирования «минимальной конфигурации». Экономия здесь не в объёме вычислений — вычислений нужно ровно столько, сколько нужно — а в том, что не приходится оплачивать пять раз минимальный порог входа (шасси, БП, сетевая карта, диск под ОС) ради малых нагрузок вроде VPN-шлюза на 1 vCPU.

Где экономия реальная, а где иллюзорная

Разграничим честно, чтобы не выдавать желаемое за действительное.

Реальная экономия:

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

Иллюзорная или переоценённая экономия:

• «Одна лицензия панели управления вместо пяти» — если вы ставите Proxmox VE (бесплатный) поверх, экономии на лицензии как таковой нет; экономия только в том, что настраивать эту панель приходится один раз.
• «Меньше администрирования» — как показано выше, это неверно на уровне ОС и сервисов, верно только на уровне железа.
• «Меньше рисков» — риски не исчезают, а меняют форму: вместо риска отказа одного маленького сервера (теряете одну задачу) появляется риск отказа одного большого сервера (теряете все пять задач одновременно, если не защититься отдельно — см. следующий раздел).
• Оверхед самой виртуализации. Гипервизор съедает часть CPU и RAM на служебные процессы, виртуализация диска и сети даёт накладные расходы (обычно единицы процентов на CPU-bound задачах, больше на I/O-интенсивных — точная цифра зависит от нагрузки и настройки virtio, поэтому проектировать нужно с запасом). Подробнее — в отдельном разборе: где виртуализация теряет производительность.

Единая точка отказа и как её закрыть

Главный честный минус консолидации — это то, что раньше было пятью независимыми точками отказа, стало одной. Диск, память, блок питания или материнская плата одного сервера — и «легли» сразу все пять сервисов, а не один. Это не повод отказываться от виртуализации, это повод заложить защиту в бюджет отдельной строкой:

• RAID на дисках (аппаратный или программный, mdadm/ZFS) — отказ одного диска не должен уронить хост. Это стоит либо денег на RAID-контроллер, либо CPU на программный RAID, но не бесплатно.
• Резервный блок питания. На выделенных серверах бизнес-класса это обычно опция, а не стандарт — и её часто осознанно не берут ради экономии; для консолидированного хоста это стоит пересмотреть, ставки выше.
• Регулярные бэкапы образов ВМ на отдельное хранилище (не на тот же физический сервер) — Proxmox Backup Server, restic, borgbackup — чтобы при полном отказе железа поднять все пять ВМ на другом сервере за часы, а не потерять их насовсем.
• План восстановления, который вы реально проверяли, а не только настроили. Бэкап, который ни разу не разворачивали тестово, с равной вероятностью не развернётся и в момент реальной аварии.
• При потребности в высокой доступности — кластер из нескольких узлов с живой миграцией вместо одного сервера. Это уже не «экономия на железе», а осознанный компромисс между стоимостью и допустимым простоем.

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

Лицензии при консолидации

Отдельная статья расходов, которая может как усилить экономию, так и съесть её — лицензирование ОС и ПО.

Для Linux-стека (Ubuntu, Debian, большинство дистрибутивов) лицензий как таковых нет — экономия консолидации здесь чистая, ограничена только железом и обслуживанием.

Для Windows Server ситуация сложнее: лицензирование считается по физическим ядрам сервера (per-core, минимум 8 ядер и 16 core-лицензий), а не по числу ВМ. Консолидация пяти отдельных Windows-серверов в пять ВМ на одном физическом хосте почти всегда выгоднее по лицензиям, чем пять отдельных серверов — вместо пяти лицензионных пулов вы покупаете один пул на реальное число ядер хоста. При этом редакция Standard даёт право на 2 виртуальных инстанса на лицензируемый сервер, Datacenter — неограниченное число ВМ, что при плотной консолидации может окупить более высокую цену Datacenter. Методика расчёта разобрана отдельно: лицензии Windows Server и CAL: как посчитать сумму до покупки.

Отдельно стоит учитывать лицензии прикладного ПО, которые считаются «по ядру» или «по инстансу» (некоторые СУБД, антивирусы уровня предприятия, системы резервного копирования с оплатой за агента) — при консолидации число агентов/инстансов не падает, падает только число физических ядер, на которое считается лицензия ядра ОС или гипервизора.

Когда консолидация не выгодна

Виртуализация — не универсальный ответ. Она проигрывает или требует пересмотра в нескольких случаях:

• Совпадающие по времени пики нагрузки. Если все пять сервисов упираются в CPU одновременно (например, ночной батч-расчёт, ночные бэкапы и ночная синхронизация базы совпадают по времени), overcommit не работает — ресурсы нужны всем сразу, и придётся закладывать сумму пиковых потребностей, а не среднюю, что снижает выгоду консолидации почти до нуля.
• GPU и специализированное железо. Passthrough GPU в ВМ технически возможен, но обычно отдаёт всю карту одной ВМ целиком (без vGPU-лицензий уровня datacenter), так что «пять ВМ шарят одну видеокарту» на практике не работает — для таких задач разумнее либо отдельный сервер с GPU, либо несколько карт на одном хосте.
• Compliance и требования физической изоляции. Часть отраслевых требований (обработка платёжных данных в определённых схемах, некоторые государственные контракты) прямо требует физически изолированного оборудования под конкретный контур — виртуализация с общим гипервизором формально не подходит, даже если технически изоляция ВМ достаточна.
• Очень маленькая нагрузка совокупно. Если суммарные потребности всех сервисов укладываются в один недорогой VPS, разговор о выделенном сервере под консолидацию вообще избыточен — экономика работает в обратную сторону, переплата за мощность, которая не используется.
• Сильно разные требования к сети или задержкам. Если одному сервису нужен выделенный физический сетевой интерфейс с гарантированной полосой, а виртуальная сеть гипервизора вносит джиттер, который критичен именно для этой задачи — изоляция на уровне ВМ не решает проблему, нужна физическая изоляция сетевого пути.

Как посчитать свою экономику

Практическая методика, которая не требует гадать на кофейной гуще:

1. Соберите текущие счета. Если сервисы уже разнесены по отдельным серверам/VPS — сложите их ежемесячную стоимость, включая место в стойке или тариф VPS, IP-адреса, панели управления, если они оплачиваются отдельно.
2. Посчитайте реальные, а не «на всякий случай», требования по ресурсам для каждого сервиса — vCPU, RAM, диск, как в таблице выше. Возьмите текущую загрузку (top, vmstat, iostat на существующих серверах) как базу, а не паспортные характеристики железа.
3. Просуммируйте с разумным запасом (обычно 20-30% на CPU/RAM сверх суммы средних нагрузок, больше — если пики совпадают по времени) и подберите один сервер, который закрывает эту сумму с местом для роста на год-полтора вперёд.
4. Добавьте стоимость резервирования — RAID, второй блок питания, план бэкапов на отдельное хранилище. Это не опция, а обязательная строка расчёта, если консолидация вообще рассматривается всерьёз.
5. Сравните лицензии до и после, особенно если в стеке есть Windows Server или прикладное ПО с лицензированием по ядру.
6. Вычтите административную экономию отдельно — только то, что реально относится к железу (мониторинг физического сервера, прошивки, замена компонентов), не приплюсовывайте сюда патчинг ОС и бэкапы приложений, которые остаются как были.

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

Частые вопросы