Compartir a través de


Procedimientos recomendados de migración y recuperación ante desastres de Microsoft Purview

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.

Lograr la continuidad empresarial para Microsoft Purview

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:

  1. 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.

  2. 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.

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 typeDefpersonalizados.

  • 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.

Pasos para lograr la continuidad empresarial

Creación de la nueva cuenta

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

Migración de elementos de configuración

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.

Ejecución de exámenes

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.

Migración de definiciones de tipos personalizadas y recursos personalizados

Si su organización ha creado tipos personalizados en Microsoft Purview, debe migrarlos manualmente.

Definiciones de tipo personalizadas

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>"

Recursos personalizados

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 KeywordKeyword: "<Parent String>/*"
  • Uso de Filter: incluir assetType con la personalizada typedef 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, como updateTime, updateTimey lastModifiedTS.

  • 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 que guids no sean iguales o no se hayan creado todavía. Debe convertirse relationshipAttributes 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.

Migración de relaciones

Para completar la migración de recursos, debe volver a asignar las relaciones. Hay tres tareas:

  1. Llame a la API de relación para obtener información de relación entre entidades por su guid

  2. 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 actualizarlos guids a la nueva cuenta guids.

  3. Por último, cree una nueva relación entre entidades.

Migración de términos del glosario

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 .

Uso del portal de gobernanza de Microsoft Purview

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.

Uso de la API 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 guidde 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 , glossaryGuidpuede empezar a migrar los términos mediante dos pasos:

  1. Exportar términos del glosario como .csv

  2. Importar términos del glosario a través de .csv

Asignación de clasificaciones a recursos

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.

Asignación de contactos a recursos

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.