ТРАДИЦИОННЫЙ ПОДХОД К DISASTER RECOVERY
Производители серверов и систем хранения постоянно совершенствуют используемые в этих продуктах средства для предотвращения аппаратных и программных сбоев, их своевременной идентификации и диагностики, а также оперативного устранения таких сбоев. В этой связи можно упомянуть специальные сервисные процессоры, контролирующие состояние оборудования, дублирование основных компонентов системы, функции горячей замены жестких дисков, вентиляторов и блоков питания. Наконец, объединение двух и более серверов в отказоустойчивый кластер позволяет обеспечить продолжение работы приложений даже в случае полного выхода из строя одного из них.
Однако все эти меры оказываются неэффективными, если по каким-то причинам будет остановлен весь центр обработки данных — например, из-за наводнения, пожара или многочасового отключения электричества. Поскольку крупные природные и техногенные катастрофы обычно охватывают целые города или регионы, защитить от них критичные для бизнеса приложения можно одним способом: построить удаленный на десятки или сотни километров резервный ЦОД, чтобы оперативно запустить там приложения в случае подобных ситуаций. В идеале и тот и другой должны быть оснащены одинаковыми серверами и системами хранения данных.
Для перезапуска приложений на сервере резервного ЦОДа требуется объединить его с сервером основного ЦОДа, создав географически распределенный кластер (еще недавно эта функциональность поддерживалась только Unix/RISC-серверами старшего класса и мейнфреймами). Кроме того, для оперативного переключения приложения с основного центра обработки данных на резервный в последнем должны находиться актуальные копии данных нужных приложений, для чего необходимы специальные средства удаленной синхронной и асинхронной репликации, которые используются в дисковых массивах старшего класса (например, EMC Symmetrix SRDF), а также арендованные или собственные высокоскоростные каналы связи, соединяющие обе площадки. Разумеется, из-за больших затрат на создание и эксплуатацию резервного центра обработки данных только самые крупные организации могут позволить себе построить вспомогательную площадку для защиты своих бизнес-критичных приложений от катастроф.
В результате применения виртуализации для консолидации серверных приложений и внедрения частных облаков появилась потребность в новом подходе к защите от катастроф. При классическом способе защита обеспечивалась только для нескольких приложений, основные характеристики которых (требования к производительности сервера и системы хранения) мало менялись со временем. Очевидно, что старые методы Disaster Recovery, ориентированные на физические серверы, нельзя применять к облакам, где могут работать десятки виртуализированных приложений с разными требованиями к вычислительной мощности и емкости. Кроме того, для развернутых в частном облаке приложений нужно обеспечить гибкое выделение ресурсов, а также возможность быстрого запуска новых приложений, в том числе высококритичных и потому нуждающихся в защите от катастроф. Наконец, в большинстве облаков в качестве аппаратной платформы используются серверы стандартной архитектуры, которые не поддерживают классические решения географически распределенных кластеров, разработанные для Unix-систем и мейнфреймов.
.png "Упрощенная схема VMware Site Recovery Manager") |
| Упрощенная схема VMware Site Recovery Manager |
ЗАЩИТА ОТ КАТАСТРОФ ДЛЯ СРЕД VMWARE
Фактическим стандартом современных решений для серверной виртуализации в крупных организациях являются продукты VMware, поэтому неудивительно, что эта компания разработала пакет для обеспечения защиты частных облаков от катастроф. Предназначенное для виртуальных машин VMware vSphere программное обеспечение VMware Site Recovery Manager (номер текущей версии — 6.1) на базе технологии репликации виртуальных машин VMware vSphere Replication и пакета управления виртуальными машинами VMware vCenter Server реализует автоматическое выполнение планов послеаварийного восстановления с использованием заданных правил.
Site Recovery Manager координирует работу vCenter Server, которые обслуживают виртуализированные серверы двух центров обработки данных, поэтому, если по какой-то причине в одном ЦОДе виртуальные машины останавливаются, сразу же запускаются их копии в другом. В плане послеаварийного восстановления определяется порядок выключения и перезапуска виртуальных машин, указываются выделяемые им ресурсы в резервном центре обработки данных и доступные сетевые подключения. Кроме того, планы послеаварийного восстановления можно создавать для отдельных приложений и разных сценариев аварийных ситуаций.
VMware vSphere Replication обеспечивает независимую от СХД асинхронную репликацию на уровне гипервизора с возможностью настройки целевых точек восстановления (RPO) и нескольких точек отката (point-in-time instance). Такой подход позволяет легко конфигурировать виртуальные машины vSphere без привязки к конкретной конфигурации физического сервера, настраивать репликацию на уровне дисков Virtual Machine Disk (VMDK) отдельных виртуальных машин и проводить их гранулярное восстановление.
Помимо «родной интеграции» с vSphere Replication (требуется при использовании программно определяемых систем хранения VMware VSAN), Site Recovery Manager интегрируется с решениями по репликации ведущих производителей дисковых массивов с помощью специальных адаптеров. Его можно применять и для тестирования планов послеаварийного восстановления ключевых приложений без прерывания их работы. Тестирование проводится на временных копиях реплицированных данных и в изолированных сетях, поэтому функционирование рабочих приложений обоих центров обработки данных не нарушается. Кроме того, это решение VMware позволяет осуществлять безопасную миграцию приложений между ЦОДами с помощью пакета vSphere vMotion и перераспределять нагрузку между ними.
.png "Архитектура DRaaS от Amazon Web Services") |
| Архитектура DRaaS от Amazon Web Services |
ПОСЛЕАВАРИЙНОЕ ВОССТАНОВЛЕНИЕ КАК СЕРВИС
При использовании VMware Site Recovery Manager, как и традиционных решений защиты от катастроф, нужен второй резервный центр обработки данных, территориально удаленный от основного. Большинство средних по размеру компаний, ИТ-бюджет которых невелик, не имеют финансовой возможности организовать вторую площадку, но могут внедрить катастрофоустойчивое решение с помощью сервисов Disaster Recovery as Service (DraaS), предлагаемых провайдерами облачных услуг. В модели DraaS роль резервного центра обработки данных выполняет облако провайдера, и в случае аварии на площадке заказчика расположенные в нем виртуальные машины и их приложения быстро перезапускаются.
Сервис VMware vCloud Air Disaster Recovery, который можно рассматривать как аналог VMware Site Recovery Manager для DRaaS, предназначен для аварийного восстановления виртуальных машин VMware vSphere с помощью гибридного облака VMware Air. Как и VMware Site Recovery Manager, он предполагает использование репликации VMware Site Recovery Manager и инструментов управления виртуальной средой vCenter Server и позволяет задавать целевую точку восстановления от 15 мин и до 24 ч, причем можно создавать до 24 точек отката. В нем предусмотрены возможности тестирования плана послеаварийного восстановления для различных сценариев аварий. Подписка на VMware vCloud Air Disaster Recovery обеспечивает защиту до 500 виртуальных машин.
В случае Amazon Web Services (AWS) услуги DRaaS предусматривают три варианта решения: «горячее» (warm), когда целевое время восстановления RTO не превышает одного часа; «холодное» (cold) с RTO от одного рабочего дня; Pilot-Light — промежуточный вариант, при котором время восстановления составляет не более 4 ч. При холодном методе используется традиционное резервное копирование на ленточные картриджи, хранящиеся в защищенном хранилище, при горячем — резервируется вся серверная инфраструктура заказчика, а в варианте Pilot-Light в облаке AWS создается пул ресурсов в минимальной конфигурации, который при необходимости можно быстро развернуть в полной конфигурации для обслуживания приложений заказчика.
Microsoft предлагает в своем облаке Azure восстановление виртуальных машин VMware vSphere и Hyper-V, а также приложений, работающих на физических серверах. В сервисе Azure Site Recovery (ASR) используются функции репликации SQL AlwaysON и Active Directory, обеспечивается сокращение целевой точки восстановления до 30 сек. Клиенты ASR могут выполнять перезапуск своих виртуальных машин в облаке Azure в автоматическом режиме и вручную по команде оператора. После устранения аварии автоматическое возобновление работы виртуальных машин в ЦОДе и обратная репликация производятся автоматически.
Услуги защиты от катастроф с помощью публичного облака доступны и у нескольких российских операторов ЦОДов. Летом компания DataLine развернула сервис DRaaS на базе своего облака CloudLine. С помощью решения для удаленной репликации Veeam Cloud Connect Replication пользователи этого сервиса могут организовать репликацию виртуальных машин в облако CloudLine и настроить переключение на использование тиражированных копий при аварии в своем центре обработки данных. Пока репликация в облако реализована для VMware vSphere, но DataLine планирует вскоре обеспечить защиту и виртуальных машин Hyper-V.
В предлагаемом системным интегратором «Крок» сервисе DraaS, созданном на базе построенного в 2015 году облака Cisco Powered, предусмотрены три варианта обеспечения катастрофоустойчивости:
- перенос виртуальных машин в облако;
- развертывание в облаке новых серверов;
- использование облака как резервного ЦОДа.
Компания IT-Grad в своем публичном облаке реализовала сервис «Резервная площадка» для тех заказчиков, которые либо уже развернули собственную виртуальную инфраструктуру, либо планируют использовать технологии виртуализации на базе VMware vSphere. Отказоустойчивость в этом решении достигается с помощью средств VMware vShpere и VMware vCenter Site Recovery Manager, а также технологий зеркалирования SnapMirror и систем хранения NetApp FAS. Для vSphere Replication целевая точка восстановления RPO составляет от 15 мин до 24 ч, а в случае применения NetApp SnapMirror этот показатель RPO уменьшается почти до нуля.
Обращение к сервисам DRaaS позволяет малому и среднему бизнесу реализовать с помощью облачных технологий защиту от катастроф для своих основных приложений без организации резервного центра обработки данных и применения систем хранения корпоративного класса.
Лев Левин, независимый автор (lan@lanmag.ru)