Bewährte Methoden für die Notfallwiederherstellung und Migration von Microsoft Purview

Dieser Artikel enthält Anleitungen zur Sicherungs- und Wiederherstellungsstrategie, wenn Ihr organization über Einheitliche Governancelösungen von Microsoft Purview in der Produktionsbereitstellung verfügt. Sie können diese allgemeine Richtlinie auch verwenden, um die Kontomigration zu implementieren. In diesem Artikel werden manuelle BCDR-Methoden behandelt, bei denen Sie die Verwendung von APIs automatisieren können.

Azure-Rechenzentrumsausfälle sind selten, können aber zwischen einigen Minuten und Stunden dauern. Rechenzentrumsausfälle können zu Unterbrechungen in Umgebungen führen, die für die Datengovernance verwendet werden. Mit den in diesem Artikel beschriebenen Schritten können Sie Ihre Daten im Falle eines Rechenzentrumsausfalls für die primäre Region Ihres Microsoft Purview-Kontos weiterhin steuern.

Erreichen von Geschäftskontinuität für Microsoft Purview

Geschäftskontinuität und Notfallwiederherstellung (Business Continuity and Disaster Recovery, BCDR) in einem Microsoft Purview-instance bezieht sich auf die Mechanismen, Richtlinien und Verfahren, die es Ihrem Unternehmen ermöglichen, Datenverluste zu schützen und bei Unterbrechungen weiterzubestehen, insbesondere für die Scan-, Katalog- und Erkenntnisebenen. Auf dieser Seite wird erläutert, wie Sie eine Notfallwiederherstellungsumgebung für Microsoft Purview konfigurieren.

Microsoft Purview unterstützt derzeit keine automatisierte BCDR-Unterstützung. Bis diese Unterstützung hinzugefügt wird, sind Sie dafür verantwortlich, die Sicherungs- und Wiederherstellungsaktivitäten zu übernehmen. Sie können manuell ein sekundäres Microsoft Purview-Konto als warmer Standby-instance in einer anderen Region erstellen.

In den folgenden Schritten wird zusammengefasst, wie Sie die Notfallwiederherstellung manuell durchführen können:

1. Nachdem das primäre Microsoft Purview-Konto erstellt wurde, erstellen Sie mindestens ein sekundäres Microsoft Purview-Konto in einer separaten Region.

   Wichtig

   Microsoft Purview unterstützt derzeit eine einzelne Microsoft Purview-instance pro Mandant. Wenden Sie sich an den Support, um ein zweites Konto für Sicherung und Notfallwiederherstellung zu erstellen.

2. Alle Aktivitäten, die für das primäre Microsoft Purview-Konto ausgeführt werden, müssen auch für die sekundären Microsoft Purview-Konten ausgeführt werden. Dies umfasst Folgendes:

   • Verwalten von Kontoinformationen
   • Erstellen und Verwalten benutzerdefinierter Überprüfungsregelsätze, Klassifizierungen und Klassifizierungsregeln
   • Registrieren und Überprüfen von Quellen
   • Erstellen und Verwalten von Sammlungen zusammen mit der Zuordnung von Quellen zu den Sammlungen
   • Erstellen und Verwalten von Anmeldeinformationen, die beim Scannen verwendet werden
   • Zusammenstellen von Datenressourcen
   • Erstellen und Verwalten von Glossarbegriffen

Spezifische Schritte zum Erstellen und Verwalten eines Notfallwiederherstellungskontos finden Sie weiter unten in diesem Artikel. Bevor Sie ihnen folgen, lesen Sie die Einschränkungen und Überlegungen.

Einschränkungen und Überlegungen

Beachten Sie beim Erstellen Ihres manuellen BCDR-Plans die folgenden Punkte:

• Ihnen werden primäre und sekundäre Microsoft Purview-Instanzen in Rechnung gestellt.

• Die primären und sekundären Microsoft Purview-Konten können nicht für dasselbe Azure Data Factory-, Azure Data Share- und Synapse Analytics-Konto konfiguriert werden, falls zutreffend. Daher kann die Herkunft von Azure Data Factory und Azure Data Share in den sekundären Microsoft Purview-Konten nicht angezeigt werden. Diese Einschränkung wird behoben, wenn automatisierte BCDR unterstützt wird.

• Die Integration Runtimes sind spezifisch für ein Microsoft Purview-Konto. Daher müssen Überprüfungen in primären und sekundären Microsoft Purview-Konten parallel ausgeführt werden, und mehrere selbstgehostete Integration Runtimes müssen verwaltet werden. Diese Einschränkung wird auch behoben, wenn automatisierte BCDR unterstützt wird.

• Die parallele Ausführung von Überprüfungen von primären und sekundären Microsoft Purview-Konten in derselben Quelle kann sich auf die Leistung der Quelle auswirken. Dies kann dazu führen, dass die Überprüfungsdauer zwischen den Microsoft Purview-Konten variiert.

• Es ist nicht ratsam, "gescannte" Ressourcendetails zu sichern. Sie sollten nur die kuratierten Daten sichern, z. B. die Zuordnung von Klassifizierungen und Glossaren für Ressourcen. Der einzige Fall, in dem Sie die Details von Ressourcen sichern müssen, ist, wenn Sie über benutzerdefinierte typeDefRessourcen verfügen.

• Die Anzahl der gesicherten Ressourcen sollte weniger als 100.000 Ressourcen sein. Der Standard Treibers besteht darin, dass Sie die Suchabfrage-API verwenden müssen, um die Ressourcen abzurufen, für die eine Beschränkung von 100.000 Zurückgegebenen Ressourcen gilt. Wenn Sie die Suchabfrage jedoch segmentieren können, um eine kleinere Anzahl von Ressourcen pro API-Aufruf zu erhalten, ist es möglich, mehr als 100.000 Ressourcen zu sichern.

• Wenn Sie Ressourcen kontinuierlich zwischen zwei Konten "synchronisieren" möchten, gibt es weitere Schritte, die in diesem Artikel nicht ausführlich behandelt werden. Sie müssen die Event Hubs von Microsoft Purview verwenden, um Entitäten für ein anderes Konto zu abonnieren und zu erstellen. Event Hubs verfügt jedoch nur über Atlas-Informationen. Microsoft Purview hat weitere Funktionen wie Glossare und Kontakte hinzugefügt, die nicht über Event Hubs verfügbar sind.

Schritte zum Erreichen der Geschäftskontinuität

Erstellen des neuen Kontos

• Wenn Ihr organization bereits über mehrere Microsoft Purview-Konten verfügt, können Sie ein neues Microsoft Purview-Konto erstellen, indem Sie diese Anleitung befolgen: Schnellstart: Erstellen eines Microsoft Purview-Kontos im Azure-Portal

• Wenn Ihr organization nur über ein Microsoft Purview-Mandanten-/Organisationskonto verfügt, wenden Sie sich an den Support, um ein Konto für Sicherung und Wiederherstellung zu erstellen.

Planen Sie diese Konfigurationselemente, die Sie später nicht mehr ändern können:

• Kontoname
• Region
• Abonnement
• Verwalten des Ressourcengruppennamens

Migrieren von Konfigurationselementen

Die folgenden Schritte beziehen sich auf die Dokumentation zur Microsoft Purview-API , damit Sie das Sicherungskonto schnell programmgesteuert einrichten können:

Ausführen von Überprüfungen

Dadurch werden alle Ressourcen mit dem Standard typedefaufgefüllt. Es gibt mehrere Gründe, die Überprüfungen erneut auszuführen, anstatt die vorhandenen Ressourcen zu exportieren und in das neue Konto zu importieren:

• Es gibt ein Limit von 100.000 Ressourcen, die von der Suchabfrage zurückgegeben werden, um Ressourcen zu exportieren.

• Es ist umständlich, Ressourcen mit Beziehungen zu exportieren.

• Wenn Sie die Überprüfungen erneut ausführen, erhalten Sie alle Beziehungen und Ressourcendetails auf dem neuesten Stand.

• Microsoft Purview bietet regelmäßig neue Features, sodass Sie von anderen Features profitieren können, wenn Sie neue Überprüfungen ausführen.

Das Ausführen der Überprüfungen ist die effektivste Methode, um alle Ressourcen von Datenquellen abzurufen, die microsoft Purview bereits unterstützt.

Migrieren von benutzerdefinierten Typdefinitionen und benutzerdefinierten Ressourcen

Wenn Ihr organization benutzerdefinierte Typen in Microsoft Purview erstellt hat, müssen Sie diese manuell migrieren.

Benutzerdefinierte Typdefinitionen

Um alle benutzerdefinierten typedefzu identifizieren, können Sie die API zum Abrufen aller Typdefinitionen verwenden. Dadurch wird jeder Typ zurückgegeben. Sie müssen die benutzerdefinierten Typen in folgendem Format identifizieren: "serviceType": "<custom_typedef>"

Benutzerdefinierte Ressourcen

Um benutzerdefinierte Ressourcen zu exportieren, können Sie diese benutzerdefinierten Ressourcen durchsuchen und die richtigen benutzerdefinierten typedef Über die Ermittlungs-API übergeben.

Es gibt mehrere Möglichkeiten, den Bereich der Suchabfrage zu senken, um eine Teilmenge der Ressourcen abzurufen:

• Verwenden von Keyword: Übergeben Sie den übergeordneten FQN, z. B. Keyword: "<Parent String>/*"
• Verwenden von Filter: Fügen Sie assetType mit dem spezifischen benutzerdefinierten typedef in Ihre Suche ein, z. B. "assetType": "<custom_typedef>"

