Как обеспечить поддержку распределенной 1С на 100+ узлов?

Итак, как правило, мы сталкиваемся со следующими категориями проблем:

  • Проблемы большого объема общих данных (дисконтные карты, акции и т.п.).
  • Проблемы скорости выгрузки информации в узлы.
  • Проблемы работы 1С:БСП.
  • Проблемы централизованного обновления конфигурации информационной базы.
  • Проблемы централизованного администрирования информационных баз (резервное копирование, реиндексация и т.п.).
  • Проблемы производительности конечных клиентов.

Собственно, решению этих вопросов и посвящена данная статья.

Большой объем общих данных и скорость выгрузки

При переходе от традиционных способов обмера «csv файлами по ftp» или «по почте» к нормальным (для 1С это РИБ) первое негативное явление, которое становится заметным, – это резкий рост объема выгрузки.

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

В случае обычного файлового обмена выгружается один файл (цены/акции/товары) и рассылается по всем точкам, а в РИБ – регистрация изменений, инфраструктура сообщений и прочие «полезности», по сути, заставляют этот файл выгружать для всех узлов индивидуально. На первый взгляд ничего страшного – объем сжатых XML не так велик.

Но вот чтобы выгрузить разные изменения на 100 точек, нужно иметь достаточно много вычислительных ресурсов. Кроме того, РИБ в 1С обладает существенным ограничением на параллельность: изменения для выгрузки в узел могут выбираться только последовательно. Почему так? Суть в инфраструктуре сообщений: в момент получения списка измененных объектов (вызов функции «ВыбратьИзменения()») у всех измененных объектов должен установиться номер сообщения для данного узла – они должны быть перезаписаны. При этом любые другие действия с этими объектами невозможны до установки номера сообщения. Это важно для того, чтобы не потерять изменения – в XML выгружаются определенные номера сообщений, после этого приходит подтверждение их успешной загрузки в ответном сообщении и только потом информация об изменениях удаляется.

Таким образом, единовременный вызов функции «ВыбратьИзменения()» для одних и тех же объектов невозможен. Это приводит к невозможности начала выгрузки сразу в два или три узла. Пока эта проблема в 1С не решена и неизвестно, когда будет решаться. Общие данные составляют, как правило, большую часть сообщения обмена. Их количество при каждой выгрузке желательно сокращать. Причем речь идет именно о количестве – т.е. значение имеет главным образом количество записей таблицы регистрации изменений. Если у вас есть элемент справочника с табличной частью из ста строк, то это одна запись в таблице регистрации, а если есть сто записей в регистре сведений – это сто записей в таблице регистрации, поэтому избегайте  по возможности регистрировать изменения регистров. Записывайте их в подчиненном узле из объектов, которые формируют в них записи. А что касается объемов выгрузки – сама выгрузка объектов в XML может идти параллельно – объемы тут не так критичны.

Если вы исчерпали возможности оптимизации, обмены стоят и тормозят. Что делать? У нас, к примеру, есть такой вариант – за день по сети распространяются и изменятся более 10 тыс. дисконтных карт. Этот объем может существенно нагрузить РИБ. Как синхронизировать такие объемы? Ответ: использовать специализированную СУБД, ориентированную главным образом на репликацию данных. У нас это CouchDB  – открытая NoSQL СУБД, главное достоинство которой – в развитом механизме репликации данных. При этом настройки репликации поражают своей «сложностью» (см. рис. 1).распределенная 1с

Установка данного ПО в точки откроет перед вами практически неограниченные возможности в сфере производительности обменов. В CouchDB репликация работает очень быстро. Складывать в нее вы можете произвольные JSON-файлы, таким образом реплицировать практически все объекты между узлами. Уэтого варианта репликации нет ограничений на параллельность, он намного быстрее, менее требователен к интернет-каналу и аппаратным ресурсам. Тем не менее, пока это возможно, рекомендую все-таки использовать классический РИБ. Использование сторонних средств сопряжено с накладными расходами и новыми компетенциями.

Проблемы работы 1С:БСП

К сожалению, последняя БСП привносит ряд проблем в сопровождении РИБ:

  • Проблема обновления конфигурации.
  • Проблема обновления вспомогательных данных.

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

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

