Begränsningar och konfigurationsreferens för Azure Logic Apps

För arbetsflöden för förbrukningslogikapp styr samma inställning det maximala antalet dagar som ett arbetsflöde kan köras och för att hålla körningshistoriken i lagringen.

• I Azure Logic Apps med flera klientorganisationer är standardgränsen på 90 dagar samma som maxgränsen. Du kan bara minska det här värdet.

Anta till exempel att du minskar kvarhållningsgränsen från 90 dagar till 30 dagar. En 60 dagar gammal körning tas bort från körningshistoriken. Om du ökar kvarhållningsperioden från 30 dagar till 60 dagar stannar en 20 dagar gammal körning i körningshistoriken i ytterligare 40 dagar.

Portalen

1. I sökrutan Azure Portal öppnar du logikappens arbetsflöde i designern.

2. På logikappmenyn väljer du Arbetsflödesinställningar.

3. Under Körningsalternativ går du till listan Kör historikkvarhållning i dagar och väljer Anpassad.

4. Dra skjutreglaget om du vill ändra det antal dagar du vill ha.

5. När du är klar väljer du Spara i verktygsfältet Arbetsflödesinställningar.

ARM-mall

Om du använder en Azure Resource Manager-mall visas den här inställningen som en egenskap i arbetsflödets resursdefinition, som beskrivs i mallreferensen för Microsoft.Logic-arbetsflöden:

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

För standardarbetsflöden för logikappar kan du minska eller öka standardgränsen på 90 dagar, men du måste lägga till följande inställningar och deras värden i logikappens resurs eller projekt:

• En appinställning med namnet Workflows.RuntimeConfiguration.RetentionInDays

• En värdinställning med namnet Runtime.FlowMaintenanceJob.RetentionCooldownInterval

Som standard är appinställningen Workflows.RuntimeConfiguration.RetentionInDays inställd på att behålla 90 dagars data. Värdinställningen Runtime.FlowMaintenanceJob.RetentionCooldownInterval är inställd på att kontrollera var sjunde dag att gamla data ska tas bort. Om du lämnar dessa standardvärden kan du se data upp till 97 dagar gamla. Anta till exempel att Azure Logic Apps kontrollerar dag X och tar bort data som är äldre än dag X – 90 dagar och sedan väntar i 7 dagar innan de körs igen. Det här beteendet resulterar i data som åldras upp till 97 dagar innan jobbet körs igen. Men om du anger intervallet till 1 dag, men lämnar kvarhållningsdagarna som standardvärde, är den maximala fördröjningen för att ta bort gamla data 90+1 dagar.

Portalen

1. Följ de här stegen om du vill lägga till appinställningen Workflows.RuntimeConfiguration.RetentionInDays och ange värdet till det antal dagar som du vill behålla arbetsflödets körningshistorik.

2. Följ de här stegen för att lägga till värdinställningen Runtime.FlowMaintenanceJob.RetentionCooldownInterval och ange värdet till det antal dagar som intervallet mellan när du ska söka efter och ta bort körningshistoriken som du inte vill behålla.

Visual Studio-koden

1. Följ de här stegen om du vill lägga till appinställningen Workflows.RuntimeConfiguration.RetentionInDays och ange värdet till det antal dagar som du vill behålla arbetsflödets körningshistorik.

2. Följ de här stegen för att lägga till värdinställningen Runtime.FlowMaintenanceJob.RetentionCooldownInterval och ange värdet till det antal dagar som intervallet mellan när du ska söka efter och ta bort körningshistoriken som du inte vill behålla.

I Azure Logic Apps för en enda klient använder en standardlogikappresurs lagring och beräkning som primära resurser för att köra arbetsflöden.

Storage

Tillståndskänsliga arbetsflöden i Azure Logic Apps med en enda klientorganisation använder Azure Table Storage för beständiga datalagring under körning, Azure Blob Storage för att underhålla arbetsflödeskörningshistorik och Azure Queue Storage i schemaläggningssyfte. Ett enda lagringskonto gör det till exempel möjligt att hantera ett stort antal begäranden med priser på upp till 2 000 begäranden per partition och 20 000 begäranden per sekund på lagringskontonivå. Ett enda lagringskonto kan hantera relativt högt dataflöde, men utöver dessa tröskelvärden kan begärandefrekvenser begränsas, och dina arbetsflöden kan uppleva begränsning på partitionsnivå eller begränsning på kontonivå när arbetsflödets körningshastighet ökar. För att säkerställa att dina arbetsflöden fungerar smidigt är det viktigt att du förstår de möjliga begränsningarna och hur du kan åtgärda dem.

