你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

了解 Azure Service Fabric 中的定期备份配置

为可靠的有状态服务或 Reliable Actors 配置定期备份包括以下步骤:

  1. 创建备份策略:在此步骤中,根据需求创建一个或多个备份策略。

  2. 启用备份:在此步骤中,将在步骤 1 中创建的备份策略关联到所需的实体,即“应用程序”、“服务”或“分区”。

创建备份策略

备份策略包括以下配置:

  • 在数据丢失时自动还原:指定在分区发生数据丢失事件时是否使用最新的可用备份自动触发还原。

注意

建议不要在生产群集中设置自动还原

  • 最大增量备份数:定义在两个完整备份之间可执行的增量备份的最大数目。 最大增量备份数指定上限。 在下列条件之一下,可以在完成指定数目的增量备份前执行完整备份

    1. 副本在变为主副本后从未执行过完整备份。

    2. 自上次备份以来的一些日志记录已截断。

    3. 副本超出了 MaxAccumulatedBackupLogSizeInMB 限制。

  • 备份计划:要执行定期备份的时间或频率。 可以将备份安排为按指定的时间间隔或者每日/每周在固定的时间进行。

    1. 基于频率的备份计划:如果需要按固定时间间隔执行数据备份,应使用此计划类型。 两个连续备份之间的所需时间间隔是使用 ISO8601 格式定义的。 基于频率的备份计划支持的时间间隔分辨率为分钟。

      {
          "ScheduleKind": "FrequencyBased",
          "Interval": "PT10M"
      }
      
    2. 基于时间的备份计划:如果需要在每天或每周的特定时间执行数据备份,应使用此计划类型。 计划频率类型可以是每日或每周。

      1. 每日基于时间的备份计划:如果需要在每天的特定时间执行数据备份,应使用此计划类型。 若要指定此计划类型,请将 ScheduleFrequencyType 设置为 Daily,将 RunTimes 以 ISO8601 格式设置为每天中的所需时间的列表,随时间一起指定的日期将被忽略。 例如,0001-01-01T18:00:00 表示每天下午 6:00 ,忽略日期部分 0001-01-01。 下面的示例展示了在每天上午 9:00 和下午 6:00 点触发每日备份的配置。

        {
            "ScheduleKind": "TimeBased",
            "ScheduleFrequencyType": "Daily",
            "RunTimes": [
              "0001-01-01T09:00:00Z",
              "0001-01-01T18:00:00Z"
            ]
        }
        
      2. 每周基于时间的备份计划:如果需要在每天的特定时间执行数据备份,应使用此计划类型。 若要指定此计划类型,请将 ScheduleFrequencyType 设置为 Weekly,将 RunDays 设置为需要触发备份的星期几的列表,将 RunTimes 以 ISO8601 格式设置为每天中的所需时间的列表,随时间一起指定的日期将被忽略。 要触发定期备份的星期几的列表。 下面的示例展示了从星期一到星期五在上午 9:00 和下午 6:00 点触发每日备份的配置。

        {
            "ScheduleKind": "TimeBased",
            "ScheduleFrequencyType": "Weekly",
            "RunDays": [
               "Monday",
               "Tuesday",
               "Wednesday",
               "Thursday",
               "Friday"
            ],
            "RunTimes": [
              "0001-01-01T09:00:00Z",
              "0001-01-01T18:00:00Z"
            ]
        }
        
  • 备份存储:指定要将备份上传到的位置。 存储可以是 Azure Blob 存储或文件共享。

    1. 具有托管标识的 Azure blob 存储:需要将生成的备份存储在 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 与用户分配的托管标识的客户端 ID(如果分配给资源或同时分配了 SAMI 和 UAMI 的多个用户分配的托管标识),我们需要使用 UAMI 作为默认值,否则不需要此参数。

      遵循 Azure 资源上的托管标识分配的步骤:

      1. 在 VMSS 中启用系统分配的或用户分配的托管标识在虚拟机规模集上配置托管标识

      2. 将角色分配给 VMSS 托管标识使用 Azure 门户分配 Azure 角色 - Azure RBAC

        1. 至少存储 Blob 数据参与者角色

      有关详细信息,请参阅托管标识

    2. 具有 ConnectionString 的 Azure blob 存储:需要将生成的备份存储在 Azure 中时,应选择此存储类型。 “独立的”和“基于云的”群集都可以使用此存储类型。 描述此存储类型需要提供连接字符串和要将备份上传到的容器的名称。 如果具有指定名称的容器不可用,则在上传备份期间会创建该容器。

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

      注意

      备份还原服务不适用于 v1 Azure 存储 ConnectionString,不建议在生产环境中使用,因为无需用户身份验证即可直接访问资源

    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 中,应用程序、服务和分区之间的关系是分层的,如应用程序模型中所述。 备份策略可以与层次结构中的“应用程序”、“服务”或“分区”相关联。 备份策略将按层次结构传播到下一级别。 假设仅创建了一个备份策略并将其与某个应用程序相关联,则所有属于该应用程序的所有“可靠有状态服务”Reliable Actors 的有状态分区都将使用该备份策略进行备份。 或者,如果该备份策略与某个可靠有状态服务相关联,则其所有分区都将使用该备份策略进行备份。

替代备份策略

某些情况下,应用程序的大多数服务的数据备份要求使用相同的备份计划,但某些服务除外,这些服务要求数据备份使用频率更高的计划或者要求将备份存放到不同的存储帐户或文件共享。 为应对这样的情况,备份还原服务提供了相关机制来用于在服务和分区作用域内替代传播的策略。 当备份策略与“服务”或“分区”相关联时,它将替代所传播的任何备份策略。

示例

此示例将设置用于两个应用程序:MyApp_AMyApp_B。 应用程序 MyApp_A 包含两个可靠有状态服务 SvcA1 和 SvcA3,以及一个 Reliable Actors 服务 ActorA2。 SvcA1 包含三个分区,而 ActorA2SvcA3 各包含两个分区。 应用程序 MyApp_B 包含三个可靠有状态服务 SvcB1SvcB2SvcB3_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。 使用启用应用程序备份 API 为应用程序 MyApp_A 启用此策略. 此操作为属于应用程序 MyApp_A 的“可靠有状态服务”Reliable Actors 的所有分区启用使用备份策略 BP_1 的数据备份。

    2. 创建备份策略 BP_2,使其采用基于频率的备份计划且将频率设置为 1 小时。 将备份存储配置为使用存储位置 BackupStore1。 使用启用服务备份 API 为服务 SvcA3 启用此策略。 此操作将使用显式启用的备份策略 BP_2 为服务 SvcA3 的所有分区替代传播的策略 BP_1,从而导致使用备份策略 BP_2 为这些分区执行数据备份。

    3. 创建备份策略 BP_3,使其采用基于频率的备份计划且将频率设置为 24 小时。 将备份存储配置为使用存储位置 BackupStore2。 使用启用分区备份 API 为分区 SvcA1_P2 启用此策略。 此操作将使用显式启用的备份策略 BP_3 为分区 SvcA1_P2 替代传播的策略 BP_1

  2. MyApp_B

    1. 创建备份策略 BP_4,使其采用基于时间的备份计划,将计划频率类型设置为每周,将运行日设置为星期日,将运行时间设置为早上 8:00。 将备份存储配置为使用存储位置 BackupStore1。 使用启用服务备份 API 为服务 SvcB1 启用此策略。 此操作为服务 SvcB1 的所有分区启用使用备份策略 BP_4 的数据备份。

    2. 创建备份策略 BP_5,使其采用基于时间的备份计划,将计划频率类型设置为每日,将运行时间设置为早上 8:00。 将备份存储配置为使用存储位置 BackupStore1。 使用启用分区备份 API 为分区 SvcB2_P1 启用此策略。 此操作为分区 SvcB2_P1 启用使用备份策略 BP_5 的数据备份。

下图描绘了显式启用的备份策略和传播的备份策略。

Service Fabric 应用程序层次结构

禁用备份

不需要对数据进行备份时,可以禁用备份策略。 在“应用程序” 上启用的备份策略只能在同一“应用程序” 上使用禁用应用程序备份 API 进行禁用,在“服务” 上启用的备份策略可以在同一“服务” 上使用禁用服务备份 API 进行禁用,在“分区” 上启用的备份策略可以在同一“分区” 上使用禁用分区备份 API 进行禁用。

  • 为“应用程序” 禁用备份策略将停止因为传播到可靠有状态分区或 Reliable Actors 分区的备份策略而发生的所有定期数据备份。

  • 为“服务”禁用备份策略将停止因为传播到“服务”的分区的此备份策略而发生的所有定期数据备份。

  • 为“分区” 禁用备份策略将停止因为分区处的备份策略而发生的所有定期数据备份。

  • 禁用实体(应用程序/服务/分区)的备份时,可将 CleanBackup 设置为 true 以删除配置存储中的所有备份。

    {
        "CleanBackup": true 
    }
    

