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

Введение

NNM используется в многоплатформенных неоднородных сетевых средах. GUI X-Windows или web-браузеров способствуют проявлению различий, зависящих от конкретного клиентского компьютера, операционной системы, браузера и эмулятора X-Windows. В этой лекции собраны все подобные вопросы, хотя некоторые из них кратко затрагиваются в других разделах книги.

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

Проблемы версии Java и производительности требуют, чтобы в Solaris и HP-UX были должным образом внесены патчи, и чтобы в качестве межплатформенного браузера был выбран браузер Netscape 4.6 или более поздней версии.

Требования пропускной способности для X-Windows на самом деле весьма скромны, если только не приходится пересылать реальные растровые фоновые изображения. Канал WAN с пропускной способностью в 56 Kbps предоставляет минимально приемлемую производительность (когда через него отображается несколько растровых изображений), и сжатие последовательной линии в маршрутизаторе может уменьшить время задержки. VNC на основе коммутируемых каналов с пропускной способностью 56 Kbps демонстрирует лучшую эффективность, чем X-Windows.

Что касается печати посредством NNM в разных операционных системах, X-Windows и web-интерфейсах, то об этом шла речь в разделе "Создание мгновенных снимков экранов схем".

Различия X-Windows

Модель X-Windows позволяет приложению функционировать на компьютере, отличном от того, на котором находится дисплей. Приложение называется X-клиентом, а дисплей – X-сервером. Оба они общаются путем вызовов xlib, передаваемых посредством TCP/IP. Когда X-клиент выполняется на рабочей станции UNIX с встроенным X-сервером, физическое сетевое соединение между приложением и дисплеем заменяется на высокоэффективный локальный драйвер возвратной петли. В системе NNM, основанной на UNIX, нередко запускается локальная сессия ovw, в то время как более десяти дополнительных одновременно работающих удаленных пользователей выполняют дополнительные сессии ovw. Все удаленные пользователи могут задействовать разные типы компьютеров и программного обеспечения для эмуляции X-Windows. Стандарт X-Windows допускает и поддерживает эти различия.

Стандарт X-Windows действует на сетевом, транспортном, сессионном и представительном уровнях. Это делает его невосприимчивым к операционной системе. Эмулятор X-Windows работает одним и тем же образом независимо от используемой операционной системы, которой может быть Windows, Mac OS, Linux, UNIX или BeOS.

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

В привилегированном режиме эмулятор X-Windows создает полный X-сервер, работающий в одном окне изменяемого размера оконной системы эмулятора. В этом случае обычно требуется, чтобы сервером приложения запускался оконный менеджер, такой как xwm, vuewm или dtwm. В X-терминалах может поддерживаться встроенный оконный менеджер. В непривилегированном режиме каждое окно X-Window отображается в отдельном окне локального менеджера окон.

X-сервер также имеет дело с насыщенностью цвета дисплея. В ранних дисплеях поддерживались только монохромные или 256-цветные отображения, тогда как в современных дисплеях обеспечиваются миллионы цветов с 24-битной насыщенностью. Таким образом, один пользователь может оперировать 256-цветным дисплеем, тогда как другой может одновременно пользоваться дисплеем с 24-битной насыщенностью. Приложение X-клиента уведомляется о цветовых возможностях и настраивается соответствующим образом.

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

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

Проблемы Java

NNM 6.x обеспечивает хорошую поддержку web-доступа в режиме только чтения к схемам и утилитам NNM (включая некоторые конфигурации, такие как отчетность, ECS и браузер событий), хотя доступны не все средства NNM. В идеальном варианте мог бы использоваться любой web-браузер, но в действительности поддерживается только несколько браузеров, а за версией Java нужно следить и устанавливать необходимые пачи. Данные о последних версиях можно найти в инсталляционном разделе руководства NNM. В таблице 14.1 приведен список браузеров с поддержкой Java, существующих на момент написания этой книги.

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

