Condividi tramite

Procedure consigliate per il ripristino di emergenza e la migrazione di Microsoft Purview

  • Articolo

Nota

Il Microsoft Purview Data Catalog sta cambiando il nome in Microsoft Purview Unified Catalog. Tutte le funzionalità rimarranno invariate. Verrà visualizzata la modifica del nome quando la nuova esperienza di governance dei dati di Microsoft Purview è disponibile a livello generale nell'area. Controllare il nome nell'area.

Questo articolo fornisce indicazioni sulla strategia di backup e ripristino quando l'organizzazione dispone di soluzioni di governance unificata di Microsoft Purview nella distribuzione di produzione. È anche possibile usare questa linea guida generale per implementare la migrazione degli account. L'ambito di questo articolo riguarda i metodi BCDR manuali, in cui è possibile automatizzare l'uso delle API.

Le interruzioni del data center di Azure sono rare, ma possono durare da pochi minuti a ore. Le interruzioni del data center possono causare interruzioni degli ambienti su cui si fa affidamento per la governance dei dati. Seguendo i passaggi descritti in questo articolo, è possibile continuare a gestire i dati in caso di interruzione del data center per l'area primaria dell'account Microsoft Purview.

Consiglio

Per altre informazioni sull'affidabilità per Microsoft Purview, vedere la documentazione sull'affidabilità.

Ottenere la continuità aziendale per Microsoft Purview

La continuità aziendale e il ripristino di emergenza (BCDR) in un'istanza di Microsoft Purview si riferiscono ai meccanismi, ai criteri e alle procedure che consentono all'azienda di proteggere la perdita di dati e continuare a operare in caso di interruzioni, in particolare per i livelli di analisi, catalogo e informazioni dettagliate. Questa pagina illustra come configurare un ambiente di ripristino di emergenza per Microsoft Purview.

Attualmente Microsoft Purview non supporta bcdr automatizzato. Fino a quando non viene aggiunto il supporto, è necessario occuparsi delle attività di backup e ripristino. È possibile creare manualmente un account Microsoft Purview secondario come istanza di warm standby in un'altra area.

I passaggi seguenti riepilogano come è possibile ottenere manualmente il ripristino di emergenza:

  1. Dopo aver creato l'account Microsoft Purview primario, creare uno o più account Microsoft Purview secondari in un'area separata.

    Importante

    Microsoft Purview supporta attualmente una singola istanza di Microsoft Purview per tenant. Per creare un secondo account per il backup e il ripristino di emergenza, contattare il supporto tecnico

  2. Tutte le attività eseguite sull'account Microsoft Purview primario devono essere eseguite anche negli account Microsoft Purview secondari. Tra queste vi sono anche:

    • Gestire le informazioni sull'account
    • Creare e gestire set di regole di analisi personalizzati, classificazioni e regole di classificazione
    • Registrare e analizzare le origini
    • Creare e gestire raccolte insieme all'associazione di origini con le raccolte
    • Creare e gestire le credenziali usate durante l'analisi
    • Gestire gli asset di dati
    • Creare e gestire termini del glossario

I passaggi specifici per creare e gestire un account di ripristino di emergenza sono disponibili più avanti nell'articolo. Prima di seguirli, leggere le limitazioni e le considerazioni.

Limitazioni e considerazioni

Durante la creazione del piano BCDR manuale, tenere presente quanto segue:

  • Verranno addebitati i costi per le istanze primarie e secondarie di Microsoft Purview.

  • Gli account Microsoft Purview primario e secondario non possono essere configurati per gli stessi account Azure Data Factory, Azure Condivisione dati e Synapse Analytics, se applicabile. Di conseguenza, la derivazione da Azure Data Factory e azure Condivisione dati non può essere visualizzata negli account Microsoft Purview secondari. Questa limitazione verrà risolta quando è supportato il bcdr automatizzato.

  • I runtime di integrazione sono specifici di un account Microsoft Purview. Le analisi devono quindi essere eseguite in account Microsoft Purview primari e secondari in parallelo e devono essere gestiti più runtime di integrazione self-hosted. Questa limitazione verrà risolta anche quando è supportato il bcdr automatizzato.

  • L'esecuzione parallela di analisi da account Microsoft Purview primario e secondario nella stessa origine può influire sulle prestazioni dell'origine. Ciò può comportare una variazione della durata dell'analisi tra gli account Microsoft Purview.

  • Non è consigliabile eseguire il backup dei dettagli degli asset "analizzati". È consigliabile eseguire il backup solo dei dati curati, ad esempio il mapping di classificazioni e glossari sugli asset. L'unico caso in cui è necessario eseguire il backup dei dettagli degli asset è quando si dispone di asset personalizzati tramite typeDef.

  • Il numero di asset di cui è stato eseguito il backup deve essere inferiore a 100.000 asset. Il driver principale è che è necessario usare l'API query di ricerca per ottenere gli asset, che hanno una limitazione di 100.000 asset restituiti. Tuttavia, se si è in grado di segmentare la query di ricerca per ottenere un numero minore di asset per ogni chiamata API, è possibile eseguire il backup di più di 100.000 asset.

  • Se si vuole "sincronizzare" continuamente gli asset tra due account, esistono altri passaggi che non verranno trattati in dettaglio in questo articolo. È necessario usare Hub eventi di Microsoft Purview per sottoscrivere e creare entità a un altro account. Tuttavia, Hub eventi include solo informazioni atlas. Microsoft Purview ha aggiunto altre funzionalità, ad esempio glossari e contatti , che non saranno disponibili tramite Hub eventi.

Passaggi per ottenere la continuità aziendale

Creare il nuovo account

Pianificare questi elementi di configurazione che non è possibile modificare in un secondo momento:

  • Account name (Nome account)
  • Area geografica
  • Abbonamento
  • Gestire il nome del gruppo di risorse

Eseguire la migrazione di elementi di configurazione

I passaggi seguenti fanno riferimento alla documentazione dell'API Microsoft Purview in modo che sia possibile aumentare rapidamente l'account di backup a livello di codice:

Attività Descrizione
Informazioni sull'account Gestire le informazioni sull'account concedendole l'accesso per l'amministratore e/o l'entità servizio all'account a livello radice
Raccolte Creare e gestire raccolte insieme all'associazione di origini con le raccolte. È possibile chiamare l'API List Collections e quindi ottenere dettagli specifici di ogni raccolta tramite l'API Get Collection
Set di regole di analisi Creare e gestire set di regole di analisi personalizzati. È necessario chiamare l'API Elenco set di regole di analisi personalizzati e ottenere i dettagli chiamando l'API Get scan rule set
Classificazioni manuali Ottenere un elenco di tutte le classificazioni manuali chiamando le API get classifications e ottenere i dettagli di ogni classificazione
Regola del set di risorse Creare e gestire la regola del set di risorse. È possibile chiamare l'API get resource set rule (Ottieni regola set di risorse ) per ottenere i dettagli della regola
Origini dati Chiamare l'API Recupera tutte le origini dati per elencare le origini dati con i dettagli. È anche necessario ottenere i trigger chiamando l'API get trigger. È anche disponibile l'API Crea origini dati se è necessario ricreare le origini in blocco nel nuovo account.
Credenziali Creare e gestire le credenziali usate durante l'analisi. Non è disponibile alcuna API per estrarre le credenziali, quindi deve essere eseguito di nuovo nel nuovo account.
Runtime di integrazione self-hosted (SHIR) Ottenere un elenco di SHIR e ottenere chiavi aggiornate dal nuovo account e quindi aggiornare gli SRI. Questa operazione deve essere eseguita manualmente all'interno degli host degli SRI. Questi devono essere in esecuzione prima di creare analisi.
Connessioni ADF Attualmente una funzione di azure data può essere connessa a un'istanza di Microsoft Purview alla volta. È necessario disconnettere ADF dall'account Microsoft Purview non riuscito e riconnetterlo al nuovo account in un secondo momento.

Eseguire analisi

Importante

Assicurarsi che i runtime di integrazione self-hosted siano stati configurati e siano in esecuzione e disponibili prima di creare analisi.

Verranno popolati tutti gli asset con l'impostazione predefinita typedef. Esistono diversi motivi per eseguire di nuovo le analisi rispetto all'esportazione degli asset esistenti e all'importazione nel nuovo account:

  • È previsto un limite di 100.000 asset restituiti dalla query di ricerca per esportare gli asset.

  • L'esportazione di asset con relazioni è complessa.

  • Quando si eseguono di nuovo le analisi, si ottengono tutte le relazioni e i dettagli degli asset aggiornati.

  • Microsoft Purview viene fornito con nuove funzionalità regolarmente in modo da poter trarre vantaggio da altre funzionalità quando si eseguono nuove analisi.

L'esecuzione delle analisi è il modo più efficace per ottenere tutte le risorse di origini dati già supportate da Microsoft Purview.

Eseguire la migrazione di typedef personalizzati e asset personalizzati

Se l'organizzazione ha creato tipi personalizzati in Microsoft Purview, è necessario eseguirne la migrazione manualmente.

Typedef personalizzati

Per identificare tutti gli elementi personalizzati typedef, è possibile usare l'API get all type definitions . Verrà restituito ogni tipo. È necessario identificare i tipi personalizzati in un formato come "serviceType": "<custom_typedef>"

Asset personalizzati

Per esportare gli asset personalizzati, è possibile eseguire una ricerca in tali asset personalizzati e passare il valore personalizzato typedef appropriato tramite l'API di individuazione

