Планирование мощности ЦОД на 3 года: прогноз CPU, RAM и Storage

Что дает 3-летний прогноз и где обычно ошибаются

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

Главная ошибка - заменить прогноз одной цифрой вроде «берем +30%». CPU, RAM, хранилище и сеть растут по разным причинам и с разной скоростью. Новая аналитическая витрина может почти не добавить CPU, но резко увеличить RAM и IOPS. А подключение филиалов иногда упирается в порты и uplink, даже если серверов стало ненамного больше.

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

Удобнее сразу разделить планирование по ресурсам: CPU (пик и средняя загрузка), RAM (реальное потребление, а не выделение), storage (емкость, IOPS и скорость), сеть (пропускная способность и количество портов). Цель - понятный запас под рост и новые проекты без переплаты и без риска простоев. Для госорганизаций и крупных предприятий это особенно важно: сроки закупок и согласований часто длиннее, чем рост нагрузки.

Какие данные собрать перед расчетами

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

Начните с инвентаризации, но не «по названиям», а по ресурсам и зависимостям. Зафиксируйте серверы и кластеры, гипервизоры и версии, СХД и схему подключения, коммутаторы и скорости портов, uplink и их фактическую загрузку. Отдельно отметьте, где заканчиваются стойки, порты, лицензии, гарантии и поддержка.

Дальше нужны исторические метрики минимум за 3-6 месяцев, лучше за год: средние значения мало что говорят без пиков и трендов. Смотрите пики CPU, потребление RAM, задержки и IOPS на хранилище, заполнение пулов, сетевой трафик на uplink и между сегментами. Отметьте сезонность (например, отчетные периоды) и регулярные «всплески» от бэкапов.

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

• схема текущей инфраструктуры и критичных сервисов;
• пики и 95-й перцентиль, плюс тренды по CPU, RAM, storage и сети;
• планы бизнеса (новые системы, рост пользователей, требования ИБ);
• физические лимиты (питание, охлаждение, место, сроки поставки);
• требования по доступности (N+1, репликация, DR, окна простоя).

Простой пример: если планируется внедрение SIEM и хранение логов 12 месяцев, рост будет не только по емкости. Увеличатся IOPS и сеть (сбор, нормализация, репликация). Эти требования лучше получить от владельца проекта заранее, до того как вы раздадите одинаковый «запас» всем ресурсам.

Модель роста: драйверы, сценарии и допущения

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

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

Обычно драйверы такие: пользователи и рабочие места (VDI, филиалы), транзакции и операции (CRM/ERP, онлайн-каналы), данные (логи, видео, архивы, аналитика), новые сервисы (контейнеры, AI-пилоты, интеграции).

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

• Базовый: рост по текущим планам бизнеса.
• Оптимистичный: быстрее растут пользователи или запускаются дополнительные сервисы.
• Стресс-сценарий: проекты задерживаются, но внезапно появляются требования по безопасности, хранению или отказоустойчивости.

Отдельно отметьте «ступени» роста: внедрение ERP, массовый переход на VDI, подключение видеопотоков, запуск AI-инференса, открытие филиалов. Эти события дают скачок по CPU/RAM/storage/сети и редко укладываются в плавную кривую.

В конце зафиксируйте допущения: что считается верным (например, «+500 пользователей к Q4», «репликация 2x», «retention логов 180 дней») и кто подтверждает это - владелец сервиса, ИБ, владелец данных, архитектура, финансы. Без этих подтверждений прогноз быстро теряет смысл.

CPU: как прогнозировать и какой запас закладывать

С CPU чаще всего путаются из-за терминов. Физические ядра (cores) дают базовую производительность. Потоки (threads) через Hyper-Threading/SMT помогают не всегда и не в каждой нагрузке. vCPU в виртуализации - это единица планирования, а не гарантия скорости. Заранее договоритесь, в каких единицах считаете (например, pCPU-ядра и частота) и какая загрузка в пике считается допустимой.

Ориентируйтесь на пики, а не на среднее за месяц. Если бухгалтерия «взлетает» в конце месяца, а BI строит отчеты утром, именно эти окна и будут задавать требования. Практика, которая обычно работает: считать 95-й или 99-й перцентиль по кластерам и отдельно фиксировать «самые тяжелые» дни (закрытие периода, регламентные расчеты).

