Как рассчитать конфигурацию сервера под свои задачи?

Правильную конфигурацию сервера рассчитывают не от бюджета и не от количества сотрудников, а от реальной нагрузки. Сервер для 1С, сервер виртуализации, сервер баз данных и файловый сервер используют ресурсы по-разному, поэтому универсальной конфигурации «на 50 или 100 пользователей» не существует. Перед подбором сервера нужно определить приложения, число одновременно работающих пользователей, объём данных, характер операций, пиковую нагрузку и ожидаемый рост системы

Назначение сервера определяет, какой компонент станет главным ограничением производительности. Сервер баз данных обычно чувствителен к производительности накопителей, задержкам и объёму RAM; сервер виртуализации требует большого количества процессорных ядер и памяти; файловый сервер зависит прежде всего от ёмкости дисков и скорости сети; сервер 1С чувствителен не только к количеству CPU, но и к производительности отдельных ядер и дисковой подсистемы.

Для расчёта сервера желательно заранее собрать пять показателей:

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

Именно пиковая нагрузка должна быть ориентиром для сервера. Сервер, который в среднем загружен на 30%, может несколько раз в день достигать 100% CPU или I/O и именно в эти моменты создавать задержки для сотрудников.

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

Если существующий сервер уже работает, приблизительное фактическое потребление CPU можно оценить:

Используемые ядра = число физических ядер × загрузка CPU / 100
Например, сервер с 16 физическими ядрами при устойчивой нагрузке 70% использует примерно:
16 × 0,7 = 11,2 ядра

Новый сервер нельзя выбирать просто на 12 ядер. Серверу потребуется резерв для пиков нагрузки и дальнейшего роста, поэтому при сопоставимой производительности процессоров разумно рассматривать следующую ступень конфигурации.

Тактовые частоты процессора сервера складывать нельзя. Формула «16 ядер × 3 ГГц = 48 ГГц» технического смысла практически не имеет, потому что производительность сервера зависит от архитектуры процессора, IPC, частоты, числа ядер, кеша и характера программной нагрузки. Процессоры разных поколений с одинаковыми 3 ГГц могут показывать заметно различающуюся производительность.

Оперативная память сервера должна покрывать одновременно работающие приложения и оставлять резерв под пики и рост. Для обычного физического сервера можно использовать базовую формулу:
RAM сервера = ОС + приложения + рабочие данные + резерв

Для сервера виртуализации расчёт другой:
RAM сервера = память гипервизора + сумма RAM виртуальных машин + резерв

Например, если сервер виртуализации должен запустить четыре виртуальные машины по 16 ГБ и две виртуальные машины по 32 ГБ, сами виртуальные машины потребуют:
4 × 16 + 2 × 32 = 128 ГБ RAM

К 128 ГБ серверу виртуализации необходимо добавить память для гипервизора и резерв для новых виртуальных машин.

Количество RAM сервера - только половина расчёта, потому что важна ещё схема установки DIMM. Серверные процессоры используют несколько каналов памяти, поэтому неудачное размещение модулей может снизить пропускную способность памяти даже при правильном общем объёме. Конкретные правила зависят от платформы: производители прямо рекомендуют заполнять определённые каналы симметрично и предупреждают, что несбалансированные конфигурации могут работать менее эффективно.

Поэтому сервер на 256 ГБ RAM нельзя автоматически считать одинаковым по производительности с другим сервером на 256 ГБ RAM - количество модулей, число занятых каналов и распределение памяти между процессорами тоже имеют значение.

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

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

Например, сервер может хранить базу 500 ГБ, но если большая часть запросов постоянно обращается только к 80–100 ГБ активных таблиц и индексов, именно рабочий набор сильнее влияет на фактическую потребность в RAM.

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

Будущий объём данных сервера можно приблизительно оценить:
Объём через N лет = текущий объём × (1 + ежегодный рост)^N
Например, сервер хранит 4 ТБ данных, а объём увеличивается примерно на 20% ежегодно:
4 × 1,2² = 5,76 ТБ

Следовательно, через два года серверу потребуется минимум около 5,76 ТБ только под исходные данные. Серверу дополнительно понадобится место для журналов, временных файлов, снимков, служебных данных и свободного пространства.

