Планирование процесса аварийного восстановления в облачных сервисах

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

В процессе планирования аварийного восстановления вам необходимо определить так называемое приемлемое восстанавливаемое состояние (acceptable recovery state), до которого необходимо восстановить систему, а затем разработать пошаговые процедуры и способы восстановления этого состояния при ликвидации последствий катастрофы. Говоря о приемлемом восстанавливаемом состоянии, я имею в виду объем данных, который вы можете позволить себе потерять в случае наступления катастрофического события.

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

± Целевая точка восстановления (Recovery Point Objective, RPO)2 — этот показа-

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

1 Планирование и подготовка процессов аварийного восстановления после катастрофических событий является одной из самых горячих тем в отрасли IТ. Читателям, желающим углубленно ознакомиться с данной тематикой и не путаться в различиях между аварийным восстановлением (Disaster Recovery, DR),  планированием  непрерывности  производственного  процесса  (Business  Continuity  Planning, BCP/BC)  и такими вещами,  как высокая  доступность  (High  availability)  и  резервное  копирование (Backups), можно порекомендовать для начала ознакомиться со следующими материалами: http://en.wikipedia.org/wiki/Disaster_recovery, http://www.continuitycentral.com/itdr.htm, http://www.disaster-recovery-guide.com/, http://www.drj.com/, http://msft.ineta.ru/blogs/blogEntrySearch.aspx?tags=failover. — Прим. перев.

2  Фактически представляет собой временную точку, на момент которой будет восстановлено состояние  системы  после  приведения  в  действие  плана  аварийного  восстановления.  Подробнее  см.:

http://en.wikipedia.org/wiki/Recovery_point_objective, http://www.it.ru/press_center/expert/Est_li_u_vas_plan. — Прим. перев.

± Допустимое время восстановления (Recovery  Time Objective,  RTO)1 — этот показатель определяет допустимое время простоя в случае наступления катастрофического события. Если показатель RTO составляет 24 часа, это означает, что промежуток между выходом вашей системы из строя и моментом, когда система должна будет возвращена в полнофункциональное состояние, должен составлять не более 24 часов.

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

Естественно, что абсолютно все предпочтут такой сценарий восстановления работоспособности, при котором не наблюдается никакого простоя и не происходит никаких потерь данных, причем не имеет никакого значения тип произошедшей катастрофы. Однако в реальной жизни природа катастрофического события обычно вынуждает нас согласиться с некоторым уровнем потерь; что-либо другое окажется весьма дорогостоящим. Например, в случае такого бедствия в масштабах целого города, как ураган "Катрина" (Hurricane Katrina)2, стоимость выживания IT- компании, расположенной в Новом Орлеане (80 % площади которого было затоплено), без потери данных и с нулевым временем простоя включала бы стоимость множества физических центров обработки данных, расположенных в разных географических точках и постоянно синхронизирующих информацию. Иными словами, такая компания должна была обладать возможностью иметь не менее двух дублирующих центров обработки данных, соединенных выделенным широкополосным соединением.

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

Определение оптимальных для компании показателей RPO и RTO, в таком случае, представляет собой именно финансовый расчет: необходимо определить, в какой именно момент стоимость потери данных и простоя превысит стоимость поддержания стратегии резервного копирования, которая предотвратит такие потери и

1 Подробнее см. http://en.wikipedia.org/wiki/Recovery_Time_Objective, http://www.trinitygroup.ru/solution/infrastucture/disastrous_accident. — Прим. перев.

2 Ураган "Катрина" — самый разрушительный ураган в истории США, произошедший относительно недавно (в конце августа 2005 года). См. http://hurricane-katrina.org/ Прим. перев.

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

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

Целевая точка восстановления (RPO)

Проще всего начать планирование с определения целевой точки восстановления (RPO). Сценарий развития катастрофических событий по типу "Армагеддон" ведет к полной потере всех системных данных и сборок (binaries) всех приложений, необходимых для работы системы. Ваш показатель RPO лежит где-то в интервале между состоянием вашего приложения на момент его первого развертывания и состоянием, которое оно имело в момент наступления катастрофы. Вы можете также спланировать несколько уровней угрозы катастроф, и для каждого из них определить свой показатель RPO1.

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

Обычно ваш показатель RPO зависит от того, как вы сохраняете данные и выполняете их резервное копирование.

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

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

1 Например, вы можете определить катастрофу первого уровня как потерю одного центра обработки данных, а катастрофу уровня 2 — как потерю двух или большего количества центров обработки данных.

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

± Сетевые системы хранения данных (Network Attached Storage, NAS) и сети хранения данных (Storage Area Networks, SAN)1 могут без потерь пережить потерю любого отдельного сервера, за исключением случаев, когда имеет место повреждение данных.

± Кластеризованная база данных переживет потерю любого отдельного устройства хранения данных или узла базы данных без потери данных.

± Кластеризованная база данных, распределенная по множеству центров обработки данных, переживает потерю любого отдельного центра обработки данных без потери данных.

Далее в этой главе мы поговорим о том, как облачные технологии позволяют минимизировать показатель RPO.

Допустимое время восстановления (RTO)

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

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

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

1 Подробнее см. http://en.wikipedia.org/wiki/Network-attached_storage, http://www.ixbt.com/storage/san.shtml, http://www.nas-central.org/. — Прим. перев.

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

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100