Катастрофоустойчивая защита - какой ценой?

Виктор Бабков (Viktor Babkov), технический директор, Business Continuity Asia Pacific

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

1. Сколько информации будет потеряно, если сервер сломается или офис будет эвакуирован?
2. Как быстро можно будет вернуться к бизнесу?
3. Каким образом такой простой скажется на бизнесе с финансовой точки зрения?

Ответы на эти вопросы просто необходимы для оценки рисков, которую требуют акционеры и управляющие компании.

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

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

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

Учитывая количество возможностей и факторов, о которых необходимо помнить, создается впечатление, что каждый CIO должен иметь ученую степень, чтобы принять верное решение.
[cid:image001.png@01CB2D83.C2FA4B60]

Данный материал создан для того, чтобы помочь ответственным лицам выбрать наиболее подходящий способ защиты данных для их бизнеса.

Ниже будут рассмотрены следующие вопросы:

1. Страхование данных - репликация

2. Определение восстановления IT-систем - RTO и RTO восстановления

3. План поддержки непрерывности бизнеса - бизнес-процессы и надежность IT

4. Катастрофоустойчивость против Операционного Восстановления

5. История резервного копирования - эволюция GRID-вычислений

6. Катастрофоустойчивость и облачные вычисления

7. Пропускная способность и другие лучшие практики области технических решений

8. Воздействие внедрения и управления изменениями системы

9. Катастрофоустойчивость и виртуализация

10. ПО против аппаратных средств - преимущество оптимизированной загрузки

11. Решение для конкретных целей - CAPEX и OPEX


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

Исторически эти вопросы решали продукты из семейства Резервное копирование и восстановление: компании должны делать резервные копии данных на другие носители и в случае сбоя аппаратных средств или ПО восстановить систему в состояние до резервного копирования.

Этот подход подразумевает две сложности:

• Данные, созданные между последним резервным копированием и сбоем системы, будут потеряны
• Пока идет восстановление систем, персонал не сможет нормально выполнять свою работу и новые данные также оказываются утерянными.

1. Определение современных концепций восстановления IT-систем - RTO и RTO <восстановления>
Сегодня CIO должен определить две задачи для обеспечения поддержки непрерывности бизнеса со стороны IT:
(1) Объем данных, который бизнес может позволить себе потерять (известный как термин Recovery Point Objective (RPO))
(2) Период, в течение которого допустимо отсутствие доступа к системам (известный как термин Recovery Time Objective (RTO)).

Чтобы определить значение этих показателей для конкретного бизнеса, менеджмент должен рассмотреть:
(1) Бизнес-процессы, которые зависят от IT-инфраструктуры, и оценить стоимость прерывания работы этих процессов в результате сбоя инфраструктуры
(2) Технологии, способные смягчить сбои инфраструктуры и оценить стоимость их содержания (поддержка, подписка и т.д.).

[cid:image002.png@01CB2D83.C2FA4B60]
[cid:image003.png@01CB2D83.C2FA4B60] [cid:image004.png@01CB2D83.C2FA4B60]

3. Определение цены простоя - бизнес-процессы и зависимость от IT
Определение RTO/RPO требует серьезного анализа фундаментальных основ бизнеса. С таким анализом невозможно справиться без активного диалога с управляющими департаментами, которые имеют наиболее четкое представление о взаимодействии бизнес-функций и IT. Классическим примером может послужить интернет-банкинг: если система недоступна, зарплаты не могут быть выплачены, в результате сотрудники не смогут совершить запланированные покупки, и начнут требовать от бизнеса возмещения.

Наиболее показательным будет пример потери системы бронирования мест в одной из крупных авиакомпаний в 2009 году: 6 часов отсутствия доступа к системе привели к неделе хаоса в аэропортах по всей Новой Зеландии и Австралии, а также к финансовым затратам авиакомпании (пропущенные полеты, требования размещения пассажиров и т.д.)

Результаты общения с главами департаментов обычно отражаются в отчете воздействий на бизнес - Business Impact Analysis (BIA). Этот документ позволяет четко определить RPO и RTO для конкретного бизнеса и выявить подходящие стратегии, которые позволят соответствовать найденным показателям. С технической точки зрения, определение таких стратегий приводит к перемещению критически важных для бизнеса приложений на специальные front-end серверы, сети и серверы баз данных (<компоненты инфраструктуры>).

RPO/RTO каждой бизнес-функции позволяет определить техническое решение, подходящее для определенных компонентов инфраструктуры. Решение, обеспечивающее большую доступность (например, меньшее время простоя), стоит дороже. Однако менее критические для бизнеса функции (для которых невозможно допустить потерю данных, но есть возможность потратить 24 часа на восстановление сервиса), будут ранжированы соответствующим образом, и их защита будет стоить дешевле. В случае, когда невозможно допустить ни минуты простоя, потребуется другое (еще более дорогое) решение.


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