Mer information om skalningsmål och begränsningar för de olika Azure Storage-tjänsterna finns i följande dokumentation:

• Skalningsmål för Table Storage
• Dataåtgärdsmål för Table Storage
• Skalningsmål för Blob Storage
• Skalningsmål för kölagring

Skala logikappen för lagringsbegränsningar

Följande rekommendationer gäller för skalning av standardarbetsflöden för logikappar:

• Dela arbetsbelastning över flera arbetsflöden.

  Azure Logic Apps med en klientorganisation minimerar redan begränsning på partitionsnivå genom att distribuera lagringstransaktioner över flera partitioner. Men för att förbättra distributionen och minska begränsningen på partitionsnivå distribuerar du arbetsbelastningen över flera arbetsflöden i stället för att förlita dig på ett enda arbetsflöde.

• Dela arbetsbelastning över flera lagringskonton.

  Om dina arbetsflöden kräver högt dataflöde kan du avsevärt öka dataflödet genom att distribuera arbetsbelastningen över flera lagringskonton i stället för att förlita dig på ett enda lagringskonto. Du kan konfigurera standardlogikappresursen så att upp till 32 lagringskonton används som gräns. För att fastställa antalet lagringskonton som du behöver använder du den allmänna riktlinjen för att sikta på ~100 000 åtgärdskörningar per minut, per lagringskonto. Även om den här uppskattningen fungerar bra för de flesta scenarier kan du använda ett lägre antal åtgärdskörningar om dina arbetsflödesåtgärder är beräkningsintensiva, till exempel en frågeåtgärd som bearbetar stora datamatriser. Kontrollera att du utför belastningstestning och finjusterar lösningen innan du använder den i produktion.

  Om du vill aktivera med flera lagringskonton följer du de här stegen innan du skapar standardlogikappen. Om du ändrar inställningarna när du har skapat dem kan det hända att data går förlorade eller inte uppnår den skalbarhet som krävs.

  1. Skapa de lagringskonton som du vill använda. Spara anslutningssträng för varje lagringskonto.

  2. Leta upp och öppna standardlogikappen och redigera sedan logikappens värdinställningar (host.json fil) för att inkludera följande extensions objekt, som innehåller objekten workflow och settings med inställningen Runtime.ScaleUnitsCount :

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     I följande exempel anges 3 som antal lagringskonton:

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. Redigera logikappens programkonfigurationsinställningar (local.settings.json) för att lägga till en appinställning med namnet CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number>. ConnectionString och motsvarande lagringskonto anslutningssträng med hjälp av följande syntax där det första lagringskontonumret är 00 upp till antalet lagringskonton minus 1, till exempel:

     Namn på appinställning	Värde
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     Viktigt!

     När du har känslig information, till exempel anslutningssträng som innehåller användarnamn och lösenord, bör du använda det säkraste tillgängliga autentiseringsflödet. I standardarbetsflöden för logikappar stöds till exempel inte säkra datatyper, till exempel securestring och secureobject. Microsoft rekommenderar att du autentiserar åtkomst till Azure-resurser med en hanterad identitet när det är möjligt och tilldelar en roll som har minsta möjliga behörighet.

     Om den här funktionen inte är tillgänglig måste du skydda anslutningssträng via andra mått, till exempel Azure Key Vault, som du kan använda med appinställningar. Du kan sedan direkt referera till säkra strängar, till exempel anslutningssträng och nycklar. På samma sätt som ARM-mallar, där du kan definiera miljövariabler vid distributionen, kan du definiera appinställningar i logikappens arbetsflödesdefinition. Du kan sedan samla in dynamiskt genererade infrastrukturvärden, till exempel anslutningsslutpunkter, lagringssträngar med mera. Mer information finns i Programtyper för Microsofts identitetsplattform.

  4. I konfigurationsinställningarna för logikappen uppdaterar du inställningsvärdet AzureWebJobsStorage med samma anslutningssträng som finns i inställningen CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString.

Compute

En standardlogikapp körs med hjälp av en av de tillgängliga beräkningsplanerna, som ger olika nivåer av virtuell processor och minne, eller med hjälp av en App Service-miljön v3, som ger fler beräkningsalternativ.

Azure Logic Apps för en klientorganisation skalas dynamiskt för att effektivt hantera ökande belastningar. Logikappen använder följande primära faktorer för att avgöra om skalning ska skalas.

• Utlösare

  För att fastställa skalningskrav analyserar skalningsappen utlösaren som startar varje arbetsflöde i logikappen. Om kölängden växer kontinuerligt för ett arbetsflöde med en Service Bus-utlösare vidtar skalningsaren åtgärder för att lägga till arbetsinstanser, vilket gör det möjligt att bearbeta fler meddelanden. På samma sätt ökar skalningsaren antalet arbetsinstanser för att distribuera begärandebelastningen effektivare om svarstiden för begäranden upplever en uppåtgående trend. Mer information om arbetsinstanser finns i Azure Logic Apps (Standard) – Runtime Deep Dive.

• Fördröjning av arbetsflödesjobbkörning

  Vid körning delas arbetsflödesåtgärder in i enskilda jobb som placeras i kö för körning. Jobbutskickare avsöker regelbundet jobbkön för att hämta och köra dessa jobb. Men om beräkningskapaciteten inte räcker till för att hämta de här jobben stannar de i kön under en längre tid, vilket resulterar i ökade körningsfördröjningar. Skalningskontrollen övervakar den här situationen och fattar skalningsbeslut för att hålla körningsfördröjningarna under kontroll. Mer information om hur körningen schemalägger och kör jobb finns i Azure Logic Apps (Standard) – Runtime Deep Dive.

  Skalningsappen tar också hänsyn till den lägsta och högsta arbetsinstansens räknare för att avgöra om skalningsbeslut ska fattas, till exempel lägga till, ta bort eller underhålla det aktuella antalet arbetsinstanser. Vanligtvis fattar skalningsaren dessa beslut med intervall på cirka 15–30 sekunder. Tänk därför på den här upptrappningstiden och dess inverkan på logikappens skalningshastighet för att effektivt hantera belastningstoppar. Om din arbetsbelastning till exempel kräver skalning av logikappen från bara 1 arbetsinstans till 100 arbetsinstanser, kan det ta 25–50 minuter att bara rampa upp. Azure Logic Apps-skalning med en klientorganisation delar samma Azure Functions-skalningsinfrastruktur.

Konfigurera logikappens beräkning för snabbare skalning

• Dela arbetsbelastning över flera logikappar.

  Varje logikapp kan skalas separat, så att distribuera din arbetsbelastning över mer än en logikapp kan avsevärt påskynda skalningshastigheten. Två logikappar kan till exempel skalas till dubbelt så många arbetsinstanser inom samma tidsram som en enda logikapp. Genom att dela upp arbetsbelastningen mellan flera appar kan du effektivt multiplicera skalbarheten och uppnå snabbare skalningsresultat.

• Använd förinställda instanser.

  Om ditt scenario kräver snabbare upprampningstid bör du överväga att använda förvärmade instanser. Om de högsta inläsningstiderna är deterministiska kan du använda en automatiseringsaktivitet för att justera dessa förkrigsinstanser enligt ett schema. Mer information finns i Hantera Azure-resurser och övervaka kostnader genom att skapa automatiseringsuppgifter (förhandsversion).

Azure Logic Apps med flera klientorganisationer har en standardgräns för antalet åtgärder som körs var 5:e minut. Om du vill höja standardvärdet till det maximala värdet kan du aktivera läget för högt dataflöde, som är i förhandsversion. Du kan också distribuera arbetsbelastningen över flera logikappar och arbetsflöden i stället för att förlita dig på en enda logikapp och ett enda arbetsflöde.

Aktivera högt dataflöde i portalen

1. I Azure Portal går du till logikappens meny och väljer Arbetsflödesinställningar under Inställningar.

2. Under Körningsalternativ>Högt dataflöde ändrar du inställningen till På.

   

Aktivera högt dataflöde i en Resource Manager-mall

Om du vill aktivera den här inställningen i en ARM-mall för att distribuera logikappen properties lägger du till objektet med operationOptions egenskapen inställd OptimizedForHighThroughputpå : i objektet för logikappens runtimeConfiguration resursdefinition:

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

Mer information om resursdefinitionen för logikappen finns i Översikt: Automatisera distribution för Azure Logic Apps med hjälp av Azure Resource Manager-mallar.