Тысяча мелочей

• Недокументированное открытие
• Головоломная схема

НЕДОКУМЕНТИРОВАННОЕ ОТКРЫТИЕ

Недавно, при переустановке сервера NetWare 3.12 на Pentium 100 МГц, мне потребовалось создать журнальный файл с информацией, выводимой на экран при запуске сервера. Обновление сопровождалось значительными изменениями в конфигурации; возникли проблемы с загрузкой некоторых NLM, но информация на экране сменялась так быстро, что прочитать ее и, тем самым, установить в чем же дело не удавалось.

Я бы так никогда и не смог ее прочитать, если бы не CONLOG.NLM. (Модуль создает ASCII-файл, в который заносится вся информация, появляющаяся на экране во время запуска сервера. Файл сохраняется в каталог SYS.ETC.)

Я битый час просматривал в Internet все упоминания о "журнальных файлах" и "запуске системы" и в конце концов нашел упоминание CONLOG в 27-ом файле в списке из 100. Модуль CONLOG не задокументирован ни в руководстве администратора, ни в справочнике по утилитам NetWare 3.12. Не упоминается о нем и в интерактивной справочной системе. Но как бы то ни было, модуль помог решить проблему (она оказалась следствием нескольких опечаток), и я немедленно вставил его в AUTOEXEC.NCF всех остальных серверов в системе - на всякий случай.

Комментарий редактора: Novell содержит CONLOG.NLM в NetWare 3.12 и выше, но это не отражено в документации. Однако командная строка с вызовом этой утилиты автоматически помещается в файл AUTOEXEC.NCF в процессе установки сервера NetWare 4.1. Версия CONLOG на сервере NetWare 4.1 отличается от той, что имеется в NetWare 3.12: версия для 4.1 допускает несколько параметров командной строки, в то время как версия для 3.12 игнорирует любые параметры. Версия для 4.1 имеет следующие опции:

FILE=<имя журнального файла>

Данный параметр позволяет задать имя журнального файла. По умолчанию вывод заносится в SYS:ETCCONSOLE.LOG.

MAXIMUM=<размер файла в килобайтах>

Данная опция позволяет ограничить размер создаваемого CONLOG журнального файла.

SAVE=<имя резервной копии>

Данная опция позволяет создать резервную копию предыдущей версии журнального файла до его перезаписи.

ENTIRE=yes

Данная опция позволяет запротоколировать информацию, появившуюся на экране до вызова CONLOG (при ее отсутствии будет регистрироваться только информация, появляющаяся на экране после вызова CONLOG). Используя NetWare 3.12, вы можете включить оператор UNLOAD CONLOG.NLM в конец файла AUTOEXEC.BAT для ограничения размера файла CONSOLE.LOG.

Модуль CONLOG.NLM используется даже на сервере NetWare 3.11. Просто загрузите файл из NetWire на CompuServe.

---

ГОЛОВОЛОМНАЯ СХЕМА

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

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

В качестве примера рассмотрим случай трех дисков (в головоломке число дисков обычно равно шести или семи - см. Рис. 1). Пусть вертикальные линии представляют колышки, а горизонтальные - диски, причем все диски в начальный момент находятся на левом колышке.

Пометим маленький диск буквой "А", средний - "B" и большой - "C". В результате получаем следующую последовательность перемещения дисков - A B A C A B A. Помимо того, что данная последовательность представляет собой палиндром (т.е. читается одинаково слева направо и справо налево), она обладает некоторыми важными особенностями в применении к ротации магнитной ленты. Каждый набор лент помечается буквами A, B, C и т.д и используется в соответствующий день или неделю, в зависимости от того, как часто вы хотите менять ленту.

