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

 

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

Последнее изменение раздела: 2009-04-03

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

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

  • Калькулятор хранилища почтовых ящиков для сервера Exchange Server 2007.

  • Емкость LUN базы данных

  • Емкость LUN журнала

  • Транзакционные операции ввода-вывода

  • Прогнозирование базового количества операций ввода-вывода в секунду для сервера Exchange Server 2007

  • Нетранзактные операции ввода-вывода

  • Логические номера устройств и физические диски

  • Влияние непрерывной репликации на схему хранилища

Калькулятор хранилища почтовых ящиков для сервера Exchange Server 2007

Калькулятор для расчета требований к хранилищу для роли сервера почтовых ящиков Exchange Server 2007 (калькулятор хранилища) позволяет определить требования к хранилищу (производительность ввода-вывода и объем) и оптимальную структуру логических номеров устройств (LUN) с учетом ряда факторов. Имеется множество факторов, которые необходимо учитывать при разработке оптимального хранилища для сервера почтовых ящиков Exchange 2007. Эти факторы перечислены в данном разделе.

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

Дополнительные сведения о калькуляторе хранилища и его использовании см. в статье Калькулятор требований к хранилищу для роли сервера почтовых ящиков Exchange Server 2007 (на английском языке) блога команды разработчиков сервера Exchange (там же можно загрузить калькулятор).

noteПримечание.
UNRESOLVED_TOKEN_VAL(exBlog)

Объем LUN базы данных

Существует несколько точек данных, с помощью которых можно определить необходимый размер логического номера устройства (LUN) базы данных. Кроме того, необходимо учитывать и другие факторы. После учета и расчета всех факторов рекомендуется прибавить дополнительный коэффициент накладных расходов для LUN базы данных, равный 20 %. Это значение учитывает другие данные, хранящиеся в базе данных, которые не всегда очевидны при расчете размеров почтовых ящиков и свободного места. Например, структура данных (таблицы, представления, внутренние индексы и т.д.) в базе данных увеличивает общий размер базы данных. Например, если после прочтения следующих подразделов расчетная емкость диска составила 120 гигабайт (ГБ), рекомендуется использовать 144 ГБ, чтобы зарезервировать 20% места на диске для логического номера устройства (LUN) базы данных этой группы хранения.

Квота почтового ящика

Первым показателем, с которым нужно разобраться, является размер почтового ящика. Зная объем данных, который может храниться в почтовом ящике конечного пользователя, можно определить, сколько пользователей можно разместить на сервере. Хотя окончательные размеры и квоты почтовых ящиков могут меняться, наличие цели является первым шагом к определению необходимого объема. Например, если имеется 5000 пользователей на сервере с квотой почтового ящика 250 мегабайт (МБ), потребуется не менее 1,25 терабайт дискового пространства. Если для квот почтовых ящиков не заданы четкие ограничения, необходимый объем определить труднее.

Свободное пространство в базе данных

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

Размер свободного пространства в базе данных можно приблизительно определить по объему почты, отправленной и полученной пользователями, почтовые ящики которых расположены в этой базе данных. Например, если в базе данных имеется 100 почтовых ящиков размером по 2 ГБ каждый (всего 200 ГБ), пользователи которых ежедневно отправляют и получают в среднем 10 МБ почты, приблизительный размер свободного пространства составляет 1 ГБ (100 почтовых ящиков × 10 МБ на почтовый ящик).

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

Корзина базы данных

У каждой базы данных есть корзина, в которой хранятся удаленные элементы, которые можно восстановить. По умолчанию на сервере Microsoft Exchange Server 2007 элементы хранятся в течение 14 дней. К ним относятся элементы, удаленные из папки «Удаленные». По умолчанию накладные расходы для корзины базы данных для сервера Exchange 2007 превышают аналогичные расходы для сервера Exchange Server 2003, поскольку удаленные элементы теперь хранятся вдвое дольше. Фактический размер корзины зависит от размера каждого элемента и установленных в организации конкретных параметров хранения.

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

Корзина увеличивает размер базы данных в зависимости от размера почтового ящика и объема поступающей почты для этого почтового ящика. Например, если постоянный объем поступающей почты составляет 52 МБ в неделю, почтовый ящик размером 250 МБ с очень высокой нагрузкой будет хранить примерно 104 МБ в корзине, то есть служебные данные составят 41 %. Для почтового ящика размером 1 ГБ, в корзине которого хранятся те же 104 МБ, накладные расходы составят 10%.

Реальный размер почтового ящика

