Сервер под 1С или виртуализацию уже согласован, но поставщик меняет состав, срок поставки и условия ремонта. Процессор, память и диски выбраны правильно — купить исходную конфигурацию всё равно не получается.
В исследовании MWS Cloud 71% из 503 участников назвали хотя бы одну сложность при закупке или эксплуатации собственного оборудования. Это около 357 респондентов: 503 × 0,71 ≈ 357. Чаще всего им мешали цена техники — 28%, обновление и ремонт — 19%, поиск нужной конфигурации и дефицит запчастей — по 18%.
Эти цифры меняют сам вопрос закупки. Защищать нужно не только производительность сервера, но и его путь от заказа до последнего ремонта: можно ли получить согласованный состав, куда расширять память и диски, сколько ждать блок питания или контроллер при отказе.
71% — не довод отказаться от своего сервера
Показатель MWS Cloud объединяет разные проблемы. Складывать 28% стоимости, 19% ремонта, 18% конфигурации, 18% запчастей и 17% нехватки инженеров нельзя: один участник мог выбрать несколько ответов.
Исследование также не доказывает, что облако само по себе устраняет закупочные риски. Хотя бы одну сложность назвали 72% компаний с гибридной инфраструктурой и 69% пользователей публичного облака. Разница — три процентных пункта.
Своё оборудование остаётся оправданным для постоянной и предсказуемой нагрузки: баз 1С, файловых служб, виртуальных рабочих мест. Но прежняя схема «рассчитали сервер на пять лет и купили» больше не закрывает поставку, расширение и ремонт.
Низкая цена поставки может дорого обойтись при первом отказе
Стоимость оборудования беспокоит 28% участников исследования MWS Cloud. Однако рядом стоят расходы, которые проявятся после покупки: 19% респондентов упомянули обновление или ремонт, 18% — дефицит запчастей, 17% — нехватку инженеров.
Поэтому сравнивай не две цены сервера, а два сценария его эксплуатации. В расчёт входят совместимые модули памяти и диски, резервный блок питания, контроллер, срок поставки запасных частей и предел расширения платформы.
Например, поставщик предлагает машину на 128 ГБ дешевле альтернативы на 12%. Но у первой заняты все разъёмы памяти, а для перехода на 256 ГБ придётся снять установленные модули. Экономия исчезнет при первом расширении. Процент в этом примере — допущение; проверяемый критерий другой: сколько свободных разъёмов останется после поставки и какие модули придётся заменить при росте.
Если новая платформа не помещается в бюджет, имеет смысл отдельно проверить, сколько риска добавляет восстановленный сервер. Сравнение должно учитывать не возраст корпуса, а состояние накопителей, доступность совместимых узлов, гарантию и срок замены отказавшей детали.
Гибридная схема не отменяет дефицит оборудования
Компании с гибридной инфраструктурой чаще пользователей публичного облака называли стоимость оборудования проблемой: 34% против 21%. Для поиска нужной конфигурации соотношение составило 23% против 12%, для дефицита запчастей — 22% против 13%.
Эти данные не назначают архитектуру. Они показывают, что гибридная схема сохраняет закупочные риски той части инфраструктуры, которая стоит у компании.
Разделяй нагрузки по характеру потребления. Постоянные базы и виртуальные машины можно считать под свой сервер. Редкие задачи на дорогих ускорителях требуют отдельного сравнения покупки с арендой. Для них полезнее считать загрузку GPU-узла, при которой владение начинает окупаться, чем автоматически добавлять ускорители в общую конфигурацию.
Тот же принцип работает с хранилищем. Если объём данных растёт независимо от вычислительной нагрузки, не закладывай весь рост в локальные дисковые корзины. Сначала задай полезную ёмкость, число операций чтения и записи, время восстановления массива. Такой подход подробно разобран в материале о том, как превратить требования к СХД в измеримые параметры.
Планировать стоит платформу, а не неизменную конфигурацию
В опросе MWS Cloud 48% участников ожидают роста цен на оборудование в ближайшие 12 месяцев. Это ожидание респондентов, а не прогноз стоимости. Покупать сервер раньше срока только из-за этой цифры не следует.
Горизонт планирования уже сократился. В исследовании «Инфосистемы Джет» о зрелости ИТ в российских компаниях в 2025 году 42% участников планировали развитие ИТ на три года, 29% — на два года и 20% — на пять лет. До 2022 года обычным горизонтом были пять лет.
Из этого следует практичное требование: текущая конфигурация закрывает известную нагрузку, а платформа позволяет расширить её на горизонте двух-трёх лет. Поставщик должен подтвердить этот путь конкретными разъёмами, отсеками, портами и совместимыми модулями.
Фраза «сервер можно масштабировать» ничего не обещает. В спецификации должны стоять пределы: поставляем 128 ГБ в четырёх модулях, остаётся четыре разъёма; устанавливаем четыре накопителя, свободно ещё четыре отсека; используем два сетевых порта, ещё два доступны без замены платы.
Спецификация под типовую нагрузку
Без числа пользователей, состава виртуальных машин и профиля дисковых операций нельзя назначить модель сервера для конкретной компании. Но можно показать, как требования к поставке выглядят на типовом сценарии.
Возьмём офис с 60 сотрудниками. На сервере работают десять виртуальных машин: одна с базой, одна с сервером приложений, остальные восемь обслуживают файловые, служебные и внутренние системы. Это допущение для расчёта, а не готовая конфигурация для любого офиса.
Процессор
Предположим, каждой из десяти машин назначено по 4 vCPU. Получаем 40 vCPU. При переподписке 2,5:1 требуется 40 ÷ 2,5 = 16 физических ядер. Добавляем четыре ядра под гипервизор и пики нагрузки — получаем один процессор на 20 ядер.
В требованиях к закупке стоит указать один сокет, 20 физических ядер и базовую частоту от 3,0 ГГц. Частота здесь — нижняя граница, принятая для сценария с чувствительной к скорости ядра базой. Если нагрузка состоит из множества независимых виртуальных машин, сравнивай варианты с большим числом ядер по результатам испытания своей системы.
Память
Считаем по назначенным объёмам: 48 ГБ для базы, 16 ГБ для сервера приложений и по 8 ГБ для восьми остальных машин. Получается 48 + 16 + 8 × 8 = 128 ГБ.
Ещё 32 ГБ оставляем гипервизору и файловому кэшу. Текущая потребность — 160 ГБ. В поставку разумно заложить 192 ГБ ECC RDIMM, собранные так, чтобы после установки остались свободные разъёмы. Предел расширения платформы — не менее 384 ГБ: это удвоение расчётной потребности с запасом в 64 ГБ.
Накопители
Допустим, база занимает 600 ГБ, остальные машины — 800 ГБ, а рабочий запас под снимки и рост составляет ещё 600 ГБ. Всего нужно 2 ТБ полезной ёмкости.
Четыре NVMe по 1,92 ТБ в RAID10 дадут около 3,84 ТБ до учёта служебных накладных расходов массива. Это закрывает исходные 2 ТБ и оставляет около 1,84 ТБ под рост и временные копии.
Для загрузочного тома достаточно двух отдельных SSD в RAID1. Такое разделение не ускоряет базу само по себе, зато обслуживание системного тома не затрагивает рабочий массив.
Сеть, питание и корпус
Для этого сценария закладываем два порта 10 Гбит/с под рабочий трафик и резервирование. Если резервные копии уходят в отдельное хранилище, добавляем ещё два порта либо выделенную сетевую карту.
Два блока питания с горячей заменой позволяют пережить отказ одного блока без остановки сервера. Мощность выбирают после расчёта процессора, накопителей и плат расширения; само число ватт без состава оборудования ничего не доказывает.
Корпус — 2U минимум с восемью отсеками под накопители. Четыре займёт RAID10, четыре останутся под расширение или замену массива без смены платформы.
Получается такая отправная конфигурация:
- один процессор: 20 ядер, базовая частота от 3,0 ГГц;
- 192 ГБ ECC RDIMM с возможностью расширения минимум до 384 ГБ;
- четыре NVMe по 1,92 ТБ в RAID10 под данные;
- два SSD в RAID1 под систему;
- четыре порта 10 Гбит/с либо два встроенных и свободный разъём под сетевую карту;
- два блока питания с горячей заменой;
- корпус 2U минимум с восемью дисковыми отсеками.
Её компромисс — запас по памяти, отсекам и сети оплачивается сразу, хотя может не понадобиться. Более дешёвая машина закроет текущую нагрузку, но потребует замены модулей или всей платформы при росте.
Если число vCPU удвоится, при той же переподписке потребуется 80 ÷ 2,5 = 32 физических ядра плюс ресурс гипервизора. Если объём базы вырастет вдвое, четырёх накопителей может хватить по ёмкости, но решение нужно принимать после проверки задержек и числа операций ввода-вывода. Если остановка сервиса недопустима, один сервер уже не закрывает требование: понадобится второй узел и отдельный расчёт отказоустойчивости.
Что потребовать от поставщика
Покупай не «сервер на пять лет», а платформу с проверяемым путём расширения и ремонта. В обосновании закупки зафиксируй пять вещей:
- нагрузку, которая остаётся на своём оборудовании;
- текущую конфигурацию и предел роста памяти, дисков и сетевых портов на два-три года;
- допустимый срок ремонта и замены критичного узла;
- доступность совместимых накопителей, памяти, блоков питания и контроллеров;
- нагрузки, которые можно временно или постоянно вынести в облако.
Если поставщик не подтверждает согласованный состав и запасные части, сравни другую платформу. Если бюджет не сходится — проверь восстановленную машину. Если оборудование требуется для коротких пиков — посчитай аренду отделяемой нагрузки. Так решение переживёт не только согласование, но и первый отказ.
