Проблема.
До недавнего времени масштабируемость службы WorkFlow достигалась лишь за счет увеличения числа процессов. Но данный способ решения является временным и рано или поздно приводит к некоторым проблемам.
Среди этих проблем можно отметить резкое возрастание количества тупиков (DeadLock - ситуация в многозадачной среде или СУБД, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, занятых самими этими процессами). Тупики, помимо проблем при работе, вызывают множество проблем при отладке, т.к. для их возникновения нужны специфические условия одновременного выполнения нескольких процессов.
Также, в определенных ситуациях, при изменении количества процессов могли появиться не обрабатываемые задачи.
Решение.
Учитывая вышесказанное, было принято решение добавить возможность распределения задач между несколькими службами Workflow, установленными на разных компьютерах. Для этого в настройках системы можно задать имена нескольких служб Workflow. При этом все клиенты ставят задачи на обработку в очередь через первую указанную службу, а уже она распределяет задачи между всеми остальными службами. Помимо этого задачи равномерно распределяются между процессами служб.
Следует отметить, что теперь при изменении количества служб и/или процессов у этих служб все задачи будут обработаны.
Для реализации данной возможности в настройке системы «WorkflowServiceName» можно задать имена нескольких компьютеров через символ «;». При этом в таблицу SBWorflowProcessing добавляется поле с номером службы (ServiceNumber).
Установка:
На одну физическую машину можно поставить только одну службу Workflow, ограничение связано с именованием служб в ОС.
У службы WorkFlow теперь появился отдельный установщик. Процесс установки не имеет существенных отличий, за исключением одного дополнительного этапа. Установщик проверяет, заполнено ли поле WorkflowServiceName в настройке системы (в таблице XIni), и в случае, если поле пустое, прописывает себя в это поле. В противном случае установщик предлагает 3 возможных варианта:
Дальнейшие действия ничем не отличаются от процесса обычной установки сервисных служб.
Если главная служба остановится, поведение системы, насколько я понял, будет такое же как в предыдущих версиях. А если остановится дополнительная служба?
Какие-то рекомендации уже можете дать по практическому использованию механизма?
Как определить, что нам нужно несколько служб, а не одна?
Сколько одновременно работающих служб тестировалось?
Можно ли устанавливать доп. службы во время работы пользователей с системой?
Ограничения использования по версиям DIRECTUM есть?
А можно задать чтобы только один конкретный типовой маршрут выполнялся только на дополнительной службе?
Нет, такой возможности нет. Все задачи распределяются равномерно между службами, а затем между их процессами.
Изменилась ли в 4.8 структура таблицы SBWorkflowProcessing ввиду того, что задача может обрабатываться различными службами разных машин? Каким образом администратор может понять какой процесс и какой службы обрабатывает конкретную задачу?
PS: отличие в процессе установки есть и в части назначения портов для службы Workflow. Указать порты, используемые службой, можно лишь при установке главной службы.
PS1: структура конфигурационных файлов служб(ы) worflow не изменилась.
Простите, но мне не понятно, каким образом несколько процессов запущенных на одной машине могут приводить к дедлокам, а то же количество процессов на разных машинах, к ним не проводят. Поясните, пожалуйста.
Запуск процессов на разных машинах напрямую не влияет на количество дедлоков.
Артем, и все- таки, почему? Поясните тогда подробнее природу дедлоков. Казалось бы, на дедлоки будет влиять количество процессов вцелом, а не то, где исполняются процессы, если дедлоки появляются на sql сервере?
Или дедлок в данном случае - это нехватка ресурсов сервера, на котором выполняется служба, а не sql сервера?
Михаил, я может быть не совсем корректно выразился в ответе на Ваш вопрос, поэтому поясняю: непосредственно запуск процессов на разных машинах никак не повлияет на количество дедлоков. Повлиять на количество дедлоков может только стечение обстоятельств, потому что, как сказано в статье, "для их возникновения нужны специфические условия одновременного выполнения нескольких процессов".
А как будут лицензироваиться дополнительные службы Workflow? Будут ли они выделены в отдельные позиции прайс-листа?
Вот это просто замечательно...
Четные к одной, нечетные к другой.
Авторизуйтесь, чтобы написать комментарий