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.
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:
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
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.
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:
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
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.
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
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):
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:
Chamar a API de relação para obter informações de relação entre entidades pelo respetivo guid
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.
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:
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.
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.