Conseils sur la récupération d’urgence spécifiques à l’expérience

Cet article fournit des conseils propres à l’expérience pour récupérer les données Fabric en cas de catastrophe régionale.

Exemple de scénario

De nombreuses sections d’orientation de cet article utilisent le scénario suivant à des fins d’explication et d’illustration. Reportez-vous à ce scénario le cas échéant.

Supposons que vous avez une capacité C1 dans la région A qui a un espace de travail W1. Si vous avez activé la récupération d'urgence pour la capacité C1, les données OneLake sont répliquées dans une sauvegarde dans la région B. Si la région A subit des interruptions, le service Fabric en C1 bascule vers la région B.

L’image suivante illustre ce scénario. La boîte à gauche montre la région interrompue. La zone du milieu représente la disponibilité continue des données après le basculement, et la zone à droite montre la situation entièrement rétablie après l’action du client pour restaurer le plein fonctionnement de ses services.

Voici le plan de récupération général :

1. Créez une nouvelle capacité de tissu C2 dans une nouvelle région.

2. Créez un espace de travail W2 dans C2, incluant ses éléments correspondants avec les mêmes noms que dans C1.W1.

3. Copiez les données du C1.W1 perturbé vers C2.W2.

4. Suivez les instructions dédiées de chaque composant pour restaurer les éléments afin qu’ils fonctionnent pleinement.

Ce plan de récupération suppose que la région d’accueil du locataire reste opérationnelle. Si la région d’origine locataire subit une panne, les étapes décrites dans cet article dépendent de sa récupération, qui doit d’abord être initiée et complétée par Microsoft.

Plans de récupération spécifiques à l’expérience

Les sections suivantes fournissent des guides étape par étape pour chaque expérience Fabric afin de vous accompagner tout au long du processus de récupération.

Ingénierie des données

Ce guide vous guide tout au long des procédures de récupération pour l’expérience Ingénieurs de données. Il couvre les lakehouses, les notebooks, les définitions de tâches Spark, les fonctions de données utilisateur et les API GraphQL.

Lakehouse

Les lakehouses de la région d’origine restent indisponibles aux clients. Pour récupérer un lakehouse, les clients peuvent le recréer dans l'espace de travail C2.W2. Nous recommandons deux approches pour la récupération de lakehouses :

Approche 1 : utilisation d’un script personnalisé pour copier des fichiers et des tables Delta Lakehouse

Les clients peuvent recréer des lakehouses en utilisant un script Scala personnalisé.

1. Créez le lakehouse (par exemple, LH1) dans l’espace de travail C2.W2 nouvellement créé.

2. Créez un notebook dans l’espace de travail C2.W2.

3. Pour récupérer les tables et les fichiers de la lakehouse d'origine, consultez les données en utilisant des chemins OneLake tels que "abfss" (voir Connexion à Microsoft OneLake). Vous pouvez utiliser l’exemple de code suivant (voir Introduction aux utilitaires Microsoft Spark) dans le notebook pour obtenir les chemins ABFS des fichiers et des tables du lakehouse d’origine. (Remplacez C1.W1 par le nom réel de l’espace de travail)

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

4. Utilisez l’exemple de code suivant pour copier des fichiers et des tables dans le lakehouse nouvellement créé.

   1. Pour les tables Delta, vous devez copier les tables une par une afin de les récupérer dans le nouvel entrepôt de données. Dans le cas des fichiers Lakehouse, vous pouvez copier la structure complète du fichier avec tous les dossiers sous-jacents à l’aide d’une seule exécution.

   2. Contactez l’équipe du support technique pour obtenir le timestamp du basculement requis dans le 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
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Une fois que vous avez exécuté le script, les tables apparaissent dans le nouveau lakehouse.

Approche 2 : Utiliser Explorateur Stockage Azure pour copier des fichiers et des tables

Pour récupérer uniquement des fichiers ou des tables Lakehouse spécifiques à partir de la lakehouse d’origine, utilisez Explorateur Stockage Azure. Reportez-vous à Integrate OneLake avec Explorateur Stockage Azure pour obtenir des étapes détaillées. Pour des tailles volumineuses de données, utilisez l’Approche 1.

Récupération des vues de lac matérialisées de "Fabric"

Après le basculement, vous ne pouvez plus accéder aux vues matérialisées sur le lac depuis la région d’origine. Le processus de basculement ne réplique pas les calendriers d’actualisation ni l’historique d’exécution vers la région secondaire. Pour récupérer ces éléments, suivez les étapes suivantes après avoir récupéré vos données de Lakehouse :

• Récupérez les tables de Lakehouse en utilisant l’Approche 1 ou l’Approche 2 décrite plus tôt dans cet article. Copiez uniquement les tables sources.
• Récupérez les blocs-notes qui contiennent vos définitions MLV. Pour connaître les étapes de récupération, consultez la section Notebook.
• Exécutez les blocs-notes récupérés pour recréer les MLVs dans le nouveau Lakehouse. Pour plus d’informations sur la création de MLV, consultez Créer une vue Materialized Lake. Si vous avez copié des MLV à l’étape précédente, exécutez CREATE OR REPLACE lors de leur recréation.
• Recréez manuellement les planifications d’actualisation MLV dans le nouvel espace de travail. Vous ne pouvez pas récupérer l’historique des plannings ni les métriques d’exécution.
• Si vos MLVs alimentent des modèles sémantiques ou des rapports, vérifiez et mettez à jour les références d’ID lakehouse et d’ID de jeu de données si nécessaire. Reconnectez les rapports au modèle sémantique mis à jour et validez l’actualisation des données.

Ordinateur portable

Les carnets de la région principale restent indisponibles pour les clients, et le code des carnets ne se reproduit pas dans la région secondaire. Pour récupérer le code du notebook dans la nouvelle région, utilisez l’une des approches suivantes.

Approche 1 : redondance managée par l’utilisateur avec une intégration Git (dans la préversion publique)

Utilisez l’intégration Fabric Git pour synchroniser votre notebook avec votre dépôt Azure DevOps (ADO). Après que le service ait basculé vers une autre région, utilisez le dépôt pour reconstruire le carnet dans le nouvel espace de travail que vous avez créé.

1. Configurez l’intégration Git pour votre espace de travail, puis sélectionnez Connecter et synchroniser avec le référentiel ADO.

   

   L’image suivante montre le notebook synchronisé.

   

2. Récupérez le notebook à partir du référentiel ADO.

   1. Dans l’espace de travail nouvellement créé, connectez-vous à nouveau à votre dépôt ADO Azure.

      

   2. Sélectionnez le bouton Contrôle de code source. Sélectionnez ensuite la branche appropriée du référentiel. Sélectionnez ensuite Tout mettre à jour. Le bloc-notes d’origine s’affiche.

      

      

   3. Si le carnet original a une maison de lac par défaut, consultez la section Maison du lac pour récupérer la maison du lac, puis reliez la maison nouvellement récupérée au carnet nouvellement récupéré.

      

   4. L’intégration Git ne prend pas en charge la synchronisation des fichiers, des dossiers ou des captures instantanées de notebook dans l'explorateur de ressources du notebook.

      1. Si le notebook d’origine dispose de fichiers dans l’explorateur de ressources du notebook :

         1. Sauvegardez les fichiers ou dossiers sur un disque local ou ailleurs.

         2. Rechargez le fichier à partir de votre disque local ou de lecteurs cloud dans le notebook récupéré.

      2. Si le notebook d'origine a un instantané, enregistrez également cet instantané dans votre système de contrôle de version ou sur votre disque local.

         

         

Pour obtenir plus d’informations sur l’intégration Git, voir Introduction à l’intégration Git.

