Планирование аварийного восстановления Windows Server 2003 (часть 2)

Чтобы получить полное руководство по безопасности, ознакомьтесь с « Учебным пособием по безопасности + и DVD-системой обучения » на Amazon.com.

В части I мы рассмотрели кластеризацию и балансировку нагрузки Windows 2000 и Windows Server 2003 для обеспечения высокой доступности, а также общую информацию по планированию.

Что может случиться?

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

• Хакеры, эксплойты и нарушения безопасности
  
• Сбой системы, сбой диска и т. д.
  
• Сбой питания
  
• Пожарные аварии
  
• Штормовые аварии
  
• Аварии на воде, наводнения
  
• Землетрясения
  
• Теракты
  
• Преступность и вандализм
  
• Экстремальные погодные условия, такие как холод, жара, сухость и влажность
  
• Потеря персонала, который эксплуатировал или обслуживал такие системы

Как видите, катастрофа может быть вызвана практически чем угодно! В этом разделе вы узнаете, что может потребоваться для восстановления после аварии с помощью плана аварийного восстановления (DRP).

Составление плана аварийного восстановления

Если подумать, высокая доступность в любом решении — это то же самое, что иметь встроенный план аварийного восстановления! Если у вас есть кластер из двух узлов и один из них выходит из строя, катастрофой является отказ одного узла, а восстановлением является переход на другой узел. Это форма аварийного восстановления. Произошла катастрофа, и вы выздоровели, потому что были готовы. Чтобы сделать этот процесс более формализованным и презентабельным для руководства, вы захотите включить его в документированный план, но механика избыточности и отказоустойчивости является основой самого плана. Чтобы начать DRP, вы должны сначала оценить свой бизнес и его работающее решение. Вот некоторые первоначальные мысли. Какова допустимая продолжительность простоя? Я часто задаю этот вопрос и всегда получаю пустой взгляд. Я говорю это потому, что часто предприятия думают, что, внедрив DRP, они сразу же избегут катастрофы. Извините, это не так. У вас есть разные уровни аварийного восстановления, которые определяют, сколько вы можете восстановить и как быстро. Детализируя время простоя, руководство должно поговорить с клиентами и другими пользователями услуг, чтобы решить, сколько успешных предприятий может выдержать во время простоя и при этом выжить.

Вот пример: вы владелец сайта электронной коммерции, который продает виджеты в Интернете. Если вы продаете виджеты 24 часа в сутки на международном и внутреннем рынках, вы получаете доход 24 часа в сутки от своих веб-сайтов. Вы бы хотели, чтобы эта нагрузка была сбалансированной и избыточной. Если ваш сайт не работает более 30 минут, ваши покупатели могут уйти к другому продавцу виджетов, и они никогда не вернутся. И это после всего лишь одного отказа! Вы можете так быстро потерять бизнес без DRP и решения, поэтому допустимое время простоя сведено к минимуму, если это возможно.

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

Аварийное восстановление и управление

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

Определение возможного воздействия стихийного бедствия

Теперь давайте обсудим, какие вопросы, основанные на воздействии, вы можете задать, чтобы помочь вашему бизнесу перейти к высокодоступной и безаварийной среде.

Какая часть материальных ресурсов компании будет потеряна?

Этот вопрос важно оценить. Хотя это не одна из основных причин наличия решения высокой доступности, тем не менее, это важная причина. Если вы потеряете материальные ресурсы из-за стихийного бедствия, это может дорого обойтись бизнесу. Подумайте, что могло бы произойти, если бы у вас был кластер Windows 2000 с работающим на нем SAP/R3, который контролировал бы все ресурсы вашей компании. Другими словами, SAP/R3 — это приложение для планирования ресурсов предприятия (ERP), которое помогает вам управлять материальными ресурсами вашей компании. Если в вашей системе произошел сбой и все данные были потеряны, вы рискуете потерять всю информацию о доставке, возможно, вашу базу данных материалов или, что еще хуже, инвентарь. Все эти элементы имеют решающее значение для бизнеса, и без них вы не сможете вести свой бизнес. Только по этой причине для вас очень важно оценить возможную потерю данных о ваших материальных ресурсах.

