Megosztás a következőn keresztül:

Többrégiós üzembe helyezés vészhelyreállításhoz az Azure Logic Appsben

Ez a cikk útmutatást és stratégiákat tartalmaz a többrégiós üzembe helyezés beállításához a logikai alkalmazás munkafolyamataihoz az Azure Logic Appsben. A többrégiós üzembe helyezés segít az adatok védelmében, a katasztrófák és egyéb zavaró események gyors helyreállításában, a kritikus üzleti funkciók által igényelt erőforrások visszaállításában és az üzletmenet folytonosságának fenntartásában.

Az Azure Logic Apps megbízhatósági funkcióiról, beleértve a rendelkezésre állási zónákon keresztüli régión belüli rugalmasságot is, tekintse meg az Azure Logic Apps megbízhatóságát.

Megfontolások

A logikai alkalmazás munkafolyamatai egyszerűbben integrálhatók és vezénylik az adatokat az alkalmazások, a felhőszolgáltatások és a helyszíni rendszerek között azáltal, hogy csökkentik az írandó kód mennyiségét. Ha többrégiós redundanciát tervez, győződjön meg arról, hogy nem csak a logikai alkalmazásokat, hanem a logikai alkalmazásokkal használt Azure-erőforrásokat is figyelembe veszi:

Az Azure Logic Apps megbízhatóságáról, beleértve a régión belüli rugalmasságot a rendelkezésre állási zónákon és a többrégiós üzemelő példányokon keresztül, tekintse meg az Azure Logic Apps megbízhatóságát.

Elsődleges és másodlagos üzembe helyezés

A többrégiós üzembe helyezés egy elsődleges és egy másodlagos logikai alkalmazásból áll. Az elsődleges logikai alkalmazás úgy van konfigurálva, hogy feladatátvételt végezzen a másodlagos logikai alkalmazásba egy másik régióban, ahol az Azure Logic Apps is elérhető. Így ha az elsődleges veszteségeket, fennakadásokat vagy meghibásodásokat szenved el, a másodlagos a munkát is elvégezheti. Ez az üzembe helyezési stratégia megköveteli, hogy a másodlagos logikai alkalmazás és a függő erőforrások már üzembe legyenek helyezve és készen álljanak a másodlagos régióban.

Feljegyzés

Ha a logikai alkalmazás olyan B2B-összetevőkkel is működik, mint a kereskedelmi partnerek, a megállapodások, a sémák, a térképek és a tanúsítványok, amelyek egy integrációs fiókban vannak tárolva, az integrációs fióknak és a logikai alkalmazásoknak is ugyanazt a helyet kell használniuk.

Ha követi a bevált DevOps-eljárásokat, már Bicep - vagy Azure Resource Manager-sablonokkal definiálhatja és helyezheti üzembe a logikai alkalmazásokat és azok függő erőforrásait. A Bicep- és Resource Manager-sablonok lehetővé teszik, hogy egyetlen üzembehelyezési definíciót használjon, majd paraméterfájlokkal adja meg az egyes üzembehelyezési célokhoz használandó konfigurációs értékeket. Ez a képesség azt jelenti, hogy ugyanazt a logikai alkalmazást különböző környezetekben, például fejlesztésben, tesztelésben és éles környezetben is üzembe helyezheti. Ugyanezt a logikai alkalmazást különböző Azure-régiókban is üzembe helyezheti, amelyek támogatják a többrégiós üzembe helyezéseket, például vészhelyreállítási stratégiák esetén.

Ahhoz, hogy a feladatátvétel sikeres legyen, a logikai alkalmazásoknak és a helyeknek meg kell felelniük az alábbi követelményeknek:

  • A másodlagos logikai alkalmazáspéldány ugyanazokat az alkalmazásokat, szolgáltatásokat és rendszereket érheti el, mint az elsődleges logikai alkalmazáspéldány.

  • Mindkét logikaialkalmazás-példány ugyanazzal a gazdagéptípussal rendelkezik. Így mindkét példány üzembe lesz helyezve a globális több-bérlős Azure Logic Apps vagy az egybérlős Azure Logic Apps régióiban. Ajánlott eljárások és további információk a több régió üzletmenet-folytonossági és vészhelyreállítási (BC/DR) használatáról: Régiók közötti replikáció az Azure-ban: Üzletmenet-folytonosság és vészhelyreállítás.

Példa: Több-bérlős Azure

Ez a példa az elsődleges és másodlagos logikai alkalmazáspéldányokat mutatja be, amelyek a globális több-bérlős Azure különálló régióiban vannak üzembe helyezve. Egyetlen Resource Manager-sablon határozza meg a logikai alkalmazáspéldányokat és a logikai alkalmazások által igényelt függő erőforrásokat. Külön paraméterfájlok határozzák meg az egyes üzembehelyezési helyekhez használandó konfigurációs értékeket:

Elsődleges és másodlagos logikai alkalmazáspéldányok külön helyeken

Kapcsolatok az erőforrásokhoz

Az Azure Logic Apps több mint 1000 összekötőhöz biztosít műveleteket, amelyeket a logikai alkalmazás munkafolyamata más alkalmazásokkal, szolgáltatásokkal, rendszerekkel és egyéb erőforrásokkal, például Azure Storage-fiókokkal, SQL Server-adatbázisokkal, munkahelyi vagy iskolai e-mail-fiókokkal stb. használható. Ha a logikai alkalmazásnak hozzá kell férnie ezekhez az erőforrásokhoz, olyan kapcsolatokat hozhat létre, amelyek hitelesítik az erőforrásokhoz való hozzáférést. Minden kapcsolat egy külön Azure-erőforrás, amely egy adott helyen található, és más helyeken lévő erőforrások nem használhatók.

A többrégiós redundanciastratégiához vegye figyelembe azokat a helyeket, ahol a függő erőforrások a logikai alkalmazáspéldányokhoz képest léteznek:

  • Az elsődleges példány és a függő erőforrások különböző helyeken léteznek. Ebben az esetben a másodlagos példány ugyanahhoz a függő erőforráshoz vagy végponthoz csatlakozhat. Azonban kifejezetten a másodlagos példányhoz kell kapcsolatokat létrehoznia. Így, ha az elsődleges hely elérhetetlenné válik, a másodlagos kapcsolatok nem lesznek hatással.

    Tegyük fel például, hogy az elsődleges logikai alkalmazás egy külső szolgáltatáshoz, például a Salesforce-hoz csatlakozik. A külső szolgáltatás elérhetősége és helye általában független a logikai alkalmazás elérhetőségétől. Ebben az esetben a másodlagos példány ugyanahhoz a szolgáltatáshoz csatlakozhat, de saját kapcsolattal kell rendelkeznie a másodlagos régióban.

  • Az elsődleges példány és a függő erőforrások is ugyanazon a helyen találhatók. Ebben az esetben a függő erőforrásoknak biztonsági másolatokkal vagy más helyen replikált verziókkal kell rendelkezniük, hogy a másodlagos példány továbbra is hozzáférhessen ezekhez az erőforrásokhoz.

    Tegyük fel például, hogy az elsődleges logikai alkalmazás egy ugyanazon a helyen vagy régióban található szolgáltatáshoz csatlakozik, például az Azure SQL Database-hez. Ha ez a teljes régió elérhetetlenné válik, az ebben a régióban található Azure SQL Database szolgáltatás valószínűleg nem is érhető el. Ebben az esetben azt szeretné, hogy a másodlagos példány replikált vagy biztonsági mentési adatbázist használjon a másodlagos régióban, valamint egy külön kapcsolatot az adatbázissal, amely szintén a másodlagos régióban található.

Helyszíni adatátjárók

Ha a logikai alkalmazás több-bérlős Azure-ban fut, és helyszíni erőforrásokhoz, például SQL Server-adatbázisokhoz kell hozzáférnie, telepítenie kell a helyszíni adatátjárót egy helyi számítógépen. Ezután létrehozhat egy adatátjáró-erőforrást az Azure Portalon, így a logikai alkalmazás használhatja az átjárót, amikor kapcsolatot hoz létre az erőforrással.

Az adatátjáró-erőforrás a logikai alkalmazás erőforrásához hasonlóan egy helyhez vagy Azure-régióhoz van társítva. A többrégiós redundanciastratégiában győződjön meg arról, hogy az adatátjáró elérhető marad a logikai alkalmazás számára. Ha több átjárótelepítése van, engedélyezheti az átjáró magas rendelkezésre állását.

Aktív-aktív és aktív-passzív szerepkörök

Beállíthatja az elsődleges és a másodlagos helyeket, hogy az ezeken a helyeken található logikai alkalmazáspéldányok az alábbi szerepköröket játsszák le:

Elsődleges-másodlagos szerepkör Leírás
Aktív-aktív A két helyen található elsődleges és másodlagos logikai alkalmazáspéldányok aktívan kezelik a kéréseket az alábbi minták valamelyikének követésével:

- Terheléselosztás: Mindkét példány figyelheti a végpontokat, és szükség esetén terheléselosztást végezhet az egyes példányok felé.

- Versengő fogyasztók: Mindkét példány konkurens fogyasztóként működhet, így a példányok versengenek az üzenetsorból érkező üzenetekért. Ha az egyik példány meghibásodik, a másik példány átveszi a számítási feladatot.
Aktív-passzív Az elsődleges logikai alkalmazáspéldány aktívan kezeli a teljes számítási feladatot, míg a másodlagos példány passzív (letiltva vagy inaktív). A másodlagos várakozás arra a jelzésre vár, hogy az elsődleges nem érhető el, vagy nem működik megszakítás vagy hiba miatt, és a számítási feladatot veszi át aktív példányként.
Kombináció Egyes logikai alkalmazások aktív-aktív szerepkört játszanak, míg más logikai alkalmazások aktív-passzív szerepkört játszanak.

Aktív-aktív példák

Ezek a példák azt az aktív-aktív beállítást mutatják be, ahol mindkét logikaialkalmazás-példány aktívan kezeli a kéréseket vagy üzeneteket. Néhány más rendszer vagy szolgáltatás elosztja a kéréseket vagy üzeneteket a példányok között, például az alábbi lehetőségek egyikét:

  • Egy "fizikai" terheléselosztó, például egy forgalomirányító hardver

  • Egy "puha" terheléselosztó, például az Azure Load Balancer vagy az Azure API Management. Az API Management segítségével megadhatja azokat a szabályzatokat, amelyek meghatározzák a bejövő forgalom terheléselosztását. Használhat olyan szolgáltatást is, amely támogatja az állapotkövetést, például az Azure Service Bust.

    Bár ez a példa elsősorban az Azure Load Balancert mutatja be, a forgatókönyv igényeinek leginkább megfelelő lehetőséget használhatja:

  • Minden logikaialkalmazás-példány fogyasztóként működik, és mindkét példány verseng az üzenetsorból érkező üzenetekért:

Aktív-passzív példák

Ez a példa azt az aktív-passzív beállítást mutatja be, ahol az elsődleges logikai alkalmazáspéldány aktív egy helyen, míg a másodlagos példány inaktív marad egy másik helyen. Ha az elsődleges rendszer fennakadást vagy hibát tapasztal, egy operátor futtathat egy szkriptet, amely aktiválja a másodlagost a számítási feladathoz.

Kombináció aktív-aktív és aktív-passzív

