Основные сведения о настройке периодического резервного копирования в Azure Service Fabric

Настройка периодического резервного копирования надежных служб с отслеживанием состояния и Reliable Actors предусматривает следующие шаги:

1. Создание политик резервного копирования. На этом шаге создаются одна или несколько политик резервного копирования в зависимости от требований.

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

Создать политику архивации

Политика резервного копирования состоит из следующих конфигураций:

• Автоматическое восстановление в случае потери данных. Указывает, следует ли активировать автоматическое восстановление с использованием последней доступной резервной копии в случае потери данных в разделе.

Примечание.

НЕ рекомендуется использовать автоматическое восстановление в рабочих кластерах.

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

  1. Для реплики никогда не создавалась полная резервная копия, так как она стала первичной.

  2. Некоторые записи журнала с момента последнего резервного копирования были усечены.

  3. Размер реплики превысил ограничение MaxAccumulatedBackupLogSizeInMB.

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

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

     {
         "ScheduleKind": "FrequencyBased",
         "Interval": "PT10M"
     }
     

  2. Расписание резервного копирования на основе времени. Этот тип расписания следует использовать, если резервное копирование данных необходимо выполнять в указанное время дня или недели. Тип частоты расписания может быть ежедневным или еженедельным.

     1. Расписание резервного копирования на основе времени, выполняющееся ежедневно. Этот тип расписания следует использовать, если резервное копирование данных необходимо выполнять в указанное время дня. Чтобы сделать это, задайте для параметра ScheduleFrequencyType значение Ежедневно, а для параметра RunTimes задайте список значений нужного времени в течение дня в формате ISO8601. Дата, указанная с временем, будет игнорироваться. Например, 0001-01-01T18:00:00 означает 18:00 каждый день, а часть даты 0001-01-01 игнорируется. В приведенном ниже примере показана конфигурация активации ежедневного резервного копирования в 9:00 и 18:00 ежедневно.

        {
            "ScheduleKind": "TimeBased",
            "ScheduleFrequencyType": "Daily",
            "RunTimes": [
              "0001-01-01T09:00:00Z",
              "0001-01-01T18:00:00Z"
            ]
        }
        

     2. Расписание резервного копирования на основе времени, выполняющееся еженедельно. Этот тип расписания следует использовать, если резервное копирование данных необходимо выполнять в указанное время дня. Чтобы сделать это, задайте для параметра ScheduleFrequencyType значение Еженедельно, а для параметра RunDays задайте список дней недели, когда необходимо активировать резервное копирование, а для параметра RunTimes задайте список необходимых значений нужного времени в течение дня в формате ISO8601. Дата, указанная с временем, будет игнорироваться. Выведите список дней недели, когда необходимо активировать периодическое резервное копирование. В приведенном ниже примере показана конфигурация активации ежедневного резервного копирования в 9:00 и 18:00 с понедельника по пятницу.

        {
            "ScheduleKind": "TimeBased",
            "ScheduleFrequencyType": "Weekly",
            "RunDays": [
               "Monday",
               "Tuesday",
               "Wednesday",
               "Thursday",
               "Friday"
            ],
            "RunTimes": [
              "0001-01-01T09:00:00Z",
              "0001-01-01T18:00:00Z"
            ]
        }
        

• Хранилище резервных копий. Указывает расположение, в которое нужно передать резервные копии. Роль хранилища может выполнять хранилище больших двоичных объектов или файловый ресурс Azure.

  1. Хранилище BLOB-объектов Azure с управляемым удостоверением: этот тип хранилища должен быть выбран, если требуется хранить созданные резервные копии в Azure. Автономные и облачные кластеры могут использовать этот тип хранилища. Описание этого типа хранилища требует blobServiceUri и имя контейнера, в котором необходимо отправить резервные копии. Если контейнер с указанным именем недоступен, он создается во время отправки резервной копии. Замените account-name имя учетной записи хранения.

     {
         "StorageKind": "ManagedIdentityAzureBlobStore",
         "FriendlyName": "AzureMI_storagesample",
         "BlobServiceUri": "https://<account-name>.blob.core.windows.net",
         "ContainerName": "backup-container",
         "ManagedIdentityType": "VMSS",
         "ManagedIdentityClientId": "<Client-Id of User-Assigned MI>" 
     }
     

     [ПРИМЕЧАНИЕ] Используйте необязательный параметр ManagedIdentityClientId с идентификатором клиента управляемого удостоверения, назначаемого пользователем, в случае нескольких назначаемых пользователем управляемых удостоверений, назначенных вашему ресурсу или назначаемым SAMI и UAMI, и нам нужно использовать UAMI в качестве значения по умолчанию. Кроме того, этот параметр не требуется.

     Выполните действия по назначению управляемых удостоверений в ресурсе Azure:

     1. Включение управляемого удостоверения, назначаемого системой или назначаемого пользователем, в vmSS Configure managed identityes on virtual machine scale set

     2. Назначение роли управляемому удостоверению VMSS учетной записи хранения назначение ролей Azure с помощью портал Azure — Azure RBAC

        1. Роль участника данных BLOB-объектов хранилища как минимум

     Дополнительные сведения об управляемом удостоверении

  2. Хранилище BLOB-объектов Azure с помощью ConnectionString: этот тип хранилища должен быть выбран, если требуется хранить созданные резервные копии в Azure. Автономные и облачные кластеры могут использовать этот тип хранилища. Для описания этого типа хранилища требуется строка подключения и имя контейнера, в который необходимо передать резервные копии. Если контейнер с указанным именем недоступен, он будет создан во время передачи резервной копии.

     {
         "StorageKind": "AzureBlobStore",
         "FriendlyName": "Azure_storagesample",
         "ConnectionString": "<Put your Azure blob store connection string here>",
         "ContainerName": "backup-container"
     }
     

     Примечание.

     Служба восстановления резервного копирования не работает с azure storage ConnectionString версии 1, не рекомендуется в рабочей среде, так как прямой доступ к ресурсу без проверки подлинности пользователя

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

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

        {
            "StorageKind": "FileShare",
            "FriendlyName": "Sample_FileShare",
            "Path": "\\\\StorageServer\\BackupStore"
        }
        

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

        {
            "StorageKind": "FileShare",
            "FriendlyName": "Sample_FileShare",
            "Path": "\\\\StorageServer\\BackupStore",
            "PrimaryUserName": "backupaccount",
            "PrimaryPassword": "<Password for backupaccount>",
            "SecondaryUserName": "backupaccount2",
            "SecondaryPassword": "<Password for backupaccount2>"
        }
        

Примечание.

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

• Политика хранения. Указывает политику хранения резервных копий в настроенном хранилище. Поддерживается только политика хранения уровня "Базовый".

  1. Базовая политика хранения. Эта политика хранения позволяет обеспечить оптимальное использование хранилища, удаляя файлы резервного копирования, которые больше не требуются. RetentionDuration можно указать, чтобы задать период времени, в течение которого резервные копии должны храниться в хранилище. MinimumNumberOfBackups — необязательный параметр, который можно указать, чтобы указанное количество резервных копий всегда хранилось независимо от настроенного параметра RetentionDuration. В приведенном ниже примере показана конфигурация для хранения резервных копий в течение 10 дней и не позволяет выполнять резервное копирование ниже 20.

     {
         "RetentionPolicyType": "Basic",
         "RetentionDuration": "P10D",
         "MinimumNumberOfBackups": 20
     }
     

Включение периодического резервного копирования

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

Примечание.

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

Иерархические распространение политики резервного копирования

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

Переопределение политики резервного копирования

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

Пример

В этом примере используется установка с двумя приложениями, MyApp_A и MyApp_B. Приложение MyApp_A содержит две службы Reliable Stateful, SvcA1 и SvcA3 и одну службу Reliable Actor, ActorA2. SvcA1 содержит три раздела, а ActorA2 и SvcA3 — по два раздела. Приложение MyApp_B содержит три надежные службы с отслеживанием, SvcB1, SvcB2 и SvcB3. _SvcB1 и SvcB2 содержат две секции, в то время как SvcB3 содержит три секции.

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

1. MyApp_A

   1. Ежедневно создавайте резервную копию данных для всех разделов всех надежных служб с отслеживанием и Reliable Actors, относящихся к приложению. Передайте данные резервного копирования в расположение BackupStore1.

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

   3. Размер данных в разделе SvcA1_P2 превышает ожидаемый и его данные резервного копирования следует сохранить в другое место хранения BackupStore2.

2. MyApp_B

   1. Создавайте резервную копию данных каждое воскресенье в 8:00 для всех разделов службы SvcB1. Передайте данные резервного копирования в расположение BackupStore1.

   2. Создавайте резервную копию данных каждый день в 8:00 для раздела SvcB2_P1. Передайте данные резервного копирования в расположение BackupStore1.

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

1. MyApp_A

   1. Создайте политику резервного копирования, BP_1, с расписанием резервного копирования на основе частоты, где для частоты задается значение 24 часа. и хранилищем резервных копий, настроенным для использования места хранения BackupStore1. Включите эту политику для приложения MyApp_A с помощью API Enable Application Backup (Включение резервного копирования приложения). Это действие позволяет выполнять резервное копирование данных с помощью политики резервного копирования BP_1 для всех разделов надежных служб с отслеживанием состояния и Reliable Actors, относящихся к приложению MyApp_A.

   2. Создайте политику резервного копирования, BP_2, с расписанием резервного копирования на основе частоты, где для частоты задается значение 1 час, и хранилищем резервных копий, настроенным для использования места хранения BackupStore1. Включите эту политику для службы SvcA3 с помощью API Enable Service Backup (Включение резервного копирования службы). Это действие переопределяет распространенную политику BP_1 с помощью включенной политики резервного копирования BP_2 для всех разделов службы SvcA3, в результате чего для этих разделов резервное копирование данных выполняется с помощью политики резервного копирования BP_2.

   3. Создайте политику резервного копирования, BP_3, с расписанием резервного копирования на основе частоты, где для частоты задается значение 24 часа. и хранилищем резервных копий, настроенным для использования места хранения BackupStore2. Включите эту политику для раздела SvcA1_P2 с помощью API Enable Partition Backup (Включение резервного копирования раздела). Это действие переопределяет распространенную политику BP_1 с помощью включенной политики резервного копирования BP_3 для раздела SvcA1_P2.

2. MyApp_B

   1. Создайте политику резервного копирования, BP_4, с расписанием резервного копирования на основе времени, в котором для типа частоты расписания задано значение "еженедельно", для дней выполнения — воскресенье, а времени выполнения — 8:00. Хранилище резервных копий, настроенное для использования места хранения BackupStore1. Включите эту политику для службы SvcB1 с помощью API Enable Service Backup (Включение резервного копирования службы). Это действие позволяет выполнять резервное копирование данных с помощью политики резервного копирования BP_4 для всех разделов службы SvcB1.

   2. Создайте политику резервного копирования, BP_5, с расписанием резервного копирования на основе времени, в котором для типа частоты расписания задано значение "ежедневно", а времени выполнения — 8:00. Хранилище резервных копий, настроенное для использования места хранения BackupStore1. Включите эту политику для раздела SvcB2_P1 с помощью API Enable Partition Backup (Включение резервного копирования раздела). Это действие позволяет выполнять резервное копирование данных с помощью политики резервного копирования BP_5 для раздела SvcB2_P1.

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

Отключение резервного копирования

Политики резервного копирования могут быть отключены, если нет необходимости резервного копирования данных. Политику резервного копирования, включенную на уровне приложения, можно отключить только в том же самом приложении с помощью API Disable Application Backup (Отключение резервного копирования приложения). Политику резервного копирования, включенную на уровне службы, можно отключить в той же самой службе с помощью API Disable Service Backup (Отключение резервного копирования службы). Политику резервного копирования, включенную на уровне раздела, можно отключить в том же самом разделе с помощью API Disable Partition Backup (Отключение резервного копирования раздела).

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

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

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

• При отключении резервного копирования для сущности (приложения/службы/раздела) для параметра CleanBackup можно установить значение true, чтобы удалить все резервные копии в настроенном хранилище.

  {
      "CleanBackup": true 
  }
  