Само собою, в вышеупомянутой схеме ротации используется только три ленты. Такая схема не обеспечивает достаточной сохранностиданных, как схемы с большим числом лент. К счастью, добавление еще нескольких лент не сопряжено с какими-либо затруднениями. Например, последовательность с четырьмя лентами получаете следующим образом: последовательность с тремя лентами, четвертая лента и затем снова последовательность с тремя лентами. Таким образом, последовательность с четырьмя лентами выглядит следующим образом: A B A C A B A D A B A C A B A. Аналогично выглядит последовательность с пятью лентами - A B A C A B A D A B A C A B А E A B A C A B A D A B A C A B A. Таблица 1 демонстрирует изменение последовательности ротации лент при добавлении очередной ленты.

Продолжить схему ротации после достижения конца какой-либо последовательности можно, взяв ленту с наибольшим номером (в данном примере, буквой латинского алфавита) и затем повторив исходную последовательность. Например, в случае трех лент непрерывная последовательность будет иметь вид A B A C A B A C A B A C A B A...

Лента A будет использоваться через раз, лента B - через три смены на четвертую. В случае трех лент лента C используется через три смены на четвертую, т.е. с той же частотой, что и лента B. При добавлении одной или нескольких лент лента C будет использоваться через семь смен на восьмую. Число смен между использованием каждой последующей ленты растет экспотенциально как степень двойки, т.е. лента D будет использоваться через пятнадцать смен на шестнадцатую, лента E - через тридцать одну смену на тридцать вторую и т.д.

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

При увеличении числа лент в последовательности вы сможете иметь более старые копии. При девяти лентах в последовательности самая старая копия будет сделана 150 дней назад, а средний возраст копий составит 35 дней.

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

Давайте сравним "Ханойскую башню" с двумя другими схемами ротации: дед-отец-сын (GFS) и той, что Novell называет схемой ротации с 10 лентами.

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

Полная реализация схемы GFS потребует не менее 20 лент (четыре ежедневные, четыре еженедельные и двенадцать месячных плюс одна годовая лента), поэтому у вас уйдет больше лент, чем в схеме "Ханойская башня" с тем же временным охватом. Однако нумерация в этом случае интуитивно более понятна, а посему, если потребуется, найти ленту гораздо проще (без обращения к схеме).

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

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

Найти самую старую ленту при схеме "Ханойскоя башня" сложнее, чем при схеме GFS - здесь без графика ротации не обойтись. "Ханойская башня" годится для ситуаций, когда необходимо иметь разновременные архивы. Если программное обеспечение резервного копирования имеет достаточный интеллект для сопровождения информации о каждой версии каждого файла на магнитной ленте (и способ проверки необходимого числа копий версий конкретного файла на ленте), оно может использовать схему "Ханойская башня" для сопровождения резервных копий в широком диапазоне дат.

Схема дед-отец-сын хорошо работает, если программное обеспечение тесно увязано с календарными датами. В частности, в случае учетных файлов предпочтительнее иметь еженедельные, ежемесячные и ежегодные архивы. Хотя сама по себе схема GFS обладает определенной гибкостью в отношении последовательности ротации (никто не обязан планировать резервное копирование исключительно по дням и неделям), программное обеспечение резервного копирования производит планирование, как правило, в соответствии с календарем. При обеих схемах ротации ленты с наименьшими номерами (буквами) используются чересчур часто (ленты A и B в схеме "Ханойская башня" и ежедневные ленты в схеме GFS).

Предложенная Novell схема последовательности с 10 лентами дает возможность более равномерно распределить использование ленты. Имея сходные с GFS характеристики в отношении среднего возраста копий и числа недавних копий, этот метод представляет собой модифицированную схему ротации дед-отец-сын с сохранением ежедневных и еженедельных резервирований. Различие состоит в том, что после ряда недельных копирований лента используется для ежедневных копирований, как показано в Таблице 2.

Применять именно десять лент необязательно. Данный метод позволяет иметь более старые копии, нежели GFS (при одном и том же числе лент), однако не настолько старые, как в схеме "Ханойская башня".

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