Сервер для корпоративной почты: как подобрать железо под нагрузку

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

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

Когда собственный почтовый сервер не нужен

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

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

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

Что собрать для расчёта нагрузки

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

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

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

Платформа задаёт требования к серверу

Разные почтовые продукты нельзя рассчитывать по одному шаблону. Требования к операционной системе, памяти, процессорам и способу хранения определяются конкретной поддерживаемой версией. У Microsoft для Exchange опубликованы системные требования и матрица совместимости; использовать старую памятку администратора вместо текущей документации недостаточно.

Для нового проекта на Exchange сначала проверьте актуальную ветку продукта и условия её обслуживания. Microsoft сообщает о завершении поддержки Exchange Server 2016 и 2019 и указывает Exchange Server Subscription Edition среди вариантов перехода. Нельзя считать старую установку подходящей для нового развёртывания только потому, что оборудование её запускает. См. матрицу поддерживаемых конфигураций Exchange и дорожную карту завершения поддержки.

У связки отдельных Linux-компонентов также есть требования: формат ящиков, индексы, фильтры, база пользователей и интерфейс веб-почты нужно рассматривать совместно. Например, Dovecot предупреждает, что в формате dbox индексы содержат важные данные о сообщениях и их потеря может привести к потере данных. Поэтому нельзя заранее объявить все индексные файлы восстанавливаемым кэшем. Это зависит от формата и версии: документация Dovecot dbox.

Как считать ёмкость почтового хранилища

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

Например, 100 ящиков с квотой 10 ГБ дают 1000 ГБ суммарных квот. Это только арифметический лимит содержимого ящиков, а не готовая ёмкость дисковой подсистемы. Прибавлять к нему универсальный процент «на всё» некорректно: логи, индексы, архив, реплики и правила хранения считают по выбранной системе и измеренной нагрузке.

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

Процессор, память, диски и виртуализация

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

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

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

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

Доставка писем зависит не только от железа

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

SPF описывает разрешённых отправителей домена, DKIM позволяет проверять подпись сообщений, а DMARC связывает проверку домена с политикой обработки. Эти механизмы не равны шифрованию содержимого письма и не заменяют защиту аккаунтов. Изменения DNS и почтового маршрута выполняют по отдельному плану миграции с проверкой действующих сервисов; экспериментировать с ними при выборе оборудования не нужно.

Резервирование и проверка восстановления

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

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

Что включить в заявку на подбор

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

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

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

Частые вопросы

Можно выбрать сервер только по числу сотрудников?

Нет. Нужны платформа, объём и рост ящиков, функции обработки, активность в пике и требования к восстановлению. Число сотрудников — один из исходных параметров.

Обязательно ли ставить отдельный физический сервер?

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

RAID достаточно для защиты корпоративной почты?

Нет. Он не заменяет отдельные резервные копии и проверку восстановления после удаления, повреждения данных или компрометации.

Мощный сервер гарантирует доставку писем?

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

Авторство и источники

Автор: Сергей Коваль, коммерческий директор ANDPRO. Материал подготовлен при участии AI-ассистента по документации Microsoft, Google и Dovecot; собственные испытания почтовых систем и личное техническое рецензирование не заявлены. Факты сверены 26 октября 2026 года.

Не назначен; отдельное личное техническое рецензирование не проводилось.