Хранилище – это наиболее критичный компонент для внутреннего сервера Exchange и именно оно обычно является причиной снижения производительности. Если ваши пользователи жалуются на частые сообщения Outlook, которые говорят о необходимости доставки данных с сервера Exchange, это указывает на то, что узким местом является именно хранилище. Хорошее планирование и выбор правильного размера диска поможет избежать этих проблем.
Если вы пропустили первую часть Искусство и наука оценки требований к Exchange 2003 (Часть 1)
Дисковая подсистема
Выбор размера дисковой подсистемы – наиболее сложная и критичная задача, потому что этот компонент наиболее часто становится узким местом. В следующих нескольких строчках я попытаюсь объяснить вам, как оценить требования к вашему дисковому хранилищу и как правильно выбрать размер вашего внутреннего сервера, чтобы избежать его загрузки.
| Технология | Описание |
|---|---|
| DAS – Direct Attached Storage | Это наиболее главный уровень хранилища и наиболее популярная технология для малых и средних серверов. Устройства хранения локально подключены к компьютеру, в качестве внешних дисков или напрямую подключены к серверу, в виде массивов RAID или библиотек. Диски могут быть SCSI, Fibre-Channel или ATA/SATA. |
| SAN – Storage Area Network | Эта технология для корпоративных решений. Данные хранятся отдельно от сервера, подключены с помощью высокопроизводительной сети. В основном используется Fibre-Channel, гигабитная сетевая технология, но для присоединяемых устройств может также использоваться SCSI или iSCSI. |
| NAS – Network Attached Storage | Хотя и не поддерживается изначально, но может быть использована в Exchange после пересмотра политик Microsoft (Q839687). NAS – устройство специального назначения, включающее в себя жесткие диски и управляющее программное обеспечение, которое обслуживает сетевые файлы. |
Таблица 1: Технологии хранения
Exchange Information Store – это базовое хранилище для общих и частных данных. Службы Information Store используют технологию Extensible Storage Design, транзакционный движок баз данных. Информация хранится в файлах .EDB and .STM, в то время как транзакции регистрируются в файлах журналов с расширением .LOG. Хотя, существуют также дополнительные файлы, но их не стоит брать в расчет при планировании подсистемы хранения информации. Шаблоны ввода/вывода операций чтения и записи различны для каждого типа файлов, что отображено в таблице.
| Компонент | Шаблон ввода/вывода |
|---|---|
| Jet database (.edb) | Произвольное число операций чтения и записи размер: 4KB |
| Streaming database (.stm) | Последовательные операции чтения и записи Переменный размер страницы, но в промышленном окружении обычно 8K |
| Transactional logs (.log) | 100% последовательная запись при нормальных операциях 100% последовательное чтение при операциях восстановления Различный размер – от 512 байт до размера буфера |
Таблица 2: шаблоны ввода/вывода для компонентов Exchange store
Несмотря на то, что известны шаблоны ввода/вывода основных компонентов Exchange, при размещении этих файлов необходимо придерживаться рекомендаций для улучшения производительности и доступности. Эти рекомендации приведены в следующей таблице:
| Источник ввода/вывода в Exchange | RAID уровень | Рекомендации |
|---|---|---|
| OS Binaries | RAID 1 (DAS) | Двоичные файлы операционной системы должны размещаться на томе RAID 1 DAS, по причине сохранения переносимости. |
| Database files | RAID 0+1 (5) | Все файлы базы данных (.edb и .stm) должны располагаться внутри группы хранилищ на отдельном диске, отведенном для этой базы данных. Диск, на котором расположена база данных, должен иметь высокую скорость произвольного доступа. RAID 0+1 должен использоваться для обеспечения высокой производительности и переносимости. Для небольших реализаций Exchange ( |
| Transaction logs | RAID 1 | Т.к. транзакции сначала записываются в журнал транзакций, журнал транзакций должен размещаться на устройстве хранения с наибольшей скорость записи ( |
| Content indexing files | RAID 0+1 | Файлы с индексированных содержимым не следует размещать на том же диске что и файлы страниц (хотя это и является их размещением по умолчанию). Если вы не можете выделить для них отдельный диск, то их можно разместить на одном диске с базой данных. |
| SMTP Queue | RAID 0+1 | Это наиболее важно для серверов с высоким ожидаемым уровнем сообщений SMTP messages, т.е. bridge-heads. В этом случае рекомендуется помещать файлы SMTP Queue на отдельный диск RAID 0+1 с несколькими шпинделями. Избегайте использования дисков, выполняющих другие функции, например, базы данных, журналы транзакций и файлы страниц. |
| MTA Queue | RAID 0+1 | Анализ, проведенный для SMTP queue, также применим для MTA queue, поэтому используйте диск 0+1 volume пока это возможно, если ваш сервер имеет дело со значительным числом трафика SMTP и/или MTA. |
| Page file | RAID 1 (DAS) | Это не новая рекомендация, но вы должны знать, что файлы страниц следует размещать на отдельном диске RAID 1, для оптимальной производительности и переносимости. |
Таблица 3: Рекомендации по оптимизации дискового ввода/вывода
Примечание
Однако, вам необходимо помнить, что эти практические рекомендации должны соотноситься с размерностью и сложностью проектируемой реализации. Например, для небольшой компании с пятью пользователями замечательно подойдет установка сервера Exchange и всех его компонентов на диск C:.
Если бюджет не позволяет вам выполнить все рекомендации, представленные в таблице, то придется рисковать. В самом крайнем случае вы должны разместить файлы базы данных и файлы журналов транзакции на разных дисках (не в разных разделах).
Как расчитать требования к вводу/выводу
После долго вступления давайте прейдем к главной теме этой статьи: как расчитать рекомендации для ввода/вывода для сервера Exchange.
Большинство людей учитывают лишь размер хранилища данных и забывают про фактор производительности. Однако, как я покажу вам немного далее, ключевым фактором здесь является *IOPS*.
Рекомендуемая методология следующая:
1.Определение производительности: первый шаг – это расчет конфигурации хранилища для для удовлетворения итоговой IOPS, требуемой для системы. Запомните, определяем производительность перед определением емкости.
2.Определение емкости: не ошибитесь, взяв для расчета емкость, полученную перемножением количества пользователей на максимальный размер почтового ящика. Мы должны предусмотреть дополнительное пространство для используемых политик, операций с базой данных и учесть будущий рост.
3.Размещение компонентов: наиболее важное правило заключается в размещении журналов транзакций и файлов базы данных по разным дискам. Следуйте рекомендациям, изложенным в таблице 3.
4.Дополнительные настройки: последний шаг – это настройка окружения хранилища для готовности к требованиям Exchange. Например, вы можете сделать максимальным write-back кэш и увеличить размер страницы до 4kB. Еще что вы можете сделать, это настроить физические разделы так, чтобы дорожки диска соответствовали дорожкам сектора, но здесь, я рекомендую сначала проконсультироваться у вашего поставщика аппаратного обеспечения.
Определение емкости относительно простая задача: для того чтобы подсчитать пространство, необходимое базе данных, мы должны умножить итоговое число пользователей на максимальный размер почтового ящика, плюс дополнительное пространство для операций с базой данных и пространство для прогнозируемого роста.
Проблема здесь заключается в том, производительность не учитывали в течении многих лет. Если вы помните первую часть этой статьи, я упоминал 2 важные величины для определения профиля пользователя: megacycles/mailbox и IOPS/mailbox. Последняя из них наиболее важна для определения требований к вводу/выводу.
Для того чтобы вычислить шаблоны использования вновь создаваемого сервера Exchange существует два приближения для расчета требований к вводу/выводу:
Теоретическая оценка нужд пользователей
Если не было предыдущих настроек сервера Exchange, то для определения профиля пользователя,
| Профиль | IOPS | Megacycles | Размер сообщения | Размер ящика |
|---|---|---|---|---|
| Легкий | 0,18 | 0,75 | 10 послано / 50 получено | |
| Средний | 0,4 | 1,9 | 20 послано / 100 получено | 50 MB |
| Тяжелый | 0,75 | 2,5 | 30 послано / 100 получено | 100 MB |
Таблица 4: Профили почтовых ящиков и соответствующие им шаблоны
IOPS, упоминаемая в этой таблице, относится к объему хранилища, которое отводится для баз данных писем, которая наиболее критична, т.к. с ней связано 90 процентов всех операций ввода/вывода.
Расчет с использованием «живых» данных окружения
Для того чтобы получить величину IOPS/mailbox из промышленного окружения, мы должны сделать несколько измерений с использованием Performance Monitor (Монитор Производительности). Измерения должны производиться в период пиковой нагрузки в течение минимум 2 часов. Мы будем рассматривать:
·Logical Disk\Disk Transfers/sec\Instance= Диск, на котором находится база данных Exchange Store. (Добавьте все диски, которые содержат файлы базы данных Exchange).
·MSExchangeIS\Active User Count
Величина IOPS/Mailbox получается при делении среднего значения из этих двух величин.
Определение производительности
После определения требований к вводу/выводу, пришло время подумать, как удовлетворить их. Факторы, которые влияют на IOPS системы хранения следующие:
·Скорость вращения диска (10.000rpm, 15.000rpm): Обычно, 15.000rpm диски могут обеспечить до 180 IOPS, в то время как 10.000rpm обеспечивают около 130 IOPS. Точные значения могут быть получены при консультации у поставщика аппаратного обеспечения.
·Уровень RAID: от RAID напрямую зависит производительность, т.к. информация может быть записана более одного раза.
·Число дисков: много маленьких дисков обеспечивают большую производительность чем несколько больших.
При расчете штрафа на производительность RAID необходимо сделать некоторые допущения. Одно из этих допущений заключается в том, что соотношение операций чтения/записи в базе данных равно 3:1, т.е. 3 оперции чтения для каждой операции записи.
Следующая таблица показывает коэффициент штрафа для различных уровней RAID:
| Уровень RAID | Штраф I/O | Коэффициент штрафа для 3 чтений + 1 запись (read/write ratio 3:1) |
|---|---|---|
| RAID 0 | Нет дополнительных штрафов. Каждая опреция чтения и каждая операция записи соответствует одной операции ввода/вывода. | 4 / 4 = 1 |
| RAID 1, RAID 0+1 | Каждая операция записи требует 2 дисковых операций ввода/вывода. Операция чтения – одна операция ввода/вывода. | 4 / (3+2) = 0.80 |
| RAID 5 | Каждая операция записи требует 4 дисковых операций ввода/вывода. Операция чтения – одна операция ввода/вывода. | 4 / (3+4) = 0.57 |
Таблица 5: коэффициенты штрафа для RAID
Теперь мы знаем все переменные, которые влияют на производительность ввода/вывода (скорость вращения, уровень RAID и число дисков), все, что нам необходимо – это формула, которая объединит их все вместе:
(IOPS/mailbox) / (number of mailboxes) = (IOPS/disk) / (RAID penalty factor) / number of disks)
Пример:
Представьте себе следующий сценарий: нам необходимо рассчитать требуемый размер хранилища данных для новой инфраструктуры Exchange, которая будет обслуживать 1000 пользователей со средним профилем (0.4 IOPS/user, размер ящика 50MB).
Давайте предположим, что будут использоваться 15000rpm диски с конфигурацией RAID 0+1. Итак, для того чтобы определить число дисков:
(number of disks) = (IOPS/mailbox / number of mailboxes) / (IOPS/disk / RAID penalty factor) = (0.4 / 1000) / (180 / 0.80) = 2.78
Так как мы использовали RAID 0+1, то результат необходимо округлить до ближайшего четного числа, в нашем случае это 4.
Помните, что предыдущие вычисления верны для внутренних серверов. Если у вас большой bridge-head и вы хотите правильно определить его, то необходимо использовать импирическое правило, что один диск может обработать около 30 сообщений в секунду.
Определение емкости
После того как определение производительности завершено, необходимо определить необходимую емкость. Я не буду описывать каждый компонент Exchange, потому что может быть очень много вариатнов. Например, требование к очереди SMTP будет во многом зависеть от объема почтового трафика.
Для сервера внутреннего наиболее критичен объем, содержащий базу данных писем, т.к. он отвечает за 90 процентов операций ввода/вывода. Существует ряд правил, которых необходимо придерживаться:
·Хранить различные группы хранилищ на различных дисках
·Назначать одну базу данных для одной группы хранилищ
·Оценить дополнительно требуемое пространство, основываясь на удаленных элементах вспомогательных политик, прогнозируемом росте и операциях с базой данных.
Итак, для каждой группы хранилищ требумое пространство равно сумме всех баз данных. Предполагая только частные хранилища, требуемый размер для каждой базы данных равен числу пользователей этой базы данных умноженному на размер почтового ящика:
DB size = number of users / mailbox size
Для расчета дополнительного требуемого пространства, я обычно удваиваю эту величину, на вы можете использовать любое другое правило на ваше усмотрение.
Объем, требуемый для журналов транзакций, в основном зависит от двух факторов:
·Размер сообщения
·Политика резервного копирования
Помните, что если вы не используете круговой журнал (а вы и не должны его использовать), размер журнала будет увеличиваться, пока не будет сделана резервная копия.
Мое личное правило – это настроить объем так, чтобы он составлял примерно 10 % от объема базы данных.
Пример:
Для описанного ранее сценария, для определения емкости, мы умножаем количество пользователей на размер электронного ящика:
Capacity = 1000 / 50MB = 50 GB
Обычно, я рекомендую удвоить это значение, для того чтобы предусмотреть будущий рост, оставить место для хранения удаленных элементов и операций с базой данных, поэтому, давайте предположим, что требуется 100 Гб дискового пространства. Для массива RAID 0+1, это пространство может быть получено использованием 4 SCSI дисков, каждый по 72GB.
Резюме
В не зависимости от размера вашей организации и используемой вами технологии, хранилище – это наиболее критичный элемент для успешной работы Exchange. Это абсолютно верно для серверов внутренних и для bridge-heads. Во второй части этой статьи вы увидели, как правильно определить размер для хранилища для внутренних серверов, которое является ядром вашей инфраструктуры. В следующей части я расскажу о процессе проверки, а также, о средсвах, которые помогут вам в процессе определения размеров.
Если вы пропустили первую часть из этой серии, прочтите Искусство и наука оценки требований к Exchange 2003 (Часть 1)
