Compartilhar via

Melhores práticas de recuperação após desastre e migração do Microsoft Purview

  • Artigo

Observação

O Catálogo de Dados do Microsoft Purview está a alterar o nome para Catálogo Unificado do Microsoft Purview. Todas as funcionalidades permanecerão iguais. Verá o nome mudar quando a nova experiência de Governação de Dados do Microsoft Purview estiver geralmente disponível na sua região. Verifique o nome na sua região.

Este artigo fornece orientações sobre a estratégia de cópia de segurança e recuperação quando a sua organização tem soluções de governação unificadas do Microsoft Purview na implementação de produção. Também pode utilizar esta orientação geral para implementar a migração de contas. O âmbito deste artigo consiste em abranger métodos BCDR manuais, onde pode automatizar a utilização de APIs.

As interrupções do datacenter do Azure são raras, mas podem durar entre alguns minutos e horas. As interrupções do Data Center podem causar interrupções em ambientes em que a governação de dados está a ser confiada. Ao seguir os passos detalhados neste artigo, pode continuar a governar os seus dados em caso de indisponibilidade do datacenter para a região primária da sua conta do Microsoft Purview.

Dica

Para obter mais informações sobre a fiabilidade do Microsoft Purview, veja a nossa documentação de fiabilidade.

Alcançar a continuidade do negócio para o Microsoft Purview

A continuidade de negócio e a recuperação após desastre (BCDR) numa instância do Microsoft Purview referem-se aos mecanismos, políticas e procedimentos que permitem à sua empresa proteger a perda de dados e continuar a operar perante interrupções, nomeadamente nas camadas de análise, catálogo e informações. Esta página explica como configurar um ambiente de recuperação após desastre para o Microsoft Purview.

Atualmente, o Microsoft Purview não suporta BCDR automatizado. Até que esse suporte seja adicionado, é responsável por tratar das atividades de cópia de segurança e restauro. Pode criar manualmente uma conta secundária do Microsoft Purview como uma instância de reserva ativa noutra região.

Os passos seguintes resumem como pode obter a recuperação após desastre manualmente:

  1. Assim que a conta principal do Microsoft Purview for criada, crie uma ou mais contas secundárias do Microsoft Purview numa região separada.

    Importante

    Atualmente, o Microsoft Purview suporta uma única instância do Microsoft Purview por inquilino. Para criar uma segunda conta para cópia de segurança e recuperação após desastre, contacte o suporte

  2. Todas as atividades realizadas na conta principal do Microsoft Purview também têm de ser realizadas nas contas secundárias do Microsoft Purview. Isso inclui:

    • Manter informações da Conta
    • Criar e manter regras de classificação, classificações e conjuntos de regras de análise personalizados
    • Registar e analisar origens
    • Criar e manter coleções juntamente com a associação de origens com as coleções
    • Criar e manter credenciais utilizadas durante a análise
    • Organizar recursos de dados
    • Criar e manter termos do glossário

Os passos específicos para criar e manter uma conta de recuperação após desastre são fornecidos mais à frente no artigo. Antes de as seguir, leia as limitações e considerações.

Limitações e considerações

À medida que cria o seu plano BCDR manual, tenha em atenção os seguintes pontos:

  • Ser-lhe-ão cobradas instâncias primárias e secundárias do Microsoft Purview.

  • As contas primárias e secundárias do Microsoft Purview não podem ser configuradas para as mesmas contas do Azure Data Factory, do Azure Data Share e do Synapse Analytics, se aplicável. Como resultado, a linhagem de Azure Data Factory e Data Share do Azure não pode ser vista nas contas secundárias do Microsoft Purview. Esta limitação será abordada quando o BCDR automatizado for suportado.

  • Os runtimes de integração são específicos de uma conta do Microsoft Purview. Por isso, as análises têm de ser executadas em contas primárias e secundárias do Microsoft Purview em paralelo e têm de ser mantidos vários runtimes de integração autoalojados. Esta limitação também será abordada quando o BCDR automatizado for suportado.

  • A execução paralela de análises de contas primárias e secundárias do Microsoft Purview na mesma origem pode afetar o desempenho da origem. Isto pode resultar em durações de análise para variar entre as contas do Microsoft Purview.

  • Não é aconselhável fazer uma cópia de segurança dos detalhes dos recursos "analisados". Só deve fazer uma cópia de segurança dos dados organizados, como o mapeamento de classificações e glossários em recursos. O único caso em que precisa de fazer uma cópia de segurança dos detalhes dos recursos é quando tem recursos personalizados através de typeDef.

  • A contagem de recursos de cópia de segurança deve ser inferior a 100 000 ativos. O controlador main é que tem de utilizar a API de consulta de pesquisa para obter os recursos, que têm a limitação de 100 000 recursos devolvidos. No entanto, se conseguir segmentar a consulta de pesquisa para obter um número menor de recursos por chamada à API, é possível fazer uma cópia de segurança de mais de 100 000 recursos.

  • Se quiser "sincronizar" continuamente recursos entre duas contas, existem outros passos que não serão abordados em detalhe neste artigo. Tem de utilizar os Hubs de Eventos do Microsoft Purview para subscrever e criar entidades para outra conta. No entanto, os Hubs de Eventos só têm informações do Atlas. O Microsoft Purview adicionou outras funcionalidades, como glossários e contactos que não estarão disponíveis através dos Hubs de Eventos.

