Проверенные решения на базе Exchange 2010: 32400 почтовых ящиков на трех площадках с Hyper-V на блейд-серверах Cisco Unified Compute с хранилищем EMC CLARiiON Storage

 

Последнее изменение раздела: 2016-12-14

Роб Симпсон, руководитель программы, Microsoft Exchange; Борис Воронин, старший инженер по решениям, Exchange Solutions Engineering, EMC; Майк Манковски, архитектор решений Microsoft, Cisco

Дата

Июнь 2011 года

Протестированные решения для Exchange 2010

В материалах серии "Протестированные решения для Exchange 2010" специалисты Майкрософт и участвующих в проекте компаний-партнеров (из отраслей серверных решений, хранения данных и сетевых технологий) рассматривают распространенные сценарии и ключевые аспекты проектирования, с которыми встретятся клиенты, планирующие развернуть Microsoft Exchange Server 2010. В этих технических документах приводятся примеры хорошо спроектированных и экономически выгодных решений Exchange 2010, развернутых на оборудовании, которое предлагают некоторые наши партнеры из отраслей серверных решений, хранения данных и сетевых технологий.

Этот документ можно загрузить из Центра загрузки Майкрософт.

Применяется к

Microsoft Exchange Server 2010 с пакетом обновления 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

Содержание

• Введение

• Сводная информация о решении

• Требования клиента

  • Требования к профилю почтового ящика

  • Требования к географическому расположению

  • Требования к серверам и защите данных

• Предположения при разработке

  • Предположения относительно конфигурации сервера

  • Предположения относительно конфигурации хранилища

• Проектирование решения

  • Определение стратегии высокой доступности

  • Ожидаемые требования к емкости хранилища почтовых ящиков

  • Ожидаемые требования к системе ввода-вывода почтовых ящиков

  • Определение типа хранилища

  • Выбор между хранилищами DAS и SAN

  • Выбор хранилища

  • Ожидаемые требования к объему памяти для почтового ящика

  • Расчет требуемого размера кэша базы данных

  • Ожидаемые требования к процессору для почтовых ящиков

  • Сводные требования для почтовых ящиков

  • Выбор модели сервера

  • Расчет мощности процессора выбранной модели сервера

  • Определение необходимого количества физических серверов почтовых ящиков

  • Определение количества активных почтовых ящиков на каждом сервере почтовых ящиков для сценариев нормальной работы и сбоя

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

  • Определение необходимого количества комбинаций физических серверов клиентского доступа и транспортных серверов-концентраторов

  • Определение общего количества физических серверов

  • Определение необходимости применения виртуализации серверов

  • Определение возможности использования виртуализации для сокращения количества физических серверов

  • Расчет мощности ЦП корневого сервера Hyper-V

  • Корректировка числа доступных мегациклов для служебных данных виртуализации

  • Определение мощности ЦП виртуальных машин

  • Проверка мощности ЦП виртуальных машин основного сервера почтовых ящиков

  • Проверка мощности ЦП виртуальных машин дополнительного сервера почтовых ящиков

  • Определение объема памяти, необходимого для каждой виртуальной машины основного сервера почтовых ящиков

  • Определение объема памяти, необходимого для каждой виртуальной машины дополнительного сервера почтовых ящиков

  • Определение объема памяти, необходимой для совместного использования сервера клиентского доступа и транспортного сервера-концентратора

  • Определение объема памяти, необходимого для каждого корневого сервера Hyper-V

  • Проектирование групп обеспечения доступности баз данных

  • Проектирование структуры копий баз данных

  • Режим координации активации центра данных

  • Определение размещения следящего файлового ресурса

  • Планирование пространств имен

  • Определение массива серверов клиентского доступа и стратегии балансировки нагрузки

  • Определение модели аппаратной балансировки нагрузки

  • Определение конструкции хранилища

• Обзор решения

  • Схема логического решения

  • Схема физического решения

  • Таблица конфигурации корневого сервера Hyper-V

  • Конфигурация сервера клиентского доступа и транспортного сервера-концентратора

  • Конфигурация сервера почтовых ящиков

  • Структура базы данных

  • Сводные данные об оборудовании хранилища

  • Конфигурация хранилища

• Методология проверки решения

  • Методология проверки макета хранилища

  • Проверка макета сервера

  • Функциональные проверочные тесты

  • Проверка переключения базы данных

  • Проверка переключения сервера

  • Проверка отказоустойчивости сервера

  • Проверка переключения центра данных

  • Проверка восстановления служб основного центра данных

  • Место проведения теста

• Результаты проверки решения

  • Результаты функциональных проверок

  • Результаты проверки макета хранилища

  • Результаты проверки макета сервера

• Заключение

• Дополнительные сведения

Введение

В этом документе приводится пример проектирования, тестирования и проверки решения Exchange Server 2010, работающего под управлением Windows Server 2008 R2 с использованием технологии Hyper-V. Решение предназначается для клиентской среды с 32 400 почтовыми ящиками, развернутой на блейд-серверах Cisco Unified Computing System и хранилищах EMC CLARiiON. Одна из основных задач при разработке крупных сред Exchange 2010 — анализ доступных вариантов серверной инфраструктуры и хранилищ, а также принятие правильного решения по выбору оборудования, которое будет наиболее выгодным в течение всего ожидаемого срока эксплуатации решения. В этом документе пошагово описываются ключевые решения и аспекты проектирования, которые помогают решить вышеозначенные задачи и при этом выполнить все требования, предъявляемые базовыми бизнес-процессами клиента. Когда оптимальное решение для конкретного клиента выбрано, оно проходит стандартную проверку. Этот процесс включает эмуляцию нагрузки и проводится со сценариями нормальной работы, технического обслуживания и сбоя.

Протестированные решения для Exchange 2010

Сводная информация о решении

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

Компоненты Exchange

Компонент Exchange	Значение или описание
Целевое число почтовых ящиков	32400
Средний целевой размер почтового ящика	2 гигабайта (ГБ); тонкая подготовка при начальном размере 600 мегабайт (МБ)
Средний целевой профиль использования	100 сообщений в день
Число копий базы данных	3
Резервное копирование службы теневого копирования томов (VSS)	Нет
Устойчивость работы производственных площадей	Да
Количество производственных площадей	3
Модель группы обеспечения доступности баз данных	Распределение "активный-активный" с несколькими группами обеспечения доступности баз данных
Виртуализация	Hyper-V
Число серверов Exchange	4 виртуальные машины (ВМ)
Число физических серверов	2

Компоненты оборудования

Компонент оборудования	Значение или описание
Партнер — производитель сервера	Cisco
Модель сервера	M200
Тип сервера	Блейд-сервер
Процессор	Intel Xeon X5570
Партнер — производитель хранилища	Консоль управления Exchange
Модель хранилища	CX4-480
Тип хранилища	Сеть хранения данных (SAN)
Тип диска	450 ГБ; 15 000 об/мин; SAS; 3,5"
Партнер — производитель системы балансировки нагрузки	Cisco
Модель балансировки нагрузки оборудования	ACE

Протестированные решения для Exchange 2010

Требования клиента

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

Протестированные решения для Exchange 2010

Требования к профилю почтового ящика

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

Требования к количеству почтовых ящиков

Требование к количеству почтовых ящиков	Значение
Количество почтовых ящиков (общее число, включая почтовые ящики ресурсов)	30000
Прогнозируемый рост (в %) количества почтовых ящиков (ожидаемое увеличение их числа в течение срока эксплуатации решения)	8%
Ожидаемый % одновременного доступа к почтовым ящикам (максимальное число активных почтовых ящиков в любой отдельный момент времени)	100%
Целевое число почтовых ящиков (их количество, включая произведение процента роста и параметра одновременного доступа)	32400

Требования к размеру почтовых ящиков

Требование к размеру почтовых ящиков	Значение
Средний размер почтового ящика, МБ	600 МБ
Средний размер архива почтового ящика, МБ	Неприменимо
Прогнозируемый рост (в %) размера почтового ящика (ожидаемое увеличение размера в течение срока эксплуатации решения), МБ	230%
Целевой средний размер почтового ящика, МБ	2048 МБ

Требования к профилю почтового ящика

Требование к профилю почтового ящика	Значение
Целевой профиль использования (среднее общее число сообщений, отправленных и принятых пользователем в день)	100 сообщений в день
Целевой средний размер сообщения в килобайтах (КБ)	75
% в режиме кэширования MAPI	100
% в оперативном режиме MAPI	0
% в режиме кэширования Outlook Anywhere	0
% в Microsoft Office Outlook Web App (Outlook Web Access в Exchange 2007 и предыдущих версиях)	0
% в Exchange ActiveSync	0

Протестированные решения для Exchange 2010

Требования к географическому расположению

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

В следующей таблице описано географическое распределение пользователей системы Exchange.

Географическое распределение пользователей

Требование к производственным площадям, где находятся пользователи почтовых ящиков	Значение
Количество основных производственных площадей, где находятся пользователи почтовых ящиков	3
Число пользователей, работающих на площадке 1	10800
Число пользователей, работающих на площадке 2	10800
Число пользователей, работающих на площадке 3	10800

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

Географическое распределение центров данных

Требование к местонахождению центров данных	Значение
Общее количество центров данных	3
Количество активных почтовых ящиков вблизи центра данных 1	10800
Количество активных почтовых ящиков вблизи центра данных 2	10800
Количество активных почтовых ящиков вблизи центра данных 3	10800
Требуется ли, чтобы система Exchange находилась в нескольких центрах данных	Да

Протестированные решения для Exchange 2010

Требования к серверам и защите данных

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

В следующей таблице перечислены требования к защите сервера.

Требования к защите сервера

Требование к защите сервера	Значение
Число одновременных сбоев сервера или ВМ в пределах производственной площади	1
Число одновременных сбоев сервера или ВМ во время отказа на уровне производственной площади	0

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

Требования к защите данных

Требование к защите данных	Значение или описание
Требуется ли поддерживать резервную копию баз данных Exchange вне среды Exchange (например, с помощью решения резервного копирования стороннего производителя)	Нет
Требуется ли поддерживать копии баз данных Exchange в среде Exchange (например, с помощью собственной системы защиты данных Exchange)	Да
Требуется ли поддерживать несколько копий данных почтового ящика в основном центре данных	Да
Требуется ли поддерживать несколько копий данных почтового ящика в дополнительном центре данных	Нет
Требуется ли поддерживать изолированную копию какой-либо базы данных Exchange	Нет
Период изолированной копии, дней	Неприменимо
Целевое число копий базы данных	3
Срок хранения папки "Удаленные", дней	14

Протестированные решения для Exchange 2010

Предположения при разработке

В этот раздел включены параметры, которые обычно не относятся к требованиям клиента, однако являются критически важными во время проектирования и при выборе подхода проверки решения.

Протестированные решения для Exchange 2010

Предположения относительно конфигурации сервера

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

Целевая загрузка сервера

Предположение при разработке о целевой загрузке ЦП сервера	Значение
Нормальный рабочий режим, серверы почтовых ящиков	<70%
Нормальный рабочий режим, серверы клиентского доступа	<70%
Нормальный рабочий режим, транспортные серверы-концентраторы	<70%
Нормальный рабочий режим, несколько ролей сервера (комбинации ролей транспортного сервера-концентратора, сервера клиентского доступа и сервера почтовых ящиков)	<70%
Нормальный рабочий режим, несколько ролей сервера (комбинации ролей транспортного сервера-концентратора и сервера клиентского доступа)	<70%
Сбой узла, серверы почтовых ящиков	<80%
Сбой узла, серверы клиентского доступа	<80%
Сбой узла, транспортные серверы-концентраторы	<80%
Сбой узла, несколько ролей сервера (комбинации ролей транспортного сервера-концентратора, сервера клиентского доступа и сервера почтовых ящиков)	<80%
Сбой узла, несколько ролей сервера (комбинации ролей транспортного сервера-концентратора и сервера клиентского доступа)	<80%
Сбой производственной площади, серверы почтовых ящиков	<80%
Сбой производственной площади, серверы клиентского доступа	<80%
Сбой производственной площади, транспортные серверы-концентраторы	<80%
Сбой производственной площади, несколько ролей сервера (комбинации ролей транспортного сервера-концентратора, сервера клиентского доступа и сервера почтовых ящиков)	<80%
Сбой производственной площади, несколько ролей сервера (комбинации ролей транспортного сервера-концентратора и сервера клиентского доступа)	<80%

Протестированные решения для Exchange 2010

Предположения относительно конфигурации хранилища

В следующих таблицах приведены предположения о конфигурации данных и системе ввода-вывода, принятые при проектировании конфигурации хранилища.

Предположения о конфигурации данных

Предположение о конфигурации данных	Значение или описание
Фактор служебных данных	20%
Перемещение почтовых ящиков (в неделю)	1%
Выделенное обслуживание или восстановление номера логического устройства (LUN)	Нет
Свободное пространство LUN	20%
Включено ли сжатие доставки журналов	Да
Включено ли шифрование доставки журналов	Да

Предположения о конфигурации системы ввода-вывода

Предположение о конфигурации системы ввода-вывода	Значение или описание
Фактор служебных данных системы ввода/вывода	20%
Дополнительные требования к системе ввода-вывода	Нет

Протестированные решения для Exchange 2010

Проектирование решения

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

Протестированные решения для Exchange 2010

Определение стратегии высокой доступности

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

• Общие сведения о факторах высокой доступности

• Планирование высокой доступности и устойчивости сайтов

• Общие сведения об архивации, восстановлении и аварийном восстановлении

Действие 1. Определение необходимости обеспечить устойчивость производственных площадей

Если центров данных несколько, нужно определить, как будет развернута инфраструктура Exchange: в одном или в нескольких центрах данных. В соглашениях об уровне обслуживания (SLA) организации по вопросу восстановления следует определить, какой уровень требуется при сбоях в основном центре данных. Эта информация должна стать основой для принятия этого решения.

*Момент принятия решения*

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

Действие 2. Определение взаимосвязи между местоположениями пользователей почтовых ящиков и расположением центров данных

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

*Момент принятия решения*

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

Действие 3. Определение модели распределения базы данных

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

• Распределение "активный/пассивный". В основном центре данных развертываются активные копии баз данных, а в дополнительном — только пассивные копии. Дополнительный центр данных выступает в роли резервного: в условиях нормальной работы активные почтовые ящики в нем не размещаются. В случае отказа основного центра данных выполняется ручное переключение на дополнительный. Базы данных размещаются в нем до тех пор, пока не восстановится работоспособность основного центра.

  Распределение "активный/пассивный"

  

• Распределение "активный/активный" с одной группой обеспечения доступности баз данных. Активные копии баз данных развертываются и в основном центре, и в дополнительном центре данных. Соответствующая пассивная копия расположена в альтернативном центре данных. Все серверы почтовых ящиков входят в одну группу обеспечения доступности баз данных. В этой модели соединение двух центров данных по глобальной сети — точка, потенциальный отказ которой приводит к отказу всей системы. Потеря подключения к глобальной сети приводит к тому, что серверы почтовых ящиков в одном из центров данных переходят в состояние сбоя из-за потери кворума.

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

  

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

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

  

*Момент принятия решения*

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

Действие 4. Выбор стратегии резервного копирования и устойчивости баз данных

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

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

• Восстановление случайно удаленных элементов. Благодаря папке "Элементы с возможностью восстановления" в Exchange 2010 и политике удержания, применяемой к этой папке, можно сохранять все удаленные и измененные данные в течение определенного времени, что позволяет упростить и ускорить процесс восстановления таких элементов. Дополнительные сведения см. в разделах Политика обмена сообщениями и соответствие требованиям, Общие сведения об элементах для восстановления и Общие сведения о тегах и политиках хранения.

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

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

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

*Момент принятия решения*

В этом примере (при текущей реализации Exchange) традиционное решение резервного копирования используется в основном для восстановления элементов электронной почты, которые были случайно удалены. 80 % запросов на восстановление отдельного элемента касаются сообщений, которые были созданы в ближайшие 15 дней. Соответственно, срок хранения удаленных элементов будет равен 14 дням. Так как традиционные резервные копии службы теневого копирования томов (VSS) не требуются для восстановления одного элемента и не соответствуют требованиям к времени восстановления, для реализации стратегии устойчивости баз данных будет использоваться собственная система защиты данных Exchange и функции восстановления папки "Удаленные".

Действие 5. Определение требуемого количества копий базы данных

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

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

*Момент принятия решения*

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

Действие 6. Определение типа копий баз данных

Существует два типа копий баз данных:

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

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

*Момент принятия решения*

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

Действие 7. Выбор стратегии устойчивости сервера почтовых ящиков

Система Exchange 2010 была переработана с учетом концепции устойчивости работы почтовых ящиков. Теперь автоматическая защита через отработку отказов обеспечивается на уровне базы данных почтовых ящиков, а не на уровне сервера. Активные и пассивные копии баз данных можно стратегически распределить на серверах почтовых ящиков, которые входят в группу обеспечения доступности баз данных. Ключевой аспект планирования мощностей Exchange 2010 заключается в определении количества копий баз данных, которые будут активированы на каждом сервере. Существуют различные модели распределения базы данных, но обычно рекомендуется развертывать одну из перечисленных ниже.

