Если в небольших сетях можно обойтись единственной системой
В этом разделе приводятся выборочные вопросы и ответы, которые могут помочь группе IT сформулировать требования, предъявляемые сообществом пользователей к решению 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-браузера? Нужен ли на этих платформах доступ из командной строки? Если у пользователей нет соответствующего программного обеспечения, придется его приобрести, протестировать и обеспечить поддержку.
Какая защита требуется для нормальной эксплуатации NNM? Достаточна ли обычная схема UNIX "логин/пароль"? Нужно ли, чтобы пользовательские учетные записи были согласованы на всех системах, на которых работает NNM? В большинстве случаев ответ положителен.
Насколько доступными должны быть NNM? На 99% или более? Учитываются ли в этих цифрах перерывы в работе для планового обслуживания? Должно ли приложение NNM быть доступным каждый день в течение всего дня? Отметим, что для удовлетворения потребности в резервном копировании базы данных, настройке схем и в получении некоторых данных нужен, по крайней мере, режим частичного функционирования, при котором приостанавливаются программы-демоны NNM (для NNM 6). Является ли резервный опрос полностью приемлемым решением для достижения высокой степени доступности средств NNM?
В ответ на эти вопросы следует сказать, что необходимо всегда иметь средства управления сетью в доступном состоянии, 99% не считается высоким уровнем доступности, а резервный опрос обязателен.
Насколько велика сеть, которой предстоит управлять? Для достаточно больших сетей нецелесообразно обеспечивать крупную компьютерную систему, исполняющую роль основного узла в приложении NNM. Чтобы иметь возможность поддерживать пользовательскую базу, этот одиночный компьютер должен быть большим и дорогим; требуются также чрезмерная мощность процессора и пропускная способность. В распределенном управленческом решении системы NNM, называемые накопительными станциями, могут размещаться в пределах географии своих доменов управления, поблизости от пользователей. Чтобы сохранить единое представление сети, управляющая станция импортирует из накопительных станций данные об устройствах и топологии и создает новую схему сети, представляющую предприятие в целом.
Для наилучшего обслуживания пользователей, разработчиков и менеджеров проекта NNM более всего подходит совместное использование информации, размещенной на web-сервере. Страницы должны обновляться, поскольку важно поддерживать документы и информацию в актуальном состоянии. Никто не обратится повторно к устаревшему web-сайту. В любое время, когда кому-либо требуется информация о проекте NNM, можно посетить web-сайт и просмотреть или скачать нужную информацию.
Документы, размещаемые на web-сайте, следует преобразовать в формат PDF (Adobe’s
К видам информации, пригодным для совместного пользования на web-сайте, относятся представленные в формате PDF руководства HP по NNM (которые можно загрузить с web-сайта HP, посвященного
Соглашение о функциональности заключается между пользователями NNM и отделом информационной технологии (IT). В соглашении о функциональности разъясняется следующее: какие функции должна выполнять система NNM; как обеспечивается поддержка отдела IT; какие имеются процедуры расширения масштаба задач; цели внедрения NNM; наполнение схем; определение порогов производительности и типы собираемых данных о производительности. Это соглашение может разрастаться до 50-страничного документа и выдерживать множество редакций, прежде чем будет принято всеми сторонами.
В соглашении о функциональности перечисляются пользователи и участники поддержки NNM. Участниками поддержки обычно являются отдел IT и группа системного администрирования. Группа системного администрирования поддерживает не только системы, на которых работает NNM, но также и системы Windows, Linux, UNIX и Macintosh, из которых пользователи обращаются к NNM посредством X-Window или web-браузеров. К числу этих пользователей обычно относятся конструкторы схем NNM, справочная служба, привлеченные исследователи и ремонтники, которые используют NNM для отслеживания сетевых проблем. В небольших организациях несколько сотрудников могут одновременно выступать в ролях системного администратора, конструктора схем, исследователя и пользователя.
В соглашении о функциональности также перечисляются места, в которых будут инсталлироваться системы NNM, описываются условия питания от источников переменного тока (AC), тип стоек и требуемый тип организации LAN. Определяется также территория, которую будет обслуживать каждая из систем NNM. Несмотря на то, что соглашение о функциональности может содержать эти и другие требования, конечно, может существовать и специальный документ о требованиях.
После введения в действие систем NNM пользователям, несомненно, захочется иметь большее число средств и получить более широкую функциональность. Вместо того чтобы направлять эти запросы об изменениях непосредственно в департамент IT, можно организовать совет по изменениям или управляющий комитет. В больших компаниях такой совет рассматривает запросы на модернизацию и соотносит их с бюджетом и ресурсами разработчиков.
Не всегда удается избежать выбора аппаратной конфигурации, которая окажется недостаточной по прошествии нескольких месяцев. Ухудшение времени ответа запомнится как неудачный опыт, который может ограничить признание системы сообществом пользователей. Каковы бы ни были значения начальных параметров, оцениваемые для каждой системы NNM, важно выбирать масштабируемую систему.
Масштабируемая система – это такая система, которую можно модернизировать на месте, так что влияние данной процедуры на работоспособность NNM будет ограничено всего несколькими минутами простоя.
Немасштабируемая система конфигурируется в некотором роде по максимуму. Масштабируемость означает, что компоненты аппаратуры можно модернизировать с целью увеличения производительности и сокращения времени выполнения транзакций.
В масштабируемой системе предусматривается место для установки дополнительных плат центрального процессора, или, по крайней мере, имеется возможность модернизации существующих плат ЦП с увеличением размеров кэш-памяти. Дополнительные платы ЦП не повысят производительность однопотокового процесса, но они могут использоваться параллельными процессами для ослабления давления, создаваемого множеством одновременно работающих пользователей.
Кроме того, следует иметь резервные слоты памяти, или, по крайней мере, существующая память должна быть модернизируемой за счет использования модулей RAM большей емкости. Когда операционная система не в состоянии предоставить необходимую память всем работающим приложениям, система виртуальной памяти (VM) обращается к диску для откачки страниц памяти. С увеличением активности VM обмены с дисками могут стать узким местом производительности.
Должны быть предусмотрены отсеки дополнительных устройств, чтобы можно было добавлять дисковую память, и дополнительные каналы дискового ввода/вывода (такие как шина SCSI) для увеличения пропускной способности дискового ввода-вывода. В крайнем случае, должна существовать возможность замены существующего жесткого диска на диск большего объема, но для этого требуется резервное копирование и шаг восстановления, что неизбежно вызывает увеличенное время простоя. Поскольку большая база данных NNM может стать узким местом производительности, размещение тома, на котором она располагается, на нескольких (от двух до четырех) дисковых носителях может радикально улучшить время реакции.
В редких случаях стандартный системный Ethernet LAN-адаптер может стать узким местом производительности, особенно когда NNM управляет большим числом присоединенных к LAN устройств с использованием стратегии активного опроса. Разумно также предусмотреть опцию модернизации LAN-адаптера для перехода к Fast Ethernet (100BASE-T), чтобы сократить задержки в сети. Технология Fast Ethernet особенно важна, если производится сетевое резервное копирование, поскольку стандартное Ethernet-соединение резко увеличивает время копирования. Естественно, система NNM должна подключаться к выделенному порту коммутатора Ethernet, чтобы можно было избежать конфликтов с трафиком LAN общего пользования. В идеальном случае этот порт конфигурируется для дуплексного (
Меня могут спросить: а почему бы, прежде всего, не определить правильный размер системы NNM? Ответ содержится в PDF-документе компании HP, который является руководством по заданию размера и называется Network Node Manager 6.0 Performance and Configuration Guide. В этом руководстве требуется, чтобы администратор NNM был в состоянии оценить такие параметры, как число активных пользователей, число управляемых устройств, число интерфейсов (объектов в базе данных), скорость поступления сетевых событий и объем данных истории SNMP, которые требуется собирать. Подобные оценки неизбежно будут приблизительными.
Даже определение "правильности" в приведенном вопросе является предметом интерпретации. Параметры со временем могут меняться. После принятия средства NNM пользовательским сообществом число активных пользователей может легко удвоиться по сравнению с первоначальными оценками. По мере возрастания уровня требований пользователей к системе изменятся их ожидания относительно времени ответа системы, и встанет вопрос об увеличении масштабов системы, чтобы можно было поддерживать высокий уровень удовлетворенности пользователей. Для удовлетворения новых потребностей могут понадобиться дополнительные схемы. Пользователи могут начать применять дополнительные средства NNM, использование которых не предусматривалось, и это приведет к потреблению еще большего объема ресурсов системы. По мере того как NNM будет становиться общепринятой платформой сетевого управления, могут добавляться дополнительные приложения сторонних поставщиков. Вполне вероятно, что размеры и сфера применения сети будут расти быстрее, чем ожидалось. Наконец, с выпуском компанией HP новых редакций NNM будут меняться и руководства по заданию размеров.
Может быть, на практике окажется целесообразным применить руководства по определению размеров для их исходной оценки, а затем использовать поправочный коэффициент для учета возможности роста. После этого стоит провести пилотное тестирование на самом большом домене управления, чтобы приобрести опыт и соответствующим образом модифицировать формулу оценки размеров. После этого можно развертывать масштабируемую систему.
До развертывания NNM в сети предприятия важно разъяснить преимущества реализации продукта. Пилотное тестирование представляет собой отличный способ укрепить доверие пользователей. В пилотном тесте должны принимать участие несколько узлов. Пилотные пользователи становятся активными пропагандистами NNM. Кроме того, они помогают свести данные о результатах применения системы и производственном опыте в единую таблицу. Успешный пилотный тест следует считать необходимым предварительным условием развертывания NNM в масштабе предприятия.
По сути, пилотный тест является проектом. Продолжительность пилотного тестирования должна быть зафиксирована, скажем, на уровне нескольких месяцев. Должны быть согласованы правила использования систем NNM, и этим правилам нужно следовать. Например, все участники пилотного проекта должны пройти полный курс обучения NNM. Приветствуется обратная связь с пользователями (во всех видах). Данные об успешном применении NNM следует распространять с тем же энтузиазмом, с каким дети обмениваются карточками с покемонами. Уроки будут усвоены. Для поддержки выбранного курса проекта и поощрения наиболее активных участников следует организовывать еженедельные конференции участников пилотного проекта.
В ходе пилотного тестирования выясняется, что в действительности подключено к сети. Ко всеобщему удивлению, может оказаться, что в сетевых устройствах строки сообществ (community string) не всегда сконфигурированы согласованным образом. Может обнаружиться оборудование, про которое забыли или которое только что установили. Будет изучено влияние трафика SNMP на центральные процессоры маршрутизаторов. Проявятся также и "дефектные" агенты SNMP. Придется иметь дело и с проблемами автоматического раскрытия и автоматического размещения.
На ранних стадиях пилотного тестирования фильтр раскрытия будет широко открытым. Это удобно, потому что соответствует предусмотренному по умолчанию в NNM "отсутствию фильтра вообще". Это правильный первый шаг с целью получения реестра сетевых устройств. Затем фильтр раскрытия будет сконфигурирован так, чтобы ограничить NNM раскрытием только тех видов устройств, которыми предстоит управлять, таких как маршрутизаторы, коммутаторы, мосты, концентраторы, сетевые принтеры, серверы и терминальные серверы. Размер базы данных NNM без фильтра раскрытия будет слишком большим, а система после применения фильтра станет работать гораздо быстрее.
В процессе выполнения пилотного проекта различные пользователи будут иметь возможность узнать, как лучше всего конструировать схемы, подходящие для их нужд. Можно усовершенствовать сбор данных SNMP и установку пороговых значений. Наконец, можно оценить объем дискового пространства, необходимого для поддержки требуемых функциональных возможностей. В это время становится ясно, какие размеры системы оптимальны для достижения хорошего времени реакции.
Во время выполнения пилотного тестирования можно произвести тестирование модели удаленной поддержки, чтобы убедиться, что ее можно реализовать в масштабе предприятия. Могут сгладиться трудности с удаленной инсталляцией. Для удобства пользователей можно разработать скрипты. Можно оценить, сколько времени занимает резервное копирование, как быстро синхронизируется схема и насколько чувствительна утилита Grapher SNMP к длинным наборам данных.
Для крупного внедрения NNM в масштабе предприятия потребуется обучение великого множества пользователей. Развертывание системы на 20 узлах с 10 пользователями на каждом означает приобретение 200 учебных модулей. Не все пользователи нуждаются в одинаковом обучении. Потребности в обучении можно нестрого разделить на три категории: полное, двойное и базовое обучение.
Персонал IT, вероятно, конструирует, конфигурирует, модернизирует и подправляет системы NNM в удаленном режиме, так что эти администраторы уже имеют некоторую подготовку просто потому, что они являются теми самыми людьми, которые отвечали за пилотное тестирование. Этим сотрудникам требуется полный курс обучения NNM. Сообщество удаленных пользователей составляет две оставшиеся категории. Пользователи, которым требуется конфигурировать инструментарий NNM (конструкторы схем) или проводить сбор специальных данных (планировщики нагрузки), должны пройти двойное обучение, включающее и администрирование, и применение NNM. Сотрудники, которые только применяют предварительно определенные функциональные возможности, нуждаются в базовом пользовательском обучении.
HP обеспечивает подготовку заказчиков NNM по всему миру, а клиенты посещают наиболее удобно расположенные учебные центры, чтобы получить базовую или расширенную подготовку. Как правило, из оборудования достаточно простой лабораторной среды учебного класса. HP также обеспечивает обучение на территории заказчика. В тех случаях, когда действует
В идеальном случае пользователи обучаются в здании своего предприятия на базе корпоративной сети настроенной версии NNM, предоставляемой группой IT. Это вступает в противоречие с курсом обучения от поставщика, единообразным и основанным на воспроизводимых практических занятиях и упражнениях. Поэтому в больших компаниях группа IT может нанять свою корпоративную группу преподавателей для разработки собственного учебного курса по NNM, отвечающего потребностям и особенностям предприятия. При другом подходе группа IT может заключить договор с выбранным поставщиком обучающих курсов по NNM на поставку курса, настроенного под конкретные условия.
Обычно в компаниях принято управлять сетью по доменам управления путем разделения сети на основе географии, общности бизнес-интересов, функциональных возможностей или архитектуры сети. Разделение сети, прежде всего, определяется географией, и часто карта страны (или континента, или мира) переделывается так, чтобы она отражала домены управления. Пилотный тест обеспечивает хороший испытательный полигон для определения и реализации доменов управления.
Существует риск отсутствия фрагментов сети внутри намеченного домена управления. Это означает, что части сети остаются неуправляемыми. Для реализаций NNM с единственной станцией имеется только один домен управления, и процесс раскрытия вручную направляется во все уголки сети до тех пор, пока не перестанут обнаруживаться новые подсети. Для реализаций NNM с несколькими станциями существует опасность того, что домены могут стыковаться недостаточно плотно. Например, в доменах управления А и В может быть раскрыт маршрутизатор и его подсети, и эти подсети могут сначала оставаться неуправляемыми. В каком домене и какие пиктограммы подсетей следует сделать управляемыми? Требуется значительный объем учета сетевых ресурсов, чтобы можно было гарантировать, что фрагменты домена управления складываются в общую мозаику сети.
Так что же лучше допустить – бреши между доменами или наличие перекрытий? Большинство согласится, что лучше иметь перекрывающиеся домены управления, чем оставить раздел сети неуправляемым. Что произойдет, если ряд сетевых устройств будет управляться более чем одной системой NNM? Управляемые устройства будут дважды получать запросы SNMP, и им в два раза чаще будет перебрасываться информация. Когда устройство выйдет из строя, над проблемой будут работать две группы вместо одной, если, конечно, управление сетью не является централизованным. Куда сетевое устройство посылает прерывание SNMP? Это прерывание посылается на управляющие станции NNM из списка Trap Forwarding программного обеспечения локального агента SNMP.
Сетевые администраторы могут конфигурировать на своих маршрутизаторах списки управления доступом (ACL). Так можно ограничить доступ к указанным сервисам, подобным SNMP, к конкретным устройствам или подсетям. Например, чтобы защитить сервис SNMP на маршрутизаторе, доступ к нему разрешается только локальной системе NNM. Это гораздо более сильный механизм защиты, чем неразглашаемая строка сообщества SNMP. Здесь имеется побочный эффект: ограничение возможности появления перекрытий доменов управления.
При заданной стратегии определения доменов управления правильно конфигурировать систему NNM становится проще. По умолчанию исходным доменом управления является подсеть, в которой находится сама система NNM. Этот домен можно расширить, используя параметр seedfile демона netmon. Параметр seedfile – это список устройств в домене управления, как правило, маршрутизаторов, которые обладают емкими ARP-кэшами и отличной сетевой связностью, что помогает управлять автоматическим раскрытием NNM. Первоначально годится автоматическое раскрытие, направляемое вручную, когда конструктор схемы вручную управляет соответствующими подсетями по мере их обнаружения, пока не будет раскрыт нужный раздел сети.
Поскольку определение доменов управления первоначально является итеративным процессом, было бы хорошо иметь возможность его повторять. Ручные методы повторять нелегко, поэтому, когда все убедятся, что домен управления определен корректно, следует создать и поддерживать список маршрутизаторов для seedfile. Рекомендуется, чтобы мастер-список для всех seedfile (для каждой накопительной и управляющей станции) поддерживался централизованно. Даже если потребуется построить систему NNM заново, знание информации соответствующего seedfile не помешает.
Начнем с определения термина "клиент". В HP принято называть клиентами людей, которые покупают и используют продукты NNM. Но группа IT в компании тоже считает клиентами своих пользователей NNM. Поэтому корпоративные пользователи NNM обращаются за поддержкой в связи с проблемами NNM в свой отдел IT, а отдел IT по поводу проблем с NNM обращается в группу поддержки HP.
Для поддержки своих клиентов NNM группа IT создает список сотрудников – руководителей проектов, ведущих специалистов и консультантов локальных узлов, персонала NNM и системных администраторов. В списке содержатся имена, роли, телефонные номера и номера
Для обмена общей информацией группа IT может установить списочный сервер, такой как majordomo, на услуги которого подписываются клиенты. Каждый, кто хочет задать вопрос или дать совет, может послать в список сообщение по электронной почте. Все подписчики списка получают копию этого сообщения, и каждый может прислать ответ или новости. Список архивируется, а доступ к нему предоставляется через web-интерфейс.
К числу проблем, требующих особого внимания, относятся затруднения с доступом зарегистрированных пользователей, аномалии операционной системы, выход из строя сети, неправильная конфигурация NNM, низкая производительность, дефекты обучения, нарушения защиты, зависания пользовательских X-терминалов и ошибки конфигурации DNS.
Группе IT следует иметь небольшую лабораторную среду с одной или несколькими лицензированными тестовыми системами NNM и типовым сетевым оборудованием. Некоторые сложные проблемы NNM, обнаруженные в рабочей обстановке, лучше воспроизводятся в лабораторных условиях, где простои не играют роли. Тестовую систему можно реконфигурировать и привести в такое состояние, чтобы проблема проявилась.
Эту лабораторную среду можно сделать более полезной, если содержащиеся в ней системы NNM принадлежат к "золотой подсети", которая включается в ACL корпоративного сетевого оборудования. Это дает лабораторной системе NNM возможность выявлять и разрешать проблемы, которые связаны с сетевым оборудованием, используемым в рабочих условиях. Кроме того, лабораторную систему можно использовать как запасную станцию сбора резервных данных. Это может стать частью плана восстановления после аварийных ситуаций.
В надежной системе NNM используются преимущества зеркальных дисков. Время простоя минимизируется за счет применения следующей процедуры. Прежде всего, требуется приостановить систему NNM или полностью вывести ее из рабочего состояния. После этого нужно отключить диск зеркальной системы и перезапустить систему NNM, которая теперь будет работать без активного зеркалирования. Далее следует выполнить резервное копирование томов с неактивного зеркального диска, и когда это будет сделано, снова установить зеркальный режим, при котором текущее состояние активного диска автоматически переброшено на тот диск, который только что был скопирован. Поскольку память на жестких дисках очень недорога, некоторые системные администраторы создают тройные зеркала для дополнительной надежности. В этом случае, когда с одного из дисков производится резервное копирование, система NNM работает на зеркальной паре. Общепринятым термином для дисковой подсистемы с чередованием (striping) дисков является RAID 0, а для подсистемы с зеркалированием – RAID 1; комбинированный вариант называется RAID 1+0.
Заметим, что в NNM обеспечивается утилита резервного копирования ovbackup.ovpl, которая автоматизирует правильную синхронизацию всех баз данных. Она создает моментальный снимок базы данных в буферной области и предназначается для вызовов из процесса резервного копирования операционной системы. Если пользоваться этим средством, не придется заботиться о расположении
Предпочтительный механизм резервного копирования передает через сеть данные каждого сжатого образа дискового тома в выделенную систему резервного копирования. Здесь становится очевидным преимущество адаптера Fast Ethernet как для NNM, так и для системы резервного копирования, поскольку важно сохранять небольшой временной интервал резервного копирования. Задача автоматизации резервного копирования и управления им обычно возлагается на системных администраторов, у которых есть навыки в технологии зеркалирования, резервного копирования и управления дисками.
Наибольший объем данных, подлежащих резервному копированию, находится в базе данных (все, что хранится под $OV_DB ). Однако разумно собирать все данные на инсталляционных и рабочих дисках NNM. Это гарантирует, что будет произведено резервное копирование и конфигурационных файлов (хранящихся под $OV_CONF ).
Статические конфигурационные файлы и программное обеспечение всегда можно переустановить, а не восстанавливать с резервной копии. Например, регистрационные файлы (ARF) (хранящиеся под $OV_REGISTRATION ) не изменяются в оперативном режиме, если только пользователям не разрешается создавать незапланированные /etc/named.conf и файлы, сохраняемые под /var/named ) являются статическими, и их нужно скопировать всего один раз.
Конструкторы схем быстро привыкают сохранять свои настройки подсхем Root и Internet (по умолчанию местом их хранения является /var/opt/OV/tmp/ipmap.out ). Это связано с тем, что они затрачивают при работе изрядное количество времени. Размер текстовых файлов больших схем превышает мегабайт. Вместо того чтобы использовать при сохранении файла настроек схемы имя файла, назначенное по умолчанию, конструкторы схем (которые могут управлять многими схемами систем NNM) обычно включают в имя файла временную метку и, возможно, метку узла. Особо аккуратные конструкторы схем сохраняют копии этих файлов на своих персональных рабочих станциях, но они все равно включаются в ежедневное резервное копирование системы NNM.
Следует быть готовым заново строить систему NNM в удаленном режиме с нуля. Это может стать необходимым, если дисковые устройства повредятся или сломаются. Опытный системный администратор в состоянии собрать загрузочный CD-ROM, содержащий операционную систему и инсталлятор NNM. Достаточно разрешить загрузку системы NNM с CD-ROM и заново построить образ NNM в удаленном режиме. Процесс дистанционной инсталляции завершается демонтированием NFS от системы NNM и ее монтированием к инсталляционному серверу.
Реконструкция удаленной системы NNM завершается монтированием к NFS тома резервного копирования сервера резервного копирования, копированием по сети сжатого образа тома на другой том системы NNM и восстановлением архива на целевом томе. Системный администратор управляет этим процессом в интерактивном режиме в окне telnet.
Может случиться, что резервные данные являются точной копией поврежденных данных. Например, предположим, что на протяжении ряда недель база данных NNM все более портится, пока не станет полностью бесполезной. Резервные копии, таким образом, тоже бесполезны; поиск хорошей копии может занять много времени, а если такая копия найдется, она может оказаться слишком старой, чтобы принести пользу. В таком случае после инсталляции операционной системы и приложения NNM (или подтверждения, что с ними все в порядке) базу данных NNM нужно строить заново посредством автоматического раскрытия. Применение хорошей копии seedfile и фильтра раскрытия позволяет процедуре автоматического раскрытия заново построить базы данных объектов и топологии. Когда автоматическое раскрытие сойдется (прекратится раскрытие новых объектов), следует создать новые схемы с соответствующими именами и импортировать файлы настроек.
Продукт HP OV Operations – это платформа управления сетью и системой, построенная поверх выполняемых компонентов NNM. Базовый процессор автоматического раскрытия, база данных и пользовательский интерфейс – это те же самые элементы, что используются в NNM. Это делает HP OV Operations идеальным решением для управления большим числом (более 20) систем NNM, распределенных в сети предприятия.
В чистой среде HP можно использовать HP OV Operations совместно с дополнительно подключаемыми продуктами как полное решение системного администрирования. Для выполнения автоматического резервного копирования и интерактивных операций восстановления можно использовать продукт OmniBack. Для управления конфигурированием системного программного обеспечения пригоден продукт SoftWare Distributor. Для управления
Время выполнения пилотного проекта идеально подходит для накопления начального опыта применения HP OV Operations для управления системами NNM. Время от времени один из демонов NNM может завершиться, или может перестать работать демон syslogd. HP OV Operations может выявить это, перезапустить демон и зарегистрировать данное событие в журнале. Иногда процесс ovw отсоединяется от своего X-дисплея и зацикливается, потребляя время ЦП и ухудшая время ответа для других пользователей. HP OV Operations можно настроить на выявление отсоединенного зацикленного процесса,
HP OV Operations можно сконфигурировать для мониторинга размера журнальных файлов и для предупреждения пользователей о том, что они вышли за допустимые пределы. Можно производить мониторинг даже свободного пространства на важнейших дисковых томах. Используя агента HP OV Performance Agents, HP OV Operations может выявлять чрезмерную загрузку различных системных ресурсов. Поскольку в системах NNM требуется, чтобы схема, доступная в режиме записи, всегда была открыта, HP OV Operations может проверить, так ли это на самом деле.
Поскольку персонал IT в процессе решения задач NNM становится опытнее, можно развертывать в системе HP OV Operations все больше и больше функциональных возможностей для оптимизации выявления проблем, автоматизации устранения многих тривиальных неполадок, автоматизации посылки сообщений на e-mail или оповещение персонала, ответственного за решение критически важных задач и т.д. Но, конечно же, все это можно делать непосредственно в NNM в
В проекте больших систем NNM имеется слишком много работы для одного или двух человек, чтобы завершить деятельность в приемлемое время. Требуется огромный опыт во многих областях, а встретить это у одного человека – большая редкость.
Для выполнения больших проектов по развертыванию NNM необходимы базовые навыки в области сетевых технологий. Обязательным является знание концентраторов, повторителей, мостов, коммутаторов, переключателей маршрутизации, маршрутизатров и шлюзов приложений. Обязательно также понимание инфраструктуры DNS, X-Window, TCP/IP, маршрутизазации и LAN/WAN. В этом может помочь консультант по сетям.
Поскольку NNM работает под управлением операционной системы, нужны навыки в генерировании и конфигурировании ОС, создании инсталляционных скриптов, автоматизации процессов, поиске и устранении неисправностей, управлении учетными записями пользователей, управлении дисковыми томами, резервном копировании и восстановлении, а также конфигурировании сетевых подсистем. Этот сервис может обеспечить выделенный системный администратор.
Нужны также навыки инсталляции NNM, конфигурирования, настройки, сопровождения, обновления, обучения и руководства. Здесь ключевую роль играют консультанты.
Поскольку речь идет о большом проекте, требуются усилия по координации различных участников, отслеживанию этапов проекта, планированию совещаний, выделению критически важных частей плана проекта, распределению ресурсов и взаимодействию с управляющим комитетом. Следовательно, нужен менеджер проекта.
При наличии специальных требований, которым NNM не удовлетворяет, необходимо разрабатывать заказной код, имеющий отношение к работе с настроенными схемами, управлению конфигурационными файлами, подпрограммам отображения данных и скриптам сокращения объема базы данных SNMP. Это требует навыков написания скриптов на языках Perl, C/C++ и shell, а также умения использовать средства разработки NNM. С подобными задачами лучше всего справляются разработчики программного обеспечения.
Успешный проект приводит к достижению всех намеченных целей к запланированной дате, и наступает время объявить о победе. Это необходимо в целях признания успехов группы IT и ее соратников. Одним из способов признания являются подписанные IT-менеджерами и обрамленные в рамки официальные письма, в которых участникам выражается благодарность и подробно описываются их достижения. Возможно, каждому участнику следует вручить еще и подарочный сертификат. Наконец, в завершение мероприятия все приглашаются за праздничный стол.
При наличии полнофункционального развертывания NNM приходится решать задачу сопровождения. В некоторых или во всех системах NNM могут потребоваться вставка
Менее рутинным является цикл модернизации, проводимой ежегодно или два раза в год. Может наступить срок модернизации операционной системы, может появиться возможность модернизации продукта стороннего поставщика, позволяющей получить желаемые функции, или, еще лучше, возможность обязательной модернизации 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.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.