Со временем почтовые ящики пользователей достигают квоты почтового ящика, и для того, чтобы не выйти за ее пределы, приходится удалять такой же объем сообщений, который поступает в почтовый ящик. Это означает, что корзина увеличится до максимального размера, равного объему почты за две недели. Если для большинства пользователей квота почтового ящика не достигнута, только некоторая часть входящей и исходящей почты будет удаляться, а рост будет распределяться между корзиной и увеличением размера почтового ящика. Например, для активно используемого почтового ящика размером 250 МБ, принимающего 52 МБ почты в неделю со средним размером сообщения 50 килобайт (КБ) размер корзины составит 104 МБ (41 %), объем свободного места — 7,3 МБ, а общий размер почтового ящика — 360 МБ. Другим примером является активно используемый почтовый ящик размером 2 ГБ, принимающий 52 МБ почты в неделю, для которого размер корзины составит 104 МБ (5 %), объем свободного места — 7,3 МБ, а общий размер почтового ящика — 2,11 ГБ. Пятьдесят почтовых ящиков размером 2 ГБ в группе хранения займут 105,6 ГБ.

Ниже приведена формула расчета размера базы данных с почтовыми ящиками размером 2 ГБ:

Размер почтового ящика = Квота почтового ящика + Свободное пространство + (Объем почты за неделю × 2)

Размер почтового ящика = 2,048 МБ + (7.3 МБ) + (52 МБ × 2)

2,159 МБ = 2,048 МБ + 7.3 МБ + 104 МБ (на 5 % больше квоты)

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

Индексация содержимого

Во время индексирования содержимого создается индекс или каталог, позволяющий пользователям быстро и просто находить письма без необходимости искать их вручную. Сервер Exchange 2007 создает индекс размером примерно в 5% от общего размера базы данных, который размещается на устройстве с тем же логическим номером устройства (LUN), что и база данных. Поэтому необходимо дополнительно прибавить 5 % к объему LUN базы данных для индексирования содержимого.

Обслуживание

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

Группа хранения для восстановления

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

Резервное копирование на диск

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

Объем LUN журнала

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

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

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

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

Низкий

5 отправленных и 20 полученных

6

Средний

10 отправленных и 40 полученных

12

Высокий

20 отправленных и 80 полученных

24

Очень высокий

30 отправленных и 120 полученных

36

Самый высокий

40 отправленных и 160 полученных

48

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

  • Если средний размер сообщения удваивается до 100 КБ, количество журналов, создаваемых для одного почтового ящика, увеличивается в 1,9 раза. Это число представляет собой часть базы данных (в процентах), которая содержит вложения и таблицы сообщений (текст сообщений и вложения).

  • Впоследствии, когда размер сообщения становится в два раза больше 100 КБ, скорость создания журналов также удваивается.

Например:

  • При высокой нагрузке на почтовый ящик и среднем размере сообщения 100 КБ количество журналов, создаваемых для одного почтового ящика, составляет 24 *

  • При высокой нагрузке на почтовый ящик и среднем размере сообщения 200 КБ количество журналов, создаваемых для одного почтового ящика, составляет 24 *

Факторы резервного копирования и восстановления

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

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

Операции перемещения почтового ящика

Перемещение почтовых ящиков является основным фактором, определяющим объем в системах с большими почтовыми ящиками. Многие большие компании перемещают часть пользователей каждую ночь или раз в неделю на различные серверы, сайты или базы данных. Если организация придерживается подобной схемы, может потребоваться дополнительное место для LUN журнала для поддержки миграции пользователей. Хотя исходный сервер заносит в журнал удаление записей, что не занимает много места, сервер назначения должен сначала записать все перемещенные данные в журналы транзакций. Если ежедневно создаются файлы журналов размером 10 ГБ и поддерживается 3-дневный буфер в 30 ГБ, перемещение пятидесяти почтовых ящиков размером 2 ГБ (всего 100 ГБ) полностью заполнит LUN целевого журнала и приведет к простою. В таких случаях необходимо выделить дополнительное пространство для LUN журнала для размещения перемещенных почтовых ящиков.

Низкий коэффициент роста

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

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

В следующем примере показано определение необходимого размера места на диске для среды, в которой четыре тысячи почтовых ящиков размером 1 ГБ каждый расположены на одном кластерном сервере почтовых ящиков в кластере с непрерывной репликацией. Эти почтовые ящики принимают в среднем 52 МБ почты в неделю, средний размер сообщения составляет 50 КБ. В приведенной ниже таблице указаны примеры значений для определения реального размера почтового ящика.

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

Размер почтового ящика Размер корзины (2 недели) Свободное пространство Общий размер на диске

1 ГБ

104 МБ (2 × 52 МБ)

7,3 МБ

1,11 ГБ (+11%)

