Architektur¶

Diese Seite beschreibt das High-Level-Design der Base Fabric Data Platform: wie die Deployments auf subscriptions aufgeteilt sind, was jede Stufe erstellt und wie Netzwerk, Verschlüsselung und Identität funktionieren. Sie richtet sich an das Plattform-Team und an Workload-Teams, die verstehen wollen, was in ihrem Auftrag läuft.

Referenzdesign, dein Deployment kann abweichen

Das folgende Design stammt aus dem Code der Lösung und dem HLD der Lösung. Namen, SKUs und optionale Teile hängen von deinem Deployment ab.

Überblick¶

flowchart TB
    subgraph shared["Shared subscription (spoke)"]
        cap["Fabric capacities"]
        pause["Logic Apps: pause / resume (optional)"]
        purview["Microsoft Purview (optional)"]
    end
    subgraph env["Environment subscription (spoke), one per environment"]
        gw["VNet data gateway"]
        st["Storage account (data lake, CMK)"]
        pep["Private endpoints"]
        graf["Managed Grafana (optional)"]
    end
    subgraph fabric["Microsoft Fabric tenant"]
        ws["Workspaces: OneLake, Lakehouses, Warehouses, pipelines"]
    end
    kv["Spoke Key Vault: key + connection secrets"]
    law["Spoke Log Analytics"]
    src["Data sources: Azure, on-premises"]

    cap -->|"capacity assigned"| ws
    ws -->|"outbound only via"| gw
    gw --> src
    ws -->|"managed private endpoints"| src
    pep --> ws
    ws --> st
    st --> kv
    pause --> cap
    graf --> law

Subscriptions und Tiers¶

Die Plattform nutzt eine subscription pro Umgebung und eine Shared-subscription. Jede subscription ist ein spoke der Plattform (Spoke canvas) und stellt das virtual network, das Subnetz für private endpoints, das Key Vault, das Storage Account und den Log-Analytics-Workspace bereit, auf denen die Lösung aufbaut.

Tier	Subscription	Terraform-Root	Was er erstellt
Shared	Shared	`infra/deploy/shared`	Ressourcengruppe, eine oder mehrere Fabric capacities, die Custom Role Fabric Capacity Operator, optionale Logic Apps zum Pausieren und Fortsetzen der capacity mit Alerts
Workload	Eine pro Umgebung	`infra/deploy/workload`	Ressourcengruppe, ein VNet data gateway pro capacity key, die Fabric workspaces mit ihren Items und Connections, das Data-Lake-Storage-Account, der Key und die private endpoints
Governance	Shared	`infra/deploy/governance`	Microsoft-Purview-Account (Governance)
Observability	Pro Umgebung	`infra/deploy/observability`	Azure Managed Grafana, Alert-Regeln und optional gestufte Log-Speicherung (Observability)

Jedes Root module hat seinen eigenen Terraform-state. Der Shared-Tier wird zuerst deployt, weil der Workload-Tier die capacities über ihren Namen nachschlägt. Die capacities liegen absichtlich in der Shared-subscription: Eine capacity kann eine oder mehrere Umgebungen bedienen, was den Kostenfußabdruck senkt, und eine eigene capacity pro Umgebung bleibt möglich, weil jeder workspace die capacity nennt, die er nutzt (capacity_key).

Namen und tags¶

Namen folgen dem Azure-Naming-module mit einem Suffix aus <workload>, einem kurzen Umgebungsnamen und einem kurzen Regionsnamen.

Element	Wert
Workload-Name	Höchstens 8 Zeichen
Umgebungen	`development`, `test`, `acceptance`, `production` (`shared` für die Shared- und Governance-Tiers), verkürzt zu `dev`, `tst`, `acc`, `prd`, `shrd`
Regionen	`westeurope`, `northeurope`, `swedencentral`, `uksouth` (verkürzt zu `weu`, `neu`, `sec`, `uks`)
Fabric capacity	`fc` + workload + Umgebung + Region + capacity key
Workspace	`<workload>-<env>-<region>-<workspace key>`
Gateway	`VNet Gateway - <environment> - <capacity key>`
Private Link Service for Fabric	`privateLinkServicesForFabric-<workspace name>`
Tags	`Environment`, `Workload` und `CostCentre`. Das module setzt `CostCentre` auf einen festen Wert, prüfe ihn für deine Plattform (Namen und Tags).

Fabric capacity¶

Eine capacity wird pro Eintrag in fabric_capacities des Shared-Tiers erstellt, mit einer SKU von F2 bis F2048. Die capacity-Administratoren werden aus einer Liste von Principal-IDs gesetzt: den Service Principals der spokes, die workspaces deployen, und optional Benutzern. Fabric erlaubt in dieser Rolle nur Service Principals und Benutzer, keine Gruppen, deshalb muss ein Team, das capacity-Adminrechte braucht, Person für Person hinzugefügt werden.

Capacities lassen sich pausieren, um Kosten zu sparen, siehe Kostenoptimierung und Capacity auto-pause.

Workspaces¶

Jeder workspace wird mit einer System-assigned Managed Identity erstellt und einer capacity zugeordnet. Der Workload-Tier ergänzt pro workspace:

Rollenzuweisungen für bis zu vier Entra-ID-Gruppen (Zugriff und Rollen),
einen private endpoint zum workspace (Private Link Service for Fabric, Sub-Ressource workspace) im Subnetz für private endpoints,
eine Network Communication Policy und eine Gateway-Regel (Network Policy des Workspaces),
optionale Lakehouses (mit oder ohne Schema-Unterstützung) und Warehouses (mit einer Collation aus einer festen Liste),
optionale Connections (Konnektivität),
einen optionalen Git-Link.

