Microsoft Purview 灾难恢复和迁移最佳做法

项目
04/12/2024

本文提供有关组织在生产部署中使用 Microsoft Purview 统一治理解决方案时的备份和恢复策略的指导。还可使用此一般准则来实现帐户迁移。本文的范围是介绍手动 BCDR 方法，你可以在其中使用 API 自动执行操作。

Azure 数据中心很少发生故障，但可能会持续数分钟到数小时之久。数据中心发生故障可能会导致对数据管理所依赖的环境出现中断。通过执行本文介绍的详细步骤，便可在 Microsoft Purview 帐户的主要区域发生数据中心故障时继续管理数据。

提示

有关 Microsoft Purview 可靠性的详细信息，请参阅我们的可靠性文档。

实现 Microsoft Purview 的业务连续性

Microsoft Purview 实例中的业务连续性和灾难恢复 (BCDR) 是指能够让你的企业在面临中断时防止数据丢失并继续运营的机制、策略和过程，尤其是在其扫描、目录和见解层。本页介绍如何为 Microsoft Purview 配置灾难恢复环境。

目前，Microsoft Purview 不支持自动化 BCDR。在添加该支持前，你要负责处理备份和还原活动。你可以在另一个区域手动创建 Microsoft Purview 次级帐户作为热备用实例。

以下步骤对如何手动实现灾难恢复进行了汇总：

创建主要 Microsoft Purview 帐户后，在单独的区域中创建一个或多个辅助 Microsoft Purview 帐户。

重要

Microsoft Purview 目前支持每个租户的单个 Microsoft Purview 实例。要创建用于备份和灾难恢复的第二个帐户，请联系客户支持
在 Microsoft Purview 主要帐户上执行的所有活动也必须在 Microsoft Purview 次级帐户上执行。这包括：
- 维护帐户信息
- 创建和维护自定义扫描规则集、分类和分类规则
- 注册和扫描源
- 创建和维护集合以及源与集合之间的关联
- 创建和维护扫描时使用的凭据
- 评判数据资产
- 创建和维护术语表术语

本文后面提供了创建和维护灾难恢复帐户的具体步骤。在遵循它们之前，请阅读限制和注意事项。

限制和注意事项

创建手动 BCDR 计划时，请记住以下要点：

主实例和辅助 Microsoft Purview 实例将会向你收费。
不得将 Microsoft Purview 主要和辅助帐户配置为相同的 Azure 数据工厂、Azure Data Share 和 Synapse Analytics 帐户（如果适用）。因此，辅助 Microsoft Purview 帐户无法显示 Azure 数据工厂和 Azure Data Share 的世系。如果支持自动化 BCDR，则会解决此限制。
集成运行时特定于 Microsoft Purview 帐户。因此，扫描需要在 Microsoft Purview 主要和辅助帐户中并行运行，并且必须维护多个自承载集成运行时。当支持自动 BCDR 时，此限制也会得到解决。
在同一源上对 Microsoft Purview 主要和次级帐户并行执行扫描可能会影响到源的性能。这可能导致不同 Microsoft Purview 帐户的扫描持续时间有所差异。
不建议备份“扫描”资产的详细信息。只应备份特选数据，例如资产分类和术语表的映射。唯一需要备份资产详细信息的情况是你通过自定义 typeDef 拥有自定义资产。
备份的资产计数应少于 100,000 个资产。主要驱动因素是，你必须使用搜索查询 API 获取资产，其返回的资产数限制为 100,000。但是，如果能够将搜索查询分段，以获取每个 API 调用的较小资产数，则可以备份超过 100,000 个资产。
如果希望在两个帐户之间持续“同步”资产，则存在本文不会详细介绍的其他步骤。必须使用 Microsoft Purview 的事件中心来订阅和创建另一个帐户实体。但是，事件中心只有 Atlas 信息。 Microsoft Purview 添加了其他功能，例如无法通过事件中心获取的术语表和联系人。

实现业务连续性的步骤

创建新帐户

如果组织已有多个 Microsoft Purview 帐户，则可以按照本指南说明创建新的 Microsoft Purview 帐户：快速入门：在 Azure 门户中创建 Microsoft Purview 帐户
如果组织只有一个租户/组织 Microsoft Purview 帐户，则要创建用于备份和恢复的账户，请联系客户支持。

规划以后无法更改的以下配置项目：

帐户名
区域
订阅
管理资源组名称

迁移配置项目

以下步骤引用 Microsoft Purview API 文档，以便可以通过编程方式快速启动备份帐户：

任务	说明
帐户信息	通过授予管理员和/或服务主体对根级别帐户的访问权限来维护帐户信息
集合	创建和维护集合以及源与集合之间的关联。可以调用列表集合 API，然后通过获取集合 API 获取每个集合的特定详细信息
扫描规则集	创建和维护自定义扫描规则集。需要调用“列出自定义扫描规则集 API”，并通过调用“获取扫描规则集 API”来获取详细信息
手动分类	通过调用“获取分类 API”获取所有手动分类的列表，并获取每个分类的详细信息
资源集规则	创建和维护资源集规则。可以调用获取资源集规则 API 来获取规则详细信息
数据源	调用获取所有数据源 API以列出包含详细信息的数据源。还必须通过调用获取触发器 API 获取触发器。如果需要在新帐户中批量重新创建源，还可以调用创建数据源 API。
凭据	创建和维护扫描时使用的凭据。没有用于提取凭据的 API，因此必须在新帐户中重新进行此操作。
自承载集成运行时 (SHIR)	获取 SHIR 列表，从新帐户获取更新的密钥，然后更新 SHIR。必须在 SHIR 的主机内手动完成此操作。创建扫描之前，需要先运行这些组件。
ADF 连接	目前，ADF 可以一次连接到一个 Microsoft Purview。必须从失败的 Microsoft Purview 帐户断开 ADF 连接，稍后再将其重新连接到新帐户。

运行扫描

重要

在创建扫描之前，请确保已配置自承载集成运行时，并且该运行时正在运行且可用。

这会使用默认 typedef 填充所有资产。重新运行扫描，而不是导出现有资产并导入到新帐户，有以下几个原因：

从搜索查询以导出资产中返回的资产限制为 100,000 个。
导出具有关系的资产很麻烦。
重新运行扫描时，将获取所有最新的关系和资产详细信息。
Microsoft Purview 会定期提供新功能，因此可以在运行新扫描时从其他功能中受益。

运行扫描是获取 Microsoft Purview 已支持的所有数据源资产的最有效方法。

迁移自定义 typedef 和自定义资产

如果组织已在 Microsoft Purview 中创建了自定义类型，则需要手动迁移这些类型。

自定义 typedef

若要标识所有自定义 typedef，可以使用获取所有类型定义 API。这将返回每种类型。你需要以 "serviceType": "<custom_typedef>" 这样的格式标识自定义类型

自定义资产

若要导出自定义资产，可以搜索这些自定义资产，并通过发现 API 传递正确的自定义 typedef

注意

每个搜索结果的返回限制为 100,000。你可能需要中断搜索查询，这样它不会返回超过 100,000 个记录。

有几种方法可以缩小搜索查询的范围，以获取资产的子集：

使用 Keyword：传递父 FQN，例如 Keyword: "<Parent String>/*"
使用 Filter：在搜索中包含具有特定自定义 typedef 的 assetType，例如 "assetType": "<custom_typedef>"

下面是通过自定义 keywords 的搜索有效负载示例，以便仅返回特定存储帐户 (exampleaccount) 中的资产：

{
  "keywords": "adl://exampleaccount.azuredatalakestore.net/*",
  "filter": {
    "and": [
      {
        "not": {
          "or": [
            {
              "attributeName": "size",
              "operator": "eq",
              "attributeValue": 0
            },
            {
              "attributeName": "fileSize",
              "operator": "eq",
              "attributeValue": 0
            }
          ]
        }
      },
      {
        "not": {
          "classification": "MICROSOFT.SYSTEM.TEMP_FILE"
        }
      },
      {
        "not": {
          "or": [
            {
              "entityType": "AtlasGlossaryTerm"
            },
            {
              "entityType": "AtlasGlossary"
            }
          ]
        }
      }
    ]
  },
  "limit": 10,
  "offset": 0,
  "facets": [
    {
      "facet": "assetType",
      "count": 0,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "classification",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "contactId",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "label",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    },
    {
      "facet": "term",
      "count": 10,
      "sort": {
        "count": "desc"
      }
    }
  ]
}

返回的资产将会有一些键值对，可从中提取详细信息：

