Share via

Orientação de recuperação de desastres específica da experiência

  • Artigo

Este documento fornece orientação específica da experiência para recuperar seus dados do Fabric no caso de um desastre regional.

Cenário de exemplo

Algumas das seções de orientação deste documento usam o seguinte cenário de exemplo para fins de explicação e ilustração. Consulte novamente este cenário conforme necessário.

Digamos que você tenha uma capacidade C1 na região A que tenha um espaço de trabalho W1. Se você ativou a recuperação de desastres para a capacidade C1, os dados do OneLake serão replicados para um backup na região B. Se a região A enfrentar interrupções, o serviço de malha em C1 fará failover para a região B.

A imagem a seguir ilustra esse cenário. A caixa à esquerda mostra a região interrompida. A caixa no meio representa a disponibilidade contínua dos dados após o failover, e a caixa à direita mostra a situação totalmente coberta depois que o cliente age para restaurar seus serviços para o pleno funcionamento.

Diagrama mostrando um cenário de desastre, failover e recuperação completa.

Eis o plano geral de recuperação:

  1. Crie uma nova capacidade de malha C2 em uma nova região.

  2. Crie um novo espaço de trabalho W2 em C2, incluindo seus itens correspondentes com os mesmos nomes que em C1. W1.

  3. Copie os dados do C1 interrompido. W1 a C2. W2.

  4. Siga as instruções dedicadas para cada componente para restaurar os itens para a sua função completa.

Planos de recuperação específicos da experiência

As seções a seguir fornecem guias passo a passo para cada experiência de malha para ajudar os clientes durante o processo de recuperação.

Engenharia de Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência de Engenharia de Dados. Abrange casas de lago, cadernos e definições de trabalho do Spark.

Casa do Lago

Lakehouses da região original continuam indisponíveis para os clientes. Para recuperar uma casa do lago, os clientes podem recriá-la no espaço de trabalho C2. W2. Recomendamos duas abordagens para recuperar casas de lago:

Abordagem 1: Usando script personalizado para copiar tabelas e arquivos Lakehouse Delta

Os clientes podem recriar lakehouses usando um script Scala personalizado.

  1. Crie a casa do lago (por exemplo, LH1) no espaço de trabalho C2 recém-criado. W2.

  2. Crie um novo bloco de anotações no espaço de trabalho C2. W2.

  3. Para recuperar as tabelas e arquivos do lakehouse original, você precisa usar o caminho ABFS para acessar os dados (consulte Conectando-se ao Microsoft OneLake). Você pode usar o exemplo de código abaixo (consulte Introdução ao Microsoft Spark Utilities) no bloco de anotações para obter os caminhos ABFS de arquivos e tabelas do lakehouse original. (Substituir C1. W1 com o nome real do espaço de trabalho)

    mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')

  4. Use o exemplo de código a seguir para copiar tabelas e arquivos para o lakehouse recém-criado.

    1. Para tabelas Delta, você precisa copiar a tabela uma de cada vez para recuperar na nova casa do lago. No caso de arquivos Lakehouse, você pode copiar a estrutura completa do arquivo com todas as pastas subjacentes com uma única execução.

    2. Entre em contato com a equipe de suporte para obter o carimbo de data/hora do failover necessário no script.

    %%spark
val source="abfs path to original Lakehouse file or table directory"
val destination="abfs path to new Lakehouse file or table directory"
val timestamp= //timestamp provided by Support

mssparkutils.fs.cp(source, destination, true)

val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
    .filter{sf => sf.isFile && sf.modifyTime > timestamp}

for(fileToDelte <- filesToDelete) {
    val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
    println(s"Deleting file $destFileToDelete")
    mssparkutils.fs.rm(destFileToDelete, false)
}

mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)

  5. Depois de executar o script, as tabelas aparecerão na nova casa do lago.

Abordagem 2: Usar o Gerenciador de Armazenamento do Azure para copiar arquivos e tabelas

Para recuperar apenas arquivos ou tabelas específicos do Lakehouse do lakehouse original, use o Gerenciador de Armazenamento do Azure. Consulte Integrar o OneLake com o Azure Storage Explorer para obter etapas detalhadas. Para tamanhos de dados grandes, use a Abordagem 1.

Nota

As duas abordagens descritas acima recuperam os metadados e os dados para tabelas formatadas em Delta, porque os metadados são colocalizados e armazenados com os dados no OneLake. Para tabelas formatadas não Delta (e.g. CSV, Parquet, etc.) que são criadas usando scripts/comandos DDL (Spark Data Definition Language), o usuário é responsável por manter e executar novamente os scripts/comandos DDL do Spark para recuperá-los.

Bloco de Notas

Os blocos de anotações da região primária permanecem indisponíveis para os clientes e o código nos blocos de anotações não será replicado para a região secundária. Para recuperar o código do Bloco de Anotações na nova região, há duas abordagens para recuperar o conteúdo do código do Bloco de Anotações.

Abordagem 1: Redundância gerenciada pelo usuário com integração Git (em visualização pública)

A melhor maneira de tornar isso fácil e rápido é usar a integração do Fabric Git e, em seguida, sincronizar seu notebook com o repositório ADO. Depois que o serviço fizer failover para outra região, você poderá usar o repositório para reconstruir o bloco de anotações no novo espaço de trabalho criado.

  1. Configure a integração do Git e selecione Conectar e sincronizar com o repositório ADO.

    Captura de tela mostrando como conectar e sincronizar o notebook com o repositório ADO.

    A imagem a seguir mostra o bloco de anotações sincronizado.

    Captura de tela mostrando o notebook sincronizado com o repositório ADO.

  2. Recupere o bloco de anotações do repositório ADO.

    1. No espaço de trabalho recém-criado, conecte-se ao repositório do Azure ADO novamente.

      Captura de tela mostrando o notebook reconectado ao repositório ADO.

    2. Selecione o botão Controle do código-fonte. Em seguida, selecione a ramificação relevante do repositório. Em seguida, selecione Atualizar tudo. O bloco de notas original aparecerá.

      Captura de tela mostrando como atualizar todos os blocos de anotações em uma ramificação.

      Captura de ecrã a mostrar a nota original recriada.

    3. Se o notebook original tiver uma casa de lago padrão, os usuários podem consultar a seção Lakehouse para recuperar a casa do lago e, em seguida, conectar a casa do lago recém-recuperada ao notebook recém-recuperado.

      Captura de tela mostrando como conectar uma casa do lago recuperada a um notebook recuperado.

    4. A integração do Git não suporta a sincronização de arquivos, pastas ou instantâneos do bloco de anotações no explorador de recursos do bloco de anotações.

      1. Se o bloco de notas original tiver ficheiros no explorador de recursos do bloco de notas:

        1. Certifique-se de salvar arquivos ou pastas em um disco local ou em algum outro lugar.

        2. Recarregue o ficheiro a partir do seu disco local ou unidades na nuvem para o bloco de notas recuperado.

      2. Se o bloco de anotações original tiver um instantâneo do bloco de anotações, salve-o também em seu próprio sistema de controle de versão ou disco local.

        Captura de tela mostrando como executar o bloco de anotações para salvar instantâneos.

        Captura de ecrã a mostrar como guardar instantâneos do bloco de notas.

Para obter mais informações sobre a integração do Git, consulte Introdução à integração do Git.

Abordagem 2: Abordagem manual para fazer backup do conteúdo do código

Se você não adotar a abordagem de integração do Git, poderá salvar a versão mais recente do código, os arquivos no explorador de recursos e o instantâneo do bloco de anotações em um sistema de controle de versão, como o Git, e recuperar manualmente o conteúdo do bloco de anotações após um desastre:

  1. Use o recurso "Importar bloco de anotações" para importar o código do bloco de anotações que você deseja recuperar.

    Captura de ecrã a mostrar como importar o código do bloco de notas.

  2. Após a importação, vá para o espaço de trabalho desejado (por exemplo, "C2. W2") para acessá-lo.

  3. Se o bloco de anotações original tiver uma lakehouse padrão, consulte a seção Lakehouse. Em seguida, conecte o lakehouse recém-recuperado (que tem o mesmo conteúdo do lakehouse padrão original) ao notebook recém-recuperado.

  4. Se o bloco de notas original tiver ficheiros ou pastas no explorador de recursos, volte a carregar os ficheiros ou pastas guardados no sistema de controlo de versão do utilizador.

Definição de trabalho do Spark

As definições de trabalho do Spark (SJD) da região primária permanecem indisponíveis para os clientes, e o arquivo de definição principal e o arquivo de referência no bloco de anotações serão replicados para a região secundária por meio do OneLake. Se você quiser recuperar o SJD na nova região, você pode seguir as etapas manuais descritas abaixo para recuperar o SJD. Observe que as execuções históricas do SJD não serão recuperadas.

Você pode recuperar os itens SJD copiando o código da região original usando o Gerenciador de Armazenamento do Azure e reconectando manualmente as referências do Lakehouse após o desastre.

  1. Crie um novo item SJD (por exemplo, SJD1) no novo espaço de trabalho C2. W2, com as mesmas definições e configurações do item SJD original (por exemplo, idioma, ambiente, etc.).

  2. Use o Gerenciador de Armazenamento do Azure para copiar Libs, Mains e Snapshots do item SJD original para o novo item SJD.

    Captura de tela mostrando como copiar da definição de trabalho de faísca original para a nova definição de trabalho de faísca.

  3. O conteúdo do código aparecerá no SJD recém-criado. Você precisará adicionar manualmente a referência Lakehouse recém-recuperada ao trabalho (Consulte as etapas de recuperação do Lakehouse). Os usuários precisarão reinserir os argumentos de linha de comando originais manualmente.

    Captura de tela mostrando argumentos de linha de comando para recuperar a definição de trabalho de faísca.

Agora você pode executar ou agendar seu SJD recém-recuperado.

Para obter detalhes sobre o Gerenciador de Armazenamento do Azure, consulte Integrar o OneLake ao Gerenciador de Armazenamento do Azure.

Ciência dos Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência de Ciência de Dados. Abrange modelos e experiências de ML.

Modelo e Experimento de ML

Os itens de Ciência de Dados da região primária permanecem indisponíveis para os clientes, e o conteúdo e os metadados em modelos e experimentos de ML não serão replicados para a região secundária. Para recuperá-los totalmente na nova região, salve o conteúdo do código em um sistema de controle de versão (como o Git) e execute manualmente o conteúdo do código novamente após o desastre.

  1. Recupere o bloco de notas. Consulte as etapas de recuperação do Bloco de Anotações.

  2. A configuração, as métricas de execução histórica e os metadados não serão replicados para a região emparelhada. Você terá que executar novamente cada versão do seu código de ciência de dados para recuperar totalmente os modelos e experimentos de ML após o desastre.

Armazém de Dados

Este guia orienta você pelos procedimentos de recuperação para a experiência do Data Warehouse. Abrange armazéns.

Armazém

Os armazéns da região original permanecem indisponíveis para os clientes. Para recuperar armazéns, use as duas etapas a seguir.

  1. Crie uma nova casa de lago provisória no espaço de trabalho C2. W2 para os dados que irá copiar do armazém original.

  2. Preencha as tabelas Delta do armazém aproveitando o warehouse Explorer e os recursos T-SQL (consulte Tabelas em data warehousing no Microsoft Fabric).

Nota

É recomendável que você mantenha o código do Warehouse (esquema, tabela, exibição, procedimento armazenado, definições de função e códigos de segurança) versionado e salvo em um local seguro (como o Git) de acordo com suas práticas de desenvolvimento.

Ingestão de dados via Lakehouse e código T-SQL

No espaço de trabalho C2 recém-criado. W2:

  1. Crie uma casa de lago provisória "LH2" em C2. W2.

  2. Recupere as mesas Delta no lakehouse provisório do armazém original seguindo as etapas de recuperação Lakehouse.

  3. Crie um novo armazém "WH2" em C2. W2.

  4. Conecte a casa do lago provisória em seu explorador de armazém.

    Captura de ecrã do Explorador de armazém durante a recuperação do armazém.

  5. Dependendo de como você vai implantar definições de tabela antes da importação de dados, o T-SQL real usado para importações pode variar. Você pode usar a abordagem INSERT INTO, SELECT INTO ou CREATE TABLE AS SELECT para recuperar tabelas de armazém de lakehouses. Mais adiante no exemplo, estaríamos usando o sabor INSERT INTO. (Se você usar o código abaixo, substitua exemplos por nomes reais de tabelas e colunas)

    USE WH1

INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])

SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
GO

  6. Por fim, altere a cadeia de conexão em aplicativos que usam seu armazém de malha.

Nota

Para clientes que precisam de recuperação de desastres entre regiões e continuidade de negócios totalmente automatizada, recomendamos manter duas configurações de Fabric Warehouse em regiões de malha separadas e manter a paridade de código e dados fazendo implantações regulares e ingestão de dados em ambos os locais.

Data Factory

Os itens do Data Factory da região primária permanecem indisponíveis para os clientes e as definições e configurações em pipelines de dados ou itens gen2 de fluxo de dados não serão replicadas para a região secundária. Para recuperar esses itens no caso de uma falha regional, você precisará recriar seus itens de Integração de Dados em outro espaço de trabalho de uma região diferente. As seções a seguir descrevem os detalhes.

Fluxos de dados Gen2

Se você quiser recuperar um item Dataflow Gen2 na nova região, precisará exportar um arquivo PQT para um sistema de controle de versão, como o Git, e, em seguida, recuperar manualmente o conteúdo do Dataflow Gen2 após o desastre.

  1. No item Dataflow Gen2, no separador Base do editor do Power Query, selecione Exportar modelo.

    Captura de ecrã a mostrar o editor do Power Query, com a opção Exportar modelo realçada.

  2. Na caixa de diálogo Exportar modelo, insira um nome (obrigatório) e uma descrição (opcional) para esse modelo. Quando terminar, selecione OK.

    Captura de tela mostrando como exportar um modelo.

  3. Após o desastre, crie um novo item Dataflow Gen2 no novo espaço de trabalho "C2. W2".

  4. No painel de vista atual do editor do Power Query, selecione Importar a partir de um modelo do Power Query.

    Captura de ecrã a mostrar a vista atual com Importar de um modelo do Power Query enfatizado.

  5. Na caixa de diálogo Abrir, navegue até a pasta de downloads padrão e selecione o arquivo .pqt salvo nas etapas anteriores. Em seguida, selecione Abrir.

  6. O modelo é então importado para o novo item Dataflow Gen2.

Pipelines de Dados

Os clientes não podem acessar pipelines de dados em caso de desastre regional e as configurações não são replicadas para a região emparelhada. Recomendamos criar seus pipelines de dados críticos em vários espaços de trabalho em diferentes regiões.

Inteligência em tempo real

Este guia orienta você pelos procedimentos de recuperação para a experiência de Inteligência em Tempo Real. Abrange bases de dados/conjuntos de consultas KQL e fluxos de eventos.

Banco de dados KQL/Queryset

Os usuários do banco de dados/conjunto de consultas KQL devem tomar medidas proativas para se proteger contra um desastre regional. A abordagem a seguir garante que, no caso de um desastre regional, os dados em seus conjuntos de consultas de bancos de dados KQL permaneçam seguros e acessíveis.

Use as etapas a seguir para garantir uma solução eficaz de recuperação de desastres para bancos de dados e conjuntos de consultas KQL.

  1. Estabelecer bancos de dados KQL independentes: configure dois ou mais bancos de dados/conjuntos de consultas KQL independentes em capacidades de malha dedicadas. Eles devem ser configurados em duas regiões diferentes do Azure (de preferência regiões emparelhadas com o Azure) para maximizar a resiliência.

  2. Replicar atividades de gerenciamento: qualquer ação de gerenciamento executada em um banco de dados KQL deve ser espelhada no outro. Isso garante que ambos os bancos de dados permaneçam sincronizados. As principais atividades a serem replicadas incluem:

    • Tabelas: Certifique-se de que as estruturas de tabela e as definições de esquema sejam consistentes entre os bancos de dados.

    • Mapeamento: duplique todos os mapeamentos necessários. Certifique-se de que as fontes de dados e os destinos estão alinhados corretamente.

    • Políticas: certifique-se de que ambos os bancos de dados tenham políticas semelhantes de retenção, acesso e outras políticas relevantes.

  3. Gerenciar autenticação e autorização: para cada réplica, configure as permissões necessárias. Certifique-se de que os níveis de autorização adequados sejam estabelecidos, concedendo acesso ao pessoal necessário, mantendo os padrões de segurança.

  4. Ingestão paralela de dados: para manter os dados consistentes e prontos em várias regiões, carregue o mesmo conjunto de dados em cada banco de dados KQL ao mesmo tempo em que o ingere.

Fluxo de eventos

Um fluxo de eventos é um local centralizado na plataforma Fabric para capturar, transformar e rotear eventos em tempo real para vários destinos (por exemplo, lakehouses, bancos de dados KQL/conjuntos de consultas) com uma experiência sem código. Desde que os destinos sejam suportados pela recuperação de desastres, os fluxos de eventos não perderão dados. Portanto, os clientes devem usar os recursos de recuperação de desastres desses sistemas de destino para garantir a disponibilidade dos dados.

Os clientes também podem obter redundância geográfica implantando cargas de trabalho idênticas do Eventstream em várias regiões do Azure como parte de uma estratégia ativa/ativa de vários sites. Com uma abordagem ativa/ativa em vários locais, os clientes podem acessar sua carga de trabalho em qualquer uma das regiões implantadas. Essa abordagem é a mais complexa e dispendiosa para a recuperação de desastres, mas pode reduzir o tempo de recuperação para quase zero na maioria das situações. Para serem totalmente redundantes geograficamente, os clientes podem

  1. Crie réplicas de suas fontes de dados em diferentes regiões.

  2. Crie itens Eventstream nas regiões correspondentes.

  3. Conecte esses novos itens às fontes de dados idênticas.

  4. Adicione destinos idênticos para cada fluxo de eventos em regiões diferentes.