Delen via

Overwegingen bij het gebruik van opslag voor Azure Functions

  • Artikel

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 functietoetsen1.
Implementatiebron voor apps die worden uitgevoerd in een Flex Consumption-abonnement.
Standaard gebruikt voor taakhubs in Durable Functions.
Kan worden gebruikt om functie-app-code op te slaan voor externe build voor Linux-verbruik of als onderdeel van externe pakket-URL-implementaties.
Azure Files2 Bestandsshare die wordt gebruikt om uw functie-app-code op te slaan en uit te voeren in een verbruiksabonnement en Premium-abonnement.
Azure Queue Storage Standaard gebruikt voor taakhubs in Durable Functions. Wordt gebruikt voor het verwerken van fouten en het opnieuw proberen in specifieke Azure Functions-triggers. Wordt gebruikt voor het bijhouden van objecten door de Blob Storage-trigger.
Azure Table storage Standaard gebruikt voor taakhubs in Durable Functions.
  1. Blob Storage is het standaardarchief voor functiesleutels, maar u kunt een alternatief archief configureren.
  2. Azure Files is standaard ingesteld, maar u kunt onder bepaalde voorwaarden een app zonder Azure Files maken.

Belangrijke aandachtspunten

Houd rekening met de volgende feiten met betrekking tot de opslagaccounts die door uw functie-apps worden gebruikt:

  • Wanneer uw functie-app wordt gehost in het verbruiksabonnement of Premium-abonnement, worden uw functiecode en configuratiebestanden opgeslagen in Azure Files in het gekoppelde opslagaccount. Wanneer u dit opslagaccount verwijdert, wordt de inhoud verwijderd en kan deze niet worden hersteld. Zie Opslagaccount is verwijderd voor meer informatie

  • Belangrijke gegevens, zoals functiecode, toegangssleutels en andere belangrijke servicegerelateerde gegevens, kunnen worden bewaard in het opslagaccount. U moet de toegang tot de opslagaccounts die door functie-apps worden gebruikt, zorgvuldig beheren op de volgende manieren:

    • Controleer en beperk de toegang van apps en gebruikers tot het opslagaccount op basis van een model met minimale bevoegdheden. Machtigingen voor het opslagaccount kunnen afkomstig zijn van gegevensacties in de toegewezen rol of via machtigingen voor het uitvoeren van de listKeys-bewerking.

    • Bewaak de activiteit van het besturingsvlak (zoals het ophalen van sleutels) en gegevensvlakbewerkingen (zoals schrijven naar een blob) in uw opslagaccount. Overweeg opslaglogboeken te onderhouden op een andere locatie dan Azure Storage. Zie Opslaglogboeken voor meer informatie.

Vereisten voor een opslagaccount

Opslagaccounts die zijn gemaakt als onderdeel van de stroom voor het maken van de functie-app in Azure Portal, werken gegarandeerd met de nieuwe functie-app. Wanneer u ervoor kiest om een bestaand opslagaccount te gebruiken, bevat de opgegeven lijst geen bepaalde niet-ondersteunde opslagaccounts. De volgende beperkingen zijn van toepassing op opslagaccounts die worden gebruikt door uw functie-app, dus zorg ervoor dat een bestaand opslagaccount aan deze vereisten voldoet:

  • Het accounttype moet blob-, wachtrij- en tableopslag ondersteunen. Sommige opslagaccounts bieden geen ondersteuning voor wachtrijen en tabellen. Deze accounts omvatten opslagaccounts met alleen blob en Azure Premium Storage. Zie het overzicht van opslagaccounts voor meer informatie over typen opslagaccounts.

  • U kunt geen met een netwerk beveiligd opslagaccount gebruiken wanneer uw functie-app wordt gehost in het verbruiksabonnement.

  • Wanneer u uw functie-app maakt in de portal, kunt u alleen een bestaand opslagaccount kiezen in dezelfde regio als de functie-app die u maakt. Dit is een optimalisatie van prestaties en geen strikte beperking. Zie opslagaccountlocatie voor meer informatie.

  • Wanneer u uw functie-app maakt op een plan waarvoor ondersteuning voor beschikbaarheidszones is ingeschakeld, worden alleen zone-redundante opslagaccounts ondersteund.

Wanneer u implementatieautomatisering gebruikt om uw functie-app te maken met een met het netwerk beveiligd opslagaccount, moet u specifieke netwerkconfiguraties opnemen in uw ARM-sjabloon of Bicep-bestand. Wanneer u deze instellingen en resources niet opneemt, kan uw geautomatiseerde implementatie mislukken tijdens de validatie. Zie Beveiligde implementaties voor specifiekere ARM- en Bicep-richtlijnen. Zie Een beveiligd opslagaccount gebruiken met Azure Functions voor een overzicht van het configureren van opslagaccounts met netwerken.

Richtlijnen voor opslagaccounts

Voor elke functie-app moet een opslagaccount worden uitgevoerd. Wanneer dat account wordt verwijderd, wordt uw functie-app niet uitgevoerd. Als u problemen met betrekking tot opslag wilt oplossen, raadpleegt u Problemen met betrekking tot opslag oplossen. De volgende andere overwegingen zijn van toepassing op het opslagaccount dat wordt gebruikt door functie-apps.

Locatie van opslagaccount

Voor de beste prestaties moet uw functie-app een opslagaccount in dezelfde regio gebruiken, waardoor de latentie wordt verminderd. In Azure Portal wordt deze best practice afgedwongen. Als u om een of andere reden een opslagaccount in een andere regio dan uw functie-app moet gebruiken, moet u uw functie-app buiten de portal maken.

Het opslagaccount moet toegankelijk zijn voor de functie-app. Als u een beveiligd opslagaccount wilt gebruiken, kunt u overwegen uw opslagaccount te beperken tot een virtueel netwerk.

Verbindingsinstelling voor opslagaccount

Functie-apps configureren de AzureWebJobsStorage verbinding standaard als een verbindingsreeks die zijn opgeslagen in de toepassingsinstelling AzureWebJobsStorage, maar u kunt AzureWebJobsStorage ook configureren om een op identiteit gebaseerde verbinding zonder geheim te gebruiken.

Functie-apps die worden uitgevoerd in een verbruiksabonnement (alleen Windows) of een Elastic Premium-abonnement (Windows of Linux) kunnen Azure Files gebruiken om de installatiekopieën op te slaan die nodig zijn om dynamisch schalen mogelijk te maken. Voor deze plannen stelt u de verbindingsreeks in voor het opslagaccount in de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-instelling en de naam van de bestandsshare in de WEBSITE_CONTENTSHARE-instelling. Dit is meestal hetzelfde account dat wordt gebruikt voor AzureWebJobsStorage. U kunt ook een functie-app maken die geen gebruik maakt van Azure Files, maar het schalen is mogelijk beperkt.

Notitie

Een opslagaccount verbindingsreeks moet worden bijgewerkt wanneer u opslagsleutels opnieuw genereert. Lees hier meer over opslagsleutelbeheer.

Gedeelde opslagaccounts

Het is mogelijk dat meerdere functie-apps hetzelfde opslagaccount delen zonder problemen. In Visual Studio kunt u bijvoorbeeld meerdere apps ontwikkelen met behulp van de Emulator voor opslag van Azurite. 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 benadering is echter niet altijd een goed idee in een productieomgeving.

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

Overwegingen voor levenscyclusbeheerbeleid

U moet geen beleid voor levenscyclusbeheer toepassen op uw Blob Storage-account dat wordt gebruikt door uw functie-app. Functions maakt gebruik van Blob Storage om belangrijke informatie te behouden, zoals functietoegangssleutels, en beleidsregels kunnen blobs (zoals sleutels) verwijderen die nodig zijn voor de Functions-host. Als u beleidsregels moet gebruiken, sluit u containers uit die worden gebruikt door Functions. Deze worden voorafgegaan door azure-webjobs of scm.

Opslaglogboeken

Omdat functiecode en sleutels mogelijk worden bewaard in het opslagaccount, is logboekregistratie van activiteiten voor het opslagaccount een goede manier om te controleren op onbevoegde toegang. Azure Monitor-resourcelogboeken kunnen worden gebruikt voor het bijhouden van gebeurtenissen op het gegevensvlak van de opslag. Zie Bewaking van Azure Storage voor meer informatie over het configureren en onderzoeken van deze logboeken.

In het Activiteitenlogboek van Azure Monitor worden gebeurtenissen van het besturingsvlak weergegeven, waaronder de bewerking listKeys. U moet echter ook resourcelogboeken configureren voor het opslagaccount om het volgende gebruik van sleutels of andere op identiteit gebaseerde gegevensvlakbewerkingen bij te houden. U moet ten minste de storageWrite-logboekcategorie hebben ingeschakeld om wijzigingen in de gegevens buiten normale Functies-bewerkingen te kunnen identificeren.

Als u de mogelijke impact van eventuele opslagmachtigingen binnen het bereik wilt beperken, kunt u overwegen om een niet-opslagbestemming te gebruiken voor deze logboeken, zoals Log Analytics. Zie Azure Blob Storage bewaken voor meer informatie.

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 andere voor de blobs die door de functie worden opgeslagen.

