Speicheraspekte für Azure Functions
Azure Functions erfordert ein Azure Storage-Konto, wenn Sie eine Funktions-App-Instanz erstellen. Die folgenden Speicherdienste können von ihrer Funktions-App verwendet werden:
| Speicherdienst | Verwendung in Functions |
|---|---|
| Azure Blob Storage | Aufrechterhalten von Bindungszustand und Funktionsschlüsseln. Wird auch von Aufgabenhubs in Durable Functions verwendet. |
| Azure Files | Dateifreigabe, die zum Speichern und Ausführen Ihres Funktions-App-Codes in einem Verbrauchstarif und Premium-Plan verwendet wird. Azure Files wird standardmäßig eingerichtet, aber Sie können unter bestimmten Bedingungen eine App ohne Azure Files erstellen. |
| Azure Queue Storage | Verwendet von Aufgabenhubs in Durable Functions und für die Behandlung von Fehlern und Wiederholungen durch bestimmte Azure Functions-Trigger. |
| Azure Table Storage | Wird von Aufgabenhubs in Durable Functions verwendet. |
Wichtig
Wenn der verbrauchsbasierte Premium-Hostingplan verwendet wird, werden die Funktionscode- und Bindungskonfigurationsdateien in Azure Files im Hauptspeicherkonto gespeichert. Wenn Sie das Hauptspeicherkonto löschen, wird dieser Inhalt ebenfalls gelöscht und kann nicht wiederhergestellt werden.
Anforderungen an das Speicherkonto
Beim Erstellen einer Funktions-App müssen Sie ein allgemeines Azure Storage-Konto erstellen oder verknüpfen, das Blob-, Warteschlangen- und Tabellenspeicher unterstützt. Der Grund für diese Anforderung ist, dass Functions für Vorgänge wie das Verwalten von Triggern und das Ausführen von Protokollierfunktionen auf Azure Storage basiert. Einige Speicherkonten unterstützen keine Warteschlangen und Tabellen. Zu diesen Konten zählen reine Blobspeicherkonten und Azure Storage Premium.
Weitere Informationen zu Speicherkontotypen finden Sie in der Übersicht über Azure Storage-Konten.
Sie können zwar ein vorhandenes Speicherkonto mit ihrer Funktions-App verwenden, aber Sie müssen sicherstellen, dass diese Anforderungen erfüllt werden. Für Speicherkonten, die im Rahmen der Erstellung der Funktions-App im Azure-Portal erstellt werden, ist garantiert, dass sie diese Speicherkontenanforderungen erfüllen. Im Portal werden nicht unterstützte Konten herausgefiltert, wenn Sie beim Erstellen einer Funktions-App ein vorhandenes Speicherkonto auswählen. In diesem Flow dürfen Sie nur vorhandene Speicherkonten in derselben Region wie die von Ihnen erstellte Funktions-App auswählen. Weitere Informationen finden Sie unter Standort des Speicherkontos.
Speicherkonten, die mithilfe von Firewalls oder virtuellen privaten Netzwerken geschützt sind, können ebenfalls nicht im Erstellungsflow des Portals verwendet werden. Weitere Informationen finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.
Speicherkontoanleitung
Jede Funktions-App benötigt für den Betrieb ein Speicherkonto. Wenn dieses Konto gelöscht wird, wird Ihre Funktions-App nicht ausgeführt. Informationen zur Behandlung speicherbezogener Probleme finden Sie unter Behandeln speicherbezogener Probleme. Die folgenden weiteren Überlegungen gelten für das von Funktions-Apps verwendete Speicherkonto.
Standort des Speicherkontos
Für eine optimale Leistung sollte Ihre Funktions-App ein Speicherkonto in derselben Region verwenden, um die Latenz zu verringern. Im Azure-Portal wird diese bewährte Methode erzwungen. Wenn Sie aus irgendeinem Grund ein Speicherkonto in einer anderen Region als Ihre Funktions-App verwenden möchten, müssen Sie Ihre Funktions-App außerhalb des Portals erstellen.
Die Funktions-App benötigt Zugriff auf das Speicherkonto. Wenn Sie ein geschütztes Speicherkonto verwenden müssen, können Sie erwäge, Ihr Speicherkonto auf ein virtuelles Netzwerk zu beschränken.
Verbindungszeichenfolge für das Speicherkonto
Die Speicherkontoverbindung wird in der Anwendungseinstellung AzureWebJobsStorage verwaltet.
Die Verbindungszeichenfolgen für das Speicherkonto muss aktualisiert werden, wenn Sie Speicherschlüssel neu generieren. Erfahren Sie hier mehr über die Verwaltung von Speicherschlüsseln.
Freigegebene Speicherkonten
Es ist möglich, dass mehrere Funktions-Apps dasselbe Speicherkonto ohne Probleme gemeinsam nutzen. Beispielsweise können Sie in Visual Studio mit dem Azurite-Speicheremulator mehrere Apps entwickeln. In diesem Fall verhält sich der Emulator wie ein einzelnes Speicherkonto. Dasselbe Speicherkonto, das von Ihrer Funktions-App verwendet wird, kann auch von zum Speichern Ihrer Anwendungsdaten verwendet werden. Dieser Ansatz ist jedoch in einer Produktionsumgebung nicht immer eine gute Idee.
Möglicherweise müssen Sie separate Speicherkonten verwenden, um Host-ID-Kollisionen zu vermeiden.
Überlegungen zu Richtlinien für die Lebenszyklusverwaltung
Azure Functions verwendet Blob Storage, um wichtige Informationen wie Funktionszugriffsschlüssel dauerhaft zu speichern. Wenn Sie eine Richtlinie zur Lebenszyklusverwaltung auf Ihr Blob Storage-Konto anwenden, kann die Richtlinie Blobs entfernen, die vom Azure Functions-Host benötigt werden. Aus diesem Grund sollten Sie solche Richtlinien nicht auf das Speicherkonto anwenden, das von Functions verwendet wird. Wenn Sie eine solche Richtlinie anwenden müssen, denken Sie daran, die von Functions verwendeten Container auszuschließen, die das Präfix azure-webjobs oder scm aufweisen.
Optimieren der Speicherleistung
Verwenden Sie für jede Funktions-App ein separates Speicherkonto, um die Leistung zu maximieren. Dies ist besonders wichtig, wenn Sie über Durable Functions oder durch Event Hub ausgelöste Funktionen verfügen, die eine große Menge an Speichertransaktionen generieren. Wenn Ihre Anwendungslogik mit Azure Storage interagiert (direkt mit dem Storage SDK oder über eine der Speicherbindungen), sollten Sie ein dediziertes Speicherkonto verwenden. Wenn Sie z. B. über eine von Event Hub ausgelöste Funktion verfügen, die Daten in Blob Storage schreibt, verwenden Sie zwei Speicherkonten: eines für die Funktions-App und ein weiteres für die Blobs, die von der Funktion gespeichert werden.
Speicherdatenverschlüsselung
Azure Storage verschlüsselt alle Daten in einem ruhenden Speicherkonto. Weitere Informationen finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.
Standardmäßig werden Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Für eine zusätzliche Kontrolle über die Verschlüsselungsschlüssel können Sie vom Kunden verwaltete Schlüssel bereitstellen, mit denen Blob- und Dateidaten verschlüsselt werden können. Diese Schlüssel müssen in Azure Key Vault vorhanden sein, damit Functions auf das Speicherkonto zugreifen kann. Weitere Informationen finden Sie unter Verschlüsselung im Ruhezustand mithilfe von kundenseitig verwalteten Schlüsseln.
Data Residency in der Region
Wenn alle Kundendaten in einer einzelnen Region verbleiben müssen, muss das Speicherkonto, das der Funktions-App zugeordnet ist, eines mit regionsinterner Redundanz sein. Für Speicherkonten mit regionsinterner Redundanz muss auch Azure Durable Functions verwendet werden.
Andere plattformseitig verwaltete Kundendaten werden nur dann in der Region gespeichert, wenn sie in einer App Service-Umgebung (ASE) mit internem Lastenausgleich gehostet werden. Weitere Informationen finden Sie unter ASE-Zonenredundanz.
Überlegungen zur Host-ID
Funktionen verwenden einen Host-ID-Wert als Möglichkeit, eine bestimmte Funktions-App in gespeicherten Artefakten eindeutig zu identifizieren. Standardmäßig wird diese ID automatisch vom Namen der Funktions-App generiert, der auf die ersten 32 Zeichen abgeschnitten wird. Diese ID wird dann beim Speichern von Korrelations- und Nachverfolgungsinformationen pro App im verknüpften Speicherkonto verwendet. Wenn Sie Funktions-Apps mit Namen mit mehr als 32 Zeichen haben und wenn die ersten 32 Zeichen identisch sind, kann diese Abkürzung zu doppelten Host-ID-Werten führen. Wenn zwei Funktions-Apps mit identischen Host-IDs dasselbe Speicherkonto verwenden, erhalten Sie eine Host-ID-Kollision, da gespeicherte Daten nicht eindeutig mit der richtigen Funktions-App verknüpft werden können.
Hinweis
Die gleiche Art von Host-ID-Kollision kann zwischen einer Funktions-App in einem Produktionsslot und der gleichen Funktions-App in einem Stagingslot auftreten, wenn beide Slots das gleiche Speicherkonto verwenden.
Ab Version 3.x der Funktions-Runtime wird die Host-ID-Kollision erkannt und eine Warnung protokolliert. In Version 4.x wird ein Fehler protokolliert, und der Host wird beendet, was zu einem schweren Fehler führt. Weitere Informationen zur Host-ID-Kollision finden Sie in diesem Problem.
Vermeiden von Host-ID-Kollisionen
Sie können die folgenden Strategien verwenden, um Host-ID-Kollisionen zu vermeiden:
- Verwenden Sie ein getrenntes Speicherkonto für jede Funktions-App oder jeden Slot, die bzw.der an der Kollision beteiligt ist.
- Benennen Sie eine Ihrer Funktionsanwendungen in einen Wert um, der weniger als 32 Zeichen lang ist. Dadurch wird die berechnete Host-ID für die App geändert und die Kollision beseitigt.
- Legen Sie eine explizite Host-ID für eine oder mehrere der kollidierenden Apps fest. Weitere Informationen finden Sie unter Außerkraftsetzung der Host-ID.
Wichtig
Das Ändern des Speicherkontos, das einer vorhandenen Funktions-App zugeordnet ist, oder das Ändern der Host-ID der App kann sich auf das Verhalten vorhandener Funktionen auswirken. Beispielsweise verfolgt ein Blob-Storage-Trigger nach, ob einzelne Blobs verarbeitet werden, indem er Bestätigungen unter einem bestimmten Host-ID-Pfad im Speicher schreibt. Wenn sich die Host-ID ändert oder Sie auf ein neues Speicherkonto verweisen, werden zuvor verarbeitete Blobs möglicherweise erneut verarbeitet.
Außerkraftsetzung der Host-ID
Sie können mithilfe der Einstellung AzureFunctionsWebHost__hostid explizit eine bestimmte Host-ID für Ihre Funktions-App in den Anwendungseinstellungen festlegen. Weitere Informationen finden Sie unter AzureFunctionsWebHost__hostid.
Wenn die Kollision zwischen Slots auftritt, müssen Sie eine spezifische Host-ID für jeden Slot festlegen, einschließlich des Produktionsslots. Sie müssen diese Einstellungen auch als Bereitstellungseinstellungen markieren, damit sie nicht ausgetauscht werden. Informationen zum Erstellen von App-Einstellungen finden Sie unter Arbeiten mit Anwendungseinstellungen.
Cluster mit Azure Arc-Unterstützung
Wenn Ihre Funktions-App in einem Kubernetes-Cluster mit Azure Arc-Unterstützung bereitgestellt wird, ist möglicherweise kein Speicherkonto für Ihre Funktions-App erforderlich. In diesem Fall ist nur ein Speicherkonto für Functions erforderlich, wenn Ihre Funktions-App einen Trigger verwendet, der Speicher erfordert. In der folgenden Tabelle ist angegeben, welche Trigger möglicherweise ein Speicherkonto erfordern und welche nicht:
| Nicht erforderlich | Speicher möglicherweise erforderlich |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Blob Storage • Event Grid • Event Hubs • IoT Hub • Queue Storage • SendGrid • SignalR • Table Storage • Timer • Twilio |
Um eine Funktions-App in einem Kubernetes-Cluster mit Azure Arc-Unterstützung ohne Speicher zu erstellen, müssen Sie den Azure CLI-Befehl az functionapp create verwenden. Die Version der Azure CLI muss mindestens Version 0.1.7 der Erweiterung appservice-kube enthalten. Verwenden Sie den Befehl az --version, um zu überprüfen, ob die richtige Version der Erweiterung installiert ist.
Das Erstellen Ihrer Funktions-App-Ressourcen mit anderen Methoden als der Azure CLI erfordert ein vorhandenes Speicherkonto. Wenn Sie beabsichtigen, Trigger zu verwenden, die ein Speicherkonto erfordern, sollten Sie das Konto erstellen, bevor Sie die Funktions-App erstellen.
Erstellen einer App ohne Azure Files
Azure Files wird standardmäßig für Premium- und Nicht-Linux-Verbrauchspläne eingerichtet, um als freigegebenes Dateisystem in Szenarien mit hoher Skalierung zu dienen. Das Dateisystem wird von der Plattform für einige Features wie Protokollstreaming verwendet, stellt aber in erster Linie die Konsistenz der bereitgestellten Funktionsnutzdaten sicher. Wenn eine App mithilfe einer externen Paket-URL bereitgestellt wird, wird der App-Inhalt von einem separaten schreibgeschützten Dateisystem bereitgestellt. Dies bedeutet, dass Sie Ihre Funktions-App ohne Azure Files erstellen können. Wenn Sie Ihre Funktions-App mit Azure Files erstellen, wird weiterhin ein schreibbares Dateisystem bereitgestellt. Dieses Dateisystem ist jedoch möglicherweise nicht für alle Funktions-App-Instanzen verfügbar.
Wenn Azure Files nicht verwendet wird, müssen Sie die folgenden Anforderungen erfüllen:
- Sie müssen die Bereitstellung über eine externe Paket-URL ausführen.
- Ihre App kann sich nicht auf ein freigegebenes beschreibbares Dateisystem verlassen.
- Die App kann nicht Version 1.x der Functions-Runtime verwenden.
- Für Protokollstreaming in Clients wie dem Azure-Portal werden standardmäßig Dateisystemprotokolle verwendet. Sie sollten stattdessen Application Insights-Protokolle verwenden.
Wenn die oben genannten Punkte ordnungsgemäß berücksichtigt werden, können Sie die App ohne Azure Files erstellen. Erstellen Sie die Funktions-App, ohne die Anwendungseinstellungen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE anzugeben. Sie können diese Einstellungen vermeiden, indem Sie eine ARM-Vorlage für eine Standardbereitstellung generieren, diese beiden Einstellungen entfernen und die Vorlage dann bereitstellen.
Da Functions Azure Files in Teilen der dynamischen horizontalen Skalierung verwendet, kann Skalierung eingeschränkt werden, wenn die Ausführung ohne Azure Files in Verbrauchs- und Premium-Plänen erfolgt.
Einbinden von Dateifreigaben
Diese Funktion ist derzeit nur unter Linux verfügbar.
Sie können vorhandene Azure Files-Freigaben in Ihre Linux-Funktions-Apps einbinden. Durch das Einbinden einer Freigabe in Ihre Linux-Funktions-App können Sie vorhandene Machine Learning-Modelle oder andere Daten in Ihren Funktionen verwenden. Sie können den folgenden Befehl verwenden, um eine vorhandene Freigabe in Ihre Linux-Funktions-App einzubinden.
az webapp config storage-account add
Bei diesem Befehl ist share-name der Name der vorhandenen Azure Files-Freigabe, und custom-id kann ein beliebige Zeichenfolge sein, mit der die Freigabe bei der Einbindung in die Funktions-App eindeutig definiert wird. mount-path ist der Pfad, über den in Ihrer Funktions-App auf die Freigabe zugegriffen wird. mount-path muss das Format /dir-name haben und darf nicht mit /home beginnen.
Ein vollständiges Beispiel finden Sie in den Skripts unter Einbinden einer Dateifreigabe in eine Python-Funktions-App mithilfe der Azure CLI.
Derzeit wird als storage-type nur AzureFiles unterstützt. Sie können pro Funktions-App nicht mehr als fünf Freigaben einbinden. Durch die Einbindung einer Dateifreigabe verlängert sich die Kaltstartdauer ggf. um mindestens 200 bis 300 ms. Dieser Wert ist noch höher, wenn sich das Speicherkonto in einer anderen Region befindet.
Die eingebundene Freigabe ist für Ihren Funktionscode unter dem angegebenen mount-path verfügbar. Wenn mount-path beispielsweise /path/to/mount lautet, können Sie wie im folgenden Python-Beispiel über Dateisystem-APIs auf das Zielverzeichnis zugreifen:
import os
...
files_in_share = os.listdir("/path/to/mount")
Nächste Schritte
Weitere Informationen zu Hostingoptionen von Azure Functions.