Поделиться через

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

  • Статья

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

Чтобы избежать потери данных и длительных простоев, реализуйте план резервного копирования и восстановления или план аварийного восстановления для пользовательских приложений и данных. Каждое приложение должно оцениваться как часть комплексной стратегии непрерывности бизнес-процессов и аварийного восстановления (BC/DR).

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

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

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

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

Владелец (архитектор) приложения Оператор Azure Stack Hub
— согласование архитектуры приложений с принципами облачного проектирования.
— Модернизируйте традиционные приложения по мере необходимости, чтобы подготовить их к облачной среде.
— определите допустимые RTO и RPO для приложения.
— определите ресурсы приложения и репозитории данных, которые необходимо защитить.
— реализация метода восстановления данных и приложений, который лучше всего соответствует архитектуре приложения и требованиям клиентов.		 — Определение целей непрерывности бизнес-процессов и аварийного восстановления организации.
— Разверните достаточно экземпляров Azure Stack Hub для достижения целей bc/dr организации.
— Проектирование и эксплуатация инфраструктуры защиты приложений и данных.
— предоставление управляемых решений или самостоятельного доступа к службам защиты.
— Работайте с владельцами и архитекторами приложений, чтобы понять структуру приложений и рекомендовать стратегии защиты.
— Включите резервное копирование инфраструктуры для восстановления служб и восстановления в облаке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

Для приложений без отслеживания состояния, для которых допускается простой не более нескольких минут или секунд, необходимо настроить конфигурацию высокой доступности. Приложения с высоким уровнем доступности разрабатываются так, чтобы их можно было развертывать одновременно в нескольких расположениях по топологии "активный — активный", то есть все экземпляры обслуживают запросы одновременно. Для защиты от локальных сбоев оборудования в инфраструктуре Azure Stack Hub реализована высокая доступность в физической сети на основе двух стоечных коммутаторов. Для сбоев на уровне вычислений Azure Stack Hub использует несколько узлов в единице масштабирования и автоматически выполняет отработку отказа виртуальной машины. На уровне виртуальной машины можно использовать масштабируемые наборы или виртуальные машины в группе доступности, чтобы гарантировать, что сбои узлов не переключили приложение. То же самое приложение нужно развернуть во вторичном расположении в той же конфигурации. Чтобы приложение работало по схеме "активный — активный", можно применить подсистему балансировки нагрузки или 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-адрес виртуального сетевого адаптера можно задать в соответствии с исходным. Возможно, потребуется рассмотреть, есть ли в виртуальной сети vpn-подключение типа "сеть — сеть" во внешней среде, где может использоваться IP-адрес.
  • Ненужные артефакты
    Если резервная копия виртуальной машины была создана на другой платформе, например VMware vSphere, вам потребуется выполнить некоторые дополнительные действия для очистки ненужных артефактов из источника.

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

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