Lagringsöverväganden för Azure Functions

När du skapar en funktionsappinstans i Azure måste du ge åtkomst till ett standardkonto för Azure Storage. Det här diagrammet och den efterföljande tabellen beskriver hur Azure Functions använder tjänster i standardlagringskontot:

1. Blob Storage är standardlagringsplatsen för funktionsnycklar, men du kan konfigurera ett alternativt arkiv.
2. Azure Files är konfigurerat som standard, men du kan skapa en app utan Azure Files under vissa förhållanden.

Viktigt!

Du måste tänka igenom följande fakta om de lagringskonton som används av dina funktionsappar:

• När din funktionsapp finns i förbrukningsplanen eller Premium-planen lagras funktionskoden och konfigurationsfilerna i Azure Files i det länkade lagringskontot. När du tar bort det här lagringskontot tas innehållet bort och kan inte återställas. Mer information finns i Lagringskontot har tagits bort.

• Viktiga data, till exempel funktionskod, åtkomstnycklar och andra viktiga tjänstrelaterade data, kan sparas i lagringskontot. Du måste noggrant hantera åtkomsten till de lagringskonton som används av funktionsappar på följande sätt:

  • Granska och begränsa åtkomsten för appar och användare till lagringskontot baserat på en modell med lägsta behörighet. Behörigheter till lagringskontot kan komma från dataåtgärder i den tilldelade rollen eller via behörighet att utföra åtgärden listKeys.

  • Övervaka både kontrollplansaktivitet (till exempel hämtning av nycklar) och dataplansåtgärder (till exempel att skriva till en blob) i ditt lagringskonto. Överväg att underhålla lagringsloggar på en annan plats än Azure Storage. Mer information finns i Lagringsloggar.

Krav för Storage-konto

Lagringskonton som skapats som en del av funktionsappens create-flöde i Azure-portalen fungerar med den nya funktionsappen. När du väljer att använda ett befintligt lagringskonto innehåller den angivna listan inte vissa lagringskonton som inte stöds. Följande begränsningar gäller för lagringskonton som används av funktionsappen. Kontrollera att ett befintligt lagringskonto uppfyller följande krav:

• Kontotypen måste ha stöd för blob-, kö- och tabelllagring. Vissa lagringskonton stöder inte köer och tabeller. Det gäller till exempel lagringskonton med endast bloblagring och Azure Premium Storage. Mer information om lagringskontotyper finns i Översikt över lagringskonto.

• Du kan inte använda ett nätverksskyddat lagringskonto när din funktionsapp finns i förbrukningsplanen.

• När du skapar din funktionsapp i Azure-portalen får du bara välja ett befintligt lagringskonto i samma region som den funktionsapp som du skapar. Det här kravet är en prestandaoptimering och inte en strikt begränsning. Mer information finns i Lagringskontots plats.

• När du skapar din funktionsapp i en plan med stöd för tillgänglighetszoner aktiverat stöds endast zonredundanta lagringskonton .

När du använder distributionsautomatisering för att skapa din funktionsapp med ett nätverksskyddat lagringskonto måste du inkludera specifika nätverkskonfigurationer i ARM-mallen eller Bicep-filen. När du inte inkluderar de här inställningarna och resurserna kan den automatiserade distributionen misslyckas i valideringen. Arm-mall och Bicep-vägledning finns i Säkra distributioner. En översikt över hur du konfigurerar lagringskonton med nätverk finns i Använda ett skyddat lagringskonto med Azure Functions.

Vägledning för lagringskonto

Varje funktionsapp kräver ett lagringskonto för att fungera. När kontot tas bort körs inte längre funktionsappen. Information om hur du felsöker lagringsrelaterade problem finns i Så här felsöker du lagringsrelaterade problem. Följande andra överväganden gäller för lagringskontot som används av funktionsappar.

Lagringskontoplats

För bästa prestanda bör din funktionsapp använda ett lagringskonto i samma region, vilket minskar svarstiden. Den Azure Portal tillämpar den här bästa metoden. Om du av någon anledning behöver använda ett lagringskonto i en annan region än din funktionsapp måste du skapa funktionsappen utanför Azure-portalen.

Lagringskontot måste vara tillgängligt för funktionsappen. Om du behöver använda ett skyddat lagringskonto bör du överväga att begränsa ditt lagringskonto till ett virtuellt nätverk.

Inställning för lagringskontoanslutning