В этой среде каждый пользователь будет использовать 1,11 ГБ дискового пространства. Так как максимальный рекомендуемый размер базы данных в среде кластера с непрерывной репликацией составляет 200 ГБ, сервер должен размещать не более 180 почтовых ящиков в одной базе данных. Чтобы поддерживать в данной среде работу 4000 почтовых ящиков, необходимо 23 базы данных, а также 23 группы хранения. Так как в среде кластера с непрерывной репликацией в одной группе хранения должна присутствовать одна базы данных, каждая база данных будет размещаться в собственной группе хранения. В результате окончательное количество почтовых ящиков в одной группе хранения составит 174. С учетом такого количества и фактического размера почтовых ящиков размер базы данных составляет 193 ГБ, как показано в приведенной ниже таблице.

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

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

174

23

193 ГБ

Чтобы гарантировать отсутствие простоев в работе почтового ящика, связанных с выделением места на диске, необходимо оценить размер журналов транзакций, чтобы учесть размер всех журналов, создаваемых в процессе резервного копирования. Многие организации используют стратегию ежедневного полного резервного копирования с частотой в три раза больше скорости создания журнала транзакций в сутки на случай сбоя резервного копирования. При использовании еженедельного полного резервного копирования с разностным или добавочным резервным копированием для проведения процесса восстановления необходимо место, достаточное для хранения всех созданных в течение недели журналов. Если известно, что активно используемый почтовый ящик создает в среднем 42 журнала транзакций в день, сервер с 4000 почтовых ящиков будет создавать 168 тысяч журналов транзакций в день. Это означает, что каждая группа хранения будет создавать 7304 журнала в день. Десять процентов почтовых ящиков перемещаются еженедельно в один день (субботу), а режим резервного копирования включает еженедельное полное и ежедневное добавочное резервное копирование. Кроме того, сервер сможет проработать три дня без усечения журналов. Как показано в приведенной ниже таблице, этому серверу требуется 38,8 ГБ места на диске для каждой группы хранения.

Требования к месту на диске для журналов

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

7,304

1 МБ

7,13 ГБ

17 ГБ

(17 × 1 ГБ)

21,4 ГБ

(3 × 7,13 ГБ)

38,8 ГБ

(17.4 + 21.4)

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

Транзактные операции ввода-вывода

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

Общее представление о количестве операций ввода-вывода в секунду

В предыдущих версиях сервера Exchange Server одним из ключевых показателей, используемых при выборе размера хранилища, было количество операций ввода-вывода базы данных в секунду на каждого пользователя. Чтобы определить количество операций ввода-вывода в секунду для пользователя, нужно количество операций ввода-вывода (и чтения, и записи) в секунду в LUN базы данных для группы хранения разделить на количество пользователей группы хранения. Например, если 1 000 пользователей выполняют 1 000 операций ввода-вывода на LUN базы данных, это означает, что количество операций ввода-вывода в секунду для одного пользователя равно 1.0.

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

При использовании предыдущей версии сервера Exchange Server и расчете базового количества операций ввода-вывода в секунду необходимо иметь в виду, что сервер Exchange 2007 влияет на этот показатель следующим образом:

  • количество пользователей на сервере влияет на общий кэш базы данных на одного пользователя;

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

Смысл в том, что знание количества операций ввода-вывода в секунду для одного сервера не дает возможности планирования для компании в целом, поскольку объем ОЗУ, количество пользователей и групп хранения наверняка будут различаться от сервера к серверу. Получив количество операций ввода-вывода в секунду, обязательно прибавьте 20% на накладные расходы ввода-вывода, чтобы обеспечить некоторый запас. Без этого пользователи могут испытывать неудобства при работе из-за сниженной производительности.

Кэш базы данных

Использование 64-разрядной операционной системы Windows Server с 64-разрядной версией сервера Exchange 2007 значительно увеличивает виртуальное адресное пространство и позволяет серверу Exchange увеличить кэш базы данных и уменьшить количество операций чтения базы данных, а также дает возможность разместить до 50 баз данных на одном сервере.

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

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

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

Количество почтовых ящиков Размер кэша базы данных сервера Exchange 2003 на один почтовый ящик (МБ) Размер кэша базы данных сервера Exchange 2007 на один почтовый ящик (МБ) Увеличение размера кэша базы данных по сравнению с сервером Exchange 2003

4,000

0.225

5

23 раза

2,000

0.45

5

11 раз

1,000

0.9

5

6 раз

500

1.8

5

3 раза

Прогнозирование базового количества операций ввода-вывода в секунду для Exchange 2007

