Ватт на VM/ядро: измерение энергоэффективности серверов ЦОД

Зачем считать энергоэффективность не в ваттах, а на нагрузку

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

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

Метрика «ватт на VM/ядро» переводит разговор из «сколько ест железо» в «сколько стоит полезная работа». С ней проще прикинуть, сколько виртуальных машин реально поместится в стойке при лимите мощности, и во сколько обойдется рост нагрузки через год.

На практике такая метрика помогает:

• выбрать между двумя конфигурациями CPU и памяти, если обе проходят по производительности;
• оценить плотность размещения (VM на сервер и серверов на стойку) без сюрпризов по питанию;
• обосновать более дорогую конфигурацию, если она дает меньше ватт на единицу нагрузки;
• понять, где выгоднее масштабироваться: добавлять серверы или уплотнять виртуализацию.

Простой пример: в проекте ЦОД для госорганизации вы сравниваете два сервера, и оба держат нужное число VM. Разница в 80-120 Вт на сервер при рабочей загрузке кажется небольшой, но на десятках узлов это превращается в заметные деньги, а еще - в ограничения по стойкам и вводам питания.

Что означает «ватт на VM/ядро» и как не запутаться в терминах

Метрика «ватт на VM/ядро» нужна, чтобы сравнивать серверы не по «сколько ватт ест коробка», а по тому, сколько энергии уходит на понятную единицу нагрузки. Это особенно заметно, когда два сервера потребляют близко в простое, но по-разному ведут себя под виртуализацией.

W/VM (ватт на виртуальную машину) - это средняя мощность сервера под тестовой нагрузкой, разделенная на количество одновременно работающих VM заданного размера. Проще: сколько ватт нужно, чтобы «прокормить» одну типовую VM в ваших условиях.

W/ядро (ватт на ядро) обычно считают как мощность под нагрузкой, разделенную на число задействованных физических ядер (или vCPU, если вы сознательно нормализуете виртуальные ядра). Проще: сколько ватт уходит на «единицу CPU-ресурса».

Чтобы не путаться, держите базовые определения:

• VM - виртуальная машина (логический сервер).
• vCPU - виртуальный процессор, который планировщик гипервизора привязывает к ресурсам хоста.
• Физическое ядро - реальное ядро CPU.
• Поток (thread) - логический поток (например, при SMT/Hyper-Threading). Это не то же самое, что ядро.

Когда что использовать: W/VM удобнее, если вам нужно понять «сколько VM влезет в бюджет по энергии» при типовом профиле (VDI или одинаковые прикладные серверы). W/ядро полезнее, когда VM сильно разные, а закупка и лицензирование завязаны на CPU-ресурс.

Размер VM важно фиксировать заранее. VM на 1 vCPU и VM на 4 vCPU - это разные «единицы нагрузки». Практично считать отдельно для 1 vCPU, 2 vCPU и 4 vCPU и не смешивать результаты в одну цифру. Сервер может выглядеть отлично по W/VM на маленьких VM, но хуже на крупных, если упирается в частоту, память или планировщик.

Какие данные нужны, чтобы сравнение было честным

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

Потребление: где и как мерить

Фиксируйте мощность на входе - на PDU или через розеточный измеритель. Так учитывается КПД блоков питания и потери, которые не видны по внутренним датчикам сервера. Запишите модель PDU/ваттметра, шаг измерений (например, раз в 1-5 секунд) и длительность прогона, чтобы средние значения были стабильными.

Одна цифра почти ничего не говорит. Для планирования в ЦОД полезно иметь три значения: средняя мощность за тест, пиковая мощность (короткие всплески) и 95-й перцентиль (типичная верхняя граница без редких пиков). Обычно для питания и охлаждения ориентируются на 95-й перцентиль, а для сравнения эффективности под одинаковой нагрузкой - на среднюю. Главное - выбрать правило заранее и не менять его между стендами.

