1с как удалить кластеры сервер приложений
Время от времени у меня возникает ощущение, что с какой-то проблемой никто, кроме меня, не сталкивался. То ли остальные не считают это проблемой и не видят смысла обсуждать, то ли секретную инструкцию вовремя прочитали и тем более молчат. В общем, никого вокруг проблема не беспокоит, хотя надо бы. А мне и спросить не у кого.
Именно такая ситуация возникла, когда я несколько лет назад занялся администрированием серверов 1С. А конкретно проблема заключалась в потерянных сеансах пользователей, мешающих обслуживать базы на сервере. Коллеги в таком случае просто открывали консоль администрирования и жали мышкой на красный крестик, да и то лишь когда им позвонят и попросят удалить сеансы.
Меня такой подход совершенно не устраивал, тем более что приближались новогодние каникулы. Бухгалтера, как водится, собирались ударно поработать чуть ли не со 2 января, а я вовсе не горел желанием чего-то там удалять мышкой по крестику, отвлекаясь от личных дел.
Средства, предусмотренные на этот случай разработчиками платформы (Конфигуратор – Администрирование – Параметры ИБ – Время засыпания пассивного сеанса, Время завершения спящего сеанса), почему-то работали как хотели и не гарантировали результат. Возможно, они до сих пор точно так же халтурят. Давно не проверял за ненадобностью.
Когда я стал искать в интернете готовый рецепт, довольно легко нашел, как удалять соединения, но не сеансы. Недоумение переросло в беспокойство. У меня-то проблем с соединениями не было, у меня проблема с сеансами! У меня что, платформа какая-то не такая, как у всех?
Но все же через синтакс-помощник и путем экспериментов решение было найдено достаточно быстро. Первый вариант внешней обработки был готов к нужному моменту, и результат стоил того. С тех пор накопился реальный опыт применения, обработка неспешно обросла опциями и в своем нынешнем виде прикреплена к этой статье. А здесь хотелось бы поговорить о том, как этим средством пользоваться.
Алгоритм, предлагаемый платформой 1С для получения сведений о сеансах, а заодно и удаления, в схематичном виде выглядит так:
Здесь АдминКластера и ПарольАдминКластера – это логин и пароль администратора кластера серверов 1С. На практике их обычно можно не задавать. Значения по умолчанию – пустая строка.
Посмотрите еще раз на процедуру Сеансы(). В свойствах объекта Сеанс содержится все, что нужно, чтобы отличить одни сеансы от других. Ну, кроме того, чего в платформе все равно нет. А нет там хоть какого-то признака потерянных сеансов.
С остальным все просто. Например, на вопрос, каким приложением создан сеанс, отвечает свойство Сеанс.AppID. Оно может иметь значения: "1CV8" – толстый клиент, "1CV8C" – тонкий клиент, "WebClient" – веб-клиент, "Designer" – конфигуратор, "BackgroundJob" – фоновое задание.
Есть еще свойства, значения которых сообщаются только для толстого клиента, конфигуратора и фонового задания. Это номер процесса (Сеанс.Process.PID) и номер соединения (Сеанс.Connection.ConnID). Учитывая все большее распространение тонкого клиента, эти сведения приходится признать бесполезными. Скорее всего, таким способом вам не удастся выяснить связь конкретного процесса rphost.exe с какой-либо базой. Кстати, в консоли администрирования мы наблюдаем ту же картину.
А еще жаль, что в длинном списке свойств нет явного указания на тот самый сеанс, в котором работает наша программа. Ведь его ни в коем случае нельзя удалять. Значит, придется самим организовать паспортный контроль. Например, вот так:
У объекта ТекущийСеанс есть еще свойство НомерСоединения, но надежность этого признака может зависеть от того, когда объекту присваивается значение – в начале работы или непосредственно перед проверкой. Ну, и замечание, сделанное выше, тоже надо иметь в виду.
Впрочем, даже показанный здесь набор условий выглядит избыточным. Наверняка хватило бы имени базы и номера сеанса, ведь остальные свойства – по сути атрибуты сочетания база + сеанс. Но, сдается мне, лучше воздержаться от такой оптимизации. Никто ведь не гарантировал корректность паспортных данных у потерянных сеансов и невозможность случайных совпадений.
Лучше обратите внимание на то, что проверка имени пользователя должна учитывать подвох, возникающий, например, при работе с пустой базой или при запуске фоновых заданий в отсутствие активных пользователей .
Ну, а если кому-то необходимо посмотреть или удалить соединения, то вместо процедуры Сеансы() нужно вызвать процедуру Соединения(), показанную ниже, но тогда еще потребуются логин и пароль администратора информационной базы:
Разбирая весьма неочевидную последовательность действий, описанную в этой процедуре, можно догадаться, почему в свое время на каком-то форуме нашлась подсказка именно насчет соединений. Для прохождения этого квеста нужен опытный проводник, а с сеансами можно и самому разобраться.
Впрочем, для меня до сих пор остается загадкой, зачем кому-то может потребоваться удалять соединения. Они и сами исправно отваливаются. Лично мне они никогда не мешали.
К тому же, сеанс может быть без соединения, если не нуждается в нем в данный момент. Если сеанс не обращается к кластеру (то есть пользователь бездействует), соединение ему не назначается. Так что для нас объект охоты – сеансы, а не соединения.
Ну так вот, что, собственно, мы собираемся удалять, если у сеансов нет никакого специально предусмотренного флажка вроде ЭтоПотерянный? Как отличить хороших от плохих?
А никак. Нет ведь флажка. Это и есть правильный ответ. Но меня он совершенно не устраивал.
Поэтому моя обработка удаляет сеансы, которые выглядят потерянными. Первый кандидат на это звание – заснувшие сеансы, созданные тонким или толстым клиентом. Просто с другими клиентами я до сих пор не сталкивался, так что пусть пока будет так.
И пусть такие сеансы удаляются автоматически с некоторой периодичностью, например, раз в минуту, что совсем не трудно реализовать. А также при нажатии кнопки, что еще проще.
И вот тут возникает пара совершенно справедливых вопросов.
А во-вторых, как быть с сеансами, которым не спится? Как ни заглянешь в консоль, у них последняя активность вот только что была. Звонишь пользователю – нет никого. Пингуешь компьютер – опять никого. А сеанс все трудится, занят непонятно чем.
В ответ обработка обзавелась парой самых важных опций.
Во-первых, предусмотрен период бездействия, то есть время, в течение которого автоматическое удаление не выполняется. Границы периода задаются с учетом обстоятельств.
Например, если у вас лицензия на 50 подключений, в консоли стабильно наблюдаются 45-48 реальных сеансов, а денег на еще одну лицензию не дают, значит бездействуем только в обед и немного до и после него. Здесь главная задача – обеспечить резерв подключений, чему пользователи будут только рады. Их гораздо больше раздражает невозможность подключиться к базе, когда очень надо.
Если пользователей мало, лицензий гарантированно хватает, к тому же пользователи славятся дружным уходом домой в конце рабочего дня, тогда можно никого не беспокоить весь рабочий день с небольшим запасом.
Кроме того, параметр «Время засыпания пассивного сеанса» все-таки чаще работает, чем не работает. Можно увеличить его с традиционных 20 минут до часа, и это сильно сократит количество жалоб.
Вторая важная опция – возможность удалять сеансы, созданные вчера или еще раньше, но не позднее заданного количества часов назад. Последнее условие позволяет не обрушивать ровно в полночь всю работу. По умолчанию задано 12 часов в расчете на тех, кто приступил к работе после обеда.
Не стоит легкомысленно относиться к этому параметру. Мало ли кто засиделся за компом, нервно смотрит на часы и хочет домой. Кофе давно допит, отчетность вот-вот будет сдана, а тут бац – и карета превращается в тыкву. Тут уж не сомневайтесь – утром придет злая мачеха, и вы узнаете о себе много такого, о чем, в принципе, догадывались.
Необходимо сделать важное замечание, связанное с сеансом самой обработки. Очевидно, что ее выполнение не должно зависеть от пользователей. Самый простой способ добиться этого – специально создать пустую базу и запускать обработку поверх нее. Разумеется, в этом случае база с обработкой займет лишний сеанс.
Сеанс, в котором запущена сама обработка, игнорируется. Но тут есть пара нюансов. С одной стороны, ничто не мешает запускать несколько экземпляров обработки с разными настройками, причем каждый в своем сеансе. С другой стороны, при перезапуске сервера сеанс базы с обработкой может восстановиться, но стать недоступным для управления, то есть по сути потерянным.
Из этих и не только этих соображений предусмотрена возможность указывать базы, исключенные из проверки, а для быстрого заполнения списков добавлены галочки «Проверять все базы» и «кроме этой базы». По умолчанию база с обработкой игнорируется.
Со временем появилась еще пара опций, требующихся редко, даже очень редко, но иногда полезных.
Во-первых, иногда коллеги-админы забывают закрыть конфигуратор после обслуживания базы на сервере. Пришлось предусмотреть возможность удалять такие сеансы. Но это только возможность, а вовсе не обязанность!
Только не забудьте, что если вы решили с помощью обработки расчищать дорогу для бэкапа, а бэкап баз 1С делаете запуском конфигуратора из командной строки, то придется как-то развести по времени удаление чужих сеансов конфигуратора и запуск своих. Тут период бездействия будет как раз кстати.
Ну, а во-вторых, один раз за свою не слишком долгую практику я наблюдал потерянные сеансы фоновых заданий. Уж не помню, что там за катаклизм приключился, но сеансы дружно повисли в консоли. Ладно, пусть будет и такая галочка. Опять же только возможность, а не обязанность.
Поскольку здесь обсуждались индивидуальные настройки процесса удаления для каждого конкретного сервера, возникает вопрос, не обзавелась ли моя обработка, как любая уважающая себя программа, файлом конфигурации? Да, есть такой. Назовем его файлом параметров, чтобы не путаться в терминах. Но об этом ниже.
В командной строке приложений 1С предусмотрены два очень полезных ключика. Ну, не считая других, разумеется. Это /Execute и /C.
Благодаря им установка и первый запуск моей обработки на сервере выглядят так:
1. Копирую на сервер комплект файлов:
v8i-файл для ее запуска
cmd-файл для регистрации библиотеки comcntr.dll
2. Создаю пустую базу. Пусть будет emptybase, к примеру.
3. Регистрирую на сервере библиотеку comcntr.dll, если это до сих пор еще не сделано.
4. В меню стартера 1С добавляю готовый v8i-файл запуска базы с обработкой, хотя это можно и не делать.
Где взять файл обработки, сказано в конце статьи.
Файл для регистрации comcntr.dll сделан из файла RegMSC.cmd. В нем просто заменено имя библиотеки. Ну, и запускать его надо в подкаталоге bin каталога нужной версии платформы.
Файл для запуска базы с обработкой выглядит примерно так:
Уверен, вы знаете, как им пользоваться. Самое интересное написано в последней строке.
Ну и наконец, файл параметров. Здесь он называется setup.txt. Одновременно он служит руководством по написанию таких файлов. Вот реальный пример:
Тут интересны два момента:
1) НомерСоединенияИнформационнойБазы() - Получает номер текущего соединения с информационной базой.
2) ПолучитьСоединенияИнформационнойБазы() - Получает массив описаний соединений с текущей информационной базой.
И всё, третий сеанс им не даёт открыть.
У нас ещё есть пользователи, которым можно любое количество сеансов.
Всем остальным было сделано при открытии нового сеанса просто сбрасывали все ранние. Так решилась проблема зависших сеансов, когда пользователи не могли зайти в документ, который они открывали зависшими сеансами.
Раздел содержит перечень данных, описывающих кластер серверов 1С:Предприятия 8.1, и их расположение. Для наиболее важных данных даны пояснения к их хранению. Раздел не содержит исчерпывающего описания всех данных, управляющих работой кластера.
Рабочий каталог центрального сервера
При установке на компьютер сервера 1С:Предприятия 8.1 происходит выбор рабочего каталога центрального сервера. Обычно, этот каталог "C:Program Files1cv81server", который располагается рядом с каталогом загрузочных модулей 1С:Предприятия 8.1. Этот каталог указывается в строке запуска агента сервера 1С:Предприятия 8.1 при его регистрации в качестве сервиса Windows.
При запуске агента сервера 1С:Предприятия 8.1 ему может быть указан рабочий каталог центрального сервера. Для этого используется параметр -d. Например:
Если параметр -d не указан, то в качестве рабочего каталога центрального сервера используется каталог:
Файл списка кластеров
Список кластеров имеет имя srvribrg.lst. Ниже приведен пример его содержимого с пояснениями:
Важно, что при изменении имени или адреса данного компьютера, а также при копировании рабочего каталога кластера на другой компьютер, имя или IP адрес компьютера должны быть изменены в файле управления агентом. Иначе кластер серверов стартовать не сможет.
При первом запуске агента сервера после установки он создает кластер по умолчанию. При этом список кластеров обычно выглядит так:
Если при первом запуске агента кластера возникли какие-либо проблемы, то кластер по умолчанию может быть не создан. Это проявляется в том, что при запуске агента сервера (ragent) он стартует, но не запускает другие процессы кластера (rmngr, rphost). Список кластеров при этом выглядит так:
В этом случае можно остановить процесс ragent, удалить список кластеров (srvribrg.lst) и запустить ragent снова. Кроме того, кластер может быть создан при помощи утилиты администрирования клиент-серверного варианта работы.
Вторая часть файла списка кластеров содержит список администраторов центрального сервера. В приведенном примере к нему относятся строки:
Наличие хотя бы одного администратора в этом списке требует аутентификации администратора центрального сервера при создании нового кластера. Пустой список администраторов центрального сервера имеет вид:
Рабочий каталог кластера
Рабочие каталоги кластеров располагаются в рабочем каталоге центрального сервера под именами reg_ . Например, для кластера с портом 1541 рабочий каталог кластера будет иметь имя reg_1541. Он создается при создании кластера и содержит всю информацию о работе кластера. При удалении кластера при помощи утилиты администрирования клиент-серверного варианта работы рабочий каталог кластера сохраняется. В рабочем каталоге кластера содержится файл реестра кластера и рабочие каталоги информационных баз.
Файл реестра кластера
Файл реестра кластера содержит общие параметры кластера и списки:
- рабочих серверов,
- рабочих процессов,
- информационных баз,
- администраторов кластера.
Ниже приведен пример файла реестра кластера с пояснениями.
Файл состоит из 5 разделов. Первый раздел включает строки:
и содержит общие параметры кластера, которые можно увидеть среди свойств кластера в утилите администрирования клиент-серверного варианта работы. Имя или IP адрес центрального сервера кластера (server_name_1) должен быть изменен при изменении имени или IP адреса центрального сервера кластера или в случае копирования файла реестра кластера на другой компьютер.
Второй раздел файла в приведенном примере содержит строки:
Следующий раздел определяет список рабочих процессов кластера. В приведенном примере к нему относятся строки:
Здесь определено два рабочих процесса, запускаемых на рабочих серверах server_name_1 (этот же компьютер выполняет функции центрального сервера) и server_name_2. Для каждого рабочего процесса хранится статистическая информация, собранная в процессе его работы. Имена или IP адреса рабочих серверов должны быть изменены при изменении имен или IP адресов рабочих серверов, а также при копировании файла реестра кластера на другой компьютер.
Четвертый раздел определяет список администраторов кластера. В приведенном примере он состоит из строк:
Последний раздел содержит список рабочих серверов кластера. В нашем примере к нему относятся строки:
Здесь определены два сервера с именами server_name_1 и server_name_2. На обоих серверах агент сервера использует порт 1540 и выделены диапазоны динамического распределения IP портов с 1560 по 1591. Имена или IP адреса рабочих серверов должны быть изменены при изменении имен или IP адресов рабочих серверов, а также при копировании файла реестра кластера на другой компьютер.
Рабочий каталог информационной базы
В рабочем каталоге кластера могут располагаться рабочие каталоги информационных баз. Имя рабочего каталога информационной базы совпадает с ее идентификатором в файле реестра кластера. Например, рабочий каталог информационной базы InfoBase1 из приведенного выше примера будет называться 63e734a9-d0dc-4cd9-bcdf-4ede41666a24.
В рабочем каталоге информационной базы содержатся профайлы информационной базы, журнал регистрации (подкаталог 1Cv8Log), служебные данные системы полнотекстового поиска и некоторые другие данные.
Маленький IT блог с характером 1С.
Поиск по блогу
четверг, 14 июля 2016 г.
Миграция на новую версию сервера 1С:Предприятия
Данный метод справедлив для клиент-серверного варианта работы! Первым шагом выполняем создание резервной копии информационной базы (ИБ). Выполнить создание резервной копии можно различными способами, как средствами конфигуратора, так и средствами СУБД.
При работе в клиент-серверном варианте используется трехуровневая архитектура с использованием кластер серверов 1С:Предприятия, через который выполняется общение клиентской части 1С:Предприятия и СУБД.
После создания резервной копии, удаляем информационную базу в кластере серверов 1С:Предприятия старой версии (допустим, версии 8.2), связанную с базой данных СУБД, которая хранит данные информационной базы. Перед удалением запоминаем имя базы данных в СУБД.
У сервера 1С:Предприятие нет собственного пользовательского интерфейса (GUI), для управления им используется консоль администрирования кластера серверов, ее можно установить при установке платформы 1С.
Что бы выполнить данную операцию, открываем консоль администрирования кластера старой версии, выделяем необходимую информационную базу. Правой кнопкой мыши вызываем контекстное меню и выбираем пункт Свойства, откроется окно параметров информационной базы, в котором в свойстве База данных будет отображаться имя базы данных (см. рисунок 1), запоминаем его.
 |
