Компания 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 или полностью вывести ее из рабочего состояния. После этого нужно отключить диск зеркальной системы и перезапустить систему NNM, которая теперь будет работать без активного зеркалирования. Далее следует выполнить резервное копирование томов с неактивного зеркального диска, и когда это будет сделано, снова установить зеркальный режим, при котором текущее состояние активного диска автоматически переброшено на тот диск, который только что был скопирован. Поскольку память на жестких дисках очень недорога, некоторые системные администраторы создают тройные зеркала для дополнительной надежности. В этом случае, когда с одного из дисков производится резервное копирование, система NNM работает на зеркальной паре. Общепринятым термином для дисковой подсистемы с чередованием (striping) дисков является RAID 0, а для подсистемы с зеркалированием – RAID 1; комбинированный вариант называется RAID 1+0.

Заметим, что в NNM обеспечивается утилита резервного копирования ovbackup.ovpl, которая автоматизирует правильную синхронизацию всех баз данных. Она создает моментальный снимок базы данных в буферной области и предназначается для вызовов из процесса резервного копирования операционной системы. Если пользоваться этим средством, не придется заботиться о расположении операционной базы данных, как описано ниже.

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

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

Статические конфигурационные файлы и программное обеспечение всегда можно переустановить, а не восстанавливать с резервной копии. Например, регистрационные файлы (ARF) (хранящиеся под $OV_REGISTRATION ) не изменяются в оперативном режиме, если только пользователям не разрешается создавать незапланированные MIB-приложения. Конфигурационные файлы DNS (такие как /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

Продукт HP OV Operations – это платформа управления сетью и системой, построенная поверх выполняемых компонентов NNM. Базовый процессор автоматического раскрытия, база данных и пользовательский интерфейс – это те же самые элементы, что используются в NNM. Это делает HP OV Operations идеальным решением для управления большим числом (более 20) систем NNM, распределенных в сети предприятия.

В чистой среде HP можно использовать HP OV Operations совместно с дополнительно подключаемыми продуктами как полное решение системного администрирования. Для выполнения автоматического резервного копирования и интерактивных операций восстановления можно использовать продукт OmniBack. Для управления конфигурированием системного программного обеспечения пригоден продукт SoftWare Distributor. Для управления подсистемой печати – OpenSpool. Для мониторинга производительности системы – PerfView и HP OV Performance Agents. Для общего мониторинга системы можно применять настраиваемые агенты HP OV Operations (не следует путать их с агентами SNMP или HP OV Performance Agents). Программное обеспечение HP OV Operations должно работать на отдельной системе, контролируемой группой IT.

Время выполнения пилотного проекта идеально подходит для накопления начального опыта применения HP OV Operations для управления системами NNM. Время от времени один из демонов NNM может завершиться, или может перестать работать демон syslogd. HP OV Operations может выявить это, перезапустить демон и зарегистрировать данное событие в журнале. Иногда процесс ovw отсоединяется от своего X-дисплея и зацикливается, потребляя время ЦП и ухудшая время ответа для других пользователей. HP OV Operations можно настроить на выявление отсоединенного зацикленного процесса, посылку сигнала SIGHUP для его завершения и регистрацию этого события в журнале. HP OV Operations может следить за жизнеспособностью соединения между каждой накопительной станцией NNM и управляющей станцией и регистрировать в журнале событие, когда управляющая станция оказывается неспособной к взаимодействию.

HP OV Operations можно сконфигурировать для мониторинга размера журнальных файлов и для предупреждения пользователей о том, что они вышли за допустимые пределы. Можно производить мониторинг даже свободного пространства на важнейших дисковых томах. Используя агента HP OV Performance Agents, HP OV Operations может выявлять чрезмерную загрузку различных системных ресурсов. Поскольку в системах NNM требуется, чтобы схема, доступная в режиме записи, всегда была открыта, HP OV Operations может проверить, так ли это на самом деле.

Поскольку персонал IT в процессе решения задач NNM становится опытнее, можно развертывать в системе HP OV Operations все больше и больше функциональных возможностей для оптимизации выявления проблем, автоматизации устранения многих тривиальных неполадок, автоматизации посылки сообщений на e-mail или оповещение персонала, ответственного за решение критически важных задач и т.д. Но, конечно же, все это можно делать непосредственно в NNM в локальном режиме.

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