Условия и конфигурация: что обязательно фиксировать

Даже одинаковые по спецификации серверы могут вести себя по-разному из-за температуры, BIOS и настроек энергосбережения. Запишите температуру воздуха на входе в сервер (и диапазон во время теста), профиль питания в BIOS, лимиты мощности, режимы C-states, частотные профили и версию прошивок.

Конфигурацию фиксируйте так, чтобы ее можно было повторить без догадок: модель CPU и количество сокетов, объем и скорость RAM (и число модулей), диски и контроллеры (тип, количество, RAID-профиль), сетевые адаптеры (скорость, число портов, ключевые offload-настройки), блоки питания (мощность, количество, режим резервирования).

Практический момент: если вы сравниваете локально произведенные серверы (например, в проектах системной интеграции GSE) и импортные аналоги, не смешивайте разные уровни резервирования питания или разные профили BIOS. Иначе разница будет про настройки, а не про платформу.

Подготовка стенда: условия, которые важно зафиксировать заранее

Чтобы «ватт на VM/ядро» было сравнимым, стенд должен быть максимально одинаковым для всех тестов. Иначе вы измеряете не сервер, а разницу в настройках.

Чаще всего сравнение ломают питание и прошивки. Один и тот же сервер даст разные цифры, если включить другой профиль энергосбережения, оставить автоматический разгон или изменить режим вентиляторов.

Что нужно зафиксировать до первого прогона

Сведите условия в один документ и не меняйте их в середине серии тестов:

• профиль питания ОС и гипервизора, а также ключевые настройки BIOS (turbo/boost, C-states, лимиты мощности, режим вентиляторов);
• версию гипервизора, патчи, драйверы (сеть, RAID/HBA, NVMe) и настройки планировщика CPU;
• тип нагрузки и цель по уровню загрузки (например, 60-70% CPU);
• тайминг: прогрев, длительность прогона и окно усреднения (например, первые 10 минут не считать, далее усреднять 20 минут);
• два режима измерений: простой (idle) отдельно и рабочая нагрузка отдельно.

Это выглядит как бюрократия, но именно она делает цифры пригодными для закупки и для разговора с вендорами.

Нагрузка должна быть одинаковой, а не «похожей»

Выберите один сценарий и держитесь его. Если вы подбираете серверы под виртуализацию офисных систем, чистый CPU-тест даст аккуратные графики, но не покажет влияние памяти и диска. Для проектов ЦОД чаще полезнее смешанная нагрузка, где есть и вычисления, и I/O.

Заранее зафиксируйте: сколько VM, какой размер vCPU и RAM, какой профиль диска (случайное чтение/запись или последовательный), какие ограничения по сети. Тогда W/VM и W/ядро будут отражать именно вашу задачу.

Отдельно снимайте idle. Он важен, потому что в реальном ЦОД серверы далеко не всегда работают на пике. Разница между idle и нагрузкой часто показывает, насколько удачно настроены питание, охлаждение и базовая платформа. Иногда два похожих сервера под одинаковым гипервизором дают близкую мощность на нагрузке, но сильно расходятся в простое из-за настроек BIOS и профиля питания.

Пошаговая методика измерений на одном сервере

Чтобы сравнение было честным, на одном сервере нужно снять три вещи: потребление в простое, потребление под заданной нагрузкой и фактическую производительность (сколько VM или ядер реально занято). Тогда «ватт на VM/ядро» получается из повторяемого измерения, а не из впечатлений.

Перед стартом зафиксируйте одинаковое состояние: настройки BIOS, профиль питания ОС/гипервизора, версии драйверов, схему питания (желательно через один и тот же PDU/ваттметр). Дайте серверу прогреться 10-15 минут после включения.

Последовательность, которую удобно повторять:

1. Измерьте потребление в простое: ничего не запускайте, кроме базовых служб. Запишите среднее значение за одинаковый интервал (например, 5 минут).
2. Поднимите заранее определенное число VM одного профиля. Профиль должен быть одинаковым: vCPU, RAM, диск, сетевые настройки и одна и та же ОС.
3. Запустите одинаковую нагрузку внутри VM (или на хосте) и дождитесь стабильности, когда мощность и CPU перестанут «ползти». Обычно нужно 3-7 минут.
4. Снимите показатели за тот же интервал, что и в простое: среднюю мощность, загрузку CPU, число активных VM, частоты (если доступны), температуру и обороты вентиляторов. Мощность и производительность измеряйте одновременно.
5. Повторите прогон минимум три раза. Для итоговой цифры берите медиану, чтобы один «странный» запуск не испортил результат.

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

Как правильно посчитать W/VM и W/ядро и нормализовать результаты

Смысл метрики - не «сколько ватт ест сервер», а сколько ватт уходит на измеримую работу. Тогда сравнение между брендами и конфигурациями становится понятнее.

Базовые формулы: W/VM и W/ядро

Возьмите среднюю потребляемую мощность под стабильной нагрузкой (например, после прогрева) и разделите на фактически выполненную «единицу» нагрузки.

• W/VM = P_avg_load / N_vm_active, где N_vm_active - число VM, которые реально выполняют тест (не просто включены).
• W/ядро = P_avg_load / N_core_active, где N_core_active - число активных физических ядер, задействованных планировщиком под тест.

Если хотите оценить «полезную» энергию, используйте мощность сверх простоя:

P_useful = P_avg_load - P_avg_idle

Тогда:

W/VM_useful = P_useful / N_vm_active и W/ядро_useful = P_useful / N_core_active.

Так вы снижаете эффект от «красивого idle» и фокусируетесь на том, что важно в ЦОД.

Нормализация, если серверы разные

Когда у серверов разное число ядер, частоты, объем RAM или лимиты питания, обязательно нормализуйте условия. Обычно помогают два подхода: держать одинаковую целевую производительность (например, одинаковый RPS, TPS или время отклика) или одинаковую загрузку (например, 70% CPU). В обоих случаях рядом фиксируйте, что именно вы ограничивали, чтобы понимать, почему метрика получилась такой.

Полезно добавить в таблицу колонку «Ограничение» и заполнять одним словом: CPU-bound, RAM-bound, Storage-bound, Network-bound или Power-capped. Два сервера могут дать одинаковые «ватт на VM/ядро», но один упрется в память (не хватает RAM на VM), а другой - в лимит мощности BIOS.

Метрика работает лучше, когда рядом есть контекст: сколько ресурсов выделено каждой VM и что стало узким местом.

Шаблон таблицы для сравнения брендов и конфигураций

Таблица должна фиксировать не только «сколько ватт», но и что именно вы измеряли: конфигурацию, условия теста и результат в метриках на нагрузку. Тогда «ватт на VM/ядро» будет сопоставим между брендами и разными сборками.

Ниже - шаблон, который удобно заполнять по каждой конфигурации (одна строка = один прогон). Если делаете несколько прогонов, добавляйте строки с теми же параметрами и разными ID прогона.

| ID | Вендор/модель | CPU (модель, сокеты) | RAM (ГБ, тип) | Накопители (тип, кол-во) | PSU (Вт, 80 Plus) | NIC (скорость) | BIOS профиль | Гипервизор (версия) | Темп. вход (C) | PDU/счетчик (модель) | Idle W | Load W | Delta W | VM count (шт) | Активные vCPU/cores | W/VM | W/ядро | Delta/VM (полезн.) | Примечания | |---|---|---|---|---|---|---|---|---|---:|---|---:|---:|---:|---:|---:|---:|---:|---:|---|---| | 01 | | | | | | | | | | | | | | | | | | | | |

Как заполнять ключевые поля:

