Поделиться через

Надежность в Azure Backup

Azure Backup — это встроенная служба Azure, которая безопасно защищает облачные и локальные рабочие нагрузки. Резервное копирование может масштабировать защиту нескольких рабочих нагрузок и обеспечивает встроенную интеграцию с рабочими нагрузками Azure, включая виртуальные машины, SAP HANA в виртуальных машинах Azure, SQL в Azure виртуальных машинах, Файлы Azure, Хранилище BLOB-объектов Azure, Azure Data Lake Storage, управляемые диски Azure, тома Azure Elastic SAN и Azure Kubernetes Service (AKS). Вам не нужно управлять автоматизацией или инфраструктурой, писать скрипты или подготавливать хранилище.

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

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

Замечание

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

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

Чтобы создать резервную копию рабочих нагрузок, рекомендуется настроить хранилище следующим образом:

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

  • Если вы используете геоизбыточное хранилище (GRS) для репликации резервных копий в парный регион Azure, включите восстановление между регионами (CRR) для поддерживаемых источников данных. CRR позволяет в любое время восстановить резервные копии в парной области.

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

Замечание

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

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

Обзор архитектуры надежности

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

Логическая архитектура

Резервное копирование может выполнять сохранение и восстановление различных источников данных. Резервное копирование настраивается по-разному в зависимости от источника данных, с которым вы работаете. Ниже приведены распространенные источники данных:

  • Виртуальные машины Azure
  • Различные базы данных
  • учетные записи Хранилище BLOB-объектов
  • Кластеры AKS
  • Локальные серверы через агент служб восстановления Microsoft Azure (MARS)

Резервное копирование сохраняет резервные копии данных в хранилищах. Хранилища — это объекты онлайн-хранилища Azure, в которых хранятся данные, такие как политики резервного копирования, резервные копии и точки восстановления. Хранилища служб восстановления и хранилища резервных копий — это два типа хранилищ. Вы можете использовать один или оба типа в зависимости от того, что необходимо защитить. Список источников данных, поддерживаемых каждым типом хранилища, см. в разделе часто задаваемые вопросы о хранилищах, поддерживаемых для резервного копирования и восстановления.

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

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

Физическая архитектура

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

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

  • Локально избыточное хранилище (LRS) реплицирует данные в ваше хранилище по одной или нескольким зонам доступности Azure, расположенным в основном регионе вашего выбора. Вы не можете выбрать предпочтительную зону доступности, но Azure может перемещать или расширять учетные записи LRS между зонами, чтобы повысить балансировку нагрузки. Ваши данные не гарантируется, что будут распределены по зонам. Дополнительные сведения см. в разделе "Обзор зон доступности".

  • ZRS и GRS обеспечивают дополнительную защиту. В этой статье подробно описаны эти параметры.

Замечание

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

Устойчивость к временным сбоям

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

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

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

Устойчивость к сбоям зоны доступности

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

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

  • Служба: Служба резервного копирования автоматически зонально устойчива в поддерживаемых регионах. Однако эта встроенная устойчивость зоны не применяется к резервным копиям данных.

  • Избыточность хранилища резервных копий: Выберите уровень избыточности, который требуется для данных резервного копирования, настроив хранилище служб восстановления или хранилище резервных копий. При выборе ZRS копии данных резервного копирования автоматически хранятся в нескольких зонах доступности в используемом регионе Azure.

    Если вы не используете ZRS, данные резервного копирования считаются незональными и могут храниться в любой зоне. Если у любой зоны в регионе возникла проблема, данные незонального резервного копирования могут быть недоступны.

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

Требования

  • Поддержка региона: Служба автоматически устойчива к зонам во всех регионах с зонами доступности. Хранилища ZRS поддерживаются в тех же регионах.

  • Только новые хранилища: Настройте ZRS в хранилище перед первой резервной копией.

Себестоимость

При включении ZRS для резервных копий плата взимается по-разному, чем LRS из-за дополнительных затрат на репликацию и хранение. Дополнительные сведения см. в разделе о ценах на резервное копирование.

Настройка поддержки зоны доступности

  • Создайте новое хранилище, использующее ZRS: Настройте избыточность хранилища при создании хранилища. Выполните различные действия в зависимости от типа хранилища. Дополнительные сведения см. в следующих статьях:

  • Настройте ZRS в существующих хранилищах: Для хранилищ резервных копий настройте избыточность хранилища при создании хранилища. После создания хранилища резервного копирования параметр заблокирован и его невозможно изменить.

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

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

Поведение, когда все зоны работоспособны

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

  • Операция между зонами: Задания резервного копирования выполняются в инфраструктуре, реплицируемой между зонами. Azure управляет заданиями из инфраструктуры в любой зоне.

  • Репликация данных между зонами: ZRS реплицирует резервные копии данных между зонами. Репликация выполняется синхронно, что означает, что перед завершением каждой операции записи несколько зон признают каждую операцию записи.

Поведение во время сбоя зоны

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

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

    Это важно

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

  • Активные запросы: Поведение текущих заданий зависит от того, в какой зоне произошел сбой.

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

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

  • Ожидаемая потеря данных: Ожидаемый объем потери данных также называется целевой точкой восстановления (RPO). RPO для данных резервного копирования зависит от нескольких факторов, включая расписание резервного копирования. Как правило, для сбоя зоны не ожидается потеря резервных данных, так как все данные реплицируются синхронно между зонами.

  • Ожидаемое время простоя: Ожидаемое время простоя также называется целевой задачей времени восстановления (RTO). RTO отличается для каждого из следующих сценариев:

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

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

  • Перераспределение: Последующие задания автоматически используют инфраструктуру в здоровых зонах, пока доступны источники данных.

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

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