К двум важнейшим факторам, которые можно использовать для прогнозирования количества операций ввода-вывода в секунду для базы данных Exchange 2007, относят объем кэша базы данных на одного пользователя и количество сообщений, которое пользователь отправляет и получает ежедневно. При создании приведенной ниже формулы в расчет брался стандартный сотрудник, использующий сервер Office Outlook 2007 в режиме кэширования Exchange. Результаты проверки показали, что погрешность расчетов по данной формуле составляет +/- 20%. Использование данной формулы для других типов клиентов и сценариев использования может приводит к менее точным результатам. Прогнозирование с использованием данной формулы можно считать действительным только для размера кэша базы данных на одного пользователя, составляющем от 2 до 5 МБ. Оценка погрешности расчетов по этой формуле для пользователей, отправляющих и получающих более 150 сообщений ежедневно, не проводилась. В качестве среднего размера сообщения для расчета по данной формуле было принято значение 50 КБ, однако размер сообщения не является основным фактором при оценке количества операций ввода-вывода в секунду.

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

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

Тип пользователя (профиль использования) Отправленные и полученные сообщения за день (приблизительный размер сообщения — 50 КБ) Кэш базы данных для одного пользователя Расчетное количество операций ввода-вывода в секунду для одного пользователя

Низкий

5 отправленных и 20 полученных

2 МБ

0.11

Средний

10 отправленных и 40 полученных

3,5 МБ

0.18

Высокий

20 отправленных и 80 полученных

5 МБ

0.32

Очень высокий

30 отправленных и 120 полученных

5 МБ

0.48

Самый высокий

40 отправленных и 160 полученных

5 МБ

0.64

Чтобы оценить размер кэша базы данных, отнимите 2048 МБ (3072 МБ при использовании локальной непрерывной репликации) от общего объема памяти, установленной на сервере Exchange, и разделите получившееся значение на количество пользователей. Например, для сервера с 3 000 пользователей и 16 ГБ ОЗУ отнимите 2 ГБ для системы. В результате получится 14 ГБ ОЗУ на всех пользователей или 4,66 МБ на одного пользователя (14 ГБ / 3 000 = 4,66 МБ).

Зная, что средний размер кэша базы данных для одного пользователя составляет 4,66 МБ, а количество сообщений, отправляемых и получаемых пользователем ежедневно, равно 60, можно оценить количество операций чтения и записи в базу данных:

  • Количество операций чтения базы данных   Умножьте 60 сообщений в день на 0,0048, в результате получится 0,288. Затем возведите объем кэша базы данных для одного почтового ящика (4,66 МБ) в степень -0.65 (5 ^ -0.65), что даст в результате 0,3622. В заключении перемножьте два полученных значения, что в результате даст 0,104 операций чтения базы данных для одного пользователя (0,288 × 0,3622 = 0,104).

  • Количество операций записи в базу данных   Умножьте количество сообщений для одного пользователя (60) на 0,00152, что в результате даст 0,0912 операций записи в базу данных для одного пользователя.

Формула, которую следует использовать:

((0.0048 × M) × (D ^-0,65)) + (0,00152 × M) = общее количество операций ввода-вывода в секунду для базы данных

где M — это количество сообщений одного пользователя, а D — это кэш базы данных для одного пользователя. Общее количество операций ввода-вывода в секунду для базы данных для одного пользователя представляет собой сумму количества операций чтения и операций записи в базу данных. Для значений, заданных в этом примере общее количество операций ввода-вывода в секунду равно 0,189:

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

На приведенном ниже графике показано сокращение количества операций чтения и записи для базы данных, достигнутое при запуске сервера Exchange 2007 с 4000 почтовых ящиков размером 250 МБ с имитацией работы Outlook 2007 в режиме кэширования Exchange и рекомендованным объемом памяти на сервере.

Сокращение количество операций ввода-вывода на сервере Exchange Server 2007 по сравнению с сервером Exchange Server 2003

Сокращение числа операций ввода-вывода в секунду в Exchange Server 2007

Влияние клиентов, работающих в оперативном режиме

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

  • Клиенты с почтовым ящиком размером 250 МБ, работающие в оперативном режиме, увеличивают количество операций чтения базы данных в 1,5 раза по сравнению с клиентами, работающими в режиме кэширования Exchange. Для почтовых ящиков размером менее 250 МБ влияние незначительно.

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

На приведенном ниже графике показана зависимость количества операций ввода-вывода от размера почтового ящика.

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

Повышение числа операций ввода-вывода в секунду для чтения при увеличении размера почтового ящика

Тестирование также показало, что увеличение размера кэша базы данных свыше 5 МБ на один почтовый ящик не приводит к существенному сокращению количества операций чтения базы данных. На приведенном ниже графике показана работа клиентов в оперативном режиме с почтовыми ящиками размером 2 ГБ и влияние увеличения кэша свыше 5 МБ на сокращение количество операций чтения из базы данных.

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

Повышение числа операций ввода-вывода в секунду для чтения при увеличении кэша почтового ящика

