Lagringsöverväganden för Azure Functions

Azure Functions kräver ett Azure Storage-konto när du skapar en funktionsappinstans. Följande lagringstjänster kan användas av funktionsappen:

Lagringstjänst Funktionsanvändning
Azure Blob Storage Behåll bindningstillstånd och funktionsnycklar. Används också av aktivitetshubbar i Durable Functions.
Azure Files Filresurs som används för att lagra och köra funktionsappens kod i en förbrukningsplan och en Premium-plan. Azure Files är konfigurerat som standard, men du kan skapa en app utan Azure Files under vissa förhållanden.
Azure Queue Storage Används av aktivitetshubbar i Durable Functions och för fel- och återförsökshantering av specifika Azure Functions utlösare.
Azure Table Storage Används av aktivitetshubbar i Durable Functions.

Viktigt

När du använder värdplanen Consumption/Premium lagras funktionskoden och bindningskonfigurationsfilerna i Azure Files i huvudlagringskontot. När du tar bort huvudlagringskontot tas även det här innehållet bort och kan inte återställas.

Krav för lagringskonto

När du skapar en funktionsapp måste du skapa eller länka till ett allmänt Azure Storage-konto som stöder blob-, kö- och tabellagring. Det här kravet finns eftersom Functions förlitar sig på Azure Storage för åtgärder som att hantera utlösare och logga funktionskörningar. Vissa lagringskonton stöder inte köer och tabeller. Dessa konton omfattar endast bloblagringskonton och Azure Premium Storage.

Mer information om lagringskontotyper finns i Översikt över lagringskonto.

Du kan använda ett befintligt lagringskonto med funktionsappen, men du måste se till att det uppfyller dessa krav. Lagringskonton som skapas som en del av funktionsappens skapandeflöde i Azure Portal garanteras uppfylla dessa krav för lagringskontot. I portalen filtreras konton som inte stöds bort när du väljer ett befintligt lagringskonto när du skapar en funktionsapp. I det här flödet får du bara välja befintliga lagringskonton i samma region som den funktionsapp som du skapar. Mer information finns i Lagringskontots plats.

Vägledning för lagringskonto

Varje funktionsapp kräver ett lagringskonto för att fungera. När kontot tas bort körs inte funktionsappen. Information om hur du felsöker lagringsrelaterade problem finns i Felsöka 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 portalen.

Inställning för lagringskontoanslutning

Anslutningen till lagringskontot upprätthålls i programinställningen AzureWebJobsStorage.

Anslutningssträngen för lagringskontot måste uppdateras när du återskapar lagringsnycklar. Läs mer om hantering av lagringsnycklar här.

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

Funktioner använder Blob Storage för att bevara viktig information, till exempel åtkomstnycklar för funktioner. När du tillämpar en livscykelhanteringsprincip på ditt Blob Storage-konto kan principen ta bort blobar som krävs av Functions-värden. Därför bör du inte tillämpa sådana principer på det lagringskonto som används av Functions. Om du behöver tillämpa en sådan princip måste du komma ihåg att exkludera containrar som används av Functions, som har prefixet azure-webjobs eller scm.

Optimera lagringsprestanda

Använd ett separat lagringskonto för varje funktionsapp för att maximera prestanda. Detta är särskilt viktigt när du har Durable Functions- eller Event Hub-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 en av lagringsbindningarna, bör du använda ett dedikerat lagringskonto. Om du till exempel har en händelsehubbutlöst funktion som skriver vissa data till bloblagring använder du två lagringskonton – ett för funktionsappen och ett annat för de blobar som lagras av funktionen.

Kryptering av lagringsdata

Azure Storage krypterar alla data i ett vilande lagringskonto. Mer information finns i Azure Storage-kryptering för vilande data.

Som standard krypteras data med Microsoft hanterade nycklar. Om du vill ha ytterligare 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 Kryptering i vila med 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 de lagras i 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. Detta ID används sedan vid lagring av korrelations- och spårningsinformation per app i det länkade lagringskontot. Om du har funktionsappar med namn som är längre än 32 tecken och 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.