Passos para alcançar a continuidade do negócio

Criar a nova conta

  • Se a sua organização já tiver várias contas do Microsoft Purview, pode criar uma nova conta do Microsoft Purview ao seguir esta instrução do guia: Início Rápido: Criar uma conta do Microsoft Purview no portal do Azure

  • Se a sua organização tiver apenas uma conta do Microsoft Purview de inquilino/organizacional, crie uma conta para suporte de contactos de cópia de segurança e recuperação.

Planeie estes itens de configuração que não pode alterar mais tarde:

  • Nome da conta
  • Região
  • Assinatura
  • Gerir o nome do grupo de recursos

Migrar itens de configuração

Os passos abaixo referem-se à documentação da API do Microsoft Purview para que possa suportar programaticamente a conta de cópia de segurança rapidamente:

Tarefa Descrição
Informações da conta Manter as informações da Conta ao conceder acesso ao administrador e/ou principal de serviço à conta ao nível de raiz
Coleções Crie e mantenha Coleções juntamente com a associação de origens com as Coleções. Pode chamar a API De Coleções de Listas e, em seguida, obter detalhes específicos de cada coleção através da API Obter Coleção
Conjunto de regras de análise Criar e manter conjuntos de regras de análise personalizados. Tem de chamar a API Listar conjuntos de regras de análise personalizada e obter detalhes ao chamar a API Obter conjunto de regras de análise
Classificações manuais Obtenha uma lista de todas as classificações manuais ao chamar as APIs obter classificações e obter detalhes de cada classificação
Regra do conjunto de recursos Criar e manter a regra do conjunto de recursos. Pode chamar a API de regra Obter conjunto de recursos para obter os detalhes da regra
Fontes de dados Chame a API Obter todas as origens de dados para listar origens de dados com detalhes. Também tem de obter os acionadores ao chamar Obter API de acionador. Também existe a API Criar origens de dados se precisar de recriar as origens em massa na nova conta.
Credenciais Crie e mantenha as credenciais utilizadas durante a análise. Não existe nenhuma API para extrair credenciais, pelo que tem de ser refeito na nova conta.
Runtime de integração autoalojado (SHIR) Obtenha uma lista de SHIR e obtenha as chaves atualizadas da nova conta e, em seguida, atualize os SHIRs. Isto tem de ser feito manualmente nos anfitriões dos SHIRs. Estes têm de estar em execução antes de criar análises.
Ligações do ADF Atualmente, um ADF pode ser ligado a um Microsoft Purview de cada vez. Tem de desligar o ADF da conta do Microsoft Purview falhada e voltar a ligá-la à nova conta mais tarde.

Executar análises

Importante

Certifique-se de que os runtimes de integração autoalojados foram configurados e estão em execução e disponíveis antes de criar análises.

Esta ação irá preencher todos os recursos com a predefinição typedef. Existem várias razões para executar as análises novamente vs. exportar os recursos existentes e importar para a nova conta:

  • Existe um limite de 100 000 recursos devolvidos da consulta de pesquisa para exportar recursos.

  • É complicado exportar recursos com relações.

  • Quando executar novamente as análises, obterá todos os detalhes de relações e recursos atualizados.

  • O Microsoft Purview é disponibilizado regularmente com novas funcionalidades para que possa beneficiar de outras funcionalidades ao executar novas análises.

Executar as análises é a forma mais eficaz de obter todos os recursos de origens de dados que o Microsoft Purview já suporta.

Migrar typedefs personalizados e recursos personalizados

Se a sua organização tiver criado tipos personalizados no Microsoft Purview, terá de os migrar manualmente.

Typedefs personalizados

Para identificar todas as definições personalizadas typedef, pode utilizar a API obter todas as definições de tipo. Esta ação irá devolver cada tipo. Tem de identificar os tipos personalizados num formato como "serviceType": "<custom_typedef>"

Recursos personalizados

Para exportar recursos personalizados, pode procurar esses recursos personalizados e transmitir o personalizado typedef adequado através da API de deteção

Observação

Existe um limite de retorno de 100 000 por resultado de pesquisa. Poderá ter de interromper a consulta de pesquisa para que não devolva mais de 100 000 registos.

Existem várias formas de definir o âmbito da consulta de pesquisa para obter um subconjunto de recursos:

  • Com Keyword: transmita o FQN principal, como Keyword: "<Parent String>/*"
  • Utilizar Filter: incluir assetType com o personalizado typedef específico na sua pesquisa, como "assetType": "<custom_typedef>"

Eis um exemplo de um payload de pesquisa ao personalizar o keywords para que apenas sejam devolvidos recursos numa conta de armazenamento 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"
      }
    }
  ]
}

Os recursos devolvidos terão algum valor de chave/par que pode extrair detalhes:

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

Observação

Também tem de migrar o termo modelos a partir da typedef saída.

Quando recriar as entidades personalizadas, poderá ter de preparar o payload antes de enviar para a API:

Observação

O objetivo inicial é migrar todas as entidades sem quaisquer relações ou mapeamentos. Isto evitará potenciais erros.

  • Todo o timestamp valor tem de ser nulo, como updateTime, updateTimee lastModifiedTS.

  • O guid não pode ser regenerado exatamente como antes, pelo que tem de transmitir um número inteiro negativo, como "-5000" para evitar o erro.

  • O conteúdo de relationshipAttributes não deve fazer parte do payload para evitar erros, uma vez que é possível que guids não sejam iguais ou ainda não tenham sido criados. Tem de se transformar relationshipAttributes numa matriz vazia antes de submeter o payload.

    • meanings contém todos os mapeamentos do glossário, que serão atualizados em massa após a criação das entidades.

  • Da mesma forma, também tem de ser uma matriz vazia quando submete o payload para criar entidades, classifications uma vez que tem de criar o mapeamento de classificação para entidades em massa mais tarde com uma API diferente.

Migrar relações

Para concluir a migração de recursos, tem de remapear as relações. Existem três tarefas:

  1. Chamar a API de relação para obter informações de relação entre entidades pelo respetivo guid

  2. Prepare o payload da relação para que não exista uma referência rígida a antiga guids nas contas antigas do Microsoft Purview. Tem de atualizá-los guids para o guids.

  3. Por fim, crie uma nova relação entre entidades

Migrar termos do glossário

Observação

Antes de migrar os termos, tem de migrar o termo modelos. Este passo já deve ser abordado na migração personalizada typedef .

Utilizar o portal de governação do Microsoft Purview

A forma mais rápida de migrar termos do glossário é exportar termos para um ficheiro .csv. Pode fazê-lo através do portal de governação do Microsoft Purview.

Utilizar a API do Microsoft Purview

Para automatizar a migração do glossário, primeiro tem de obter o glossário guid (glossaryGuid) através da API de Glossários de Lista. O glossaryGuid é o glossário guidde nível superior/raiz .

A resposta de exemplo abaixo fornecerá a guid utilização para chamadas à API subsequentes:

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

Assim que tiver o glossaryGuid, pode começar a migrar os termos através de dois passos:

  1. Exportar Termos do Glossário Como .csv

  2. Importar Termos do Glossário Através de .csv

Atribuir classificações a recursos

Observação

O pré-requisito para este passo é ter todas as classificações disponíveis na nova conta no passo Migrar itens de configuração .

Tem de chamar a API de deteção para obter as atribuições de classificação para os recursos. Isto aplica-se a todos os recursos. Se tiver migrado os recursos personalizados, as informações sobre atribuições de classificação já estão disponíveis na classifications propriedade . Outra forma de obter classificações é listar a classificação por guid na conta antiga.

Para atribuir classificações a recursos, tem de associar uma classificação a múltiplas entidades em massa através da API.

Atribuir contactos a recursos

Se tiver extraído informações de recursos dos passos anteriores, os detalhes de contacto estão disponíveis na API de deteção.

Para atribuir contactos a recursos, precisa de uma lista de guids e identificar todos os objectid contactos. Pode automatizar este processo ao iterar todos os recursos e reatribuir contactos a todos os recursos através da API Criar ou Atualizar Entidades.