Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки – его можно успешно использовать в качестве резервной!
С развитием облачных технологий все большее количество организаций готовы отказаться от собственной инфраструктуры в пользу высокодоступных сервисов по размещению виртуальных машин в публичном облаке.
Однако остаются ситуации, обусловленные спецификой деятельности компании, наличием уже осуществленных проектов по построению приватного облака, специфическими требованиями по производительности, безопасности и т.п., которые, возможно, временны, но не дают возможности воспользоваться публичным облаком для хостинга своих ИТ-сервисов.
Существует ли техническая возможность разместить резервную площадку в публичном облаке? С какими трудностями придется столкнуться при реализации проекта? Такие вопросы все чаще возникают как на просторах сети, так и у потенциальных потребителей облачных услуг. Сервис-провайдеры добавляют к этому вопросы про multi-tenancy, про эффективность использования ресурсов, про совместимость и про требования к сетевой инфраструктуре.
Классические DRS решения
Классические решения по созданию резервных площадок или Data Recovery сайтов всегда поражали воображение обывателя своей сложностью. В первую очередь это касалось репликации данных, которая должна была осуществляться средствами СХД, что, в свою очередь:
- сильно повышало планку требований к возможностям СХД,
- накладывало ограничения на выбор производителей СХД для обеспечения совместимости,
- требовало покупки дорогостоящих лицензий.
Да и само ПО для управления резервированием и восстановлением имело (и имеет на настоящий момент) существенную стоимость. Яркий пример такого решения – VMware Site Recovery Manager. Однако технологии не стоят на месте, и возрастающая конкуренция на рынке вынуждает производителей открывать новые возможности для решения старых проблем.
Новый подход – репликация на уровне гипервизора
Одной из таких новых возможностей стала технология VMware vSphere Replication, дебютировавшая в составе VMware Site Recovery Manager версии 5.0, а затем включенная в состав платформы виртуализации vSphere 5.1, причем бесплатно и практически во все редакции!
Данная технология обеспечила возможность репликации данных между сайтами на уровне гипервизора, без использования специальных возможностей СХД. И практически сразу возник интерес компаний, имеющих собственные виртуальные инфраструктуры на базе vSphere, к потенциальной возможности организовать резервную копию своих информационных систем «малой кровью».
Но отвязка от СХД дала не только удешевление и упрощение систем репликации – она дала важную возможность осуществления репликации между «несогласованными» по СХД и независимо управляемыми инфраструктурами. И, фактически, открыла дорогу к простой и эффективной реализации резервной площадки в облаке.
Технология vSphere Replication
Технология vSphere Replication с точки зрения пользователя очень проста. Изменения, вносящиеся в диски виртуальных машин на основной площадке, отслеживаются гипервизором, а затем в соответствии с заданными политиками RPO (Recovery point objective) периодически синхронизируются с резервным сайтом. При этом синхронизацией управляют служебные виртуальные машины VR Appliance, расположенные в обоих сайтах, а данные между сайтами передаются от гипервизора на основном сайте к VR Appliance на резервном.
При этом данная технология доступна как рядовым пользователям платформы vSphere для организации репликации данных с ручным управлением, так и в составе Site Recovery Manager, позволяющим гибко управлять процессом failover-а и giveback-а, с соответствующей автоматизированной перенастройкой сети, проведением периодического неразрушающего тестирования и т.п.
Использование vSphere Replication на практике
Когда к нам в компанию обратился очередной клиент с предложением организовать резервную площадку, с момента выхода vSphere 5.1 прошло менее месяца. Но практически сразу такая технология репликации стала основным вариантом, рассматривавшимся в данном проекте.
Использование vSphere в качестве платформы виртуализации с обеих сторон, различия в используемых СХД – все это определило выбор технологии репликации, а отсутствие бизнес-необходимости реализации автоматического failover-а позволило обойтись без дополнительных затрат на использование SRM.
Первым этапом проекта стало формирование и реализация схемы сети, обеспечивающей защищенную и быструю передачу реплицированных данных по выделенным каналам, а в случае failover-а – безболезненный переход пользователей на работу с резервной площадкой.
Организация каналов была осуществлена на базе провайдера, уже предоставлявшего клиенту услуги по объединению филиалов на базе «виртуального свича», к которому был добавлен новый линк к сервис-провайдеру, для обеспечения маршрутизации и «встройки» резервной площадки в имеющуюся инфраструктуру заказчика.
При функционировании репликации (прямой или обратной) в такой схеме траффик при помощи роутеров направляется на площадку сервис-провайдера или в головной офис клиента, в случае failover-а на площадках клиента изменяются шлюзы на серверные сети клиента, в которых расположены виртуальные машины. Таким образом, вся инфраструктура оказывается работающей на площадке сервис-провайдера без переконфигурации сети на виртуальных машинах.
Вторым этапом проекта стала настройка и тестирование самой vSphere Replication применительно к данной задаче. Надо сказать, что технология, которая пережила по сути уже второй свой релиз, успешно функционирует «из коробки», в стандартных конфигурациях. Однако специфика данного внедрения – независимые инфраструктуры с обеих сторон репликационного «линка», необходимость разграничения прав пользователей в инфраструктуры сервис провайдера — потребовала значительное время провозиться с настройками и даже провести некоторые изменения в инфраструктуре, обеспечивающие возможность функционирования ранее неиспользовавшейся технологии.
В ходе тестирования внимание уделялось не только функциональному тестированию схемы, но и нагрузочному тестированию на реальных данных – требовалось гарантировать соблюдение RPO при выбранной ширине канала. В результате было принято решение расширить ранее сконфигурированный на 100Мбит канал до 1Гбит для обеспечения запаса по скорости репликации при проведении регулярных maintenance операций на серверах клиента – например, переиндексированиях и перестройках БД, генерирующих повышенный объем изменений.
Третьим и финальным этапом проекта стала первоначальная репликация более 10ТБ данных на площадку сервис-провайдера и запуск системы в промышленное использование. При этом для проведения периодического тестирования возможности восстановления инфраструктуры была создана дополнительная схема маршрутизации, при которой работу с поднятой в частной сети, расположенной у сервис-провайдера, инфраструктурой осуществляет только искусственная группа пользователей.
Заключение
Возможна ли организация резервной площадки в облаке в настоящее время?
Принципиальный ответ – да, возможна.
Пока еще клиентам приходится считаться с некоторыми допущениями – с неполным соответствием таких решений идеологии «облачности» — например, с недостаточной эластичностью и необходимостью использования службы поддержки сервис-провайдера вместо self-service интерфейсов в части случаев. Сервис-провайдерам в свою очередь приходится считаться с ограниченной применимостью технологий в multi-tenant окружении, пока еще существуют ограничения по совместимости различных платформ виртуализации.
Однако мир не стоит на месте, и за первым проектом обычно следуют новые, и при поддержке вендоров, уверен, практика организации резервных площадок в облаке в скором времени станет повсеместной.
