Notfallwiederherstellung und Bereichswiederherstellung in Workflow Manager 1.0

 

Dieses Thema stellt die Notfallwiederherstellungsoptionen und -verfahren für Workflow-Manager 1.0 im Überblick vor. Es werden Verfahren zum Behandeln von Datenbankserverfehlern sowie Anwendungsserverfehlern beschrieben und Verfahren zum Wiederherstellen eines fehlerhaften oder gelöschten Bereichs vorgestellt.

• Wiederherstellung im Notfall

• Bereichswiederherstellung

Wiederherstellung im Notfall

Workflow-Manager 1.0 ermöglicht die Vorbereitung auf Notfallwiederherstellungsszenarien. Im Rahmen dieses Themas ist ein "Notfall" ein Ereignis, das zu erheblichen Datenverlusten, Zerstörung, Ausfällen usw. führt. Bei einem Serverprodukt handelt es sich um ein Ereignis, das zu einer längeren Unterbrechung der Verfügbarkeit des Servers führt und das ggf. einen Verlust des ursprünglich für den Server eingerichteten Clusters (oder Teilen davon) in verschiedenen Schweregraden bedeutet.

Notfallwiederherstellung im Vergleich Hochverfügbarkeit

Normalerweise steht Notfallwiederherstellung in enger Verbindung mit hoher Verfügbarkeit. Hohe Verfügbarkeit stellt sicher, dass der Dienst unter normalen Bedingungen hochgradig verfügbar ist – durch Erstellen einer ausreichend großen Anzahl von Redundanzen im System und Beseitigen einzelner Fehlerquellen. Bei der Notfallwiederherstellung besteht das Problem, dass der primäre Dienst aufgrund von äußeren Bedingungen (z. B. durch eine Naturkatastrophe) ausfällt und der gleiche Dienstumfang weiterhin bereitgestellt werden muss.

Modell für die Notfallwiederherstellung auf hoher Ebene

Der Vorgang der Vorbereitung und des Reagierens auf einen Notfall kann – wie in den folgenden Abschnitten gezeigt – in verschiedene Phasen aufgeteilt werden. Diese Abbildung zeigt jede dieser Phasen und nennt die Verantwortlichkeiten, die der Benutzer übernehmen muss, sowie die Funktionen, die von Workflow-Manager bereitgestellt werden.

Verschiedene Typen von Notfallszenarien für Workflow Manager

Für Workflow-Manager sollte eine Vorbereitung auf verschiedene Notfallszenarien erfolgen.

1. Auf einen Notfall, der zu einem Verlust von mindestens einer der von Workflow-Manager verwendeten Datenbanken führt.

   1. Dies kann durch einen Hardwarefehler oder ein Notfallereignis verursacht werden, der das gesamte Datencenter betrifft.

2. Auf einen Notfall, der zu einem Verlust der Anwendungsserver führt, auf denen die Binärdateien von Workflow-Manager bereitgestellt werden.

3. Auf einen Notfall, der zu einem Verlust des gesamten Clusters führt, bei dem sowohl die Anwendungsserver als auch die Datenbanken verloren gehen.

Da Workflow-Manager Informationen enthält, die sich auf die Workflows, Aktivitäten und Instanzen der Benutzer beziehen, besteht ein Kernpunkt der Notfallwiederherstellung von Workflow-Manager im Wiederherstellen der Daten der Workflow-Manager-Installation durch Verwenden von Sicherungskopien. Die Notfallwiederherstellung bedeutet daher in den meisten Szenarien das Wiederherstellen von Daten aus Sicherungen und das Gewährleisten, dass die Daten in verschiedenen Untersystemen von Workflow-Manager konsistent sind.

Vorbereiten der Notfallwiederherstellung

Bei der Notfallwiederherstellung dreht sich alles darum, auf einen Notfall vorbereitet zu sein, bevor dieser eintritt. Für Workflow-Manager möchten Sie bei einem Notfall ggf. die Daten sichern, die sich auf alle Aktivitäten, Workflows und Instanzen beziehen.

Workflow-Manager speichert sämtliche Daten in SQL Server-Datenbanken. Eine wichtige Voraussetzung für die Notfallwiederherstellung besteht daher im Einrichten regelmäßiger Sicherungen und/oder Datenredundanzlösungen, damit beim Eintreten eines tatsächlichen Notfalls im Datencenter eine aktuelle Kopie der Datenbank vorhanden ist, die zum Wiederherstellen der Workflow-Manager-Installation verwendet werden kann.

Ihre Workflow-Manager-Installation verwendet die folgenden Datenbanken.

Datenbankname	Beschreibung
WFManagementDB	Workflow-Manager-Farmverwaltungsdatenbank
SbManagementDB	Service Bus-Farmverwaltungsdatenbank
WFResourceManagementDB	Workflow-Manager-Ressourcenverwaltungsspeicher
WFInstanceManagementDB	Workflow-Manager-Instanzverwaltungsspeicher
SbGatewayDatabase	Service Bus-Gatewaydatenbank
SBMessageContainer01 - n	Service Bus-Nachrichtencontainerdatenbanken

Abhängig von der Wichtigkeit der Workflowdaten in Ihrer Workflow-Manager-Installation können Sie unter verschiedenen Optionen zur Vorbereitung der Notfallwiederherstellung wählen. Da alle Daten von Workflow-Manager in den oben genannten SQL Server-Datenbanken gespeichert werden, gelten alle auf SQL Server basierenden Strategien für hohe Verfügbarkeit und Sicherung auch für Workflow-Manager gelten.

Weitere Informationen über zum Implementieren von hoher Verfügbarkeit und Notfallwiederherstellung für SQL Server finden Sie unter Auswählen einer Hochverfügbarkeitslösung und Beschreibung der Optionen für Notfallwiederherstellung für Microsoft SQL Server.

Hinweis

Unabhängig von der ausgewählten Option zum Sichern dieser Datenbanken sollten Sie sicherstellen, dass diese Sicherungen zeitlich nah beieinander liegen. Es ist z. B. schwierig, Workflow-Manager ordnungsgemäß wiederherzustellen, wenn die Sicherungen dieser einzelnen Datenbanken sich um Stunden oder Tage unterscheiden.

Die folgende Abbildung zeigt die verschiedenen Komponenten einer Workflow-Manager-Installation.

Aus der Sicht des Administrators der Serverfarm können zwei Bestandteile von Workflow-Manager bei einem Notfall ausfallen: mindestens eine der betroffenen Datenbanken und mindestens einer der Anwendungsserverknoten. Es können verschiedene Kombinationen von Anwendungs- und Datenbankservern ausfallen, auf hoher Ebene stellen jedoch die Datenschicht und die Anwendungsschicht die Fehlerpunkte dar.

• Datenschicht

• Serverschicht (Workflow-/Messagingschicht)

Datenschicht

Workflow-Manager 1.0 speichert alle Daten in den folgenden SQL Server-Datenbanken.

Datenbankname	Beschreibung
WFManagementDB	Workflow-Manager-Farmverwaltungsdatenbank
SbManagementDB	Service Bus-Farmverwaltungsdatenbank
WFResourceManagementDB	Workflow-Manager-Ressourcenverwaltungsspeicher
WFInstanceManagementDB	Workflow-Manager-Instanzverwaltungsspeicher
SbGatewayDatabase	Service Bus-Gatewaydatenbank
SBMessageContainer01 - n	Service Bus-Nachrichtencontainerdatenbanken

Hinsichtlich der Datenschicht sind bei der Notfallwiederherstellung drei wichtige Aufgaben zu berücksichtigen:

1. Vorbereitung – Sicherstellen, dass die richtige Sicherungs-/Replikationsstrategie für Ihre Datenbanken verwendet wird, damit bei einem Notfall, der die Datenbanken betrifft, keine Daten verloren gehen.

   Damit eine Wiederherstellung nach einem Notfall erfolgen kann, müssen Sie auf den Notfall vorbereitet sein. Insbesondere bei der Wiederherstellung nach Notfällen, die Datenbankverluste mit sich bringen, müssen Sie eine Kopie der Daten an einem anderen Speicherort speichern. Da es sich bei diesen Datenbanken um SQL-Standarddatenbanken handelt, wird empfohlen, bewährte SQL-Techniken zu verwenden:

   1. SQL-Spiegelung

   2. SQL-Replikation

   3. Einfache Sicherungen sowie eine Kombination aus Sicherungen und Protokollversand

   Sie können eine beliebige Technik abhängig von Ihrem Geschäftstyp und dem Genauigkeitsgrad der Daten auswählen, der zwischen der Sicherung und den primären Datenbanken bestehen soll.

   Im Wesentlichen wird von Ihnen als Administrator der Workflow-Manager-Farm erwartet, Sicherungen dieser Datenbanken mithilfe einer geeigneten Sicherungsstrategie zu erstellen, die Ihren Anforderungen genügt.Workflow-Manager stellt keine Funktionen zur Verfügung, die die Erstellung dieser Sicherungsdatenbanken unterstützen.