В результате анализа этих данных можно дать две рекомендации, приведенные ниже.

  • Следует по возможности развертывать клиенты, работающие в режиме кэширования. Дополнительные сведения см. в разделе «Количество элементов в одной папке».

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

Сведения о дополнительных факторах, влияющих на скорость операций ввода-вывода, например о сторонних клиентах, см. в статье Оптимизация хранилища для сервера Exchange Server 2003 (на английском языке).

Отношение количества операций чтения и записи базы данных

В сервере Exchange 2003 отношение количества операций чтения к количеству операций записи обычно составляло 2:1 (66% приходилось на долю операций чтения). В сервере Exchange 2007 кэш базы данных большего размера уменьшает количество операций чтения из базы данных на диске, что приводит к снижению доли операций чтения. Если следовать рекомендациям по объемам памяти и использовать режим кэширования Exchange, то отношение количества операций чтения к количеству операций записи будет ближе к 1:1, то есть на долю операций чтения будет приходиться около 50%.

При использовании оперативного режима Outlook или при использовании поисковой подсистемы компьютера отношение количества операций чтения к количеству операций записи несколько увеличится в сторону операций чтения (в зависимости от размера почтового ящика). Большее количество операций чтения создает некоторые сложности при выборе типа массива RAID, обладающего значительными затратами на операции записи, например RAID5 или RAID6. Дополнительные сведения о том, как выбрать подходящее решение RAID для серверов, см. в разделе Технологии хранения.

Соотношение журнала и базы данных

В сервере Exchange 2003 на долю журнала транзакций для группы хранения приходится приблизительно 10% от количества операций ввода-вывода базы данных в группе хранения. Например, если LUN базы данных использует 1 000 операций ввода-вывода, LUN журнала будет использовать 100 операций ввода-вывода. С учетом снижения количества операций чтения базы данных в сервере Exchange 2007 в сочетании с меньшим размером файла журнала и возможностью использовать больше групп хранения, соотношение количества операций записи журнала и базы данных составляет приблизительно 3:4. Например, если LUN базы данных использует 500 операций записи, LUN журнала будет использовать примерно 375 операций записи.

После измерения или расчета количества операций ввода-вывода журнала транзакций необходимо прибавить 20% на накладные расходы ввода-вывода, чтобы иметь адекватный запас на периоды более интенсивного использования. Кроме того, при использовании непрерывной репликации необходимо считывать и отправлять в другое место закрытые журналы транзакций. Эти накладные расходы составляют 10 % операций чтения журнала. Если журнал транзакций для группы хранения использует 375 операций записи можно ожидать, что понадобится еще 37,5 операций чтения при использовании непрерывной репликации.

Количество элементов в папке

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

Одним из способов снизить количество операций ввода-вывода для сервера является использование Outlook 2007 в режиме кэширования Exchange. Первоначальная синхронизация почтового ящика связана с очень значительными затратами, но по мере роста почтового ящика нагрузка на дисковую подсистему переносится с сервера Exchange на клиент Outlook. Это означает, что большое количество элементов в папке «Входящие» или поиск почтового ящика, выполняемый пользователем, почти не будут влиять на сервер. Это также означает, что пользователям с большими почтовыми ящиками в режиме кэширования Exchange могут потребоваться более быстрые компьютеры, чем пользователям с небольшими почтовыми ящиками (в зависимости от приемлемой для каждого пользователя производительности). При развертывании клиентских компьютеров с Outlook 2007 в режиме кэширования Exchange рекомендуется учитывать приведенные ниже рекомендации в отношении размеров OST-файлов и почтовых ящиков.

  • До 5 гигабайт (ГБ): этот размер должен обеспечить хорошее взаимодействие с пользователем на большей части оборудования.

  • От 5 до 10 ГБ: обычно этот размер зависит от оборудования. Поэтому при наличии быстрого жесткого диска и большого количества ОЗУ будет обеспечиваться лучшее взаимодействие. Однако медленные жесткие диски (например, диски, которые обычно устанавливаются на портативные компьютеры, или твердотельные накопители первых поколений) создают задержки в работе приложений из-за замедленной реакции.

  • Более 10 ГБ: это размер, при котором на большей части оборудования начинают возникать небольшие задержки.

  • Очень большой (25 ГБ и более): этот размер повышает частоту коротких пауз, особенно при загрузке новых электронных писем. Для синхронизации почты вручную также можно использовать группы отправки и получения.

noteПримечание.
В этом руководстве подразумевается, что установлено накопительное обновление для Outlook 2007 с пакетом обновления 1 (SP1) или более поздней версии, как описано в статье 961752 базы знаний Майкрософт Description of the Outlook 2007 hotfix package (Outlook.msp): February 24, 2009 (на английском языке).