• Модель для всех активированных копий. При использовании этой модели роль сервера почтовых ящиков расширяется, чтобы обеспечить активацию всех копий баз данных на сервере. Например, на сервере почтовых ящиков могут быть размещены четыре копии базы данных. В условиях нормальной работы две копии базы данных на сервере являются активными, а две другие — пассивными. В случае сбоя или обслуживания все четыре копии базы данных на сервере почтовых ящиков становятся активными. Это решение обычно развертывается в парном варианте. В примере с 4 серверами первая пара — сервера MBX1 и MBX2, а вторая — MBX3 и MBX4. Кроме того, при проектировании данной модели нужно задать для каждого сервер почтовых ящиков размер, не превышающий 40 % ресурсов, доступных в условиях нормальной работы. В случае развертывания устойчивой площадки с тремя копиями базы данных и шестью серверами эта модель может быть развернута с помощью наборов по 3 сервера, причем третий сервер должен находиться в дополнительном центре данных. Эта модель предоставляет стандартный блок из 3 серверов для создания решений на основе модели устойчивости площадки "активный/пассивный".

  Эту модель можно использовать в следующих сценариях.

  • Конфигурация "активный/пассивный" с несколькими производственными площадями, в которой для доменов отказа (например, стоек, корзин блейд-серверов и массивов хранения) требуется простая изоляция копий базы данных в основном центре данных.

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

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

  В рамках этой модели сервера должны развертываться попарно (при развертывании на одной площадке) или тройками (при развертывании на нескольких производственных площадях). В приведенной ниже таблице показан пример структуры базы данных для этой модели.

  Модель для всех активированных копий

  

  В предыдущей таблице выполняются следующие условия:

  • C1 = активная копия (значение приоритета активации 1) в условиях нормальной работы.

  • C2 = пассивная копия (значение приоритета активации 2) в условиях нормальной работы.

  • C3 = пассивная копия (значение приоритета активации 3) в случае сбоя на уровне площадки.

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

  Эту модель следует использовать в следующих сценариях.

  • Все конфигурации с одной площадкой и тремя или более копиями базы данных.

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

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

  Модель для целевых сценариев сбоя

  

  В предыдущей таблице выполняются следующие условия:

  • C1 = активная копия (значение приоритета активации 1) в условиях нормальной работы.

  • C2 = пассивная копия (значение приоритета активации 2) в условиях нормальной работы.

  • C3 = пассивная копия (значение приоритета активации 3) в условиях нормальной работы.

*Момент принятия решения*

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

Действие 8. Определение количества групп обеспечения доступности баз данных

Группа обеспечения доступности баз данных — это основной компонент платформы обеспечения высокого уровня доступности и устойчивости площадки в Exchange 2010. Это группа серверов почтовых ящиков (до 16 серверов), которая содержит набор реплицированных баз данных и обеспечивает автоматическое восстановление на уровне базы данных после сбоя, затрагивающего отдельные серверы и базы данных.

Группа обеспечения доступности баз данных является единым объектом для репликации базы данных почтовых ящиков, переключений базы данных и сервера, отработок отказа и внутреннего компонента, который называется Active Manager. Active Manager — это компонент Exchange 2010, который управляет переключениями и отработкой отказов. Active Manager работает на каждом сервере в группе обеспечения доступности баз данных.

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

• Вы развертываете более 16 серверов почтовых ящиков.

• Имеются активные пользователи почтовых ящиков на нескольких производственных площадях (конфигурация площадки "активный/активный").

• Требуется определить отдельные административные границы на уровне групп обеспечения доступности баз данных.

• Имеются серверы почтовых ящиков в нескольких доменах. (Группы обеспечения доступности баз данных привязаны к доменам.)

*Момент принятия решения*

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

Действие 9. Определение количества серверов почтовых ящиков в группе обеспечения доступности баз данных

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

*Момент принятия решения*

В предыдущем действии было принято решение развернуть три активны/пассивных группы обеспечения доступности баз данных, а также обеспечить стратегию устойчивости сервера для всех активируемых копий. Число серверов, необходимых для развертывания каждой группы обеспечения доступности баз данных, кратно 3 (два на основной площадке и один на альтернативной площадке). Так как развертывается три группы обеспечения доступности баз данных, для их поддержки требуется минимум 9 серверов. В решении будет 9, 18 или 27 серверов (в зависимости от количества серверов, необходимого для поддержки рабочей нагрузки). В таблице ниже приведены возможные конфигурации.

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

Группа DAG1 основного центра данных	Группа DAG1 дополнительного центра данных	Группа DAG2 основного центра данных	Группа DAG2 дополнительного центра данных	Группа DAG3 основного центра данных	Группа DAG3 дополнительного центра данных	Общее число серверов почтовых ящиков
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

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

Протестированные решения для Exchange 2010

Ожидаемые требования к емкости хранилища почтовых ящиков

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

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

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

Действие 1. Расчет размера почтового ящика на диске

Прежде чем определять общие требования к хранилищу, необходимо узнать размер почтового ящика на диске. Для хранения полного почтового ящика с квотой 1 ГБ требуется более 1 ГБ дискового пространства, так как нужно учесть ограничение запрещения отправки и получения; количество сообщений, которое пользователь отправляет и получает ежедневно; срок хранения папки "Удаленные" (как при включенных восстановлении отдельного элемента и регистрации версии календаря, так и при выключенных); а также среднее дневное изменение базы данных на почтовый ящик. Калькулятор для расчета требований к роли сервера почтовых ящиков автоматически выполняет все необходимые вычисления. Кроме того, ниже описано, как выполнить эти расчеты вручную.

Следующая формула используется для определения размера на диске для почтового ящика с ограничением 2 ГБ (учитываются требования и предположения данного решения):

• Свободное пространство = 100 сообщений в день × 75 ÷ 1024 МБ = 7,3 МБ

• Корзина = (100 сообщений в день × 75 ÷ 1024 МБ × 14 дней) + (2048 МБ × 0,012) + (2048 МБ × 0,058) = 246 МБ

• Размер почтового ящика на диске = ограничение почтового ящика + свободное пространство + корзина

  = 2048 + 7.3 + 246

  = 2301 МБ

Действие 2. Расчет требований к емкости хранилища баз данных

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

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

• Размер базы данных = (количество почтовых ящиков × размер почтового ящика на диске × коэффициент роста буфера базы данных) + (20 % служебных данных)

  = (32400 × 2301 × 1) + (14910480)

  = 89 462 880 МБ

  = 87 366 ГБ

• Размер индекса базы данных = 10% от размера базы данных

  = 87366 × 0.10

  = 8737 ГБ

• Общая емкость базы данных = (размер базы данных) + (размер индекса) ÷ 0,80 для добавления 20 % свободного пространства

  = (87366 + 8737) ÷ 0.8

  = 120 128 ГБ

Действие 3. Расчет требований к емкости хранилища журналов транзакций

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

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

• Размер файлов журналов = (размер файла журнала × число журналов для каждого почтового ящика в день × число дней, необходимое для замены сбойной инфраструктуры × число пользователей почтовых ящиков) + (1% буфера для перемещения почтовых ящиков)

  = (1 МБ × 20 × 4 × 32 400) + (32 400 × 0,01 × 2048 МБ)

  = 3 255 552 МБ

  = 3179 ГБ

• Общая емкость журналов = размер файлов журналов ÷ 0,80 для добавления 20 % свободного пространства

  = (3179) ÷ 0.80

  = 3974

Действие 4. Определение общих требований к емкости хранилища

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

Сводка требований к емкости хранилища

Требования к дисковому пространству	Значение
Средний размер почтового ящика на диске, МБ	2301
Требуемая емкость базы данных, ГБ	120128
Требуемая емкость журналов, ГБ	3974
Общая требуемая емкость, ГБ	124102
Общая емкость, необходимая для трех копий базы данных, ГБ	372306
Общая емкость, необходимая для трех копий базы данных, ТБ	364
Общая емкость, необходимая для каждой площадки, ТБ	122

Протестированные решения для Exchange 2010

Ожидаемые требования к системе ввода-вывода почтовых ящиков

При проектировании среды Exchange важно понимание факторов производительности баз данных и журналов. Рекомендуется ознакомиться со статьей Общие сведения о вопросах производительности баз данных и журналов.

Действие 1. Расчет общих требований к системе ввода-вывода почтовых ящиков

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

• Ожидаемое количество операций ввода-вывода в секунду для одного пользователя = 0,10

• Общее требуемое количество операций ввода-вывода в секунду = количество операций ввода-вывода в секунду для одного пользователя × число почтовых ящиков × фактор служебных данных системы ввода/вывода

  = 0.10 × 32400 × 1.2

  = 3888

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

Действие 2. Расчет общих требований к системе ввода-вывода почтовых ящиков для каждой площадки

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

• Общее требуемое количество операций ввода-вывода в секунду для каждой площадки = количество операций ввода-вывода в секунду для одного пользователя × число почтовых ящиков × фактор служебных данных системы ввода/вывода

  = 0.10 × 21600 × 1.2

  = 2592

Протестированные решения для Exchange 2010

Определение типа хранилища

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

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

Дополнительные сведения о выборе хранилища для Exchange 2010 см. в статье Проектирование системы хранения сервера почтовых ящиков.

Протестированные решения для Exchange 2010

Выбор между хранилищами DAS и SAN

Для Exchange 2010 доступен богатый выбор хранилищ. Чтобы сузить список подходящих вариантов, нужно определить, какое решение предпочтительнее: непосредственно подключаемое хранилище DAS (например, локальный диск) или система SAN. Так как оба варианта имеют свои сильные и слабые стороны, для определения оптимального (с учетом ваших бизнес-требований и общей стоимости владения) рекомендуется обратиться к вашему поставщику систем хранения.

*Момент принятия решения*

В этом примере развернута инфраструктура SAN, поэтому для хранения всех данных среды используется хранилище SAN. В будущем также планируется использовать хранилище SAN, поэтому развертывание Exchange 2010 будет описано подробно.

Протестированные решения для Exchange 2010

Выбор хранилища

Для выбора хранилища выполните описанные ниже действия.

Действие 1. Выбор поставщика хранилища

В данном примере в течение многих лет использовалось хранилище EMC, поэтому для развертывания Exchange 2010 будет также применяться решение этого поставщика. EMC Corporation предлагает высокопроизводительные массивы хранения данных, такие как CLARiiON и Symmetric.

Действие 2. Анализ доступных предложений выбранного поставщика

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

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

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

Возможности серии CLARiiON CX4

Feature	Модель CX4 120	Модель CX4 240	Модель CX4 480	Модель CX4 960
Максимальное число дисков	120	240	480	960
Число процессоров хранилища	2	2	2	2
Объем физической памяти на процессор хранилища	3 ГБ	4 ГБ	8 ГБ	16 ГБ
Максимальный кэш записи	600 МБ	1,264 ГБ	4,5 ГБ	10,764 ГБ
Максимальное число инициаторов в системе	256	512	512	1024
Число узлов высокой доступности	128	256	256	512
Минимально возможный форм-фактор	6U	6U	6U	9U
Максимальное число стандартных LUN	1024	1024	4096	4096
Моментальные снимки SnapView	Да	Да	Да	Да
Клоны SnapView	Да	Да	Да	Да
Копия SAN	Да	Да	Да	Да
MirrorView/S	Да	Да	Да	Да
MirrorView/A	Да	Да	Да	Да
RecoverPoint/S	Да	Да	Да	Да
RecoverPoint/A	Да	Да	Да	Да

Действие 3. Выбор типа дисков

В этом примере были выбраны диски объемом 450 ГБ (интерфейс Fibre Channel, 15 000 об/мин), которые обладают высокой производительностью системы ввода-вывода и емкостью, соответствующей начальным требованиям пользователей Exchange.

Примечание.
Через некоторое время после проведения тестирования диски объемом 600 ГБ (10 000 об/мин) снизились в цене и также стали хорошим вариантом для этого развертывания.

Действие 4. Выбор массива

Требования для решения в этом примере: 122 ТБ доступного для использования пространства и 2592 IOPS. Все варианты в таблице выше соответствуют требованию к числу операций ввода-вывода в секунду, поэтому решение будет приниматься на основании требований к емкости. Модель CLARiiON CX4 240 обладает доступной для использования емкостью около 100 ТБ (с дисками 450 ГБ в конфигурации RAID-5). Поэтому мы выбираем модель EMC CLARiiON CX4 480, так как она соответствует требованиям Exchange 2010 по емкости и производительности системы ввода-вывода.

Протестированные решения для Exchange 2010

Ожидаемые требования к объему памяти для почтового ящика

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

Протестированные решения для Exchange 2010

Расчет требуемого размера кэша базы данных

Кэш базы данных используется модулем расширяемого хранилища (ESE) для сокращения количества операций ввода-вывода. Другими словами, чем больше объем доступной кэш-памяти базы данных, тем меньше операций ввода-вывода будет выполнять сервер почтовых ящиков Exchange 2010. Однако имеется предел, по достижении которого рост кэша базы данных перестанет приводить к значительному сокращению IOPS. Соответственно, добавление на сервер Exchange значительного объема физической памяти без определения оптимального размера кэша базы данных может привести к значительным затратам и минимальному приросту производительности.

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

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

Кэш базы данных для одного пользователя

Количество ежедневно отправляемых или получаемых сообщений каждым почтовым ящиком (средний размер сообщения 75 КБ)	Кэш базы данных для одного пользователя (МБ)
50	3 МБ
100	6 МБ
150	9 МБ
200	12 МБ

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

• Размер кэша базы данных = размер кэша базы данных для профиля × число пользователей почтовых ящиков

  = 6 МБ × 32 400

  = 194 400 МБ

  = 190 ГБ

Протестированные решения для Exchange 2010

Ожидаемые требования к процессору для почтовых ящиков

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

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

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

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

Предполагаемое количество мегациклов

Сообщения, получаемые или отправляемые на каждый почтовый ящик в день	Число мегациклов на почтовый ящик для активной базы данных почтовых ящиков	Число мегациклов на почтовый ящик для удаленной пассивной базы данных почтовых ящиков	Число мегациклов на почтовый ящик для локальной пассивной базы данных почтовых ящиков
50	1	0.1	0.15
100	2	0.2	0.3
150	3	0.3	0.45
200	4	0.4	0.6

Действие 1. Расчет требований к процессору для активных почтовых ящиков

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

• Необходимое количество мегациклов для активных почтовых ящиков = количество мегациклов для профиля × количество пользователей почтового ящика

  = 2 × 32400

  = 64800

Действие 2. Расчет требований к процессору для активной удаленной копии базы данных почтовых ящиков

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

• Необходимое количество мегациклов для удаленной копии = количество мегациклов для профиля × количество пользователей почтового ящика × количество удаленных копий

  = 0.1 × 32400 × 2

  = 6480

Действие 3. Расчет требований к процессору для локальных пассивных почтовых ящиков

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

• Необходимое количество мегациклов для локальных пассивных почтовых ящиков = количество мегациклов для профиля × количество пользователей почтового ящика × количество пассивных копий

  = 0.3 × 32400 × 2

  = 19440

Действие 4. Расчет общих требований к процессору

Расчет общих требований выполняется с помощью следующей формулы:

• Общее требуемое число мегациклов = число мегациклов для активных почтовых ящиков + для удаленных пассивных + для локальных пассивных

  = 64800 + 6480 + 19440

  = 90720

  Среднее число мегациклов на один почтовый ящик = 90 720 ÷ 32 400 = 2,8

Протестированные решения для Exchange 2010

Сводные требования для почтовых ящиков

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

Сводные требования для почтовых ящиков

Требования к процессору для почтовых ящиков	Значение
Общее требуемое число мегациклов для всей среды	97200
Общий требуемый кэш базы данных для всей среды	190 ГБ

Протестированные решения для Exchange 2010

Выбор модели сервера

Чтобы выбрать модель сервера, выполните следующие действия.

Действие 1. Выбор поставщика сервера

В нашем случае предпочтительной серверной платформой является Cisco Unified Computing System. Это платформа для центров данных, которая отличается гибкостью и низкой общей стоимостью владения благодаря применению современных вычислительных и сетевых решений, методов доступа к данным и технологий виртуализации. В платформу интегрирована объединенная сетевая структура Ethernet 10 Гбит/с с низкой задержкой, а также серверы корпоративного класса на базе архитектуры x86. Благодаря системному подходу к выбору архитектуры, технологий, партнеров и служб Cisco Unified Computing System повышает эффективность использования ресурсов центра данных и доставки служб, а также сокращает число устройств, для которых требуется настройка, управление, питание, охлаждение и прокладка кабелей.

Действие 2. Анализ доступных предложений выбранного поставщика

Cisco Unified Computing System — это система на основе блейд-серверов, которая состоит из четырех основных компонентов: многоканальной сетевой структуры, шасси, расширителей сети (модулей ввода-вывода) и блейд-серверов.

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