2. Wiederherstellen der Sicherungsdatenbanken

   Abhängig von Ihrer Datenreplikationsstrategie müssen Sie ein geeignetes Wiederherstellungstool bzw. einen -mechanismus zum Wiederherstellen der Sicherungsdatenbanken verwenden. Es stehen SQL-Tools und -Techniken nach Branchenstandard zur Verfügung, die zum Wiederherstellen der SQL-Datenbanken verwendet werden können.

3. Wiederherstellen der Workflow-Manager-Farm

   Dieser Schritt bezieht sich auf das Sicherstellen, dass die Workflow-Manager-Farm in einem konsistenten Status wiederhergestellt wird und ordnungsgemäß funktionieren kann.Workflow-Manager stellt die erforderlichen PowerShell-Skripts sowie Anleitungen zum Ausführen dieses Schritts zur Verfügung.

Serverschicht (Workflow-/Messagingschicht)

Sie können eine sekundäre Farm an einem sekundären Speicherort erstellen, um Szenarien für die Notfallwiederherstellung zu berücksichtigen. Sie können die sekundäre Farm vor oder nach dem Notfall erstellen. Drei Modelle können zu diesem Zweck verwendet werden.

1. Verzögert betriebsbereit

   In diesem Modell können Sie die Farm nach dem Auftreten des Notfalls erneut erstellen. Dies wirkt sich auf die benötigte Zeit zum Wiederherstellen der Farm aus, weil Sie neue Serverknoten bereitstellen und Workflow-Manager auf diesen Knoten neu installieren müssen.

2. Betriebsbereit

   Sie können dieses Modell normalerweise verwenden, wenn Sie sicherstellen möchten, dass die sekundäre Farm erstellt und getestet wurde, bevor ein Notfall eintritt. In diesem Modell stellen Sie Serverknoten in der neuen Farm bereit, bevor ein Notfall eintritt. Nachdem Sie die Beziehung der Datenbankpaare eingerichtet haben, verweisen Sie diese neue Farm auf die sekundären Datenbanken.

   Nachdem Sie diese neue Farm eingerichtet haben, deaktivieren Sie die Serverknoten, damit diese nicht im Leerlauf ausgeführt werden. Als Teil der Notfallwiederherstellung müssen Sie die Datenbankkonsistenzskripts ausführen, die von Workflow Manager bereitgestellt werden.

   Hinweis

   Dieses Modell geht davon aus, dass keine neuen Service Bus-Containerdatenbanken in der primären Installation erstellt werden, nachdem das Anfangssetup vorgenommen wurde. Wenn eine neue Service Bus-Containerdatenbank in der primären Installation erstellt wird, müssen bei der Wiederherstellung zusätzliche Schritte ausgeführt werden.

3. Unmittelbar betriebsbereit

   Dies bedeutet eine Verbesserung im Vergleich zum betriebsbereiten Modus, in dem die Serverknoten aktiviert sein können. Dieser Modus verkürzt die Zeitspanne bis zur Wiederherstellung nach einem Notfall.

   Warnung

   Der unmittelbar betriebsbereite Modus wird von Workflow-Manager nicht unterstützt.

Vorgang der Notfallwiederherstellung

In diesem Abschnitt wird der eigentliche Vorgang der Notfallwiederherstellung beschrieben, der für verschiedene der weiter oben beschriebenen Notfallszenarien verwendet wird. Auf hoher Ebene besteht der empfohlene Vorgang im Wiederherstellen der erforderlichen Datenbanken aus einer Sicherung (die mithilfe einer der SQL Server-Standardtechniken erstellt wurde) sowie im Verwenden der Wiederherstellungs-Cmdlets, die von Workflow-Manager zum Wiederherstellen einer Farm bereitgestellt werden.

Hinweis

Die folgenden Schritte beschreiben das Verwerfen der vorherigen Farmverwaltungsdatenbanken und deren erneute Erstellung.

Vorgang des Ausführens der Wiederherstellungsbefehle

