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

1. Проверка целостности базы данных

Не секрет, что версии, предшествующие Exchange Server 2003, были весьма уязвимы. Поначалу проблема не носила катастрофического характера, но со временем усугублялась. На одном крупном предприятии сотрудники, сами того не ведая, в течение нескольких месяцев архивировали испорченные данные Exchange Server. Масштаб проблемы нарастал, пока наконец испорченная база данных не перестала монтироваться.

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

Лучшее средство тестирования баз данных — ISINTEG, утилита командной строки, с помощью которой можно проверить целостность Information Store и устранить неполадки, связанные со сбоями и несоответствиями. Для тестирования Information Stores нужно демонтировать хранилище, открыв диспетчер Exchange System Manager и пройдя по дереву консоли к Administrative Groups, нужной административной группе, Servers, нужному серверу и, наконец, группе хранения, содержащей демонтируемое хранилище. Щелкните правой кнопкой мыши на хранилище и выберите команду Dismount Store из контекстного меню (но сохраните активной службу Information Store; это необходимо для ISINTEG). Убедитесь, что архивная копия в порядке, а на томе, содержащем хранилище, много свободного места. Полезное правило — иметь достаточно свободного места для записи копии базы данных плюс еще 20%.

Откройте окно командной строки и перейдите в папку Program Filesexchsrvrin. Чтобы проверить базы данных и устранить обнаруженные неисправности, нужно выполнить следующую команду:

ISINTEG -S servername
–fix -test alltests

В этой команде ключ -S указывает имя сервера, содержащего базу данных, которую требуется проверить или восстановить, ключ -ALLTESTS настраивает утилиту на выполнение полного набора тестов хранилища, а благодаря ключу -FIX будут предприняты попытки исправить все обнаруженные неполадки. Следует помнить, что ISINTEG устраняет только несогласованности в базах данных. Инструмент не устраняет физические неполадки внутри базы данных, такие как поврежденные страницы базы данных. Для этого нужно использовать утилиту ESEUTIL, которая будет описана ниже.

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

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

2. Тестирование целостности базы данных

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

Проверка с помощью ESEUTIL не принесет вреда базе данных, но может занять больше времени, чем проверка ISINTEG. Если ESEUTIL обнаруживает неполадки, можно использовать ключ /P, чтобы перестроить базу данных и исправить ошибку. Ключ /P следует использовать только как последнюю меру, поскольку (как и ключ -FIX команды ISINTEG) он может повредить базу данных. Всегда следует создавать хорошую резервную копию, прежде чем вносить какие-либо исправления с помощью ESEUTIL. Но для общего тестирования можно свободно использовать ESEUTIL. При этом нужно убедиться, что база данных работает в автономном режиме, открыть окно командной строки, перейти в папку Program FilesExchsrvrBin и ввести команду:

ESEUTIL /G имя_базы_данных

3. Автономная дефрагментация

С помощью ESEUTIL полезно время от времени выполнять автономную дефрагментацию хранилищ Exchange Information Stores. Exchange Server 2003 каждую ночь выполняет оперативную дефрагментацию Information Stores. В сущности, автономная дефрагментация предназначена для того же, но база данных при этом становится более компактной.

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

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

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

ESEUTIL /D имя_базы_данных

4. Регулярное тестирование архивных копий

Надеюсь, что, прочитав эту статью, читатели усвоят, что время влияет на сервер Exchange 2003, а серверные аппаратные средства не вечны (о том, как продлить срок эксплуатации оборудования, рассказано во врезке «Четыре совета по обслуживанию аппаратных средств сервера»). Поскольку отказы сервера не всегда прогнозируемы, важно регулярно тестировать архивные копии. Таким образом, администратор будет уверен, что сможет восстановить потерянные данные в случае аварии.

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

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

5. Проверка регулярности цикла ночного обслуживания

Exchange Server 2003 проектировался как вполне самодостаточный продукт. Следующие 11 задач обслуживания выполняются автоматически:

