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

NETAPP TECHNICAL REPORT

Эффективность хранения и наилучшие методы
при использовании NetApp FAS для
Microsoft Exchange Server 2010

Brad Garvey, NetApp

Февраль 2010 | TR-3824

Коротко о главном:

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

Оглавление

1 Введение. 4

1.1 Цель. 4

1.2 Области применения. 4

1.3 Аудитория. 4

1.4 Учтите!. 4

2 Основы.. 4

2.1 Что такое «эффективность хранения»?. 4

Определение «эффективности хранения» принятое в NetApp. 4

2.2 Технологии NetApp для повышения эффективности хранения. 5

RAID-DP. 5

SATA.. 5

Thin Provisioning и FlexVol 6

Дедупликация. 6

Снэпшоты.. 6

2.3 Стратегия NetApp для достижения эффективности хранения. 6

3 Как достичь высокой эффективности с MS Exchange Server 2010. 6

4 Принципы разработки эффективного решения для Exchange Server 2010. 7

4.1 Установка и распределение пространства хранения. 7

5 Организация пространства хранения. 8

5.4 Сайзинг томов. 11

Сайзинг тома для Transaction Log. 11

Сайзинг тома для Database. 11

Объем дневных изменений в базе данных. 12

Планирование пространства под Snapshots. 12

Наблюдение за свободным местом на томе и скоростью изменений данных. 13

6 Сайзинг и планирование емкости. 14

Емкость под журнал транзакций. 15

6.2 Планирование емкости хранилища. 15

7 Планирование емкости системы хранения. 16

7.1 Размеры майлбоксов, Database Dumpster, базы поиска. 16

Размеры майлбоксов и квот. 16

Database Dumpster. 17

Поисковый индекс Exchange. 18

7.2 Обслуживание и перенос майлбоксов. 18

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

Перенос майлбоксов. 18

7.3 Защита данных. 18

8 Высокая доступность. 19

8.1 Общий дизайн системы и наилучшие его решения. 20

Отказы на уровне системы хранения. 20

Моментальные восстановления. 21

8.2 Сценарии развертывания инфраструктуры.. 21

Одиночный сайт. 21

Многосайтовая система. 21

9 Виртуализация. 22

10 Выводы.. 22

11 Приложение A – Все рекомендации NetApp. 23

Организация пространства хранения. 23

Сайзинг и планирование емкости. 24

Обслуживание базы данных. 24

Защита данных. 24

Высокая доступность. 24

1 Введение

1.1 Цель

Данный документ предлагает ряд наилучших, рекомендованных NetApp способов и практик для различных дизайнов применения систем хранения NetApp®, при создании высокоэффективного хранилища для Microsoft® Exchange Server 2010.

1.2 Области применения

Область применения данного руководства ограничена техническим обсуждением правил и методов разработки технического дизайна, основанных на принципах, политиках и предпочтительных стандартах, рекомендованных NetApp для инфраструктуры хранения Microsoft Exchange Server 2010. Этот документ не описывает полный процесс построения эталонной инфраструктуры «от и до».

1.3 Аудитория

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

В документе рассмотрены следующие области:

• Решения повышения эффективности хранения для Microsoft Exchange Server 2010

• Наилучшие методы и практики при развертывании Exchange Server 2010 на NetApp

• Оценки сайзинга для системы серверов Exchange Server 2010

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

Внимание: В этом документе конкретные рекомендации NetApp выделены в специальные блоки «Наилучшее решение». Полный список всех рекомендаций собран также в конце документа в Приложении A.

1.4 Учтите!

Приведенные рекомендации по Exchange Server 2010 относятся в первую очередь к наиболее свежей версии OS Data ONTAP - Data ONTAP® 7.3.x

Рекомендации по использованию и настройке Unified Messaging в Exchange Server 2010 в данный документ не включены.

2 Основы

2.1 Что такое «эффективность хранения»?

Определение «эффективности хранения» принятое в NetApp

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

2.2 Технологии NetApp для повышения эффективности хранения

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

RAID-DP®

FlexVol®

Thin Provisioning

Deduplication

Snapshot™

Replication

Рис. 1) Технологии NetApp, повышающие эффективность хранения

RAID-DP

RAID-DP это собственная реализация NetApp метода «двойной четности» RAID 6, он является расширением собственной разработки NetApp – Data ONTAP WAFL® RAID 4.

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

SATA

Увеличение дисковой производительности, присущее WAFL и защита от двойного сбоя, которую обеспечивает RAID-DP, делают экономичные и емкие диски SATA более применимыми для использования в дисковых системах хранения. Кроме этого, для снижения негативного эффекта высоких значений времени задержки при доступе к данным (latency), диски SATA могут использоваться вместе с картой NetApp Performance Acceleration Module (PAM), которая значительно увеличивает производительность система при работе большими наборами данных на дисках SATA.

Диски SATA более подвержены проблемам с unrecoverable BIT errors и отказам при работе. Без высокопроизводительной защиты RAID устойчивой к двойному отказу диска, такого как RAID-DP, диски SATA большой емкости несут большие риски сбоя, особенно в течение длительного периода перестроения RAID после единичного дискового сбоя. Таблица ниже приводит сравнение различных типов RAID и вероятности потери данных в течение пятилетнего срока.

Таблица 1) Вероятность потери данных для различных типов RAID

Тип RAID	Вероятность потери данных за пятилетний период	Относительный риск потери данных в сравнении с RAID-DP
RAID-10 (1 диск данных)	0,33%	163
RAID-5 (7 дисков данных)	6,0%	3,955
RAID-6 (7 дисков данных)	0,002%	1,0
RAID-DP (7 дисков данных)	0,002%	1,0

Для подробностей об использовании RAID-DP с Exchange Server смотрите документ: http://media.netapp.com/documents/tr-3574.pdf.

Thin Provisioning и FlexVol

Thin provisioning это функция Data ONTAP в томе типа FlexVol, которая позволяет распределять пространство на дисках таким образом, чтобы разделы данных занимали место на дисках только по мере записи данных на такой раздел (just-in-time storage).

Дедупликация

Технология дедупликации в системах NetApp FAS использует возможности совместного использования блоков данных на дисках. Это возможность Data ONTAP WAFL, и она не зависит от типа протокола, и выполняется самой системой хранения.

Снэпшоты

Технология Snapshot в системах NetApp FAS это не занимающая лишнего места на дисках, практически мгновенно создаваемая копия хранимых на дисках данных тома или LUN, обеспечиваемая функцией Data ONTAP WAFL под названием consistency points (CP).

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

2.3 Стратегия NetApp для достижения эффективности хранения

Как вы видели в предыдущей главе с описанием технологий достижения эффективности хранения, стратегия NetApp по достижению эффективности базируется на ряде встроенных возможностей виртуализации хранилища и универсального хранения (unified storage), которые обеспечиваются собственной операционной системой Data ONTAP и ее структурой организации данных на дисках – WAFL (Write Anywhere File Layout). Таким образом, в отличие от ряда конкурирующих технологий, решение NetApp, построенное вокруг его продуктов FAS и V-Series, использует методы достижения эффективности, находящиеся непосредственно в основе, в «ядре» системы хранения.

Пользователи, уже использующие системы хранения других производителей могут использовать все описываемые возможности и преимущества систем NetApp FAS, воспользовавшись продуктом NetApp V-Series.

3 Как достичь высокой эффективности с MS Exchange Server 2010

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

4 Принципы разработки эффективного решения для Exchange Server 2010

Table 2) Принципы эффективности

Принцип 1
Определение	Используйте RAID-DP как основной тип RAID
Основание	Защита от двойного дискового отказа в RAID с минимальным оверхедом
Следствие	Высокий уровень защиты данных с минимальными накладными расходами, влиянием на производительность и высокой эффективностью
Принцип 2
Определение	В соответствующих случаях используйте диски SATA
Основание	Диски SATA хорошо подходят для систем с высокими требованиями по емкости хранения. Невысокие показатели времени доступа к данным могут быть компенсированы использованием Performance Acceleration Module
Следствие	Экономичные диски с высокой плотностью хранения лучше всего соответствуют системе Exchange c объемными майлбоксами и высокими требованиями по объемам хранения
Принцип 3
Определение	Используйте Thin Provision на системе хранения NetApp
Основание	Использование Thin Provisioning для dedicated restore LUN позволяет его использовать когда он требуется, без необходимости выделять и резервировать на него место на томах системы хранения.
Следствие	Устанение избыточного резервирования пространства хранения
Принцип 4
Определение	В соответствующих случаях использование серверной виртуализации совместно с системами хранения NetApp дает дополнительную экономию
Основание	Технология дедупликации в NetApp предельно эффективна в виртуальной инфраструктуре, что позволяет достичь значительной экономии пространства
Следствие	Позволяет использовать более динамичную, эффективную инфраструктуру
Принцип 5
Определение	Использование дедупликации в Exchange 2010 снижает объем занятого пространства
Основание	NetApp использует стратегию дедупликации на уже размещенных на дисках данных, которая способна работать как на основных, рабочих данных, так и на резервных копиях
Следствие	В зависимости от характера хранимых данных использование дедупликации может снизить используемое на дисках пространство на 10-30% с минимальным влиянием на производительность

4.1 Установка и распределение пространства хранения

Диски

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

Fibre Channel

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

SAS

Диски с интерфейсом SAS, по сравнению с дисками Fibre Channel и SATA, это новинка рынка. Диски SAS обеспечивают показатели емкости и производительности, делающие их отличным выбором для задач сервера Exchange.

SATA

Снизившиеся требования по вводу-выводу в версии Exchange Server 2010 позволяют начать рассматривать диски с интерфейсом SATA как возможное решение для ряда вариантов систем хранения под Exchange. Хотя диски SATA могут и быть иногда неплохим вариантом в отношении производительности и емкости, NetApp рекомендует, чтобы при использовании дисков SATA для Exchange они использовались установленными в полке DS4243. Карта PAM (Performance Acceleration Module) должна использоваться в решении с использованием дисков SATA для того, чтобы обеспечить достаточную производительность решения в периоды повышенной загрузки системы хранения по вводу-выводу.

При выборе типа дисков для решения Exchange 2010, NetApp рекомендует проконсультироваться с нашим экспертом по Exchange. Эксперт поможет вам с процессом планирования и развертывания решения, чтобы вы были уверены в том, что необходимые параметры, такие как задержки ввода-вывода (latency) были обеспечены, и были выполнены SLA, а также требования администраторов Exchange Server 2010.

RAID-DP

В отличие от других типов и расширений технологии RAID, таких как RAID 10, RAID 5, RAID 6, RAID 50, и так далее, RAID-DP обеспечивает более высокий уровень защиты данных одновременно с минимальными потерями производительности при своей работе, и затрачивая на это минимальный объем пространства хранения.

5 Организация пространства хранения

5.1 Рекомендации по организации aggregate

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

Создание отдельных aggregates для томов базы Exchange и для томов под Exchange transaction log/SnapInfo по-прежнему является требованием, продиктованным производительностью Exchange Server 2010, если необходимо обеспечивать доступность данных, как это требуется в большинстве SLA. В случае аварии, когда какой-то из aggregates будет потерян, то частично данные Exchange будут доступны. Администратор Exchange будет иметь возможность восстановить данные с доступного aggregate.

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

Таблица 3) Схемы создания Aggregates

Число агрегатов

Преимущества

Недостатки

Рекомендуется для:

Один общий aggregate для всех данных Exchange

Количество дисков parity минимально

В случае аварии с потерей aggregate, данные Exchange на таком aggregate теряются полностью

Небольших систем, с невысоким уровнем ввода-вывода

Несколько aggregates для данных Exchange (данные database и transaction logs отдельно)

Нагрузка ввода-вывода для database и transaction logs разделена.

Если теряется какой-то из aggregates целиком (маловероятная проблема), то это не приводит к полной потере данных Exchange.

Больше дисков уходит на parity disks.

Систем с высокой нагрузкой

Наилучшее решение

NetApp рекомендует сохранять как минимум 10% свободного места на aggregate, который несет данные Exchange. Это позволит системе хранения работать более оптимально.

5.2 Рекомендации по организации томов

Data ONTAP предлагает особую функциональность, которая позволяет создавать тома для размещения данных не привязанные к конкретным физическим дискам, такие тома называются FlexVol (flexible volumes).Вместо этого FlexVol создается поверх пула физических дисков, входящих в структуру, под названием «aggregate». Такая модель позволяет значительно увеличить производительность работы с данными тома за счет возможности распараллелить ввод-вывод к его данным по всем входящим в aggregate физическим дискам.

Все это дает следующие дополнительные преимущества:

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

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

Схема разбиения пространства системы хранения на тома особенно важна для создания и поддержания высокодоступного хранилища данных Exchange. Внимательный анализ и планирование групп резервного копирования (backup groups), сценариев резервного копирования, решений архивирования, поможет определить порядок размещения томов и LUN на «аггрегейтах».

Наилучшее решение

Рекомендуется разделить разные тома баз и transaction log, принадлежащие разным серверам Exchange, для предотвращения потенциальной проблемы «busy Snapshot copy». Так как каждый сервер будет размещен на отдельном томе, то не нужно беспокоиться о возможной проблеме перекрывающихся на разных серверах расписаний создания снэпшотов.

Наилучшее решение

Поместите LUN-ы базы данных и transaction log/SnapInfo в отдельные тома.

Наилучшее решение

Если вы используете отдельные LUN-ы для файлов transaction log и директории SnapInfo, поместите эти LUN-ы на один том. Оба этих LUN-а имеют сходный характер профиля ввода-вывода, позволяющий держать их на одном томе. В случае же сценария disaster recovery, хранение всего лога на одном томе поможет обеспечить требования SLA.

Наилучшее решение

NetApp рекомендует держать по меньшей мере 10% свободного места на томе, который несет данные Exchange.

5.3 Рекомендации по организации LUN

При создании конфигурации LUN-ов для Exchange 2010, число их сильно зависит от выбранных значений recovery point objectives (RPO) и recovery time objectives (RTO).

• Один LUN на базу данных

Один LUN на базу данных означает, что как база данных, так и соответствующий ей журнал транзакций будут помещены на один и тот же LUN. При использовании такой конфигурации LUN, база майлбоксов должна быть частью database availability group (DAG) и иметь две или более копии, и не использовать аппаратный Volume Shadow Copy Service (VSS).

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

• Два LUN-а на каждую базу данных

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

В системе с большим количеством LUN-ов, журналы транзакций нескольких баз майлбоксов могут помещаться на одном LUN. В такой ситуации, каждый LUN журналов транзакций должен быть помещен в отдельный том, для обеспечения наилучших показателей RPO/RTO. При использовании конфигурации LUN-ов такого типа, NetApp рекомендует ограничивать число потоков записи журналов на LUN числом от 5 до 10.

Наилучшее решение

При создании LUN-ов наилучшим решением будет использовать «точки монтирования», а не «буквы дисков». Такое решение сэкономит буквы дисков в том случае, если вы потребуется множество LUN.

Наилучшее решение

Когда это возможно, отделяйте базу Exchange и файлы transaction log на отдельные LUN-ы и отдельные тома. Это дает больше гибкости в процедурах резервного копирования и восстановления, а также в методах защиты данных.

Наилучшее решение

Microsoft рекомендует иметь на диске примерно 20% свободного дискового места для оптимальной производительности Windows. Эти 20% свободного места могут помочь предотвратить сбои в работе Exchange, обеспечив дополнительное место, в том случае, когда дополнительные данные Exchange записываются на LUN, и предотвратить ситуацию с закончившимся местом у Exchange, что приведет к отключению соответствующей storage group.

5.4 Сайзинг томов

Задача сайзинга томов делится на две части, сайзинг томов под базу, и под transaction log. NetApp рекомендует, для планирования томов Exchange, в первую очередь руководствоваться Microsoft sizing spreadsheet for Exchange, чтобы определить объемы, необходимые для каждого LUN. Величину Total LUN Requirements можно использовать как основу для вычисления необходимых размеров для томов.

Сайзинг тома для Transaction Log

Точное вычисление размеров тома под transaction log, зависит от следующих факторов.

• Total Transaction log LUN size = Общий размер всех LUN-ов для transaction log, хранящихся на одном томе

• Snapshot copy space = Место, занятое под transaction logs, созданных за 24 часа

• Online Backup Retention Duration = Число дней, за которые хранится резервная копия. День считается за 24 часа

Размер тома под transaction log вычисляется по формуле:

Размер тома Transaction Log = Total Transaction Log LUN size + (snapshot copy space * Online Backup Retention Duration)

Сайзинг тома для Database

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

Для вычисления размеров тома под Exchange DB задействованы следующие переменные:

• Database LUN Size = Размер LUN, на котором хранится Exchange Mailbox или Public Folder Database

• Database daily change rate = Величина изменений в Exchange Mailbox или Public Folder Database за день, в процентах от общего объема базы.

• Online Backup Retention Duration = Число дней, за которые хранится резервная копия. День считается за 24 часа

• Fault Tolerance Window = Число дней, в течении которых резервная копия хранится без исчерпания пространства снэпшотов. Обычное значение для этого параметра 2 – 4.

Размер тома под database вычисляется по формуле:

Размер тома Database = Сумма объемов всех Database LUN Size + (Fault Tolerance Window + Online Backup Retention Duration) * Database daily change rate

Объем дневных изменений в базе данных

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

A = средний (average) размер сообщения

R = число принятых (received) сообщений на пользователя в день

S = число посланных (sended) сообщений на пользователя в день

U = число пользователей (users)

log change delta = (R+S) * A * U * 1,2.

database change delta равна log change delta * 1.4.

Пример:

Средний размер сообщения (A) = 100K

Число принятых сообщений на пользователя в день (R) = 80

Число посланных сообщений на пользователя в день (S) = 20

Количество пользователей (U) = 25K

Log Change Delta (80+20)* 100K * 25K * 1.2 = 300GB/день

Database Change Delta = Log change delta * 1.4 = 420GB

Общий объем = 720GB

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

Когда вы планируете тома системы хранения под сервер Exchange, используйте рекомендации NetApp для установок размеров места под снэпшоты и политик retention для несущих LUN-ы томов, содержащих данные Exchange. Это гарантирует достаточно пространства для работы баз Exchange Server и использования восстановления из резервных копий в онлайне.

Рекомендуются следующие параметры для томов на системе хранения, и пространства для снэпшотов.

Guarantee = volume

LUN reservation = on

Fractional_reserve = 0%

Snap_reserve = 0%

Auto_delete = volume

Auto_grow = off (Устанавливается в зависимости от выбранной схемы)

Try_first = snap_delete

Внимание: В случае если используется параметр volume autogrow, то параметр autodelete также должен быть включен и установлен, чтобы гарантировать достаточный объем свободного места на томе.

Параметры snapshot auto delete

State = on

Trigger = volume

Delete_order = oldest_first

Defer_delete = prefix

Prefix = exchsnap

Target free space = это количество пространства, которое ONTAP освободит при удалении снэпшотов с помощью функции autodelete. По умолчанию эта величина установлена на 20%, это означает, что если запущен auto delete по причине нехватки места, то autodelete будет продолжать удалять снэпшоты, пока на томе не появится 20% свободного места. Рекомендуется устанавливать этот параметр на 2% больше чем порог auto delete.

Пороги автоудаления (autodelete) зависят от размера тома.

Volume Size	Trigger
< 20GB	85%
20 < 100GB	90%
100 < 500GB	92%
500 < 1TB	95%
=>1TB	98%

Пример:
Для тома размером 500GB установки target_free_space должны быть установлены в значение 93%.

Наблюдение за свободным местом на томе и скоростью изменений данных

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

Количество свободного места на томе показывается консольной командой в интерфейсе командной строки Data ONTAP:

df –g <vol_name>

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

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

6 Сайзинг и планирование емкости

6.1 Рекомендации по планированию размера кэша базы данных

В предыдущих версиях Exchange Server, одной из ключевых метрик необходимой для планирования хранилища данных был величина операций ввода-вывода для базы данных на каждого ее пользователя. Наилучшим критерием оценки объемов IOPS майлбокса в Exchange Server 2010 является величина кэша базы данных из расчета на майлбокс и число сообщений, которые пользователь получает и отсылает за день. Эти оценки действуют только для кэша базы размером от 3MB до 30MB на майлбокс. Средний размер сообщения принятый в данной оценке взят равным 75KB, но размер сообщения это не основной фактор для величины IOPS. Другие типы клиентов и сценариев использования могут давать иные результаты.

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

Таблица 4) Профили ввода-вывода

Отправленных/полученных сообщений на майлбокс в день (~75K каждое)	Кэш базы данных на mailbox (MB)	Single Database Copy (Standalone): оценочно IOPS на mailbox	Multiple Database Copies (Resiliency): оценочно IOPS на mailbox
50	3	0,060	0,050
100	6	0,120	0,100
150	9	0,180	0,150
200	12	0,240	0,200
250	15	0,300	0,250
300	18	0,360	0,300
350	21	0,420	0,350
400	24	0,480	0,400
450	27	0,540	0,450
500	30	0,600	0,500

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

Размер кэша базы данных должен быть учтен в процессе сайзинга, чтобы быть уверенным в том, что физический объем памяти в сервере адекватен требованиям числа майлбоксов на сервере для данного пользовательского профиля и использования. Приведенная ниже таблица показывает размеры кэша базы данных майлбоксов по умолчанию для сервера типа single-role mailbox server и для сервера типа multirole:

Таблица 5) Размер кэша базы майлбоксов по умолчанию

Физическая память сервера, GB	DB Cache: Mailbox Role (только), GB	DB Cache: Multirole (например Mailbox + Hub), GB
2	0,5	Не поддерживается
4	1	Не поддерживается
8	3,6	2
16	10,4	8
24	17,6	14
32	24,4	20
48	39,2	32
64	53,6	44
96	82,4	68
128	111,2	92

Для того чтобы определить требования к памяти для сервера, сперва определим размер кэша базы данных, умножив число майлбоксов на объем памяти, объем которого основан на данных пользовательского профиля. Например, 2500 майлбоксов профиля «150 сообщений в день» требуют 22,5GB кэша базы данных (2500 * 9MB = 22,5GB). Далее, определим объем потребной физической памяти, определив что данной конфигурации нужно 22,5GB кэша базы данных. Например, single role mailbox server с 32GB физической памяти обеспечит 24,4GB кэша базы данных, таким образом 32GB физической памяти это идеальная конфигурация памяти для рассмотренного количества майлбоксов и профиля их использования. Наконец, определим число баз данных, необходимых для нашего дизайна, чтобы убедиться в том, что требования по памяти на базу данных выполняются. Такой же простой процесс может быть выполнен и в случае конфигурации multirole server. Требования к памяти дополнительных приложений или нагрузок должны быть прибавлены к вычисленной величине физической памяти для Exchange Server 2010.

Емкость под журнал транзакций

Exchange 2010 создает примерно на 10% меньшее число журналов транзакций в день, чем Exchange 2007. В таблице приведены данные, которые следует применять для оценки числа журналов транзакций. Важно отметить, что данные приведены для среднего размера письма в 75KB, и показывают число журналов транзакций, создаваемых системой из расчета на майлбокс в день.

Таблица 6) Количество журналов транзакций

Профиль	Объем журнала транзакций (на майлбокс в день)
10 послано/40 получено	10
20 послано/80 получено	20
30 послано/120 получено	30
40 послано/160 получено	40
50 послано/200 получено	50
60 послано/240 получено	60
70 послано/280 получено	70

Для дополнительной информации о кэше базы данных и рекомендациях по параметрам ввода-вывода смотрите документ http://technet.microsoft.com/en-us/library/ee832793.aspx

6.2 Планирование емкости хранилища

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

Имеется два основных инструмента, которые можно использовать при планировании и оценке системы Exchange для пользователя:

1. Microsoft storage calculator

2. NetApp Exchange Sizing Tool

Microsoft storage calculator предлагает информацию по сайзингу основываясь на следующих параметрах:

• Конфигурация Exchange Server

• Конфигурация Mailbox

• Требования по I/O

• Конфигурация данных Exchange и их резервных копий

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

Информация, полученная в результате работы с этими инструментами важна для планирования инфраструктуры Exchange и обеспечивает базис для планирования и создания дисковых ресурсов, а также требований к создаваемым LUN. Важно упомянуть, что Microsoft storage calculator не предоставляет рекомендаций по планированию собственно системы хранения (RAID parity, число дисков, и так далее) так как планирование хранилища данных сильно зависит от типа используемой системы хранения. Когда вы планируете инфраструктуру Exchange в расчете на использование систем хранения NetApp, воспользуйтесь NetApp Exchange Sizing Tool.

Наилучшее решение

Воспользуйтесь NetApp Sizing Tool for Exchange для оценки и планирования всех серверов Exchange, которые будут использовать системы хранения NetApp.

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

7 Планирование емкости системы хранения

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

7.1 Размеры майлбоксов, Database Dumpster, базы поиска

Размеры майлбоксов и квот

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

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

Одна из новинок Exchange 2010 это «архивный майлбокс» (archive mailbox). Если процесс архивирования почты включен, то у пользователя появляется специальный дополнительный майлбокс, созданный в той же базе данных. Пользователь может вручную переносить в такой «архивный» майлбокс объекты из своего основного майлбокса. Также есть возможность импортировать файл PST в такой архивный майлбокс. Можно настроить автоматическую политику по переносу почты в такой архивный майлбокс из основного. Квота на архивный майлбокс может быть установлена также, как и на основной.

Database Dumpster

Database dumpster претерпел определенные архитектурные изменения в версии Exchange 2010. Его новая версия называется Dumpster 2.0. В Exchange 2007 dumpster был в основном виртуальным и являлся «видом» (view). Удаленные объекты, находящиеся в папке, оставались в папке, но были помечены в базе данных как удаленные, и тем самым были скрыты при просмотре.

Dumpster в Exchange 2010 реализован как специальная папка под названием Recoverable Items и расположен в пределах Non-IPM subtree пользовательского майлбокса. Эта папка имеет три подпапки:

1. Deletions

2. Versions

3. Purges

Папка Deletions заменила собой вид, который отображался, когда пользователь использовал инструмент Recover Deleted Items. В случае soft delete, или когда пользователь в Outlook делает hard delete для объекта, объект перемещается в папку Recoverable Items\Deletions. Когда пользователь Outlook/OWA попадает в Recover Deleted Items, служба RPC Client Access переводит запрос и возвращает вид из папки Recoverable Items\Deletions.

Single Item Recovery предотвращает нежелательную очистку данных и обеспечивает возможности хранения версий (то есть возможность восстановить несколько различных состояний объекта с течением времени). По умолчанию данные сохраняются, пока время их нахождения «удаленными» не превысит заданного «окна восстановления». Вдобавок к этому, Exchange 2010 позволяет долговременное хранение удаленных данных для использования сценария litigation hold, чтобы предотвратить очистку всех данных разом. Таблица поясняет варианты поведения Exchange 2010:

Таблица 7) Single Item Recovery

Состояние опций	Soft-Deleted лежат в Dumpster	Измененные (версии) и Store Hard-Deleted лежат в Dumpster	Пользователь может очистить Dumpster	MRM автоматически очищает Dumpster
Single Item Recovery включен	Да	Нет	Да	Да, 14 дней по умолчанию и до 120 дней для объектов календаря
Single Item Recovery выключен	Да	Да	Нет	Да, 14 дней по умолчанию и до 120 дней для объектов календаря
Litigation hold включен	Да	Да	Нет	Нет

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

Поисковый индекс Exchange

Exchange Server 2010 создает индекс базы данных Exchange, который, в среднем, имеет размер примерно в 10% ее размера. Этот индекс размещается на том же LUN, что и соответствующая ему проиндексированная база. Очень важно учесть размер их обоих при планировании размеров тома и несущего их LUN. Администратор может выключить процесс content Indexing для конкретной базы, но по умолчанию в Exchange 2010 она включена.

7.2 Обслуживание и перенос майлбоксов

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

Процесс онлайн-обслуживания (online maintenance) радикально поменялся в Exchange 2010. По умолчанию online maintenance выполняется при запуске системы, и работает в фоновом режиме.

• Очистка производится непосредственно (в момент когда происходит hard delete).

• Онлайн-обслуживание происходит во время очистки store dumpster.

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

• Параметр Database checksum по умолчанию установлен в Always On, что дает более «последовательный» (sequential) паттерн ввода-вывода.

Наилучшее решение

Процесс Online maintenance должен работать круглосуточно.

Перенос майлбоксов

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

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

7.3 Защита данных

Программный продукт NetApp под названием SnapManager® for Microsoft Exchange (SME) поддерживает Microsoft Exchange Server 2007 и 2010.

SME тесно интегрируется с Microsoft Exchange, что позволяет создавать консистентную резервную копию в онлайн-режиме для системы Exchange, с использованием технологии NetApp Snapshot copy. SME это VSS (Snapshot copy) requestor, что означает, что он использует разработанную Microsoft подсистему VSS для создния резервной копии. SME предлагает ряд возможностей, дополняющих штатные возможности высокой доступности Microsoft Exchange Server 2010.

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

Наилучшее решение

Используйте SnapManager for Exchange при развертывании Exchange Server 2007 на системе хранения NetApp. SME проведет миграцию данных с локальных дисков на LUN-ы NetApp. Он также помогает управлять данными, организует резервные копии, восстановление из них, и задачи контроля целостности.

Для подробностей о SnapManager for Microsoft Exchange, посетите страницу SnapManager for Exchange на вебсайте NetApp. Дополнительные материалы по применению доступны в документе: TR-3541: SnapManager 4.0 for Microsoft Exchange: Best Practices Guide.

8 Высокая доступность

Microsoft предпринял ряд значительных шагов для дальнейшего улучшения возможностей высокодоступной конфигурации в Exchange 2010. Часть существовавших в предшествующих версиях опций были удалены. LCR, CCR, SCR, и SCC, которые присутствовали в Exchange 2007 больше не используются.

Изменения по сравнению с Exchange 2007:

• Больше нет EVS/CMS.

• База данных больше не привязана к серверу, а является ресурсом уровня «организации» (organization-level).

• Больше не требуется выбирать конфигурацию Cluster или Non Cluster на этапе инсталляции; сервер Exchange 2010 Server может вступать и исключаться из DAG по мере необходимости.

• Снято ограничение, что в кластерный Exchange Server может иметь роль только севера майлбоксов.

• Процессы failover и failback теперь не являются частью сервиса Windows Cluster Services.

Вместо ранее существовавших решений в прежних версиях Exchange, Microsoft предложил новую концепцию, под названием Database Availability Group (DAG). DAG использует концепцию «отправки логов» (log shipping), которая использовалась в CCR. DAG состоит из 2 или более серверов майлбоксов; однако максимальное количество их не может превышать 16 в одной DAG. Каждый mailbox server может держать на себе одну или более активную или пассивную копию базы. Каждая база имеет самостоятельный статус, таким образом один сервер может нести копии множества баз, при этом только некоторые из них могут быть одновременно активными.

DAG использует новый компонент Exchange, под названием Active Manager. Active Manager обслуживает процедуры failover и failback. В случае отказа, Exchange 2010 «повышает» статус одной из копий баз до активного и сервер роли mailbox server role принимает на себя задачу обслуживания майлбоксов из этой базы. Некоторые новые возможности DAG:

• Резервная пассивная копия (как в CCR) вместо политики HA+Hold (без резервной копии)

• Обнаружение отказов хранилища и автоматическое реагирование (failover)

• Нет требований к настройке подсети и DNS

• Быстрый failover (<30s)

Рисунок показывает пример DAG.

Рис. 2) Database Availability Group

На рисунке вы видите три сервера и три копии каждой базы, по одной на каждом сервере. Активная база на каждом сервере только одна, она выделена красным. Пассивные копии каждой базы обновляются с помощью log shipping.

8.1 Общий дизайн системы и наилучшие его решения

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

Отказы на уровне системы хранения

Чтобы снизить негативный эффект от отказов на уровне хранилища, в особенности с использованием JBOD, Microsoft рекомендует держать как минимум три копии каждой базы данных майлбоксов. Это обеспечивает устойчивость к двойному дисковому отказу в случае использования JBOD без RAID. При хранении данных на системе NetApp, RAID-DP может обеспечить отказоустойчивость против двойного дискового отказа с минимальными потерями дисковой производительности.

Моментальные восстановления

В конфигурации с использованием DAG, каждая копия базы данных это текущая, актуальная копия данных. Это делает восстановление на какой-то определенный прошедший момент времени более сложной задачей. Для этого можно добавить создание дополнительной копии, под названием LAG. Для Exchange 2010 DAG, мы можем определить задержку времени «обрезки» базы вплоть до 14 дней. Это позволяет нам осуществлять моментальные восстановления из такой копии на заданный момент времени в пределах срока в две недели. Для моментального восстановления данных можно также применять SnapManager for Exchange, который позволяет использовать эффективно использующие пространство на дисках снэпшоты, обеспечивая гибкость быстрого и простого восстановления состояния базы на необходимый момент времени, не требуя создавать и использовать копию базы LAG.

8.2 Сценарии развертывания инфраструктуры

Одиночный сайт

Вариант с использованием двухузлового DAG, с минимум двумя копиями каждой базы майлбоксов на одном сайте лучше всего подходит для компаний, желающих получить избыточность на уровне сервера и приложения. В такой ситуации, развертывание двухузлового DAG, использующего RAID-DP обеспечивает не только избыточность на уровне сервера приложений, но и защиту от двойного отказа дисков в системе хранения. Добавление SnapManager for Exchange в рассматриваемый сценарий даст вам также возможность осуществлять моментальные восстановления на заданные моменты времени без значительных дополнительных требований к пространству для размещения резервной копии LAG и всей сопутствующей этому сложности.

Многосайтовая система

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

Для подробностей о планировании структуры DAG смотрите http://technet.microsoft.com/en-us/library/dd979781.aspx.

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

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

9 Виртуализация

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

Для подробной информации и рекомендаций по виртуализации сервисов Exchange 2010 смотрите: http://technet.microsoft.com/en-us/library/aa996719.aspx.

10 Выводы

Microsoft Exchange Server 2010 это не простая программа типа «поставил-запустил-и-работай». Множество опции конфигурации доступны для настройки, чтобы обеспечить конфигурацию для потребностей почти любого пользователя. Системы хранения NetApp и ПО управления данными обеспечивают пользователям необходимую гибкость использования и управления данными Exchange для удовлетворения потребностей бизнеса. Обеспечивая высокую производительность, простоту администрирования и надежность, NetApp предлагает гибкое решение хранения и управления данными для обеспечения работы Exchange Server 2010 enterprise messaging systems.

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

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

11 Приложение A – Все рекомендации NetApp

Организация пространства хранения

Наилучшее решение

Поместите LUN-ы базы данных и transaction log/SnapInfo в отдельные тома.

Наилучшее решение

NetApp рекомендует держать по меньшей мере 10% свободного места на томе, который несет данные Exchange.

Наилучшее решение

Сайзинг и планирование емкости

Наилучшее решение

Обслуживание базы данных

Наилучшее решение

Процесс Online maintenance должен работать круглосуточно.

Защита данных

Наилучшее решение

Высокая доступность

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