Práticas recomendadas de recuperação de desastre e migração para governança de dados do Microsoft Purview (clássico)

Este artigo fornece diretrizes sobre a estratégia de backup e recuperação quando sua organização tem soluções clássicas de governança do Microsoft Purview na implantação de produção. Você também pode usar essa diretriz geral para implementar a migração de conta. O escopo deste artigo é abordar métodos manuais de BCDR (continuidade dos negócios e recuperação de desastres), em que você pode automatizar usando APIs.

As interrupções do data center do Azure são raras, mas podem durar de alguns minutos a horas. As interrupções do data center podem causar interrupções em ambientes que estão sendo usados para governança de dados. Seguindo as etapas detalhadas neste artigo, você pode continuar a controlar seus dados no caso de uma interrupção do data center para a região primária da sua conta do Microsoft Purview.

Obter continuidade dos negócios para o Microsoft Purview

A BCDR em uma instância do Microsoft Purview refere-se aos mecanismos, políticas e procedimentos que permitem que sua empresa proteja a perda de dados e continue operando diante de interrupções, especialmente em suas camadas de verificação, catálogo clássico e insights clássicos. Esta página explica como configurar um ambiente de recuperação de desastre para o Microsoft Purview.

Atualmente, o Microsoft Purview não dá suporte à BCDR automatizada. Até que esse suporte seja adicionado, você é responsável por cuidar das atividades de backup e restauração. Você pode criar manualmente uma conta secundária do Microsoft Purview como uma instância de espera ativa em outra região.

As etapas a seguir resumem como você pode obter a recuperação de desastre manualmente:

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

   Importante

   Atualmente, o Microsoft Purview dá suporte a uma única instância do Microsoft Purview por locatário. Para criar uma segunda conta para backup e recuperação de desastre, entre em contato com o suporte

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

   • Manter informações da conta
   • Criar e manter conjuntos de regras de verificação, classificações e regras de classificação personalizados
   • Registrar e examinar fontes
   • Criar e manter coleções juntamente com a associação de fontes com as coleções
   • Crie e mantenha as credenciais usadas durante a verificação
   • Coletar ativos de dados
   • Criar e manter termos do glossário

Etapas específicas para criar e manter uma conta de recuperação de desastre são fornecidas mais adiante neste artigo. Antes de segui-los, leia as limitações e considerações.

Limitações e considerações

Ao criar seu plano BCDR manual, lembre-se dos seguintes pontos:

• Você será cobrado por instâncias primárias e secundárias do Microsoft Purview.

• As contas principal e secundária do Microsoft Purview não podem ser configuradas para as mesmas contas Azure Data Factory, Azure Data Share e Synapse Analytics, se aplicável. Como resultado, a linhagem de Azure Data Factory e Azure Data Share não pode ser vista nas contas secundárias do Microsoft Purview. Essa limitação será abordada quando houver suporte para a BCDR automatizada.

• Os runtimes de integração são específicos para uma conta do Microsoft Purview. Portanto, as verificações precisam ser executadas em contas principais e secundárias do Microsoft Purview em paralelo, vários runtimes de integração auto-hospedada devem ser mantidos. Essa limitação também será abordada quando houver suporte para a BCDR automatizada.

• A execução paralela de verificações de contas principais e secundárias do Microsoft Purview na mesma fonte pode afetar o desempenho da fonte. Isso pode fazer com que as durações de verificação variem entre as contas do Microsoft Purview.

• Não é aconselhável fazer backup dos detalhes dos ativos "digitalizados". Você só deve fazer backup dos dados coletados, como mapeamento de classificações e glossários em ativos. O único caso em que você precisa fazer backup dos detalhes dos ativos é quando você tem ativos personalizados por meio de arquivos .typeDef

• A contagem de ativos de backup deve ser inferior a 100.000 ativos. O principal fator é que você precisa usar a API de consulta de pesquisa para obter os ativos, que têm limitação de 100.000 ativos retornados. No entanto, se você puder segmentar a consulta de pesquisa para obter um número menor de ativos por chamada de API, será possível fazer backup de mais de 100.000 ativos.

• Se você deseja "sincronizar" continuamente ativos entre duas contas, há outras etapas que não serão abordadas em detalhes neste artigo. Você precisa usar os Hubs de Eventos do Microsoft Purview para assinar e criar entidades em outra conta. No entanto, os Hubs de Eventos só têm informações do Atlas. O Microsoft Purview adicionou outros recursos, como glossários e contatos , que não estarão disponíveis por meio dos Hubs de Eventos.

Etapas para alcançar a continuidade dos negócios

Criar a nova conta

• Se sua organização já tiver várias contas do Microsoft Purview, você poderá criar uma nova conta do Microsoft Purview seguindo estas instruções do guia: Início Rápido: criar uma conta do Microsoft Purview no portal do Azure

• Se sua organização tiver apenas uma conta do locatário/organização do Microsoft Purview, para criar uma conta de backup e recuperação, entre em contato com o suporte.

Planeje estes itens de configuração que você não pode alterar mais tarde:

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

Migrar itens de configuração

As etapas abaixo estão se referindo à documentação da API do Microsoft Purview para que você possa ativar programaticamente a conta de backup rapidamente:

Executar verificações

Isso preencherá todos os ativos com o padrão typedef. Há vários motivos para executar as verificações novamente em comparação com a exportação dos ativos existentes e a importação para a nova conta:

• Há um limite de 100.000 ativos retornados da consulta de pesquisa para exportar ativos.

• É complicado exportar ativos com relacionamentos.

• Ao executar as verificações novamente, você terá todos os relacionamentos e detalhes de ativos atualizados.

• O Microsoft Purview apresenta novos recursos regularmente para que você possa se beneficiar de outros recursos ao executar novas verificações.

Executar as verificações é a maneira mais eficaz de obter todos os ativos de fontes de dados que o Microsoft Purview já está suportando.

Migrar typedefs personalizados e ativos personalizados

Se sua organização criou tipos personalizados no Microsoft Purview, você precisará migrá-los manualmente.

Typedefs personalizados

Para identificar todos os personalizadostypedef, você pode usar a API obter todas as definições de tipo. Isso retornará cada tipo. Você precisa identificar os tipos personalizados em um formato como "serviceType": "<custom_typedef>"

Ativos personalizados

Para exportar ativos personalizados, você pode pesquisar esses ativos personalizados e passar o personalizado typedef adequado por meio da API de descoberta

Há várias maneiras de reduzir o escopo da consulta de pesquisa para obter um subconjunto de ativos:

• Usando Keyword: Transmita o FQN pai, como Keyword: "<Parent String>/*"
• Usando Filter: Inclua assetType com o costume typedef específico em sua pesquisa, como "assetType": "<custom_typedef>"

Aqui está um exemplo de um conteúdo de pesquisa personalizando o keywords para que apenas os ativos na conta de armazenamento específica (exampleaccount) sejam retornados:

{
  "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 ativos retornados terão algum valor de chave/par que você 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"
        }
        ]
    }
    }
}

Ao recriar as entidades personalizadas, talvez seja necessário preparar a carga antes de enviar para a API:

• Todos os timestamp valores devem ser nulos, como updateTime, updateTimee lastModifiedTS.

• O guid não pode ser regenerado exatamente como antes, então você deve passar um número inteiro negativo, como "-5000", para evitar erros.

• O conteúdo não relationshipAttributes deve fazer parte do conteúdo para evitar erros, pois é possível que não guids sejam os mesmos ou ainda não tenham sido criados. Você precisa transformar relationshipAttributes em uma matriz vazia antes de enviar a carga.

  • meanings Contém todos os mapeamentos do glossário, que serão atualizados em massa depois que as entidades forem criadas.

• Da mesma forma, também precisa ser uma matriz vazia quando você envia a carga para criar entidades, classifications pois precisa criar mapeamento de classificação para entidades em massa posteriormente usando uma API diferente.

Migrar relacionamentos

Para concluir a migração de ativos, você deve remapear as relações. Há três tarefas:

1. Chame a API de relação para obter informações de relação entre entidades por meio da guid

2. Prepare o conteúdo da relação para que não haja referência rígida ao antigo guids nas contas antigas do Microsoft Purview. Você precisa atualizá-los guids para a nova conta guids.

3. Por fim, crie um novo relacionamento entre entidades

Migrar termos do glossário

Usando o portal de governança do Microsoft Purview

A maneira mais rápida de migrar termos do glossário é exportá-los para um arquivo .csv. Você pode fazer isso usando o portal de governança do Microsoft Purview.

Usando a API do Microsoft Purview

Para automatizar a migração do glossário, primeiro você precisa obter o glossário guid (glossaryGuid) por meio da API de glossários de lista. O glossaryGuid é o glossário guidde nível superior/raiz.

A resposta de exemplo abaixo fornecerá o uso para chamadas de guid API subsequentes:

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

Depois de ter o glossaryGuid, você pode começar a migrar os termos por meio de duas etapas:

1. Exportar termos do glossário como .csv

2. Importar termos do glossário por meio do .csv

Atribuir classificações a ativos

Você deve chamar a API de descoberta para obter as atribuições de classificação aos ativos. Isso é aplicável a todos os ativos. Se você migrou os ativos personalizados, as informações sobre as atribuições de classificação já estão disponíveis na classifications propriedade. Outra maneira de obter classificações é listar a classificação por guid na conta antiga.

Para atribuir classificações a ativos, você precisa associar uma classificação a várias entidades em massa por meio da API.

Atribuir contatos a ativos

Se você tiver extraído informações de ativos de etapas anteriores, os detalhes de contato estarão disponíveis na API de descoberta.

Para atribuir contatos a ativos, você precisa de uma lista e guids identificar todos os objectid contatos. Você pode automatizar esse processo iterando por todos os ativos e reatribuir contatos a todos os ativos usando a API Criar ou atualizar entidades.

Informações relacionadas

• Documentação de confiabilidade do Microsoft Purview
• Continuidade do negócio e recuperação de desastre
• Integre a alta disponibilidade à sua estratégia BCDR
• Azure status