Не забывайте про неизбежные накладные расходы: гипервизор, агенты безопасности, мониторинг, резервное копирование, системные службы. Даже 5-10% сверху иногда решают, будет ли кластер жить спокойно или постоянно упираться в потолок.

Запас по CPU обычно складывается из двух частей: резерв на отказ узла и плановые работы (N+1, иногда N+2 для критичных кластеров) и резерв на рост нагрузки с порогом по пиковому utilization (например, держать пик не выше 60-70%).

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

RAM: учет реального потребления и рисков overcommit

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

Начните со сравнения: сколько RAM выдали системам и сколько они реально берут. Делайте это не по отдельным серверам, а по группам: базы данных, виртуализация, VDI, прикладные сервисы, инфраструктура (AD, мониторинг, бэкапы). Так быстрее видно, где есть безопасная подушка, а где память постоянно на грани.

Что обычно раздувает потребление RAM

Рост памяти редко бывает линейным. Чаще он идет скачками из-за кэшей, индексов и новых функций.

Типовые причины: увеличение кэша и параллелизма в БД, новые модули и очереди в приложениях, рост числа VM и требований к HA, утяжеление VDI-профиля (браузер, видеозвонки), а также агенты безопасности (EDR, шифрование, сканирование).

Overcommit: где риск становится реальным

Overcommit по памяти может работать в спокойные дни, но ломается в трех ситуациях: пики, массовые перезапуски и миграции VM (например, при обслуживании хоста или отказе узла). Если кластер рассчитан впритык, миграция нескольких крупных VM может упереться в нехватку RAM и сорвать план восстановления.

Практичное правило: отдельно считайте «обычную» нагрузку и «стресс-сценарий» (пик плюс N-1 по хостам). Для баз данных и VDI делайте отдельную оценку: эти нагрузки часто плохо переносят агрессивный overcommit.

Не забудьте резерв под обновления ОС и платформ. Новые версии нередко требуют больше памяти, а добавление агентов безопасности и мониторинга на сотни VM дает заметный суммарный рост. Этот резерв почти всегда «съедается» без предупреждения.

Storage: емкость, IOPS и влияние бэкапов и репликации

В хранилище важно разделять два вопроса: сколько данных (TB) и насколько быстро они читаются и пишутся (IOPS и MBps). Частая ошибка - посчитать только емкость и потом удивляться, что диски «вроде не забиты», а приложения тормозят.

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

Отдельно посчитайте «надстройки», которые часто удваивают (и больше) потребность: логи и телеметрия (особенно при более подробном аудите), бэкапы и snapshots вместе со сроками хранения, репликацию на второй сайт и DR (плюс сетевой трафик).

Дальше разделите данные по температурам: «горячие» (нужны IOPS и низкие задержки) и «холодные» (важнее TB). Это помогает выбрать уровни хранения: быстрый пул для критичных систем и более емкий для архивов и бэкапов.

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

Заложите резерв не только на рост, но и на восстановление после инцидента и тестовые среды. Если у вас 50 TB рабочих данных, 30 дней бэкапов и реплика на второй площадке, реальная потребность по емкости легко вырастает до 150-250 TB. По IOPS критичными часто становятся окно ночных бэкапов и утренний старт виртуальных машин.

Сеть: как прогнозировать пропускную способность и порты

Сеть в ЦОД часто «ломает» план, потому что рост трафика не всегда виден по внешним каналам. Начните с разделения потоков: east-west (внутри ЦОД) и north-south (к пользователям, филиалам, интернету). Обычно быстрее растет именно east-west из-за микросервисов, виртуализации, кластеров и внутренних API.

Для прогноза смотрите не среднее, а пики: 95-й или 99-й перцентиль по интерфейсам и очередям на портах. Отдельной строкой добавьте «скрытый» трафик, который растет вместе с инфраструктурой: бэкапы, репликация, snapshots, журналы, мониторинг, обновления.

Проверьте сеть по трем уровням: uplink на серверах, агрегация (leaf), ядро (spine/core). Узкое место часто не в общей пропускной способности, а в нехватке портов нужной скорости или в перегрузе конкретных uplink.

Короткая проверка перед расчетом:

• посчитайте пиковый east-west и north-south и отметьте сезонность (конец месяца, ночные окна);
• оцените вклад бэкапов и репликации и время их работы;
• проверьте запас по портам 10/25/100G и что можно занять без перестройки;
• учтите накладные расходы сегментации и безопасности (ACL, экраны, шифрование, инспекция);
• заложите «лестницу скорости», чтобы перейти на более быстрые интерфейсы без замены всего слоя.

