Durable Functions-Speicheranbieter

  • Artikel

Die Durable Functions-Erweiterung besteht aus Azure Functions-Triggern und -Bindungen, die intern vom Durable Task-Framework unterstützt werden. DTFx unterstützt verschiedene Back-End-Speicheranbieter, einschließlich des Azure Storage-Anbieters, der von Durable Functions verwendet wird. Ab der Durable Functions-Version v2.5.0 können Benutzer ihre Funktions-Apps so konfigurieren, dass ein anderer DTFx-Speicheranbieter als der Azure Storage-Anbieter verwendet wird.

Hinweis

Für viele Funktions-Apps ist der standardmäßige Azure Storage-Anbieter für Durable Functions wahrscheinlich ausreichend und am einfachsten zu verwenden, da er keine zusätzliche Konfiguration erfordert. Es gibt jedoch Kompromisse bei den Kosten, der Skalierbarkeit und der Datenverwaltung, die den Einsatz eines alternativen Speicheranbieters befürworten können.

Zwei alternative Speicheranbieter wurden für die Verwendung mit Durable Functions und dem Durable Task Framework entwickelt, und zwar der Netherite-Speicheranbieter und der Microsoft SQL Server-Speicheranbieter (MSSQL). Dieser Artikel beschreibt alle drei unterstützten Anbieter, vergleicht sie miteinander und stellt grundlegende Informationen zu den ersten Schritten bei der Verwendung bereit.

Hinweis

Es ist derzeit nicht möglich, Daten von einem Speicheranbieter zu einem anderen zu migrieren. Wenn Sie einen neuen Speicheranbieter verwenden möchten, sollten Sie eine neue App erstellen, die mit dem neuen Speicheranbieter konfiguriert ist.

Azure Storage

Azure Storage ist der Standardspeicheranbieter für Durable Functions. Dieser nutzt Warteschlangen, Tabellen und Blobs, um den Orchestrierungs- und Entitätszustand dauerhaft zu speichern. Außerdem werden Blobs und Blobleases verwendet, um Partitionen zu verwalten. In vielen Fällen ist das Speicherkonto, das zum Speichern des Durable Functions-Laufzeitstatus verwendet wird, mit dem Standardspeicherkonto identisch, das von Azure Functions (AzureWebJobsStorage) verwendet wird. Es ist jedoch auch möglich, Durable Functions mit einem separaten Speicherkonto zu konfigurieren. Der Azure Storage-Anbieter ist in die Durable Functions-Erweiterung integriert und besitzt keine anderen Abhängigkeiten.

Die wichtigsten Vorteile des Azure Storage-Anbieters sind die folgenden:

  • Es ist kein Setup erforderlich. Sie können das Speicherkonto verwenden, das von den Einrichtungsfunktionen der Funktions-App für Sie erstellt wurde.
  • Kostengünstigstes serverloses Abrechnungsmodell: Azure Storage verfügt über ein nutzungsbasiertes Preismodell, das vollständig auf der Nutzung basiert (weitere Informationen).
  • Beste Toolunterstützung: Azure Storage bietet plattformübergreifende lokale Emulation und lässt sich in Visual Studio, Visual Studio Code und das Azure Functions Core Tools-Toolset integrieren.
  • Der ausgereifteste Anbieter: Azure Storage ist das ursprüngliche und bewährteste Speicher-Back-End für Durable Functions.
  • Vorschausupport für die Verwendung der Identität anstelle von Geheimnissen zum Herstellen einer Verbindung mit dem Speicheranbieter.

Den Quellcode für die DTFx-Komponenten des Azure Storage-Speicheranbieters finden Sie im GitHub-Repository Azure/durabletask.

Hinweis

Für die universelle Verwendung des Azure Storage-Anbieters sind allgemeine Azure Storage-Standardkonten erforderlich. Andere Speicherkontotypen werden nicht unterstützt. Es wird dringend empfohlen, allgemeine Legacyspeicherkonten der Version 1 zu verwenden, da die neueren v2-Speicherkonten für Durable Functions-Workloads um einiges teurer sein können. Weitere Informationen zu Azure Storage-Kontotypen finden Sie in der Dokumentation unter Speicherkontoübersicht.

Netherite

Das Netherite-Speicher-Back-End wurde von Microsoft Research entworfen und entwickelt. Dabei werden, zusätzlich zu Azure-Seiten-Blobs, Azure Event Hubs sowie die FASTER-Datenbanktechnologie verwendet. Das Design von Netherite ermöglicht im Vergleich zu anderen Anbietern eine Verarbeitung von Orchestrierungen und Entitäten mit deutlich höherem Durchsatz. In einigen Benchmarkszenarios wurde deutlich, dass der Durchsatz im Vergleich zum Azure Storage-Standardanbieter um mehr als eine Größenordnung zunimmt.