Вариант 1. Блейд-сервер B200

Cisco Unified Computing System B200 является блейд-сервером половинной ширины с двумя гнездами. Система включает два процессора серии Intel Xeon 5500 или 5600, память DDR3 объемом до 96 ГБ, два дополнительных жестких диска малого форм-фактора SAS с возможностью горячей замены и один мезонинный разъем с пропускной способностью до 20 Гбит/с. Этот сервер отличается простотой, производительностью и высокой плотностью компоновки. Он идеально подходит для систем виртуализации корпоративного уровня и активной работы в центрах данных.

Вариант 2. Блейд-сервер B250

Cisco Unified Computing System B250 Extended Memory — блейд-сервер полной ширины с двумя гнездами, поддерживающий технологию Cisco Extended Memory. Система поддерживает два процессора серии Intel Xeon 5500 или 5600, память DDR3 объемом до 384 ГБ, два дополнительных жестких диска малого форм-фактора SAS и два мезонинных разъема с пропускной способностью до 40 Гбит/с. Этот сервер способен значительно повысить производительность систем виртуализации корпоративного уровня и эффективность обработки больших массивов данных.

Вариант 3. Блейд-сервер B440

Блейд-сервер Cisco Unified Computing System B440 Blade Server предназначен для решения ресурсоемких корпоративных задач, таких как работа с базами данным с большим количеством транзакций, планирование ресурсов в масштабах предприятия (ERP) и поддержка принятия решений (DSS). Благодаря масштабируемости и повышенной надежности процессоров серии Intel Xeon 7500 платформа Cisco Unified Computing System B440 позволяет расширить сферу применения виртуализации и объединить отдельные ресурсоемкие приложения в удобную интегрированную инфраструктуру. Cisco Unified Computing System B440 поддерживает до 32 процессорных ядер и до 256 ГБ основной памяти, объединенная пропускная способность может достигать 40 Гбит/с.

Действие 3. Выбор модели сервера

Была выбрана модель Cisco Unified Computing System B200 с процессорами Intel Xeon X5570, так как этот блейд-сервер обладает оптимальной производительностью, объемом памяти и форм-фактором для данного развертывания. Серверная платформа с двумя гнездами часто идеально подходит для развертываний Exchange 2010 благодаря сочетанию важных факторов (включая масштабируемость и стоимость). Хотя модель Cisco Unified Computing System B250 поддерживает более емкую конфигурацию памяти и обладает увеличенной пропускной способностью, эти параметры не являются обязательными для данного решения.

Примечание.
Через некоторое время после проведения тестирования диски объемом 600 ГБ (10 000 об/мин) снизились в цене и также стали хорошим вариантом для этого развертывания.

Протестированные решения для Exchange 2010

Расчет мощности процессора выбранной модели сервера

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

Действие 1. Определение эталонного значения для сервера и процессора

Так как требование к количеству мегациклов основано на характеристиках базовой модели сервера и процессора, необходимо скорректировать количество доступных мегациклов в соответствии с этими базовыми характеристиками. Для этого используются эталонные тесты производительности, которые проводятся независимой корпорацией Standard Performance Evaluation Corporation (SPEC). SPEC — некоммерческая организация, занимающаяся созданием, поддержкой и одобрением стандартизированных наборов эталонных тестов, которые используются для оценки высокопроизводительных компьютеров новейшего поколения.

Чтобы упростить получение результатов теста для вашего сервера и процессора, рекомендуется использовать инструмент запросов процессора Exchange. Это средство автоматически выполняет действия по определению рейтинга SPECint 2006 для выбранного процессора. Для запуска этой программы компьютер должен быть подключен к Интернету. Вы указываете модель процессора, которую планируете использовать, затем инструмент отправляет запрос на веб-сайт Standard Performance Evaluation Corporation и возвращает результаты тестов для выбранной модели. Кроме того, инструмент вычисляет средний рейтинг SPECint 2006, учитывая количество процессоров, которое планируется использовать в каждом сервере почтовых ящиков. Используется следующая формула:

• Процессор = Intel X5570 2,93 ГГц

• Значение SPECint_rate2006 = 256

• Значение SPECint_rate2006 для процессорного ядра = 256 ÷ 8

  = 32

Действие 2. Расчет скорректированного количества мегациклов

На предыдущих этапах было рассчитано количество мегациклов, необходимое для всей среды, на основе ожидаемого количества мегациклов для почтового ящика. Эти оценки основывались на эталонной системе (HP DL380 G5 x5470 3,33 ГГц, 8 ядер) с рейтингом SPECint_rate2006, равным 150 (для 8-ядерного сервера) или 18,75 (для одного ядра).

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

Чтобы определить число мегациклов платформы Cisco B200-M1 Intel X5570 2,93 ГГц, используйте следующие формулы:

• Скорректированное число мегациклов на ядро = (значение для ядра новой платформы) × (частота ядра эталонной платформы в герцах) ÷ (значение для ядра эталонной платформы)

  = (32 × 3330) ÷ 18.75

  = 5683

• Скорректированное число мегациклов на сервер = скорректированное число мегациклов на ядро × количество ядер

  = 5683 × 8

  = 45466

Действие 3. Расчет количества доступных мегациклов на один сервер почтовых ящиков

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

• Скорректированное число доступных мегациклов = число доступных мегациклов на сервер × максимальная целевая интенсивность использования процессора

  = 45466 × 0.80

  = 36372

Каждый сервер имеет полезную мощность, составляющую 36 372 мегациклов.

Протестированные решения для Exchange 2010

Определение необходимого количества физических серверов почтовых ящиков

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

Действие 1. Определение максимального числа активных почтовых ящиков, которое поддерживается одним сервером почтовых ящиков

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

• Количество активных почтовых ящиков = количество доступных мегациклов на сервер ÷ количество мегациклов для почтового ящика

  = 36372 ÷ 2.8

  = 12990

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

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

• Требуемое количество серверов = общее количество почтовых ящиков в группе обеспечения доступности баз данных ÷ число активных почтовых ящиков на сервере

  = 10800 ÷ 12990

  = 0.83

Для поддержки рабочей нагрузки (10 800 активных почтовых ящиков) в каждой группе обеспечения доступности баз данных требуется как минимум 1 сервер почтовых ящиков.

Действие 3. Определение числа серверов, которое требуется для поддержки стратегии устойчивости сервера почтовых ящиков в каждой группе обеспечения доступности баз данных

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

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

Группа DAG1 основного центра данных	Группа DAG1 дополнительного центра данных	Группа DAG2 основного центра данных	Группа DAG2 дополнительного центра данных	Группа DAG3 основного центра данных	Группа DAG3 дополнительного центра данных	Общее число серверов почтовых ящиков
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

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

Протестированные решения для Exchange 2010

Определение количества активных почтовых ящиков на каждом сервере почтовых ящиков для сценариев нормальной работы и сбоя

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

Действие 1. Определение количества активных почтовых ящиков на каждом сервере почтовых ящиков в условиях нормальной работы

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

• Количество почтовых ящиков на каждом сервере = общее число почтовых ящиков в группе обеспечения доступности баз данных ÷ количество серверов почтовых ящиков в основном центре данных

  = 10800 ÷ 2

  = 5400

Действие 2. Определение количества активных почтовых ящиков на каждом сервере почтовых ящиков в условиях сбоя на сервере почтовых ящиков в основном центре данных

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

Действие 3. Определение количества активных почтовых ящиков на каждом сервере почтовых ящиков в условиях сбоя на обоих серверах почтовых ящиков в основном центре данных

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

Протестированные решения для Exchange 2010

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

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

*Момент принятия решения*

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

Протестированные решения для Exchange 2010

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

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

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

Количество необходимых комбинаций сервера клиентского доступа и транспортного сервера-концентратора

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

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

Серверы клиентского доступа и транспортные серверы-концентраторы

Протестированные решения для Exchange 2010

Определение общего количества физических серверов

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

Необходимое количество физических серверов

Протестированные решения для Exchange 2010

Определение необходимости применения виртуализации серверов

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

Рассмотреть возможность использования виртуализации с Exchange можно в следующих случаях:

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

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

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

Чтобы определить, нужна ли виртуализация в этой среде, выясните ожидаемую интенсивность использования процессора и установите, будет ли он использоваться в полном объеме.

Действие 1. Определение ожидаемой интенсивности использования ЦП сервера почтовых ящиков в нормальных условиях эксплуатации

Чтобы определить интенсивность использования ЦП при наличии 5 400 активных почтовых ящиков на одном сервере почтовых ящиков, воспользуйтесь следующей формулой:

• Процент использования процессора (пиковая нагрузка при нормальной эксплуатации) = требуемое число мегациклов ÷ доступное число мегациклов

  = (5400 × 2.8) ÷ 45466

  = 33.2%

Действие 2. Расчет ожидаемой интенсивности использования ЦП сервера почтовых ящиков в условиях сбоя в наихудшем случае

Чтобы определить интенсивность использования ЦП при наличии 10 800 активных почтовых ящиков на одном сервере почтовых ящиков, воспользуйтесь следующей формулой:

• Процент использования процессора (пиковая нагрузка при сбое) = требуемое число мегациклов ÷ доступное число мегациклов

  = (10800 × 2.8) ÷ 45466

  = 66.5%

*Момент принятия решения*

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

Протестированные решения для Exchange 2010

Определение возможности использования виртуализации для сокращения количества физических серверов

Дальнейшие действия посвящены определению возможности использования виртуализации для сокращения количества физических серверов в данном решении. В качестве платформы виртуализации будет использоваться Microsoft Hyper-V.

Действие 1. Добавление виртуализации к существующим физическим серверам

На стадии тестирования платформа Microsoft Hyper-V поддерживала не более четырех виртуальных процессоров на каждую виртуальную машину. В случае физической реализации роль сервера почтовых ящиков для основной группы обеспечения доступности баз данных развертывалась на двух физических серверах с общим числом логических процессоров 16. При добавлении виртуализации роль сервера почтовых ящиков для основной группы обеспечения доступности баз данных развертывается уже на четырех виртуальных машинах, каждая из которых имеет по четыре виртуальных процессора (всего 16 виртуальных процессоров).

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

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

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

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

Виртуальные машины

Действие 2. Сокращение количества физических серверов

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

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

Виртуальные машины

Виртуальные машины

Действие 3. Определение количества виртуальных процессоров, назначенных каждой виртуальной машине

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

Каждая из виртуальных машин сервера почтовых ящиков в основной группе обеспечения доступности баз данных будет поддерживать 25 % из 10 800 активных почтовых ящиков в группе обеспечения доступности баз данных при нормальных условиях эксплуатации, то есть по 2700 почтовых ящиков каждая. В случае сбоя сервера оставшаяся в рабочем состоянии виртуальная машина сервера почтовых ящиков будет вынуждена поддерживать 5400 активных почтовых ящиков.

В случае отказа на уровне площадки каждая из четырех виртуальных машин сервера почтовых ящиков в основной группе обеспечения доступности баз данных будет поддерживать 25 % из 10 800 активных почтовых ящиков в группе обеспечения доступности баз данных, или по 2700 почтовых ящиков каждая. В данном сценарии почтовые ящики будут выполняться в третьей и последней копии базы данных. В случае сбоя сервера или виртуальной машины оставшаяся в рабочем состоянии виртуальная машина не должна будет поддерживать 5400 активных почтовых ящиков. Максимальное количество почтовых ящиков всегда будет 2700.

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

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

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

Распределение виртуальных процессоров

Виртуальная машина	Количество виртуальных процессоров
Комбинация сервера клиентского доступа и транспортного сервера-концентратора	3
Почтовый ящик (основная группа обеспечения доступности баз данных)	4
Почтовый ящик (альтернативная группа обеспечения доступности баз данных)	2
Всего	9

Протестированные решения для Exchange 2010

Расчет мощности ЦП корневого сервера Hyper-V

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

Протестированные решения для Exchange 2010

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

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

• Скорректированное число доступных мегациклов = число доступных мегациклов × 0,90

  = 45466 × 0.90

  = 40919

Каждый сервер имеет полезную мощность для виртуальных машин, составляющую 40 919 мегациклов.

Полезная мощность на один логический процессор составляет 5115 мегациклов.

Протестированные решения для Exchange 2010

Определение мощности ЦП виртуальных машин

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

Распределение виртуальных процессоров

Виртуальная машина	Количество виртуальных процессоров
Комбинация сервера клиентского доступа и транспортного сервера-концентратора	3
Почтовый ящик (основная группа обеспечения доступности баз данных)	4
Почтовый ящик (альтернативная группа обеспечения доступности баз данных)	2
Всего	9

Действие 1. Определение числа доступных мегациклов на один виртуальный процессор

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

• Количество мегациклов на один виртуальный процессор = количество мегациклов на один логический процессор× (количество логических процессоров ÷ количество виртуальных процессоров)

  = 5115 × (8 ÷ 9)

  = 4547

Действие 2. Определение количества доступных мегациклов на одну виртуальную машину

Это действие посвящено определению количества доступных мегациклов на одну виртуальную машину (см. следующую таблицу).

Количество доступных мегациклов на одну виртуальную машину

Виртуальная машина	Количество виртуальных процессоров	Количество мегациклов на один виртуальный процессор	Количество доступных мегациклов
Комбинация сервера клиентского доступа и транспортного сервера-концентратора	3	4547	13641
Почтовый ящик (основная группа обеспечения доступности баз данных)	4	4547	18188
Почтовый ящик (альтернативная группа обеспечения доступности баз данных)	2	4547	9094

Действие 3. Определение целевого количества доступных мегациклов на одну виртуальную машину

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

Целевое количество доступных мегациклов на одну виртуальную машину

Виртуальная машина	Количество доступных мегациклов	Максимальная интенсивность использования процессора	Целевое количество доступных мегациклов
Комбинация сервера клиентского доступа и транспортного сервера-концентратора	13641	80%	10913
Почтовый ящик (основная группа обеспечения доступности баз данных)	18188	80%	14550
Почтовый ящик (альтернативная группа обеспечения доступности баз данных)	9094	80%	7275

Протестированные решения для Exchange 2010

Проверка мощности ЦП виртуальных машин основного сервера почтовых ящиков

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

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

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

• Необходимое количество мегациклов для почтового ящика = (количество пользователей почтового ящика × количество мегациклов для профиля) + количество удаленных копий базы данных × (количество пользователей почтового ящика × количество мегациклов для профиля× 10 %)

  = (5400 × 2) + 2 × (5400 × 2 × 0.1)

  = 10800 + 2160

  = 12960

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

В этом действии мы определим, превышает ли количество доступных мегациклов необходимое количество мегациклов. Вам требуется 12 960 мегациклов, а в наличии имеется 14 550 мегациклов, поэтому мощности виртуальных машин основного сервера почтовых ящиков достаточно для поддержки 5400 активных почтовых ящиков.

Протестированные решения для Exchange 2010

Проверка мощности ЦП виртуальных машин дополнительного сервера почтовых ящиков

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

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

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

• Необходимое количество мегациклов для почтового ящика = (количество пользователей почтового ящика × количество мегациклов для профиля) + количество удаленных копий базы данных × (количество пользователей почтового ящика × количество мегациклов для профиля× 10 %)

  = (2700 × 2) + 2 × (2700 × 2 × 0.1)

  = 5400 + 1080

  = 6480

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

В этом действии мы определим, превышает ли количество доступных мегациклов необходимое количество мегациклов. Вам требуется 6 480 мегациклов, а в наличии имеется 7 275 мегациклов, поэтому мощности виртуальных машин дополнительного сервера почтовых ящиков достаточно для поддержки 2 700 активных почтовых ящиков.

Протестированные решения для Exchange 2010

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

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

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

На предыдущем этапе было установлено, что требования к кэшу базы данных для всех почтовых ящиков составляют 190 ГБ, а средний объем кэша, необходимого для активного почтового ящика, — 6 МБ.

Для проектирования с учетом самого серьезного сценария сбоя требуемый объем кэша базы данных рассчитывается на основе 5400 активных почтовых ящиков на оставшихся виртуальных машинах сервера почтовых ящиков:

• Объем памяти, необходимый для кэша базы данных = число активных почтовых ящиков × средний размер кэша почтового ящика

  = 5400 × 6 МБ

  = 32 400 МБ

  = 31,6 ГБ

Действие 2. Определение требований к общему объему памяти виртуальной машины на сервере почтовых ящиков в самом серьезном сценарии сбоя

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

Требования к памяти

Размер физической памяти сервера (ОЗУ)	Размер кэша базы данных (только для роли сервера почтовых ящиков)
24 ГБ	17,6 ГБ
32 ГБ	24,4 ГБ
48 ГБ	39,2 ГБ

Рекомендуемая конфигурация памяти, позволяющая поддерживать кэш базы данных объемом 31,6 ГБ для роли сервера почтовых ящиков, составляет 48 ГБ.

Протестированные решения для Exchange 2010

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

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

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

На предыдущем этапе было установлено, что требования к кэшу базы данных для всех почтовых ящиков составляют 190 ГБ, а средний объем кэша, необходимого для активного почтового ящика, — 6 МБ.

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

• Объем памяти, необходимый для кэша базы данных = число активных почтовых ящиков × средний размер кэша почтового ящика

  = 2700 × 6 МБ

  = 16 200 МБ

  = 15,8 ГБ

Действие 2. Определение требований к общему объему памяти виртуальной машины на сервере почтовых ящиков в самом серьезном сценарии сбоя

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

Требования к памяти

Размер физической памяти сервера (ОЗУ)	Размер кэша базы данных (только для роли сервера почтовых ящиков)	Размер кэша базы данных (несколько ролей сервера, например роли сервера почтовых ящиков и транспортного сервера-концентратора)
24 ГБ	17,6 ГБ	14 ГБ
32 ГБ	24,4 ГБ	20 ГБ
48 ГБ	39,2 ГБ	32 ГБ

Рекомендуемая конфигурация памяти, позволяющая поддерживать кэш базы данных объемом 15,8 ГБ для роли сервера почтовых ящиков, составляет 24 ГБ.

Протестированные решения для Exchange 2010

Определение объема памяти, необходимой для совместного использования сервера клиентского доступа и транспортного сервера-концентратора

Чтобы определить конфигурацию памяти для виртуальной машины на сервере, объединяющем функции сервера клиентского доступа и транспортного сервера-концентратора, см. следующую таблицу.

Конфигурации памяти для серверов Exchange 2010 в зависимости от установленных ролей сервера

Роль сервера Exchange Server 2010	Минимальная поддерживаемая	Рекомендуемый максимум
Роль объединенного сервера клиентского доступа и транспортного сервера-концентратора (эти две роли запускаются на одном физическом сервере)	4 ГБ	2 ГБ на ядро (минимум 8 ГБ)

Поскольку виртуальная машина объединенного сервера клиентского доступа и транспортного сервера-концентратора содержит три виртуальных процессора, каждой виртуальной машине на таком сервере выделяется 6 ГБ памяти.

Протестированные решения для Exchange 2010

Определение объема памяти, необходимого для каждого корневого сервера Hyper-V

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

• Объем памяти корневого сервера = объем памяти корневой операционной системы + объем памяти виртуальной машины на объединенном сервере клиентского доступа и транспортном сервере-концентраторе + объем памяти виртуальной машины на основном сервере почтовых ящиков + объем памяти виртуальной машины на дополнительном сервере почтовых ящиков

  = 4 ГБ + 6 ГБ + 48 ГБ + 24 ГБ

  = 82 ГБ

Требование к физической памяти для корневого сервера составляет 82 ГБ. Для соответствия рекомендуемым конфигурациям физической памяти на сервер будет установлено 96 ГБ.

Протестированные решения для Exchange 2010

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

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

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

Протестированные решения для Exchange 2010

Проектирование структуры копий баз данных

Для проектирования структуры копий баз данных выполните следующие действия.

Действие 1. Определение количества уникальных баз данных Exchange в группе обеспечения доступности баз данных

Чтобы определить оптимальное количество баз данных Exchange для развертывания, используйте калькулятор для расчета требований к роли сервера почтовых ящиков Exchange 2010. Укажите соответствующую информацию на вкладке ввода и выберите Да, чтобы Automatically Calculate Number of Databases / DAG (Автоматически рассчитать количество баз данных или групп обеспечения доступности баз данных). В поле предельного размера почтового ящика укажите полностью подготовленную квоту почтового ящика, равную 2048 МБ.

Базы данных Exchange в группе обеспечения доступности баз данных

На вкладке Role Requirements (Требования к роли) отобразится рекомендуемое количество баз данных. Для данного решения калькулятор рекомендует, чтобы каждая группа обеспечения доступности баз данных содержала не менее 24 уникальных баз данных.

*Момент принятия решения*

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

Действие 2. Определение структуры базы данных при обычных условиях эксплуатации

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

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

Структура базы данных при обычных условиях эксплуатации

Database	MBX1	MBX2	MBX3	MBX4
DB1-6	А1
DB7-12		А1
DB13-18			А1
DB19-24				А1

В предыдущей таблице выполняются следующие условия:

• A1 = активная копия базы данных

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

Поскольку в состав группы обеспечения доступности баз данных входят четыре сервера почтовых ящиков, в пары будут объединены сервер 1 и 2, а также сервер 3 и 4. На этом этапе на другой сервер в каждой паре добавляются пассивные копии базы данных (P1), как показано в следующей таблице.

Структура базы данных при обычных условиях эксплуатации с пассивными копиями

Database	MBX1	MBX2	MBX3	MBX4
DB1-6	А1	P1
DB7-12	P1	А1
DB13-18			А1	P1
DB19-24			P1	А1

В предыдущей таблице выполняются следующие условия:

• A1 = активная копия базы данных

• P1 = пассивная копия базы данных

Действие 3. Определение структуры базы данных в условиях сбоя или профилактических работ на площадке сервера

При возникновении сбоя на сервере или в период обслуживания копии P1 активируются на другом сервере. Эта процедура представлена в следующей таблице, где серверы почтовых ящиков MBX2 и MBX4 отключены на период обслуживания.

Структура копий баз данных в условиях сбоя или профилактических работ на площадке сервера

В предыдущей таблице выполняются следующие условия:

• A1 = активная копия базы данных

• P1 = пассивная копия базы данных

Действие 4. Добавление копий баз данных в дополнительный центр данных для обеспечения устойчивости площадок

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

Копии баз данных, добавленные в дополнительный центр данных для обеспечения устойчивости площадок

Database	MBX1 на площадке А	MBX2 на площадке А	MBX3 на площадке А	MBX4 на площадке А	MBX5 на площадке B	MBX6 на площадке B	MBX7 на площадке B	MBX8 на площадке B
DB1-6	А1	P1			P2
DB7-12	P1	А1				P2
DB13-18			А1	P1			P2
DB19-24			P1	А1				P2

В предыдущей таблице выполняются следующие условия:

• A1 = активная копия базы данных

• P1 = локальная пассивная копия базы данных

• P2 = удаленная пассивная копия базы данных

Действие 5. Определение структуры базы данных в условиях сбоя на площадке

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

Структура базы данных в условиях сбоя на площадке

В предыдущей таблице выполняются следующие условия:

• A1 = активная копия базы данных

• P1 = пассивная копия базы данных

• P2 = пассивная копия базы данных

Протестированные решения для Exchange 2010

Режим координации активации центра данных

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

*Момент принятия решения*

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

Протестированные решения для Exchange 2010

Определение размещения следящего файлового ресурса

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

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

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

*Момент принятия решения*

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

Протестированные решения для Exchange 2010

Планирование пространств имен

При планировании организации сервера Exchange 2010 одним из важнейших решений является определение того, как будут использоваться внешние пространства имен. Пространство имен — это логическая структура, которая обычно представлена именем домена в службе доменных имен (DNS). При определении пространства имен необходимо учесть различные расположения клиентов и серверов, на которых находятся их почтовые ящики. Помимо физического расположения клиентов, необходимо оценить, каким образом они подключаются к серверу Exchange 2010. Ответы на эти вопросы позволят определить необходимое количество пространств имен. Пространства имен обычно соответствуют конфигурации DNS. Рекомендуется создать уникальное пространство имен для каждой площадки Active Directory в регионе, в котором есть один или несколько серверов клиентского доступа с выходом в Интернет. В службе DNS это обычно представлено в виде A-записи, например mail.contoso.com или mail.europe.contoso.com.

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

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

• Модель объединенного центра данных. Эта модель состоит из одной физической площадки. Все серверы расположены в пределах площадки, и присутствует одно пространство имен, например mail.contoso.com.

• Одно пространство имен с прокси-площадками. Эта модель состоит из нескольких физических площадок. Только один сайт содержит сервер клиентского доступа, доступный из Интернета. Другие площадки не доступны через Интернет. Для сайтов в модели существует только одно пространство имен, например mail.contoso.com.

• Одно пространство имен и несколько площадок. Эта модель состоит из нескольких физических площадок. Каждая площадка может содержать сервер клиентского доступа с выходом в Интернет. Также возможна ситуация, когда присутствует только одна площадка, содержащая серверы клиентского доступа с выходом в Интернет. Для сайтов в модели существует только одно пространство имен, например mail.contoso.com.

• Региональные пространства имен. Эта модель состоит из нескольких физических площадок и нескольких пространств имен. Например, площадка, расположенная в Нью-Йорке, имеет пространство имен mail.usa.contoso.com, площадка, расположенная в Торонто, — mail.canada.contoso.com, а площадка в Лондоне — mail.europe.contoso.com.

• Несколько лесов. Эта модель состоит из нескольких лесов и нескольких пространств имен. Организация, применяющая эту модель, может состоять из двух партнерских компаний (например, Contoso и Fabrikam). При этом могут использоваться пространства имен mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com и mail.europe.fabrikam.com.

*Момент принятия решения*

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

Преимущество этой модели заключается в том, что объем передачи будет сокращен, так как большое количество пользователей смогут подключаться к серверу клиентского доступа на той же площадке Active Directory, что и их сервер почтовых ящиков. Это улучшит работу пользователей и производительность. Для пользователей, почтовые ящики которых находятся на площадке без сервера клиентского доступа с выходом в Интернет, будет выполняться передача.

Это решение также имеет следующие требования к конфигурации:

• Требуется управлять несколькими записями DNS.

• Требуется получить и настроить несколько сертификатов, а также управлять ими.

• Усложняется управление безопасностью, так как для каждой площадки, доступной из Интернета, требуется компьютер с программным обеспечением Microsoft Forefront Threat Management Gateway либо другое решение с обратным прокси-сервером или брандмауэром.

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

Протестированные решения для Exchange 2010

Определение массива серверов клиентского доступа и стратегии балансировки нагрузки

На сервере Exchange 2010 службы клиентского доступа RPC и адресной книги Exchange добавлены к роли сервера клиентского доступа, чтобы улучшить работу пользователей при переносе активной копии базы данных почтовых ящиков на другой сервер (например, во время сбоев и обслуживания баз данных почтовых ящиков). Конечные точки подключений для доступа к почтовым ящикам из приложения Microsoft Outlook и других клиентов MAPI перенесены из роли сервера почтовых ящиков в роль сервера клиентского доступа. Поэтому теперь нагрузка внутренних и внешних подключений Outlook должна быть сбалансирована по всем серверам клиентского доступа на площадке для обеспечения отказоустойчивости. Чтобы связать конечную точку MAPI с группой серверов клиентского доступа вместо конкретного сервера клиентского доступа, можно определить массив серверов клиентского доступа. На каждой площадке Active Directory можно настроить только один массив, который должен охватывать не более одной площадки Active Directory. Дополнительные сведения см. в разделах Общие сведения о серверах клиентского доступа RPC и Understanding Load Balancing in Exchange.

*Момент принятия решения*

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

Протестированные решения для Exchange 2010

Определение модели аппаратной балансировки нагрузки

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

Действие 1. Определение предпочтительного поставщика аппаратного решения для балансировки нагрузки

В этом примере предпочтительным поставщиком является компания Cisco, так как линейка продуктов Cisco Application Control Engine (ACE) поддерживает работу с системой унифицированных вычислений Cisco Unified Computing System, выбранной для компонентов подключения серверов, сети и хранилища в этом решении.

Линейка продуктов Cisco ACE обеспечивает высоконадежное и масштабируемое решение для организации центров данных, предоставляющее выгоды для среды приложения Exchange 2010. Продукты Cisco ACE обеспечивают возможность взаимодействия со следующими преимуществами:

• производительность, масштабируемость, пропускная способность и доступность приложений;

• проектирование на основе стандартов;

• виртуальная архитектура с выделением разделов устройств;

• администрирование и централизованное управление на основе ролей;

• услуги обеспечения безопасности за счет углубленной проверки пакетов, списков управления доступом (ACL), одноадресной пересылки по обратному пути и преобразования сетевых адресов (NAT) или адресов портов.

Действие 2. Анализ доступных предложений выбранного поставщика

В состав линейки продуктов Cisco ACE входят две разных модели устройств для аппаратной балансировки нагрузки, которые соответствуют потребностям в высоконадежном и масштабируемом центре данных, подходящем для среды приложения Exchange 2010. Это устройство Cisco ACE 4710 и модуль с интегрированной службой на платформах маршрутизации Cisco Catalyst 6500/Cisco 7600.

Устройство Cisco ACE 4710 обеспечивает пропускную способность на уровне до 4 Гбит/с, имеет высоту, равную одной монтажной единице (1RU), и предоставляет возможность обновления с помощью лицензий на использование ПО, что гарантирует защиту долгосрочных инвестиций и масштабируемость. Конструкция 4710 представляет собой монтируемый в стойку корпус высотой 1U с платой ускорителя Cavium Nitrox Octeon, оснащенной четырьмя портами Gigabit Ethernet. Такие порты можно объединить с помощью Cisco EtherChannel и подключить к коммутатору. По умолчанию Cisco ACE 4710 поддерживает виртуализацию с использованием одного устройства администратора и пяти устройств пользователей, пропускную способность на уровне 1 Гбит/с, скорость обработки данных, равную 1000 SSL-транзакций в секунду, и скорость сжатия, составляющую 100 мегабит в секунду (Мбит/с). Решение можно расширять без необходимости покупки нового оборудования. Для этого потребуются следующие обновления лицензий на использование ПО.

• Пропускная способность. Уровень пропускной способности, составляющий по умолчанию 1 Гбит/с, можно увеличить до 2 или 4 Гбит/с.

• Виртуальные устройства. Количество виртуальных устройств можно увеличить с 5 до 20 единиц.

• SSL-транзакций в секунду. Количество SSL-транзакций в секунду можно увеличить с 1000 до 5000 или 7500.

• Сжатие. Скорость сжатия можно увеличить до 500 Мбит/с либо 1 или 2 Гбит/с пропускной способности.

• Управление доступом на основе ролей. Централизованное управление на основе ролей реализуется посредством графического интерфейса сетевого диспетчера приложений или интерфейса командной строки.

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

Модуль Cisco ACE для коммутаторов серии Cisco Catalyst 6500 Series или маршрутизаторов серии Cisco 7600 Series обеспечивает пропускную способность на уровне до 16 Гбит/с в корпусе с одним гнездом, который, как и устройство ACE 4710, поддерживает обновление с помощью лицензий на использование ПО. В одном коммутаторе Cisco Catalyst 6500 Series или маршрутизаторе Cisco 7600 Series можно установить до четырех модулей Cisco ACE. Каждый из них может поддерживать бизнес-процессы нескольких независимых подразделений с преимуществом широкого выбора вариантов подключений, предоставляемых коммутатором и маршрутизатором. Администратор определяет требования к приложениям и назначает соответствующие сетевые службы в форме виртуального контекста. Каждый такой контекст содержит собственный набор политик, интерфейсов, ресурсов и администраторов.

• Пропускная способность. Службы балансировки нагрузки обеспечивают пропускную способность до 16 Гбит/с и 345 000 подключений уровня 4 в секунду.

• Виртуальные устройства. Количество виртуальных устройств можно увеличить с 5 до 250 единиц.

• SSL-транзакций в секунду. Число SSL-транзакций в секунду можно увеличить до 15 000 SSL-сеансов за счет лицензирования на основе модулей ACE20 и до 30 000 SSL-сеансов на основе модулей ACE30.

• Сжатие. Скорость сжатия можно увеличить до 6 Гбит/с, используя модули ACE30.

• Управление доступом на основе ролей. Централизованное управление на основе ролей реализуется посредством графического интерфейса сетевого диспетчера приложений или интерфейса командной строки.

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

Действие 3. Выбор модели оборудования для балансировки нагрузки

Выбор устройства Cisco ACE 4710 обусловлен тем, что оно обеспечивает максимальную доступность и полную безопасность приложений, виртуализованную архитектуру, а также окупаемость и защиту инвестиций.

• Максимальная доступность приложений. Устройство Cisco ACE 4710 помогает обеспечить непрерывность ведения бизнеса и обслуживание пользователей. Это возможно за счет роста доступности, реализуемого с помощью легко масштабируемой балансировки нагрузки на уровне 4 и коммутации содержимого на уровне 7, что также позволяет максимально сократить последствия сбоя приложения или устройства.

• Полная безопасность приложений. Устройство Cisco ACE 4710 выступает в качестве последнего уровня серверной защиты от угроз приложений и атак типа "отказ в обслуживании" (DoS), предоставляя такие возможности, как углубленная проверка пакетов, безопасность сети и протоколов, а также управление доступом с высокой степенью масштабируемости.

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

Протестированные решения для Exchange 2010

Определение конструкции хранилища

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

Действие 1. Объединение требований к хранилищу

В следующей таблице представлены сводные требования к хранилищу, рассчитанные или определенные на предыдущем этапе проектирования.

Сводные требования к дисковому пространству