Кроме того, для обеспечения web-доступа к NNM требуется, чтобы в ovw, выполняющемся на клиенте X-Windows, была открыта схема в режиме записи. Чтобы ограничить доступ авторизованными пользователями, требуется пароль. Этот механизм включается путем редактирования файла /etc/opt/OV/share/www/conf/session.conf, чтобы обеспечить наличие строки UserLogin: on. ID пользователей вводятся с помощью команды ovhtpasswd username, а пароли хранятся в файле /etc/opt/OV/share/www/etc/htpasswd. Наконец, заметим, что по умолчанию файл $OV_CONF/ovw.auth разрешает доступ любого пользователя из любого компьютера.

Пропускная способность и X-Windows

Систему X-Windows окружает целый ряд мифов, и один из них касается требований к пропускной способности. Часто упоминаются передача растровых изображений, движения мыши и отсутствие сжатия.

Обычно в X-Windows растровая графика не передается, если только приложение специально этого не потребует. Например, невзирая ни на что, по сети должны посылаться небольшие растровые изображения внутри пиктограммы устройства, и то же относится к растровому изображению фона. Эти встроенные типы данных не имеют никакого отношения к X-Windows и полностью связаны с прикладными требованиями ovw. Все другие объекты, изображаемые на X-дисплее, воспроизводятся в локальном режиме при получении описывающих их инструкций xlib. Например, зеленый прямоугольник 100x100 передается не как растровое изображение, а как краткая, крошечная графическая команда xlib от X-клиента к X-серверу. Для повышения эффективности эти команды буферизуются.

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

X-Windows замечательно работает через каналы WAN. Для более медленных каналов WAN часто применяется сжатие последовательных каналов в маршрутизаторах. Для сессии X-Windows требуется, по крайней мере, 56Kbps, но задержка является большей проблемой, чем пропускная способность.

Решения для X-Windows с применением сжатия обеспечиваются в продуктах Serial XPress компании Tektronics, XRemote компании NCD и Low Bandwidth X (LBX). LBX является частью спецификации X11R6.3 и реализуется в продукте Broadway компании Hummingbird. Заметим, что VNC является альтернативой X-Windows при низкой пропускной способности.

В заключение заметим, что производительность X-терминала можно повысить путем обеспечения вспомогательной памяти. Когда невидимое окно перемещается на передний план, терминал X-Windows сможет перерисовать окно из вспомогательной памяти. Это означает, что удаленному X-клиенту не потребуется самому перерисовывать окно.

Печать с использованием NNM

С NNM можно работать из эмулятора X-Windows или из web-клиента в среде любой операционной системы, которая поддерживает X-Windows и Netscape 4.6 или более старшей версии. При наличии такого разнообразия платформ не существует согласованного способа печати информации, предоставляемой NNM (см. обсуждение особенностей разных платформ в разделе "Создание мгновенных снимков экранов схем" в лекции 5).

Вопросы кадрового обеспечения для NNM

Развертывание NNM часто представляется как техническая задача, масштабность и сложность которой требуют применения методов управления проектами. Кроме того, при развертывании NNM возникают вопросы (не проблемы) кадрового обеспечения.

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

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

Кто отвечает за поиск и устранение неисправностей самого приложения NNM? Иерархия поддержки для пользовательского сообщества, вероятно, начинается с лидера локального сайта NNM, за которым следуют администратор NNM из персонала IT, администратор системы UNIX и консультант NNM. Для разрешения проблем продукта NNM требуется заключение контракта на поддержку с Response Center компании HP.

Кто решает проблемы DNS? NNM зависит от правильного функционирования сервисов имен. Но серверы имен рассредоточены, администраторы их узлов получают информацию от других системных и сетевых администраторов, и клиентские системы могут использовать разнообразные сервисы именования. Если добавить к этому серверы динамического DNS, WINS и DHCP, становится очевидно, как много разных людей могут привлекаться к разрешению проблем DNS.

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

Кто осуществляет системное администрирование? На небольших установках администратор приложения NNM может одновременно являться и администратором UNIX. В более крупных компаниях могут работать отдельные администраторы приложения NNM и системы UNIX.

Кто разрабатывает специальные приложения? Обычно этим занимается программист, разработчик или аналитик, обученный C/C++, Perl, Java и API HP OpenView. Однако любой сотрудник может воспользоваться средством MIB Application Builder системы NNM.

Определение круга пользователей схем, доступных только по чтению

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

ovw -ro -map map_name