Approche 2 : approche manuelle de la sauvegarde du contenu de code

Si vous n’adoptez pas l’approche d’intégration Git, enregistrez la dernière version de votre code, vos fichiers dans l’explorateur de ressources et l’instantané du notebook dans un système de gestion de versions comme Git. Récupérez manuellement le contenu du carnet après un désastre :

1. Utilisez la fonction Importer un carnet pour importer le code que vous souhaitez récupérer.

   

2. Après l’importation, accédez à l’espace de travail souhaité (par exemple, « C2.W2 ») pour y accéder.

3. Si le notebook d’origine a un lakehouse par défaut, consultez la section Lakehouse. Connectez ensuite le lakehouse nouvellement récupéré (qui dispose du même contenu que le lakehouse par défaut d’origine) au notebook nouvellement récupéré.

4. Si le notebook d’origine a des fichiers ou des dossiers dans l’explorateur de ressources, rechargez les fichiers ou dossiers enregistrés dans le système de gestion de version de l’utilisateur.

Configuration d'une tâche Spark

Les définitions de tâches Spark (SJD) de la région primaire restent indisponibles, et OneLake réplique le fichier de définition principal et le fichier de référence dans le carnet vers la région secondaire. Si vous souhaitez récupérer le SJD dans la nouvelle région, suivez les étapes manuelles décrites dans cette section. Les parcours historiques du SJD ne sont pas retrouvés.

Vous pouvez récupérer les éléments SJD en copiant le code de la région d’origine en utilisant Explorateur Stockage Azure et en reconnectant manuellement les références Lakehouse après le sinistre.

1. Créer un nouvel élément SJD (par exemple, SJD1) dans le nouvel espace de travail C2. W2, avec les mêmes réglages et configurations que l’élément SJD original (par exemple, langage, environnement, etc.).

2. Utilisez Explorateur Stockage Azure pour copier les Libs, Mains et Snapshots de l’élément SJD d’origine vers le nouvel élément SJD.

   

3. Le contenu du code apparaît dans le SJD nouvellement créé. Vous devez ajouter manuellement au travail la référence du Lakehouse qui vient d’être récupérée (voir les étapes de récupération du Lakehouse). Les utilisateurs doivent saisir manuellement les arguments originaux de la ligne de commande.

   

Vous pouvez maintenant exécuter ou planifier votre SJD nouvellement récupérée.

Pour plus d’informations sur Explorateur Stockage Azure, consultez Integrate OneLake avec Explorateur Stockage Azure.

Fonctions de données utilisateur

Pour récupérer vos fonctions de données utilisateur dans une région saine, utilisez l’une des approches suivantes.

Approche 1 : Avec l’intégration Git (recommandée)

Le mécanisme de récupération préféré est l’intégration Fabric Git. En synchronisant les projets de fonctions de données utilisateur avec un dépôt Azure DevOps ou GitHub, vous pouvez rapidement les reconstruire dans un nouvel espace de travail après le basculement.

Préparez-vous avant une catastrophe

1. Configurez l’intégration Fabric Git pour l’espace de travail qui héberge la fonction de données utilisateur.
2. Connectez l’espace de travail à un dépôt Azure DevOps ou GitHub.
3. Enregistrez toutes les données utilisateur dans le dépôt et synchronisez régulièrement les modifications.
4. Stockez les paramètres spécifiques à l’environnement séparément dans des bibliothèques variables si nécessaire.

Étapes de récupération

Après une catastrophe régionale :

1. Créez une nouvelle capacité Fabric dans une région saine, comme le C2.
2. Créez un nouvel espace de travail, comme W2, dans cette nouvelle capacité.
3. Connectez l’espace de travail au même dépôt Azure DevOps ou GitHub.
4. Ouvrez Contrôle de code source et synchronisez le contenu du dépôt dans l’espace de travail.
5. Recréez ou récupérez toutes les ressources Fabric dépendantes, telles que les maisons lacustres, les bases de données SQL dans Fabric, les entrepôts et les événements professionnels.
6. Redéployez les fonctions de données utilisateur.
7. Validez l’exécution des fonctions et la connectivité des dépendances.
8. Mettez à jour les applications en aval, les pipelines de données ou tout autre système intégré afin qu’ils fassent référence aux fonctions restaurées.
9. Validation complète de bout en bout de tous vos scénarios.

Considérations importantes

• L’intégration Git ne récupère que le code source et les assets du projet.
• Les journaux historiques d’exécution ne sont pas récupérés.
• Les systèmes en aval peuvent nécessiter une reconnexion des points d’extrémité.

Pour plus d’informations, voir Fonctions de données utilisateur, contrôle de sources et déploiement.

Approche 2 : récupération manuelle

Si l’intégration Git n’était pas configurée avant la catastrophe, vous pouvez reconstruire manuellement les fonctions de données utilisateur à partir des sauvegardes du code source.

Préparez-vous avant une catastrophe

Accomplissez régulièrement les tâches suivantes et stockez les éléments dans un dépôt de contrôle de version externe ou un lieu de sauvegarde :

• Exportez le code source de la fonction vers un dépôt GitHub.
• Documentez et conservez les informations de dépendance.
• Paramètres de l’environnement du document.

Étapes de récupération

Après une catastrophe régionale :

1. Créez une nouvelle capacité Fabric dans une région saine, comme le C2.
2. Créez un nouvel espace de travail, comme W2.
3. Récupérer toutes les ressources requises par la fonction, y compris les lakehouses, les bases de données SQL dans Fabric, les entrepôts de données, les eventhouses et les services externes.
4. Créez un nouveau projet de fonction de données utilisateur.
5. Importez ou recréez le code source de la fonction.
6. Réappliquez les paramètres de configuration à l’exécution.
7. Réinstallez toutes les dépendances de fonction.
8. Redéployez la fonction.
9. Reconfigurez l’authentification et l’autorisation.
10. Recréez les éditeurs ou les consommateurs de Business Event, le cas échéant.
11. Effectuez des tests de validation de bout en bout pour vos scénarios et intégrations.

GraphQL

Les éléments GraphQL de la région primaire ne sont pas disponibles après un sinistre régional, et les définitions et configurations GraphQL ne sont pas répliquées dans la région secondaire. Pour récupérer GraphQL dans une nouvelle région, utilisez l’une des approches suivantes.

Approche 1 : Redondance gérée par l’utilisateur avec intégration Git

La meilleure façon de faciliter et de simplifier ce processus consiste à utiliser Fabric intégration Git, puis à synchroniser votre GraphQL avec votre dépôt ADO. Une fois que le service bascule vers une autre région, vous pouvez utiliser le dépôt pour reconstruire GraphQL dans le nouvel espace de travail que vous avez créé.

1. Créez un espace de travail dans la capacité et la région cibles.

2. Récupérez toutes les sources de données dépendantes, telles que Les bases de données Lakehouse, Warehouse ou SQL, en suivant leurs étapes de récupération respectives.

3. Mettez à jour la définition de GraphQL pour pointer vers les ressources nouvellement récupérées en modifiant des références spécifiques à l’environnement telles que les identifiants des espaces de travail source, les identifiants des éléments sources et les détails de connexion. Cette étape garantit une liaison correcte au moment du déploiement.

4. Redéployez les éléments GraphQL du dépôt Git dans le nouvel espace de travail. Cette étape recrée la structure et la configuration de l’API à l’aide des définitions mises à jour.

5. Réappliquez les paramètres des éléments, y compris les rôles, les contrôles d’accès et la configuration de l’authentification.

6. Réappliquez les références de point de terminaison en mettant à jour toutes les applications ou intégrations pour utiliser le point de terminaison GraphQL nouvellement créé.

7. Mettez à jour tous les pipelines de déploiement existants qui pointaient vers l’ancien espace de travail pour référencer l’espace de travail nouvellement créé.

8. Validez les fonctionnalités de bout en bout de l’API.

Approche 2 : Approche manuelle

Si vous ne suivez pas l’approche d’intégration Git, vous pouvez utiliser l’approche manuelle suivante pour récupérer GraphQL.

1. Créez un espace de travail dans la capacité et la région cibles.

2. Récupérez toutes les sources de données dépendantes, telles que Les bases de données Lakehouse, Warehouse ou SQL.

3. Recréez manuellement l’API GraphQL dans le nouvel espace de travail, notamment les définitions de schéma, les connexions de source de données et les relations.

4. Réappliquez les paramètres des éléments, y compris les rôles, les contrôles d’accès et la configuration de l’authentification.

5. Réappliquez les références de point de terminaison en mettant à jour toutes les applications ou intégrations pour utiliser le point de terminaison GraphQL nouvellement créé.

6. Mettez à jour tous les pipelines de déploiement existants qui pointaient vers l’ancien espace de travail pour référencer l’espace de travail nouvellement créé.

7. Validez les fonctionnalités de bout en bout de l’API.

Considérations importantes

1. GraphQL s’appuie sur des dépendances externes (telles que Lakehouse, Warehouse et SQL), que vous devez récupérer avant le déploiement de GraphQL.

2. Les définitions d’API GraphQL incluent des références spécifiques à l’environnement (telles que sourceWorkspaceId et sourceItemId). Lors de la récupération dans une nouvelle région, ces références peuvent devenir non valides. Mettez-les à jour pour qu’elles pointent vers des ressources nouvellement approvisionnées.

3. La liaison automatique de sources de données n’est pas garantie dans les scénarios de récupération d’urgence, en particulier lors de l’utilisation d’informations d’identification enregistrées ou de connexions entre espaces de travail.

4. D’autres paramètres, tels que la surveillance, l’autorisation, le RBAC, l’introspection et plus encore, ne sont pas conservés après un basculement. Vous devez rétablir ces paramètres dans la nouvelle région.

References

• Vue d’ensemble de l’intégration Fabric Git - Microsoft Fabric | Microsoft Learn

• Pipelines de contrôle de code source et de déploiement dans l’API pour GraphQL - Microsoft Fabric | Microsoft Learn 

App

Le système ne réplique pas les applications Fabric, y compris leur code, leur configuration et leurs métadonnées, vers les régions secondaires. Si la région principale échoue, l’application reste indisponible. Pour la récupération, stockez le code source de l’application en dehors du système dans GitHub, Azure DevOps ou un autre système de contrôle de version. Récupérez les données des applications séparément en suivant les conseils de reprise après sinistre pour chaque magasin de données Fabric sous-jacent.

Approche manuelle

Vous pouvez récupérer manuellement une application Fabric après un sinistre régional à l’aide du code source de l’application et de l’interface de ligne de commande Rayfin. 

Conditions préalables 

Avant qu’une catastrophe ne survienne :

• Stockez le code source de Fabric App dans GitHub, Azure DevOps ou un autre dépôt de contrôle de version. 

• Documentez le processus de récupération.  

Étapes de récupération 

1. Créez un espace de travail dans la capacité et la région cibles. 

2. Récupérez les ressources dépendantes avant de redéployer l’application.  

3. Récupérez le dernier code source de l’application Fabric depuis votre dépôt de contrôle de version ou une sauvegarde locale. 

4. Depuis le répertoire source de l’application, déployez l’application Fabric dans l’espace de travail de récupération en utilisant la CLI Rayfin. Exécutez rayfin up --workspace <new workspace>. 

5. Récupérez l'élément enfant de l'application (base de données SQL dans Fabric) en suivant ses procédures de récupération respectives.  

6. Réappliquez les paramètres au niveau des objets, y compris les rôles et les contrôles d’accès si nécessaire.  

7. Validez la fonctionnalité de l’application et assurez-vous que les utilisateurs disposent des bonnes permissions.  

Important 

• Maintenez le code source de Fabric App en dehors de la région Fabric pour permettre la récupération.  

• Les données d'application dans la base de données ne sont pas récupérées dans le cadre du déploiement de l'application Fabric et doivent être restaurées séparément.  Vous pouvez récupérer manuellement une application Fabric après un sinistre régional à l’aide du code source de l’application et de l’interface de ligne de commande Rayfin. 

Azure Databricks Storage

Azure Databricks Storage stocke les données dans OneLake. Pour protéger vos données contre une panne régionale, activez le paramètre de reprise après sinistre sur la capacité Fabric qui contient l’élément Azure Databricks Storage. Lorsque vous activez ce paramètre, OneLake réplique les données de manière asynchrone vers la région appairée Azure.

Si OneLake initie un basculement régional, les applications peuvent continuer à accéder aux données répliquées via le point de terminaison global OneLake après la fin du basculement. L'accès continu via les API publiques OneLake ne nécessite pas de créer un autre élément Azure Databricks Storage ni de copier les données vers un autre espace de travail.

Consultez OneLake Disaster Recovery and Data Protection pour connaître les comportements, considérations et limites applicables.

Pour la planification de la reprise après sinistre spécifique à Azure Databricks, voir Disaster recovery - Azure Databricks.

Science des données

Ce guide vous accompagne tout au long des procédures de récupération pour l’expérience Science des données. Il aborde les modèles et les expériences ML.

Modèle et expérience d’apprentissage automatique

Les éléments de la science des données provenant de la région principale restent indisponibles pour les clients, et le contenu ainsi que les métadonnées des modèles et expériences ML ne se reproduisent pas dans la région secondaire. Pour les récupérer complètement dans la nouvelle région, enregistrez le contenu de code dans un système de gestion de version (tel que Git) et réexécutez manuellement le contenu de code après le sinistre.

1. Récupérez le notebook. Consultez les Étapes de récupération de notebooks.

2. La configuration, les métriques exécutées par le passé et les métadonnées ne sont pas répliquées vers la région jumelée. Vous devez relancer chaque version de votre code data science pour récupérer entièrement les modèles et expériences ML après la catastrophe.

Entrepôt de données

Ce guide vous guide à travers les procédures de récupération pour la charge de travail Fabric Data Warehouse. Il couvre les articles d’entrepôt.

Entrepôt

Vous ne pouvez pas accéder aux entrepôts depuis la région d’origine. Pour récupérer des entrepôts, utilisez les deux étapes suivantes.

1. Créez une nouvelle maison de lac provisoire dans l’espace de travail C2. W2 pour les données que vous copiez depuis l’entrepôt d’origine.

2. Peuplez les tables Delta de l'entrepôt en utilisant l'Explorateur de l'entrepôt et les capacités T-SQL (voir Tables dans Fabric Data Warehouse).

Ingestion de données via un code Lakehouse et T-SQL

Dans un espace de travail C2.W2 nouvellement créé :

1. Créez un lakehouse temporaire « LH2 » dans C2.W2.

2. Récupérez les tables Delta dans le lakehouse intermédiaire à partir de l'entrepôt d'origine en suivant les Étapes de récupération de Lakehouse.

3. Créez un entrepôt « WH2 » dans C2.W2.

4. Connectez le lakehouse provisoire à votre explorateur d’entrepôts.

5. Selon la manière dont vous déployez les définitions de tables avant l’importation de données, le T-SQL réel utilisé pour les importations peut varier. Pour récupérer les tables d’entrepôt des maisons lacustres, vous pouvez utiliser , INSERT INTOSELECT INTO, ou CREATE TABLE AS SELECT approche. Dans l’exemple suivant, nous utilisons INSERT INTO. Si vous utilisez le code suivant, remplacez les exemples par de véritables noms de tables et de colonnes.

   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. Modifiez la chaîne de connexion dans les applications qui utilisent votre entrepôt Fabric.

