Часть 1

Шон Дейли

К сбою готов!

Иллюстрация: Стив Адамс
А вы задумывались над тем, что будете делать, если однажды ваш сервер зависнет после перезагрузки системы? И, что не менее важно, сколько времени вам потребуется на решение возникшей проблемы? Большинство администраторов Windows NT при одной мысли о возможности увидеть голубой экран с кучей цифр и надписью STOP (известный как blue screen of death) бросает в холодный пот. Впрочем, и любая другая неполадка в работе сервера компании не может вызвать улыбку.

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

Типичные неприятности

Причин, по которым система Windows NT может остановиться при загрузке, много, но результатом их действия почти всегда является ужасающий «голубой экран смерти» (см. экран 1). После того как Windows NT останавливает систему, она выводит этот экран, чтобы предотвратить дальнейшее нарушение целостности данных.

ЭКРАН 1: Содержимое «голубого экрана смерти» — blue screen of death в Windows NT

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

  • Вы установили программное обеспечение, которое разрушило часть системного реестра HKEY_LOCAL_MACHINE — это может происходить при попытках прикладной программы установить новую службу или драйвер. Результатом будет появление голубого экрана, на котором пользователь читает о невозможности загрузить реестр или один из его файлов.
  • Вы некорректно изменяете конфигурацию сетевого оборудования, что может привести к нарушению сетевых привязок и соответствующих им ключей в реестре (то есть NT разрушает или перезаписывает критически важные файлы OS несовместимыми или неверными версиями системных файлов во время работы).
  • Вы установили новую службу или системный драйвер, который несовместим с аппаратным обеспечением и вызывает ошибку при перезагрузке (то есть загрузка некорректного файла приводит к разрушению исправного системного файла, который вы загрузили в память до момента сбоя).

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

Нарушения в реестре

Системный реестр — сердце системы NT. Поэтому в зависимости, от вида и степени нарушения целостности, поврежденный реестр весьма часто вызывает сбой при загрузке операционной системы. Нарушения целостности реестра могут быть физические и логические. Физическое нарушение подразумевает, что какие-то неполадки (обычно сбои в работе дисковой подсистемы) вносят путаницу в файлы реестра (например, в файлы SOFTWARE или SYSTEM в системном каталоге %winntroot%system32config). Логические нарушения означают, что приложение, пользователь или сама операционная система записали в реестр неверные данные, которые в свою очередь могут вызвать сбой при загрузке, если значение данного ключа в реестре достаточно критично.

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

Если имеются основания подозревать, что проблемы с загрузкой связаны именно с реестром, можно начать восстановление с использованием варианта загрузки предыдущей конфигурации (Last known good configuration). Это можно сделать несколькими путями.

Вариант Last known good configuration. Вы можете воспользоваться этой опцией при появлении соответствующей подсказки и нажатии клавиши пробела в период загрузки системы. Выбрав эту опцию, вы загрузитесь с предыдущей работоспособной конфигурацией. Это самый быстрый и легкий способ, если, конечно, он срабатывает. К сожалению, шансы на успех в реальной ситуации не так уж велики, поскольку данный способ ограничивается восстановлением только одной части реестра (а именно, ветви ControlSet00X в ключе HKEY_LOCAL_MACHINESYSTEM). То есть вы сможете восстановить систему данным способом, только если проблема ограничена данной ветвью реестра и вы сразу использовали вариант Last known good configuration. Однако в большинстве случаев предложенный метод не поможет.

Восстановление через процесс установки и с помощью дискеты восстановления ERD (Emergency Repair Disk). Можно воспользоваться процедурой установки NT для проверки и замены индивидуальных файлов реестра, если первый способ не сработал. После установки дискеты восстановления ERD в дисковод вы должны будете указать, какую часть существующей операционной системы требуется проверить (см. экран 2). Если вы выберете пункт Inspect registry files, появится список файлов реестра, и вы сможете указать, какие из них нужно заменить. Заменяющие файлы берутся либо с диска ERD, либо из каталога %systemroot% epair. Файлы на диске ERD и в каталоге %systemroot% repair хранятся в сжатом виде, и каждый из них имеет расширение в виде подчерка «_» (например, SYSTEM._, SOFTWARE._).

ЭКРАН 2: Экран выбора опций при процедуре восстановления программы установки

