![]() |
#9 |
Участник
|
Планировщик написан на C/AL и работает у нас под NativeDb. Но в действительности можно использовать и SQL сервер, как хранилище данных, от этого суть не меняется. Настройки соответственно тоже хранятся в таблицах Navision. Никаких Aplication серверов мы не используем(даже в своём Интернет решении мы их не используем), но действительно используем собственные сервисы и отдельную программу(монитор задач), написанную на C++ для управления этими планировщиками. Протокол tcp. У нас каналы связи VPN от 64 до 128кb/c, но они нужны только для репликации. Для работы монитора задач можно и попроще каналы, так как он не создаёт трафика.
Но дело не в планировщике-это тривиальная вещь и их существует множество, есть РБОошные, есть в сервисном модуле и т.д. Действительно монитор является частью большого комплекса, но прямого отношения к репликации он не имеет, но может использоваться вместе с ней. Дело в том, что мониторить и соответственно управлять информационной системой, состоящей например из 10 и более баз данных, разбросанных по всему земному шарику достаточно сложно. В каждой базе выполняется множество задач в автоматическом режиме. Все эти задачи запускаются планировщиками в заданное время. Следить за работой этих планировщиков(например, используя всеми любимый терминальный доступ) при большом количестве баз данных очень сложно и неудобно, а в удалённых точках и некому, поэтому и был придуман монитор задач, который в едином окне показывает статусы планировщиков и в случае сетевых сбоев автоматически либо вручную(путём нажатия кнопочки) перезапускает их в удалённых базах через VPN каналы. В результате получаем жуткую экономию времени администратора и соответственно удешевляем затраты.) Сложностей в реализации решения особых нет, но выгода существенная. |
|