РИБ - не лучший, но, пожалуй, пока единственный способ более-менее системно поддерживать единую конфигурацию 1С по всей филиальной сети,
конечно, в случае, если филиальная сеть работает на 1С. Но жесткие требования к поддержанию единой конфигурации привносят и определенные проблемы.
Хотя, если их исключить, проблем будет ещё больше. Поэтому конечными узлами РИБ управлять централизованно крайне важно.
За годы своей работы я пробовал различные варианты:
1) Внести компьютеры в домен и использовать групповые политики.
Очень плохой вариант - репликация базы AD часто требует хорошего интернет-соединения, определенных ОС и их настроек на конечных рабочих станциях,
вызывает проблемы с централизованным администрированием большого количества учетных записей. Также требует наличие и поддержание VPN соединений на конечных точках.
Ни одного удачного решения подобного рода я лично не видел.
2) На каждом компьютере настроить расписание запуска регламентных операций
Неплохой в целом вариант. Но имеет ряд недостатков:
- выполнилась операция или нет, мы никак не узнаем;
- для того чтобы узнать, какие были ошибки, нужно удаленное подключение;
- нельзя обновить информационную базу по желанию, даже если допустили ошибку, и нужно срочно;
- обновление скриптов - дело сугубо ручное.
3) Запускать регламентные операции средствами самой 1С
Это, конечно, можно сделать, только вот обновлять 1С средствами самой 1С - это проблема, как минимум ввиду того, что в большинстве случаев требуется монопольный доступ к информационной базе.
Для этого часто используются специфичные решения вроде динамического формирования скриптов и их запуска. Такой подход вызывает регулярные проблемы:
- часто защита Windows запрещает записывать запускаемые файлы;
- передать логи обновления в центр тоже бывает проблематично;
- обновление информационной базы "по желанию" возможно только с нормально работающими фоновыми заданиями в файловом варианте, а это, само по себе, редкость.
4) Использовать антивирус как средство удаленного администирирования
Этот вариант как минимум требует наличия продвинутого антивирусного ПО на конечных компьютерах, имеющего средство удаленного администрирования, а это уже не дешевое решение.
Кроме того, антивирусное ПО часто приносит больше проблем, чем решает. Но положительным моментом является как минимум тот факт, что в этом случае обновление можно выполнить по желанию.
5) Вообще запускать клиентов централизовано в единой БД илди посредством RDP.
Хороший вариант, более современный, несомненно более подходящий для внедрения... где-нибудь в странах Западной Европы.
В нашей необъятной стране, к сожалению, качество интернет-соединения часто оставляет желать лучшего. Даже в крупных городах, не говоря уже о небольших провинциях.
При этом работа ведётся с торговым оборудованием. До сих пор не вышел из употребления COM порт, для корректной работы которого требуется очень короткое время ping до сервера.
Подводя итог всему вышесказанному - нормального средства администрирования РИБ не существует.
Я бы даже сказал больше - нормального средства администрирования сети компьютеров под Windows, не объединенных в AD, мне тоже как-то не встречалось.
Кроме того, для 1С есть достаточно специфичные задачи, которые лучше решать спеицализированными средствами.
Отвечу сразу на вопрос, который хочется задать: "Почему не на 1С":
- Вы же любите "без изменения колнгфигурации" - единственный вариант.
- Большинство манипуляций с базами 1С выполняется монопольно.
- Не всё возможно сделать средствами платформы 1С.
Таким образом, было принято решение разработать систему администрирования 1С.
Система состоит из следующих компонент:
Magic Updater Agent
Программа агент - устанавливается на конечные компьютеры. Опрашивает базу заданий и выполняет их.
Magic Updater Monitor
Интерфейс управления агентами и получения информации о результатах выполнения заданий, а также монитор обменов и агентов.
Magic Updater Sheduler
Служба управления запуском заданий по расписанию. Задания могут быть как для агентов на местах, так и выполняться самой службой в центре.
Принципиально архитектура выглядит следующим образом:
Подобная архитектура позволяет выполнять на рабочих станциях произвольные задания в произвольное время и получать результат выполнения.
Основные функциональные возможности Magic Updater:
1) Выполнение произвольных операций с 1С в узлах как по расписанию, так и принудительно.
В настоящий момент времени поддерживаются следующие виды операций:
- Динамическое обновление 1С
- Не динамическое обновление 1С с завершением работы пользователей
- Выполнение обмена данными по произвольной настройке
- Резервная копия информационной базы
- Перезагрузка сервера
- Выполнение произвольной внешней обработки
- Закачка произвольного файла
- Закачка и выполнение произвольного файла
Вообще, система поддерживает плагины - состав выполняемых операций может быть существенно расширен.
2) Получение состояния обмена с удаленными точками
3) Получение состояния интернет-соединения в удаленных точках
4) Сохранение статуса выполнения операций и логов 1С по результатам выполнения
5) Задание расписания выполнения операций как агентами, так и сервером Magic Updater
Для использования данного ПП необходимо:
1) Наличие сервера MS SQL Server (работает только с ним)
2) .NET Framework 3.5 (на некоторых старых системах её может не быть)
3) Наличие FTP сервера
Если дочитали до этих строк то, наверное, продукт интересен - далее несколько видео по функциональности:
Установка и настройка Magic Updater:
Основная функциональность Magic Updater:
Разработка Плагина Magic Updater:
На текущий момент времени у Magic Updater есть следующие плагины:
- BackupBaseSqlPlugin.dll - резервная копия SQL базы
- CacheClear1CPlugin.dll - Очистка КЭШ-а метаданных 1С
- DownloadAnyFilesPlugin.dll - Загрузка произвольного файла
- DynamicUpdate1CPlugin.dll - Динамическое обновление базы 1С (ориентировано на клиент-сервер)
- ExecAnySqlPlugin.dll - Выполнение произвольного SQL запроса
- ExecProcessing1CPlugin.dll - Выполнение внешней обработки 1С
- FileBackupBasePlugin.dll - Создание резервной копии файловой базы
- FileDynamicUpdate1CPlugin.dll - Динамической обновление файловой базы
- FileUpdate1CPlugin.dll - Обновление файловой базы
- ForceStaticUpdate1CPlugin.dll - Обновление базы с завершением сеансов (клиент-сервер)
- KillForceStaticUpdate1CPlugin.dll - Обновление базы с перезапуском сервера 1С (клиент-сервер)
- LockBackgroundJobsPlugin.dll - Блокировка фоновых заданий (клиент-сервер)
- OperationExchangeToCenterPlugin.dll - Обмен с центром
- RenameAnyFilePlugin.dll - Переименование произвольного файла
- RestartComputerPlugin.dll - Перезагрузка компьютера
- RestartServer1CPlugin.dll - Перезапуск сервера 1С
Пример использования для обновления большого количества узлов:
Чем же нам станет лучше после того, как мы его внедрим?
Мои лично ощущения следующие:
- Не страшно ошибиться. Ошибки исправляются в считанные минуты даже на большой филиальной сети.
- Доработки теперь делаются не "к следующему месяцу" и не "из-за этого не будем обновляться".
- Инфраструктурные изменения также становятся не страшны для всей сети.
Сейчас Magic Updater, конечно, умеет многое, но не всё, что хотелось бы.
В разработке следующие фичи:
1) Изменения протокола обмена с сервером - для скорости и безопасности планируется TCP сервер
2) Получение идентификатора конфигурации центра и узлов - для того чтобы автоматически определять обновленные и не обновленные узлы
3) Получение информации о загруженности оборудования (диск/процессор/память)
4) Взаимодействие службы с рабочим столом - отправка пользователю служебных сообщений, обратная связь.
Что же выложено в архиве ниже?
Собственно планировалось коммерческое использование, но не пошло, поэтому выкладываю в OpenSource:
https://github.com/comol/MagicUpdater
Продавец из меня не очень, но уверен что само решение получилось хорошим,
хоть и очень нишевым, тем не менее, без материальных вливаний развивать его своими силами уже не получается, а хочется чтобы такой продукт таки существовал.
Все наверное, слышали уже про "Центр администрирования". Чем сиё решение лучше:
1) Теперь оно бесплатное
2) Обкатано на больших объёмах и в реальных условиях
3) На Windows системах будет работать быстрее и лучше чем ЦА
4) Административные действия можно совершать при упавшем 1С (именно тогда когда нужно)
5) Знать Python нет необходимости - достаточно знать 1С, а потому как в основе C# - можно онтегрировать плагины на OneScript
6) Гибкость в разы больше
Чем пока что хуже (что хотелось бы добавить):
1) поменять протокол взаимодействия агента и сервера на http
2) Интегрировать OneScript
3) Сделать нормальный Web интерфейс
4) Сделать нормальную интерфейсную часть в агенте
5) Упростить установку и настройку
- Собственно желающие присоединиться к доработке - Welcome
- Сочувствующие и кто хочет чтобы что-то доработал я (или коллеги) - тоже Welcome https://yasobe.ru/na/MU
- Установка и настройка сего продукта дело непростое. При минимальных знаниях C# и SQL справитесь, кто не справился но хочет пользоваться - я буду готов помочь, но на возмездных условиях конечно :)