1). Очистка индексов хранилищ почтовых ящиков и общих папок.
2). Обслуживание «меток на удаление» почтовых ящиков и общих папок.
3). Удаление просроченных сообщений из «корзины» хранилищ почтовых ящиков и общих папок.
4). Удаление просроченных сообщений из общих папок.
5). Окончательное удаление общих папок с «метками на удаление» возрастом более 180 дней.
6). Разрешение конфликтов сообщений в общих папках.
7). Обновление информации о версии сервера для общих папок.
8). Проверка и удаление дублированных папок сайта в хранилищах общих папок.
9). Окончательное удаление почтовых ящиков в хранилищах почтовых ящиков.
10). Проверка таблицы сообщений для сообщений-сирот (сообщения со значением счетчика ссылок 0).
11). Оперативная дефрагментация хранилища.

Выполнение всех 11 задач в большом информационном хранилище может занять много времени, и Exchange должен выполнять задачи обслуживания, не прерывая обычной работы. В большинстве случаев для этого приходится проводить обслуживание ночью. Из-за нехватки времени для выполнения всех задач каждую ночь Exchange Server решает задачи в порядке приоритета с учетом их важности и времени предыдущего выполнения. У первых 10 задач приоритет одинаковый. Но 11-я задача (оперативная дефрагментация хранилища) считается гораздо более важной, чем остальные.

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

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

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

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

По умолчанию обслуживание каждого хранилища планируется с полуночи до 4:00 утра. Чтобы изменить расписание, откройте диспетчер Exchange System Manager и перейдите по дереву консоли к Administrative Groups, нужной административной группе, Servers, нужному серверу, группе хранилищ и хранилищу. Щелкните на хранилище правой кнопкой мыши и выберите команду Properties из контекстного меню. Из списка свойств хранилища выберите вкладку Database. Как показано на экране, вкладка Database содержит раскрывающийся список Maintenance Interval, который используется для выбора четырехчасового блока времени для ежедневного или еженощного периода обслуживания. Или же можно нажать кнопку Customize, чтобы указать иной интервал обслуживания.

Экран. Определение интервала обслуживания хранилища

6. Ежедневная проверка журналов событий

Для контроля серверов Exchange широко используются такие продукты, как Microsoft Operations Manager (MOM) и System Center Operations Manager 2007. Если эти программы не применяются, следует ежедневно проверять журналы событий. Иногда события, внесенные в журнал приложения, указывают на потенциальные проблемы. Упреждающие проверки журналов дают возможность устранить аномалии, прежде чем они превратятся в неисправности. Простой пример: журналы событий могут предупредить о том, что на диске остается мало места. Администратор может переместить какие-нибудь объекты или установить диск большей емкости, прежде чем ситуация выйдет из-под контроля.

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

Лекарство от старости

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

Брайен Поуси (http://www.brienposey.com) — вице-президент по исследованиям компании Relevant Technologies. Автор статей на технические темы для различных изданий и Web-сайтов


Четыре совета по обслуживаню аппаратных средств сервера

Аппаратные средства не вечны. Но срок эксплуатации серверного оборудования можно продлить, если выполнять практические рекомендации по обслуживанию

1. Изучите свой сервер

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

Большинство серверов содержат механизмы для прогнозирования отказов дисков. Эти механизмы не безупречны с точки зрения надежности, но к их предупреждениям нужно прислушиваться. Проблема в том, что не существует отраслевого стандарта для предупреждений об отказах дисков. Один из наиболее широко используемых механизмов — SMART, но даже эту технологию различные изготовители реализуют по-разному, поэтому трудно угадать, каким будет предупреждение о приближающемся отказе. Одни серверы могут выдать предупреждение через операционную систему, другие — только через BIOS или светодиод. Важно знать, какой метод используется в сервере, чтобы распознать признаки надвигающегося отказа и периодически проверять состояние дисков сервера.

2. Проверяйте наличие дисков

Компания Microsoft рекомендует объединять базы данных Exchange Server в массивы RAID, обеспечивающие как повышенное быстродействие, так и отказоустойчивость. Но в некоторых случаях отказоустойчивый массив создает ложное чувство безопасности.

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

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

3. Удаляйте пыль

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

С пылью связаны три типа серверных неполадок. Во-первых, пыль нарушает работу накопителей CD и DVD. Пыль может покрыть линзу лазера или помешать ее правильному перемещению. В результате линза будет перемещаться медленно или ненадежно или даже совсем перестанет работать.

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

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

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

4. Проверьте батареи

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

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

Таблица. Полезные события обслуживания

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF