Для системного администратора

Каждому администратору, обслуживающему систему Exchange Server, хочется иметь информацию о малейших ее сбоях. Многие разумно предпочитают заниматься незначительными неполадками, чтобы потом не устранять более масштабные проблемы. Возможно, кто-то из читателей полагает, что для этого требуется программный пакет средств мониторинга и управления, такой, например, как Microsoft Operations Manager (MOM), OpenView компании HP или Spotlight on Exchange компании Quest Software. Разумеется, перечисленные изделия наделены массой полезных функций, но многие наверняка будут удивлены обилием средств мониторинга и контроля, реализованных в Exchange и Windows. Администратор может следить за работой служб и приложений, управлять службами и получать уведомления без каких-либо дополнительных затрат. С помощью встроенных инструментов можно управлять сразу несколькими серверами. Более сложные инструменты могут быть полезны при переходе от небольшой группы серверов к организациям Exchange, состоящим из множества серверов, расположенных в различных местах, или в тех случаях, когда необходимо строго соблюдать соглашения об уровне обслуживания (Service Level Agreements, SLA), в которых большое значение придается извещениям о проблемах на ранних стадиях.

Основы мониторинга служб

Функционирует ли интересующий меня сервер? Пожалуй, на этот вопрос ответить проще всего, но между тем он относится к числу самых важных. Многие администраторы, как правило, проверяют состояние серверов средствами диспетчера Exchange System Manager (ESM).

Чтобы проверить состояние любого виртуального сервера, нужно раскрыть узел протокола в контейнере Protocols, расположенном под сервером, а затем найти знакомый кружок красного цвета. Подобная мера вполне целесообразна в качестве первого шага. Но при этом мы узнаем только одно — активен ли виртуальный сервер. Базовая служба не может быть остановлена без какого-либо указания на это в ESM, кроме красного «X», поэтому нам непросто определить, что именно случилось: остановлен экземпляр виртуального сервера, произошел сбой базовой службы или эта служба была отключена.

Более надежный источник данных — приложение панели управления Services (services.msc). Эта небольшая служебная программа позволяет просматривать и изменять состояние служб Exchange, а также служб, необходимых для их функционирования. Для подключения к другому серверу достаточно правой клавишей мыши щелкнуть на значке Services (Local) и выбрать команду Connect to another computer. Это очень удобно в тех случаях, когда требуется управлять серверами с помощью настольной системы или ноутбука. Приложение позволяет определять, функционирует ли служба в данный момент; администратор может останавливать и перезапускать службы, а также задавать условия их запуска. Приложение Services можно использовать для получения дополнительной информации в тех случаях, когда ESM сообщает, что служба не функционирует в штатном режиме.

Разумеется, не каждый администратор захочет выполнять любую задачу с помощью графического интерфейса. Службами можно управлять и из командной строки. Для этого существует два метода: проверенные временем команды NET и команда Sc. Скорее всего, многие уже знакомы с командами NET START и NET STOP; при их использовании необходимо вводить имя службы, которой предстоит управлять (скажем, с помощью команды NET STOP msexchangeIS можно остановить выполнение службы Information Store). Если ввести только имя команды NET START без указания аргументов, на экране будет отображен список всех служб, функционирующих в системе, в которой вы зарегистрировались; эта функция может быть полезной, когда требуется установить, какие службы функционируют в данный момент. Если же попытаться остановить службу, от функционирования которой зависят другие службы (скажем, System Attendant), NET STOP предложит подтвердить команду, если вы не присоединили к ней переключатель /y.

Команда Sc более функциональна, но для ее использования придется проделать кое-какую дополнительную работу. Для начала полезно вспомнить, что с помощью команды Sc администратор может обращаться к службам на других серверах; достаточно указать имя сервера (имя NetBIOS или полностью уточненное имя DNS), перед которым следует ввести две обратные косые черты. С командой Sc можно использовать несколько командных глаголов:

• Sc query извещает администратора о состоянии указанной службы (которая, будем надеяться, функционирует в данный момент), о том, какие управляющие команды она готова принимать, а также о ее последнем коде выхода.
• Sc qc показывает имя службы, способ запуска (автоматический, ручной или “отключено”), путь к двоичному образу, описательное имя (display name), учетную запись, использованную для запуска службы, и зависящие от нее службы.
• Sc queryex отображает ту же информацию, что и Sc query, плюс идентификатор процесса службы, который иногда требуется для того, чтобы завершить зависший процесс; эти сведения могут понадобиться в случае зависания службы SMTP при появлении искаженного сообщения.
• Sc start и Sc stop выполняют задачи, указанные в их именах, т. е. запускают и останавливают службы. Каждую службу необходимо останавливать своей командой, поскольку одна команда не в состоянии остановить службу и зависящие от нее компоненты. Sc имеет еще одну особенность, в отличие от команд NET: последние не возвращают управление пользователю до тех пор, пока команда либо не завершила выполнение запроса, либо не дала сбой при попытке его выполнения. Между тем Sc просто передает команду и немедленно возвращает управление, отображая при этом состояние START_PENDING или STOP_PENDING.
• Sc enumdepend отображает список служб, функционирование которых зависит от указанной службы. Эту команду полезно применять в сочетании с командой Sc stop; таким образом, можно начинать с остановки зависимых служб.

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

Настройка служб для повторного запуска в автоматическом режиме

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

1. Запустить приложение Services.
2. Открыть диалоговое окно Properties целевой службы.
3. Перейти на вкладку Recovery, показанную на рис. 1. По умолчанию службы Exchange настроены таким образом, что в случае аварийного сбоя никакие действия не предпринимаются. Однако можно указать другие настройки: запустить службу повторно, выполнить внешнюю программу (это может быть сценарий) или перезапустить компьютер. Так, служба IIS Admin в случае отказа запускает файл iisreset.exe с переключателем /start. Задача этого исполняемого модуля в том, чтобы очистить службу и обеспечить ее нормальный перезапуск.
4. В качестве первой меры при сбое служб Exchange указать перезапуск соответствующей службы.
5. В качестве второй меры на случай сбоя предусмотреть отправку средством уведомления соответствующего сообщения непосредственно на какую-либо другую учетную запись или устройство, работу которого вы контролируете.

В окне диспетчера ESM есть узел Monitoring and Status (он располагается внутри узла Tools). Должен признать, что большинство администраторов Exchange из тех, с кем мне доводилось встречаться, никогда не пользовались этими инструментами, что весьма прискорбно. Конечно, инструменты, о которых идет речь, не могут заменить такие пакеты, как, скажем, MOM, но они наделены рядом весьма полезных функций. Начнем с узла Status (см. рис. 2). Он предоставляет сводные данные по состоянию всех коннекторов Exchange и серверов организации. Администратор видит, какие коннекторы находятся в рабочем состоянии, а какие отключены; увидев отключенный коннектор, он должен вручную проверить виртуальный сервер, на котором тот расположен, и систему на другом конце канала связи, поскольку ESM не дает информации о том, в чем именно состоит проблема. В этом случае может оказаться полезным инструментальное средство Winroute; оно отображает таблицу маршрутизации, которая может помочь установить, что является причиной проблемы.

Другие объекты, за которыми можно наблюдать с помощью узла Status, пожалуй, представляют больший интерес. По умолчанию каждый сервер имеет компонент состояния, именуемый Default Microsoft Exchange Services. Этот компонент в сочетании с инструментарием управления Windows WMI (Windows Management Instrumentation) обеспечивает мониторинг состояния хранилища Information Store, стеков агента Message Transfer Agent (MTA), процессора маршрутизации, компонента System Attendant, виртуального сервера SMTP, а также Web-служб IIS. Если какая-либо из этих служб останавливается, состояние контролируемого компонента меняется на критическое, и диспетчер ESM рассылает уведомления; к сожалению, для получения новых данных администратор должен следить за состоянием узла Status. Однако все эти службы проверяются с помощью инструментария WMI, что может приводить к некоторому запаздыванию отчетов. К примеру, когда я останавливаю агент MTA на одном сервере и вновь запускаю его через минуту-другую, ESM на другом сервере может не зафиксировать перерыв в работе. Поэтому, если используется данное средство мониторинга, следует чаще нажимать клавишу F5, чтобы инициировать обновление ESM. Кроме того, можно создавать собственные мониторы состояния на базе любого из шести типов ресурсов, которыми располагает ESM.

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

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

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

Счетчики увеличения очередей SMTP и X.400 позволяют отслеживать динамику состояния очередей. Если какая-либо очередь заданного типа постоянно увеличивается в течение указанного периода, администратор получает соответствующее уведомление.