Base de données miroir

Les clients ne peuvent pas accéder aux bases de données miroir depuis la région principale, et les paramètres ne se répliquent pas vers la région secondaire. Pour récupérer une base de données miroir après une défaillance régionale, vous devez la recréer dans un autre espace de travail d’une autre région.

Usine de Données (Data Factory)

Les clients ne peuvent pas accéder aux éléments Data Factory depuis la région principale, et les paramètres ainsi que la configuration dans les pipelines ou les éléments Dataflow Gen2 ne se reproduisent pas vers la région secondaire. Pour récupérer ces éléments après un échec régional, vous devez recréer vos éléments d’Intégration des données dans un autre espace de travail d’une autre région. Les sections suivantes décrivent les détails.

Flux de données Gen2

Pour récupérer un élément Dataflow Gen2 dans la nouvelle région, exportez un .pqt fichier vers un système de contrôle de versions tel que Git, puis récupérez manuellement le contenu Dataflow Gen2 après la catastrophe.

1. Depuis votre élément Dataflow Gen2, dans l’onglet Accueil de l’éditeur Power Query, sélectionnez Export template.

   

2. Dans la boîte de dialogue Export du modèle , saisissez un nom (obligatoire) et une description (optionnelle) pour ce modèle. Une fois cette opération effectuée, sélectionnez OK.

   

3. Après le sinistre, créez un élément Dataflow Gen2 dans le nouvel espace de travail « C2.W2 ».

4. Dans le volet d’affichage actuel de l’éditeur de Power Query, sélectionnez Importer à partir d’un modèle Power Query.

   

5. Dans la boîte d’ouverture Ouvrir , naviguez jusqu’à votre dossier de téléchargements par défaut et sélectionnez le .pqt fichier que vous avez sauvegardé lors des étapes précédentes. Sélectionnez ensuite Ouvrir.

6. Le modèle est ensuite importé dans votre nouvel élément Dataflow Gen2.

La fonction Enregistrer sous forme pour Dataflows n’est pas prise en charge en cas de reprise après sinistre.

Pipelines

Les clients ne peuvent pas accéder aux pipelines en cas de sinistre régional et les configurations ne sont pas répliquées dans la région jumelée. Construisez vos pipelines critiques dans plusieurs espaces de travail répartis dans différentes régions.

Tâche de copie

Les utilisateurs copyJob doivent entreprendre des mesures proactives pour se protéger contre une catastrophe régionale. L’approche suivante garantit que, après une catastrophe régionale, les CopyJobs d’un utilisateur restent disponibles.

Redondance gérée par l’utilisateur avec l’intégration Git (en préversion publique)

La meilleure façon de rendre ce processus simple et rapide est d’utiliser l’intégration Fabric Git, puis de synchroniser votre CopyJob avec votre dépôt Azure DevOps. Une fois que le service bascule vers une autre région, vous pouvez utiliser le référentiel pour reconstruire le CopyJob dans le nouvel espace de travail que vous avez créé.

1. Configurez l'intégration Git de votre espace de travail et sélectionnez connecter et synchroniser avec le dépôt Azure DevOps.

   

   L’image suivante montre le CopyJob synchronisé.

   

2. Récupérez le CopyJob depuis le dépôt Azure DevOps.

   1. Dans l’espace de travail nouvellement créé, connectez-vous et synchronisez à nouveau avec votre dépôt Azure DevOps. Tous les éléments Fabric de ce dépôt sont automatiquement téléchargés dans votre nouvel espace de travail.

      

   2. Si le CopyJob original utilise un Lakehouse, les utilisateurs peuvent se référer à la section Lakehouse pour récupérer le Lakehouse et ensuite connecter le CopyJob nouvellement récupéré au Lakehouse nouvellement récupéré.

Pour obtenir plus d’informations sur l’intégration Git, voir Introduction à l’intégration Git.

Travail Apache Airflow

Vous devez prendre des mesures proactives pour protéger les emplois Apache Airflow à Fabric contre une catastrophe régionale.

Gérez la redondance en utilisant l’intégration Fabric Git. D’abord, synchronisez votre travail Airflow avec votre dépôt ADO. Si le service bascule vers une autre région, vous pouvez utiliser le dépôt pour reconstruire le travail Airflow dans le nouvel espace de travail que vous avez créé.

Suivez ces étapes pour atteindre cet objectif :

1. Configurez l’intégration Git de votre espace de travail et sélectionnez Connecter et synchroniser avec le dépôt ADO.

2. Après cela, vous voyez votre job Airflow synchronisé avec votre dépôt ADO.

3. Si vous devez récupérer le travail Airflow à partir du référentiel ADO, créez un espace de travail, connectez-vous et synchronisez à nouveau avec votre dépôt ADO Azure. Tous les éléments Fabric, y compris Airflow, dans ce dépôt se téléchargent automatiquement dans votre nouvel espace de travail.

Intelligence en Temps Réel

Ce guide vous accompagne tout au long des procédures de récupération pour l’expérience Real-Time Intelligence. Il couvre les bases de données KQL, les ensembles de requêtes et les éléments du flux d’événements.

Activator

Les éléments de l’Activator de la région principale restent indisponibles pour les clients, et les définitions de déclencheur de l’Activator ne sont pas répliquées vers la région secondaire. Les utilisateurs de l’activateur doivent prendre des mesures proactives pour préparer la récupération d’urgence régionale.

Pour vous assurer que vous pouvez récupérer des éléments d’activateur en cas de sinistre régional, configurez Fabric intégration Git pour sauvegarder les définitions de déclencheur et les restaurer dans un espace de travail dans une autre région.

1. Configurez l’intégration Git de Fabric pour l’espace de travail contenant votre élément Activator, et synchronisez vos définitions de déclencheurs avec votre dépôt Git.
2. Conservez régulièrement les définitions de déclencheur d’activateur validées et synchronisées.
3. Pendant la récupération, créez un espace de travail dans la région cible (C2). W2), connectez-le au même référentiel et synchronisez-le pour restaurer les définitions de déclencheur.
4. Reconfigurez et validez toutes les sources de données et dépendances d’Activator dans le nouvel espace de travail.

Pour obtenir plus d’informations sur l’intégration Git, voir Introduction à l’intégration Git.

Modèle de graphe/ensemble de requêtes

Les clients ne peuvent pas accéder aux éléments du modèle Graph et du jeu de requêtes Graph depuis la région principale, et Fabric ne réplique pas ces éléments dans la région secondaire. Pour effectuer la récupération, créez ou utilisez une capacité dans une région différente et recréez-y le modèle Graph ainsi que les éléments du jeu de requêtes Graph.

1. Créez ou utilisez une capacité de Fabric existante dans une autre région qui n'est pas affectée par la catastrophe.

2. Créez un espace de travail ou utilisez un espace de travail existant dans cette capacité.

3. Recréez l’élément du modèle Graphe dans l’espace de travail secondaire (référencé à l’étape 2). Reconfigurez la définition du modèle, y compris les nœuds, les arêtes et autres, pour qu’elle corresponde au modèle Graph original.

4. Si le lakehouse d’origine se trouve dans la région défaillante, récupérez-le d’abord en suivant la section Lakehouse.

5. Connectez une maison lacustre comme source de données OneLake pour l’élément du modèle Graph nouvellement créé. Utilisez le lac récupéré s’il était dans la région défaillante ou reconnectez-vous à la zone de lac existante s’il reste disponible.

