Как держать данные Exchange под контролем

Эффективно управлять данными Microsoft Exchange Server — непростая работа. Задача поддержания баланса между запросами пользователей и стабильностью и производительностью работы сервера Exchange всегда входила в обязанности администратора системы. Но со временем электронная почта превратилась в жизненно важное для бизнеса приложение, и действующие распорядительные документы ставят администраторов в трудное положение, буквально между Сциллой и Харибдой.

Чтобы держать под контролем данные Exchange, требуется комплексный подход, в котором будут сочетаться ясно описанные политики и подходящие для конкретной ситуации технологии (оборудование для хранения данных, утилиты мониторинга и оставления отчетов, приложения управления данными). С чего же начать?

Сначала хочу пояснить, что я подразумеваю под словами «эффективное управление данными». Я понимаю это как некую практику безопасного манипулирования хранящимися в Exchange данными, до известной степени оптимизирующую хранение данных и обеспечивающую адекватный доступ к ним. Следовательно, правильнее всего начать с изучения финансовых, технических и распорядительных ограничений, принятых в организации. Эти факторы повлияют на то, как будет осуществляться управление данными в группах хранения (SG), базах данных и почтовых ящиках пользователей (включая автономные хранилища — OST и персональные хранилища — PST) при соблюдении требований, предъявляемых к резервированию, восстановлению и архивированию данных.

Ограничения

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

Финансовые ограничения. По мере того как трафик почтовых сообщений растет (с точки зрения объема и размера) и все чаще принимаются решения о хранении сообщений в базах данных Exchange в оперативном состоянии или постоянно проверяемых автономных хранилищах, требования к хранилищам данных, а следовательно, и к их стоимости растут. Финансовые ограничения — это не просто затраты на дополнительные диски для поддержания более крупных баз данных. Придется платить за необходимую инфраструктуру хранения (дополнительные дисковые массивы, ленточные устройства, Storage Area Network — SAN) и технический персонал, обслуживающий возросший объем данных. Эти затраты разнятся в зависимости от размера и профиля организации. Предприятия малого бизнеса с несколькими сотнями пользователей, скорее всего, ограничатся увеличением объема хранилища, но более крупные организации с несколькими тысячами пользователей могут быть вовлечены в существенные траты.

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

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

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

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

Итак, какие ограничения применяются в организации, известно. Теперь можно приступать к разработке руководящих принципов, в соответствии с которыми данные будут размещаться в файлах баз данных Exchange, в кэш-файлах Microsoft Outlook (т. е. в OST-файлах) и PST-файлах. Одновременно с этим выбираются наиболее полно удовлетворяющие специфике конкретной вычислительной среды решения резервирования, восстановления и архивирования.

Работа с данными на сервере

Exchange хранит почтовые данные в базах данных на одном или нескольких серверах Exchange. Эти базы данных, вероятно, следует считать наилучшим местом хранения почтового контента, и не в последнюю очередь из-за наличия в каждой базе единого механизма хранения (хотя между разными базами единый механизм хранения отсутствует). В общем случае данные на сервере более доступны, чем данные в файлах PST, хотя бы с позиции обслуживания. Информацию общего пользования лучше всего размещать в общих папках баз данных Exchange. На сервере Exchange Server 2003 или на станции Exchange 2000 Server может содержаться до четырех групп хранения (SG) и в пределах одной группы может быть до пяти баз данных; получается, что один сервер может содержать до 20 баз данных. Как показывает практика, размер базы данных не должен превышать 40 Гбайт, чтобы процедура резервирования и, что более важно, восстановления укладывалась в отведенное время.

Именно возможности хранения определяют максимальное число активных пользователей, которых в состоянии обслужить одна система Exchange. Подсистемы хранения Exchange должны справляться с загрузкой каналов ввода/вывода, инициируемой пользователями. В руководстве Microsoft «Optimizing Storage for Exchange 2003» приводятся рекомендации по созданию подсистемы, которая может обеспечить средний показатель примерно 0,75 операций ввода/вывода в секунду на одного активного пользователя. Для большинства подсистем хранения — и это справедливо даже для мощных платформ SAN — в данном руководстве называется цифра не более 4000 активных пользователей на один сервер.