Резервное копирование поддерживает геоизбыточность и резервное переключение с помощью GRS и CRR.

Это важно

GRS для резервного копирования работает только в сопряжённых регионах Azure.

Географически избыточное хранилище и кросс-региональное восстановление

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

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

Парный регион также называется вторичным регионом.

Схема, показывающая, как данные реплицируются с помощью GRS.

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

Межрегиональное восстановление

При настройке GRS в хранилище Майкрософт делает резервные копии доступными в парном регионе после возникновения сбоя в основном регионе. Если источник данных поддерживает CRR, вы можете восстановить данные из точек восстановления дополнительного региона даже при отсутствии сбоя в основном регионе. CRR также позволяет проводить учения для проверки устойчивости к региональным сбоям. При включении CRR Майкрософт обновляет хранилище резервных копий с GRS до геоизбыточного хранилища с доступом только для чтения (RA-GRS).

Требования

  • Поддержка регионов: GRS для резервного копирования работает только в составных регионах Azure.

  • Только новые хранилища: Перед началом создания первой резервной копии необходимо настроить GRS в хранилище.

Соображения

  • CRR: После включения CRR элементы резервного копирования могут занять до 48 часов, чтобы быть доступными в дополнительном регионе.

Себестоимость

Хранилища GRS требуют дополнительных затрат на репликацию данных между регионами и хранение в резервном регионе. Плата за передачу данных между Azure регионами взимается на основе стандартных скоростей межрегионочной пропускной способности. CRR взимается по другой ставке, так как Майкрософт обновляет ваше хранилище с GRS до RA-GRS. Дополнительные сведения см. в разделе о ценах на резервное копирование.

Настройка поддержки нескольких регионов

  • Создайте новое хранилище, использующее GRS и CRR: При создании хранилища необходимо также настроить избыточность хранилища. Выбрав GRS, можно опционально включить CRR в хранилище (vault). Действия, которые необходимо выполнить, зависят от типа хранилища. Дополнительные сведения см. в следующих статьях:

  • Настройте GRS и CRR в существующих хранилищах: Для хранилищ резервных копий необходимо настроить избыточность хранилища при создании хранилища.

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

    Вы можете включить CRR в существующих сейфах GRS. После включения CRR его нельзя отключить.

Поведение, когда все регионы работоспособны

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

  • Операция между регионами: Резервные копии всегда выполняются в основном регионе, который является регионом, в котором развертываются хранилище и источник данных.

  • Репликация данных между регионами: При настройке хранилища для использования GRS резервные копии сначала фиксируются в основном регионе с помощью LRS. После успешного завершения в основном регионе данные асинхронно реплицируются в дополнительный регион. Дополнительный регион использует LRS для хранения данных. Данные резервного копирования могут занять до 12 часов для репликации из основного региона в дополнительный регион.

Поведение во время сбоя региона

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

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

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

  • Ожидаемая потеря данных: RPO для данных резервного копирования зависит от нескольких факторов, включая расписание резервного копирования. Как правило, для сбоя региона ожидается до 36 часов потери данных, так как RPO в основном регионе составляет 24 часа, и для репликации резервных данных из первичного в дополнительный регион может потребоваться до 12 часов.

  • Ожидаемое время простоя: RTO отличается для каждого из следующих сценариев:

    • Источники данных и другие ресурсы в регионе сбоя могут быть недоступны до восстановления региона, поэтому RTO не может быть определено.

    • Резервное копирование может не выполнять операции резервирования или восстановления в неработающем регионе до его восстановления, поэтому RTO не определен.

    • При использовании CRR RTO для запуска восстановления резервных копий, уже реплицированных в парный регион, равен нулю. Если вы не используете CRR, RTO зависит от того, сколько времени потребуется Майкрософт, чтобы объявить аварию в отказавшем регионе.

  • Перераспределение: Задания резервного копирования не могут выполняться, пока основной регион находится в автономном режиме. Вы можете восстановить данные в хранилище, но не можете добавить новые данные.

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

Восстановление региона

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

Проверка сбоев в регионе

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

Устойчивость к потере данных резервного копирования

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

  • Обратимое удаление позволяет восстанавливать удаленные объекты и хранилища в течение настраиваемого периода хранения. По умолчанию этот период составляет 14 дней, но его можно изменить. Мягкое удаление — это как корзина для удаления для ваших резервных копий и защищенных хранилищ. Для получения дополнительной информации см. Безопасность по умолчанию с мягким удалением для резервного копирования.

  • Неизменяемые хранилища могут помочь защитить данные резервного копирования, блокируя операции, которые могут привести к потере точек восстановления. Вы можете заблокировать неизменяемую настройку хранилища, чтобы сделать её необратимой. Вы также можете использовать хранилище с однократной записью и многократным чтением (WORM) для резервного копирования, чтобы предотвратить отключение неизменяемости и удаление резервных копий злоумышленниками. Дополнительные сведения см. в разделе " Неизменяемое хранилище для резервного копирования".

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLAs для онлайн-сервисов.

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

Связанный контент

  • Last updated on