Как посчитать ресурсы для Exchange в IaaS

Как посчитать ресурсы для Exchange в IaaS

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

 

Что влияет на CPU, а что — на диски

Размер ящика влияет прежде всего на диски и количество баз. Количество писем в день влияет прежде всего на CPU и на объём логов. Для дисков лучше считать по реальному размеру ящика в ГБ, а для CPU — по профилю сообщений в день и среднему размеру письма.

 

На что сразу ориентироваться по памяти

Для production Mailbox server Microsoft сейчас указывает 128 GB minimum recommended RAM. Поэтому в диапазоне 300–1000 пользователей память чаще всего не «масштабируют по чуть‑чуть», а просто берут 128 GB на каждый Mailbox‑узел как производственный минимум, а дальше уже масштабируют CPU, диски и число серверов. Page file Microsoft рекомендует держать фиксированным, по 25% от установленной памяти.

 

Быстрые формулы, для подсчета размера БД

Для быстрой коммерческой оценки удобно считать так:

Активный объём БД = Кол-во ящиков × размер ящика × коэффициент роста × 1.2

Где:

  • коэффициент роста обычно берут 1.2, если хочется сразу заложить примерно 20% запаса по росту;
  • множитель 1.2 сверху — это рекомендация Microsoft закладывать 120% от расчетного максимального размера БД.

Дальше:

Количество БД = Активный объём БД / целевой размер одной БД

Размер БД, best practices у Microsoft: для standalone  — 200 GB и меньше, а для high availability — до 2 TB на БД.

Ещё одна важная проверка — лицензия сервера. Standard Edition позволяет держать до 5 подключенных БД на сервер, Enterprise Edition — до 100. Поэтому выбор Standard/Enterprise зависит не только от числа пользователей, но и от того, на сколько БД вы делите массив почты.

 

Как быстро смотреть CPU

Microsoft публиковала коэффициенты CPU в megacycles на пользователя в зависимости от числа сообщений в день. Для Exchange family‑калькуляторов можно использовать такую быструю шкалу:

Сообщений в день на ящик Active DB / Standalone Passive DB copy

Сообщений в день на ящик Mcycles на Пользователя, Активная БД Mcycles на Пользователя, Пассивная БД
50 2.99 0.70
100 5.97 1.40
150 8.96 2.10
200 11.94 2.80
250 14.93 3.50
300 17.91 4.20
350 20.90 4.90
400 23.88 5.60
450 26.87 6.30
500 29.85 7.00

Из этого хорошо видно главное правило: если профиль сообщений вырастает с 50 до 100 писем в день, CPU нужен примерно вдвое больше; если до 150 — почти втрое больше. При этом хороший дизайн не должен планироваться «в 100% CPU».

Solo или DAG

Если нужен просто один сервер, это Solo. Если нужен отказоустойчивый вариант, это DAG. Для DAG с чётным количеством узлов обязателен witness server.

С практической точки зрения это значит следующее:

  • Solo дешевле по серверам и storage.
  • 2‑узловой DAG примерно удваивает storage под БД, потому что каждая база хранится в двух копиях.
  • 4‑узла PA(Preferred Architecture) примерно учетверяет storage под БД.

Это уже чистая арифметика поверх количества копий. Под логи Microsoft рекомендует закладывать запас как минимум на 3 дня.

 

Базовый пример

Ниже примеры с такими допущениями:

  • 5 GB на один ящик;
  • 50 писем в день на ящик;
  • 20% запас на рост;
  • целевой размер активной БД — 500 GB;
  • production‑подход по памяти — 128 GB RAM на каждый Mailbox‑узел;
    объём OS‑диска и служебных томов в цифры ниже не включён.
    Числа по vCPU ниже — это практический стартовый ориентир, выведенный из опубликованных Microsoft коэффициентов CPU, требования не уходить в 100% CPU и текущей рекомендации по памяти; финально их надо прогонять через Exchange Sizing Calculator.

 

300 пользователей

Solo

  • 1 Mailbox VM
  • 4 vCPU
  • 128 GB RAM
  • активный DB‑объём: 300 × 5 × 1.2 × 1.2 = 2.16 TB
  • примерно 5 БД по 500 GB или 3 БД по 1 TB

DAG

  • 2 Mailbox VM + witness
  • на каждом узле: 4 vCPU / 128 GB RAM
  • активных БД всё так же примерно 5 или 3
  • физических копий уже 10 или 6, поэтому только под БД нужно около 4.32 TB

Для 2‑node DAG witness обязателен, потому что это чётное число узлов.

500 пользователей

Solo

  • 1 Mailbox VM
  • 6 vCPU
  • 128 GB RAM
  • активный DB‑объём: 500 × 5 × 1.2 × 1.2 = 3.60 TB
  • примерно 4 БД по 1 TB

DAG

  • 2 Mailbox VM + witness
  • на каждом узле: 6 vCPU / 128 GB RAM
  • активных БД: примерно 4
  • физических копий: 8
  • storage только под БД: около 7.20 TB


1000 пользователей

Solo

  • 1 Mailbox VM
  • 8 vCPU
  • 128 GB RAM
  • активный DB‑объём: 1000 × 5 × 1.2 × 1.2 = 7.20 TB
  • примерно 8 БД по 1 TB

DAG

  • 2 Mailbox VM + witness
  • на каждом узле: 8 vCPU / 128 GB RAM
  • активных БД: примерно 8
  • физических копий: 16
  • storage только под БД: около 14.40 TB

Для такого объёма Enterprise Edition уже неизбежен, так как лимит для Standard Edition 5 активных БД. А если нужен вариант ближе к Microsoft Preferred Architecture, то надо не 2, а минимум 4 Exchange‑сервера и 4 копии БД, то есть порядка 28.8 TB только под DB‑тома.

  • exchange
  • 0 משתמשים שמצאו מאמר זה מועיל
?האם התשובה שקיבלתם הייתה מועילה

מאמרים קשורים

Диагностика проблем со скоростью Интернет

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

Cloud4Y RDP Connect to Terminal Mini-HowTo

Как подключится к рабочему терминальному серверу Компании Для работы в корпоративных системах...

Интерактивная схема по категориям

В данной статье располагается интерактиваня схема для поиска ответа на часто задаваемые вопросы....

Как открыть тикет в техническую поддержку?

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

Расширенный вопросник по производительности при подаче заявки в тикет-систему

Расширенные вопросы и проблемы с производительностью. В случае, если вы замечаете какие-то...