Хранилище Exchange 2013

Хранилище Exchange 2013 вызывает традиционно много вопросов по поводу своего принципа работы, обслуживания и траблшутинга – Как все устроено? Почему в папке с базой столько файлов? Могу ли я эти файлы удалить? А что значит Dirty Shutdown? и многие другие. Эта статья создана с целью пролить свет на принцип работы этого сложного и очень важного компонента почтового сервера Microsoft.

---

Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.

---

Хранилище Exchange 2013

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

Введение

Базы данных Exchange 2013 – это наверно самое первое, с чем администраторам приходится сталкиваться при работе с хранилищем. Много вопросов вызывает обилие файлов в каталогах с базами. Ещё более сильное недоумение испытывают опытные администраторы СУБД, которым приходилось работать не более чем с двумя файлами БД например у MS SQL.

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

Структура файлов

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

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

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

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

.edb

Расширение .edb имеют файлы баз данных, которых в каталоге каждой БД бывает не больше двух штук.

• Database 1.edb (имя взято для примера) – основной файл БД. Является хранилищем полезных данных и их конечным местом назначения. Имя файла, как я и упоминал ранее, обычно совпадает с именем каталога, в котором он находится. На практике размер БД ограничен лишь возможностями оборудования и файловой системы. Теоретический максимум составляет 16ТБ (ограничение ntfs);
• tmp.edb – также файл БД, но его задача отличается. Он предназначен для промежуточного хранения данных в процессе выполнения транзакций. Файл существует лишь в тот момент, когда база смонтирована и пропадает в момент размонтирования БД. Весит не более нескольких мегабайт.

Если имя tmp.edb установлено системой и администраторам не дано его изменить, то имя основного файла БД вы можете выбрать на свое усмотрение. По сути это единственный файл в каталоге, именем которого вы можете управлять.

---

Все остальные файлы имеют в своем имени одинаковый префикс Enn, в котором буквы nn означают порядковый номер базы. Самая первая база на сервере будет иметь номер 00, вторая база – 01, третья 02 и так далее.

Нумерация идет в десятичной системе счисления и, как можно легко догадаться, максимальное количество баз на сервере составляет 100 штук для версии Enterprise (до Exchange 2013 CU2 – 50 БД для Enterprise), в версии Standard максимальное количество активных баз данных искусственно ограничено 5 шт.

---

.log

Файлы логов бывают трех видов:

• Enn.log – текущий файл журнала транзакций. Именно в него идет непрерывная запись всех транзакций и как только достигается размер в 1МБ (1024КБ), он переименовывается и на его месте создается новый Enn.log;

• Enntmp.log – промежуточный файл журнала транзакций. Когда Enn.log приближается к пороговому объему, создается файл Enntmp.log размером в 1МБ. Как только текущий файл лога транзакций заполняется полностью, движок хранилища переименовывает его для дальнейшего хранения, присваивая следующий по порядку номер (см. ниже). Файл Enntmp.log при этом также меняет имя и становится текущим файлом журнала транзакций (Enn.log). Этот механизм необходим для обеспечения непрерывной записи данных в журналы;
• Enn00000001.log – EnnFFFFFFFF.log – архивные файлы журнала транзакций. Любой текущий файл логов – Enn.log – в момент достижения своего максимального объема переименовывается в архивный файл. Нумерация файлов идет в шестнадцатиричной системе счисления и может обеспечить одновременное существование более чем 4 миллиардов файлов журнала транзакций. Эти файлы нужны для восстановления данных в случае сбоев. Если у вас есть полная резервная копия, то необходимость в журналах, сделанных до её создания, отпадает. Именно поэтому при правильном выполнении резервного копирования происходит автоматическое усечение логов транзакций.

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

.chk

В каталоге с БД всегда находится всего лишь один файл .chk:

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

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

Возникает вполне логичный вопрос – “До какого предела сервер может держать данные в оперативной памяти и журналах, не сбрасывая их в БД?” Для Exchange 2013 пороговое значение составляет 100МБ (то есть 100 журналов транзакций) для каждой базы данных и в технической терминологии имеет название глубина контрольной точки (Checkpoint Depth). 

.jrs

Переходим к последнему типу файлов:

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

Вот так выглядит каталог со среднестатистической базой данных Exchange 2013:

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

Принцип работы

В основе хранилища Exchange 2013 лежит ESE (Extensible Storage Engine) – движок на базе индексно-последовательного метода доступа к данным (сокращенно ISAM ² – Indexed Sequential Access Method), который использует модель хранения информации в виде сбалансированных деревьев (B+-дерево ³).

B+-дерево

Структура B-tree ⁴ представляет из себя перевернутое древо с корнем – родителем элементов (страниц данных) – в верхней части и листьями в нижней и выглядит следующим образом:

На уровне Root и Internal располагаются страницы со служебными данными – указателями. “Листья” – Leaf – содержат страницы с полезными данными (например с почтой пользователей). Благодаря такой структуре обеспечивается быстрый доступ к данным, минуя необходимость последовательного перебора всей информации до того момента, пока не будет найдена нужная.

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

Буква “B” – сокращение от Balanced (сбалансированное) – означает, что длина двух любых путей от корня до листьев во всем дереве совпадает.

В БД находится множество сбалансированных деревьев, из которых, в свою очередь, состоят таблицы, а множество таблиц образует схему базы данных: ⁵:

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

Страница данных

Страница данных состоит из заголовка, указателей на другие страницы, контрольной суммы (механизм определения факта повреждения данных) и непосредственно из самих данных (в случае если страница является листом в иерархии дерева). Сервер не может считать половину или полторы страницы, поскольку они являются неделимыми единицами. Размер страницы в Exchange 2013 и 2010 составляет 32КБ, в более ранних версиях использовался размер 8КБ, что требовало больше операций ввода/вывода для считывания одного и того же объема данных.

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

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

Транзакции

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

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

Все это конечно же ни коим образом не способствует тому, чтобы файлы логов транзакций занимали меньше места на диске. Именно поэтому, имея базу данных в пару гигабайт, можно дожить до того, что её журналы транзакций будут весить все 40ГБ. А можно воспользоваться и циклическим ведением журнала транзакций, когда архивные журналы перезаписываются новой информацией после того, как старые данных внутри них будут применены (операция commit) к базе. Но лучшим вариантом будет правильное выполнение резервного копирования.

Состояния базы

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

Если же работа сервера была завершена аварийно или произошло некорректное отключение БД, то состояние базы будет Dirty Shutdown:

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

1. Файл базы данных находится в исправном состоянии;
2. Существуют и находятся в исправном состоянии все необходимые журналы транзакций.

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

Улучшения в Exchange 2013

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

Функциональные

В Exchange 2013 были добавлены следующие новые функции:

• Несколько баз данных на одном логическом диске. Данная возможность позволяет более эффективно использовать дисковое пространство;
• Автоматическое повторное заполнение (AutoReseed). В случае сбоя диска для копий базы данных (на каком-либо сервере DAG), хранящихся на нем, автоматически выполняется повторное заполнение на предварительно настроенном свободном диске на сервере почтовых ящиков ⁹.

• Автоматическая настройка сети в DAG. Администратору больше не требуется поддерживать отдельно сеть для DAG, за него это делает система. Тем не менее, возможность ручной настройки осталась (командлет Set-DatabaseAvailabilityGroup ¹⁰, значение –ManualDagNetworkConfiguration $true).

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

Архитектурные

Основные улучшения в архитектуре хранилища Exchange 2013:

• Разделение экземпляра процесса хранилища ¹². Теперь для обслуживания каждой базы данных выделяется отдельный рабочий процесс хранилища (Microsoft.Exchange.Store.Worker.exe), вместо одного единственного для всех БД в Exchange 2010. Управляет ими отдельный процесс службы хранилища (Microsoft.Exchange.Store.Service.exe), репликация данных осуществляется через процесс службы репликации Microsoft Exchange (MSExchangeRepl.exe).

• Активный мониторинг ¹³. Сервис создан для непрерывного мониторинга и устранения возникающих проблем в автоматическом режиме. Лишь после неудачных попыток восстановления работоспособности идет оповещение администратора через журнал событий. Существует возможность тонкой настройки ¹⁴. Реализован двумя службами:
  • Служба диспетчера работоспособности Exchange (MSExchangeHMHost.exe). Используется для построения, выполнения, восстановления, запуска и остановки рабочих процессов по мере необходимости;
  • Рабочий процесс диспетчера работоспособности Exchange (MSExchangeHMWorker.exe).

• Служба управления DAG (доступна после CU2). Расширяет функцию внутреннего мониторинга DAG, которая ранее выполнялась в службе репликации Microsoft Exchange (MSExchangeRepl).
• DAG без административной точки доступа (AAP – Administrative Access Point) кластера ¹⁵. В Windows Server 2012 R2 появилась возможность создавать кластеры DAG без использования отдельного ip-адреса (Командлет New-DatabaseAvailabilityGroup ¹⁶ с параметром –DatabaseAvailabilityGroupIPAddresses None). Нововведение упрощает администрирование, а также существенно снижает поверхность атаки, ведь ни дополнительного адреса, ни дополнительной записи в DNS больше не будет.

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

Улучшения производительности

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

• Глубина контрольных точек пассивных копий DAG увеличена с 5 до 100МБ. Раньше поддерживался лишь небольшой кэш в 5МБ, чего было явно недостаточно. Как следствие – пассивная копия базы данных нуждалась в таком же количестве операций ввода/вывода, как и активные БД. Также это обеспечивает более быструю отработку отказа в случае проблем с активной копией;
• Оптимизация фонового обслуживания баз данных. Скорость уменьшена с 5 до 1МБ/сек, что положительным образом сказалось на общую нагрузку на дисковую подсистему.

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

Лучшие практики

Ниже сформулированы основные рекомендации по развертыванию и обслуживанию хранилища Exchange 2013.

Планирование развертывания

Перед развертыванием Exchange 2013 важно правильно спланировать и настроить хранилище:

• Между задачами полного бэкапа дисковое пространство непременно будет заполняться логами транзакций. Важно, чтобы при этом всегда оставалось свободное место, иначе вы рискуете столкнуться с простоями в работе. Рассчитайте необходимое свободное место на каждом диске с базами данных в зависимости от политик резервного копирования вашей организации и держите необходимый запас;
• Хранилище Exchange 2013 оптимизировано для работы с большими почтовыми ящиками, вплоть до десятков гигабайт. При этом реальная нагрузка на дисковую подсистему значительно уменьшена в сравнении с Exchange 2010. Самой оптимальной стратегией в этом случае будет покупка емких хранилищ с дешевыми enterprise-дисками SATA большого объема. Отказоустойчивость и надежность решения обеспечивается на прикладном уровне технологией DAG;
• Каждая база данных не должна превышать объем в 2ТБ. В небольших организациях Exchange 2013 объем даже в 200ГБ на каждую БД может показаться большим – определите оптимальный для своей инфраструктуры объем БД, учтите пропускную способность сети, производительность дисковой подсистемы серверов и хранилищ бэкапа и принимайте окончательные технические решения в контексте обеспечения SLA.
• Обязательно разносите на разные диски ОС и базы данных.

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

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

Рекомендации для виртуальной инфраструктуры ¹⁹:

• Не используйте снимки виртуальных машин для серверов Exchange 2013 ни при каких обстоятельствах;
• Используйте только .vhdx-диски фиксированного объем. Fixed .vhdx обеспечат лучшую производительность. Помимо этого, они ещё и более функциональны ²⁰:

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

Не забудьте посетить раздел документации ²¹ на technet по планированию виртуального Exchange 2013.

Повседневные задачи администрирования

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

• Необходимость в резервном копировании БД теоретически отпадает в том случае, если каждая база существует как минимум в трех онлайн копиях DAG;
• Функция автоматического повторного заполнения может повысить надежность и улучшить защиту от потенциальной потери данных. Рассмотрите возможность внедрения этой опции, доступной впервые в Exchange 2013;
• Используйте циклическое ведение журнала только в том случае, если база данных существует как минимум в трех активных копиях DAG. Во всех остальных случаях забудьте про circular loging, если не хотите рисковать сохранностью данных;

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

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