Ez a példa egy olyan kombinált beállítást mutat be, amelyben az elsődleges hely mindkét aktív logikaialkalmazás-példányt tartalmaz, míg a másodlagos helyen aktív-passzív logikai alkalmazáspéldányok találhatók. Ha az elsődleges hely fennakadást vagy hibát tapasztal, a másodlagos helyen lévő aktív logikai alkalmazás, amely már kezel egy részleges számítási feladatot, átveheti a teljes számítási feladatot.

  • Az elsődleges helyen egy aktív logikai alkalmazás figyeli az Üzenetek Azure Service Bus-üzenetsorát, míg egy másik aktív logikai alkalmazás egy Office 365 Outlook-lekérdezési eseményindító használatával ellenőrzi az e-maileket.

  • A másodlagos helyen egy aktív logikai alkalmazás az elsődleges helyen lévő logikai alkalmazással együttműködve figyeli és verseng az ugyanabból a Service Bus-üzenetsorból érkező üzenetekért. Közben egy passzív inaktív logikai alkalmazás készenléti állapotban várakozik, hogy ellenőrizze az e-maileket, amikor az elsődleges hely elérhetetlenné válik, de le van tiltva az e-mailek újraolvasásának elkerülése érdekében.

Logikai alkalmazás állapota és előzményei

Amikor a logikai alkalmazás aktiválódik és elindul, az alkalmazás állapota ugyanabban a helyen lesz tárolva, ahol az alkalmazás elindult, és nem helyezhető át egy másik helyre. Ha hiba vagy fennakadás történik, a folyamatban lévő munkafolyamat-példányok megszűnnek. Amikor beállít egy elsődleges és másodlagos helyet, az új munkafolyamat-példányok a másodlagos helyen indulnak el.

Az elhagyott folyamatban lévő példányok csökkentése

Az elhagyatott folyamatban lévő munkafolyamat-példányok számának minimalizálása érdekében különböző, implementálható üzenetminták közül választhat, például:

  • Rögzített útválasztási csúszásminta

    Ez a vállalati üzenetminta, amely kisebb szakaszokra osztja az üzleti folyamatokat. Minden fázishoz beállít egy logikai alkalmazást, amely kezeli az adott fázis számítási feladatait. Az egymással való kommunikációhoz a logikai alkalmazások aszinkron üzenetkezelési protokollt használnak, például Azure Service Bus-üzenetsorokat vagy témaköröket. Ha egy folyamatot kisebb szakaszokra oszt, csökkentheti a sikertelen logikai alkalmazáspéldányokon elakadó üzleti folyamatok számát. A mintával kapcsolatos általános információkért lásd : Vállalati integrációs minták – Útválasztási csúsztatás.

    Ez a példa egy útválasztási csúszásmintát mutat be, amelyben minden logikai alkalmazás egy szakaszt jelöl, és egy Service Bus-üzenetsor használatával kommunikál a folyamat következő logikai alkalmazásával.

    Üzleti folyamat felosztása logikai alkalmazások által képviselt szakaszokra, amelyek az Azure Service Bus-üzenetsorok használatával kommunikálnak egymással

    Ha az elsődleges és a másodlagos logikai alkalmazáspéldányok is ugyanazt az útválasztási csúszásmintát követik a helyükön, akkor a konkurens fogyasztói mintát úgy implementálhatja, hogy aktív-aktív szerepköröket állít be ezekhez a példányokhoz.

  • Folyamatkezelői (közvetítői) minta

  • Betekintő-zárolás időtúllépési minta nélkül

Hozzáférés az eseményindítóhoz és futtatási előzményekhez

Ha további információt szeretne kapni a logikai alkalmazás korábbi munkafolyamat-végrehajtásairól, áttekintheti az alkalmazás eseményindítóját, és futtathatja az előzményeket. A logikai alkalmazások végrehajtási előzményei ugyanabban a helyen vagy régióban vannak tárolva, ahol a logikai alkalmazás futott, ami azt jelenti, hogy nem migrálhatja ezt az előzményt egy másik helyre. Ha az elsődleges példány egy másodlagos példánynak nem adhatja át a feladatátvételt, csak az egyes példányok eseményindítójához férhet hozzá, és az előzményeket azokon a helyeken futtathatja, ahol a példányok futottak. A logikai alkalmazás előzményeiről azonban helyinformációkat kaphat, ha beállítja a logikai alkalmazásokat, hogy diagnosztikai eseményeket küldjön egy Azure Log Analytics-munkaterületre. Ezután áttekintheti a több helyen futó logikai alkalmazások állapotát és előzményeit.

Eseményindító típusának útmutatója

A logikai alkalmazásokban használt triggertípus határozza meg, hogyan állíthat be logikai alkalmazásokat különböző helyeken vészhelyreállítási stratégiában. Az alábbi triggertípusok használhatók a logikaialkalmazás-munkafolyamatokban:

Ismétlődési eseményindító

Az ismétlődési eseményindító független bármely adott szolgáltatástól vagy végponttól, és kizárólag egy megadott ütemezésen és egyéb feltételeken alapul, például:

  • Rögzített gyakoriság és intervallum, például 10 percenként
  • Speciálisabb ütemezés, például minden hónap utolsó hétfője 17:00-kor

Amikor a logikai alkalmazás ismétlődési eseményindítóval indul, be kell állítania az elsődleges és a másodlagos logikai alkalmazáspéldányokat az aktív-passzív szerepkörökkel. A helyreállítási idő célkitűzésének (RTO) csökkentése érdekében, amely egy üzleti folyamat megszakítás vagy katasztrófa utáni visszaállításának célidejű időtartamára vonatkozik, beállíthatja a logikai alkalmazáspéldányokat aktív-passzív szerepkörök és passzív-aktív szerepkörök kombinációjával. Ebben a beállításban felosztja az ütemezést a helyek között.

Tegyük fel például, hogy rendelkezik egy logikai alkalmazással, amelyet 10 percenként kell futtatnia. Beállíthatja a logikai alkalmazásokat és helyeket, hogy ha az elsődleges hely elérhetetlenné válik, a másodlagos hely átvehesse a munkát:

  • Az elsődleges helyen állítsa be az aktív-passzív szerepköröket ezekhez a logikai alkalmazásokhoz:

    • Az aktív engedélyezett logikai alkalmazás esetében állítsa az Ismétlődés eseményindítót az óra tetején való kezdésre, és ismételje meg 20 percenként, például 9:00-kor, 9:20-kor stb.

    • A passzív letiltott logikai alkalmazás esetében állítsa az Ismétlődés eseményindítót ugyanarra az ütemezésre, de az óra 10 perccel korábbi időpontban kezdődjön, és 20 percenként ismételje meg, például 9:10-kor, 9:30-kor stb.

  • A másodlagos helyen állítsa be a passzív-aktív beállítást ezekhez a logikai alkalmazásokhoz:

    • A passzív letiltott logikai alkalmazás esetében állítsa az Ismétlődés eseményindítót az elsődleges helyen található aktív logikai alkalmazással megegyező ütemezésre, amely az óra tetején van, és 20 percenként ismétlődik, például 9:00, 9:10 stb.

    • Az aktív engedélyezett logikai alkalmazás esetében állítsa az Ismétlődés eseményindítót az elsődleges helyen található passzív logikai alkalmazással megegyező ütemezésre, amely az óra 10 percénél kezdődik, és 20 percenként ismétlődik, például 9:10, 9:20 és így tovább.

Most, ha egy zavaró esemény történik az elsődleges helyen, aktiválja a passzív logikai alkalmazást a másodlagos helyen. Így, ha a hiba megkeresése időt vesz igénybe, ez a beállítás korlátozza az elmulasztott ismétlődések számát a késés során.

Lekérdezési eseményindító

Ha rendszeresen ellenőrizni szeretné, hogy az új adatok egy adott szolgáltatásból vagy végpontról érhetők-e el, a logikai alkalmazás használhat egy lekérdezési eseményindítót, amely rögzített ismétlődési ütemezés alapján ismételten meghívja a szolgáltatást vagy a végpontot. A szolgáltatás vagy végpont által biztosított adatok az alábbi típusúak lehetnek:

  • Statikus adatok, amelyek az olvasáshoz mindig elérhető adatokat írják le
  • Illékony adatok, amelyek olyan adatokat írnak le, amelyek olvasás után már nem érhetők el

Az adatok ismételt olvasásának elkerülése érdekében a logikai alkalmazásnak emlékeznie kell arra, hogy mely adatokat olvasták be korábban az ügyféloldalon, illetve a kiszolgáló, a szolgáltatás vagy a rendszeroldal állapotának fenntartásával.

  • Az ügyféloldali állapottal dolgozó logikai alkalmazások olyan eseményindítókat használnak, amelyek képesek fenntartani az állapotot.

    Ha például egy eseményindító új üzenetet olvas be egy e-mail-postaládából, az eseményindítónak emlékeznie kell a legutóbb olvasott üzenetre. Így az eseményindító csak a következő olvasatlan üzenet érkezésekor indítja el a logikai alkalmazást.

  • A kiszolgálói, szolgáltatási vagy rendszeroldali állapottal dolgozó logikai alkalmazások a kiszolgáló, a szolgáltatás vagy a rendszer oldalán található tulajdonságértékeket vagy beállításokat használják.

    Egy lekérdezésalapú eseményindítóhoz például, amely beolvassa a sorokat egy adatbázisból, a sornak rendelkeznie kell egy isRead olyan oszloppal, amely a következőre FALSEvan állítva. Minden alkalommal, amikor az eseményindító beolvassa a sorokat, a logikai alkalmazás frissíti a sort úgy, hogy az oszlopot isRead a FALSE következőre TRUEmódosítja.

    Ez a kiszolgálóoldali megközelítés hasonlóan működik a Service Bus-üzenetsorokhoz vagy olyan témakörökhöz, amelyek sorbaállási szemantikával rendelkeznek, ahol az eseményindítók elolvashatnak és zárolhatnak egy üzenetet, miközben a logikai alkalmazás feldolgozza az üzenetet. Amikor a logikai alkalmazás befejezi a feldolgozást, az eseményindító törli az üzenetet az üzenetsorból vagy a témakörből.

Vészhelyreállítás szempontjából, amikor beállítja a logikai alkalmazás elsődleges és másodlagos példányait, győződjön meg arról, hogy ezeket a viselkedéseket figyelembe veszi attól függően, hogy a logikai alkalmazás nyomon követi-e az ügyféloldali vagy a kiszolgálóoldali állapotot:

  • Ügyféloldali állapottal működő logikai alkalmazások esetén győződjön meg arról, hogy a logikai alkalmazás nem olvassa el többször ugyanazt az üzenetet. Egy adott időpontban csak egy helyen lehet aktív logikai alkalmazáspéldány. Győződjön meg arról, hogy a másik helyen lévő logikai alkalmazáspéldány inaktív vagy le van tiltva, amíg az elsődleges példány nem kerül át a másik helyre.

    Az Office 365 Outlook-eseményindító például fenntartja az ügyféloldali állapotot, és nyomon követi a legutóbbi olvasási e-mailek időbélyegét, hogy elkerülje az ismétlődő üzenetek olvasását.

  • A kiszolgálóoldali állapottal működő logikai alkalmazások esetében beállíthatja, hogy a logikaialkalmazás-példányok aktív-aktív szerepköröket játsszanak le, ahol versengő felhasználókként dolgoznak, vagy aktív-passzív szerepkörökként, ahol a másodlagos példány megvárja, amíg az elsődleges példány át nem kerül a másik helyre.

    Az üzenetsorból (például egy Azure Service Bus-üzenetsorból) való olvasás például kiszolgálóoldali állapotot használ, mivel a sorba állítási szolgáltatás zárolja az üzeneteket, hogy más ügyfelek ne olvassák ugyanazokat az üzeneteket.

    Feljegyzés

    Ha a logikai alkalmazásnak egy adott sorrendben kell olvasnia az üzeneteket, például egy Service Bus-üzenetsorból, használhatja a versengő fogyasztói mintát, de csak a Service Bus-munkamenetekkel kombinálva, amelyet szekvenciális konvojmintának is neveznek. Ellenkező esetben a logikai alkalmazáspéldányokat aktív-passzív szerepkörökkel kell beállítania.

Kérelem eseményindítója

A Kérés eseményindítója meghívhatóvá teszi a logikai alkalmazást más alkalmazásokból, szolgáltatásokból és rendszerekből, és általában az alábbi képességek biztosítására szolgál:

  • Közvetlen REST API a logikai alkalmazáshoz, amelyet mások meghívhatnak

    A Kérelem eseményindítóval például elindíthatja a logikai alkalmazást, hogy más logikai alkalmazások meghívhassák az eseményindítót a Hívás munkafolyamat – Logic Apps művelet használatával.

  • Webhook- vagy visszahívási mechanizmus a logikai alkalmazáshoz

  • Olyan módszer, amellyel manuálisan futtathatja a felhasználói műveleteket vagy rutinokat a logikai alkalmazás meghívásához, például egy adott feladatot végrehajtó PowerShell-szkript használatával

Vészhelyreállítási szempontból a Kérelem eseményindító egy passzív fogadó, mivel a logikai alkalmazás nem végez semmilyen munkát, és megvárja, amíg más szolgáltatás vagy rendszer explicit módon meghívja az eseményindítót. Passzív végpontként az alábbi módokon állíthatja be az elsődleges és a másodlagos példányokat:

  • Aktív-aktív: Mindkét példány aktívan kezeli a kéréseket vagy hívásokat. A hívó vagy az útválasztó kiegyensúlyozza vagy elosztja a forgalmat a példányok között.

  • Aktív-passzív: Csak az elsődleges példány aktív, és kezeli az összes munkát, míg a másodlagos példány megvárja, amíg az elsődleges szolgáltatás megszakad vagy meghibásodik. A hívó vagy az útválasztó határozza meg, hogy mikor hívja meg a másodlagos példányt.

Ajánlott architektúraként az Azure API Managementet proxyként használhatja a Kérelem eseményindítókat használó logikai alkalmazásokhoz. Az API Management beépített régiók közötti rugalmasságot biztosít , és lehetővé teszi a forgalom több végpont közötti átirányítását.

Webhook-eseményindító

A webhook-eseményindító lehetővé teszi, hogy a logikai alkalmazás feliratkozzon egy szolgáltatásra egy visszahívási URL-címnek a szolgáltatásnak való átadásával. A logikai alkalmazás ezután figyelheti és megvárhatja, amíg egy adott esemény bekövetkezik az adott szolgáltatásvégponton. Az esemény bekövetkezésekor a szolgáltatás meghívja a webhook-eseményindítót a visszahívási URL-cím használatával, amely ezután futtatja a logikai alkalmazást. Ha engedélyezve van, a webhook-eseményindító feliratkozik a szolgáltatásra. Ha le van tiltva, az eseményindító leiratkozik a szolgáltatásról.

Vészhelyreállítás szempontjából állítson be olyan elsődleges és másodlagos példányokat, amelyek webhook-eseményindítókat használnak az aktív-passzív szerepkörök lejátszásához, mert csak egy példánynak kell eseményeket vagy üzeneteket fogadnia az előfizetett végpontról.

Elsődleges példány állapotának felmérése

A többrégiós feladatátvételi stratégia működéséhez a megoldásnak a következő feladatok végrehajtására van szüksége:

Ez a szakasz egy olyan megoldást ír le, amelyet akár nyíltan, akár saját tervezésének alapjaként is használhat. A megoldás magas szintű vizualizációs áttekintése:

Watchdog logikai alkalmazás létrehozása, amely egy állapot-ellenőrző logikai alkalmazást figyel az elsődleges helyen

Az elsődleges példány rendelkezésre állásának ellenőrzése

Annak megállapításához, hogy az elsődleges példány elérhető, futtatható és használható-e, létrehozhat egy állapotellenőrzési logikai alkalmazást, amely az elsődleges példánysal azonos helyen található. Ezután meghívhatja ezt az állapot-ellenőrző alkalmazást egy másik helyről. Ha az állapot-ellenőrző alkalmazás sikeresen válaszol, az adott régióban található Azure Logic Apps szolgáltatás mögöttes infrastruktúrája elérhető és működik. Ha az állapot-ellenőrző alkalmazás nem válaszol, feltételezheti, hogy a hely már nem kifogástalan.

Ehhez a feladathoz hozzon létre egy alapszintű állapotellenőrzési logikai alkalmazást, amely az alábbi feladatokat hajtja végre:

  1. Hívást fogad a watchdog alkalmazástól a Kérés eseményindító használatával.

  2. Válasz olyan állapottal, amely jelzi, hogy az ellenőrzött logikai alkalmazás továbbra is működik-e a Válasz művelettel.

    Fontos

    Az állapot-ellenőrző logikai alkalmazásnak válaszműveletet kell használnia, hogy az alkalmazás szinkron módon, nem aszinkron módon válaszoljon.

  3. Ha szeretné tovább meghatározni, hogy az elsődleges hely kifogástalan-e, az ezen a helyen található céllogikaalkalmazással interakcióba lépő egyéb szolgáltatások állapotát is figyelembe vehet. Csak bontsa ki az állapot-ellenőrző logikai alkalmazást, hogy felmérje a többi szolgáltatás állapotát is.

Watchdog logikai alkalmazás létrehozása

Az elsődleges példány állapotának figyeléséhez és az állapot-ellenőrző logikai alkalmazás meghívásához hozzon létre egy "watchdog" logikai alkalmazást egy másik helyen. Beállíthatja például a watchdog logikai alkalmazást, hogy ha az állapot-ellenőrző logika meghívása meghiúsul, a figyelő riasztást küldhet az operatív csapatnak, hogy kivizsgálhassák a hibát, és hogy miért nem válaszol az elsődleges példány.

Fontos

Győződjön meg arról, hogy a watchdog logikai alkalmazás az elsődleges helytől eltérő helyen található. Ha az elsődleges helyen található Azure Logic Apps problémákat tapasztal, előfordulhat, hogy a watchdog logikai alkalmazás munkafolyamata nem fut.

Ehhez a feladathoz a másodlagos helyen hozzon létre egy watchdog logikai alkalmazást, amely az alábbi feladatokat hajtja végre:

  1. Futtatás rögzített vagy ütemezett ismétlődés alapján az Ismétlődés eseményindítóval.

    Az ismétlődést beállíthatja olyan értékre, amely a helyreállítási időkorlát (RTO) tűrésszintje alatt van.

  2. Hívja meg az állapot-ellenőrző logikai alkalmazás munkafolyamatát az elsődleges helyen a HTTP-művelet használatával.

Létrehozhat egy kifinomultabb watchdog logikai alkalmazást is, amely számos hiba után meghív egy másik logikai alkalmazást, amely automatikusan kezeli a másodlagos helyre való váltást, amikor az elsődleges sikertelen.

Másodlagos példány aktiválása

A másodlagos példány automatikus aktiválásához létrehozhat egy logikai alkalmazást, amely meghívja a felügyeleti API-t, például az Azure Resource Manager-összekötőt , hogy aktiválja a megfelelő logikai alkalmazásokat a másodlagos helyen. A watchdog-alkalmazás kibontásával meghívhatja ezt az aktiválási logikai alkalmazást egy adott számú hiba bekövetkezése után.

Diagnosztikai adatok gyűjtése

Beállíthat naplózást a logikai alkalmazás futtatásához, és elküldheti az így kapott diagnosztikai adatokat olyan szolgáltatásoknak, mint az Azure Storage, az Azure Event Hubs és az Azure Log Analytics a további kezeléshez és feldolgozáshoz.

Következő lépések

  • Last updated on