Корпорация Symantec (Купертино, шт. Калифорния) в конце октября выпустила новую версию пакета резервного копирования Norton Enterprise Backup (NEB) 1.5. Несмотря на то что в него добавлена поддержка Windows 95 и Windows NT, в целом пакет не отвечает сегодняшним требованиям в этой быстро развивающейся области ПО.
Новый продукт мало пригоден для использования в сетях предприятий из-за присущих ему многочисленных недостатков. Это слабые возможности предупреждения, отсутствие поддержки SNMP, наличие последовательного доступа только к накопителям со сменными магнитными лентами, а также неполный инструментарий генерации отчетов. Кроме того, пакету явно не хватает поддержки службы каталогов NetWare (NDS). Вследствие этого NEB 1.5 может быть полезным лишь менеджерам информационных систем, созданных исключительно на базе серверов NetWare 3.x.
Для тех же, кто стремится интегрировать создание резервных копий в ЛВС NetWare с хост-компьютерами на базе Unix-систем или мэйнфреймов, лучшим выбором может стать AdStar Distributed Storage Manager корпорации IBM или Networker фирмы Legato Systems.
В Тестовом центре PC Week Labs была испытана многопользовательская версия NEB (цена $1395). Существует также версия этого пакета для одного сервера, цена которой составляет $795.
Когда Symantec впервые представила NEB, примененное в пакете централизованное администрирование было хоть и не оригинальным, но все же новшеством. В наших тестах функции автоматизированного восстановления после сбоев реализовывались легко и работали надежно.
Важно, что разработчикам конкурирующих с этим ПО пакетов Storage Express корпорации Intel и Backup Exec for NetWare фирмы Arcada Software удалось избежать единственной слабости NEB - его центрального репозитория данных.
Поскольку NEB имеет централизованную архитектуру, необходимые для работы системы базы данных хранятся только на главном сервере. С него же осуществляются процессы управления. NEB использует эти БД и процессы для поддержки всех доменов сети, а также одного или нескольких входящих в них серверов-накопителей на магнитной ленте (НМЛ). Таким образом, в случае выхода из строя главного сервера все работающие под его управлением НМЛ-серверы не смогут осуществлять резервное копирование.
Результаты тестирования
Установка NEB 1.5 в нашей комбинированной среде NetWare представляла собой долгий многоступенчатый процесс. Нам пришлось создать для всех серверов NetWare 4.1 общий контекст связей (Bindery), а затем добавить в него учет связей (Bindery account) для администратора NEB. При этом для определения администратора-пользователя мы использовали SYSCON из NetWare, а затем переключились на NWADMIN с целью обеспечения необходимого уровня безопасности для каждого сервера в ведении NEB.
Дальнейшая инсталляция прошла без осложнений. NEB автоматически заменил такие устаревшие модули, как постоянно обновляемый CLIB.NLM, и установил на наших серверах файл NEBLOAD.NCF.
В ходе установки был создан файл INCLUDE, содержащий сценарий обращения к системе log-in для автоматической настройки клиентов. В NetWare 4.x и NetWare 3.x log-in-сценарии хранятся по-разному, в силу чего ценность этого файла в нашей тестовой среде была ограниченной. Однако нам удалось добиться частичного успеха после того, как мы попытались включить команды из файла INCLUDE в исполняемый batch-файл.
NEB поставляется с модернизированным клиентским ПО TSA (Target Service Agent - агент службы назначения) под DOS, Windows 3.x, Windows 95 и Windows NT. Для работы с серверами и другими клиентами (такими, как Macintosh) пакет NEB использует TSA фирмы Novell.
Использование входящих в NEB интерфейсов DOS и Windows делает назначение заданий на выполнение очень простым. В дерево выбора были включены только те системы, на доступ к которым наши пользователи имели право, при этом предлагалось большое разнообразие фильтров выбора файлов. Кроме того, мы создали группы резервного копирования и назначили для них диспетчера. Администраторы могут также назначать операторов для резервного копирования на НМЛ и ограничивать права пользователей на выполнение только резервирования или только восстановления информации.
Многочисленные опции составления графика резервного копирования делают NEB одним из самых гибких пакетов среди аналогичных продуктов. Он предлагает также богатые возможности выбора методов восстановления информации и новые средства верификации при записи на НМЛ.
При первой попытке провести резервное копирование с локального НЖМД рабочей станции мы были неприятно удивлены, не увидев в дереве выбора дисковода C:. Позже выяснилось, что зарегистрированные при вхождении в систему имена пользователя и ПК должны соответствовать друг другу, в противном случае NEB запрещает доступ к локальному диску.
Консоль администратора позволяет контролировать и изменять все параметры работы NEB
Чтобы выйти из такой ситуации, нам пришлось предоставить пользователям право доступа к их собственным ПК, к ПК других пользователей и серверам через консоль управления. Мы полагаем, что было бы лучше позволить администраторам присваивать имена аппаратным средствам одновременно с начальной установкой клиентского ПО, а затем согласовывать их с идентификаторами пользователей.
Другая проблема возникла, когда мы добавили новых пользователей к серверу NetWare. NEB не позволил им даже запустить процесс инсталляции, поскольку просмотр и обновление таблиц пользователей в Bindery осуществляется лишь один раз в сутки - в полночь.
Хотя мы смогли провести сканирование Bindery в ручном режиме из консоли управления, в рабочей сети это было бы весьма неудобно.
Главным недостатком NEB является его неспособность опознавать объекты службы NDS. Как заявили представители Symantec, он будет устранен в следующей версии.
Распределенное управление тоже имеет слабые стороны.
Очень сильной стороной пакета NEB 1.5 является то, что с НМЛ-серверами, входящими в состав домена, он обращается как с единым ресурсом, организованным в виде пулов. При резервном копировании администраторы могут назначить любую комбинацию (в том числе все) НМЛ-серверов для обслуживания активного задания. ПО поддерживает неограниченное количество НМЛ.
Кроме того, в NEB предусмотрена функция, позволяющая перемежать данные, поступающие от нескольких клиентов и серверов, что повышает производительность и сокращает время выполнения задания.
Однако у такого подхода имеется и негативная сторона. Все подчиненные НМЛ-серверы в домене полагаются на главный сервер при составлении и сохранении баз данных, используемых для работы с файлами. (Ожидается, что в следующей версии NEB будет применена более распределенная схема.)
Windows-консоль обеспечила нам хорошие возможности мониторинга всех показателей работы NEB в масштабе времени, близком к реальному. Однако в пакете нет никаких механизмов оповещения о неполадках, кроме встроенных служебных сообщений Novell. А для работы на уровне предприятия программе не обойтись без поддержки электронной почты и пейджинговой связи, усиленных SNMP.
Качество отчетов NEB с точки зрения глубины включенной в них информации мы оценили как среднее. Нам не удалось получить подробного перечня архивированных файлов. Последнее обескураживает, поскольку в данном ПО не предусмотрено автоматическое повторное планирование с пропущенными при резервном копировании файлами (например, с открытыми файлами БД).
Установка еще одного сервера в домене сети с NEB оказалась простой. Пакет сам скопировал все необходимые файлы, а затем создал файл NEBLOAD.NCF и уже упоминавшийся файл сценария INCLUDE.
Чрезвычайные ситуации
Основательно “погоняв” главный сервер домена, мы прибегли к крайнему средству и начисто стерли системный диск. Реставрация системы удивительно безболезненна. Переустановив файлы NetWare, мы с помощью аварийного диска NEB загрузили несколько модулей NetWare и “воскресили” былую инсталляцию.
В ходе выполнения этой процедуры программа создала временную структуру данных, а затем запросила последнюю ленту для восстановления после аварий. Мы создавали эти ленты регулярно в ходе запланированного резервного копирования. Но поскольку для этого используется отдельная лента, а не те же, что при резервировании, операция требует больше ручного вмешательства и усложняет процесс восстановления. Хотелось бы иметь возможность записи данных для восстановления на те же ленты, что и применяемые для резервного копирования.
Телефон корпорации Symantec: (800) 453-1193, представительства в Москве:
(095) 320-0733.
Уильям Ф. Кэтц
