Как посчитать запас мощности сервера и защитить бюджет

Рабочая конфигурация укладывается в согласованные 700 000 ₽. После слов «нужен запас на три года» цена вырастает до 910 000 ₽. Финансист видит доплату 210 000 ₽ и спрашивает: что компания покупает за эти деньги?

Ответ «сервер на вырост» бюджет не защищает. Разделите доплату между процессором, памятью, дисками и возможностью расширения. У каждой позиции появятся исходная нагрузка, формула и цена.

Цены ниже взяты из условного коммерческого предложения. Это не статистика рынка и не ориентир для конкретной модели. В своём расчёте замените их ценами поставщика.

Процент запаса сам по себе ничего не объясняет #

Допустим, замеры рабочего сервера показали:

• занято 16 процессорных ядер;
• используется 128 ГБ оперативной памяти;
• данные занимают 8 ТБ полезной ёмкости.

Компания ожидает рост нагрузки и принимает запас 25% как внутреннее правило для этой закупки. Коэффициент отражает прогноз компании, а не требование производителя.

Расчёт даёт 20 ядер: 16 × 1,25 = 20. Для памяти получается 160 ГБ: 128 × 1,25 = 160.

Коммерческое предложение может не содержать такую конфигурацию. Поставщик подбирает процессор из доступных моделей с заданным числом ядер, а память — из совместимых модулей по допустимой для сервера схеме. В нашем примере ближайший вариант содержит 24 ядра и 192 ГБ RAM.

После округления фактический резерв вырос до 50%:

• CPU: (24 − 16) / 16 × 100% = 50%;
• RAM: (192 − 128) / 128 × 100% = 50%.

Компания оплачивает не коэффициент 1,25, а конкретный процессор и набор модулей. Перед заказом сверьте их с руководством к выбранному PowerEdge. На портале поддержки Dell собраны документы по установке, обслуживанию и устранению неисправностей серверов.

Если сервер работает с 1С, сначала разделите нагрузку СУБД, серверной части и терминальных сессий. Иначе общий коэффициент скроет ошибку в исходных данных. Начать можно с отдельного расчёта процессора, памяти и дисков под 1С.

Дискам нужен прогноз в терабайтах, а не коэффициент #

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

Сейчас занято 8 ТБ. Каждый месяц база, файлы и журналы добавляют 200 ГБ, то есть 0,2 ТБ. На три года потребуется:

8 + 0,2 × 36 = 15,2 ТБ

Если объём растёт на 400 ГБ в месяц, расчёт меняется:

8 + 0,4 × 36 = 22,4 ТБ

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

Полученные 15,2 или 22,4 ТБ — требование к полезной ёмкости массива. Число физических дисков зависит от уровня RAID, ёмкости накопителей и выбранного сценария восстановления.

Hot spare вынесите в отдельную строку расчёта как резервный накопитель. Не прибавляйте его номинальную ёмкость к доступному пространству, пока не проверите итоговую конфигурацию массива на выбранном контроллере. Порядок замены и варианты настройки разобраны в материале про hot spare и горячую замену.

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

Запас на рост не спасает при отказе узла #

Свободные ресурсы внутри одного сервера принимают новую нагрузку, но не заменяют второй узел, резервное питание или отдельную копию данных.

Для примера зададим внутреннее требование: пара узлов должна продолжить работу после отказа одного сервера. Тогда оставшийся узел обязан вместить обе нагрузки.

Если каждый сервер загружен на 40%, после переноса расчётная загрузка составит 40% + 40% = 80%. До номинального предела останется 20 процентных пунктов.

При загрузке каждого узла на 60% арифметическая сумма даст 120%. В таком сценарии один сервер не вместит обе исходные нагрузки в пределах принятой мощности. Придётся остановить часть служб, допустить снижение производительности либо заранее увеличить ресурсы узлов.

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

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

Доплата 210 000 ₽ раскладывается на четыре покупки #

Вернёмся к условному предложению. Рабочая конфигурация стоит 700 000 ₽. Поставщик добавил:

Доплата	Что меняется	Цена
Процессорный резерв	16 → 24 ядра	90 000 ₽
Резерв памяти	128 → 192 ГБ	45 000 ₽
Дисковая часть	Ёмкость под трёхлетний рост	60 000 ₽
Путь следующего апгрейда	Шасси с нужными отсеками и возможностями расширения	15 000 ₽
Итого		210 000 ₽

Полная цена составит 700 000 + 210 000 = 910 000 ₽. Доплата равна 210 000 / 700 000 × 100% = 30%.

Строка «запас» распалась на три понятных назначения:

• 135 000 ₽ — дополнительные ядра и память;
• 60 000 ₽ — рост объёма данных;
• 15 000 ₽ — следующее расширение без замены шасси.

Расчёт не доказывает, что все четыре доплаты нужны. Он показывает цену каждого решения.

Если нагрузка стабильна, часть вычислительного резерва можно убрать. Если сервер заменят через два года, диски не нужно считать на три. Если в шасси уже хватает отсеков и слотов, доплата 15 000 ₽ теряет основание.

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

Что заложить в этот сценарий #

При исходной нагрузке 16 ядер, 128 ГБ RAM и 8 ТБ данных с приростом 200 ГБ в месяц расчёт даёт:

• 24 ядра после округления до доступной конфигурации;
• 192 ГБ RAM;
• не менее 15,2 ТБ полезной ёмкости на три года;
• отдельную проверку нагрузки после отказа, если один сервер должен принять работу второго.

По условному предложению такой набор увеличивает бюджет с 700 000 до 910 000 ₽. Доплата — 210 000 ₽, или 30%.

Для стабильной нагрузки можно проверить сценарий с внутренним коэффициентом 1,15: 16 ядер превратятся в 18,4, а 128 ГБ RAM — в 147,2 ГБ до округления. Для ожидаемого роста повторите расчёт с 1,25. Оба коэффициента — допущения компании, поэтому приложите к ним замеры и прогноз.

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

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