Consistente routering via virtuele netwerken

Meerdere functie-apps die in hetzelfde abonnement worden gehost, kunnen ook hetzelfde opslagaccount gebruiken voor de Azure Files-inhoudsshare (gedefinieerd door WEBSITE_CONTENTAZUREFILECONNECTIONSTRING). Wanneer dit opslagaccount ook wordt beveiligd door een virtueel netwerk, moeten al deze apps ook dezelfde waarde voor vnetContentShareEnabled (voorheen WEBSITE_CONTENTOVERVNET) gebruiken om ervoor te zorgen dat verkeer consistent wordt gerouteerd via het beoogde virtuele netwerk. Een onjuiste overeenkomst in deze instelling tussen apps die hetzelfde Azure Files-opslagaccount gebruiken, kan ertoe leiden dat verkeer wordt gerouteerd via openbare netwerken, waardoor de toegang wordt geblokkeerd door netwerkregels voor het opslagaccount.

Werken met blobs

Een belangrijk scenario voor Functions is bestandsverwerking van bestanden in een blobcontainer, zoals voor afbeeldingsverwerking of sentimentanalyse. Zie Uploads van procesbestanden voor meer informatie.

Trigger op een blobcontainer

Er zijn verschillende manieren om uw functiecode uit te voeren op basis van wijzigingen in blobs in een opslagcontainer. Gebruik de volgende tabel om te bepalen welke functietrigger het beste past bij uw behoeften:

Strategie Container (polling) Container (gebeurtenissen) Wachtrijtrigger Event Grid
Latentie Hoog (maximaal 10 minuten) Beperkt Gemiddeld Beperkt
Beperkingen voor opslagaccounts Accounts met alleen blobs worden niet ondersteund¹ algemeen gebruik v1 wordt niet ondersteund Geen algemeen gebruik v1 wordt niet ondersteund
Triggertype Blob Storage Blob Storage Queue Storage Event Grid
Versie van de extensie Alle Storage v5.x+ Alle Alle
Bestaande blobs verwerkt Ja No Nee Nr.
Filters Blob-naampatroon Gebeurtenisfilters N.v.t. Gebeurtenisfilters
Vereist gebeurtenisabonnement Nr. Ja No Ja
Ondersteunt het Flex Consumption-abonnement Nr. Ja Ja Ja
Ondersteunt grootschalige² Nr. Ja Ja Ja
Beschrijving Standaardtriggergedrag, dat afhankelijk is van het peilen van de container voor updates. Zie de voorbeelden in de naslaginformatie over de Blob Storage-trigger voor meer informatie. Verbruikt blobopslag-gebeurtenissen van een gebeurtenisabonnement. Vereist een Source parameterwaarde van EventGrid. Zie Zelfstudie: Azure Functions activeren voor blobcontainers met behulp van een gebeurtenisabonnement voor meer informatie. De blobnaamtekenreeks wordt handmatig toegevoegd aan een opslagwachtrij wanneer een blob wordt toegevoegd aan de container. Deze waarde wordt rechtstreeks door een Queue Storage-trigger doorgegeven aan een Blob Storage-invoerbinding op dezelfde functie. Biedt de flexibiliteit van het activeren van gebeurtenissen naast gebeurtenissen die afkomstig zijn van een opslagcontainer. Gebruik deze functie wanneer u ook niet-opstaande gebeurtenissen moet activeren. Zie Hoe u werkt met Event Grid-triggers en -bindingen in Azure Functions voor meer informatie.
  1. Blob Storage-invoer- en uitvoerbindingen ondersteunen alleen blob-accounts.
  2. Grote schaal kan losjes worden gedefinieerd als containers met meer dan 100.000 blobs in deze containers of opslagaccounts met meer dan 100 blob-updates per seconde.

Opslaggegevensversleuteling

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

Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor extra controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven voor versleuteling van blob- en bestandsgegevens. Deze sleutels moeten aanwezig zijn in Azure Key Vault voor Functions om toegang te krijgen tot het opslagaccount. Zie Versleuteling-at-rest met behulp van door de klant beheerde sleutels voor meer informatie.

Gegevenslocatie in uw regio

Wanneer alle klantgegevens binnen één regio moeten blijven, moet het opslagaccount dat is gekoppeld aan de functie-app, één 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 in de regio opgeslagen wanneer ze worden gehost in een app-omgeving met interne taakverdeling (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 uniek 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- en traceringsgegevens per app 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 host-id-botsing omdat opgeslagen gegevens niet uniek kunnen worden gekoppeld aan de juiste functie-app.

Notitie

Dit soort host-id-conflict 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 een waarschuwing vastgelegd. In versie 4.x wordt een fout geregistreerd en wordt de host gestopt, wat resulteert in een harde fout. Meer informatie over host-id-botsingen vindt u in dit probleem.

Host-id-conflicten 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 sleuf 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. Met een Blob Storage-trigger wordt bijvoorbeeld bijgehouden of 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 instellen voor uw functie-app in de toepassingsinstellingen met behulp van de AzureFunctionsWebHost__hostid instelling. Zie AzureFunctionsWebHost__hostid voor meer informatie.

Wanneer de botsing tussen sites plaatsvindt, moet u een specifieke host-id instellen voor elke site, inclusief de productiesite. U moet deze instellingen ook markeren als implementatie-instellingen , zodat ze niet worden verwisseld. Zie Werken met toepassingsinstellingen voor meer informatie over het maken van app-instellingen.

Clusters met Azure Arc

Wanneer uw functie-app is geïmplementeerd in een Kubernetes-cluster met Azure Arc, is een opslagaccount mogelijk niet 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. De volgende tabel geeft aan welke triggers mogelijk een opslagaccount vereisen en welke niet.

Niet vereist vereist mogelijk opslag
• 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 is.

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

De Azure Files-service biedt een gedeeld bestandssysteem dat ondersteuning biedt voor grootschalige scenario's. Wanneer uw functie-app wordt uitgevoerd in Windows in een Elastic Premium- of Consumption-abonnement, wordt er standaard een Azure Files-share gemaakt in uw opslagaccount. Deze share wordt door Functions gebruikt om bepaalde functies, zoals logboekstreaming, in te schakelen. Het wordt ook gebruikt als een locatie voor gedeelde pakketimplementatie, die de consistentie van uw geïmplementeerde functiecode garandeert voor alle exemplaren.

Standaard gebruiken functie-apps die worden gehost in Premium- en Verbruiksabonnementen zip-implementatie, met implementatiepakketten die zijn opgeslagen in deze Azure-bestandsshare. Deze sectie is alleen relevant voor deze hostingabonnementen.

Voor het gebruik van Azure Files is het gebruik van een verbindingsreeks vereist, die is opgeslagen in uw app-instellingen als WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files biedt momenteel geen ondersteuning voor op identiteit gebaseerde verbindingen. Als uw scenario vereist dat u geen geheimen opslaat in app-instellingen, moet u de afhankelijkheid van uw app op Azure Files verwijderen. U kunt dit doen door uw app te maken zonder de standaardafhankelijkheid van Azure Files.

Notitie

U moet ook overwegen om te worden uitgevoerd in uw functie-app in het Flex Consumption-abonnement, dat momenteel in preview is. Het Flex Consumption-abonnement biedt meer controle over het implementatiepakket, inclusief de mogelijkheid om beheerde identiteitverbindingen te gebruiken. Zie Implementatie-instellingen configureren in het artikel Flex consumption voor meer informatie.

Als u uw app wilt uitvoeren zonder de Azure-bestandsshare, moet u voldoen aan de volgende vereisten:

U bent verantwoordelijk voor het handmatig bijwerken van het implementatiepakket en het onderhouden van de URL van het implementatiepakket, die waarschijnlijk een SAS (Shared Access Signature) bevat.

  • Uw app kan niet vertrouwen op een gedeeld beschrijfbaar bestandssysteem.
  • De app kan versie 1.x van de Functions-runtime niet gebruiken.
  • Logboekstreamingervaringen in clients zoals azure Portal zijn standaard ingesteld op bestandssysteemlogboeken. U moet in plaats daarvan afhankelijk zijn van Application Insights-logboeken.

Als de bovenstaande vereisten geschikt zijn voor uw scenario, kunt u doorgaan met het maken van een functie-app zonder Azure Files. U kunt dit doen door een app te maken zonder de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING en WEBSITE_CONTENTSHARE app-instellingen. Als u wilt beginnen, genereert u een ARM-sjabloon voor een standaardimplementatie, verwijdert u de twee instellingen en implementeert u vervolgens de gewijzigde sjabloon.

Omdat Azure Files wordt gebruikt om dynamische uitschalen voor Functions in te schakelen, kan schalen beperkt zijn bij het uitvoeren van uw app zonder Azure Files in het Elastic Premium-abonnement en verbruiksabonnementen die worden uitgevoerd in Windows.

Bestandsshares koppelen

Deze functionaliteit is alleen actueel wanneer deze wordt uitgevoerd op 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 dit 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 kan 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 of AzureFiles meer 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 hebt /path/to/mountu bijvoorbeeld mount-path toegang tot de doelmap op 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.

Schaal en hosting van Azure Functions