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

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

«Полное руководство по обеспечению высокой доступности см. в разделе «Кластеризация и балансировка нагрузки Windows Server 2003» на сайте Amazon.com».

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

В этом разделе мы обсуждаем планирование аварийного восстановления. В первой статье (находящейся в разделе «Ссылки и ссылки» этой статьи) мы рассмотрели очень общие детали, теперь мы рассмотрим, что может произойти на самом деле. Если вы когда-либо сталкивались с крупномасштабной катастрофой, вы точно знаете, что может случиться — может случиться «все что угодно». Чтобы подготовиться к чему-либо, вы должны начать мозговой штурм со своей командой, что может произойти, и перечислить это. Вот несколько примеров потенциальной катастрофы для бизнеса вашей организации, которые, скорее всего, возникнут.

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

«Катастрофа» — это неизбежная катастрофа, которая обычно происходит неожиданно. «Восстановление» — это переход от катастрофы к полному производству — либо полное предотвращение катастрофы, либо возможность оправиться от нее. Не заблуждайтесь, бедствие когда-нибудь произойдет, и когда оно произойдет (большого или малого масштаба), вы сможете оправиться от него, если будете к этому готовы. Помните, из списка ясно видно, что катастрофа может быть вызвана практически чем угодно! В следующем разделе мы расскажем об использовании плана аварийного восстановления, который поможет вам организованно и быстро восстановиться после аварии — время имеет решающее значение, когда дело доходит до аварии, каждая секунда на счету.

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

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

Пример: Онлайн-примеры журнала аварийного восстановления

Если случилось бедствие и вы выздоровели, то только потому, что вы были готовы или вам действительно повезло. Мне нравится быть подготовленным; это полностью исключает сетевые аспекты Лас-Вегаса.

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

Какова допустимая продолжительность простоя?

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

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

Другой пример — сервер приложений, который находится во внутренней сети вашей компании.

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

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

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

Вам нужно, чтобы ваше руководство купило DRP. Я видел слишком много управленческих команд, которые выбрасывали DRP из окна из-за затрат. Но катастрофы могут случиться всегда, поэтому руководство должно взять на себя ответственность за эффективную DRP. Высшее руководство должно понимать и поддерживать влияние на бизнес и риски, связанные с полным отказом системы. Если вы публичная компания, вас могут даже в определенной степени привлечь к ответственности, если удастся доказать небрежность. Это серьезный вопрос, когда речь идет о данных. Руководству необходимо понимать риски с внедрением решения высокой доступности и без него, а также способы финансирования DRP. Подумайте о медицинских картах человека в медицинском учреждении. Если вы рассчитаете первоначальные затраты на HA и DR, сможете ли вы сказать любому пациенту, что его история болезни исчезла, потому что вы сэкономили несколько долларов для компании и положили бонус в свой карман. Вы бы поступили так со своим родителем или любимым человеком? Вы бы сожгли медицинские карты вашей матери ради бассейна? Когда я объясняю это таким образом, люди смеются – но насколько это правда? Я никогда не видел, чтобы компании относились к этому серьезно, пока не стало слишком поздно, очень немногие активно планируют способ вернуться к делу, если произойдет что-то серьезное. Системы резервного копирования данных и системы RAID могут помешать землетрясению лишить всякой надежды на повторное использование «этого» объекта. Если у вас нет доступного резервного сайта, на который вы могли бы пойти с хорошими резервными копиями данных, вы не вернетесь в бизнес. Это так просто. Безбумажное общество означает потребность в способе сохранения этих данных. DRP - поддержите это, примите это. Чем больше вы принимаете это, тем больше у вас шансов предотвратить катастрофу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте посмотрим на мои уровни:

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

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

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

Вам необходимо спланировать отказоустойчивость, проверив следующие области вашей сети:

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

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

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

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

Ссылки и ссылки

Планирование высокой доступности: планирование аварийного восстановления
Статья о сетях Windows — часть I из серии «Планирование высокой доступности»

Написано Робертом Шимонски: «Полное руководство по обеспечению высокой доступности см. в статье Кластеризация и балансировка нагрузки Windows Server 2003 на Amazon.com».