Anteckning

Samma typ av värd-ID collison kan inträffa mellan en funktionsapp i en produktionsplats och samma funktionsapp på en mellanlagringsplats, när båda platserna använder samma lagringskonto.

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 om kollision med värd-ID finns i det här problemet.

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 är inblandat i kollisionen.
  • Byt namn på en av dina funktionsappar till ett värde som är mindre än 32 tecken långt, vilket ändrar appens beräknade värd-ID och tar bort kollisionen.
  • Ange ett explicit värd-ID för en eller flera av de appar som kolliderar. Mer information finns i Åsidosättning av värd-ID.

Viktigt

Om du ändrar lagringskontot som är associerat med en befintlig funktionsapp eller ändrar appens värd-ID kan det påverka beteendet för befintliga funktioner. En Blob Storage-utlösare spårar till exempel om den bearbetas enskilda blobar genom att skriva kvitton under en specifik värd-ID-sökväg i lagringen. När värd-ID:t ändras eller om du pekar på ett nytt lagringskonto kan tidigare bearbetade blobar bearbetas på nytt.

Åsidosätt värd-ID:t

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

När kollisionen inträffar mellan platser kan du behöva markera den här inställningen som en fackinställning. 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 inte ett lagringskonto krävs av funktionsappen. I det här fallet krävs endast ett lagringskonto av Functions när din funktionsapp 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.

Krävs inte Kan kräva lagring
Azure Cosmos DBHTTPKafkaRabbitMQService Bus Azure SQLBlob StorageEvent GridEvent HubsIoT HubQueue StorageSendGridSignalRTable StorageTimerTwilio

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.

Att skapa dina funktionsappresurser med andra metoder än Azure CLI kräver 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 konfigureras som standard för premium- och icke-Linux-förbrukningsplaner som fungerar som ett delat filsystem i storskaliga scenarier. Filsystemet används av plattformen för vissa funktioner, till exempel loggströmning, men det garanterar främst konsekvens för den distribuerade funktionsnyttolasten. När en app distribueras med hjälp av en extern paket-URL hanteras appinnehållet från ett separat skrivskyddat filsystem. Det innebär att du kan skapa din funktionsapp utan Azure Files. Om du skapar funktionsappen med Azure Files tillhandahålls fortfarande ett skrivbart filsystem. Det här filsystemet kanske dock inte är tillgängligt för alla funktionsappinstanser.

När Azure Files inte används måste du uppfylla följande krav:

  • Du måste distribuera från en extern paket-URL.
  • Din app kan inte förlita sig på ett delat skrivbart filsystem.
  • Appen kan inte använda version 1.x av Functions-körningen.
  • 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 redovisas korrekt kan du skapa appen utan Azure Files. Skapa funktionsappen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING utan att ange programinställningarna och WEBSITE_CONTENTSHARE . Du kan undvika de här inställningarna genom att generera en ARM-mall för en standarddistribution, ta bort de två inställningarna och sedan distribuera mallen.

Eftersom Functions använder Azure Files under delar av den dynamiska utskalningsprocessen kan skalning begränsas vid körning utan Azure Files i förbruknings- och Premium-planer.

Montera filresurser

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

Du kan montera befintliga Azure Files resurser till 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 till din Linux-funktionsapp.

az webapp config storage-account add

I det här kommandot share-name är namnet på den befintliga Azure Files resursen och custom-id kan vara valfri sträng som unikt definierar resursen när den monteras på funktionsappen. mount-path Är också sökvägen som resursen nås från i funktionsappen. mount-path måste vara i formatet /dir-nameoch det kan inte börja med /home.

Ett fullständigt exempel finns i skripten i Skapa en Python-funktionsapp och montera en Azure Files resurs.

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 starttiden för kallstart öka 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 /path/to/mountkan du till exempel mount-path komma åt målkatalogen efter filsystem-API:er, som i följande Python-exempel:

import os
...

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

Nästa steg

Läs mer om Azure Functions värdalternativ.