Affärskontinuitet och haveriberedskap för Azure Logic Apps

  • Artikel

För att minska påverkan och effekter som oförutsägbara händelser har på ditt företag och dina kunder kontrollerar du att du har en haveriberedskapslösning (DR) på plats så att du kan skydda data, snabbt återställa resurser som stöder kritiska affärsfunktioner och hålla verksamheten igång för att upprätthålla affärskontinuitet (BC). Avbrott kan till exempel omfatta avbrott, förluster i underliggande infrastruktur eller komponenter som lagring, nätverk eller beräkningsresurser, oåterkalleliga programfel eller till och med en fullständig datacenterförlust. Genom att ha en lösning för affärskontinuitet och haveriberedskap (BCDR) redo kan företaget eller organisationen reagera snabbare på avbrott, planerade eller oplanerade och minska stilleståndstiden för dina kunder.

Den här artikeln innehåller BCDR-vägledning och strategier som du kan använda när du skapar automatiserade arbetsflöden med hjälp av Azure Logic Apps. Med arbetsflöden för logikappar kan du enklare integrera och samordna data mellan appar, molntjänster och lokala system genom att minska hur mycket kod du måste skriva. När du planerar för BCDR bör du inte bara överväga dina logikappar, utan även de Azure-resurser som du använder med dina logikappar:

Primära och sekundära platser

Varje logikapp måste ange den plats som du vill använda för distribution. Den här platsen är antingen en offentlig region i globala Azure med flera klientorganisationer, till exempel "USA, västra" eller en integrationstjänstmiljö (ISE) som du tidigare skapade och distribuerade till ett virtuellt Azure-nätverk. Att köra logikappar i en ISE liknar att köra logikappar i en global Azure-region, vilket innebär att din haveriberedskapsstrategi kan tillämpas på båda scenarierna. Internetservrar har dock andra överväganden, till exempel att konfigurera åtkomst till resurser som endast är tillgängliga för ISE:er.

Anteckning

Om logikappen också fungerar med B2B-artefakter, till exempel handelspartner, avtal, scheman, kartor och certifikat, som lagras i ett integrationskonto, måste både ditt integrationskonto och logikappar ange samma plats.

Den här haveriberedskapsstrategin fokuserar på att konfigurera din primära logikapp för redundansväxling till en logikapp för vänteläge eller säkerhetskopiering på en annan plats där Azure Logic Apps också är tillgängligt. På så sätt, om den primära drabbas av förluster, störningar eller fel, kan den sekundära ta på sig arbetet. Den här strategin kräver att din sekundära logikapp och beroende resurser redan har distribuerats och är klara på den alternativa platsen.

Om du följer bra DevOps-metoder använder du redan Azure Resource Manager-mallar för att definiera och distribuera dina logikappar och deras beroende resurser. Resource Manager mallar ger dig möjlighet att använda en enda distributionsdefinition och sedan använda parameterfiler för att ange de konfigurationsvärden som ska användas för varje distributionsmål. Den här funktionen innebär att du kan distribuera samma logikapp till olika miljöer, till exempel utveckling, test och produktion. Du kan också distribuera samma logikapp till olika Azure-regioner eller ISE:er, som stöder strategier för haveriberedskap som använder länkade regioner.

För redundansstrategin måste dina logikappar och platser uppfylla följande krav:

Exempel: Azure med flera klientorganisationer

Det här exemplet visar primära och sekundära logikappinstanser som distribueras till separata regioner i den globala Azure för flera klientorganisationer för det här scenariot. En enda Resource Manager-mall definierar både logikappinstanser och de beroende resurser som krävs av dessa logikappar. Separata parameterfiler anger de konfigurationsvärden som ska användas för varje distributionsplats:

Primära och sekundära logikappinstanser på separata platser

Exempel: Integrationstjänstmiljö

Det här exemplet visar tidigare primära och sekundära logikappinstanser men distribueras till separata ISE:er. En enda Resource Manager-mall definierar både logikappinstanser, de beroende resurser som krävs av dessa logikappar och ISE:erna som distributionsplatser. Separata parameterfiler definierar de konfigurationsvärden som ska användas för distribution på varje plats:

Primära och sekundära logikappar på olika platser

Anslutningar till resurser

