Общие сведения о нескольких конфигурациях ролей сервера при планировании загрузки

  • Статья

 

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2016-11-28

В настоящее время к Microsoft Exchange Server 2010 применяются некоторые тенденции в использовании оборудования серверов. Одной из тенденций является значительное повышение производительности процессора и увеличение количества ядер, поддерживаемых физическим процессором. Это значит, что при развертывании одной роли сервера Exchange на обычном сервере, оснащенном многоядерными процессорами, большой объем ресурсов ЦП может быть недогруженным. Некоторые клиенты пытаются повысить эффективность использования ресурсов ЦП сервера за счет виртуализация сервера. Другие пользователи объединяют роли сервера Exchange на одном физическом сервере. Оба решения являются допустимыми.

Другая тенденция — доступность моделей серверов с многоядерными процессорами и 10–16 внутренними дисками. При размещении определенного количества почтовых ящиков в соответствии со скоростью операций ввода-вывода, обеспечиваемой 10–16 дисками, роль сервера почтовых ящиков обычно будет использовать не более половины доступных ресурсов ЦП. Добавление роли сервера клиентского доступа и роли транспортного сервера-концентратора на сервер позволит повысить эффективность использования емкости этого сервера.

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

Содержание

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

Когда рекомендуется использовать конфигурации серверов с несколькими ролями?

Когда не рекомендуется использовать конфигурации серверов с несколькими ролями?

Рекомендации по выбору оборудования для серверов с несколькими ролями

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

Пример определения размера для сценария использования нескольких ролей Exchange 2010

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

Первая и наиболее важная причина заключается в том, что современное оборудование оснащено очень быстрыми процессорами, обеспечивающими 5000–6000 мегациклов, по сравнению с предлагаемой нами базовой конфигурацией. Эта конфигурация состоит из двух 4-ядерных процессоров Intel Xeon x5470 с тактовой частотой 3,33 ГГц. (Дополнительные сведения о предлагаемой нами базовой конфигурации процессоров см. в подразделе "Пример планирования емкости для сервера почтовых ящиков" в разделе Планирование загрузки процессора сервера почтовых ящиков.) Если заменить существующую архитектуру процессоров на процессоры, предлагаемые сейчас на рынке, оставив все остальные факторы среды без изменений, загрузка процессоров значительно сократится.

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

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

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

  • Разверните в системе дополнительные роли сервера Exchange.

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

Развертывание Exchange 2010 с использованием архитектуры с несколькими ролями имеет несколько преимуществ.

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

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

  • Во многих случаях архитектура с несколькими ролями позволяет сократить число физических серверов Exchange в среде. А это приводит к снижению расходов по целому ряду причин.

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

    • Приобретается меньше лицензий на серверы Exchange. Для сервера с несколькими ролями требуется только одна лицензия на сервер Exchange и одна лицензия на операционную систему, в то время как при разделении ролей требуются несколько лицензий на сервер Exchange и, возможно, несколько лицензий на операционную систему. Дополнительные сведения см. в статье Сведения о лицензировании: лицензирование для виртуальных сред (на английском языке).

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

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

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

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

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

Когда рекомендуется использовать конфигурации серверов с несколькими ролями?

Конфигурации с несколькими ролями рекомендуются для большинства сценариев по следующим причинам.

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

  • Крупномасштабные развертывания, требующие использования современных процессоров.   На основе тестирования масштабируемости, проведенного до выхода окончательной первоначальной версии (RTM) Exchange 2010, один сервер с несколькими ролями может эффективно использовать процессор с шестью и более ядрами. Такая емкость позволяет большим организациям сократить число серверов благодаря объединению ролей сервера почтовых ящиков, транспортного сервера-концентратора и сервера клиентского доступа вместо развертывания этих ролей на отдельных серверах, оснащенных процессорами с меньшим числом ядер. В этом подходе используется модель стандартных блоков, описанная выше, с целью обеспечения платформы для крупномасштабных развертываний при сокращении общего числа необходимых серверов. Масштабируемость конфигурации с несколькими ролями в системах, оснащенных процессорами с большим числом ядер, необходимо тестировать в лабораторной среде перед выполнением развертывания в производственной среде.

  • Развертывание серверов с внутренним хранилищем.   Многие современные серверы оснащены двумя физическими многоядерными процессорами и 10–16 внутренними дисками. Некоторые улучшения в Exchange 2010 позволяют снизить требования к системе ввода-вывода и сократить расходы на обслуживание и управление для таких серверов. В зависимости от профиля пользователя и типа диска эти серверы как правило поддерживают до 4000 почтовых ящиков. Рекомендуется добавлять роли сервера клиентского доступа и транспортного сервера-концентратора на такие серверы для использования дополнительных ресурсов ЦП и преобразования серверов в автономные стандартные блоки.

  • Сценарии устранения рисков, в которых количество почтовых ящиков, размещенных на сервере почтовых ящиков, искусственно ограничено.   Серверы с несколькими ролями можно развертывать в случае, когда политики управления рисками ограничивают количество почтовых ящиков, которое можно развернуть на сервере почтовых ящиков. Например, в организации, содержащей 10 000 почтовых ящиков, действует политика, указывающая, что отключение одного сервера не должно повлиять более чем на 25 процентов почтовых ящиков в среде. Такое требование ограничивает количество почтовых ящиков на сервере почтовых ящиков на уровне 2500. Дополнительную емкость на этом сервере можно использовать благодаря добавлению ролей сервера клиентского доступа и транспортного сервера-концентратора на этот сервер.

  • Развертывания в небольших организациях и филиалах.   Кроме указанных ниже ситуаций, в которых используется балансировка сетевой нагрузки Windows, в развертываниях, основной целью которых является сокращение числа физических серверов, экземпляров операционных систем и серверов Exchange, рекомендуется использовать конфигурации с несколькими ролями. Запуск ролей сервера клиентского доступа, транспортного сервера-концентратора и сервера почтовых ящиков на одном физическом сервере позволяет установить все необходимые роли на минимальном количестве физических серверов (2 или 3).

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

