Dela via

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, se till att du har en haveriberedskapslösning (DR) på plats så att du kan skydda data, snabbt återställa de resurser som stöder kritiska affärsfunktioner och hålla driften 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 lagrings-, nätverks- 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 svara snabbare på avbrott, planerade eller oplanerade och minska stilleståndstiden för dina kunder.

Den här artikeln innehåller BCDR-riktlinjer 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, till exempel en Azure-region, till exempel "USA, västra". Den här haveriberedskapsstrategin fokuserar på att konfigurera din primära logikapp för redundansväxling till en standby- eller säkerhetskopieringslogikapp på en alternativ 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 redo på den alternativa platsen.

Kommentar

Om logikappen även 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 använda samma plats.

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. Med Resource Manager-mallar kan du 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, som stöder strategier för haveriberedskap som använder kopplade regioner.

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

  • Den sekundära logikappsinstansen har åtkomst till samma appar, tjänster och system som den primära logikappsinstansen.

  • Båda logikappinstanserna har samma värdtyp. Båda instanserna distribueras därför till regioner i globala Azure Logic Apps med flera klienter eller regioner i Azure Logic Apps med en enda klientorganisation. Metodtips och mer information om kopplade regioner för BCDR finns i Replikering mellan regioner i Azure: Affärskontinuitet och haveriberedskap.

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 med flera klientorganisationer för det här scenariot. En enskild 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

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 strategi för haveriberedskap 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ära anslutningen om den primära platsen blir otillgänglig.

    Anta till exempel att din primära logikapp ansluter till en extern tjänst, till exempel 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 regionen blir otillgänglig är Azure SQL Database-tjänsten i den regionen sannolikt också otillgänglig. I det här fallet vill du att den sekundära instansen ska använda en replikerad databas eller en säkerhetskopia 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-portalen 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 din logikappresurs. 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.

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 upp följande roller:

Primär-sekundär roll beskrivning
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 logikappsinstansen 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 avgör 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ö:

Aktiv-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 det uppstår ett avbrott eller ett fel i den primära enheten kan du låta en operatör köra ett skript som aktiverar den sekundära för att ta sig an arbetsbelastningen.

Konfiguration av

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 tävla om meddelanden från samma Service Bus-kö. Samtidigt 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.

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 eventuella 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:

  • Mönster för fast routningslista

    Det här företagsmeddelandemönstret som delar upp en affärsprocess i mindre faser. För varje steg konfigurerar du en logikapp som hanterar arbetsbelastningen för den fasen. För att kommunicera med varandra använder dina logikappar ett asynkront meddelandeprotokoll, till exempel Azure Service Bus-köer eller ämnen. När du delar in en process i mindre steg minskar du antalet affärsprocesser som kan fastna på en misslyckad logikappinstans. Mer allmän information om det här mönstret finns i Enterprise Integration Patterns – Routningslista.

    Det här exemplet visar ett mönster för routningssedlar där varje logikapp representerar en fas och använder en Service Bus-kö för att kommunicera med nästa logikapp i processen.

    Dela upp en affärsprocess i faser som representeras av logikappar som kommunicerar med varandra med hjälp av Azure Service Bus-köer

    Om både primära och sekundära logikappinstanser följer samma mönster för routningssnedsteg på sina platser kan du implementera det konkurrerande konsumentmönstret genom att konfigurera aktiva-aktiva roller för dessa instanser.

  • Processhanterarens (broker) mönster

  • Peek-lock utan timeout-mönster

Åtkomst till utlösare och körningshistorik

Om du vill ha 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 dessa instanser 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å olika platser i din strategi för haveriberedskap. Här är de tillgängliga utlösartyperna som du kan använda i logikappar:

Återkomstutlö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 10:e 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 målet för återställningstid (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 aktiv-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 10:e 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 högst upp i timmen och upprepar var 20:e minut, till exempel 09:00, 09:20 och så vidare.

    • För logikappen passivt inaktiverad 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 är 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 upprepa var 20:e minut, till exempel 09:10, 09: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.

Sökningsutlösare

Om du regelbundet vill kontrollera om nya data för bearbetning är tillgängliga från en viss 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 upprepningsschema. 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 att läsa samma data upprepade gånger måste logikappen komma ihåg vilka data som tidigare lästes genom att underhålla tillstånd 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ånd.

    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 logikappen först 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.

    En frågebaserad utlösare som läser en rad från en databas kräver till exempel att raden har en isRead kolumn som är inställd på FALSE. Varje gång utlösaren läser en rad uppdaterar logikappen raden genom att ändra isRead 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 bör du se till 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 logikappsinstansen på den alternativa platsen är inaktiv eller inaktiverad tills den primära instansen redundansväxlar till den alternativa platsen.

    Office 365 Outlook-utlösaren upprätthåller till exempel tillståndet på klientsidan 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 över till den alternativa platsen.

    Om du till exempel läser från en meddelandekö, till exempel en Azure Service Bus-kö, används tillstånd på serversidan eftersom kötjänsten behåller lås på meddelanden för att förhindra att andra klienter läser samma meddelanden.

    Kommentar

    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 Förfrågning gör logikappen anropsbar 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 Samtalsarbetsflö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 specifik 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 något 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 händelsen stör eller misslyckas. 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 utlösare för begäran. API Management ger inbyggd korsregional återhämtning 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 specifik händelse inträffar på tjänstslutpunkten. När händelsen inträffar anropar tjänsten webhookens utlösare 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 din strategi för haveriberedskap 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 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 logikapp för vakthundar 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 utlösaren Förfrågning.

  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 ytterligare avgöra 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 logikapp för vakthundar

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 för vakthundar så att om anropet av hälsokontrolllogik misslyckas kan vakthunden 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 vakthundar 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 arbetsflödet för logikappen för vakthundar körs.

För den här uppgiften skapar du en övervakningslogikapp på den sekundära platsen 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 arbetsflödet för logikappen för hälsokontroll på den primära platsen med hjälp av HTTP-åtgärden.

Du kan också skapa en mer avancerad logikapp för vakthundar, som efter ett antal fel anropar en annan logikapp som automatiskt hanterar växling till den sekundära platsen när den primära datorn 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 variera 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 minst tre separata tillgänglighetszoner i alla Azure-regioner som stöder och aktiverar 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 elastiska arkitekturer och ge 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