Предисловие
Приступая к написанию этой статьи, я рассчитывал кратко описать новый инструментарий. В процессе работы выяснилось, что совсем кратко не выйдет. Статья получилась гораздо больше ожидаемого, и поэтому была разбита на две части. Части эти связаны общим заголовком, но информация в них различна, и применяться может независимо. Поэтому, если в процессе чтения 1-й части Вы решите, что это не представляет для Вас интереса, предлагаю не ставить автоматически крест на всей теме, а заглянуть всё же и во 2-ю часть. Возможно, она заинтересует Вас больше.
Вступление
Коллеги, признайтесь, часто ли Вы проверяете, что нового появилось в Платформе? Внимательно читаете v8Update каждого нового релиза? Заглядываете в документацию новых версий в поисках изменений?
Полагаю, что в большинстве своем, о нововведениях мы узнаем из «Заметок из Зазеркалья». Обычно там анонсируют планируемые изменения еще до их релиза, с описанием и примерами применения. И эти нововведения мы ждём.
С другими новшествами бывает наоборот – они уже есть в Платформе. О них несколькими строчками сказано в Информационном письме о выходе новой версии и описано в «простыне» v8Update со ссылками на документацию. При этом нововведение остается совершенно незамеченным.
Одним из таких незамеченных новшеств является появившийся уже более года назад, в версии 8.3.14, «Автономный сервер». Несколько строк в пресс-релизе – это всё, что о нём сообщили. Механизм представлен пока в бета-версии. Возможно, именно этим объясняется отсутствие информации.
В Интернете вообще и на Инфостарте в частности, материалов об этом механизме нет, если не считать перепостов пресс-релиза. Потому возьму на себя смелость извлечь «Автономный сервер» из тени.
Давайте попробуем разобраться что это такое, для чего нужно, какие преимущества дает, что можно использовать уже сейчас, чего можно ожидать.
Мне придется цитировать и местами приводить выдержки из документации, т.к. это единственный источник знаний на текущий момент. Также, некоторую информацию удалось получить на Партнерском форуме (ссылки приведены в конце статьи).
Итак, пресс-релиз гласит:
Реализована новая архитектура сервера 1С:Предприятия в виде нового варианта работы – автономного сервера. Новая архитектура призвана повысить эффективность и надежность работы сервера 1С:Предприятия и повысить удобство его использования.
Для организации доступа к базе по HTTP не нужно разворачивать отдельный веб-сервер, так как автономный сервер самостоятельно обеспечивает такую возможность. Он также может работать с файловой базой, в частности, позволяет запускать до трех клиентских сеансов с информационной базой (без учета сеансов фоновых заданий, интернет-сервисов и т. п.) без лицензии на сервер.Автономный сервер в настоящее время находится в статусе бета-версии, поэтому имеет ряд ограничений, описанных в документации.
Собственно, «Автономный сервер», это два новых приложения, появившихся в дистрибутиве:
- ibsrv – консольное приложение сервера. Служит для подключения Клиентских приложений: Тонкий, Мобильный и Веб-Клиенты.
Может запускаться как приложение или в виде службы Windows или в режиме демона в Linux, аналогично ныне существующему кластеру.
- ibcmd – утилита управления сервером, также консольная.
Согласно документации - предназначена для конфигурирования сервера. На самом деле, функционал этой утилиты несколько шире, чем просто формирование конфигурационного файла для сервера. Она также позволяет производить манипуляции с информационной базой. Уже сейчас её можно использовать в качестве замены пакетного режима Конфигуратора в ряде случаев. Об этом речь пойдет во второй части статьи.
Автономный сервер – ibsrv
По поводу предназначения «Автономного сервера» в пресс-релизе нет ни слова, в документации же сказано: «это специальное серверное приложение, которое предназначено для обеспечения работы с информационной базой клиентских приложений: тонкий клиент, веб-клиент, мобильный клиент».
Далее документация описывает технические возможности, особенности и ограничения. Однако это не добавляет понимания, когда и для чего его следует применять.
Со слов разработчиков на партнерском форуме, в настоящее время «Автономный сервер» выпускается в бета-версии и предполагается к использованию для разработки и тестирования прикладных приложений. Текущая версия «Автономного сервера» обладает только базовым набором функциональности, позволяющим тем не менее, обслуживать прикладные приложения 1С:Предприятия 8.3 с достаточной степенью функциональной совместимости.
Применимость его для разработки вызывает серьезные сомнения, поскольку на настоящий момент, подключение к нему Конфигуратором невозможно.
Что касается тестирования или использования для реальной работы, нам придется самим «примерять» и самостоятельно решать, нужен ли он в каждом конкретном случае.
В документации приводится перечень ограничений текущей версии.
Автономный сервер не поддерживает следующие возможности:
- Обслуживание нескольких информационных баз одним автономным сервером.
- Работу нескольких автономных серверов с одной информационной базой.
- Изменение параметров автономного сервера во время его (автономного сервера) работы.
- Работу с информационной базой, используя толстый клиент.
- Работу с информационной базой в режиме Конфигуратора.
- Работу с информационной базой с использованием внешнего соединения (COM-соединение).
- Управление автономным сервером с помощью сервера ras.
- Для автономного сервера отсутствуют графические инструменты управления (аналог консоли кластера).
- Динамическое обновление конфигурации базы данных.
- Использование фоновой реструктуризации.
- Управление сервером с помощью COM-объекта V83.ComConnector.
- Работу по протоколу HTTPS. Возможно использование протокола HTTPS при использовании промежуточного веб-сервера между автономным сервером и клиентским приложением.
- Отладка по протоколу TCP/IP.
- Использование аутентификации операционной системы.
Какие-то из этих ограничений являются критическими, какие-то малозначительными. Попробуем проверить.
Исходя из первых двух пунктов, можно сделать вывод что публикация информационных баз посредством Автономного сервера организуется по правилу «одна база - один экземпляр сервера».
Пробы
Термин «тесты» я счел не очень подходящим для своих экспериментов. Скорее этот формат можно назвать «распаковкой» по аналогии с обзорами потребительских товаров.
Для экспериментов под руку попались демо-база УНФ и тестовая Розница. «Управление холдингом» или ERP проверять в таком режиме, думаю, преждевременно.
Публикуем локально
Самый первый и простой эксперимент – запускаем ibsrv в режиме приложения с публикацией файловой базы. Все настройки, кроме каталога базы, по умолчанию. Запуск в режиме приложения, без регистрации службы.
При этом база опубликовалась на интерфейсе localhost – http://localhost:8314
Открываю стартер, добавляю новую базу в список со строкой подключения ws="http://localhost:8314";
Запускаю и ... Ура! Оно работает! В качестве бонуса – база открывается удивительно быстро. Явно быстрее файловой.
Замеры времени запуска
Решив сравнить с обычным файловым подключением, заполняю в параметрах базы авторизационные данные, чтобы не запрашивался диалог и произвожу замер секундомером по 5 раз время с момента запуска до открытия Клиента и отрисовки начальной страницы, на которую выведен журнал «Документы по продажам». Первые 2-3 запуска в каждом варианте не считаю, для исключения влияния начального заполнения кэша. Также, для сравнения, настроил публикацию через IIS.
Результаты замеров открытия Тонкого клиента:
- 11,83 сек. - Подключение к базе в файловом варианте;
- 3,05 сек. - Подключение к той же базе через Автономный сервер;
- 3,19 сек. - Подключение к той же базе через «обычную» публикацию на веб-сервере IIS.
Разница между файловым вариантом и «Автономным сервером» почти 4-кратная! Оба варианта подключения по http стартуют существенно быстрее.
С целью понять действительно ли есть разница в скорости работы или же только при запуске, провел другие замеры: пробитие чека из 5 позиций в Рознице (на эмуляторе ККМ). Результаты:
- 1,94 сек. - Файловая;
- 1,63 сек. - Автономный сервер;
- 1,72 сек. - IIS.
Разница не такая разительная как при запуске, и её можно отнести на погрешность измерений. Без детального анализа можно предположить, что запуск клиента при http-подключении выполняется несколько иначе.
Публикуем в локальной сети
База, опубликованная на localhost недоступна с других компьютеров, поэтому следующим шагом укажем публикацию на конкретном IP-адресе (указать для публикации имя сервера невозможно)
При такой публикации уже возможно подключаться к базе с других машин в локальной сети. Если при этом в сети есть DNS-сервер или внесены соответствующие записи в файлы hosts, базам можно указывать строку подключения вида ws="http://our-1c-server:8314";
Не забудьте разрешить входящие соединения на нужный порт в брандмауэре.
Работа без лицензии
Удостоверимся что без лицензии можно запустить 3 сеанса.
Да, действительно, сообщение о необходимости лицензии выдается при попытке запустить 4-й сеанс подключения к файловой базе.
Забегая вперед, скажу что для баз, размещенных в СУБД, лицензия запрашивается при попытке запуска 1-го сеанса. А очень жаль. Возможность запустить хотя бы одно клиентское приложение без лицензии, могла бы позволить решить проблему конфликта блокировок для узлов РИБ, которые сейчас обычно разворачиваются в файловом варианте и получают ошибку при выполнении фонового задания обмена. Достаточно было бы разместить базу в Postgresql и подключаться через Автономный сервер.
Публикуем несколько баз
При наличии нескольких баз, которые требуется опубликовать посредством АС, для каждой базы нужно создать отдельную публикацию. На отдельном порту. Кроме порта, также необходимо указать отдельный рабочий каталог, иначе получим ошибку «Рабочий каталог заблокирован процессом: nnn». Таким образом, для каждой базы будет отдельный процесс ibsrv, отдельный порт, отдельный рабочий каталог. Для файловых баз удобно разместить рабочий каталог внутри каталога базы, чтобы при переносе или удалении базы Журнал регистрации не потерялся.
В рабочем каталоге размещаются Журнал регистрации, сеансовые данные, временные файлы.
Замечание: Кроме указания всех параметров в строке запуска, возможно использовать конфигурационный файл. Некоторые возможности, например несколько публикаций одной и той же базы с разными точками входа, возможны только при использовании конфигурационного файла.
Публикуем базы, размещенные в СУБД
Следующий эксперимент – запуск с подключением к базе, размещаемой в СУБД. Здесь уже понадобится лицензия, поэтому запуск производится на другом сервере, где уже работают несколько тестовых кластеров разных версий и установлен аппаратный ключ.
Замечание: если подключаетесь к серверу по RDP и на сервере используется аппаратный серверный лицензионный ключ, попытка подключиться к «Автономному серверу», запущенному как приложение (не служба), увенчается сообщением о том, что не найдена серверная лицензия. Причина – приложение, запущенное в пользовательской сессии не «видит» HASP-ключ. Чтобы ключ нашелся, требуется запускать сервер как службу.
В документации традиционно приведен образец скрипта для регистрации службы. В образце создается служба, использующая конфигурационный файл.
В своем эксперименте я зарегистрирую службу несколько видоизмененным скриптом, с непосредственной передачей необходимых параметров в командную строку службы.
При желании изменить настройки службы на использование конфигурационного файла, это всегда можно сделать правкой ключа ImagePath в реестре, точно так же, как мы обычно включаем и выключаем отладку у службы сервера 1С.
Замеры времени запуска
Выполняю такие же замеры запуска Тонкого клиента до момента отрисовки динамического списка.
- 24,34 сек. - Подключение к базе, размещенной в «обычном» кластере Тонким клиентом по TCP;
- 4,10 сек. - Подключение к той же базе через «Автономный сервер»;
- 4,49 сек. - Подключение к той же базе через «обычную» публикацию на веб-сервере IIS.
Признаюсь, такая огромная разница между временем запуска клиента при «обычном» подключении к кластеру и подключении через веб-сервер, для меня явилась сюрпризом.
Работа с Конфигуратором
Как указано в списке ограничений, подключение Конфигуратора, равно как и любое другое подключение по TCP, не поддерживается. Но ведь как-то с Конфигурацией нужно работать... Варианты, конечно есть.
Для файловых баз есть два способа:
- Открывать базу как обычно, файловым подключением Конфигуратора. При запущенном сервере есть возможность сохранять изменения Конфигурации. Но обновить конфигурацию БД не удастся - получим сообщение «Ошибка исключительнной блокировки». Для обновления БД придется остановить процесс или службу «Автономного сервера».
Кстати, сеансы, обслуживаемые «Автономным сервером» в списке Конфигуратора не отображаются.
- Править конфигурацию можно (и, вероятно, нужно) в базе-копии. И при необходимости, загружать измененную конфигурацию в рабочую базу посредством утилиты ibcmd, речь о которой пойдет во 2-й части статьи. Процесс сервера для такой операции также рекомендуется остановить.
Для баз, размещенных в СУБД, возможен только второй способ.
Отладка
Формально, возможна отладка по http, путем подключения к самостоятельному серверу отладки. Переписывать справку здесь не буду, интересующиеся могут ознакомиться с оригиналом.
Предлагаемый процесс подключения отладки не оставляет сомнений что пользоваться ей будут только при полном отсутствии любых других возможностей. На мой взгляд, при необходимости отладки на рабочих данных, проще работать с копией базы в обычном файловом подключении.
Управление сеансами
Среди ограничений текущей версии указано что не поддерживается «Управление автономным сервером с помощью сервера ras». На самом деле, для управления сервером сейчас нет совсем никаких средств. Сервер можно только запустить и остановить. Управлять сеансами не получится. Устанавливать блокировку новых подключений тоже не получится. Единственный способ удалить сеансы - это остановить процесс Автономного сервера. Выборочно удалить зависший сеанс не получится.
Замечание: После нового запуска процесса ibsrv, все отключенные сеансы подключатся вновь. И будут работать. При этом, список активных сеансов, отображаемый в ранее запущенных клиентских приложениях, пуст. Это конечно, же, баг. Но, в какой-то степени, и фича. Дело в том, что теперь, если начать запускать новые сеансы, подключатся еще 3. А после повторного перезапуска процесса сервера, можно будет подключить еще 3 и т.д. На скриншоте видно, что запущено 9 сеансов в одной базе. Поверьте, все они работают.
Ошибки при работе, удобство настройки
Каких-либо ошибок, мешающих работе, при тестах не было. Все операции выполняются ожидаемо.
Настройка и запуск сервера предельно просты. Все параметры можно задать как непосредственно в командной строке, так и в конфигурационном файле.
Создание конфигурационного файла я умышленно обошел вниманием, т.к. это в большей степени относится к утилите администрирования ibcmd, которой посвящена вторая часть статьи.
Плюсы и минусы
Подводя итог ознакомлению с бета-версией архитектуры «Автономного сервера», приведу свой субъективный список плюсов и минусов. У Вас он вполне может быть другим.
Плюсы
- Содержит встроенный http-сервер. Таким образом, исключаются два промежуточных компонента в цепочке между Клиентским приложением и Сервером – веб-сервер и модуль расширения веб-сервера.
- Работает как с базами, расположенными в СУБД, так и файловыми.
- При работе с файловой базой до 3-х сеансов (не считая фоновые задания и сервисы), не требуется серверная лицензия.
- Достойная производительность. Очень быстрый старт клиентских приложений.
- Простой запуск и конфигурирование. Удобно для контейнеризации.
- Работа регламентных заданий, веб- и http-сервисов, точно также как и при работе кластера. В том числе и для файловой базы. Без серверной лицензии.
Минусы
- Невозможна работа Конфигуратора.
- Требуется серверная лицензия даже для одного сеанса при подключении к базе, размещенной в СУБД.
- Нет возможности управления сеансами.
- Невозможность отладки.
- Невозможно подключение Толстым клиентом.
Хотя уже давно все современные прикладные решения используются в управляемом режиме, иногда требуется подключение в режиме Обычного приложения - для запуска любимой консоли запросов или «Инструментов разработчика».
- Не работает по https.
В случае необходимости можно установить фронт-сервер.
Возможные показания к применению
На текущий момент единственным показанием к применению Автономного сервера мне видится замена подключения для файловых баз, где достаточно 3-х одновременных сеансов. Простая и бесплатная.
Если подключений требуется больше 3-х, уже потребуется серверная лицензия. Такая же, какая сейчас используется кластером. То есть дорогая. Не думаю, что многие решатся на покупку серверной лицензии для обеспечения работы 5-7-10 пользователей с одной базой. В данном случае выход остается прежним – публиковать файловую базу «обычным» веб-сервером. И задумываться о сервере только когда заставят таймауты на блокировках.
Критерии разграничения сфер применения «обычного» кластера и автономного сервера мне пока не ясны.
Полагаю, в будущем эти два механизма будут разведены по своим нишам некими рамками, вероятно стоимостью лицензий.
Ссылки на документацию и темы партнерского форума
Лицензирование: Аппаратная (клиент) , Аппаратная (сервер), программная (клиент), программная (сервер)
Темы партнерского форума, содержащие информацию об Автономном сервере:
https://partners.v8.1c.ru/forum/topic/1771569
https://partners.v8.1c.ru/forum/topic/1776027
https://partners.v8.1c.ru/forum/topic/1782134
https://partners.v8.1c.ru/forum/topic/1772069
UPDATE
В комментариях ко второй части статьи коллеги обсуждали работает ли запуск регламентных заданий по расписанию. На текущий момент сделан вывод что регламентные задания не работают.
Продолжение следует
В следующей части будет рассмотрена утилита администрирования Автономного сервера ibcmd. Несмотря на позиционирование этой утилиты как средства администрирования, у неё есть функционал, который позволяет использовать её самостоятельно, независимо от процесса «Автономного сервера», и эффективно решать задачи, для которых сейчас используется пакетный режим Конфигуратора.
Замечу, что целью статьи не является «раскрытие темы». Скорее предполагалось пробуждение интереса к незамеченному инструменту. Возможно, кто-то уже успел воспользоваться им, протестировать, может быть даже применить в рабочем режиме и может поделиться в комментариях опытом.
