Как удалить сервер из кластера 1с

Обновлено: 06.07.2024

Собственные наработки и набитые шишки в моей практике по программированию в 1С.

вторник, 8 декабря 2015 г.

Выдержки из ИТС по настройке кластера сервера 1С

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

Масштабируемость кластера серверов

Отказоустойчивый кластер

Уровень отказоустойчивости

Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.

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

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

Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.

2.1.6. Масштабируемость кластера серверов

Масштабируемость кластера серверов обеспечивается несколькими способами:

Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.

В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер . При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер .

Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам.

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

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

2.1.7. Балансировка нагрузки в кластере

2.1.7.1. Доступная производительность рабочего процесса

Каждый рабочий процесс имеет свойство Доступная производительность . Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонный вызов сервера по сравнению с другими рабочими процессами. Эталонный вызов включает в себя следующие операции:

Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.

При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.

При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.

2.1.7.3. Требования назначения функциональности

2.1.7.3.1. Общая информация

Кластер серверов предоставляет некоторый набор функциональных возможностей (называемые объекты требований ), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере.

Для того чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.

Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс

Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.

Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
Сделать систему простой в развертывании и администрировании.

К желаемому результату мы пришли не сразу.

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

Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:

Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
Вычислительные кластеры (High performance computing clusters, HPC)
Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.

Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.

1С:Предприятие 8.0

Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».

Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.

1С:Предприятие 8.1

В следующей версии мы захотели:

Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.

Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.

На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:

rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).

Под катом – схема работы этих трёх процессов в составе кластера.

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

1С:Предприятие 8.2

В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.

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

Отказоустойчивость

Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.

Балансировка нагрузки

Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:

Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.

Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.

Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).

Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:

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

Резервирование кластеров

Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.

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

1С:Предприятие 8.3

В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:

Новая настройка кластера «Уровень отказоустойчивости»: число, указывающее, сколько серверов может выйти из строя без последствий в виде аварийного завершения сеансов подключенных пользователей. Исходя из этой настройки кластер будет тратить определённый объём ресурсов на синхронизацию данных между рабочими серверами, чтобы иметь всю необходимую для продолжения работы клиентов информацию на «живых» серверах в случае выхода из строя одного или нескольких серверов.
Количество рабочих процессов не задается вручную, как раньше, а автоматически рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
Появился ряд настроек, связанных с максимальными объемами памяти, которые разрешается потреблять рабочим процессам, а также настройки, определяющие что делать, если эти объемы превышены:

Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».

Три звена отказоустойчивости

Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:

В заключение

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

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

Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.

В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):

Релиз версии 1С: Предприятие 8.3 был анонсирован в 2012 году. Вместо резервного кластера ( как в версии 8.2 ) сделали один кластер, но внутри кластера можно указывать различные параметры, т.е. значительно упростили настройку отказоустойчивости.

В этой версии был существенно переписан весь код самой платформы.

Перед тем, как рассмотреть настройки, отмечу ключевые параметры запуска ragent :

–range – Порты рабочих процессов
–d – Директория, где живет сервер (было рассмотрено в предыдущей статье)
–debug – Флаг отладки на сервере

Строку запуска ragent можно посмотреть в службе, а настроить параметры в редакторе регистра: «HKLM -> SYSTEM -> Current Control Set - > Services». Строку запуска ragent можно посмотреть в службе, а настроить параметры в редакторе регистра: «HKLM -> SYSTEM -> Current Control Set - > Services».

Файлы и каталоги сервера 1С

Общий каталог сервера (C:\Program Files\1cv8\srvinfo\)
lst – файл настроек кластера
lst – файл со списком баз
Каталоги баз:1Cv8FTxt – файлы полнотекстового поиска
1Cv8Log – файлы журналов регистрации
Snccntx – сеансовые данные.

Поместить во временное хранилище помещает данные в сеансовые данные (snccntx на диске), при этом часть данных может кэшироваться в оперативной памяти.

Основные настройки кластера 1С: 8.3

Защищенное соединение:

Шифрует данные между клиентом и сервером 1С.

Поэтому и в данном случае, при включенном шифровании, производительность будет падать, т.к. тратятся ресурсы.

Рекомендуется оставлять «выключено», тогда будет шифроваться пароль только при первом соединении(!). Не влияет на шифрование данных между 1С и СУБД.

Интервал перезапуска:

Автоматически перезапускает рабочие процессы (rphost). Начало отсчета интервала перезапуска = момент нажатия на кнопку «ОК», поэтому ставите интервал 1 раз в сутки (86 400 с.), то ставьте ночью.

Перезапуск процесса (выключение старого и включение нового) разделен на этапы:

