Аварии сервера и клиента - это то, чего стремится избежать каждый, но при их возникновении вашей самой приоритетной задачей должно быть получение необходимых данных для предотвращения повторных аварий и для быстрого восстановления. В данной статье рассматриваются некоторые из новых функциональных возможностей, добавленных в IBM Lotus Notes/Domino 7. Данная статья предназначена для администраторов Domino, желающих получить корректные данные по аварии для передачи в службу поддержки IBM, а также для пользователей, которым интересно узнать, что происходит при внезапном прекращении работы их Notes-клиента.
Некоторые основы восстановления после сбоев и автоматического сбора диагностической информации
Функция восстановления после сбоев (fault recovery) реализована в Lotus Domino для платформ UNIX, начиная с версии 4, но она не была документирована, и с ней было сложно работать. В Lotus Notes/Domino 6 восстановление после сбоев стало работать на всех платформах, на которых выполняется Lotus Notes/Domino; кроме того, восстановление стало легко настраивать в документе Server. Функция восстановления после сбоев следит за всеми используемыми клиентом или сервером ресурсами и в случае аварии полностью их освобождает. Для сервера Domino существует возможность его перезапуска после сбора диагностической информации. Для пользователей это означает, что они могут перезапустить Notes-клиент после аварии без необходимости завершения всех процессов, которые были запущены Notes-клиентом.
При помощи функции восстановления после сбоев Lotus Notes/Domino может собрать нужную диагностическую информацию по каждой аварии. Однако для каждой машины, на которой произошел сбой, вы должны иметь доступ к этой информации, что может быть проблематичным при сбоях Notes-клиента. В Lotus Notes/Domino 6.0.1 для удаления требования сбора данных с каждой машины была добавлена функция автоматического сбора диагностической информации (automatic diagnostic collection - ADC). ADC позволяет настроить почтовую базу данных (mail-in database) на сбор диагностической информации, генерируемой при аварии на Notes-клиенте и/или сервере Domino, в одном центральном репозитории.
Вы можете настроить ADC через документы Server Configuration (для серверов) и политики Desktop Setting (для клиентов). Данные передаются в почтовую базу данных после перезапуска клиента или сервера. Для случаев аварии на клиенте можно настроить документ Policy, разрешив пользователю выбирать передачу диагностической информации или вводить комментарии о том, что он сделал до аварии.
Новые функциональные возможности, добавленные в ADC в Lotus Notes/Domino 7
Функциональность ADC в Lotus Notes/Domino 7 была расширена. В данном разделе вы узнаете о новой функциональности и о том, как она может помочь вам собрать более качественную диагностическую информацию, а также определить тенденцию аварий во времени. К новым функциям относятся:
- Конфигурация файлов для сбора во время аварии.
- Дополнительная информация, собранная для аварий Sametime и QuickPlace.
- Уведомление о перезапуске сервера в Domino Domain Monitoring (DDM).
- Расширенные варианты ведения журналов.
- Расширенная информация в почтовых уведомлениях.
- Ограничение размера присоединения.
- Предупреждение, если NSD не настроен для запуска.
- Анализатор неисправностей.
Конфигурация файлов
В Lotus Notes/Domino 6.x ADC собирает жестко закодированный список файлов, в который входят выходные данные NSD, log-файл консоли и дамп памяти. Этой информации, обычно, достаточно для отладки стандартных аварий, но что если на клиенте или на сервере работают приложения сторонних поставщиков, имеющие собственные log-файлы? Или, предположим, вы хотите сохранить файл SEMDEBUG.TXT, поскольку произошел конфликт с семафором, приведший к аварии?
Lotus Notes/Domino 7 расширяет количество файлов, собираемых по умолчанию, и вы можете собрать дополнительные файлы в случае аварии. Собираемыми по умолчанию файлами являются:
- Выходная информация NSD. Дамп системной информации и информации о том, что делал каждый поток во всех процессах Notes/Domino на момент аварии.
- Выходная информация консоли. Текстовый файл, содержащий сообщения, записываемые на консоль Domino.
- Дампы памяти. Снимок блоков оперативной памяти, распределенных процессами Notes/Domino в данное время.
- Выходная информация Notes_Child_PID. Process ID каждого процесса при его создании вместе со статусом завершения при его завершении.
- Ошибки memcheck. Все ошибки, обнаруживаемые программой memcheck при сканировании пулов памяти Notes/Domino.
- Отладка семафора. Текстовый файл, показывающий соревнующиеся семафоры.
- Журналы HTTP-сессии/потока. Подробная информация о каждой проведенной HTTP-сессии и потоке. Эти файлы собираются, только если авария возникла на HTTP, и разрешено ведение журналов сессии/потока.
- Выходная информация NSD-sysinfo. TСистемная информация, записываемая во время запуска клиента/сервера.
- Выходная информация NSD-kill. Информация, собираемая во время использования команды nsd -kill для завершения работы клиента или сервера.
Кроме этих файлов вы можете также собирать любые другие файлы, которые могут присутствовать во время аварии, заполняя информацию в документе Server Configuration или документе Desktop Settings Policy. Если вы перейдете на закладку Diagnostics в любом из этих документов, то увидите раздел (аналогичный изображенному на рисунке 1), использующий дизайн Domino 7 Directory.
Рисунок 1. Раздел Diagnostic Collection Options
В поле Diagnostic file patterns вы можете ввести список названий файлов и/или шаблонов для поиска во время аварии и присоединить информацию к документу, передаваемому в почтовую базу данных, если настроенный предельный размер не превышен (информация по предельным размерам приведена в разделе "Ограничение размеров присоединения", расположенной далее в данной статье). Шаблон может содержать звездочку ( * ) для указания одного или более символов, либо знак вопроса ( ? ) для указания одного символа.
Если файл размещен в текущем диагностическом каталоге (обычно, <data directory>/IBM_TECHNICAL_SUPPORT), вам нужно только его название. В случае, если файл расположен вне этого каталога, вы должны указывать полный путь к файлу.
Дополнительная информация по авариям Sametime/QuickPlace
Если авария происходит на сервере Sametime или на сервере QuickPlace, по умолчанию собирается дополнительная информация и добавляется к документу, передаваемому в почтовую базу данных. В частности, если авария происходит на сервере Sametime, файл stdiags_* автоматически добавляется к почтовому документу. Если авария происходит на сервере QuickPlace, Lotus Domino пытается присоединить файлы qpconfig.xml и admin.nsf для помощи при диагностике проблемы.
Информация о перезапуске сервера, отправляемая в Domino Domain Monitoring
Domino Domain Monitoring (DDM) - это новая функциональная возможность в Lotus Domino 7, обеспечивающая администраторов высокоуровневым представлением процесса работы всего их домена. Когда сервер перезапускается после сбоя, в DDM передается сообщение, то есть, вы можете проследить за событием на консоли администратора. Также предоставляется история слежения за этими событиями в домене.
Варианты расширенного ведения журналов
В Lotus Notes/Domino 6.x, если ведение журнала в консоли не разрешено на клиенте или сервере, в почтовой базе данных никакая информация не собирается. В определенных случаях, однако, эта информация необходима для поиска проблемы, поэтому Lotus Notes/Domino 7 делает значительные усилия для получения этой информации.
Независимо от того, разрешено ли ведение журналов в консоли, ADC сначала ищет информацию в log-файлах Domino Controller (на сервере), если сервер работает под Domino Controller (известен, также, как Java Controller). Если сервер работает под управлением Domino Controller, ADC использует его log-файлы (все равно следя за предельными размерами, указанными в документе Configuration), поскольку информация, выводимая на консоль, является подмножеством информации в этих файлах; то есть, log-файлы содержат сообщения плюс код серьезности ошибки для каждого сообщения.
Если ADC работает на клиенте, либо сервер не работает под управлением Domino Controller, ADC проверяет, разрешено ли ведение журнала в консоли. Если да, он использует выходную информацию консоли точно так же, как и в Lotus Domino 6.x.
Если ведение журналов в консоли не разрешено, ADC возвращается к использованию информации, записываемой в log.nsf (которая является подмножеством информации, содержащейся в журнале консоли). Он делает это путем извлечения текста во время аварии из вида Miscellaneous Events в файл log.nsf, создавая файл псевдо-консоли с выходной информацией. Затем этот файл присоединяется к документу точно так же, как присоединялся бы log-файл консоли. Причина не присоединения всего файла log.nsf, заключается в том, что в большинстве случаев он будет больше, чем установленный предел размера файла, и поскольку log.nsf является бинарным файлом, вы не можете просто сократить его и передать последнюю часть.
Расширенная информация в почтовых уведомлениях
В Lotus Domino 6.x существует параметр конфигурации для передачи уведомления человеку или группе при перезапуске сервера. Однако в этом уведомлении предоставляется только основная информация: время аварии на сервере и факт возобновления работы.
Рисунок 2. Уведомление о перезапуске сервера Domino 6 
В Lotus Notes/Domino 7 это уведомление было расширено, и теперь оно содержит больше информации в обоих полях (Subject и Body), поэтому люди, присутствующие в списке для уведомления, смогут более быстро получить больше информации об аварии. Как вы можете увидеть на рисунке 3, поле Subject содержит версию Domino, аварийный процесс и время аварии. Поле Body содержит почти всю информацию, которая передается в почтовую базу данных (за исключением присоединений) вместе со ссылкой на почтовую базу данных (если она расположена в том же самом домене, что и сервер, потерпевший аварию).
Рисунок 3. Уведомление о перезапуске сервера
С такой расширенной строкой Subject пользователи переносимых устройств или пейджеров, включенные в список для уведомления, могут получить необходимую им информацию без необходимости обращения к почтовой базе данных. Если вы предпочитаете формат 6.x, то можете использовать параметр ADC_USE_OLD_EMAIL_FORMAT=1 в файле Notes.ini всех серверов, которым хотите передавать сообщения в стиле 6.x.
Параметр Notes.ini FR_ATTACH_NSD все еще работает в Lotus Domino 7. Он определяет, присоединяется ли выходной файл NSD к сообщению-уведомлению, передаваемому при перезагрузке сервера. Если параметра установлен в 1, выходной файл NSD присоединяется к уведомлению. Если его значение больше 1, тогда выходной файл NSD присоединяется только в случае, если его размер меньше или равен значению параметра в килобайтах (то есть, FR_ATTACH_NSD=5 означает присоединение файла с размером меньшим или равным 5KB). Этот параметр применяется только для присоединения к уведомлению выходного файла NSD и не имеет отношения к тому, что присоединяется к сообщению, передаваемому в почтовую базу данных.
Ограничение размеров присоединения
Одной из проблем при добавлении присоединений к сообщениям, передаваемым ADC в почтовую базу данных, является то, что это сильно увеличивает размер сообщения. Это может вызвать проблемы, если на диске недостаточно свободного пространства для передачи сообщения, или если в вашей организации используется управляемый маршрутизатор для ограничения размеров передаваемых по сети сообщений.
В Lotus Notes/Domino 7 вы можете ограничить общий размер сообщения, передаваемого в почтовую базу данных, и объем выходного файла NSD (это не имеет отношения к INI-параметру, упомянутому в последнем разделе) для присоединения в секции Diagnostic Collection Options (см. рисунок 4).
Рисунок 4. Поля Maximum size в секции Diagnostic Collection Options 
На рисунке 4 показано значение по умолчанию в 5MB для общего размера сообщения и 2MB для выходного файла NSD, который читается с начала файла, то есть, используются первые 2 MB файла.
Когда ADC формирует сообщение, он присоединяет файлы в следующем порядке:
- Выходная информация NSD (до указанного размера).
- Выходная информация консоли (до указанного размера).
- Файл Diagindex.nbf file, содержащий список всех диагностических файлов, сгенерированных после последнего перезапуска сервера.
- Все другие файлы, включая другие файлы по умолчанию и файлы, которые вы настроили для сбора.
Если файл NSD должен быть сокращен, или если какие-либо из файлов не могут быть присоединены к сообщению (поскольку они превысят предел), они перечисляются в почтовом документе, поэтому вы можете затем извлечь их вручную. На рисунке 5 показан пример аварии на сервере.
Рисунок 5. Пример сообщения ADC при аварии на сервере
При аварии на клиенте вы получаете дополнительную информацию о том, какая политика Desktop Setting действовала (см. рисунок 6).
Рисунок 6. Пример сообщения ADC при аварии на клиенте
Предупреждение о том, что NSD не сконфигурирован
ADC полагается на выходной файл NSD в отношении большей части своей информации, поэтому, если NSD не сконфигурирован на выполнение во время аварии, в отчете ADC очень мало пользы. В частности, нет информации для группы IBM Support, используемой для решения вашей проблемы. Для предупреждения администраторов об этом в почтовой базе данных отображается следующее предупреждение, если не был обнаружен выходной файл NSD во время аварии:
WARNING: Crash information not extracted! Make sure NSD is configured to run on the Server document.
Анализатор неисправностей
Наибольшей новой функциональной возможностью для ADC в Lotus Domino 7 является анализатор неисправностей. Анализатор неисправностей является новым дополнительным заданием сервера Domino, которое может искать соответствие отчетов об авариях в почтовой базе данных с передаваемой ADC информацией.
Анализатор неисправностей может обрабатывать много почтовых баз данных (например, если у вас есть различные базы данных для аварий на клиенте и на сервере), но он ищет соответствия только в базе данных, которая работает в данный момент времени; он не выполняет поиск соответствия в нескольких базах данных.
Если анализатор неисправностей не обнаруживает соответствия новой аварии, она обозначается родительской аварией (parent crash) (это означает, что данная авария была обнаружена впервые). Если он находит соответствие аварии, она обозначается дочерней аварией (child crash), и первое возникновение этой аварии становится ее родителем. Взаимоотношения родитель/потомок обсуждается в данной статье ниже, а сейчас давайте рассмотрим процесс, используемый для определения соответствия двух аварий.
Процесс поиска соответствия
Определение того, являются ли две аварии Notes/Domino результатом одной проблемы, не всегда простая задача. Поскольку архитектура Lotus Notes/Domino является многоуровневой, вы не можете полагаться только на сообщение об ошибке для уникальной идентификации проблемы, потому что в коде возможны различные пути, ведущие к одинаковому сообщению об ошибке.
Анализатор неисправностей использует последовательность функций, вызываемых потерпевшим аварию потоком, для формирования уникальной сигнатуры аварии. Эта последовательность вызовов функций показывает путь к аварии.
Если бы вы просмотрели выходные файлы NSD на различных платформах Notes/Domino, то увидели бы, что различные операционные системы отображают информацию о стеке вызовов совершенно по-разному. ADC берет на себя заботу о нормализации этих различий перед передачей отчета в почтовую базу данных. Нормализация включает в себя гарантирование перечисления функций в обратном хронологическом порядке и не декорированные (de-mangled) C++-функции (то есть, они должны быть в формате <class>::<function>).
Анализатор неисправностей начинает процесс поиска соответствия, читая с вершины стека вниз до тех пор, пока не обнаружит имя функции, не совпадающее в двух стеках. Вершина стека определяется функцией Panic, которая является первой функцией в стеке для нарушений доступа в платформах Windows 32 или первой функцией после fatal_error на платформах UNIX.
Анализатор неисправностей проходит через каждую функцию в stack1 и ищет соответствия на той же позиции в stack2. Этот процесс повторяется до тех пор, пока имена функций перестанут совпадать. Когда это происходит, определяется процент соответствия между двумя стеками. Процент соответствия вычисляется путем деления количества совпадающих функций в стеках на среднее количество функций в стеках.
Если stack1 имеет 10 функций, а stack2 имеет 15 функций, и первые пять функций соответствуют друг другу в обоих стеках, процент соответствия будет равен 5 / ((10+15) / 2) = 41%.
Если в двух стеках все функции совпадают, их процент соответствия равен 100 процентам, и они называются точным соответствием. Не трудно определить, что эти две аварии имеют одну и ту же основную причину. Однако существует вероятность того, что две аварии имеют одинаковую основную причину, но не имеют идентичных стеков вызовов. Это происходит потому, что Lotus Domino написан с использованием уровневой модели, в которой различные подсистемы построены над другими подсистемами. Если существует проблема на уровне, который обращается к базам данным (NSF), многие другие подсистемы (например, маршрутизатор, репликатор и т.д.) могут столкнуться с той же основной проблемой, но будут иметь различные стеки, ведущие к проблеме.
Для определения того, соответствуют ли частично два стека, мы используем процентный срез, основанный на средней длине стека двух стеков вызовов. Средняя длина стека определяется суммой количества функций в stack1 и количества функций в stack2, деленной на 2. Приведенные проценты, основанные на средней длине стека вызовов, приведены в следующей таблице.
| Длина стека вызовов | Приведенный процент |
| < 4 | Должно быть точное соответствие. При таком малом количестве функций в стеке очень рискованно назвать это частичным совпадением, если есть только подмножество одинаковых функций. |
| 4 | Должно быть соответствие 75% и выше. |
| От 5 до 7 | Должно быть соответствие 60% и выше. |
| 8 и более | Должно быть соответствие 40% и выше. |
По мере увеличения длины стека процентное соотношение, при котором можно считать соответствие частичным, уменьшается, поскольку в длинных стеках, если есть много одинаковых функций на вершине стека, вы можете быть уверены, что проблемы одинаковы.
Вы можете вручную изменить этот алгоритм, установив параметр FAULT_ANALYZER_MATCH_PERCENTAGE в файле Notes.ini на сервере, выполняющем анализатор неисправностей. Вы можете установить его в значение от 1 до 99. Если вы используете эту настройку, она применяется ко всем частичным совпадениям, независимо от средней длины стека.
Конфигурация анализатора неисправностей
Анализатор неисправностей по умолчанию отключен. Вам необходим сервер Domino 7 для хранения ваших почтовых баз данных, для того чтобы анализатор неисправностей работал с ними. Также, каталог Domino Directory должен быть обновлен до версии 7, чтобы вы смогли увидеть новые поля документа Server Configuration для настройки анализатора неисправностей на закладке Diagnostics (см. рисунок 7).
Рисунок 7. Поля анализатора неисправностей в документе Server Configuration 
По умолчанию, если вы разрешите работу анализатора неисправностей, он работает со всеми почтовыми базами данных на сервере и запускается во время запуска сервера (нет необходимости добавлять его в строку ServerTasks в файле Notes.ini). Анализатор неисправностей определяет, какие базы данных на сервере являются почтовыми базами ADC, путем сканирования локального Domino Directory для поиска документов Server Configuration и Desktop Setting Policy, в которых определены почтовые базы данных. Если любая из этих баз данных находится на локальном сервере, за ними осуществляется мониторинг. Если на локальном сервере баз данных не обнаружено, анализатор неисправностей прекращает работу.
Когда анализатор неисправностей запускается, он обрабатывает все новые аварии в почтовых базах данных, а затем работает в режиме ожидания до возникновения новой аварии. Тогда он немедленно запускается в рабочем режиме и обрабатывает новую аварию.
Вы можете, также, настроить анализатор неисправностей на работу с выбранными базами данных (см. рисунок 8). Вы можете выбрать этот параметр, если хотите, чтобы анализатор неисправностей работал только с подмножеством баз данных на сервере, или если хотите реплицировать все ваши почтовые базы данных на одном сервере, так чтобы они могли обрабатываться в одном месте вместо запуска анализатора неисправностей в нескольких местах.
Рисунок 8. Анализатор неисправностей установлен на запуск с выбранными базами данных
Вы можете также запустить анализатор неисправностей вручную, выполнив команду в консоли load faultanalyzer. Если вы не передаете какие-либо аргументы, анализатор неисправностей использует описанный ранее метод для поиска почтовых баз данных ADC на текущем сервере. Вы можете также передать параметр, указывающий базу данных, каталог или косвенный файл (*.IND, содержащий список баз данных) для работы анализатора неисправностей. Когда анализатор неисправностей загружается вручную, он обрабатывает все новые аварии в базах данных и затем завершает свою работу; он не остается в режиме ожидания доставки следующей аварии.
Для сохранения пространства в почтовой базе данных вы можете также использовать параметр для удаления присоединений из дочерних аварий (и точных, и частичных). Идея состоит в том, что вы знаете, что это аналогичная родительской авария, поэтому нет необходимости хранить диагностическую информацию дважды. Данные все равно доступны на клиенте или на сервере, если вы выберете удаление их из почтовой базы данных.
ПРИМЕЧАНИЕ: Если вы запускали ADC в Lotus Domino 6.x, при обновлении до Lotus Domino 7 (и разрешении анализатора неисправностей) он обрабатывает все текущие записи в почтовой базе данных при первом запуске.
Изменения в базе данных Notes/Domino Fault Reports
Шаблон Notes/Domino Fault Reports (lndfr.ntf) был обновлен для сервера Domino 7, для того чтобы вы могли увидеть всю новую информацию, присутствующую в почтовой базе данных ADC. Текущие почтовые базы данных были обновлены до новой версии тогда, когда вы обновляли сервер до версии 7 (и выполнялось задание design).
На рисунке 9 показана новая схема базы данных. Представления Standard и Fault Analyzed были добавлены в представления By Date, Clients и Servers, для того чтобы вы могли видеть взаимоотношения родитель/потомок, а также текущие категоризации By Date (по дате).
Рисунок 9. Схема базы данных Domino 7 Fault Report 
В новых представлениях Fault Analyzed потомок категоризирован в его соответствующей родительской аварии. Когда документ родительской аварии открывается, вверху его есть встроенное представление, показывающее всех потомков, связанных с ним. Двойной щелчок мышкой открывает эти документы непосредственно из встроенного представления. Точные и частичные соответствия содержат ссылки doclink к родительской аварии, поэтому вы также можете выполнять навигацию, используя их. Кроме того, частичные совпадения отображают процент совпадения, поэтому вы можете видеть, насколько два стека совпадают друг с другом.
Счетчик событий
Счетчик событий для каждой родительской аварии представляет собой общую сумму аварий, произошедших в текущей почтовой базе данных. Этот счетчик показывается в Administrative Section документа родительской аварии (см. рисунок 10) и отображается также во всех представлениях в почтовой базе данных.
Рисунок 10. Поле событий в Administrative Section документа родительской аварии
Счетчик уникальных ID
Кроме счетчика событий анализатор неисправностей также отслеживает количество уникальных клиентов и/или серверов, которые были затронуты конкретной аварией. Он может быть полезен при определении взвешенной величины для проблемы. Например, если вы столкнулись с аварией 20 раз у 20 различных пользователей, это может быть более серьезно, чем 20 аварий у одного пользователя. Уникальные ID перечислены в Administrative Section документа родительской аварии в порядке убывания количества случаев, когда они сталкивались с проблемой. Вы можете также увидеть этот счетчик в представлениях почтовой базы данных.
Устраненные аварии
После определения главной причины аварии и после обновления до версии, содержащей исправление (fix), или после применения корректирующего последнего исправления (hotfix), не желательно, чтобы любые дальнейшие аварии с тем же стеком отмечались как дочерние (потому что авария еще только должна быть устранена).
Для того чтобы будущие совпадающие вызовы стеков считались новыми родительскими, вы можете пометить аварию как устраненную в Administrative Section документа родительской аварии. Устраненные аварии отображаются зеленой галочкой рядом с ними в представлениях.
Отмечая аварию как устраненную, вы можете указать, что все клиенты/серверы имеют исправление, либо ввести список версий Notes/Domino и/или последних исправлений, содержащих исправление (см. рисунок 11). Анализатор неисправностей полагает, что если проблема решена в данной версии, то она решена и в последующих версиях (это относится к версиям Notes/Domino и последним исправлениям, то есть, комбинированным последним исправлениям). Анализатор неисправностей также принимает во внимание взаимоотношение между версиями 6.x и 6.5x; следовательно, если что-то отмечается как исправленное в 6.0.4, это считается исправленным также и в 6.5.2.
Рисунок 11. Редактирование родительской аварии и отметка о ее устранении
Заключение
Вы узнали о некоторых улучшенных функциональных возможностях для удобства обслуживания, добавленных в Lotus Notes/Domino 7 и позволяющих лучше обрабатывать аварии на сервере и на клиенте. Теперь пришло время обновиться до Lotus Notes/Domino 7 и ожидать появления на горизонте следующей версий IBM Lotus Notes под кодовым названием Hannover!