Тип накопителей сервера выбирают по характеру операций, а не только по цене одного терабайта. HDD подходят серверу для архивов, резервных копий и хранения большого объёма редко используемых данных. SATA/SAS SSD подходят серверу со средней интенсивностью I/O. NVMe имеет смысл для сервера баз данных, виртуализации и других нагрузок, где критичны высокая производительность и низкая задержка.

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

RAID сервера нужно выбирать исходя из требований к скорости, полезной ёмкости и допустимому простою. RAID 1 подходит серверу, где требуется простое зеркалирование двух накопителей. RAID 10 подходит серверу баз данных и интенсивной записи, когда необходимы производительность и резервирование. RAID 5 или RAID 6 могут быть оправданы в сервере хранения, но итоговый выбор зависит от размера массива, характера записи, времени восстановления и допустимого риска.

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

Сетевой интерфейс сервера рассчитывают по объёму данных, который требуется передать за определённое время. Если одно активное соединение потребляет 25 Мбит/с, а одновременно сервер обслуживает 40 таких соединений:
25 × 40 = 1000 Мбит/с

Теоретически получается 1 Гбит/с, но серверу не стоит проектировать сеть вплотную к этому значению, потому что остаются накладные расходы протоколов и другие потоки данных.
Для резервного копирования сервер можно считать от допустимого времени передачи. Если сервер должен передать 500 ГБ за два часа:
500 × 8 = 4000 Гбит
4000 / 7200 секунд ≈ 0,56 Гбит/с

Серверу понадобится не менее 560 Мбит/с полезной пропускной способности только для этой операции, поэтому интерфейс 1 GbE уже оставляет сравнительно небольшой запас.

Серверу нужен 10 GbE не потому, что 10 Гбит/с «быстрее», а когда фактические потоки приближаются к возможностям 1 GbE. Сервер виртуализации, сервер резервного копирования, сервер видеонаблюдения и сервер, активно работающий с отдельной СХД, довольно быстро могут выйти за пределы гигабитной сети.

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

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

При выборе SSD для сервера стоит смотреть на показатели допустимой записи, например TBW или DWPD, а также на наличие защиты от потери питания, если такие требования есть у конкретной системы.

Хорошая конфигурация сервера должна оставлять пространство для модернизации. Сервер, в котором при покупке заняты все DIMM-слоты, дисковые корзины и PCIe-разъёмы, может оказаться дешевле сегодня, но гораздо дороже при первом расширении.

Перед покупкой сервера проверьте:

• свободные DIMM-слоты;
• максимальный объём RAM;
• количество свободных дисковых отсеков;
• поддержку NVMe;
• свободные PCIe-слоты;
• возможность установки второй сетевой карты;
• поддержку второго процессора, если второй CPU действительно может понадобиться;
• мощность и резервирование блоков питания.

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

• четыре VM: 4 vCPU и 16 ГБ RAM каждая;
• две VM: 8 vCPU и 32 ГБ RAM каждая.

Номинальный объём ресурсов сервера составит:
CPU: 4 × 4 + 2 × 8 = 32 vCPU
RAM: 4 × 16 + 2 × 32 = 128 ГБ

Но физический сервер нельзя автоматически комплектовать 32 физическими ядрами и 128 ГБ памяти. Нужно учитывать реальную одновременность нагрузки, допустимый CPU overcommit, память гипервизора, дисковый I/O, NUMA и резерв на рост. Microsoft также рекомендует определять количество виртуальных процессоров по измеренной нагрузке и увеличивать количество vCPU при необходимости под пиковыми нагрузками, а не просто выдавать каждой VM максимум возможных ресурсов.

Самый точный расчёт сервера начинается с измерений существующей или тестовой системы. Если действующий сервер уже работает, нужно собирать показатели CPU, RAM, IOPS, latency, сети и длительность пиковых периодов. Если сервер создаётся для новой системы, полезнее провести нагрузочное тестирование или использовать данные максимально похожей рабочей инфраструктуры, чем подбирать оборудование по количеству сотрудников.

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

Конфигурацию сервера нужно считать от нагрузки, а не от названия процессора или количества сотрудников. Сначала определите, какие приложения будут работать на сервере и какое узкое место они создают, затем рассчитайте CPU, RAM, накопители, RAID и сеть, проверьте каналы памяти, NUMA, лицензирование и возможность апгрейда. Такой подход позволяет избежать двух крайностей: сервера, который тормозит бизнес уже после запуска, и сервера, половина мощности которого была куплена впустую.