Partager via

Meilleures pratiques en matière de récupération d’urgence et de migration microsoft Purview

  • Article

Cet article fournit des conseils sur la stratégie de sauvegarde et de récupération lorsque votre organization dispose de solutions de gouvernance unifiée Microsoft Purview dans le déploiement de production. Vous pouvez également utiliser ces instructions générales pour implémenter la migration de compte. L’étendue de cet article est de couvrir les méthodes BCDR manuelles, où vous pouvez automatiser à l’aide d’API.

Les pannes du centre de données Azure sont rares, mais peuvent durer de quelques minutes à quelques heures. Les pannes du centre de données peuvent perturber les environnements sur lesquels on s’appuie pour la gouvernance des données. En suivant les étapes détaillées dans cet article, vous pouvez continuer à régir vos données en cas de panne du centre de données pour la région primaire de votre compte Microsoft Purview.

Conseil

Pour plus d’informations sur la fiabilité de Microsoft Purview, consultez notre documentation sur la fiabilité.

Assurer la continuité d’activité pour Microsoft Purview

La continuité d’activité et la récupération d’urgence (BCDR) dans un instance Microsoft Purview fait référence aux mécanismes, stratégies et procédures qui permettent à votre entreprise de protéger la perte de données et de continuer à fonctionner en cas de perturbation, en particulier à ses niveaux d’analyse, de catalogue et d’insights. Cette page explique comment configurer un environnement de récupération d’urgence pour Microsoft Purview.

Aujourd’hui, Microsoft Purview ne prend pas en charge la bcDR automatisée. Tant que cette prise en charge n’est pas ajoutée, vous êtes responsable des activités de sauvegarde et de restauration. Vous pouvez créer manuellement un compte Microsoft Purview secondaire en tant que instance de secours dans une autre région.

Les étapes suivantes résument la façon dont vous pouvez effectuer la récupération d’urgence manuellement :

  1. Une fois le compte Microsoft Purview principal créé, créez un ou plusieurs comptes Microsoft Purview secondaires dans une région distincte.

    Importante

    Microsoft Purview prend actuellement en charge une seule instance Microsoft Purview par locataire. Pour créer un deuxième compte pour la sauvegarde et la récupération d’urgence, contactez le support technique

  2. Toutes les activités effectuées sur le compte Microsoft Purview principal doivent également être effectuées sur les comptes Microsoft Purview secondaires. Cela inclut les opérations suivantes :

    • Gérer les informations de compte
    • Créer et gérer des ensembles de règles d’analyse, des classifications et des règles de classification personnalisés
    • Inscrire et analyser des sources
    • Créer et gérer des collections, ainsi que l’association de sources avec les collections
    • Créer et gérer les informations d’identification utilisées lors de l’analyse
    • Organiser les ressources de données
    • Créer et gérer les termes du glossaire

Les étapes spécifiques pour créer et gérer un compte de récupération d’urgence sont fournies plus loin dans l’article. Avant de les suivre, lisez les limitations et les considérations.

Limitations et considérations

Lorsque vous créez votre plan BCDR manuel, gardez les points suivants à l’esprit :

  • Vous serez facturé pour les instances principales et secondaires de Microsoft Purview.

  • Les comptes Microsoft Purview principaux et secondaires ne peuvent pas être configurés sur les mêmes comptes Azure Data Factory, Azure Data Share et Synapse Analytics, le cas échéant. Par conséquent, la traçabilité de Azure Data Factory et d’Azure Data Share n’est pas visible dans les comptes Microsoft Purview secondaires. Cette limitation sera traitée lorsque la bcDR automatisée est prise en charge.

  • Les runtimes d’intégration sont spécifiques à un compte Microsoft Purview. Par conséquent, les analyses doivent s’exécuter dans les comptes Microsoft Purview principaux et secondaires en parallèle, et plusieurs runtimes d’intégration auto-hébergés doivent être conservés. Cette limitation sera également traitée lorsque la bcDR automatisée est prise en charge.

  • L’exécution parallèle d’analyses à partir de comptes Microsoft Purview principaux et secondaires sur la même source peut affecter les performances de la source. Cela peut entraîner des durées d’analyse variables entre les comptes Microsoft Purview.

  • Il n’est pas recommandé de sauvegarder les détails des ressources « analysées ». Vous devez uniquement sauvegarder les données organisées, telles que le mappage des classifications et des glossaires sur les ressources. Le seul cas où vous devez sauvegarder les détails des ressources est lorsque vous avez des ressources personnalisées via personnalisé typeDef.

  • Le nombre de ressources sauvegardées doit être inférieur à 100 000. Le pilote main est que vous devez utiliser l’API de requête de recherche pour obtenir les ressources, dont la limite est de 100 000 ressources retournées. Toutefois, si vous êtes en mesure de segmenter la requête de recherche pour obtenir un plus petit nombre de ressources par appel d’API, il est possible de sauvegarder plus de 100 000 ressources.

  • Si vous souhaitez « synchroniser » en continu les ressources entre deux comptes, il existe d’autres étapes qui ne seront pas décrites en détail dans cet article. Vous devez utiliser Event Hubs de Microsoft Purview pour vous abonner et créer des entités à un autre compte. Toutefois, Event Hubs contient uniquement des informations Atlas. Microsoft Purview a ajouté d’autres fonctionnalités telles que des glossaires et descontacts qui ne seront pas disponibles via Event Hubs.

Étapes pour assurer la continuité des activités

Créer le compte

Planifiez ces éléments de configuration que vous ne pourrez pas modifier ultérieurement :

  • Nom du compte
  • Région
  • Abonnement
  • Gérer le nom du groupe de ressources

Migrer des éléments de configuration

Les étapes ci-dessous font référence à la documentation de l’API Microsoft Purview afin que vous puissiez rapidement mettre en place par programme le compte de sauvegarde :

Tâche Description
Informations sur le compte Gérer les informations de compte en accordant l’accès à l’administrateur et/ou au principal de service au compte au niveau racine
Collections Créez et gérez des collections, ainsi que l’association de sources aux collections. Vous pouvez appeler l’API De collections de listes , puis obtenir des détails spécifiques de chaque collection via l’API Get Collection
Ensemble de règles d’analyse Créez et gérez des ensembles de règles d’analyse personnalisés. Vous devez appeler l’API Lister les ensembles de règles d’analyse personnalisées et obtenir des détails en appelant l’API Obtenir un ensemble de règles d’analyse
Classifications manuelles Obtenir la liste de toutes les classifications manuelles en appelant les API get classifications et obtenir les détails de chaque classification
Règle d’ensemble de ressources Créer et gérer une règle d’ensemble de ressources. Vous pouvez appeler l’API Obtenir une règle d’ensemble de ressources pour obtenir les détails de la règle
Sources de données Appelez l’API Obtenir toutes les sources de données pour répertorier les sources de données avec des détails. Vous devez également obtenir les déclencheurs en appelant l’API Get trigger. Il existe également l’API Créer des sources de données si vous devez recréer les sources en bloc dans le nouveau compte.
Identifiants Créez et gérez les informations d’identification utilisées lors de l’analyse. Il n’y a pas d’API pour extraire les informations d’identification. Cela doit donc être refait dans le nouveau compte.
Runtime d’intégration auto-hébergé (SHIR) Obtenez une liste de SHIR et des clés mises à jour à partir du nouveau compte, puis mettez à jour les valeurs SHIR. Cette opération doit être effectuée manuellement à l’intérieur des hôtes SHIR. Celles-ci doivent être en cours d’exécution avant de créer des analyses.
Connexions ADF Actuellement, un ADF peut être connecté à un Microsoft Purview à la fois. Vous devez déconnecter ADF du compte Microsoft Purview défaillant et le reconnecter au nouveau compte ultérieurement.

Exécuter des analyses

Importante

Assurez-vous que vos runtimes d’intégration auto-hébergés ont été configurés et sont en cours d’exécution et disponibles avant de créer des analyses.

Cette opération remplit toutes les ressources avec la valeur par défaut typedef. Il existe plusieurs raisons d’exécuter à nouveau les analyses par rapport à l’exportation des ressources existantes et à l’importation dans le nouveau compte :

  • Il existe une limite de 100 000 ressources retournées à partir de la requête de recherche pour exporter des ressources.

  • Il est fastidieux d’exporter des ressources avec des relations.

  • Lorsque vous réexécutez les analyses, vous obtenez tous les détails des relations et des ressources à jour.

  • Microsoft Purview propose régulièrement de nouvelles fonctionnalités, ce qui vous permet de tirer parti d’autres fonctionnalités lors de l’exécution de nouvelles analyses.

L’exécution des analyses est le moyen le plus efficace d’obtenir toutes les ressources des sources de données que Microsoft Purview prend déjà en charge.

Migrer des typesdefs personnalisés et des ressources personnalisées

Si votre organization a créé des types personnalisés dans Microsoft Purview, vous devez les migrer manuellement.

Typedefs personnalisé

Pour identifier toutes les définitions de type personnalisées typedef, vous pouvez utiliser l’API Obtenir toutes les définitions de type. Cette opération retourne chaque type. Vous devez identifier les types personnalisés dans un format tel que "serviceType": "<custom_typedef>"

Ressources personnalisées

Pour exporter des ressources personnalisées, vous pouvez effectuer une recherche sur ces ressources personnalisées et transmettre la valeur personnalisée typedef appropriée via l’API de découverte

