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