Как подобрать серверное оборудование под задачи компании и не ошибиться с конфигурацией

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

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

Сначала определите, какую работу будет выполнять сервер

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

Для первичного проектирования полезно разделить нагрузки на несколько типов:

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

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

Почему нельзя выбирать сервер только по процессору

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

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

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

Оперативную память нужно считать по рабочей нагрузке

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

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

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

Дисковая подсистема: ёмкость — только один из параметров

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

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

Не путайте RAID и резервное копирование

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

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

Проверяйте возможность дальнейшего расширения

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

Сеть должна соответствовать скорости серверов и хранилища

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

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

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

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

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

Сценарий	Что проверить в первую очередь	Типичный компромисс
Компактное размещение	Плотность оборудования, охлаждение, доступные слоты	Экономия места может ограничивать расширение
Большое количество накопителей	Число отсеков, контроллеры, питание	Корпус занимает больше пространства
Установка ускорителей	Габариты карт, слоты, питание, воздушный поток	Повышаются требования к электропитанию и охлаждению
Универсальный корпоративный сервер	Память, диски, сеть, резервирование	Приходится искать баланс между ресурсами

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

Охлаждение нельзя оставлять на последний этап

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

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

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

Резервирование нужно строить от допустимого времени простоя

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

После этого рассматривают потенциальные точки отказа:

• блоки питания;
• накопители;
• сетевые соединения;
• коммутаторы;
• система хранения;
• сам сервер;
• электропитание помещения;
• система охлаждения.

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

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

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

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

Особого внимания требуют:

• совместимость процессоров с системной платой и её поколением;
• поддерживаемые типы и схемы установки оперативной памяти;
• доступные линии и слоты расширения;
• поддержка выбранных накопителей и интерфейсов;
• возможности RAID- или HBA-контроллеров;
• достаточность и совместимость блоков питания;
• физические размеры дополнительных плат;
• требования компонентов к охлаждению;
• поддержка оборудования операционной системой и используемым ПО.

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

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

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

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

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

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

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

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

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

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

Когда полезнее несколько серверов вместо одного большого

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

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

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

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

Типичные ошибки при закупке

Максимальная производительность одного компонента

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

Заполнение всех возможностей платформы сразу

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

Игнорирование инфраструктуры

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

Путаница между резервированием и резервной копией

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

Выбор без учёта обслуживания

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

Что проверить перед согласованием спецификации

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

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

Как проверить сервер после получения

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

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

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

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

Как принять решение без переплаты за ненужные ресурсы

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

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

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