Процесс помечается как выключенный, теперь на него не назначаются новые сеансы.
Создается новый процесс, на который перекидываются все сеансы с выключенного.
Если за интервал времени « проблемные процессы завершать через » (например, 1 минута) остались висеть сеансы, то они обрываются принудительно, а процесс убивается (клиент получит ошибку).

Имеет смысл только для 32 разрядных систем, т.к. там есть фрагментация памяти (рассматривается на занятии 01-01. Знакомство с 1С ). Для 64 полезно использовать только тогда, когда есть утечки памяти, и проблема пока не решается.

Уровень отказоустойчивости (УО):

Имеет смысл только если в кластере более 1 сервера. Максимальный уровень отказоустойчивости - это количество серверов в кластере минус 1, т.е. если в кластере 1 сервер, то уровень отказоустойчивости = 0. Если же их 3, то есть возможность задать значение УО равным от 0 до 2.

Уровень отказоустойчивости – это количество серверов, которые могут упасть, без последствий для пользователя.

Важный момент, что резервирование идет именно для служебных серверов, т.е. если упадет центральный, то весь кластер умрет. Все обеспечивается за счет резервирования сеансовых данных (копирование на резервный сервер), а это опять же влияет на производительность.

В этой статье описано, как удалить серверы в локальных дисковых пространствах с помощью PowerShell.

Удаление сервера без удаления дисков

Если вы планируете вскоре вернуть сервер в кластер или переместить его диски на другой сервер, вы можете удалить сервер из кластера, не удаляя его диски из пула носителей (вариант по умолчанию при удалении сервера с помощью диспетчера отказоустойчивости кластеров).

Используйте командлет Remove-ClusterNode в PowerShell:

Этот командлет выполняется быстро независимо от реализованной мощности, так как пул носителей "запоминает" недостающие диски и ожидает их возвращения. Данные с недостающих дисков не перемещаются. У параметра OperationalStatus для недостающих дисков будет значение "Связь утеряна", а состояние томов будет отображаться как "Неполный".

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

Не перемещайте диски с данными пула с одного сервера на несколько других серверов. Например, в случае сбоя одного сервера с десятью дисками (например, из-за сбоя системной платы или загрузочного диска) вы можете переместить все десять дисков на один новый сервер, но не перемещайте их по отдельности на разные серверы.

Удаление сервера и его дисков

Если вы хотите окончательно удалить сервер из кластера (это называется свертыванием), можете удалить как сам сервер из кластера, так и его диски из пула носителей.

Используйте командлет Remove-ClusterNode с необязательным флагом -CleanUpDisks:

Выполнение этого командлета может длиться долго (иногда много часов), так как Windows должна переместить все данные с этого сервера на другие серверы в кластере. После выполнения этого командлета диски окончательно удаляются из пула носителей, а тома возвращаются в работоспособное состояние.

Требования

Чтобы можно было окончательно удалить сервер и его диски, кластер должен соответствовать двум требованиям, указанным ниже. В противном случае командлет Remove-ClusterNode -CleanUpDisks сразу вернет ошибку и не будет перемещать данные, чтобы не допустить дополнительных сбоев.

Достаточно памяти

Во первых, необходимо иметь достаточно места на оставшихся серверах для размещения всех томов.

Например, если у вас четыре сервера, каждый из которых состоит из 10 дисков по 1 ТБ, у вас есть 40 ТБ физической памяти. После удаления одного сервера и всех его дисков у вас останется 30 ТБ места. Если ваши тома занимают более 30 ТБ места, они не поместятся на остающихся серверах, поэтому командлет вернет ошибку и не будет перемещать данные.

Достаточно доменов сбоя

Во-вторых, у вас должно быть достаточно доменов сбоя (как правило, серверов) для обеспечения устойчивости томов.

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

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

Устойчивость	Минимальное количество доменов сбоя
Двухстороннее зеркало	2
Трехстороннее зеркало	3
Двойная четность	4

Ничего страшного, если в течение короткого периода у вас будет меньше серверов (например, во время сбоев или обслуживания). Но чтобы тома вернулись в полностью работоспособное состояние, необходимо минимальное количество серверов, указанное выше.

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

Именно такая ситуация возникла, когда я несколько лет назад занялся администрированием серверов 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) ПолучитьСоединенияИнформационнойБазы() - Получает массив описаний соединений с текущей информационной базой.

И всё, третий сеанс им не даёт открыть.

У нас ещё есть пользователи, которым можно любое количество сеансов.
Всем остальным было сделано при открытии нового сеанса просто сбрасывали все ранние. Так решилась проблема зависших сеансов, когда пользователи не могли зайти в документ, который они открывали зависшими сеансами.

Читайте также: