Хранилище Exchange 2013

MapiExceptionNetworkError: Unable to mount database

www.microsoft.com

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


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


Хранилище Exchange 2013

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

Введение

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

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

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

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

Примечание: На самом деле имя каталога и базы данных могут отличаться. Имя БД содержится в атрибуте Name, а имя каталога фигурирует в строке пути к базе данных и к журналам транзакций. Значения этих параметров содержатся в атрибутах EdbFilePath и LogFolderPath соответственно и могут указывать на любые локальные расположения

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

Хранилище Exchange 2013 02

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

Хранилище Exchange 2013 03

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

.edb

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

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

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


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

Примечание: Если какую-либо базу удалить, то её порядковый номер освободится и в дальнейшем присвоится следующей созданной базе. То есть, если на сервере были базы с префиксами E00, E01, E02 и в какой-то момент база с префиксом E01 была удалена, то когда на сервере будет создана ещё одна база, ей будет назначен префикс E01 

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


.log

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

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

Примечание: размер логов в 1МБ был введен в Exchange Server 2007, более ранние версии использовали дефолтный размер в 5МБ.

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

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

.chk

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

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

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

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

Хранилище Exchange 2013 08

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

.jrs

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

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

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

Хранилище Exchange 2013 07

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

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

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

B+-дерево

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

IC16326

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

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

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

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

Хранилище Exchange 2013 06

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

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

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

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

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

Транзакции

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

slide-3

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

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

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

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

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

Хранилище Exchange 2013 04

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

Хранилище Exchange 2013 05

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

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

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

Примечание: подробнее о принципе работы хранилища вы сможете найти в официальной документации, в том числе и для предыдущих версий Exchange Server 7 8. Но будьте внимательны — между версиями есть существенные различия, особенно это касается Exchange 2007 и старше.

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

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

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

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

  • Несколько баз данных на одном логическом диске. Данная возможность позволяет более эффективно использовать дисковое пространство;
  • Автоматическое повторное заполнение (AutoReseed). В случае сбоя диска для копий базы данных (на каком-либо сервере DAG), хранящихся на нем, автоматически выполняется повторное заполнение на предварительно настроенном свободном диске на сервере почтовых ящиков 9.
Примечание: на ум приходит аналогия с диском горячего резерва (hot spare) для массивов raid.
  • Автоматическая настройка сети в DAG. Администратору больше не требуется поддерживать отдельно сеть для DAG, за него это делает система. Тем не менее, возможность ручной настройки осталась (командлет Set-DatabaseAvailabilityGroup 10, значение —ManualDagNetworkConfiguration $true).

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

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

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

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

Хранилище Exchange 2013 09

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

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

Компоненты управляемой доступности

Примечание: на мой взгляд сервис ещё достаточно «сырой» и качественную диагностическую информацию удается получить не всегда. Тем не менее, уникальными в диагностике могут оказаться командлеты Get-ServerHealth, Get-HealthReport. В любом случае игнорировать такой функционал было бы неправильным решением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vhdresize

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

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

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

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

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

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

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

comments powered by HyperComments