Требования к дисковому пространству	Значение
Размер пространства на диске для почтового ящика емкостью 2 ГБ (в МБ)	2301
Требуемая общая емкость базы данных (в ГБ)	120128
Требуемая общая емкость журнала (в ГБ)	3974
Общая требуемая емкость, ГБ	124102
Общая емкость, необходимая для трех копий базы данных, ГБ	372306
Общая емкость, необходимая для трех копий базы данных, ТБ	364
Требуемая общая емкость для каждого сайта (в терабайтах)	122

Действие 2. Выбор виртуальной или тонкой подготовки для использования

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

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

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

*Момент принятия решения*

В текущей реализации Exchange квота почтового ящика установлена на уровне 200 МБ. После перехода на версию Exchange 2010 предполагается, что в первые 12–18 месяцев размеры почтовых ящиков возрастут примерно на 300 процентов. Планируется приобрести достаточный объем для хранения данных, чтобы обеспечить хранение почтовых ящиков, средний размер которых составляет 600 МБ. В течение периода реализации Exchange 2010 средний размер почтового ящика должен достигнуть 2 ГБ. Поскольку оплата квот почтовых ящиков на уровне 2 ГБ потребует крупных инвестиций, будет реализована тонкая подготовка, чтобы обеспечить развертывание первоначальной квоты почтового ящика на уровне 600 МБ. В последующие циклы бюджетирования базовое физическое хранилище будет увеличено для соответствия прогнозируемым потребностям.

Действие 3. Определение необходимости размещения журналов и баз данных на одном LUN

При использовании тонкой подготовки в объединенном хранилище EMC для развертываний Exchange 2010 рекомендуется разделять файлы журналов и файлы баз данных. Если прогнозируется рост размера почтовых ящиков за пределами профиля сообщений (это количество сообщений, отправляемых и получаемых в день), потребуется постепенно увеличивать номера LUN баз данных, но не номера LUN журналов. Размещение журналов на тонко подготовленных LUN может быть нежелательным.

Разделение LUN баз данных и журналов также обеспечивает гибкость при их сохранении на дисках разных типов или использовании различных уровней массивов RAID.

*Момент принятия решения*

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

Действие 4. Определение количества баз данных из расчета на LUN

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

• Перегрузка базы данных, влияющая на работоспособную базу данных.

• Операция заполнения в одной базе данных, влияющая на работоспособную базу данных.

• Пассивные операции ввода-вывода в базе данных, влияющие на активные базы данных.

*Момент принятия решения*

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

Действие 5. Определение количества LUN на каждом сервере почтовых ящиков основного центра данных

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

Количество LUN, необходимых для каждого сервера почтовых ящиков

Типы LUN	Количество LUN на каждом сервере
LUN активных баз данных	6
LUN активных журналов	6
LUN пассивных баз данных	6
LUN пассивных журналов	6
Всего LUN	24

Действие 6. Определение количества LUN на каждом сервере почтовых ящиков дополнительного центра данных

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

Количество LUN, необходимых для каждого сервера почтовых ящиков

Типы LUN	Количество LUN на каждом сервере
LUN пассивных баз данных	6
LUN пассивных журналов	6
Всего LUN	12

Действие 7. Определение стандартного блока хранилища

Чтобы упростить выполнение оставшихся этапов проектирования хранилища, используйте подход на основе стандартных блоков. В этом решении каждая база данных поддерживает 450 активных почтовых ящиков. Каждый сервер почтовых ящиков поддерживает 6 баз данных или 2700 активных почтовых ящиков на 6 LUN баз данных и 6 LUN журналов. Будет использоваться стандартный блок, состоящий из 12 LUN и поддерживающий обработку 2700 почтовых ящиков.

Действие 8. Определение требований к числу операций ввода-вывода в секунду для стандартного блока

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

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

  = 0.10 × 2700 × 20%

  = 324 операций ввода-вывода в секунду

Действие 9. Определение первоначального размера почтового ящика на диске

На предыдущем этапе был рассчитан размер почтового ящика на диске для предельной квоты почтового ящика на уровне 2048 МБ, составивший 2301 МБ. Так как будет использоваться тонкая подготовка, следует рассчитать первоначальный размер почтового ящика на диске. Указанное значение будет использовано в дальнейшем для определения первоначальных требований к емкости.

Следующие расчеты используются, чтобы определить первоначальный размер почтового ящика на диске для этого решения на основе квоты почтового ящика, составляющей 600 МБ:

• Свободное пространство = 100 сообщений в день × 75 ÷ 1024 МБ = 7,3 МБ

• Корзина = (100 сообщений в день × 75 ÷ 1024 МБ × 14 дней) + (600 МБ × 0,012) + (600 МБ × 0,058) = 144,2 МБ

• Размер почтового ящика на диске = ограничение почтового ящика + свободное пространство + корзина

  = 600 МБ + 7,3 МБ + 144,2 МБ

  = 752 МБ

Действие 10. Определение первоначальных требований к емкости базы данных в стандартном блоке

Чтобы определить первоначальную емкость хранилища, необходимую для 2700 почтовых ящиков, с первоначальной квотой почтового ящика, составляющей 600 МБ, используйте следующие расчеты:

• Размер файлов базы данных = (количество почтовых ящиков × размер почтового ящика на диске × надбавочный коэффициент роста базы данных) + (надбавка к объему данных в размере 20%)

  = (2700 × 752 × 1) + (406080)

  = 2 436 480 МБ

  = 2379 ГБ

• Размер каталога базы данных = 10% от размера файлов базы данных

  = 238 ГБ

• Общая емкость базы данных = (размер файлов базы данных) + (размер индекса) ÷ 0,80 для обеспечения свободного места на уровне 20% объема

  = (2379 + 238) ÷ 0.8

  = 3271 ГБ

Для шести баз данных в стандартном блоке требуется 3271 ГБ первоначальной емкости хранилища.

Действие 11. Определение требований к полностью подготовленной емкости базы данных стандартного блока

Чтобы определить полностью подготовленную емкость хранилища, необходимую для 2700 почтовых ящиков с квотой 2048 МБ на один почтовый ящик, используйте следующую формулу:

• Размер файлов базы данных = (количество почтовых ящиков × размер почтового ящика на диске × надбавочный коэффициент роста базы данных) + (надбавка к объему данных в размере 20%)

  = (2700 × 2301 × 1) + (1242540)

  = 7 455 240 МБ

  = 7281 ГБ

• Размер каталога базы данных = 10% от размера файлов базы данных

  = 728 ГБ

• Общая емкость базы данных = (размер файлов базы данных) + (размер индекса) ÷ 0,80 для обеспечения свободного места на уровне 20% объема

  = (7281 + 728) ÷ 0.8

  = 10 011 ГБ

Для шести баз данных в стандартном блоке необходимо 10 011 ГБ полностью подготовленной емкости хранилища.

Действие 12. Определение требований к свободному месту для журналов стандартного блока

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

• Необходимая емкость журнала стандартного блока = количество пользователей почтовых ящиков × количество журналов на почтовый ящик в день × размер журнала × (число дней, необходимых для замены сбойной инфраструктуры) + (процент буфера для перемещения почтовых ящиков)

  = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

  = 216 054 МБ

  = 211 ГБ

• Общая емкость журналов = емкость журнала ÷ 0,80 для обеспечения 20% свободного пространства

  = 211 ÷ 0.80

  = 264

Для шести наборов журналов в стандартном блоке требуется 264 ГБ.

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

Действие 13. Определение количества шпинделей, необходимых, чтобы удовлетворить требования к количеству операций ввода-вывода в секунду стандартного блока

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

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

• Количество дисков = (необходимое количество операций ввода-вывода в секунду × коэффициент операций считывания) + коэффициент уменьшения операций записи × (необходимое количество операций ввода-вывода в секунду × коэффициент операций записи) ÷ количество операций ввода-вывода в секунду, максимальное для выбранного типа дисков

  = (324 × 0.6) + 4 × (324 × 0.4) ÷ 155

  = 4.6

Требования к количеству операций ввода-вывода могут быть удовлетворены пятью дисками в конфигурации RAID-5.

Примечание.
Эти расчеты характерны для данного решения EMC. Проконсультируйтесь с поставщиком хранилища относительно требований к количеству шпинделей в выбранном решении.

Действие 14. Определение количества шпинделей, необходимых для поддержки требований к исходной вместимости базы данных стандартного блока

На предыдущем этапе мы определили, что для стандартного блока с 2700 почтовыми ящиками (первоначально выделено 600 МБ на ящик) требуется объем 3271 ГБ. Полезная емкость шпинделя объемом 450 ГБ (в конфигурации RAID-5 на CX4, модель 480) составляет около 402 ГБ. Чтобы определить необходимое количество дисков, используйте следующую формулу:

• Количество дисков = (требуемая общая емкость) ÷ (полезная емкость каждого шпинделя с RAID-5)

  = 3271 ГБ ÷ 402 ГБ

  = 8.1

Требованиям к исходной емкости базы данных удовлетворяет количество дисков, равное девяти.

Наилучшим решением для организации единого хранилища на EMC при использовании тонкой подготовки будет сконфигурировать тонкие пулы RAID-5 группами по пять дисков. Выделите 10 дисков для стандартного блока с 2700 почтовыми ящиками, чтобы обеспечить свободное место для дальнейшего роста.

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

На предыдущем этапе мы определили, что для стандартного блока с 2700 почтовыми ящиками (первоначально выделено 2048 МБ на ящик) требуется объем 10 011 ГБ. Полезная емкость шпинделя объемом 450 ГБ (в конфигурации RAID-5 на CX4, модель 480) составляет около 402 ГБ. Чтобы определить необходимое количество дисков, используйте следующую формулу:

• Количество дисков = (требуемая общая емкость) ÷ (полезная емкость каждого шпинделя с RAID-5)

  = 10 011 ГБ ÷ 402 ГБ

  = 24.9

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

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

На предыдущем этапе мы определили, что для стандартного блока с 2700 почтовыми ящиками для хранения журнала требуется 264 ГБ. Использование двух дисков объемом 450 ГБ в конфигурации RAID-1/0 на CX4-480 обеспечит 402 ГБ полезной емкости хранилища. Предложенная конфигурация из двух дисков удовлетворяет требованиям стандартного блока с 2700 почтовыми ящиками к емкости журнала.

Действие 17. Определение стратегии тонкого пула

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

Существуют три модели, которые могут быть использованы при создании тонких пулов для Exchange:

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

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

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

*Момент принятия решения*

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

Действие 18. Определение начального количества шпинделей на один тонкий пул

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

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

Третий тонкий пул будет содержать стандартный блок с 2700 почтовыми ящиками каждого из четырех дополнительных почтовых серверов в центре данных сайта (серверы другой группы обеспечения доступности базы данных, на которых на случай сбоя хранятся копии базы данных сайта). Для третьего пула, поддерживающего 10 800 пассивных почтовых ящиков, потребуется 40 шпинделей.

Чтобы удовлетворить требованиям к исходной емкости базы данных, потребуется 120 шпинделей на площадку.

Действие 19. Определение количества полностью подготовленных шпинделей на один тонкий пул

Первый тонкий пул будет содержать стандартный блок с 2700 почтовыми ящиками каждого из четырех основных серверов почтовых ящиков в центре данных сайта. На предыдущем этапе мы определили, что для удовлетворения требованиям к количеству операций ввода-вывода в секунду и полностью подготовленной емкости стандартного блока потребуется 25 шпинделей. Для первого тонкого пула, поддерживающего 10 800 активных почтовых ящиков, потребуется 100 шпинделей.

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

Третий тонкий пул будет содержать стандартный блок с 2700 почтовыми ящиками каждого из четырех дополнительных почтовых серверов в центре данных сайта (серверы другой группы обеспечения доступности базы данных, на которых на случай сбоя хранятся копии базы данных сайта). Для третьего пула, поддерживающего 10 800 пассивных почтовых ящиков, потребуется 100 шпинделей.

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

Действие 20. Определение количества шпинделей, необходимого для поддержки всех номеров LUN журналов

На предыдущем этапе мы определили, что для каждого стандартного блока с 2700 почтовыми ящиками требуется два шпинделя, чтобы удовлетворить требованиям к номерам LUN журналов.

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

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

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

Чтобы удовлетворить требованиям к LUN журнала на отдельном сайте, требуется 24 шпинделя.

Действие 21. Проверка того, что хранилище удовлетворяет требованиям к начальному количеству шпинделей

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

• Общее количество шпинделей на сайт = количество шпинделей, необходимое для номеров LUN базы данных + количество шпинделей, необходимое для номеров LUN журнала

  = 120 + 24

  = 144

У A CX4-480 с корпусами для десятидисковых массивов имеется 150 шпинделей, что удовлетворяет требованиям.

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

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

• Общее количество шпинделей на сайт = количество шпинделей, необходимое для номеров LUN базы данных + количество шпинделей, необходимое для номеров LUN журнала

  = 300 + 24

  = 324

У A CX4-480 с корпусами для двадцатидвухдисковых массивов имеется 330 шпинделей, что удовлетворяет требованиям.

Протестированные решения для Exchange 2010

Обзор решения

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

Протестированные решения для Exchange 2010

Схема логического решения

В данное решение всего входит 36 серверов Exchange 2010, развернутых с использованием топологии с несколькими производственными площадями. Двенадцать из 36 серверов выполняют одновременно роль сервера клиентского доступа и транспортного сервера-концентратора. Остальные 24 сервера выполняют роль серверов почтовых ящиков. Имеется группа серверов клиентского доступа с четырьмя серверами на каждой площадке, выполняющими одновременно функции клиентского сервера и транспортного сервера-концентратора. Имеется три группы обеспечения доступности баз данных с восемью серверами почтовых ящиков в каждой. На файловых серверах каждой площадки расположены основные и альтернативные файловые следящие серверы для каждой группы обеспечения доступности баз данных.

Схема логического решения

Протестированные решения для Exchange 2010

Схема физического решения

На каждой из трех площадок имеются четыре блейд-сервера Cisco B200, соединенных с массивом хранения EMC CLARiiON CX4 480 посредством коммутаторов Cisco Fabric Interconnect 6120 и Cisco MDS 9134. Резервируемые коммутаторы Cisco Nexus 5010 Ethernet создают основу сетевой инфраструктуры. На каждой площадке клиентский трафик распределяется между массивом серверов клиентского доступа посредством избыточных распределителей нагрузки Cisco ACE 4710.

Схема физического решения

Протестированные решения для Exchange 2010

Таблица конфигурации корневого сервера Hyper-V

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

Сводные характеристики Cisco Unified Computing System

Элемент	Описание
Блейд-сервер	4 × B200 M1
Процессоры	2 × Intel Zeon x5570 (2,93 ГГц)
память;	ОЗУ 96 ГБ (12 × 8 ГБ DIMM)
Конвергентный сетевой адаптер	M71KR-Q (2 × 10 Гбит/с Ethernet и 2 × 4 Гбит/с Fibre Channel)
Внутреннее хранилище блейд-сервера	2 диска объемом 146 ГБ (SAS, 10 000 об/мин); RAID-1
Шасси	5108 (6RU)
Расширитель матрицы	2 × 2104XP
Межсоединение	2 × 6120XP
Fabric interconnect expansion module	2 × 8-портовых Fibre Channel (4 Гбит/с)

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

Коммутаторы LAN и SAN

Элемент	Описание
Коммутатор 10 Гбит Ethernet (GbE)	2 × Nexus 5010 (8 фиксированных портов 1 GbE/10 GbE портов, 12 фиксированных портов 10 GbE, мост центра данных)
Коммутатор Fibre Channel	2 × MDS 9134 (32 фиксированных порта 4 Гбит/с)

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

Программное обеспечение, используемое в решении

Элемент	Описание
Низкоуровневая оболочка хост-серверов	Windows Server 2008 R2 Hyper-V Enterprise
Виртуальные машины серверов Exchange	Windows Server 2008 R2 Enterprise
Роль сервера почтовых ящиков Exchange Server 2010	Enterprise Edition RU2
Роль сервера клиентского доступа и транспортного сервера-концентратора Exchange Server 2010	Standard Edition RU2
Балансировка многопутевых операций и операций ввода/вывода	EMC PowerPath

Протестированные решения для Exchange 2010

Конфигурация сервера клиентского доступа и транспортного сервера-концентратора

В данной таблице представлена информация о конфигурации сервера, выполняющего одновременно функции сервера клиентского доступа и транспортного сервера-концентратора в данном решении.

Конфигурация сервера клиентского доступа и транспортного сервера-концентратора

Компонент	Значение или описание
Физический или виртуальный	Виртуальная машина Hyper-V
Виртуальные процессоры	3
память;	8 ГБ
Хранилище	Виртуальный жесткий диск на томе с операционной системой корневого сервера
Операционная система	Windows Server 2008 R2
Версия сервера Exchange Server	Exchange Server 2010 Standard Edition
Уровень обновления сервера Exchange	Накопительный пакет обновлений 2 для Exchange 2010
Программное обеспечение сторонних производителей	Нет

Протестированные решения для Exchange 2010

Конфигурация сервера почтовых ящиков

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