Следует придерживаться определенного баланса при соблюдении рекомендаций относительно размера базы данных и ограничений числа пользователей, а также учитывать другие факторы, влияющие на производительность системы (например, размер файлов — журналов транзакций) при модернизации серверов, размещении систем хранения и установке ограничений на почтовые ящики пользователей. На экране представлена типичная таблица, которую я использую при расчете требований, предъявляемых к системе хранения. Например, для сервера, на котором размещено около 4000 почтовых ящиков, соответствующая дисковая квота устанавливается равной 200 Мбайт.

Помимо использования почтовых квот (которые можно наложить на базу в целом или на отдельного пользователя), для управления данными, размещенными на сервере Exchange, можно задействовать Group Policy для настройки Exchange Mailbox Manager в целях обнаружения и удаления старых или очень больших сообщений из почтовых ящиков пользователей. Такой подход позволяет контролировать размеры почтовых ящиков и не доводить до появления сообщения о превышении квоты — mailbox quota exceeded. Если вы опасаетесь удалить случайно что-то важное, функция Deleted Items Recovery (если она включена) даст пользователям возможность восстановить сообщения даже после того, как папка Deleted Items окажется пустой. Этот мощный инструмент администратора поможет бороться с ошибками пользователей. Если бы его не было, пришлось бы прибегнуть к дорогостоящим операциям восстановления. Однако нужно соблюдать осторожность — активизация функции Deleted Items Recovery может привести к чрезмерному разрастанию баз данных. По своему опыту могу сказать, что удержание удаленных сообщений в течение всего лишь семи дней может вызвать рост базы данных на 10-30%.

Управление данными пользователя

Данные, которые пользователи хранят в файлах OST и PST на своем рабочем месте — в настольной системе или ноутбуке, являются наиболее сложными данными Exchange с точки зрения обслуживания, поскольку это распределенные данные, зачастую недоступные (с позиции администратора Exchange). С файлами OST хлопот меньше, поскольку это просто копия содержимого почтового ящика сервера Exchange. При использовании режима Microsoft Office Outlook 2003 Cached Exchange Mode файл OST — полная репликация оперативного почтового ящика Exchange; при использовании других режимов работы Microsoft Office Outlook 2003 (или при работе с более ранними версиями Outlook) локальный файл OST содержит некоторое подмножество данных серверного почтового ящика.

С PST все иначе. Квотирование размера почтового ящика на сервере часто заставляет пользователей сохранять важные для них данные в файлах PST, при этом размер файлов становится огромным (несколько сотен мегабайтов или больше) и — при локальном хранении — они, как правило, обходятся процедурами резервирования локальных жестких дисков, если резервирование используется вообще. Нередко пользователи размещают файлы PST на сетевых дисках, что, естественно, лучше, чем держать их у себя. Но хотя задача резервирования в этом случае упрощается, неконтролируемый рост размера PST-файлов по-прежнему не дает администраторам покоя. По мере увеличения размера PST растет вероятность его разрушения без возможности восстановления. В действительности получается, что по сравнению с хранением на локальном диске у сетевого хранения PST-файлов оказывается совсем немного преимуществ. Более того, данные в PST, по сути, не защищены. Можно зашифровать файлы PST, но утилиты дешифрации хорошо известны и доступны. Если пользователь хранит конфиденциальные корпоративные данные в PST, скажем, на ноутбуке, он рискует этими данными в том случае, если ноутбук будет потерян или украден. Даже данные PST, хранящиеся на сетевых дисках, необходимо должным образом защищать от несанкционированного доступа. К тому же надо помнить, что при наличии узаконенных требований по процедурам архивирования и продолжительности использования данных необслуживаемые файлы PST могут создавать массу проблем.

Резервирование и восстановление

Выбор решений для выполнения резервирования и, что еще важнее, для восстановления данных будет зависеть от объема данных, которые предстоит обработать, и от скорости обработки. Для данных, размещенных на сервере, многие крупные компании реализуют процедуры, которые позволяют восстанавливать базы данных в течение часа (параметры соглашения об уровне обслуживания — Service Level Agreements, SLA — в каждом конкретном случае могут несколько отличаться). Например, чтобы в течение часа выполнить восстановление базы данных размером 40 Гбайт, размещенной на сервере, ленточное устройство должно обеспечивать скорость восстановления (не путать со скоростью резервирования) не менее 10 Мбайт/с. Многие решения резервирования теперь используют промежуточную запись данных на диск перед тем, как записывать данные на ленту, поэтому начальная скорость резервирования (т. е. скорость передачи данных на диск) и скорость восстановления часто существенно выше, чем при использовании традиционного подхода при участии только ленточных накопителей.

Решения на базе SAN нередко обеспечивают высокую скорость передачи данных при восстановлении с ленты; цифры в диапазоне от 100 до 140 Гбайт в час уже не являются чем-то из ряда вон выходящим. Такая производительность может повлиять на допустимые размеры баз данных, которые назначает администратор. Возможность резервировать и восстанавливать большие объемы данных за более короткое время означает, что можно создавать более крупные базы данных, и это влечет за собой или возможность увеличения квот на почтовые ящики, или подключение к серверу большего числа пользователей.

Windows Server 2003 обеспечивает поддержку Volume Shadow Copy Services (VSS), благодаря чему Exchange 2003 в любой момент может предоставить непротиворечивую копию — снимок (snapshot) базы данных в течение нескольких секунд. Следует понимать, что это всего лишь моментальный снимок диска, где размещен файл базы данных, и если физические тома, на которых размещается база данных, недоступны, использовать снимок бесполезно (хотя многие вендоры постоянно предпринимают попытки решить эту проблему). Следовательно, даже с учетом того обстоятельства, что снимки баз данных могут быть получены за несколько секунд, снимок тома по-прежнему приходится копировать на магнитный носитель (обычно это лента). Тем не менее «отснятые» тома могут быть восстановлены в течение секунд. Подсистемы хранения и решения резервирования/восстановления, поддерживающие технологию VSS, в состоянии радикальным образом повлиять на всю архитектуру управления данными, однако следует самым тщательным образом исследовать и протестировать возможности использования VSS, прежде чем внедрять эту технологию в реальный бизнес.

Exchange 2003 (особенно при развертывании Service Pack 1, SP1) предлагает новую функциональность в форме Recovery Storage Group (RSG). Назначение новой функции очевидно: если после сбоя база данных в некоторой группе хранения становится недоступной и предстоит выполнить восстановление данных из резервной копии, для пользователей, на работу которых повлиял этот сбой, на время восстановления утраченных данных заводится пустая аварийная база (recovery database). Хотя ни одно из существующих сообщений пользователей в течение всего времени восстановления не будет доступно, по крайней мере обеспечивается отправка и получение электронной почты. После завершения восстановления содержимое аварийной базы данных можно объединить с данными восстановленной базы. При правильной организации работ и грамотно составленном плане на случай возникновения аварийных ситуаций концепция RSG может положительно сказаться на соблюдении требований SLA, а появившийся в SP1 мастер Recover Mailbox Data Wizard упрощает задачу объединения восстановленных и вновь созданных данных.

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

Все об архивировании

Строго говоря, решения архивирования отличаются от решений, подчиняющихся определенным распорядительным документам, и проявляется это в следующем.

  • Архивирование часто инициируется самим пользователем - пользователь по своему усмотрению решает, когда нужно выполнить архивирование объекта в своем почтовом ящике Exchange и скопировать данные в хранилище.
  • Момент архивирования часто задается соответствующей политикой, в которой установлены параметры устаревания информации.
  • Решения архивирования обычно не гарантируют, что все сообщения, созданные или отправленные в системе либо циркулирующие в ней, будут записаны в хранилище.

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

