Экспорт (0) Печать
Развернуть все

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

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

Восстановление после сбоев

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

Восстановление после сбоев и высокий уровень доступности

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

Высокоуровневая модель восстановления после сбоев

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

Диаграмма управляемости диспетчера рабочих процессов 1.0

Различные виды восстановления после сбоев в Workflow Manager

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

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

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

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

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

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

Подготовка восстановления после сбоев

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

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

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

 

Имя базы данных Описание

WFManagementDB

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

SbManagementDB

База данных управления фермой Service Bus

WFResourceManagementDB

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

WFInstanceManagementDB

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

SbGatewayDatabase

База данных шлюза Service Bus

SBMessageContainer01 - n

БД контейнеров сообщений Service Bus

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

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

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

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

Представление администратора фермы серверов диспетчера рабочих процессов 1.0

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

Уровень данных

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

 

Имя базы данных Описание

WFManagementDB

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

SbManagementDB

База данных управления фермой Service Bus

WFResourceManagementDB

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

WFInstanceManagementDB

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

SbGatewayDatabase

База данных шлюза Service Bus

SBMessageContainer01 - n

БД контейнеров сообщений Service Bus

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

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

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

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

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

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

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

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

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

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

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

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

Уровень вычислений (рабочие процессы и сообщения)

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

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

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

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

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

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

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

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

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

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

Процесс восстановления после сбоев

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

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

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

  1. Откройте консоль PowerShell с повышенными привилегиями на новой машине.

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

     

    Параметр Описание

    RunAsAccount

    Учетная запись, с которой работают службы Service Bus. Это должна быть та же учетная запись, что и в старой ферме.

    GatewayDBConnectionString

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

    SBFarmDBConnectionString

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

    CertificateAutoGenerationKey

    SecureString, содержащий парольную фразу для защиты нового сертификата фермы, создаваемого этим командлетом.

    MessageBrokerPort

    Порт для связи с брокером сообщений. Это должен быть тот же порт, что использовался в старой ферме. Если значение не задано, используется значение по умолчанию.

    HttpsPort

    Порт для связи по HTTPS. Это должен быть тот же порт, что использовался в старой ферме. Если значение не задано, используется значение по умолчанию.

    TcpPort

    Порт для связи по TCP. Это должен быть тот же порт, что использовался в старой ферме. Если значение не задано, используется значение по умолчанию.

  3. Вызовите командлет Restore-SBGateway на одном из узлов фермы со следующими параметрами.

     

    Параметр Описание

    SBFarmDBConnectionString

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

    GatewayDBConnectionString

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

  4. Вызовите командлет Update-SBHost на всех узлах фермы.

  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.

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

    PS C:\Windows\system32> $sec = ConvertTo-SecureString -Force -AsPlainText TwistAndShout#2012
    PS C:\Windows\system32> Add-SBHost -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog=SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" -CertificateAutoGenerationKey $sec
    командлет Add-SBHost в позиции конвейера команд 1
    Укажите значения следующих параметров:
    RunAsPassword: ******************
    EnableFirewallRules: yes
  7. Вызовите командлет Restore-WFFarm и используйте строки подключения к базам данных управления ресурсами и экземпляров.

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

    PS C:\Windows\system32> Restore-WFFarm
    командлет Restore-WFFarm в позиции конвейера команд 1
    Укажите значения следующих параметров:
    InstanceDBConnectionString: Data Source=localhost;Initial Catalog=WFInstanceManagementDB;Integrated Security=SSPI;Asynchronous Processing=True
    ResourceDBConnectionString: Data Source=localhost;Initial Catalog=WFResourceManagementDB;Integrated Security=SSPI;Asynchronous Processing=True
    InstanceStateSyncTime: September 7, 2012 11:00:00 AM
    ConsistencyVerifierLogPath: c:\windows\System32\helloLog
    WFFarmDBConnectionString: Data Source=localhost;Initial Catalog=WFManagementDB;Integrated Security=SSPI;Asynchronous Processing=True
    CertificateAutoGenerationKey: **********
    noteПримечание
    InstanceStateSyncTime должен иметь в точности такой формат, какой был использован в примере выше. ConsistencyVerifierLogPath должен содержать путь к папке, куда командлет сохранит журналы восстановления.

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

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

    PS C:\Windows\system32> $secWF = ConvertTo-SecureString -Force -AsPlainText pass@word1
    PS C:\Windows\system32> Add-WFHost -WFFarmDBConnectionString "Data Source=localhost;Initial Catalog=WFManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" -CertificateAutoGenerationKey $secWF
    командлет Add-WFHost в позиции конвейера команд 1
    Укажите значения следующих параметров:
    RunAsPassword: ******************
    EnableFirewallRules: yes

Сценарий 1. Сбой затронул весь кластер

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

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

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

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

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

    • WFResourceManagementDB

    • WFInstanceManagementDB

    • SbGatewayDatabase

    • SBMessageContainer*

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

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

Сценарий 2. Сбой затронул только БД SQL Server

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

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

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

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

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

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

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

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

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

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

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

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

Сценарий 3. Сбой затронул только серверы приложений

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

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

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

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

    • WFManagementDB

    • SbManagementDB

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

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

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

Восстановление областей

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

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

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

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

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

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

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

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

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

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

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

 

Термин Описание

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

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

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

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

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

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

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

Процедура восстановления области

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

  1. Восстановление БД SQL Сначала нужно восстановить БД SQL по резервным копиям, как рассказывается по ссылке ниже. Restore a Database Backup (SQL Server Management Studio)

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

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

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

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

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

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

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

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

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

Вопросы восстановления областей

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

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

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

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


Workflow Manager 1.0 MSDN Community Forum


Дата сборки:

2013-10-23

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

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