Компания HP
Опубликован: 22.09.2006 | Доступ: свободный | Студентов: 617 / 52 | Оценка: 4.22 / 3.72 | Длительность: 22:59:00
ISBN: 978-5-9556-0042-6
Лекция 14:

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

< Лекция 13 || Лекция 14: 1234 || Лекция 15 >

Пропускная способность и 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.

< Лекция 13 || Лекция 14: 1234 || Лекция 15 >
Андрей Хохлов
Андрей Хохлов
Россия
Игорь Соловьев
Игорь Соловьев
Россия, Братск