Непрерывность бизнес-процессов и аварийное восстановление для аналитики в масштабе облака

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

Функции обеспечения высокой доступности и аварийного восстановления иногда можно объединять. Для этих двух областей используется несколько различных стратегий, особенно если речь идет о данных. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework и в описании принципов надежности.

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

Стратегии резервного копирования

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

• Резервное копирование и восстановление. Восстановите приложение базы данных из последней резервной копии до сбоя. Такой подход обычно используется после повреждения или случайного удаления данных.

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

• Теплая замена (активная/пассивная). Создайте дополнительную размещенную службу в альтернативном регионе. Разверните роли, чтобы обеспечить минимальную емкость. При этом роли не получают рабочий трафик. Этот подход можно использовать для приложений, которые не предназначены для распределения трафика по регионам.

• Горячая замена (активная/активная). Спроектируйте приложение для получения рабочей нагрузки в нескольких регионах. Приложение предназначено для получения рабочей нагрузки в нескольких регионах. Облачные службы в каждом регионе могут быть настроены для горизонтального увеличения масштаба в случае аварии и отработки отказа.

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

Аварийное восстановление и высокий уровень доступности для служб Azure

В следующих разделах обсуждаются различные службы Azure.

Azure Cosmos DB

Общие сведения о высоком уровне доступности в Azure Cosmos DB см. в статье Обеспечение высокого уровня доступности в Azure Cosmos DB.

Фабрика данных Azure

Для интеграции данных и продукта данных, скорее всего, будут созданы репозитории Azure DevOps, связанные с Фабрикой данных Azure. Можно развернуть конвейеры в другой фабрике данных при минимальном времени простоя. Чтобы использовать программное обеспечение для управления версиями кода из репозитория GitHub и Azure DevOps, используйте пакет SDK Фабрики данных Azure для создания конвейеров и других объектов Фабрики данных Azure.

Azure Data Lake;

Azure Data Lake Storage 2-го поколения уже выполняет трехкратную репликацию для защиты от локальных сбоев оборудования. Другие параметры репликации, такие как хранилище, избыточное между зонами (ZRS), или хранилище, геоизбыточное между зонами (GZRS), улучшают высокий уровень доступности. Геоизбыточное хранилище (GRS) и геоизбыточное хранилище с доступом на чтение (RA-GRS) улучшают аварийное восстановление. Для обеспечения высокой доступности при перебоях в работе службы рабочей нагрузке необходимо как можно быстрее получить доступ к актуальным данным. Рабочая нагрузка может переключиться на реплицируемый экземпляр локально или в новом регионе.

Учетная запись хранения, настроенная как RA-GRS или GRS, может быть частью плана аварийного восстановления, но требует комплексной экспертизы анализа целевой точки восстановления (RPO) и целевого времени восстановления (RTO) и просмотра других вариантов, таких как сценарий двойной загрузки, который копирует данные в два разных региона Azure.

Каждая целевая зона данных должна иметь целевую точку восстановления для своих продуктов данных. Для всех целевых зон данных должна использоваться определенная стратегия репликации для различных вариантов использования.

Примечание

Отработка отказа учетной записи под управлением пользователя пока не поддерживается в учетных записях с иерархическим пространством имен (Azure Data Lake Storage 2-го поколения).

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

Дополнительные сведения см. в статье Аварийное восстановление и отработка отказа учетной записи хранения.

Azure Databricks

Общие сведения об архитектуре аварийного восстановления для кластеров Azure Databricks см. в разделе Региональные аварийное восстановление для кластеров Azure Databricks.

Машинное обучение Azure

Общие сведения о высоком уровне доступности в службе Машинное обучение Azure см. в статье Отработка отказа для обеспечения непрерывности бизнес-процессов и аварийного восстановления.

Azure Key Vault

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

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

База данных SQL Azure

Общие сведения об обеспечении бизнес-процессов с помощью службы База данных SQL Azure см. разделе Общие сведения об обеспечении непрерывности бизнес-процессов с помощью службы База данных SQL Azure.

Azure Synapse Analytics

Общие сведения об обеспечении непрерывности бизнес-процессов с помощью Azure Synapse Analytics см. в статье Обеспечение высокого уровня доступности для Azure Synapse Analytics.

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

• Общие сведения об управлении данными