6. Reconfigurez tous les plannings de chargement de données ou connexions pour le modèle Graph dans le nouvel espace de travail.

7. Recréez l’élément du jeu de requêtes Graph dans l’espace de travail secondaire. Réentrez manuellement les requêtes et toutes les configurations de requêtes sauvegardées depuis le jeu de requêtes Graph d’origine.

Base de données/KQL Queryset

Les utilisateurs de la base de données et du set de requêtes KQL doivent prendre des mesures proactives pour se protéger contre une catastrophe régionale. L’approche suivante garantit qu’en cas de catastrophe régionale, les données de vos bases de données et questionnaires KQL restent sûres et accessibles.

Utilisez les étapes suivantes afin d’assurer une solution de récupération d’urgence efficace pour des ensembles de requêtes et des bases de données KQL.

1. Configurez des bases de données KQL indépendantes : Configurez deux bases de données KQL indépendantes et des ensembles de requêtes sur des capacités Fabric dédiées. Configurez ces bases de données dans deux régions Azure différentes (de préférence des régions Azure-appariées) pour maximiser la résilience.

2. Répliquez les activités de gestion : Imitez toute action de gestion que vous entreprenez dans une base de données KQL dans l’autre. Cette approche maintient les deux bases de données synchronisées. Les principales activités à reproduire incluent :

   • Tableaux : Assurez-vous que les structures de tables et les définitions de schéma sont cohérentes à travers les bases de données.

   • Mappage : dupliquez les mappages requis. Assurez-vous que les sources et destinations des données s’alignent correctement.

   • Politiques : Assurez-vous que les deux bases de données disposent de politiques similaires de conservation des données, d’accès et d’autres politiques pertinentes.

3. Gérer l’authentification et l’autorisation : Configurez les autorisations requises pour chaque réplique. Veillez à établir des niveaux d’autorisation appropriés, en accordant l’accès au personnel requis tout en maintenant les normes de sécurité.

4. Ingestion de données parallèles : pour maintenir la cohérence et la disponibilité des données dans plusieurs régions, chargez le même jeu de données dans chaque base de données KQL en même temps que vous l'ingérez.

Flux d'événements

Un flux d’événements est un emplacement centralisé dans la plateforme Fabric pour capturer, transformer et router des événements en temps réel vers différentes destinations (par exemple, lakehouses, bases de données KQL/ensembles de requêtes) avec une expérience sans code. Tant que les destinations prennent en charge la reprise après sinistre, les eventstreams ne perdent pas de données. Par conséquent, utilisez les capacités de reprise après sinistre de ces systèmes de destination pour garantir la disponibilité des données.

Vous pouvez également assurer une redondance géographique en déployant des charges de travail Eventstream identiques dans plusieurs régions Azure dans le cadre d’une stratégie multisite active/active. Avec une approche multi-site active/active, vous pouvez accéder à votre charge de travail dans n’importe laquelle des régions où elle est déployée. Cette approche est la plus complexe et la plus coûteuse en ce qui concerne la récupération d’urgence, mais elle peut réduire le temps de récupération à une valeur proche de zéro dans la majorité des situations. Pour assurer une redondance géographique complète :

1. Créez des répliques de vos sources de données dans différentes régions.

2. Créez des éléments du courant d’événements dans les régions correspondantes.

3. Connecter ces nouveaux éléments aux sources de données identiques.

4. Ajouter des destinations identiques pour chaque eventstream dans diverses régions.

Événements d’entreprise, événements Fabric et événements de Azure

Bien que Business Events, Fabric Events et Azure Events partagent la même infrastructure du hub en temps réel dans Microsoft Fabric, ils ont des origines, des comportements et des exigences de récupération distincts. Comprenez ces différences avant de planifier la reprise après sinistre :

• Les Fabric Events sont des abonnements à des événements qui réagissent aux activités produites par les ressources Fabric elles-mêmes. Ces événements incluent les changements du cycle de vie des éléments de l’espace de travail (comme la création, la mise à jour ou la suppression de lakehouses, de notebooks ou d’entrepôts), les exécutions de tâches (comme les exécutions de pipelines ou de notebooks), ainsi que les opérations sur les fichiers et dossiers OneLake. Ces abonnements sont basés sur push et éphémères. Les abonnements ne sont pas reproduits dans la région secondaire.

• Les Événements Azure sont des abonnements à des événements liés à l’activité générée par des comptes Stockage Blob Azure. Ces ressources Azure existent indépendamment de n’importe quelle capacité ou région Fabric. Bien que la ressource Stockage Blob Azure elle-même puisse rester disponible lors d'une panne régionale Fabric, les abonnements configurés dans Real-Time hub ne sont pas répliqués dans la région secondaire et doivent être recréés.

• Les événements métier sont une fonctionnalité distincte dans Fabric Real-Time Intelligence qui permet aux équipes de définir, de publier et d’agir sur des signaux métier significatifs. Les événements métier sont générés au sein de Fabric via Activator, des notebooks Spark ou des fonctions de données utilisateur, puis publiés dans Real-Time hub, où des consommateurs en aval tels qu’Activator, Eventhouse ou Power Automate peuvent réagir à ces événements. Les schémas d’événement sont régis de manière centralisée via le Registre de schémas. Eventhouse stocke automatiquement chaque événement professionnel publié, de sorte que sa récupération affecte directement la disponibilité de l’historique des événements métier. Aucune des configurations de l’éditeur ou du consommateur, des définitions de schéma ou des abonnements n’est répliquée vers la région secondaire.

Procédez comme suit pour restaurer les événements professionnels, les événements Fabric et les événements Azure dans le nouvel espace de travail de la région de récupération.

Événements d’entreprise :

1. Recréez l’événement métier utilisé par les éditeurs et les consommateurs en suivant l’article Créer des événements métier dans Fabric Real-Time Hub. Lors de la création de l’événement métier, vous créez la ressource Event Schema Set. La ressource Eventhouse est facultative en fonction du scénario. Si vous avez sauvegardé votre ensemble de schéma d’événements avec l’intégration Git, restaurez-le d’abord en suivant la section Ensemble de schémas d’événements, puis pointez l’événement métier vers l’ensemble de schéma restauré.

2. Recréez dans le nouvel espace de travail tous les éléments éditeurs qui génèrent des événements métier, tels que les notebooks Spark ou les fonctions de données utilisateur, en vous appuyant sur les articles consacrés aux éditeurs : Utiliser une fonction de données utilisateur comme éditeur d’événements métier, Utiliser Activator comme éditeur d’événements métier, Utiliser Notebook comme éditeur d’événements métier et Utiliser Eventstream comme éditeur d’événements métier.

3. Recréez les abonnements consommateurs dans Real-Time hub (par exemple, les règles Activator, les déclencheurs de notebook ou les flux Power Automate) qui réagissaient à l’origine aux événements métier dans la région concernée en suivant les articles Eventhouse and Real-Time Dashboard Integration with Business Events et Consume Business Events from Activator.

4. Vérifiez que les événements circulent de bout en bout en vérifiant que les abonnements sont actifs et que les données arrivent aux destinations attendues dans la région de récupération.

Pour les événements Fabric :

1. Recréez les abonnements dans Real-Time hub qui pointent vers les éléments de l’espace de travail, les travaux ou les chemins OneLake que vous avez restaurés dans la région de récupération, en suivant l’article Explorer les événements Fabric dans Fabric Real-Time hub.

2. Vérifiez que les événements circulent de bout en bout en vérifiant que les abonnements sont actifs et que les données arrivent aux destinations attendues dans la région de récupération.

Pour les événements Azure :