Azure Logic Apps tillhandahåller många hundratals anslutningsåtgärder som logikappens arbetsflöde kan använda för att arbeta med andra appar, tjänster, system och andra resurser, till exempel Azure Storage-konton, SQL Server databaser, arbets- eller skol-e-postkonton och så vidare. Om logikappen behöver åtkomst till dessa resurser skapar du anslutningar som autentiserar åtkomsten till dessa resurser. Varje anslutning är en separat Azure-resurs som finns på en specifik plats och som inte kan användas av resurser på andra platser.

För din haveriberedskapsstrategi bör du överväga de platser där beroende resurser finns i förhållande till dina logikappinstanser:

  • Din primära instans och beroende resurser finns på olika platser. I det här fallet kan den sekundära instansen ansluta till samma beroende resurser eller slutpunkter. Du bör dock skapa anslutningar specifikt för den sekundära instansen. På så sätt påverkas inte den sekundäras anslutningar om den primära platsen blir otillgänglig.

    Anta till exempel att din primära logikapp ansluter till en extern tjänst som Salesforce. Vanligtvis är den externa tjänstens tillgänglighet och plats oberoende av logikappens tillgänglighet. I det här fallet kan den sekundära instansen ansluta till samma tjänst men ha en egen anslutning.

  • Både din primära instans och beroende resurser finns på samma plats. I det här fallet bör beroende resurser ha säkerhetskopior eller replikerade versioner på en annan plats så att den sekundära instansen fortfarande kan komma åt dessa resurser.

    Anta till exempel att din primära logikapp ansluter till en tjänst som finns på samma plats eller region, till exempel Azure SQL Database. Om hela den här regionen blir otillgänglig är Azure SQL Database-tjänsten i den regionen förmodligen inte tillgänglig. I det här fallet vill du att den sekundära instansen ska använda en replikerad eller säkerhetskopierad databas tillsammans med en separat anslutning till databasen.

Lokala datagatewayer

Om logikappen körs i Azure med flera klientorganisationer och behöver åtkomst till lokala resurser, till exempel SQL Server databaser, måste du installera den lokala datagatewayen på en lokal dator. Du kan sedan skapa en datagatewayresurs i Azure Portal så att logikappen kan använda gatewayen när du skapar en anslutning till resursen.

Datagatewayresursen är associerad med en plats eller Azure-region, precis som logikappresursen. I din strategi för haveriberedskap kontrollerar du att datagatewayen är tillgänglig för din logikapp. Du kan aktivera hög tillgänglighet för din gateway när du har flera gatewayinstallationer.

Anteckning

Om logikappen körs i en integrationstjänstmiljö (ISE) och endast använder ISE-versionerade anslutningsappar för lokala datakällor behöver du inte datagatewayen eftersom ISE-anslutningsappar ger direkt åtkomst till den lokala resursen.

Om det inte finns någon ISE-version av anslutningsappen tillgänglig för den lokala resurs som du vill använda kan logikappen fortfarande skapa anslutningen med hjälp av en icke-ISE-anslutning, som körs i den globala Azure för flera klientorganisationer, inte din ISE. Den här anslutningen kräver dock den lokala datagatewayen.

Aktiv-aktiv kontra aktiv-passiva roller

Du kan konfigurera dina primära och sekundära platser så att dina logikappinstanser på dessa platser kan spela dessa roller:

Primär-sekundär roll Description
Aktiv-aktiv De primära och sekundära logikappinstanserna på båda platserna hanterar aktivt begäranden genom att följa något av följande mönster:

- Belastningsutjämning: Du kan låta båda instanserna lyssna på en slutpunkt och belastningsutjämningstrafik till varje instans efter behov.

- Konkurrerande konsumenter: Du kan låta båda instanserna fungera som konkurrerande konsumenter så att instanserna konkurrerar om meddelanden från en kö. Om en instans misslyckas tar den andra instansen över arbetsbelastningen.
Aktiv-passiv Den primära logikappinstansen hanterar aktivt hela arbetsbelastningen, medan den sekundära instansen är passiv (inaktiverad eller inaktiv). Den sekundära väntar på en signal om att den primära är otillgänglig eller inte fungerar på grund av avbrott eller fel och tar över arbetsbelastningen som den aktiva instansen.
Kombination Vissa logikappar spelar en aktiv-aktiv roll, medan andra logikappar spelar en aktiv-passiv roll.