Когда не рекомендуется использовать конфигурации серверов с несколькими ролями?

Конфигурации серверов с несколькими ролями не рекомендуется использовать в следующих случаях.

  • Развертывания в небольших организациях или филиалах, в которых планируется использовать балансировку сетевой нагрузки Windows (NLB).   Серверы с несколькими ролями могут работать неэффективно в небольших развертываниях, если два или три таких сервера развертываются в качестве участников группы обеспечения доступности баз данных (DAG). Дополнительные сведения о группах доступности баз данных см. в разделе Управление группами доступности базы данных. Компонент кластеризации, добавленный на серверы почтовых ящиков, входящих в группу доступности баз данных, не позволяет установить на сервер средство балансировки сетевой нагрузки Windows. Дополнительные сведения о рекомендациях по использованию балансировки нагрузки см. в разделе Общие сведения о балансировке нагрузки в Exchange 2010. Тем не менее, требование балансировать нагрузку входящего трафика на серверах клиентского доступа сохраняется. В этом случае существует два основных сценария.

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

    • Виртуализация ролей сервера Exchange. В некоторых средах ограничение количества серверов приводит к необходимости развертывания контроллеров домена, файловых серверов, серверов печати и других приложений на том же физическом оборудовании, на котором размещены серверы Exchange 2010. Рекомендуется внедрять физические серверы в качестве несущих серверов и изолировать приложения в виртуальной среде. Благодаря такой изоляции можно выполнить балансировку сетевой нагрузки Windows для серверов клиентского доступа, запущенных на виртуальных машинах.

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

    ПримечаниеПримечание.
    Роль сервера Exchange нельзя установить на несущем сервере низкоуровневой оболочки. На несущих серверах можно развертывать только программы для управления (например, антивирусные программы, программы резервного копирования или программы управления виртуальной машиной). Никакие другие серверные приложения (например, Exchange, Microsoft SQL Server или Служба каталогов Active Directory) на несущем сервере устанавливаться не должны. Необходимо выделить несущие серверы для запуска ведомых виртуальных машин.

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

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

Рекомендации по выбору оборудования для серверов с несколькими ролями

Обычно рекомендуется определить такой размер сервера с несколькими ролями, который бы позволил использовать половину доступных ядер процессора для роли сервера почтовых ящиков, а другую половину — для ролей сервера клиентского доступа и транспортного сервера-концентратора. Корпорация Майкрософт не определяет максимальное рекомендованное количество ядер процессора для серверов с несколькими ролями. Вместо этого предоставляются рекомендации по максимальному числу заполненных гнезд процессора. Под этим понимается число гнезд процессора на материнской плате, в которые вставлены многоядерные процессоры. Дополнительные сведения см. в разделе Общие сведения о конфигурациях процессоров и производительности Exchange.

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

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

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

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

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

Пример определения размера для сценария использования нескольких ролей Exchange 2010

В следующем примере показан процесс определения размера сервера с несколькими ролями. В этом примере при разработке используются следующие допущения.

  • Общее количество почтовых ящиков   24 000

  • Профиль почтового ящика   100 сообщений, отправляемых или получаемых в день (например, 20 отправляемых и 80 получаемых)

  • Кэш базы данных на каждый почтовый ящик   6 МБ (для профиля 100 сообщений в день)

  • Требования к доступности:   устойчивость работы почтовых ящиков на одном сайте; защита от одновременного сбоя трех копий базы данных и двух серверов.

  • Требования к базе данных:   120 баз данных в группе обеспечения доступности баз данных, 200 почтовых ящиков в каждой базе данных.

  • Серверная платформа:   сервер с двумя 6-ядерными процессорами (X5650) с тактовой частотой 2,26 ГГц (12 ядер).