Die wichtigsten Vorteile des Netherite-Speicheranbieters sind die folgenden:

  • Er bietet einen erheblich höheren Durchsatz bei geringeren Kosten im Vergleich zu anderen Speicheranbietern.
  • Netherite unterstützt die Preis-/Leistungsoptimierung, wodurch Sie die Leistung bei Bedarf hochskalieren können.
  • Es werden bis zu 32 Datenpartitionen mit Event Hubs Basic- und Standard-SKUs unterstützt.
  • Netherite ist kostengünstiger als andere Anbieter im Hinblick auf Workloads mit hohem Durchsatz.

Weitere Informationen zu den technischen Details des Netherite-Speicheranbieters, einschließlich der ersten Schritte bei der Verwendung, finden Sie in der Netherite-Dokumentation. Den Quellcode für den Netherite-Speicheranbieter finden Sie im GitHub-Repository microsoft/durabletask-netherite. Eine detailliertere Auswertung des Netherite-Speicheranbieters ist auch in der folgenden Forschungsarbeit verfügbar: Serverless Workflows with Durable Functions and Netherite (Serverlose Workflows mit Durable Functions und Netherite).

Hinweis

Der Name Netherite stammt aus der Welt von Minecraft.

Microsoft SQL Server (MSSQL)

Der Microsoft SQL Server-Speicheranbieter (MSSQL) speichert alle Zustände dauerhaft in einer Microsoft SQL Server-Datenbank. Er ist sowohl mit lokalen als auch in der Cloud gehosteten Bereitstellungen von SQL Server kompatibel (einschließlich Azure SQL-Datenbank).

Die wichtigsten Vorteile des MSSQL-Speicheranbieters sind die folgenden:

  • Er unterstützt nicht verknüpfte Umgebungen: Es ist keine Azure-Konnektivität bei der Verwendung einer SQL Server-Installation erforderlich.
  • Er ist umgebungs- und cloudübergreifend portierbar, einschließlich in von Azure gehosteten und lokalen Umgebungen und Clouds.
  • Es wird eine starke Datenkonsistenz bereitgestellt, wodurch Sicherung bzw. Wiederherstellung sowie Failover ohne Datenverlust möglich sind.
  • Er bietet native Unterstützung für benutzerdefinierte Datenverschlüsselung (ein Feature von SQL Server).
  • Die Integration in vorhandene Datenbankanwendungen über integrierte gespeicherte Prozeduren ist ebenfalls enthalten.

Weitere Informationen zu den technischen Details des MSSQL-Speicheranbieters, einschließlich der ersten Schritte bei der Verwendung, finden Sie in der Dokumentation für den Microsoft SQL-Anbieter. Den Quellcode für den MSSQL-Speicheranbieter finden Sie im GitHub-Repository microsoft/durabletask-mssql.

Konfigurieren alternativer Speicheranbieter

Das Konfigurieren alternativer Speicheranbieter ist in der Regel ein zweistufiger Prozess:

  1. Fügen Sie Ihrer Funktions-App das entsprechende NuGet-Paket hinzu (diese Anforderung gilt temporär für Apps, die Erweiterungsbündel verwenden).
  2. Aktualisieren Sie die host.json-Datei, um anzugeben, welchen Speicheranbieter Sie verwenden möchten.

Wenn in „host.json“ explizit kein Speicheranbieter konfiguriert ist, wird standardmäßig der Azure Storage-Anbieter aktiviert.

Konfigurieren des Azure Storage-Anbieters

Der Azure Storage-Anbieter ist der Standardspeicheranbieter und erfordert keine explizite Konfiguration, keine NuGet-Paketverweise oder Erweiterungspaketverweise. Die vollständigen host.json-Konfigurationsoptionen finden Sie hier unter dem Pfad extensions/durableTask/storageProvider.

Verbindungen

Die connectionName-Eigenschaft in host.json ist ein Verweis auf eine Umgebungskonfiguration, die angibt, wie sich die App mit Azure Storage verbinden soll. Folgendes kann angegeben werden:

Wenn der konfigurierte Wert sowohl eine genaue Übereinstimmung für eine einzelne Einstellung als auch eine Präfix-Übereinstimmung für andere Einstellungen ist, wird die genaue Übereinstimmung verwendet. Wenn in host.json kein Wert angegeben ist, lautet der Standardwert „AzureWebJobsStorage“.

Identitätsbasierte Verbindungen

Wenn Sie Version 2.7.0.x oder eine höhere Version der Erweiterung und den Azure Storage-Anbieter verwenden, können Sie die App anstelle einer Verbindungszeichenfolge mit einem Geheimnis eine Microsoft Entra-Identität verwenden lassen. Dazu definieren Sie Einstellungen unter einem gemeinsamen Präfix, das der Eigenschaft connectionName in der Trigger- und Bindungskonfiguration entspricht.

Um eine identitätsbasierte Verbindung für Durable Functions zu verwenden, konfigurieren Sie die folgenden App-Einstellungen:

Eigenschaft Vorlage für Umgebungsvariable BESCHREIBUNG Beispielwert
Blob-Dienst-URI <CONNECTION_NAME_PREFIX>__blobServiceUri Der Datenebenen-URI des Blob-Diensts des Speicherkontos im HTTPS-Schema. https://<storage_account_name>.blob.core.windows.net
Warteschlangendienst-URI <CONNECTION_NAME_PREFIX>__queueServiceUri Der Datenebenen-URI des Warteschlangendiensts des Speicherkontos im HTTPS-Schema. https://<storage_account_name>.queue.core.windows.net
Tabellendienst-URI <CONNECTION_NAME_PREFIX>__tableServiceUri Der Datenebenen-URI eines Tabellendiensts des Speicherkontos im HTTPS-Schema. https://<speicherkonto_name>.table.core.windows.net

Zusätzliche Eigenschaften können festgelegt werden, um die Verbindung anzupassen. Weitere Informationen finden Sie unter Allgemeine Eigenschaften für identitätsbasierte Verbindungen.

Identitätsbasierte Verbindungen verwenden eine verwaltete Identität, wenn sie im Azure Functions-Dienst gehostet werden. Standardmäßig wird eine vom System zugewiesene Identität verwendet, auch wenn mit den Eigenschaften credential und clientID eine vom Benutzer zugewiesene Identität angegeben werden kann. Beachten Sie, dass das Konfigurieren einer benutzerseitig zugewiesenen Identität mit einer Ressourcen-ID nicht unterstützt wird. Bei Ausführung in anderen Kontexten (z. B. bei der lokalen Entwicklung) wird stattdessen Ihre Entwickleridentität verwendet, Dieses Verhalten kann angepasst werden. Weitere Informationen finden Sie unter Lokale Entwicklung mit identitätsbasierten Verbindungen.

Erteilen der Berechtigung für die Identität

Unabhängig davon, welche Identität verwendet wird, muss diese über Berechtigungen zum Ausführen der vorgesehenen Aktionen verfügen. Daher müssen Sie für die meisten Azure-Dienste eine Rolle in Azure RBAC zuweisen, indem Sie entweder integrierte oder benutzerdefinierte Rollen verwenden, die diese Berechtigungen bieten.

Wichtig

Vom Zieldienst werden möglicherweise einige nicht für alle Kontexte erforderliche Berechtigungen verfügbar gemacht. Befolgen Sie nach Möglichkeit das Prinzip der geringsten Berechtigung, und gewähren Sie der Identität nur die erforderlichen Berechtigungen. Wenn die App beispielsweise nur Daten aus einer Datenquelle lesen muss, verwenden Sie eine Rolle, die nur über Leseberechtigungen verfügt. Es wäre nicht angemessen, eine Rolle zu zuweisen, die auch das Schreiben in diesen Dienst zulässt, da dies eine übermäßige Berechtigung für einen Lesevorgang wäre. Ebenso sollten Sie sicherstellen, dass die Rollenzuweisung auf die Ressourcen begrenzt ist, die gelesen werden müssen.

Sie müssen eine Rollenzuweisung erstellen, die zur Laufzeit Zugriff auf Azure Storage ermöglicht. Verwaltungsrollen wie Besitzer sind nicht ausreichend. Die folgenden integrierten Rollen werden für die Durable Functions-Erweiterung im Normalbetrieb empfohlen:

Ihre Anwendung erfordert möglicherweise weitere Berechtigungen basierend auf dem von Ihnen geschriebenen Code. Wenn Sie das Standardverhalten verwenden oder connectionName explizit auf „AzureWebJobsStorage“ festlegen, finden Sie unter Verbinden mit dem Hostspeicher mit einer Identität weitere Aspekte im Zusammenhang mit Berechtigungen.

Konfigurieren des Netherite-Speicheranbieters

Wenn Sie den Netherite-Speicheranbieter aktivieren möchten, muss die Konfiguration in Ihrem host.json geändert werden. Für C#-Benutzer ist außerdem ein zusätzlicher Installationsschritt erforderlich.

host.json Konfiguration

Das folgende „host.json“-Beispiel zeigt die Mindestkonfiguration, die zum Aktivieren des Netherite-Speicheranbieters erforderlich ist.

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "Netherite",
        "storageConnectionName": "AzureWebJobsStorage",
        "eventHubsConnectionName": "EventHubsConnection"
      }
    }
  }
}

Ausführlichere Setupanweisungen finden Sie in der Netherite-Dokumentation zu den ersten Schritten.

Netherite-Erweiterung installieren (nur .NET)

Hinweis

Wenn Ihre App Erweiterungspakete verwendet, sollten Sie diesen Abschnitt ignorieren, da die manuelle Erweiterungsverwaltung durch Erweiterungspakete entfällt.

Sie müssen die neueste Version der Netherite-Erweiterung auf NuGet installieren. Dies bedeutet in der Regel, dass Sie einen Verweis darauf in Ihre Datei vom Typ „.csproj“ aufnehmen und das Projekt erstellen.

Das zu installierende Erweiterungspaket hängt vom verwendeten .NET-Worker ab:

Konfigurieren des MSSQL-Speicheranbieters

Wenn Sie den MSSQL-Speicheranbieter aktivieren möchten, muss die Konfiguration in Ihrem host.json geändert werden. Für C#-Benutzer ist außerdem ein zusätzlicher Installationsschritt erforderlich.

host.json Konfiguration

Das folgende Beispiel zeigt die Mindestkonfiguration, die zum Aktivieren des MSSQL-Speicheranbieters erforderlich ist.

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "mssql",
        "connectionStringName": "SQLDB_Connection"
      }
    }
  }
}

Ausführlichere Setupanweisungen finden Sie in der Dokumentation zu den ersten Schritten im MSSQL-Anbieter.

MSSQL-Erweiterung für dauerhafte Aufgaben installieren (nur .NET)

Hinweis

Wenn Ihre App Erweiterungspakete verwendet, sollten Sie diesen Abschnitt ignorieren, da die manuelle Erweiterungsverwaltung durch Erweiterungspakete entfällt.

Sie müssen die neueste Version der MSSQL-Speicheranbietererweiterung auf NuGet installieren. Dies bedeutet in der Regel, dass Sie einen Verweis darauf in Ihre Datei vom Typ „.csproj“ aufnehmen und das Projekt erstellen.

Das zu installierende Erweiterungspaket hängt vom verwendeten .NET-Worker ab:

Vergleichen von Speicheranbietern

Es gibt viele maßgebliche Kompromisse zwischen den verschiedenen unterstützten Speicheranbietern. In der folgenden Tabelle sind die jeweiligen Kompromisse aufgeführt, und Sie können anhand dieser Punkte dann entscheiden, welcher Speicheranbieter für Ihre Anforderungen am besten geeignet ist.

Speicheranbieter Azure Storage Netherite MSSQL
Offizieller Supportstatus ✅ Allgemein verfügbar (Generally Available, GA) ✅ Allgemein verfügbar (Generally Available, GA) ✅ Allgemein verfügbar (Generally Available, GA)
Externe Abhängigkeiten Azure Storage-Konto (universell, v1) Azure Event Hubs
Azure Storage-Konto (universell)		 SQL Server 2019 oder Azure SQL-Datenbank
Lokale Entwicklungs- und Emulationsoptionen Azurite v3.12 und höher (plattformübergreifend) Unterstützt die Speicheremulation von Aufgabenhubs (weitere Informationen) SQL Server Developer Edition (unterstützt Windows-, Linux- und Docker-Container)
Aufgabenhubkonfiguration Explizit Explizit Standardmäßig implizit (weitere Informationen)
Maximaler Durchsatz Moderat Sehr hoch Moderat
Maximale Orchestrierung/Aufskalierung von Entitäten (Knoten) 16 32 –
Maximales Aufskalieren von Aktivitäten (Knoten) – 32 –
KEDA 2.0: Skalierungsunterstützung
(Weitere Informationen)		 ❌ Nicht unterstützt ❌ Nicht unterstützt ✅ Unterstützt die Verwendung des MSSQL-Scalers (weitere Informationen)
Unterstützung für Erweiterungsbündel (empfohlen für Apps, die keine .NET-Apps sind) ✅ Vollständig unterstützt ✅ Vollständig unterstützt ✅ Vollständig unterstützt
Für Preis/Leistung konfigurierbar? ❌ Nein ✅ Ja (Event Hubs-TUs und -CUs) ✅ Ja (SQL-vCPUs)
Unterstützung von nicht verknüpften Umgebungen ❌ Azure-Konnektivität erforderlich ❌ Azure-Konnektivität erforderlich ✅ Vollständig unterstützt
Identitätsbasierte Verbindungen ✅ Vollständig unterstützt ❌ Nicht unterstützt ⚠️ Erfordert runtimegesteuerte Skalierung

Nächste Schritte

Informationen zur Durable Functions-Leistung und -Skalierung