Workflow Manager 1.0 中的嚴重損壞修復和領域還原

 

本主題提供 Workflow Manager 1.0 的嚴重損壞修復選項和程序的概觀。 它涵蓋處理資料庫伺服器失敗、應用程式伺服器失敗的程序，並提供還原損毀或已刪除之領域的程序。

• 災害復原

• 領域還原

災害復原

Workflow Manager 1.0 可讓您為準備處理嚴重損壞狀況。 在本主題的範圍內，嚴重損壞是指造成嚴重損失、毀損、困境等的事件。 以伺服器產品而言，這是指造成伺服器可用性長時間中斷的任何事件，可能伴隨著伺服器設定的原始叢集 (或其一部分) 發生不同程度的損失。

災害復原與高可用性的比較

「嚴重損壞修復」通常與「高可用性」混為一談。 「高可用性」是確保服務在正常情況下高度可用的問題 - 包括在系統中建置足夠的備援，避免單一失敗點。 但是，「嚴重損壞修復」是主要服務由於外在環境而停止 (例如天災) 且必須持續提供相同服務水準的問題。

高度嚴重損壞修復模型

對嚴重損壞做好準備和反應的程序可分成各種階段，如下列各節所述。 此圖說明各階段，並指出使用者必須負起的責任相較於 Workflow Manager 所提供的功能。

Workflow Manager的各種不同的嚴重損壞狀況

以 Workflow Manager 而言，可能不同的嚴重損壞狀況，應該做好準備。

1. 導致 Workflow Manager 使用的一或多個資料庫遺失的嚴重損壞。

   1. 這可能是硬體故障或資料中心方面的嚴重損壞事件所引起。

2. 導致已部署 Workflow Manager 二進位檔的應用程式伺服器遺失的嚴重損壞。

3. 導致整個叢集遺失的嚴重損壞，也就是應用程式伺服器和資料庫都遺失。

由於 Workflow Manager 包含使用者工作流程、活動及執行個體的相關資訊，Workflow Manager 嚴重損壞修復的一項重點是能夠使用備份複本來還原 Workflow Manager 安裝的資料。 所以，在上述大多數情況下，嚴重損壞修復主要是從備份還原資料，並確保資料在 Workflow Manager 的各子系統之保持一致。

嚴重損壞修復的準備

「嚴重損壞修復」就是為萬一發生的緊急情況做好準備。 在 Workflow Manager 中，即使在嚴重損壞的情況下，您都可能想要保留所有活動、工作流程及執行個體的相關資料。

Workflow Manager 將所有資料儲存在 SQL Server資料庫中。 因此，嚴重損壞修復的一項重要必要條件是設定定期備份和/或資料備援解決方案，萬一損害資料中心的嚴重損壞情況真的發生時，資料庫才有最新複本可用來還原 Workflow Manager 安裝。

Workflow Manager 安裝使用下列資料庫。

資料庫名稱	說明
WFManagementDB	Workflow Manager 陣列管理資料庫
SbManagementDB	服務匯流排 陣列管理資料庫
WFResourceManagementDB	Workflow Manager 資源管理存放區
WFInstanceManagementDB	Workflow Manager 執行個體管理存放區
SbGatewayDatabase	服務匯流排 閘道資料庫
SBMessageContainer01 - n	服務匯流排 訊息容器資料庫

視 Workflow Manager 安裝中的工作流程資料的危急程度而定，有各種嚴重損壞修復準備選項供您選擇。 由於 Workflow Manager 的所有資料儲存在上述 SQL Server 資料庫中，所以 Workflow Manager 也應該套用任何以 SQL Server 為基礎的高可用性和備份策略。

如需以下內容的詳細資訊實作 SQL Server 的高可用性和嚴重損壞修復，請參閱選擇高可用性解決方案和 Microsoft SQL Server 的嚴重損害修復說明。

注意事項
無論您選擇什麼選項來備份這些資料庫，請確定這些備份在時間上不會相隔太久。 例如，如果上述個別資料庫彼此相距數小時或數天，則很難適當地還原 Workflow Manager。

下圖列列出 Workflow Manager 安裝的不同元件。

從伺服器陣列系統管理員的觀點來看，在嚴重損壞的情況下，Workflow Manager 有兩個部分可能損毀：一或多個相關資料庫，或一或多個應用程式伺服器節點。 故障的應用程式和資料庫伺服器可能有不同的組合，但以高階觀點來說，資料層和應用程式層才是失敗點。

• 資料層

• 運算層 (工作流程/訊息層)

資料層

Workflow Manager 1.0 將資料儲存在下列 SQL Server 資料庫中。

資料庫名稱	說明
WFManagementDB	Workflow Manager 陣列管理資料庫
SbManagementDB	服務匯流排 陣列管理資料庫
WFResourceManagementDB	Workflow Manager 資源管理存放區
WFInstanceManagementDB	Workflow Manager 執行個體管理存放區
SbGatewayDatabase	服務匯流排 閘道資料庫
SBMessageContainer01 - n	服務匯流排 訊息容器資料庫

在資料層方面，嚴重損壞修復有三個重要的相關工作：

1. 準備 - 確定資料庫有正確的備份/複寫策略，萬一嚴重損壞波及資料庫，才不會遺失資料。

   為了從嚴重損壞情況下還原，您必須為嚴重損壞做好準備。 特別是，為了能夠在遺失資料庫的嚴重損壞情況下修復，您必須設法將資料的複本儲存在不同位置。 因為這些資料庫是標準 SQL 資料庫，建議使用已建立的 SQL 技術，例如：

   1. SQL 鏡像

   2. SQL 複寫

   3. 簡易備份及備份與記錄傳送的組合

   視您的行業本質及您在備份與主要資料庫之間想要的資料準確度而定，您可以選擇其中任何技術。

   在本質上，Workflow Manager 陣列的系統管理員應該採用符合需求的適當備份策略，建立這些資料庫的備份。Workflow Manager 沒有任何功能可協助建立這些備份資料庫。

2. 還原備份資料庫

   視資料複寫策略而定，您可以使用適當的還原工具/機制來還原備份資料庫。 您可以使用業界標準 SQL 工具和技術來還原 SQL 資料庫。

3. 還原 Workflow Manager 陣列

   此步驟是確保 Workflow Manager 陣列還原為一致狀態且正常運作的程序。Workflow Manager 提供必要的 PowerShell 指令碼和指引來執行此步驟。

運算層 (工作流程/訊息層)

您可以在第二個位置建立第二個陣列，以協助解決嚴重損壞修復的情況。 您可以在嚴重損壞之前或之後建立第二個陣列。 有三種模型可考慮。

1. 冷待命

   在此模型中，您可以在嚴重損壞發生後重建陣列。 這會影響還原陣列所花的時間，因為您需要提供新的運算節點和在這些節點上再次安裝 Workflow Manager。

2. 暖待命

   即使在嚴重損壞打擊後，如果您要確定已建立並測試第二個陣列，您通常可以選擇採用此模型。 在此模型中，您需要在嚴重損壞之前在新的陣列中提供運算節點。 建立資料庫配對關係之後，您要將此新陣列指向第二次資料庫。

   設定此新陣列之後，基本上要「關閉」運算節點，而不讓它們閒置。 在嚴重損壞修復期間，您心須執行 Workflow Manager 提供的資料庫一致性指令碼。

   注意事項
   此模型假設在完成初始安裝後沒有立即建立新的 服務匯流排 容器資料庫。 如果最初沒有建立新的 服務匯流排 容器資料庫，則修復期間必須採取其他步驟。

3. 熱待命

   這是改良自運算節點所處的「暖待命」。 這可加速從嚴重損壞還原所花的時間。

   警告
   Workflow Manager 不支援熱待命。

嚴重損壞修復程序

本節說明前述各種嚴重損壞狀況可用的實際嚴重損壞修復程序。 以高階角度來說，建議的程序是從備份 (您使用任何標準 SQL Server 技術所建立) 還原所需的資料庫，並使用 Workflow Manager 提供的 Cmdlet 來還原陣列。

注意事項
下列步驟說明捨棄前述陣列管理資料庫並重建它們的程序。

執行還原命令的程序

1. 匯出具有私人金鑰的 ServiceBus 陣列憑證，以及具有私人金鑰的服務匯流排加密憑證。 將這兩個項目匯入新伺服器的本機電腦\個人資料夾。 也將根憑證匯入新伺服器的本機電腦\受信件的根授權單位。 您可以從 Get-SBFarm 輸出中識別陣列憑證及加密憑證。

   注意事項

   只有在舊 WFM/SB 伺服器上的舊 ServiceBus 加密憑證為以下兩種情況之一時，才可進行匯入作業： 由組態工具在舊陣列組態期間自動產生。 或者，如果您在舊環境中使用的是自訂的 ServiceBus 憑證，則您的網域需要萬用字元憑證，舉例來說，憑證中的 “Subject Alternative Name” 欄位值會類似 - *.mydomainname.com。 如果並未匯入舊 ServiceBus 憑證，則下列步驟中的 Restore-WFFarm cmdlet 會失敗，且產生的錯誤會類似以下範例： Token provider returned message: '<Error><Code>400</Code><Detail>The namespace 'WorkflowDefaultNamespace' does not have a valid issuer that can be used to issue tokens. Add a valid issuer with a valid signature to the namespace.

2. 在新電腦上開啟已提高權限的 PowerShell (RunAs 系統管理員) 視窗。

3. 呼叫 Restore-SBFarm Cmdlet 並傳遞下列參數。 此 Cmdlet 會建立新的 服務匯流排 陣列管理資料庫。 接著就可以刪除舊的 服務匯流排 陣列管理資料庫。

   Restore-SBFarm -FarmCertificateThumbprint <String> -GatewayDBConnectionString <String> -SBFarmDBConnectionString <String> [-AdminApiCredentials <PSCredential> ] [-AdminGroup <String> ] [-AmqpPort <Int32> ] [-AmqpsPort <Int32> ] [-EncryptionCertificateThumbprint <String> ] [-FarmDns <String> ] [-Force] [-HttpsPort <Int32> ] [-InternalPortRangeStart <Int32> ] [-MessageBrokerPort <Int32> ] [-RPHttpsPort <Int32> ] [-RunAsAccount <String> ] [-TcpPort <Int32> ] [-TenantApiCredentials <PSCredential> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
   

   注意事項
   如果您在舊的 ServiceBus 組態中使用了自訂的萬用字元憑證，同時也針對 FarmCertificate 和 EncryptionCertificate 使用了兩種不同的憑證，就需要在每個新節點匯入這兩個憑證，並依序在上述的 Cmdlet 提供 FarmCertificateThumbprint 和 EncryptionCertificateThumbprint 參數。

   下列程式碼片段是呼叫 Restore-SBFarm 的範例。

   Restore-SBFarm -RunAsAccount 'farm\test' -FarmCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2 -GatewayDBConnectionString 'Data Source=DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -AdminGroup 'BUILTIN\Administrators' -EncryptionCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2
   

4. 在其中一個陣列節點上使用下列參數呼叫 Restore-SBGateway Cmdlet。

   參數	說明
   SBFarmDBConnectionString	前一個步驟中建立的 Service Bus 陣列資料庫的連線字串。
   GatewayDBConnectionString	還原的閘道資料庫的連線字串。

   下列程式碼片段是呼叫 Restore-SBGateway 的範例。

   Restore-SBGateway -GatewayDBConnectionString 'Data Source= DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

5. 對於每個容器資料庫，請使用下列參數呼叫 Restore-SBMessageContainer Cmdlet。 在其中一個伺服器陣列機器上執行此 Cmdlet。

   參數	說明
   SBFarmDBConnectionString	前一個步驟中建立的 Service Bus 陣列資料庫的連線字串。
   ContainerDBConnectionString	容器資料庫的連線字串。
   Id	還原的訊息容器的 ID。 從閘道資料庫的 [dbo].[ContainersTable] 表格取得還原的訊息容器的 ID，此表格包含所有訊息容器的 ID、連線字串、資料庫伺服器名稱及資料庫名稱。 挑選資料庫名稱符合原始容器資料庫名稱的 ID。

   下列程式碼片段是呼叫 Restore-SBMessageContainer Cmdlet 的範例。

   Restore-SBMessageContainer -ContainerDBConnectionString "Data Source=localhost;Initial Catalog=SBMessageContainer01;Integrated Security=SSPI;Asynchronous Processing=True" -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog= SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" –id 1
   

6. 呼叫 Add-SBHost Cmdlet 並傳遞下列參數。

   參數	說明
   SBFarmDBConnectionString	前一個步驟中建立的 Service Bus 陣列資料庫的連線字串。
   CertificateAutoGenerationKey	這是用來自動產生 SB 憑證的金鑰。
   RunAsPassword	SecureString，包含用來執行 Service Bus 程序之帳戶的密碼。
   EnableFirewallRules	如果應該更新主機的防火牆規則以允許 Service Bus 資料周遊防火牆，則為 true。 否則為 false。

   以下範例說明如何叫用此 Cmdlet。

   $myPassword=convertto-securestring 'ereee' -asplaintext -force Add-SBHost -EnableFirewallRules $TRUE -RunAsPassword $myPassword -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

7. 呼叫 Restore-WFFarm Cmdlet 並使用 ResourceManagement 和執行個體資料庫連線字串。

   以下範例說明如何叫用此 Cmdlet。

   $mykey=convertto-securestring 'etwegff' -asplaintext -force Restore-WFFarm  -RunAsAccount 'farm\test' -InstanceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -ResourceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -InstanceStateSyncTime 'Sunday, May 11, 2014 12:30:00 PM' -ConsistencyVerifierLogPath 'c:\log.txt' -CertificateAutoGenerationKey $myKey
   

   注意事項
   InstanceStateSyncTime 必須遵循前一個範例中指定的確切格式。 ConsistencyVerifierLogPath 應該為資料夾的路徑，此 Cmdlet 會在此資料夾中寫入還原程序的相關記錄。

8. 呼叫 Add-WFHost Cmdlet。

   以下範例說明如何叫用此 Cmdlet。

   Add-WFHost -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -RunAsPassword $myPassword -EnableFirewallRules $TRUE -CertificateAutoGenerationKey $myKey
   

案例 1 - 嚴重損壞影響整個叢集

在此案例中，由於嚴重損壞而影響整個叢集。 若要在此嚴重損壞情況下修復，必須使用最新的資料庫備份來重建整個叢集。

1. 在新電腦上安裝 Workflow Manager 1.0。

   注意事項
   使用安裝程式來安裝 Workflow Manager 1.0，但不要開始設定陣列

2. 使用 SQL Server 還原功能來還原已備份的主要資料庫。 此步驟隨著您選擇的備份解決方案而不同。

   應該只還原下列資料庫。

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   重要事項
   請不要還原 WFManagementDB 和 SbManagementDb 資料庫，因為還原作業期間會重建它們。

3. 請遵循執行還原命令的程序中所述的步驟。

案例 2 - 嚴重損壞只影響 SQL Server 資料庫

在此情況下，Workflow Manager 使用的一或多個資料庫遺失或無法存取。 這可能起因於硬體故障或 SQL Server 本身的其他任何嚴重損壞。

注意事項
也可以按照此案例中的步驟，將資料庫的最新備份傳送至新的資料中心，並使用本節所述的程序，從一個資料中心移轉至另一個資料中心。

1. 從其中一個現有的應用程式伺服器節點解除安裝 Workflow Manager 1.0。

2. 自前一個步驟在伺服器上重新安裝 Workflow Manager 1.0。

   注意事項
   使用安裝程式來安裝 Workflow Manager，但不要開始設定陣列

3. 使用 SQL Server 還原功能來還原已備份的主要資料庫。 此步驟隨著您選擇的備份解決方案而不同。 視嚴重損壞的本質而定，您可以還原至現有的 SQL Server 或不同的 SQL Server。

4. 請遵循執行還原命令的程序中所述的步驟。

完成這些步驟時，您就會有一個陣列，而其中有一個節點使用現有的資料庫。 已使用原始資料庫的備份複本來還原此陣列，且此陣列已進入一致的狀態而能夠完整地運作。

對於主要陣列中的每一個節點，請執行下列步驟：

1. 解除安裝 Workflow Manager 1.0。

2. 重新安裝 Workflow Manager 1.0。

3. 執行 Add-SBHost 和 Add-WFHost Cmdlets，如＜執行還原命令的程序＞中所述。

案例 3 - 嚴重損壞只影響應用程式伺服器

有時，可能因為局部性嚴重損壞而造成應用程式伺服器當機或遺失，而資料庫伺服器毫髮無傷。 雖然這在資料中心是罕見情況，萬一發生這種嚴重損壞，可以很輕鬆修復。 因為沒有遺失資料庫，您可以繼續使用主要位置，並將新的節點加入到此現有陣列中。 如果您因為任何理由而喜歡移至第二個位置，您仍然可以將資料庫複製到第二個位置，然後在執行修復步驟時指向新的資料庫。

若要從應用程式伺服器嚴重損壞情況修復，請執行下列步驟。

1. 在新電腦上安裝 Workflow Manager 1.0。

2. 捨棄下列資料庫。

   • WFManagementDB

   • SbManagementDB

3. 請遵循執行還原命令的程序中所述的程序。

   注意事項
   如果您移動資料庫，請在執行這些步驟時指向新的資料庫，否則請指向原始資料庫。

完成這些步驟時，您就會有一個陣列，而其中有一個節點使用現有 (或已移動的) 的資料庫。 如有需要，您可以將其他節點加入至陣列，就像將更多節點加入至工作流程管理員陣列中一樣。

領域還原

有時您可能不小心刪除特定領域，或特定領域的內容損毀。 您也有領域內容正確時的 Workflow Manager 資料庫備份。 您可能想從您具有的備份複本來只還原此領域的內容。

還原領域時會還原下列內容。

• 領域和子領域及其組態。

• 還原的領域階層內的活動

• 領域階層內的工作流程及其組態

• 領域階層內的工作流程執行個體

  • 執行個體會從上一個持續點繼續執行。

• 對應於這些執行個體的追蹤記錄。

• 此領域階層內工作流程的任何未遞送的訊息

注意事項
刪除領域時，幾分鐘之內就會清除 (為非同步程序) 其所有內容 (包括執行個體和追蹤記錄)。

下表說明領域還原作業採用的重要術語。

詞彙	說明
備份資料庫	假設您已經為 Workflow Manager 使用的所有資料庫建立備份，而且此備份複本中有您打算還原的領域。 換言之，此資料庫是複製此領域內容的來源資料庫。
即時資料庫	此術語是指 Workflow Manager 陣列中的目前使用中資料庫。 換言之，這是領域還原程序的目標資料庫。
要還原的領域。	您可以指定領域階層內要從備份資料庫還原的任何領域。

Workflow Manager 可讓您啟用此案例。 以下是您必須遵循以完成領域還原的步驟。

• 領域還原程序

• 領域還原考量

領域還原程序

您要還原的領域不應該存在於即時資料庫中。 因此，如果您因為即時資料庫包含領域的損毀複本而從備份還原此領域，則必須從即時資料庫中刪除此損毀領域。

1. 還原 SQL 資料庫：第一步是使用備份來還原 SQL 資料庫，如還原資料庫備份 (SQL Server Management Studio) 中所述。

   重要事項
   您必須將備份資料庫還原至不同伺服器。 不要覆寫即時資料庫。

2. 傳遞下列參數來執行 Restore-WFScope PowerShell 命令。

   • 要還原的領域的路徑

   • 備份資源 DB 的連線字串

   • 備份執行個體 DB 的連線字串

   • 提供建立備份的時間 - 這可以是約略近似值。 如果資料庫是在不同時間備份，請務必提供其中最舊的時間戳記作為此步驟的輸入。

   • 閘道 DB 的連線字串

   • 一或多個容器資料庫的連線字串。 您通常只有一個容器資料庫。 如果您的伺服器有多個容器資料庫，請務必提供所有這些連線字串給此 Cmdlet。

   此時，即時資料庫中應該已還原領域和內容，可移除剛還原的備份資料庫。

領域還原考量

「領域還原」可從備份和還原的資料庫來還原領域，請注意以下關於整個還原程序的幾個重點。

• 您只能從目前即時資料庫的前一個備份複本來還原領域。 換言之，您無法嘗試將特定領域從一個 Workflow Manager 陣列移至另一個陣列。

• 「領域還原」只還原屬於某個領域及其所有子項的內容。 不會還原此領域子項階層以外的任何內容。

• 如果活動或工作流程參考此領域階層以外的另一個活動 (亦即，參考的活動位於還原的領域之上的父系領域中)，則此作業不會還原參考的活動。 這表示這些工作流程會無效，而嘗試建立這些工作流程的執行個體都會導致錯誤。