Применяется следующая процедура.

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

  2. Расчет максимального числа активных почтовых ящиков на каждый сервер в соответствии с моделью активации.   Если предположить, что активные базы данных равномерно распределены между узлами, на каждом сервере в идеале может размещаться 4000 активных почтовых ящиков (24 000 / 6). Чтобы вычислить число активных почтовых ящиков после отказа двух узлов (в рамках данного примера), необходимо разделить число почтовых ящиков на число оставшихся узлов, равное 4. В результате получается 6000 активных ящиков на каждый узел (24 000 / 4).

    В этом примере для параметра MaximumActiveDatabases в командлете Set-MailboxServer настроено значение 30, чтобы обеспечить активацию не более 40 процентов баз данных на одном сервере.

  3. Расчет требований к ЦП для активных почтовых ящиков.   Умножьте максимальное количество активных почтовых ящиков на сервере на число мегациклов для активного почтового ящика (6000 × 2 мегацикла = 12 000 мегациклов) с учетом таблицы Расчетное количество операций ввода-вывода в секунду для одного почтового ящика на основе количества ежедневно отправляемых и получаемых пользователем сообщений и объема кэша базы данных в разделе Общие сведения о кэше базы данных почтовых ящиков. Умножьте это значение на 10 процентов для каждой дополнительной копии базы данных.

    В этом примере для каждой базы данных существует одна активная копия и три пассивные копии, поэтому 12 000 мегациклов увеличиваются на 30 процентов (12 000 × 1,3 = 15 600 мегациклов). Дополнительные сведения см. в подразделе «Показатели кэша базы данных» раздела Общие сведения о кэше базы данных почтовых ящиков.

  4. Расчет требований к ЦП для пассивных почтовых ящиков.   Умножьте количество пассивных почтовых ящиков (когда на сервере размещается максимальное количество активных почтовых ящиков) на количество мегациклов для пассивного почтового ящика (10 000 × 0,3 мегацикла = 3 000 мегациклов) с учетом таблицы Расчетное количество операций ввода-вывода в секунду для одного почтового ящика на основе количества ежедневно отправляемых и получаемых пользователем сообщений и объема кэша базы данных в разделе Общие сведения о кэше базы данных почтовых ящиков. Дополнительные сведения см. в подразделе «Показатели кэша базы данных» раздела Общие сведения о кэше базы данных почтовых ящиков.

  5. Сложение требований к процессору для активных и пассивных почтовых ящиков для расчета общего требования к процессору   В этом примере общее требование к процессору для почтовых ящиков рассчитывается по формуле: 15 600 мегациклов активных почтовых ящиков + 3 000 мегациклов пассивных почтовых ящиков = 18 600 мегациклов.

  6. Применение требований к ЦП для почтовых ящиков к аппаратной платформе.   В этом примере используется сервер с двумя 6-ядерными процессорами (x5650) с тактовой частотой 2,26 ГГц. В соответствии с рекомендациями в разделе Планирование загрузки процессора сервера почтовых ящиков это равнозначно 60 083 мегациклам. Чтобы оценить загрузку ЦП в пиковый период после отказа двух узлов, разделите требуемое число мегациклов на число мегациклов, обеспечиваемое серверной платформой (18 600 / 60 083 = 31 процент прогнозируемой загрузки процессора).

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

  7. Расчет требований к памяти для активного почтового ящика   Умножьте количество активных почтовых ящиков на значение обязательного кэша базы данных для почтового ящика. В этом примере при отказе двух серверов на оставшихся серверах будет размещаться 6000 активных почтовых ящиков (6000 × 6 МБ) / 1024 = 35,1 ГБ. Требования к кэшу базы данных основаны на профиле почтового ящика. Дополнительные сведения см. в подразделе «Показатели кэша базы данных» раздела Общие сведения о кэше базы данных почтовых ящиков.

  8. Применение общих требований к памяти к аппаратной платформе.   Требования к общему объему памяти основаны на требованиях к размеру кэша базы данных и конфигурации серверов (выделенные или с несколькими ролями). Дополнительные сведения см. в таблице Размер кэша базы данных почтовых ящиков по умолчанию в разделе Общие сведения о кэше базы данных почтовых ящиков. Общий объем требуемой памяти для сервера с несколькими ролями в этом примере составляет 52,2 ГБ ((4 ГБ + 35,1 ГБ) / 0.75). Так как значение 52,2 ГБ не является стандартной конфигурацией памяти, значение конфигурации памяти, которую поддерживает текущий сервер, округляется до 64 ГБ.

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

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.