注意

在禁用备份之前,请确保没有正在进行的应用程序升级

暂停和恢复备份

某些情况下可能需要临时暂停定期数据备份。 在这种情况下,可以根据需要在“应用程序”、“服务”或“分区”上使用暂停备份 API。 定期备份暂停将在应用程序层次结构的子树中从应用暂停的点开始向下传递。

  • 当在某个“应用程序” 上使用暂停应用程序备份 API 应用暂停时,此应用程序下的所有服务和分区都将暂停定期数据备份。

  • 当在某个“服务” 上使用暂停服务备份 API 应用暂停时,此服务下的所有分区都将暂停定期数据备份。

  • 当在某个“分区” 上使用暂停分区备份 API 应用暂停时,此分区将暂停定期数据备份。

不再需要暂停时,可以使用各自的恢复备份 API 来恢复定期数据备份。 必须在暂停定期备份时所在的同一“应用程序”、“服务”或“分区”上进行恢复。

  • 如果暂停是在“应用程序”上应用的,则应当使用恢复应用程序备份 API 进行恢复。

  • 如果暂停是在“服务”上应用的,则应当使用恢复服务备份 API 进行恢复。

  • 如果暂停是在“分区”上应用的,则应当使用恢复分区备份 API 进行恢复。

暂停备份与禁用备份之间的差异

当特定的应用程序、服务或分区不再需要备份时,应当禁用备份。 用户可以在将“清理备份”参数设置为 true 的情况下调用禁用备份请求,这意味着所有现有备份也将被删除。 但是,暂停将用于以下场景:当用户希望暂时关闭备份时,例如,当本地磁盘已满或者上传备份由于已知的网络问题等而失败时。

只能在先前显式启用备份的级别调用禁用,但是可以在当前直接或通过继承/层次结构启用备份的任何级别应用暂停。 例如,如果在某个应用程序级别启用了备份,则用户只能在该应用程序级别调用禁用,但是可以在该应用程序上以及该应用程序下的任何服务或分区上调用暂停。

在数据丢失时自动还原

服务分区可能会由于意外故障而导致数据丢失。 例如,分区的三个副本中两个副本(包括主副本)的磁盘数据已损坏或被擦除。

当 Service Fabric 检测到分区丢失了数据时,它会对分区调用 OnDataLossAsync 接口方法并期望分区采取所需的操作来避免数据丢失。 在这种情况下,如果在分区上生效的备份策略将 AutoRestoreOnDataLoss 标志设置为 true,则将自动触发还原并使用此分区的最新可用备份。

注意

建议不要在生产群集中设置自动还原

获取备份配置

有单独的 API 可用来在“应用程序”、“服务”和“分区”作用域内获取备份配置信息。 这些 API 分别是获取应用程序备份配置信息获取服务备份配置信息获取分区备份配置信息。 这些 API 主要返回适用的备份策略、备份策略应用于的作用域以及备份暂停详细信息。 下面是有关这些 API 的返回结果的简要说明。

  • 应用程序备份配置信息:提供在应用程序上应用的备份策略的详细信息,以及在属于该应用程序的服务和分区上被替代的所有策略。 它还包括应用程序及其服务和分区的暂停信息。

  • 服务备份配置信息:提供在服务上生效的备份策略的详细信息,此策略应用的作用域,以及其分区上被替代的所有策略。 它还包括服务及其分区的暂停信息。

  • 分区备份配置信息:提供在分区上生效的备份策略的详细信息,以及此策略应用于的作用域。 它还包括分区的暂停信息。

列出可用备份

可以使用获取备份列表 API 列出可用备份。 此 API 调用的结果包括与备份存储上可用的所有备份相关的备份信息项,备份存储是在适用的备份策略中配置的。 提供了此 API 的不同变体,用以列出属于应用程序、服务或分区的可用备份。 这些 API 支持获取所有适用的分区的“最新”可用备份,也支持根据“开始日期”和“结束日期”来筛选备份。

这些 API 还支持对结果进行分页,当 MaxResults 参数设置为非零正整数时,API 将返回最多 MaxResults 个备份信息项。 如果可用的备份信息项多于 MaxResults 值,则会返回一个继续标记。 可以使用有效的继续标记参数来获取下一组结果。 将有效的继续标记值传递给下一次 API 调用时,该 API 将返回下一组结果。 当返回了所有可用结果时,响应中将不包含继续标记。

下面是有关受支持变体的简要信息。

后续步骤