• Delta W = Load W - Idle W. Полезно, когда у разных серверов сильно отличается «фон» в простое.
• W/VM = Load W / VM count. Работает, если VM одинакового размера и действительно нагружают систему.
• W/ядро считайте от тех ядер, которые вы считаете активными в тесте (например, занятые vCPU или физические cores под пиннинг).
• Delta/VM (полезную) = Delta W / VM count. Часто понятнее для закупки: сколько ватт добавляет одна «рабочая» VM поверх простоя.

Поле «Примечания» спасает таблицу от неправильных выводов. Туда обычно попадают: упор в память (VM не влезли), троттлинг по температуре, лимиты питания, необычный профиль BIOS, особенности драйверов NIC/RAID, отличия в версии микрокода.

Если вы сравниваете конфигурации для проекта ЦОД, оставляйте место под «клон» одинакового теста для разных серверов (например, rack-серверов одного класса, включая локально произведенные модели), чтобы условия были один в один.

Пример расчета для проекта ЦОД: простой и реалистичный сценарий

Представим задачу: нужно разместить 100 типовых VM для офисных приложений и внутренних сервисов (AD, файловые ресурсы, печать, небольшие веб-сервисы). Чтобы сравнение было честным, сначала фиксируем профиль одной VM и критерий «нормально работает».

Стартовый профиль: 2 vCPU, 4 ГБ RAM, диск 60-80 ГБ. Дальше делаем короткий прогон нагрузки и смотрим, во что упираемся. Если CPU постоянно высоко и растет задержка - вы CPU-bound. Если CPU умеренный, но начинается активный своп и падает отклик - вы RAM-bound. Это важно: сервер может быть сильным по CPU, но проигрывать по плотности VM из-за памяти.

Теперь сравним 3 варианта хоста. На каждом запускаем одинаковые 50 VM и измеряем среднюю мощность «из розетки» за 30-60 минут в стабильном режиме:

• Сервер A: 520 Вт при 50 VM -> 10,4 W/VM
• Сервер B: 430 Вт при 50 VM -> 8,6 W/VM
• Сервер C: 610 Вт при 50 VM -> 12,2 W/VM

Так и применяется метрика: вы сравниваете не «просто ватт», а энергию на одну единицу полезной нагрузки.

Перевод в годовую энергию для 100 VM (без учета резерва): берем вариант B. Если нужно 2 хоста по 50 VM, средняя мощность кластера 2 x 430 = 860 Вт = 0,86 кВт. Годовое потребление: 0,86 x 8760 = 7534 кВт·ч. При тарифе, например, 35 KZT за кВт·ч это около 264 тыс. KZT в год только на IT-нагрузку (для оценки «все вместе» часто добавляют коэффициент PUE).

Если победитель по W/VM проигрывает по цене или срокам, решайте через простой расчет окупаемости: разницу в цене делите на годовую экономию энергии. А если сроки критичны, фиксируйте это как отдельный риск и сравнивайте варианты по двум осям: «стоимость владения» и «время ввода в эксплуатацию».

Типичные ошибки, из-за которых цифры становятся бесполезными

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

Самая частая ловушка - сравнить серверы разных поколений CPU, но не зафиксировать одинаковую нагрузку и настройки. Например, один стенд запускает 40 одинаковых VM с ограничением по CPU, а второй - «сколько влезет». На графике получится «победитель», но метрика будет означать разные вещи.

Ошибки, которые чаще всего ломают сравнение:

• берут мощность из паспорта или из iDRAC/iLO и не проверяют измерением на PDU/в розетке;
• замеряют только «под нагрузкой» и игнорируют idle;
• сравнивают «грязные» ватты без одинаковых условий: разные профили питания BIOS, разные лимиты turbo, разная скорость вентиляторов из-за температуры;
• меняют версию гипервизора, драйверов или микрокода между стендами;
• путают vCPU и физические ядра: считают W/ядро по vCPU, забывая про overcommit и SMT/Hyper-Threading.