Использование самых последних копий заменяющих файлов позволит не потерять важную информацию о конфигурации приложений и системы. Созданию диска ERD с последними копиями файлов реестра посвящена статья Майка Рейли, опубликованная в январском номере журнала за 1997 год. Добавлю, что не следует восстанавливать ветви SAM и SECURITY на контроллере домена, если только вы не запускали программу создания дискеты восстановления rdisk с ключом /s или s- (то есть Rdisk /s). В противном случае программа установки перепишет вашу базу SAM ее версией, создаваемой в процессе установки, что вызовет череду новых затруднений. Кроме того, следует убедиться в том, что файлы реестра на дискете ERD и заменяемые файлы созданы операционной системой, на которую был установлен один и тот же сервисный пакет. Важно помнить, что Service Pack 3 и последующие проводят изменения в ветвях SAM и SECURITY, связанные с усилением системы безопасности NT. Если не соблюдать это правило, то вы не сможете войти в систему после завершения процедуры восстановления. Далее заметим, что исправление файлов SAM и SECURITY вряд ли разрешит проблему нарушения целостности реестра, поскольку сбой при загрузке системы вызывают по большей части ветви SYSTEM и SOFTWARE. Поэтому начинайте с восстановления предыдущих версий именно этих файлов. Причем в первую очередь ветви SYSTEM, поскольку именно в ней содержатся записи о наиболее важных компонентах системы, такие как драйверы и службы.

Альтернативная/параллельная установка NT. Использование альтернативной/параллельной установки для восстановления реестра — на наш взгляд, оптимальное средство решения проблемы. Загрузка альтернативной системы позволяет вам получить доступ к томам с NTFS, которые в противном случае были бы недоступны. А запуск параллельной системы дает вам доступ к первоначальной версии файлов реестра, так что вы можете скорректировать или заменить их. Вы можете достичь того же результата, используя ERD Commander от Systems Internals по http://www.internals.com или NTFS-DOS от Winternals Software по http://www.winternals.com. После загрузки альтернативной системы вы имеете возможность выполнить те же действия по восстановлению, что и при использовании программы установки и выборе опции восстановления, но с большей гибкостью и избирательностью. И хотя специалисты из Microsoft не рекомендуют применять данный способ, мы считаем, что он лучше всего подходит для опытных пользователей NT. Более подробная информация об использовании параллельно установленной системы находится во врезке «Параллельное мышление».

Прежде чем начать операцию восстановления, сделайте копии своих файлов реестра. Я обычно копирую существующие файлы в подкаталог каталога, содержащего файлы реестра (например, %systemroot%system32configackup). Только после этого можно начинать эксперименты с заменой отдельных файлов реестра. Однако вы не можете просто скопировать файлы, которыми будете заменять поврежденные, поскольку на дискете ERD и в каталоге %systemroot% epair эти файлы хранятся в сжатом виде. Перед использованием этих файлов примените к ним команду expand.exe, чтобы разархивировать их вручную. Например, чтобы развернуть сжатую копию ветви SYSTEM с дискеты ERD или из каталога %systemroot% epair, наберите в командной строке NT:

Expand system._ system

Скопируйте получившийся файл в %systemroot%system32config первоначальной системы и перезагрузитесь.

Если вы не хотите иметь дело со сжатыми файлами, можете использовать утилиту regback.exe из Microsoft Windows NT Server 4.0 Resource Kit для создания дополнительных копий реестра. Она создает копию, которая содержит все файлы реестра в несжатом виде. Кроме того, данная утилита копирует ветви SAM и SECURITY, так что вам не нужно будет помнить о необходимости указывать дополнительные переключатели. Однако здесь нужно учесть, что несжатые копии реестра могут не уместиться на трехдюймовую дискету. Безопасным местом для хранения копий реестра, созданных с помощью regback.exe, может служить раздел диска, отличный от загрузочного. Предпочтительно вообще хранить их на другом физическом диске. Для достижения максимальной защиты от аппаратных сбоев, которые могут сделать полученные копии файлов реестра недоступными, рекомендую хранить дополнительную копию реестра одного сервера на другом сервере и наоборот.

Переписанные или разрушенные файлы

К числу наиболее существенных недостатков операционной системы Windows 4.0 относится использование разделяемых системных файлов, которые могут быть свободно переписаны приложениями независимых компаний. Кроме того, сама система NT не слишком надежно защищает себя от замены ключевых системных файлов, таких как файлы драйверов и системных служб. В некоторых случаях это приводит только к появлению сообщений об ошибках и сбоям в работе конкретных приложений. Однако это может вызвать сбой и при загрузке самой системы NT. Следующая версия NT — Windows 2000 или Win2K — снижает вероятность такого рода сбоев посредством разделения библиотек приложений и обеспечения большей защиты от перезаписи критически важных системных файлов.

Для восстановления поврежденных или некорректных файлов на томах NTFS вы можете использовать либо параллельно установленную систему NT, либо процедуру восстановления программы установки. Для восстановления на томах FAT можно воспользоваться загрузочными дисками от DOS или Windows 9x.

