• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Аварийное восстановление из облака

Новый тренд, обозначившийся на рынке решений обеспечения непрерывности бизнеса, – аварийное восстановление из облака. Какие преимущества оно дает и какие подводные камни таит?

Облако поможет поспеть за бизнесом

Несмотря на то что первая ассоциация с решением аварийного восстановления (disas-ter recovery) из облака, как правило, техническая, начинать разработку проекта создания такой системы следует не с ИТ-составляющей, а с анализа потребностей заказчика. Ему же в первую очередь нужно, чтобы в случае аварии на основной площадке (в ЦОДе, офисе, на узле связи) деятельность компании автоматически восстановилась – полностью или частично, но в заранее оговоренном режиме.

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

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

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

Существует множество вариантов реализации disaster recovery в облаке. Какой из них выбрать, зависит от разных факторов: требований к скорости восстановления, актуальности восстановленных данных и т.д. Причем выбор необязательно должен быть сделан раз и навсегда: можно начать с простого варианта и постепенно развить его до самого «продвинутого».

Простейший вариант решения аварийного восстановления – обеспечение копирования данных на удаленной площадке. В этом случае значения RTO и RPO велики. Нужно понимать, что резервное копирование – процесс периодический, а не непрерывный. Это значит, что если резервная копия формируется один раз в 24 часа, то RPO тоже составляет сутки. А если основные ИТ-системы окажутся полностью разрушенными, в RTO будет входить не только время восстановления данных с резервной копии, но и время на воссоздание самих ИТ-систем. Тогда RTO может составить несколько месяцев, что, конечно, неприемлемо. Поэтому с помощью одного только резервного копирования создать полноценное решение аварийного восстановления вряд ли получится. То, что мы называем облачным резервным копированием – Backup as a service (BaaS), – обычно является составной частью disaster recovery. BaaS обеспечивает копирование данных на удаленной площадке с минимальными затратами времени на организационные процедуры. Это первый шаг в построении решения аварийного восстановления.

Второй вариант disaster recovery более масштабный: на резервной облачной площадке создаются вычислительные мощности, которые поддерживаются в режиме готовности. Там выполняются все инфраструктурные настройки, устанавливается программное обеспечение, настраиваются системы безопасности, копируются профили пользователей и т.д. Бизнес-процессы могут туда «переехать»в любой момент. Это предполагает также наличие на резервной площадке копии данных, не сильно «отстающей» от основной.

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

Конечно, между тремя вариантами реализации di-saster recovery, описанными выше, есть промежуточные, и спектр возможностей, которые они предоставляют, весьма широк.

Препятствия и способы их преодоления

Препятствием при организации системы аварийного восстановления часто становятся «проблемные» каналы связи между облаком или ЦОДом, где развернуто решение disaster recovery, и ИТ-инфраструктурой заказчика. Преодолеть это препятствие можно двумя способами. Первый – проложить специальный волоконно-оптический канал. Второй – организовать выделенный канал связи от интернет-провайдера, а еще лучше – от двух.

Вне зависимости от того, каким из способов обеспечивается канал связи, его можно безопасно подвести к облаку. Правда, крупные публичные провайдеры не предоставляют такой технической возможности: они делают упор на стандартизацию сервисов и выделяют только хороший канал публичного Интернета. Конечно, ничто не мешает запустить передачу данных для disaster recovery поверх этого канала, например через VPN-туннель. Однако в этом случае скорость получится слишком низкой, а из-за большого расстояния между системами задержки при передаче будут неизбежны. Важно помнить, что технологии позволяют подводить выделенные каналы связи к публичному облаку в интересах конкретного заказчика. Все ограничения на это – искусственные препятствия, созданные  провайдерами.

Другое препятствие связано со стандартизацией, к которой стремятся облачные провайдеры в погоне за экономической эффективностью. Нередко предложенные варианты стандартизации вступают в противоречие с интересами заказчиков. У одной компании может быть установлена система виртуализации от Microsoft, у другой – от VMware, третьей не важен производитель, но необходим определенный уровень гибкости и т.д. В результате провайдер может оказаться в непростой ситуации: прикладные системы заказчика должны функционировать на таком инструменте виртуализации, которого еще нет в стандартном наборе решений. Однако, как показывает опыт, вполне реально оперативно реализовать сегмент облака на технологиях, которые нужны конкретной компании. Скажем, помимо стандартного виртуализатора RedHat KVM провайдер может предложить решения от Oracle и VMware. Кроме того, надо понимать, что иногда ограничения надуманы и специально вводятся производителями прикладного ПО для продвижения собственных инструментов виртуализации.

Еще один нюанс, который необходимо учитывать при создании disaster recovery в облаке, – неспособность некоторых ИТ-систем работать на гибкой виртуальной платформе. Например, иногда заказчик размещает у провайдера всю свою ИТ-инфраструктуру, в состав которой входит «тяжелая» база данных. У этого решения особенная архитектура, кроме того, оно настолько масштабное, что может эффективно функционировать только на UNIX-системе. В ближайшее время технологии не разовьются до такого уровня, чтобы подобные решения можно было переносить в стандартизированное облако. И даже если столь радикальные изменения все же произойдут, заказчик, скорее всего, не согласится пойти на риск и поменять действующую схему работы. Выход в данном случае – подключить к облаку аппаратные ресурсы, предназначенные для конкретного заказчика.

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