Opslagoverwegingen voor Azure Functions

Azure Functions vereist een Azure Storage-account wanneer u een exemplaar van een functie-app maakt. De volgende opslagservices kunnen worden gebruikt door uw functie-app:

Opslagservice Gebruik van functies
Azure Blob Storage Behoud de status van bindingen en functiesleutels.
Wordt ook gebruikt door taakhubs in Durable Functions.
Azure Files Bestandsshare die wordt gebruikt om de code van uw functie-app op te slaan en uit te voeren in een verbruiksabonnement en een Premium-abonnement.
Azure Files is standaard ingesteld, maar u kunt onder bepaalde voorwaarden een app maken zonder Azure Files.
Azure Queue Storage Wordt gebruikt door taakhubs in Durable Functions en voor het afhandelen van fouten en nieuwe pogingen door specifieke Azure Functions-triggers.
Azure Table Storage Wordt gebruikt door taakhubs in Durable Functions.

Belangrijk

Wanneer u het hostingabonnement Verbruik/Premium gebruikt, worden uw functiecode en bindingsconfiguratiebestanden opgeslagen in Azure Files in het hoofdopslagaccount. Wanneer u het belangrijkste opslagaccount verwijdert, wordt de inhoud verwijderd en kan deze niet worden hersteld.

Vereisten voor een opslagaccount

Wanneer u een functie-app maakt, moet u een Azure Storage-account voor algemeen gebruik maken of koppelen dat blob-, wachtrij- en tabelopslag ondersteunt. Deze vereiste bestaat omdat Functions afhankelijk is van Azure Storage voor bewerkingen zoals het beheren van triggers en het vastleggen van functie-uitvoeringen. Sommige opslagaccounts bieden geen ondersteuning voor wachtrijen en tabellen. Deze accounts omvatten opslagaccounts met alleen blob en Azure Premium Storage.

Zie Overzicht van opslagaccounts voor meer informatie over opslagaccounttypen.

Hoewel u een bestaand opslagaccount kunt gebruiken met uw functie-app, moet u ervoor zorgen dat het aan deze vereisten voldoet. Opslagaccounts die zijn gemaakt als onderdeel van de stroom voor het maken van functie-apps in de Azure Portal voldoen gegarandeerd aan deze opslagaccountvereisten. In de portal worden niet-ondersteunde accounts uitgefilterd bij het kiezen van een bestaand opslagaccount tijdens het maken van een functie-app. In deze stroom kunt u alleen bestaande opslagaccounts kiezen in dezelfde regio als de functie-app die u maakt. Zie Opslagaccountlocatie voor meer informatie.

Richtlijnen voor opslagaccounts

Voor elke functie-app is een opslagaccount vereist. Wanneer dat account wordt verwijderd, wordt uw functie-app niet uitgevoerd. Zie Problemen met betrekking tot opslag oplossen om problemen met betrekking tot opslag op te lossen. De volgende andere overwegingen zijn van toepassing op het opslagaccount dat wordt gebruikt door functie-apps.

De locatie van het opslagaccount

Voor de beste prestaties moet uw functie-app een opslagaccount in dezelfde regio gebruiken, wat de latentie vermindert. De Azure Portal dwingt deze best practice af. Als u om de een of andere reden een opslagaccount moet gebruiken in een andere regio dan uw functie-app, moet u uw functie-app buiten de portal maken.

Instelling voor verbinding met opslagaccount

De verbinding met het opslagaccount wordt onderhouden in de toepassingsinstelling AzureWebJobsStorage.

Het opslagaccount connection string moet worden bijgewerkt wanneer u opslagsleutels opnieuw genereert. Lees hier meer over opslagsleutelbeheer.

Gedeelde opslagaccounts

Het is mogelijk dat meerdere functie-apps hetzelfde opslagaccount zonder problemen delen. In Visual Studio kunt u bijvoorbeeld meerdere apps ontwikkelen met behulp van de Azurite-opslagemulator. In dit geval fungeert de emulator als één opslagaccount. Hetzelfde opslagaccount dat door uw functie-app wordt gebruikt, kan ook worden gebruikt om uw toepassingsgegevens op te slaan. Deze aanpak is echter niet altijd een goed idee in een productieomgeving.

Mogelijk moet u afzonderlijke store-accounts gebruiken om conflicten met host-id's te voorkomen.

Overwegingen voor levenscyclusbeheerbeleid

Functions maakt gebruik van Blob Storage om belangrijke informatie, zoals functietoegangssleutels, te behouden. Wanneer u beleid voor levenscyclusbeheer toepast op uw Blob Storage-account, kan het beleid blobs verwijderen die nodig zijn voor de Functions-host. Daarom moet u dergelijke beleidsregels niet toepassen op het opslagaccount dat door Functions wordt gebruikt. Als u een dergelijk beleid moet toepassen, vergeet dan niet om containers uit te sluiten die worden gebruikt door Functions, die worden voorafgegaan door azure-webjobs of scm.

Opslagprestaties optimaliseren

Gebruik een afzonderlijk opslagaccount voor elke functie-app om de prestaties te maximaliseren. Dit is vooral belangrijk wanneer u Durable Functions of door Event Hub geactiveerde functies hebt die beide een groot aantal opslagtransacties genereren. Wanneer uw toepassingslogica communiceert met Azure Storage, direct (met behulp van de opslag-SDK) of via een van de opslagbindingen, moet u een speciaal opslagaccount gebruiken. Als u bijvoorbeeld een door Event Hub geactiveerde functie hebt die bepaalde gegevens naar blobopslag schrijft, gebruikt u twee opslagaccounts: een voor de functie-app en een voor de blobs die door de functie worden opgeslagen.

Opslaggegevensversleuteling

Azure Storage versleutelt alle gegevens in een opslagaccount-at-rest. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie.

Gegevens worden standaard versleuteld met Microsoft beheerde sleutels. Voor meer controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven voor het versleutelen van blob- en bestandsgegevens. Deze sleutels moeten aanwezig zijn in Azure Key Vault voordat Functions toegang kan krijgen tot het opslagaccount. Zie Versleuteling-at-rest met door de klant beheerde sleutels voor meer informatie.

Gegevenslocatie in uw regio

Wanneer alle klantgegevens binnen één regio moeten blijven, moet het opslagaccount dat aan de functie-app is gekoppeld, een account zijn met redundantie in de regio. Er moet ook een redundant opslagaccount in de regio worden gebruikt met Azure Durable Functions.

Andere door het platform beheerde klantgegevens worden alleen opgeslagen in de regio wanneer ze worden gehost in een intern App Service Environment (ASE). Zie ASE-zoneredundantie voor meer informatie.

Overwegingen voor host-id's

Functions gebruikt een host-id-waarde als een manier om een bepaalde functie-app op unieke wijze te identificeren in opgeslagen artefacten. Deze id wordt standaard automatisch gegenereerd op basis van de naam van de functie-app, afgekapt tot de eerste 32 tekens. Deze id wordt vervolgens gebruikt bij het opslaan van correlatie per app en het bijhouden van informatie in het gekoppelde opslagaccount. Wanneer u functie-apps hebt met namen die langer zijn dan 32 tekens en wanneer de eerste 32 tekens identiek zijn, kan deze afkapping leiden tot dubbele host-id-waarden. Wanneer twee functie-apps met identieke host-id's hetzelfde opslagaccount gebruiken, krijgt u een conflict met de host-id omdat opgeslagen gegevens niet uniek kunnen worden gekoppeld aan de juiste functie-app.

Notitie

Dit zelfde soort host-id-collison kan optreden tussen een functie-app in een productiesite en dezelfde functie-app in een staging-site, wanneer beide sites hetzelfde opslagaccount gebruiken.

Vanaf versie 3.x van de Functions-runtime wordt een host-id-botsing gedetecteerd en wordt er een waarschuwing geregistreerd. In versie 4.x wordt een fout geregistreerd en wordt de host gestopt, wat resulteert in een harde fout. Meer informatie over host-id-botsing vindt u in dit probleem.

Conflicten met host-id's voorkomen

U kunt de volgende strategieën gebruiken om conflicten met host-id's te voorkomen:

  • Gebruik een gescheiden opslagaccount voor elke functie-app of -site die betrokken is bij de botsing.
  • Wijzig de naam van een van uw functie-apps in een waarde van minder dan 32 tekens, waardoor de berekende host-id voor de app wordt gewijzigd en de botsing wordt verwijderd.
  • Stel een expliciete host-id in voor een of meer van de botsende apps. Zie Host-id overschrijven voor meer informatie.

Belangrijk

Het wijzigen van het opslagaccount dat is gekoppeld aan een bestaande functie-app of het wijzigen van de host-id van de app kan van invloed zijn op het gedrag van bestaande functies. Een Blob Storage-trigger houdt bijvoorbeeld bij of er afzonderlijke blobs worden verwerkt door ontvangstbewijzen te schrijven onder een specifiek host-id-pad in de opslag. Wanneer de host-id wordt gewijzigd of u verwijst naar een nieuw opslagaccount, kunnen eerder verwerkte blobs opnieuw worden verwerkt.

De host-id overschrijven

U kunt expliciet een specifieke host-id voor uw functie-app instellen in de toepassingsinstellingen met behulp van de AzureFunctionsWebHost__hostid instelling. Zie AzureFunctionsWebHost__hostid voor meer informatie.

Wanneer de botsing tussen sleuven optreedt, moet u deze instelling mogelijk markeren als een site-instelling. Zie Werken met toepassingsinstellingen voor meer informatie over het maken van app-instellingen.

Clusters met Azure Arc

Wanneer uw functie-app wordt geïmplementeerd in een Kubernetes-cluster met Azure Arc, is er mogelijk geen opslagaccount vereist voor uw functie-app. In dit geval is een opslagaccount alleen vereist voor Functions wanneer uw functie-app een trigger gebruikt waarvoor opslag is vereist. In de volgende tabel wordt aangegeven voor welke triggers een opslagaccount is vereist en welke niet.

Niet vereist Mogelijk is opslag vereist
Azure Cosmos DB
HTTP
Kafka
RabbitMQ
Service Bus
Azure SQL
Blob-opslag
Event Grid
Event Hubs
IoT Hub
Wachtrijopslag
SendGrid
SignalR
Tabelopslag
Timer
Twilio

Als u een functie-app wilt maken in een Kubernetes-cluster met Azure Arc zonder opslag, moet u de Azure CLI-opdracht az functionapp create gebruiken. De versie van de Azure CLI moet versie 0.1.7 of een latere versie van de appservice-kube-extensie bevatten. Gebruik de az --version opdracht om te controleren of de extensie is geïnstalleerd en de juiste versie heeft.

Voor het maken van uw functie-app-resources met andere methoden dan de Azure CLI is een bestaand opslagaccount vereist. Als u van plan bent om triggers te gebruiken waarvoor een opslagaccount is vereist, moet u het account maken voordat u de functie-app maakt.

Een app maken zonder Azure Files

Azure Files is standaard ingesteld voor Premium- en niet-Linux-verbruiksabonnementen om te fungeren als een gedeeld bestandssysteem in grootschalige scenario's. Het bestandssysteem wordt door het platform gebruikt voor sommige functies, zoals logboekstreaming, maar het zorgt voornamelijk voor consistentie van de nettolading van de geïmplementeerde functie. Wanneer een app wordt geïmplementeerd met behulp van een externe pakket-URL, wordt de app-inhoud geleverd vanuit een afzonderlijk alleen-lezen bestandssysteem. Dit betekent dat u uw functie-app kunt maken zonder Azure Files. Als u uw functie-app maakt met Azure Files, is er nog steeds een beschrijfbaar bestandssysteem beschikbaar. Dit bestandssysteem is echter mogelijk niet beschikbaar voor alle exemplaren van functie-apps.

Wanneer Azure Files niet wordt gebruikt, moet u aan de volgende vereisten voldoen:

  • U moet implementeren vanuit een externe pakket-URL.
  • Uw app kan niet vertrouwen op een gedeeld beschrijfbaar bestandssysteem.
  • De app kan versie 1.x van de Functions-runtime niet gebruiken.
  • Logboekstreaming-ervaringen in clients, zoals de Azure Portal standaard in bestandssysteemlogboeken. In plaats daarvan moet u vertrouwen op Application Insights-logboeken.

Als er goed rekening wordt gehouden met het bovenstaande, kunt u de app maken zonder Azure Files. Maak de functie-app zonder de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING toepassingsinstellingen en WEBSITE_CONTENTSHARE op te geven. U kunt deze instellingen vermijden door een ARM-sjabloon voor een standaardimplementatie te genereren, de twee instellingen te verwijderen en vervolgens de sjabloon te implementeren.

Omdat functions Azure Files gebruiken tijdens onderdelen van het dynamische uitschaalproces, kan het schalen worden beperkt wanneer u zonder Azure Files werkt op verbruiks- en Premium-abonnementen.

Bestandsshares koppelen

Deze functionaliteit is momenteel alleen beschikbaar wanneer deze wordt uitgevoerd in Linux.

U kunt bestaande Azure Files shares koppelen aan uw Linux-functie-apps. Door een share te koppelen aan uw Linux-functie-app, kunt u bestaande machine learning-modellen of andere gegevens in uw functies gebruiken. U kunt de volgende opdracht gebruiken om een bestaande share te koppelen aan uw Linux-functie-app.

az webapp config storage-account add

In deze opdracht share-name is de naam van de bestaande Azure Files share en custom-id kan elke tekenreeks zijn die de share uniek definieert wanneer deze is gekoppeld aan de functie-app. mount-path Is ook het pad van waaruit de share wordt geopend in uw functie-app. mount-path moet de indeling /dir-namehebben en mag niet beginnen met /home.

Zie de scripts in Een Python-functie-app maken en een Azure Files share koppelen voor een volledig voorbeeld.

Op dit moment wordt alleen een storage-type van AzureFiles ondersteund. U kunt slechts vijf shares koppelen aan een bepaalde functie-app. Het koppelen van een bestandsshare kan de koude begintijd met ten minste 200-300 ms verhogen, of zelfs meer wanneer het opslagaccount zich in een andere regio bevindt.

De gekoppelde share is beschikbaar voor uw functiecode op de mount-path opgegeven. Wanneer mount-path bijvoorbeeld is /path/to/mount, hebt u toegang tot de doelmap per bestandssysteem-API's, zoals in het volgende Python-voorbeeld:

import os
...

files_in_share = os.listdir("/path/to/mount")

Volgende stappen

Meer informatie over Azure Functions hostingopties.