Короткий пример: два сервера показывают по 600 Вт на PDU. На первом 50 VM в среднем по 15% CPU, на втором 35 VM по 25% CPU. Если делить «как есть», первый кажется лучше, но вы сравнили не эффективность, а уровень загрузки.

Правила, которые помогают защитить цифры перед закупкой:

• фиксируйте профиль питания и лимиты CPU в BIOS;
• снимайте мощность с одной и той же точки (лучше PDU) и в одинаковом окне времени;
• отдельно записывайте idle и несколько уровней нагрузки (например, 30/60/90%);
• замораживайте версии гипервизора, драйверов и прошивок на весь цикл теста;
• явно подписывайте, где vCPU, а где физические ядра, и по чему именно считаете W/ядро.

Короткий чеклист перед тем, как показывать результаты руководству

Руководству важны не детали стенда, а доверие к цифрам. Если в расчете есть скрытые допущения, «ватт на VM/ядро» быстро превращается в спор о методике.

Перед встречей проверьте пять вещей:

• Конфигурации и версии зафиксированы: CPU, RAM, диски, сетевые карты, BIOS/firmware, режимы питания, гипервизор и его настройки. Все записано в таблице; отличия отмечены явно.
• Idle и нагрузка измерены одинаково: один и тот же прибор/источник данных, одинаковая точка замера, одинаковый период, без параллельных работ и фоновых обновлений.
• Есть повторы: минимум три прогона каждого сценария. Понятно, как усредняете (среднее или медиана) и что делаете с выбросами.
• Понятно узкое место: CPU, память, диск или сеть. Иначе метрика может «врать».
• В итоговой строке есть контекст: профиль питания, температура, целевые метрики нагрузки, краткое описание теста.

Пример формулировки для слайда: «Сервер А: 210 Вт под нагрузкой, 30 VM, узкое место CPU, 3 прогона, среднее, условия одинаковые». Так проще сравнить варианты и задать правильные вопросы.

Следующие шаги: как использовать метрику в выборе серверов

Когда измерения уже есть, задача меняется: не «кто потребляет меньше ватт», а какой сервер даст нужную производительность при понятных затратах и рисках. «Ватт на VM/ядро» работает как общий язык между ИТ, закупкой и эксплуатацией.

Соберите короткий список и повторите замеры на своих профилях

Начните с 2-3 типовых профилей VM под реальные сервисы. Например: «веб + API», «база данных», «VDI/офисные рабочие места». Затем прогоните одинаковые сценарии на кандидатах в одинаковых условиях (те же версии гипервизора, те же политики питания, та же схема сетей и СХД).

Чтобы результаты не расползались, заранее закрепите минимум артефактов: профили VM и критерии «достигнуто» (латентность, IOPS, RPS, время отклика), расчет W/VM и W/ядро, а также емкость «VM на сервер при целевом SLA». Отдельно договоритесь, какие условия поставщик подтверждает в приемочных испытаниях и какие данные предоставляет.

Превратите цифры в решение для закупки и эксплуатации

Сведите результаты в одну таблицу: цена, емкость (сколько VM выдерживает при целевых метриках), итоговые ватт на VM/ядро, прогноз по энергии на стойку. Затем добавьте факторы, которые часто решают исход: доступность конфигураций, совместимость со стандартами, требования по локальному происхождению, прозрачность цепочки поставок.

Если для проекта важны локальный производитель и интеграция под ЦОД (поставка, внедрение, поддержка 24/7), имеет смысл включить в сравнение серверы GSE серии S200 и услуги системной интеграции GSE.kz, но оценивать их по тем же правилам и на том же стенде, что и остальных кандидатов. При необходимости детали по конфигурациям и сервисам удобно уточнять напрямую у команды GSE.kz (gse.kz).

Финальный шаг - зафиксировать «паспорт» выбранной конфигурации: какие настройки BIOS/питания допустимы, какие режимы считаются нормой, и какие показатели вы проверяете при приемке и при последующих расширениях.