Hier sehen Sie ein Beispiel für eine Suchnutzlast, indem Sie die keywords anpassen, sodass nur Ressourcen in einem bestimmten Speicherkonto (exampleaccount) zurückgegeben werden:

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

Die zurückgegebenen Ressourcen verfügen über einen Schlüssel-/Paarwert, den Sie extrahieren können:

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

Wenn Sie die benutzerdefinierten Entitäten neu erstellen, müssen Sie die Nutzlast möglicherweise vor dem Senden an die API vorbereiten:

• Alle timestamp Werte müssen NULL sein, z updateTime. B. , updateTimeund lastModifiedTS.

• Der guid kann nicht genau wie zuvor neu generiert werden, sodass Sie eine negative ganze Zahl wie "-5000" übergeben müssen, um Fehler zu vermeiden.

• Der Inhalt von relationshipAttributes sollte nicht Teil der Nutzlast sein, um Fehler zu vermeiden, da es möglich ist, dass die guids nicht identisch sind oder noch nicht erstellt wurden. Sie müssen vor der Übermittlung der Nutzlast in ein leeres Array umgewandelt relationshipAttributes werden.

  • meanings enthält alle Glossarzuordnungen, die nach der Erstellung der Entitäten in einem Massenvorgang aktualisiert werden.

• Auf ähnliche Weise muss auch ein leeres Array sein, classifications wenn Sie die Nutzlast zum Erstellen von Entitäten übermitteln, da Sie später eine Klassifizierungszuordnung zu Massenentitäten mithilfe einer anderen API erstellen müssen.

Migrieren von Beziehungen

Um die Ressourcenmigration abzuschließen, müssen Sie die Beziehungen neu zuordnen. Es gibt drei Aufgaben:

1. Rufen Sie die Beziehungs-API auf, um Beziehungsinformationen zwischen Entitäten nach ihrer guid

2. Bereiten Sie die Beziehungsnutzlast so vor, dass in den alten Microsoft Purview-Konten kein harter Verweis auf alt guids vorhanden ist. Sie müssen diese guids auf die des neuen Kontos guidsaktualisieren.

3. Erstellen Sie schließlich eine neue Beziehung zwischen Entitäten.

Migrieren von Glossarbegriffen

Verwenden des Microsoft Purview-Governanceportals

Die schnellste Möglichkeit zum Migrieren von Glossarbegriffen besteht darin, Begriffe in eine .csv-Datei zu exportieren. Dazu können Sie das Microsoft Purview-Governanceportal verwenden.

Verwenden der Microsoft Purview-API

Um die Glossarmigration zu automatisieren, müssen Sie zuerst das Glossar guid (glossaryGuid) über die Listenglossar-API abrufen. ist glossaryGuid das Glossar guidauf oberster/Stammebene.

Die folgende Beispielantwort enthält die guid für nachfolgende API-Aufrufe:

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

Sobald Sie über glossaryGuidverfügen, können Sie mit der Migration der Begriffe in zwei Schritten beginnen:

1. Exportieren von Glossarbegriffen als .csv

2. Importieren von Glossarbegriffen über .csv

Zuweisen von Klassifizierungen zu Ressourcen

Sie müssen die Ermittlungs-API aufrufen, um die Klassifizierungszuweisungen zu Ressourcen abzurufen. Dies gilt für alle Ressourcen. Wenn Sie die benutzerdefinierten Ressourcen migriert haben, sind die Informationen zu Klassifizierungszuweisungen bereits in der classifications -Eigenschaft verfügbar. Eine weitere Möglichkeit zum Abrufen von Klassifizierungen ist das Auflisten der Klassifizierung pro guid im alten Konto.

Um Ressourcen Klassifizierungen zuzuweisen, müssen Sie mehrere Entitäten über die API massenweise eine Klassifizierung zuordnen .

Zuweisen von Kontakten zu Ressourcen

Wenn Sie Ressourceninformationen aus vorherigen Schritten extrahiert haben, sind die Kontaktdetails in der Ermittlungs-API verfügbar.

Zum Zuweisen von Kontakten zu Ressourcen benötigen Sie eine Liste mit guids und identifizieren alle objectid Kontakte. Sie können diesen Prozess automatisieren, indem Sie alle Ressourcen durchlaufen und kontakte mithilfe der API zum Erstellen oder Aktualisieren von Entitäten allen Ressourcen neu zuweisen.

Verwandte Informationen

• Dokumentation zur Microsoft Purview-Zuverlässigkeit
• Geschäftskontinuität und Notfallwiederherstellung
• Integrieren von Hochverfügbarkeit in Ihre BCDR-Strategie
• Azure status