Пример: при добавлении кластера аналитики внешняя нагрузка может вырасти на 10%, а внутренние пересылки данных между узлами - в 2 раза. В таком случае прогноз должен включать не только гигабиты, но и план по портам и обновлению интерфейсов.

Резерв под новые проекты: как не переплатить и не рискнуть

Резерв нужен не «на всякий случай», а под конкретные неизвестные. Сначала выпишите «известные неизвестные»: новые сервисы для клиентов, требования регуляторов, интеграции с внешними системами, рост отчетности, импортозамещение, миграции между площадками. Такой список помогает спорить не про проценты, а про реальные события.

Дальше определите логику резерва. Фиксированный буфер (например, +20% к CPU/RAM и +30% к хранилищу) проще, но часто ведет к переплате. Практичнее считать буфер по классу нагрузок: для БД важнее IOPS и задержка, для VDI и аналитики - RAM и GPU, для файловых сервисов - емкость и скорость роста.

Хорошо работает «портфель» резерва: небольшой быстрый пул для пилотов на 4-8 недель, плановый резерв на 6-12 месяцев под масштабирование одобренных инициатив, отдельный запас по сети (порты, uplink, лицензии), и резерв по хранению с учетом бэкапов и репликации.

Чтобы резерв не «съели» случайно, закрепите правила входа проекта в ЦОД: минимальные требования, шаблон заявки, сроки подтверждения, кто дает приоритет. И держите план форс-мажора (например, рост в 2 раза за квартал): какие узлы расширяем первыми, что переносим в другой кластер, что докупаем.

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

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

Шаги расчета

1. Снимите базовую линию и инвентаризацию. Соберите фактическое потребление CPU, RAM, дисков (занято и прирост), IOPS/задержки, сетевой трафик. Добавьте список серверов, гипервизоров, СХД, коммутаторов и версий ПО. Базу лучше брать минимум за 4-8 недель, чтобы увидеть типичные пики.

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

3. Посчитайте потребность по периодам. Для каждого квартала посчитайте CPU и RAM (с учетом реального utilization и политики overcommit), storage (емкость плюс IOPS), сеть (Gbps и количество портов). На выходе должна получиться таблица «было - станет».

4. Добавьте резерв, но с правилами. Учтите N+1/отказы, сезонные пики, окна бэкапов и репликации, а также пул под проекты, который можно быстро выделить. Формулировка должна быть конкретной: «базовая потребность на Q3 + резерв на пик + резерв на запуск CRM».

5. Проверьте физические ограничения и превратите расчет в план. Сверьте стойки, питание, охлаждение, запас по портам и uplink, а также сроки поставок. Затем разбейте закупки и внедрение на этапы: что нужно сейчас, что через 12-18 месяцев, что можно отложить при низком сценарии.

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

Частые ошибки и ловушки при планировании

Самая распространенная ошибка - «средняя температура по больнице». Средняя загрузка CPU 20% выглядит безопасно, но если в конце месяца или в рабочие часы пики доходят до 85-95%, пользователи уже видят тормоза. На горизонте нескольких лет важнее понимать пики и их причины, чем красивые средние цифры.

Вторая ловушка - смешивать тестовые и продуктивные нагрузки в одном расчете. Тестовые стенды живут рывками: сегодня почти ноль, завтра прогон релиза «съедает» ресурсы и сеть. В итоге вы либо переплачиваете за железо под редкие всплески, либо рискуете продуктивом.

Часто недооценивают рост данных «сбоку»: логи приложений, аудит, мониторинг, метрики, SIEM. Команда включает более подробное логирование для расследований, и объем под логи за год удваивается, плюс растут IOPS на запись. Если это не заложить, место закончится неожиданно, хотя «бизнес-данных» почти не прибавилось.

Еще одна проблема - недооценить отказоустойчивость и реальные окна обслуживания. План «впритык» ломается при любом ремонте узла или обновлении гипервизора: кластер должен переживать N+1 (а иногда и N+2), и это влияет на CPU, RAM, сеть и storage.

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

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

Чеклист перед утверждением бюджета

Перед тем как подписывать бюджет, убедитесь, что вы опираетесь на факты, а не на ощущения.

Метрики должны быть не за «пару недель», а хотя бы за 6-12 месяцев, чтобы увидеть сезонность и пики. Для CPU и RAM важно разделять среднее и 95-й перцентиль, а для storage - рост данных и нагрузку (IOPS) в рабочие часы.

