Base Fabric Data Platform: Servicebeschreibung¶
Diese Seite beschreibt, was die Base Fabric Data Platform bietet, wie Änderungen laufen und wo die Grenzen liegen. Die anderen Seiten gehen ins Detail: Anfragen und Änderungen, Zugriff und Rollen, Konnektivität, Monitoring und Kostenoptimierung.
Optionales Angebot, pro Plattform festgelegt
Der Service wird vom Plattform-Team im Rahmen einer Vereinbarung geliefert (Betriebsmodelle). Support-Zeiten, Reaktionszeiten, SLA-Ziele, Kontakte und Gebühren sind Teil dieser Vereinbarung und stehen nicht in dieser Dokumentation. Wo diese Seite einen Default nennt, ist das der übliche Wert der Lösung. Deine Plattform kann abweichen.
Kurz gesagt¶
Data-Teams bekommen eine produktionsreife, vollständig verwaltete Microsoft-Fabric-Umgebung, ohne Infrastruktur-Know-how zu brauchen. Das Plattform-Team pflegt die Plattform als Infrastructure as Code mit Terraform und deployt sie über CI/CD- pipelines. Jede Umgebung hat eigene, isolierte Ressourcen. Jede Konnektivität läuft über das private Netzwerk der Plattform: Daten werden nicht über das öffentliche Internet transportiert. Ausnahmen sind ausdrücklich benannt (siehe Netzwerk und Sicherheit) und werden vom Service Delivery Manager und vom Kunden genehmigt.
| Wert | Was er bedeutet |
|---|---|
| Produktiv ab Tag 1 | Vorkonfigurierte workspaces mit capacity, OneLake, Lakehouses und Warehouses sowie automatisierte Bereitstellung |
| Monitoring und Alerting | Verfügbarkeit und Performance der Plattform-Komponenten werden überwacht, Abweichungen werden gemeldet |
| Governance und Sicherheit | Entra-ID-Gruppen mit rollenbasiertem Zugriff, private endpoints, Netzwerkisolation und verschlüsselter Speicher |
| Time to value | Gemeinsame Infrastruktur und Standardkonfigurationen lassen neue Umgebungen und workspaces schnell und einheitlich deployen |
Was angeboten wird¶
Die Plattform hat vier Gruppen von Komponenten. Wie sie zusammenpassen, steht unter Architektur.
Plattform-Services¶
| Komponente | Beschreibung |
|---|---|
| Fabric capacity | Die Rechen- und Abrechnungseinheit aller Fabric workspaces. Capacities werden in einem gemeinsamen Deployment erstellt, damit mehrere Umgebungen eine wiederverwenden können, was die Kosten senkt. Das SKU ist über die Fabric F-Serie konfigurierbar und änderbar. |
| VNet data gateway | Ein Gateway, das Fabric ausgehende Konnektivität zu Datenquellen im spoke-Netzwerk und, über ExpressRoute oder VPN, zu On-Premises-Systemen gibt. Es aktiviert sich bei der ersten Nutzung und schläft nach einer Zeit der Inaktivität ein, um Kosten zu sparen. |
Workspace-Services¶
| Komponente | Beschreibung |
|---|---|
| Fabric workspace | Der Container für alle Datenobjekte. Der Zugriff wird mit Entra-ID-Gruppen für die Rollen Admin (optional), Contributor, Member und Viewer gesteuert. Jeder workspace hat eine system-assigned managed identity und lässt sich mit einem Git-Repository verknüpfen. |
| OneLake | Der Standard-Data-Lake-Speicher jedes workspace. |
| Lakehouses | Speicher für analytische Workloads in offenen Formaten (Delta). Schema-Unterstützung lässt sich pro Lakehouse aktivieren. Mehrere pro workspace. |
| Warehouses | Relationaler Speicher für SQL-basierte Analysen. Die Collation ist konfigurierbar. Mehrere pro workspace. |
Konnektivität¶
| Verbindungstyp | Beschreibung |
|---|---|
| ADLS | Zu Containern des Storage Accounts der Umgebung, über das VNet data gateway, mit einem Service Principal, dessen Zugangsdaten aus dem Key Vault kommen |
| SQL | Zu SQL-Server-Datenbanken, über das Gateway, mit einem Service Principal oder mit Basic-Zugangsdaten aus dem Key Vault |
| Oracle Cloud Storage | Zu Oracle Cloud Storage, über das Gateway, mit Basic-Zugangsdaten aus dem Key Vault |
| Workspace zu workspace | Managed private endpoints zwischen workspaces, sodass Lakehouses und Warehouses eines anderen workspace genutzt werden können |
| Managed private endpoints | Direkte private Verbindungen von einem workspace zu bestimmten Azure-Ressourcen über Private Link |
Details und Anfragefelder: Konnektivität.
Storage¶
| Komponente | Beschreibung |
|---|---|
| Storage Account (Data Lake) | Einer pro Umgebung. Premium Block Blob Storage mit hierarchischem Namespace, zonenredundant, verschlüsselt mit einem kundenverwalteten Schlüssel plus Infrastrukturverschlüsselung, erreichbar über private endpoints für blob und dfs. Für die konfigurierten ADLS-Verbindungen werden Container erstellt. |
| Key Vault | Enthält den Verschlüsselungsschlüssel des Storage Accounts und die Zugangsdaten, auf die Verbindungen verweisen. Es ist der Key Vault des spokes. |
Optionale Bausteine¶
| Komponente | Beschreibung | Seite |
|---|---|---|
| Capacity auto-pause | Pausiert capacities nach einem täglichen Zeitplan, um Kosten zu sparen, Resume ist standardmäßig manuell | Kostenoptimierung |
| Observability (Managed Grafana) | Dashboards und Alerts auf pipeline-Fehler aus Log Analytics | Monitoring |
| Governance (Microsoft Purview) | Katalog, Klassifizierung und Lineage für die Fabric workspaces | Governance |
Das sind getrennte Deployments. Frag das Plattform-Team, ob sie Teil deiner Vereinbarung sind.
Netzwerk und Sicherheit¶
Die Plattform setzt auf Defence in Depth: Netzwerkisolation, Verschlüsselung und Zugriffsverwaltung zusammen.
| Aspekt | Beschreibung |
|---|---|
| Inbound | Jeder workspace bekommt einen Private Link Service für Fabric und einen private endpoint im Subnet für private endpoints des spokes |
| Outbound | Standardmäßig blockiert (outbound Deny). Nur über das vorgesehene VNet data gateway oder managed private endpoints erlaubt. Wie das pro workspace gesetzt wird und welche Grenzen es hat, steht unter Workspace network policy. |
| Gateway-Einschränkung | Pro workspace ist die Gateway-Nutzung standardmäßig verweigert, und nur das Gateway der Umgebung ist erlaubt |
| Git-Ausnahme | Ein workspace mit Git-Verknüpfung bekommt eine benannte Outbound-Ausnahme für Git-Traffic. Workspaces ohne Git nicht. |
| DNS | Namen von private endpoints werden über die privaten DNS zones der Plattform aufgelöst |
| Entwicklerzugriff | Über VPN oder ExpressRoute. Es gibt keinen Weg über das öffentliche Internet für Entwickler. |
| Datenschutz | Beschreibung |
|---|---|
| Kundenverwalteter Schlüssel | RSA-4096-Bit-Schlüssel im Key Vault mit automatischer Rotation, genutzt für den Storage Account |
| Infrastrukturverschlüsselung | Zusätzlich zum kundenverwalteten Schlüssel aktiviert (doppelte Verschlüsselung im Ruhezustand) |
| Soft Delete | Blobs 90 Tage, Container 95 Tage |
| Replikation | Zonenredundant (ZRS) |
| Authentifizierung | Shared Access Keys sind auf dem Storage Account deaktiviert. Der Zugriff läuft nur über Entra ID. |
| Zugangsdaten | Zugangsdaten für Verbindungen liegen im Key Vault, nie im Code oder in Konfigurationsdateien |
Abgleich mit Frameworks¶
Die technische Konfiguration orientiert sich am CIS Microsoft Azure Foundations Benchmark 2.0, an ISO 27001 und am Microsoft Cloud Security Benchmark. Das betrifft nur die technische Konfiguration. Eine formale Zertifizierung ist ein organisatorischer Prozess und bleibt beim Kunden.
Wie Änderungen laufen¶
Das Code-Repository ist die Single Source of Truth. Änderungen laufen als pull request auf die Terraform-Konfiguration und werden von der pipeline deployt. Manuelle Änderungen im Azure-Portal oder im Fabric-Portal an Ressourcen unter Terraform- Verwaltung sind nicht erlaubt: Der nächste pipeline-Lauf macht sie rückgängig. Siehe Anfragen und Änderungen.
Standardänderungen¶
Standardänderungen sind vordefiniert und über die Terraform-Konfiguration automatisiert. Jede folgt dem kontrollierten Änderungs- prozess, und das Plattform-Team hält den pull request und die Wiederherstellungszeit (MTTR) im SLA-Reporting fest.
| Standardänderung |
|---|
| Einen neuen Fabric workspace erstellen |
| Rollengruppen eines workspace ändern (Admins, Contributors, Members, Viewers) |
| Ein Lakehouse erstellen oder löschen |
| Ein Warehouse erstellen oder löschen |
| Eine ADLS-Verbindung hinzufügen, ändern oder löschen |
| Eine SQL-Verbindung hinzufügen, ändern oder löschen |
| Eine Oracle-Cloud-Storage-Verbindung hinzufügen, ändern oder löschen |
| Eine Verbindung von workspace zu workspace konfigurieren |
| Einen managed private endpoint hinzufügen oder entfernen |
| Die Git-Verknüpfung konfigurieren oder ändern |
| Die Fabric capacity skalieren oder das SKU ändern |
| Über eine ADLS-Verbindung einen Storage-Container hinzufügen |
SLA-Metriken¶
Die Verfügbarkeit der Plattform wird mit den Metriken unten gemessen. Die Ziele werden pro Kunde vereinbart und im übergreifenden SLA festgehalten, nicht in dieser Dokumentation.
| Metrik | Misst |
|---|---|
| Verfügbarkeit der Fabric capacity | Die bereitgestellte capacity kann Workloads ausführen |
| Verfügbarkeit des VNet data gateway | Netzwerkkonnektivität zwischen Fabric und Datenquellen |
| Verfügbarkeit des Storage Accounts | Die Storage Accounts, die als Data Landing genutzt werden |
| Verfügbarkeit der Verbindungen | Die konfigurierten Verbindungen (ADLS, SQL, Oracle Cloud Storage, workspace zu workspace) |
Recovery Objectives¶
| Metrik | Ziel | Grundlage |
|---|---|---|
| RPO | höchstens 1 Stunde | Zonenredundanter Speicher repliziert synchron über drei Availability Zones. Die Plattformkonfiguration liegt als Terraform in Git. Die Stunde deckt Randfälle ab, etwa laufende pipeline-Läufe oder nicht committete Metadaten zum Zeitpunkt eines Incidents. |
| RTO | höchstens 4 Stunden | Die Infrastruktur lässt sich aus Terraform in etwa 30 bis 90 Minuten neu deployen. Der Rest deckt Validierung, den Wiederaufbau von Verbindungen, die Aktivierung des Gateways und die Prüfung der Ende-zu-Ende-Konnektivität ab. Bei einem Ausfall einer Availability Zone, den Azure transparent behandelt, liegt die Wiederherstellung typischerweise deutlich unter 1 Stunde. |
Geltungsbereich der Objectives
RPO und RTO gelten für die Plattform-Infrastruktur und die Daten im Storage Account. Die Wiederherstellung von Daten-Workloads (pipelines, Notebooks, Semantic Models, Data Products) liegt in der Verantwortung des Workload-Teams und braucht eine eigene Recovery-Planung auf Workload-Ebene.
Incident-Prozess¶
- Erkennung: Das Plattform-Monitoring meldet eine Abweichung, oder du meldest sie.
- Triage: Das Plattform-Team bewertet Auswirkung und Dringlichkeit.
- Behebung: Das Plattform-Team arbeitet an der Wiederherstellung und hält dich auf dem Laufenden.
- Abschluss: Du erfährst die Ursache und die getroffenen Maßnahmen.
Severities, Reaktionszeiten und support-Zeiten stammen aus deiner Vereinbarung. Im Eigenbetrieb legt sie dein eigenes Plattform-Team fest (Incident Management).
Grenzen¶
| Plattform-Team | Workload-Team |
|---|---|
| Capacity, Gateway, Storage Account, Schlüsselrotation, private endpoints, Rollengruppen und Verbindungen als Code | OneLake-Inhalt, die Daten in Lakehouses und Warehouses |
| Plattform-Monitoring (capacity, Gateway, Storage, Verbindungen) | Workload-Monitoring: Query-Performance, Datenqualität und Aktualität |
| Retry fehlgeschlagener Baseline-pipelines | Das Datenproblem lösen, wenn ein Retry nicht hilft |
| Terraform-pipelines, modules und Code | Git-Repositories des Workloads |
| Technischer Abgleich mit den Frameworks | Formale Compliance und Zertifizierung |
Die vollständige Aufteilung steht unter Verantwortlichkeiten.