Procedimientos recomendados de migración y recuperación ante desastres de Microsoft Purview
Nota
El Catálogo de datos de Microsoft Purview está cambiando su nombre a Catálogo unificado de Microsoft Purview. Todas las características permanecerán iguales. Verá el cambio de nombre cuando la nueva experiencia de gobernanza de datos de Microsoft Purview esté disponible con carácter general en su región. Compruebe el nombre en su región.
En este artículo se proporcionan instrucciones sobre la estrategia de copia de seguridad y recuperación cuando su organización tiene soluciones unificadas de gobernanza de Microsoft Purview en la implementación en producción. También puede usar esta guía general para implementar la migración de cuentas. El ámbito de este artículo es tratar los métodos BCDR manuales, en los que podría automatizar el uso de API.
Las interrupciones del centro de datos de Azure son poco frecuentes, pero pueden durar desde unos minutos hasta horas. Las interrupciones del Centro de datos pueden provocar interrupciones en los entornos en los que se basa para la gobernanza de datos. Siguiendo los pasos detallados en este artículo, puede seguir gobernando los datos en caso de una interrupción del centro de datos para la región principal de su cuenta de Microsoft Purview.
Sugerencia
Para obtener más información sobre la confiabilidad de Microsoft Purview, consulte nuestra documentación de confiabilidad.
La continuidad empresarial y la recuperación ante desastres (BCDR) en una instancia de Microsoft Purview hace referencia a los mecanismos, directivas y procedimientos que permiten a su empresa proteger la pérdida de datos y seguir funcionando frente a interrupciones, especialmente en sus niveles de análisis, catálogo e información. En esta página se explica cómo configurar un entorno de recuperación ante desastres para Microsoft Purview.
En la actualidad, Microsoft Purview no admite BCDR automatizado. Hasta que se agregue esa compatibilidad, es responsable de encargarse de las actividades de copia de seguridad y restauración. Puede crear manualmente una cuenta secundaria de Microsoft Purview como una instancia en espera activa en otra región.
En los pasos siguientes se resume cómo puede lograr la recuperación ante desastres manualmente:
Una vez creada la cuenta principal de Microsoft Purview, cree una o varias cuentas secundarias de Microsoft Purview en una región independiente.
Importante
Microsoft Purview admite actualmente una única instancia de Microsoft Purview por inquilino. Para crear una segunda cuenta para la copia de seguridad y la recuperación ante desastres, póngase en contacto con el soporte técnico.
Todas las actividades realizadas en la cuenta principal de Microsoft Purview también deben realizarse en las cuentas secundarias de Microsoft Purview. Esto incluye lo siguiente:
- Mantener la información de la cuenta
- Creación y mantenimiento de conjuntos de reglas de examen personalizados, clasificaciones y reglas de clasificación
- Registro y examen de orígenes
- Creación y mantenimiento de colecciones junto con la asociación de orígenes con las colecciones
- Creación y mantenimiento de credenciales usadas durante el examen
- Conservación de recursos de datos
- Creación y mantenimiento de términos del glosario
Más adelante en el artículo se proporcionan pasos específicos para crear y mantener una cuenta de recuperación ante desastres. Antes de seguirlas, lea las limitaciones y consideraciones.
A medida que cree el plan BCDR manual, tenga en cuenta los siguientes puntos:
Se le cobrará por las instancias principales y secundarias de Microsoft Purview.
Las cuentas principales y secundarias de Microsoft Purview no se pueden configurar en las mismas cuentas de Azure Data Factory, Azure Data Share y Synapse Analytics, si procede. Como resultado, el linaje de Azure Data Factory y Azure Data Share no se puede ver en las cuentas secundarias de Microsoft Purview. Esta limitación se abordará cuando se admita BCDR automatizado.
Los entornos de ejecución de integración son específicos de una cuenta de Microsoft Purview. Por lo tanto, los exámenes deben ejecutarse en cuentas de Microsoft Purview principales y secundarias en paralelo, se deben mantener varios entornos de ejecución de integración autohospedados. Esta limitación también se abordará cuando se admita BCDR automatizado.
La ejecución en paralelo de exámenes desde cuentas de Microsoft Purview principales y secundarias en el mismo origen puede afectar al rendimiento del origen. Esto puede dar lugar a que las duraciones del examen varían entre las cuentas de Microsoft Purview.
No es aconsejable realizar una copia de seguridad de los detalles de los recursos "examinados". Solo debe realizar una copia de seguridad de los datos seleccionados, como la asignación de clasificaciones y glosarios en recursos. El único caso en el que necesita realizar una copia de seguridad de los detalles de los recursos es cuando tiene recursos personalizados a través de
typeDef
personalizados.El recuento de recursos de copia de seguridad debe ser inferior a 100 000 activos. El controlador principal es que tiene que usar la API de consulta de búsqueda para obtener los recursos, que tienen una limitación de 100 000 recursos devueltos. Sin embargo, si puede segmentar la consulta de búsqueda para obtener un menor número de recursos por llamada API, es posible realizar una copia de seguridad de más de 100 000 recursos.
Si desea "sincronizar" continuamente los recursos entre dos cuentas, hay otros pasos que no se tratarán en detalle en este artículo. Tiene que usar Event Hubs de Microsoft Purview para suscribirse y crear entidades a otra cuenta. Sin embargo, Event Hubs solo tiene información de Atlas. Microsoft Purview ha agregado otras funcionalidades, como glosarios y contactos , que no estarán disponibles a través de Event Hubs.
Si su organización ya tiene varias cuentas de Microsoft Purview, puede crear una nueva cuenta de Microsoft Purview siguiendo esta instrucción de guía: Inicio rápido: Creación de una cuenta de Microsoft Purview en el Azure Portal
Si su organización solo tiene una cuenta de Microsoft Purview de inquilino u organización, para crear una cuenta para el soporte técnico de copia de seguridad y recuperación.
Planee estos elementos de configuración que no puede cambiar más adelante:
- Nombre de cuenta
- Región
- Suscripción
- Administrar el nombre del grupo de recursos
Los pasos siguientes hacen referencia a la documentación de la API de Microsoft Purview para que pueda mantener la cuenta de copia de seguridad rápidamente mediante programación:
Tarea | Descripción |
---|---|
Información de la cuenta | Mantener la información de la cuenta mediante la concesión de acceso para el administrador o la entidad de servicio a la cuenta en el nivel raíz |
Colecciones | Cree y mantenga colecciones junto con la asociación de orígenes con las colecciones. Puede llamar a List Collections API y, a continuación, obtener detalles específicos de cada colección a través de Get Collection API |
Conjunto de reglas de examen | Cree y mantenga conjuntos de reglas de examen personalizados. Debe llamar a la API List custom scan rule sets (Enumerar conjuntos de reglas de examen personalizados ) y obtener detalles llamando a Get scan rule set API (Obtener conjunto de reglas de examen) |
Clasificaciones manuales | Obtenga una lista de todas las clasificaciones manuales llamando a las API get classifications y obtenga detalles de cada clasificación. |
Regla de conjunto de recursos | Cree y mantenga una regla de conjunto de recursos. Puede llamar a la API get resource set rule para obtener los detalles de la regla. |
Orígenes de datos | Llame a la API Get all data sources (Obtener todos los orígenes de datos) para enumerar los orígenes de datos con detalles. También tiene que obtener los desencadenadores llamando a Get trigger API. También hay la API Crear orígenes de datos si necesita volver a crear los orígenes de forma masiva en la nueva cuenta. |
Credenciales | Cree y mantenga las credenciales usadas durante el examen. No hay ninguna API para extraer credenciales, por lo que debe volver a crearse en la nueva cuenta. |
Entorno de ejecución de integración autohospedado (SHIR) | Obtenga una lista de SHIR y obtenga las claves actualizadas de la nueva cuenta y, a continuación, actualice los SHIR. Esto debe realizarse manualmente dentro de los hosts de los SHIR. Deben ejecutarse antes de crear exámenes. |
Conexiones de ADF | Actualmente, un ADF se puede conectar a una instancia de Microsoft Purview a la vez. Debe desconectar ADF de la cuenta de Microsoft Purview con error y volver a conectarla a la nueva cuenta más adelante. |
Importante
Asegúrese de que los entornos de ejecución de integración autohospedados se han configurado y están en ejecución y disponibles antes de crear exámenes.
Esto rellenará todos los recursos con el valor predeterminado typedef
. Hay varias razones para volver a ejecutar los exámenes frente a la exportación de los recursos existentes y la importación a la nueva cuenta:
Hay un límite de 100 000 recursos devueltos por la consulta de búsqueda para exportar recursos.
Es complicado exportar recursos con relaciones.
Al volver a ejecutar los exámenes, obtendrá todos los detalles de relaciones y recursos actualizados.
Microsoft Purview ofrece nuevas características con regularidad para que pueda beneficiarse de otras características al ejecutar nuevos exámenes.
La ejecución de los exámenes es la manera más eficaz de obtener todos los recursos de orígenes de datos que Microsoft Purview ya admite.
Si su organización ha creado tipos personalizados en Microsoft Purview, debe migrarlos manualmente.
Para identificar todos los personalizados typedef
, puede usar la API get all type definitions. Esto devolverá cada tipo. Debe identificar los tipos personalizados en un formato como "serviceType": "<custom_typedef>"
Para exportar recursos personalizados, puede buscar esos recursos personalizados y pasar el personalizado typedef
adecuado a través de la API de detección.
Nota
Hay un límite de 100 000 devoluciones por resultado de búsqueda. Es posible que tenga que interrumpir la consulta de búsqueda para que no devuelva más de 100 000 registros.
Hay varias maneras de reducir el ámbito de la consulta de búsqueda para obtener un subconjunto de recursos:
- Using : Pass the parent FQN such as as
Keyword
Keyword: "<Parent String>/*"
-
Uso de
Filter
: incluirassetType
con la personalizadatypedef
específica en la búsqueda, como"assetType": "<custom_typedef>"
Este es un ejemplo de una carga de búsqueda personalizando para keywords
que solo se devuelvan recursos de una cuenta de almacenamiento específica (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"
}
}
]
}
Los recursos devueltos tendrán algún valor de clave/par que puede extraer detalles:
{
"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"
}
]
}
}
}
Nota
También debe migrar las plantillas de términos de la typedef
salida.
Al volver a crear las entidades personalizadas, es posible que tenga que preparar la carga antes de enviarla a la API:
Nota
El objetivo inicial es migrar todas las entidades sin relaciones ni asignaciones. Esto evitará posibles errores.
Todos los
timestamp
valores deben ser NULL, comoupdateTime
,updateTime
ylastModifiedTS
.guid
No se puede regenerar exactamente como antes, por lo que debe pasar un entero negativo como "-5000" para evitar errores.El contenido de
relationshipAttributes
no debe formar parte de la carga para evitar errores, ya que es posible queguids
no sean iguales o no se hayan creado todavía. Debe convertirserelationshipAttributes
en una matriz vacía antes de enviar la carga.-
meanings
contiene todas las asignaciones del glosario, que se actualizarán de forma masiva después de crear las entidades.
-
De forma similar, también debe ser una matriz vacía al enviar la carga útil para crear entidades,
classifications
ya que tiene que crear la asignación de clasificación a entidades masivas más adelante mediante una API diferente.
Para completar la migración de recursos, debe volver a asignar las relaciones. Hay tres tareas:
Llame a la API de relación para obtener información de relación entre entidades por su
guid
Prepare la carga de la relación para que no haya ninguna referencia difícil a la antigua
guids
en las cuentas anteriores de Microsoft Purview. Debe actualizarlosguids
a la nueva cuentaguids
.Por último, cree una nueva relación entre entidades.
Nota
Antes de migrar términos, debe migrar las plantillas de términos. Este paso ya debe estar cubierto en la migración personalizada typedef
.
La forma más rápida de migrar términos del glosario es exportar términos a un archivo .csv. Puede hacerlo mediante el portal de gobernanza de Microsoft Purview.
Para automatizar la migración del glosario, primero debe obtener el glosario guid
(glossaryGuid
) a través de List Glossaries API.
glossaryGuid
es el glosario guid
de nivel superior o raíz .
La siguiente respuesta de ejemplo proporcionará el guid
objeto que se usará para las llamadas API posteriores:
"guid": "c018ddaf-7c21-4b37-a838-dae5f110c3d8"
Una vez que tenga , glossaryGuid
puede empezar a migrar los términos mediante dos pasos:
Nota
El requisito previo para este paso es tener todas las clasificaciones disponibles en la nueva cuenta del paso Migrar elementos de configuración .
Debe llamar a la API de detección para obtener las asignaciones de clasificación a los recursos. Esto se aplica a todos los recursos. Si ha migrado los recursos personalizados, la información sobre las asignaciones de clasificación ya está disponible en classifications
la propiedad . Otra manera de obtener clasificaciones es enumerar la clasificación por guid
en la cuenta anterior.
Para asignar clasificaciones a recursos, debe asociar una clasificación a varias entidades de forma masiva a través de la API.
Si ha extraído información de recursos de pasos anteriores, los detalles de contacto están disponibles en la API de detección.
Para asignar contactos a los recursos, necesita una lista de guids
e identificar todos los objectid
contactos. Puede automatizar este proceso iterando a través de todos los recursos y reasignando contactos a todos los recursos mediante la API Crear o actualizar entidades.