Обзор архитектуры хранения в Exchange 2003
В лекции 2 рассказывалось об архитектуре хранилища Exchange Server 2003. В этом параграфе мы вспомним основные концепции этой архитектуры. Группа хранения в системе Exchange содержит до пяти баз данных в версии Enterprise Edition и до двух баз в версии Standard Edition. Для всех этих баз данных используются одни и те же файлы журналов транзакций. Каждая база данных в Exchange Server 2003 состоит из двух файлов: файла в формате RTF (.EDB-файл) и файла с содержимым в исходном формате (.STM-файл). Этими файлами (как единым целым) управляет процесс Store (Store.exe). Файл с содержимым в исходном формате может содержать любой тип информации в ее исходной форме. Информация записывается в этот файл и считывается из него монтируемой файловой системой Exchange (Installable File System, ExIFS) – компонентом привилегированного режима, который обеспечивает очень быструю потоковую передачу данных.
Преимущества использования групп хранения
В настоящее время уже нет ничего необычного в том, что размер базы данных Exchange 5.5 может превышать 20 Гб. На резервное копирование баз данных может уходить несколько часов. Но проблемой в данном случае является не длительность резервного копирования, а время, затрачиваемое на восстановление столь больших баз данных. Разумеется, на время восстановления производительность работы пользователей системы резко снизится. При планировании баз данных Exchange необходимо помнить об одном старом добром правиле: чтобы работа шла успешно, нужно всегда включать в план неудачи, то есть отказы в работе. Эта предусмотрительность поможет при восстановлении после аварийных отказов.
При применении групп хранения и разрешении использования нескольких баз данных на одном сервере компания Microsoft внесла огромные изменения в архитектуру баз данных на основе механизма расширяемого хранения (Extensible Storage Engine, ESE) со времен версии Exchange Server 5.5. Эти изменения позволили существенно улучшить восстанавливаемость и свести к минимуму нерациональные затраты времени при повреждении какой-либо базы данных Exchange. Кроме того, использование групп хранения дает несколько ключевых преимуществ:
на каждом сервере можно размещать больше пользователей, чем раньше;
резервное копирование и восстановление каждой базы данных можно выполнять по отдельности;
на каждом сервере можно размещать несколько предприятий;
для особых почтовых ящиков можно использовать отдельное хранилище;
к отдельным группам хранения можно применять циклическое ведение журналов.
Возросший уровень поддержки пользователей
Возможно, самым большим преимуществом групп хранения является то, что они позволяют распределять пользователей по нескольким базам данных на одном сервере Exchange Server 2003. Это обеспечивает три преимущества:
существует возможность поддерживать большее число пользователей на одном сервере, нежели в Exchange 5.5;
сокращено время простоя в случае повреждения одной из баз данных;
на одном сервере Exchange можно размещать больше пользователей, поскольку имеется возможность поддерживать размеры баз данных в разумных пределах.
Как уже упоминалось ранее, внутри одной группы хранения находится до пяти баз данных, каждый сервер содержит до четырех групп хранения. Таким образом, каждый сервер содержит до 20 баз данных.
Однако при использовании утилиты проверки целостности хранилища информации (Information Store Integrity Checker) Isinteg.exe для какой-либо базы данных необходимо демонтировать (отсоединить) эту базу данных. Кроме того, для Isinteg.exe требуется вторая, временная, база данных. Поэтому при шести базах данных в одной группе хранения придется демонтировать еще одну базу данных, чтобы утилита Isinteg.exe могла правильно работать. Снизив количество работающих баз данных в одной группе хранения до четырех, всегда можно использоват Isinteg.exe без необходимости демонтирования второго хранилища.
Если пользователи распределены по нескольким базам данных, то отсоединение одной из баз данных (по той или иной причине) затронет лишь некоторую часть пользователей. Остальные пользователи смогут продолжать работу, поскольку их базы данных останутся подсоединенными. Отсоединенная база данных считается демонтированной. Ее значок в окне вставки Exchange System будет содержать красную стрелку, направленную вниз, как показано на рис 11.1.
(рис 11.1) Подсоединенные базы данных и отсоединенная база данных (Executive MBX) в группе хранения
Резервное копирование и восстановление баз данных по отдельности
Поскольку каждую базу данных можно монтировать или демонтировать по отдельности, то резервное копирование и восстановление баз данных в одной группе хранения тоже можно выполнять по отдельности, в то время как остальные базы данных этой группы будут оставаться смонтированными и продолжать функционировать. Рассмотрим ситуацию, когда создано четыре хранилища почтовых ящиков в одной группе хранения, по одному хранилищу на каждое из четырех подразделений компании. В случае повреждения одного из хранилищ остальные три останутся подсоединенными во время восстановления четвертого хранилища с резервной копии. Нет необходимости демонтировать все хранилища одной группы хранения для восстановления одного из них. И если одно из хранилищ повреждено, и его нельзя смонтировать, это не помешает монтированию других хранилищ данной группы хранения и доступу пользователей к этим хранилищам.
Примечание. Помимо пяти баз данных, разрешенных для использования в каждой группе хранения, есть также возможность использования шестой группы хранения, называемой группой восстановления. Группа восстановления является временной группой, которую можно подключить при выполнении операций по восстановлению. Например, можно подключить эту группу, восстановить в ней почтовые ящики и разрешить пользователям доступ к ней в процессе разрешения возникших проблем с исходной группой хранения. Затем производится слияние почтовых ящиков группы восстановления с исходной группой хранения. Работа с группой восстановления подробно описывается в лекции 7 "Функциональность, безопасность и поддержка Exchange Server 2003".
Размещение нескольких предприятий на одном сервере
Если осуществляется поддержка электронной почты для нескольких предприятий, то их возможно разместить на одном сервере. Можете создать отдельное хранилище для каждого предприятия и даже выделить для предприятия при необходимости отдельную группу хранения. В любом случае Exchange Server 2003 содержит информацию каждого предприятия совершенно отдельно в выделенном для него хранилище, в отличие от Exchange Server 5.5.
То, что хранилища существуют отдельно и независимо друг от друга, позволяет устанавливать различные графики администрирования для предприятий. Например, некоторым администраторам нужно выполнять полное резервное копирование ежедневно, в то время как у других администраторов эта процедура проводится один раз в неделю. Одни администраторы размещают каждое подразделение фирмы в отдельном хранилище, в то время как другие размещают всех своих пользователей в одном хранилище. Эта гибкость выбора упрощает задачу создания структуры, отвечающей требованиям заказчика.
Поддержка специальных почтовых ящиков
Хотя это не является распространенной рекомендацией, существует возможность использования специального почтового ящика или специального набора почтовых ящиков, чтобы создать их в отдельном хранилище. В качестве примера приведем получателя, который регистрирует копии всех сообщений электронной почты организации, связанных с местными законами и промышленными нормами. Еще один пример – проектная группа, которая работает с очень важной для компании информацией. Их работа оправдывает использование отдельного хранилища или дерева общих папок.
Циклическое ведение журналов для одной группы хранения
Иногда в процессе работы требуется осуществлять контроль над журналами транзакций для некоторых групп хранения из-за ограниченности пространства на диске. Например, возможно, что в одном файле с содержимым в исходном формате содержится информация разового использования, в то время как в другом файле такого же типа информация используется многократно. Поскольку при циклическом ведении журналов можно выполнять восстановление только с последней полной резервной копии, то информацию разового назначения (например, оповещения, распространяемые во всей организации) можно поместить в одну общую папку в одной группе хранения, для которой разрешено циклическое ведение журналов, а сообщения электронной почты пользователей – в другую группу хранения, в которой циклическое ведение журналов отключено. Тем самым при восстановлении после аварийного отказа можно будет сосредоточить усилия на более важной информации. Описание циклического ведения
журналов приведено в лекции 2.
Планирование групп хранения
В большей части операций по установке, будь то миграция (переход) из старых систем или новые инсталляции, планированию уделяется наименьшее внимание. Мы готовы сколь угодно повторять, что недостаточное планирование приводит к низкому уровню реализации и увеличению затрат на администрирование в долгосрочной перспективе. Если бы вы записывали виды своей деятельности по администрированию каждый день в течение месяца и затем просматривали их, то, вполне возможно, пришли бы к выводу, что при лучшем планировании и реализации можно снизить объем производимых работ на 50 процентов или больше. Разумеется, многие станут ссылаться на отсутствие времени для исчерпывающего планирования. Но если осуществить тщательное планирование, то дело кончится тем, что сэкономленное время будет потрачено на непредвиденные трудности, вызванные переходом на систему Exchange Server 2003.
Пример из практики.Образцовое администрирование сети
Мы знаем одного администратора Exchange, который регулярно выполняет следующие действия. Основываясь на своей ежедневной деятельности и планируя профилактические средства, чтобы избежать "острых ситуаций", он разработал приведенный ниже список. Естественно, что его сеть Exchange работает без сбоев, и он готов к любой возможной аварии. Некоторым из читателей книги эти задачи покажутся чрезмерными. Но мы уверены, что, изучив эти шаги, вы измените свое мнение. Мы думаем, что это как раз пример отличного администрирования.
Ежедневно он проверяет свои журналы – абсолютно все. Он просматривает журналы приложений, безопасности, системный журнал, журнал каталогов и другие журналы. Если он видит любые предупреждения или уведомления, он помечает их и по возможности решает эти проблемы в тот же день. Он также проверяет каждый день журналы программ резервного копирования, чтобы убедиться в успешном завершении резервного копирования. Он выполняет наращиваемое (инкрементальное) резервное копирование каждый день, кроме пятницы. Кроме того, он запускает монитор серверов (Server Monitor) для критических служб на своих серверах Exchange и отправляет каждый час возвращаемые сообщения монитора соединений (Link Monitor) постоянным поставщикам и заказчикам своей компании. (Возвращаемые сообщения направляются в общей сложности восьми SMTP-серверам интернета.) При неисправности соответствующего канала он зачастую узнает об этом раньше, чем кто-либо еще, и может найти неисправность и (иногда)
устранить ее раньше, чем пользователи вообще узнают о каких-то неполадках. (Подробнее о мониторе соединений и мониторе серверов будет рассказано в лекции 7 "Функциональность, безопасность и поддержка Exchange Server 2003".)
Еженедельно он выполняет полное резервное копирование всех своих серверов и в понедельник убеждается, что копирование прошло успешно. Если нет, то он запускает в понедельник новое полное резервное копирование, когда уходит с работы. Он также проверяет наличие обновлений по антивирусным программам и использует программное обеспечение своей сети для обновления своих серверов и рабочих станций своих пользователей.
Каждый месяц он получает серию диаграмм оснастки System Monitor, регистрирует виды операций и затем печатает отчет для каждого сервера, помещая его в постоянно наращиваемую записную книжку. Эти диаграммы отражают состояние его серверов, и они измеряются в течение трех дней через 10-минутные интервалы. С помощью этих диаграмм он прогнозирует, как повлияет добавление какой-либо службы или новой группы пользователей на каждый из этих серверов. И когда он запрашивает у руководства компании новое оборудование, то у него есть числовое обоснование и достоверные сведения, чтобы подкрепить свой запрос.
Кроме того, каждый месяц он выполняет пробное восстановление для каждого используемого ленточного устройства резервного копирования. Поскольку резервное копирование выполняется для трех различных серверов, он выполняет три пробных восстановления. Вот как он это делает. Он берет 15% информации, для которой выполняется резервное копирование, и копирует ее в другое место того же сервера. Часто он создает временную папку с именем Test. Затем он получает резервную копию этой папки, записывая ее размер и количество файлов. После окончания операции резервного копирования и проверки он удаляет папку Test и затем восстанавливает ее с резервной копии на ленте. По окончании операции восстановления он сравнивает размер и количество файлов восстановленной папки со значениями, записанными для исходной папки Test. Если они совпадают, то он считает, что система резервного копирования на ленту работает правильно. Если нет, он начинает поиск и устранение неисправностей.
Раз в месяц он восстанавливает свои базы данных Exchange на автономном сервере, который сконфигурирован приблизительно так же, как и его эксплуатируемый сервер. Затем он проверяет, что его базы данных действуют на автономном сервере. Эта проверка позволяет убедиться, что он может выполнять полное восстановление быстро и эффективно, и его система резервного копирования находится в работоспособном состоянии. Учиться восстановлению нужно до того, как "грянет гром" и придется сидеть на телефоне, непрерывно консультируясь со службой технической поддержки Microsoft. Лучше делать это, когда все спокойно, и можно позволить себе ошибки, работая на автономном сервере.
Кроме того, с периодичностью от четырех до шести недель он предлагает конечным пользователям обучение – обычно по вопросам, которые преобладали, когда пользователи обращались к нему за поддержкой. Использование этого подхода к "обслуживанию заказчиков" привело к устойчивому снижению количества обращений в службу технической поддержки, поскольку у него появились пользователи, которые стали лучше разбираться в системе и самостоятельно выполнять некоторые базовые операции, связанные с поиском и устранением неисправностей, такие как проверка разъемов или подсоединения принтера к сети.
Раз в квартал он разряжает батареи системы бесперебойного электропитания (UPS), чтобы убедиться, что программное обеспечение UPS корректно отключает его серверы. Будет лучше, если обнаружится, что программное обеспечение UPS не работает, во время теста, чем во время сбоя электропитания. Если при неожиданном нарушении электропитания UPS сразу отключит напряжение, подаваемое на сервер Exchange (вместо постепенного отключения), то это с большой вероятностью приведет к повреждению базы данных.
Кроме того, он ежеквартально проверяет, не появились ли модификации и обновления аппаратно-программного обеспечения для всех его серверов, и в случае новых обновлений он выполняет их инсталляцию. Для пользователей он следит за модификациями и пакетами обновлений различных программ, которые используются в его фирме, и в случае их появления проводит тестирование совместно с небольшим количеством надежных пользователей; затем, исключив то, что дает отрицательные результаты, он распространяет модификации на всю сеть. И, наконец, он ежеквартально проверяет охлаждающие вентиляторы на всех серверах, чтобы убедиться, что они продолжают хорошо работать.
Хорошее планирование позволило ему заслужить доверие своих руководителей. Он не жалеет времени, чтобы объяснить, что он делает и почему. Поэтому со временем ему удалось реализовать много стандартов, обеспечивающих безотказную работу сети. Профилактические меры, включенные в планирование, позволяют ему в большинстве случаев предвидеть возможные изменения в его сети, а не заниматься устранением неполадок.
Планирование пространства на диске
Рассмотрим некоторые вопросы планирования. Надеемся, что вы уделите достаточное внимание этому параграфу. Поскольку данная лекция посвящена группам хранения, мы рассмотрим здесь планирование таких аспектов, как объем пространства на диске, использование нескольких баз данных и нескольких групп хранения. (Для получения более подробных сведений по планированию для Exchange Server 2003 обратитесь к лекции 5.) Планируя объем пространства на диске для сервера Exchange 2003, следует учесть следующие ключевые факторы:
количество пользователей, которых нужно разместить на данном сервере Exchange;
типы пользователей, которых нужно разместить на данном сервере Exchange;
средний размер одного сообщения и одного вложения электронной почты, а также количество вложений, которое потребуется отправлять и получать пользователям;
количество и размер общих папок.
В следующих двух разделах описано, как рассчитать необходимый объем пространства на диске сервера Exchange.
Расчет пространства на диске для сообщений и вложений электронной почты
Прогнозирование интенсивности обмена сообщениями между пользователями информационной системы является нелегким делом. Некоторые пользователи отправляют и принимают лишь несколько сообщений в день. Другие отправляют и получают множество сообщений и некоторые – с большими вложениями. Очевидно, что при одинаковых возможностях оборудования можно разместить в одном хранилище почтовых ящиков больше пользователей с небольшим объемом корреспонденции. Это наиболее простой путь, но все же будет лучше, если разработать систему классификации для рассматриваемой среды и затем провести подсчеты, чтобы определить, сколько пользователей можно разместить в каждом хранилище, в каждой группе хранения и, наконец, на каждом сервере. Если получится составить приблизительную картину текущего использования системы обмена сообщениями, то представится возможным более точно прогнозировать требования к оборудованию и группам хранения.
Для достижения этой цели рекомендуется получить случайную выборку пользователей системы (не менее 15%) и затем провести анализ текущего использования электронной почты в папке Sent Items (Отправленные), чтобы получить представление о количестве сообщений, отправляемых каждый день, и о размере этих сообщений. Вы можете также определить, сколько сообщений содержат вложения, а раскрыв сообщения, – размеры этих вложений. Соображения безопасности могут не позволить получить эту информацию от некоторых пользователей, и в этих случаях попросите их заполнить небольшую анкету.
Собрав необходимые данные, их необходимо проанализировать. Эта часть работы состоит из расчета некоторых показателей. Рассмотрим следующий пример. Предположим, что проводится анализ по 45 пользователям (из 300) в течение 60 дней и определяется, что среднее количество сообщений электронной почты в день, приходящихся на одного пользователя, равно 14 с двумя вложениями. И еще предположим, что средний размер каждого сообщения составляет 1 Кб, а средний размер каждого вложения – 200 Кб. Расчет проводится следующим образом:
14 сообщений x 1 Кб = 14 Кб в день для сообщений электронной почты;
2 вложения x 200 Кб = 400 Кб в день для вложений;
средний объем используемого пространства на диске: 828 Кб в день (414 Кб для хранилища и 414 Кб для журналов транзакций);
828 Кб x 300 пользователей = 248400 Кб (248,4 Мб) пространства на диске в день для всех 300 пользователей. На два месяца (60 дней) приходится 44 рабочих дня, то есть потребуется 10929 Мб (10,9 Гб) пространства на диске.
Это последнее значение несколько неточно, поскольку журналы транзакций не хранятся бесконечно долго. В конечном счете, система ESE удалит старые журналы, освобождая пространство на диске, которое будет снова использоваться журналами транзакций. Поэтому давайте предположим, что ESE хранит только часть журналов за последнюю неделю, то есть 5 x 414 Кб = 2070 Кб. Таким образом, для работы Exchange Server 2003 через два месяца потребуется только 5466870 Кб, то есть 5.4 Гб (44 дня x 414 Кб в среднем х 300 пользователей плюс 2070 Кб для журналов).
И это еще не все. Мы только определили объем пространства на диске, необходимый для записи сообщений и вложений электронной почты. Нам нужно еще оценить общие папки и производительность устройств резервного копирования.
Расчет пространства на диске для общих папок
Чтобы показать, как рассчитывается объем пространства на диске, необходимого для общих папок, предположим, что каждый пользователь помещает в общие папки примерно три документа в день со средним размером одного документа 6 Кб. (Если этот размер документа кажется слишком большим, обратитесь к лекции 2, где рассматривается архитектура хранилища. Мы еще не раз будем рассматривать хранение различных типов документов в Exchange.) Рассчитаем объем пространства на диске для общих папок следующим образом: 3 документа x 300 пользователей x 6 Кб x 2 (поскольку каждый документ записывается в хранилище и журнал транзакций). В результате получаем, что для размещения документов пользователей в общих папках требуется 10800 Кб (10,8 Мб) пространства на диске. На 44 дня потребуется 237600 Кб (237,6 Мб) плюс 27000 Кб для журналов транзакций (3 документа х 300 пользователей х 6 Кб х 5 дней),
что даст в сумме за два месяца 264600 Кб (264,6 Мб) пространства на диске, необходимого для общих папок. Таким образом, потребуется 5,46 Гб для сообщений электронной почты и 264,6 Мб для общих папок, или приблизительно 5,7 Гб на период в два месяца. Но планирование еще не закончено. Теперь нужно определить, как использовать эти значения в процессе планирования групп хранения.
Планирование нескольких групп хранения
Получив оценку необходимого пространства на диске, необходимо оценить, сколько потребуется групп хранения. Одним из факторов, который нужно учесть, является различие приоритетов работы, которую выполняют пользователи. Предположим, что 20 из 300 пользователей рассматриваемой системы выполняют критически важную работу. Возможно, это персонал отдела продаж, который принимает заказы по телефону или обрабатывает заказы клиентов, размещаемые в общей папке, представленной на веб-сайте. Предположим, что при отключении этих пользователей даже на 15 минут компания теряет более 50000 долларов. При подобной ситуации стоит подумать о том, чтобы разбить этих пользователей на две группы и поместить каждую группу в ее собственные хранилища почтовых ящиков и общих папок. Однако здесь нет необходимости размещать их в отдельной группе хранения.
Причиной такой рекомендации является то, что в случае повреждения других баз данных эти пользователи смогут продолжать свою работу, поскольку вы можете отключить и восстанавливать одно или несколько хранилищ, в то время как другие хранилища той же группы хранения продолжают работать. И если потребуется восстановление базы данных одной группы этих пользователей, это будет сделано быстро, поскольку эта база данных намного меньше, чем база данных всей компании, в которой хранится информация остальных 280 пользователей. Кроме того, поскольку критические пользователи распределены по двум базам данных, вторая половина группы сможет продолжать работу. Таким образом, следует планировать группы хранения, уделяя большее внимание вопросам аварийного восстановления, чем вопросам использования пространства на диске.
Планирование производительности устройств резервного копирования
Еще одним фактором в планировании групп хранения является уровень производительности, который потребуется при восстановлении. Предположим, что вы приобрели ленточный накопитель с максимальной скоростью 10 Гб в час, или 166,6 Mб в минуту. При такой скорости восстановление баз данных с резервной копии на ленте займет приблизительно 35 минут, если все пользователи включены в одну базу данных. С учетом времени, необходимого для диагностирования проблемы, поиска лент и восстановления, можно предположить, что пользователи системы не смогут пользоваться электронной почтой и общими папками от одного до двух часов (в зависимости от характера проблемы, а также от времени, которое потребуется, чтобы вернуться к точке, с которой можно начать операцию восстановления).
В некоторых компаниях отключение системы на 1-2 часа не столь существенно. Для других компаний это катастрофа. Поэтому следует определить, сколько времени пользователи смогут обходиться без услуг Exchange во время восстановления. Консультации с руководителем помогут определить длительность приемлемого простоя в случае аварии.
Предположим, что в результате этих консультаций определено, что ни один из пользователей не должен оставаться без услуг Exchange более 30 минут. Чтобы запланировать меры, позволяющие укладываться в это максимальное время простоя, необходимо взять рассчитанное выше время восстановления и разделить его на максимальное время простоя, допускаемое политикой руководства. В результате будет получено количество хранилищ, которое потребуется создать на сервере Exchange. Чтобы определить минимальное количество групп хранения, которое вам потребуется, разделите количество хранилищ на 5 (количество хранилищ на одну группу хранения).
В данном примере мы знаем, что восстановление данных для 300 пользователей потребует 35 минут. Однако это время соответствует хранению данных только в течение двух месяцев. В большинстве компаний хранят информацию намного дольше. Поэтому, если мы примем в данном примере более реальный период хранения в один год, то нам потребуется умножить рассчитанные выше значения на 6, чтобы определить картину восстановления для годичного запаса данных. Таким образом, восстановление баз данных, содержащих накопленную за год информацию, займет 210 минут (3,5 часа). Что делать в этом случае? А ведь нам нужно, чтобы базы данных можно было восстанавливать в течение 15 минут, чтобы был запас времени, позволяющий уложиться в 30-минутное требование максимального простоя, принятое в рассматриваемой компании. Поэтому нам потребуется создать не менее 14 отдельных хранилищ почтовых ящиков и 14 отдельных хранилищ общих папок (210/15).
Здесь, конечно, предполагается, что будут использоваться базы данных приблизительно одинакового размера. Если некоторые базы данных оказываются намного больше, чем допускается временем восстановления, то имеет смысл создать дополнительные хранилища или переместить почтовые ящики некоторых пользователей в другие хранилища, чтобы размеры хранилищ отвечали поставленным целям.
В данном случае нам потребуется не менее пяти групп хранения, чтобы в них можно было поместить 28 хранилищ. Поскольку на одном сервере допускается не более четырех групп хранения, то для размещения этих хранилищ нам потребуются два сервера Exchange. Лучше всего по возможности равномерно распределить эти базы данных между двумя серверами. Кроме того, поскольку в системе на одну группу хранения приходится один набор журналов транзакций, то увеличение количества групп хранения будет препятствовать образованию большого количества журналов транзакций на одну группу хранения, хотя и приведет к общему увеличению количества журналов транзакций для системы в целом.
Создание группы хранения
Группа хранения создается быстро и без проблем. Напомним, что на одном сервере Exchange 2003 нельзя создать более четырех групп хранения. При попытке сделать это появится сообщение об ошибке.
Чтобы создать группу хранения, откройте оснастку Exchange System и найдите нужный объект-сервер. Щелкните правой кнопкой мыши на этом объекте-сервере, укажите пункт New (Создать) и выберите пункт Storage Group (Группа хранения) из соответствующего подменю (рис 11.2). Появится страница свойств новой группы хранения (рис 11.3). При вводе имени группы хранения станет видно, что это имя одновременно вводится во все три поля. Это защищает от ошибок в местоположении журналов транзакций (Transaction log location) или системного пути доступа к хранилищам (System path location).
(рис 11.3) Создание группы хранения(рис 11.2) Страница свойств новой группы храненияНа странице свойств можно включить опции Zero Out Deleted Database Pages (Обнуление удаленных страниц баз данных) и Enable Circular Logging (Активизировать циклическое ведение журналов). Параметр Zero Out Deleted Database Pages указывает, чтобы при резервном копировании в режиме он-лайн во все удаленные страницы всех хранилищ, входящих в данную группу хранения, записывались нули. Установите этот флажок, если хотите, чтобы удаленные данные нельзя было восстановить. Это потребует дополнительной обработки в процессе копирования и замедлит процесс, но улучшит защиту от доступа к удаленным данным. В поле Log File Prefix (Префикс для файлов журналов) можно указывать префикс, который помещается перед началом имени каждого файла журнала. Это позволяет хранить все файлы журналов в одном месте и при этом видеть, какие журналы относятся к соответствующей группе хранения.
Опция Enable Circular Logging позволяет использовать циклическое ведение журналов для данной группы хранения. Активизируйте это средство только для тех групп хранения, которые не содержат критически важных данных. Использование циклического ведения журналов не приводит к снижению количества журналов транзакций, создаваемых процессом Store системы ESE, но лишает возможности восстановления баз данных вплоть до точки аварийного отказа. При циклическом ведении журналов возможно осуществить восстановление только с последней полной резервной копии. Прежде чем выбрать эту опцию, тщательно продумайте возможные последствия потери новых данных в базах данных Exchange.
В окне вкладки Details (Дополнительно) группы хранения можно вводить примечания по данной группе хранения, например, кто ее создал, и для чего она предназначена.
Создание хранилища
В группе хранения можно создавать два вида хранилищ – хранилище почтовых ящиков для сообщений и хранилище общих папок для доступа к общим папкам. Каждое хранилище содержит свои файлы .EDB и .STM. Хранилище нельзя создать, пока не создана группа хранения. При первоначальной инсталляции Exchange Server 2003 создается группа хранения с именем First Storage Group (Первая группа хранения), которую можно после этого переименовать, а также хранилище почтовых ящиков и хранилище общих папок внутри этой группы хранения.
Создание хранилища почтовых ящиков
Чтобы создать новое хранилище почтовых ящиков, щелкните правой кнопкой мыши на группе хранения, в которой нужно создать хранилище, наведите указатель мыши на пункт New (Создать) и затем выберите опцию Mailbox Store (Хранилище почтовых ящиков). Появится страница свойств, показанная на рис 11.4. В окне вкладки General (Общие) введите имя хранилища почтовых ящиков и затем щелкните на кнопке Browse (Обзор) рядом с полем Default Public Store (Хранилище общих папок по умолчанию), чтобы увидеть список хранилищ общих папок, с которыми можно ассоциировать (связать) данное хранилище почтовых ящиков (рис 11.5). Выделите в этом списке нужное хранилище общих папок и нажмите OK.
(рис 11.5) Вкладка General страницы свойств нового хранилища почтовых ящиков(рис 11.4) Выбор хранилища общих папок по умолчанию для нового хранилища почтовых ящиковПримечание. Указание хранилища общих папок для нового хранилища почтовых ящиков требуется потому, что каждый пользователь Exchange для доступа к общим папкам должен иметь какое-то установленное по умолчанию хранилище общих папок. Выбор хранилища общих папок в этом окне не ограничивает пользователя в доступе к другим хранилищам общих папок или деревьям общих папок. Это точка входа во всю область общих папок.
Выбрав хранилище общих папок, ассоциированное с данным хранилищем почтовых ящиков, нажмите кнопку Browse (Обзор) рядом с полем Default Offline Address List (Автономный список адресов по умолчанию), чтобы выбрать принимаемый по умолчанию автономный список адресов для пользователей, размещаемых в этом хранилище (см. рис 11.6). Пользователи по-прежнему смогут загружать другие автономные списки адресов; в этом поле просто указывается список по умолчанию.
(рис 11.6) Выбор автономного списка адресов по умолчанию для нового хранилища почтовых ящиковЕсли необходимо, чтобы в данном хранилище почтовых ящиков поддерживался стандарт S/MIME (Secure/Multipurpose Internet Mail Extensions – защищенные/многоцелевые почтовые расширения интернета), включите опцию Clients Support S/MIME Signatures (Клиентская поддержка подписей S/MIME). (Подробнее о стандарте S/MIME и случаях его использования рассказывается в части IV.) Если требуется, чтобы все входящие сообщения преобразовывались в 10-точечный шрифт Courier, установите флажок Display Plain Text Messages In A Fixed-Sized Font (Использовать для отображения сообщений с открытым текстом шрифт фиксированного размера).
На вкладке Database (База данных) этой страницы свойств (см. рис 11.7) указывается физическое местоположение двух файлов, образующих данное хранилище. Несмотря на то что можно перемещаться в удаленные точки общего доступа на другом сервере, в Exchange Server 2003 не разрешается связывать любой из файлов с совместно используемым сетевым ресурсом. Однако можно создать точку монтирования тома и указать ее как местоположение для любого из файлов. Это может оказаться полезным, если известно, что в определенную базу данных будут помещать большие файлы или много файлов, поскольку вы можете создать для них специальный раздел. Также можно указывать нужное время запуска обслуживающих утилит для данного хранилища.
Опция Do Not Mount This Store At Start-Up (Не монтировать это хранилище при запуске) позволяет указывать, что это хранилище не монтируется в момент запуска. По умолчанию данное хранилище монтируется при запуске служб Exchange. И, наконец, можно включить опцию This Database Can Be Overwritten By A Restore (Эта база данных может быть перезаписана при восстановлении). Этот параметр связан с глобально уникальным идентификатором данной базы данных (GUID).
(рис 11.7) Вкладка Database страницы свойств нового хранилища почтовых ящиковКаждая база данных имеет свой идентификатор GUID. Этот идентификатор хранится в базе данных системы ESE в одной из таблиц общего назначения. (Подробнее о системе ESE рассказывалось в лекции 2.) Идентификатор GUID базы данных вместе с физическим путем доступа на жестком диске также хранится в Active Directory. При запуске процесса Store.exe одной из его задач является монтирование базы данных. Но прежде чем монтировать базу данных, процесс Store.exe сравнивает GUID этой базы данных, который он находит в самой базе данных, с GUID этой базы данных в Active Directory. Сравниваются также пути доступа к каталогам.
Если все совпадает, то база данных монтируется. Но если какие-то элементы информации не совпадают, то процесс Store.exe не выполняет запуск базы данных. Это может произойти, если файлы базы данных перемещены с другого сервера или каталога в текущее местоположение. Процесс Store.exe требует совпадения идентификаторов GUID для предотвращения случайного перемещения базы данных в другое место и ее запуска в другой группе хранения с другими журналами транзакций.
Если включена опция This Database Can Be Overwritten By A Restore, то в процессе Store.exe предполагается, что действительно требуется перемещение этой базы данных в данное местоположение. Поэтому при запуске процесс Store.exe "исправит" базу данных, изменив ее GUID в самой базе данных на GUID, который хранится в Active Directory; при следующей попытке монтирования идентификаторы GUID совпадут, и база данных будет смонтирована. И, наконец, в результате этого процесса данный флажок будет сброшен.
Примечание. Если при монтировании базы данных процесс Store.exe вообще не найдет никакой базы данных, соответствующей указанному пути доступа, то этот процесс предложит создать новую базу данных. Опция This Database Can Be Overwritten By A Restore используется только в тех случаях, когда процесс Store.exe ищет базу данных в соответствии с указанным путем доступа и обнаруживает, что это неверная база данных, поскольку идентификаторы GUID не совпадают.
Опция This Database Can Be Overwritten By A Restore действует аналогичным образом при восстановлении. При вызове AddDatabase() процедура Ntbackup передает процессу Store.exe идентификатор GUID, имя базы данных и имя группы хранения. Если они совпадают, то процесс Store.exe передает в обратном направлении местоположения, где должны быть восстановлены данные файлы. Если идентификаторы GUID не совпадают, то в случае установки этого флажка процесс Store.exe передает процессу резервного копирования информацию о том, куда нужно записать файлы данной базы данных.
Примечание. Перемещая базы данных и включая опцию This Database Can Be Overwritten By A Restore, можно создавать несколько различных баз данных с одинаковым идентификатором GUID в системе Exchange Server 2003. При попытке монтировать обе базы данных будет смонтирована только одна из них (из-за конфликта идентификаторов GUID). Фирма Microsoft ни при каких обстоятельствах не рекомендует содержать две базы данных с одинаковыми GUID или выполнять "перестановку" баз данных. Возможны непредсказуемые и нежелательные результаты.
На вкладке Limits (Пределы хранения), показанной на рис 11.8, задается длительность хранения удаленных элементов и интервалы выдачи предупреждающих сообщений по хранению для данного хранилища почтовых ящиков. Можно задать эти параметры глобально, создав политику почтовых ящиков в контейнере Policies (Политики). Значения, заданные с помощью политики, нельзя изменить на уровне сервера.
Средства вкладки Full-Text Indexing (Индексирование по всему тексту) будут недоступны (затенены) при создании хранилища почтовых ящиков. Но после создания хранилища можно активизировать индексирование по всему тексту. Для этого нужно щелкнуть правой кнопкой мыши на имени хранилища в окне оснастки Exchange System, указать на пункт All Tasks (Все задачи) и выбрать Create Full Text Index (Создать индекс по всему тексту). После создания индекса внутри контейнера Full-Text Indexing появятся новые объекты (рис 11.9), и параметры внутри вкладки Full-Text Indexing будут доступны для конфигурирования. Подробнее об архитектуре индексирования по всему тексту рассказано в лекции 2. О том, как работать с индексированием по всему тексту, рассказывается ниже в разделе "Создание индекса по всему тексту".
(рис 11.9) Вкладка Limits страницы свойств нового хранилища почтовых ящиков(рис 11.8) Объекты в контейнере Full-Text Indexing для хранилища почтовых ящиков.На вкладке Details (Дополнительно) страницы свойств хранилища почтовых ящиков можно ввести административные замечания по хранилищу почтовых ящиков, такие как имя создателя хранилища и назначение этого хранилища. На вкладке Security (Безопасность), которая появляется только на странице свойств успешно созданного хранилища почтовых ящиков, содержатся полномочия для пользователей и групп, имеющих доступ к данному хранилищу. Лучше всего оставить в этом окне заданные по умолчанию значения, если только нет особых причин к их изменению. И, наконец, в окне вкладки Policies (Политики) приводятся все групповые политики, которые применяются к рассматриваемой базе данных. Тем не менее, нельзя конфигурировать групповую политику в этом окне.
Примечание. В группе хранения можно создавать новые хранилища общих папок. Этот процесс описывается в лекции 10.
Перемещение файлов журналов транзакций и файлов баз данных
В пакет Exchange Server 5.5 компания Microsoft включила средство Microsoft Exchange Optimizer – мастер с графическим интерфейсом, используемый для перемещения баз данных из одного места в другое. В Exchange Server 2003 этот процесс стал осуществляться вручную, и он требует тщательного внимания со стороны лица, осуществляющего перемещение файлов. Поскольку все хранилища связаны с одним набором журналов транзакций, нельзя переместить какое-либо одно хранилище определенной группы хранения в другое место без перемещения вместе с ним всех остальных хранилищ. Однако существует возможность перемещать файлы внутри базы данных в отдельное место, что будет рассмотрено чуть ниже.
При попытке изменить местоположение файлов журналов транзакций для какой-либо группы хранения или хранилища в группе хранения на экране появится предупреждающее сообщение о том, что текущие резервные копии будут неприменимы после этого перемещения. Причиной того, что в результате перемещения базы данных текущие резервные копии становятся недействительными, является то, что журналы транзакций, для которых созданы резервные копии, содержат в своих заголовках жестко кодированный путь доступа к базе данных. После перемещения базы данных заголовки в резервных копиях журналов транзакций будут по-прежнему содержать указатель на старое местоположение базы данных. Таким образом, процесс восстановления не будет работать, поскольку он не сможет найти базу данных, которая поддерживается этими журналами транзакций. (Подробнее об этом рассказывается в лекции 2.)
Поскольку компания Microsoft рекомендует содержать журнал транзакций и хранилища на разных дисководах, то можно изменить местоположение файлов транзакций, баз данных хранилищ или то и другое с помощью вкладки General (Общие) окна свойств соответствующей группы хранения (см. выше рис 11.3). Выберите новое местоположение, чтобы разместить там файлы или базы данных, после чего произойдет следующее.
Все хранилища будут демонтированы.
Произойдет перемещение выбранных файлов или баз данных.
Хранилища будут снова смонтированы.
Как мы уже отмечали чуть выше, разместить файлы баз данных хранилища можно в двух разных местах. Чтобы изменить местоположение файлов баз данных хранилища, используйте вкладку Database (База данных) в окне свойств данного хранилища (см. выше рис 11.7). Сначала демонтируйте данное хранилище, а затем введите новое местоположение в каталоге для файлов баз данных. Не обязательно помещать их в одном месте. И, как мы отмечали выше, есть возможность поместить базы данных в какой-либо точке монтирования тома. После выбора нового местоположения в каталоге и нажатия кнопки OK произойдет перемещение баз данных и обновление Active Directory. При этом также происходит автоматическое обновление заголовков в файлах транзакций. Монтирование хранилища происходит обычным образом.
Удаление хранилища или группы хранения
Прежде чем удалять хранилище или группу хранения, необходимо удалить их содержимое. Поэтому перед удалением группы хранения нужно удалить хранилища почтовых ящиков и общих папок.
Удаление хранилища почтовых ящиков
Прежде чем удалить хранилище почтовых ящиков, необходимо создать резервную копию всех его данных, чтобы гарантировать восстановление любой важной информации, удаленной вместе с этим хранилищем. Закончив резервное копирование, проследите за тем, чтобы переместить в другое хранилище все почтовые ящики, которые нужно сохранить. Если требуется удалить только одно хранилище, то можно переместить его почтовые ящики в другое хранилище той же самой группы хранения. Конечно, если планируется удалить всю группу хранения, то следует переместить почтовые ящики в хранилище другой группы хранения. Можно удалить хранилище почтовых ящиков, щелкнув на нем правой кнопкой мыши в окне оснастки Exchange System и выбрав пункт Delete (Удалить).
Если в очереди SMTP имеются сообщения, ожидающие внешней доставки, то будет получено сообщение об ошибке, информирующее об этом обстоятельстве. Если все-таки принято решение выполнить удаление, то будет предложено выбрать новое хранилище, которое будет использоваться как входная очередь для сообщений SMTP.
Удаление хранилища общих папок
Удаление хранилища общих папок осуществляется несколько сложнее, чем удаление хранилища почтовых ящиков. Во-первых, удаляемое хранилище не должно быть последним хранилищем или единственным хранилищем, содержащим дерево общих папок. Если это так, то нельзя будет удалить это хранилище общих папок. Во-вторых, это хранилище не должно быть принятым по умолчанию хранилищем общих папок для любых хранилищ почтовых ящиков или пользователей. Чтобы определить это в конкретном случае, нужно просмотреть страницу свойств каждого хранилища почтовых ящиков и определить, не использует ли оно удаляемое хранилище как принятое по умолчанию хранилище общих папок. Если да, то необходимо изменить конфигурацию этого хранилища почтовых ящиков, указав использование по умолчанию другого хранилища общих папок. В-третьих, если удаляемое хранилище общих папок содержит единственную реплику одной или нескольких папок, то появится предупреждение, что будут потеряны все данные, если сначала
не реплицировать эти данные в другое хранилище.
Удаление группы хранения
Если не остается никаких хранилищ, связанных с данной группой хранения, то ее можно удалить, щелкнув правой кнопкой мыши на этой группе в окне оснастки Exchange System и выбрав пункт Delete (Удалить).
Создание индекса по всему тексту
В хранилище информации происходит создание и управление индексами общих ключевых полей для быстрого просмотра и поиска. Если активизировать индексирование по всему тексту, то соответствующий индекс будет создаваться перед поиском в программе-клиенте, что позволит выполнять более быстрый поиск. Индексирование по всему тексту упрощает поиск документов (включая текстовые вложения) пользователями Outlook в хранилище информации. Для повышения гибкости каждое хранилище информации можно индексировать по отдельности. Процесс индексирования описан в лекции 2.
Чтобы включить индексирование, щелкните правой кнопкой мыши на хранилище, которое нужно индексировать, укажите на пункт All Tasks (Все задачи) и выберите опцию Create Full-Text Index (Создать индекс по всему тексту). Хотя выбранный пункт называется "Создать индекс по всему тексту", этой командой лишь активизируется средство индексирования для данного хранилища. Будет получен запрос, где необходимо указать местоположение, в котором должен быть создан соответствующий каталог. Указав местоположение, нажмите OK, после чего будут созданы объекты индексирования. Эти новые объекты отобразятся внутри объекта Full-Text Indexing (Индексирование по всему тексту) (см. рис 11.9).
Сначала объект Index State (Состояние индекса) указывет, что для данного хранилища еще не создавался индекс по всему тексту. Кроме того, объект Last Build Time (Время последнего построения индекса) обозначает, что данный каталог еще не создавался. Таким образом, несмотря на то что объекты индексирования созданы, еще не получен индекс по всему тексту.
Чтобы создать индекс по всему тексту, щелкните правой кнопкой мыши на данном объекте-хранилище, укажите на пункт All Tasks (Все задачи) и выберите опцию Start Full Population (Запуск по всей информации) или Start Incremental Population (Запуск по новой информации). При выборе варианта Start Full Population индексируются все имеющиеся данные, а выбор Start Incremental Population приводит к индексированию только той информации, которая поступила или была модифицирована с момента последнего индексирования по всей информации. В зависимости от объема информации этот процесс может занять от нескольких минут до нескольких часов.
После создания индекса станет видно, что увеличилось значение контейнера Number Of Documents Indexed (Количество индексированных документов), а также значение контейнера Index Size (MB) [Размер индекса (Мб)]. Также отобразится время, когда произошло последнее построение индекса для данного хранилища, и текущее местоположение баз данных этого индекса.
Заключение
В данной лекции рассказывалось о том, как осуществляется администрирование групп хранения в организации Exchange. Теперь вам должна быть понятна архитектура группы хранения и то, как создавать и осуществлять управление группами хранения и хранилищами. Вам также должно быть ясно, как активизировать индексирование и создавать полнотекстовый индекс для хранилища. В следующей лекции рассказывается о том, как реализовать и администрировать группы маршрутизации.
Обзор архитектуры хранения в Exchange 2003
В лекции 2 рассказывалось об архитектуре хранилища Exchange Server 2003. В этом параграфе мы вспомним основные концепции этой архитектуры. Группа хранения в системе Exchange содержит до пяти баз данных в версии Enterprise Edition и до двух баз в версии Standard Edition. Для всех этих баз данных используются одни и те же файлы журналов транзакций. Каждая база данных в Exchange Server 2003 состоит из двух файлов: файла в формате RTF (.EDB-файл) и файла с содержимым в исходном формате (.STM-файл). Этими файлами (как единым целым) управляет процесс Store (Store.exe). Файл с содержимым в исходном формате может содержать любой тип информации в ее исходной форме. Информация записывается в этот файл и считывается из него монтируемой файловой системой Exchange (Installable File System, ExIFS) – компонентом привилегированного режима, который обеспечивает очень быструю потоковую передачу данных.
Преимущества использования групп хранения
В настоящее время уже нет ничего необычного в том, что размер базы данных Exchange 5.5 может превышать 20 Гб. На резервное копирование баз данных может уходить несколько часов. Но проблемой в данном случае является не длительность резервного копирования, а время, затрачиваемое на восстановление столь больших баз данных. Разумеется, на время восстановления производительность работы пользователей системы резко снизится. При планировании баз данных Exchange необходимо помнить об одном старом добром правиле: чтобы работа шла успешно, нужно всегда включать в план неудачи, то есть отказы в работе. Эта предусмотрительность поможет при восстановлении после аварийных отказов.
При применении групп хранения и разрешении использования нескольких баз данных на одном сервере компания Microsoft внесла огромные изменения в архитектуру баз данных на основе механизма расширяемого хранения (Extensible Storage Engine, ESE) со времен версии Exchange Server 5.5. Эти изменения позволили существенно улучшить восстанавливаемость и свести к минимуму нерациональные затраты времени при повреждении какой-либо базы данных Exchange. Кроме того, использование групп хранения дает несколько ключевых преимуществ:
на каждом сервере можно размещать больше пользователей, чем раньше;
резервное копирование и восстановление каждой базы данных можно выполнять по отдельности;
на каждом сервере можно размещать несколько предприятий;
для особых почтовых ящиков можно использовать отдельное хранилище;
к отдельным группам хранения можно применять циклическое ведение журналов.
Возросший уровень поддержки пользователей
Возможно, самым большим преимуществом групп хранения является то, что они позволяют распределять пользователей по нескольким базам данных на одном сервере Exchange Server 2003. Это обеспечивает три преимущества:
существует возможность поддерживать большее число пользователей на одном сервере, нежели в Exchange 5.5;
сокращено время простоя в случае повреждения одной из баз данных;
на одном сервере Exchange можно размещать больше пользователей, поскольку имеется возможность поддерживать размеры баз данных в разумных пределах.
Как уже упоминалось ранее, внутри одной группы хранения находится до пяти баз данных, каждый сервер содержит до четырех групп хранения. Таким образом, каждый сервер содержит до 20 баз данных.
Однако при использовании утилиты проверки целостности хранилища информации (Information Store Integrity Checker) Isinteg.exe для какой-либо базы данных необходимо демонтировать (отсоединить) эту базу данных. Кроме того, для Isinteg.exe требуется вторая, временная, база данных. Поэтому при шести базах данных в одной группе хранения придется демонтировать еще одну базу данных, чтобы утилита Isinteg.exe могла правильно работать. Снизив количество работающих баз данных в одной группе хранения до четырех, всегда можно использоват Isinteg.exe без необходимости демонтирования второго хранилища.
Если пользователи распределены по нескольким базам данных, то отсоединение одной из баз данных (по той или иной причине) затронет лишь некоторую часть пользователей. Остальные пользователи смогут продолжать работу, поскольку их базы данных останутся подсоединенными. Отсоединенная база данных считается демонтированной. Ее значок в окне вставки Exchange System будет содержать красную стрелку, направленную вниз, как показано на рис 11.1.
(рис 11.1) Подсоединенные базы данных и отсоединенная база данных (Executive MBX) в группе хранения
Резервное копирование и восстановление баз данных по отдельности
Поскольку каждую базу данных можно монтировать или демонтировать по отдельности, то резервное копирование и восстановление баз данных в одной группе хранения тоже можно выполнять по отдельности, в то время как остальные базы данных этой группы будут оставаться смонтированными и продолжать функционировать. Рассмотрим ситуацию, когда создано четыре хранилища почтовых ящиков в одной группе хранения, по одному хранилищу на каждое из четырех подразделений компании. В случае повреждения одного из хранилищ остальные три останутся подсоединенными во время восстановления четвертого хранилища с резервной копии. Нет необходимости демонтировать все хранилища одной группы хранения для восстановления одного из них. И если одно из хранилищ повреждено, и его нельзя смонтировать, это не помешает монтированию других хранилищ данной группы хранения и доступу пользователей к этим хранилищам.
Примечание. Помимо пяти баз данных, разрешенных для использования в каждой группе хранения, есть также возможность использования шестой группы хранения, называемой группой восстановления. Группа восстановления является временной группой, которую можно подключить при выполнении операций по восстановлению. Например, можно подключить эту группу, восстановить в ней почтовые ящики и разрешить пользователям доступ к ней в процессе разрешения возникших проблем с исходной группой хранения. Затем производится слияние почтовых ящиков группы восстановления с исходной группой хранения. Работа с группой восстановления подробно описывается в лекции 7 "Функциональность, безопасность и поддержка Exchange Server 2003".
Размещение нескольких предприятий на одном сервере
Если осуществляется поддержка электронной почты для нескольких предприятий, то их возможно разместить на одном сервере. Можете создать отдельное хранилище для каждого предприятия и даже выделить для предприятия при необходимости отдельную группу хранения. В любом случае Exchange Server 2003 содержит информацию каждого предприятия совершенно отдельно в выделенном для него хранилище, в отличие от Exchange Server 5.5.
То, что хранилища существуют отдельно и независимо друг от друга, позволяет устанавливать различные графики администрирования для предприятий. Например, некоторым администраторам нужно выполнять полное резервное копирование ежедневно, в то время как у других администраторов эта процедура проводится один раз в неделю. Одни администраторы размещают каждое подразделение фирмы в отдельном хранилище, в то время как другие размещают всех своих пользователей в одном хранилище. Эта гибкость выбора упрощает задачу создания структуры, отвечающей требованиям заказчика.
Поддержка специальных почтовых ящиков
Хотя это не является распространенной рекомендацией, существует возможность использования специального почтового ящика или специального набора почтовых ящиков, чтобы создать их в отдельном хранилище. В качестве примера приведем получателя, который регистрирует копии всех сообщений электронной почты организации, связанных с местными законами и промышленными нормами. Еще один пример – проектная группа, которая работает с очень важной для компании информацией. Их работа оправдывает использование отдельного хранилища или дерева общих папок.
Циклическое ведение журналов для одной группы хранения
Иногда в процессе работы требуется осуществлять контроль над журналами транзакций для некоторых групп хранения из-за ограниченности пространства на диске. Например, возможно, что в одном файле с содержимым в исходном формате содержится информация разового использования, в то время как в другом файле такого же типа информация используется многократно. Поскольку при циклическом ведении журналов можно выполнять восстановление только с последней полной резервной копии, то информацию разового назначения (например, оповещения, распространяемые во всей организации) можно поместить в одну общую папку в одной группе хранения, для которой разрешено циклическое ведение журналов, а сообщения электронной почты пользователей – в другую группу хранения, в которой циклическое ведение журналов отключено. Тем самым при восстановлении после аварийного отказа можно будет сосредоточить усилия на более важной информации. Описание циклического ведения
журналов приведено в лекции 2.
Планирование групп хранения
В большей части операций по установке, будь то миграция (переход) из старых систем или новые инсталляции, планированию уделяется наименьшее внимание. Мы готовы сколь угодно повторять, что недостаточное планирование приводит к низкому уровню реализации и увеличению затрат на администрирование в долгосрочной перспективе. Если бы вы записывали виды своей деятельности по администрированию каждый день в течение месяца и затем просматривали их, то, вполне возможно, пришли бы к выводу, что при лучшем планировании и реализации можно снизить объем производимых работ на 50 процентов или больше. Разумеется, многие станут ссылаться на отсутствие времени для исчерпывающего планирования. Но если осуществить тщательное планирование, то дело кончится тем, что сэкономленное время будет потрачено на непредвиденные трудности, вызванные переходом на систему Exchange Server 2003.
Пример из практики.Образцовое администрирование сети
Мы знаем одного администратора Exchange, который регулярно выполняет следующие действия. Основываясь на своей ежедневной деятельности и планируя профилактические средства, чтобы избежать "острых ситуаций", он разработал приведенный ниже список. Естественно, что его сеть Exchange работает без сбоев, и он готов к любой возможной аварии. Некоторым из читателей книги эти задачи покажутся чрезмерными. Но мы уверены, что, изучив эти шаги, вы измените свое мнение. Мы думаем, что это как раз пример отличного администрирования.
Ежедневно он проверяет свои журналы – абсолютно все. Он просматривает журналы приложений, безопасности, системный журнал, журнал каталогов и другие журналы. Если он видит любые предупреждения или уведомления, он помечает их и по возможности решает эти проблемы в тот же день. Он также проверяет каждый день журналы программ резервного копирования, чтобы убедиться в успешном завершении резервного копирования. Он выполняет наращиваемое (инкрементальное) резервное копирование каждый день, кроме пятницы. Кроме того, он запускает монитор серверов (Server Monitor) для критических служб на своих серверах Exchange и отправляет каждый час возвращаемые сообщения монитора соединений (Link Monitor) постоянным поставщикам и заказчикам своей компании. (Возвращаемые сообщения направляются в общей сложности восьми SMTP-серверам интернета.) При неисправности соответствующего канала он зачастую узнает об этом раньше, чем кто-либо еще, и может найти неисправность и (иногда)
устранить ее раньше, чем пользователи вообще узнают о каких-то неполадках. (Подробнее о мониторе соединений и мониторе серверов будет рассказано в лекции 7 "Функциональность, безопасность и поддержка Exchange Server 2003".)
Еженедельно он выполняет полное резервное копирование всех своих серверов и в понедельник убеждается, что копирование прошло успешно. Если нет, то он запускает в понедельник новое полное резервное копирование, когда уходит с работы. Он также проверяет наличие обновлений по антивирусным программам и использует программное обеспечение своей сети для обновления своих серверов и рабочих станций своих пользователей.
Каждый месяц он получает серию диаграмм оснастки System Monitor, регистрирует виды операций и затем печатает отчет для каждого сервера, помещая его в постоянно наращиваемую записную книжку. Эти диаграммы отражают состояние его серверов, и они измеряются в течение трех дней через 10-минутные интервалы. С помощью этих диаграмм он прогнозирует, как повлияет добавление какой-либо службы или новой группы пользователей на каждый из этих серверов. И когда он запрашивает у руководства компании новое оборудование, то у него есть числовое обоснование и достоверные сведения, чтобы подкрепить свой запрос.
Кроме того, каждый месяц он выполняет пробное восстановление для каждого используемого ленточного устройства резервного копирования. Поскольку резервное копирование выполняется для трех различных серверов, он выполняет три пробных восстановления. Вот как он это делает. Он берет 15% информации, для которой выполняется резервное копирование, и копирует ее в другое место того же сервера. Часто он создает временную папку с именем Test. Затем он получает резервную копию этой папки, записывая ее размер и количество файлов. После окончания операции резервного копирования и проверки он удаляет папку Test и затем восстанавливает ее с резервной копии на ленте. По окончании операции восстановления он сравнивает размер и количество файлов восстановленной папки со значениями, записанными для исходной папки Test. Если они совпадают, то он считает, что система резервного копирования на ленту работает правильно. Если нет, он начинает поиск и устранение неисправностей.
Раз в месяц он восстанавливает свои базы данных Exchange на автономном сервере, который сконфигурирован приблизительно так же, как и его эксплуатируемый сервер. Затем он проверяет, что его базы данных действуют на автономном сервере. Эта проверка позволяет убедиться, что он может выполнять полное восстановление быстро и эффективно, и его система резервного копирования находится в работоспособном состоянии. Учиться восстановлению нужно до того, как "грянет гром" и придется сидеть на телефоне, непрерывно консультируясь со службой технической поддержки Microsoft. Лучше делать это, когда все спокойно, и можно позволить себе ошибки, работая на автономном сервере.
Кроме того, с периодичностью от четырех до шести недель он предлагает конечным пользователям обучение – обычно по вопросам, которые преобладали, когда пользователи обращались к нему за поддержкой. Использование этого подхода к "обслуживанию заказчиков" привело к устойчивому снижению количества обращений в службу технической поддержки, поскольку у него появились пользователи, которые стали лучше разбираться в системе и самостоятельно выполнять некоторые базовые операции, связанные с поиском и устранением неисправностей, такие как проверка разъемов или подсоединения принтера к сети.
Раз в квартал он разряжает батареи системы бесперебойного электропитания (UPS), чтобы убедиться, что программное обеспечение UPS корректно отключает его серверы. Будет лучше, если обнаружится, что программное обеспечение UPS не работает, во время теста, чем во время сбоя электропитания. Если при неожиданном нарушении электропитания UPS сразу отключит напряжение, подаваемое на сервер Exchange (вместо постепенного отключения), то это с большой вероятностью приведет к повреждению базы данных.
Кроме того, он ежеквартально проверяет, не появились ли модификации и обновления аппаратно-программного обеспечения для всех его серверов, и в случае новых обновлений он выполняет их инсталляцию. Для пользователей он следит за модификациями и пакетами обновлений различных программ, которые используются в его фирме, и в случае их появления проводит тестирование совместно с небольшим количеством надежных пользователей; затем, исключив то, что дает отрицательные результаты, он распространяет модификации на всю сеть. И, наконец, он ежеквартально проверяет охлаждающие вентиляторы на всех серверах, чтобы убедиться, что они продолжают хорошо работать.
Хорошее планирование позволило ему заслужить доверие своих руководителей. Он не жалеет времени, чтобы объяснить, что он делает и почему. Поэтому со временем ему удалось реализовать много стандартов, обеспечивающих безотказную работу сети. Профилактические меры, включенные в планирование, позволяют ему в большинстве случаев предвидеть возможные изменения в его сети, а не заниматься устранением неполадок.
Планирование пространства на диске
Рассмотрим некоторые вопросы планирования. Надеемся, что вы уделите достаточное внимание этому параграфу. Поскольку данная лекция посвящена группам хранения, мы рассмотрим здесь планирование таких аспектов, как объем пространства на диске, использование нескольких баз данных и нескольких групп хранения. (Для получения более подробных сведений по планированию для Exchange Server 2003 обратитесь к лекции 5.) Планируя объем пространства на диске для сервера Exchange 2003, следует учесть следующие ключевые факторы:
количество пользователей, которых нужно разместить на данном сервере Exchange;
типы пользователей, которых нужно разместить на данном сервере Exchange;
средний размер одного сообщения и одного вложения электронной почты, а также количество вложений, которое потребуется отправлять и получать пользователям;
количество и размер общих папок.
В следующих двух разделах описано, как рассчитать необходимый объем пространства на диске сервера Exchange.
Расчет пространства на диске для сообщений и вложений электронной почты
Прогнозирование интенсивности обмена сообщениями между пользователями информационной системы является нелегким делом. Некоторые пользователи отправляют и принимают лишь несколько сообщений в день. Другие отправляют и получают множество сообщений и некоторые – с большими вложениями. Очевидно, что при одинаковых возможностях оборудования можно разместить в одном хранилище почтовых ящиков больше пользователей с небольшим объемом корреспонденции. Это наиболее простой путь, но все же будет лучше, если разработать систему классификации для рассматриваемой среды и затем провести подсчеты, чтобы определить, сколько пользователей можно разместить в каждом хранилище, в каждой группе хранения и, наконец, на каждом сервере. Если получится составить приблизительную картину текущего использования системы обмена сообщениями, то представится возможным более точно прогнозировать требования к оборудованию и группам хранения.
Для достижения этой цели рекомендуется получить случайную выборку пользователей системы (не менее 15%) и затем провести анализ текущего использования электронной почты в папке Sent Items (Отправленные), чтобы получить представление о количестве сообщений, отправляемых каждый день, и о размере этих сообщений. Вы можете также определить, сколько сообщений содержат вложения, а раскрыв сообщения, – размеры этих вложений. Соображения безопасности могут не позволить получить эту информацию от некоторых пользователей, и в этих случаях попросите их заполнить небольшую анкету.
Собрав необходимые данные, их необходимо проанализировать. Эта часть работы состоит из расчета некоторых показателей. Рассмотрим следующий пример. Предположим, что проводится анализ по 45 пользователям (из 300) в течение 60 дней и определяется, что среднее количество сообщений электронной почты в день, приходящихся на одного пользователя, равно 14 с двумя вложениями. И еще предположим, что средний размер каждого сообщения составляет 1 Кб, а средний размер каждого вложения – 200 Кб. Расчет проводится следующим образом:
14 сообщений x 1 Кб = 14 Кб в день для сообщений электронной почты;
2 вложения x 200 Кб = 400 Кб в день для вложений;
средний объем используемого пространства на диске: 828 Кб в день (414 Кб для хранилища и 414 Кб для журналов транзакций);
828 Кб x 300 пользователей = 248400 Кб (248,4 Мб) пространства на диске в день для всех 300 пользователей. На два месяца (60 дней) приходится 44 рабочих дня, то есть потребуется 10929 Мб (10,9 Гб) пространства на диске.
Это последнее значение несколько неточно, поскольку журналы транзакций не хранятся бесконечно долго. В конечном счете, система ESE удалит старые журналы, освобождая пространство на диске, которое будет снова использоваться журналами транзакций. Поэтому давайте предположим, что ESE хранит только часть журналов за последнюю неделю, то есть 5 x 414 Кб = 2070 Кб. Таким образом, для работы Exchange Server 2003 через два месяца потребуется только 5466870 Кб, то есть 5.4 Гб (44 дня x 414 Кб в среднем х 300 пользователей плюс 2070 Кб для журналов).
И это еще не все. Мы только определили объем пространства на диске, необходимый для записи сообщений и вложений электронной почты. Нам нужно еще оценить общие папки и производительность устройств резервного копирования.
Расчет пространства на диске для общих папок
Чтобы показать, как рассчитывается объем пространства на диске, необходимого для общих папок, предположим, что каждый пользователь помещает в общие папки примерно три документа в день со средним размером одного документа 6 Кб. (Если этот размер документа кажется слишком большим, обратитесь к лекции 2, где рассматривается архитектура хранилища. Мы еще не раз будем рассматривать хранение различных типов документов в Exchange.) Рассчитаем объем пространства на диске для общих папок следующим образом: 3 документа x 300 пользователей x 6 Кб x 2 (поскольку каждый документ записывается в хранилище и журнал транзакций). В результате получаем, что для размещения документов пользователей в общих папках требуется 10800 Кб (10,8 Мб) пространства на диске. На 44 дня потребуется 237600 Кб (237,6 Мб) плюс 27000 Кб для журналов транзакций (3 документа х 300 пользователей х 6 Кб х 5 дней),
что даст в сумме за два месяца 264600 Кб (264,6 Мб) пространства на диске, необходимого для общих папок. Таким образом, потребуется 5,46 Гб для сообщений электронной почты и 264,6 Мб для общих папок, или приблизительно 5,7 Гб на период в два месяца. Но планирование еще не закончено. Теперь нужно определить, как использовать эти значения в процессе планирования групп хранения.
Планирование нескольких групп хранения
Получив оценку необходимого пространства на диске, необходимо оценить, сколько потребуется групп хранения. Одним из факторов, который нужно учесть, является различие приоритетов работы, которую выполняют пользователи. Предположим, что 20 из 300 пользователей рассматриваемой системы выполняют критически важную работу. Возможно, это персонал отдела продаж, который принимает заказы по телефону или обрабатывает заказы клиентов, размещаемые в общей папке, представленной на веб-сайте. Предположим, что при отключении этих пользователей даже на 15 минут компания теряет более 50000 долларов. При подобной ситуации стоит подумать о том, чтобы разбить этих пользователей на две группы и поместить каждую группу в ее собственные хранилища почтовых ящиков и общих папок. Однако здесь нет необходимости размещать их в отдельной группе хранения.
Причиной такой рекомендации является то, что в случае повреждения других баз данных эти пользователи смогут продолжать свою работу, поскольку вы можете отключить и восстанавливать одно или несколько хранилищ, в то время как другие хранилища той же группы хранения продолжают работать. И если потребуется восстановление базы данных одной группы этих пользователей, это будет сделано быстро, поскольку эта база данных намного меньше, чем база данных всей компании, в которой хранится информация остальных 280 пользователей. Кроме того, поскольку критические пользователи распределены по двум базам данных, вторая половина группы сможет продолжать работу. Таким образом, следует планировать группы хранения, уделяя большее внимание вопросам аварийного восстановления, чем вопросам использования пространства на диске.
Планирование производительности устройств резервного копирования
Еще одним фактором в планировании групп хранения является уровень производительности, который потребуется при восстановлении. Предположим, что вы приобрели ленточный накопитель с максимальной скоростью 10 Гб в час, или 166,6 Mб в минуту. При такой скорости восстановление баз данных с резервной копии на ленте займет приблизительно 35 минут, если все пользователи включены в одну базу данных. С учетом времени, необходимого для диагностирования проблемы, поиска лент и восстановления, можно предположить, что пользователи системы не смогут пользоваться электронной почтой и общими папками от одного до двух часов (в зависимости от характера проблемы, а также от времени, которое потребуется, чтобы вернуться к точке, с которой можно начать операцию восстановления).
В некоторых компаниях отключение системы на 1-2 часа не столь существенно. Для других компаний это катастрофа. Поэтому следует определить, сколько времени пользователи смогут обходиться без услуг Exchange во время восстановления. Консультации с руководителем помогут определить длительность приемлемого простоя в случае аварии.
Предположим, что в результате этих консультаций определено, что ни один из пользователей не должен оставаться без услуг Exchange более 30 минут. Чтобы запланировать меры, позволяющие укладываться в это максимальное время простоя, необходимо взять рассчитанное выше время восстановления и разделить его на максимальное время простоя, допускаемое политикой руководства. В результате будет получено количество хранилищ, которое потребуется создать на сервере Exchange. Чтобы определить минимальное количество групп хранения, которое вам потребуется, разделите количество хранилищ на 5 (количество хранилищ на одну группу хранения).
В данном примере мы знаем, что восстановление данных для 300 пользователей потребует 35 минут. Однако это время соответствует хранению данных только в течение двух месяцев. В большинстве компаний хранят информацию намного дольше. Поэтому, если мы примем в данном примере более реальный период хранения в один год, то нам потребуется умножить рассчитанные выше значения на 6, чтобы определить картину восстановления для годичного запаса данных. Таким образом, восстановление баз данных, содержащих накопленную за год информацию, займет 210 минут (3,5 часа). Что делать в этом случае? А ведь нам нужно, чтобы базы данных можно было восстанавливать в течение 15 минут, чтобы был запас времени, позволяющий уложиться в 30-минутное требование максимального простоя, принятое в рассматриваемой компании. Поэтому нам потребуется создать не менее 14 отдельных хранилищ почтовых ящиков и 14 отдельных хранилищ общих папок (210/15).
Здесь, конечно, предполагается, что будут использоваться базы данных приблизительно одинакового размера. Если некоторые базы данных оказываются намного больше, чем допускается временем восстановления, то имеет смысл создать дополнительные хранилища или переместить почтовые ящики некоторых пользователей в другие хранилища, чтобы размеры хранилищ отвечали поставленным целям.
В данном случае нам потребуется не менее пяти групп хранения, чтобы в них можно было поместить 28 хранилищ. Поскольку на одном сервере допускается не более четырех групп хранения, то для размещения этих хранилищ нам потребуются два сервера Exchange. Лучше всего по возможности равномерно распределить эти базы данных между двумя серверами. Кроме того, поскольку в системе на одну группу хранения приходится один набор журналов транзакций, то увеличение количества групп хранения будет препятствовать образованию большого количества журналов транзакций на одну группу хранения, хотя и приведет к общему увеличению количества журналов транзакций для системы в целом.
Создание группы хранения
Группа хранения создается быстро и без проблем. Напомним, что на одном сервере Exchange 2003 нельзя создать более четырех групп хранения. При попытке сделать это появится сообщение об ошибке.
Чтобы создать группу хранения, откройте оснастку Exchange System и найдите нужный объект-сервер. Щелкните правой кнопкой мыши на этом объекте-сервере, укажите пункт New (Создать) и выберите пункт Storage Group (Группа хранения) из соответствующего подменю (рис 11.2). Появится страница свойств новой группы хранения (рис 11.3). При вводе имени группы хранения станет видно, что это имя одновременно вводится во все три поля. Это защищает от ошибок в местоположении журналов транзакций (Transaction log location) или системного пути доступа к хранилищам (System path location).
(рис 11.3) Создание группы хранения(рис 11.2) Страница свойств новой группы храненияНа странице свойств можно включить опции Zero Out Deleted Database Pages (Обнуление удаленных страниц баз данных) и Enable Circular Logging (Активизировать циклическое ведение журналов). Параметр Zero Out Deleted Database Pages указывает, чтобы при резервном копировании в режиме он-лайн во все удаленные страницы всех хранилищ, входящих в данную группу хранения, записывались нули. Установите этот флажок, если хотите, чтобы удаленные данные нельзя было восстановить. Это потребует дополнительной обработки в процессе копирования и замедлит процесс, но улучшит защиту от доступа к удаленным данным. В поле Log File Prefix (Префикс для файлов журналов) можно указывать префикс, который помещается перед началом имени каждого файла журнала. Это позволяет хранить все файлы журналов в одном месте и при этом видеть, какие журналы относятся к соответствующей группе хранения.
Опция Enable Circular Logging позволяет использовать циклическое ведение журналов для данной группы хранения. Активизируйте это средство только для тех групп хранения, которые не содержат критически важных данных. Использование циклического ведения журналов не приводит к снижению количества журналов транзакций, создаваемых процессом Store системы ESE, но лишает возможности восстановления баз данных вплоть до точки аварийного отказа. При циклическом ведении журналов возможно осуществить восстановление только с последней полной резервной копии. Прежде чем выбрать эту опцию, тщательно продумайте возможные последствия потери новых данных в базах данных Exchange.
В окне вкладки Details (Дополнительно) группы хранения можно вводить примечания по данной группе хранения, например, кто ее создал, и для чего она предназначена.
Создание хранилища
В группе хранения можно создавать два вида хранилищ – хранилище почтовых ящиков для сообщений и хранилище общих папок для доступа к общим папкам. Каждое хранилище содержит свои файлы .EDB и .STM. Хранилище нельзя создать, пока не создана группа хранения. При первоначальной инсталляции Exchange Server 2003 создается группа хранения с именем First Storage Group (Первая группа хранения), которую можно после этого переименовать, а также хранилище почтовых ящиков и хранилище общих папок внутри этой группы хранения.
Создание хранилища почтовых ящиков
Чтобы создать новое хранилище почтовых ящиков, щелкните правой кнопкой мыши на группе хранения, в которой нужно создать хранилище, наведите указатель мыши на пункт New (Создать) и затем выберите опцию Mailbox Store (Хранилище почтовых ящиков). Появится страница свойств, показанная на рис 11.4. В окне вкладки General (Общие) введите имя хранилища почтовых ящиков и затем щелкните на кнопке Browse (Обзор) рядом с полем Default Public Store (Хранилище общих папок по умолчанию), чтобы увидеть список хранилищ общих папок, с которыми можно ассоциировать (связать) данное хранилище почтовых ящиков (рис 11.5). Выделите в этом списке нужное хранилище общих папок и нажмите OK.
(рис 11.5) Вкладка General страницы свойств нового хранилища почтовых ящиков(рис 11.4) Выбор хранилища общих папок по умолчанию для нового хранилища почтовых ящиковПримечание. Указание хранилища общих папок для нового хранилища почтовых ящиков требуется потому, что каждый пользователь Exchange для доступа к общим папкам должен иметь какое-то установленное по умолчанию хранилище общих папок. Выбор хранилища общих папок в этом окне не ограничивает пользователя в доступе к другим хранилищам общих папок или деревьям общих папок. Это точка входа во всю область общих папок.
Выбрав хранилище общих папок, ассоциированное с данным хранилищем почтовых ящиков, нажмите кнопку Browse (Обзор) рядом с полем Default Offline Address List (Автономный список адресов по умолчанию), чтобы выбрать принимаемый по умолчанию автономный список адресов для пользователей, размещаемых в этом хранилище (см. рис 11.6). Пользователи по-прежнему смогут загружать другие автономные списки адресов; в этом поле просто указывается список по умолчанию.
(рис 11.6) Выбор автономного списка адресов по умолчанию для нового хранилища почтовых ящиковЕсли необходимо, чтобы в данном хранилище почтовых ящиков поддерживался стандарт S/MIME (Secure/Multipurpose Internet Mail Extensions – защищенные/многоцелевые почтовые расширения интернета), включите опцию Clients Support S/MIME Signatures (Клиентская поддержка подписей S/MIME). (Подробнее о стандарте S/MIME и случаях его использования рассказывается в части IV.) Если требуется, чтобы все входящие сообщения преобразовывались в 10-точечный шрифт Courier, установите флажок Display Plain Text Messages In A Fixed-Sized Font (Использовать для отображения сообщений с открытым текстом шрифт фиксированного размера).
На вкладке Database (База данных) этой страницы свойств (см. рис 11.7) указывается физическое местоположение двух файлов, образующих данное хранилище. Несмотря на то что можно перемещаться в удаленные точки общего доступа на другом сервере, в Exchange Server 2003 не разрешается связывать любой из файлов с совместно используемым сетевым ресурсом. Однако можно создать точку монтирования тома и указать ее как местоположение для любого из файлов. Это может оказаться полезным, если известно, что в определенную базу данных будут помещать большие файлы или много файлов, поскольку вы можете создать для них специальный раздел. Также можно указывать нужное время запуска обслуживающих утилит для данного хранилища.
Опция Do Not Mount This Store At Start-Up (Не монтировать это хранилище при запуске) позволяет указывать, что это хранилище не монтируется в момент запуска. По умолчанию данное хранилище монтируется при запуске служб Exchange. И, наконец, можно включить опцию This Database Can Be Overwritten By A Restore (Эта база данных может быть перезаписана при восстановлении). Этот параметр связан с глобально уникальным идентификатором данной базы данных (GUID).
(рис 11.7) Вкладка Database страницы свойств нового хранилища почтовых ящиковКаждая база данных имеет свой идентификатор GUID. Этот идентификатор хранится в базе данных системы ESE в одной из таблиц общего назначения. (Подробнее о системе ESE рассказывалось в лекции 2.) Идентификатор GUID базы данных вместе с физическим путем доступа на жестком диске также хранится в Active Directory. При запуске процесса Store.exe одной из его задач является монтирование базы данных. Но прежде чем монтировать базу данных, процесс Store.exe сравнивает GUID этой базы данных, который он находит в самой базе данных, с GUID этой базы данных в Active Directory. Сравниваются также пути доступа к каталогам.
Если все совпадает, то база данных монтируется. Но если какие-то элементы информации не совпадают, то процесс Store.exe не выполняет запуск базы данных. Это может произойти, если файлы базы данных перемещены с другого сервера или каталога в текущее местоположение. Процесс Store.exe требует совпадения идентификаторов GUID для предотвращения случайного перемещения базы данных в другое место и ее запуска в другой группе хранения с другими журналами транзакций.
Если включена опция This Database Can Be Overwritten By A Restore, то в процессе Store.exe предполагается, что действительно требуется перемещение этой базы данных в данное местоположение. Поэтому при запуске процесс Store.exe "исправит" базу данных, изменив ее GUID в самой базе данных на GUID, который хранится в Active Directory; при следующей попытке монтирования идентификаторы GUID совпадут, и база данных будет смонтирована. И, наконец, в результате этого процесса данный флажок будет сброшен.
Примечание. Если при монтировании базы данных процесс Store.exe вообще не найдет никакой базы данных, соответствующей указанному пути доступа, то этот процесс предложит создать новую базу данных. Опция This Database Can Be Overwritten By A Restore используется только в тех случаях, когда процесс Store.exe ищет базу данных в соответствии с указанным путем доступа и обнаруживает, что это неверная база данных, поскольку идентификаторы GUID не совпадают.
Опция This Database Can Be Overwritten By A Restore действует аналогичным образом при восстановлении. При вызове AddDatabase() процедура Ntbackup передает процессу Store.exe идентификатор GUID, имя базы данных и имя группы хранения. Если они совпадают, то процесс Store.exe передает в обратном направлении местоположения, где должны быть восстановлены данные файлы. Если идентификаторы GUID не совпадают, то в случае установки этого флажка процесс Store.exe передает процессу резервного копирования информацию о том, куда нужно записать файлы данной базы данных.
Примечание. Перемещая базы данных и включая опцию This Database Can Be Overwritten By A Restore, можно создавать несколько различных баз данных с одинаковым идентификатором GUID в системе Exchange Server 2003. При попытке монтировать обе базы данных будет смонтирована только одна из них (из-за конфликта идентификаторов GUID). Фирма Microsoft ни при каких обстоятельствах не рекомендует содержать две базы данных с одинаковыми GUID или выполнять "перестановку" баз данных. Возможны непредсказуемые и нежелательные результаты.
На вкладке Limits (Пределы хранения), показанной на рис 11.8, задается длительность хранения удаленных элементов и интервалы выдачи предупреждающих сообщений по хранению для данного хранилища почтовых ящиков. Можно задать эти параметры глобально, создав политику почтовых ящиков в контейнере Policies (Политики). Значения, заданные с помощью политики, нельзя изменить на уровне сервера.
Средства вкладки Full-Text Indexing (Индексирование по всему тексту) будут недоступны (затенены) при создании хранилища почтовых ящиков. Но после создания хранилища можно активизировать индексирование по всему тексту. Для этого нужно щелкнуть правой кнопкой мыши на имени хранилища в окне оснастки Exchange System, указать на пункт All Tasks (Все задачи) и выбрать Create Full Text Index (Создать индекс по всему тексту). После создания индекса внутри контейнера Full-Text Indexing появятся новые объекты (рис 11.9), и параметры внутри вкладки Full-Text Indexing будут доступны для конфигурирования. Подробнее об архитектуре индексирования по всему тексту рассказано в лекции 2. О том, как работать с индексированием по всему тексту, рассказывается ниже в разделе "Создание индекса по всему тексту".
(рис 11.9) Вкладка Limits страницы свойств нового хранилища почтовых ящиков(рис 11.8) Объекты в контейнере Full-Text Indexing для хранилища почтовых ящиков.На вкладке Details (Дополнительно) страницы свойств хранилища почтовых ящиков можно ввести административные замечания по хранилищу почтовых ящиков, такие как имя создателя хранилища и назначение этого хранилища. На вкладке Security (Безопасность), которая появляется только на странице свойств успешно созданного хранилища почтовых ящиков, содержатся полномочия для пользователей и групп, имеющих доступ к данному хранилищу. Лучше всего оставить в этом окне заданные по умолчанию значения, если только нет особых причин к их изменению. И, наконец, в окне вкладки Policies (Политики) приводятся все групповые политики, которые применяются к рассматриваемой базе данных. Тем не менее, нельзя конфигурировать групповую политику в этом окне.
Примечание. В группе хранения можно создавать новые хранилища общих папок. Этот процесс описывается в лекции 10.
Перемещение файлов журналов транзакций и файлов баз данных
В пакет Exchange Server 5.5 компания Microsoft включила средство Microsoft Exchange Optimizer – мастер с графическим интерфейсом, используемый для перемещения баз данных из одного места в другое. В Exchange Server 2003 этот процесс стал осуществляться вручную, и он требует тщательного внимания со стороны лица, осуществляющего перемещение файлов. Поскольку все хранилища связаны с одним набором журналов транзакций, нельзя переместить какое-либо одно хранилище определенной группы хранения в другое место без перемещения вместе с ним всех остальных хранилищ. Однако существует возможность перемещать файлы внутри базы данных в отдельное место, что будет рассмотрено чуть ниже.
При попытке изменить местоположение файлов журналов транзакций для какой-либо группы хранения или хранилища в группе хранения на экране появится предупреждающее сообщение о том, что текущие резервные копии будут неприменимы после этого перемещения. Причиной того, что в результате перемещения базы данных текущие резервные копии становятся недействительными, является то, что журналы транзакций, для которых созданы резервные копии, содержат в своих заголовках жестко кодированный путь доступа к базе данных. После перемещения базы данных заголовки в резервных копиях журналов транзакций будут по-прежнему содержать указатель на старое местоположение базы данных. Таким образом, процесс восстановления не будет работать, поскольку он не сможет найти базу данных, которая поддерживается этими журналами транзакций. (Подробнее об этом рассказывается в лекции 2.)
Поскольку компания Microsoft рекомендует содержать журнал транзакций и хранилища на разных дисководах, то можно изменить местоположение файлов транзакций, баз данных хранилищ или то и другое с помощью вкладки General (Общие) окна свойств соответствующей группы хранения (см. выше рис 11.3). Выберите новое местоположение, чтобы разместить там файлы или базы данных, после чего произойдет следующее.
Все хранилища будут демонтированы.
Произойдет перемещение выбранных файлов или баз данных.
Хранилища будут снова смонтированы.
Как мы уже отмечали чуть выше, разместить файлы баз данных хранилища можно в двух разных местах. Чтобы изменить местоположение файлов баз данных хранилища, используйте вкладку Database (База данных) в окне свойств данного хранилища (см. выше рис 11.7). Сначала демонтируйте данное хранилище, а затем введите новое местоположение в каталоге для файлов баз данных. Не обязательно помещать их в одном месте. И, как мы отмечали выше, есть возможность поместить базы данных в какой-либо точке монтирования тома. После выбора нового местоположения в каталоге и нажатия кнопки OK произойдет перемещение баз данных и обновление Active Directory. При этом также происходит автоматическое обновление заголовков в файлах транзакций. Монтирование хранилища происходит обычным образом.
Удаление хранилища или группы хранения
Прежде чем удалять хранилище или группу хранения, необходимо удалить их содержимое. Поэтому перед удалением группы хранения нужно удалить хранилища почтовых ящиков и общих папок.
Удаление хранилища почтовых ящиков
Прежде чем удалить хранилище почтовых ящиков, необходимо создать резервную копию всех его данных, чтобы гарантировать восстановление любой важной информации, удаленной вместе с этим хранилищем. Закончив резервное копирование, проследите за тем, чтобы переместить в другое хранилище все почтовые ящики, которые нужно сохранить. Если требуется удалить только одно хранилище, то можно переместить его почтовые ящики в другое хранилище той же самой группы хранения. Конечно, если планируется удалить всю группу хранения, то следует переместить почтовые ящики в хранилище другой группы хранения. Можно удалить хранилище почтовых ящиков, щелкнув на нем правой кнопкой мыши в окне оснастки Exchange System и выбрав пункт Delete (Удалить).
Если в очереди SMTP имеются сообщения, ожидающие внешней доставки, то будет получено сообщение об ошибке, информирующее об этом обстоятельстве. Если все-таки принято решение выполнить удаление, то будет предложено выбрать новое хранилище, которое будет использоваться как входная очередь для сообщений SMTP.
Удаление хранилища общих папок
Удаление хранилища общих папок осуществляется несколько сложнее, чем удаление хранилища почтовых ящиков. Во-первых, удаляемое хранилище не должно быть последним хранилищем или единственным хранилищем, содержащим дерево общих папок. Если это так, то нельзя будет удалить это хранилище общих папок. Во-вторых, это хранилище не должно быть принятым по умолчанию хранилищем общих папок для любых хранилищ почтовых ящиков или пользователей. Чтобы определить это в конкретном случае, нужно просмотреть страницу свойств каждого хранилища почтовых ящиков и определить, не использует ли оно удаляемое хранилище как принятое по умолчанию хранилище общих папок. Если да, то необходимо изменить конфигурацию этого хранилища почтовых ящиков, указав использование по умолчанию другого хранилища общих папок. В-третьих, если удаляемое хранилище общих папок содержит единственную реплику одной или нескольких папок, то появится предупреждение, что будут потеряны все данные, если сначала
не реплицировать эти данные в другое хранилище.
Удаление группы хранения
Если не остается никаких хранилищ, связанных с данной группой хранения, то ее можно удалить, щелкнув правой кнопкой мыши на этой группе в окне оснастки Exchange System и выбрав пункт Delete (Удалить).
Создание индекса по всему тексту
В хранилище информации происходит создание и управление индексами общих ключевых полей для быстрого просмотра и поиска. Если активизировать индексирование по всему тексту, то соответствующий индекс будет создаваться перед поиском в программе-клиенте, что позволит выполнять более быстрый поиск. Индексирование по всему тексту упрощает поиск документов (включая текстовые вложения) пользователями Outlook в хранилище информации. Для повышения гибкости каждое хранилище информации можно индексировать по отдельности. Процесс индексирования описан в лекции 2.
Чтобы включить индексирование, щелкните правой кнопкой мыши на хранилище, которое нужно индексировать, укажите на пункт All Tasks (Все задачи) и выберите опцию Create Full-Text Index (Создать индекс по всему тексту). Хотя выбранный пункт называется "Создать индекс по всему тексту", этой командой лишь активизируется средство индексирования для данного хранилища. Будет получен запрос, где необходимо указать местоположение, в котором должен быть создан соответствующий каталог. Указав местоположение, нажмите OK, после чего будут созданы объекты индексирования. Эти новые объекты отобразятся внутри объекта Full-Text Indexing (Индексирование по всему тексту) (см. рис 11.9).
Сначала объект Index State (Состояние индекса) указывет, что для данного хранилища еще не создавался индекс по всему тексту. Кроме того, объект Last Build Time (Время последнего построения индекса) обозначает, что данный каталог еще не создавался. Таким образом, несмотря на то что объекты индексирования созданы, еще не получен индекс по всему тексту.
Чтобы создать индекс по всему тексту, щелкните правой кнопкой мыши на данном объекте-хранилище, укажите на пункт All Tasks (Все задачи) и выберите опцию Start Full Population (Запуск по всей информации) или Start Incremental Population (Запуск по новой информации). При выборе варианта Start Full Population индексируются все имеющиеся данные, а выбор Start Incremental Population приводит к индексированию только той информации, которая поступила или была модифицирована с момента последнего индексирования по всей информации. В зависимости от объема информации этот процесс может занять от нескольких минут до нескольких часов.
После создания индекса станет видно, что увеличилось значение контейнера Number Of Documents Indexed (Количество индексированных документов), а также значение контейнера Index Size (MB) [Размер индекса (Мб)]. Также отобразится время, когда произошло последнее построение индекса для данного хранилища, и текущее местоположение баз данных этого индекса.
Заключение
В данной лекции рассказывалось о том, как осуществляется администрирование групп хранения в организации Exchange. Теперь вам должна быть понятна архитектура группы хранения и то, как создавать и осуществлять управление группами хранения и хранилищами. Вам также должно быть ясно, как активизировать индексирование и создавать полнотекстовый индекс для хранилища. В следующей лекции рассказывается о том, как реализовать и администрировать группы маршрутизации.