Nota

Esiste un limite restituito di 100.000 per ogni risultato della ricerca. Potrebbe essere necessario interrompere la query di ricerca in modo che non restituisca più di 100.000 record.

Esistono diversi modi per definire l'ambito della query di ricerca per ottenere un subset di asset:

  • Using Keyword: Passare il FQN padre, ad esempio Keyword: "<Parent String>/*"
  • Uso di Filter: includere assetType con l'personalizzato typedef specifico nella ricerca, ad esempio "assetType": "<custom_typedef>"

Ecco un esempio di payload di ricerca personalizzando in keywords modo che vengano restituiti solo gli asset in un account di archiviazione specifico (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"
      }
    }
  ]
}

Gli asset restituiti avranno un valore chiave/coppia che è possibile estrarre i dettagli:

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

È anche necessario eseguire la migrazione dei modelli di termini dall'output typedef .

Quando si ricreano le entità personalizzate, potrebbe essere necessario preparare il payload prima di inviare all'API:

Nota

L'obiettivo iniziale è eseguire la migrazione di tutte le entità senza relazioni o mapping. In questo modo si eviteranno potenziali errori.

  • Tutto il timestamp valore deve essere null, ad updateTimeesempio , updateTimee lastModifiedTS.

  • L'oggetto guid non può essere rigenerato esattamente come in precedenza, quindi è necessario passare un numero intero negativo, ad esempio "-5000" per evitare errori.

  • Il contenuto di relationshipAttributes non deve far parte del payload per evitare errori poiché è possibile che guids non siano ancora uguali o non siano stati creati. È necessario trasformare relationshipAttributes in una matrice vuota prima di inviare il payload.

    • meanings contiene tutti i mapping del glossario, che verranno aggiornati in blocco dopo la creazione delle entità.

  • Analogamente, classifications deve essere anche una matrice vuota quando si invia il payload per creare entità poiché è necessario creare il mapping di classificazione alle entità bulk in un secondo momento usando un'API diversa.

Eseguire la migrazione delle relazioni

Per completare la migrazione degli asset, è necessario modificare il mapping delle relazioni. Sono disponibili tre attività:

  1. Chiamare l'API di relazione per ottenere informazioni sulla relazione tra entità in base al relativo guid

  2. Preparare il payload della relazione in modo che non vi sia alcun riferimento rigido al vecchio guids negli account Microsoft Purview precedenti. È necessario aggiornarli guids al nuovo account guids.

  3. Infine, creare una nuova relazione tra entità

Eseguire la migrazione dei termini del glossario

Nota

Prima di eseguire la migrazione dei termini, è necessario eseguire la migrazione dei modelli di termini. Questo passaggio dovrebbe essere già trattato nella migrazione personalizzata typedef .

Uso del portale di governance di Microsoft Purview

Il modo più rapido per eseguire la migrazione dei termini del glossario consiste nell'esportare i termini in un file .csv. A tale scopo, è possibile usare il portale di governance di Microsoft Purview.

Uso dell'API Microsoft Purview

Per automatizzare la migrazione del glossario, è prima necessario ottenere il glossario guid (glossaryGuid) tramite l'API Glossari elenco. è glossaryGuid il glossario guiddi livello principale/radice.

La risposta di esempio seguente fornirà l'oggetto guid da usare per le chiamate API successive:

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

Dopo aver creato , glossaryGuidè possibile iniziare a eseguire la migrazione dei termini tramite due passaggi:

  1. Esportare termini del glossario come .csv

  2. Importare termini del glossario tramite .csv

Assegnare classificazioni agli asset

Nota

Il prerequisito per questo passaggio consiste nell'avere tutte le classificazioni disponibili nel nuovo account dal passaggio Eseguire la migrazione degli elementi di configurazione .

È necessario chiamare l'API di individuazione per ottenere le assegnazioni di classificazione agli asset. Questo è applicabile a tutti gli asset. Se è stata eseguita la migrazione degli asset personalizzati, le informazioni sulle assegnazioni di classificazione sono già disponibili nella classifications proprietà . Un altro modo per ottenere le classificazioni consiste nell'elencare la classificazione per guid ogni account precedente.

Per assegnare classificazioni agli asset, è necessario associare una classificazione a più entità in blocco tramite l'API.

Assegnare contatti agli asset

Se sono state estratte informazioni sugli asset dai passaggi precedenti, i dettagli del contatto sono disponibili dall'API di individuazione.

Per assegnare i contatti agli asset, è necessario un elenco di guids tutti i objectid contatti e identificarlo. È possibile automatizzare questo processo eseguendo l'iterazione di tutti gli asset e riassegnando i contatti a tutti gli asset usando l'API Crea o aggiorna entità.