Сервер купили с запасом, но мощности не хватает: какие ошибки допускают при выборе конфигурации

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

Ошибка 1. Подбирать сервер по числу сотрудников

«Сервер на 100 пользователей» — недостаточное описание задачи. Сто зарегистрированных учетных записей не равны ста одновременно работающим сотрудникам. При этом несколько аналитиков с тяжелыми запросами могут создавать значительную нагрузку.

До подбора конфигурации нужно определить:

• какие приложения и базы будут размещены;
• сколько пользователей работает одновременно;
• какие операции выполняются в пиковые периоды;
• какие фоновые задания запускаются;
• как растут данные;
• какое время отклика требуется бизнесу.

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

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

Ошибка 2. Оценивать процессор только по числу ядер

Количество ядер важно для параллельной работы, но отдельная операция может зависеть от производительности одного ядра. Не каждый алгоритм способен равномерно распределить вычисления между всеми доступными ресурсами.

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

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

Ошибка 3. Выбирать накопители по объему

Емкость отвечает на вопрос, сколько данных поместится. Она не показывает, как быстро система выполнит операции с ними.

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

У SSD также различаются ресурс записи, устойчивость производительности под длительной нагрузкой и наличие защиты от потери питания. Эти параметры нужно сопоставлять с назначением системы.

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

Ошибка 4. Учесть объем памяти, но забыть о конфигурации

Одинаковый суммарный объем памяти можно набрать разным количеством модулей. От их размещения по каналам и процессорам зависит доступная пропускная способность.

Поэтому формулировки «установить 256 ГБ» недостаточно. Нужно проверить поддерживаемые модули и схему заполнения слотов по документации конкретного сервера.

Для многопроцессорных систем имеет значение и NUMA — организация доступа процессоров к локальной и удаленной памяти. Настройки виртуальных машин следует согласовывать с архитектурой узла. Простое увеличение виртуальных процессоров и памяти не гарантирует ускорения.

Ошибка 5. Сложить нагрузки, не учитывая их совпадение

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

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

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

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

Ошибка 6. Не проверить путь от сервера до пользователя

Быстрое хранилище не устранит ограничение медленного сетевого подключения. Мощный сервер приложений не компенсирует задержки между ним и базой данных.

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

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

Что включить в приемку

Проверка должна подтверждать работу приложений, а не только соответствие установленного оборудования спецификации.

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

Например, договориться о проверке формирования определенного отчета одновременно с типовыми пользовательскими операциями. Конкретные сроки выполнения определяются требованиями компании и подтверждаются испытаниями.

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