Конфигурация основного сервера почтовых ящиков

Компонент	Значение или описание
Физический или виртуальный	Виртуальная машина Hyper-V
Виртуальные процессоры	4
память;	53 ГБ
Хранилище	Виртуальный жесткий диск на томе с операционной системой корневого сервера
Операционная система	Windows Server 2008 R2
Версия сервера Exchange Server	Exchange Server 2010 Enterprise Edition
Уровень обновления сервера Exchange	Накопительный пакет обновлений 2 для Exchange 2010
Программное обеспечение сторонних производителей	Нет

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

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

Компонент	Значение или описание
Физический или виртуальный	Виртуальная машина Hyper-V
Виртуальные процессоры	2
память;	24 ГБ
Хранилище	Виртуальный жесткий диск на томе с операционной системой корневого сервера
Операционная система	Windows Server 2008 R2
Версия сервера Exchange Server	Exchange Server 2010 Enterprise Edition
Уровень обновления сервера Exchange	Накопительный пакет обновлений 2 для Exchange 2010
Программное обеспечение сторонних производителей	Нет

Протестированные решения для Exchange 2010

Структура базы данных

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

Структура копий баз данных: 1

Структура копий баз данных: 2

Структура копий баз данных: 3

Протестированные решения для Exchange 2010

Сводные данные об оборудовании хранилища

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

Объединенное хранилище EMC NS-480 (с интегрированными CLARiiON CX4-480)

Элемент	Описание
Хранилище	3 CLARiiON CX4-480 (по 1 на площадку)
Подключение хранилища (Fibre Channel, SAS, SATA, iSCSI)	Fibre Channel
Кэш хранилища	32 ГБ (кэш чтения объемом 600 МБ и кэш записи объемом 10 160 МБ для каждого порта хранилища)
Количество контроллеров хранилища	2 в каждом корпусе хранилища
Количество портов хранилища, которые доступны или используются	Доступно 8 (4 на порт хранилища) в каждом корпусе хранилища, используется 4 (2 на порт хранилища)
Максимальную пропускную способность соединения хранилища с узлом	8 × 4 Гбит/с
Общее протестированное количество дисков для решения	432 (360 для баз данных и 72 для журналов на всех 3 площадках)
Максимальное количество шпинделей, которые могут быть размещены в хранилище	480 в одном массиве хранилища

Протестированные решения для Exchange 2010

Конфигурация хранилища

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

Конфигурация хранилища

Компонент	Значение или описание
Общее число корпусов хранилищ	3
Общее число корпусов хранилищ на каждой площадке	1
Общее число дисков в одном корпусе	150
Общее число пулов хранения в одном корпусе	3
Общее число дисков в пуле хранения (первоначальное)	40
Общее число дисков в LUN базы данных (первоначальное)	10
Общее число дисков в LUN журнала	2
Общее число используемых дисков в одном корпусе	144
Объем LUN базы данных (первоначальный)	4020 ГБ
Объем LUN журналов	402 ГБ
Уровень RAID для баз данных	5
Уровень RAID для журналов	1/0

В приведенной ниже таблице показана структура и распределение доступного дискового пространства для трех хранилищ модели CX4 480.

Конфигурация хранилища, состоящего из систем CX4 480

Центр данных	Группа обеспечения доступности баз данных	Database	Массив 1	Массив 2	Массив 3
1	1	DB1-24	C1, C2		C3
2	2	DB25-48	C3	C1, C2
3	3	DB49-72		C3	C1, C2

Протестированные решения для Exchange 2010

Методология проверки решения

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

• Тесты производительности.

  • Проверка производительности хранилища (Jetstress).

  • Проверка производительности сервера (Loadgen).

• Функциональные тесты.

  • Проверка переключения базы данных.

  • Проверка переключения сервера.

  • Проверка отказоустойчивости сервера.

  • Проверка переключения центра данных.

Протестированные решения для Exchange 2010

Методология проверки макета хранилища

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

Набор инструментов

В целях проверки размера и конфигурации хранилища Exchange рекомендуется использовать средство Jetstress для Microsoft Exchange Server. Инструмент Jetstress предназначен для имитации рабочей нагрузки операций ввода-вывода Exchange на уровне базы данных путем прямого взаимодействия с технологией ESE, также известной как Jet. ESE — это технология баз данных, которую сервер Exchange использует для сохранения данных обмена сообщениями в рамках роли сервера почтовых ящиков. Средство Jetstress можно настроить для проверки максимальной пропускной способности по операциям ввода-вывода, доступной в подсистеме хранения с учетом требуемых ограничений производительности Exchange. Jetstress может также принимать целевой профиль количества пользователей и операций ввода-вывода в секунду по каждому пользователю, а также проверять, что подсистема хранения способна поддерживать допустимый уровень производительности при использовании этого профиля. Тестирование имеет настраиваемую продолжительность и может быть запущено в течение минимального периода времени для проверки соответствующей производительности или в течение длительного периода времени для дополнительной проверки надежности подсистемы хранения.

Средство Jetstress можно получить в центре загрузки Майкрософт по следующим адресам:

• Microsoft Exchange Server Jetstress 2010 (64-разрядная версия)

• Microsoft Exchange Server Jetstress 2010 (32-разрядная версия)

Документация, входящая в состав установщика Jetstress, описывает способы настройки и выполнения проверочного теста Jetstress на серверном оборудовании.

Подход к проверке хранилища

Существует два основных типа конфигураций хранилища:

• Сценарии с использованием DAS или внутренних дисков.

• Сценарии с использованием сети SAN.

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

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

Тестовые случаи для проверки хранилища

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

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

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

Анализ результатов

Средство Jetstress создает файл отчета после завершения каждого теста. Подробные инструкции по анализу отчета см. в разделе Jetstress 2010 Test Summary Reports.

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

Анализ результатов Jetstress

Экземпляр счетчика производительности	Инструкции по тесту производительности
Средняя задержка чтения при вводе-выводе для базы данных (мс)	Среднее значение должно быть менее 20 миллисекунд (мс) (0,020 секунды), а максимальные значения — менее 50 мс.
Средняя задержка записи в журнал при вводе-выводе (мс)	Записи в журнал на диске выполняются последовательно, поэтому средняя величина задержки при записи должна составлять менее 10 мс, а максимальное значение — не более 50 мс.
% процессорного времени	Среднее значение должно быть менее 80%, а максимальное — менее 90%.
Переходных многоцелевых страниц/с (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)	Среднее значение должно быть менее 100.

В файле отчета приводятся различные категории операций ввода-вывода, выполняемых системой Exchange.

• Производительность транзакционных операций ввода-вывода. В этой таблице перечисляются операции ввода-вывода, отражающие действия пользователей по отношению к базе данных (например, операции ввода-вывода, выполняемые приложением Outlook). Чтобы получить такие данные, количество операций ввода-вывода при обслуживании в фоновом режиме и репликации журналов вычитается из общего количества операций ввода-вывода, определенного во время тестирования. Данные позволяют оценить фактическое число операций базы данных по вводу-выводу в секунду с учетом измерений величины задержки ввода-вывода, необходимых для того, чтобы определить успешность выполнения теста производительности Jetstress.

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

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

• Общая производительность операций ввода-вывода. В этой таблице указано общее количество операций ввода-вывода, выполненных во время тестирования Jetstress.

Протестированные решения для Exchange 2010

Проверка макета сервера

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

Набор инструментов

Для проверки производительности и масштабируемости комплексного решения рекомендуется использовать средство имитации серверной нагрузки Microsoft Exchange Server Load Generator (Loadgen). Средство Loadgen предназначено для имитации рабочей нагрузки клиента в развертывании Exchange. Эта рабочая нагрузка может использоваться для оценки производительности системы Exchange и влияния различных изменений конфигурации на общее решение в условиях, когда система находится под нагрузкой. Средство Loadgen может имитировать работу клиентских компонентов Microsoft Office Outlook 2007 (в Интернете и в кэше), Office Outlook 2003 (в Интернете и в кэше), POP3, IMAP4, SMTP, ActiveSync и Outlook Web App (который имел название Outlook Web Access в Exchange 2007 и более ранних версиях системы). Оно может использоваться для создания рабочей нагрузки на отдельный протокол. Указанные клиентские протоколы можно также объединять для создания рабочей нагрузки на несколько протоколов.

Инструмент Loadgen доступен в центре загрузки Майкрософт по следующим адресам:

• Exchange Load Generator 2010 (64-разрядная версия)

• Exchange Load Generator 2010 (32-разрядная версия)

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

Подход к проверке сервера

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

Системный монитор

На представленном снимке системного монитора, который отображает различные счетчики, соответствующие объему работ, выполняемых Exchange в динамике по времени на рабочем сервере почтовых ящиков, среднее значение числа операций RPC в секунду (выделенная линия) составляет около 2386 при средневзвешенных измерениях в течение всего дня. Среднее значение этого счетчика в период пиковой нагрузки (с 10:00 до 11:00) составляет 4971 при соотношении пиковой и средней нагрузок на уровне 2,08.

Чтобы гарантировать возможность решения Exchange поддержать рабочую нагрузку, создаваемую в течение среднего пикового периода, измените параметры средства Loadgen для формирования постоянной нагрузки на уровне средних пиковых значений вместо распределения рабочей нагрузки в течение всего рабочего дня. Модули имитации Loadgen на основе задач (например, модули имитации приложения Outlook) используют профиль задач, определяющий, сколько раз каждая задача возникнет для среднестатистического пользователя в течение имитируемого дня.

Общее количество задач, которые необходимо выполнить в течение имитируемого дня, рассчитывается как число пользователей, умноженное на сумму значений счетчиков задач в настроенном профиле задач. Затем средство Loadgen определяет скорость, при которой следует выполнять задачи для настроенной группы пользователей, разделив общее количество задач для выполнения в течение имитируемого дня на продолжительность этого дня. Например, если средству Loadgen необходимо выполнить 1 000 000 задач в течение имитируемого дня и его продолжительность составляет 8 часов (28 800 секунд), для соответствия требуемому определению рабочей нагрузки скорость их выполнения составит 1 000 000 ÷ 28 800 = 34,72 задачи в секунду. Чтобы повысить уровень нагрузки до требуемого среднего пикового значения, разделите стандартную продолжительность имитируемого дня (8 часов) на соотношение пиковой и средней нагрузок (2) и используйте полученное значение в качестве новой продолжительности имитируемого дня.

Снова используя пример расчета скорости выполнения задач, получим: 1 000 000 ÷ 14 400 = 69,44 задач в секунду. Благодаря этому продолжительность имитируемого дня сокращается наполовину, что приводит к удвоению фактической рабочей нагрузки при выполнении на сервере и достижению целевой средней пиковой нагрузки. В конфигурации средства Loadgen не требуется настраивать продолжительность выполнения теста. Продолжительность выполнения определяет длительность теста и не оказывает влияния на скорость выполнения задач на сервере Exchange.

Тестовые случаи для проверки макета сервера

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

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

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

Проведение теста и сбор данных

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

Проверка ожидаемой нагрузки

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

Расчет ожидаемой пиковой скорости доставки сообщений

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

Пиковая скорость доставки сообщений

Профиль сообщения	Сообщений, отправляемых в день	Сообщений, получаемых в день
50	10	40
100	20	80
150	30	120
200	40	160

В следующем примере предполагается, что каждый сервер почтовых ящиков содержит 5000 активных почтовых ящиков с профилем на уровне 150 сообщений в день (ежедневно отправляется 30 сообщений и принимается 120 сообщений).

Пиковая скорость доставки сообщений для 5000 активных почтовых ящиков

Описание	Расчет	Значение
Профиль сообщения	Количество сообщений, получаемых в день	120
Количество активных почтовых ящиков на каждом сервере почтовых ящиков	Неприменимо	5000
Всего сообщений, получаемых в день, для каждого сервера почтовых ящиков	5000 × 120	600000
Всего сообщений, получаемых в секунду, для каждого сервера почтовых ящиков	600000 ÷ 28800	20.83
Всего сообщений с учетом пиковой нагрузки	20.83 × 2	41.67

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

Определение фактической скорости доставки сообщений

Фактическую скорость доставки сообщений можно определить с помощью следующего счетчика на каждом сервере почтовых ящиков: доставлено сообщений/с для почтового ящика MSExchangeIS(_Total). Если измеренная скорость доставки сообщений не превышает одного–двух сообщений в секунду из расчета целевой скорости, можно с уверенностью утверждать, что требуемый профиль нагрузки был успешно реализован.

Проверка сервера: критерии производительности и работоспособности

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

Корневые серверы Hyper-V

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

Hyper-V содержит три основных компонента: стек виртуализации, низкоуровневую оболочку и устройства. Стек виртуализации обрабатывает эмулированные устройства, управляет виртуальными машинами и обслуживает операции ввода-вывода. Низкоуровневая оболочка планирует работу виртуальных процессоров, управляет прерываниями, обслуживает таймеры и осуществляет контроль над другими функциями на уровне микросхем. Она не обрабатывает операции устройств или ввода-вывода (например, при отсутствии драйверов для низкоуровневой оболочки). Устройства являются частью корневого сервера или устанавливаются на гостевых серверах в составе служб интеграции. Поскольку корневой сервер обеспечивает полное представление системы и контроль над виртуальными машинами, он также предоставляет сведения о мониторинге посредством инструментария управления Windows (WMI) и счетчиков производительности.

Процессор

При проверке степени использования физического процессора на корневом сервере (или на гостевой виртуальной машине) стандартный счетчик "Процессор\% загруженности процессора" не предоставит полезных сведений.

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

Счетчик	Целевой объект
% общего времени работы логического процессора низкоуровневой оболочки Hyper-V	<80%

Если требуется узнать, какой процент времени процессора расходуется на обслуживание гостевых виртуальных машин, можно изучить показания счетчика "% времени гостевой работы логического процессора низкоуровневой оболочки Hyper-V". Если требуется узнать, какой процент времени процессора расходуется на низкоуровневую оболочку, можно изучить показания счетчика "% времени работы низкоуровневой оболочки логического процессора низкоуровневой оболочки Hyper-V". Значение этого счетчика не должно превышать 5 процентов. Счетчик "% времени гостевой работы корневого виртуального процессора низкоуровневой оболочки Hyper-V" показывает долю (в процентах) времени процессора, затрачиваемого на стек виртуализации. Значение этого счетчика также должно быть меньше 5 процентов. Эти два счетчика можно использовать для определения доли (в процентах) доступного времени физического процессора, используемого для поддержки виртуализации.

Счетчик	Целевой объект
% времени гостевой работы логического процессора низкоуровневой оболочки Hyper-V	<80%
% времени работы низкоуровневой оболочки логического процессора низкоуровневой оболочки Hyper-V	<5%
% времени гостевой работы корневого виртуального процессора низкоуровневой оболочки Hyper-V	<5%

память;

Необходимо обеспечить, чтобы на корневом сервере Hyper-V имелось достаточно памяти для поддержки памяти, выделенной виртуальным машинам. Hyper-V автоматически резервирует 512 МБ (это значение может отличаться в разных выпусках Hyper-V) для корневой операционной системы. Если памяти недостаточно, Hyper-V заблокирует запуск последней виртуальной машины. Как правило, не следует беспокоиться о проверке памяти на корневом сервере Hyper-V. Вместо этого особое внимание следует уделить обеспечению достаточного объема памяти, выделяемой виртуальным машинам для поддержки ролей сервера Exchange.

Работоспособность приложений

Чтобы определить, все ли виртуальные машины находятся в работоспособном состоянии, проще всего изучить показания сводных счетчиков работоспособности виртуальных машин Hyper-V.

Счетчик	Целевой объект
Сводные данные о работоспособности виртуальных машин Hyper-V\Работоспособность в норме	1
Сводные данные о работоспособности виртуальных машин Hyper-V\Критическое состояние	0

Серверы почтовых ящиков

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

Процессор

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

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

В отношении физических развертываний сервера Exchange используйте счетчик "Процессор(_Total)\% загруженности процессора" и убедитесь в том, что его значение в среднем составляет менее 80 процентов.

Счетчик	Целевой объект
Процессор(_Total)\% загруженности процессора	<80%

В отношении виртуальных развертываний сервера Exchange показания счетчика "Процессор(_Total)\% загруженности процессора" оцениваются в пределах виртуальной машины. В этом случае счетчик не измеряет степень использования физического ЦП. Он измеряет степень использования виртуального ЦП, представляемого низкоуровневой оболочкой. Поэтому он не обеспечивает точного считывания показаний физического процессора и должен использоваться в целях проверки макетов. Дополнительные сведения см. в статье Hyper-V: каким счетчикам производительности можно доверять.

Для проверки развертываний сервера Exchange под управлением системы Microsoft Hyper-V используйте счетчик "% времени работы низкоуровневой оболочки виртуального процессора низкоуровневой оболочки Hyper-V". Он позволяет получить более точное значение использования физического ЦП операционной системой на виртуальной машине. Значение этого счетчика в среднем должно быть меньше 80 процентов.

Счетчик	Целевой объект
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<80%

