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

Üzletmenet-folytonosság és vészhelyreállítás az Azure Logic Appshez

  • Cikk

A kiszámíthatatlan események vállalkozásra és ügyfelekre gyakorolt hatásának csökkentése érdekében győződjön meg arról, hogy vészhelyreállítási (DR) megoldással rendelkezik az adatok védelme érdekében, gyorsan visszaállíthatja a kritikus üzleti funkciókat támogató erőforrásokat, és az üzletmenet-folytonosság (BC) fenntartása érdekében folyamatosan futtassa a műveleteket. A fennakadások közé tartozhatnak például a leállások, a mögöttes infrastruktúra vagy összetevők , például a tárolási, hálózati vagy számítási erőforrások, a helyreállíthatatlan alkalmazáshibák vagy akár a teljes adatközpont-veszteség. Az üzletmenet-folytonossági és vészhelyreállítási (BCDR) megoldás készen áll, a vállalat vagy a szervezet gyorsabban reagálhat a megszakításokra, a tervezett vagy a nem tervezett problémákra, és csökkentheti az ügyfelek állásidejét.

Ez a cikk BCDR-útmutatást és stratégiákat tartalmaz, amelyeket akkor alkalmazhat, ha automatizált munkafolyamatokat hoz létre az Azure Logic Apps használatával. 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. A BCDR tervezésekor 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:

Elsődleges és másodlagos helyek

Minden logikai alkalmazásnak meg kell adnia az üzembe helyezéshez használni kívánt helyet. Ez a hely vagy egy nyilvános régió a globális több-bérlős Azure-ban, például az "USA nyugati régiója", vagy egy integrációs szolgáltatási környezet (ISE), amelyet korábban létrehozott és üzembe helyezett egy Azure-beli virtuális hálózaton. A logikai alkalmazások ISE-ben való futtatása hasonló a globális Azure-régióban futó logikai alkalmazásokhoz, ami azt jelenti, hogy a vészhelyreállítási stratégia mindkét forgatókönyvre alkalmazható. Az ISE-k azonban más szempontokat is figyelembe vetek, például a csak az ISE-k számára elérhető erőforrásokhoz való hozzáférés konfigurálását.

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

Ez a vészhelyreállítási stratégia az elsődleges logikai alkalmazás feladatátvételének beállítására összpontosít egy készenléti vagy biztonsági mentési logikai alkalmazásra egy alternatív helyen, 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 a 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ásik helyen.

Ha követi a bevált DevOps-eljárásokat, már Azure Resource Manager-sablonokkal definiálhatja és üzembe helyezheti a logikai alkalmazásokat és azok függő erőforrásait. A 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 vagy ISE-kben is üzembe helyezheti, amelyek támogatják a párosított régiókat használó vészhelyreállítási stratégiákat.

A feladatátvételi stratégia esetében a logikai alkalmazásoknak és 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. Tehát mindkét példány a globális több-bérlős Azure régióiban van üzembe helyezve, vagy mindkét példány az ISE-kben van üzembe helyezve, ami lehetővé teszi, hogy a logikai alkalmazások közvetlenül hozzáférjenek egy Azure-beli virtuális hálózat erőforrásaihoz. A BCDR párosított régióival kapcsolatos ajánlott eljárásokért és további információkért lásd : Régiók közötti replikáció az Azure-ban: Üzletmenet-folytonosság és vészhelyreállítás.

    Például az elsődleges és a másodlagos helynek ISE-nek kell lennie, ha az elsődleges logikai alkalmazás ISE-ben fut, és ISE-verziójú összekötőkkel, HTTP-műveletekkel hívja meg az Azure-beli virtuális hálózaton lévő erőforrásokat, vagy mindkettőt. Ebben a forgatókönyvben a másodlagos logikai alkalmazásnak hasonló beállítással kell rendelkeznie a másodlagos helyen, mint az elsődleges logikai alkalmazás.

    Feljegyzés

    Speciálisabb forgatókönyvek esetén a több-bérlős Azure-t és az ISE-t is kombinálhatja helyekként. Ügyeljen azonban arra, hogy figyelembe vegye és megértse az ISE-ben és a több-bérlős Azure-ban futtatott logikai alkalmazások közötti különbségeket.

  • Ha ISE-ket használ, győződjön meg arról, hogy felskálázzák őket, vagy elegendő kapacitással rendelkeznek a terhelés kezeléséhez.

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önböző régióiban vannak üzembe helyezve ebben a forgatókönyvben. 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

Példa: Integrációs szolgáltatási környezet

Ez a példa az előző elsődleges és másodlagos logikai alkalmazáspéldányokat mutatja be, de külön ISE-kben van üzembe helyezve. Egyetlen Resource Manager-sablon határozza meg a logikai alkalmazáspéldányokat, a logikai alkalmazások által igényelt függő erőforrásokat és az ISE-ket üzembehelyezési helyként. Az egyes helyeken az üzembe helyezéshez használandó konfigurációs értékeket külön paraméterfájlok határozzák meg:

Elsődleges és másodlagos logikai alkalmazások különböző helyeken

Kapcsolatok az erőforrásokhoz

Az Azure Logic Apps több száz összekötőműveletet biztosít, amelyekkel a logikai alkalmazás munkafolyamata más alkalmazásokkal, szolgáltatásokkal, rendszerekkel és más erőforrásokkal, például Azure Storage-fiókokkal, SQL Server-adatbázisokkal, munkahelyi vagy iskolai e-mail-fiókokkal stb. dolgozhat. 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 vészhelyreállítási straté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.

  • 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 az adatbázishoz való külön kapcsolattal együtt.

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 vészhelyreállítási straté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.

Feljegyzés

Ha a logikai alkalmazás integrációs szolgáltatási környezetben (ISE) fut, és csak ISE-verziójú összekötőket használ a helyszíni adatforrásokhoz, nincs szüksége az adatátjáróra, mert az ISE-összekötők közvetlen hozzáférést biztosítanak a helyszíni erőforráshoz.

Ha a kívánt helyszíni erőforráshoz nem érhető el ISE-verziójú összekötő, a logikai alkalmazás továbbra is létrehozhatja a kapcsolatot egy nem ISE-összekötő használatával, amely a globális több-bérlős Azure-ban fut, nem az ISE-ben. Ehhez a kapcsolathoz azonban szükség van a helyszíni adatátjáróra.

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 eseményindító-típus határozza meg, hogyan állíthat be logikai alkalmazásokat a vészhelyreállítási stratégiában különböző helyeken. A logikai alkalmazásokban az alábbi triggertípusok használhatók:

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 FALSE a isRead 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 vészhelyreállítási 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.

Zónaredundancia rendelkezésre állási zónákkal

Minden Azure-régióban a rendelkezésre állási zónák fizikailag különálló helyek, amelyek tolerálják a helyi hibákat. Az ilyen hibák a szoftver- és hardverhibáktól kezdve az olyan eseményekig terjedhetnek, mint a földrengések, árvizek és tüzek. Ezek a zónák az Azure-szolgáltatások redundanciája és logikai elkülönítése révén tűréshatárt érnek el.

A rugalmasság és az elosztott rendelkezésre állás biztosítása érdekében legalább három különálló rendelkezésre állási zóna létezik minden olyan Azure-régióban, amely támogatja és engedélyezi a zónaredundanciát. Az Azure Logic Apps platform ezeket a zónákat és logikai alkalmazások számítási feladatait osztja el ezeken a zónákon. Ez a képesség kulcsfontosságú követelmény a rugalmas architektúrák engedélyezéséhez és a magas rendelkezésre állás biztosításához, ha adatközpont-hibák történnek egy régióban.

Ez a funkció jelenleg előzetes verzióban érhető el, és adott régiókban elérhető az új használatlogika-alkalmazásokhoz. További információkért tekintse meg a következő dokumentációt:

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