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

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

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

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

Когда я делаю различие между предотвращением сбоя и восстановлением после сбоя, я полагаю, что предотвращение - это то, что можно сделать до того, как что-то произойдет, а восстановлением называю то, что делается после происшествия. "Что-то" может быть событием, которое можно предотвратить, таким как многократные сбои диска, или происшествием, которое нельзя предотвратить, например землетрясение. Во врезке "Возможно ли полное восстановление?" описывается личный опыт одного из признанных экспертов по SQL Server в сфере предотвращения сбоев после атаки 11 сентября 2001 года на Всемирный международной торговый центр. Как подчеркивается в статье, планирование, подготовка и настойчивость гарантируют, что организация сможет пережить сбой. Давайте рассмотрим некоторые методы, которые помогут подготовиться к худшему.

Стратегии предотвращения сбоев

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

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

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

Кроме того, необходимо убедиться, что в список возможных сбоев занесена печально известная "ошибка пользователя". Подобные ошибки могут вызывать наиболее сложные сбои с точки зрения их предотвращения и часто оказываются трудноустранимыми. Пользователи совершают такие ошибки, как случайное удаление строк с данными, таблиц или всей базы данных. В SQL Server пользователи, имеющие высокий уровень привилегий, легко могут нанести большой ущерб. Хотя проверка целостности по ключевым ссылкам, связывание схем и триггеры могут помочь предотвратить случайное удаление строк, или удаление данных из таблиц, SQL Server не в состоянии обеспечить надежную защиту от удаления всей базы данных. В отличие от более ранних версий SQL Server, в которых команда DROP DATABASE на самом деле не удаляет файлы из файловой системы, когда удаляется база данных, SQL Server версии 2000 или 7.0 удаляет с диска файлы, содержащие данные, так что база данных действительно удаляется.

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

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

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

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

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

Многие решения, позволяющие избежать простоев, зависят от подсистемы жестких дисков. Диски - наиболее активная часть любой системы, и ни один из них не является полностью защищенным от сбоев. Даже если имеется лучшая из RAID-систем, аппаратура может дать сбой, который способен сделать весь массив недоступным. При использовании RAID нужно помнить, что отказоустойчивость применима только к сбоям одиночного жесткого диска, так что следует рассмотреть вероятность сбоя двух жестких дисков. Не стоит думать, что вероятность сбоя второго диска мала, после того как первый уже отказал. Если все диски были куплены в одно и то же время, другие диски, вполне вероятно, также приближаются к моменту отказа. И помните, что даже избыточные массивы дисков не защитят от ошибок пользователя. Если пользователь случайно удаляет таблицу с производственными данными, это удаление повторится на всей дисковой системе. Если жесткий диск дал сбой, и это прошло незамеченным, далее возможен и полный сбой системы. Следует регулярно проверять журнальные файлы на предмет сообщения об ошибках или сделать так, чтобы в случае сбоя рассылались автоматические уведомления.

4. Рассмотрите варианты решений "теплого" резерва. В решениях, которые решают проблемы с простоями почти полностью, и используют избыточность, дополнительные аппаратные средства называются "горячим" резервом. Другое решение, не такое дорогостоящее, но обеспечивающее сопоставимую защиту, называется "теплым" резервом. В отличие от "горячей" системы, подобной SQL Server, работающему на кластере, "теплый" резерв требует вмешательства пользователя на прикладном уровне, для того чтобы переключиться с системы, находящейся в состоянии сбоя, на резервную систему.

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

5. Спланируйте стратегию архивирования и восстановления данных. Хотя планирование архивирования и восстановления можно было рассматривать как часть предыдущих технологий, я определяю его как отдельную стратегию. Даже если не делать больше ничего, данные следует сохранить. Если вы работаете с SQL Server только через утилиту Enterprise Manager, то для вас процедура резервирования представляет собой простую пошаговую операцию, которую требуется настроить один раз. Но хороший администратор, чтобы избежать потери данных при сбоях или потери производительности, должен знать все о возможностях резервирования и восстановления данных в SQL Server. В SQL Server предусмотрено три способа восстановления данных, в каждом из которых резервирование и восстановление можно выполнять по-разному. SQL Server позволяет резервировать всю базу данных, журнальные файлы и индивидуальные файлы или группы файлов. Кроме того, можно делать дифференциальное резервирование базы данных, которое позволяет оперировать только с данными, которые изменились, начиная с последней полной копии базы данных. А в SQL Server версии 2000 можно также исполнять дифференциальное резервирование файла или группы файлов.

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

Кэлен Дилани - Независимый консультант и инструктор по SQL Server. Имеет сертификаты MCT и MCSE. Автор книги Inside SQL Server 2000 (Microsoft Press). С ней можно связаться по адресу: kalen@sqlmag.com.

"Возможно ли полное восстановление?"

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

Майк Хотек - руководитель и мой коллега по Solid Quality Learning - является одним из ведущих экспертов по репликациям и высокой отказоустойчивости SQL Server. В качестве консультанта Хотек сотрудничает как с компаниями, входящими в Fortune 100, так и с небольшими организациями. Двенадцать компаний-клиентов Хотека 11 сентября 2001 года находились в Центре всемирной торговли в Нью-Йорке. Из тех 12 компаний семь были тогда уничтожены. Хотя некоторые данные могли быть сохранены, не осталось сотрудников, нуждавшихся в этой информации.

Оставшиеся в живых сотрудники остальных пяти компаний обратились к Хотеку за помощью. Из первой компании позвонили через два дня после нападения. Хотек потратил только полдня на работу с этой компанией, поскольку все данные, принадлежащие ей, и информация о том, как эти данные восстановить, пропали в результате катастрофы. Фирма не выжила. Две из оставшихся четырех компаний находились в похожих обстоятельствах - они просто не имели ничего, чтобы можно было возобновить деловую активность. Еще две компании уцелели главным образом из-за того, что выполнили указания Хотека по предохранению от катастрофы. Хотек описал мне свой опыт работы с этим уцелевшими фирмами.

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

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

Во-вторых, отличие этого восстановления от типичного сценария в большей степени касалось персонала. Большинство методик защиты от аварийных ситуаций предполагают, что системными паролями должен владеть не один человек, и не один человек должен знать, где хранятся резервные копии программы. Несмотря на это, немногие действительно планируют мероприятия на случай, если весь штат ИТ-службы будет отсутствовать. Обе уцелевшие компании потеряли большую часть персонала ИТ. К счастью, по причине того, что Хотек помогал компаниям разрабатывать план восстановления после аварий, в обоих случаях он обладал большей частью необходимой информации. Для обеих компаний он был единственным человеком, который знал технические требования их бизнеса. Хотя члены правления и акционеры не ожидали немедленного восстановления, Хотек осознавал, что он должен помочь компаниям восстановиться как можно быстрее. Для того чтобы обе фирмы снова стали действующими, он предпринял 6 основных шагов:

  1. Определил, какими навыками обладают оставшиеся сотрудники.
  2. Обеспечил финансирование работ по восстановлению.
  3. Нашел новое место и заказал новое оборудование для наиболее важных систем.
  4. Нанял подрядчиков для оказания помощи в восстановлении систем.
  5. Установил местонахождение всех резервных копий и рабочих документов и определил, какие еще данные имеются в наличии.
  6. Заставил уцелевший персонал ИТ и подрядчиков работать вместе.

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

Спустя два года после нападений обе компании продолжают работать. Они вновь укомплектованы, хотя в настоящее время немного меньше, чем до 11 сентября. Хотек по-прежнему работает с компаниями, осуществляя контроль и анализ. Кроме того, он обладает уникальными знаниями об их системах, поскольку сам разработал и создал эти системы. Тем не менее, он полагает, что сотрудничество прекратится, когда он передаст свои знания ИТ-персоналу компаний. В настоящее время обе компании располагают резервным оборудованием, удаленным от вычислительного центра, которое они могут немедленно установить. Они обе имеют удаленные на 25 миль от основных систем кластеры и применяют пересылку журналов для синхронизации удаленных кластеров с основными системами. Резервирование данных осуществляется каждые пять минут. Примечательно, что обе компании разработали план такого резервирования два года назад и предполагали начать его реализацию в октябре 2001 года.

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