Если в случае использования Outlook 2007 в режиме кэширования Exchange возникают проблемы с производительностью, см. статью 940226 базы знаний How to troubleshoot performance issues in Outlook 2007 (на английском языке).

Как Outlook Web Access, так и Outlook в оперативном режиме хранят индексы и выполняют поиск по копии данных сервера. Для почтовых ящиков среднего размера это приводит к удвоению количества операций ввода-вывода в секунду для каждого почтового ящика, сравнимого с размером клиента в режиме кэширования Exchange. Количество операций ввода-вывода в секунду для больших почтовых ящиков будет еще больше. При первой сортировке представления новым способом создается индекс, для чего используется большое количество операций чтения LUN базы данных. Последующие сортировки по активному индексу почти не требуют ресурсов.

Сложности возникают, когда пользователь превышает количество индексов, которое может храниться в Exchange (для сервера Exchange 2007 это значение равно 11). При выполнении новой сортировки и создании двенадцатого индекса выполняются дополнительные дисковые операции ввода-вывода. Поскольку индекс не сохраняется, дополнительные дисковые операции ввода-вывода выполняются при каждой сортировке. Поскольку в таком сценарии происходит много операций ввода-вывода, настоятельно рекомендуется хранить не более 20 000 элементов в основных папках, таких как папки «Входящие» и «Отправленные». Создание большего количества папок верхнего уровня или подпапок в папках «Входящие» и «Отправленные» значительно снижает затраты, связанные с созданием индекса, если количество элементов в одной папке не превышает 20 000. Дополнительные сведения о том, как количество элементов влияет на производительность сервера почтовых ящиков, см. в статье Recommended Mailbox Size Limits и Влияние большого числа элементов и ограниченных представлений на производительность (на английском языке).

noteПримечание.
UNRESOLVED_TOKEN_VAL(exBlog)

Дополнительные сведения о доступных усовершенствованиях см. в статье 968009 базы знаний Майкрософт Outlook 2007 improvements in the February 2009 cumulative update (на английском языке).

Дисковые операции ввода-вывода, не относящиеся к транзакциям

Транзактные операции ввода-вывода выполняются в ответ на непосредственное действие пользователя. Они обычно имеют наивысший приоритет, и им придается наибольшее значение при проектировании хранилища. Уменьшение количества транзактных операций ввода-вывода делает операции ввода вывода, не относящиеся к транзактным, еще более важными. Получая большие почтовые ящики, особенно размером в 2 ГБ, многие компании увеличивают объем для пользователей не в два раза, а иногда в десять раз. Примером этого может быть переход от 200 МБ к 2 ГБ. Если есть необходимость в таком значительном увеличении объема данных на диске, при планировании хранилища необходимо учесть и принять во внимание нетранзакционные операции ввода-вывода.

Индексация содержимого

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

Управление записями сообщений

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

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

Оперативное обслуживание

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

noteПримечание.
UNRESOLVED_TOKEN_VAL(exBlog) 

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

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

При наличии 2000 пользователей на сервере, переход от почтовых ящиков размером 200 МБ к почтовым ящикам размером 2 ГБ увеличивает размер базы данных в десять раз. Многие администраторы не привыкли иметь дело с большим количеством данных на одном сервере. Рассмотрим сервер с 2000 почтовых ящиков размером 2 ГБ каждый. С учетом описанных выше накладных расходов общий объем данных составит более 4 терабайт. Если предположить, что можно добиться скорости резервного копирования в 175 ГБ/час (48 МБ/мин), на создание резервной копии такого сервера необходимо 23 часа. В качестве альтернативы серверам, не использующим локальную непрерывную репликацию или кластер с непрерывной репликацией, можно выполнять полную резервную копию одной седьмой части базы данных каждый день, а также добавочное резервное копирование для остатка, как показано в приведенной ниже таблице.

Пример еженедельной процедуры резервного копирования

Тип резервного копирования 1-й день 2-й день 3-й день 4-й день 5-й день 6-й день 7-й день

Полное

БД 1-2

БД 3-4

БД 5-6

БД 7-8

БД 9-10

БД 11-12

БД 13-14

Добавочное

БД 3-14

DB 1-2 DB 5-14

DB 1-4 DB 7-14

DB 1-6 DB 9-14

DB 1-8 DB 11-14

DB 1-10 DB 13-14

БД 1-12

Как видно из приведенной выше таблицы, каждую ночь будет копироваться примерно 650 ГБ данных, на что при скорости в 175 ГБ/час потребуется примерно 3,7 часа. Различные решения обеспечивают большую или меньшую пропускную способность. Однако для больших почтовых ящиков может потребоваться другой подход.

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

Потоковое оперативное резервное копирование

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

Пример одновременного резервного копирования

Номер резервной копии LUN 1 LUN 2 LUN 3 LUN 4 LUN 5 LUN 6 LUN 7

Первое резервное копирование

группа хранения 1

SG 2

SG 3

SG 4

SG 5

SG 6

SG 7

Второе резервное копирование

SG 8

SG 9

SG 10

SG 11

SG 12

SG 13

SG 14

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

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

Сервер Exchange 2007 использует службу теневого копирования томов, входящую в состав сервера Windows Server 2003, для создания теневых копий баз данных и файлов журналов транзакций. Дополнительные сведения о службе теневого копирования томов, включая методы клонирования и моментальных снимков, см. в статье Рекомендации по использованию службы теневого копирования томов в сервере Exchange Server 2003 (на английском языке). В Exchange 2007 добавлена возможность создания службой теневого копирования резервных копий пассивной копии групп хранения в среде кластера с непрерывной репликацией или в среде локальной непрерывной репликации. В этих средах снятие службой теневого копирования томов моментального снимка пассивной копии снижает нагрузку на диск активного LUN в процессе проверки контрольной суммы при резервном копировании, а также при дальнейшем копировании на ленту или диск. Это также позволяет увеличить для активного LUN время, доступное для оперативного обслуживания, управления записями сообщений и выполнения других задач.

Логические номера устройств и физические диски

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

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

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

Проектирование LUN

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

Поскольку в базе данных Exchange используется случайный ввод-вывод, в этом случае для большинства подсистем хранения будет лучше, если физические диски будут иметь одну и ту же рабочую нагрузку. Многие массивы хранения используют виртуальное хранилище таким образом, что сначала физические диски объединяются в группу дисков, после чего из доступного данной группе дисков пространства создаются LUN, которые затем равномерно распределяются по всем физическим дискам. Если не используется непрерывная репликация, вполне допустимо, чтобы физические диски, которые выполняют резервное копирование LUN базы данных группы хранения, также выполняли резервное копирование других LUN, на которых размещаются базы данных других групп хранения и серверов. Также совсем не обязательно размещать LUN журнала транзакций каждой группы хранения на отдельном физическом диске, хотя при этом будет наблюдаться незначительное ухудшение производительности (по причине потери последовательного ввода-вывода). Важно разместить LUN журнала и базы данных одной группы хранения на разных физических дисках. Не имеет практического смысла выделять два или четыре физических диска объемом 500 ГБ для одного LUN журнала транзакций группы хранения, если необходимо обеспечить 30 операций ввода-вывода в секунду и использовать 5% емкости.

Хотя в сервере Exchange 2007 существует много способов создания LUN, во избежание чрезмерной сложности рекомендуется использовать следующие две структуры:

  • два LUN для одной группы хранения;

  • два LUN для одного резервного набора данных;

Два LUN для одной группы хранения

Создание двух LUN (один для журналов, другой для баз данных) для одной группы хранения было стандартной рекомендацией для сервера Exchange 2003. В сервере Exchange 2007 даже при максимальном количестве групп хранения, равном 50, количество LUN зависит от стратегии резервного копирования. Если ожидаемое время восстановления очень мало, или если для быстрого восстановления используются клоны теневого копирования томов, лучше всего поместить каждую группу хранения в собственный LUN журнала транзакций и собственный LUN базы данных. Поскольку такой подход требует больше букв дисков, чем имеется в наличии, необходимо использовать точки подключения томов.

Ниже указаны некоторые преимущества этой стратегии.

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

  • Возможность разделения производительности между группами хранения.

  • Повышенная надежность. Проблемы с емкостью, повреждения или вирусы на одном LUN влияют только на одну группу хранения.

Ниже приведены некоторые недостатки этой стратегии.

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

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

Два LUN для одного набора резервных копий

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

Ниже перечислены некоторые преимущества этой стратегии.

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

  • Потенциальная возможность уменьшить количество заданий резервного копирования.

Ниже приведены некоторые недостатки этой стратегии.

  • Ограничение возможности выполнения аппаратного теневого копирования и восстановления.

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

Точки подключения томов

Во многих случаях, например, для многоузлового кластера с единым хранилищем, количество необходимых LUN превышает количество доступных букв дисков. В таких случаях необходимо использовать точки подключения томов. Буквы дисков — это унаследованная возможность операционной системы MS-DOS для обозначения разделов на дисках. Не рекомендуется использовать слишком много букв дисков. Намного проще поместить все LUN журнала транзакций и базы данных в точку подключения томов, которую легче администрировать. При наличии 20 групп хранения, в каждой из которых расположена база данных, тяжело запомнить, какой букве диска соответствует база данных 17. В приведенной ниже таблице показан пример использования точек подключения томов.

Пример размещения папок с использованием точек подключения томов

Журналы транзакций (L:) Базы данных (P:)

L:\SG1LOG

P:\SG1DB

L:\SG2LOG

P:\SG2DB

L:\SG3LOG

P:\SG3DB

L:\SG4LOG

P:\SG4DB

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

Аппаратное теневое копирование

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

Программное теневое копирование

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

Надежность LUN

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

Пример LUN

Рассмотрим следующий сценарий, который строится на предыдущем примере емкости и применяет эти данные для создания LUN. В данном примере в качестве режима резервного копирования выбрано ежедневное полное резервное копирование. Необходимо включить индексирование содержимого и разместить его в LUN базы данных. 5 % от 193 ГБ приблизительно составляют 10 ГБ. Необходимо добавить это значение к окончательному размеру LUN. Коэффициент роста для 193 ГБ должен составлять 20% от окончательного размера базы данных. 20% от 193 ГБ составляют 39 ГБ. Результаты сведены в приведенные ниже таблицы.

Примеры значений для определения размера LUN базы данных

Размер базы данных Коэффициент роста Индексирование содержимого Размер LUN базы данных

193 ГБ

39 ГБ

10 ГБ

241 ГБ

Каждая группа хранения создает 7,13 ГБ журналов ежедневно. Необходимо сохранять по меньшей мере 3-дневный объем журналов.

Примеры значений для определения размера LUN журналов

Журналы (1 день) Журналы (3 дня)

7,13 ГБ

21,4 ГБ

Переместить почтовый ящик

В данном примере организация перемещает 10% своих почтовых ящиков в неделю. Все перемещения выполняются по субботам. Таким образом, LUN журнала должен обрабатывать всю дневную нагрузку. Стратегия перемещения почтовых ящиков, используемая в корпорации Microsoft, заключается в равномерном распределении входящих пользователей по всем группам хранения. Это означает, что используемый в данном примере сервер с 4000 пользователей будет каждую субботу перемещать 400 пользователей. При наличии 23 групп хранения каждая группа хранения должна принимать 17 почтовых ящиков размером 1 ГБ каждый, как показано в приведенной ниже таблице.

Примеры значений для определения размера LUN журналов для перемещения почтовых ящиков

Журналы (3 дня) Перемещения почтовых ящиков Размер LUN журнала

21,4 ГБ

17,64 ГБ (17 пользователей с почтовыми ящиками по 1 ГБ)

46,6 ГБ (38,8 ГБ + 20%)

При таких условиях в одну группу хранения будет перемещаться не более 17 пользователей ежедневно. Поэтому если в какой-то конкретный день планируется перемещение более 10% пользователей, имеет смысл увеличить размер LUN журнала.

Влияние непрерывной репликации на схему хранилища

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

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

Рекомендуется выполнить следующие действия:

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

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

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

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

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

При использовании непрерывной репликации количество транзактных операций ввода-вывода увеличивается. Этот фактор необходимо учитывать при определении размера сервера. Активный журнал транзакций, который является последовательной записью, должен иметь возможность читать журнал после того, как этот журнал был закрыт, а также копировать его в папку карантина для реплик номеров LUN журналов транзакций. После этого журнал должен пройти проверку по местонахождению реплики, а затем перемещен в точку назначения на реплике номера LUN. В заключении журнал считывается и преобразуется в базу данных. Номера LUN, используемые для активного и реплицированного журналов транзакций, должны обеспечивать чтение и запись при 100%-активности последовательной записи, имеющей место на автономном сервере почтовых ящиков. Такое изменение в поведении может потребовать пересмотра параметров кэша контроллера хранилища. Рекомендуемые значения параметров на контроллере хранилища, оснащенном батареей аварийного питания, составляют 25 процентов для чтения и 75 процентов для записи.

Непрерывная репликация и размер базы данных

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

  • базы данных, размещенные на сервере почтовых ящиков без непрерывной репликации: 100 ГБ

  • Базы данных, размещенные на сервере почтовых ящиков с непрерывной репликацией, оснащенном сетевым адаптером Gigabit Ethernet: 200 ГБ

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

Параметры хранилища локальной непрерывной репликации

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

  • Карты контроллеров хранилищ должны быть установлены на различных шинах PCI.

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

  • Каждое хранилище должно запитываться от отдельной электросети.

Параметры хранилища кластерной непрерывной репликации

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

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

Параметры хранилища кластера с единым хранилищем

Оборудование, используемое для кластера с единым хранилищем, должно быть указано в категории «Кластер» в каталоге серверов Windows. Поддерживаемое оборудование для географически распределенных кластеров с единым хранилищем указано в категории «Географически распределенные кластеры» каталога серверов Windows.

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