Во-вторых, если права доступа к схеме (чтобы увидеть права доступа, нужно выполнить команду ovwls, а чтобы изменить их – команду ovwperms ) препятствуют получению пользователем доступа для чтения и записи, то схема также открывается в режиме только чтения. В-третьих, когда схема открывается в режиме чтения и записи, дополнительные копии схемы могут открываться исключительно в режиме только чтения. В-четвертых, схема, открытая с использованием интерфейса web-браузера, всегда является схемой только для чтения (см. подробную информацию в главе 9 руководства Managing Your Network with HP OpenView Network Node Manager ).

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

Кто отвечает за хранение схем?

NNM-схемы представляют собой набор файлов, для которых коллективно назначаются согласованные права доступа файловой системы, соответствующие правам доступа к схеме. Это значит, что у схем имеются независимые права чтения и записи, а также ассоциированные с ними имена владельцев и групп. Владелец схемы является ее хранителем и имеет по отношению к ней права чтения и записи. Производственные схемы предназначены для общего использования в режиме только чтения, так что владельцем схемы является назначенный конструктор схем. Для крупных сетей сохранение настроенных схем связано с большой ответственностью, и эта ответственность обычно возлагается на выделенного конструктора схем. Только привилегированный пользователь может редактировать любую схему NNM, но идею сделать владельцем схемы пользователя root нельзя назвать удачной. Для простого редактирования схем не требуется абсолютная власть привилегированного пользователя. Поэтому лучше всего сделать конструкторов схем членами группы ОС UNIX, имеющими коллективный доступ по записи к производственным схемам.

Кто создает MIB-приложения?

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

Группа IT, поставляющая инструментарий NNM для общего пользования, предпочтет предоставлять собственные MIB-приложения, поскольку они влияют на структуру меню через регистрационные файлы приложений. Поэтому для рядовых пользователей производственных систем NNM можно удалить меню NNM для конструирования MIB-приложений. Это меню должно быть только у персонала поддержки инструментария NNM. Таким образом, регистрационный файл конструктора MIB-приложения отсутствует в регистрационном каталоге приложений общих пользователей, но не пользователей службы поддержки NNM. Напомним, что настройка меню контролируется переменной окружения $OVwRegDir. Настройка меню является сложной задачей, для выполнения которой следует вооружиться информацией из главы 9 "Using ARF Files to Control Menu Choices" руководства Managing Your Network with HP OpenView Network Node Manager.

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

Кто отслеживает неисправности самой системы NNM?

Многолетний опыт убеждает меня, что пока пользователи не обретут доверие к NNM, они будут склонны обвинять инструмент во всех неприятностях, с которыми доведется столкнуться. Из моего опыта также следует, что большую часть времени NNM работает корректно. Обычно, при внимательном изучении все симптомы можно объяснить в терминах реальной проблемы сети. Конечно, время от времени в NNM встречаются "опечатки". (Читатели, знакомые с индустрией производства микросхем, узнают этот политически корректный термин.)

Когда пользователи испытывают затруднения при работе с NNM, им следует позвонить в свою службу поддержки IT, послать туда сообщение по e-mail или поместить вопрос на списочном сервере NNM, который поддерживает эта служба. Большие компании могут иметь в узле NNM специальный центр, действующий как пункт первого контакта для пользовательского сообщества узла.

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

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

OV Forum является независимой организацией со своим web-сайтом http://www.ovforum.org. На этом сайте поддерживаются поисковые средства и сервис электронной почты для поддержки дискуссионного списка OpenView. Это ценный ресурс для сообщества NNM. Чтобы в полной мере воспользоваться преимуществами, которые предлагает OpenView Forum, следует стать его участником.

Не менее важными являются службы поддержки HP. web-сайт HP OpenView имеет адрес http://www.openview.hp.com, там можно прочитать новости о продукте и скачать патчи. Заказчики, у которых имеется соглашение о поддержке, могут осуществлять поиск в базе данных разрешения проблем и звонить в Response Center.

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

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

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

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

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

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

Наконец, взаимная связь между 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, как, например, средство выравнивания пиктограмм по вертикали и по горизонтали и средство создания специальной подсхемы сетевой магистрали.