Aktiva exempel

De här exemplen visar den aktiva-aktiva konfigurationen där båda logikappinstanserna aktivt hanterar begäranden eller meddelanden. Något annat system eller en annan tjänst distribuerar begäranden eller meddelanden mellan instanser, till exempel något av följande alternativ:

  • En "fysisk" lastbalanserare, till exempel en maskinvara som dirigerar trafik

  • En "mjuk" lastbalanserare som Azure Load Balancer eller Azure API Management. Med API Management kan du ange principer som bestämmer hur inkommande trafik ska lastbalanseras. Eller så kan du använda en tjänst som stöder tillståndsspårning, till exempel Azure Service Bus.

    Även om det här exemplet främst visar Azure Load Balancer kan du använda det alternativ som bäst passar ditt scenarios behov:

  • Varje logikappinstans fungerar som konsument och båda instanserna konkurrerar om meddelanden från en kö:

Aktiva-passiva exempel

Det här exemplet visar den aktiva-passiva konfigurationen där den primära logikappinstansen är aktiv på en plats, medan den sekundära instansen förblir inaktiv på en annan plats. Om den primära stöter på avbrott eller fel kan du låta en operatör köra ett skript som aktiverar den sekundära för att ta sig an arbetsbelastningen.

Kombination med aktiv-aktiv och aktiv-passiv

Det här exemplet visar en kombinerad konfiguration där den primära platsen har både aktiva logikappinstanser, medan den sekundära platsen har aktiv-passiva logikappinstanser. Om den primära platsen drabbas av avbrott eller fel kan den aktiva logikappen på den sekundära platsen, som redan hanterar en partiell arbetsbelastning, ta över hela arbetsbelastningen.

  • På den primära platsen lyssnar en aktiv logikapp på en Azure Service Bus kö efter meddelanden, medan en annan aktiv logikapp söker efter e-postmeddelanden med hjälp av en Office 365 Outlook-avsökningsutlösare.

  • På den sekundära platsen fungerar en aktiv logikapp med logikappen på den primära platsen genom att lyssna och konkurrera om meddelanden från samma Service Bus-kö. Under tiden väntar en passiv inaktiv logikapp i vänteläge för att söka efter e-postmeddelanden när den primära platsen blir otillgänglig, men inaktiveras för att undvika att läsa e-postmeddelanden igen.

Kombinationen

Logikappens tillstånd och historik

När logikappen utlöses och börjar köras lagras appens tillstånd på samma plats där appen startade och kan inte överföras till en annan plats. Om ett fel eller avbrott inträffar avbryts pågående arbetsflödesinstanser. När du har konfigurerat en primär och sekundär plats börjar nya arbetsflödesinstanser köras på den sekundära platsen.

Minska övergivna pågående instanser

För att minimera antalet övergivna pågående arbetsflödesinstanser kan du välja bland olika meddelandemönster som du kan implementera, till exempel:

Åtkomst till utlösare och körningshistorik

Om du vill få mer information om logikappens tidigare arbetsflödeskörningar kan du granska appens utlösare och körningshistorik. En logikapps körningshistorik lagras på samma plats eller region där logikappen kördes, vilket innebär att du inte kan migrera den här historiken till en annan plats. Om din primära instans redundansväxlar till en sekundär instans kan du bara komma åt varje instans utlösare och köra historik på respektive plats där instanserna kördes. Du kan dock få platsagnostisk information om logikappens historik genom att konfigurera dina logikappar för att skicka diagnostikhändelser till en Azure Log Analytics-arbetsyta. Du kan sedan granska hälsotillståndet och historiken för logikappar som körs på flera platser.

Vägledning för utlösartyp

Den utlösartyp som du använder i dina logikappar avgör dina alternativ för hur du kan konfigurera logikappar på flera platser i din strategi för haveriberedskap. Här är de tillgängliga utlösartyperna som du kan använda i logikappar:

Upprepningsutlösare

Upprepningsutlösaren är oberoende av en specifik tjänst eller slutpunkt och utlöses enbart baserat på ett angivet schema och inga andra kriterier, till exempel:

  • En fast frekvens och ett fast intervall, till exempel var tionde minut
  • Ett mer avancerat schema, till exempel den sista måndagen i varje månad kl. 17:00