Более продуманные решения, например KVS Enterprise Vault от компании VERITAS Software, предлагают систему архивирования, инициируемую как самим пользователем, так и на базе политик архивации, причем данные перемещаются на устройства хранения второго (или более высокого) уровня хранения. Подобные решения весьма эффективны, поскольку они могут оставлять специальные заглушки для сообщения (message stub) в почтовом ящике пользователя Exchange, пока происходит перемещение вложений или содержимого сообщения в хранилище. Если пользователь хочет просмотреть содержимое архива, обычно бывает достаточно простого щелчка мышкой по заглушке, после чего заархивированное сообщение извлекается. Таким образом, оптимизируется использование собственного хранилища Exchange — огромные объемы данных выгружаются в систему, обеспеченную запоминающими устройствами большой емкости и более пригодную для долговременного хранения информации.

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

Примерами более развитых технологий могут служить EMC Centera и Reference Information Storage System (RISS) компании HP. Они позволяют хранить статический контент в неизменяемом формате — на диске и на RAID-массивах, гарантировать целостность данных и их аутентичность благодаря цифровым подписям и отметке о времени работы с данными. Как правило, в таких решениях реализованы системы иерархического хранения Hierarchical Storage Management (HSM), что дополнительно дает преимущества индексации контента и быстрого поиска. Если организация соблюдает требования распорядительных документов, использование HSM становится очень важным, поскольку огромные массивы данных электронной почты могут быть очень быстро смонтированы, и чем крупнее организация, тем важнее этот фактор. Предположим, что в среднем один пользователь отправляет в день около 20 писем, каждое размером 25 Кбайт. Исходя из этих оценок получается, что в организации, насчитывающей 10 тыс. пользователей, в день отправляется порядка 200 тыс. сообщений — 4,7 Гбайт в день или 1,7 Тбайт в год. Если нужно архивировать и входящую корреспонденцию, требования к подсистеме хранения существенно возрастают. Конечно, эти расчеты — усредненные, но мне известна компания, где работает 9400 человек, которые ежемесячно получают от 120 до 150 Гбайт почтовых сообщений.

Многие организации развертывают решения архивирования в качестве самого первого шага при миграции с одной версии Exchange на другую или при изменении всей почтовой организации. Такой подход позволяет ускорить миграцию и сократить объем данных, задействованный при ее проведении.

Заключение

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

Киран Маккорри - Главный консультант подразделения HP Advanced Technology Group в Ирландии. kieran. mccorry@hp.com

Комплексное управление данными Exchange

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

  • Одна и та же инфраструктура хранения часто используется несколькими приложениями, поэтому подсистема хранения Exchange и платформа, на которой она работает, может оказать влияние на все мероприятия, связанные с политикой компании в области управления данными.
  • Соглашения об уровне сервисного обслуживания, Service Level Agreements (SLAs), относящиеся к вопросам хранения данных в Exchange, тесно связаны со всем бизнесом компании.
  • Хранение данных в Exchange неотрывно связано с вопросами архивирования информации и следования техническим требованиям - вопросами, которые решаются на уровне компании в целом.
  • Все инициативы, касающиеся управления данными Exchange, в конечном счете являются производными бизнеса компании и факторов ее развития

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

Формальные рекомендации, которые могут помочь при написании внутренних процедур компании для повышения качества сервисного обслуживания подразделений IT, включены в рекомендации ITIL. Рекомендации ITIL — часть общей инициативы IT Service Management Forum (itSMF); зачастую в компаниях стараются следовать этим рекомендациям с учетом требований стандарта BS15000. Полное описание инициативы itSMF и ее положений, относящихся к управлению данными Exchange, выходит за рамки данной статьи. Но будет вполне достаточно для любой организации, стремящейся двигаться по пути сертификации itSMF, реализовать политики и процедуры, способствующие эффективному управлению данными. Узнать подробнее об ITIL можно по адресу http://www.ogc.gov.uk/index.asp?id=2261.

Управление данными: статистика