Remarque

Il existe une limite de retour de 100 000 par résultat de recherche. Vous devrez peut-être interrompre la requête de recherche afin qu’elle ne retourne pas plus de 100 000 enregistrements.

Il existe plusieurs façons d’étendre la requête de recherche pour obtenir un sous-ensemble de ressources :

  • À l’aide Keywordde : passez le nom de domaine complet parent tel que Keyword: "<Parent String>/*"
  • Utilisation Filterde : Inclure assetType avec le personnalisé typedef spécifique dans votre recherche, par exemple "assetType": "<custom_typedef>"

Voici un exemple de charge utile de recherche en personnalisant le keywords afin que seules les ressources dans un compte de stockage spécifique (exampleaccount) soient retournées :

{
  "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"
      }
    }
  ]
}

Les ressources retournées auront une valeur clé/paire que vous pouvez extraire des détails :

{
    "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"
        }
        ]
    }
    }
}

Remarque

Vous devez également migrer les modèles de terme à partir de la typedef sortie.

Lorsque vous recréez les entités personnalisées, vous devrez peut-être préparer la charge utile avant de l’envoyer à l’API :

Remarque

L’objectif initial est de migrer toutes les entités sans relations ni mappages. Cela permet d’éviter les erreurs potentielles.

  • Toutes les timestamp valeurs doivent être null, telles que updateTime, updateTimeet lastModifiedTS.

  • Le guid ne peut pas être régénéré exactement comme avant, vous devez donc passer un entier négatif tel que « -5000 » pour éviter toute erreur.

  • Le contenu de relationshipAttributes ne doit pas faire partie de la charge utile pour éviter les erreurs, car il est possible que les guids ne soient pas les mêmes ou n’ont pas encore été créés. Vous devez transformer relationshipAttributes en tableau vide avant d’envoyer la charge utile.

    • meanings contient tous les mappages de glossaire, qui seront mis à jour en bloc après la création des entités.

  • De même, doit également être un tableau vide lorsque vous soumettez la charge utile pour créer des entités, classifications car vous devez créer ultérieurement un mappage de classification avec des entités en bloc à l’aide d’une autre API.

Migrer des relations

Pour terminer la migration des ressources, vous devez remapper les relations. Il existe trois tâches :

  1. Appelez l’API de relation pour obtenir des informations de relation entre les entités par son guid

  2. Préparez la charge utile de la relation afin qu’il n’y ait aucune référence à l’ancienne guids dans les anciens comptes Microsoft Purview. Vous devez les mettre à jour guids vers le nouveau compte guids.

  3. Enfin, créez une relation entre les entités.

Migrer les termes du glossaire

Remarque

Avant de migrer les termes, vous devez migrer les modèles de terme. Cette étape doit déjà être abordée dans la migration personnalisée typedef .

Utilisation du portail de gouvernance Microsoft Purview

Le moyen le plus rapide de migrer des termes de glossaire consiste à exporter des termes vers un fichier .csv. Pour ce faire, utilisez le portail de gouvernance Microsoft Purview.

Utilisation de l’API Microsoft Purview

Pour automatiser la migration du glossaire, vous devez d’abord obtenir le glossaire guid (glossaryGuid) via l’API List Glossaries. est glossaryGuid le glossaire guidde niveau supérieur/racine.

L’exemple de réponse ci-dessous fournit le guid à utiliser pour les appels d’API suivants :

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

Une fois que vous avez le glossaryGuid, vous pouvez commencer à migrer les termes en deux étapes :

  1. Exporter les termes du glossaire en tant que .csv

  2. Importer les termes du glossaire via .csv

Affecter des classifications à des ressources

Remarque

La condition préalable à cette étape est que toutes les classifications soient disponibles dans le nouveau compte à partir de l’étape Migrer les éléments de configuration .

Vous devez appeler l’API de découverte pour obtenir les affectations de classification aux ressources. Cela s’applique à toutes les ressources. Si vous avez migré les ressources personnalisées, les informations sur les affectations de classification sont déjà disponibles dans classifications la propriété . Une autre façon d’obtenir des classifications consiste à répertorier la classification par guid dans l’ancien compte.

Pour affecter des classifications à des ressources, vous devez associer une classification à plusieurs entités en bloc via l’API.

Affecter des contacts à des ressources

Si vous avez extrait des informations de ressource à partir des étapes précédentes, les coordonnées sont disponibles à partir de l’API de découverte.

Pour affecter des contacts à des ressources, vous avez besoin d’une liste et d’une guids identification de tous les objectid contacts. Vous pouvez automatiser ce processus en itérant toutes les ressources et réaffecter des contacts à toutes les ressources à l’aide de l’API Créer ou mettre à jour des entités.