Im Basis-Setup ist der Development-workspace mit Git verknüpft und der Production-workspace nicht. Production erhält seine Inhalte über CI/CD-pipelines, was ein kontrollierteres Setup ergibt als eine direkte Git-Integration.

Data pipelines

Das workspace-module kann leere Fabric Data Pipelines erstellen (data_pipelines), aber das Workload-Root-module gibt diese Einstellung nicht weiter. Pipelines legt normalerweise das Data-Team im workspace an.

Networking¶

flowchart LR
    dev["Developer (VPN / ExpressRoute)"] --> pe["Private endpoint (spoke PE subnet)"]
    pe --> ws["Fabric workspace"]
    ws -->|"VNet data gateway"| spokenet["Spoke VNet"]
    spokenet --> azsrc["Azure data sources"]
    spokenet -->|"ExpressRoute / VPN"| onprem["On-premises sources"]
    ws -->|"managed private endpoint"| azres["Azure resource (Private Link)"]
    ws -->|"managed private endpoint"| ws2["Other Fabric workspace"]

Fabric zur Datenquelle, Option 1: das VNet data gateway. Es bietet ausgehende Konnektivität in das spoke-VNet und von dort zu On-Premises-Systemen. Connections sind so konfiguriert, dass sie das Gateway nutzen, und der workspace ist auf das vorgesehene Gateway beschränkt. Das Gateway nutzt ein eigenes Subnetz des spokes und wird mit einem Member-Gateway und einem Sleep nach 30 Minuten Inaktivität erstellt.
Fabric zur Datenquelle, Option 2: managed private endpoints. Eine direkte private Verbindung pro Ressource (zum Beispiel Storage oder SQL) über Private Link. Das Gateway braucht sie normalerweise nicht.
Azure zu Fabric. Private endpoints verbinden das spoke-VNet mit den workspaces. Die DNS-Auflösung dieser Endpunkte übernehmen die Private DNS zones, die die Plattform verwaltet (per Policy).
Entwickler. Die workspaces sind im Plattformnetzwerk isoliert, daher brauchen Entwickler VPN oder ExpressRoute.
Git. Ein Link zu GitHub braucht eine Outbound-Ausnahme, die die Plattform nur für workspaces mit einem Git-Link setzt.

Storage Account und Verschlüsselung¶

Der Workload-Tier erstellt pro Umgebung ein Storage Account:

Einstellung	Wert
Art und Tier	`BlockBlobStorage`, `Premium`, Hierarchical Namespace an
Replikation	`ZRS`
Verschlüsselung	Customer-managed Key im Key Vault des spokes (RSA 4096) über eine User-assigned Identity mit der Rolle Key Vault Crypto Service Encryption User, plus Infrastrukturverschlüsselung
Key-Rotation	Rotation Policy mit einer Lebensdauer von einem Jahr, automatische Rotation einen Monat vor Ablauf
Authentifizierung	Shared Access Keys deaktiviert, OAuth als Standard
Netzwerk	Default Action `Deny` mit Bypass für Azure-Services, private endpoints für `blob` und `dfs`
Datenschutz	Blob Soft Delete 90 Tage, Container Soft Delete 95 Tage, Change Feed an, Versionierung aus
Container	Ein privater Container pro ADLS-Connection

Flag für den öffentlichen Netzwerkzugriff

Der Code setzt public_network_access_enabled = true auf dem Storage Account zusammen mit einer Default-Action Deny der firewall. In der Praxis blockiert die firewall den öffentlichen Pfad, aber prüfe, was deine Plattform-Policy erwartet.

Identität¶

Workspace-Zugriff läuft über Entra-ID-Gruppen pro Rolle. Siehe Zugriff und Rollen.
Deployment-Identität: Der Service Principal des spokes deployt die Lösung. Er braucht unter anderem Rechte, um Keys zu erstellen und Secrets im Key Vault des spokes zu lesen, und die Rolle Storage Blob Data Contributor auf dem Data Lake (das module weist sie dem aktuellen Aufrufer zu). Für die capacity-Administratoren braucht er Microsoft-Graph-Anwendungsberechtigungen, siehe Voraussetzungen.
Zugriff auf Datenquellen: Für Quellen mit Entra-ID-Authentifizierung (Azure Storage, SQL) wird ein Service Principal verwendet. Standardmäßig ist es der Service Principal des spokes, aber es kann ein eigener referenziert werden. Er bekommt Zugriff auf die Quelle außerhalb dieser Lösung. Für Quellen ohne Entra-ID-Authentifizierung werden Basic Credentials oder Keys im Key Vault gespeichert und per Name referenziert.
Automatisierungs-Identitäten: Die Logic Apps zum Pausieren und Fortsetzen nutzen eine Managed Identity mit der Custom Role Fabric Capacity Operator. Siehe Entscheidungen.

Reihenfolge des Deployments¶

Voraussetzungen und Tenant-Einstellungen (Plattformkonfiguration).
Shared-Tier (capacities, optional auto-pause).
Governance-Tier (optional). Er braucht nur den Log-Analytics-Workspace und das Storage Account des spokes, kann also vor oder parallel zum Workload-Tier laufen.
Workload-Tier pro Umgebung (Gateway, workspaces, Connections, Storage).
Observability-Tier pro Umgebung (optional).