С каждым годом бизнес становится, все более зависим от различных ИТ-систем и сервисов. Приостановка работы приложения или сайта, даже на несколько часов, может привести к катастрофическим финансовым убыткам. Именно поэтому разрабатываются и внедряются все новые инструменты и решения, направленные на повышение надежности ит-инфраструктур, как на аппаратном, так и программном уровне. Но что делать, когда предприятию нужна не просто надежность, а стопроцентная гарантия возврата сервисов в строй, даже в случае наводнения или пожара? Ответ прост – необходимо сделать свою инфраструктуру катастрофоустойчивой. В данной статье мы рассмотрим варианты построения систем аварийного восстановления (DRS - Disaster Recovery System) в виртуальной среде VMware, которые могут обеспечить функционирование критичных для бизнеса приложений даже в случае полного уничтожения оборудования.
Географическое распределение
Разумеется, основным условием для обеспечения катастрофоустойчивости ИТ-инфраструктуры является ее географическое распределение. Для этого должна быть организована дополнительная площадка с оборудованием, на котором, в случае падения основного сайта, будет запущена его точная копия. Для того чтобы обеспечить максимальный уровень безопасности, такую площадку необходимо разместить как можно дальше от основной, чтобы исключить возможность влияния чрезвычайной ситуации на обе локации. Другими словами, запасное серверное помещение не стоит устраивать в том же здании, где находится основное.
Репликация – основа основ
Для того чтобы, в случае аварии, данные на второстепенной площадке были актуальными и полностью были синхронизированы с основным сайтом на момент отказа систем, между ними настраивается процедура репликации.
Репликация бывает двух видов, синхронная и асинхронная, а также может быть реализована на программном или аппаратном уровне.
Синхронная репликация означает, что данные сразу же после изменения на основном сайте, будут изменены и на запасном. Это гарантирует наличие только одной версии данных в одно и то же время. Стоит отметить, что для реализации этого типа репликации необходимо очень быстрое и надежное сетевое соединение. При возникновении даже самых незначительных проблем с пропускной способностью канала связи, такая репликация просто остановится.
При применении асинхронного метода репликации, данные будут записаны на страхующую площадку спустя некоторое время. Такой тип репликации гарантирует приемлемый уровень идентичности данных, но при этом значительно менее требователен к параметрам канала связи.
Тут стоит отметить, что тип репликации необходимо выбрать еще на этапе планирования, так как от этого будет зависеть не только стоимость решения, но и территориальная удаленность запасной площадки. Ведь чем дальше оборудование будет находиться, друг от друга, тем больше будет задержка при передаче данных.
Необходимо учесть, что репликацию данных ни в коем случае не стоит рассматривать в качестве резервного копирования. Дело в том синхронизация означает, что при удалении или порче информации на основной площадке с оборудованием, она в таком же виде попадет на резервную.
Disaster Recovery в среде VMware
Для обеспечения катастрофоустойчивости инфраструктуры выстроенной на базе виртуализации VMware существует два основных инструмента.
SRM (Site Recovery Manager) – это само распространенное решение для обеспечения непрерывности бизнеса в виртуальной среде VMware. Данный инструмент работает на основе Array-based replication, то есть репликации на уровне массива. Другими словами синхронизация данных обеспечивается возможностями СХД. Это решение включает в себя возможности плановой миграции ВМ, аварийной миграции ВМ, а также тестирования планов восстановления ВМ. Существует несколько условий для реализации данного решения:
- Оба сайта (основной и резервный) должны иметь одинаковые версии vCenter и SRM
- Между сайтами должна быть настроена сеть с высокой пропускной способностью
- СХД на резервной и основной площадке должны поддерживать функцию аппаратной репликации
- Резервная площадка должна иметь доступ к сетям, доступным на основной площадке
Ну, и разумеется, резервный сайт должен обладать необходимыми ресурсами для того чтобы принять на себя нагрузку в случае аварии.
SRM может также быть настроен на нескольких площадках, и тогда будут доступны дополнительные типы восстановления:
many-to-one – Несколько сайтов используют для восстановления одну площадку
many-to-many – Несколько основных и несколько резервных площадок
one-to many – Один сайт имеет несколько площадок для восстановления
Для того чтобы построить решение SRM, необходимо проделать глобальную подготовительную работу и потратить значительные финансовые средства на оборудование и ПО. Но в обмен на это, предприятие полусает многофункциональный и гибкий инструмент, позволяющий, при правильной настройке, реализовать практически стопроцентную отказоустойчивость. При возникновении аварии, администратор заходит на веб интерфейс резервной площадки и, нажатием одной кнопки запускает заранее настроенный план восстановления. Весь процесс занимает ровно столько времени, сколько длится загрузка ВМ. При восстановлении работоспособности основной площадки, процесс можно запустить в обратном направлении.
vSphere Replication – данный инструмент является бесплатным и входит практичеки во все редакции vSphere. Тут все гораздо проще и примитивнее, репликация происходит на уровне гипервизора, за счет чего считается менее надежной. При этом большая часть процессов восстановления требует ручного вмешательства и последующей настройки, например восстановленные ВМ не имеют сетевых подключений. Это позволяет значительно сэкономить средства и время на внедрение решения, но при этом увеличивается время восстановления, а также надежность.
vSphere replication не требует каких то специальных условий и не зависит от типа массива, поэтому внедрение обычно происходит быстро и без существенных затрат.
Облачные решения катастрофоустойчивости
Так как географическое распределение ИТ-инфраструктуры является основным требованием к развертыванию систем аварийного восстановления, то вполне логично использовать для этого облако.
Крупные компании, которым нужно максимально обезопасить свои бизнес-критичные приложения, и исключить время их простоя, обычно выбирают поставщиков услуг, предоставляющих DraaS (Disaster Recovery as a Service). Такие проекты обычно являются глобальными и дорогими, а на их настройку и запуск уходит довольно много времени. Основным инструментом в этом случае является использование SRM.
Средние и небольшие компании, которые хотят реализовать непрерывность работы одного или двух сервисов, чаще всего самостоятельно настраивают систему аварийного восстановления, используя для этого арендованные ВМ облачного провайдера. Для этих целей идеально подходит vSphere Replication. Таким образом, за вполне разумные деньги заказчик получает страховку для бизнеса, на случай глобальных аварий.
Заключение
Современные технологии позволяют выстроить систему аварийного восстановления различного уровня и для любых компаний. Основная задача при выборе подхода к обеспечению непрерывности бизнеса, правильно все взвесить и посчитать. Перед тем как внедрять DRS, необходимо понять насколько остановка того или иного сервиса повлияет на бизнес, и правильно расставить приоритеты.
