共用方式為


Microsoft Purview 災害復原和移轉最佳做法

本文提供當您的組織在生產部署中具有 Microsoft Purview 治理解決方案時,備份和復原策略的指引。 您也可以使用此一般準則來實作帳戶移轉。 本文的範圍是涵蓋 BCDR) 方法 (手動商務持續性和災害復原,您可以在其中使用 API 自動化。

Azure 數據中心中斷很少見,但可能會持續幾分鐘到幾小時不等。 資料中心中斷可能會導致依賴資料控管的環境中斷。 藉由遵循本文中詳述的步驟,您可以在 Microsoft Purview 帳戶的主要區域發生資料中心中斷時繼續控管您的資料。

提示

尋找 Microsoft Purview 可靠性的詳細資訊。

實現 Microsoft Purview 的業務持續性

Microsoft Purview 實例中的 BCDR 是指可讓您的企業保護數據遺失並在面臨中斷時繼續運作的機制、原則和程式,特別是其掃描、傳統目錄和傳統深入解析層。 本頁說明如何設定 Microsoft Purview 的災害復原環境。

目前,Microsoft Purview 不支援自動化 BCDR。 在新增該支援之前,您有責任處理備份和還原活動。 您可以手動將次要 Microsoft Purview 帳戶建立為另一個區域中的暖待命執行個體。

下列步驟摘要說明如何手動實現災難復原:

  1. 建立主要 Microsoft Purview 帳戶之後,請在個別區域中建立一或多個次要 Microsoft Purview 帳戶。

    重要事項

    Microsoft Purview 目前支援每個租用戶的單一 Microsoft Purview 實例。 若要建立第二個帳戶進行備份和災難復原, 請聯絡支援人員

  2. 在主要 Microsoft Purview 帳戶上執行的所有活動也必須在次要 Microsoft Purview 帳戶上執行。 這包括:

    • 維護帳戶資訊
    • 建立和維護自訂掃描規則集、分類和分類規則
    • 註冊和掃描來源
    • 建立和維護集合,以及來源與集合的關聯
    • 建立和維護掃描時使用的認證
    • 策劃資料資產
    • 建立和維護詞彙表術語

本文稍後會提供建立和維護災害復原帳戶的特定步驟。 在遵循它們之前,請仔細閱讀限制和注意事項。

限制和考量

當您建立手動 BCDR 計劃時,請記住下列幾點:

  • 您需要支付主要和次要 Microsoft Purview 執行個體的費用。

  • 如果適用,主要和次要 Microsoft Purview 帳戶無法設定為相同的 Azure Data Factory、Azure Data Share 和 Synapse Analytics 帳戶。 因此,在次要 Microsoft Purview 帳戶中看不到來自 Azure Data Factory 和 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 API 檔 ,讓您可以以程式設計方式快速建立備份帳戶:

工作 描述
帳戶資訊 藉由在根層級授與系統管理員和/或服務主體對帳戶的存取權來維護帳戶資訊
Collections 建立和維護集合以及來源與集合的關聯。 您可以呼叫清單集合 API,然後透過取得集合 API 取得每個集合的特定詳細資料
掃描規則集 建立和維護自訂掃描規則集。 您需要呼叫列出自訂掃描規則集 API,並呼叫取得掃描規則集 API 來取得詳細資料
手動分類 呼叫取得分類 API 來取得所有手動分類的清單,並取得每個分類的詳細資料
資源集規則 建立和維護資源集規則。 您可以呼叫 取得資源集規則 API 來取得規則詳細資料
資料來源 呼叫 取得所有資料來源 API ,以列出具有詳細資料的資料來源。 您也必須呼叫 取得觸發程式 API 來取得觸發程式。 如果您需要在新帳戶中大量重新建立來源,還有建立 資料來源 API
證件 建立並維護掃描時使用的認證。 沒有 API 可擷取認證,因此必須在新帳戶中重做。
自我裝載整合執行階段 (SHIR) 獲取 SHIR 列表並從新帳戶獲取更新的密鑰,然後更新 SHIR。 這必須在 SHIR 的主機內手動完成。 在建立掃描之前,必須先執行這些掃描。
ADF 連線 目前,ADF 一次可以連線到一個 Microsoft Purview。 您必須中斷 ADF 與失敗的 Microsoft Purview 帳戶的連線,稍後再重新連線到新帳戶。

執行掃描

重要事項

在建立掃描之前,請確定您的 自我裝載整合執行階段 已設定,且正在執行且可用。

這會使用預設 typedef填入所有資產。 與匯出現有資產並匯入至新帳戶相比,再次執行掃描有數個原因:

  • 從搜尋查詢傳回的資產數量限制為 100,000 個,以匯出資產。

  • 匯出具有關係的資產很麻煩。

  • 當您重新執行掃描時,您將取得最新的所有關聯性和資產詳細資料。

  • Microsoft Purview 會定期推出新功能,因此您可以在執行新掃描時從其他功能中受益。

執行掃描是取得 Microsoft Purview 已支援之資料來源所有資產的最有效方式。

移轉自訂 typedef 和自訂資產

如果您的組織 已在 Microsoft Purview 中建立自訂類型,您必須手動移轉這些類型。

自訂類型定義

若要識別所有自訂 typedef,您可以使用 取得所有類型定義 API。 這會傳回每個類型。 您需要以以下格式識別自訂類型 "serviceType": "<custom_typedef>"

自訂資產

若要匯出自訂資產,您可以搜尋這些自訂資產,並透過探索API傳遞適當的自訂typedef

注意事項

每個搜尋結果有 100,000 次傳回限制。 您可能必須中斷搜尋查詢,使其不會傳回超過 100,000 筆記錄。

有數種方式可縮小搜尋查詢範圍,以取得資產子集:

  • 使用: Keyword傳遞父 FQN,例如 Keyword: "<Parent String>/*"
  • 使用: Filter在您的搜尋中包含 assetType 特定自訂 typedef ,例如 "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 必須為空值,例如 updateTimeupdateTimelastModifiedTS

  • 無法完全像以前一樣重新生成, guid 因此您必須傳入負整數,例如“-5000”以避免錯誤。

  • 的內容 relationshipAttributes 不應該是承載的一部分,以避免錯誤,因為可能 guids 不相同或尚未建立。 您必須 relationshipAttributes 先變成空陣列,才能提交有效負載。

    • meanings 包含所有詞彙表對應,這些對應將在建立實體後大量更新。
  • 同樣地,當您提交承載以建立實體時, classifications 也必須是空陣列,因為您必須稍後使用不同的 API 建立大量實體的分類對應。

移轉關聯性

若要完成資產移轉,您必須重新對應關係。 有三個任務:

  1. 呼叫 關係 API ,以取得實體之間的關係資訊,依其 guid

  2. 準備關聯性承載,讓舊的 Microsoft Purview 帳戶中沒有硬 guids 性參考舊的。 您需要將它們 guids 更新為新帳戶的 guids

  3. 最後, 在實體之間建立新的關聯性

移轉詞彙表術語

注意事項

在移轉字詞之前,您必須先移轉字詞範本。 自訂 typedef 移轉中應該已涵蓋此步驟。

使用 Microsoft Purview 治理入口網站

移轉詞彙表術語的最快方式是 將術語匯出至 .csv 檔案。 您可以使用 Microsoft Purview 治理入口網站來執行此動作。

使用 Microsoft Purview API

若要自動化詞彙表移轉,您首先需要透過 List Glossaries API 取得詞彙guid表 (glossaryGuid) 。 是 glossaryGuid 頂層/根層級詞彙表 guid

下列範例回應將提供用於後續 API 呼叫的 :guid

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

擁有 glossaryGuid之後,您可以透過兩個步驟開始移轉條款:

  1. 匯出詞彙表術語為 .csv

  2. 透過 .csv匯入詞彙表術語

將分類指派給資產

注意事項

此步驟的必要條件是讓移 轉組態項目 步驟中的新帳戶中提供所有分類。

您必須呼叫 探索 API 才能取得資產的分類指派。 這適用於所有資產。 如果您已移轉自訂資產,則分類指派的相關資訊已在屬性中 classifications 取得。 獲取分類的另一種方法是在舊帳戶中 列出分類 guid

若要將分類指派給資產,您必須透過 API 將分類大量 與多個實體建立關聯

將聯絡人指派給資產

如果您已從先前的步驟擷取資產資訊,則可從 探索 API 取得聯絡詳細資料。

若要將聯絡人指派給資產,您需要所有聯絡人的清單 guids 並識別 objectid 所有聯絡人。 您可以透過逐一查看所有資產並使用 建立或更新實體 API 將聯絡人重新指派給所有資產來自動化此流程。