Межплатформенные вопросы при использовании NNM
Пропускная способность и 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.