Partager via

Fiabilité dans Microsoft Fabric

  • Article

Cet article décrit la prise en charge de la fiabilité dans Microsoft Fabric et la résilience intra-régionale avec les zones de disponibilité et la reprise d’activité de récupération inter-région et la continuité d’activité. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes de centres de données physiquement séparés au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.

Fabric déploie des efforts commercialement raisonnables pour prendre en charge les zones de disponibilité redondantes, où les ressources se répliquent automatiquement entre les zones, sans que vous ayez à les mettre en place ou à les configurer.

Prérequis

  • Fabric fournit actuellement une prise en charge partielle des zones de disponibilité dans un nombre limité de régions. Cette prise en charge partielle de la zone de disponibilité couvre les expériences (et/ou certaines fonctionnalités au sein d’une expérience).
  • Les expériences telles que les flux d’événements ne prennent pas en charge les zones de disponibilité.
  • L’engineering données prend en charge les zones de disponibilité si vous utilisez OneLake. Si vous utilisez d’autres sources de données, comme ADLS Gen2, vous devez alors confirmer l’activation du stockage redondant interzone (ZRS).
  • La disponibilité de zone peut ou non être disponible pour les expériences et/ou fonctionnalités Fabric qui sont en préversion.
  • Les passerelles locales et les modèles sémantiques volumineux dans Power BI ne prennent pas en charge les zones de disponibilité.
  • Data Factory (pipelines) prend en charge les zones de disponibilité en Europe Ouest, mais les exécutions de pipelines nouveaux ou en cours peuvent échouer en cas de panne de zone.

Régions prises en charge

Fabric fait des efforts commercialement raisonnables pour fournir une prise en charge de zone de disponibilité dans différentes régions comme suit :

Amérique Power BI Datamarts Data Warehouses Analytique en temps réel Data Factory (pipelines) Engineering données Base de données SQL
Brésil Sud
Centre du Canada
USA Centre
USA Est
USA Est 2
États-Unis - partie centrale méridionale
USA Ouest 2
USA Ouest 3
Europe Power BI Datamarts Data Warehouses Analytique en temps réel Data Factory (pipelines) Engineering données Base de données SQL
France Centre
Allemagne Centre-Ouest
Italie Nord
Europe Nord
Norvège Est
Pologne Centre
Sud du Royaume-Uni
Europe Ouest
Moyen-Orient Power BI Datamarts Data Warehouses Analytique en temps réel Data Factory (pipelines) Engineering données Base de données SQL
Qatar Centre
Israël Central
Afrique Power BI Datamarts Data Warehouses Analytique en temps réel Data Factory (pipelines) Engineering données Base de données SQL
Afrique du Sud Nord
Asie-Pacifique Power BI Datamarts Data Warehouses Analytique en temps réel Data Factory (pipelines) Engineering données Base de données SQL
Australie Est
Japon Est
Asie Sud-Est

Expérience en cas de panne de zone

Lors d’une panne à l’échelle de la zone, aucune action n’est requise lors de la récupération de zone. Les capacités de Fabric dans les régions répertoriées dans les régions prises en charge s'autorépareront et se rééquilibreront automatiquement pour tirer parti de la zone saine. L’exécution de Travaux Spark peut échouer si le nœud principal se trouve dans la zone ayant échoué. Dans ce cas, les travaux doivent être soumis à nouveau.

Important

Bien que Microsoft s’efforce de fournir une prise en charge uniforme et cohérente de la zone de disponibilité, dans certains cas de défaillance de zone de disponibilité, les capacités Fabric situées dans les régions Azure où les fluctuations de la demande des clients sont plus importantes peuvent présenter une latence supérieure à la normale.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Cette section décrit un plan de récupération d’urgence pour Fabric conçu pour aider votre organisation à sécuriser et à rendre ses données accessibles en cas de sinistre régional non planifié. Le plan couvre les rubriques suivantes :

  • Réplication inter-région : Fabric offre une réplication inter-région pour les données stockées dans OneLake. Vous pouvez accepter ou refuser cette fonctionnalité selon vos exigences.

  • Accès aux données après sinistre : dans un scénario de sinistre régional, Fabric garantit l’accès aux données, avec certaines limitations. Bien que la création ou la modification de nouveaux éléments soit limitée après le basculement, le focus principal reste sur la garantie que les données existantes restent accessibles et intactes.

  • Conseils pour la récupération : Fabric fournit un ensemble structuré d’instructions pour vous guider dans le processus de récupération. Les conseils structurés facilitent la transition vers les opérations régulières.

Power BI, qui fait désormais partie de la plateforme Fabric, dispose d’un solide système de récupération d’urgence en place et offre les fonctionnalités suivantes :

  • BCDR par défaut : Power BI inclut automatiquement les fonctionnalités de récupération d’urgence dans son offre par défaut. Vous n’avez pas besoin d’accepter ou d’activer cette fonctionnalité séparément.

  • Réplication inter-région : Power BI utilise la réplication géoredondante de stockage Azure et la réplication géoredondante Azure SQL pour garantir que les instances de sauvegarde existent dans d’autres régions et peuvent être utilisées. Cela signifie que les données sont dupliquées dans différentes régions, améliorant leur disponibilité et réduisant les risques liés aux pannes régionales.

  • Services et accès continus après sinistre : même pendant les événements perturbants, les éléments Power BI restent accessibles en mode lecture seule. Les éléments incluent des modèles sémantiques, des rapports et des tableaux de bord, ce qui permet aux entreprises de poursuivre leurs processus d’analyse et de prise de décision sans entrave significative.

Pour plus d’informations, consultez la FAQ sur la haute disponibilité, le basculement et la récupération d’urgence de Power BI

Important

Pour les clients dont la région d'origine ne dispose pas d'une région Azure pair et qui sont touchés par un sinistre, la possibilité d'utiliser les capacités Fabric peut être compromise, même si les données au sein de ces capacités sont répliquées. Cette limitation est liée à l’infrastructure de la région d’origine, essentielle pour l’opération des capacités.

Fonctionnalité de capacité et de région d’accueil

Pour une planification efficace de la reprise après sinistre, il est essentiel que vous compreniez la relation entre votre région d'origine et les sites de capacité. La compréhension des régions d'origine et des emplacements de capacité vous aide à effectuer des sélections stratégiques de régions de capacité, ainsi que des processus de réplication et de récupération correspondants.

La région d’accueil de la location et du stockage de données de votre organisation est définie sur l’emplacement de l’adresse de facturation du premier utilisateur qui s’inscrit. Pour plus d’informations sur la configuration de la location, accédez à Planification de l’implémentation de Power BI : configuration du locataire. Lorsque vous créez de nouvelles capacités, votre stockage de données est défini par défaut dans la région d'origine. Si vous souhaitez modifier votre région de stockage de données vers une autre région, vous devez activer multi-géographique, une fonctionnalité Fabric Premium.

Important

Le choix d'une région différente pour votre capacité n'entraîne pas la délocalisation de toutes vos données vers cette région. Certains éléments de données restent stockés dans la région d’accueil. Pour voir quelles données restent dans la région d’accueil et quelles données sont stockées dans la région multi-géographique, consultez Configurer la prise en charge multi-géographique pour Fabric Premium.

Dans le cas d'une région d'origine qui n'a pas de région jumelée, les capacités de n'importe quelle région équipée de Multi-Geo peuvent rencontrer des problèmes opérationnels si la région d'origine subit un désastre, car la fonctionnalité de base du service est liée à la région d'origine.

Si vous sélectionnez une région de l'UE dotée de la fonction Multi-Geo, il est garanti que vos données sont stockées à l'intérieur du périmètre de l'UE.

Pour savoir comment identifier votre région d’origine, consultez Rechercher votre région d’accueil Fabric.

Paramètre de capacité de récupération d’urgence

Fabric fournit un commutateur de récupération d’urgence sur la page des paramètres de la capacité. Il est disponible dans les emplacement où les associations régionales Azure s’alignent sur la présence du service Azure. Voici les spécificités de ce commutateur :

  • Rôle d’accès : seuls les utilisateurs dotés du rôle administrateur de capacité ou supérieur peuvent utiliser ce commutateur.

  • Granularité : la granularité de ce commutateur correspond au niveau de la capacité. Elle est disponible pour les capacités Fabric et Premium.

  • Étendue des données : la bascule de récupération d’urgence traite spécifiquement les données OneLake qui inclut les données Lakehouse et Warehouse. Le commutateur n’affecte pas vos données stockées en dehors de OneLake.

  • Continuité d’activité et reprise d’activité (BCDR) pour Power BI : bien que la récupération d’urgence pour des données OneLake puisse être activée ou désactivée, la BCDR pour Power BI est toujours prise en charge, que le commutateur soit activé ou désactivé.

  • Fréquence : une fois que vous modifiez le paramètre de capacité de récupération d’urgence, vous devez attendre 30 jours avant de pouvoir le modifier à nouveau. La période d’attente est définie pour maintenir la stabilité et empêcher le basculement constant,

Capture d’écran du paramètre de locataire de récupération d’urgence.

Remarque

Après l’activation du paramètre de capacité de récupération d’urgence, le démarrage de la réplication des données peut prendre jusqu’à une semaine.

Réplication des données

Lorsque vous activez le paramètre de la capacité de récupération d’urgence, la réplication inter-région est activé en tant que capacité de récupération d’urgence pour les données OneLake. La plateforme Fabric s’aligne sur les régions Azure pour approvisionner les paires géoredondantes. Toutefois, certaines régions ne disposent pas de paires de régions Azure ou que la paire de régions ne prend pas en charge Fabric. Pour ces régions, la réplication de données n’est pas disponible. Pour obtenir plus d’informations, voir Régions avec zone de disponibilité et aucune paire de régions et Disponibilité des régions Fabric.

Remarque

Même si Fabric propose une solution de réplication de données dans OneLake pour prendre en charge la récupération d’urgence, il n’existe aucune limitation notable. Par exemple, les données des bases de données et des ensembles de requêtes KQL sont stockées en externe dans OneLake, ce qui signifie qu’une approche particulière de récupération d’urgence est nécessaire. Consultez le reste de ce document pour obtenir des détails sur l’approche de récupération d’urgence pour chaque élément Fabric.

Facturation

La fonctionnalité de récupération d’urgence dans Fabric active la géoréplication de vos données pour une efficacité et une sécurité améliorées. Cette fonctionnalité consomme des transactions et plus de stockage qui sont facturés en tant que stockage de BCDR et opérations de BCDR respectivement. Vous pouvez monitorer et gérer ces coûts dans l’application Métriques de capacité Microsoft Fabric lorsqu’ils s’affichent en tant qu’éléments de ligne distincts.

Pour une répartition complète de tous les coûts de récupération d’urgence associés pour vous permettre de planifier et de budgétiser en conséquence, consultez Consommation de calcul et de stockage OneLake.

Configurer une récupération d'urgence

Bien que Fabric fournisse des fonctionnalités de récupération d’urgence pour prendre en charge la résilience des données, vous devez suivre certaines étapes manuelles pour restaurer le service pendant des interruptions. Ce section détaille les mesures que vous devez prendre pour vous préparer aux interruptions éventuelles.

Phase 1 : se préparer

  • Activer les paramètres de la capacité de récupération d’urgence : examinez et définissez régulièrement les paramètres de la capacité de récupération d’urgence pour veiller à ce qu’ils répondent à vos besoins en matière de protection et de performances.

  • Créer des sauvegardes de données : copiez les données stockées critiques en dehors de OneLake dans une autre région d’une manière qui s’aligne sur votre plan de récupération d’urgence.

Phase 2 : basculement d’urgence

Lorsqu’un sinistre majeur rend la région primaire irrécupérable, Microsoft Fabric lance un basculement régional. L’accès au portail Fabric n’est pas disponible tant que le basculement n’est pas terminé et qu’une notification est publiée sur la page de support Microsoft Fabric.

Le temps nécessaire à l’achèvement d’un basculement peut varier, bien qu’il prenne généralement moins d’une heure. Une fois le basculement terminé, voici ce à quoi vous pouvez vous attendre :

  • Portail Fabric : vous pouvez accéder au portail et lire des opérations, par exemple, la navigation dans des espaces de travail et des éléments continue de fonctionner. Toutes les opérations en écriture, telles que la création ou la modification d’un espace de travail, sont interrompues.

  • Power BI : vous pouvez effectuer des opérations en lecture, comme l’affichage de tableaux de bord et de rapports. Les actualisations, opérations de publication de rapports, modifications de rapports et de tableaux de bord et d’autres opérations nécessitant la modification de métadonnées ne sont pas prises en charge.

  • Lakehouse/Warehouse : vous ne pouvez pas ouvrir ces éléments, mais les fichiers sont accessibles via des outils ou des API OneLake.

  • Définition de tâche Spark : vous ne pouvez pas ouvrir des définitions de tâche Spark, mais les fichiers de code sont accessibles via des outils ou des API OneLake. Toute métadonnée ou configuration est enregistrée après un basculement.

  • Notebook : vous ne pouvez ouvrir aucun notebook et le contenu de code n’est enregistré qu’après le sinistre.

  • Expérience/Modèle ML : vous ne pouvez ouvrir aucun modèle ou expérience ML. Le contenu de code et les métadonnées telles que l’exécution de métriques et de configurations ne sont enregistrés qu’après le sinistre.

  • Dataflow Gen2/Pipeline/Eventstream : vous ne pouvez pas ouvrir ces éléments, mais vous pouvez utiliser des destinations de récupération d’urgence prises en charge (lakehouses ou entrepôts) pour protéger des données.

  • Ensemble de requêtes/base de données KQL : vous ne pouvez pas accéder aux ensembles de requêtes ou aux bases de données KQL après un basculement. D’autres étapes de conditions préalables sont nécessaires pour protéger des données dans des ensembles de requêtes ou des bases de données KQL.

Dans un scénario de catastrophe, le portail Fabric et Power BI sont en mode lecture seule, et d'autres éléments Fabric sont indisponibles, vous pouvez accéder à leurs données stockées dans OneLake à l'aide d'API ou d'outils tiers. Le portail et Power BI conservent la possibilité d’effectuer des opérations en lecture-écriture sur ces données. Cette capacité permet d’accéder et de modifier des données critiques et d’atténuer les interruptions potentielles de vos opérations d’entreprise.

Les données OneLake restent accessibles via plusieurs canaux :

Phase 3 : plan de récupération

Même si Fabric veille à ce que les données restent accessibles après un sinistre, vous pouvez également agir pour restaurer complètement leurs services dans l’état dans lequel ils se trouvaient avant l’incident. Cette section fournit un guide détaillé pour vous aider tout au long du processus de récupération.

Étapes de récupération

  1. Créez une capacité Fabric dans n’importe quelle région après un sinistre. Compte tenu de la forte demande pendant de tels événements, nous vous recommandons de sélectionner une région en dehors de votre géoréplication primaire pour augmenter la probabilité de disponibilité du service de calcul. Pour obtenir plus d’informations sur la création d’une capacité, voir Acheter un abonnement Microsoft Fabric.

  2. Créez des espaces de travail dans la capacité nouvellement créée. Le cas échéant, utilisez les mêmes noms que les anciens espaces de travail.

  3. Créez des éléments ayant le même nom que ceux que vous souhaitez récupérer. Cette étape est importante si vous utilisez le script personnalisé pour récupérer des lacs de données et des entrepôts.

  4. Restaurez les éléments. Pour chaque élément, suivez la section pertinente dans Conseils sur la récupération d’urgence spécifique à l’expérience afin de le restaurer.

Étapes suivantes