Возрастанию роли решений управления данными Exchange Server способствуют четыре фактора: все более активное использование электронной почты, увеличение числа форматов и размера документов, доступность недорогих устройств хранения и следование корпоративным и другим регулирующим документам при использовании электронной почты.

Более активное использование электронной почты. По данным IDC, количество людей во всем мире, которые будут использовать электронную почту, возрастет с 452 млн. в 2000 году до 1,2 млрд. в 2005-м. Также был предсказан рост почтового трафика с 9,7 млрд. сообщений в среднем в день в 2000 году до 35 млрд. в 2005-м. Принимая во внимание приведенные цифры, рост требований к устройствам хранения и управлению данными выглядит вполне обоснованным.

Увеличение числа форматов и размера пересылаемых документов. За последние годы документы, особенно подготавливаемые в приложениях Microsoft Office, значительно увеличились в размерах. Рост количества типов документов, используемых как вложения, также нужно принимать в расчет при оценке требований, предъявляемых к устройствам хранения. Типичный файл Microsoft PowerPoint может оказаться в 1000 раз больше, чем средних размеров электронное письмо на основе текстового сообщения. С файлами Microsoft Word картина похожая (хотя и не такая, как с PowerPoint). Для сохранения, скажем, 1000 почтовых сообщений в Exchange сегодня потребуется значительно больше места на устройстве хранения, чем несколько лет тому назад. В течение последних нескольких лет обычно происходил рост размера почтовых ящиков на сервере — для хранения в почтовых ящиках пользователей файлов сложных форматов теперь требуется куда больше места, чем для хранения простых текстовых сообщений. В отчете исследовательской группы Radicati Group сказано, что размер простого текстового сообщения увеличился за период с 2003 до 2004 года более чем в два раза. При этом размер усредненного сообщения составил 38,1 Кбайт и 469,2 Кбайт (без вложений и с вложениями соответственно); размер вложений ежегодно возрастал примерно на 30%.

Доступность недорогих устройств хранения. Еще один фактор, способствующий усилению роли управления данными, — абсолютная доступность на рынке недорогих устройств хранения. Во многих подсистемах ввода/вывода Exchange используется максимально возможное число дисковых накопителей и найдется немного развернутых систем Exchange, где не могут позволить себе такую роскошь. По мере того как емкость дисковых накопителей возрастала, появлялся приятный побочный эффект — на диске становилось все больше свободного места за более низкую цену. В докладе Harrow Technology Report, составленном Harrow Group, говорится, что 20 лет назад дисковый накопитель емкостью 20 Мбайт стоил около 1200 долл. (примерно 20 долл. за мегабайт), тогда как в 2004 году диск емкостью 200 Гбайт стоил около 100 долл. (примерно 0,0005 долл. за мегабайт). Учитывая подобный рост емкости дисковых накопителей и стремясь удовлетворить все возрастающие требования, предъявляемые к устройствам хранения, во многих организациях щедро раздаются дисковые квоты, что неизбежно приведет к необходимости в ближайшем будущем решать проблемы управления данными Exchange. Размер почтовых ящиков возрос с 25 Мбайт в 1996 году до 100-200 Мбайт в 2005 году.

Аналогичным образом росла производительность устройств, используемых при выполнении резервирования и восстановления, что привело к сокращению времени выполнения этих операций. Первые ленточные накопители DLT обеспечивали скорость передачи данных 1,25 Mбит/с; современные накопители DLT поддерживают скорость передачи 16 Mбит/с, а ленточные накопители Linear Tape-Open (LTO) предлагают скорость передачи данных до 30 Mбит/с. Благодаря такому значительному улучшению характеристик устройств, используемых при резервировании/восстановлении, появляется возможность поддерживать более крупные базы данных Exchange, что уменьшает остроту проблемы управления данными, но не решает ее до конца.

Требования регулирующих органов. Все больше становится компаний, в которых появляется необходимость использования политик, соответствующих требованиям внешних регулирующих органов в противовес выполнению простых внутрикорпоративных инструкций.