Freigeben über

Zuverlässigkeit in Microsoft Fabric

In diesem Artikel werden die Zuverlässigkeitsunterstützung in Microsoft Fabric und sowohl die regionale Resilienz mit Verfügbarkeitszonen als auch die regionsübergreifende Wiederherstellung und Geschäftskontinuität beschrieben. Eine ausführlichere Übersicht über die Zuverlässigkeit in Azure finden Sie unter Azure-Zuverlässigkeit.

Unterstützung für Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, kann für die Dienste ein Failover zu einer der verbleibenden Zonen erfolgen.

Fabric bemüht sich in wirtschaftlich angemessener Weise um die Unterstützung zonenredundanter Verfügbarkeitszonen, in denen Ressourcen automatisch über Zonen repliziert werden, ohne dass sie manuell eingerichtet oder konfiguriert werden müssen.

Voraussetzungen

  • Fabric bietet derzeit teilweise Unterstützung für Verfügbarkeitszonen in einer begrenzten Anzahl von Regionen. Diese teilweise Unterstützung der Verfügbarkeitszonen umfasst Erfahrungen (und/oder bestimmte Funktionalitäten innerhalb einer Erfahrung).
  • Erfahrungen wie Ereignisstreams unterstützen keine Verfügbarkeitszonen.
  • Data Engineering unterstützt Verfügbarkeitszonen, wenn Sie OneLake verwenden. Wenn Sie andere Datenquellen wie ADLS Gen2 verwenden, müssen Sie sicherstellen, dass zonenredundanter Speicher (Zone-redundant storage, ZRS) aktiviert ist.
  • Die Zonenverfügbarkeit steht möglicherweise nicht für Erfahrungen von Fabric und/oder Features/Funktionen zur Verfügung, die sich in der Vorschau befinden.
  • Lokale Gateways und große Semantikmodelle in Power BI unterstützen keine Verfügbarkeitszonen.
  • Data Factory (Pipelines) unterstützt Verfügbarkeitszonen in der Region „Europa, Westen“, aber neue oder laufende Ausführungen von Pipelines können bei einem Zonenausfall fehlschlagen.

Unterstützte Regionen

Fabric unternimmt wirtschaftlich vertretbare Schritte, um in verschiedenen Regionen wie folgt Unterstützung für Verfügbarkeitszonen anzubieten:

Nord-, Mittel- und Südamerika Power BI Datamarts Data Warehouses Echtzeitanalysen Data Factory (Pipelines) Datentechnik SQL-Datenbank Aktivator
Brasilien, Süden
Kanada, Mitte
USA, Mitte
Ost-USA
USA, Osten 2
USA, Süden-Mitte
USA, Westen 2
USA, Westen 3
Europa Power BI Datamarts Data Warehouses Echtzeitanalysen Data Factory (Pipelines) Datentechnik SQL-Datenbank Aktivator
Frankreich, Mitte
Deutschland, Westen-Mitte
Italien, Norden
Europa, Norden
Norwegen, Osten
Polen, Mitte
Vereinigtes Königreich, Süden
Europa, Westen
Schweden, Mitte
Naher Osten Power BI Datamarts Data Warehouses Echtzeitanalysen Data Factory (Pipelines) Datentechnik SQL-Datenbank Aktivator
Katar, Mitte
Israel, Mitte
Afrika Power BI Datamarts Data Warehouses Echtzeitanalysen Data Factory (Pipelines) Datentechnik SQL-Datenbank Aktivator
Südafrika, Norden
Asien-Pazifik Power BI Datamarts Data Warehouses Echtzeitanalysen Data Factory (Pipelines) Datentechnik SQL-Datenbank Aktivator
Australien, Osten
Japan, Osten
Asien, Südosten

Zonenausfall

Während eines zonenweiten Ausfalls ist während der Zonenwiederherstellung keine Aktion erforderlich. Fabric-Funktionen in Regionen, die in unterstützten Regionen aufgeführt sind, sind selbstheilend und werden automatisch neu ausbalanciert, um die Vorteile der fehlerfreien Zone zu nutzen. Das Ausführen von Spark-Aufträgen schlägt möglicherweise fehl, wenn sich der Masterknoten in der ausgefallenen Zone befindet. In diesem Fall müssen die Aufträge erneut übermittelt werden.

Wichtig

