Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article décrit la prise en charge de la fiabilité dans Microsoft Fabric, ainsi que la résilience régionale avec les zones de disponibilité et la récupération inter-région et la continuité des activités. 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, 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'ingénierie des 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é des zones peut être incertaine pour les expériences et/ou les fonctionnalités de Fabric qui sont en aperçu.
- 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 | Entrepôts de données | Analytique en temps réel | Data Factory (pipelines de données) | Ingénierie des données | Base de données SQL | Activateur |
---|---|---|---|---|---|---|---|---|
Brésil Sud | ||||||||
Centre du Canada | ||||||||
Centre des États-Unis | ||||||||
USA Est | ||||||||
Est des États-Unis 2 | ||||||||
États-Unis - partie centrale méridionale | ||||||||
Ouest des États-Unis 2 | ||||||||
USA Ouest 3 | ||||||||
Europe | Power BI | Datamarts | Entrepôts de données | Analytique en temps réel | Data Factory (pipelines de données) | Ingénierie des données | Base de données SQL | Activateur |
France Centre | ||||||||
Allemagne Centre-Ouest | ||||||||
Italie Nord | ||||||||
Europe Nord | ||||||||
Norvège Est | ||||||||
Pologne Centre | ||||||||
Sud du Royaume-Uni | ||||||||
Europe Ouest | ||||||||
Suède Centre | ||||||||
Moyen-Orient | Power BI | Datamarts | Entrepôts de données | Analytique en temps réel | Data Factory (pipelines de données) | Ingénierie des données | Base de données SQL | Activateur |
Banque Centrale du Qatar | ||||||||
Israël Central | ||||||||
Afrique | Power BI | Datamarts | Entrepôts de données | Analytique en temps réel | Data Factory (pipelines de données) | Ingénierie des données | Base de données SQL | Activateur |
Afrique du Sud Nord | ||||||||
Asie-Pacifique | Power BI | Datamarts | Entrepôts de données | Analytique en temps réel | Data Factory (pipelines de données) | Ingénierie des données | Base de données SQL | Activateur |
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 reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes 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 à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.
Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas 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 instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.
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 : l'option de récupération d’urgence traite spécifiquement les données OneLake, qui incluent 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,
Remarque
Après avoir activé le paramètre de capacité de récupération d’urgence ou créé de nouveaux espaces de travail au sein de la capacité, la réplication des données peut prendre un certain temps pour démarrer. Vous pouvez vérifier que la réplication a commencé en vérifiant si votre stockage pour un espace de travail particulier est facturé en tant que « Stockage BCDR OneLake » dans l’application Métriques de capacité Microsoft Fabric.
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 d'une région partenaire Azure ou la région partenaire ne prend pas en charge la solution 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 existe des limitations notables. 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 davantage de stockage et de transactions, lesquels sont facturés respectivement en tant que stockage BCDR et opérations BCDR. 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 les opérations de consultation telles que l'exploration des espaces de travail existants, des flux de tâches dans les espaces de travail et des éléments continuent 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 du code et les métadonnées, notamment les métriques d'exécution et les configurations, ne seront pas sauvegardés 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.
Base de données/ensemble de requêtes KQL : vous ne pourrez pas accéder aux bases de données et ensembles de requêtes KQL après basculement. D'autres étapes prérequises sont nécessaires pour protéger les données dans les bases de données KQL et les ensembles de requêtes.
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 :
API OneLake ADLS Gen2 : voir Connexion à Microsoft OneLake
Exemples d’outils pouvant se connecter aux données OneLake :
Explorateur Stockage Azure : voir Intégrer OneLake à l’Explorateur Stockage Azure
Explorateur de fichiers OneLake : voir Utiliser l’Explorateur de fichiers OneLake pour accéder aux données Fabric
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
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 région principale pour augmenter les chances de disponibilité du service informatique. Pour obtenir plus d’informations sur la création d’une capacité, voir Acheter un abonnement Microsoft Fabric.
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.
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.
Restaurez les éléments. Pour chaque élément, suivez la section pertinente dans le guide de récupération après sinistre spécifique à l'Experience pour restaurer l'élément.