適用於 Azure Logic Apps 的商務持續性和災害復原
為了協助降低無法預期的事件對業務和客戶的影響，請確定您已準備好災害復原 (DR) 解決方案 (英文)，以便保護資料、快速還原支援重要商務功能的資源，並可讓作業持續執行，以維持商務持續性 (BC) (英文)。 例如，中斷可能包括中斷、基礎結構或元件中的損失，例如儲存體、網路或計算資源、無法復原的應用程式失敗，或甚至是整個資料中心遺失。 藉由將商務持續性和災害復原 (BCDR) 解決方案準備就緒，您的企業或組織可以更快速地回應中斷 (不論計劃性或非計劃性中斷)，並減少客戶的停機時間。
本文提供 BCDR 指導和策略，可讓您在使用 Azure Logic Apps 建置自動化工作流程時套用。 邏輯應用程式工作流程可藉由減少您必須撰寫的程式碼數量，協助您更輕鬆地整合及協調應用程式、雲端服務和內部部署系統之間的資料。 當您規劃 BCDR 時，請確定您不只考慮邏輯應用程式，也考慮搭配邏輯應用程式使用的這些 Azure 資源：
您從邏輯應用程式工作流程建立的連線，以連至其他應用程式、服務及系統。 如需詳細資訊，請參閱本主題稍後將討論的連線至資源部分。
內部部署的資料閘道是您在邏輯應用程式中建立並使用的 Azure 資源，可存取內部部署系統中的資料。 每個網路閘道資源都代表本機電腦上的個別資料閘道安裝。 如需詳細資訊，請參閱本主題稍後將討論的內部部署的資料閘道部分。
企業整合帳戶，您可以在其中定義及儲存邏輯應用程式用於企業對企業 (B2B) 企業整合案例的成品。 例如，您可以設定整合帳戶的跨區域災害復原。
主要和次要位置
每個邏輯應用程式都必須指定要用於部署的位置，例如 Azure 區域 (如「美國西部」)。 此災害復原策略著重於設定主要邏輯應用程式，以在 Azure Logic Apps 也可供使用的另一個位置容錯移轉至待命或備份邏輯應用程式。 如此一來，如果主要邏輯應用程式發生損失、中斷或失敗，次要邏輯應用程式就可以處理工作。 此策略需要您已部署次要邏輯應用程式和相依資源，並已備妥替代位置。
注意
如果您的邏輯應用程式也搭配 B2B 成品來運作 (例如交易夥伴、合約、結構描述、地圖和憑證)，這些成品會儲存在整合帳戶中，因此您的整合帳戶和邏輯應用程式都必須使用相同的位置。
如果您遵循良好的 DevOps 做法，您應已經使用 Azure Resource Manager 範本來定義和部署邏輯應用程式及其相依資源。 Resource Manager 範本可讓您使用單一部署定義，然後使用參數檔案來提供每個部署目的地要使用的組態值。 這項功能表示您可以將相同的邏輯應用程式部署到不同的環境，例如開發、測試和實際執行環境。 您也可以將相同的邏輯應用程式部署至不同的 Azure 區域，以支援使用配對區域的災害復原策略。
針對容錯移轉策略，邏輯應用程式和位置必須符合下列需求：
次要邏輯應用程式執行個體可存取的應用程式、服務和系統，會與主要邏輯應用程式執行個體可存取者相同。
這兩個邏輯應用程式執行個體具有相同的主機類型。 因此，這兩個執行個體都會部署至全域多租用戶 Azure Logic Apps 中的區域，或是單一租用戶 Azure Logic Apps 中的區域。 如需 BCDR 配對區域的最佳做法和詳細資訊，請參閱 Azure 中的跨區域複寫：商務持續性和災害復原。
範例：多租用戶 Azure
此範例顯示主要和次要邏輯應用程式執行個體，這些執行個體會針對此案例部署至全域多租用戶 Azure 中的個別區域。 單一 Resource Manager 範本會定義這兩個邏輯應用程式執行個體和這些邏輯應用程式所需的相依資源。 個別的參數檔案會指定要用於每個部署位置的組態值：
與資源的連線
Azure Logic Apps 提供數百個連接器作業，您的邏輯應用程式可用來與其他應用程式、服務、系統和其他資源合作，例如 Azure 儲存體帳戶、SQL Server 資料庫、公司或學校電子郵件帳戶等等。 如果您的邏輯應用程式需要存取這些資源，您可以建立可針對這些資源驗證存取權的連線。 每個連線都是存在於特定位置的個別 Azure 資源，無法供其他位置的資源使用。
針對災害復原策略，請考慮相依資源存在相對於邏輯應用程式執行個體的位置：
您的主要執行個體和相依資源存在於不同的位置。 在此情況下，您的次要執行個體可以連線到相同的相依資源或端點。 不過，您應該特別為次要執行個體建立連線。 如此一來，如果您的主要位置無法使用，則您的次要連線不會受到影響。
例如，假設您的主要邏輯應用程式會連線到外部服務，例如 Salesforce。 通常，外部服務的可用性和位置與您的邏輯應用程式可用性無關。 在此情況下，您的次要執行個體可以連線到相同的服務，但應該有自己的連線。
您的主要執行個體和相依資源存在於相同的位置。 在此情況下，相依資源應該在不同的位置有備份或複寫的版本，讓您的次要執行個體仍然可以存取那些資源。
例如，假設您的主要邏輯應用程式會連線到位於相同位置或區域中的服務，例如 Azure SQL 資料庫。 如果這整個區域都無法使用，則該區域中的 Azure SQL 資料庫服務也可能無法使用。 在此情況下，您會想要讓次要執行個體使用複寫或備份資料庫，以及與該資料庫的個別連線。
內部部署資料閘道
如果您的邏輯應用程式是在多租用戶 Azure 中執行，且需要存取內部部署資源 (例如 SQL Server 資料庫)，您必須在本機電腦上安裝內部部署的資料閘道。 接著，您可以在 Azure 入口網站中建立資料閘道資源，以便在建立對資源的連線時，邏輯應用程式可以使用閘道。
資料閘道資源與位置或 Azure 區域相關聯，如同您的邏輯應用程式資源一樣。 在您的災害復原策略中，請確定資料閘道仍可供邏輯應用程式使用。 當您安裝多個閘道時，您可以啟用閘道的高可用性。
主動-主動與主動-被動角色
您可以設定主要和次要位置，讓這些位置中的邏輯應用程式執行個體可以扮演下列角色：
| 主要-次要角色 | 描述 |
|---|---|
| 主動-主動 | 這兩個位置中的主要和次要邏輯應用程式執行個體會遵循下列任一模式主動處理要求： - 負載平衡：您可以讓兩個執行個體接聽端點，並視需要對每個執行個體的流量進行負載平衡。 - 競爭取用者：您可以讓這兩個執行個體作為競爭取用者，讓執行個體競爭來自佇列的訊息。 如果一個執行個體失敗，另一個執行個體會接管工作負載。 |
| 主動-被動 | 主要邏輯應用程式執行個體會主動處理整個工作負載，而次要執行個體是被動 (停用或非作用中)。 次要邏輯應用程式會等候主要邏輯應用程式因為中斷或失敗，而無法使用或無法運作的訊號，並接管工作負載作為作用中的執行個體。 |
| 合併 | 某些邏輯應用程式扮演主動-主動角色，而其他邏輯應用程式則扮演主動-被動角色。 |
主動-主動範例
這些範例顯示主動-主動設定，兩個邏輯應用程式執行個體都會主動處理要求或訊息。 某些其他系統或服務會在執行個體之間散發要求或訊息，例如下列為其中一個選項：
一個「實體」負載平衡器，例如路由流量的一件硬體
「軟體」負載平衡器，例如 Azure Load Balancer 或 Azure API 管理。 透過 API 管理，您可以指定原則來決定如何平衡傳入流量的負載。 或者，您可以使用支援狀態追蹤的服務，例如 Azure 服務匯流排。
雖然此範例主要呈現 Azure Load Balancer 的情況，但您可以使用最符合您案例需求的選項：
每個邏輯應用程式執行個體都會作為取用者，而且讓兩個執行個體都競爭來自佇列的訊息：
主動-被動範例
此範例顯示主動-被動設定，其中主要邏輯應用程式執行個體在一個位置處於作用中狀態，而次要執行個體在另一個位置保持非作用中狀態。 如果主要邏輯應用程式發生中斷或失敗，您可以讓操作員執行指令碼來啟動次要邏輯應用程式，以接管工作負載。
結合主動-主動和主動-被動
此範例顯示合併的設定，其中主要位置具有 2 個主動邏輯應用程式執行個體，而次要位置則具有主動-被動邏輯應用程式執行個體。 如果主要位置發生中斷或失敗，次要位置中已處理部分工作負載的主動邏輯應用程式可能會接管整個工作負載。
在主要位置中，主動邏輯應用程式會接聽 Azure 服務匯流排佇列的訊息，而另一個主動邏輯應用程式則會使用 Office 365 Outlook 輪詢觸發程序來檢查電子郵件。
在次要位置中，主動邏輯應用程式會藉由接聽和競爭來自相同服務匯流排佇列的訊息，與主要位置中的邏輯應用程式搭配運作。 同時，被動非作用中的邏輯應用程式會在主要位置變成無法使用時，等候待命來檢查電子郵件，但應用程式會轉為停用，以避免重新讀取電子郵件。
邏輯應用程式狀態和歷程記錄
觸發邏輯應用程式並開始執行時，應用程式的狀態會儲存在與應用程式啟動所在的相同位置，且無法傳輸到另一個位置。 如果發生失敗或中斷，則會放棄任何進行中的工作流程執行個體。 當您設定主要和次要位置時，新的工作流程執行個體就會開始在次要位置執行。
減少已放棄的進行中執行個體
若要將已放棄的進行中工作流程執行個體數目降到最低，您可以從可實作的各種訊息模式中選擇，例如：
-
此企業訊息模式會將商務流程分割成較小的階段。 針對每個階段，您會設定可處理該階段工作負載的邏輯應用程式。 若要彼此通訊，邏輯應用程式會使用非同步傳訊通訊協定，例如 Azure 服務匯流排佇列或主題。 當您將流程分割成較小的階段時，可減少可能會卡在失敗邏輯應用程式執行個體上的商務流程數目。 如需此模式的一般資訊，請參閱企業整合模式：傳閱名單 (英文)。
此範例呈現的是傳閱名單模式，其中每個邏輯應用程式代表一個階段，並使用服務匯流排佇列與流程中的下一個邏輯應用程式通訊。
如果主要和次要邏輯應用程式執行個體在其位置都遵循相同的傳閱名單模式，您可以為這些執行個體設定主動-主動角色，以實作競爭取用者模式。
存取觸發程序和執行歷程記錄
若要取得邏輯應用程式過去工作流程執行的詳細資訊，您可以檢閱應用程式的觸發程序和執行歷程記錄。 邏輯應用程式的執行歷程記錄會儲存在與邏輯應用程式執行所在的相同位置或區域中，這表示您無法將此歷程記錄移轉至不同的位置。 如果您的主要執行個體容錯移轉至次要執行個體，您只能存取每個執行個體的觸發程序，並在這些執行個體執行所在的個別位置上執行歷程記錄。 不過，您可以藉由設定邏輯應用程式，將診斷事件傳送至 Azure Log Analytics 工作區，以取得邏輯應用程式歷程記錄的無從驗證位置資訊。 然後，您可以針對在多個位置執行的邏輯應用程式，檢閱其健康情況和歷程記錄。
觸發程序類型指導
您在邏輯應用程式中使用的觸發程序類型會決定如何在災害復原策略中跨位置設定邏輯應用程式的選項。 以下是您可以在邏輯應用程式中使用的觸發程序類型：
循環觸發程序
定期觸發程序與任何特定服務或端點無關，而且只會根據指定的排程引發，而且沒有其他準則，例如：
- 固定頻率和間隔，例如每 10 分鐘一次
- 更進階的排程，例如每個月最後一個星期一的下午 5：00
當邏輯應用程式以週期觸發程序啟動時，您必須使用主動-被動角色來設定主要和次要邏輯應用程式執行個體。 若要減少復原時間目標 (RTO)，這是指在中斷或災害後，還原商務流程的目標持續時間，您可以使用主動-被動角色和被動-主動角色的組合來設定邏輯應用程式執行個體。 在此設定中，您會將排程分割到各個位置。
例如，假設您有一個必須每 10 分鐘執行一次的邏輯應用程式。 您可以設定邏輯應用程式和位置，以便在主要位置變成無法使用時，次要位置可以接管工作：
在主要位置中，為這些邏輯應用程式設定主動-被動角色 ：
針對主動已啟用的邏輯應用程式，將週期觸發程序設定為從整點開始，並每隔 20 分鐘重複一次，例如上午 9：00、上午 9：20 等等。
針對被動停用的邏輯應用程式，將週期觸發程序設定為相同的排程，但從整點後 10 分鐘開始，然後每隔 20 分鐘重複一次，例如上午 9：10、上午 9：30 等等。
在次要位置中，為這些邏輯應用程式設定被動-主動：
針對被動停用的邏輯應用程式，將週期觸發程序設定為與主要位置中之主動邏輯應用程式相同的排程，也就是在整點時每隔 20 分鐘重複一次，例如上午 9：00、上午 9：20 等等。
針對主動已啟用的邏輯應用程式，將週期觸發程序設定為與主要位置中之被動邏輯應用程式相同的排程，也就是在整點後 10 分鐘開始，並每隔 20 分鐘重複一次，例如上午 9：10、上午 9：30 等等。
現在，如果在主要位置發生干擾性事件，請於替代位置啟動被動邏輯應用程式。 如此一來，若需要時間找出失敗，則此設定會限制該延遲期間遺漏的週期數目。
輪詢觸發程序
若要定期檢查特定服務或端點是否有新的資料處理資料，邏輯應用程式可以使用輪詢觸發程序，根據固定的週期排程重複呼叫服務或端點。 服務或端點提供的資料可具備下列其中一種類型：
- 靜態資料指的是永遠可供讀取的資料
- 揮發性資料指的是讀取之後不再提供的資料
若要避免重複讀取相同的資料，邏輯應用程式必須透過先前在用戶端，或者在伺服器、服務或系統端的維護狀態，來記住曾讀取過哪些資料。
可配合用戶端狀態運作的邏輯應用程式，會使用可維護狀態的觸發程序。
例如，從電子郵件收件匣讀取新訊息的觸發程序，即需要記住最近讀取的訊息。 如此一來，只有在下一個未讀取的訊息送達時，觸發程序才會啟動邏輯應用程式。
可配合伺服器、服務或系統端狀態運作的邏輯應用程式，會使用位於伺服器、服務或系統端的屬性值或設定。
例如，從資料庫讀取資料列的查詢型觸發程序，需要資料列具有
isRead設定為FALSE的資料行。 每次觸發程序讀取資料列時，邏輯應用程式都會將isRead資料行從FALSE變更為TRUE來更新該資料列。此伺服器端方法的作用，類似於具有佇列語意的服務匯流排佇列或主題，其中觸發程序可以在邏輯應用程式處理訊息時，用於讀取和鎖定訊息。 當邏輯應用程式完成處理時，觸發程序會從佇列或主題中刪除訊息。
從災害復原的觀點來看，當您設定邏輯應用程式的主要和次要執行個體時，請務必根據邏輯應用程式是否會追蹤用戶端或伺服器端的狀態，來解釋這些行為：
對於可配合用戶端狀態運作的邏輯應用程式，請確定邏輯應用程式不會多次讀取相同的訊息。 在任何特定時間，只有一個位置可以有主動邏輯應用程式執行個體。 請確定替代位置中的邏輯應用程式執行個體為非使用中或停用，直到主要執行個體容錯移轉至替代位置為止。
例如，Office 365 Outlook 觸發程序會維護用戶端狀態，並追蹤最近讀取電子郵件的時間戳記，以避免重複讀取。
對於搭配伺服器端狀態運作的邏輯應用程式，您可以設定邏輯應用程式執行個體，以擔任主動-主動角色，讓它們作為競爭取用者運作，或者擔任主動-被動角色，讓替代執行個體等候，直到主要執行個體容錯移轉至替代位置為止。
例如，從訊息佇列讀取 (例如 Azure 服務匯流排佇列) 會使用伺服器端狀態，因為佇列服務會維持訊息的鎖定，以防止其他用戶端讀取相同的訊息。
注意
例如，如果您的邏輯應用程式需要依特定順序讀取訊息，例如您可以從服務匯流排佇列使用競爭取用者模式，但只有在與服務匯流排工作階段結合時才能使用，這也稱為循序群組模式。 否則，您必須使用主動-被動角色來設定邏輯應用程式執行個體。
要求觸發程序
要求觸發程序可讓您的邏輯應用程式從其他應用程式、服務和系統呼叫，而且通常用來提供這些功能：
其他人可以呼叫之邏輯應用程式的直接 REST API
例如，使用要求觸發程序啟動邏輯應用程式，讓其他邏輯應用程式可以使用呼叫工作流程 - Logic Apps 動作來呼叫觸發程序。
邏輯應用程式的 Webhook 或回撥機制
一個您可以手動執行使用者作業或常式來呼叫邏輯應用程式的方式，例如使用執行特定工作的 PowerShell 指令碼
從災害復原的觀點來看，要求觸發程序是被動接收者，因為在某些其他服務或系統明確呼叫觸發程序前，邏輯應用程式都不會執行任何工作。 身為被動端點，您可以透過下列方式設定主要和次要執行個體：
主動-主動：這兩個執行個體都會主動處理要求或呼叫。 呼叫者或路由器會平衡或分散這些執行個體之間的流量。
主動-被動：只有主要執行個體為作用中，並處理所有工作，而次要執行個體會等到主要執行個體發生中斷或失敗時，才會接手處理所有工作。 呼叫者或路由器會決定何時呼叫次要執行個體。
作為建議的架構，您可以使用 Azure API 管理，作為使用要求觸發程序之邏輯應用程式的 Proxy。 API 管理提供內建跨區域復原功能，以及跨多個端點路由流量的功能。
Webhook 觸發程序
Webhook 觸發程序可讓您的邏輯應用程式透過將回撥 URL 傳遞至該服務來訂閱服務。 邏輯應用程式接著可以接聽並等候在該服務端點發生的特定事件。 事件發生時，服務會使用回撥 URL 呼叫 Webhook 觸發程序，然後執行邏輯應用程式。 啟用時，Webhook 觸發程序會訂閱該服務。 停用時，觸發程序會取消訂閱服務。
從災害復原的觀點來看，您應設定使用 Webhook 觸發程序扮演主動-被動角色的主要和次要執行個體，因為只有一個執行個體應該從訂閱的端點接收事件或訊息。
評估主要執行個體健康情況
若要讓災害復原策略能夠運作，您的解決方案需要能執行這些工作的方式：
本節說明一個您可以充分使用，或作為自身設計基礎使用的解決方案。 以下是此解決方案的高階視覺效果概觀：
檢查主要執行個體可用性
若要判斷主要執行個體是否可用、可執行且能夠運作，您可以建立與主要執行個體位於相同位置的「健康情況檢查」邏輯應用程式。 然後，您可以從替代位置呼叫此健康情況檢查應用程式。 如果健康情況檢查應用程式成功回應，則該區域中 Azure Logic Apps 服務的基礎結構可供使用且可運作。 如果健康情況檢查應用程式無法回應，您可以假設位置的狀況不再良好。
針對這項工作，建立要執行這些工作的基本健康情況檢查邏輯應用程式：
使用要求觸發程序，從看門狗應用程式接收呼叫。
以一個狀態回應，表示檢查的邏輯應用程式是否仍能使用回應動作運作。
重要
健康情況檢查邏輯應用程式必須使用回應動作，讓應用程式以同步方式，而不是以非同步方式回應。
或者，若要進一步判斷主要位置狀況是否良好，您可以參考與此位置中目標邏輯應用程式互動之任何其他服務的健康情況。 只要展開健康情況檢查邏輯應用程式，即可評估這些其他服務的健康情況。
建立看門狗邏輯應用程式
若要監視主要執行個體的健康情況並呼叫健康情況檢查邏輯應用程式，請在替代位置建立「看門狗」邏輯應用程式。 例如，您可以設定看門狗邏輯應用程式，當呼叫健康情況檢查邏輯失敗時，看門狗就可以將警示傳送給您的作業團隊，以便調查失敗本身與主要執行個體沒有回應的原因。
重要
請確定您的看門狗邏輯應用程式與主要位置處於不同的位置。 如果主要位置的 Azure Logic Apps 遇到問題，則您的看門狗邏輯應用程式工作流程可能無法執行。
針對這項工作，請在次要位置建立看門狗邏輯應用程式，以執行下列工作：
使用週期觸發程序，根據固定或排程定期執行。
您可以將週期設定為低於復原時間目標 (RTO) 容錯層級的值。
使用 HTTP 動作，在主要位置呼叫健康情況檢查邏輯應用程式工作流程。
您也可以建立更複雜的看門狗邏輯應用程式，在發生許多失敗之後，其會呼叫另一個邏輯應用程式，以在主要位置失敗時自動處理切換至次要位置。
啟用次要執行個體
若要自動啟動次要執行個體，您可以建立邏輯應用程式來呼叫管理 API，例如 Azure Resource Manager 連接器，以在次要位置啟用適當的邏輯應用程式。 您可以展開看門狗應用程式，以在特定失敗數目發生之後，呼叫此啟用邏輯應用程式。
具有可用性區域的區域備援
在每個 Azure 區域中，可用性區域的位置與可容忍本機失敗的位置，實際上都不同。 這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 這些區域可透過 Azure 服務的備援和邏輯隔離來達成容錯。
為了提供復原和分散式可用性，至少有三個不同的可用性區域存在於任何支援及啟用區域備援的 Azure 區域中。 Azure Logic Apps 平台會將這些區域和邏輯應用程式工作負載分散到這些區域。 這項功能是啟用復原架構的重要要求，如果區域發生資料中心失敗，則會提供高可用性。
這項功能目前為預覽功能，可供特定區域中的新取用邏輯應用程式使用。 如需詳細資訊，請參閱下列文件：
收集診斷資料
您可以設定邏輯應用程式的記錄，並將產生的診斷資料傳送至 Azure 儲存體、Azure 事件中樞和 Azure Log Analytics 等服務，以便進一步處理。
如果您想要將此資料與 Azure Log Analytics 搭配使用，您可以藉由設定邏輯應用程式的診斷設定，並將資料傳送至多個 Log Analytics 工作區，讓主要和次要位置都能使用資料。 如需詳細資訊，請參閱設定 Azure 監視器記錄並收集 Azure Logic Apps 的診斷資料。
如果您想要將資料傳送至 Azure 儲存體或 Azure 事件中樞，您可以藉由設定異地備援，讓主要和次要位置都能使用資料。 如需詳細資訊，請參閱下列文章：