Катастрофоустойчивое решение с использованием IaaS

Решения
01.04.2015
41
10 min

Катастрофоустойчивое решение с использованием IaaS

#draas

Катастрофоустойчивое решение с использованием IaaS

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


Часто катастрофоустойчивое решение (Disaster Recovery Solution) путают с обычной системой высокой доступности. Оба подхода обеспечивают работоспособность приложения в случае проблем с оборудованием или ПО. Но ключевое отличие в допустимом масштабе аварии. К примеру, у вас может быть отличный 16-узловой HA-кластер, но он никак не спасет от затопления помещения или не слишком прямых рук электрика. В то же время DRS-системы могут выжить при масштабном отказе сразу нескольких дата-центров, не парализуя при этом работу приложения на неопределенный срок.

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

Говоря о системах подобного класса, мы обычно подразумеваем резервный ЦОД, который можно использовать для переноса нагрузки из уже неработающего места. Такие «запасные» дата-центры обычно делят на три типа: холодный, теплый и горячий резерв. Разница более-менее улавливается из названия, но на всякий случай приведу сравнительную табличку:


Именно теплый вариант сейчас используется многими компаниями из-за приемлемой стоимости и неплохих временных показателей. Но если задействовать резервную площадку на базе IaaS, то можно получить даже горячий вариант без значительного увеличения бюджета. Давайте рассмотрим такой вариант. Катастрофоустойчивое решение (DRS) в облачной инфраструктуре идейно не особенно отличается от того, что недавно внедрялось для физической серверной. Просто часть проблем отпала сама собой, и появились некоторые новые возможности. Вообще я бы сравнил DRS в облачной среде со строительными кубиками: выбираешь десяток нужных и складываешь по-разному,

пока не получится слово «счастье»

.

Катастрофоустойчивое решение (DRS) в облачной инфраструктуре

В облачном варианте DRS отличается от «олдскульного» подхода следующими моментами:


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

Зачем тут облако

Для любого сценария c резервным дата-центром характерны такие пожелания:



Допустимая точка восстановления (RPO)

Наиболее ощутимы для бюджета второй и четвертый пункт, подразумевающие строительство или аренду ЦОД вне стен родной компании. Более того, потребуется не просто перевезти часть железа в соседнее здание, а обеспечить действительно независимый подвод WAN и должный уровень надежности серверного помещения и инфраструктуры. В общем, на этом этапе «отваливаются» многие заказчики. Для частичного решения вопроса человечество когда-то придумало сдавать «юниты» в подготовленном ЦОД. А с приходом виртуализации построение инфраструктуры из сотен выделенных серверов требовало от провайдера неизмеримо меньших денежных вливаний. Как следствие — подобные услуги стали дешевле и для конечного заказчика. Фактически мы получаем IaaS, самую популярную разновидность

корпоративного облака

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

Запасной аэродром из vSphere

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

vSphere SRM

(Site Recovery Manager).

SRM (Site Recovery Manager) — это решение для автоматизации всего процесса восстановления VM на резервной площадке. Это не готовое DR-решение, а менеджер для координации сразу нескольких отдельных систем (гипервизоры, хранилища, сети).

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







Любую из этих схем можно частично или полностью построить на базе облака, что позволит получить максимально дешево такие возможности:


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


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

Непростые вопросы репликации

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


Что из этого выбрать? Хороший вопрос, но в общем случае рекомендуется гибридный вариант. В нем вы выделяете datastore с аппаратной репликацией наиболее важных VM, а все остальные защищаете механизмом vSphere Replica, который допускает работу с более дешевыми СХД. Приятным бонусом от устройств с аппаратной репликацией будут также фирменные технологии снэпшотов, теневые тома и прочие полезности. В связи с популярностью систем хранения NetApp на отечественном рынке, рассмотрим именно их в качестве основного хранилища для DRS.

NetApp SnapMirror

Это и есть встроенный механизм репликации в массивах NetApp. Кроме привычных синхронной и асинхронной репликации, SnapMirror предлагает несколько интересных особенностей:






FlexClone

В описании SRM я упоминал о возможности использовать резервный сайт для чего-то полезного в быту. Например, для тестирования масштабных изменений на серверах. Фактически SRM создает изолированную лабораторию с собственным LUN, на котором

уже

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

FlexClone

.

FlexClone

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


На дисках клон займет ровно столько места, на сколько потянут Write-изменения

На дисках клон займет ровно столько места, на сколько потянут Write-изменения



Согласитесь, это гораздо интереснее ручного восстановления резервных копий VM на виртуальных машинах стенда с самостоятельной настройкой сети. Вообще у NetApp много интересных технологий для работы со снимками и копиями томов, но не все они вписываются в тему этой статьи. Что ж, пора подводить итоги. Мы обсудили преимущества работы с IaaS-облаком в качестве резервной площадки и оценили его гибкость. При использовании vSphere SRM и современных систем хранения катастрофоустойчивые системы уже не выглядят чем-то «для избранных». Вне зависимости от возможностей вашей сети хранения и уровня надежности дата-центра, благодаря облачным услугам можно застраховать бизнес организации от серьезных потерь. Но лучше один раз попробовать, чем много раз прочесть, как все это красиво, верно? Потому напоминаю про наш тестовый полигон, где вы можете оценить возможности облачной vSphere и

опробовать интересующие сценарии организации резервной площадки в облаке

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



V.Sinitskiy
Профильный эксперт