Skapa replikeringsuppgifter för Azure-resurser med hjälp av Azure Logic Apps (förhandsversion)
Viktigt!
Den här funktionen är i förhandsversion och omfattas av kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.
Maximal tillgänglighet och tillförlitlighet är de främsta operativa prioriteringarna för Azure-tjänster, men det finns fortfarande många sätt för kommunikation att stoppas på grund av problem med nätverks- eller namnmatchning, fel eller tillfällig responsivitet. Sådana villkor är inte "katastrofala" så att du vill överge den regionala distributionen helt och hållet som du kan göra i haveriberedskapssituation. Affärsscenariot för vissa appar kan dock påverkas av tillgänglighetshändelser som inte varar längre än några minuter eller till och med sekunder.
För att minska den effekt som oförutsägbara händelser kan ha på dina Azure-resurser i en Azure-region kan du replikera innehållet i dessa resurser från en region till en annan region så att du kan upprätthålla affärskontinuitet. I Azure kan du skapa en replikeringsaktivitet som flyttar data, händelser eller meddelanden från en källa i en region till ett mål i en annan region. På så sätt kan du ha målet lättillgängligt om källan går offline och målet måste ta över.
Kommentar
Du kan också använda replikeringsuppgifter för att flytta innehåll mellan entiteter i samma region, men om hela regionen blir otillgänglig eller upplever avbrott påverkas både källa och mål.
Den här artikeln innehåller en översikt över replikeringsuppgifter som drivs av Azure Logic Apps och visar hur du skapar en exempelreplikeringsuppgift för Azure Service Bus-köer. Om du är nybörjare på logikappar och arbetsflöden kan du läsa Vad är Azure Logic Apps och Single-tenant kontra multitenant i Azure Logic Apps.
Vad är en replikeringsaktivitet?
I allmänhet tar en replikeringsaktivitet emot data, händelser eller meddelanden från en källa, flyttar innehållet till ett mål och tar sedan bort innehållet från källan, förutom när källan är en Event Hubs-entitet. Replikeringsaktiviteten flyttar vanligtvis innehållet oförändrat, men replikeringsuppgifter som drivs av Azure Logic Apps lägger också till replikeringsegenskaper. Om käll- och målprotokollen skiljer sig åt utför dessa uppgifter även mappningar mellan metadatastrukturer. Replikeringsuppgifter är tillståndslösa, vilket innebär att de inte delar tillstånd eller andra biverkningar över parallella eller sekventiella körningar av en aktivitet.
När du använder de tillgängliga replikeringsaktivitetsmallarna har varje replikeringsaktivitet som du skapar ett underliggande tillståndslöst arbetsflöde i en Logic App-resurs (Standard), som kan innehålla flera arbetsflöden för replikeringsuppgifter. Den här resursen finns i Azure Logic Apps med en enda klientorganisation, vilket är en skalbar och tillförlitlig körningsmiljö för att konfigurera och köra serverlösa program, inklusive replikering och federationsuppgifter. Azure Logic Apps-körningen med en klient använder också Utökningsmodellen för Azure Functions och finns som ett tillägg i Azure Functions-körningen. Den här designen ger portabilitet, flexibilitet och mer prestanda för logikapparbetsflöden plus andra funktioner och fördelar som ärvs från Azure Functions-plattformen och Azure App Service-ekosystemet.
Mer information om replikering och federation finns i följande dokumentation:
- Event Hubs-federation för flera platser och flera regioner
- Mönster för händelsereplikeringsuppgifter
- Service Bus-meddelandereplikering och federation mellan regioner
- Mönster för meddelandereplikeringsuppgifter
Uppgiftsmallar för replikering
För närvarande är replikeringsaktivitetsmallar tillgängliga för Azure Event Hubs och Azure Service Bus. I följande tabell visas de replikeringsaktivitetsmallar som för närvarande är tillgängliga i den här förhandsversionen:
| Resurstyp | Replikeringskälla och mål |
|---|---|
| Namnområde för Azure Event Hubs | – Event Hubs-instans till Event Hubs-instans – Event Hubs-instans till Service Bus-kö – Event Hubs-instans till Service Bus-ämne |
| Azure Service Bus-namnområde | – Service Bus-kö till Service Bus-kö – Service Bus-kö till Service Bus-ämne – Service Bus-ämne för Service Bus-ämnet – Service Bus-kö till Event Hubs-instans – Service Bus-ämne i Service Bus-kön – Service Bus-ämne för Event Hubs-instans Viktigt: När en kö är källan kopierar inte en replikeringsaktivitet meddelanden utan flyttar dem från källan till målet och tar bort dem från källan. Om du vill spegla meddelanden i stället använder du ett ämne som källa där "huvudprenumerationen" fungerar som en köslutpunkt. På så sätt får målet en kopia av varje meddelande från källan. Om du vill dirigera meddelanden mellan olika regioner kan du skapa en kö där meddelanden skickas från en app. Replikeringsaktiviteten överför meddelanden från kön till en målkö i ett namnområde som finns i en annan region. Du kan också använda en ämnesprenumeration som entitet som fungerar som överföringskö. Mer information finns i Replikeringstopologi för ServiceBusCopy. |
Replikeringstopologi och arbetsflöde
För att hjälpa dig att visualisera hur en replikeringsuppgift som drivs av Azure Logic Apps (Standard) fungerar visar följande diagram replikeringsaktivitetsstrukturen och arbetsflödet för Event Hubs-instanser och för Service Bus-köer.
Replikeringstopologi för Event Hubs
Följande diagram visar arbetsflödet för topologi och replikering mellan Event Hubs-instanser:
Information om replikering och federation i Azure Event Hubs finns i följande dokumentation:
- Event Hubs-federation för flera platser och flera regioner
- Mönster för händelsereplikeringsuppgifter
Replikeringstopologi för Service Bus
Följande diagram visar arbetsflödet för topologi- och replikeringsaktivitet mellan Service Bus-köer:
Information om replikering och federation i Azure Service Bus finns i följande dokumentation:
- Service Bus-meddelandereplikering och federation mellan regioner
- Mönster för meddelandereplikeringsuppgifter
Metadata och egenskapsmappningar
För Event Hubs ersätts följande objekt från källans Event Hubs-namnområde av nya tjänsttilldelade värden i målhändelsehubbens namnområde: tjänsttilldelade metadata för en händelse, ursprunglig kötid, sekvensnummer och förskjutning. För hjälpfunktioner och replikeringsuppgifterna i azure-exemplen bevaras dock de ursprungliga värdena i användaregenskaperna: repl-enqueue-time (ISO8601 sträng), repl-sequenceoch repl-offset. Dessa egenskaper har typen string och innehåller det strängifierade värdet för respektive ursprungliga egenskaper. Om händelsen vidarebefordras flera gånger läggs de tjänsttilldelade metadata för den omedelbara källan till eventuella befintliga egenskaper, med värden avgränsade med semikolon. Mer information finns i Tjänsttilldelade metadata – Aktivitetsmönster för händelsereplikering.
För Service Bus ersätts följande objekt från Service Bus-källkön eller -ämnet med nya tjänsttilldelade värden i service bus-målkön eller -ämnet: tjänsttilldelade metadata för ett meddelande, ursprunglig kötid och sekvensnummer. För standardreplikeringsuppgifterna i azure-exemplen bevaras dock de ursprungliga värdena i användaregenskaperna: repl-enqueue-time (ISO8601 sträng) och repl-sequence. Dessa egenskaper har typen string och innehåller det strängifierade värdet för respektive ursprungliga egenskaper. Om meddelandet vidarebefordras flera gånger läggs de tjänsttilldelade metadata för den omedelbara källan till i befintliga egenskaper, med värden avgränsade med semikolon. Mer information finns i Tjänsttilldelade metadata – Aktivitetsmönster för meddelandereplikering.
När en uppgift replikeras från Service Bus till Event Hubs mappar uppgiften endast User Properties egenskapen till egenskapen Properties . Men när uppgiften replikeras från Event Hubs till Service Bus mappar uppgiften följande egenskaper:
| Från Event Hubs | Till Service Bus |
|---|---|
| ContentType | ContentType |
| CorrelationId | CorrelationId |
| MessageId | MessageId |
| PartitionKey | PartitionKey SessionId |
| Egenskaper | Egenskaper för användare |
| ReplyTo | ReplyTo |
| ReplyToGroupName | ReplyToSessionId |
| Ämne | Etikett |
| Till | Till |
Beställ bevarande
För Event Hubs skapar replikering mellan samma antal partitioner 1:1 kloner utan ändringar i händelserna, men kan även innehålla dubbletter. Men replikering mellan olika antal partitioner, endast den relativa ordningen för händelser bevaras baserat på partitionsnyckel, men kan även innehålla dubbletter. Mer information finns i Streams och orderbevarande.
För Service Bus måste du aktivera sessioner så att meddelandesekvenser med samma sessions-ID som hämtats från källan skickas till målkön eller ämnet som en batch i den ursprungliga sekvensen och med samma sessions-ID. Mer information finns i Sekvenser och ordningsbevarande.
Viktigt!
Replikeringsuppgifter spårar inte vilka meddelanden som redan har bearbetats när källan upplever en störande händelse. För att förhindra ombearbetning av redan bearbetade meddelanden måste du konfigurera ett sätt att spåra de redan bearbetade meddelandena så att bearbetningen återupptas endast med obearbetade meddelanden.
Du kan till exempel konfigurera en databas som lagrar statusen proccessing för varje meddelande. När ett meddelande tas emot kontrollerar du meddelandets tillstånd och bearbetar endast när meddelandet är obearbetat. På så sätt sker ingen bearbetning för ett redan bearbetat meddelande.
Det här mönstret visar begreppet idempotens där upprepande av en åtgärd på indata ger samma resultat utan andra biverkningar eller inte ändrar indatavärdet.
Mer information om federation mellan flera platser och flera regioner för Azure-tjänster där du kan skapa replikeringsuppgifter finns i följande dokumentation:
- Event Hubs-federation för flera platser och flera regioner
- Mönster för händelsereplikeringsuppgifter
- Service Bus-meddelandereplikering och federation mellan regioner
- Mönster för meddelandereplikeringsuppgifter
Prissättning
Underifrån drivs en replikeringsaktivitet av ett tillståndslöst arbetsflöde i en logikappresurs (Standard) som finns i Azure Logic Apps med en enda klientorganisation. När du skapar den här replikeringsaktiviteten börjar avgifterna uppstå omedelbart. Användning, mätning, fakturering och prismodellen följer prisnivåerna Standard-värdplan och Standardplan.
Baserat på antalet händelser som Event Hubs tar emot eller meddelanden som Service Bus hanterar kan värdplanen skalas upp eller ned för att upprätthålla minsta vCPU-användning och låg svarstid under aktiv replikering. Det här beteendet kräver att när du skapar en logikappresurs som ska användas för replikeringsuppgiften väljer du lämplig prisnivå för standardplanen så att Azure Logic Apps inte begränsar eller börjar maxa CPU-användningen och fortfarande kan garantera snabb replikeringshastighet.
Kommentar
Om din app börjar med en instans av WS1-planen och sedan skalar ut till två instanser är kostnaden dubbelt så stor som kostnaden för WS1, förutsatt att planerna körs hela dagen. Om du skalar upp din app till WS2-planen och använder en instans är kostnaden i praktiken densamma som två WS1-planinstanser. På samma sätt, om du skalar upp din app till WS3-planen och använder en instans, är kostnaden i praktiken densamma som två WS2-planinstanser eller fyra WS1-planinstanser.
Följande exempel illustrerar prisnivån för värdplan och konfigurationsalternativ som ger det bästa dataflödet och kostnaden för specifika replikeringsaktivitetsscenarier, baserat på om scenariot är Event Hubs eller Service Bus och olika konfigurationsvärden.
Kommentar
Exemplen i följande avsnitt använder 800 som standardvärde för antalet prefetch, maximal händelsebatchstorlek för Event Hubs och maximalt antal meddelanden för Service Bus, förutsatt att händelsen eller meddelandestorleken är 1 KB. Baserat på dina händelsestorlekar kanske du vill justera antalet prefetch, maximal händelsebatchstorlek eller maximalt antal meddelanden. Om händelsestorleken eller meddelandestorleken till exempel är över 1 kB kanske du vill minska värdena för antalet prefetch och maximal händelsebatchstorlek eller meddelandeantal från 800.
Utskalning av Event Hubs
Följande exempel illustrerar prisnivån för värdplan och konfigurationsalternativ för en replikeringsaktivitet mellan två Event Hubs-namnområden i samma region, baserat på antalet partitioner, antalet händelser per sekund och andra konfigurationsvärden.
Exemplen i det här avsnittet använder 800 som standardvärde för antalet prefetch och maximal händelsebatchstorlek, förutsatt att händelsestorleken är 1 KB. Baserat på dina händelsestorlekar kanske du vill justera antalet prefetch och den maximala händelsebatchstorleken. Om händelsestorleken till exempel är över 1 KB kanske du vill minska värdena för antalet prefetch och den maximala händelsebatchstorleken från 800.
| Prisnivå | Antal partitioner | Händelser per sekund | Maximalt antal bursts* | Alltid redo instanser* | Antal prefetch* | Maximal händelsebatchstorlek* |
|---|---|---|---|---|---|---|
| WS1 | 1 | 1000 | 1 | 1 | 800 | 800 |
| WS1 | 2 | 2000 | 1 | 1 | 800 | 800 |
| WS2 | 4 | 4000 | 2 | 1 | 800 | 800 |
| WS2 | 8 | 8000 | 2 | 1 | 800 | 800 |
| WS3 | 16 | 16000 | 2 | 1 | 800 | 800 |
| WS3 | 32 | 32000 | 3 | 1 | 800 | 800 |
* Mer information om de värden som du kan ändra för varje prisnivå finns i följande tabell:
| Värde | beskrivning |
|---|---|
| Maximalt antal bursts | Det maximala antalet elastiska arbetare som ska skalas ut under belastning. Om din underliggande app kräver instanser utöver de alltid redo instanserna i nästa tabellrad kan din app fortsätta att skalas ut tills antalet instanser når den maximala burst-gränsen. Om du vill ändra det här värdet läser du Redigera inställningar för utskalning av värdplan senare i den här artikeln. Obs! Alla instanser utöver din planstorlek debiteras endast när de körs och allokeras till dig per sekund. Plattformen gör sitt bästa för att skala ut din app till den definierade maxgränsen. Tips: Som rekommendation väljer du ett högsta värde som är högre än du kan behöva så att plattformen kan skalas ut för att hantera en större belastning om det behövs, eftersom oanvända instanser inte faktureras. Mer information finns i följande dokumentation eftersom Workflow Standard-planen delar vissa aspekter med Azure Functions Premium-planen: - Planera och SKU-inställningar – Azure Functions Premium-plan |
| Alltid redo instanser | Det minsta antalet instanser som alltid är redo och varma för att vara värd för din app. Det minsta antalet är alltid 1. Om du vill ändra det här värdet läser du Redigera inställningar för utskalning av värdplan senare i den här artikeln. Obs! Alla instanser utöver din planstorlek debiteras oavsett om de körs när de allokeras till dig eller inte . Mer information finns i följande dokumentation eftersom Arbetsflödesstandardplanen delar vissa aspekter med Azure Functions Premium-planen: Alltid redo instanser – Azure Functions Premium-plan. |
| Antal prefetch | Standardvärdet för AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__prefetchCount appinställningen i logikappresursen som avgör antalet förhämtningar som används av den underliggande EventProcessorHost klassen. Om du vill lägga till eller ange ett annat värde för den här appinställningen läser du Hantera appinställningar – local.settings.json, till exempel: - Namn: Mer information om egenskapen finns i - host.json inställningar – Utlösare och bindningar för Azure Event Hubs för Azure Functions |
| Maximal händelsebatchstorlek | Standardvärdet för appinställningen AzureFunctionsJobHost__extensions__eventHubs__eventProcessorOptions__maxBatchSize i logikappresursen som avgör det maximala antalet händelser som tas emot av varje mottagningsloop. Om du vill lägga till eller ange ett annat värde för den här appinställningen läser du Hantera appinställningar – local.settings.json, till exempel: - Namn: Mer information om egenskapen finns i - host.json inställningar – Utlösare och bindningar för Azure Event Hubs för Azure Functions |
Utskalning av Service Bus
Följande exempel illustrerar prisnivån för värdplan och konfigurationsalternativ för en replikeringsaktivitet mellan två Service Bus-namnområden i samma region, baserat på antalet meddelanden per sekund och andra konfigurationsvärden.
Exemplen i det här avsnittet använder 800 som standardvärde för antalet prefetch och maximalt antal meddelanden, förutsatt att meddelandestorleken är 1 KB. Baserat på dina meddelandestorlekar kanske du vill justera antalet förinställda meddelanden och det maximala antalet meddelanden. Om meddelandestorleken till exempel är över 1 kB kanske du vill minska värdena för antalet prefetch och det maximala antalet meddelanden från 800.
| Prisnivå | Meddelanden per sekund | Maximalt antal bursts* | Alltid redo instanser* | Antal prefetch* | Maximalt antal meddelanden* |
|---|---|---|---|---|---|
| WS1 | 2000 | 1 | 1 | 800 | 800 |
| WS2 | 2500 | 1 | 1 | 800 | 800 |
| WS3 | 3500 | 1 | 1 | 800 | 800 |
* Mer information om de värden som du kan ändra för varje prisnivå finns i följande tabell:
| Värde | beskrivning |
|---|---|
| Maximalt antal bursts | Det maximala antalet elastiska arbetare som ska skalas ut under belastning. Om din underliggande app kräver instanser utöver de alltid redo instanserna i nästa tabellrad kan din app fortsätta att skalas ut tills antalet instanser når den maximala burst-gränsen. Om du vill ändra det här värdet läser du Redigera inställningar för utskalning av värdplan senare i den här artikeln. Obs! Alla instanser utöver din planstorlek debiteras endast när de körs och allokeras till dig per sekund. Plattformen gör sitt bästa för att skala ut din app till den definierade maxgränsen. Tips: Som rekommendation väljer du ett högsta värde som är högre än du kan behöva så att plattformen kan skalas ut för att hantera en större belastning om det behövs, eftersom oanvända instanser inte faktureras. Mer information finns i följande dokumentation eftersom Workflow Standard-planen delar vissa aspekter med Azure Functions Premium-planen: - Planera och SKU-inställningar – Azure Functions Premium-plan |
| Alltid redo instanser | Det minsta antalet instanser som alltid är redo och varma för att vara värd för din app. Det minsta antalet är alltid 1. Om du vill ändra det här värdet läser du Redigera inställningar för utskalning av värdplan senare i den här artikeln. Obs! Alla instanser utöver din planstorlek debiteras oavsett om de körs när de allokeras till dig eller inte . Mer information finns i följande dokumentation eftersom Arbetsflödesstandardplanen delar vissa aspekter med Azure Functions Premium-planen: Alltid redo instanser – Azure Functions Premium-plan. |
| Antal prefetch | Standardvärdet för AzureFunctionsJobHost__extensions__serviceBus__prefetchCount appinställningen i logikappresursen som avgör antalet förhämtningar som används av den underliggande ServiceBusProcessor klassen. Om du vill lägga till eller ange ett annat värde för den här appinställningen läser du Hantera appinställningar – local.settings.json, till exempel: - Namn: Mer information om egenskapen finns i - host.json inställningar – Azure Service Bus-bindningar för Azure Functions |
| Maximalt antal meddelanden | Standardvärdet för appinställningen AzureFunctionsJobHost__extensions__serviceBus__batchOptions__maxMessageCount i logikappresursen som avgör det maximala antalet meddelanden som ska skickas när den utlöses. Om du vill lägga till eller ange ett annat värde för den här appinställningen läser du Hantera appinställningar – local.settings.json, till exempel: - Namn: Mer information om egenskapen finns i |
Förutsättningar
Ett Azure-konto och prenumeration. Om du inte har någon prenumeration kan du registrera ett kostnadsfritt Azure-konto.
Käll- och målresurserna eller entiteterna, som ska finnas i olika Azure-regioner så att du kan testa för scenariot för geo-haveriberedskapsredundans. Dessa entiteter kan variera beroende på den uppgiftsmall som du vill använda. Exemplet i den här artikeln använder två Service Bus-köer, som finns i olika namnområden och Azure-regioner.
En Logic App-resurs (Standard) som du kan återanvända när du skapar replikeringsaktiviteten. På så sätt kan du anpassa den här resursen specifikt för replikeringsaktiviteten, till exempel genom att välja värdplan och prisnivå baserat på replikeringsscenariots behov, till exempel kapacitet, dataflöde och skalning. Även om du kan skapa den här resursen när du skapar replikeringsaktiviteten kan du inte ändra region, värdplan och prisnivå. Följande lista innehåller andra orsaker och metodtips för en tidigare skapad logikappresurs:
Du kan skapa den här logikappresursen i en region som skiljer sig från käll- och målentiteterna i replikeringsuppgiften.
För närvarande tillhandahålls den här vägledningen på grund av replikeringsaktivitetens interna integrering i Azure-resurser. När du skapar en replikeringsaktivitet mellan entiteter och väljer att skapa en ny logikappresurs i stället för att använda en befintlig, skapas den nya logikappen i samma region som källentiteten. Om källregionen blir otillgänglig kan replikeringsaktiviteten inte heller fungera. I ett redundansscenario kan aktiviteten inte heller börja läsa data från den nya källan, tidigare målentiteten, vilket är vad det aktiva-passiva replikeringsmönstret försöker uppnå.
Du kan anpassa den här logikappresursen i förväg genom att välja värdplan och prisnivå i stället för att använda standardattributen. På så sätt kan replikeringsaktiviteten bearbeta fler händelser eller meddelanden per sekund för snabbare replikering. Om du skapar den här resursen när du skapar replikeringsaktiviteten korrigeras dessa standardattribut.
Du kan se till att den här logikappresursen endast innehåller arbetsflöden för replikeringsaktivitet, särskilt om du vill följa mönstret för aktiv-passiv replikering. När du använder en befintlig logikapp för att skapa replikeringsaktiviteten lägger det här alternativet till uppgiften (tillståndslöst arbetsflöde) till den logikappresursen.
Mer information finns i Skapa ett integreringsarbetsflöde med Azure Logic Apps (Standard) med en enda klientorganisation i Azure Portal.
Valfritt: anslutningssträng för målnamnområdet. Med det här alternativet kan målet finnas i en annan prenumeration, så att du kan konfigurera replikering mellan prenumerationer.
Följ dessa steg för att hitta anslutningssträng för målentiteten:
På navigeringsmenyn för namnområdet går du till Inställningar och väljer Principer för delad åtkomst.
I fönstret Principer för delad åtkomst som öppnas går du till Princip och väljer RootManageSharedAccessKey.
I fönstret SAS-princip: RootManageSharedAccessKey som öppnas kopierar du värdet primär anslutningssträng .
Spara anslutningssträng någonstans så att du senare kan använda strängen för att ansluta till målnamnområdet.
Namngivningskonventioner
Tänk noga på den namngivningsstrategi som du använder för dina replikeringsuppgifter eller entiteter, om du inte har skapat dem ännu. Kontrollera att namnen är lätt identifierbara och differentierade. Om du till exempel arbetar med Event Hubs-namnområdet replikeras replikeringsaktiviteten från varje Event Hubs-instans i källnamnområdet. Om du arbetar med Service Bus-köer innehåller följande tabell ett exempel på namngivning av entiteter och replikeringsaktivitet:
| Källnamn | Exempel | Replikeringsapp | Exempel | Målnamn | Exempel |
|---|---|---|---|---|---|
Namnområde: <name>-sb-<region> |
fabrikam-sb-weu |
Logikapp: <name-source-region-target-region> |
fabrikam-rep-weu-wus |
Namnområde: <name>-sb-<region> |
fabrikam-sb-wus |
Kö: <name> |
jobs-transfer |
Arbetsflöde: <name> |
jobs-transfer-workflow |
Kö: <name> |
jobs |
Skapa en replikeringsaktivitet
Det här exemplet visar hur du skapar en replikeringsaktivitet för Service Bus-köer.
I Azure Portal letar du reda på det Service Bus-namnområde som du vill använda som källa.
På namnområdets navigeringsmeny går du till avsnittet Automation och väljer Uppgifter (förhandsversion).
I fönstret Uppgifter väljer du Lägg till en uppgift så att du kan välja en uppgiftsmall.
I fönstret Lägg till en åtgärd går du till Välj en mall och i mallen för replikeringsaktiviteten som du vill skapa väljer du Välj. Om nästa sida inte visas väljer du Nästa: Autentisera.
Det här exemplet fortsätter genom att välja mallen Replikera från Service Bus-kön för att köa uppgift, som replikerar innehåll mellan Service Bus-köer.
På fliken Autentisera går du till avsnittet Anslutningar och väljer Skapa för varje anslutning som visas i uppgiften så att du kan ange autentiseringsuppgifter för alla anslutningar. Typerna av anslutningar i varje aktivitet varierar beroende på aktiviteten.
Det här exemplet visar uppmaningen att skapa anslutningen till service bus-målnamnområdet där målkön finns. Anslutningen finns för Service Bus-källnamnområdet.
Ange nödvändig information om målet och välj sedan Skapa.
I det här exemplet anger du ett visningsnamn för anslutningen och väljer sedan service bus-namnområdet där målkön finns.
Dricks
Du kan också skapa anslutningen med en anslutningssträng i stället. Med det här alternativet kan du ha målet i en annan prenumeration, så att du kan konfigurera replikering mellan prenumerationer. Målet, eller källan baserat på var du började skapa replikeringsaktiviteten, konfigureras dynamiskt så att du bara behöver ansluta målet. Använd följande steg om du vill använda en anslutningssträng:
I fönstret Anslut väljer du Anslut via anslutningssträng.
I rutan Anslutningssträng anger du anslutningssträng för målnamnområdet.
I följande exempel visas anslutningen som har skapats:
När du har slutfört alla anslutningar väljer du Nästa: Konfigurera.
På fliken Konfigurera anger du ett namn för uppgiften och annan information som krävs för aktiviteten.
Kommentar
Du kan inte ändra aktivitetsnamnet när du har skapat det, så tänk på ett namn som fortfarande gäller om du redigerar det underliggande arbetsflödet. Ändringar som du gör i det underliggande arbetsflödet gäller endast för den uppgift som du skapade, inte för uppgiftsmallen.
Om du till exempel namnger aktiviteten
fabrikam-rep-weu-wus, men senare redigerar det underliggande arbetsflödet för ett annat syfte, kan du inte ändra uppgiftsnamnet så att det matchar.Om du vill lägga till uppgiftsarbetsflödet i en befintlig Logic App-resurs (Standard) väljer du den befintliga logikappen i listan Logikapp . Om du i stället vill skapa en ny logikappresurs (Standard) väljer du Skapa ny under listan Logikapp och anger det namn som ska användas för den nya logikappen.
Kommentar
Om du skapar en ny logikappresurs när replikeringsaktiviteten skapas skapas logikappen i samma region som källentiteten, vilket är problematiskt om källregionen blir otillgänglig och inte fungerar i ett redundansscenario. Det bästa sättet är att skapa en logikappresurs (Standard) i en annan region än din källa. När du skapar replikeringsuppgiften väljer du den befintliga logikappen i stället och lägger till det underliggande tillståndslösa arbetsflödet i den befintliga logikappen. Mer information finns i Förutsättningar.
När du är klar väljer du Granska + skapa.
På fliken Granska + skapa bekräftar du de Azure-resurser som replikeringsaktiviteten kräver för åtgärd.
Om du väljer att skapa en ny logikappresurs för replikeringsaktiviteten visar fönstret de Nödvändiga Azure-resurser som replikeringsaktiviteten skapar för att fungera. Dessa resurser innehåller till exempel ett Azure Storage-konto som innehåller konfigurationsinformation för logikappens resurs, arbetsflöde och andra körningsåtgärder. Till exempel med Event Hubs innehåller det här lagringskontot kontrollpunktsinformation och positionen eller förskjutningen i strömmen där källentiteten stoppas om källregionen avbryts eller blir otillgänglig.
I följande exempel visas fliken Granska + skapa om du väljer att skapa en ny logikapp:
Om du väljer att återanvända en befintlig logikappresurs för replikeringsaktiviteten visar fönstret de Azure-resurser som replikeringen återanvänder för att fungera.
I följande exempel visas fliken Granska + skapa om du väljer att återanvända en befintlig logikapp:
Kommentar
Om källan, målet eller båda ligger bakom ett virtuellt nätverk måste du konfigurera behörigheter och åtkomst när du har skapat uppgiften. I det här scenariot krävs behörigheter och åtkomst så att logikappens arbetsflöde kan utföra replikeringsuppgiften.
När du är klar väljer du Skapa.
Den uppgift som du skapade, som körs automatiskt och körs, visas nu i listan Uppgifter .
Dricks
Om aktiviteten inte visas omedelbart kan du prova att uppdatera uppgiftslistan eller vänta lite innan du uppdaterar. Välj Uppdatera i verktygsfältet.
Om dina resurser finns bakom ett virtuellt nätverk måste du komma ihåg att konfigurera behörigheter för logikappresursen och arbetsflödet för att få åtkomst till dessa resurser.
Konfigurera återförsöksprincip
För att undvika dataförlust under en tillgänglighetshändelse på båda sidor av en replikeringsrelation måste du konfigurera återförsöksprincipen för robusthet. Om du vill konfigurera återförsöksprincipen för en replikeringsuppgift läser du dokumentationen om återförsöksprinciper i Azure Logic Apps och stegen för att redigera det underliggande arbetsflödet.
Granska aktivitetshistorik
Det här exemplet visar hur du visar en uppgifts historik över arbetsflöden tillsammans med deras statusar, indata, utdata och annan information och fortsätter att använda exemplet för en Service Bus-köreplikeringsaktivitet.
I Azure Portal hittar du den Azure-resurs eller entitet som har den aktivitetshistorik som du vill granska.
I det här exemplet är den här resursen ett Service Bus-namnområde.
På resursnavigeringsmenyn under Inställningar går du till avsnittet Automation och väljer Uppgifter (förhandsversion).
Leta reda på den uppgift som du vill granska i fönstret Uppgifter . I kolumnen Körningar för aktiviteten väljer du Visa.
Det här steget öppnar fönstret Översikt för det underliggande tillståndslösa arbetsflödet, som ingår i en standardlogikappresurs.
Om du vill visa körningshistorik för ett tillståndslöst arbetsflöde går du till verktygsfältet Översikt och väljer Aktivera felsökningsläge.
Fliken Körningshistorik visar alla tidigare, pågående och väntande körningar för aktiviteten tillsammans med deras identifierare, statusar, starttider och körningsvaraktighet.
I följande tabell beskrivs möjliga statusar för en körning:
Statusetikett beskrivning Avbruten Uppgiften avbröts när den kördes. Misslyckades Uppgiften har minst en misslyckad åtgärd, men det fanns inga efterföljande åtgärder för att hantera felet. Körs Uppgiften körs för närvarande. Lyckades Alla åtgärder har slutförts. En uppgift kan fortfarande slutföras om en åtgärd misslyckades, men det fanns en efterföljande åtgärd för att hantera felet. Väntar Körningen har inte startat ännu och pausas eftersom en tidigare instans av aktiviteten fortfarande körs. Om du vill visa status och annan information för varje steg i en körning väljer du den körningen.
Fönstret körningsinformation öppnas och visar det underliggande arbetsflödet som kördes.
Ett arbetsflöde börjar alltid med en utlösare. För den här uppgiften börjar arbetsflödet med en Service Bus-utlösare som väntar på att meddelanden ska tas emot i service bus-källkön.
Varje steg visar dess status och körningsvaraktighet. Steg som har 0 sekunders varaktighet tog mindre än 1 sekund att köra.
Om du vill granska indata och utdata för varje steg väljer du steget, som öppnar ett fönster som visar information om indata, utdata och egenskaper för det steget.
Det här exemplet visar indata för Service Bus-utlösaren.
Om du vill lära dig hur du kan skapa egna automatiserade arbetsflöden så att du kan integrera appar, data, tjänster och system, förutom kontexten för replikeringsuppgifter för Azure-resurser, läser du Skapa ett integreringsarbetsflöde med Azure Logic Apps (Standard) för en enda klientorganisation i Azure Portal.
Övervaka replikeringsuppgifter
Om du vill kontrollera prestanda och hälsotillstånd för replikeringsaktiviteten eller det underliggande logikapparbetsflödet kan du använda Application Insights, som är en funktion i Azure Monitor. Application Insights-programkartan är ett användbart visuellt verktyg som du kan använda för att övervaka replikeringsuppgifter. Den här kartan genereras automatiskt från den insamlade övervakningsinformationen så att du kan utforska prestanda och tillförlitlighet för replikeringsaktivitetens källa och målöverföringar. För omedelbara diagnostikinsikter och visualisering av logginformation med kort svarstid kan du arbeta med verktyget Live Metrics-portalen , även en funktion i Azure Monitor.
Redigera uppgiften
Om du vill ändra en uppgift har du följande alternativ:
Redigera uppgiften "infogad" så att du kan ändra aktivitetens egenskaper, till exempel anslutningsinformation eller konfigurationsinformation.
Redigera uppgiftens underliggande arbetsflöde i designern.
Redigera uppgiften infogad
I Azure Portal letar du reda på resursen som har den uppgift som du vill uppdatera.
På resursnavigeringsmenyn går du till avsnittet Automation och väljer Uppgifter (förhandsversion).
Leta reda på den uppgift som du vill uppdatera i uppgiftslistan. Öppna aktivitetens ellipsmeny (...) och välj Redigera på rad.
Som standard visas fliken Autentisera och visar befintliga anslutningar.
Om du vill lägga till nya autentiseringsuppgifter eller välja olika befintliga autentiseringsuppgifter för en anslutning öppnar du anslutningens ellipsmeny (...) och väljer antingen Lägg till ny anslutning eller, om det är tillgängligt, olika autentiseringsuppgifter.
Kommentar
Du kan bara redigera målanslutningen, inte källanslutningen.
Om du vill uppdatera andra aktivitetsegenskaper väljer du Nästa: Konfigurera.
För uppgiften i det här exemplet kan du ange olika käll- och målköer. Uppgiftsnamnet och den underliggande logikappen och arbetsflödet förblir dock desamma.
När du är klar väljer du Spara.
Redigera aktivitetens underliggande arbetsflöde
Du kan redigera det underliggande arbetsflödet bakom en replikeringsaktivitet, vilket ändrar den ursprungliga konfigurationen för den uppgift som du skapade men inte själva uppgiftsmallen. När du har gjort och sparat ändringarna utför den redigerade aktiviteten inte längre samma funktion som den ursprungliga aktiviteten. Om du vill ha en uppgift som utför den ursprungliga funktionen kan du behöva skapa en ny uppgift med samma mall. Om du inte vill återskapa den ursprungliga uppgiften bör du undvika att ändra arbetsflödet bakom uppgiften med hjälp av designern. Skapa i stället ett tillståndslöst arbetsflöde för logikappen (Standard) för att uppfylla dina integreringsbehov. Mer information finns i Skapa ett integreringsarbetsflöde med Azure Logic Apps (Standard) med en enda klientorganisation i Azure Portal.
I Azure Portal letar du reda på resursen som har den uppgift som du vill uppdatera.
I avsnittet Automation på resursnavigeringsmenyn väljer du Uppgifter.
Leta reda på den uppgift som du vill uppdatera i uppgiftslistan. Öppna aktivitetens ellipsmeny (...) och välj Öppna i Logic Apps.
Azure Portal ändrar kontexten till designern där du nu kan redigera arbetsflödet.
Nu kan du redigera arbetsflödets utlösare och åtgärder samt egenskaperna för utlösaren och åtgärderna.
Om du vill visa egenskaperna för utlösaren eller en åtgärd väljer du den utlösaren eller åtgärden.
I det här exemplet ändras utlösarens egenskap IsSessionsEnabled till Ja.
Spara ändringarna genom att välja Spara i designerverktygsfältet.
Om du vill testa och köra det uppdaterade arbetsflödet öppnar du logikappresursen som innehåller det uppdaterade arbetsflödet. På arbetsflödesnavigeringsmenyn väljer du Översikt>Kör utlösarkörning.>
När körningen är klar visar designern arbetsflödets körningsinformation. Om du vill granska indata och utdata för varje steg väljer du steget, som öppnar ett fönster som visar information om indata, utdata och egenskaper för det steget.
Det här exemplet visar den valda Service Bus-utlösarens indata, utdata och egenskaper, tillsammans med det uppdaterade egenskapsvärdet för utlösaren.
Om du vill inaktivera arbetsflödet så att aktiviteten inte fortsätter att köras väljer du Inaktivera i verktygsfältet Översikt. Mer information finns i Inaktivera eller aktivera arbetsflöden för en enda klientorganisation.
Konfigurera redundans för Azure Event Hubs
För Azure Event Hubs-replikering mellan samma entitetstyper kräver geo-haveriberedskap att du utför en redundansväxling från källentiteten till målentiteten och sedan uppmanar berörda händelsekonsumenter och producenter att använda slutpunkten för målentiteten, som blir den nya källan. Om en katastrof inträffar och källentiteten redundansväxlar omdirigeras konsumenter och producenter, inklusive replikeringsaktiviteten, till den nya källan. Lagringskontot som skapades av replikeringsaktiviteten innehåller kontrollpunktsinformation och positionen eller förskjutningen i strömmen där källentiteten stoppas om källregionen avbryts eller blir otillgänglig.
För att säkerställa att lagringskontot inte innehåller någon äldre information från den ursprungliga källan och att replikeringsaktiviteten börjar läsa och replikera händelser från början av den nya källströmmen måste du manuellt rensa all äldre information från den ursprungliga källan och konfigurera om replikeringsaktiviteten.
Öppna logikappresursen eller det underliggande arbetsflödet bakom replikeringsuppgiften i Azure Portal.
Kommentar
Logikappresursen ska endast innehålla arbetsflöden för replikeringsaktivitet.
På resursens eller arbetsflödets navigeringsmeny väljer du Översikt. Välj Inaktivera för arbetsflödet i verktygsfältet Översikt eller välj Stoppa för logikappresursen.
Följ dessa steg för att hitta lagringskontot som används av replikeringsaktivitetens underliggande logikappresurs för att lagra kontrollpunkten och strömma förskjutningsinformation från källentiteten:
På resursmenyn för logikappen går du till Inställningar och väljer Konfiguration.
I fönstret Konfiguration går du till fliken Programinställningar och väljer appinställningen AzureWebJobsStorage .
Den här inställningen anger det anslutningssträng- och lagringskonto som används av logikappresursen.
Kommentar
Om appinställningen inte visas i listan väljer du Visa värden.
Välj appinställningen AzureWebJobsStorage så att du kan visa lagringskontots namn.
Det här exemplet visar hur du hittar namnet på det här lagringskontot, som finns
storagefabrikamreplb0chär:
- Bekräfta att lagringskontoresursen finns genom att i sökrutan Azure Portal ange namnet och sedan välja lagringskontot, till exempel:
Ta nu bort mappen som innehåller källentitetens kontrollpunkt och förskjutningsinformation med hjälp av följande steg:
Ladda ned, installera och öppna den senaste Azure Storage Explorer-skrivbordsklienten om du inte har den senaste versionen.
Kommentar
För borttagningsrensningen måste du för närvarande använda Azure Storage Explorer-klienten, inte lagringsutforskaren, webbläsaren, redigeraren eller hanteringsmiljön i Azure Portal.
Även om du kan ta bort containermappar med PowerShell-kommandot
Remove-AzStorageDirectoryfungerar det här kommandot bara på tomma mappar.Om du inte redan har gjort det loggar du in med ditt Azure-konto och ser till att din Azure-prenumeration för lagringskontoresursen har valts. Mer information finns i Kom igång med Storage Explorer.
I Utforskaren går du till Lagringskonton>{ditt lagringskontonamn}>BlobContainrar>azure-webjobs-eventhub under ditt Azure-prenumerationsnamn.
Kommentar
Om mappen azure-webjobs-eventhub inte finns har replikeringsaktiviteten inte körts ännu. Mappen visas först efter att replikeringsaktiviteten har körts minst en gång.
I fönstret azure-webjobs-eventhub som öppnas väljer du mappen Event Hubs-namnområde, som har ett namn med följande format:
<source-Event-Hubs-namespace-name>.servicebus.windows.net.När namnområdesmappen har öppnats går du till fönstret azure-webjobs-eventhub och väljer <mappen tidigare-source-entity-name>. I verktygsfältet eller mappens snabbmeny väljer du Ta bort, till exempel:
Bekräfta att du vill ta bort mappen.
Gå tillbaka till logikappresursen eller arbetsflödet bakom replikeringsuppgiften. Starta om logikappen eller aktivera arbetsflödet igen.
För att producenter och konsumenter ska kunna använda den nya källslutpunkten måste du göra information om den nya källentiteten tillgänglig för användning och hitta på en plats som är lätt att nå och uppdatera. Om producenter eller konsumenter får frekventa eller beständiga fel bör de kontrollera platsen och justera konfigurationen. Det finns många sätt att dela den konfigurationen, men DNS och filresurser är exempel.
Mer information om geo-haveriberedskap finns i följande dokumentation:
Redigera utskalningsinställningar för värdplan
Öppna den underliggande logikappresursen för replikeringsaktiviteten i Azure Portal.
På resursmenyn för logikappen går du till Inställningar och väljer Skala ut (App Service-plan).
Baserat på ditt scenarios behov ändrar du värdena för maximal burst respektive alltid redo instanser under Plan Scale out and App Scale out (Planera utskalning och App Scale out).
När du är klar går du till verktygsfältet Skala ut (App Service-plan) och väljer Spara.
Mer information finns i följande dokumentation eftersom Workflow Standard-planen delar vissa aspekter med Azure Functions Premium-planen:
- Planera och SKU-inställningar – Azure Functions Premium-plan
- Vad är molnsprängning?
- Alltid redo instanser – Azure Functions Premium-plan
Replikeringsproblem och -fel
I det här avsnittet beskrivs möjliga sätt att replikering kan misslyckas eller sluta fungera:
Storleksgränser för meddelanden
Se till att skicka meddelanden som är mindre än 1 MB eftersom replikeringsaktiviteten lägger till replikeringsegenskaper. Annars, om meddelandestorleken är större än storleken på händelser som kan skickas till en Event Hubs-entitet efter att uppgiften har lagt till replikeringsegenskaper, misslyckas replikeringsprocessen.
Anta till exempel att meddelandestorleken är 1 MB. När uppgiften har lagt till replikeringsegenskaper är meddelandestorleken större än 1 MB. Det utgående anropet som försöker skicka meddelandet misslyckas.
Partitionsnycklar
Om det finns partitionsnycklar i händelserna misslyckas replikeringen mellan Event Hubs-instanser om dessa instanser har samma antal partitioner.