1. Exportieren Sie das Service Bus-Farmzertifikat mit dem privatem Schlüssel und das Service Bus-Verschlüsselungszertifikat mit dem privaten Schlüssel. Importieren Sie beide Zertifikate in den Ordner "Lokaler Computer\Eigene Zertifikate" des neuen Servers. Importieren Sie außerdem die Stammzertifikate in den Ordner "Lokaler Computer\Vertrauenswürdige Stammzertifizierungsstelle" des neuen Servers. Sie können das Farmzertifikat und das Verschlüsselungszertifikat anhand der Ausgabe von "Get-SBFarm" identifizieren.

   Hinweis

   Der Import funktioniert nur, wenn auf die alten Service Bus-Verschlüsselungszertifikate aus den alten WFM-/SB-Servern Folgendes zutrifft:

   • Sie wurden während der alten Farmkonfiguration vom Konfigurationstool automatisch generiert.

   • Für den Fall, dass Sie ein benutzerdefiniertes Zertifikat für Service Bus in der alten Umgebung verwendet haben, muss es sich um Platzhalterzertifikate für Ihre Domäne handeln. Das Feld "Alternativer Antragstellername" im Zertifikat wurde also mit einem Wert wie etwa "- *. mydomainname.com" erstellt.

   Wenn der Import des alten Service Bus-Zertifikats nicht ausgeführt wird, tritt für das Cmdlet Restore-WFFarm in den folgenden Schritten ein Fehler ähnlich dem folgenden auf. 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. Öffnen Sie ein PowerShell-Fenster mit erhöhten Rechten (RunAs Administrator) auf dem neuen Computer.

3. Rufen Sie das Cmdlet Restore-SBFarm auf, und übergeben Sie die folgenden Parameter. Dieses Cmdlet erstellt eine neue Service Bus-Farmverwaltungsdatenbank. Die alte Service Bus-Farmverwaltungsdatenbank kann anschließend gelöscht werden.

   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>]
   

   Hinweis

   Wenn Sie benutzerdefinierte Platzhalterzertifikate in der alten Service Bus-Konfiguration und zwei verschiedene Zertifikate für "FarmCertificate" und "EncryptionCertificate" verwendet haben, müssen Sie beide Zertifikate für jeden neuen Knoten importieren und die Parameter FarmCertificateThumbprint und EncryptionCertificateThumbprint im oben aufgeführten Cmdlet entsprechend bereitstellen.

   Der folgende Codeausschnitt zeigt ein Beispiel für den Aufruf des Cmdlets 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. Rufen Sie das Cmdlet Restore-SBGateway für einen der Farmknoten mit den folgenden Parametern auf.

   Parameter	Beschreibung
   SBFarmDBConnectionString	Die Verbindungszeichenfolge der Service Bus-Farmdatenbank, die im vorherigen Schritt erstellt wurde.
   GatewayDBConnectionString	Die Verbindungszeichenfolge der wiederhergestellten Gatewaydatenbank.

   Der folgende Codeausschnitt zeigt ein Beispiel für den Aufruf des Cmdlets 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. Rufen Sie das Cmdlet Restore-SBMessageContainer für jede Containerdatenbank mit den folgenden Parametern auf. Führen Sie dieses Cmdlet auf einem der Farmcomputern aus.

   Parameter	Beschreibung
   SBFarmDBConnectionString	Die Verbindungszeichenfolge der Service Bus-Farmdatenbank, die im vorherigen Schritt erstellt wurde.
   ContainerDBConnectionString	Die Verbindungszeichenfolge der Containerdatenbank.
   ID	Die ID des wiederhergestellten Nachrichtencontainers. Rufen Sie die ID des wiederhergestellten Nachrichtencontainers aus der Tabelle [dbo].[ContainersTable] der Gatewaydatenbank ab. Diese enthält die IDs, Verbindungszeichenfolgen, Datenbankservernamen und Datenbanknamen aller Nachrichtencontainer. Wählen Sie die ID des Containers aus, dessen Datenbankname mit dem Namen der ursprünglichen Containerdatenbank übereinstimmt.

   Der folgende Codeausschnitt zeigt ein Beispiel für den Aufruf des Cmdlets Restore-SBMessageContainer.

   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. Rufen Sie das Cmdlet Add-SBHost auf, und übergeben Sie die folgenden Parameter.

   Parameter	Beschreibung
   SBFarmDBConnectionString	Die Verbindungszeichenfolge der Service Bus-Farmdatenbank, die im vorherigen Schritt erstellt wurde.
   CertificateAutoGenerationKey	Dies ist der Schlüssel, der zum automatischen Generieren von SB-Zertifikaten verwendet wird.
   RunAsPassword	Eine Zeichenfolge vom Typ SecureString, die das Kennwort des Kontos enthält, unter dem die Service Bus-Prozesse ausgeführt werden.
   EnableFirewallRules	True, wenn die Firewallregeln des Hosts aktualisiert werden sollen, damit Service Bus-Daten die Firewall durchlaufen können. Andernfalls False.

   Das folgende Beispiel zeigt den Aufruf des Cmdlets.

   $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. Rufen Sie das Cmdlet Restore-WFFarm auf, und verwenden Sie die Verbindungszeichenfolgen "ResourceManagement" und "InstanceDatabase".

   Das folgende Beispiel zeigt den Aufruf des Cmdlets.

   $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
   

   Hinweis

   Die Angabe InstanceStateSyncTime muss das genaue Format aufweisen, das im vorherigen Beispiel angegeben wurde. ConsistencyVerifierLogPath sollte der Pfad zu einem Ordner sein, in den dieses Cmdlet Protokolle schreibt, die sich auf den Wiederherstellungsvorgang beziehen.

8. Rufen Sie das Cmdlet Add-WFHost auf.

   Das folgende Beispiel zeigt den Aufruf des Cmdlets.

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

Szenario 1 - Der Notfall betrifft den gesamten Cluster

In diesem Szenario ist der gesamte Cluster von dem Notfall betroffen. Für die Wiederherstellung nach diesem Notfallszenario muss der gesamte Cluster mithilfe der aktuellsten Datenbanksicherungen neu erstellt werden.

1. Installieren Sie Workflow-Manager 1.0 auf einem neuen Computer.

   Hinweis

   Installieren Sie Workflow-Manager 1.0 mithilfe des Installers, beginnen Sie jedoch nicht mit der Konfiguration der Farm.

2. Stellen Sie die gesicherten primären Datenbank mithilfe der Wiederherstellungsfunktionen von SQL Server wieder her. Dieser Schritt ist je nach ausgewählter Sicherungslösung unterschiedlich.

   Nur die folgende Datenbank sollte wiederhergestellt werden.

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   Wichtig

   Stellen Sie die Datenbanken WFManagementDB und SbManagementDb nicht wieder her, weil diese als Teil des Wiederherstellungsvorgangs neu erstellt werden.

3. Führen Sie die unter Vorgang des Ausführens der Wiederherstellungsbefehle beschriebenen Schritte aus.

Szenario 2 - Der Notfall betrifft nur die SQL Server-Datenbanken

In diesem Fall geht mindestens eine von Workflow-Manager verwendete Datenbank verloren, oder der Zugriff darauf ist nicht möglich. Dies kann durch einen Hardwarefehler oder einen anderen Notfall verursacht werden, der nur die Computer mit SQL Server betrifft.

Hinweis

Die Schritte in diesem Szenario sollten auch befolgt werden, um die Migration aus einem in ein anderen Datencenter auszuführen, indem die aktuellste Sicherung der Datenbank in das neue Datencenter übertragen und der in diesem Abschnitt beschriebene Vorgang verwendet wird.

1. Deinstallieren Sie Workflow-Manager 1.0 von einem der vorhandenen Anwendungsserverknoten.

2. Installieren Sie Workflow-Manager 1.0 auf dem Server aus dem vorherigen Schritt erneut.

   Hinweis

   Installieren Sie Workflow-Manager mithilfe des Installers, beginnen Sie jedoch nicht mit der Konfiguration der Farm.

3. Stellen Sie die gesicherten primären Datenbank mithilfe der Wiederherstellungsfunktionen von SQL Server wieder her. Dieser Schritt ist je nach ausgewählter Sicherungslösung unterschiedlich. Sie können die Wiederherstellung abhängig von der Art des Notfalls auf dem vorhandenen Computer mit SQL Server oder auf einem anderen Computer mit SQL Server vornehmen.

4. Führen Sie die unter Vorgang des Ausführens der Wiederherstellungsbefehle beschriebenen Schritte aus.

Nachdem diese Schritte abgeschlossen sind, verfügen Sie über eine Farm mit einem Knoten, die die vorhandenen Datenbanken verwendet. Diese Farm wurde mit Ihren Sicherungskopien der ursprünglichen Datenbanken wiederhergestellt, und diese Farm wurde in einen konsistenten Zustand versetzt, damit sie vollständig funktionsfähig ist.

Führen Sie für jeden Knoten, der Bestandteil der primären Farm war, die folgenden Schritte aus.

1. Deinstallieren Sie Workflow-Manager 1.0.

2. Installieren Sie den Workflow-Manager 1.0 erneut.

3. Führen Sie die Cmdlets "Add-SBHost" und "Add-WFHost" wie unter Vorgang des Ausführens der Wiederherstellungsbefehle beschrieben aus.

Szenario 3 - Der Notfall betrifft nur die Anwendungsserver

Manchmal stürzen nur Ihre Anwendungsserver aufgrund eines lokalen Notfalls ab oder gehen verloren, und ihre Datenbankserver bleiben intakt. Obwohl dieses Szenario in einem Datencenter selten vorkommt, ist die Wiederherstellung nach einem solchen Notfall relativ einfach. Da die Datenbanken nicht verloren gegangen sind, können Sie den primären Speicherort weiterhin verwenden und dieser vorhandenen Farm neue Knoten hinzufügen. Wenn Sie es aus bestimmten Gründen bevorzugen, zum sekundären Speicherort zu wechseln, können Sie die Datenbanken an den sekundären Speicherort kopieren und beim Ausführen der Wiederherstellungsschritte auf die neuen Datenbanken verweisen.

Führen Sie die folgenden Schritte aus, um die Wiederherstellung nach Anwendungsserver-Notfallszenarien auszuführen.

1. Installieren Sie Workflow-Manager 1.0 auf einem neuen Computer.

2. Legen Sie die folgenden Datenbanken ab.

   • WFManagementDB

   • SbManagementDB

3. Führen Sie das unter Vorgang des Ausführens der Wiederherstellungsbefehle beschriebenen Verfahren aus.

   Hinweis

   Wenn Sie die Datenbanken verschoben haben, verweisen Sie auf die neuen Datenbanken, wenn Sie diese Schritte ausführen. Verweisen Sie andernfalls auf die ursprünglichen Datenbanken.

Nachdem diese Schritte abgeschlossen sind, verfügen Sie über eine Farm mit einem Knoten, die die vorhandenen (oder verschobenen) Datenbanken verwendet. Wenn gewünscht, können Sie der Farm weitere Knoten auf die gleiche Weise hinzufügen, wie Sie einer Workflow Manager-Farm weitere Knoten hinzufügen würden.

Bereichswiederherstellung

Unter bestimmten Umständen können Sie versehentlich einen bestimmten Bereich löschen, oder die Inhalte eines bestimmten Bereichs sind fehlerhaft. Sie verfügen außerdem über eine Sicherung der Workflow-Manager-Datenbanken, in der die Inhalte des Bereichs ordnungsgemäß sind. Sie können die Inhalte dieses Bereichs ausschließlich aus der vorhandenen Sicherheitskopie wiederherstellen.

Wenn Sie einen Bereich wiederherstellen, werden die folgenden Inhalte wiederhergestellt.

• Bereiche und untergeordnete Bereiche zusammen mit ihren Konfigurationen.

• Aktivitäten in der Bereichshierarchie, die wiederhergestellt wird.

• Workflows in der Bereichshierarchie zusammen mit ihren Konfigurationen.

• Instanzen für Workflows in der Bereichshierarchie.

  • Instanzen setzen ihre Ausführung ab dem letzten Persistenzpunkt fort.

• Nachverfolgungsdatensätze, die diesen Instanzen entsprechen.

• Alle nicht zugestellten Nachrichten für Workflows in dieser Bereichshierarchie.

Hinweis

Wenn Sie einen Bereich löschen, wird sein gesamter Inhalt (einschließlich der Instanzen und Nachverfolgungsdatensätze) innerhalb weniger Minuten bereinigt (der Vorgang ist asynchron).

In der folgenden Tabelle wird die Schlüsselterminologie bei einem Bereichswiederherstellungsvorgang beschrieben.

Ausdruck	Beschreibung
Sicherungsdatenbanken	Es wird vorausgesetzt, dass Sie einer Sicherung aller Datenbanken vorgenommen haben, die von Workflow-Manager verwendet werden, und dass der Bereich, der wiederhergestellt werden soll, in dieser Sicherungskopie verfügbar ist. Anders ausgedrückt, fungiert diese Datenbank als Quelldatenbank zum Kopieren der Inhalte dieses Bereichs.
Livedatenbanken	Dieser Begriff bezieht sich auf die aktuell aktiven Datenbanken in Ihrer Workflow-Manager-Farm. Anders ausgedrückt, ist dies die Zieldatenbank für den Bereichswiederherstellungsvorgang.
Der wiederherzustellende Bereich.	Sie können einen beliebigen Bereich in der Bereichshierarchie angeben, der aus einer Sicherungsdatenbank wiederhergestellt werden soll.

Workflow-Manager stellt Funktionen zur Verfügung, die dieses Szenario ermöglichen. Sie müssen die folgenden Schritte ausführen, um eine Bereichswiederherstellung auszuführen.

• Bereichswiederherstellungsvorgang

• Erwägungen für die Bereichswiederherstellung

Bereichswiederherstellungsvorgang

Der wiederherzustellende Bereich sollte nicht in der oder den Livedatenbank(en) vorhanden sein. Wenn Sie einen Bereich aus einer Sicherung wiederherstellen, weil Ihre Livedatenbank eine fehlerhafte Kopie dieses Bereichs enthält, müssen Sie daher diesen fehlerhaften Bereich aus der Livedatenbank löschen.

1. Wiederherstellen der SQL-Datenbanken: Der erste Schritt ist das Wiederherstellen der SQL-Datenbanken mithilfe der Sicherungen, wie unter Wiederherstellen einer Datenbanksicherung (SQL Server Management Studio) beschrieben.

   Wichtig

   Sie müssen die Sicherungsdatenbanken auf einem anderen Server wiederherstellen. Überschreiben Sie nicht die Livedatenbanken.

2. Führen Sie den PowerShell-Befehl Restore-WFScope aus, indem Sie die folgenden Parameter übergeben:

   • Pfad des wiederherzustellenden Bereichs.

   • Verbindungszeichenfolge der Sicherungs-Ressourcendatenbank.

   • Verbindungszeichenfolge der Sicherungs-Instanzdatenbank.

   • Stellen Sie die Zeit zur Verfügung, zu der die Sicherungen erstellt wurden – dabei kann es sich um einen groben Schätzwert handeln. Wenn die Datenbanken zu verschiedenen Zeiten gesichert wurden, stellen Sie sicher, dass der älteste dieser Zeitstempel als Eingabe für diesen Schritt bereitgestellt wird.

   • Verbindungszeichenfolge der Gatewaydatenbank.

   • Verbindungszeichenfolgen mindestens einer Containerdatenbank. Normalerweise verfügen Sie nur über eine Containerdatenbank. Wenn Ihr Server mehrere Containerdatenbanken aufweist, stellen Sie sicher, dass Sie alle diese Verbindungszeichenfolgen für dieses Cmdlet bereitstellen.

   Zu diesem Zeitpunkt sollten der Bereich und seine Inhalte in der Livedatenbank wiederhergestellt worden sein, und die neu wiederhergestellten Sicherungsdatenbanken können entfernt werden.

Erwägungen für die Bereichswiederherstellung

Die Bereichswiederherstellung stellt Ihren Bereich aus mindestens einer gesicherten und wiederhergestellten Datenbank wieder her. Dabei sollten die folgenden Punkte für den gesamten Wiederherstellungsvorgang beachtet werden.

• Sie können einen Bereich nur aus einer vorherigen Sicherungskopie der aktuellen Livedatenbank wiederherstellen. Anders ausgedrückt: Es ist nicht möglich, einen bestimmten Bereich aus einer Workflow-Manager-Farm in eine andere -Farm zu verschieben.

• Die Bereichswiederherstellung stellt nur die Inhalte wieder her, die zu einem Bereich und allen seinen untergeordneten Bereichen gehören. Sie stellt keine Inhalte wieder her, die außerhalb der untergeordneten Hierarchie dieses Bereichs liegen.

• Wenn eine Aktivität oder ein Workflow auf eine andere Aktivität außerhalb dieser Bereichshierarchie verweist (z. B., wenn die Aktivität, auf die verwiesen wird, in einem übergeordneten Bereich über dem Bereich liegt, der wiederhergestellt wird), wird die Aktivität, auf die verwiesen wird, nicht als Teil dieses Vorgangs wiederhergestellt. Dies bedeutet, dass solche Workflows ungültig sind. Jeder Versuch, eine Instanz eines solchen Workflows zu erstellen, führt zu Fehlern.