Как подобрать серверное оборудование под задачи компании и не переплатить за лишние ресурсы

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

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

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

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

Поэтому перед сравнением оборудования полезно составить небольшой профиль нагрузки. В него стоит включить:

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

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

Как определить необходимую производительность процессоров

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

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

При оценке процессорной подсистемы проверяют:

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

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

Оперативная память: важны не только гигабайты

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

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

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

Дисковая подсистема должна соответствовать характеру данных

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

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

Тип нагрузки	Что особенно важно	Что проверить
Файловое хранилище	Ёмкость и надёжность хранения	Количество дисковых отсеков, резервирование, скорость сети
Виртуализация	Большое число параллельных операций	Задержки накопителей, производительность массива, возможность расширения
База данных	Низкие задержки и стабильная скорость	Характер чтения и записи, класс накопителей, резервирование
Архив	Стоимость хранения большого объёма	Ёмкость, стратегия резервного копирования, скорость восстановления
Высокопроизводительные задачи	Пропускная способность	Интерфейс накопителей, число устройств, возможности платформы

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

RAID не заменяет резервное копирование

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

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

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

Сеть может ограничить быстрый сервер

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

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

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

Односокетная или двухсокетная платформа

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

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

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

Форм-фактор сервера влияет на всю инфраструктуру

При размещении в стойке часто используются корпуса высотой 1U, 2U и более. Компактность позволяет увеличить плотность оборудования, однако уменьшение корпуса усложняет охлаждение и ограничивает пространство для дисков, плат расширения и крупных компонентов.

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

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

Питание и отказоустойчивость

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

Полезно последовательно искать единичные точки отказа:

1. Определить, какие сервисы должны продолжать работу после отказа одного компонента.
2. Проверить питание серверов, сетевого оборудования и систем хранения.
3. Оценить резервирование сетевых соединений.
4. Проверить дисковую отказоустойчивость и наличие резервных копий.
5. Определить, что произойдёт при отказе самого сервера.
6. Проверить процедуру восстановления, а не только наличие резервных механизмов.

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

Почему важно удалённое управление

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

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

Интерфейс управления нельзя рассматривать как обычный общедоступный веб-сервис. Его следует размещать в защищённом сегменте инфраструктуры, ограничивать доступ и соблюдать принятую в организации политику информационной безопасности.

Охлаждение рассчитывают вместе с вычислительной нагрузкой

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

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

Перед размещением оборудования стоит проверить:

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

Совместимость компонентов проверяют до покупки

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

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

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

Запас производительности должен иметь причину

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

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

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

Когда отдельный физический сервер действительно нужен

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

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

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

Как подготовить техническое задание на сервер

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

Практический порядок подготовки выглядит так:

1. Опишите сервис. Укажите приложения, операционные системы, базы данных и предполагаемый характер использования.
2. Зафиксируйте текущую нагрузку. Если система уже работает, соберите показатели процессора, памяти, дисков и сети в обычные и пиковые периоды.
3. Определите требования к хранению. Нужны текущий объём, темпы роста данных, характер операций и требования к восстановлению.
4. Установите допустимый простой. От этого зависят требования к резервированию компонентов и архитектуре всей системы.
5. Опишите сеть. Укажите необходимые скорости, число соединений и требования к резервированию.
6. Учтите физическую инфраструктуру. Проверьте стойку, глубину корпуса, питание, охлаждение и доступное пространство.
7. Заложите понятный путь расширения. Определите, какие ресурсы вероятнее всего понадобятся дополнительно.
8. Проверьте программные ограничения. Некоторые приложения лицензируются или работают по-разному в зависимости от числа процессоров, ядер и архитектуры системы.

Типичные ошибки при выборе

Ориентация только на характеристики процессора

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

Выбор накопителей только по объёму

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

Отсутствие плана расширения

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

Резервирование одного компонента вместо всей цепочки

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

Покупка максимальной конфигурации «на будущее»

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

Что проверить перед окончательным выбором

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

• Хватает ли процессорных ресурсов именно для используемого программного обеспечения?
• Достаточно ли оперативной памяти во время пиковых нагрузок?
• Соответствует ли дисковая подсистема требуемому числу операций и объёму данных?
• Не станет ли сеть ограничением для хранилища или виртуальных машин?
• Есть ли необходимые свободные слоты и дисковые отсеки для расширения?
• Что произойдёт при отказе накопителя, блока питания, сетевого подключения или всего сервера?
• Соответствуют ли питание и охлаждение реальному энергопотреблению системы?
• Проверена ли совместимость всех компонентов?
• Можно ли обслуживать и диагностировать сервер без длительного физического доступа?
• Понятно ли, какие компоненты потребуется добавить при росте нагрузки?

Практический подход к выбору

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

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

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