Самоучитель
системного администратора

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

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

Прежде чем начать...

Если отказ все же случился, не спешите сразу же начинать что-то делать. Попробуйте успокоиться, может быть, выпить кофе и только после этого приступать к активной деятельности.

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

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

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

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

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

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

Пять девяток?

Цель, которую ставят изготовители оборудования и разработчики программного обеспечения, — достичь доступности информационной системы на "пять девяток" — 99,999%. При круглосуточной работе этот показатель соответствует примерно пяти минутам простоя за год.

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

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

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

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

Будьте готовы к худшему

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

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

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

Главное, что нужно запомнить, — резервная копия, резервная копия и еще раз резервная копия!

Запасные детали

Любая информационная система нуждается в ЗИП — запасных инструментах и принадлежностях. В идеале состав ЗИП должен рассчитываться при создании системы, но обычно для этого не хватает показателей надежности и ЗИП составляется в процентах от объема (например, 10% — цифра зависит от практики, принятой на конкретном предприятии), но не менее одного элемента каждого типа.

Следует учесть, что запасные детали к оборудованию, находящемуся на эксплуатации более 3-х лет, приобрести становится весьма сложно. Часто для этого необходимо наличие сервисных контрактов, стоимость которых за 3—5 лет уже начинает превышать стоимость исходного оборудования.

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

Где найти помощь

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

  • Windows Help.

    Первое, к чему необходимо обратиться при возникновении любой проблемы в работе компьютера, — это встроенная справочная система. С каждой новой версией Windows эти системы становятся все более содержательными и полезными (если только вы знаете, что хотите найти, и правильно формулируете условия поиска).

  • Онлайновая база данных Microsoft.

    Громадный объем документации содержится на сайте корпорации Microsoft по адресу http://msdn.microsoft.com/. В различных разделах этого ресурса вы можете найти как описания работы отдельных компонентов операционной системы, так и технические статьи, содержащие сведения об обнаруженных ошибках и методах их устранения.

    Онлайновая справочная база Microsoft локализована практически в полном объеме. Страницы с русской версией сайта корпорации можно найти по адресу http://www.microsoft.com/rus/, однако следует учитывать, что англоязычные материалы публикуются оперативнее переводов.

  • Материалы Интернета.

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

  • Конференции Интернета.

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

      Примечание

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

  • Техническая поддержка производителя.

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

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

Сбор информации об отказе

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

Затем систематизируйте информацию о системе:

  • доступные журналы (журнал событий Windows, syslog для unix-систем, журналы приложений);
  • уточните время возникновения проблемы, какие операции выполнялись в этот момент;
  • выясните, проводились ли изменения в настройках системы перед возникновением проблемы, менялось ли оборудование и т. п.;
  • проанализируйте ситуацию: встречались ли наблюдаемые симптомы ранее, были ли сходные отказы, которые могли привести к текущей проблеме и т. п.;
  • если ошибка наблюдается у пользователя, переговорите с ним, уточните ситуацию, попытайтесь воспроизвести проблему.

Анализ журналов системы

Неисправность практически невозможно определить без обращения к протоколам, в которых фиксируются события, возникающие в системе. Для Windows основные протоколы — это журналы системы, приложений и безопасности, для *nix-систем — журнал syslog и журналы приложений.

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

    Примечание

    После устранения неисправности необходимо восстановить исходный уровень детализации журналов, чтобы не использовать нерационально ресурсы системы на запись информации о событиях.

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

Рис. 11.1.
Insight for Active Directory протоколирует все попытки доступа к службе каталогов на контроллере домена

Средства просмотра журналов системы

В Windows для просмотра журналов событий применяется специальная программа Просмотр событий (рис. 11.2), вызов которой выполняется через Панель управления | Административные задачи | Просмотр событий.

Рис. 11.2.
Средство просмотра журнала событий в Windows 7

После запуска программы и выбора нужного журнала в окне будет показан список событий. Описание для каждого события предоставляет краткие характеристики того, что произошло в системе. Дополнительная расшифровка кодов событий приведена в документации Resource Kit, но анализ ситуации в общем случае невозможен без обращения к онлайновой справочной базе Microsoft.

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

    Примечание

    Информация о событиях в программе просмотра Windows не меняется в режиме реального времени. Для обновления следует выполнить команду Обновить (нажать клавишу <F5>).

В *nix-системах события записываются в текстовые файлы. Читать их удобно при помощи команды tail, позволяющей отображать события в реальном режиме времени. Для фильтрации событий используется перенаправление потоков в команду grep, которая и фильтрует вывод по задаваемым критериям. Так, следующий пример приводит к отображению на экране в реальном режиме времени событий, записанных в системном журнале Ubuntu демоном dhcpd (приведено только 4 строки вывода):

Чтобы одновременно наблюдать за событиями двух или более журналов в *nix, используется возможность одновременного открытия нескольких консолей: в каждой консоли запускается просмотр одного журнала, а переход к другому реализуется переключением между консолями.

Изменение детализации протоколирования

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

    Примечание

    Файлы протоколов достаточно сложно анализировать вручную. Существуют различные программы, позволяющие автоматизировать данную операцию, например, отфильтровать и отсортировать записи по каким-либо критериям и т. п. Такие программы легко найти как в свободных ресурсах Интернета, так и у самих разработчиков ПО (например, утилита LogParser от Microsoft).

В *nix-системах детализация протоколирования устанавливается в соответствующих конфигурационных файлах программ. Это текстовые файлы, обычно настроенные на минимум протоколирования. Например, в конфигурации samba1 присутствует строка syslog = 0. Чтобы перейти к более подробной записи, достаточно сменить 0 на большее значение (до 10, чем больше, тем подробнее будет вестись журнал) и перезапустить службу. Рекомендации по изменению уровня протоколирования (какие события будут включены в журнал на каждом уровне) обычно описаны в сопроводительной справочной документации.

Другой способ включения расширенного протоколирования в *nix-системах заключается в запуске соответствующих программ в режиме отладки (debug). Для этого необходимо запустить процесс с определенным ключом и параметром уровня детализации. Сведения о возможности такого старта так же приводятся в справочной документации программы. Например, для упоминавшегося уже демона samba нужно использовать ключ -d с последующим указанием уровня протоколирования: smbd -d <уровень>

Централизованное ведение журналов

Системным администраторам приходится анализировать данные журналов нескольких серверов. Удобно, если эта операция будет выполняться из одной консоли.

В этих целях в системах Windows 7/Vista/2008R2 присутствует возможность настройки сбора событий с различных компьютеров. Для этого используется опция Подписка.

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

Рис. 11.3.
Настройка подписки в Windows 7

В реальных сетях еще долго будут эксплуатироваться компьютеры с Windows XP или Windows 2003 Server, режим подписки с которыми не работает. В этом случае можно использовать скрипт EVENTQUERY.vbs из состава Windows 2003 Server, который позволяет вывести события как с локального, так и с удаленных компьютеров, используя необходимые фильтры (по дате, по номеру события, типу и т. п.).

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

При желании использовать графический интерфейс при анализе журналов можно обратиться к специальной утилите — EventCombMT, бесплатно загружаемой с сервера Microsoft (рис. 11.4).

Рис. 11.4.
Окно утилиты EventCombMT

Утилита EventCombMT позволяет просматривать данные протоколов работы сразу нескольких систем. Администратор может задать желаемые условия поиска (номер события, имена компьютеров для анализа, диапазон дат и т. п.). Утилита содержит несколько встроенных описаний условий поиска, например, по ошибкам DNS, FRS, жестких дисков, службы каталогов. Результаты работы программа сохраняет в виде текстовых файлов.

    Примечание

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

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

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

На рис. 11.5 представлен пример такой программы — EvenTrigger от компании IS Decisions (www.eventrigger.com). Программа позволяет запускать сценарии в соответствии с возникающими событиями, отправлять сообщения на пейджер или по электронной почте, заносить данные в ODBC-базы. С программой поставляется несколько предварительно настроенных триггеров (на события остановки служб, неудачного входа в систему, события печати и т. п.).

Рис. 11.5.
Окно программы EvenTrigger

Подобные функции реализованы и во многих других программах, доступных системным администраторам (GFI LANGuard Security EventLog Monitor, Microsoft Operation Management Server и т. д.).

Установка триггеров на события протоколов

Основным способом мониторинга систем на основе Windows является реагирование на события журналов. Подобные настройки можно легко сделать и собственными силами, если представлять контролируемый объем.

В Windows 7/Vista/2008 настройку триггеров можно сделать в программе просмотра событий. Достаточно выделить событие, которое будет использовано в качестве образца, и в столбце задач по ссылке Назначить задачу... запустить мастер операций (рис. 11.6).

Рис. 11.6.
Мастер создания простой задачи на возникновение события в журнале

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

Для предыдущих версий Windows для создания триггеров можно использовать сценарии. В Windows Server 2003 имеется команда, которая позволяет легко настраивать автоматический запуск любых программ при возникновении заданного события. Это команда eventtriggers. Справочная система к этой команде подробно описывает, как создать триггер, настроенный на появление определенного события, поэтому мы не будем останавливаться на этом описании.

При помощи сценариев в Windows 2003 Server в журналы можно записать и пользовательские события. Это команда eventcreate. Использование утилиты подробно описано в ее справке (eventcreate /?), поэтому мы не будем специально приводить ее описание.

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

Настройка аудита событий безопасности

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

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

    Примечание

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

Если необходимо вести протокол работы с файлами, то следует включить аудит доступа к объектам, после чего в свойствах объекта на вкладке Безопасность следует нажать кнопку Дополнительно и выбрать вкладку Аудит. Затем нужно добавить сведения о том, какие действия и от каких пользователей следует фиксировать в журнале.

Утилиты от Sysinternals

Для поиска проблем администратору часто необходимо отслеживать процессы доступа программ к файлам, к реестру системы и т. д. Наблюдение за такими процессами может существенно помочь в выяснении причин сбоев. В этом случае можно воспользоваться бесплатными утилитами, доступными для загрузки с сайта www.sysinternals.com(http://technet.microsoft.com/ru-ru/sysinternals). Окно одной из таких утилит представлено на рис. 11.7.

Рис. 11.7.
Программа протоколирует операции доступа к файлам компьютера


1Программа samba обеспечивает реализацию общего доступа к файловым ресурсам и принтерам, совместимого с аналогичным в системах Windows.


Рейтинг@Mail.ru