Прочитать на английском

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


Рекомендации по аварийному восстановлению и миграции Microsoft Purview

Примечание

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

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

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

Совет

Дополнительные сведения о надежности Microsoft Purview см. в нашей документации по надежности.

Обеспечение непрерывности бизнес-процессов для Microsoft Purview

Непрерывность бизнес-процессов и аварийное восстановление (BCDR) в экземпляре Microsoft Purview относится к механизмам, политикам и процедурам, которые позволяют вашему бизнесу защитить потерю данных и продолжить работу в условиях сбоя, особенно на уровнях сканирования, каталога и аналитики. На этой странице объясняется, как настроить среду аварийного восстановления для 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, Azure Data Share и Synapse Analytics, если применимо. В результате происхождение данных из Фабрика данных Azure и Azure Data Share не может быть видно в дополнительных учетных записях Microsoft Purview. Это ограничение будет устранено при поддержке автоматического BCDR.

  • Среды выполнения интеграции относятся к учетной записи Microsoft Purview. Таким образом, сканирование должно выполняться в основной и вторичной учетных записях Microsoft Purview параллельно, необходимо поддерживать несколько локальных сред выполнения интеграции. Это ограничение также будет устранено при поддержке автоматического BCDR.

  • Параллельное выполнение проверок из основной и вторичной учетных записей Microsoft Purview в одном источнике может повлиять на производительность источника. Это может привести к тому, что длительность сканирования зависит от учетных записей Microsoft Purview.

  • Не рекомендуется создавать резервные копии "сканированных" ресурсов. Следует создавать резервные копии только проверенных данных, таких как сопоставление классификаций и глоссарий ресурсов. Единственный случай, когда требуется создать резервную копию сведений о ресурсах, — это когда у вас есть пользовательские ресурсы с помощью пользовательского typeDef.

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

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

Шаги для обеспечения непрерывности бизнес-процессов

Создание учетной записи

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

  • Имя учетной записи
  • Region
  • Подписка
  • Управление именем группы ресурсов

Перенос элементов конфигурации

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

Задача Описание
Сведения об учетной записи Обслуживание сведений об учетной записи путем предоставления доступа администратору и (или) субъекту-службе к учетной записи на корневом уровне.
Коллекции Создание и обслуживание коллекций, а также связь источников с коллекциями. Вы можете вызвать API списков коллекций, а затем получить конкретные сведения о каждой коллекции с помощью API получения коллекции.
Набор правил сканирования Создание и обслуживание настраиваемых наборов правил проверки. Необходимо вызвать API списка настраиваемых наборов правил проверки и получить сведения, вызвав API получения набора правил проверки.
Классификации вручную Получение списка всех классификаций вручную путем вызова API get classifications и получения сведений о каждой классификации
Правило набора ресурсов Создание и обслуживание правила набора ресурсов. Вы можете вызвать API получения правила набора ресурсов , чтобы получить сведения о правиле.
Источники данных Вызовите API Получения всех источников данных , чтобы получить список источников данных с подробными сведениями. Кроме того, необходимо получить триггеры, вызвав API get trigger. Кроме того, существует API создания источников данных , если необходимо повторно создать источники в новой учетной записи.
Учетные данные Создание и обслуживание учетных данных, используемых при проверке. Не существует API для извлечения учетных данных, поэтому их необходимо переделать в новой учетной записи.
Локальная среда выполнения интеграции (SHIR) Получите список SHIR и получите обновленные ключи из новой учетной записи, а затем обновите SHIR. Это необходимо сделать вручную внутри узлов SHIR. Они должны быть запущены перед созданием проверок.
Подключения ADF В настоящее время ADF можно подключить к одному Microsoft Purview за раз. Необходимо отключить ADF от учетной записи Microsoft Purview, завершив ошибку, и повторно подключить ее к новой учетной записи позже.

Выполнение проверок

Важно!

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

При этом все ресурсы будут заполнены значением по умолчанию typedef. Существует несколько причин для повторного выполнения сканирования и экспорта существующих ресурсов и импорта в новую учетную запись:

  • Существует ограничение в 100 000 ресурсов, возвращенных из поискового запроса для экспорта ресурсов.

  • Экспорт ресурсов с связями является громоздким.

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

  • Microsoft Purview регулярно предоставляет новые функции, чтобы вы могли воспользоваться другими функциями при выполнении новых проверок.

Выполнение проверок является наиболее эффективным способом получения всех ресурсов источников данных, которые уже поддерживает Microsoft Purview.

Перенос настраиваемых типов и пользовательских ресурсов

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

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

Для идентификации всех пользовательских typedefможно использовать API получения всех определений типов. При этом будут возвращены все типы. Необходимо определить настраиваемые типы в таком формате, как "serviceType": "<custom_typedef>"

Пользовательские ресурсы

Чтобы экспортировать настраиваемые ресурсы, можно выполнить поиск в этих настраиваемых ресурсах и передать их с помощью API обнаружения.typedef

Примечание

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

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

  • Использование Keyword: передайте родительское полное доменное имя, например 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 значения должны иметь значение NULL, например updateTime, updateTimeи lastModifiedTS.

  • guid Нельзя повторно создать так же, как раньше, поэтому необходимо передать отрицательное целое число, например "-5000", чтобы избежать ошибки.

  • Содержимое relationshipAttributes не должно быть частью полезных данных, чтобы избежать ошибок, так как возможно, что guids они не совпадают или еще не созданы. Перед отправкой полезных данных необходимо преобразовать relationshipAttributes в пустой массив.

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

Связи миграции

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

  1. Вызов API отношений для получения сведений о связях между сущностями по guid

  2. Подготовьте полезные данные связи, чтобы в старых учетных записях Microsoft Purview не было жесткой ссылки на старые guids учетные записи Microsoft Purview. Необходимо обновить их guids до новой учетной guidsзаписи .

  3. Наконец, создайте новую связь между сущностями.

Перенос терминов глоссария

Примечание

Перед переносом терминов необходимо перенести шаблоны терминов. Этот шаг уже должен быть описан в пользовательской typedef миграции.

Использование портала управления Microsoft Purview

Самый быстрый способ переноса терминов глоссария — экспорт терминов в файл .csv. Это можно сделать с помощью портала управления Microsoft Purview.

Использование API Microsoft Purview

Чтобы автоматизировать миграцию глоссария, сначала необходимо получить глоссарий guid (glossaryGuid) через API глоссария списка. — glossaryGuid это глоссарий guidверхнего или корневого уровня.

В приведенном ниже примере ответа будет предоставлен guid для использования для последующих вызовов API:

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

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

  1. Экспорт терминов глоссария как .csv

  2. Импорт терминов глоссария через .csv

Назначение классификаций ресурсам

Примечание

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

Чтобы получить назначения классификации для ресурсов, необходимо вызвать API обнаружения . Это применимо ко всем ресурсам. Если вы перенесли пользовательские ресурсы, сведения о назначениях классификации уже доступны в classifications свойстве . Другой способ получения классификаций — вывод списка классификаций в guid старой учетной записи.

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

Назначение контактов ресурсам

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

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