Procedure consigliate per il ripristino di emergenza e la migrazione di Microsoft Purview
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.
Suggerimento
Per altre informazioni sull'affidabilità per Microsoft Purview, vedere la documentazione sull'affidabilità.
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:
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
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.
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.
Se l'organizzazione ha già più account Microsoft Purview, è possibile creare un nuovo account Microsoft Purview seguendo questa guida: Guida introduttiva: Creare un account Microsoft Purview nel portale di Azure
Se l'organizzazione ha un solo account Microsoft Purview tenant/aziendale, per creare un account per il supporto dei contatti di backup e ripristino.
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
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. |
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.
Se l'organizzazione ha creato tipi personalizzati in Microsoft Purview, è necessario eseguirne la migrazione manualmente.
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>"
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 esempioKeyword: "<Parent String>/*"
-
Uso di
Filter
: includereassetType
con l'personalizzatotypedef
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, adupdateTime
esempio ,updateTime
elastModifiedTS
.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 cheguids
non siano ancora uguali o non siano stati creati. È necessario trasformarerelationshipAttributes
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.
Per completare la migrazione degli asset, è necessario modificare il mapping delle relazioni. Sono disponibili tre attività:
Chiamare l'API di relazione per ottenere informazioni sulla relazione tra entità in base al relativo
guid
Preparare il payload della relazione in modo che non vi sia alcun riferimento rigido al vecchio
guids
negli account Microsoft Purview precedenti. È necessario aggiornarliguids
al nuovo accountguids
.
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
.
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.
Per automatizzare la migrazione del glossario, è prima necessario ottenere il glossario guid
(glossaryGuid
) tramite l'API Glossari elenco. è glossaryGuid
il glossario guid
di 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:
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.
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à.