Представьте, что вы платите за электричество, которое не используете. Не потому что ошиблись в расчётах, а потому что так устроена тарифная модель. Именно это может стать реальностью операторов ЦОДов: переход к оплате за резервируемую мощность превращает каждый запас на будущее в убыток в текущий момент. То, что раньше считалось хорошей практикой ― строить с запасом и постепенно загружать мощности, ― теперь становится финансовой ловушкой.
В таких условиях архитектура серверов и стоек перестает быть вопросом предпочтений или устоявшихся привычек и напрямую влияет на экономику проекта. Разберем, почему это происходит и как OCP (Open Compute Project) в сочетании с фрикулингом может помочь в адаптации к новой реальности.
От «сколько потребили» к «сколько заявили»
Традиционная модель развития ЦОД допускает определённую асинхронность. Площадка строится с запасом: подводится мощность (например, 50 МВт), создается инженерный контур. Затем в течение достаточно длительного времени ( иногда до 10 лет) машзалы постепенно заполняются серверами. Пока действует оплата «по счетчику», такая неспешность оправдана. Она позволяет плавно наращивать мощности и равномерно развивать площадку.
Но если регулятор вводит норму оплаты 80% от заявленной мощности (независимо от того, крутятся там диски или нет), разрыв между «построили» и «загрузили» должен быть минимальным. Time to Market (TTM) ввода ИТ-нагрузки выходит в ключевые KPI, а не утилизированные мощности не просто простаивают, но и генерируют затраты.
Мы регулярно видим проекты, где инженерные мощности простаивают месяцами, пока идёт постепенное наращивание ИТ-нагрузки. В новой тарифной модели это уже становится роскошью.
Здесь классический 19-дюймовый подход становится узким горлышком. Поштучный монтаж серверов, индивидуальное каблирование каждой единицы и настройка на месте – это долго и дорого. Когда у вас впереди счета за пустые мегаватты, скорость развёртывания перестает быть вопросом удобства ― это уже вопрос денег.
И именно поэтому требуется уже не серверная сборка, а промышленная скорость развертывания.
Экономика мощности: где возникают потери
Но даже если вы ускорили ввод мощностей, возникает логичный вопрос: сколько из них вообще превращается в полезные вычисления?
Здесь на первый план выходит привычная метрика PUE (Power Usage Effectiveness).
В модели оплаты «по факту» высокий PUE (например, 1.7) – это просто раздутый OPEX. В модели «заявленной мощности» – это потеря полезного ресурса. При заявке в 10 МВт и PUE 1.6 у вас остается всего 6.25 МВт на полезные вычисления. Остальное – «налог» по сути своей только на охлаждение и потери в блоках питания.
Снижение PUE до 1.1-1.2 (что достижимо для OCP-решений) высвобождает дополнительные 20-30% мощности под ИТ-нагрузку в рамках того же договора с энергетическими компаниями. И в этот момент происходит важный сдвиг: архитектура ЦОДа впервые начинает напрямую влиять на P&L, а не просто на инженерную красоту решения.
Фрикулинг, или глоток свежего воздуха
Если ключевая задача повысить полезное потребление нашего дата-центра, следующий очевидный шаг ― пересмотреть подход к охлаждению.
И здесь на первый план выходит фрикулинг (free cooling) – использование уличного воздуха для охлаждения ― один из самых эффективных способов радикально снизить PUE. Однако это настоящий инженерный вызов для серверного оборудования, потому что открытой форточки в машинном зале объективно недостаточно.
Чтобы фрикулинг работал эффективно, серверы должны соответствовать жестким требованиям:
Расширенный температурный диапазон: Оборудование должно стабильно работать при 35-40°C на входе (стандарт ASHRAE A3/A4). Это позволяет минимизировать работу чиллеров даже в жаркие дни.
Аэродинамика: В классических серверах воздушный поток часто натыкается на преграды в виде плотного монтажа или кабельной укладки. В архитектуре OpenYard (на базе OCP) передняя панель максимально проницаема, а рациональное расположение основных источников тепла внутри, позволяет эффективно использовать воздух для максимального теплосъёма.
Интеллектуальный BMC: Управление вентиляторами должно быть прецизионным, чтобы не переохлаждать систему там, где это не нужно, экономя каждый ватт.
Почему OCP выигрывает в гонке энергоэффективности?
В условиях, где оплачивается не потребление, а заявленная мощность, любые потери времени и энергии начинают напрямую конвертироваться в деньги. И именно здесь rack-scale архитектура (OCP) перестает быть альтернативой и начинает выигрывать у классического подхода.
Вместо того чтобы собирать ЦОД из кирпичиков (серверов), вы оперируете целыми домами (готовыми стойками), быстрее развертываете инфраструктуру и экономите на эксплуатации.
Когда счёт идёт не за киловатт-часы, а за зарезервированную мощность, такие архитектурные различия перестают быть нюансом — они становятся экономическим фактором.
1. Скорость ввода (TTM):
Стойки могут приходить на объект полностью интегрированными: серверы, коммутаторы и шины питания уже смонтированы и протестированы на заводе. На площадке остается только подкатить стойку и подключить внешнее питание. Это кратно сокращает время развёртывания.
2. Энергоэффективность питания:
В классическом сервере в каждом блоке питания (БП) происходит преобразование AC/DC. В OCP используется централизованная полка питания на всю стойку. Это дает:
Меньшее количество точек отказа.
Отсутствие лишних преобразований внутри каждого узла.
3. Плотность и обслуживание:
Отказ от индивидуальных БП освобождает место для вычислительных ресурсов или дисков. Обслуживание происходит только из «холодного» коридора, что критично для современных высокоплотных машзалов.
Инфраструктурная зрелость: от CAPEX к стоимости «полезного киловатта»
В старой парадигме выбор часто делался в пользу самого дешевого сервера (минимальный CAPEX). В новой конфигурации уравнение становится сложнее. Нужно учитывать:
Скорость, с которой сервер начнет «отбивать» зарезервированную мощность.
Затраты, связанные с обеспечением инфраструктуры (в основном системы ОВиК).
Стоимость обслуживания при высокой плотности.
В этой логике решения на базе OCP (включая OpenYard) выглядят не как альтернатива, а как логичное развитие инфраструктуры. Возможность использовать прямой воздушный фрикулинг в сочетании с высокой скоростью развертывания стоек сможет позволить российским ЦОДам не просто выживать под давлением новых тарифов, но и строить более маржинальный бизнес.
Отметим, что отсутствие системы механического охлаждения в ЦОД (фрикулинг подразумевает только вентиляцию, без снижения температуры воздуха) повышает и отказоустойчивость инфраструктуры. Отсутствие систем механического охлаждения позволяет кратно снизить количество точек отказа на оборудовании, упростить обслуживание, ремонт и капитальные затраты на строительство. Так как нет зависимости, например, от чиллера (который непременно нужно обслуживать и который является точкой отказа), симплификация системы также упрощает и систему мониторинга ЦОД, снижает нагрузку на персонал и требования к его квалификации. Отдельным пунктом можно добавить снижение зависимости от подрядных организаций, обслуживающих холодильное оборудование, наличия расходников, ЗИП и так далее.
Вывод
Мы переходим от эпохи относительно дешёвых и медленных мегаватт к эпохе их жёсткой утилизации. Архитектура ЦОДа становится активом, который либо приносит прибыль за счёт высокой эффективности и скорости, либо генерирует убытки из-за простоев инфраструктуры, длительного развёртывания ИТ и высокого PUE.
Связка Rack-Scale подхода (OCP) и технологий фрикулинга – это необходимый стандарт для любого игрока, который хочет эффективно конвертировать зарезервированную мощность в реальные деньги. И в этом смысле вопрос уже не в том, использовать ли такие решения, а в том, кто успеет перейти на них раньше ― и тем самым снизить тот самый «налог на неэффективность».
Уже сейчас становится очевидно, что следующая стадия развития ― «эпоха водяного охлаждения». Всё больше компаний разворачивают кластеры с Direct Liquid Cooling (DLC), где тепло снимается напрямую с CPU и GPU с помощью жидкости.
И в этом контексте фрикулинг выглядит не альтернативой, а логичным этапом эволюции после классических «чиллерных» дата-центров. Пока жидкость забирает тепло с самых горячих компонентов, наружный очищенный воздух продолжает эффективно охлаждать остальную инфраструктуру: диски, память и карты расширения.
В результате появляется новая точка роста эффективности: чем глубже интеграция ИТ-оборудования и инженерной инфраструктуры, тем выше экономический эффект.