Som standard konfigurerar AzureWebJobsStorage funktionsappar anslutningen som en anslutningssträng som lagras i programinställningen AzureWebJobsStorage, men du kan också konfigurera AzureWebJobsStorage att använda en identitetsbaserad anslutning utan hemlighet.

Funktionsappar som körs i en förbrukningsplan (endast Windows) eller en Elastic Premium-plan (Windows eller Linux) kan använda Azure Files för att lagra de avbildningar som krävs för att aktivera dynamisk skalning. För dessa planer anger du anslutningssträng för lagringskontot i inställningen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING och namnet på filresursen i inställningen WEBSITE_CONTENTSHARE. Det här värdet är vanligtvis samma konto som används för AzureWebJobsStorage. Du kan också skapa en funktionsapp som inte använder Azure Files, men skalningen kan vara begränsad.

Delade lagringskonton

Det är möjligt för flera funktionsappar att dela samma lagringskonto utan problem. I Visual Studio kan du till exempel utveckla flera appar med hjälp av Azurite Storage-emulatorn. I det här fallet fungerar emulatorn som ett enda lagringskonto. Samma lagringskonto som används av funktionsappen kan också användas för att lagra dina programdata. Den här metoden är dock inte alltid en bra idé i en produktionsmiljö.

Du kan behöva använda separata lagringskonton för att undvika kollisioner med värd-ID.

Principöverväganden för livscykelhantering

Du bör inte tillämpa livscykelhanteringsprinciper på ditt Blob Storage-konto som används av funktionsappen. Functions använder Blob Storage för att spara viktig information, till exempel åtkomstnycklar för funktioner. Policyer kan ta bort blobar, till exempel nycklar, som krävs av Functions-värden. Om du måste använda principer undantar du containrar som används av Functions, som är prefix med azure-webjobs eller scm.

Lagringsloggar

Eftersom funktionskod och nycklar kan sparas i lagringskontot är loggning av aktivitet mot lagringskontot ett bra sätt att övervaka obehörig åtkomst. Azure Monitor-resursloggar kan användas för att spåra händelser mot lagringsdataplanet. Mer information om hur du konfigurerar och undersöker loggarna finns i Övervaka Azure Storage .

Aktivitetsloggen för Azure Monitor visar kontrollplanshändelser, inklusive listKeys-åtgärden. Du bör dock även konfigurera resursloggar för lagringskontot för att spåra efterföljande användning av nycklar eller andra identitetsbaserade dataplansåtgärder. Du bör ha minst logkategorin StorageWrite aktiverad för att kunna identifiera ändringar av data utanför normala Functions-åtgärder.

Om du vill begränsa den potentiella effekten av alla brett begränsade lagringsbehörigheter bör du överväga att använda ett icke-lagringsmål för dessa loggar, till exempel Log Analytics. Mer information finns i Övervaka Azure Blob Storage.

Optimera lagringsprestanda

Använd ett separat lagringskonto för varje funktionsapp för att maximera prestandan. Den här metoden är särskilt viktig när du har Durable Functions- eller Event Hubs-utlösta funktioner, som båda genererar en stor mängd lagringstransaktioner. När din programlogik interagerar med Azure Storage, antingen direkt (med hjälp av Storage SDK) eller via någon av lagringsbindningarna, bör du använda ett dedikerat lagringskonto. Om du har till exempel en funktion utlöst av en händelsehub som skriver data till bloblagring, använd två lagringskonton: ett för funktionsappen och ett annat för de blobbar som funktionen lagrar.

Konsekvent routning via virtuella nätverk

Flera funktionsappar som finns i samma plan kan också använda samma lagringskonto för Azure Files-innehållsresursen, som definieras av WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. När det här lagringskontot också är säkrat av ett virtuellt nätverk, bör alla dessa appar också använda samma värde för vnetContentShareEnabled (tidigare WEBSITE_CONTENTOVERVNET) för att säkerställa att trafiken dirigeras konsekvent via det avsedda virtuella nätverket. Ett matchningsfel i den här inställningen mellan appar som använder samma Azure Files-lagringskonto kan leda till att trafik dirigeras via offentliga nätverk. I den här konfigurationen blockerar lagringskontots nätverksregler åtkomst.

Arbeta med blobar

Ett nyckelscenario för Functions är filbearbetning av filer i en blobcontainer, till exempel för bildbearbetning eller attitydanalys. Mer information finns i Bearbeta filuppladdningar.

Utlösare för en blobcontainer

Det finns flera sätt att köra funktionskoden baserat på ändringar i blobar i en lagringscontainer, vilket anges i det här diagrammet:

Använd följande tabell för att avgöra vilken funktionsutlösare som bäst passar dina behov för bearbetning av tillagda eller uppdaterade blobar i en container:

1. Blob Storage-indata- och utdatabindningar stöder endast blob-konton.
2. Hög skala kan definieras löst som containrar som har mer än 100 000 blobar i sig eller lagringskonton som har mer än 100 blobuppdateringar per sekund.
3. Du kan kringgå begränsningar för inkommande åtkomst genom att låta händelseprenumerationen leverera händelser via en krypterad kanal i offentligt IP-utrymme med hjälp av en känd användaridentitet. Mer information finns i Leverera händelser på ett säkert sätt med hanterade identiteter.

Kryptering av lagringsdata

Azure Storage krypterar alla data i ett lagringskonto i vila. För mer information, se Azure Storage-kryptering för vilande data.

Som standard krypteras data med Microsoft-hanterade nycklar. Om du vill ha mer kontroll över krypteringsnycklar kan du ange kundhanterade nycklar som ska användas för kryptering av blob- och fildata. Dessa nycklar måste finnas i Azure Key Vault för att Functions ska kunna komma åt lagringskontot. Mer information finns i Kryptera dina programdata i vila med hjälp av kundhanterade nycklar.

Datahemvist i regionen

När alla kunddata måste finnas kvar i en enda region måste lagringskontot som är associerat med funktionsappen vara ett med redundans i regionen. Ett redundant lagringskonto i regionen måste också användas med Azure Durable Functions.

Andra plattformshanterade kunddata lagras endast i regionen när du är värd för en internt belastningsutjämnad App Service-miljön (ASE). Mer information finns i ASE-zonredundans.

Överväganden för värd-ID

Functions använder ett värd-ID-värde som ett sätt att unikt identifiera en viss funktionsapp i lagrade artefakter. Som standard genereras detta ID automatiskt från namnet på funktionsappen, trunkerat till de första 32 tecknen. Det här ID:t används sedan vid lagring av korrelations- och spårningsinformation per app i det länkade lagringskontot. När du har funktionsappar med namn som är längre än 32 tecken och när de första 32 tecknen är identiska kan den här trunkeringen resultera i duplicerade värd-ID-värden. När två funktionsappar med identiska värd-ID:er använder samma lagringskonto får du en värd-ID-kollision eftersom lagrade data inte kan länkas unikt till rätt funktionsapp.

Från och med version 3.x av Functions-körningen identifieras en kollision mellan värd-ID och en varning loggas. I version 4.x loggas ett fel och värden stoppas, vilket resulterar i ett hårt fel. Mer information finns i HostID Truncation kan orsaka kollisioner.

Undvika kollisioner med värd-ID

Du kan använda följande strategier för att undvika kollisioner med värd-ID:

• Använd ett separat lagringskonto för varje funktionsapp eller fack som ingår i kollisionen.
• Byt namn på en av dina funktionsappar till ett värde som är mindre än 32 tecken långt, vilket ändrar det beräknade värd-ID:t för appen och tar bort kollisionen.
• Ange ett explicit värd-ID för en eller flera av de kolliderande apparna. Mer information finns i Åsidosätt värd-ID:t.

Åsidosätt värd-ID:t

Du kan uttryckligen ange ett specifikt värd-ID för funktionsappen i programinställningarna med hjälp av inställningen AzureFunctionsWebHost__hostid . Mer information finns i AzureFunctionsWebHost__hostid.

När kollisionen inträffar mellan platser måste du ange ett specifikt värd-ID för varje fack, inklusive produktionsplatsen. Du måste också markera de här inställningarna som distributionsinställningar så att de inte byts ut. Information om hur du skapar appinställningar finns i Arbeta med programinställningar.

Azure Arc-aktiverade kluster

När din funktionsapp distribueras till ett Azure Arc-aktiverat Kubernetes-kluster kanske din funktionsapp inte kräver något lagringskonto. I det här fallet kräver funktioner bara ett lagringskonto när funktionsappen använder en utlösare som kräver lagring. Följande tabell anger vilka utlösare som kan kräva ett lagringskonto och vilka som inte gör det.

Om du vill skapa en funktionsapp i ett Azure Arc-aktiverat Kubernetes-kluster utan lagring måste du använda Azure CLI-kommandot az functionapp create. Versionen av Azure CLI måste innehålla version 0.1.7 eller en senare version av appservice-kube-tillägget. az --version Använd kommandot för att kontrollera att tillägget är installerat och att det är rätt version.

För att skapa dina funktionsappresurser med andra metoder än Azure CLI krävs ett befintligt lagringskonto. Om du planerar att använda utlösare som kräver ett lagringskonto bör du skapa kontot innan du skapar funktionsappen.

Skapa en app utan Azure Files

Azure Files-tjänsten tillhandahåller ett delat filsystem som stöder storskaliga scenarier. När din funktionsapp körs i en Elastic Premium-plan eller i Windows i en förbrukningsplan skapas en Azure Files-resurs som standard i ditt lagringskonto. Funktioner som använder den delningen möjliggör vissa funktioner, som loggströmning. Det används också som en distributionsplats för delade paket, vilket garanterar konsekvensen för din distribuerade funktionskod i alla instanser.

Som standard använder funktionsappar som finns i Premium- och förbrukningsplaner zip-distribution, med distributionspaket som lagras i den här Azure-filresursen. Det här avsnittet är endast relevant för dessa värdplaner.

Användning av Azure Files kräver användning av en anslutningssträng, som lagras i appinställningarna som WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files stöder för närvarande inte identitetsbaserade anslutningar. Om ditt scenario kräver att du inte lagrar några hemligheter i appinställningarna måste du ta bort appens beroende av Azure Files. Du kan undvika beroenden genom att skapa din app utan standardberoendet för Azure Files.

Om du vill köra din app utan Azure-filresursen måste du uppfylla följande krav:

• Du måste distribuera paketet till en Azure Blob Storage-fjärrcontainer och sedan ange den URL som ger åtkomst till paketet som WEBSITE_RUN_FROM_PACKAGE appinställning. Med den här metoden kan du lagra ditt appinnehåll i Blob Storage i stället för Azure Files, som stöder hanterade identiteter.

Du måste uppdatera distributionspaketet manuellt och underhålla distributionspaketets URL, som troligen innehåller en signatur för delad åtkomst (SAS).

Du bör också tänka på följande:

• Appen kan inte använda version 1.x av Functions-körningen.
• Din app kan inte förlita sig på ett delat skrivbart filsystem.
• Portalredigering stöds inte.
• Loggströmningsupplevelser i klienter som Azure Portal standard för filsystemloggar. Du bör i stället förlita dig på Application Insights-loggar.

Om ovanstående krav passar ditt scenario kan du fortsätta att skapa en funktionsapp utan Azure Files. Skapa en app utan WEBSITE_CONTENTAZUREFILECONNECTIONSTRING appinställningarna och WEBSITE_CONTENTSHARE på något av följande sätt:

• Bicep/ARM-mallar: Ta bort de två appinställningarna från ARM-mallen eller Bicep-filen och distribuera sedan appen med den ändrade mallen.
• Azure-portalen: avmarkera Lägg till en Azure Files-anslutning på fliken Lagring när du skapar appen i Azure-portalen.

Azure Files används för att aktivera dynamisk utskalning för Functions. Skalning kan begränsas när du kör din app utan Azure Files i Elastic Premium-planen och förbrukningsplanerna som körs i Windows.

Montera filresurser

Den här funktionen är endast tillgänglig när den körs på Linux.

Du kan montera befintliga Azure Files-resurser i dina Linux-funktionsappar. Genom att montera en resurs i din Linux-funktionsapp kan du använda befintliga maskininlärningsmodeller eller andra data i dina funktioner.

Du kan använda följande kommando för att montera en befintlig resurs i din Linux-funktionsapp.

För närvarande stöds endast en storage-type av AzureFiles . Du kan bara montera fem resurser till en viss funktionsapp. Om du monterar en filresurs kan du öka den kalla starttiden med minst 200–300 ms, eller ännu mer när lagringskontot finns i en annan region.

Den monterade resursen är tillgänglig för funktionskoden vid angiven mount-path . När är mount-pathkan du till exempel /path/to/mount komma åt målkatalogen efter filsystem-API:er, som i följande Python-exempel:

import os
...

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

Relaterad artikel

Läs mer om värdalternativ för Azure Functions.