Заменить файл, воспользовавшись параллельной установкой системы, очень просто, если только вы точно знаете, какой из файлов разрушен или некорректен. В качестве меры предосторожности создайте каталог на жестком диске, который послужит местом хранения файлов для установки системы NT. Можно использовать для этого и CD-ROM. В этом каталоге должны находиться копии файлов ядра NT для той версии сервисного пакета, который вы установили в системе. Если вы развернули параллельную систему с тем же сервисным пакетом, что и для первой системы, то вы можете использовать каталог второй системы как каталог для установки. Если это не так, то создайте в параллельной системе отдельный каталог с файлами первичной установки системы NT самой последний версии.

Чтобы процесс восстановления мог заменить поврежденные или конфликтующие файлы, выберите опцию Verify Windows NT System Files из списка, выводимого программой установки. Microsoft реализовала эту функцию, чтобы можно было быстро найти файлы, отличные от первоначальных установочных файлов NT. Однако после установки на систему сервисного пакета слишком много файлов будут отличаться от первоначальных, поскольку они были модифицированы. В данном случае лучше всего выбрать вариант «А», чтобы позволить программе установки заменить все неоригинальные файлы и затем, после восстановления системы и ее запуска, повторить установку сервисного пакета.

Иначе вы можете заменить системные файлы NT их первоначальными версиями, используя параметр модернизации Upgrade в программе установки. И хотя некоторые пользователи обходят описанный выше процесс восстановления и сразу приступают к модернизации, нам этот метод решения кажется неудачным по нескольким причинам. Во-первых, процесс модернизации обычно занимает намного больше времени, чем процесс восстановления. Во-вторых, он более запутан и связан с большим риском для вашей системы. И наконец, даже если процесс установки успешно разрешил ваши первоначальные проблемы, он может вызвать появление голубого экрана с ошибкой, вызванной драйвером tcpip.sys (STOP error 0x00000050). При установке NT 4.0 или NT 4.0 SP1 поверх NT4.0 SP2 или более поздней программа установки не заменяет драйвер tcpip.sys из SP2 или более поздний его ранней версией. Соответственно — этот драйвер вызывает сбой в NT 4.0 или NT 4.0 SP1. Чтобы избежать такой ситуации, нужно вначале использовать процедуру Verify Window NT System Files для замены существующих файлов их первоначальными версиями. Тогда, если процедура восстановления не привела к нормальной загрузке системы, вы сможете спокойно запускать процедуру модернизации, поскольку файл tcpip.sys SP2 или поздней версии уже был заменен первоначальным.

Осторожность не помешает

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

В следующем номере обсудим причину, вызывающую добрую треть всех сбоев: стартующие в автоматическом режиме службы или драйверы прерывают процесс загрузки. Мы расскажем о некоторых «трюках», которые можно проделать при восстановлении, включая способ удаленного восстановления реестра поврежденной системы с помощью параллельной системы. Кроме того, в следующей статье пойдет речь о средствах других фирм, которые помогут вам выкарабкаться, если вдруг система откажется загружаться.

Об авторе

Шон Дейли — сертифицированный инженер Microsoft и президент iNTellinet Solutions — интеграторской и консалтинговой компании, занимающейся вопросами сетей. Дейли ведет рубрику в журнале Windows NT Magazine и является автором книг Optimazing Windows NT (IDG Books) и Migrating to Windows NT 4.0 (29th Street Press). С ним можно связаться по адресу sean@ntsol.com.

Параллельное мышление

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

Параллельная установка — это вторая система Windows NT, установленная на том же диске, что и первичная ОС, или на другом диске. Параллельная система — своеобразный «черный ход» в вашу систему, позволяющий вам получить доступ к томам NTFS и данным файлов реестра в случае сбоя первой системы. Она также может пригодиться, если вы не надеетесь на стандартную процедуру восстановления.

Я рекомендую устанавливать параллельную систему в каталог, имя которого объясняет его предназначение. Например, для своих клиентов на каждом сервере я создаю каталог winntrec (то есть Windows NT recovery) и провожу инсталляцию параллельной системы в него. Для лучшей защиты располагать этот каталог следует в другом разделе диска или на другом физическом диске.

При установке альтернативной NT системы не следует повторять все опции установки первичной системы (например, сетевые службы, роль сервера). Устанавливайте минимальный набор опций для экономии дискового пространства. Лично я сбрасываю все опции в диалоговом окне NT Accessory и обычно не устанавливаю сетевые службы. Но если вам может потребоваться доступ к другим машинам по сети при загрузке альтернативной системы, то установите сетевую компоненту. Кроме того, не обязательно устанавливать последний Service Pack — установите тот, который считаете наиболее подходящим, если только у вас нет крайней потребности в полной эквивалентности двух систем.

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

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