память;

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

Проверка наличия достаточного объема памяти на сервере почтовых ящиков Exchange для поддержки целевой рабочей нагрузки — непростая задача. Использование доступных счетчиков памяти для просмотра объема оставшейся физической памяти не решит проблему, так как диспетчер памяти в Exchange предназначен для потребления практически всей доступной физической памяти. Банк сообщений (store.exe) резервирует большой фрагмент физической памяти для кэша базы данных. Кэш базы данных используется для хранения страниц базы данных в памяти. Когда страница доступна в памяти, информацию не требуется получать с диска, что сокращает объем операций ввода-вывода при чтении. Кэш базы данных также используется для оптимизации операций ввода-вывода при записи.

При изменении страницы базы данных (которая называется "грязной" страницей) она остается в кэше в течение некоторого периода времени. Чем дольше она хранится в кэше, тем выше вероятность, что страница будет изменена несколько раз перед тем, как эти изменения будут записаны на диск. Сохранение "грязных" страниц в кэше также приводит к записи нескольких страниц на диск в пределах одной операции (которая называется объединением записи). Exchange использует максимально возможный объем доступной памяти в системе, поэтому на сервере почтовых ящиков Exchange отсутствуют большие объемы доступной памяти.

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

Хранилище

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

На первом этапе процесса проверки хранилища следует удостовериться в том, что значения задержки базы данных находятся ниже установленных пороговых значений. В предыдущих выпусках счетчики логических дисков определяли задержку при чтении и записи на диск. В системе Exchange 2010 отслеживаемый сервер почтовых ящиков Exchange, вероятно, содержит набор копий активных и пассивных баз данных почтовых ящиков. Характеристики ввода-вывода копий активных и пассивных баз данных различаются. Так как размер подсистемы ввода-вывода в пассивных копиях намного больше, их показатели задержки, как правило, имеют гораздо более высокий уровень. Целевые значения задержки для пассивных баз данных составляют 200 мс, что в 10 раз выше целевых значений для копий активных баз данных. Это не является проблемой, так как высокие уровни задержки в пассивных базах данных не влияют на работу клиентских систем. Однако если для измерения значений задержки используются традиционные счетчики логических дисков, необходимо проверить отдельные тома и отделить те из них, которые содержат активные и пассивные базы данных. Вместо этого рекомендуется использовать новые счетчики баз данных MSExchange в версии Exchange 2010.

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

Счетчик	Целевой объект
Средняя задержка операций чтения при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс
Средняя задержка операций записи при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<1 мс

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

Счетчик	Целевой объект
Средняя задержка операций чтения при вводе-выводе в базе данных (при восстановлении) для базы данных MSExchange	<200 мс
Средняя задержка операций записи при вводе-выводе в базе данных (при восстановлении) для базы данных MSExchange	<200 мс
Средняя задержка операций чтения при вводе-выводе в журнале для базы данных MSExchange	<200 мс

Примечание.
Чтобы просмотреть указанные счетчики в системном мониторе, необходимо включить дополнительные счетчики баз данных. Дополнительные сведения см. в статье Включение дополнительных счетчиков производительности системы ESE.

При проверке значений задержки на дисках для развертываний Exchange, выполняющихся под управлением Microsoft Hyper-V, следует помнить о том, что счетчики средней задержки базы данных по операциям ввода-вывода (как и многие временные счетчики) могут не предоставлять точных значений, поскольку понятие времени на виртуальной машине отличается от времени на физическом сервере. В следующем примере показано, что средняя задержка операций чтения при вводе-выводе в базе данных (прикрепленной) для одной и той же имитируемой рабочей нагрузки составляет 22,8 на виртуальной машине и 17,3 на физическом сервере. Если значения временных счетчиков превышают установленные пороговые значения, возможно, сервер работает правильно. Проверьте все критерии работоспособности для принятия решения, связанного с работоспособностью сервера, при развертывании роли сервера почтовых ящиков на виртуальной машине.

Значения счетчиков задержки на дисках для виртуальных и физических серверов почтовых ящиков

Счетчик	Виртуальный сервер почтовых ящиков	Физический сервер почтовых ящиков
База данных MSExchange/
Средняя задержка чтения при вводе-выводе для базы данных (прикрепленной)	22.792	17.250
Операций чтения при вводе-выводе для базы данных (прикрепленной)/с	17.693	18.131
Средняя задержка чтения (восстановления) при вводе-выводе для базы данных	34.215	27.758
Операций записи (восстановления) при вводе-выводе для базы данных/с	10.829	8.483
Средняя задержка записи при вводе-выводе для базы данных (прикрепленной)	0.944	0.411
Операций записи при вводе-выводе для базы данных (прикрепленной)/с	10.184	10.963
MSExchangeIS
Ńđĺäí˙˙ çŕäĺđćęŕ RPC	1.966	1.695
Операций RPC/с	334.371	341.139
Пакетов RPC/с	180.656	183.360
почтовый ящик банка данных MSExchange
Доставлено сообщений/с	2.062	2.065
Отправлено сообщений/с	0.511	0.514

Помимо значений задержки на дисках, просмотрите показания счетчика "Сбоев при ожидании страниц базы данных/с". Этот счетчик показывает частоту возникновения ошибок страниц, обслуживание которых выполнить невозможно из-за отсутствия страниц, доступных для выделения из кэша базы данных. Его значение на работоспособном сервере должно быть равно 0.

Счетчик	Целевой объект
Сбоев при ожидании страниц базы данных/с	<1

Кроме того, просмотрите значения счетчика "Ожиданий записи в журнал базы данных/с", показывающего число записей журнала, которые не удается добавить в буферы журнала из-за того, что они заполнены (в секунду). Его значение в среднем должно быть меньше 10.

Счетчик	Целевой объект
Ожиданий записи в журнал базы данных/с	<10

Работоспособность приложений Exchange

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

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

Счетчик	Целевой объект
Средняя задержка RPC для процесса MSExchangeIS	<10 мс в среднем
Запросов RPC для процесса MSExchangeIS	<70 в любой момент времени

Далее убедитесь, что транспортный уровень работоспособен. Любые проблемы в транспорте или проблемы с нисходящими потоками, влияющие на транспортный уровень, можно обнаружить с помощью счетчика "Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)". Его значение всегда должно быть меньше 50. Возможно временное повышение значений этого счетчика, но они не должны расти в динамике по времени и не должны сохраняться на таком уровне более 15 минут.

Счетчик	Целевой объект
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	<50 в любой момент времени

Далее убедитесь в том, что обслуживание копий баз данных находится в работоспособном состоянии. Любые проблемы с доставкой или преобразованием журналов можно определить с помощью счетчиков "CopyQueueLength для репликации MSExchange(*)" и "ReplayQueueLength для репликации MSExchange(*)". Длина очереди копирования показывает число файлов журнала транзакций, ожидающих копирования в папку с файлами журнала пассивной копии, и должна быть меньше 1 в любой момент времени. Длина очереди преобразования показывает количество файлов журнала транзакций, ожидающих преобразования в пассивную копию, и должна быть меньше 5. Более высокие значения не влияют на работу клиентских систем, но приводят к росту времени подключения хранилища при перемещении вручную, отработке отказа или выполнении активации.

Счетчик	Целевой объект
CopyQueueLength для репликации MSExchange(*)	<1
ReplayQueueLength для репликации MSExchange(*)	<5

Серверы клиентского доступа

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

Процессор

В отношении физических развертываний сервера Exchange используйте счетчик "Процессор(_Total)\% загруженности процессора". Значение этого счетчика в среднем должно быть меньше 80 процентов.

Счетчик	Целевой объект
Процессор(_Total)\% загруженности процессора	<80%

Для проверки развертываний сервера Exchange под управлением системы Microsoft Hyper-V используйте счетчик "% времени работы низкоуровневой оболочки виртуального процессора низкоуровневой оболочки Hyper-V". Он позволяет получить точное значение объема физического ЦП, используемого операционной системой на виртуальной машине. Значение этого счетчика в среднем должно быть меньше 80 процентов.

Счетчик	Целевой объект
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<80%

Работоспособность приложений

Чтобы определить, является ли работа клиента MAPI допустимой, используйте счетчик "Средняя задержка RPC для службы MSExchange RpcClientAccess". Его значение не должно превышать 250 мс. Высокие уровни задержки могут быть связаны с большим количеством запросов RPC. Среднее значение счетчика "Запросов RPC для службы MSExchange RpcClientAccess" должно быть ниже 40.

Счетчик	Целевой объект
Средняя задержка RPC для службы MSExchange RpcClientAccess	<250 мс
Запросов RPC для службы MSExchange RpcClientAccess	<40

Транспортные серверы

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

Процессор

В отношении физических развертываний сервера Exchange используйте счетчик "Процессор(_Total)\% загруженности процессора". Значение этого счетчика в среднем должно быть меньше 80 процентов.

Счетчик	Целевой объект
Процессор(_Total)\% загруженности процессора	<80%

Для проверки развертываний сервера Exchange под управлением системы Microsoft Hyper-V используйте счетчик "% времени работы низкоуровневой оболочки виртуального процессора низкоуровневой оболочки Hyper-V". Он позволяет получить точное значение объема физического ЦП, используемого операционной системой на виртуальной машине. Значение этого счетчика в среднем должно быть меньше 80 процентов.

Счетчик	Целевой объект
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<80%

Диск

Чтобы определить, является ли производительность диска допустимой, используйте счетчики "Логический диск(*)\Среднее время чтения с диска (сек)" и "Логический диск(*)\Среднее время записи на диск (сек)" для томов, содержащих базу данных и журналы транспорта. Значения обоих счетчиков должны быть меньше 20 мс.

Счетчик	Целевой объект
Логический диск(*)\Среднее время чтения с диска (сек)	<20 мс
Логический диск(*)\Среднее время записи на диск (сек)	<20 мс

Работоспособность приложений

Чтобы определить правильность определения размера и работоспособность транспортного сервера-концентратора, изучите показания счетчиков "Очереди MSExchangeTransport", перечисленные в следующей таблице. Во всех указанных очередях в разное время будут присутствовать сообщения. Необходимо обеспечить, чтобы длина очереди не сохранялась и не росла с течением времени. Возникновение длинных очередей может указывать на перегрузку транспортного сервера-концентратора. При этом также возможны сетевые проблемы или перегруженный сервер почтовых ящиков, которому не удается получить новые сообщения. В этом случае потребуется проверить другие компоненты среды Exchange.

Счетчик	Целевой объект
Очереди MSExchangeTransport (_total)\Общая доставка	<3000
Очереди MSExchangeTransport (_total)\Длина очереди активной удаленной доставки	<250
Очереди MSExchangeTransport (_total)\Длина очереди активной доставки для почтового ящика	<250
Очереди MSExchangeTransport (_total)\Длина очереди повторных попыток доставки для почтового ящика	<100
Очереди MSExchangeTransport (_total)\Длина очереди передачи	<100

Протестированные решения для Exchange 2010

Функциональные проверочные тесты

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

Протестированные решения для Exchange 2010

Проверка переключения базы данных

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

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

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

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

Get-MailboxDatabaseCopyStatus <DatabaseName>

Протестированные решения для Exchange 2010

Проверка переключения сервера

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

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

  Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
  

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

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

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

  Отключите текущий активный сервер.

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

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

Протестированные решения для Exchange 2010

Проверка отказоустойчивости сервера

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

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

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

• Отсоедините кабели питания от сервера, что приведет к его выключению.

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

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Протестированные решения для Exchange 2010

Проверка переключения центра данных

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

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

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

1. Завершите работу частично неисправного центра данных.

2. Проверьте и подтвердите наличие необходимых условий для второго центра данных.

3. Активируйте серверы почтовых ящиков.

4. Активируйте серверы клиентского доступа.

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

Завершение работы частично неисправного центра данных (если группа обеспечения доступности баз данных находится в режиме DAC)

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

• Если серверы почтовых ящиков в неисправном центре данных по-прежнему доступны (обычно это не так), на каждом таком сервере выполните следующую команду.

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
  

• Если серверы почтовых ящиков в неисправном центре данных недоступны, но служба Active Directory в основном центре данных работает, на контроллере домена выполните следующую команду.

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
  

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

Критерии успеха: все серверы почтовых ящиков на неисправном сайте остановлены. Это можно проверить, выполнив следующую команду на сервере в неисправном центре данных.

Get-DatabaseAvailabilityGroup | Format-List

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

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

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

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

Критерии успеха: все серверы почтовых ящиков в неисправном центре данных остановлены. Чтобы проверить это, на сервере в дополнительном центре данных выполните следующую команду.

Get-DatabaseAvailabilityGroup | Format-List

Активация серверов почтовых ящиков (если группа обеспечения доступности баз данных находится в режиме DAC)

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

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

1. Остановите службу кластеров для каждого участника группы обеспечения доступности баз данных в дополнительном центре данных. Можно использовать командлет Stop-Service, чтобы остановить эту службу (например, Stop-Service ClusSvc), или выполнить команду net stop clussvc в командной строке с повышенными привилегиями.

2. Чтобы активировать серверы почтовых ящиков в дополнительном центре данных, выполните следующую команду.

   Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
   

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

3. Чтобы активировать базы данных, выполните одну из следующих команд.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
   

   или

   Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
   

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

5. Чтобы подключить базы данных, выполните следующую команду.

   Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
   

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

Get-MailboxDatabaseCopyStatus <DatabaseName>

Активация серверов клиентского доступа

Клиенты подключаются к конечным точкам служб для получения доступа к службам и данным сервера Exchange. Поэтому процесс активации серверов клиентского доступа, подключенных к Интернету, включает в себя изменение записей DNS для указания новых IP-адресов, которые будут настроены для новых конечных точек служб. Клиенты будут автоматически подключены к новым конечным точкам служб одним из двух способов.

• Клиенты продолжат попытки подключения и будут автоматически подключены по истечении срока жизни исходной записи DNS и записи в кэше службы DNS клиента. Пользователи могут также выполнить команду ipconfig /flushdns в командной строке, чтобы очистить кэш DNS вручную. При использовании приложения Outlook Web App может потребоваться закрыть и перезапустить веб-браузер, чтобы очистить кэш DNS, который он использует. В версии Exchange 2010 с пакетом обновления 1 (SP1) такую проблему с кэшированием в браузере можно устранить, настроив параметр FailbackURL в виртуальном каталоге owa приложения Outlook Web App.

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

Чтобы проверить сценарий с помощью средства Loadgen, выполните следующие действия.

1. Измените запись DNS для массива серверов клиентского доступа, чтобы указать на виртуальный IP-адрес подсистемы аппаратной балансировки нагрузки на дополнительном сайте.

2. Выполните команду ipconfig/flushdns на всех серверах Loadgen.

3. Проведите повторно тест Loadgen.

4. Убедитесь, что серверы клиентского доступа на дополнительном сайте обслуживают нагрузку.

Чтобы проверить сценарий с помощью клиента Outlook 2007, выполните следующие действия.

1. Измените запись DNS для массива серверов клиентского доступа, чтобы указать на виртуальный IP-адрес подсистемы аппаратной балансировки нагрузки на дополнительном сайте.

2. Выполните команду ipconfig/flushdns на клиенте или дождитесь окончания срока жизни.

3. Дождитесь, пока клиент Outlook переподключится.

Протестированные решения для Exchange 2010

Проверка восстановления служб основного центра данных

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

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

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

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

   Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
   

2. Для проверки состояния копий баз данных в основном центре данных выполните следующую команду.

   Get-MailboxDatabaseCopyStatus
   

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

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

   Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
   

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

   Get-MailboxDatabase | Dismount-Database
   

3. После отключения баз данных URL-адреса сервера клиентского доступа необходимо переместить из дополнительного центра данных в основной. Для этого измените запись DNS, чтобы URL-адреса указывали на сервер клиентского доступа или массив в основном центре данных.

   Важно!

   Не переходите к следующему шагу, пока URL-адреса сервера клиентского доступа не будут перемещены, а срок жизни DNS и записей кэша не истечет. При активации баз данных в основном центре данных до перемещения URL-адресов сервера клиентского доступа в основной центр данных создается недопустимая конфигурация (например, подключенная база данных, у которой отсутствуют серверы клиентского доступа на сайте Active Directory).

4. Чтобы активировать базы данных, выполните одну из следующих команд.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
   

   или

   Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
   

5. Чтобы подключить базы данных, выполните следующую команду.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
   

Критерии успеха: активные базы данных почтовых ящиков успешно подключены к серверам почтовых ящиков на основном сайте. Для подтверждения выполните следующую команду.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Протестированные решения для Exchange 2010

Место проведения теста

Тестирование проводилось в центре Microsoft Enterprise Engineering Center, который представляет собой современную лабораторию для испытания корпоративных решений, расположенную на территории основного комплекса зданий корпорации Майкрософт в Редмонде, штат Вашингтон.

