Begränsningar och konfigurationsreferens för Azure Logic Apps

För logikapparbetsflöden för konsumtion styr samma inställning det maximala antalet dagar som ett arbetsflöde kan köras och för att behålla körhistoriken i lagring.

• 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.

• Kvarhållning av körningshistorik beräknas alltid med körningens starttid och kvarhållningsgränsen vid den tidpunkt då körningen startade, inte den aktuella kvarhållningsgränsen.

Portal

1. Öppna arbetsflödet för logikappen i designern i sökrutan i Azure-portalen .

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 template

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.

Kvarhållning av körningshistorik beräknas alltid med körningens starttid och kvarhållningsgränsen vid den tidpunkt då körningen startade, inte den aktuella kvarhållningsgränsen.

Portal

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åndsbaserade arbetsflöden i Azure Logic Apps med enkelsystem använder Azure Table Storage för beständig datalagring under körning, Azure Blob Storage för att bevara arbetsflödeskörningshistorik och Azure Queue Storage för schemaläggningsändamål. 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 enskild klient minskar redan begränsningen på partitionsnivå genom att fördela 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 du behöver strävar du efter att uppnå cirka 100 000 utföranden per minut, per lagringskonto enligt de allmänna riktlinjerna. Ä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.

  För att möjliggöra användning av flera lagringskonton följer du de här stegen innan du skapar din standardlogikapp. 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) så att följande extensions objekt inkluderas, 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 anslutningssträng för lagringskontot 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	Value
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     Important

     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 ska du skydda anslutningssträngar 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ängar 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 Environment v3, som ger fler beräkningsalternativ.

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

• Trigger

  För att fastställa skalningskrav analyserar skalningsappen utlösaren som startar varje arbetsflöde i logikappen. Om kölängden för ett arbetsflöde med en Service Bus-utlösare växer kontinuerligt, vidtar skalaren åtgärder för att lägga till fler arbetsinstanser, vilket möjliggör bearbetning av fler meddelanden. På samma sätt, för ett arbetsflöde med en begärandeutlösare, ökar skalningsmekanismen antalet arbetsinstanser för att hantera belastningen av begäranden mer effektivt om svarstiden för begäranden uppvisar en uppåtgående trend. Mer information om arbetsinstanser finns i Azure Logic Apps (Standard) – Runtime Deep Dive.

• Fördröjning i körning av arbetsflödesjobb

  Under körning delas arbetsflödesåtgärder in i enskilda jobb som placeras i kö för utförande. Uppgiftsutskickare avsöker regelbundet jobbkön för att hämta och utföra dessa jobb. Men om beräkningskapaciteten inte räcker för att hantera de här jobben, stannar de kvar längre i kön, vilket resulterar i ökade exekveringsfördröjningar. Skalern övervakar denna situation och fattar skalningsbeslut för att hålla utförandeförseningarna under kontroll. För mer information om hur körmiljön schemalägger och kör jobb, se Azure Logic Apps (Standard) – Runtime Deep Dive.

  Skalaren tar också hänsyn till den lägsta och högsta arbetsinstansens räknarkonfiguration för att avgöra huruvida skalningsbeslut ska tas, som att lägga till, ta bort eller behålla antalet nuvarande 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 Logic Apps.

  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 uppstartstid bör du överväga att använda förvärmade instanser. Om dina högsta belastningstider är deterministiska kan du använda en automatiseringsuppgift för att justera dessa förberedda instanser 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-portalen 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ög genomströmning i en Resource Manager-mall

Om du vill aktivera den här inställningen i en ARM-mall för att distribuera din logikapp, i objektet för logikappens resursdefinition, lägg till properties-objektet med runtimeConfiguration-egenskapen inställd till operationOptionsOptimizedForHighThroughput.

{
   <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.