Мы много писали о возможностях продукта для резервного копирования и восстановления виртуальной и физической инфраструктуры NAKIVO Backup and Replication. Мы подробно разбирали его возможности, средства защиты от вредоносного ПО, а также решения для бэкапа и восстановления приложений. Сегодня мы поговорим о том, как использовать продукт для аварийного восстановления инфраструктуры после больших сбоев и аварий.
Резервное копирование виртуальной инфраструктуры - это только одно из мероприятий, которое следует выполнять для ее полноценной защиты. Очевидно, что от единичного сбоя виртуальной машины или физического сервера вас защитят процедуры восстановления из резервной копии, а вот при массовом сбое или аварии (затопило этаж, сломалось блейд-шасси и т.п.) нужен план восстановления, обеспечивающий как требования к контрольной точке восстановления (RPO), так и требования ко времени восстановления (RTO), от которого зависит способность компании продолжать бизнес.
Ключевыми функциями в этом процессе являются оркестрация (Orchestration), которая подразумевает выполнение операций восстановления по строго определенному плану, а также автоматизация (Automation), что предполагает исполнение плана аварийного восстановления в полностью автоматическом режиме после нажатия кнопки оператором. Важно, что инициирование Disaster Recovery плана происходит вручную оператором, так как это очень затратная и сложная процедура, вносящая серьезные изменения в инфраструктуру, но само выполнение шагов после этого идет полностью автоматически.
Реальность такова, что если в большой инфраструктуре вы потеряете свои данные, то только 6% могут успешно восстановить их, а в остальных случаях компании придется закрыться в промежутке 2 лет:
Сейчас большие компании используют географически разнесенные датацентры, чтобы обеспечить защиту данных на уровне зданий и городов, а также применяют гибридные облачные среды (комбинация собственного ЦОД и облака сервис-провайдера) в целях повышения доступности сервисов для конечных пользователей, а также защиты от аварий и катастроф. Еще одно преимущество использования таких датацентров - это follow-the-sun и follow-the-moon стратегии, которые позволяют улучшить качество сервиса и снизить затраты.
Стоимость простоя при аварии в среднем по миру обходится в следующие суммы:
Малый бизнес - $8 580 в час
Средний - $215 637 в час
Крупный - $686 250 (несколько часов обходятся дороже купленных лицензий на продукт и железо для обеспечения катастрофоустойчивости)
А если учесть, что средняя продолжительность простоя при аварии составляет 18 часов, то можно сказать, что технически она может убить почти любой бизнес, который сильно зависит от работы ИТ-систем и доступности данных. Поэтому на каком-то этапе внедрять DR-решение нужно, вопрос только в затратах, которые компания готова понести.
Решение NAKIVO Backup and Replication позволяет комбинировать техники резервного копирования и репликации совместно с Disaster Recovery функциями, что не требует затрат на дополнительное ПО (но в железо для резервной площадки и каналы коммуникации придется все равно вложиться). Тут надо еще отметить, что решения NAKIVO предназначены для компаний любого масштаба, а значит вам не придется тратиться на новые продукты по мере роста инфраструктуры.
Итак, как в общем случае работает схема аварийного восстановления NAKIVO B&R:
Остановка виртуальных машин VMware или Hyper-V, а также инстансов в облаке EC2
Выполнение операций по восстановлению (Failover) или обратному восстановлению (Failback) для ВМ
Запуск задач по восстановлению данных, созданных в NAKIVO Backup & Replication
Выполнение кастомных специфических сценариев для ИТ-систем
Размонтирование и монтирование хранилищ данных
Отсылка администратору писем о завершении задач
Ключевая особенность NAKIVO здесь в том, что работа с задачами Site Recovery построена очень просто, все операции производятся в несколько кликов в графическом интерфейсе. Вот несколько примеров простого и универсального подхода, реализованного в продукте:
Вы можете настроить решение так, чтобы задача Site Recovery проверяла доступность ваших ВМ каждый час и оповещала о возможных проблемах.
Вы можете настроить задачу Site Recovery таким образом, чтобы она реагировала на небольшие аварии, например, путем миграции ключевых нагрузок в DR-локацию, после чего посылала письмо об успешном ее завершении.
Можно создать многоуровневую задачу Site Recovery для обработки сложных ситуаций, когда нужно учитывать возможные последствия аварии. Например, можно остановить некоторые текущие задачи (например, репликацию), выполнить кастомные скрипты, дать возможность что-то донастроить администратору (например, присоединить репозитории) и запустить процесс дальше.
При создании DR-плана нужно учитывать следующие аспекты его реализации:
Определите масштаб процедуры - какие ВМ и сервисы стоят в самом высоком приоритете и должны быть восстановлены первыми.
Определите ваше RPO (требования к контрольной точке восстановления) - на это влияет, какое количество данных во времени вам нужно реплицировать на резервную площадку.
Определите RTO (требования ко времени восстановления) - функции Site Recovery в NAKIVO Backup & Replication позволяют задать RTO и узнать, позволяет ли текущая инфраструктура резервирования обеспечить его.
Определите ресурсы резервной инфраструктуры - вам потребуются ресурсы RAM и CPU для размещения виртуальных машин, нужно понять, где будут находиться реплики ВМ, а также четко представлять, как будет работать сеть после восстановления ВМ.
Разработайте регламент тестирования процедуры восстановления - очень важно не только создать DR-план, но и регулярно проверять его в тестовой среде. Особенно это важно, когда шаги по восстановлению включают в себя сложные процедуры и кастомные операции.
Помните, что первый шаг создания инфраструктуры аварийного восстановления - это настройка репликации на резервную площадку. Только после того, как реплики будут созданы, вы можете начинать создавать DR-план.
Давайте посмотрим, как выглядит процесс создания задачи репликации в целях Site Recovery в NAKIVO Backup & Replication:
Мастер задачи репликации проведет вас по всем шагам настройки процесса - это не сложно. Главное - это правильно настроить хранилища данных для реплик, помните, что они в случае аварии возьмут на себя продуктивные ВМ с большой нагрузкой на системы хранения.
Вторая важная часть - это отображение IP-адресов (Network Mapping), чтобы на резервной площадке виртуальные машины "вписались" в инфраструктуру с другой схемой адресации. В процессе исполнения плана аварийного восстановления переназначение IP-адресов происходит автоматически, в соответствии с преднастроенными правилами.
При создании плана Site Recovery вы можете создать несколько задач. Как говорилось выше, можно сделать задачу для небольшого сегмента наиболее критичных систем, а можно восстановить всю инфраструктуру целиком. Также, например, можно сделать отдельную задачу мониторинга доступности вашей виртуальной инфраструктуры, которая тестирует ее каждые 5 минут и посылает письмо администратору в случае аварии.
Также, в отличие от других решений, NAKIVO Backup & Replication имеет расширенный функционал при настройке шагов аварийного восстановления. Например, вы можете в рамках одного из шагов погасить некритичные виртуальные машины на резервной площадке, чтобы важные виртуальные машины, которые туда переедут, получили больше вычислительных ресурсов.
Для того, чтобы все шаги работали согласованно у NAKIVO есть механизм Action Options. При выполнении каждого шага вы можете задать поведение системы в рамках DR-плана:
Run this action in - эта опция определяет, нужно ли выполнять это действие только в производственном режиме восстановления, либо только во время тестирования, либо в обоих случаях.
Waiting behavior - вы можете решить, нужно ли ожидать какое-то время перед запуском следующего шага, чтобы текущая задача завершилась.
Error handling - эта опция регулирует обработку ошибок, которые могут возникнуть в процессе плана аварийного восстановления.
Также можно задать не только план аварийного восстановления (Failover), но и план восстановления инфраструктуры обратно (Failback) для случая, когда работа основной площадки будет восстановлена.
Ну и вы можете задать тип плана - тестовый или производственный, а также определить расписание для регулярного исполнения тестового плана:
После исполнения тестового плана администратор получит на почту отчет о выполненных и невыполненных шагах, что позволит понять наиболее узкие места плана, а также донастроить его, чтобы он работал как часы.
Если вы исполняете тестовый план, то по окончании процедуры Failover будет проведена процедура обратного восстановления (Failback), чтобы привести инфраструктуру в исходное состояние. Ну и удобно то, что восстановление продуктивных систем будет проводиться в изолированный сегмент сети, чтобы не задеть производственные процессы компании.
Есть 2 типа полноценного аварийного восстановления:
Planned Failover - этот метод используется для штатного восстановления систем, когда вы знаете о том, что с основной площадкой что-то случится. Например, вам сказали, что электричество в датацентре отключится через 30 минут.
Emergency Failover - эта операция выполняется в ситуации непредсказуемой аварии. В этом случае все процедуры будут проводиться как можно быстрее, без финальной синхронизации данных при переключении на резервную площадку, чтобы обеспечить требуемый показатель RTO.
При восстановлении в рамках производственного рабочего процесса автоматического Failback не произойдет - для этого вам потребуется создать отдельную задачу. Для Failback вам потребуется предварительно создать задачи обратной репликации, чтобы потом переключиться обратно на бывшую основной площадку. Кстати, восстановление данных вы можете провести и в другую локацию. Например, ваша основная площадка потеряна навсегда или выводится из эксплуатации, а ваши продуктивные нагрузки переезжают в облако.
Скачать бесплатную версию решения NAKIVO Backup & Replication вы можете по этой ссылке.
RSS