Каковы общие расходы, связанные с стихийным бедствием?

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

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

Какие затраты и человеческие ресурсы необходимы для восстановления?

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

Сколько времени потребуется, чтобы восстановиться, если случится бедствие?

Знаете, как говорят: время – деньги. Оцените, сколько времени может потребоваться, чтобы восстановить работу вашей компании после аварии, и сколько времени потребуется для ее полного восстановления. Вам необходимо учесть тот факт, что если вы вышли из строя из-за стихийного бедствия, то чем больше времени потребуется, чтобы вернуть ваши системы в оперативный режим, тем больше денег может потерять ваш бизнес.

Каково влияние на конечных пользователей?

Конечные пользователи — ваши работники. Они являются топливом для двигателя. Если они не работают, то почти ничего не будет сделано. Это важно, если вы цените термин «производительность» в своей организации. В случае стихийного бедствия, в зависимости от воздействия стихийного бедствия (и возможного отсутствия DRP), вы можете обнаружить, что ваши сотрудники сидят без дела или околачиваются у кулера с водой.

Каково влияние на поставщиков и деловых партнеров?

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

Как это повлияет на цену вашей акции и доверие потребителей?

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

Каково влияние на общую организацию?

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

Уровни приоритета систем, сетей и приложений

Теперь, когда у вас есть веская причина для использования DRP, вам нужно немного конкретизировать его. Что касается ваших систем, сети и приложений, вам необходимо создать систему, которая классифицирует их на диаграмме, например, трехслойной диаграмме с использованием электронной таблицы Excel. Это гарантирует, что ресурсы, деньги и усилия направляются в систему, сеть или приложение, которые считаются наиболее важными. Обычно мэйнфреймы, электронная почта, маршрутизаторы и коммутаторы занимают первое место в моем списке критически важных компонентов, но решать вам и вашему анализу. Давайте посмотрим на мои уровни:

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

Например, если возникла проблема (например, ошибка дисковода), которая, если ее игнорировать, потенциально может привести к прерыванию вашего бизнеса.

• Незначительный или низкий приоритет — это любые имеющиеся у вас сбои, которые легко восстанавливаются, возвращаются в оперативный режим или исправляются с небольшим ущербом или нарушением работы. Это все еще нарушение, но оно не влияет на ваши системы или ваш бизнес. Например, если у системы есть проблема с ее монитором.
  

Отказоустойчивость сервисов

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

• Убедитесь, что ваши каналы WAN избыточны. Вы можете внедрить вторичные фреймовые соединения или двухточечные соединения или набрать резервные линии с помощью ISDN.
  
• Убедитесь, что ваши протоколы маршрутизации являются динамическими, если вы хотите, чтобы они изучали другие пути в случае аварии. Статические пути не обязательно сделают это за вас.
  
• Убедитесь, что у вас несколько сетей или операторов связи. Если у одного оператора возникла проблема, вы можете обратиться к другому. MCI WorldCom — прекрасный тому пример.
  
• Убедитесь, что у вас есть аппаратная отказоустойчивость в любой форме — жестких дисках, маршрутизаторах, брандмауэрах, кабелях и так далее.
  
• Убедитесь, что у вас есть резервная мощность в виде ИБП или резервных генераторов.
  
• Убедитесь, что у вас есть отказоустойчивость сетевых служб, таких как DHCP и т. д., в случае сбоя.

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

Предоставление плана аварийного восстановления

Теперь у вас есть план на бумаге! Так что же дальше? Убедитесь, что план полон деталей и хорошо задокументирован. Убедитесь, что ваши сотрудники изучают его. Запланируйте занятие для всех, чтобы узнать о плане, и включите устный тест по DRP как часть занятия. В наших следующих двух статьях мы коснемся других аспектов DRP и BCP, включая системный DRP и так далее… в режиме ожидания!

В сумме

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