Obwohl Microsoft versucht, eine einheitliche und konsistente Unterstützung von Verfügbarkeitszonen zu bieten, kann es in einigen Fällen bei einem Ausfall der Verfügbarkeitszone zu einer höheren Latenz für Fabric-Kapazitäten kommen, die sich in Azure-Regionen mit höheren Schwankungen der Kundennachfrage befinden.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Notfallwiederherstellung (DR) bezieht sich auf Methoden, die Organisationen zum Wiederherstellen von Ereignissen mit hohem Einfluss verwenden, z. B. Naturkatastrophen oder fehlerhafte Bereitstellungen, die zu Ausfallzeiten und Datenverlusten führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallwiederherstellungsplan und ein Anwendungsdesign, das die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, finden Sie Unter "Empfehlungen für das Entwerfen einer Notfallwiederherstellungsstrategie".

Für DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In diesem Modell stellt Microsoft sicher, dass die Basisinfrastruktur und Plattformdienste verfügbar sind. Viele Azure-Dienste replizieren jedoch nicht automatisch Daten oder greifen von einer fehlgeschlagenen Region zurück, um sie in eine andere aktivierte Region zu replizieren. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die im Rahmen von Azure-PaaS-Angeboten (Plattform-as-a-Service) ausgeführt werden, bieten Features und Anleitungen zur Unterstützung der Notfallwiederherstellung. Sie können dienstspezifische Features verwenden, um die schnelle Wiederherstellung zu unterstützen, um Ihren DR-Plan zu entwickeln.

In diesem Abschnitt wird ein Notfallwiederherstellungsplan für Fabric beschrieben, der Ihrer Organisation dabei hilft, ihre Daten sicher und zugänglich zu halten, wenn ein ungeplanter regionaler Notfall auftritt. Der Plan behandelt die folgenden Themen:

  • Regionsübergreifende Replikation: Fabric bietet eine regionsübergreifende Replikation für Daten, die in OneLake gespeichert sind. Sie können dieses Feature basierend auf Ihren Anforderungen aktivieren oder deaktivieren.

  • Datenzugriff nach einem Notfall: In einem regionalen Notfallszenario garantiert Fabric den Datenzugriff mit bestimmten Einschränkungen. Während die Erstellung oder Änderung neuer Elemente nach dem Failover eingeschränkt ist, bleibt der primäre Fokus darauf, sicherzustellen, dass vorhandene Daten weiterhin zugänglich und intakt bleiben.

  • Leitfaden für die Wiederherstellung: Fabric bietet eine strukturierte Reihe von Leitfäden, die Sie durch den Wiederherstellungsvorgang führen. Die strukturierte Anleitung erleichtert es Ihnen, wieder zu regulären Vorgängen zu wechseln.

Power BI, jetzt Teil von Fabric, verfügt über ein solides Notfallwiederherstellungssystem und bietet die folgenden Features:

  • BCDR als Standard: Power BI enthält automatisch Notfallwiederherstellungsfunktionen in seinem Standardangebot. Sie müssen dieses Feature nicht separat abonnieren oder aktivieren.

  • Regionsübergreifende Replikation: Power BI verwendet die georedundante Azure Storage-Replikation und die georedundante Azure SQL-Replikation, um sicherzustellen, dass Sicherungsinstanzen in anderen Regionen vorhanden sind und verwendet werden können. Das bedeutet, dass Daten in verschiedenen Regionen dupliziert werden, wodurch ihre Verfügbarkeit verbessert wird und die mit regionalen Ausfällen verbundenen Risiken verringert werden.

  • Fortgesetzte Dienste und Zugriffe nach dem Notfall: Auch bei störenden Ereignissen bleiben Power BI-Elemente im schreibgeschützten Modus zugänglich. Zu den Elementen gehören Semantikmodelle, Berichte und Dashboards, um sicherzustellen, dass Unternehmen ihre Analyse- und Entscheidungsprozesse ohne erhebliche Hindernisse fortsetzen können.

Weitere Informationen finden Sie in den häufig gestellten Fragen zu hoher Verfügbarkeit, Failover und Notfallwiederherstellung von Power BI.

Wichtig

Für Kunden, deren Heimregionen keine Azure-Paarregion haben und die von einer Katastrophe betroffen sind, kann die Fähigkeit, Fabric-Kapazitäten zu nutzen, eingeschränkt sein, auch wenn die Daten innerhalb dieser Kapazitäten repliziert sind. Diese Einschränkung ist an die Infrastruktur der Heimregion gebunden, die für den Betrieb der Kapazitäten unerlässlich ist.

Heimregion und Kapazitätsfunktionen

Für eine effektive Notfallwiederherstellungsplanung ist es wichtig, dass Sie die Beziehung zwischen Ihrer Heimregion und Ihren Kapazitätsstandorten verstehen. Das Verständnis von Heimregionen und Kapazitätsstandorten hilft Ihnen dabei, die strategische Auswahl von Kapazitätsregionen sowie die entsprechenden Replikations- und Wiederherstellungsprozesse zu treffen.

Die Heimregion für den Mandanten und die Datenspeicherung Ihrer Organisation wird auf den Rechnungsadressenstandort des ersten Benutzers festgelegt, der sich anmeldet. Weitere Informationen zum Mandantensetup erhalten Sie unter Power BI-Implementierungsplanung: Mandantensetup. Wenn Sie neue Kapazitäten erstellen, wird Ihre Datenspeicherung standardmäßig auf die Heimregion festgelegt. Wenn Sie Ihre Datenspeicherregion in eine andere Region ändern möchten, müssen Sie Multi-Geo aktivieren, ein Fabric Premium-Feature.

Wichtig

Wenn Sie eine andere Region für Ihre Kapazität auswählen, werden nicht alle Ihre Daten in diese Region verschoben. Einige Datenelemente bleiben weiterhin in der Heimregion gespeichert. Informationen dazu, welche Daten in der Heimregion verbleiben und welche Daten in der Multi-Geo-aktivierten Region gespeichert werden, finden Sie unter Konfigurieren der Multi-Geo-Unterstützung für Fabric Premium.

Bei einer Heimregion, die keine gekoppelte Region hat, können Kapazitäten in einer Multi-Geo-aktivierten Region nicht betriebsbereit sein, wenn die Heimregion eine Katastrophe erleidet, da die Kerndienstfunktionalität an die Heimregion gekoppelt ist.

Wenn Sie eine Multi-Geo-aktivierte Region innerhalb der EU auswählen, wird sichergestellt, dass Ihre Daten innerhalb der EU-Datengrenze gespeichert werden.

Informationen zum Identifizieren Ihrer Heimregion finden Sie unter Suchen Ihrer Fabric-Heimregion.

Kapazitätseinstellung für die Notfallwiederherstellung

Auf der Fabric-Seite „Kapazitätseinstellungen“ ist die Option „Notfallwiederherstellung“ vorhanden. Sie ist verfügbar, wo regionale Kopplungen in Azure der Dienstpräsenz von Fabric entsprechen. Einstellungen für diese Option:

  • Rollenzugriff: Nur Benutzende mit der Rolle Kapazitätsadministrationsfachkraft oder höher können diese Option verwenden.

  • Granularität: Die Granularität der Option ist die Kapazitätsebene. Sie ist für Premium- und Fabric-Kapazitäten verfügbar.

  • Datenbereich: Der Umschalter für die Notfallwiederherstellung gilt speziell für OneLake-Daten, die Lakehouse- und Warehouse-Daten umfassen. Der Umschalter beeinflusst keine Ihrer Daten, die außerhalb von OneLake gespeichert sind.

  • BCDR-Kontinuität für Power BI: Während die Notfallwiederherstellung für OneLake-Daten ein- und ausgeschaltet werden kann, wird BCDR für Power BI immer unterstützt, unabhängig davon, ob die Option ein- oder ausgeschaltet ist.

  • Häufigkeit: Nachdem Sie die Kapazitätseinstellung für die Notfallwiederherstellung geändert haben, müssen Sie 30 Tage warten, bevor Sie sie erneut ändern können. Der Wartezeitraum wird festgelegt, um Stabilität aufrechtzuerhalten und ständiges Wechseln zu verhindern.

Screenshot: Einstellung für die Notfallwiederherstellung des Mandanten.

Hinweis

Nach dem Aktivieren der Kapazitätseinstellung für die Notfallwiederherstellung oder dem Erstellen neuer Arbeitsbereiche innerhalb der Kapazität kann die Datenreplikation einige Zeit in Anspruch nehmen. Sie können überprüfen, ob die Replikation begonnen hat, indem Sie überprüfen, ob Ihr Speicher für einen bestimmten Arbeitsbereich in der Microsoft Fabric-Kapazitätsmetriken-App als "OneLake BCDR Storage" in Rechnung gestellt wird.

Datenreplikation

Wenn Sie die Kapazitätseinstellung für die Notfallwiederherstellung aktivieren, wird die regionsübergreifende Replikation als Notfallwiederherstellungsfunktion für OneLake-Daten aktiviert. Die Fabric-Plattform entspricht Azure-Regionen, um die Georedundanzkopplungen bereitzustellen. Es ist jedoch für einige Regionen keine gekoppelte Azure-Region vorhanden, oder die gekoppelte Region unterstützt Fabric nicht. Für diese Regionen ist die Datenreplikation nicht verfügbar. Weitere Informationen finden Sie unter Regionen mit Verfügbarkeitszonen und ohne Regionspaar und Regionale Verfügbarkeit von Fabric.

Hinweis

Obwohl Fabric eine Datenreplikationslösung in OneLake zur Unterstützung der Notfallwiederherstellung bietet, gibt es beträchtliche Einschränkungen zu beachten. Beispielsweise werden die Daten von KQL-Datenbanken und -Abfragesets außerhalb von OneLake gespeichert, was bedeutet, dass ein separater Notfallwiederherstellungsansatz erforderlich ist. Weitere Informationen zum Notfallwiederherstellungsansatz für jedes Fabric-Element finden Sie im restlichen Dokument.

Abrechnung

Das Notfallwiederherstellungsfeature in Fabric ermöglicht die Georeplikation Ihrer Daten für erhöhte Sicherheit und Zuverlässigkeit. Dieses Feature nutzt zusätzlichen Speicher und zusätzliche Transaktionen, die als „BCDR-Speicher“ bzw. „BCDR-Vorgänge“ in Rechnung gestellt werden. Sie können diese Kosten in der Microsoft Fabric-App Kapazitätsmetriken überwachen und verwalten, in der sie als separate Positionen erscheinen.

Eine vollständige Aufschlüsselung aller verbundenen Kosten für die Notfallwiederherstellung, die Ihnen bei der Planung und dem Budget hilft, finden Sie unter OneLake-Nutzung von Compute- und Speicherressourcen.

Einrichten der Notfallwiederherstellung

Obwohl Fabric Notfallwiederherstellungsfeatures zur Unterstützung der Datenresilienz bereitstellt, müssen Sie bestimmte Schritte manuell ausführen, um den Dienst während Unterbrechungen wiederherzustellen. In diesem Abschnitt werden die Maßnahmen beschrieben, die Sie ergreifen sollten, um sich auf potenzielle Unterbrechungen vorzubereiten.

Phase 1: Vorbereitung

  • Kapazitätseinstellungen für Notfallwiederherstellung aktivieren: Überprüfen und bestimmen Sie regelmäßig die Kapazitätseinstellungen für die Notfallwiederherstellung, um sicherzugehen, dass sie Ihren Schutz- und Leistungsanforderungen entsprechen.

  • Datensicherungen erstellen: Kopieren Sie kritische Daten, die außerhalb von OneLake gespeichert sind, in eine andere Region und auf eine Weise, die Ihrem Notfallwiederherstellungsplan entspricht.

Phase 2: Notfallfailover

Wenn eine große Katastrophe dazu führt, dass die primäre Region nicht wiederherstellbar ist, initiiert Microsoft Fabric ein regionales Failover. Der Zugriff auf das Fabric-Portal ist nicht verfügbar, bis das Failover abgeschlossen ist und auf der Microsoft Fabric-Supportseite eine Benachrichtigung veröffentlicht wird.

Die für ein Failover benötigte Zeit kann variieren, in der Regel dauert es jedoch weniger als eine Stunde. Sobald das Failover abgeschlossen ist, können Sie Folgendes erwarten:

  • Fabric-Portal: Sie können auf das Portal zugreifen, und Lesevorgänge, wie das Durchsuchen vorhandener Arbeitsbereiche, Aufgabenflüsse in Arbeitsbereichen und Elemente, sind weiterhin funktionsfähig. Alle Schreibvorgänge, z. B. das Erstellen oder Ändern eines Arbeitsbereichs, werden angehalten.

  • Power BI: Sie können Lesevorgänge ausführen, z. B. das Anzeigen von Dashboards und Berichten. Aktualisierungen, Berichtsveröffentlichungsvorgänge, Dashboard- und Berichtsänderungen sowie andere Vorgänge, die Änderungen an Metadaten erfordern, werden nicht unterstützt.

  • Lakehouse/Warehouse: Sie können diese Elemente nicht öffnen, aber Dateien können über OneLake-APIs oder -Tools aufgerufen werden.

  • Spark-Auftragsdefinitionen: Sie können Spark-Auftragsdefinitionen nicht öffnen, Codedateien können jedoch über OneLake-APIs oder -Tools aufgerufen werden. Alle Metadaten oder Konfigurationen werden nach dem Failover gespeichert.

  • Notebook: Sie können keine Notebooks öffnen, und Codeinhalte werden nach dem Notfall nicht gespeichert.

  • ML-Modelle/-Experiment: Sie können keine ML-Modelle oder -Experimente öffnen. Codeinhalte und Metadaten wie Ausführungsmetriken und Konfigurationen werden nach dem Notfall nicht gespeichert.

  • Dataflow Gen2/Pipeline/Ereignisstream: Sie können diese Elemente nicht öffnen, aber Sie können unterstützte Notfallwiederherstellungsziele (Lakehouses oder Warehouses) verwenden, um Daten zu schützen.

  • KQL-Datenbanken/-Abfragesets: Sie können nach dem Failover nicht auf KQL-Datenbanken und -Abfragesets zugreifen. Zusätzliche Schritte sind im Voraus erforderlich, um die Daten in KQL-Datenbanken und -Abfragesets zu schützen.

In einem Notfallszenario befinden sich das Fabric-Portal und Power BI im schreibgeschützten Modus, und andere Fabric-Elemente sind nicht verfügbar. Sie können mithilfe von APIs oder Drittanbietertools auf die in OneLake gespeicherten Daten zugreifen. Sowohl das Portal als auch Power BI behalten sich die Möglichkeit zum Ausführen von Lese-/Schreibvorgängen für diese Daten vor. Diese Fähigkeit stellt sicher, dass wichtige Daten weiterhin zugänglich sind und geändert werden können und potenzielle Unterbrechungen Ihrer Geschäftsvorgänge verringert werden.

OneLake-Daten bleiben über mehrere Kanäle zugänglich:

Der OneLake-Katalog bleibt während des Notfallfailovers im schreibgeschützten Modus verfügbar: * Registerkarte „Erkunden“: Sie können auf die Registerkarte „Erkunden“ zugreifen, um alle Elemente und Arbeitsbereiche anzuzeigen, einschließlich ihrer Metadaten und zugehörigen Details. * Registerkarte "Steuern": Sie können auf die Registerkarte "Steuern" zugreifen, um Einblicke, empfohlene Aktionen und Governancetools anzuzeigen – basierend auf der letzten erfolgreichen Modellaktualisierung vor dem Failover.

Phase 3: Wiederherstellungsplan

Während Fabric sicherstellt, dass Daten nach einem Notfall weiterhin zugänglich sind, können Sie auch eingreifen, um die Dienste vollständig im Zustand vor dem Vorfall wiederherzustellen. Dieser Abschnitt enthält eine schrittweise Anleitung, mit der Sie den Wiederherstellungsvorgang durchlaufen können.

Wiederherstellungsschritte

  1. Erstellen Sie nach einem Notfall eine neue Fabric-Kapazität in einer beliebigen Region. Angesichts der hohen Nachfrage bei solchen Ereignissen wird empfohlen, eine Region außerhalb Ihrer primären Geografie auszuwählen, um die Wahrscheinlichkeit der Verfügbarkeit des Computediensts zu erhöhen. Weitere Informationen zum Erstellen einer Kapazität finden Sie unter Erwerb eines Microsoft Fabric-Abonnements.

  2. Erstellen Sie Arbeitsbereiche in der neu erstellten Kapazität. Verwenden Sie bei Bedarf die gleichen Namen wie für die alten Arbeitsbereiche.

  3. Erstellen Sie Elemente mit denselben Namen wie die wiederherzustellenden Elemente. Dieser Schritt ist wichtig, falls Sie das benutzerdefinierte Skript verwenden, um Lakehouses und Warehouses wiederherzustellen.

  4. Stellen Sie die Elemente wieder her. Befolgen Sie für jedes Element den relevanten Abschnitt im umgebungsspezifischen Leitfaden für die Notfallwiederherstellung, um es wiederherzustellen.

Nächste Schritte