1. Les comptes Stockage Blob Azure ne sont pas affectés par une panne régionale Fabric. Recréez les abonnements aux événements dans Real-Time hub pointant vers les mêmes comptes Stockage Blob Azure en suivant l’article Définir des alertes sur les événements Stockage Blob Azure dans Real-Time hub.

2. Vérifiez que les événements circulent de bout en bout en vérifiant que les abonnements sont actifs et que les données arrivent aux destinations attendues dans la région de récupération.

Ensemble de schémas d’événements

Un ensemble de schémas d’événements est l’élément Fabric qui contient les définitions des types d’événements et des schémas dans Real-Time Intelligence. D’autres capacités s’appuient sur cela : les éditeurs écrivent des événements conformes à leurs schémas, et les consommateurs lisent selon les mêmes définitions.

Les ensembles de schémas d’événements de la région principale restent indisponibles pour les clients et ne sont pas répliqués dans la région secondaire. Cependant, comme un ensemble de schéma d’événements est une définition durable et créée plutôt qu’un abonnement éphémère, vous pouvez le sauvegarder à l’avance et le restaurer plutôt que de le réécrire à la main.

Recommandé : sauvegarder avec l’intégration de Fabric Git

Pour récupérer un schéma d’événement configuré après un désastre régional, configurez l’intégration Fabric Git avant qu’un sinistre ne survienne, et synchronisez l’espace de travail contenant vos ensembles de schémas d’événements avec votre dépôt Git.

1. Configurez l’intégration Fabric Git pour l’espace de travail contenant votre ensemble de schémas d’événements, et synchronisez-le avec votre dépôt Git.

2. Gardez le set de schéma d’événements engagé et synchronisé régulièrement, surtout après avoir ajouté des types d’événements ou publié de nouvelles versions de schéma.

3. Pendant la récupération, créez un nouvel espace de travail dans la région cible (C2. W2), le connecter au même dépôt, et synchroniser pour restaurer le schéma d’événements défini. Comme le nouvel espace de travail est vide, Git Sync amène le contenu du dépôt vers l’espace de travail.

4. Recréez tous les éditeurs et consommateurs qui utilisent l’ensemble de schémas, en suivant les recommandations pour ces types d’articles.

5. Validez que les éditeurs peuvent publier sur les types d’événements restaurés et que les consommateurs reçoivent les événements comme prévu.

La définition synchronisée inclut les types d’événements dans l’ensemble de schémas, les schémas et les versions de schéma. Cela n’inclut pas les inscriptions des éditeurs, les abonnements des consommateurs ni l’historique des événements. Récupérez ces éléments séparément, en suivant les indications pour les types d’éléments utilisant l’ensemble de schéma.

Alternative : recréer manuellement

Si vous n’avez pas configuré l’intégration Git avant le sinistre, recréez le schéma d’événements dans la région de récupération en suivant Créer et gérer les ensembles de schémas d’événements, puis ajoutez les types d’événements et les schémas contenus par l’ensemble de schémas d’origine en suivant Créer et gérer les schémas d’événements dans les ensembles de schémas.

Carte

Les éléments de la carte de la région primaire restent indisponibles pour les clients et ne sont pas répliqués dans la région secondaire.

Si vous souhaitez récupérer un élément map quand un sinistre se produit, configurez Fabric intégration Git et synchronize votre élément Map avec votre dépôt Git.

Pendant la récupération, après la configuration de la nouvelle région/capacité dans Fabric, vous pouvez utiliser le référentiel pour reconstruire l'élément Map dans le nouvel espace de travail que vous avez créé. Étant donné que le nouvel espace de travail est vide, Git sync obtient le contenu du référentiel dans l’espace de travail vide. Cette étape redonne vie à l'élément Map.

Ontologie

Les utilisateurs de l’ontologie doivent prendre des mesures proactives pour préparer la reprise après sinistre régionale. L’approche décrite ci-dessous garantit que, suite à une catastrophe régionale, votre ontologie reste récupérable et peut être restaurée rapidement.

La façon la plus simple et la plus rapide d’activer la récupération consiste à utiliser Fabric intégration Git et à synchroniser votre ontologie avec un référentiel Azure DevOps (ADO). Si le service bascule vers une autre région, vous pouvez utiliser ce référentiel pour reconstruire l’Ontology dans un espace de travail nouvellement créé.

Les éléments d'Ontology dans la région primaire ne sont pas disponibles pour les clients après un sinistre régional, et les éléments d'Ontology ne sont pas répliqués vers la région secondaire.

Pour récupérer un élément Ontology lors d’un sinistre, configurez Fabric intégration Git et synchronize l’élément Ontology avec votre référentiel ADO à l’avance.

Lors de la récupération, une fois la nouvelle région et la capacité dans Fabric configurées, vous pouvez utiliser le référentiel pour reconstruire l’élément Ontology dans un nouvel espace de travail. Étant donné que le nouvel espace de travail est vide, Git sync extrait le contenu du référentiel dans l’espace de travail, en restaurant efficacement l’élément Ontology.

Agent d’ontologie

Les utilisateurs de Ontology Agent doivent prendre des mesures proactives pour se préparer à la reprise après sinistre au niveau régional. L’approche décrite dans cette section garantit qu’après une catastrophe régionale, votre expérience Ontology Agent peut être restaurée dans un espace de travail nouvellement créé.

L’Agent d’Ontologie dépend de l’élément Ontologie et de toute source de données reliée à l’Ontologie, comme les lakehouses. Les clients ne peuvent pas accéder aux sessions Ontology Agent dans la région principale après une catastrophe régionale, et les sessions Ontology Agent ne sont pas répliquées dans la région secondaire. Les sessions de discussion actives, les actions en cours et l’historique des conversations de la région concernée ne peuvent pas être restaurés.

Pour récupérer l’expérience de l’Agent Ontology lors d’une catastrophe, configurez l’intégration Fabric Git et synchronisez l’élément Ontology avec votre dépôt Azure DevOps (ADO) à l’avance.

Pendant la récupération, une fois la nouvelle région et la capacité de Fabric mises en place, suivez les étapes suivantes :

1. Créez un nouvel espace de travail dans la nouvelle capacité Premium.
2. Connectez le nouvel espace de travail au même dépôt ADO qui contient l’élément Ontologie.
3. Utilisez Git Sync pour restaurer l’élément Ontologie dans le nouvel espace de travail.
4. Récupérez tous les éléments de données dépendants, comme les lakehouses, en suivant les consignes pour ces types d’éléments.
5. Confirmez que les données récupérées sont disponibles dans la région appariée. Pour les données adossées à OneLake, supposez que les données sont répliquées dans la région appariée, mais ne présumez pas que l’ordre des données répliquées sera conservé pendant la récupération.
6. Reliez l’élément Ontologie nouvellement récupéré aux sources de données récupérées.
7. Commencez une nouvelle session d’Agent d’Ontologie et validez que l’agent peut se connecter à l’élément d’Ontologie récupéré et aux sources de données.

Planning

Cet article décrit les procédures de récupération de la fonctionnalité de planification dans IQ. Il décrit les étapes nécessaires pour restaurer les composants clés, y compris les feuilles de planification, les feuilles PowerTable, les feuilles de renseignement, InfoBridge et les actifs de données associés.

Intégration Git pour la restauration des éléments de plan

L’approche recommandée consiste à synchroniser tous les éléments du plan avec un référentiel Azure DevOps (ADO) ou GitHub à l’aide de l’intégration Git de Fabric. Après un basculement, utilisez le référentiel pour restaurer les éléments dans le nouvel espace de travail.

Avant une catastrophe (mesures proactives) :

1. Dans l’espace de travail W1, accédez aux paramètres de l’espace de travail et configurez l’intégration Git.

2. Sélectionnez Se connecter et synchroniser avec votre référentiel ADO ou GitHub.

3. Sélectionnez les éléments de plan à télécharger vers le référentiel et sélectionnez Commit.

   

4. Vérifiez que l’état Git des éléments de plan est synchronisé.

5. Établir une discipline de validation : valider après chaque modification significative d’une définition de plan afin que le référentiel reflète toujours l’état le plus récent.

Étapes de rétablissement :

1. Créez un espace de travail W2 à l’intérieur de la capacité C2 dans la région saine.

2. Dans l’espace de travail W2, accédez aux paramètres de l’espace de travail et reconnectez-vous au même référentiel ADO/GitHub.

3. Sélectionnez Contrôle de code source. Sélectionnez la branche de dépôt appropriée, puis sélectionnez Mettre à jour tout. Tous les éléments de plan sont téléchargés sur W2.

Les composants suivants sont restaurés après la récupération :

• Feuilles PowerTable : Paramètres de table source, configuration de colonne, accès aux lignes, propriétés visuelles (disposition, formats, etc.), identification des lignes, paramètres de commentaire, dimensions à variation lente (SCD), approbations, automatisations et formulaires.
• Feuilles de planification : Propriétés de la feuille (mise en forme, mise en forme conditionnelle, etc.), paramètres de commentaire, paramètres d’écriture différée, colonnes d’entrée de données, lignes d’entrée de données, scénarios et signets.
• InfoBridge : Sources InfoBridge, requêtes InfoBridge, étapes de transformation, destinations d’écriture différée, paramètres d’écriture différée, mappages de requêtes liés, groupes de requêtes, propriétés visuelles (blend). Ces éléments ne peuvent pas être récupérés : sources basées sur des fichiers (CSV, Excel), feuilles de charge de travail croisée qui utilisent des sources basées sur des fichiers.
• Intelligence: Tous les graphiques et matrices.

Restauration Fabric SQL pour la planification

Les données entrées dans les feuilles de planification, les tables utilisées dans PowerTable et les données d’écriture différée sont stockées dans des bases de données SQL et doivent être considérées comme faisant partie de votre stratégie de récupération d’urgence. Pour récupérer des bases de données SQL, consultez la section base de données SQL .

• Métadonnées du plan de restauration : chaque élément de plan est associé à une base de données __fabric_plan_sys qui stocke les métadonnées pour les fonctionnalités de planification, notamment les commentaires, les scénarios, les entrées de données et la configuration de la réécriture. La base de données __fabric_plan_sys n’est pas restaurée automatiquement et doit être récupérée explicitement.

• Restaurer des bases de données d’écriture différée : si votre plan utilise des destinations d’écriture différée SQL, vous devez également récupérer les bases de données associées manuellement. Les destinations d’écriture différée SQL configurées ne sont pas restaurées automatiquement.

• Restauration des tables utilisées dans PowerTable : Toutes les tables créées par PowerTable sont stockées dans une base de données SQL dans Fabric. Vous devez également récupérer ces tables pendant la récupération d’urgence.

Agents d’opérations

Les utilisateurs de l’agent d’exploitation doivent prendre des mesures proactives pour préparer la récupération d’urgence régionale. La suite de l’approche décrite dans cette section permet de s’assurer que vos agents peuvent être restaurés rapidement après une panne régionale.

Utilisez Fabric intégration Git pour synchroniser votre espace de travail avec un référentiel. Cette approche vous permet de reconstruire des configurations d’agent dans un nouvel espace de travail si le service bascule vers une autre région.

Les éléments de l’agent des opérations dans la région principale ne sont pas disponibles en cas de sinistre régional. Les configurations de l’agent, les modèles de comportement et les journaux d’activité ne sont pas répliqués dans la région secondaire. Les opérations en cours, les sessions de conversation actives et les événements précédemment ingérés au moment de la catastrophe sont également perdus.

Pour préparer la récupération, configurez Fabric intégration Git et synchronisez vos éléments d’agent avec votre référentiel ADO avant qu’un sinistre ne se produise.

Lors de la récupération, configurez votre nouvelle région et votre capacité dans Fabric, puis utilisez le référentiel synchronisé pour restaurer des configurations d’agent dans un nouvel espace de travail. Git Sync extrait le contenu stocké du référentiel dans l’espace de travail vide, recréant vos éléments d’agent.

Une fois les configurations restaurées, vérifiez que toutes les bases de données Eventhouse (KQL) référencées ou les sources de données spécifiques à la région sont accessibles dans la nouvelle région. Mettez à jour les références de point de terminaison dans les configurations de l’agent si nécessaire. Enfin, redémarrez vos agents et les utilisateurs lancent de nouvelles sessions de conversation. Les conversations précédentes ne peuvent pas être reprise.

Databases

Ce guide décrit les procédures de récupération pour l’expérience de la base de données.

SQL database

Pour vous protéger contre une défaillance régionale, les utilisateurs de bases de données SQL peuvent prendre des mesures proactives pour exporter régulièrement leurs données et utiliser les données exportées pour recréer la base de données dans un nouvel espace de travail si nécessaire.

Utilisez l’outil CLI SqlPackage qui offre la portabilité des bases de données et facilite les déploiements de bases de données.

1. Utilisez l’outil SqlPackage pour exporter la base de données dans un .bacpac fichier. Pour plus d’informations, consultez Exporter une base de données avec SqlPackage .
2. Stockez le .bacpac fichier dans un endroit sécurisé, situé dans une région différente de la base de données. Des exemples incluent le stockage du .bacpac fichier dans un Lakehouse situé dans une autre région, l'utilisation d'un compte stockage Azure géo-redondant, ou l'utilisation d'un autre support de stockage sécurisé situé dans une autre région.
3. Si la base de données et la région SQL ne sont pas disponibles, vous pouvez utiliser le .bacpac fichier avec SqlPackage pour recréer la base de données dans un espace de travail dans une nouvelle région – Espace de travail C2. W2 dans la région B, comme décrit dans le scénario ci-dessus. Suivez les étapes détaillées dans Importer une base de données avec SqlPackage pour recréer la base de données avec votre .bacpac fichier.

La base de données recréée est une base de données indépendante de la base de données d’origine et reflète l’état des données au moment de l’opération d’exportation.

Considérations relatives au retour arrière

La base de données recréée est une base de données indépendante. Les données ajoutées à la base de données recréée ne seraient pas reflétées dans la base de données originale. Si vous prévoyez de revenir à la base de données d’origine lorsque la région d’origine sera disponible, vous devez envisager de rapprocher manuellement les données de la base de données recréée avec la base de données d’origine.

Platform

La plateforme fait référence aux services partagés et à l’architecture sous-jacents qui s’appliquent à toutes les charges de travail. Cette section décrit les procédures de récupération pour les capacités Fabric partagées.

Surveillance d’un espace de travail

La surveillance de l’espace de travail collecte des journaux d’activité dans l’espace de travail dans lequel vous l’activez. Après avoir récupéré votre espace de travail en tant que C2. W2, activez la surveillance de l’espace de travail sur W2. Il commence à collecter des données de surveillance pour l’espace de travail récupéré.

Les données de surveillance de l’espace de travail d’origine (C1.W1) ne sont pas reprises, car elles reflètent l’activité de l’espace de travail auquel elles sont associées.

Bibliothèque de variables

Microsoft Fabric bibliothèques de variables permettent aux développeurs de personnaliser et de partager des configurations d’éléments dans un espace de travail, ce qui simplifie la gestion du cycle de vie du contenu. Du point de vue de la récupération d’urgence, les utilisateurs de la bibliothèque de variables doivent se protéger de manière proactive contre un sinistre régional. Cette protection peut être assurée via l'intégration Fabric Git, qui garantit qu'après un désastre régional, la bibliothèque de variables de l'utilisateur reste disponible. Pour récupérer une bibliothèque de variables, suivez ces étapes :

• Utilisez Fabric intégration Git pour synchroniser votre bibliothèque de variables avec votre référentiel ADO. En cas de sinistre, vous pouvez utiliser le référentiel pour reconstruire la bibliothèque de variables dans le nouvel espace de travail que vous avez créé. Procédez comme suit :

  1. Connectez votre espace de travail au dépôt Git comme décrit ici.
  2. Veillez à conserver WS et le dépôt synchronisés avec commit et update.
  3. Récupération : en cas de sinistre, utilisez le référentiel pour reconstruire la bibliothèque de variables dans un nouvel espace de travail :

• Dans l’espace de travail nouvellement créé, connectez-vous et synchronisez à nouveau avec votre dépôt ADO Azure.

• Tous les éléments Fabric de ce référentiel sont automatiquement téléchargés dans votre nouvel espace de travail.

• Après avoir synchronisé vos éléments à partir de Git, ouvrez vos bibliothèques de variables dans le nouvel espace de travail et sélectionnez manuellement le jeu de valeurs actives souhaité.

Plan de déploiement

Un plan de déploiement est un élément dans un espace de travail Fabric. Il regroupe les éléments et donne l’ordre de les déployer. Il peut exécuter des actions avant ou après chaque déploiement d’objet. La définition de l’article stocke ces paramètres, entrées et références d’éléments. Le plan n’a pas de stockage séparé pour les valeurs utilisées à l’exécution.

Préparez-vous à la récupération en utilisant l’intégration Fabric Git :

1. Connectez l’espace de travail contenant le plan à un dépôt Azure DevOps ou GitHub.
2. Validez le plan ainsi que tous les éléments de l’espace de travail qu’il utilise.
3. Validez chaque modification pour que Git ait les dernières définitions.

Après une catastrophe régionale :

1. Créez un espace de travail dans la région saine.
2. Connectez l’espace de travail au même dépôt et à la même branche.
3. Mettez à jour l’espace de travail depuis Git. Cette étape restaure le plan et ses éléments.

Git rétablit la définition complète du plan. Il ne restaure ni les données ni l’état d’exécution des éléments liés. Utilisez les sections de cet article pour récupérer ces objets.

Clés gérées par le client pour les espaces de travail Fabric

Vous pouvez utiliser les clés gérées par le client (CMK) stockées dans Azure Key Vault pour ajouter une couche supplémentaire de chiffrement au-dessus des clés gérées par Microsoft pour les données au repos. Si Fabric devient inaccessible ou inopérant dans une région, ses composants basculent vers une instance de sauvegarde. Pendant le basculement, la fonctionnalité CMK prend en charge les opérations en lecture seule. Tant que le service Azure Key Vault reste en état de santé et que les autorisations d’accès au coffre sont intactes, Fabric continue de se connecter à votre clé et vous permet de lire les données normalement. Cela signifie que les opérations suivantes ne sont pas prises en charge pendant le basculement : activation et désactivation du paramètre CMK de l’espace de travail et mise à jour de la clé.

Fabric Assistant Migration pour une base de données SQL dans Fabric

Le Fabric Assistant Migration peut déplacer une base de données SQL Server dans une base SQL en Fabric en trois étapes : l’assistant de migration crée la base de données cible et lance la migration, le moniteur de migration suit l’avancement pendant le déploiement du schéma depuis un DACPAC, le Assistant Migration aide à revoir et corriger les erreurs de script, à préparer la base de données, à copier les données avec un travail de copie, et à finaliser la copie.

La progression de la migration n’est pas reproduite vers une autre région, et un déploiement interrompu ne peut pas être repris. Ces pannes n'affectent pas la base de données SQL Server source, donc vous pouvez relancer l'assistant de migration. Si la région d’origine n’est pas disponible, suivez d’abord le plan général de récupération de cet article pour créer la capacité C2 et l’espace de travail W2 dans la région appariée, puis lancez la migration dans W2. Si la région d’origine se récupère, vous pouvez réessayer la migration dans l’espace de travail d’origine.

Une perturbation régionale peut entraîner l’échec d’une migration de trois manières :

• La base de données cible n’est pas créée

  Si Fabric ne peut pas créer la base de données cible, l'assistant de migration affiche une erreur et la migration ne démarre pas. Sélectionnez Lancer la migration pour réessayer, ou réessayez plus tard.

  L’assistant tente de supprimer une base de données incomplète, mais le nettoyage peut échouer lors d’une interruption. Avant de réessayer, vérifiez dans l’espace de travail qu’il y a une base de données avec le nom cible. Confirmez que c’est la base de données incomplète de la tentative ratée avant de la supprimer.

• Le déploiement échoue

  Si le déploiement est interrompu, le moniteur de migration cesse de rapporter l’avancement, ouvre la base de données cible et affiche un dialogue indiquant l’échec du déploiement. Vous ne pouvez pas reprendre un déploiement raté, et la base de données créée par la tentative reste dans l’espace de travail.

  Pour récupérer :

  1. Confirmez que Fabric est disponible et que vous avez utilisé le DACPAC pour la migration originale.
  2. Identifiez la base de données créée par la tentative ratée. Supprimez-le s’il ne contient rien que vous devez garder. Sinon, garde-la et utilise un autre nom pour la nouvelle base de données.
  3. Lancer une nouvelle migration depuis le DACPAC source. La migration crée une nouvelle base de données.

  Les données sont copiées par un travail de copie dans Data Factory. Si vous avez synchronisé la tâche de copie avec Git avant la perturbation, consultez la tâche de copie dans les instructions Data Factory. Sinon, créez un nouveau travail de copie dans le cadre de la nouvelle migration.

• L’historique des migrations ne se charge pas

  Si l'Assistant Migration ne peut pas récupérer l'historique des migrations, il indique que les informations de migration ne sont plus disponibles. La progression enregistrée dans le navigateur actuel est préservée, et la base de données cible n’est pas affectée. Rafraîchissez la page pour recharger l’historique de migration.

OneLake

Cette section vous guide tout au long des procédures de récupération pour les fonctionnalités OneLake. Pour plus d’informations sur la récupération d’urgence pour les données OneLake, consultez La récupération d’urgence de OneLake.

Stratégies de gestion du cycle de vie

Si Fabric devient inaccessible ou inopérant dans une région, vous pouvez toujours lire et mettre à jour votre politique de cycle de vie OneLake lors du basculement. Les données déplacées vers le niveau intermédiaire ou le niveau froid restent dans ce niveau. Pour appliquer votre politique existante à votre nouvel espace de travail de récupération, suivez ces étapes :

1. Utilisez « Export Policy » dans votre espace de travail d’origine et enregistrez l’intégralité de la stratégie de cycle de vie.
2. Appelez l’API Import Policy sur votre espace de travail récupéré, en utilisant votre stratégie de cycle de vie exportée comme corps de la requête.

Règles d’instance de ressource

Les règles d’instance de ressource vous aident à contrôler en toute sécurité l’accès aux données dans OneLake à l’aide d’identités de ressources Azure approuvées. Lors du basculement régional, le système continue d’appliquer les règles existantes relatives à l’accès en lecture. Toutefois, vous ne pouvez pas créer, mettre à jour ou supprimer des règles d’instance de ressource tant que l’espace de travail n’est pas retourné à un état accessible en écriture.

Informations connexes

• guide de récupération d’urgence Microsoft Fabric