Межплатформенные вопросы при использовании NNM

Кто разрешает проблемы DNS?

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

• поврежден сервер имен;
• удалена запись;
• не работает обратный поиск;
• возвращаются старые данные;
• поиск не укладывается в установленное время;
• официальным является неисправный сервер имен;
• не возвращаются некоторые IP-адреса интерфейсов маршрутизаторов;
• прямое и обратное преобразования не согласованы.

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

Иногда проблема DNS вызывается не сервером имен, а процедурой распознавателя на стороне клиента:

• в распознавателе используется неисправный сервер имен;
• в пути SEARCH осуществляется поиск неправильного домена;
• установленное по умолчанию имя домена не является правильным;
• распознаватель не справляется с большим числом адресов.

Ответственность за проблемы распознавания не лежит на хост-мастерах, а возлагается на администраторов систем конечных пользователей, которыми могут быть сами пользователи. Они могут конфигурировать свои распознаватели, чтобы пользоваться несколькими механизмами разрешения имен. Порядок применения этих механизмов зависит от платформы. В среде ОС UNIX этот порядок указывается в файле /etc/nsswitch.conf. В число механизмов входят:

• сервис доменных имен;
• WINS;
• /etc/hosts ;
• LMHOSTS;
• NIS;
• запрос имени NetBIOS (широковещательный механизм).

Средства поиска и устранения проблем DNS включают следующее:

• проверку конфигурационных файлов распознавателя;
• команду nslookup ;
• команду ping ( p acket in ternet g roper);
• команда dig ( d omain i nformation g roper).

Наконец, взаимная связь между DHCP-серверами и динамическими обновлениями, которые они (предположительно) посылают на серверы DNS, может быть ошибочной, что наводит на мысль, что и администраторы DCHP могли бы разделять ответственность за появление проблемы, связанной с DNS.

Кто разрешает проблемы NNM?

Мы видим, что проблемы, предположительно связанные с NNM, могут относиться к DNS, DHCP, маршрутизаторам, клиентским распознавателям и неопытности пользователей. При наличии такого большого числа потенциально виновных, кто должен корректировать процесс поиска истинных источников проблемы? Это могла бы быть целая команда экспертов, обсуждавшаяся раньше. Реальными проблемами продукта NNM занимаются локальные знатоки NNM и эксперты NNM из отдела IT. За плечами этих людей — полный курс обучения NNM.

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

Кто осуществляет системное администрирование?

Операционной системой, в которой работает NNM, является Solaris, HP-UX или Windows NT. Клиентскими системами могут быть любые системы, на которых выполняются эмулятор X-Windows или web-браузер с поддержкой Java. Для всех этих систем требуется системное администрирование. В больших компаниях может быть создана организация, предназначенная для обеспечения администрирования клиентских и серверных систем остальной части компании. В более мелких компаниях администратор приложения NNM одновременно является и системным администратором.

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

Кто разрабатывает специальные приложения?

Штатный разработчик может писать, документировать, тестировать, сопровождать и поддерживать собственные приложения NNM. Разработчики понимают среду разработки UNIX-приложений, включая управление исходными текстами, оконную систему, набор средств разработки NNM и языки (C, C++, Perl, Java, TCL, Tk и shell). Те виды приложений, которые могут быть написаны локально, интегрируются, как минимум, в систему меню NNM посредством файлов регистрации приложений. Некоторые приложения могут работать в фоновом режиме, как, например, специализированный конфигуратор SNMP или сборщик данных о производительности. Другие приложения могут тесно интегрироваться в среду OpenView Windows, как, например, средство выравнивания пиктограмм по вертикали и по горизонтали и средство создания специальной подсхемы сетевой магистрали.