När logikappen börjar med en upprepningsutlösare måste du konfigurera dina primära och sekundära logikappinstanser med de aktiva-passiva rollerna. Om du vill minska återställningstidsmålet (RTO), som refererar till målvaraktigheten för att återställa en affärsprocess efter ett avbrott eller en katastrof, kan du konfigurera dina logikappinstanser med en kombination av aktiva-passiva roller och passiv-aktiva roller. I den här konfigurationen delar du upp schemat mellan platser.

Anta till exempel att du har en logikapp som måste köras var tionde minut. Du kan konfigurera dina logikappar och platser så att den sekundära platsen kan ta över arbetet om den primära platsen blir otillgänglig:

Kombinationen

  • På den primära platsen konfigurerar du aktiva-passiva roller för dessa logikappar:

    • För den aktiva aktiverade logikappen anger du upprepningsutlösaren så att den startar överst i timmen och upprepar var 20:e minut, till exempel 09:00, 09:20 och så vidare.

    • För den passiva inaktiverade logikappen anger du upprepningsutlösaren till samma schema men börjar vid 10 minuter efter timmen och upprepar var 20:e minut, till exempel 09:10, 09:30 och så vidare.

  • På den sekundära platsen konfigurerar du passiv-aktiv för dessa logikappar:

    • För den passiva inaktiverade logikappen anger du upprepningsutlösaren till samma schema som den aktiva logikappen på den primära platsen, som ligger högst upp i timmen och upprepas var 20:e minut, till exempel 09:00, 09:10 och så vidare.

    • För den aktiva aktiverade logikappen anger du upprepningsutlösaren till samma schema som den passiva logikappen på den primära platsen, som ska starta 10 minuter efter timmen och upprepas var 20:e minut, till exempel 09:10, 9:20 och så vidare.

Om en störande händelse inträffar på den primära platsen aktiverar du nu den passiva logikappen på den alternativa platsen. Om det tar tid att hitta felet begränsar den här konfigurationen antalet missade upprepningar under den fördröjningen.

Avsökningsutlösare

Om du regelbundet vill kontrollera om nya data för bearbetning är tillgängliga från en specifik tjänst eller slutpunkt kan logikappen använda en avsökningsutlösare som upprepade gånger anropar tjänsten eller slutpunkten baserat på ett fast återkommande schema. De data som tjänsten eller slutpunkten tillhandahåller kan ha någon av följande typer:

  • Statiska data, som beskriver data som alltid är tillgängliga för läsning
  • Flyktiga data, som beskriver data som inte längre är tillgängliga efter läsning

För att undvika upprepade läsningar av samma data måste logikappen komma ihåg vilka data som lästes tidigare genom att upprätthålla tillståndet antingen på klientsidan eller på server-, tjänst- eller systemsidan.

  • Logikappar som fungerar med tillstånd på klientsidan använder utlösare som kan underhålla tillståndet.

    En utlösare som läser ett nytt meddelande från en e-post-inkorg kräver till exempel att utlösaren kan komma ihåg det senast lästa meddelandet. På så sätt startar utlösaren bara logikappen när nästa olästa meddelande kommer.

  • Logikappar som fungerar med server-, tjänst- eller systemtillstånd använder egenskapsvärden eller inställningar som finns på server-, tjänst- eller systemsidan.

    Till exempel kräver en frågebaserad utlösare som läser en rad från en databas att raden har en isRead kolumn som är inställd på FALSE. Varje gång utlösaren läser en rad uppdaterar logikappen raden isRead genom att ändra kolumnen från FALSE till TRUE.

    Den här metoden på serversidan fungerar på samma sätt för Service Bus-köer eller ämnen som har kösemantik där en utlösare kan läsa och låsa ett meddelande medan logikappen bearbetar meddelandet. När logikappen har slutfört bearbetningen tar utlösaren bort meddelandet från kön eller ämnet.

När du konfigurerar logikappens primära och sekundära instanser ur ett haveriberedskapsperspektiv kontrollerar du att du tar hänsyn till dessa beteenden baserat på om logikappen spårar tillstånd på klientsidan eller på serversidan:

  • För en logikapp som fungerar med klientsidans tillstånd kontrollerar du att logikappen inte läser samma meddelande mer än en gång. Endast en plats kan ha en aktiv logikappinstans vid en viss tidpunkt. Kontrollera att logikappinstansen på den alternativa platsen är inaktiv eller inaktiverad tills den primära instansen redundansväxlar till den alternativa platsen.

    Till exempel behåller Office 365 Outlook-utlösaren klientsidans tillstånd och spårar tidsstämpeln för det senast lästa e-postmeddelandet för att undvika att läsa en dubblett.

  • För en logikapp som fungerar med serversidans tillstånd kan du konfigurera dina logikappinstanser så att de spelar antingen aktiva-aktiva roller där de fungerar som konkurrerande konsumenter eller aktiva-passiva roller där den alternativa instansen väntar tills den primära instansen redundansväxlar till den alternativa platsen.

    Till exempel använder läsning från en meddelandekö, till exempel en Azure Service Bus kö, tillståndet på serversidan eftersom kötjänsten behåller lås på meddelanden för att förhindra att andra klienter läser samma meddelanden.

    Anteckning

    Om logikappen behöver läsa meddelanden i en viss ordning, till exempel från en Service Bus-kö, kan du använda det konkurrerande konsumentmönstret men bara när det kombineras med Service Bus-sessioner, vilket även kallas sekventiell konvojmönster. Annars måste du konfigurera dina logikappinstanser med de aktiva-passiva rollerna.

Utlösare för begäran

Utlösaren Begäran gör logikappen anropbar från andra appar, tjänster och system och används vanligtvis för att tillhandahålla följande funktioner:

  • Ett direkt REST API för din logikapp som andra kan anropa

    Använd till exempel utlösaren Begäran för att starta logikappen så att andra logikappar kan anropa utlösaren med hjälp av åtgärden Anropa arbetsflöde – Logic Apps .

  • En webhook - eller återanropsmekanism för logikappen

  • Ett sätt att manuellt köra användaråtgärder eller rutiner för att anropa logikappen, till exempel med hjälp av ett PowerShell-skript som utför en viss uppgift

Ur ett katastrofåterställningsperspektiv är utlösaren Förfrågning en passiv mottagare eftersom logikappen inte utför något arbete och väntar tills någon annan tjänst eller ett annat system uttryckligen anropar utlösaren. Som en passiv slutpunkt kan du konfigurera dina primära och sekundära instanser på följande sätt:

  • Aktiv-aktiv: Båda instanserna hanterar aktivt begäranden eller anrop. Anroparen eller routern balanserar eller distribuerar trafik mellan dessa instanser.

  • Aktiv-passiv: Endast den primära instansen är aktiv och hanterar allt arbete, medan den sekundära instansen väntar tills den primära upplever avbrott eller fel. Anroparen eller routern avgör när den sekundära instansen ska anropas.

Som en rekommenderad arkitektur kan du använda Azure API Management som proxy för de logikappar som använder begärandeutlösare. API Management ger inbyggd återhämtning mellan regioner och möjlighet att dirigera trafik över flera slutpunkter.

Webhook-utlösare

En webhook-utlösare ger logikappen möjlighet att prenumerera på en tjänst genom att skicka en motringnings-URL till den tjänsten. Logikappen kan sedan lyssna och vänta tills en viss händelse inträffar på den tjänstslutpunkten. När händelsen inträffar anropar tjänsten webhook-utlösaren med hjälp av motringnings-URL:en, som sedan kör logikappen. När den är aktiverad prenumererar webhooksutlösaren på tjänsten. När den är inaktiverad avbryter utlösaren prenumerationen på tjänsten.

Ur ett haveriberedskapsperspektiv konfigurerar du primära och sekundära instanser som använder webhook-utlösare för att spela aktiv-passiva roller eftersom endast en instans ska ta emot händelser eller meddelanden från den prenumererade slutpunkten.

Utvärdera primär instanshälsa

För att haveriberedskapsstrategin ska fungera behöver lösningen olika sätt att utföra dessa uppgifter:

I det här avsnittet beskrivs en lösning som du kan använda direkt eller som en grund för din egen design. Här är en översikt över visuella objekt på hög nivå för den här lösningen:

Skapa en logikapp för övervakningsövervakning som övervakar en logikapp för hälsokontroll på den primära platsen

Kontrollera tillgängligheten för den primära instansen

För att avgöra om den primära instansen är tillgänglig, körs och kan fungera kan du skapa en "hälsokontroll"-logikapp som finns på samma plats som den primära instansen. Du kan sedan anropa den här hälsokontrollappen från en alternativ plats. Om hälsokontrollappen svarar är den underliggande infrastrukturen för Azure Logic Apps-tjänsten i den regionen tillgänglig och fungerar. Om hälsokontrollappen inte svarar kan du anta att platsen inte längre är felfri.

För den här uppgiften skapar du en grundläggande logikapp för hälsokontroll som utför följande uppgifter:

  1. Tar emot ett anrop från övervakningsappen med hjälp av begärandeutlösaren.

  2. Svara med en status som anger om den kontrollerade logikappen fortfarande fungerar med hjälp av åtgärden Svar.

    Viktigt

    Logikappen för hälsokontroll måste använda en svarsåtgärd så att appen svarar synkront, inte asynkront.

  3. Om du vill ta ytterligare reda på om den primära platsen är felfri kan du ta hänsyn till hälsotillståndet för andra tjänster som interagerar med mållogikappen på den här platsen. Expandera bara logikappen för hälsokontroll för att utvärdera hälsotillståndet för dessa andra tjänster också.

Skapa en övervakningslogikapp

Om du vill övervaka den primära instansens hälsa och anropa logikappen för hälsokontroll skapar du en "övervakningsapp" på en alternativ plats. Du kan till exempel konfigurera logikappen watchdog så att om anropet av hälsokontrolllogik misslyckas kan övervakningsenheten skicka en avisering till driftteamet så att de kan undersöka felet och varför den primära instansen inte svarar.

Viktigt

Kontrollera att din logikapp för övervakning finns på en plats som skiljer sig från den primära platsen. Om Azure Logic Apps på den primära platsen får problem kanske inte logikappens arbetsflöde för övervakningsappen körs.

För den här uppgiften, på den sekundära platsen, skapar du en logikapp för övervakningsenhet som utför följande uppgifter:

  1. Kör baserat på en fast eller schemalagd upprepning med hjälp av upprepningsutlösaren.

    Du kan ange upprepningen till ett värde som understiger toleransnivån för ditt mål för återställningstid (RTO).

  2. Anropa logikappens arbetsflöde för hälsokontroll på den primära platsen med hjälp av HTTP-åtgärden.

Du kan också skapa en mer sofistikerad logikapp för övervakning, som efter ett antal fel anropar en annan logikapp som automatiskt hanterar växling till den sekundära platsen när den primära platsen misslyckas.

Aktivera den sekundära instansen

Om du vill aktivera den sekundära instansen automatiskt kan du skapa en logikapp som anropar hanterings-API:et, till exempel Azure Resource Manager-anslutningsappen, för att aktivera lämpliga logikappar på den sekundära platsen. Du kan expandera din övervakningsapp för att anropa den här aktiveringslogikappen när ett visst antal fel inträffar.

Zonredundans med tillgänglighetszoner

I varje Azure-region är tillgänglighetszoner fysiskt separata platser som är toleranta mot lokala fel. Sådana fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Dessa zoner uppnår tolerans genom redundans och logisk isolering av Azure-tjänster.

För att ge återhämtning och distribuerad tillgänglighet finns det minst tre separata tillgänglighetszoner i alla Azure-regioner som stöder och möjliggör zonredundans. Azure Logic Apps-plattformen distribuerar dessa zoner och logikappsarbetsbelastningar mellan dessa zoner. Den här funktionen är ett viktigt krav för att aktivera motståndskraftiga arkitekturer och tillhandahålla hög tillgänglighet om datacenterfel inträffar i en region.

För närvarande är den här funktionen förhandsversion och tillgänglig för nya förbrukningslogikappar i specifika regioner. Mer information finns i följande dokumentation:

Samla in diagnostikdata

Du kan konfigurera loggning för dina logikappkörningar och skicka resulterande diagnostikdata till tjänster som Azure Storage, Azure Event Hubs och Azure Log Analytics för ytterligare hantering och bearbetning.

Nästa steg