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

План проекта по развертыванию NNM

Лекция 1: 1234567 || Лекция 2 >

Значимость консультантов, системных администраторов и менеджеров проекта

В проекте больших систем NNM имеется слишком много работы для одного или двух человек, чтобы завершить деятельность в приемлемое время. Требуется огромный опыт во многих областях, а встретить это у одного человека – большая редкость.

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

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

Нужны также навыки инсталляции NNM, конфигурирования, настройки, сопровождения, обновления, обучения и руководства. Здесь ключевую роль играют консультанты.

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

При наличии специальных требований, которым NNM не удовлетворяет, необходимо разрабатывать заказной код, имеющий отношение к работе с настроенными схемами, управлению конфигурационными файлами, подпрограммам отображения данных и скриптам сокращения объема базы данных SNMP. Это требует навыков написания скриптов на языках Perl, C/C++ и shell, а также умения использовать средства разработки NNM. С подобными задачами лучше всего справляются разработчики программного обеспечения.

Празднование победы

Успешный проект приводит к достижению всех намеченных целей к запланированной дате, и наступает время объявить о победе. Это необходимо в целях признания успехов группы IT и ее соратников. Одним из способов признания являются подписанные IT-менеджерами и обрамленные в рамки официальные письма, в которых участникам выражается благодарность и подробно описываются их достижения. Возможно, каждому участнику следует вручить еще и подарочный сертификат. Наконец, в завершение мероприятия все приглашаются за праздничный стол.

Планирование оперативной вставки исправлений и модернизации

При наличии полнофункционального развертывания NNM приходится решать задачу сопровождения. В некоторых или во всех системах NNM могут потребоваться вставка патчей или модернизация. Может потребоваться внесение патчей в основную операционную систему или в одну из ее подсистем (такую как DNS). Может понадобиться настройка какого-либо параметра. В некоторых узлах может наблюдаться низкая производительность, и для улучшения ситуации потребуется дополнительная дисковая и основная память. При перемещении системы в другое место может возникнуть необходимость в замене IP-адреса системы NNM. Может понадобиться вставка патчей в пакеты сторонних поставщиков, таких как CiscoView, Optivity или NetCool. Все эти рутинные действия могут повторяться изо дня в день.

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

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

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

При модернизации NNM появляются дополнительные заботы. Форматы некоторых файлов (таких как snmpCol.conf ) могут измениться, и потребуется их преобразование. Могут появиться новые демоны, для мониторинга которых понадобится конфигурирование HP OV Operations. Неизбежным решением являются изменения в структуре меню, отражающие наличие дополнительных функциональных возможностей. Для изучения новых возможностей и изменений модернизированной версии NNM рекомендуется обязательно прочесть материал Help:What's New in the GUI и, возможно, пройти курсы в Центре подготовки HP Delta Training. Пользователей следует известить об изменениях, с которыми они столкнутся после модернизации, и обучить тому, как пользоваться преимуществами новых средств. Материал корпоративного учебного курса тоже должен быть модернизирован.

Время от времени у отдельных узлов могут возникать особые проблемы. Например, система NNM может раскрыть новую подсеть, где у одного из устройств плохо работает агент SNMP, возвращающий данные, которые заставляют netmon прекращать выполнение или зацикливаться. Если в распоряжении имеется исправляющий ситуацию патч, может оказаться целесообразным залатать такую систему сразу. В данном примере можно было бы включить полную журнализацию для демона netmon и подождать, когда проблема проявится. После этого можно найти неисправное устройство в журнальном файле netmon.trace и поместить его IP-адрес в файл netmon.noDiscover.

Лекция 1: 1234567 || Лекция 2 >