Проверьте, что прогноз разложен по периодам (кварталы или полугодия) и что запас задан явно: что относится к обязательному росту, а что является резервом под новые проекты.

• есть исторические метрики и понятны пики по CPU/RAM/storage/сети минимум за 6-12 месяцев;
• согласованы 3 сценария и список проектов с датами запуска и владельцами;
• по каждому ресурсу есть прогноз по периодам и отдельной строкой указан резерв и его причина;
• проверены лимиты площадки: питание, охлаждение, стойки/юниты, порты, uplink, лицензии;
• назначены точки пересмотра (раз в квартал или раз в полгода) и критерии старта следующей закупки.

Пример критерия: «если в базовом сценарии загрузка кластера держится выше 70% по CPU или RAM два месяца подряд, а запуск нового проекта меньше чем через 90 дней - запускаем закупку». Если вы завязаны на сроки производства и поставки, такие триггеры особенно важны.

Пример сценария: рост пользователей и запуск новых сервисов

Представим компанию, где число пользователей растет на 20% в год, а в течение 12 месяцев открываются еще 3-4 филиала. Параллельно запускаются два проекта: VDI для части сотрудников (150-200 рабочих мест) и новая аналитическая платформа для отчетов и витрин данных. Этот пример хорошо показывает, почему нельзя считать только CPU.

Разложите рост на два блока: базовый рост (пользователи и филиалы) и рост от проектов (VDI и аналитика). Базовый рост обычно добавляет умеренно CPU и RAM, но заметно увеличивает трафик в WAN/LAN и объемы данных (почта, файлы, журналы, резервные копии).

VDI часто дает резкий скачок по RAM и IOPS. Даже если средняя загрузка CPU на виртуальных рабочих столах невысокая, пики по диску случаются при массовых логинах, обновлениях и антивирусных проверках. Аналитика, наоборот, может быть терпима к CPU в обычные дни, но потребует быстрых дисков и хорошей сети при загрузке данных, репликации и обновлении витрин.

Поэтому в расчетах нередко получается, что storage и сеть растут быстрее CPU: объем данных тянет за собой бэкапы, копии для теста, репликацию и журналирование, а сеть растет из-за филиалов, VDI-трафика и обмена между узлами кластера.

Резерв удобно разделить на два слоя: N+1 для кластера (пережить отказ одного узла без деградации) и отдельный буфер под пилоты (обычно 10-20% по ключевым ресурсам) с четким правилом, когда он считается «съеденным».

Оформляйте результат не общими цифрами, а таблицей по кварталам: CPU, RAM, полезная емкость, IOPS/throughput, порты/скорость. Рядом добавьте «точки расширения», например: докупить 1 серверный узел при достижении 70-75% RAM кластера; расширить пул SSD при росте задержек или IOPS выше целевого уровня; увеличить пропускную способность uplink при стабильно высоких пиках; добавить емкость под бэкапы и репликацию; зарезервировать место и питание под следующий шаг в стойке.

Следующие шаги: из прогноза в план модернизации и закупок

Когда расчеты готовы, их нужно превратить в план, который выдержит бюджетный комитет и не развалится при первом же новом проекте. Соберите итоговую таблицу по CPU, RAM, storage (емкость и IOPS) и сети (пропускная способность и порты) по годам. Рядом поставьте текущие лимиты и реальную утилизацию, чтобы увидеть разрыв: где не хватает ресурса уже сейчас, а где дефицит появится через 12-24 месяца.

Дальше разложите действия по скорости и риску. Обычно удобны два горизонта: быстрое расширение, чтобы закрыть ближайшие 3-6 месяцев, и плановая модернизация, чтобы не покупать в панике. Быстрые меры - добавить узлы, диски, лицензии, увеличить uplink, переразложить нагрузки. Плановые - обновить поколения серверов, расширить СХД, пересобрать сеть уровня ToR/агрегации, подготовить новые стойки. И обязательно назначьте контрольные точки: пересчет прогноза раз в квартал и пересмотр сценариев при изменении проектов.

Привяжите каждую покупку к метрике из прогноза, а не к ощущению «нужно больше железа». Заранее согласуйте операционные детали: сроки поставки, окна монтажа, план миграций и требования к поддержке 24/7. Отдельно зафиксируйте критерии приемки (тесты производительности, отказоустойчивость, мониторинг).

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