Что такое аварийное восстановление?
Авария — это одно важное событие с большим и длительным воздействием, чем приложение может снизить уровень доступности в рамках своей разработки. Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, что приводит к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление.
Целевые показатели восстановления
Полный план аварийного восстановления должен указать следующие критически важные бизнес-требования для каждого процесса, реализуемого приложением:
Цель точки восстановления (RPO) — это максимальная длительность допустимой потери данных. RPO измеряется в единицах времени, а не в томах, таких как "30 минут данных" или "четыре часа данных". RPO относится к ограничению и восстановлению после потери данных, а не краже данных.
Цель времени восстановления (RTO) — это максимальная длительность допустимого простоя, где "простой" определяется вашей спецификацией. Например, если допустимое время простоя в аварии составляет восемь часов, то RTO составляет восемь часов.
Каждый основной процесс или рабочая нагрузка, реализуемая приложением, должны иметь отдельные значения RPO и RTO путем изучения рисков аварийного сценария и потенциальных стратегий восстановления. Процесс указания RPO и RTO эффективно создает требования аварийного восстановления для приложения в результате уникальных бизнес-проблем (затрат, влияния, потери данных и т. д.).
Разработка для аварийного восстановления
Аварийное восстановление не является автоматической функцией, но должно быть разработано, создано и проверено. Для поддержки твердой стратегии аварийного восстановления необходимо создать приложение с учетом аварийного восстановления с учетом основы. Azure предлагает службы, функции и рекомендации для поддержки аварийного восстановления при создании приложений. Чтобы понять, что необходимо сделать для поддержки аварийного восстановления, необходимо сначала понять модель общей ответственности за устойчивость. Дополнительные сведения см. в разделе "Общая ответственность за устойчивость".
Восстановление данных
Во время аварии есть два основных метода восстановления данных: резервные копии и репликация.
Резервное копирование восстанавливает данные до определенной точки во времени. С помощью резервного копирования вы можете предоставлять простые, безопасные и экономичные решения для резервного копирования и восстановления данных в облаке Microsoft Azure. Используйте Azure Backup для создания длительных моментальных снимков данных только для чтения для восстановления.
Репликация данных создает копии динамических данных в реальном времени в реальном времени в нескольких репликах хранилища данных с минимальными потерями данных. Целью репликации является поддержание синхронизации реплик с минимально возможной задержкой при сохранении скорости реагирования приложения. Большинство полнофункциональных систем баз данных и других продуктов и служб хранилища данных включают в себя некоторую репликацию как тесно интегрированную функцию из-за его функциональных и производительности. Примером этого является геоизбыточное хранилище (GRS).
Различные проекты репликации размещают разные приоритеты в отношении согласованности данных, производительности и затрат.
Активная репликация означает, что обновления должны одновременно вступать в силу в нескольких репликах. Эта схема гарантирует полную согласованность в ущерб пропускной способности.
Пассивной репликации выполняет синхронизацию в фоновом режиме, удаляя репликацию как ограничение производительности приложения, но увеличивая RPO.
Репликация active-active или multimaster позволяет одновременно использовать несколько реплик, обеспечивая балансировку нагрузки за счет усложнения согласованности данных.
Активные пассивные репликации резервирует реплики для активного использования только во время отработки отказа.
Примечание.
Наиболее полнофункциональными системами баз данных и другими продуктами и службами хранения данных являются репликация, например геоизбыточное хранилище (GRS), из-за их функциональных и производительности.
Создание устойчивых приложений
Сценарии аварий также часто приводят к простою, будь то из-за проблем с сетевым подключением, сбоев центра обработки данных, поврежденных виртуальных машин (виртуальных машин) или поврежденных развертываний программного обеспечения. В большинстве случаев восстановление приложений включает отработку отказа в отдельное рабочее развертывание. В результате может потребоваться восстановить процессы в другом регионе Azure в случае крупномасштабной аварии. Дополнительные рекомендации могут включать в себя расположение восстановления, количество реплицированных сред и способ обслуживания этих сред.
В зависимости от дизайна приложения можно использовать несколько различных стратегий и функций Azure, таких как Azure Site Recovery, для улучшения поддержки приложения для восстановления процессов после аварии.
Функции аварийного восстановления для конкретной службы
Большинство служб, работающих на платформе Azure как услуга (PaaS), таких как служба приложение Azure, предоставляют функции и рекомендации для поддержки аварийного восстановления. В некоторых сценариях можно использовать специальные функции службы для поддержки быстрого восстановления. Например, Azure SQL Server поддерживает георепликацию для быстрого восстановления службы в другом регионе. В Службе приложений Azure есть встроенная функция резервного копирования и восстановления, а в документации описано, как применить диспетчер трафика Azure для маршрутизации трафика в дополнительный регион.