Рекомендации по аварийному восстановлению и миграции Microsoft Purview
Примечание
Каталог данных Microsoft Purview меняется на Единый каталог Microsoft Purview. Все функции останутся неизменными. Вы увидите изменение имени, когда новый интерфейс управления данными Microsoft Purview станет общедоступным в вашем регионе. Проверьте имя в регионе.
В этой статье содержатся рекомендации по стратегии резервного копирования и восстановления, если в вашей организации есть унифицированные решения по управлению Microsoft Purview в рабочей среде. Вы также можете использовать это общее руководство для реализации миграции учетных записей. В этой статье область рассматриваются ручные методы BCDR, в которых можно автоматизировать с помощью API.
Сбои центра обработки данных Azure встречаются редко, но могут длиться от нескольких минут до нескольких часов. Сбои центра обработки данных могут привести к нарушению работы сред, на которые полагаются для управления данными. Выполнив действия, описанные в этой статье, можно продолжить управление данными в случае сбоя центра обработки данных в основном регионе учетной записи Microsoft Purview.
Совет
Дополнительные сведения о надежности Microsoft Purview см. в нашей документации по надежности.
Непрерывность бизнес-процессов и аварийное восстановление (BCDR) в экземпляре Microsoft Purview относится к механизмам, политикам и процедурам, которые позволяют вашему бизнесу защитить потерю данных и продолжить работу в условиях сбоя, особенно на уровнях сканирования, каталога и аналитики. На этой странице объясняется, как настроить среду аварийного восстановления для 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, если применимо. В результате происхождение данных из Фабрика данных 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 добавила другие возможности, такие как глоссарии и контакты , которые не будут доступны через Центры событий.
Если в вашей организации уже есть несколько учетных записей Microsoft Purview, вы можете создать новую учетную запись Microsoft Purview, следуя инструкциям из следующего руководства: Краткое руководство. Создание учетной записи Microsoft Purview в портал Azure
Если в вашей организации есть только одна учетная запись клиента или организации 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.
Чтобы завершить миграцию ресурсов, необходимо переназначить связи. Существует три задачи:
Вызов API отношений для получения сведений о связях между сущностями по
guid
Подготовьте полезные данные связи, чтобы в старых учетных записях Microsoft Purview не было жесткой ссылки на старые
guids
учетные записи Microsoft Purview. Необходимо обновить ихguids
до новой учетнойguids
записи .
Примечание
Перед переносом терминов необходимо перенести шаблоны терминов. Этот шаг уже должен быть описан в пользовательской typedef
миграции.
Самый быстрый способ переноса терминов глоссария — экспорт терминов в файл .csv. Это можно сделать с помощью портала управления Microsoft Purview.
Чтобы автоматизировать миграцию глоссария, сначала необходимо получить глоссарий guid
(glossaryGuid
) через API глоссария списка. — glossaryGuid
это глоссарий guid
верхнего или корневого уровня.
В приведенном ниже примере ответа будет предоставлен guid
для использования для последующих вызовов API:
"guid": "c018ddaf-7c21-4b37-a838-dae5f110c3d8"
После того как вы запустите glossaryGuid
, вы можете приступить к переносу условий с помощью двух шагов:
Примечание
Предварительным условием для этого шага является доступность всех классификаций в новой учетной записи на шаге Миграция элементов конфигурации .
Чтобы получить назначения классификации для ресурсов, необходимо вызвать API обнаружения . Это применимо ко всем ресурсам. Если вы перенесли пользовательские ресурсы, сведения о назначениях классификации уже доступны в classifications
свойстве . Другой способ получения классификаций — вывод списка классификаций в guid
старой учетной записи.
Чтобы назначить классификации ресурсам, необходимо связать классификацию с несколькими сущностями в пакетном режиме с помощью API.
Если вы извлекли сведения об активе на предыдущих шагах, контактные данные доступны в API обнаружения.
Чтобы назначить контакты ресурсам, вам потребуется список guids
и идентификация всех objectid
контактов. Этот процесс можно автоматизировать, выполнив итерацию по всем ресурсам и переназначив контакты всем ресурсам с помощью API создания или обновления сущностей.