Практические вопросы применения программы Portlock Storage Manager
24-06-2005 от Администратор сайта
… и сильно смахивал на сочинение в стиле
"Как я провел лето у дедушки в деревне".
Писать такие отчеты - одно удовольствие,
читать их- сущее наказание…
А&Б Стругацкие. "Жук в муравейнике"
ИНТРОДУКЦИЯ
Настоящая статья посвящена практическим вопросам работы с программой Portlock Storage Manager (PSM) производства фирмы Portlock Software, являющейся составной частью пакета Portlock Storage Suite. Это набор эффективных средств для обслуживания серверов Novell NetWare. С помощью программ, входящих в состав указанного пакета, легко выполнить предварительное тестирование дисковой подсистемы сервера, произвести дефрагментацию, выполнить purge тома, создать или удалить объекты дисковой структуры, восстановить удаленные объекты дисковой структуры и т.д. и т.п.
Но особенно хороша программа PSM для организации процесса миграции серверов и для создания оперативной копии тома SYS:
В статье сделан упор именно на эти возможности программы. В практическом плане применялись версии PSM 3.29 и 3.33. Существенных и бросающихся в глаза различий между этими версиями я не увидел.
Я описываю свой опыт и основываюсь на своем понимании проблем, поэтому совершенно не исключаю, что придирчивый читатель, привыкший оперировать официальными пресс-релизами или периодикой Novell, может закончить "читать статью с тем же уровнем знаний, с которым начинал" ©, ибо для него достаточно "просто привести списком утилиты … и все, коротко и ясно". ©
Ну что же, эта категория читателей может пропустить все нижеследующее и предаться занятию, приятному их душе - чтению Novell AppNotes в оригинале. Что касается остальных моих коллег, то я буду горд и счастлив, если кому-то мой опыт покажется интересным, поможет освоить программу и избежать ошибок, а главное - убережет от потери информации, сохранит время, нервы, репутацию админа.
Все описанные ниже манипуляции проделывались мною неоднократно как на стенде, так и на реально работающих серверах:
1. ML350, 2.4GHz, 4GB, RAID-ADG on 5304(256MB)+6HDD(36,15000), lan Q57(100), NW5.1+SP6, (SPEED ~ =196000)
2. ML370, 3.0GHz, 4GB, RAID-ADG on 5304(256MB)+6HDD(72,10000), lan Q57(1000), NW5.1+SP6, (SPEED ~ = 262000)
3. P4 , ASUS, 1GB, IDE-40GB, lan INTEL100b, DOS6.22 , IP-client-16 or IP-Client32 (как DOS-хост)
Серверы и рабочая станция объединялись коммутатором 3COM SS 3300TM, сервер-приемник подключен к гигабитному порту. Все установки коммутатора оставлены по умолчанию.
МИГРАЦИЯ
В связи с тем, что программа позволяет обрабатывать различные категории дисковой структуры NW-серверов:, а именно: тома, диски, разделы, секторы, то во избежании путаницы в настоящем документе под термином МИГРАЦИЯ понимается последовательный перенос томов NW-сервера на "новое железо". Отсюда термины сервер-источник и сервер-приемник, или для краткости - источник и приемник. В этом же контексте том понимается как минимальная неделимая информационная единица процесса миграции, и в просторечии это будет: "перенести сервер по томам".
Процедура миграции достаточно подробно описана в документации на программу (в частности, см. прилагаемый файл Serv_Serv_Migration.pdf, поэтому я остановлюсь на нескольких практических моментах этого процесса.
Собственно миграция заключается в следующих шагах:
1. Подготовка аппаратной части приемника. Здесь рекомендуется следовать руководству на аппаратуру сервера, особенно на конфигурацию дисковой подсистемы.
2. Подготовка программной платформы приемника. Если по-простому - следует установить DOS. Рекомендуется Microsoft DOS версии 6.22 . Размер DOS-раздела рекомендую не менее 1 Гигабайта. (Собственно, для данной работы столько не требуется, но практика показала, что со временем пригодится.)
3. Установка программы PSM на источнике. Вопреки рекомендации уважаемой фирмы, устанавливать программу на платформу NW-сервера так, как это описано в руководстве, совершенно не обязательно. Достаточно создать каталог с произвольным именем и поместить в него необходимые файлы из комплекта поставки. Каталог включается в путь поиска сервера командой search add [том-каталог]. В минимальный набор модулей для работы на платформе Novell NetWare входят следующие:
STORMGR.NLM (или STORMGR.CLM),
PORTLOCK.NLM,
STORMGR.LIC.
Расширение CLM означает, что модуль является сжатым и самораспаковывающимся NLM-модулем.
4. Установка программы PSM на приемнике. В этом случае устанавливаются тоже не все, а только необходимые модули. Установка заключается в создании каталога и в копировании в него минимально необходимых модулей:
STORMGR.CLM 899,635 04-13-04 8:00a
STORMGRV.EXE 176,951 04-13-04 8:00a
STORMGR.LIC 1,024 07-28-04 11:40a
PORTLOCK.NLM 715,465 04-13-04 8:00a
TCPIPN.NLM 9,652 04-13-04 8:00a
Кроме этих, на приемнике должны быть и файлы, обеспечивающие работу DOS-клиента по протоколу TCP/IP.
5. Настройка сетевого клиента на приемнике. Программа работает только через IP-протокол, поэтому на стороне приемника придется организовать стек TCP/IP для DOS'а. В данном случае возможны два пути: использовать 16-ти или 32-х разрядный доступ. Оба варианта практически равны по сложности. Проблемы в случае использования 16-ти разрядного доступа могут возникнуть только при поиске того или иного модуля. В частности, стоило некоторого труда найти модули поддержки стека TCP/IP для 16-тиразрядного клиента и ODI-драйвер серверной карты для серверов HP/Compaq. Однако это вполне преодолимые проблемы. В частности, для многих карт существуют generic-драйверы для базового чипа, и нет необходимости применять фирменный драйвер под конкретную модель.
5.1. настройка 16-ти разрядного клиента Файл SM16.BAT запускает клиента. (Опытным путем было установлено, что запуск модуля STORMGRV.EXE вместо модуля STORMGR.EXE приводит к более устойчивой работе и к гарантированному запуску NLM-модулей.)
cls
@echo off
C:\nwclient\LSL.COM /C=c:\nwclient\netip.cfg > nul
echo Wait NIC......
C:\nwclient\q57.COM > nul
echo Wait TCP/IP.…..
C:\nwclient\TCPIP.EXE > nul
c:\ > nul
cd\ > nul
cd\ > nul
cd\ > nul
cd stormgr > nul
stormgrv > con
C:\nwclient\TCPIP.EXE u > nul
echo Wait NIC......
C:\nwclient\q57.COM u > nul
C:\nwclient\LSL.COM u > nul
c:
cd\
cd\
==================================================
Примечание:
В тексте статьи использованы реально работающие командные файлы, они отлажены и работают без замечаний, поэтому в строках везде прописаны параметры NUL. Коллега Влад Сокол считает, что если Вы хотите проследить логику работы командного файла, получать сообщения о загрузке и работе модулей или иметь возможность прервать выполнение командного файла, то рекомендуется иная конструкция командных файлов, а именно:
@echo on
cls
Echo Выполняем первую команду
[команда на запуск ЕХЕ1] | more
Pause
Echo Выполняем вторую команду
[команда на запуск ЕХЕ2] | more
Pause
Etc.
==================================================
Продолжим.
Файл CONFIG.SYS для случая 16ти разрядного клиента такой:
rem
rem for STORMENAGER !!!
rem
SHELL=C:\COMMAND.COM C:\ /E:1024 /P
dos=high,umb
LASTDRIVE=Z
BREAK=ON
rem
rem DEVICE=C:\root\HIMEM.SYS /testmem:off
rem OR
rem DEVICE=C:\root\HIMEM_wi.SYS /testmem:off
rem
files=30
buffers=35
Драйвер himem я использовал тот, который из комплекта еще Windows 3.1 (он указан как himem_wi). Опытным путем установлено, что он работает более устойчиво. Вы можете использовать любой вариант, раскоментировав соответствующую строку.
Файл NETIP.CFG
Link driver q57
INT 7
SLOT 4
frame ethernet_II
#
Link Support
Buffers 20 1600
MemPool 4096
#
Protocol TCPIP
PATH TCP_CFG C:\nwclient\TCP
ip_address 172.16.1.13
ip_netmask 255.255.255.00
ip_router 172.16.1.1
Для развертывания протокола TCP/IP, в каталог NWCLIENT следует добавить модули поддержки стека TCP/IP. Взять их можно из пакета NetWare/IP (из отдельной поставки или из инсталляции версии NetWare 4.11),. Тем, кто не имеет доступа к указанным пакетам, можно обратиться на сайт фирмы PORTLOCK или взять модули отсюда.
5.2. настройка 32-х разрядного клиента
Файл SM32.BAT запускает клиента.
cls
@echo off > nul
C:\nwclient\CLNT32\NIOS.EXE > nul
LOAD C:\nwclient\CLNT32\NBIC32.NLM > nul
LOAD C:\nwclient\CLNT32\LSLC32.NLM > nul
LOAD C:\nwclient\CLNT32\CMSM.NLM > nul
LOAD C:\nwclient\CLNT32\ETHERTSM.NLM > nul
LOAD C:\nwclient\CLNT32\Q57.LAN FRAME=Ethernet_II > nul
LOAD C:\nwclient\CLNT32\TCPIP.NLM > nul
c:\ > nul
cd\ > nul
cd\ > nul
cd\ > nul
cd stormgr > nul
stormgrv > con
Файл CONFIG.SYS для этого случая примерно такой
rem
rem for STORMENAGER !!!
rem
SHELL=C:\COMMAND.COM C:\ /E:1024 /P
dos=high,umb
LASTDRIVE=Z
BREAK=ON
DEVICE=C:\root\HIMEM.SYS /testmem:off
DEVICE=c:\root\EMM386.EXE RAM NOEMS /Y=c:\root\EMM386.EXE
files=80
buffers=85
Файл взят "AS IS" из состава загрузочной дискеты, образ которой можно взять отсюда
Файл NET.CFG
Link Support
MAX BUFFER SIZE 24682
#
Protocol TCPIP
IF_CONFIGURATION static
PATH TCP_CFG C:\nwclient\clnt32\TCP
ip_address 172.16.1.13
ip_netmask 255.255.255.0
ip_router 172.16.1.1
#
NIOS
ALERT BEEP OFF
MEM POOL SIZE 4096
LOG FILE C:\NWCLIENT\clnt32\LOG.TXT
LOG FILE SIZE 524288
Совершенно очевидно, что у вас будут свои каталоги и свои IP-адреса.
6. Запуск программы на серверах хорошо описан в руководстве.
В качестве комментария можно добавить следующее: программа на
сопряженных машинах запускается в разных режимах - на одном хосте
устанавливается в режиме клиента, на другом - в режиме сервера.
С практической стороны не выявлено никаких различий в работе хостов в
зависимости от варианта запуска программы на них. Так что, выбор режима
хоста - как сервер или как клиент - остается за вами.
====================================
Примечание Влада Сокола:
Разница между хостом-сервером и хостом-клиентом в том, какая из машин инициирует соединение. Клиент не инициирует трафик, а ждет [обращения сервера]. В то время как сервер шлет во все стороны пакеты, ища "партнера".
====================================
7. Про уплотнение, (оно же - сжатие). Программа, запущенная на источнике, может выполнять уплотнение данных перед передачей. Трудно сказать, есть ли смысл в таком режиме при соединении серверов в локальной сети, скорее он предполагается для медленных каналов. Если вы все же выберете режим с уплотнением, вам предложат выбрать уровень уплотнения. Всего определено десять уровней: от первого до десятого - самого "плотного" и самого медленного. Понятие "медленно" для 2ГГ процессоров несколько условно, поэтому свои серверы я мигрировал на десятом уровне сжатия информации. Экспериментально выявлено, что том SYS: (версии NW5.1 + SP6) ординарного файлового сервера сжимается приблизительно в 3.5 раза .
8. Особенности процесса миграции. Из выявленных особенностей можно отметить следующие:
8.1. про лицензии. Вообще-то, программа лицензируется по
количеству одновременно активных хостов, однако в дебрях пиратского
Интернета можно прочитать, что одну и ту же единичную лицензию можно
применять на нескольких объединенных в сеть хостах. Странный ляп для
уважаемой фирмы: работаем на Novell и не в состоянии применить
их же методику проверки действительности лицензионного файла? Мда…
Может, сатирик Задорнов не ошибается? Впрочем, я работал как раз с
легальными лицензиями.
8.2. про обновления версий. Если время Update Expiration time
вашей копии еще не истекло, программа предложит провести обновление
путем самостоятельного соединения с родным сайтом и скачивания оттуда
новых модулей. Может, найдутся оригиналы, которые откроют прямой доступ
на сервер неизвестно кому и откуда (настроек на работу через proxy не
имеется), но лично я такую возможность даже не рассматривал. Тем более,
что новые версии доступны для скачивания в любое удобное вам время…
8.3. про затяжной старт. Дисковые подсистемы на моих
серверах если и не идентичны, то достаточно подобны, тем не менее,
время сканирования и распознавания дискового массива программой PSM на разных серверах серьезно различается: 3-5 секунд против 15-20 секунд. Возможно, это время зависит от емкости массива.
8.4. резкое увеличение коэффициента сжатия (до 26 : 1 !! )
в первый момент работы программы. По достижении ~10-15 Мегабайт
обработанной информации коэффициент начинает уменьшаться и к первой
сотне Мегабайт достигает указанного в пункте 7 значения. Предполагается, что это влияние установленного на серверах дискового контроллера с достаточно ёмким кэшем.
8.5. несовпадение показателей на передающем и принимающем серверах.
Вот это интересно: в один и тот же момент времени, при передаче/приеме
одной и той же информации выявлены расхождения в показателях сжатия и
скорости передачи для хостов, участвующих в процессе миграции.
Расхождения в показателях достаточно заметны, чтобы быть случайными.
Так, при передаче образа тома SYS: в режиме с максимальным сжатием (10й уровень), коэффициент сжатия на одном хосте отображался как 3.5 : 1, а на другом хосте в тот же момент времени и для той же информации - как 2.9 : 1.
Соответственно, различались и скорости передачи: ~600Kb/s против
~450Kb/s. Серверы относятся к одной линейке, оснащены одинаковыми
дисковыми контроллерами. Объяснить это несовпадение (а оно проявлялось
стабильно, не зависимо от режима клиент/сервер в котором работал хост)
я не берусь.
8.6. пересчет и перераспределение таблиц размещения файлов.
При миграции томов с изменением размера тома, программа, запущенная на
приемнике, начинает прием обычным образом, затем приостанавливает его и
переходит в режим пересчета. Такой пересчет может обратить на себя ваше
внимание, т.к. занимает достаточно много времени. Счетчик обработанных
(чего??) бежит довольно резво, но может и остановиться. Ничего не
предпринимайте, даже если вам показалось, что программа зависла: через
некоторое время пересчет заканчивается и передача информации
возобновляется.
8.7. интерактивность миграции. К сожалению, программа
работает в оконном режиме и задает несколько вопросов для каждого
мигрирующего тома, поэтому автоматизировать процесс миграции при
последовательной миграции нескольких томов в "пакетном режиме" не
получится: режим командной строки у этой программы несколько убогий.
====================================
Примечание:
При работе с программой PSM с платформы NW-сервера есть возможность "нажимать клавиши" программой stuffkey.nlm. Что касается платформы DOS, то и для нее имеется много всяких stuffkey.com (exe), так что "жать" клавиши программно можно и в DOS'е. Если очень хочется. Миграция - процесс не самый частый и писать сценарий на "птичьем" языке stuffkey для однократной процедуры - вряд ли разумно. ©
====================================
9. Завершение миграции. Если для миграции было выбрано несколько томов, то по окончании обработки одного тома программа перейдет к обработке следующего. По исчерпанию списка томов программа прекратит работу и покажет результат: список обработанных томов с указанием результата миграции.
10. Повторная миграции "вдогонку". Интересное наблюдение для хостов, работающих под DOS'ом: если вы проводили миграцию, как описано выше, и по завершении миграции нескольких томов решили повторить процесс (например, решили мигрировать еще один том, ранее пропущенный), то повторить процесс миграции без перезагрузки не получается: при входе в пункт настройки IP-протокола программа сообщает, что "сокет занят другим процессом". Приходится перезагружаться, благо в DOS'e это занимает пару минут.
СОЗДАНИЕ ОБРАЗА ТОМА
Как уже отмечено выше, программа предназначена для работы с большим числом объектов файловой/дисковой структуры как на логическом, так и на физическом уровнях. В руководстве оператору вы найдете описание различных операций: от входного тестирования дисковой подсистемы на качество носителей и скорость передачи информации до описания процедуры слияния сегментов или посекторного копирования. В общем - каждый админ найдет в программе что-то для себя.
Я же остановлюсь на "вечной" проблеме - оперативное восстановление работоспособности сервера.
Строго говоря, программа позволяет создавать копии (образы) практически любых по размеру томов, другое дело - а есть ли в этом смысл? Исходя из своего опыта, считаю, что выполнять копирование рабочих (в широком смысле слова) наборов данных с помощью программы PSM не целесообразно в силу чисто технологических причин.
Во-первых, это достаточно долго. Тридцать Гигабайт информации на скоростном процессоре при максимальном сжатии обрабатывалось и передавалось по сети порядка трех часов. В моих условиях это ровно в три раза дольше, чем копирование этого тома на магнитную ленту. Напомню, что программа работает только с размонтированными томами. И кто же вам столько времени даст?
А во-вторых, достаточно много. Ну создадите вы образ своего рабочего тома или тома БД. И куда вы поместите бинарный файл размером в полтора-два-три, а то и в пять десятков Гигабайт? Спрячете в ладошку? А что будете делать (я уже не спрашиваю - что будете говорить!!!) когда из-за искажения одного бита весь файл окажется "битым"? Так что для сохранения копий рабочих наборов эту методику применять не следует, IMHO… хотя, хозяин-барин…
Другое дело - оперативная копия тома SYS:. В этом программе просто нет равных.
Во-первых, работает она с двух платформ: на базе NW-сервера и под чистым DOS'ом.
Во-вторых, сжимает полученный образ на достаточно заметную величину.
В-третьих - и это главное - предоставляет администратору широкий выбор целевых платформ для хранения образа тома.
Файл образа тома можно:
- создать и оставить на любом из доступных томов данного сервера;
- создать и оставить на этом же сервере в DOS-разделе. Естественно, для этого вы должны соотносить свободное место на DOS-разделе
сервера и ожидаемый размер образа. Если по тем или иным причинам
системные тома ваших серверов имею значительные размеры, тогда этот
способ не для вас;
- создавать и записывать на подключенный к серверу SCSI-стример (если такой есть);
- создавать и записывать на подключенный к серверу рекордер - CD или DVD (если такие есть);
- создавать и передать на любой из доступных NW-серверов;
- наконец - создавать и передавать по IP-сети практически на любой тип хоста: от DOS-машины до FTP-сервера.
Совершенно очевидно, что справедливо и обратное утверждение: образ тома можно загрузить с…. смотри выше.
Далее я представляю свою методику, которая помогает мне достаточно успешно противостоять потере информации, и в частности - проблемам, связанным с разрушением тома SYS:
1. Предварительная подготовка
1.1. При создании DOS-раздела
под него отводится два Гигабайта. Далее раздел форматируем и размещаем
на полученном логическом диске программы, которые вы считаете
необходимыми для работы с DOS-разделом в дальнейшем. Вопрос о версии "базового ДОСа" под систему Novell NetWare обсуждался достаточно подробно, в том числе - на сайте proNOVELL. При всем уважении к мнению коллег, остаюсь в убеждении, что желательно пользоваться версией MS DOS 6.22.
1.2. На логическом диске C: создаем каталог для размещения необходимых модулей PSM.
Для себя я отказался от передачи образа за пределы машины в момент его
создания, но если вы планируете передавать образ на удаленный хост в
момент его создания, то придется позаботиться о настройке стека TCP/IP и о размещении соответствующих модулей.
1.3. Устанавливается операционная система NetWare, настраивается сервер.
Мои условия позволяют выкроить час-полтора в неделю на проведение профилактических работ. Одной из главных составляющих и является создание образа тома SYS:.
2. В назначенное время начинается эта самая профилактика:
2.1. на серверах выполняется проверка состояния Дерева (load dsrepair -> Unattended full repair). В случае выявления ошибок, следует добиться их исправления. Копировать неполноценный том - сомнительное мероприятие;
2.2. серверы выгружаются (down);
2.3. на серверах запускается программа stormgrv.exe. При успешном запуске программы организуется run-time среда для дальнейшего запуска модулей;
2.4. загружается модуль stormgr.clm;
2.5. выполняется очистка ("purge") тома SYS: . Операция выполняется через пункт "Volumes" главного меню программы. Будьте внимательны: в пункте "Image"
так же упоминается возможность выполнить "purge", но для всех томов
сразу, а это не всегда желательно и часто - очень долго. (Можно
выполнять "purge" тома с рабочей станции перед началом всей процедуры…
как говорится - на любителя)
2.6. выполняется создание образа тома. Операция выполняется через пункт "Image" главного меню. Выбирается максимальный уровень сжатия образа и метод "создание образа в файл". Файл образа сохраняется на DOS-разделе во временном каталоге C:\TEMP\[имя_сервера].IMG. Вообще говоря, решение создавать образ тома и первоначально оставлять его на DOS-разделе сервера продиктовано желанием избежать лишней перезагрузки и манипулирования с файлом config.sys. Дело в том, что если надо получить работающий стек TCP/IP для DOS'а, то придется использовать настройку DOS'а с менеджерами и драйверами памяти, а при работе сервера необходим "чистый" config.sys. Вот и вся причина…
2.7. на указанных серверах процесс создания образа тома SYS:
занимает около 30 минут со всеми перезагрузками, есть время выполнить
те или иные манипуляции с остановленными серверами. Время работы
программы в ваших конкретный условиях определяется размером ваших томов
и производительностью процессоров;
2.8. профилактика заканчивается - загружаем серверы и проверяем, все ли в порядке. Грузим на каждом сервере модуль cc.nlm и с его помощью копируем образы тома SYS: со всех DOS-разделов серверов на рабочие тома серверов, откуда забираем их на машину администратора для записи на CD-ROM, затем выгружаем модули cc.nlm;
====================================
Примечание:
Коллега Влад предлагает передавать информацию с DOS-раздела на рабочую станцию с использованием механизма NSS: использовать команду nss dosfat
и, получив доступ к DOS-разделу, "перегнать" информацию сразу на
рабочее место админа. По окончанию этого процесса следует выгрузить
модули NSS по команде nss exit. Решение
оригинальное, однако следует помнить о двух моментах. Во-первых, если
вы работаете с TFS, то модули NSS, "висящие" в памяти сервера, вам
совсем ни к чему. А выгрузить все NSS-модули не получится, т.к. они
"цепляются" за модуль libc.nlm и выгрузке не подлежат.
Второе замечание принадлежит коллеге Сергею: с модулем dosfat
не всё так просто - если вам не хочется получить разрушенный DOS-раздел
(а это может произойти в случае abend'a сервера), необходимо проделать
предварительные манипуляции на консоли сервера: изменить значение
set-переменной auto restart after abend с "1" на "0" командой с консоли
сервера
set auto restart after abend = 0.
Если этого не сделать, система предупредит о риске и попросит вас подтвердить работу модуля dosfat.
Естественно, что по окончании манипуляций с передачей файла образа
следует восстановить значение этой переменной путем выдачи на консоли
сервера команды
set auto restart after abend = 1.
====================================
2.9. если у вас нет пользователя типа "черный_ход" и нет инструментов
для восстановления паролей администратора, то следует позаботиться о
маленьком текстовом файле с паролем администратора на данный момент.
Этот файл следует записать на носитель рядом с образом тома. Потом -
как найдете…
Все, копия тома создана и готова к использованию для восстановления
работоспособности сервера. В рамках данной статьи сознательно не
рассматривается вопросы восстановления рабочих томов. Предполагается,
что у каждого админа есть свои подходы к проблеме сохранения и
оперативного восстановления рабочих данных и соответствующая
"экипировка": хорошие стример и программа копирования, достаточный
оборот магнитных лент, утвержденный регламент копирования,
соответствующий опыт и т.д. И воспользоваться всем этим при рабочем
томе SYS: не представит труда.
ВОССТАНОВЛЕНИЕ ТОМА ИЗ ОБРАЗА
Что касается процедуры восстановления, то она фактически зеркальна относительно описанной и различается в деталях в зависимости от степени поражения сервера.
Если сервер разрушен на физическом уровне и "все надо начинать с начала", то восстанавливаем дисковую подсистему, формируем RAID. Далее на новом массиве создаем DOS-раздел, форматируем его и восстанавливаем содержимое логического диска С: с отдельного CD-ROMа (забыл упомянуть - есть у меня такой с содержимым DOS'а для каждого сервера. На нем хранится полный и отлаженный набор утилит, сетевые клиенты, bat-файлы и конфигурационные файлы. Очень рекомендую иметь). Затем берем последний записанный CD-ROM с образом данного сервера и с него восстанавливаем том SYS:.
А если произошло обычное логическое разрушение Дерева или файловой системы тома SYS:, то для восстановления тома SYS: его образ берем с рабочего каталога на DOS-разделе.
Далее все просто:
1. загружаем сервер под DOS. Файлы config.sys и autoexec.bat берем в зависимости от источника образа: при работе с удаленным источником образа или с CD-приводом используем файлы с менеджерами памяти, а при восстановлении с DOS-раздела - используем config.sys и autoexec.bat те же, что и для запуска SERVER.EXE;
2. запускаем программу stormgrv.exe;
3. запускаем модуль stormgr.clm;
4. восстанавливаем том:
4.1. если "с нуля", то вначале посредством пункта "Partition" создаем раздел и затем на этот раздел посредством пункта "Restore" восстанавливаем том SYS:;
4.2. если простое восстановление, то посредством пункта "Restore" восстанавливаем том SYS: с перекрытием существующего;
5. перезагружаем сервер - том SYS: на месте.
Описанный процесс восстановления в чисто техническом аспекте проходит без каких либо осложнений. Другое дело - целостность системы как таковой. Здесь возможны различные осложнения и с одним из них мне пришлось столкнуться: в системе работают два сервера. Один - с Мастер Репликой - служит для размещения домашних каталогов. Второй сервер несет реплику RW, а также выполняет роль сервера NDPS, LDAP и DNS/DHCP. Именно с DHCP-сервером и произошло осложнение после восстановления, проведенного по описанной методике. Как можно догадаться, восстановленный по состоянию на "10 дней ранее" DHCP-сервер сразу пришел в конфликт с уже розданными адресами: началась "ругань" сервера на дублирование IP-адресов, затем нарушилась синхронизация реплик и закончилось всё массовым появлением obituaries…. Реплику на этом сервере пришлось удалить и создать заново. В данном случае - типичная "криворукость", кстати - следовало помнить о возможной коллизии в IP-адресации и выполнить "сброс" сервера DHCP, вплоть до его пересоздания или же выполнять восстановление тома SYS: по окончании рабочего времени, когда рабочие машины отключены.
ЗАКЛЮЧЕНИЕ
Изложенной методикой я пользуюсь уже год. Копирование томов SYS: выполняется по профилактикам и по внесению существенных изменений в систему: установка SP или отдельных модулей, манипуляции с Деревом, включение новой службы и т.д.
За это время выполнено достаточно много экспериментов на стенде,
создано и записано на носители более десятка образов, проведено два
реальных "переезда" рабочих серверов и одно реальное "аварийное"
восстановление тома SYS:.
Не буду хвалить программу лишний раз, скажу только, что в настоящее
время просто не представляю своей работы как администратора Novell NetWare без пакета Portlock Storage Suite.
Цену, которая определена фирмой-производителем: (Portlock Storage Suite - 5 , а отдельно Portlock Storage Manager - 5) , программа полностью оправдывает.
При запуске программа высвечивает через весь экран данные из ключевого файла. В моём случае отображаются атрибуты организации, в которой я и.ч. служить. Организация эта достаточно известна, чтобы рекламировать ее вне собственных стен путем распространения ключевого файла, так что - не обессудьте...
ПРОЧЕСТЬ
о еще одном интересном опыте применения программы PSP можно в статье Сергея Дуброва "Практический опыт переноса Netware сервера на новые диски"
БЛАГОДАРЮ КОЛЛЕГ
Владислава Сокола и Сергея Дуброва за участие в работе над статьей и за сделанные ими важные замечания, добавления и исправления.
Музалёв Николай
17 июня 2005г