Расчет для ЦОД: строительство дата-центров как искусство нахождения баланса между запросами бизнеса

Как отмечает генеральный директор «Запуск Групп» Алексей Равинский, объем российского рынка коммерческих дата-центров вырос с 43 млрд рублей в 2020 году до 113,1 млрд в 2024-м, и спрос превышает предложение.

Все правильно рассчитать

Но проектирование и строительство ЦОД — нетривиальная задача. Для их стабильной работы нужны обработка больших массивов данных и в обязательном порядке бесперебойное функционирование сервисов. Компании, которые ранее не задумывались о таких услугах, сегодня строят собственные ЦОД или арендуют мощности. Но тут возникает сразу несколько вопросов: какой запас мощности должен быть у ЦОД, как не переплатить за его проект на старте, что нужно предусмотреть, чтобы затем не переделывать?

Дело в том, что в ЦОД-проектах площадка, рассчитанная на текущую нагрузку, через 2-3 года потребует дорогостоящей модернизации, а избыточный запас мощности увеличивает стоимость проекта. Поэтому ключевая задача — найти баланс между возможностью роста и экономической целесообразностью, то есть нужно правильно заложить запас мощности при проектировании дата-центра и грамотно связать требования бизнеса с инженерной инфраструктурой, чтобы в случае необходимости обеспечить масштабирование проекта без переплат.

Следует четко понимать, где проходит граница между надежностью и переплатой. Ведь при проектировании ЦОД запас мощности определяют не максимально возможной нагрузкой, а прогнозом развития IT-систем на ближайшие 3-5 лет, и попытка сразу построить инфраструктуру под «идеальное будущее» приводит к замороженным инвестициям: оборудование закуплено, мощности зарезервированы, но фактически простаивают.

Оптимальный подход — рассчитывать конфигурацию ЦОД, исходя из текущей нагрузки с учетом резерва на отказоустойчивость. Обычно резерв закладывают на уровне схем резервирования, например, N+1, когда к необходимому количеству оборудования добавляется один дополнительный элемент на случай отказа. Такой запас обеспечивает стабильную работу без значительного увеличения стоимости проекта.

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

Граница между надежностью и переплатой проходит там, где резерв перестает реально обеспечивать SLA (соглашение об уровне доступности сервисов) и становится просто страховкой от роста, который не подтвержден бизнес-планом.

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

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

Требования бизнеса и инженерная инфраструктура

Проектирование ЦОД — не только инженерное решение. Даже технически корректно реализованная площадка может оказаться неэффективной, если на этапе планирования не были четко сформулированы требования бизнеса.

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

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

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

Масштабирование без капитальной перестройки

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

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

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

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

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

Поэтому запас мощности — это не перестраховка, а управляемый параметр проекта с конкретной стоимостью и конкретной отдачей. «По нашему опыту, резерв 20-30% по электропитанию и охлаждению при модульном вводе окупается за 2-3 года за счет отсутствия переделок. Все, что выше этого резерва, требует обоснования в бизнес-плане, а все, что ниже, — прямой путь к реконструкции», — резюмировал Алексей Равинский.