Чрезвычайный план

Большинство планов мероприятий по решению проблемы 2000 года по сути своей одинаковы. Хотя они могут отличаться порядком предпринимаемых мер, общая стратегия предусматривает пять этапов: инвентаризацию, оценку, исправление, тестирование/анализ и чрезвычайный план на случай непредвиденных обстоятельств.

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

Специализированный сервер Web Министерства обороны США - прекрасный источник информации для подготовки плана решения проблемы 2000 года (http://www.dtic.mil/c3i/y2k/title.html). А кроме того, там любой интересующийся может найти полезное руководство по разработке чрезвычайного плана. На узле Министерства обороны говорится, что чрезвычайный план необходим для того, чтобы "сократить число и сложность решений, которые должны быть приняты в момент, когда любая ошибка может иметь самые серьезные последствия".

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

В то же время, несмотря на все заботы, связанные с решением проблемы 2000 года, вы не должны забывать о том, что менее вычурная (и непредусмотренная) авария может серьезно повредить вашим сетевым и информационным системам. Это стало для меня еще более очевидным в декабре 1998 года, когда здание редакции Network Magazine осталось без электроэнергии, поскольку свет был отключен как в самом Сан-Франциско, так и в его окрестностях.

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

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

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

Приводимое ниже описание взято с узла Web Министерства обороны. Оно определяет, какие из систем должны быть упомянуты в чрезвычайном плане. Наличие такого плана считается "обязательным" для всех систем, имеющих приоритет 1, "рекомендуемым" для систем приоритета 2 и "желательным" для систем приоритета 3.

Приоритет 1

  • Все критически важные системы.
  • Все системы, в которых к марту 1999 г. не решена проблема 2000 года.
  • Любая система, решение проблемы 2000 года в которой отстает от планируемых сроков на два и больше месяцев.

Приоритет 2

  • Системы с несколькими интерфейсами.
  • Системы, где необходимо исправить более 10% исходных текстов.
  • Системы или встроенные устройства, которые нельзя протестировать.
  • Любая система, влияющая на безопасность и здоровье персонала.
  • Системы, от которых получают данные критически важные системы.

Приоритет 3

  • Системы, ошибки в которых могут привести к незначительным сбоям.

Модернизация NDS

Комментарии редактора. Компания Novell выпустила обновления для NDS for NetWare 4.1x и опубликовала руководство по использованию серверов NetWare 5 в смешанном дереве NetWare 5 и NetWare 4.10/4.11. Обновленные версии - DS 5.15 и DS 6.00 - можно загрузить с узла технической поддержки компании Novell (http://support.novell.com). Ниже мы приводим комментарии специалистов Novell по использованию новых версий.

Серверы NetWare 5 вносят в схему NDS усовершенствования, с которыми предыдущие версии NDS for NetWare 4.1x несовместимы. Данная проблема решается посредством модернизации 4.x до последней версии NDS перед тем, как установить NetWare 5 в сети. Версия NDS 5.99a решает этот вопрос для большинства пользователей, она имеется на узле Web компании Novell с июня 1998 года.

Однако если новая точка отсчета объявлена во время планового выполнения функции Reset Schema, то это может привести к нарушению целостности схемы. (Замечание. Эта проблема может возникнуть и в "чистой" среде NetWare 4.x). Для решения этого вопроса Novell рекомендует применить DS 5.15 и DS 6.00 ко всем серверам версий 4.10 и 4.11, соответственно. Перед включением сервера 5.0 в существующее дерево 4.10/4.11 администратору следует проверить три момента.

  1. Все серверы NetWare 4.10 имеют DS 5.15 или выше (DS410N.EXE можно загрузить с узла http://support.novell.com).
  2. Все серверы NetWare 4.11 имеют DS 6.0 или выше (IWSP6.EXE).
  3. Все серверы NetWare 4.10/4.11 должны иметь DSRepair 4.59 или выше (они поставляются вместе с вышеупомянутыми файлами).

Замечание. Если дерево NDS изначально было определено с помощью NetWare 4.0 или 4.01, вы должны выполнить команду Repair local DS database, выбрав в меню опцию Advanced с DSRepair 4.59 или выше на серверах NetWare 4.1x, содержащих Master или R/W реплики [Root].

DSRepair исправляет определения схемы, которые могут иметь неверные отметки о времени, если дерево ведет свое начало от сервера NetWare 4.0 или NetWare 4.01. С установкой новых версий DS это может вызвать искажение атрибута Backlink.

Если ваше дерево создавалось изначально не на сервере NetWare 4.0 или NetWare 4.01, то запускать эту команду нет необходимости. Если вы не знаете, на каком сервере создавалось дерево, то мы рекомендуем запустить DSRepair на Master или R/W репликах [Root].

Серверы NetWare 5.0 вводят новые расширения схемы и правила включения в дерево, которые предыдущие версии DS для серверов 4.1x не понимают. Чтобы решить эту проблему, NDS 4.10 (5.15), NDS 4.11 (6.00) и DSRepair 4.59 вносят три основных изменения.

Во-первых, из-за проблем с синхронизацией схемы большинство, если не все, удаления в схеме будут некорректно синхронизироваться с серверами NetWare 4.10/4.11 без реплик. Во-вторых, если объект, на который ссылается сервер NetWare 5.0, размещается на сервере NetWare 4.10/4.11, где не работает DS 5.15/6.00, то он будет создан неверно. В-третьих, сервер NetWare 4.10/4.11 (до DS 5.15/6.00) некорректно передает ту же новую схему на другие серверы NetWare 4.10/4.11.

Несмотря на то что эти вопросы возникают редко, при включении NetWare 5 в дерево NetWare 4.10/4.11 пользователям рекомендуется модернизировать все серверы NetWare 4.10 до DS 5.15, а все серверы NetWare 4.11 - до DS 6.00. Эти меры гарантируют, что вопросы, описанные выше, не возникнут. Если это невозможно, то выполните хотя бы следующие минимальные действия для модернизации выбранных серверов NetWare 4.10/4.11 до DS 5.15/6.00.

  1. Для решения вопроса об удалениях из схемы любой сервер без реплик должен быть модернизирован до DS 5.15/6.00.

    Замечание. Любые серверы, в какой-то момент не содержащие реплик, а затем получившие реплику, могут иметь несогласованную схему, если удаления были произведены прежде, чем была добавлена реплика. На этих серверах также необходимо установить DS 5.15/6.00.
  2. Любой сервер, на консоли которого появляется сообщение об ошибке NLS [Novell Licensing Services], необходимо модернизировать до DS 5.15/6.00.

    Novell Licensing Services (NLS): An older NLS schema extension has been detected. If you have not converted your old licensing data, you may do so by running SETUPNLS.NLM.

    (Novell Licensing Services (NLS): Обнаружено устаревшее расширение схемы NLS. Если вы не преобразовали свои старые лицензионные данные, то можете сделать это, запустив SETUPNLS.NLM.)
  3. Любой сервер в том же кольце реплик, что и сервер NetWare 5, должен быть модернизирован до DS 5.15/6.00. Данный шаг гарантирует, что унаследованные списки контроля доступа (Access Control Lists, ACL) будут синхронизированы между собой. Это необходимо сделать вне зависимости от использования наследуемых свойств ACL.
  4. Любой сервер NetWare 4.10/4.11, где объект, на который ссылается сервер NetWare 5, будет восстановлен, следует модернизировать до DS 5.15/6.00. Это позволяет решить вопрос о восстановлении ссылок на объекты на сервере NetWare 5.

Относящиеся к NetWare 5 исправления в DSRepair 4.59 решают две проблемы. Основное изменение в DSRepair.NLM 4.59, касающееся NetWare 5, - это добавление новой функции под названием Reset Schema. Данная функция будет возвращать в исходное состояние схему на неглавных серверах [root]. Она работает при использовании версии DS.NLM 5.15/6.00 и выше. Изменение было внесено с целью удаления всех объектов схемы, если по каким-либо причинам они остались неудаленными с серверами без реплик.

Другая проблема связана с тем, что при запуске предшествующих версий DSRepair for NetWare 4.10/4.11 они сообщают, что серверы NetWare 5 не являются серверами NDS. DSRepair 4.59 передает корректную информацию.

Традиционный способ проверить версию DS.NLM всех серверов - использовать DSDIAG.NLM.

DSDIAG.NLM можно найти в Support Connection, предлагаемом Novell для серверов 4.1x. (DSDIAG.NLM выпускается с NetWare 5.0.)

Источник: Novell Document 2943193, ноябрь 1998 г.

УВАЖАЕМЫЕ ЧИТАТЕЛИ!

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

Присылайте ваши отклики по электронной почте: lan@lanmag.ru, или по факсу: (095) 253-9204.