Примечание.

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

Приостановка и возобновление резервного копирования

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

• Если применить приостановку в приложении с помощью API Suspend Application Backup (Приостановка резервного копирования приложения), то во всех службах и разделах этого приложения периодическое резервное копирование данных будет приостановлено.

• Если применить приостановку в службе с помощью API Suspend Service Backup (Приостановка резервного копирования службы), то во всех разделах этой службы периодическое резервное копирование данных будет приостановлено.

• Если применить приостановку в разделе с помощью API Suspend Partition Backup (Приостановка резервного копирования раздела), то во всех разделах этой службы периодическое резервное копирование данных будет приостановлено.

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

• Если приостановка применена в приложении, резервное копирование следует возобновить с помощью API Resume Application Backup (Возобновление резервного копирования приложения).

• Если приостановка применена в службе, резервное копирование следует возобновить с помощью API Resume Service Backup (Возобновление резервного копирования службы).

• Если приостановка применена в разделе, резервное копирование следует возобновить с помощью API Resume Partition Backup (Возобновление резервного копирования раздела).

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

Отключить резервное копирование следует использовать, если резервные копии больше не требуются для определенного приложения, службы или раздела. Можно вызвать запрос на отключение резервного копирования вместе с параметром "Чистые резервные копии", что означает, что все существующие резервные копии также удаляются. Приостановка резервного копирования используется в тех случаях, когда нужно временно отключить резервное копирование, например при заполнении локального диска, когда не удалось отправить резервную копию из-за известной ошибки сети и т. д.

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

Автоматическое восстановление в случае потери данных

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

Когда Service Fabric обнаруживает, что в разделе произошла потеря данных, она вызывает метод интерфейса OnDataLossAsync в раздел и ожидает, пока в разделе не будут предприняты необходимые действия по устранению потери данных. В этом случае, если в действующей политике резервного копирования в разделе для флага AutoRestoreOnDataLoss задано значение true, то восстановление автоматически активируется с использованием последней доступной резервной копии для этого раздела.

Примечание.

НЕ рекомендуется использовать автоматическое восстановление в рабочих кластерах.

Получение конфигурации резервного копирования

Для получения сведений о конфигурации резервного копирования на уровне приложения, службы и раздела теперь доступны отдельные API. Get Application Backup Configuration Info (Получение сведений о конфигурации резервного копирования приложения), Get Service Backup Configuration Info (Получение сведений о конфигурации резервного копирования службы) и Get Partition Backup Configuration Info (Получение сведений о конфигурации резервного копирования раздела) — эти API соответственно. Главным образом эти API возвращают сведения о применимой политике резервного копирования, уровне, на котором применена политика резервного копирования, и приостановке резервного копирования. Ниже приводится краткое описание возвращаемых результатов этих API.

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

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

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

Вывод списка доступных резервных копий

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

Эти API также поддерживают разбивку результатов на страницы, если параметр MaxResults имеет ненулевое положительное целое число, то API возвращает максимальные элементы сведений о резервном копировании MaxResults . Если число доступных элементов сведений о резервных копиях превышает значение MaxResults, возвращается маркер продолжения. Допустимый параметр маркера продолжения можно использовать для получения следующего набора результатов. Когда допустимое значение токена продолжения передается в следующий вызов API, он возвращает следующий набор результатов. Маркер продолжения не предоставляется в ответе, если возвращаются все доступные результаты.

Ниже приведены краткие сведения о поддерживаемых вариантах.

• Get Application Backup List (Получение списка резервного копирования приложения). Возвращает список резервных копий, доступных для каждого раздела, относящегося к данному приложению Service Fabric.

• Get Service Backup List (Получение списка резервного копирования службы). Возвращает список резервных копий, доступных для каждого раздела, относящегося к данной службе Service Fabric.

• Get Partition Backup List (Получение списка резервного копирования раздела). Возвращает список резервных копий, доступных для данного раздела.

Следующие шаги

• Backup restore REST API reference (Справочник по REST API службы резервного копирования и восстановления)