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

  • Статья

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

Чтобы защититься от потери данных и незапланированного простоя, реализуйте план защиты данных и аварийного восстановления для приложений на основе виртуальных машин в Azure Stack Hub. Реализованный план защиты будет зависеть от бизнес-требований и структуры приложения. Этот план должен соответствовать платформе, установленной комплексной стратегией непрерывности бизнес-процессов и аварийного восстановления (BC/DR).

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

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

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

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

Проведите оценку, чтобы определить RTO и RPO для каждого приложения.

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

Варианты защиты для виртуальных машин IaaS

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

Наиболее распространенная схема защиты приложений, расположенных на виртуальной машине, — использовать программное обеспечение резервного копирования. Резервное копирование виртуальной машины обычно включает операционную систему, конфигурацию операционной системы, двоичные файлы приложения и данные постоянных приложений, содержащиеся на виртуальной машине. Резервные копии создаются с помощью агента в гостевой ОС для записи приложений, ОС или файловой системы или томов. Другой подход — без агента, полагаясь на интеграцию с API Azure Stack Hub для чтения сведений о конфигурации виртуальной машины и snapshot дисков, подключенных к виртуальной машине. Обратите внимание, что Azure Stack Hub не поддерживает резервное копирование непосредственно из низкоуровневой оболочки.

Планирование стратегии резервного копирования

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

Ниже приведены важные рекомендации по резервному копированию виртуальных машин в Azure Stack.

  • Классификация
    • Рассмотрим модель, в которой пользователи выбирают резервное копирование виртуальных машин.
    • Определите соглашение об уровне обслуживания (SLA) для восстановления на основе приоритетов приложений или влияния на бизнес.
  • Масштабирование
    • Рассмотрите поочередное резервное копирование при подключении большого количества новых виртуальных машин (если резервное копирование требуется).
    • Оцените решения резервного копирования, которые могут эффективно собирать и передавать данные резервного копирования, чтобы свести к минимуму содержимое ресурса в решении.
    • Оцените решения резервного копирования, которые эффективно хранят данные архивации, используя добавочные или разностные резервные копии, чтобы свести к минимуму необходимость полных резервных копий во всех виртуальных машинах среды.
  • Восстановление
    • Решения резервного копирования могут восстанавливать виртуальные диски, данные приложения в имеющейся виртуальной машине или весь ресурс виртуальной машины и связанные виртуальные диски. Нужная схема восстановления зависит от того, как вы планируете восстанавливать приложение. Например, может быть проще повторно развернуть SQL Server из шаблона, а затем восстановить базы данных вместо восстановления всей виртуальной машины или набора виртуальных машин.

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

Альтернативным подходом к поддержке восстановления является репликация данных в другую среду. Данные могут быть ограничены приложением, например репликацией базы данных или операционной системой в гостевой ОС с помощью агента, или на уровне виртуальной машины путем интеграции с API Azure Stack Hub. В случае аварии требуется отработка отказа в дополнительное расположение. Отработка отказа может выполняться приложением, например с группами доступности SQL, на уровне гостевой ОС с помощью агентов или технологии кластера или на уровне виртуальной машины с помощью средства защиты.

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

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

Нет защиты

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

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