Благодаря инвестициям в оборудование на сумму более 125 млн долларов и тесным партнерским взаимоотношениям с ведущими в отрасли поставщиками вычислительной техники (OEM) в центре EEC можно воспроизвести практически любую рабочую среду. Центр EEC предлагает условия, обеспечивающие расширенное взаимодействие между заказчиками, партнерами и инженерами по продуктам Майкрософт. С его помощью можно гарантировать, что комплексные решения корпорации Майкрософт будут соответствовать самым высоким ожиданиям пользователей.

Протестированные решения для Exchange 2010

Результаты проверки решения

В разделе ниже приводятся сводные результаты функциональных проверок и тестирования производительности.

Протестированные решения для Exchange 2010

Результаты функциональных проверок

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

Результаты функциональных проверок

Тестовый случай	Результат	Комментарии
Переключение базы данных	Успешное выполнение	Завершено без ошибок
Переключение сервера	Успешное выполнение	Завершено без ошибок
Сбой сервера	Успешное выполнение	Завершено без ошибок
Сбой на уровне площадки	Успешное выполнение	Завершено без ошибок

Протестированные решения для Exchange 2010

Результаты проверки макета хранилища

Проверка всех дисков в одном корпусе хранилища на площадке показала, что количество транзакционных операций ввода-вывода в секунду для CX4-480 составляет чуть больше 8000 при следующих условиях: Exchange 2010, 8 виртуальных машин Exchange, на которых настроены профили пользователей со 150 сообщениями, числом операций ввода-вывода в секунду, равным 0,15, и дополнительным запасом мощности 20 %. Результат превышает требуемую эталонную производительность, которая равна 5832 операций ввода-вывода в секунду, кроме того, обеспечивается определенный запас мощности на случай пиковой нагрузки. Задержки дисков не превышали допустимых значений, указанных в рекомендациях Майкрософт по производительности Exchange 2010.

Результаты проверки макета хранилища

Операции ввода-вывода для базы данных	Целевые значения	4 сервера почтовых ящиков при нормальных условиях эксплуатации (2700 пользователей на каждом сервере почтовых ящиков)	4 сервера почтовых ящиков в состоянии переключения (5400 пользователей на каждом сервере почтовых ящиков)	Всего
Достигнуто транзакционных операций ввода-вывода в секунду (операций чтения при вводе-выводе для базы данных/с + операций записи при вводе-выводе для базы данных/с)	1944 / 3888	3576 операций ввода-вывода в секунду	4488 операций ввода-вывода в секунду	8064 операции ввода-вывода в секунду
Операций чтения при вводе-выводе для базы данных/с	Неприменимо	2193	2729	4922
Операций записи при вводе-выводе для базы данных/с	Неприменимо	1439	1703	3142
Средняя задержка чтения при вводе-выводе для базы данных (мс)	<20 мс	14	18	16
Средняя задержка записи при вводе-выводе для базы данных (мс)	Не дает убедительных показаний задержек в работе клиента, поскольку операции записи в базу данных являются асинхронными	14	18	16
Операций записи в журнал при вводе-выводе/с	Неприменимо	1238	1560	2798
Средняя задержка чтения при вводе-выводе для журнала (мс)	<10 мс	2	2	2

Протестированные решения для Exchange 2010

Результаты проверки макета сервера

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

Проверка Loadgen: тестовые сценарии

Проверка	Описание
Нормальная работа	На одной площадке моделировалась загрузка с параллелизмом 100 % для 10 800 пользователей, причем каждый север почтовых ящиков обрабатывал 2700 пользователей.
Отказ или обслуживание одного из серверов (на площадке)	Моделировался отказ одного сервера-узла Hyper-V на площадке. Выполнялась загрузка с параллелизмом 100 % для одного узла Hyper-V с одной виртуальной машиной, обрабатывающей 5400 пользователей. Только три сервера с комбинированной ролью сервера клиентского доступа и транспортного сервера-концентратора обрабатывали нагрузку.
Сбой на уровне площадки	Моделировался отказ на уровне площадки, при котором активировались дополнительные образы на виртуальных машинах резервных серверов почтовых ящиков. Выполнялась загрузка с параллелизмом 100 % для 21 600 пользователей на одной площадке.

Тестовый случай: обычные условия эксплуатации

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

Проверка ожидаемой нагрузки

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

Счетчик	Целевой объект	Результат проверки
Скорость доставки сообщений для почтового ящика	15.0	15.2

Проверка основных серверов почтовых ящиков

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

Процессор

Использование процессора составляет менее 70 процентов, как и ожидалось.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<70%	69

Хранилище

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка операций чтения при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс	19
Средняя задержка операций записи при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс <среднего показателя при чтении	18
Сбоев при ожидании страниц базы данных/с	0	0
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<20 мс	5
Ожиданий записи в журнал базы данных/с	0	0

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Запросов RPC для процесса MSExchangeIS	<70	3.0
Средняя задержка RPC для процесса MSExchangeIS	<10 мс	2.0
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	0	2.0

Проверка дополнительных серверов почтовых ящиков

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

Процессор

Использование процессора составляет менее 70 процентов, как и ожидалось.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<70%	26

Хранилище

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка операций чтения при вводе-выводе в базе данных (при восстановлении) для базы данных MSExchange	<100 мс	0
Средняя задержка операций записи при вводе-выводе в базе данных (при восстановлении) для базы данных MSExchange	<100 мс <среднего показателя при чтении	16
Сбоев при ожидании страниц базы данных/с	0	0
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<20 мс	3
Ожиданий записи в журнал базы данных/с	0	0

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Запросов RPC для процесса MSExchangeIS	<70	Неприменимо
Средняя задержка RPC для процесса MSExchangeIS	<10 мс	Неприменимо
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	0	Неприменимо

Проверка серверов клиентского доступа и транспортные серверов-концентраторов

В следующих таблицах приведены результаты проверки виртуальных машин серверов клиентского доступа и транспортные серверов-концентраторов.

Процессор

Использование процессора низкое, как и ожидалось.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<70%	48

Хранилище

Для хранилища получены хорошие результаты. Задержки очень низкие, они не должны влиять на транспортировку сообщений.

Счетчик	Целевой объект	Результат проверки
Логический/Физический диск(*)\Среднее время чтения с диска (сек)	<20 мс	0.001
Логический/Физический диск(*)\Среднее время записи на диск (сек)	<20 мс	0.005

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка RPC для службы MSExchange RpcClientAccess	<250 мс	8
Запросов RPC для службы MSExchange RpcClientAccess	<40	3

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

Счетчик	Целевой объект	Результат проверки
\Очереди MSExchangeTransport (_total)\Общая длина всех очередей доставки	<3000	2.5
\Очереди MSExchangeTransport (_total)\Длина очереди активной удаленной доставки	<250	0
\Очереди MSExchangeTransport (_total)\Длина очереди активной доставки для почтового ящика	<250	2.3
\Очереди MSExchangeTransport (_total)\Длина очереди передачи	<100	0
\Очереди MSExchangeTransport (_total)\Длина очереди повторных попыток доставки для почтового ящика	<100	0.3

Проверка работоспособности корневых серверов

В следующих таблицах приведены результаты проверки корневого сервера Hyper-V.

Процессор

Как и ожидалось, использование процессора очень низкое и не превышает целевые значения.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<75%	66
% времени работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<5%	2
% общего времени работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<80%	68
% времени гостевой работы корневого виртуального процессора низкоуровневой оболочки Hyper-V (общий)	<5%	3

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Сводные данные о работоспособности виртуальных машин Hyper-V\Критическое состояние	0	0

Тестовый случай: отказ или обслуживание одного из серверов (на площадке)

Цель этого теста состоит в проверке всей среды Exchange в условиях отказа физического корневого сервера Hyper-V или в условиях проведения обслуживания с пиковой загрузкой. Все виртуальные машины, выполняемые на одном из корневых серверов Hyper-V, отключаются для имитации состояния обслуживания узла. В результате образы (копии) базы данных перемещаются на виртуальные машины другого сервера почтовых ящиков, итоговая нагрузка составляет 5400 пользователей на каждую виртуальную машину сервера почтовых ящиков. Только половина комбинированных серверов клиентского доступа и транспортных серверов-концентраторов обрабатывает задачи клиентского доступа и доставки почты.

Проверка ожидаемой нагрузки

Фактическая скорость доставки сообщений соответствовала целевой.

Счетчик	Целевой объект	Результат проверки
Скорость доставки сообщений для сервера	30	30

Проверка основных серверов почтовых ящиков

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

Процессор

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

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<80%	83

Хранилище

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка операций чтения при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс	20.5
Средняя задержка операций записи при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс	23
Сбоев при ожидании страниц базы данных/с	0	0
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<20 мс	8
Ожиданий записи в журнал базы данных/с	0	0

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Запросов RPC для процесса MSExchangeIS	<70	9.0
Средняя задержка RPC для процесса MSExchangeIS	<10 мс	2.0
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	0	77

Проверка дополнительных серверов почтовых ящиков

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

Процессор

Использование процессора составляет менее 70 процентов, как и ожидалось.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<70%	21

Хранилище

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка операций чтения при вводе-выводе в базе данных (при восстановлении) для базы данных MSExchange	<100 мс	0
Средняя задержка операций записи при вводе-выводе в базе данных (при восстановлении) для базы данных MSExchange	<100 мс <среднего показателя при чтении	21
Сбоев при ожидании страниц базы данных/с	0	0
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<20 мс	3
Ожиданий записи в журнал базы данных/с	0	0

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Запросов RPC для процесса MSExchangeIS	<70	Неприменимо
Средняя задержка RPC для процесса MSExchangeIS	<10 мс	Неприменимо
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	0	Неприменимо

Проверка серверов клиентского доступа и транспортные серверов-концентраторов

В следующих таблицах приведены результаты проверки виртуальных машин серверов клиентского доступа и транспортные серверов-концентраторов.

Процессор

Использование процессора составляет менее 80 процентов, как и ожидалось.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<80%	74

Хранилище

Для хранилища получены хорошие результаты. Задержки очень низкие, они не должны влиять на транспортировку сообщений.

Счетчик	Целевой объект	Результат проверки
Логический/Физический диск(*)\Среднее время чтения с диска (сек)	<20 мс	0.001
Логический/Физический диск(*)\Среднее время записи на диск (сек)	<20 мс	0.008

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка RPC для службы MSExchange RpcClientAccess	<250 мс	18
Запросов RPC для службы MSExchange RpcClientAccess	<40	14

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

Счетчик	Целевой объект	Результат проверки
\Очереди MSExchangeTransport (_total)\Общая длина всех очередей доставки	<3000	49
\Очереди MSExchangeTransport (_total)\Длина очереди активной удаленной доставки	<250	0
\Очереди MSExchangeTransport (_total)\Длина очереди активной доставки для почтового ящика	<250	43
\Очереди MSExchangeTransport (_total)\Длина очереди передачи	<100	53
\Очереди MSExchangeTransport (_total)\Длина очереди повторных попыток доставки для почтового ящика	<100	4

Проверка работоспособности корневых серверов

В следующих таблицах приведены результаты проверки корневого сервера Hyper-V.

Процессор

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

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<75%	77
% времени работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<5%	2
% общего времени работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<80%	79
% времени гостевой работы корневого виртуального процессора низкоуровневой оболочки Hyper-V (общий)	<5%	3

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Сводные данные о работоспособности виртуальных машин Hyper-V\Критическое состояние	0	0

Тестовый случай: отказ на уровне площадки и переключение

В рамках этого тестового случая моделируется сбой на уровне площадки и переключение активных баз данных основной площадки на пассивные базы данных дополнительной площадки, в результате чего на одной площадке будет размещаться 21 600 активных почтовых ящиков. Четыре виртуальных машины основных серверов почтовых ящиков на оставшейся площадке работают с нормальной загрузкой, равной 2700 активных почтовых ящиков на каждой ВМ. На каждой из четырех виртуальных машин дополнительных серверов почтовых ящиков на оставшейся площадке также выполняется 2700 активных почтовых ящиков. На каждом корневом сервере Hyper-V размещается 5400 активных почтовых ящиков.

Проверка ожидаемой нагрузки

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

Счетчик	Целевой объект	Результат проверки
Скорость доставки сообщений для сервера	15	15.1

Проверка основных серверов почтовых ящиков

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

Процессор

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

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<70%	63

Хранилище

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка операций чтения при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс	12
Средняя задержка операций записи при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс	13
Сбоев при ожидании страниц базы данных/с	0	0
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<20 мс	4
Ожиданий записи в журнал базы данных/с	0	0

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Запросов RPC для процесса MSExchangeIS	<70	3.0
Средняя задержка RPC для процесса MSExchangeIS	<10 мс	2.0
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	0	3

Проверка дополнительных серверов почтовых ящиков

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

Процессор

Использование процессора незначительно превысило целевые 80 %. Хотя показатель превышает предпочтительное значение, он не влияет на другие счетчики работоспособности Exchange. Эта ситуация допустима, так как в рамках тестового случая проверяется маловероятная пиковая нагрузка в условиях сбоя на уровне площадки. Такой уровень загрузки процессора в течение продолжительного периода времени нежелателен.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<80%	84

Хранилище

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка операций чтения при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс	17
Средняя задержка операций записи при вводе-выводе в базе данных (прикрепленной) для базы данных MSExchange	<20 мс <среднего показателя при чтении	12
Сбоев при ожидании страниц базы данных/с	0	0
Средняя задержка операций записи при вводе-выводе в журнале для базы данных MSExchange	<20 мс	3
Ожиданий записи в журнал базы данных/с	0	0

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Запросов RPC для процесса MSExchangeIS	<70	3
Средняя задержка RPC для процесса MSExchangeIS	<10 мс	2
Сообщений в очереди отправки для почтового ящика MSExchangeIS(_Total)	0	106

Проверка серверов клиентского доступа и транспортные серверов-концентраторов

В следующих таблицах приведены результаты проверки виртуальных машин серверов клиентского доступа и транспортные серверов-концентраторов.

Процессор

Использование процессора составляет менее 80 процентов, как и ожидалось.

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы виртуального процессора низкоуровневой оболочки Hyper-V	<70%	63

Хранилище

Для хранилища получены хорошие результаты. Задержки очень низкие, они не должны влиять на транспортировку сообщений.

Счетчик	Целевой объект	Результат проверки
Логический/Физический диск(*)\Среднее время чтения с диска (сек)	<20 мс	0.002
Логический/Физический диск(*)\Среднее время записи на диск (сек)	<20 мс	0.003

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Средняя задержка RPC для службы MSExchange RpcClientAccess	<250 мс	9
Запросов RPC для службы MSExchange RpcClientAccess	<40	7

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

Счетчик	Целевой объект	Результат проверки
\Очереди MSExchangeTransport (_total)\Общая длина всех очередей доставки	<3000	5
\Очереди MSExchangeTransport (_total)\Длина очереди активной удаленной доставки	<250	0
\Очереди MSExchangeTransport (_total)\Длина очереди активной доставки для почтового ящика	<250	4
\Очереди MSExchangeTransport (_total)\Длина очереди передачи	<100	0
\Очереди MSExchangeTransport (_total)\Длина очереди повторных попыток доставки для почтового ящика	<100	1

Проверка работоспособности корневых серверов

В следующих таблицах приведены результаты проверки корневого сервера Hyper-V.

Процессор

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

Счетчик	Целевой объект	Результат проверки
% времени гостевой работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<75%	85
% времени работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<5%	2
% общего времени работы логического процессора низкоуровневой оболочки Hyper-V (общий)	<80%	87
% времени гостевой работы корневого виртуального процессора низкоуровневой оболочки Hyper-V (общий)	<5%	3

Работоспособность приложений

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

Счетчик	Целевой объект	Результат проверки
Сводные данные о работоспособности виртуальных машин Hyper-V\Критическое состояние	0	0

Протестированные решения для Exchange 2010

Заключение

В этом документе приводится пример проектирования, тестирования и проверки решения Exchange Server 2010, которое предназначается для клиентской среды с 32 400 почтовыми ящиками на нескольких площадках, развернутой на оборудовании Cisco и EMC. В этом документе пошагово описываются важные решения и аспекты проектирования, которые помогают решить ключевые задачи и при этом выполнить все требования, предъявляемые базовыми бизнес-процессами клиента.

Протестированные решения для Exchange 2010

Дополнительные сведения

Полный пакет документации Exchange 2010 можно найти на веб-сайте Exchange Server 2010.

Дополнительные сведения о Cisco и EMC см. на следующих веб-ресурсах:

• EMC CLARiiON CX4-480: решение EMC CLARiiON Virtual Provisioning

• EMC CLARiiON CX4-480: обзор продукта

• Решения Cisco Unified Computing and Servers: обзор

• Решения Cisco Unified Computing and Servers: блейд-серверы серии B

• Решения Cisco Unified Computing and Servers: UCS Manager

Данный документ предоставляется на условиях "как есть". Выраженные взгляды и сведения, приведенные в данном документе, в том числе URL-адреса и другие ссылки на веб-сайты, могут быть изменены без предварительного уведомления. Ответственность за использование данного документа несет пользователь.

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

Протестированные решения для Exchange 2010