Защита виртуальных машин, развернутых в Azure Stack Hub

  • Статья
  • Чтение занимает 9 мин

Эту статью можно использовать как руководство по разработке стратегии защиты данных и аварийного восстановления для развертываемых пользователем виртуальных машин IaaS в Azure Stack Hub.

Чтобы избежать потери данных и длительных простоев, реализуйте план резервного копирования и восстановления или план аварийного восстановления для пользовательских приложений и данных. Каждое приложение должно оцениваться как часть комплексной стратегии непрерывности бизнес-процессов и аварийного восстановления (BC/DR) вашей организации. Хорошей отправной точкой является технический документ Azure Stack Hub: Considerations for business continuity and disaster recovery (Рекомендации по обеспечению непрерывности бизнес-процессов и аварийного восстановления в Azure Stack).

Рекомендации по защите виртуальных машин IaaS

роли и обязанности.

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

Пользователи отвечают за защиту своих виртуальных машин. Операторы отвечают за поддержание работоспособности и подключения к Интернету Azure Stack Hub. Azure Stack Hub содержит службу, которая выполняет резервное копирование внутренних данных службы из служб инфраструктуры, но не содержит данных пользователей, включая созданные пользователями виртуальные машины, учетные записи хранения с данными пользователей или приложений, а также пользовательские базы данных.

Владелец (архитектор) приложения Оператор Azure Stack Hub
  • Сопоставление архитектуры приложения с принципами разработки в облаке.

  • Обновление традиционных приложений по мере необходимости для подготовки к использованию в облачной среде.

  • Определение допустимых значений RTO и RPO для приложений.

  • Выявление ресурсов приложений и репозиториев данных, для которых требуется защита.

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

  • Развертывание достаточного числа экземпляров Azure Stack Hub в соответствии с целями организации, касающимися непрерывности бизнес-процессов и аварийного восстановления.

  • Разработка и эксплуатация инфраструктуры защиты данных и приложений.

  • Подготовка управляемых решений или методов самообслуживания для служб защиты.

  • Взаимодействие с владельцами (архитекторами) приложений для понимания структуры приложений и рекомендации стратегий защиты.

  • Организация резервного копирования инфраструктуры для восстановления служб и облака.

Комбинации исходного и целевого объектов

Пользователи, которым требуется защита от сбоев центра обработки данных или сайта, могут использовать второй экземпляр Azure Stack Hub или платформу Azure для поддержки высокого уровня доступности и (или) быстрого восстановления. При наличии первичного и вторичного расположений пользователи могут развертывать приложения в двух средах одновременно в конфигурации "активный — активный" и (или) "активный — пассивный". Для менее критически важных рабочих нагрузок пользователи могут применять ресурсы во вторичном расположении для восстановления приложений из резервной копии по запросу.

В центре обработки данных можно развернуть одно или несколько облаков Azure Stack Hub. Чтобы избежать катастрофического сбоя, развертывание по крайней мере одного центра Azure Stack концентратора в другом центре обработки данных гарантирует отработку отказа рабочих нагрузок и сократит незапланированное время простоя. Если вы используете только один экземпляр Azure Stack Hub, следует применить общедоступное облако Azure в роли облачной платформы для аварийного восстановления. Выбор доступных расположений для работы приложения определяется государственными регламентами, корпоративными политиками и строгими требованиями к задержкам в сети. У вас есть возможность гибко выбирать расположение аварийного восстановления отдельно для каждого приложения. Например, в одной подписке могут быть приложения, выполняющие резервное копирование данных в другой центр обработки данных, а в другой — реплицирующие данные в общедоступное облако Azure.

Целевые показатели восстановления приложения

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

  • Целевое время восстановления (RTO)
    Это максимально допустимое время, в течение которого приложение может быть недоступно после инцидента. Например, если RTO составляет 90 минут, это значит, вы должны иметь возможность восстановить приложение в рабочем состоянии в течение 90 минут с момента начала сбоя. Если у вас низкое RTO, вы можете оставить второе развертывание, постоянно работающее в режиме ожидания, для защиты от регионального сбоя.
  • Целевая точка восстановления (RPO)
    Это максимальная продолжительность потери данных, которая является приемлемой во время аварии. Например, если данные хранятся в одной базе данных, резервная копия которой создается каждый час и не имеет репликации с другими базами данных, можно потерять данные в час.

Еще одной метрикой является среднее время восстановления (MTTR). Это среднее время, которое требуется для восстановления приложения после сбоя. MTTR является эмпирическим значением для системы. Если MTTR превышает RTO, то сбой в системе приведет к недопустимому сбою бизнес-процессов, так как восстановить систему в пределах определенного RTO невозможно.

Варианты технологий защиты

Резервное копирование и восстановление

Резервное копирование приложений и наборов данных позволяет быстро восстановить работоспособность при повреждении данных, случайном удалении или катастрофических сбоях. Для приложений на основе виртуальных машин IaaS можно использовать агент в гостевой системе для защиты данных приложения, конфигурации операционной системы и данных, хранящихся на томах.

Резервное копирование с помощью гостевого агента

Резервное копирование виртуальной машины с помощью гостевого агента обычно защищает конфигурацию операционной системы, файлы и папки, диски, двоичные файлы приложений и данные приложений.

Восстановление приложения через агент предполагает восстановление виртуальной машины вручную, установку операционной системы и установку гостевого агента. Только после этого появляется возможность восстановить данные в гостевой ОС или напрямую в приложении.

Резервное копирование с помощью моментального снимка остановленной виртуальной машины

Продукты для резервного копирования позволяют защитить конфигурацию виртуальной машины IaaS и диски, подключенные к остановленной виртуальной машине. Используйте продукты для резервного копирования, которые поддерживают интеграцию с API Azure Stack Hub для сбора данных о конфигурации виртуальной машины и создания моментальных снимков диска. Если для приложения допускается плановое прекращение работы, обязательно остановите работу виртуальной машины перед запуском рабочего процесса резервного копирования.

Резервное копирование с использованием моментального снимка диска для работающих виртуальных машин

Важно!

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

Виртуальные машины в наборе масштабирования или доступности

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

Репликация и переход на другой ресурс вручную

Для приложений со строгими требованиями к потере данных и (или) времени простоя можно включить репликацию данных на уровне приложения или гостевой ОС, чтобы сохранять эти данные в другом расположении. Некоторые приложения, как, например, Microsoft SQL Server, имеют встроенную поддержку репликации. Если же приложение не поддерживает репликацию, вы можете применить программное обеспечение гостевой ОС для репликации дисков или партнерское решение, которое устанавливает агент в гостевой ОС.

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

Высокий уровень доступности и автоматический переход на другой ресурс

Для приложений без отслеживания состояния, для которых допускается простой не более нескольких минут или секунд, необходимо настроить конфигурацию высокой доступности. Приложения с высоким уровнем доступности разрабатываются так, чтобы их можно было развертывать одновременно в нескольких расположениях по топологии "активный — активный", то есть все экземпляры обслуживают запросы одновременно. Для защиты от локальных сбоев оборудования в инфраструктуре Azure Stack Hub реализована высокая доступность в физической сети на основе двух стоечных коммутаторов. Для ошибок на уровне вычислений центр Azure Stack использует несколько узлов в единице масштабирования и автоматически отменяет отработку отказа виртуальной машины. На уровне виртуальной машины можно использовать масштабируемые наборы или виртуальные машины в группе доступности, чтобы убедиться, что сбои узла не занимают ваше приложение. То же самое приложение нужно развернуть во вторичном расположении в той же конфигурации. Чтобы приложение работало по схеме "активный — активный", можно применить подсистему балансировки нагрузки или DNS для распределения запросов по всем доступным экземплярам.

Без восстановления

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

Важные рекомендации по развертыванию Azure Stack Hub.

Рекомендация Комментарии
Резервное копирование и восстановление виртуальных машин на внешний целевой объект резервного копирования, уже развернутый в центре обработки данных Рекомендуемая Воспользуйтесь преимуществами имеющейся инфраструктуры резервного копирования и операционными навыками. Инфраструктура резервного копирования должна иметь соответствующий размер, чтобы она была готова защитить дополнительные экземпляры виртуальных машин. Убедитесь, что инфраструктура резервного копирования не в непосредственной близости от источника. Виртуальные машины можно восстановить в источник Azure Stack Hub, в дополнительный экземпляр Azure Stack Hub или в Azure.
Резервное копирование или восстановление виртуальных машин во внешний целевой объект резервного копирования, выделенный для Azure Stack Hub Рекомендуемая Для Azure Stack Hub можно приобрести новую инфраструктуру резервного копирования или подготовить выделенную инфраструктуру. Убедитесь, что инфраструктура резервного копирования не в непосредственной близости от источника. Виртуальные машины можно восстановить в источник Azure Stack Hub, в дополнительный экземпляр Azure Stack Hub или в Azure.
Резервное копирование и восстановление виртуальных машин напрямую в глобальную сеть Azure или доверенный поставщик служб Рекомендуемая До тех пор, пока вы можете соответствовать требованиям к конфиденциальности данных и нормативным требованиям, резервные копии можно хранить в глобальной среде Azure или в доверенном поставщике служб. В идеале поставщик служб также использует Azure Stack Hub, поэтому вы сохраняете согласованность после восстановления.
Репликация и отработка отказов виртуальных машин в отдельный экземпляр Azure Stack Hub Рекомендуемая В случае отработки отказа вам потребуется второе полностью рабочее облако Azure Stack Hub, чтобы избежать длительного простоя приложения.
Репликация и отработка отказа виртуальных машин напрямую в Azure или доверенный поставщик служб Рекомендуемая До тех пор, пока вы сможете соответствовать требованиям к конфиденциальности данных и нормативным требованиям, можно реплицировать данные в глобальную среду Azure или доверенный поставщик служб. В идеале поставщик служб также использует Azure Stack Hub, поэтому вы сохраняете согласованность после отработки отказа.
Развертывайте целевой объект резервного копирования в том же экземпляре Azure Stack Hub, где размещаются все приложения, защищаемые тем же объектом резервного копирования. Изолированный целевой объект: не рекомендуемый
целевой объект для репликации данных резервных копий извне: рекомендуется		 Если вы решите развернуть устройство резервного копирования в Azure Stack Hub (в целях оптимизации операционного восстановления), необходимо позаботиться о том, чтобы все данные постоянно копировались во внешнее расположение резервного копирования.
Развертывание физического устройства резервного копирования в той же стойке, в которой установлено решение Azure Stack Hub Не поддерживается Сейчас невозможно подключить к стоечным коммутаторам какие-либо другие устройства, которые не являются частью исходного решения.

Рекомендации по восстановленной виртуальной машине IaaS

После восстановления компьютера из резервной копии необходимо внести некоторые изменения в виртуальную машину. Сюда входит следующее.

  • MAC address (MAC-адрес)
    Виртуальный сетевой адаптер получит новый MAC-адрес. Не существует метода для сохранения исходного MAC-адреса.
  • IP-адрес
    Если для виртуальной машины задан статический IP-адрес, внутренний IP-адрес на виртуальном сетевом адаптере может быть установлен в соответствие с исходным. Возможно, потребуется определить, имеет ли ВИРТУАЛЬная сеть S2S VPN-подключение к внешней среде, где IP-адрес может использоваться.
  • Ненужные артефакты
    Если резервная копия виртуальной машины была создана на другой платформе, например VMware vSphere, необходимо выполнить некоторые дополнительные действия, чтобы очистить все ненужные артефакты из источника.

Дальнейшие действия

В этой статье представлены общие рекомендации по защите пользовательских виртуальных машин, развернутых в Azure Stack Hub. Дополнительные сведения о защите виртуальных машин пользователей с помощью служб Azure см. в следующих статьях:

Azure Backup Server

Azure Site Recovery

Партнерские продукты