| Рисунок 1. Параметры информационной базы |
Повторно вызываем контекстное меню и нажимаем на кнопку Удалить (см. рисунок 2).
 |
| Рисунок 2. Удаление информационной базы из кластера |
Консоль предложит три варианта удаления (см. рисунок 3):
 |
| Рисунок 3. Режимы удаления информационной базы |
Выбираем третий вариант. Теперь кластер серверов старой версии не знает о существовании базы данных в СУБД, которая хранит данные удаленной информационной базы.
Следующим шагом нужно "рассказать" новому кластеру серверов (допустим, версии 8.3) о существовании базы данных в СУБД, в которой содержатся данные удаленной информационной базы. Для этого открываем консоль администрирования кластера новой версии и создаем новую информационную базу (см. рисунок 4).
 |
| Рисунок 4. Создание новой информационной базы через консоль кластера |
В окне создания новой информационной базы указываем новые параметры создания, только в свойстве База данных указываем имя базы данных, которое запомнили при удалении информационной базы (см. рисунок 1 и 5).
 |
| Рисунок 5. Параметры новой информационной базы |
Данным действием связывается новая информационная база с данным в базе данных. После работ с консолью, в окне запуска 1С:Предприятия для существующей информационной базы изменяем параметры информационной базы (см. рисунок 6):
Запускаем конфигуратор информационной базы от имени пользователя с правами администрирования ИБ, конфигуратор может запросить подтверждение на конвертацию структуры ИБ под новую версию платформы 1С, соглашаемся.
Действия по переходу на новую платформу завершены.
Как создать базу
Открываем 1С и нажимаем кнопку «Добавить»
Выбираем «Создание информационной базы» и нажимаем «Далее»
Нажимаем «Создание информационной базы без конфигурации для разработки новой конфигурации или загрузки выгруженной ранее информационной базы»
Указываем название базы, выбираем тип расположения «На данном компьютере или на компьютере в локальной сети»
Указываем каталог информационной базы (рекомендуем использовать для размещения базы локальный диск D:)
Оставляем галочки «Выбирать автоматически» и нажимаем «Готово»
В результате создана пустая база, куда можно загрузить требуемую конфигурацию.
Как удалить базу
Откроем программу 1С, выберем нужную базу и внизу видим путь к базе на диске
Как многим наверное известно, система 1С Предприятие поддерживает два варианта работы. Это:
- клиент–сервер;
- файловый вариант работы.
Для клиент-серверного режима необходимо установить Сервер 1С: Предприятия.
В данной статье рассмотрим, как администрировать этот сервер с помощью утилиты Консоль администрирования серверов 1С 8.3 (8.2).
Консоль администрирования серверов 1C Предприятия
У сервера 1С нет собственного интерфейса для управления. Администрирование ведется при помощи консоли серверов 1С. Консоль входит в поставку 1С Платформы и устанавливается локально на компьютер пользователя. Сами Информационные базы могут размещаться как локально, так и на удаленных компьютерах или серверах.
Создание, редактирование и удаление баз на Сервере 1С
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
С помощью контекстного меню базу можно удалить или отредактировать свойства.
Действия в консоли
Также из консоли можно управлять блокировками.
Сегодня поговорим о средствах Администрирования серверов 1С:Предприятия.
1С:Предприятия поддерживает следующие режимы работы:
Клиент – серверный вариант работы
Файловый вариант работы
При работе в клиент-серверном режиме используется трехуровневая архитектура с использованием кластер серверов 1С:Предприятия , через который выполняется общение клиентской части 1С:Предприятия и СУБД.
У Сервера 1С нет собственного пользовательского интерфейса, для его управления могут применяться различные средства, рассмотрим стандартную Утилиту администрирования клиент-серверного варианта, ее можно установить при установке 1С.
Утилита администрирования серверов 1С:Предприятия или консоль сервера 1С
Основные задачи консоль сервера 1С:
- Создание, удаление и изменение рабочих серверов;
- Создание администраторов;
- Создание, удаление рабочих процессов кластера;
- Создание и удаление ИБ
- Принудительное завершение сеанса;
- Блокировка новых подключений.
Коротко рассмотрим основные моменты консоли администрирования 1С серверов:
Создать Центральный сервер 1С
Чтобы добавить новый Центральный сервер 1С:Предприятия 8.2 воспользуемся контекстным меню предварительно выделив строку Центральные серверы 1С
Появится окно, куда необходимо внести имя сервера 1С или его IP адрес.
Создание администраторов сервера 1С
В ветки Администраторы добавляются администраторы сервера. Администраторы имеют права на администрирования только собственным сервером, для управления кластером не нужно быть администратором. Если ни один Администратор не добавлен – то каждый вошедший сможет управлять сервером.
Создание рабочих процессов кластера 1С
Рабочие серверы здесь добавляются и удаляются рабочие процессы, что позволяет влиять на производительность сеансов пользователей, распределяя их по рабочим процессам.
Если посмотреть в свойства процесса то увидим следующее:
Производительность: указывается цифра до 1000, по умолчанию стоит 1000. Новые сеансы присоединяются к тому процессу, у которого производительность максимальная и раз в N минут система сама смотрит на фактическую загрузку процессора и переставляет цифру у производительности.
Свойство Включен: здесь отслеживается активность процесса может принимать следующие значения: Использовать, Не использовать, Использовать как резервный
Создание и удаление ИБ
В ветке Информационные базы видны подключенные базы, есть возможность удалить базу или создать новую.
Если посмотрим свойства БД, то увидим следующее:
Завершение сеанса пользователя 1С
В общей ветке Сеансы можно посмотреть список сеансов для всего кластера, чтоб посмотреть сеансы для отдельной информационной базы, необходимо выбрать нужную ИБ и посмотреть ее Сеансы.
Также можно и удалять сеансы пользователей.
Это конечно не весь перечень, для более полного обзора средств Администрирование серверов 1С Предприятия, читайте:
Задачи, которые помогает решить консоль Администрирование серверов 1С Предприятия, доступны и средствам встроенного языка, но это уже другая тема.
С вами был 1С Программист.
Оставляйте, пожалуйста, комментарий мне важно ваше мнение.
Читайте также: