Восстановление после сбоев и восстановление областей в Workflow Manager 1.0

 

В этом разделе описываются возможности и процедуры восстановления после сбоев в Диспетчер рабочих процессов 1.0. Здесь описаны процедуры на случай сбоев серверов баз данных и приложений, а также процедуры восстановления поврежденных и удаленных областей.

Диспетчер рабочих процессов 1.0 позволяет предусмотреть сценарии восстановления после сбоев. В рамках этого раздела сбоем называется событие, вызывающее серьезные потери, разрушения, трудности и так далее. В случае серверного продукта это может быть любое событие, приводящее к длительному нарушению доступности сервера, которое может сопровождаться (в различной степени) полной или частичной потерей исходного кластера, настроенного для сервера.

Обычно Восстановление после сбоев связывается с высоким уровнем доступности. Высокий уровень доступности позволяет гарантировать доступность службы в обычных условиях, включая достаточную степень избыточности системы и устранение единственных точек сбоя. При этом восстановление после сбоя решает другую проблему — если основная служба перестает работать из-за непредвиденных обстоятельств (например, из-за стихийного бедствия), но требуется поддерживать службы на том же уровне.

Процесс подготовки и самого восстановления можно разделить на несколько этапов, описанных ниже. На этой схеме описаны все эти этапы и указаны сферы ответственности пользователя и возможности Диспетчер рабочих процессов.

Workflow Manager 1.0 Manageability Diagram

В случае Диспетчер рабочих процессов можно подготовиться к разным видам сбоев.

  1. Сбой, который приводит к потере баз данных Диспетчер рабочих процессов.

    1. Он может вызываться сбоем оборудования или аварией в центре обработки данных.

  2. Сбой, который приводит к потере серверов приложений Диспетчер рабочих процессов.

  3. Сбой, приводящий к потере всего кластера — баз данных и серверов приложений.

Поскольку Диспетчер рабочих процессов хранит данные о рабочих процессах, действиях и экземплярах, ключевой аспект восстановления после сбоев в Диспетчер рабочих процессов — возможность восстановления данных Диспетчер рабочих процессов по резервным копиям. В большинстве подобных сценариев восстановление после сбоя в целом сводится к восстановлению данных по резервным копиям и обеспечению согласованности данных в различных подсистемах Диспетчер рабочих процессов.

Восстановление после сбоев — это вопрос подготовки к возможным экстренным ситуациям. В Диспетчер рабочих процессов вы можете сохранить данные о всех действиях, рабочих процессах и экземплярах даже при аварии.

Диспетчер рабочих процессов хранит все свои данные в БД SQL Server. Поэтому важное требование для восстановления после сбоев — настройка периодического резервного копирования или избыточности данных, чтобы в случае сбоя в ЦОД сохранилась недавняя копия БД, которую можно было бы использовать для восстановления Диспетчер рабочих процессов.

Диспетчер рабочих процессов использует следующие БД.

Имя базы данных

Описание

WFManagementDB

База данных управления фермой Диспетчер рабочих процессов

SbManagementDB

База данных управления фермой Служебная шина

WFResourceManagementDB

БД управления ресурсами Диспетчер рабочих процессов

WFInstanceManagementDB

БД управления экземплярами Диспетчер рабочих процессов

SbGatewayDatabase

База данных шлюза Служебная шина

SBMessageContainer01 - n

БД контейнеров сообщений Служебная шина

В зависимости от того, насколько важны данные ваших рабочих процессов в Диспетчер рабочих процессов, вы можете использовать несколько вариантов подготовки к восстановлению после сбоев. Так как все данные Диспетчер рабочих процессов хранятся в описанных БД SQL Server, все стратегии обеспечения высокого уровня доступности и резервного копирования для SQL Server также применимы для Диспетчер рабочих процессов.

Дополнительные сведения о реализации высокого уровня доступности и восстановления после сбоев для SQL Server с использованием см. в разделах Выбор решения высокого уровня доступности и Описание вариантов восстановления после сбоев для Microsoft SQL Server.

System_CAPS_noteПримечание

Вне зависимости от выбранного варианта не следует слишком сильно разносить резервные копии по времени. Например, трудно восстановить Диспетчер рабочих процессов как следует, если копии отдельных БД отстоят друг от друга на часы и дни.

На следующей схеме описаны различные компоненты Диспетчер рабочих процессов.

Workflow Manager 1.0 Server Farm Administrator Vie

С точки зрения администратора фермы серверов есть две части Диспетчер рабочих процессов, которые могут быть затронуты сбоем. Это базы данных или серверы приложений. Возможно отключение различных сочетаний БД и серверов приложений, но в общем случае точки сбоя — это либо уровень данных, либо уровень приложений.

Диспетчер рабочих процессов 1.0 хранит все свои данные в следующих БД SQL Server.

Имя базы данных

Описание

WFManagementDB

База данных управления фермой Диспетчер рабочих процессов

SbManagementDB

База данных управления фермой Служебная шина

WFResourceManagementDB

БД управления ресурсами Диспетчер рабочих процессов

WFInstanceManagementDB

БД управления экземплярами Диспетчер рабочих процессов

SbGatewayDatabase

База данных шлюза Служебная шина

SBMessageContainer01 - n

БД контейнеров сообщений Служебная шина

Для уровня данных есть три важных задачи, касающихся восстановления после сбоев.

  1. Подготовка — гарантия того, что вы используете правильную стратегию резервного копирования и репликации БД, чтобы не потерять данные при сбое, коснувшемся БД.

    Для восстановления следует проводить подготовку. Для БД это означает хранение копий данных в другом месте. Так как это обычные БД SQL, рекомендуется использовать проверенные методики для SQL, например:

    1. Зеркальное отображение SQL

    2. Репликация SQL

    3. Простые резервные копии, а также сочетание резервного копирования и доставки журналов

    Вы можете использовать любой из этих методов в зависимости от сути вашей деятельности и желаемого уровня актуальности резервных копий.

    По сути вы как администратор фермы Диспетчер рабочих процессов должны создавать резервные копии этих баз данных с помощью подходящей для вас стратегии.Диспетчер рабочих процессов не предоставляет никаких возможностей для помощи в создании резервных копий этих баз данных.

  2. Восстановление резервных БД

    В зависимости от стратегии репликации данных вам следует использовать подходящий механизм восстановления БД. Существуют стандартные для отрасли методы и средства восстановления БД SQL.

  3. Восстановление фермы Диспетчер рабочих процессов

    Это процесс восстановления фермы Диспетчер рабочих процессов в согласованное и работоспособное состояние.Диспетчер рабочих процессов предоставляет необходимые скрипты PowerShell и инструкции, необходимые для выполнения этого шага.

Вы можете создать в другом месте дополнительную ферму, обеспечивающую возможность восстановления после сбоев. Создать ее можно до сбоя или после него. Существует три возможных модели.

  1. Холодное резервирование

    В этой модели вы можете заново создать ферму после сбоя. Это занимает определенное время, так как вам потребуется подготовить вычислительные узлы и установить на них Диспетчер рабочих процессов.

  2. Теплое резервирование

    Обычно эта модель используется, если вам нужно создать и проверить дополнительную ферму до того, как произойдет сбой. В этой модели вычислительные узлы в новой ферме готовятся до сбоя. После связывания баз данных вам следует указать для этой новой фермы дополнительные базы данных.

    Настроив ферму, можно выключить ее вычислительные узлы, чтобы они не работали впустую. В рамках восстановления после сбоев следует использовать сценарии проверки согласованности БД из Workflow Manager.

    System_CAPS_noteПримечание

    В этой модели предполагается, что новые БД контейнеров Служебная шина не создаются в основной ферме после начальной настройки. Если в основной ферме создается новая БД контейнера Служебная шина, при восстановлении потребуются дополнительные действия.

  3. Горячее резервирование

    Это расширение теплого резервирования — вычислительные узлы здесь могут работать. Это ускоряет восстановление после сбоев.

    System_CAPS_warningПредупреждение

    Этот метод не поддерживается Диспетчер рабочих процессов.

В этом разделе описывается фактический процесс восстановления при различных сбоях, описанных ранее. В общем случае рекомендуется восстановить БД по резервным копиям, созданным стандартными методами SQL Server, и использовать командлеты восстановления из Диспетчер рабочих процессов, чтобы восстановить ферму.

System_CAPS_noteПримечание

Далее описан процесс удаления старых БД управления фермой и их воссоздания.

  1. Экспортируйте сертификат фермы служебной шины с закрытым ключом и сертификат шифрования служебной шины с закрытым ключом. Импортируйте оба сертификата в папку Local Computer\Personal нового сервера. Также импортируйте корневые сертификаты в папку Local Computer\Trusted Root Authority нового сервера. Сертификат фермы и сертификат шифрования можно найти в выходных данных Get-SBFarm.

    System_CAPS_noteПримечание

    Импорт возможен, только если старые сертификаты шифрования служебной шины со старых серверов WFM/SB:

    • были автоматически созданы во время настройки старой фермы средством настройки;

    • или, если вы использовали пользовательский сертификат для служебной шины в старой среде, этот сертификат должен быть групповым сертификатом для домена: например, в поле "Альтернативное имя субъекта" сертификата должно быть значение типа "*.доменное_имя.com".

    Если импорт сертификата старой служебной шины не был выполнен, произойдет сбой командлета Restore-WFFarm в последующих действиях с ошибкой, аналогичной следующей.

    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 с повышенными привилегиями на новой машине.

  3. Вызовите командлет Restore-SBFarm со следующими параметрами. Он создает новую БД управления фермой Служебная шина. Старую БД управления фермой Служебная шина затем можно удалить.

    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>]
    
    
    System_CAPS_noteПримечание

    Если вы использовали пользовательские групповые сертификаты в конфигурации старой служебной шины и использовали два разных сертификата для FarmCertificate (сертификата фермы) и EncryptionCertificate (сертификата шифрования), потребуется импортировать их оба на каждый новый узел и предоставить параметры (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 на одном из узлов фермы со следующими параметрами.

    Параметр

    Описание

    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 со следующими параметрами. Выполните этот командлет на одном из компьютеров фермы.

    Параметр

    Описание

    SBFarmDBConnectionString

    Строка подключения к БД фермы Service Bus, созданной ранее.

    ContainerDBConnectionString

    Строка подключения для базы данных контейнера.

    Id

    Идентификатор восстановленного контейнера сообщений.

    ИД восстановленного контейнера можно найти в таблице [dbo].[ContainersTable] БД шлюза, где хранятся ИД, строки подключения, имена серверов БД и имена самих БД для всех контейнеров сообщений. Выберите ИД контейнера, имя БД которого соответствует имени БД исходного контейнера.

    Ниже приведен пример вызова командлета 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. Вызовите командлет Add-SBHost со следующими параметрами.

    Параметр

    Описание

    SBFarmDBConnectionString

    Строка подключения к БД фермы Service Bus, созданной ранее.

    CertificateAutoGenerationKey

    Это ключ для автоматически создаваемых сертификатов SB.

    RunAsPassword

    SecureString, содержащий пароль учетной записи, с которой работают процессы Service Bus.

    EnableFirewallRules

    Значение true, если правила брандмауэра на узле следует обновить, чтобы обеспечить прохождение данных Service Bus. В противном случае — false.

    В следующем примере демонстрируется использование командлета.

    $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 и используйте строки подключения к базам данных управления ресурсами и экземпляров.

    В следующем примере демонстрируется использование командлета.

    $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
    
    
    System_CAPS_noteПримечание

    InstanceStateSyncTime должен иметь в точности такой формат, какой был использован в примере выше. ConsistencyVerifierLogPath должен содержать путь к папке, куда командлет сохранит журналы восстановления.

  8. Вызовите командлет Add-WFHost.

    В следующем примере демонстрируется использование командлета.

    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.0 на новой машине.

    System_CAPS_noteПримечание

    Установите Диспетчер рабочих процессов 1.0 с помощью установщика, но не запускайте настройку фермы.

  2. Восстановите резервные копии основных баз данных средствами SQL Server. Этот шаг зависит от того, какой метод резервного копирования вы используете.

    Восстановить достаточно следующие БД.

    • WFResourceManagementDB

    • WFInstanceManagementDB

    • SbGatewayDatabase

    • SBMessageContainer*

    System_CAPS_importantВажно

    Не восстанавливайте WFManagementDB и SbManagementDb, так как они будут созданы заново.

  3. Следуйте указаниям в разделе Процедура запуска команд восстановления.

В этом случае недоступна часть БД Диспетчер рабочих процессов. Он может вызываться сбоем оборудования или аварией, затронувшими исключительно SQL Server.

System_CAPS_noteПримечание

В этом случае также можно перейти из одного ЦОД в другой, перенеся последние резервные копии БД в новый центр и используя процесс, описанный ниже.

  1. Удалите Диспетчер рабочих процессов 1.0 с одного из имеющихся узлов приложений.

  2. Переустановите Диспетчер рабочих процессов 1.0 на сервере из предыдущего шага.

    System_CAPS_noteПримечание

    Установите Диспетчер рабочих процессов с помощью установщика, но не запускайте настройку фермы.

  3. Восстановите резервные копии основных баз данных средствами SQL Server. Этот шаг зависит от того, какой метод резервного копирования вы используете. Вы можете выполнить восстановление в имеющемся SQL Server или новом SQL Server в зависимости от природы сбоя.

  4. Следуйте указаниям в разделе Процедура запуска команд восстановления.

Когда все будет готово, вы получите ферму с одним узлом, использующую существующие БД. Эта ферма была восстановлена по резервным копиям исходных БД, она согласована и работоспособна.

На всех узлах из состава основной фермы выполните следующие действия.

  1. Удалите Диспетчер рабочих процессов 1.0.

  2. Переустановите Диспетчер рабочих процессов 1.0.

  3. Запустите командлеты Add-SBHost и Add-WFHost, как показано в Процедура запуска команд восстановления.

Иногда сбой затрагивает только серверы приложений, а серверы БД остаются нетронутыми. Хотя такое случается редко, восстановление в этом случае довольно просто. Так как БД не потеряны, никуда переходить не надо — достаточно добавить новые узлы в существующую ферму. Если вы все же хотите перейти в новый ЦОД, вы можете скопировать туда БД и использовать копии при восстановлении.

Для восстановления при сбое серверов приложений выполните следующие действия.

  1. Установите Диспетчер рабочих процессов 1.0 на новой машине.

  2. Удалите следующие базы данных.

    • WFManagementDB

    • SbManagementDB

  3. Следуйте указаниям в разделе Процедура запуска команд восстановления.

    System_CAPS_noteПримечание

    Если вы перемещали базы данных, укажите новые базы данных на дальнейших этапах. В противном случае указывайте исходные базы данных.

Когда все будет готово, вы получите ферму с одним узлом, использующую существующие (или перемещенные) БД. При желании вы можете добавить в ферму дополнительные узлы так же, как и обычно.

Возможны ситуации, когда вы случайно удаляете область или повреждаете ее. Вы также располагаете резервными копиями БД Диспетчер рабочих процессов, в которых область в порядке. Это позволяет вам восстановить только эту очередь по резервной копии.

При восстановлении очереди восстанавливается следующее содержимое.

  • Области и дочерние области вместе с конфигурацией

  • Действия в иерархии областей

  • Рабочие процессы в иерархии областей вместе с конфигурацией

  • Экземпляры рабочих процессов в иерархии областей

    • Экземпляры продолжат выполнение с последней точки сохранения.

  • Записи отслеживания для этих экземпляров.

  • Все недоставленные сообщения для рабочих процессов в иерархии областей

System_CAPS_noteПримечание

При удалении области все ее содержимое, включая экземпляры и записи отслеживания, удаляется в течение нескольких минут, так как это асинхронная процедура.

В следующей таблице приведены ключевые термины для восстановления области.

Термин

Описание

Резервные базы данных

Предполагается, что вы создали резервные копии всех БД Диспетчер рабочих процессов, и восстанавливаемая область доступна в них. Другими словами, такая БД будет источником содержимого области.

Активные базы данных

Это текущие работающие БД в ферме Диспетчер рабочих процессов. Другими словами, это конечная база данных для процедуры восстановления.

Восстанавливаемая область

Вы можете указать для восстановления любую область в иерархии из резервной БД.

Диспетчер рабочих процессов позволяет реализовать данный сценарий. Далее описаны действия по восстановлению области.

Восстанавливаемой области не должно существовать в активных базах данных. Если вы восстанавливаете поврежденную область, сначала удалите ее из активной БД.

  1. Восстановление БД SQL Сначала нужно восстановить базы данных SQL по резервным копиям в соответствии с инструкциями в разделе Восстановление базы данных из резервной копии (SQL Server Management Studio).

    System_CAPS_importantВажно

    Необходимо восстановить резервные базы данных на другом сервере. Не перезаписывайте активные БД.

  2. Выполните команду PowerShell Restore-WFScope со следующими параметрами.

    • Путь к восстанавливаемой области

    • Строка подключения к резервной БД ресурсов

    • Строка подключения к резервной БД экземпляров

    • Укажите время создания резервных копий — это может быть грубая оценка. Если копии создавались в разное время, укажите самую раннюю отметку времени.

    • Строка подключения к БД шлюза

    • Строки подключения к БД контейнеров. Обычно используется только одна БД контейнера. Если на вашем сервере их несколько, укажите в командлете все строки подключения к ним.

    На этом этапе область и ее содержимое должны быть восстановлены в активной БД, поэтому восстановленные резервные копии можно удалить.

Хотя вы можете восстановить область по резервной копии БД, необходимо учесть следующее.

  • Область можно восстановить только по резервной копии текущей активной БД. Другими словами, вы не можете переместить область из одной фермы Диспетчер рабочих процессов в другую.

  • Восстановление касается только содержимого самой области и ее дочерних областей. Оно не затрагивает содержимое вне дочерней иерархии области.

  • Если действие или рабочий процесс содержит внешнюю ссылку на действие вне иерархии данной области (например, в родительской области), то действие по ссылке не будет восстановлено. Это значит, что такие рабочие процессы окажутся недопустимыми, а попытки создания их экземпляров будут приводить к ошибкам.

Добавления сообщества

ДОБАВИТЬ
Показ: