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

  • Cikk

A kiszámíthatatlan események üzletmenetre és ügyfelekre gyakorolt hatásának és hatásainak 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, a kritikus üzleti funkciókat támogató erőforrások gyors visszaállítása és az üzletmenet-folytonosság (BC) fenntartása érdekében. A fennakadások közé tartozhatnak például a kimaradások, a mögöttes infrastruktúrában vagy összetevőkben, például a tárolásban, a hálózatban vagy a számítási erőforrásokban bekövetkező veszteségek, a helyreállíthatatlan alkalmazáshibák vagy akár az adatközpont teljes elvesztése. Ha egy üzletmenet-folytonossági és vészhelyreállítási (BCDR) megoldás készen áll, a vállalata vagy szervezete gyorsabban reagálhat a megszakításokra, a tervezett vagy nem tervezett eseményekre, és csökkentheti az állásidőt az ügyfelek számára.

Ez a cikk olyan BCDR-útmutatókat és stratégiákat tartalmaz, amelyeket az Azure Logic Apps használatával automatizált munkafolyamatok létrehozásakor alkalmazhat. A logikai alkalmazás munkafolyamatai egyszerűbben integrálhatók és vezényelhetőek 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 egy Azure-beli virtuális hálózaton hozott létre és helyezett üzembe. A logikai alkalmazások ISE-ben való futtatása hasonló a logikai alkalmazások globális Azure-régióban való futtatásához, 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.

Megjegyzés

Ha a logikai alkalmazás olyan B2B-összetevőkkel is működik, mint a kereskedelmi partnerek, a szerződések, 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ásnak a feladatátvétel készenléti vagy biztonsági mentési logikai alkalmazásra való beállítására összpontosít egy alternatív helyen, ahol az Azure Logic Apps is elérhető. Így, ha az elsődleges veszteségeket, fennakadásokat vagy hibákat szenved el, a másodlagos átveheti a munkát. Ehhez a stratégiához szükséges, hogy a másodlagos logikai alkalmazás és a függő erőforrások már üzembe legyenek helyezve, és készen legyenek az alternatív helyen.

Ha követi a bevált DevOps-eljárásokat, az Azure Resource Manager-sablonokkal definiálhatja és üzembe helyezheti a logikai alkalmazásokat és azok függő erőforrásait. 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 a helyeknek meg kell felelniük az alábbi követelményeknek:

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 ebben a forgatókönyvben 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 logikaialkalmazás-pé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 logikaialkalmazás-példányokat mutatja be, de különálló ISE-kben van üzembe helyezve. Egyetlen Resource Manager sablon határozza meg a logikaialkalmazás-pé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 történő ü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 számos 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álhatjá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ás példányaihoz 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 tud csatlakozni. 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 rendelkezésre állásá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 más helyen kell biztonsági másolatokkal vagy replikált verziókkal 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 lévő szolgáltatáshoz csatlakozik, például Azure SQL Database. Ha ez a teljes régió elérhetetlenné válik, a régióban lévő Azure SQL Adatbázis 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, valamint egy külön kapcsolatot az adatbázissal.

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épre. Ezután létrehozhat egy adatátjáró-erőforrást a Azure Portal, í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. Több átjáró telepítése esetén engedélyezheti a magas rendelkezésre állást az átjáró számára .

Megjegyzé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, mivel 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 pedig az ISE-n keresztül. 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 a logikaialkalmazás-példányok ezeken a helyeken le tudják játszani ezeket a szerepköröket:

Elsődleges-másodlagos szerepkör Leírás
Aktív-aktív Az elsődleges és a másodlagos logikai alkalmazáspéldányok mindkét helyen aktívan kezelik a kéréseket az alábbi minták egyikével:

- Terheléselosztás: Mindkét példány figyelhet egy végpontot, é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 versenghetnek az üzenetsorból érkező üzenetekért. Ha az egyik példány meghibásodik, a másik példány veszi át 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 (letiltott vagy inaktív). A másodlagos várakozás arra a jelzésre, hogy az elsődleges példány 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 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 osztja el 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 olyan hardver, amely a forgalmat irányítja

  • "puha" terheléselosztó, például Azure Load Balancer vagy Azure API Management. A API Management 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 Azure Service Bus.

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

  • 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 logikaialkalmazás-pé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ánysal rendelkezik, míg a másodlagos helyen aktív-passzív logikaialkalmazás-pé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ó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ő üzeneteket. 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. Hiba vagy fennakadás esetén a folyamatban lévő munkafolyamat-példányok elhagyhatók. Amikor beállít egy elsődleges és másodlagos helyet, az új munkafolyamat-példányok a másodlagos helyen indulnak el.

Az elhagyatott 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 az adott fázis számítási feladatait kezeli. 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 az olyan üzleti folyamatok számát, amelyek elakadhatnak egy sikertelen logikaialkalmazás-példányon. A mintával kapcsolatos általános információkért lásd: Vállalati integrációs minták – Útválasztási bizonylat.

    Ez a példa egy útválasztási csúszásmintát mutat be, amelyben minden logikai alkalmazás egy fázist 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 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 valósíthatja meg, 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ár időtúllépési minta nélkül

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

A logikai alkalmazás korábbi munkafolyamat-végrehajtásával kapcsolatos további információkért tekintse át az alkalmazás eseményindítóját és futtatási előzményeit. 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 átmegy egy másodlagos példányra, csak az egyes példányok eseményindítójához férhet hozzá, és futtathatja az előzményeit azokon a helyeken, ahol a példányok futottak. A logikai alkalmazás előzményeiről azonban helyfüggetlen információkat kaphat, ha úgy állítja be a logikai alkalmazásokat, hogy diagnosztikai eseményeket küldjenek 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 különböző helyeken a vészhelyreállítási stratégiában. A logikai alkalmazásokban az alábbi triggertípusok használhatók:

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

Az Ismétlődés eseményindító független bármely adott szolgáltatástól vagy végponttól, és kizárólag egy megadott ütemezésen alapul, és nem tartalmaz más feltételeket, 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 kezdődik, be kell állítania az elsődleges és másodlagos logikaialkalmazás-pé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éhez tartozik, 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 helyek között.

Tegyük fel például, hogy van egy logikai alkalmazása, 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 úgy, hogy az az óra tetején induljon el, é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 elteltével 10 perccel kezdődjön, és ismételje meg 20 percenként, 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 az alábbi logikai alkalmazásokhoz:

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

    • Az aktív engedélyezett logikai alkalmazás esetében állítsa az Ismétlődés eseményindítót ugyanarra az ütemezésre, mint az elsődleges helyen lévő passzív logikai alkalmazásra, amely az óra elteltével 10 perccel kezdődik, és 20 percenként ismétlődik, például 9:10-kor, 9:20-kor stb.

Most, ha zavaró esemény történik az elsődleges helyen, aktiválja a passzív logikai alkalmazást az alternatív 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ó

Annak rendszeres ellenőrzéséhez, hogy a feldolgozásra szánt új adatok elérhetők-e egy adott szolgáltatásból vagy végpontból, a logikai alkalmazás használhat egy lekérdezési eseményindítót, amely egy rögzített ismétlődési ütemezés alapján ismételten meghívja a szolgáltatást vagy 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 az olvasás után már nem elérhető adatokat ismertetik

Annak érdekében, hogy elkerülje ugyanazokat az adatokat, 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 működő 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óval, szolgáltatással vagy rendszeroldali állapottal működő 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.

    Ha például egy lekérdezésalapú eseményindító beolvas egy sort egy adatbázisból, akkor a sornak rendelkeznie kell egy isRead oszloppal, amely a következőre FALSEvan állítva: . Minden alkalommal, amikor az eseményindító beolvas egy sort, a logikai alkalmazás frissíti ezt a sort úgy, hogy az oszlopot a isRead következőre FALSETRUEmódosítja: .

    Ez a kiszolgálóoldali megközelítés hasonló módon működik a Service Bus-üzenetsorok vagy olyan témakörök esetében, amelyek várólistás szemantikával rendelkeznek, ahol az eseményindítók képesek olvasni és zárolni 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 figyelembe veszi ezeket a viselkedéseket attól függően, hogy a logikai alkalmazás nyomon követi-e az állapotot az ügyféloldalon vagy a kiszolgálóoldalon:

  • Az ügyféloldali állapottal működő logikai alkalmazások esetében 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 logikaialkalmazás-példány. Győződjön meg arról, hogy az alternatív helyen lévő logikaialkalmazás-példány inaktív vagy le van tiltva, amíg az elsődleges példány át nem adja a feladatokat 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óbb olvasott e-mailek időbélyegét, hogy elkerülje a duplikált ü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ő fogyasztókként vagy aktív-passzív szerepkörökként működnek, ahol a másodlagos példány megvárja, amíg az elsődleges példány át nem adja a feladatátvételt az alternatív helyre.

    Egy üzenetsorból, például egy Azure Service Bus üzenetsorból való olvasás például kiszolgálóoldali állapotot használ, mivel az üzenetsor-kezelő szolgáltatás zárolja az üzeneteket, hogy más ügyfelek ne olvassák ugyanazokat az üzeneteket.

    Megjegyzés

    Ha a logikai alkalmazásnak adott sorrendben kell olvasnia az üzeneteket, például egy Service Bus-üzenetsorból, használhatja a konkurens fogyasztói mintát, de csak akkor, ha a Service Bus-munkamenetekkel kombinálja, amelyet szekvenciális konvojmintának is neveznek. Ellenkező esetben a logikaialkalmazás-pé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óval a logikai alkalmazás meghívhatóvá válik 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érés 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 Munkafolyamat hívása – Logic Apps művelet használatával.

  • A logikai alkalmazás webhook- vagy visszahívási mechanizmusa

  • A logikai alkalmazás meghívására szolgáló felhasználói műveletek vagy rutinok manuális futtatásának módja, például egy adott feladatot végrehajtó PowerShell-szkript használatával

Vészhelyreállítás szempontjából a Request eseményindító egy passzív fogadó, mivel a logikai alkalmazás nem végez semmilyen munkát, és megvárja, amíg egy másik 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 ú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 útválasztó határozza meg, hogy mikor hívja meg a másodlagos példányt.

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

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

Ahhoz, hogy a vészhelyreállítási stratégia működjön, a megoldásnak a következő feladatok végrehajtására van szüksége:

Ez a szakasz egy olyan megoldást ismertet, amelyet közvetlenül vagy saját tervezésének alapjaként használhat. Íme egy magas szintű vizualizációs áttekintés ehhez a megoldáshoz:

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 "állapot-ellenőrzés" logikai alkalmazást, amely az elsődleges példánnyal 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 állapotú.

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

  1. Hívást fogad a watchdog alkalmazástól a Request trigger használatával.

  2. Válasz á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ési 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 állapotú-e, az ezen a helyen található céllogikaalkalmazással együttműködő egyéb szolgáltatások állapotát is figyelembe veheti. Csak bontsa ki az állapot-ellenőrzési 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 úgy, hogy ha az állapot-ellenőrzési logika meghívása meghiúsul, a figyelő riasztást küldhet az üzemeltetési csapatnak, hogy kivizsgálhassák a hibát, és hogy az elsődleges példány miért nem válaszol.

Fontos

Győződjön meg arról, hogy a watchdog logikai alkalmazás olyan helyen van, amely eltér az elsődleges helytől. 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 egy 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 feladat meghiúsul.

A 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 a megfelelő logikai alkalmazások aktiválásához 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 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 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 egy régióban adatközponthibák történnek.

Ez a képesség jelenleg előzetes verzióban érhető el az új használatalapú logikai alkalmazásokhoz adott régiókban. 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ásaihoz, és az így kapott diagnosztikai adatokat elküldheti olyan szolgáltatásoknak, mint az Azure Storage, a Azure Event Hubs és az Azure Log Analytics a további kezeléshez és feldolgozáshoz.

Következő lépések