Централизованное обновление и администрирование

Решив эту проблему достаточно красиво, можно снять с себя довольно большой и тяжелый груз по единовременному выпуску нового релиза корпоративной фронт-системы. Всем известно, что текущие ошибки отловить бывает достаточно сложно, и они часто проскакивают мимо глаз. В случае если время обновления распределенной системы на новый релиз не более 10-15 минут, катастрофу от критических ошибок можно еще успеть предотвратить.

Итак, «в лоб» решение данной проблемы выглядит примерно следующим образом. Стандартный скрипт обновления, вроде все так делают. На 20 узлов он нас вполне бы устроил, но в случае поддержки 200 узлов мы хотим видеть:

  • Централизованное обновление – запуск заданий на местах по расписанию.
  • Централизованное обновление платформы (часто бывает, что находятся критические ошибки или новый функционал не работает на старой версии платформы 1С).
  • Логи обновления (успешно/неуспешно, если не успешно – тексты ошибок).
  • Резервное копирование перед обновлением (обязательно).
  • Обновление по расписанию и принудительное. Сценарии обновления.
  • Обновление с предупреждением, прогрессом и акцептом пользователя.

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

Скриптами, конечно, дело не обойдется. Централизованное управление все-таки требует наличия инфраструктуры. Логичным кажется совершать данные операции из 1С, но в данном конкретном случае натыкаемся на большую проблему – большинство из этих операций требует закрытия клиента, а то и перезапуска сервера 1С, соответственно, это делает невозможным выполнение в нем кода. Еще на эту роль достаточно неплохо подходил антивирус с возможностью централизованного управления, но в нем недоступны некоторые возможности, такие как вывод сообщений, прогресса и передача логов в центр.

Поэтому для поддержания инфраструктуры на большое количество узлов целесообразно выделять время на разработку отдельного ПО для мониторинга и администрирования баз Рисунок 2. Пример архитектуры системы обновления конфигураций 1С Использование сторонних средств сопряжено с накладными расходами и новыми компетенциями Базы данных 40 декабрь 2016 системный администратор изучаем 1С (включая обновления). Данное ПО может быть написано произвольным образом, не обязательно с кучей возможностей – достаточно лишь нескольких основных. Единственное, что будет схоже у подобных программных продуктов, – архитектура. Пример архитектуры системы обновления узлов 1С приведен на рис. 2.

распределенная 1с

Логика достаточно проста – сервер отправляет задания, агенты на каждом компьютере сети эти задания читают и выполняют. Агенты, естественно, должны уметь сами себя обновлять. Агент может выводить сообщения и прогресс-бары в том формате, в котором вам нравится, т.е. служба должна уметь взаимодействовать с рабочим столом. Эту же программу нужно «научить» обновлять платформу 1С и делать резервные копии.

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

cloud-1c-2

 

Проблемы производительности конечных узлов

Производительность для целей РИБ в конечных узлах не так критична, как это может показаться на первый взгляд. Тем не менее если есть желание организовать обмен с определенной периодичностью, а не раз в день, то в конечной точке желательно иметь сервер. Платформа 8.3 вообще с сервером работает уже намного лучше, чем в файловом варианте, поэтому его настоятельно рекомендую. 1С продает сервер «mini» по вполне доступной цене. В качестве СУБД можно использовать SQL Express (с ограничением 2 Гб на ОЗУ и 10 Гб на размер базы) или же набирающий популярность PostgreSQL, без ограничений, но несколько хуже работает пока с платформой 1С.

Что на самом деле важно – это наличие SSD в оборудовании. Данные диски играют решительную роль – производительность системы может вырасти в несколько раз, если не в несколько десятков раз.

Итак, при поддержке инфраструктуры РИБ на 100+ узлов проблем возникает достаточно много, но все они известны и решаемы. Зная о возможных трудностях, заранее можно к ним подготовиться, заранее заложить затраты на оборудование и ПО и превратить «неожиданные трудности» в «задачи проекта».

Настройка и поддержка систем 1С любой сложности, подробнее [email protected]

0 ответы

Ответить

Хотите присоединиться к дискуссии?
Приглашаем поучаствовать!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *