Изменения в управлении версиями восстанавливаемых элементов в Exchange 2010 SP2 RU3


Исходная статья опубликована 1 июня 2012 г.

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

  1. Управление версиями в функциях восстановления отдельных элементов и судебного удержания
  2. Регистрация версий календаря

Восстановление отдельных элементов и судебное удержание

Функции “восстановление отдельных элементов” и “судебное удержание” позволяют сохранять данные в почтовом ящике. Если вы незнакомы с этими функциями, см. дополнительные сведения в моей предыдущей статье Восстановление отдельных элементов в Exchange 2010.

Помимо сохранения данных в почтовом ящике, функции восстановления отдельных элементов и судебного удержания позволяют управлять версиями. При изменении элемента выполняется операция “копирование при записи” (COW), которая сохраняет исходную версию элемента. Исходный элемент помещается в папку Восстанавливаемые элементы\Версии. Эта папка не отображается для пользователей.

Учитывая, что в Exchange 2010 включено изменение способа подключения клиента к почтовому ящику и доступа к его данным, действие “копирование при записи” выполняется на уровне системных объектов Exchange (XSO) на сервере клиентского доступа.

При каких условиях выполняется операция “копирование при записи”?

  • Для сообщений и публикаций (IPM.Note* и IPM.Post*) операция “копирование при записи” захватывает изменения в теме, основном тексте, вложениях, сведениях об отправителях и получателях, а также датах отправки и получения.
  • Для других типов элементов операция “копирование при записи” захватывает любые изменения, кроме перемещений между папками и изменений состояния “прочитано”/”не прочитано”.
  • “Копирование при записи” не применяется к черновикам, чтобы не создавать чрезмерное количество копий при их автоматическом сохранении.

Что может стать причиной чрезмерного увеличения папки “Восстанавливаемые элементы”?

Overflowing-Trash-Can_thumb[1]Поведение “копирование при записи” может привести к чрезмерному росту. Мы обнаружили, что в следующем сценарии использование Microsoft Outlook является основной причиной избыточных операций “копирования при записи”:

  1. Вы создаете встречу в календаре.
  2. Вы прикрепляете к встрече документ Office и сохраняете ее
  3. Затем вы открываете встречу, чтобы просмотреть документ Office. Вы открываете документ.
  4. Outlook начинает автоматически сохранять открытую встречу и соответствующий открытый документ в фоновом режиме (по умолчанию Outlook выполняет автоматическое сохранение каждые 3 минуты).
  5. Каждое событие автосохранения запускает операцию “копирование при записи”. Поскольку сохраняется и документ Office и встреча, происходят два события “копирования при записи”. Для каждого дополнительного вложения также будут создаваться версии “копирования при записи”.

Да, это так.

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

  1. CreateAttachment
  2. SaveAttachment
  3. SaveMessage

“Копирование при записи” происходит при выполнении обеих операций SaveAttachment и SaveMessage. Углубившись в код, мы обнаружили, что вызов SaveAttachment в конечном счете приводит к вызову метода Flush (таким образом клиент синхронизирует состояние с сервером) для сообщения, с которым он связывается после сохранения вложения. Именно вызов метода Flush активирует код “копирования при записи”.

После дополнительного анализа мы поняли, что логика “копирования при записи” запускается при любом вызове метода Flush. Это очень важное открытие, так как Flush может быть инициирован во многих сценариях и может быть причиной тысяч событий “копирования при записи”, которые некоторые пользователи наблюдали в своих средах.

Начиная с выпуска Exchange 2010 SP2 RU3 “копирование при записи” будет различать операции Flush и Save и будет запускаться только при выполнении операции Save.

Регистрация версий календаря

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

Регистрация версий календаря должна создавать журнал при каждом изменении элемента календаря. Эти журналы отражают историю встречи. С помощью командлета Get-CalendarDiagnosticLog можно просмотреть историю и определить, какие клиенты выполняли деструктивные действия. Регистрация версий календаря также используется помощником по восстановлению календаря, который использует журналы при определении истории заданного элемента календаря для обнаружения противоречий.

В Exchange 2010 регистрация версий календаря для почтовых ящиков включена по умолчанию. Эту функцию можно включить или отключить для почтового ящика с помощью свойства CalendarVersionStoreDisabled. Обратите внимание, что имя свойства CalendarVersionStoreDisabled, поэтому значение по умолчанию  $false означает, что регистрация версий календаря включена.  В зависимости от конфигурации почтового ящика, для сохранения копий элементов календаря используются разные процессы:

  1. Если для почтового ящика не включена функция восстановления отдельных элементов или судебного удержания, урезанные версии элементов календаря сохраняются в корне папки “Восстанавливаемые элементы” и хранятся там в течение 120 дней. Урезанные версии (основной текст и вложения не первого уровня или не внедренные в тип сообщения удаляются) создаются посредством “копирования при записи”.
  2. Если для почтового ящика включена функция восстановления отдельных элементов или судебного удержания, полные копии элементов календаря сохраняются в папке Восстанавливаемые элементы\Удаленные или Восстанавливаемые элементы\Версии. Урезанная версия создается посредством инфраструктуры “копирования при записи” при каждом применении операции необратимого удаления к элементам календаря из папок “Восстанавливаемые элементы\Удаленные” и “Восстанавливаемые элементы\Версии”. Эта урезанная версия помещается в корень папки “Восстанавливаемые элементы” и хранится там 120 дней. Урезанная версия не создается только в том случае, если элемент хранится в папке “Восстанавливаемые элементы\Удаленные” или “Восстанавливаемые элементы\Версии” более 134 дней (120 + 14). Такая ситуация возможна, если вы изменили период хранения, не был выполнен помощник по восстановлению почтового ящика, было отключено судебное удержание и т. д.).

Из-за вышеупомянутой проблемы (логика “копирования при записи” не различала операции Flush и Save) регистрация версий календаря в некоторых случаях могла расходовать значительную часть квоты папки “Восстанавливаемые элементы” (если помните, порог предупреждения составляет 20 ГБ, а жесткая квота — 30 ГБ).

Хотя в выпуске SP2 RU3 проблемы “копирования при записи” устранены, для решения проблем расходования функцией регистрации версий календаря всей квоты папки “Восстанавливаемые элементы” в SP2 RU2 мы внесли изменение в архитектуру, благодаря которому регистрация версий календаря теперь рассчитывает размер этой папки перед инициализацией “копирования при записи”.

Если размер папки превышает значение RecoverableItemsWarningQuota, регистрация версий календаря для почтового ящика отключается. Используемое значение RecoverableItemsWarningQuota зависит от настроек почтового ящика:

  1. Если свойство почтового ящика UseDatabaseQuotaDefaults имеет значение $true, будет использоваться значение RecoverableItemsWarningQuotaбазы данных почтовых ящиков.
  2. Если свойство почтового ящика UseDatabaseQuotaDefaults имеет значение $false, будет использоваться значение RecoverableItemsWarningQuota почтового ящика.

Когда регистрация версий календаря отключается, в журнале приложений на сервере клиентского доступа регистрируется следующее событие:

Код события: 5003
Источник: хранилище среднего уровня MSExchange
Категория задачи: CopyOnWrite
Уровень: информация
Описание: почтовый ящик пользователя <legacyExchangeDN> превысил квоту предупреждения корзины. Регистрация версий календаря для почтового ящика отключена.

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

Росс Смит IV (Ross Smith IV)
старший руководитель программы
группа улучшения качества программного обеспечения Exchange

Это локализованная запись блога. Исходная статья находится по адресу: Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3


Comments (0)

Skip to main content