Непрерывность бизнес-процессов и аварийное восстановление для облачной аналитики
При разработке архитектуры облачной службы рассмотрите требования к доступности и как реагировать на потенциальные прерывания в службе. Проблема может быть локализована как в конкретном случае, так и на уровне всего региона. Наличие планов для обоих имеет важное значение. В зависимости от цели времени восстановления и цели точки восстановления можно выбрать агрессивную стратегию для обеспечения высокой доступности и аварийного восстановления.
Высокий уровень доступности и аварийное восстановление иногда могут объединяться. Две области имеют несколько разных стратегий, особенно когда речь идет о данных. Дополнительные сведения см. в
Вместо того, чтобы попытаться предотвратить сбои, примите заранее, что сбои могут произойти и произойти. Свести к минимуму влияние любого отдельного компонента в случае сбоя в жизненном цикле. Допустимость затрат, целевой точки восстановления и целевого времени восстановления определяет тип решения для реализации.
Стратегии резервного копирования
Многие альтернативные стратегии доступны для реализации распределенных вычислений в разных регионах. Стратегии должны быть адаптированы к бизнес-требованиям и обстоятельствам приложения. На высоком уровне подходы делятся на следующие категории:
Резервное копирование и восстановление: восстановить приложение базы данных из последней резервной копии до катастрофы. Этот подход часто используется после повреждения данных или случайного удаления.
повторное развертывание при аварии: повторно развернуть приложение с нуля во время аварии. Этот подход подходит для некритических приложений, которые не требуют гарантированного времени восстановления.
Теплый запас (активный или пассивный): Создание вторичной размещенной службы в альтернативном регионе. Разверните роли, чтобы гарантировать минимальную мощность. Роли не получают производственный трафик. Этот подход полезен для приложений, которые не предназначены для распределения трафика между регионами.
Резервный запас (активный/активный): Разрабатывайте приложение для обработки производственной нагрузки в нескольких регионах. Вы можете настроить облачные службы в каждом регионе для более высокой емкости, чем требуется для аварийного восстановления. Вместо этого можно масштабировать облачные службы по мере необходимости во время аварии и переключения на резерв.
Этот подход требует инвестиций в разработку приложений, но имеет преимущества. Он предлагает низкое и гарантированное время восстановления. Осуществляется непрерывное тестирование всех точек восстановления и эффективное использование мощностей. Для приложений баз данных этот подход включает подсистему балансировки нагрузки для двух баз данных, которые синхронизируются с одной точкой подключения.
Аварийное восстановление и высокий уровень доступности для служб Azure
Cloud Scale Analytics состоит из нескольких служб Azure, которые группируются на платформу, ядро и данные. Дополнительные сведения о руководствах по надежности конкретных служб и аварийном восстановлении см. в документации по надежности Azure