Как выбрать сервер для среднего и крупного бизнеса

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

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

Перед заказом необходимо зафиксировать:

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

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

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

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

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

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

Для расчёта конфигурации нужно собрать данные по каждому сервису:

1. Название системы: 1С, CRM, ERP, SQL Server, PostgreSQL, файловое хранилище, почта, видеонаблюдение, виртуализация.
2. Количество одновременных пользователей.
3. Требования разработчика к CPU, оперативной памяти и накопителям.
4. Текущая загрузка существующего сервера, если он уже используется.
5. Объём базы данных и прогноз её роста.
6. Требования к времени восстановления после сбоя.
7. Требования к доступности: рабочие часы, круглосуточная работа, филиалы, удалённые сотрудники.

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

Процессор определяет, сколько параллельных задач сервер сможет обрабатывать. Для серверов среднего и крупного бизнеса чаще используют процессоры Intel Xeon Scalable или AMD EPYC, поскольку они поддерживают большой объём оперативной памяти, серверные интерфейсы, многопроцессорные конфигурации и технологии виртуализации.
При выборе CPU важны не только ядра, но и характер нагрузки.

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

Оперативная память влияет на стабильность корпоративных приложений, баз данных и виртуальных машин. Недостаток RAM заставляет сервер чаще обращаться к накопителям, из-за чего снижается скорость работы даже при мощном процессоре.
Для виртуализации память рассчитывают не только по текущему потреблению виртуальных машин. Нужно учесть ресурсы гипервизора, резерв для пиковых нагрузок и возможность запуска критичных виртуальных машин на другом узле при отказе одного сервера.
Практическое правило: конфигурация должна иметь свободные слоты для расширения RAM. Если сервер уже при покупке заполнен памятью до предела, дальнейшее масштабирование может потребовать замены установленных модулей, а не простого добавления новых.
Если сервер нужен для SQL, 1С, ERP или CRM, нельзя экономить на памяти без предварительного расчёта. Для таких систем медленная работа часто связана не с процессором, а с тем, что база данных не помещается в оперативной памяти и постоянно обращается к дисковой подсистеме.

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

Для корпоративной инфраструктуры обычно используют серверные SSD, SAS SSD, SAS HDD или NVMe SSD. Выбор зависит от типа нагрузки.

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

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

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

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

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

Виртуализация позволяет разместить несколько независимых систем на одном или нескольких физических серверах. Например, отдельно запустить сервер 1С, SQL-сервер, контроллер домена, файловый сервер, CRM и систему резервного копирования.

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

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

• сколько виртуальных машин будет работать сейчас;
• сколько виртуальных машин появится в течение 2–3 лет;
• сколько vCPU и RAM требуется каждой виртуальной машине;
• какие ВМ являются критичными;
• нужна ли высокая доступность;
• где будут храниться диски виртуальных машин;
• какой объём резервных копий потребуется;
• какая скорость сети нужна между серверами, СХД и резервным хранилищем.

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

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

• минимум два блока питания в сервере при наличии соответствующих источников питания;
• подключение блоков питания к разным ИБП или линиям электропитания;
• ИБП с корректно рассчитанным временем автономной работы;
• сетевые интерфейсы с резервированием;
• управляемые коммутаторы и достаточную пропускную способность;
• удалённое администрирование через BMC - например, iDRAC, iLO или аналогичные решения;
• контроль температуры, питания, состояния дисков и ошибок оборудования.

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

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

1. Какие программы будут работать на сервере?
2. Сколько одновременных пользователей и виртуальных машин планируется?
3. Какие сервисы нельзя останавливать?
4. Какой объём данных есть сейчас и каким будет через 2–3 года?
5. Какие требования предъявляет используемое ПО?
6. Нужны ли SSD, SAS или NVMe-накопители?
7. Какая схема RAID подходит для конкретной нагрузки?
8. Где и как будут храниться резервные копии?
9. Есть ли резервирование блоков питания, ИБП и сетевых подключений?
10. Можно ли расширить память, дисковую подсистему и вычислительную мощность?
11. Нужен ли один сервер, второй резервный сервер или полноценный кластер?
12. Кто будет обслуживать оборудование и восстанавливать сервисы при сбое?