Exchange 2010 ограничение памяти
Обслуживание баз данных Exchange бывает двух видов: непрерывное и по требованию. В данной статье рассматриваются оба типа обслуживания, а также изменения, внесенные специалистами Microsoft в Exchange Server 2010, включая некоторые новые команды, доступные в Exchange Server 2010 SP1
Основой Microsoft Exchange Server являются базы данных, хотя это не так очевидно, как для приложений типа Microsoft SQL Server. Базы данных требуют постоянного внимания для поддержания нужного уровня производительности. .
Необходимость в обслуживании
Некоторые специалисты утверждают, что правильно спроектированное приложение для работы с базами данных должно быть самообслуживаемым. Однако эта цель пока еще не достигнута в реальных приложениях, в том числе в Exchange. Обслуживание необходимо для оптимизации внутренних структур баз данных, удаления устаревших данных и применения политик управления. Большая часть этой работы производится в фоновом режиме, как часть непрерывного обслуживания, осуществляемого процессом Exchange Information Store, а помощник для управляемых папок Managed Folder Assistant отвечает за применение правил политик сохранения (retention policies) к почтовым ящикам, которые подпадают под действие этих политик.
Работа в режиме 24×7
Exchange всегда обладал возможностью фонового обслуживания баз данных. Отличие Exchange 2010 в том, что работа механизма Extensible Storage Engine (ESE), или обслуживание структур баз данных, выполняется по умолчанию в режиме 24 часа 7 дней в неделю, а не в заданном временном окне, как это было в предыдущих версиях (при необходимости вы могли задать в Exchange нужное именно вам временное окно). Недостаток использования временного окна заключается в том, что его могло не хватить для выполнения всей работы. И эта проблема росла с увеличением базы данных, так что приходилось увеличивать это окно в надежде, что удастся успеть выполнить всю работу.
Операции по обслуживанию очень важны для баз данных Exchange, так как они выполняют следующие действия:
- удаление из базы данных элементов и почтовых ящиков («жесткое удаление») по истечении срока сохранения;
- поиск страниц, ранее занятых удаленными элементами и почтовыми ящиками, и их возврат для использования базой данных;
- проверка контрольных сумм страниц для поиска поврежденных страниц.
Exchange 2010 выполняет все эти операции по обслуживанию, но теперь сканирование ESE может осуществляться непрерывно в режиме 24×7, если только вы не отключите фоновое обслуживание базы данных путем изменения ее свойств, как показано на экране 1.
Экран 1. Установка параметров обслуживания базы данных почтовых ящиков |
Сканирование ESE в режиме 24×7 — не единственный вид постоянно выполняемого обслуживания. Exchange 2010 выполняет дефрагментацию в режиме онлайн для оптимизации внутренней структуры, элементы удаляются из базы данных непосредственно сразу после истечения срока хранения, не дожидаясь наступления очередного окна обслуживания, а удаленные страницы сразу же возвращаются в повторное использование для хранения новых элементов. И наконец, процесс Store анализирует состояние непрерывности базы данных после выполнения транзакций и при необходимости запускает фоновый поток для перемещения данных между страницами, чтобы Exchange мог загружать большие непрерывные порции данных, вместо выискивания и извлечения из разных частей базы данных всех страниц, необходимых для выполнения транзакции.
Все эти виды деятельности регулируются автоматически таким образом, чтобы фоновое обслуживание не лишало серверы возможности выполнять клиентские запросы. Другими словами, в моменты пиковой нагрузки Exchange ограничивает объем фонового обслуживания и снимает эти ограничения, когда поток запросов пользователей сокращается.
Для выполнения обработки, например перемещения страниц, необходимой для обслуживания в режиме 24×7, требуются некоторые дополнительные циклы процессора и подсистемы ввода-вывода. Однако это не должно быть проблемой для большинства современных многоядерных серверов, особенно если операции ввода-вывода осуществляются не самим сервером.
Создание политики хранения
Теперь, когда созданы шесть тегов, призванные помочь менеджерам навести порядок в их почтовых ящиках, можно создать новую политику хранения, используя команду New-RetentionPolicy. При создании политики с ней связываются ее теги при помощи параметров -RetentionPolicyTagLinks, как показано в следующей команде:
Можно воспользоваться командой Get-RetentionPolicy чтобы посмотреть детали новой политики хранения. Для нашего примера запустим следующую команду:
Политика с шестью тегами — довольно простая политика хранения. Компания Microsoft рекомендует включать в политику не более 10 тегов, чтобы не сбивать с толку пользователей и системных администраторов, и это весьма неплохой совет. Время от времени вам, возможно, понадобится включить в политику больше тегов, чтобы удовлетворить специфические потребности бизнеса. У более сложной политики для какого-либо подразделения могут быть отдельные RPT для всех папок по умолчанию, ряд личных тегов, разработанных особым образом, чтобы удовлетворить специфические потребности в хранении, и DPT для всего остального.
Создание тегов хранения
Exchange 2010 MRM задуман и реализован весьма неплохо. Единственная проблема заключается в том, что компания Microsoft не поставляет вместе с окончательной версией Exchange 2010 какую-либо графическую оболочку, которую можно было бы использовать для создания и применения тегов и политик хранения. Недостающий инструмент компания Microsoft обещает включить в пакет обновления 1 (SP1) для Exchange 2010. Бета-версия этого кода была опубликована на TechEd в июне 2010 года, а окончательная версия выйдет, как ожидается, чуть позже в этом году. А пока не выпущен SP1, для создания и применения тегов и политик хранения можно воспользоваться оболочкой PowerShell.
Хотя здесь команда переносится по строкам, в консоли PowerShell она набирается целиком в одну строку. То же самое правило действует и для других представленных здесь команд. Параметры -Name и -Type задают имя тега и контекст соответственно. В столбце «Возможные значения -Type» таблицы 1 перечисляются другие возможные значения для параметра -Type.
Параметр -RetentionAction определяет действие, которое нужно предпринять для элементов, период хранения которых закончился. В этом примере определено действие -MoveToDeletedItems, которое является для MFA командой для перемещения элемента в папку «Корзина». Другие действия, которые можно определить, перечислены ниже.
- MarkAsPastRetentionLimit. MFA помечает элемент как исчерпавший срок хранения, но не предпринимает никаких действий. Outlook отображает это состояние, зачеркивая данный элемент в списке.
- DeleteAndAllowRecovery. MFA перемещает элемент в папку «Корзина», однако пользователь может при желании восстановить данный элемент с помощью функции «Восстановить удаленные элементы».
- PermanentlyDelete. MFA незамедлительно удаляет элемент таким образом, что он уже не будет доступен для восстановления посредством функции «Восстановить удаленные элементы». Однако если почтовый ящик поставлен на сохранение или на юридическое удержание, элемент сохраняется и все еще будет доступен для поиска методом обнаружения.
- MoveToArchive. MFA перемещает элемент в папку с аналогичным именем в архивный почтовый ящик. Это возможно, только если у почтового ящика есть персональный архив. В противном случае MFA игнорирует действие. Действие MoveToArchive подобно функции «Автоархивация» Outlook, которая перемещает элементы в файл PST согласно расписанию, чтобы не допустить превышения квоты почтового ящика. Однако, в отличие от функции «Автоархивация», действие MoveToArchive не позволяет пользователям решать, хотят ли они использовать ту возможность. MFA автоматически перемещает элементы в персональный архив, не задавая лишних вопросов. Политики, которые служат для перемещения элементов в архивный почтовый ящик, известны как политики архивации.
Можно создать тег, который даст MFA команду никогда не обрабатывать элемент. При этом значение параметра -AgeLimitForRetention не задается, а параметру -RetentionEnabled присваивается значение $False. Если же значение параметра -AgeLimitForRetention задается, то параметру -RetentionEnabled всегда присваивается значение $True.
После создания тега можно проверить его свойства при помощи команды Get-RetentionPolicyTag. Например, чтобы проверить тег Manager-Inbox, нужно запустить команду:
С помощью команды New-RetentionPolicyTag можно создать остальные пять тегов, перечисленные в таблице 2. Не потребуется делать ничего отличного от описанного выше для создания личного тега (например, тега Manager-Retain) или DPT (например, тега Manager-General).
Дабы убедиться, что в наличии есть все теги, необходимые для создания политики хранения, нужно выполнить следующую команду:
Разработка политики хранения
В пределах организации может существовать множество тегов политики хранения, что обеспечивает большую гибкость при создании соответствующих политик хранения для различных групп, работающих в компании. Например, финансовому отделу может потребоваться, чтобы Exchange окончательно удалял из «Корзины» все элементы старше трех дней (так называемый «принцип шредера»), в то время как другим подразделениям будет безразлично, если элементы в этой папке хранятся 30 дней и более. Для сотрудников финансового отдела можно применить политику хранения, содержащую RPT, который дает указание MFA окончательно удалять из «Корзины» все элементы по прошествии трех дней. Та же политика может включать личный тег, который позволяет сотрудникам финансового отдела помечать элементы в их основном почтовом ящике, которые должны быть заархивированы через месяц для последующего возможного аудита. Во время обработки почтового ящика MFA переместит элементы с этим тегом в архивный почтовый ящик.
Прежде чем создавать политику хранения, нужно определить для нее следующие «почему» «когда» и «как».
- Почему реализуется эта политика? Какой потребности бизнеса она будет отвечать?
- Когда будет реализована эта политика? К каким почтовым ящикам она будет применена? Как донести эту политику до пользователей так, чтобы они поняли ее предназначение, и каким образом она повлияет на содержимое их почтовых ящиков?
- Как будет реализована политика? Какие потребуются теги? Какие действия будут производиться посредством использования тегов и какими будут периоды хранения? Существуют ли какие-нибудь ограничения на реализацию политики? Например, если для архивации используется программное обеспечение стороннего производителя, задействовать теги для перемещения элементов в архивный почтовый ящик по истечении обозначенного периода будет невозможно.
Таблица 2. Пример политики хранения |
Несмотря на то что можно создать и использовать множество политик, не на последнем месте стоит вопрос о возможности долгосрочной поддержки всего этого многообразия. Несколькими хорошо продуманными и логичными политиками, которые удовлетворяют большинству требований, будет гораздо легче управлять, нежели массой запутанных политик, которые созданы, чтобы удовлетворить определенные нужды конкретных подразделений или бизнес-групп. Существование большого числа политик может легко запутать как системных администраторов, так и пользователей.
Переход от управляемых папок
Управляемую папку можно модернизировать до тега хранения, используя ее как шаблон для нового тега. Это можно сделать при помощи параметра -ManagedFolderToUpgrade команды New-RetentionPolicyTag. Предположим, что у нас есть управляемая папка с именем «Никогда не удалять», которая служит хранилищем для элементов, которые пользователи никогда не захотят удалить из почтового ящика, поскольку они очень важны. Можно обсудить с ними вариант хранения подобных элементов в архивном почтовом ящике. Однако в Exchange 2007 еще не было архивных почтовых ящиков, а пользователям порой требуется значительное время, чтобы изменить свою точку зрения. Лучше всего будет создать новый тег хранения, основанный на управляемой папке «Никогда не удалять», посредством использования команды:
Как можно видеть, когда используется параметр ManagedFolderTo
Upgrade, нет необходимости указывать параметры -Type, -RetentionAction, -AgeLimitForRetention, и -RetentionEnabled. Эта информация будет автоматически получена от указанной управляемой папки.
Чтобы завершить процесс, нужно связать новый тег с политикой хранения и применить ее к почтовым ящикам пользователей. После того как это будет проделано, пользователи смогут применять новый тег к любому элементу в своих почтовых ящиках.
Миф о ESEUTIL
Временами создается впечатление, что некоторые специалисты наделили ESEUTIL мифическими способностями решать любые проблемы в базах данных Exchange. Более того, они рекомендуют регулярно запускать ESEUTIL для сжатия и исправления баз данных, чтобы обеспечивать их максимально возможную производительность. Это миф и заблуждение, от которых нужно как можно скорее избавиться. Я считаю, что применение ESEUTIL подобно «операции на головном мозге» базы данных Exchange, потому что, если ESEUTIL применяется неопытным администратором и без весомых для того оснований, это может превратить базу данных в бесформенную кучу неизвестно чего.
Было время, когда применение ESEUTIL к базе данных являлось единственным средством освободить пространство в подсистеме хранения и решить ее внутренние проблемы. Эти времена прошли в начале нынешнего десятилетия, когда Microsoft наконец нашла решение, как можно с помощью фонового обслуживания эффективно возвращать в повторное использование удаленные страницы. Однако многие из нынешних администраторов застряли в том далеком времени!
Базы данных, функционирующие в группе DAG, имеют значительное преимущество перед нереплицируемыми базами данных в том, что они сами могут исправлять единичные проблемные страницы, запрашивая корректные данные из другой копии базы данных. Запрошенные данные помещаются в поток журнала транзакций, а затем реплицируются процессом Store во все копии базы данных, устраняя проблему.
Кроме перечисленных мной случаев я не могу представить какое-либо разумное основание, зачем мне может потребоваться размонтировать базу данных и лишить на несколько часов пользователей доступа к ней для запуска ESEUTIL, чтобы достичь некоего малозаметного улучшения в базе данных, и то не наверняка. В производственной среде это точно не имеет никакого смысла.
Обслуживание баз данных — это часть жизни администраторов Exchange. Львиная доля этой работы автоматизирована и выполняется в фоновом режиме, но иногда должны производиться некие действия по требованию для решения проблем, возникающих на логическом или физическом уровне. Новые команды восстановления, реализованные в Exchange 2010 SP1, — долгожданное улучшение, так как они позволяют избавляться от логических повреждений по требованию без прекращения доступа к базам данных. Однако мы всем еще продолжаем держаться за утилиту ESEUTIL, которая наверняка должна стать следующей в списке Microsoft для модернизации и обновления.
Во время работы MS Exchange 2010 SP3 забирает под себя всю доступную оперативную память и если необходимо, отдает ее другим службам и приложениям. Зарезервированная оперативная память выделяется под создание кеша для дисковой подсистемы базы данных Exchange.
Таблица значений размеров кэша базы данных по умолчанию для Exchange 2010 (Exchange 2010 Limiting Database Cache)
Физическая память на сервере (ОЗУ) | Размер кэша базы данных (только Mailbox) | Размер кэша базы данных (с несколькими ролями) |
2GB | 512 MB | Not Supported |
4GB | 1 GB | Not Supported |
8GB | 3.6 GB | 2 GB |
16GB | 10.4 GB | 8 GB |
24GB | 17.6 GB | 14 GB |
32GB | 24.4 GB | 20 GB |
48GB | 39.2 GB | 32 GB |
64GB | 53.6 GB | 44 GB |
96GB | 82.4 GB | 68 GB |
128GB | 112.2 GB | 92 GB |
Иногда случается так что Exchange перестает следовать этой таблице и правилом отдачи оперативной памяти под нужны системы или других приложений. Это приводит с снижению производительности системы, самого Exchange сервера и полному зависанию.
Данную ситуацию можно решить, путем ограничения размера выделяемой оперативной памяти для Exchange. К примеру необходимо ограничить кеш базы данных до 8 Gb, то сперва нужно рассчитать значение для параметра msExchESEparamCacheSizeMax (8 Gb переводим в килобайты = 8 388 608 Kb делим на 32 Kb = 262144)
Имея точное значение для параметра msExchESEparamCacheSizeMax, запускаем оснастку ADSIEdit.msc и подключаемся к контексту Конфигурация:
Переходим в Конфигурация — Configuration — Services — Microsoft Exchange — FIrst Organization — Administrative Groups — Exchange Administrative Group (FYDIBOHF23SPDLT) — Servers — [Имя сервера] — InformationStore.
Правой кнопкой мыши на InformationStore и редактируем параметр msExchESEParamCacheSizeMax. Установите рассчитанное ранее значение (262144).
Перезапускаем сервис Microsoft Exchange Information Store, чтобы изменения вступили в силу.
Теперь MS Exchange 2010 будет резервировать оперативной памяти ровно столько, сколько мы указали ему.
На днях столкнулся с тем, что мой Outlook 2010 показал мне «кулак дружбы» («кулаком дружбы»-автомобилисты называли у нас в институте поршень который торчал из блока цилиндров, разорвав его где-нибудь посередине), в общем перестали создаваться правила Outlook…
Все никак не хватало времени посмотреть, но сегодня нашел пару минут…
Одно или несколько правил не удалось передать на сервер Exchange и они были отключены. Возможно, некоторые параметры не поддерживаются или не хватает места для хранения всех ваших правил.
В английской версии Outlook ошибка выглядит так:
One or more rules could not be uploaded to Exchange server and have been deactivated. This could be because some of the parameters are not supported or there is insufficient space to store all your rules.
- Exchange 2003 – под правила отводится 32 Кб (этого в среднем хватает на хранение 20 – 25 правил)
- Exchange 2007/ Exchange 2010/ Exchange 2013 – под правила отводится 64 Кб
В Exchange 2003 ограничение на максимальный размер правил является фиксированным и изменить его нельзя. В более новых версиях Exchange объем памяти под хранение правил можно увеличить до 256 Кб. Лимит правил устанавливается индивидуально для каждого пользователя через специальный атрибут RulesQuota.
Текущий размер квоты правил Exchange для конкретного пользователя можно узнать с помощью следующей команды, выполненной в Exchange Management Console:
Чтобы увеличить память для ящика:
Если нужно увеличить лимит под правила сразу для всех ящиков, вам поможет команда:
В том случае, если и этого места для хранения правил будет недостаточно, пользователю рекомендуется прибегнуть к следующим манипуляциям:
- Удалить ненужные правила
- Объединить правила (например, перемещающие письма в одну и ту же папку)
- Уменьшить названия правил
- Если одно из правил перемещает письма в файл личных папок .pst, необходимо переместить архив в каталог с более коротким путем. Например, из папки C:\Documents and Settings\winitpro\Local Settings\Application Data\Microsoft\Outlook\mymail2013.pst в папку C:\mail\mymail2013.pst
Проблема решена. Всем хорошей работы .
О сайте
Записки из мира IT…
В этом блоге, я пишу заметки о своей, как повседневной жизни, так и жизни и работе в сфере IT технологий. Собираю интересные ссылки, выражаю свои мысли и прочее… В основном посты посвящены, Управленческим моментам и решениям, различным продуктам Microsoft и VMWare, которые я эксплуатирую многие годы, Nix, MacOS, сетке, и другим интересным вопросам и задачам, с которыми приходится ежедневно сталкиваться и иметь дело. Здесь приведены не только мои посты, но и посты, которые были найдены мною на безграничных просторах интернета. Все написанное здесь, было проделано мною или моими коллегами при моем непосредственном участии на виртуальных машинах или в продакшин среде, о чем свидетельствуют комментарии в текстах. Всем удачи в работе.
Пилоты говорят: «Топлива не бывает слишком много, если только не пожар». Возможен ли переизбыток оперативной памяти, когда речь идет о Microsoft Exchange Sever?
Сколько же оперативной памяти Exchange Server может эффективно использовать?
- По 1 Гбайт на каждое ядро процессора для серверов с ролями пограничного транспортного сервера и центрального транспортного сервера.
- По 2 Гбайт на ядро для системы унифицированных коммуникаций и серверов клиентского доступа.
- Для серверов почтовых ящиков 4 Гбайт плюс от 3 до 30 Мбайт на каждый ящик (иногда от 7 до 34 Гбайт для серверов с поддержкой более 1000 ящиков).
- По 2 Гбайт на ядро для серверов, которые совмещают роли центрального транспортного сервера с серверами клиентского доступа.
- Для серверов, совмещающих роли сервера почтовых ящиков с другими ролями, минимум 8 Гбайт (4 Гбайт плюс 3–30 Мбайт на каждый почтовый ящик).
На первый взгляд кажется, что нет. Хотя движок хранилища ESE использует больше памяти, если доступно, результаты тестирования Microsoft показывают, что производительность не возрастает при добавлении большего объема памяти, чем рекомендовано для вашего уровня загрузки. Учитывая, что оперативная память достаточно дешевая, увеличение ее объема не повредит производительности системы, но и не увеличит ее.
С другой стороны, установив более чем достаточный объем оперативной памяти, вы получаете возможность виртуализации Exchange, что позволяет более эффективно использовать имеющиеся аппаратные ресурсы. Рассмотрим 12-ядерный сервер с 72 Гбайт оперативной памяти, это довольно хороший сервер по современным меркам, и он не самый мощный. Этот сервер окажется мощнее, чем вам нужно для 2000 ящиков, поэтому правильнее запустить две виртуальные машины с четырьмя ядрами и 32 Гбайт оперативной памяти. Такая архитектура предполагает, что вам необходимо работать с более чем 2000 ящиков. При меньших размерах почтовой системы добавление оперативной памяти будет бесполезным, поэтому лучше использовать бюджет в других направлениях развития вашей почтовой системы.
Что касается ядер процессора, то это другая тема. Бытует мнение, что ядер много не бывает, но это не касается Exchange, а почему — я объясню в одной из следующих статей.
Необходимость в обслуживании
Некоторые специалисты утверждают, что правильно спроектированное приложение для работы с базами данных должно быть самообслуживаемым. Однако эта цель пока еще не достигнута в реальных приложениях, в том числе в Exchange. Обслуживание необходимо для оптимизации внутренних структур баз данных, удаления устаревших данных и применения политик управления. Большая часть этой работы производится в фоновом режиме, как часть непрерывного обслуживания, осуществляемого процессом Exchange Information Store, а помощник для управляемых папок Managed Folder Assistant отвечает за применение правил политик сохранения (retention policies) к почтовым ящикам, которые подпадают под действие этих политик.
Будьте готовы к большему
Тема политик хранения Exchange 2010 слишком обширна, чтобы раскрыть ее за один раз. О том, как изменять и удалять политики хранения, а также как помочь пользователям понять их, я расскажу в следующих статьях.
Share this:
Применение политики хранения
Для применения политики хранения к почтовым ящикам используется команда Set-Mailbox. Почтовый ящик может иметь только одну политику хранения, поэтому, назначая ему новую политику, мы тем самым перезаписываем любую другую действующую в его отношении политику. Новая политика будет применена к почтовому ящику во время следующего запуска MFA.
Команда для применения политики хранения может выглядеть следующим образом:
Exchange предупредит вас, что клиенты старше Outlook 2007 не поддерживают политики хранения. Ни один клиент до Outlook 2010 и OWA 2010 не имеет пользовательского интерфейса, необходимого для отображения информации о политике хранения и изменения тегов хранения на элементах или папках.
Если политика устанавливается для группы пользователей, то сделать это можно одной командой, выбрав почтовые ящики с помощью команды Get-Mailbox и передав результаты командой Set-Mailbox, как показано ниже:
Делать это будет намного легче в Exchange 2010 с пакетом обновления SP1, когда станет доступен графический интерфейс. Появится возможность выбрать группу почтовых ящиков и применить к ним политику хранения, используя консоль управления Exchange (EMC). С помощью EMC также можно будет применить политику хранения к отдельному почтовому ящику.
Чтобы обнаружить почтовые ящики, к которым применены политики хранения, можно использовать следующую команду:
После начала развертывания политик хранения необходимо продумать, как интегрировать назначение политик хранения почтовым ящикам с общим процессом настройки учетных записей пользователей компании. У Exchange нет политики хранения по умолчанию, которая может быть присвоена автоматически, поэтому администратору придется самостоятельно выполнить определенное действие, чтобы присвоить политику хранения почтовому ящику. Как было показано выше, эту задачу несложно выполнить при помощи PowerShell, однако она должна решаться в рамках единого плана развертывания.
Обслуживание по требованию
При условии что все автоматическое обслуживание выполняется в фоновом режиме, у администраторов становится меньше оснований вмешиваться в работу серверов Exchange 2010 для выполнения обслуживания по требованию. Однако мы пока еще живем не в идеальном мире, и администраторы должны уметь распознавать два основных типа повреждений баз данных: логические и физические.
Логические ошибки проявляются в таких проблемах, как неверное количество элементов в папке или неправильное их представление, которое не включает все нужные элементы. Логические ошибки часто возникают в результате сбоев на стороне клиента, когда клиент при обработке элементов в папке некорректно обновляет флаги MAPI. Такие проблемы обычно терпимы в том смысле, что вы можете нормально работать, даже если в папке или почтовом ящике есть ошибки. Некоторые пользователи вообще не замечают таких ошибок. Ведь если Outlook выдает информацию, что в папке имеется 1119 элементов, будет ли у кого-нибудь время сосчитать все элементы и убедиться, что Outlook верно отобразил их количество, предоставленное ему сервером Exchange?
Физические ошибки намного хуже по причине влияния на нормальную работу сервера Exchange, так как они могут сделать базу данных недоступной для пользователей. В прошлом физические ошибки или повреждения могли быть вызваны недоработками в программном обеспечении или аппаратными сбоями. Сегодня подавляющее большинство физических ошибок обусловлены аппаратными сбоями, такими как неполадки в дисковом контроллере при попытке записать обновленную страницу в базу данных. Физические повреждения приводят к потере данных, если страницы, содержащие индексы и контент почтовых ящиков, не могут быть исправлены.
В предыдущих версиях Exchange обслуживание по требованию осуществлялось с помощью двух утилит командной строки, входящих в набор инструментов Exchange. ISINTEG (Information Store Integrity, утилита поддержания целостности хранилища информации) исправляла логические ошибки, ESEUTIL (или даже EDBUTIL, если вы помните такое давнее название) боролась с проблемами на физическом уровне, в недрах базы данных. Эти утилиты — напоминание о тех днях, когда было допустимо отключить базы данных на несколько часов для выполнения обслуживания. По этой причине утилиты были проклятием для администраторов. Принимая во внимание размеры нынешних почтовых баз данных, их обработка может длиться много часов, а это ставит под угрозу возможность соответствия соглашениям об уровне обслуживания (SLA) и другим эксплуатационным требованиям.
Понравилось это:
Sorry, the comment form is closed at this time.
Новый подход к исправлению логических ошибок
ISINTEG не используется в Exchange 2010, так как Microsoft не стала обновлять эту утилиту для поддержки новой схемы базы данных. Перенос внимания в схеме базы данных с таблиц, работающих со всей базой данных, на таблицы для отдельных почтовых ящиков означает, что теперь весьма редки логические проблемы, влияющие на базу данных, и, если вы обнаружите проблему в почтовом ящике, простого перемещения почтового ящика из одной базы данных в другую может быть достаточно для устранения проблем с такими структурами, как именованные свойства, представления и списки элементов. Причина, по которой перемещение почтового ящика решает подобные проблемы, заключается в том, что операция перемещения пересоздает ящик заново в целевой базе данных и при этом ликвидирует многие логические ошибки.
В Exchange 2010 SP1 специалисты Microsoft вместо утилиты ISINTEG предложили новый набор команд для исправления баз данных почтовых ящиков и общих папок, с помощью которых администраторы могут создавать запросы на восстановление, способные устранить большинство причин сбоев в представлениях и отображении количества элементов. Это следующие виды повреждений:
- сбои в поиске папок (почтовый ящик);
- неверное общее количество элементов в папках (почтовый ящик);
- неверное содержимое, отображаемое представлениями папок (почтовый ящик);
- состояние репликации общих папок;
- контроль представлений общих папок;
- физическое повреждение общих папок.
Данные команды восстановления используют примерно такую же модель, как и запросы на перемещение, импорт и экспорт почтовых ящиков в Exchange 2010, где администратор создает запрос на восстановление, который помещается в очередь для обработки процессом Store, а тот в свою очередь асинхронно в режиме онлайн исполняет запрошенные восстановительные действия для баз данных. У пользователя нет необходимости завершать сеанс работы со своим почтовым ящиком в то время, пока Store проверяет и исправляет внутреннюю структуру почтового ящика. В Exchange 2010 SP1 отсутствуют какие-либо средства графического интерфейса для выполнения запросов на восстановление в консоли управления Exchange Management Console (EMC) или панели управления Exchange Control Panel (ECP), все действия должны выполняться с помощью команд консоли Exchange Management Shell (EMS). Вы также не сможете выполнять запросы на восстановление почтовых ящиков или общих папок на предыдущих версиях серверов Exchange, так как данная возможность зависит от обновлений схемы Active Directory, внесенных установкой Exchange 2010 SP1.
Команда New-MailboxRepairRequest создает запрос на восстановление почтового ящика, а команда New-PublicFolder DatabaseRepairRequest — запрос на восстановление базы данных общих папок. Например, следующая команда создает запрос для проверки корректности представления папки:
Если вы добавите к запросу параметр -DetectOnly, Exchange сообщит обо всех найденных повреждениях, но не будет их устранять. Существуют и другие типы повреждений почтовых ящиков, которые могут быть исправлены: SearchFolder, AggregateCounts и ProvisionedFolder. Они служат для исправления повреждений папок поиска, количества элементов в папках и подготовленных папок (provisioned folders).
Вы можете выполнить несколько исправлений за один проход почтового ящика с помощью задания списка соответствующих параметров. Например:
Параметр Archive определяет, нужно ли процессу Store сканировать личный архив почтового ящика. Если параметр отсутствует, то архив не обрабатывается, то есть для исправления архива нужна несколько модифицированная команда:
Для баз данных общих папок сегодня можно выполнить только один вид исправлений. Это исправление списка реплик, которое делается следующим образом:
Когда вы отправляете новый запрос на восстановление почтового ящика или общей папки, Exchange посылает в ответ идентификатор задачи и имя сервера, который будет обрабатывать запрос, как показано на экране 2. Это сервер почтовых ящиков, хранящий активную копию базы данных, или сервер, на котором смонтирована база данных общих папок.
Экран 2. Запрос на восстановление почтового ящика |
Чтобы не оказывать сильного влияния на производительность системы, вы можете выполнить только один запрос на восстановление всей базы данных. Однако на сервере можно выполнять одновременно до 100 запросов на восстановление отдельных почтовых ящиков (распределенных по нескольким базам данных).
Если база данных имеет копии внутри группы DAG, то результаты любых действий по решению проблем, обнаруженных в таблицах почтового ящика, реплицируются вместе с остальными транзакциями на все копии базы данных, а события в журнале приложений регистрируются на том сервере, на котором осуществлялось исправление. То же самое происходит и при исправлениях баз данных общих папок, за исключением того, что исправление осуществляется в одной базе данных общих папок, а результаты реплицируются с помощью механизма репликации общих папок.
Вы не можете отменить задание на восстановление или просмотреть его текущий статус. Возможно, такая функциональность будет добавлена корпорацией Microsoft в каком-либо будущем выпуске. На сегодня единственный способ прервать процесс восстановления — размонтировать базу данных или переместить ее на другой сервер. Такие действия удаляют все задания на восстановление, активные для этой базы данных.
Новый подход
Теперь вместо управляемых папок система MRM сервера Exchange 2010 использует теги и политики хранения. Управляемые папки присутствуют и в Exchange 2010, но только для обеспечения обратной совместимости.
Теги хранения. Exchange 2010 поддерживает три типа тегов хранения: теги политики хранения retention policy tags (RPT), теги политики по умолчанию default policy tags (DPT) и личные теги. В таблице 1 описаны эти типы тегов.
Таблица 1. Типы тегов хранения |
Теги хранения могут быть применены к любому элементу в любой папке. Они определяют, какое действие должен предпринять Exchange по отношению к тому или иному элементу, когда его период хранения истекает. Возможные действия включают в себя полное (окончательное) или программное (с возможностью восстановления) удаление элементов, перемещение элементов в персональный архив или установку на них флага для привлечения внимания пользователя. Теги хранения могут применяться к элементам почтовых ящиков, беседам или целым папкам. Они перемещаются вместе с элементами, если те перемещаются между папками.
Политики хранения. Политики хранения группируют теги хранения таким образом, чтобы администраторы имели возможность применять политики к почтовым ящикам, вместо того, чтобы назначать папкам отдельные теги хранения. Теги и политики хранения — объекты, действительные для всей организации. Они хранятся в AD и после создания могут быть применены к любому почтовому ящику в организации. MFA по-прежнему отвечает за проверку содержимого почтовых ящиков на предмет соответствия политикам и предпринимает указанные действия по отношению к тем элементам, период хранения которых истек.
Политики и теги хранения подчиняются двум простым принципам. Во-первых, Exchange может применить к почтовому ящику только одну политику хранения. Если применить к почтовому ящику вторую политику хранения, Exchange просто перезапишет старую политику новой. Во-вторых, Exchange может применить только один тег хранения к элементу. Если с элементом связано более одного тега хранения, Exchange руководствуется двумя правилами, чтобы определить, какой из тегов будет применяться.
- Тег хранения с самым долгим периодом хранения всегда имеет приоритет. Это правило гарантирует, что Exchange никогда не удалит элемент, прежде чем время его хранения действительно истечет.
- Тег хранения, примененный непосредственно к какому-либо элементу (или ко всем элементам в папке), имеет приоритет перед тегом, который элемент наследует через политику хранения по умолчанию. Например, если элементу назначен личный тег, определяющий, что этот элемент должен храниться в течение 6 лет, но политика хранения по умолчанию для папки требует его удаления через 12 месяцев, то этот элемент будет храниться в течение 6 лет.
Чтобы использовать Exchange 2010 MRM, необходимо развернуть клиенты, которые имеют соответствующие интеллектуальные возможности и интерфейс пользователя. На момент написания этой статьи единственными клиентами в данной категории были Outlook 2010 и Outlook Web App (OWA). Пользовательский интерфейс Outlook 2010 обеспечивает богатейший набор представлений для политик и тегов хранения. OWA не столь совершенен в этом отношении, но тем не менее весьма удобен.
Читайте также: