Книжная полка Сохранить
Размер шрифта:
А
А
А
|  Шрифт:
Arial
Times
|  Интервал:
Стандартный
Средний
Большой
|  Цвет сайта:
Ц
Ц
Ц
Ц
Ц

OpenView. Network Node Manager. Разработка и реализация корпоративного решения

Покупка
Новинка
Артикул: 825019.01.99
Доступ онлайн
1 000 ₽
В корзину
Курс посвящен планированию, внедрению и сопровождению продукта OpenView Network Node Manager (NNM) компании Hewlett-Packard в корпоративной сети. Курс не содержит пересказа руководств и учебных пособий по NNM. Рекомендуется, чтобы читатель перед изучением и до развертывания NNM прошел соответствующее обучение.
Бломмерс, Д. OpenView. Network Node Manager. Разработка и реализация корпоративного решения : краткий учебный курс / Д. Бломмерс. - Москва : ИНТУИТ, 2016. - 199 с. - ISBN 5-9556-0042-6. - Текст : электронный. - URL: https://znanium.ru/catalog/product/2137127 (дата обращения: 01.05.2024). – Режим доступа: по подписке.
Фрагмент текстового слоя документа размещен для индексирующих роботов. Для полноценной работы с документом, пожалуйста, перейдите в ридер.
OpenView Network Node Manager

2-е издание, исправленное

Национальный Открытый Университет “ИНТУИТ”
2016

2
УДК 004.738.2:658
ББК 21
Б70
OpenView. Network Node Manager. Разработка и реализация корпоративного решения / Джон
Бломмерс - M.: Национальный Открытый Университет “ИНТУИТ”, 2016
ISBN 5-9556-0042-6

Курс посвящен планированию, внедрению и сопровождению продукта OpenView Network Node
Manager (NNM) компании Hewlett-Packard в корпоративной сети.
Курс не содержит пересказа руководств и учебных пособий по NNM. Рекомендуется, чтобы читатель
перед изучением и до развертывания NNM прошел соответствующее обучение.

(c) ООО “ИНТУИТ.РУ”, 2005-2016
(c) 2005-2016

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

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

Введение

Если в небольших сетях можно обойтись единственной системой Network Node
Manager (NNM), то для сетей мирового масштаба с многочисленными узлами
потребуется много систем NNM. Для успешного развертывания крупных реализаций
необходим формальный план проекта. Такой план должен охватывать следующие
аспекты управления сетью:

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

4
В зависимости от назначенных ролей, пользователям может потребоваться краткая
подготовка для работы оператором или полный курс обучения специальностям
оператора и администратора. Если придется проводить обучение на местах,
должны быть определены ограничения по времени и бюджету.
Почти все крупные корпоративные сети являются географически
рассредоточенными и обслуживают многочисленные логические бизнес-объекты.
Поэтому группа IT будет развертывать много систем NNM, и каждая из них будет
действовать в своем домене управления. Опыт, полученный во время пилотного
тестирования, поможет определить наилучший способ конфигурирования каждой
системы NNM, чтобы реальная топология управляемой ею сети как можно ближе
соответствовала желаемой модели.
Планирование решения текущих задач при поддержке развертывания NNM
подразумевает формализацию плана поддержки, набор сотрудников в службу
поддержки, определение плана увеличения масштаба задач и процедур
публикации. Сюда входит формальный список персонала службы поддержки,
списочный сервер для общих технических дискуссий и испытательная
лаборатория NNM для тиражирования задач, тестирования и разработки.
Стратегия резервного копирования необходима на тот случай, когда данные
теряются из-за отказа аппаратуры, или портится база данных, пользователь
нечаянно удаляет файл или схему, возникают изменения в требованиях, либо
требуется удалить пач1) или вернуться к предыдущей версии. Задача этой
стратегии – минимизировать планируемое время простоя.
Для крупных проектов по развертыванию NNM следует учитывать наличие
продукта IT Operations компании HP для администрирования систем NNM. Этот
продукт позволяет центральному узлу производить мониторинг критических
ресурсов каждой системы NNM, загружать пачи в удаленные компьютеры,
производить резервное копирование, управлять спулером печати, выполнять
периодические проверки исправности и осуществлять общее системное
администрирование.
Исключительно важно привлечь для развертывания NNM одного или нескольких
опытных консультантов, системных администраторов и менеджеров проекта. Эти
специалисты помогут обеспечить необходимые кадровые ресурсы и должный
уровень компетенции. Это обеспечивает успешное и своевременное завершение
проекта.
Должна планироваться поддержка систем NNM, развернутых в корпоративной
сети. График вставки пачей должен составляться таким образом, чтобы
минимизировать время простоя и риски. Для установки и второстепенных, и
основных редакций NNM может потребоваться массовая модернизация
программного обеспечения. Также может оказаться, что большая часть
пользователей задействует те возможности систем NNM, для поддержки
приемлемой производительности которых придется выполнить модернизацию
некоторых систем.

Определение требований, которым должен удовлетворять NNM

В этом разделе приводятся выборочные вопросы и ответы, которые могут помочь
группе IT сформулировать требования, предъявляемые сообществом пользователей к

5
решению NNM в области сетевого управления. Вероятнее всего, для выполнения
анализа требований будет проводиться опрос этого сообщества.

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

Какие устройства следует раскрыть и включить в контур управления? По умолчанию
NNM будет обнаруживать IP-устройства независимо от того, поддерживают ли они
простой протокол сетевого управления (SNMP). Нужно ли раскрывать каждое
устройство сети, или в основную задачу входит только управление сетевой
инфраструктурой? Следует ли управлять серверами и сетевыми принтерами? Можно
написать фильтр раскрытия, чтобы контролировать типы устройств, которые
раскрывает NNM.

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

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

Какие требуются виды отчетов? Некоторые встроенные инструментальные средства
NNM доступны через графический пользовательский интерфейс (GUI), тогда как
другие запускаются по приглашению из shell (или по приглашению MS-DOS или
Windows). Потребуется ли пользователям производить и печатать большие 24-битовые
цветные снимки экрана, или эти снимки будут сохраняться на персональном
компьютере? Понадобится ли ведение истории событий для документирования
проблем? Нужны ли диаграммы производительности в оперативном режиме? Как
долго придется поддерживать историю событий? В большинстве случаев потребуется
обеспечить базовые возможности сохранения образа экрана и печати и предложить
диаграммы производительности.

Будет ли у пользователей иметься возможность выбора платформ, с которых будет
производиться доступ к NNM, таких как Windows, Linux, UNIX, X-terminal и
Macintosh? Будет ли у них возможность и желание обязательно запускать эмуляторы
X-Window, чтобы получить такой доступ? Достаточен ли интерфейс web-браузера?

6
Нужен ли на этих платформах доступ из командной строки? Если у пользователей нет
соответствующего программного обеспечения, придется его приобрести,
протестировать и обеспечить поддержку.

Какая защита требуется для нормальной эксплуатации NNM? Достаточна ли обычная
схема UNIX “логин/пароль”? Нужно ли, чтобы пользовательские учетные записи были
согласованы на всех системах, на которых работает NNM? В большинстве случаев
ответ положителен.

Насколько доступными должны быть NNM? На 99% или более? Учитываются ли в
этих цифрах перерывы в работе для планового обслуживания? Должно ли приложение
NNM быть доступным каждый день в течение всего дня? Отметим, что для
удовлетворения потребности в резервном копировании базы данных, настройке схем и
в получении некоторых данных нужен, по крайней мере, режим частичного
функционирования, при котором приостанавливаются программы-демоны NNM (для
NNM 6). Является ли резервный опрос полностью приемлемым решением для
достижения высокой степени доступности средств NNM?

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

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

Совместное использование планов и другой проектной
информации на web-сайте

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

Документы, размещаемые на web-сайте, следует преобразовать в формат PDF (Adobe’s
Portable Document Format), чтобы любой пользователь, независимо от компьютерной

7
платформы, мог читать и печатать их. Это также препятствует произвольному
изменению документов. Начиная с версии 4.0.5, в Acrobat Reader поддерживается
средство поворота страниц. Имеется соответствующий загружаемый компонент web-
браузера, так что документы в формате PDF можно просматривать непосредственно
через web. Это важный механизм доставки пользователям векторной графики,
поскольку такое представление является масштабируемым, тогда как растровые
изображения в общем случае не масштабируются. Использование PDF избавляет
пользователя от необходимости покупать, устанавливать, загружать и изучать
специализированное программное обеспечение. Кроме того, не приходится решать
проблему разных версий документов.

К видам информации, пригодным для совместного пользования на web-сайте,
относятся представленные в формате PDF руководства HP по NNM (которые можно
загрузить с web-сайта HP, посвященного OpenView), проектные планы, соглашения о
функциональности, соглашения об уровне сервиса (SLA), организационные графики,
руководства по конфигурации, процедуры настройки, производственные инструкции,
советы и технические приемы, чертежи сети и примерные схемы NNM.

Составление, согласование и утверждение соглашения о
функциональности

Соглашение о функциональности заключается между пользователями NNM и отделом
информационной технологии (IT). В соглашении о функциональности разъясняется
следующее: какие функции должна выполнять система NNM; как обеспечивается
поддержка отдела IT; какие имеются процедуры расширения масштаба задач; цели
внедрения NNM; наполнение схем; определение порогов производительности и типы
собираемых данных о производительности. Это соглашение может разрастаться до 50-
страничного документа и выдерживать множество редакций, прежде чем будет
принято всеми сторонами.

В соглашении о функциональности перечисляются пользователи и участники
поддержки NNM. Участниками поддержки обычно являются отдел IT и группа
системного администрирования. Группа системного администрирования поддерживает
не только системы, на которых работает NNM, но также и системы Windows, Linux,
UNIX и Macintosh, из которых пользователи обращаются к NNM посредством X-
Window или web-браузеров. К числу этих пользователей обычно относятся
конструкторы схем NNM, справочная служба, привлеченные исследователи и
ремонтники, которые используют NNM для отслеживания сетевых проблем. В
небольших организациях несколько сотрудников могут одновременно выступать в
ролях системного администратора, конструктора схем, исследователя и пользователя.

В соглашении о функциональности также перечисляются места, в которых будут
инсталлироваться системы NNM, описываются условия питания от источников
переменного тока (AC), тип стоек и требуемый тип организации LAN. Определяется
также территория, которую будет обслуживать каждая из систем NNM. Несмотря на
то, что соглашение о функциональности может содержать эти и другие требования,
конечно, может существовать и специальный документ о требованиях.

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

Выбор масштабируемого аппаратного обеспечения в каждом узле
NNM

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

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

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

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

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

Должны быть предусмотрены отсеки дополнительных устройств, чтобы можно было
добавлять дисковую память, и дополнительные каналы дискового ввода/вывода (такие
как шина SCSI) для увеличения пропускной способности дискового ввода-вывода. В
крайнем случае, должна существовать возможность замены существующего жесткого
диска на диск большего объема, но для этого требуется резервное копирование и шаг
восстановления, что неизбежно вызывает увеличенное время простоя. Поскольку
большая база данных NNM может стать узким местом производительности,
размещение тома, на котором она располагается, на нескольких (от двух до четырех)
дисковых носителях может радикально улучшить время реакции.

9
В редких случаях стандартный системный Ethernet LAN-адаптер может стать узким
местом производительности, особенно когда NNM управляет большим числом
присоединенных к LAN устройств с использованием стратегии активного опроса.
Разумно также предусмотреть опцию модернизации LAN-адаптера для перехода к Fast
Ethernet (100BASE-T), чтобы сократить задержки в сети. Технология Fast Ethernet
особенно важна, если производится сетевое резервное копирование, поскольку
стандартное Ethernet-соединение резко увеличивает время копирования. Естественно,
система NNM должна подключаться к выделенному порту коммутатора Ethernet, чтобы
можно было избежать конфликтов с трафиком LAN общего пользования. В идеальном
случае этот порт конфигурируется для дуплексного (FDX) функционирования, чтобы
избежать коллизий и потенциально удвоить пропускную способность. Следует
позаботиться о мониторинге этого порта – частой проблемой являются возврат при
автоматическом согласовании к 10 Mbps и полудуплексное (HDX) функционирование.

Меня могут спросить: а почему бы, прежде всего, не определить правильный размер
системы NNM? Ответ содержится в PDF-документе компании HP, который является
руководством по заданию размера и называется Network Node Manager 6.0 Performance
and Configuration Guide. В этом руководстве требуется, чтобы администратор NNM
был в состоянии оценить такие параметры, как число активных пользователей, число
управляемых устройств, число интерфейсов (объектов в базе данных), скорость
поступления сетевых событий и объем данных истории SNMP, которые требуется
собирать. Подобные оценки неизбежно будут приблизительными.

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

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

Определение цели и проведение пилотного теста

10
Доступ онлайн
1 000 ₽
В корзину