{
    "referredEntities": {},
    "entity": {
    "typeName": "column",
    "attributes": {
        "owner": null,
        "qualifiedName": "adl://exampleaccount.azuredatalakestore.net/123/1/DP_TFS/CBT/Extensions/DTTP.targets#:xml/Project/Target/XmlPeek/@XmlInputPath",
        "name": "~XmlInputPath",
        "description": null,
        "type": "string"
    },
    "guid": "5cf8a9e5-c9fd-abe0-2e8c-d40024263dcb",
    "status": "ACTIVE",
    "createdBy": "ExampleCreator",
    "updatedBy": "ExampleUpdator",
    "createTime": 1553072455110,
    "updateTime": 1553072455110,
    "version": 0,
    "relationshipAttributes": {
        "schema": [],
        "inputToProcesses": [],
        "composeSchema": {
        "guid": "cc6652ae-dc6d-90c9-1899-252eabc0e929",
        "typeName": "tabular_schema",
        "displayText": "tabular_schema",
        "relationshipGuid": "5a4510d4-57d0-467c-888f-4b61df42702b",
        "relationshipStatus": "ACTIVE",
        "relationshipAttributes": {
            "typeName": "tabular_schema_columns"
        }
        },
        "meanings": [],
        "outputFromProcesses": [],
        "tabular_schema": null
    },
    "classifications": [
        {
        "typeName": "MICROSOFT.PERSONAL.EMAIL",
        "lastModifiedTS": "1",
        "entityGuid": "f6095442-f289-44cf-ae56-47f6f6f6000c",
        "entityStatus": "ACTIVE"
        }
    ],
    "contacts": {
        "Expert": [
        {
            "id": "30435ff9-9b96-44af-a5a9-e05c8b1ae2df",
            "info": "Example Expert Info"
        }
        ],
        "Owner": [
        {
            "id": "30435ff9-9b96-44af-a5a9-e05c8b1ae2df",
            "info": "Example Owner Info"
        }
        ]
    }
    }
}

注意

还需要从 typedef 输出中迁移术语模板。

重新创建自定义实体时，可能需要在发送到 API 之前准备有效负载：

注意

初始目标是迁移所有没有任何关系或映射的实体。这将避免潜在错误。

所有 timestamp 值必须为 null，例如 updateTime、updateTime 和 lastModifiedTS。
无法像以前一样重新生成 guid，因此必须传递负整数（例如“-5000”）以避免错误。
relationshipAttributes 的内容不应是避免错误的有效负载的一部分，因为 guids 可能不同或尚未创建。提交有效负载之前，必须将 relationshipAttributes 转换为空数组。
- meanings 包含所有术语表映射，这些映射将在创建实体后批量更新。
同样，classifications 在提交有效负载以创建实体时也需要是空数组，因为你稍后必须使用不同的 API 创建到批量实体的分类映射。

迁移关系

若要完成资产迁移，必须重新映射关系。有以下三个任务：

调用关系 API，以通过其 guid 获取实体之间的关系信息
准备关系有效负载，以便不会硬引用旧 Microsoft Purview 帐户中的旧 guids。需要将这些 guids 更新为新帐户的 guids。
最后，创建实体之间的新关系

迁移术语表术语

注意

在迁移术语之前，需要迁移术语模板。此步骤应已在自定义 typedef 迁移中说明。

使用 Microsoft Purview 治理门户

迁移术语表术语的最快速方法是将术语导出到 .csv文件。可以使用 Microsoft Purview 治理门户来执行此操作。

使用 Microsoft Purview API

若要自动执行术语表迁移，首先需要通过列出术语表 API获取术语表 guid (glossaryGuid)。 glossaryGuid 为顶级/根级别术语表 guid。

下面的示例响应将提供 guid，用于后续 API 调用：

"guid": "c018ddaf-7c21-4b37-a838-dae5f110c3d8"

获取 glossaryGuid 后，可以通过以下两个步骤开始迁移术语：

将分类分配给资产

注意

此步骤的先决条件是在迁移配置项目步骤中的新帐户中提供所有分类。

必须调用发现 API，才能获取资产的分类分配。这适用于所有资产。如果已迁移自定义资产，则有关分类分配的信息已在 classifications 属性中提供。获取分类的另一种方法是根据旧帐户中的 guid 列出分类。

若要为资产分配分类，需要通过 API 将分类批量关联到多个实体。

为资产分配联系人

如果从前面的步骤中提取了资产信息，可从发现 API 中获取联系人详细信息。

若要将联系人分配给资产，需要一个 guids 列表并标识所有联系人的 objectid。可以通过循环访问所有资产来自动执行此过程，并使用创建或更新实体 API 将联系人重新分配给所有资产。

通过