Сотни непредсказуемых событий могут нарушить работу сети. Не дожидаясь этого, спланируйте свои действия по предупреждению сбоев в локальных сетях и по их восстановлению.
Многие считают, что подготовить локальную сеть на случай аварии - это значит создать резервные копии, чтобы иметь возможность восстановить диски с файловых серверов после краха. При всей своей важности эти мероприятия не решают всех проблем и помогают лишь в определенных ситуациях.
Главная цель - добиться непрерывного рабочего процесса на предприятиях или в других организациях, а в случае аварии - иметь возможность как можно скорее восстановить их работу. Но, в отличие от традиционных информационных центров, основанных на мэйнфреймах, при планировании мер по ликвидации последствий аварий в локальных сетях приходится иметь дело не только с компьютерными системами. Компьютерная сеть стала частью структуры корпорации, главной магистралью для движения информационного потока по всей организации. Локальная сеть обеспечивает подключение персональных компьютеров к файловым серверам и другим источникам данных, в том числе и к мейнфрейму; она не является отдельной информационной службой, а органически вплетается в структуру организации. Этим и объясняется, почему обеспечение безопасности и навыки по восстановлению деятельности предприятия неотделимы от аналогичных мероприятий для его (предприятия) локальной сети.
Чтобы разработать эффективный план действий на случай аварии, вам необходима помощь всей организации, особенно ее высшего руководства. Имеются в виду не просто одобрение и обещания, а готовность к сотрудничеству, готовность оказать финансовую и прочую, куда более реальную, нежели слова, помощь.
Понадобится и поддержка пользователей. Именно на их плечи ляжет основной груз по созданию, проверке и внедрению плана. Но для того, чтобы иметь возможность обратиться за помощью к пользователям, надо сначала завоевать их доверие.
ЗАЙМЕМСЯ ПЛАНОМ
Предупреждение сбоев и восстановление после сбоев - это не просто последовательность мероприятий, а образ мышления. Анализируя, например, систему, необходимо рассмотреть и возможные нарушения ее функционирования, и последствия этих нарушений. Как можно предотвратить сбои? Как справиться с их последствиями? К кому обратиться за помощью в чрезвычайных обстоятельствах? Есть ли этому альтернатива? При определенном опыте такой образ мышления станет для вас второй натурой.
Эффективный план должен предусматривать решение трех основных задач: поддержание системы в работоспособном состоянии - раз; обеспечение целостности, доступности и защищенности данных - два; быстрое восстановление системы после сбоя - три.
Для поддержания локальной сети в работоспособном состоянии требуется, чтобы она была грамотно спланирована, спроектирована и установлена. Хорошо выполненный монтаж физической сети (проводка, хабы, файл-серверы, шлюзы и маршрутизаторы) может предотвратить многие неприятности или, по крайней мере, облегчить поиск и диагностику неисправностей в случае их возникновения. По тем же причинам необходимо и надлежащее проектирование логических структур, а именно: защиты, входных управляющих файлов, структур каталогов.
Эти же три составляющие необходимы и для обеспечения целостности данных. Без целостности системы невозможна целостность данных. Первым шагом является создание эффективной логической структуры с надлежащей защитой и управлением доступом. Защита не только предотвращает несанкционированный доступ к данным, но и уменьшает риск случайного уничтожения файлов и распространения вирусов.
Какова бы ни была ваша стратегия предотвращения последствий сбоев, есть этапы, без которых обойтись невозможно. Для успешного восстановления особенно необходимо хорошее документирование систем и процедур резервного копирования. Важную роль в восстановлении может сыграть запасное оборудование (хабы, кабели, сетевые плоты и проч.), а также планы мероприятий по эксплуатации и ремонту оборудования и, конечно, опытный обслуживающий персонал.
НЕВИДИМЫЙ ВРАГ
Беда может нагрянуть в разных обличьях. И причины ее могут быть самые разные:
Готовясь к аварийным работам, вы должны не упустить из виду даже самые, как вам кажется, невероятные катастрофы. К примеру, для деловой части Чикаго наводнение - явление необычное, но в 1992 году оно произошло. А поскольку предусмотреть все возможные катаклизмы невозможно, следует быть готовым и к неожиданностям.
Как и при страховании, ото всех проблем восстановительные мероприятия не спасут, или же спасение обойдется слишком дорого. В вашу задачу входит обеспечение достаточного набора мер защиты от простоя и потери информации, дающих к тому же уверенность в возможности своевременного восстановления предприятия в случае аварии. (Более подробно проблема защиты сети от потери данных рассматривается во врезке под заголовком "Четыре аспекта хранения данных"). Стремясь максимально сократить время простоя, помните, что каждый дополнительный шаг в этом направлении будет намного дороже предыдущего и куда менее удачен. Поэтому в каждой конкретной ситуации следует тщательно оценить соотношение стоимости и эффективности предпринимаемых мер.
По природе своей локальные вычислительные сети неуправляемы и непредсказуемы. Зачастую они разрастаются и изменяются самым неожиданным образом. Этим же объясняется их способность быстро реагировать на изменение потребностей, но такая гибкость имеет свою цену.
Исчерпывающими знаниями, необходимыми для осуществления эффективного плана восстановления в случае аварии больших и сложных локальных вычислительных сетей, не обладают ни отдельные специалисты, ни группы. Вообще говоря, восстановление локальной сети после сбоев спланировать сверху донизу традиционными для информационных систем методами практически невозможно. Однако это не означает, что осуществить эффективный план нельзя; просто, быть может, придется выйти за рамки общепринятых идей и методов.
ПЛАНИРОВАНИЕ
Разработка эффективного плана на случай аварии в локальной вычислительной сети включает оценку возможного риска и сбор информации о системе, о ее функциях и пользователях. План надо подготовить в письменном виде, ознакомить каждого включенного в план с его ролью, а затем проверить план. План следует периодически пересматривать.
На первый взгляд этот процесс кажется простым, но это не совсем так. Большинство разработчиков подходят к плану на случай сбоя в локальной сети так же, как к аварийному плану для мэйнфрейма, но между этими планами существует масса различий (во врезке "Дело ведут знатоки" описан пример того, как эффективный план восстановления помог спасти компанию, пострадавшую от урагана Эндрю).
Традиционный информационный центр характеризуется четкой структурой с жестким управлением доступом, прикладными программами и порядком пользования. Он функционирует в организации обособленно, что позволяет управлять им как самостоятельной единицей. Новые приложения обычно внедряются только после тщательного рассмотрения, а все изменения системы планируются задолго до внесения.
Локальные вычислительные сети объединяют множество разнотипных устройств и поддерживают зачастую сотни приложений. Они подключают пользователей к источникам информации, размещенным по всей организации, а иногда и за ее пределами.
Управление и контроль часто осуществляются многими руководителями на различных уровнях, в разных подразделениях или рабочих группах. Эти люди могут иметь разные взгляды и цели. Новые приложения часто добавляются на серверы рабочих групп (или на рабочие станции пользователей) сразу же после уведомления, а многие составляющие системы: файловые серверы, рабочие станции и принтеры - добавляются или меняются без ведома центра.
Из-за наличия такого большого количества взаимодействующих элементов локальные сети часто бывают очень чувствительны к воздействию самых незначительных факторов. Малейшее изменение в одной зоне может повлиять на всю систему.
Ненадежность проводки, например, может оставаться незамеченной до тех пор, пока добавление всего одной рабочей станции не вызовет крах системы. Откачка (своппинг) драйвера для сетевого адаптера на одной станции может создать проблемы для всех остальных, если этот драйвер несовместим с другими в сети. Из этого следует: подготовиться к каждой непредвиденной ситуации невозможно, значит надо быть готовыми к неожиданностям.
Динамическая природа локальных вычислительных сетей объясняет тот факт, что написать на случай аварии исчерпывающий план, который учитывал бы каждый элемент сети и каждую поджидающую его неприятность, как правило, невозможно. Такой план может устареть, еще не будучи завершенным.
Есть ли шанс избежать данных проблем? Везде, кроме самых маленьких организаций, это невозможно. А следовательно, надо заняться разработкой набора меньших планов. Для сетей подразделений это означает, что каждый отдел должен разработать свой план. Если информационная служба имеет централизованную структуру, то она будет осуществлять планирование всех управляемых ею элементов и выступать в роли помощника, координатора и дирижера для всей организации.
ДОКУМЕНТАЦИЯ ДЛЯ ЗАЩИТЫ
Для эффективного предотвращения аварий и восстановления очень важна хорошая документация. Она способствует предотвращению ошибок и гладкому течению процесса восстановления. Руководства по эксплуатации программных и аппаратных средств хороши для предполагаемых пользователей, но они не содержат сведений о стратегии, организации и конфигурации в конкретно вашей организации.
Так, какого же рода документация вам нужна? Ответы для разных организаций различны, но существует ряд общих положений:
Важнейшей проблемой является поддержка документации. Многие компании тратят тысячи долларов на создание документации только для того, чтобы потом обнаружить, что у них нет эффективного механизма ее поддержки и обновления. При разработке документации займитесь этим вопросом вплотную.
Документация должна быть ясной, краткой и по теме, например, две или три страницы основных сведений о процедурах резервного копирования и восстановления будут более эффективны, чем чрезмерно подробный трактат на эту тему.
При написании документации не увлекайтесь чересчур техническим языком, расшифровывайте все акронимы и жаргонные термины. Для опытного пользователя сети жаргон не составит проблемы, но что, если в аварийной ситуации эту работу придется выполнять менее опытному работнику? А представим, вам самим придется воспользоваться этой документацией года через два, когда может подзабыться многое из того, что сегодня вы знаете назубок?
По возможности именно те, кто работает с системой или процедурой должны создавать и поддерживать документацию. Это дает основания надеяться, что работники будут разбираться в том, что делают, и вероятность непонимания, которое может возникнуть при привлечении независимых разработчиков, практически исчезнет. Обучите пишущих документацию пользоваться описываемым инструментарием и обеспечьте его доступность. Просмотрите и проверьте документацию с привлечением независимых специалистов, не имеющих глубоких знаний системы или процесса - это единственный способ выявить упущения и выбросить неточные и некорректно изложенные сведения.
Документация должна быть доступна любому, кто в ней нуждается. На случай аварии копии документации следует хранить и в другом помещении.
ВОЗВРАЩЕНИЕ К ДЕЯТЕЛЬНОСТИ
Так как для предотвращения большинства аварий сделать можно немного, надо основательно подготовиться на случай их возникновения. Но предусмотреть, например, бомбардировку федерального здания в Оклахома Сити просто невозможно. Да и ни к чему. Достаточно представить, что в результате какого-то неординарного события, рабочее место станет на некоторое время недоступным.
Так как системы на базе локальных вычислительных сетей становятся все более критически важными, актуальной становится проблема восстановления их в другом месте. Но не пытайтесь разрешить эту проблему одним махом. Каждая организация должна разработать свою схему восстановлению деятельности.
Имеется пять основных подходов к восстановления деятельности в другом месте:
Итого пять пунктов, каждый из которых имеет свои "за" и "против". Постоянное помещение дорого стоит, а делить помещение с другой компанией или даже с другим отделением вашей же компании, как правило, можно лишь непродолжительное время.
Многие компании, предоставляющие рабочие места на время восстановления мэйнфреймов, теперь предлагают рабочие места на время восстановления локальных вычислительных сетей. Персонал этих компаний выполнит все необходимые работы по обслуживанию системы, но стоимость их услуг относительно высока, да и пригодны такие места обычно лишь на первое время.
Еще один подход предполагает планирование аренды площади и приобретения оборудования по мере необходимости. Это может быть рискованно, но при правильном отношении к делу зачастую весьма эффективно. Такой подход, плюс ко всему прочему, обеспечивает свободу действий большую, чем остальные, здесь обсуждаемые.
ОБНОВЛЕНИЕ ПЛАНА
План восстановления устаревает в некоторых пунктах уже в момент написания. Его следует рассматривать как совокупность рекомендаций, а не как непреложные указания. В состав команды по восстановлению должны входить специалисты, обладающие достаточными знаниями, способностями и независимостью, чтобы суметь реализовать план в критической ситуации. Однако постоянное поддержание плана в максимально соответствующем текущему положению дел состоянии сведет к минимуму число обращений за разъяснениями.
Разработка плана на случай аварии не избавляет от необходимости ежедневного выполнения рабочих процедур и документирования. Но при надлежащем выполнении всего вышеописанного повышается вероятность сохранения после аварии наиболее ценных активов неповрежденными.
Патрик Х. Корриган - исполнительный директор консультативной фирмы The Corrigan Group (Tigard, OR). Отдельные части статьи взяты из его книги "LAN Disaster Prevention and Recovery". С ним можно связаться через CompuServe по адресу: 75170,146.
РЕЗЕРВИРОВАНИЕ И АРХИВИРОВАНИЕ - RAID И HSM
Четыре аспекта хранения данных
Влокальной сети применяется множество подходов к хранению и восстановлению данных. Каждый из них служит для достижения определенной цели.
Резервирование
Резервирование позволяет восстанавливать данные в случае их потери. Причиной потери данных может стать крах диска или сервера, удаление файла, перезапись файла или порча данных из-за возможных проблем в ЦП, оперативной памяти, питании или приложении. Избыточность резервирования важна для обеспечения восстановимости файлов, которые могут быть утеряны несколько дней, недель или даже месяцев тому назад. Резервирование должно быть доступно по первому требованию. Для выполнения этой задачи более всего подходит магнитная лента, так как она дешева.
Архивирование
Архивы являются постоянными или полупостоянными копиями данных для долгосрочного хранения. Архивы можно создавать во время резервирования или при помощи отдельной процедуры. Для этой цели часто используются магнитные ленты. Другими носителями являются оптические диски; они имеют значительно больший срок службы, чем магнитная лента, но и стоят гораздо дороже.
Резервные диски и серверы
В этом случае диски зеркалируются и дуплексируются, а также применяется технология RAID и зеркалирование серверов. Зеркалирование дисков означает, что данные записываются на два массива дисков более или менее одновременно. Дуплексирование является видом зеркалирования, при котором все компоненты дискового "канала", влючая адаптеры хоста или контроллеры, дублируются. Сокращение RAID иногда расшифровывают по-разному (Redundant Arrays of Inexpensive Disks - избыточные массивы недорогих дисков, либо Redundant Arrays of Independent Disks - избыточные массивы независимых дисков), в любом случае, наиболее распространненым подходом к организации хранения в локальной сети является запись данных на нескольких дисках таким образом, что если один диск выходит из строя, то дисководы других дисков могут "вычислить" данные, которые хранились на поврежденном диске. Зеркалирование сервера означает запись данных на двух серверах одновременно.
Структированное хранение информации
Структурированное хранение информации Hierarchical Storage Management (HSM) устанавливает иерархию классов хранения, которые обычно называются хранением в оперативном, почти оперативном и автономном режиме, или иначе - первичным, вторичным и третичным хранением. Хранение в оперативном режиме (первичное) обычно используется для постоянно доступных дисков, таких как жесткие диски серверов. Хранение в почти оперативном режиме (вторичное) - для дисков, которые могут стать доступными автоматически. Здесь используются проигрыватели оптических дисков и устройства для смены кассет с магнитной лентой. Наконец, хранение в автономном режиме (третичное) применяется для носителей, которые должны вставляться вручную, прежде чем станут доступны пользователям.
Системы HSM автоматически переводят данные из одного класса в другой в зависимости от использования. Основной целью HSM является обеспечение хранения больших массивов данных без больших финансовых затрат. Оно напрямую не касается вопросов потери данных или архивирования.
ВСЕ ЭТО ПЛАНИРОВАНИЕ
Рецепт восстановления
СВОИМ ВОССТАНОВЛЕНИЕМ ПОСЛЕ УРАГАНА ЭНДРЮ КОМПАНИЯ DATA ACCESS ОБЯЗАНА ЧЕТКОЙ СТРАТЕГИИ, ПРАВИЛЬНОМУ РАСПРЕДЕЛЕНИЮ РОЛЕЙ И ПРЕДАННОСТИ СВОИХ СЛУЖАЩИХ
ДЕЛО ВЕДУТ ЗНАТОКИ
24 августа 1992 года большая часть Северной Флориды пострадала от урагана Эндрю. Большинство зданий в зоне урагана было разрушено, многие из них полностью уничтожены. Возможность восстановления деятельности предприятия сразу после урагана вызывала сомнение, так как в первую очередь людей волновали первоочередные проблемы жизнеобеспечения: жилье, питание и т.п. Восстановлению предприятия препятствовало также нарушение инфраструктуры, то есть системы электропитания, связи, дорог.
Недавно построенные в Майами офисы Data Access, компании по разработке систем управления базами данных, были полностью разрушены ураганом. Большая часть компьютерного оборудования была уничтожена или повреждена так, что не подлежала ремонту, почти вся документация, хранимая на бумаге, пропала. К тому же треть персонала, включая и владельца, потеряла свои дома.
Несмотря на это, потребовалось меньше недели для восстановления работы важнейших служб, а полное восстановление деятельности компании заняло меньше двух недель.
Восстановлению способствовало множество факторов. В первую очередь помогло то, что в компании регулярно выполнялось резервное копирование, а копии хранились отдельно. Кроме того, резервные копии основных программных продуктов и исходных текстов хранились в четырех разных местах, одно из которых находится за пределами Соединенных Штатов. К тому же процедуры резервного копирования и восстановления были хорошо документированы. Почти вся информация хранилась на файловых серверах, а не на жестких дисках рабочих станций, что также облегчило решение проблемы восстановления данных.
Компания Data Access к тому времени уже использовала стандартную конфигурацию серверов. Логические установки всех серверов, в том числе структура каталогов, защита и выходные управляющие файлы, были согласованы между серверами. К тому же при проектировании сети в Data Access было осознанно принято решение использовать всегда имеющиеся в наличии, легко получаемые компоненты, не требующие доработки. Все это в сложившейся ситуации было как нельзя кстати.
Хотя полного плана восстановления данных в компании Data Access не существовало, основные действия служащих на случай аварии были хорошо документированы и усвоены. Поэтому готовность отдела обслуживания вычислительной сети к проведению восстановительных работ не вызвала сомнений. Кроме того, почва для проведения этих работ была подготовлена заранее, поскольку у работников отдела обслуживания еще до того, как компанию постигло бедствие, установились тесные связи с пользователями и руководством.
Хотя ответственность за проведение восстановительных работ лежала на отделе обслуживания сети, они работали не одни. "Сотрудники отдела имели опыт и знания, но своими силами в сложившейся ситуации им было не справиться", - говорит Стив Милей, вице-президент технических служб.
"Самым важным фактором, - продолжает Милей, - было то, что Data Access в первую очередь позаботилась о своих сотрудниках, и они отплатили за это с лихвой. В самом деле, сразу после урагана руководство компании помогло своим сотрудникам решить их личные проблемы, ведь многие остались без крыши над головой.".
По мнению Милей, "уверенность в завтрашнем дне, уверенность в том что руководство сделает все для сохранения рабочих мест" Data Access, поддерживала служащих компании в трудные минуты.
Сразу же после урагана было организовано временное размещение в северной части Майами. Сотрудники отдела обслуживания сети взяли серверы из разрушенных зданий к себе домой, чтобы там проверить и отремонтировать их. Все, что можно было спасти, сотрудники для сохранности вынесли из поврежденных зданий и разместили по домам. Персонал отдела обслуживания сети немедленно принялся за прокладку кабеля и создание новой сети на базе временно размещенного оборудования.
После случившегося бедствия компания Data Access внесла в некоторые процедуры ряд изменений. Теперь у руководителей есть списки с данными о сотрудниках, включая номера их домашних телефонов и телефонов близких родственников. Отдел обслуживания сети стал больше внимания уделять поддержанию документации по сети, а копии самых важных документов хранятся в других местах. И, наконец, с внедрением Windows во всей компании налажено регулярное резервное копирование жестких дисков рабочих станций.