Следует использовать счетчики состояния служб Windows для мониторинга служб по своему выбору. Если службы, за которыми администратор хотел бы наблюдать, имеют отношение к системе Exchange, но не включены в объект Default Microsoft Exchange Services, он должен включить их в этот объект или создать собственный. Узел Notifications обеспечивает отправку сообщений электронной почты или запуск сценариев при переходе контролируемого объекта к критическому или пороговому состоянию. Щелкнув на этом узле правой клавишей мыши, можно запустить команды New E-Mail Action или New Script Action; последние, в свою очередь, отображают диалоговое окно Properties, показанное на рис. 3. Администратор может выбрать сервер, который будет осуществлять мониторинг, серверы и коннекторы, которые станут объектами мониторинга (один сервер или коннектор, все серверы или коннекторы в группе маршрутизации либо определяемый пользователем набор серверов или коннекторов), а также текст сообщения, который будет передаваться в процессе уведомления. Разумеется, решить эту задачу можно только в том случае, если принять саму идею отправки критических уведомлений о состоянии системы обработки электронной почты по каналам этой системы. К примеру, вряд ли можно считать наилучшим решением извещение администратора о полном выходе сервера из строя (если только в данной системе каждый сервер не используется для наблюдения за другими серверами; к сожалению, настройки для выполнения подобной задачи придется вводить вручную).

Уведомления на базе сценариев реализуются аналогичным образом. Для этой цели используются обычные сценарии VBScript или исполняемые модули, и, когда контролируемые серверы или коннекторы изменяют свое состояние так, что превышаются заданные критические значения, запускается сценарий или исполнимый модуль с параметрами, указанными администратором в командной строке. Это хороший способ для ввода в действие пейджеров или средств уведомления с помощью SMS от независимых поставщиков либо для запуска сценариев, выполняющих нестандартные задачи. К примеру, можно написать небольшой сценарий, который будет направлять уведомления на устройство Ambient Orb или Dashboard либо на «интеллектуальные» часы Microsoft SPOT; такой сценарий позволит, минуя каналы электронной почты, получать информацию о том, что в системе возникли какие-то неполадки.

Уведомления об увеличении размеров очередей SMTP

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

Запустить ESM.
Открыть диалоговое окно Properties для сервера, за работой которого предстоит наблюдать, и перейти на вкладку Monitoring.
Нажать кнопку Add.
В диалоговом окне Add Resource выбрать элемент SMTP queue growth и нажать ОК.
В диалоговом окне SMTP Queue Thresholds установить флажки Warning state (minutes) и Critical state (minutes); указать количество минут, по истечении которых постоянно увеличивающаяся очередь будет считаться достигшей критического состояния; по завершении нажать ОК.
Нажать кнопку ОК, чтобы закрыть диалоговое окно Properties.
Раскрыть узел Tools.
Раскрыть узел Monitoring and Status, правой клавишей мыши щелкнуть на папке Notifications и выбрать команду New, Script notification.
Нажать кнопку Select и выбрать сервер, мониторинг которого планируется осуществлять.
Если выбирается не тот сервер, который был выбран на этапе 2, необходимо убедиться, что указан нужный сервер.

Ввести маршрут и параметры командной строки для сценария и нажать ОК, разрешая тем самым начать процесс мониторинга.

Трассировка сообщений

Функцию трассировки сообщений едва ли следует относить к средствам мониторинга, однако ее можно использовать в качестве грубого инструмента для определения состояния сервера. Бывает, что я ожидаю поступления на сервер Exchange сообщений по электронной почте, а их все нет. Причин может быть две: либо действительно никто ничего не пишет (даже спамеры), либо в инфраструктуре Exchange возникли какие-то проблемы. Существует способ, позволяющий быстро определить, в чем дело. Нужно запустить средство трассировки сообщений Message Tracking Center в узле Tools диспетчера ESM и выполнить быструю проверку сервера-моста SMTP на предмет наличия сообщений, поступивших на протяжении интересующего периода. Этот способ в сочетании с проверкой файлов регистрации прибора Barracuda Spam Firewall позволяет быстро установить, поступает ли почта в обычном режиме. Если нет, трассировка нередко указывает пункт, где сообщение «сбилось с курса». Это средство мониторинга весьма полезно, если использовать его в сочетании с функцией получения уведомлений в тех ситуациях, когда коннектор, по всей видимости, вышел из строя.

Чего не может ESM

А что если администратору необходимо отслеживать или контролировать показатели, не улавливаемые средствами ESM? В этом случае можно обратиться к интерфейсам WMI из комплекта Windows и Exchange и написать собственные сценарии для проведения мониторинга интересующих администратора показателей. Эта задача может вызвать затруднения у тех, кому никогда прежде не доводилось писать сценарии, но на самом деле она не так уж сложна. Вооружившись подготовленным специалистами Microsoft пособием Scripting Guide, а также двухтомным трудом Leveraging WMI Scripting и Understanding WMI Scripting Алана Лиссо, администратор получит в свое распоряжение все необходимые исходные материалы, а также множество примеров сценариев, которые можно приспособить для конкретных нужд.

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

Автор: Поль Робишо
Взято с Windows IT Pro