5. История резервного копирования - эволюция GRID-вычислений
Первый носитель для хранения данных был применен около 200 лет назад - это были перфокарты. В 1960-х они были заменены магнитной лентой. Тогда одна кассета ленты могла хранить данные с 10 000 перфокарт, что обеспечило ей большой успех и сделало основным хранилищем компьютерных данных до середины 1980-х годов.
Благодаря появлению протокола TCP/IP и последовавшего за ним публичного Интернета, сети передачи данных начали расти экспоненциально. Если обратить внимание на развитие современных сетей и их пропускную способность, будет очень легко настроить репликацию для создания мощного решения, поддерживающего непрерывность бизнеса. В дальнейшем репликация позволит получить преимущество от резервного копирования в реальном времени (причем в удаленный сегмент сети), без потерь данных и без создания лишних дубликатов на резервной площадке. С другой стороны, применяющиеся технологии, не должны замедлять работу серверов, поэтому требования к сохранению параметров ввода/вывода являются основными при реализации решения по поддержке непрерывности бизнеса. Технология репликации должна просто обеспечивать контроль работы серверов и отслеживать изменения со времени создания последнего слепка файловой системы (snapshot). В результате система не должна нагружать рабочие серверы, обеспечивая удаленное резервное копирование без привлечения курьеров и перегрузок каналов, избегая рамок <окна резервного копирования>, решая проблему копирования открытых файлов и т.д.

6. Катастрофоустойчивость и облачные вычисления
Централизованное резервное копирование является только часть вопроса. Решение должно помогать бизнесу быстро возобновлять операционную деятельность в случае катастрофы. Это значит, что данные должны быть не только защищены, но и готовы вернуться на серверы. Следовательно, в идеальном варианте, работающие образы операционных систем должны быть адаптированы для запуска на различном оборудовании и/или на автоматически управляемых виртуальных серверах. В данном случае модели облачных вычислений и виртуализации позволяют легко решить вопрос выделения ресурсов по требованию.

Множество бизнесов сегодня уже внедрили катастрофоустойчивое решение и зачастую используют конфигурации оборудования <один к одному> для восстановления после катастроф, что стоит значительных средств. Причина в том, что старые технологии в значительной степени зависели от аппаратного оборудования, однако теперь это уже не так важно. Растущее значение <зеленых> IT-технологий и экономии электроэнергии приводят к тому, что традиционные инструменты катастрофоустойчивых решений оказываются избыточными: в реальности не требуется постоянной работы систем, если они не используются напрямую.

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

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

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

Независимость от платформы

Внедренное решение не должно оказывать воздействие на существующее окружение. Например, не должно быть таких ситуаций, когда стратегия построения катастрофоустойчивой системы требует замены аппаратных платформ или элементов инфраструктуры. Это означает, что в идеале решение должно быть основано на программных алгоритмах и не должно зависеть от конкретной аппаратной или виртуальной платформы. Этот вопрос часто не учитывается, когда выбор падает на аппаратное решение, которое требует инвестиций, не обеспечивая гибкость для дальнейших изменений.
Восстановление после отказа и его предотвращение
<Обход отказа> подразумевает полный перенос нагрузки на удаленные серверы - эта функция практически всегда обеспечивается решениями поставщиков катастрофоустойчивых систем. При этом большинство вендоров не уделяют внимание возможности восстановления после отказа. Решение, позволяющее это сделать, должно обеспечивать возможность восстановления на любые платформы (причем в режиме он-лайн), сохраняя возможность работы для пользователей. Любое катастрофоустойчивое решение должно иметь возможность отката системы, чтобы обеспечить операционное восстановление систем.

8. Воздействие внедрения и управление изменениями системы
Слишком много представленных на рынке решений требуют изменений инфраструктуры: <Вы должны приобрести систему SAN, чтобы изменить принцип хранения данных>, <Вы должны виртуализировать всю сеть>, <Вы должны изменить конфигурацию серверов>. Воздействие на инфраструктуру при внедрении таких систем повышает и риски, и стоимость. Современное катастрофоустойчивое решение не должно требовать изменения сети при внедрении и реконфигурирования серверов.
Владельцы бизнеса должны следить за тем, чтобы масштабируемость и гибкость катастрофоустойчивого решения позволяли пользоваться ими и в будущем. Так как сам бизнес динамично меняется, IT-инфраструктура должна поддерживать его в любом виде. Если же внедряется решение, требующее фиксации инфраструктуры в определенном состоянии (особенно если речь идет о приложениях и их версиях), оно повысит операционные расходы и создаст риск неработоспособности в том случае, если катастрофа действительно случится. Катастрофоустойчивое решение должно обеспечивать защиту систем независимо от аппаратных и программных платформ, предоставляя возможность истинного восстановления: в зависимости от требований времени - на тот же сервер, на новую платформу или в облачном окружении.

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

10. ПО, но не аппаратные платформы - оптимизированная загрузка

Если требуется синхронная репликация (например, данные записываются на резервную систему до записи на основную), то нет необходимости внедрять массивы SAN.

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



11. Решение для конкретных задач - CAPEX и OPEX
Принимая решение о внедрении системы, необходимо уделить внимание следующему списку ключевых особенностей:
CAPEX

OPEX

Стоимость внедрения и обучения

Облачные ресурсы и стоимость другой подписки в резервном центре

Требования к изменению инфраструктуры (инвестиции в новое оборудование) и влияние на производительность

Стоимость канала

Управление изменениями

Стоимость электроэнергии и кондиционирования

Стоимость расширения каналов (если требуется)

Стоимость инженерной поддержки катастрофоустойчивой системы, включая установку обновлений, мониторинг и регулярное тестирование

Независимое от платформы восстановление

Поддержка аппаратных средств и ПО

Стоимость оборудования резервного центра



Стоимость лицензий на ПО для резервного центра




Другие ключевые элементы

• Возможность соответствия RPO/RTO независимо от платформы

• Возможность корпоративного мониторинга и отчетности

• Простой процесс активации системы защиты (одним кликом или автоматически), удаленный доступ для пользователей (через сеть/с использованием терминалов/через контроллеры домена)

• Локальная поддержка, сертификация и узнаваемость решения (оно должно быть проверенным и надежным)