Кластер серверов 1с предприятия что указывать
1С для автоматизации документооборота и процессов
Кластер серверов 1С:Предприятия 8 (1C:Enterprise 8 Server Cluster)
Кластер серверов 1С:Предприятия 8 является основным компонентом платформы, который обеспечивает взаимодействие между системой управления базами данных и пользователем в случае варианта клиент-серверной работы. Кластер дает возможность организовать бесперебойную, устойчивую к отказам, конкурентную работу для значительного количества пользователей с объемными информационными базами.
Кластер серверов 1С:Предприятия 8 – это логическое понятие, которое обозначает совокупность процессов, которые обслуживают один и тот же комплект информационных баз.
Можно выделить следующие возможности кластера серверов, как основные:
- возможность функционировать как на нескольких, так и на одном компьютере (рабочих серверах);
- каждый рабочий сервер может поддерживать функционирование как одного, так и нескольких рабочих процессов, которые обслуживают клиентские соединения в границах этого кластера;
- включение новых клиентов в рабочие процессы кластера происходит, основываясь на долгосрочном анализе статистики загруженности рабочих процессов;
- взаимодействие всех процессов кластера между собой, с клиентскими приложениями и сервером баз данных осуществляется по протоколу TCP/IP;
- запущены процессы кластера, могут быть как сервис, так и как приложение
Клиент-серверный вариант. Схема работы
При этом варианте работы с сервером взаимодействует клиентское приложение. Кластер серверов, в свою очередь, взаимодействует с сервером баз данных.
Роль центрального сервера кластеров играет один из компьютеров, которые входят в состав кластера серверов. Кроме того, что центральный сервер обслуживает клиентские соединения, он еще управляет работой, в целом, всего кластера и хранит реестр данного кластера.
Кластер адресуется для клиентского соединения по имени центрального сервера и, возможно, номеру сетевого порта. В случае если сетевой порт используется стандартный, то для соединения хватает просто указать имя центрального сервера.
Во время установки соединения к центральному серверу кластера обращается клиентское приложение. Основываясь на анализе статистики загруженности рабочих процессов, центральный сервер переправляет клиентское приложение к необходимому рабочему процессу, который должен его обслуживать. Данный процесс может быть активирован на любом рабочем сервере кластера, в частности и на центральном сервере.
Обслуживание соединения и аутентификация пользователя поддерживаются этим рабочим процессом до момента прекращение работы клиента с конкретной информационной базой.
Кластер серверов
Элементарный кластер серверов может представлять собой единственный компьютер и содержать только один рабочий процесс.
На рисунке можно наблюдать все элементы, которые, так или иначе, принимают участие в работе кластера серверов. Это следующие элементы:
- процессы кластера серверов: o ragent.exe; o rmngr.exe;
o rphost.exe;
- хранилища данных: o список кластеров;
o реестр кластера.
Процесс ragent.exe, называемый – агент сервера, обеспечивает функционирование компьютера как составной части кластера. Следовательно, компьютер, на котором запущен процесс ragent.exe, следует называть рабочим сервером. В частности одной из функциональных обязанностей ragent.exe является ведение реестра кластеров, которые находятся на конкретном рабочем сервере.
Ни реестр кластеров, ни агент сервера не являются составной частью кластера серверов, а только лишь дают возможность функционировать серверу и кластерам, расположенным на нем.
Сам кластер серверов состоит из таких элементов:
- один или несколько процессов rmngr.exe
- реестр кластера
- один или несколько процессов rphost.exe.
Менеджер кластера (процесс rmngr.exe). Он служит для управления функционирования всего кластера. В состав кластера может входить несколько процессов rmngr.exe, один их которых всегда будет главным менеджером данного кластера, а остальные процессы – дополнительными менеджерами. Центральным сервером кластера следует называть рабочий сервер, на котором действует главный менеджер кластера, и который содержит список кластера. Именно ведение реестра кластера является одной из функций главного менеджера кластера.
Рабочий процесс (процесс rphost.exe). Именно он, непосредственно, обслуживает клиентские приложения, взаимодействуя с сервером баз данных. В этом процессе могут исполняться некоторые процедуры конфигурации серверных модулей.
Масштабируемость 1С версии 8.3
Масштабируемость кластера серверов осуществляется следующими способами:
- увеличивают количество менеджеров в кластере и распределение сервисов между ними
- увеличивают количество рабочих процессов, которые функционируют на данном рабочем сервере
- увеличивают количество рабочих серверов, из которых состоит кластер.
Использование одновременно нескольких менеджеров.
Функции, которые исполняет менеджер кластера, разделяются на несколько сервисов. Данные сервисы можно назначить разным менеджерам кластера. Это дает возможность равномерно распределить нагрузку по нескольким процессам.
Однако некоторые сервисы могут быть использованы только главным менеджером кластера:
- сервис конфигурации кластера
- сервис управления предметами отладки
- сервис блокировок кластера.
Для прочих сервисов допустимы в назначение произвольные менеджеры кластера:
- сервис журналов регистрации
- сервис блокировки объектов
- сервис заданий
- сервис полнотекстового поиска
- сервис сеансовых данных
- сервис нумерации
- сервис пользовательских настроек
- сервис времени
- сервис транзакционных блокировок.
Использование одновременно нескольких рабочих процессов.
С одной стороны использование нескольких рабочих процессов дает возможность понизить нагрузку каждого конкретного рабочего процесса. С другой стороны, применение нескольких рабочих процессов приводит к более эффективному использованию аппаратных ресурсов рабочего сервера. Более того, процедура запуска нескольких рабочих процессов повышает надежность сервера, так как изолирует группы клиентов, которые работают с разными информационными базами. Рабочий процесс в кластере, в котором допустим запуск нескольких рабочих процессов, может быть перезапущен автоматически, в рамках временного интервала, указанного администратором кластера.
Возможность использования большего количества рабочих процессов (увеличение количества клиентских соединений) не увеличивая нагрузки на конкретный рабочий процесс, дает изменение, в большую сторону, количества рабочих серверов, которые входят в кластер.
Отказоустойчивость 1С версии 8.3
Устойчивость к отказам в работе кластера обеспечивается тремя направлениями:
- резервированием самого кластера
- резервированием рабочих процессов
- устойчивостью к обрыву канала связи.
Резервирование кластера 1С версии 8.3
Несколько кластеров объединяются в группу резервирования. Кластеры, которые находятся в такой группе, автоматически синхронизируются.
В случае выхода из строя активного кластера, его заменяет следующий рабочий кластер группы. После того, как неработоспособный кластер будет восстановлен, он станет активным после синхронизации данных.
Резервирование рабочих процессов 1С версии 8.3
Для каждого из рабочих процессов есть возможность указания вариантов его использования:
- использовать
- не использовать
- использовать как резервный.
В случае аварийного завершения работы какого-либо процесса, кластер начинает использовать вместо него неактивный на данный момент резервный процесс. При этом происходит автоматическое перераспределение имеющейся на него нагрузки.
Устойчивость 1С версии 8.3 к обрыву канала связи
Так как каждому пользователю обеспечивается собственный сеанс связи, то кластер сохраняет данные о подключавшихся пользователях и о том, какие действия ими выполнялись.
При исчезновении физического соединения кластер будет находиться в состоянии ожидания соединения с данным пользователем. В большинстве случаев, после того, как соединение восстановится пользователь будет иметь возможность продолжить работу именно с того места, момента, на котором произошел разрыв связи. Повторное подключение к информационной базе не потребуется.
Сеансы работы в 1С версии 8.3
Сеанс дает возможность определить активного пользователя конкретной информационной базы и определить поток управления от этого клиента. Различают следующие типы сеансов:
- Тонкий клиент, Веб-клиент, Толстый клиент – эти сеансы возникают при обращении соответствующих клиентов к информационной базе
- Соединение типа «Конфигуратор» — оно возникает при обращении к информационной базе конфигуратора
- СОМ-соединение – образовывается при использовании внешнего соединения для обращения к информационной базе
- WS-соединение – возникает в случае обращения к информационной базе веб-сервера, как следствие обращения к опубликованному на веб-сервере Web-сервису
- Фоновое задание – образовывается, когда рабочий процесс кластера обращается к информационной базе. Служит такой сеанс для исполнения кода процедуры фонового задания, Консоль кластера – создается, когда утилита администрирования клиент-серверного варианта обращается к рабочему процессу
- СОМ-администратор – возникает в случае обращения к рабочему процессу с использованием внешнего соединения.
- Работа при использовании различных операционных систем
Любые процессы кластера серверов могут функционировать как под операционной системы Linux, так и под операционной системы Windows. Это достигается тем, что взаимодействие кластеров происходит под управлением протокола TCP/IP. Также в состав кластера могут входить рабочие серверы под управлением любой из этих операционных систем.
Утилита администрирования кластера серверов 8.3
В комплекте поставки системы имеется утилита для администрирования варианта клиент-серверной работы. Эта утилита дает возможность изменения состава кластера, управления информационными базами, и оперативно анализировать транзакционные блокировки.
xn--90afdtkhdeabaxvge.net
Создание кластера серверов 1С:Предприятие 8.3
Рассмотрим настройку кластера серверов 1С:Предприятие 8.3 на двух серверах под управлением ОС Windows Server.
При установке сервера 1С на оба компьютера необходимо выбрать компонент «Компоненты доступа к серверам 1С:Предприятие»
После завершения установки следует на обоих сервера запустить средство управления «Администрирование серверов 1С Предприятия» и удалить «Локальный кластер»
После этого на одном из серверов необходимо создать новый кластер 1С
Нужно выбрать имя для нового кластера, в поле «Компьютер» ввести имя текущего сервера.
После этого создадим новый рабочий сервер в кластере.
В настройках указываем имя второго сервера. Обязательно следует изменить диапазон IP портов. Для каждого сервера в кластере этот диапазон должен отличаться. На этапе создания сервера параметр «Центральный сервер» неактивен. Необходимо включить его уже после создания сервера в его свойствах. После этого на втором сервере синхронизируется вся информация о созданном кластере.
На последнем этапе необходимо указать уровень отказоустойчивости созданного кластера «1». 
Вадим Соколович efsol-it.blogspot.com
Автоматизация бизнеса на платформе 1С:Предприятие 8
Содержание 1. Правильно ли оставлять настройки кластера серверов 1С 8.3 “по умолчанию”. 2. Рекомендации по настройке кластера 1С 8.3 3. Рекомендации по настройке СУБД MS SQL Устанавливая 1С в клиент-серверном варианте, случается, что специалисты оставляют настройки кластера серверов 1С 8.3 по умолчанию. Это может приводить к неоптимальному использованию аппаратных ресурсов эксплуатируемых серверов и к нестабильной работе серверов 1С и СУБД.
В статье рассмотрим рекомендации по основным настройкам кластера серверов 1С 8.3 и СУБД MS SQL. 1. Рекомендации по настройке кластера 1С 8.3
Окно настроек кластера 1С 8.3 выглядит примерно так: 
Обратите внимание, что настройки кластера отвечают за настройки всех серверов принадлежащих настраиваемому кластеру. Кластер подразумевает работу нескольких физических или виртуальных серверов, работающих с одними и теми же информационными базами. Интервал перезапуска – отвечает за частоту перезапуска рабочих процессов кластера. Этот параметр необходимо выставлять при круглосуточной работы сервера. Рекомендуется частоту перезапуска связывать с технологическим циклом информационных баз кластера. Обычно это каждые 24 часа (86400 сек). Как известно, рабочие процессы серверов 1С обрабатывают и хранят рабочие данные. Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». На ИТС есть даже информация о том, как организовать перезапуск рабочих процессов по другим параметрам (объем памяти, занимаемые ресурсы и т.п.).
Допустимый объем памяти – защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. Можно рассчитать как максимальный размер памяти, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Также стоит установить небольшой интервал превышения допустимого объема. Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы». Выключенные процессы останавливать через. При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то можно стоит этот параметр на 2-5 минут. Теперь посмотрим на настройки сервера 1С:
Эти настройки устанавливаются для каждого сервера 1С индивидуально. Максимальный объем памяти рабочих процессов – это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере. Если параметр установлен в «0», то занимает 80% оперативной памяти сервера. «-1» - без ограничений. Когда на одном сервере работают СУБД и сервер 1С, им нужно делить между собой оперативную память. Если в процессе эксплуатации обнаружится, что серверу СУБД не хватает памяти, то можно ограничить память, выделяемую серверу 1С с помощью этого параметра. Если СУБД и 1С разделены по серверам, то имеет смысл рассчитать этого параметр по формуле:
«Max объем» = «Общая оперативная память» – «Оперативная память ОС»;
«Оперативная память ОС» рассчитывается по принципу 1 Гб на каждые 16 Гб оперативной памяти сервера
Безопасный расход памяти за один вызов. В общем случае, отдельные вызовы не должны занимать всю оперативную память, выделенную рабочему процессу. Если параметр установлен в «0», то объем безопасного расхода будет равен 5 % от «Максимального объема памяти рабочих процессов». «-1» - без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0». С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам. Например, запускать под каждую информационную базу отдельный «rphost», чтобы в случае «падений» процесса, отключались только пользователи одной базы. Эти параметры стоит подбирать индивидуально под каждую конфигурацию сервера. 2. Рекомендации по настройке СУБД MS SQL
Ограничение на использование оперативной памяти сервером СУБД – У сервера СУБД MS SQL есть одна замечательная особенность – он любит загружать базы, с которыми ведется активная работа в оперативную память полностью. Если его не ограничивать, то он заберет себе всю оперативную память, какую только сможет. • Если сервер 1С:Предприятия установлен вместе с Microsoft SQL Server, то верхний порог памяти необходимо уменьшить на величину, достаточную для работы сервера 1С. • Если на сервере работает только СУБД, то для СУБД по формуле: «Память СУБД» = «Общая оперативная память» – «Оперативная память ОС»; 
Shared memory – об этом параметре известно много, но до сих пор встречается, что про него забывают. Выставляем в «1», если сервер 1С и СУБД работают на одном физическом или виртуальном сервере. Кстати, работает, начиная с платформы 8.2.17.
Max degree of parallelism – определяет сколько процессоров используется при выполнении одного запроса. СУБД распараллеливается получение данных при выполнении сложных запросов на несколько потоков. Для 1С рекомендуется устанавливать в «1», то есть одним потоком. Авторасширение файлов БД - определяем шаг в МБ, с которым «расширяется» файл базы данных. Если шаг будет маленький, то при активном росте БД, частые расширения приведут к дополнительной нагрузке на дисковую систему. Лучше установить в 500 – 1000 МБ.
Реиндексация и дефрагментация индексов – рекомендуется делать дефрагментацию/реиндексацию хотя бы раз в неделю. Реиндексация блокирует таблицы, поэтому лучше запускать в нерабочее время или периоды минимальной нагрузки. Нет смысла делать дефрагментацию после перестроения индекса (реиндексации). По рекомендации Microsoft дефрагментацию делают в том случае, если фрагментация индекса не превышает 30 %. Если выше, рекомендуется сделать реиндексацию.
Обновление статистики - рекомендуется обновлять статистику хотя бы 1 раз в день. Статистика отвечает за производительность выполнения запросов. План электропитания – в настройках электропитания операционной системы установить на высокую производительность. В статье представлены рекомендации основных настроек серверов, на которые стоит обращаться внимание в первую очередь, более подробную информацию можно узнать по ссылкам: Настройки MS SQL
Регламентные операции СУБД Кирилл Карцев,
программист 1С, руководитель отдела внедрения ООО “Кодерлайн”
www.koderline.ru
Выдержки из ИТС по настройке кластера сервера 1С
- Отказоустойчивый кластер
-
- Требования назначения функциональности
Уровень отказоустойчивости определяет максимальное количество рабочих серверов, входящих в состав кластера, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Надо понимать, что «выход из строя» подразумевает ситуации, подобные следующим: отключение питания компьютера, разрыв сетевого кабеля, проблемы с операционной системой, не позволяющие запустить процесс и т. д.
Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.
Следует понимать, что увеличение уровня отказоустойчивости выполняется ценой некоторого падения производительности кластера, т. к. кластер будет тратить некоторые ресурсы на синхронизацию данных между рабочими серверами.
Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогу подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям, несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.
Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.
Масштабируемость кластера серверов обеспечивается несколькими способами:
● Наращиванием вычислительных мощностей компьютера, на котором развернут единственный рабочий сервер кластера.
● Возможностью включения в состав кластера серверов одного или нескольких новых рабочих серверов.
Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.
В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер. При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер. Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам. Во время установки соединения с информационной базой, кластер серверов выбирает рабочие сервера с максимальной доступной производительностью (на момент выбора рабочего сервера). Существующие соединения могут быть перемещены на другой рабочий сервер. Более подробное описание этого механизма см. здесь. Описание других свойств, управляющих работой рабочего сервера, см. здесь. Каждый рабочий процесс имеет свойство Доступная производительность. Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонный вызов сервера по сравнению с другими рабочими процессами. Эталонный вызов включает в себя следующие операции:
● Операция с памятью: выделение массива, заполнение массива, освобождение массива.
● Операция с файлами: создание, запись, удаление.
● Выполняется определение степени загрузки процессоров компьютера, на котором работает рабочий процесс и количество потоков, ожидающих исполнения. Это значение корректирует время выполнения эталонного вызова в сторону увеличения. Если пользователь, от имени которого работает сервер, не входит в группу Пользователи журналов производительности (Performance Log Users), то определение степени загрузки процессора не выполняется.
Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонного вызова текущим рабочим процессом. Эталонный вызов выполняется каждые 2 секунды в том случае, если в кластере присутствует несколько рабочих серверов. Если кластер серверов состоит из одного рабочего сервера – все рабочие процессы считаются равноправными.
Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.
При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.
При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.
Кластер серверов предоставляет некоторый набор функциональных возможностей (называемые объекты требований), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере.
Для того чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.
Требование назначения функциональности определяет:
● Для какого объекта требования создается требование. В качестве объекта требования могут выступать некоторые сервисы кластера (см. здесь), клиентские соединения (см.здесь) и произвольный объект требования. В качестве объекта требования могут выступать следующие сервисы кластера: ● Блокировок объектов.
● Времени.
● Журналов регистрации.
● Заданий.
● Нумерации.
● Полнотекстового поиска.
● Пользовательских настроек.
● Сеансовых данных.
● Транзакционных блокировок.
● Работы с внешними источниками данных через ODBC.
● Работы с внешними источниками данных через XMLA.
● Сервис лицензирования.
● Сервис фонового обновления конфигурации базы данных.
● Сервис тестирования.
● Сервис внешнего управления сеансами.
● Определяет тип требования. Тип требования определяет, каким образом будет выполняться использование рабочего сервера:
● Не назначать – означает, что рабочий сервер, для которого создано данное требование, не будет назначен для обслуживания объекта требования, подходящего под условия, заданные в требовании.
● Назначать – означает, что рабочий сервер, для которого создано данное требование, будет являться одним из кандидатов на обслуживание данного объекта требования (если рабочих серверов будет несколько).
● Авто – означает, что рабочий сервер может быть использован для обслуживания объекта требования в том случае, если нет рабочего сервера с явным указанием необходимости использования.
СОВЕТ. Тип требования Авто имеет смысл использовать тогда, когда в списке требований рабочего сервера есть требование с более широким набором условий, и необходимо иметь требование для более узкого набора условий. Например, данный сервер не может обслуживать соединения клиентских приложений для всех информационных баз, кроме одной информационной базы, для которой такое обслуживание разрешено.
● Дополнительные параметры, необходимые кластеру серверов для принятия решения в ряде случаев:
● Имя информационной базы. Используется для уточнения требования для формирования требований для клиентских соединений и всех сервисов кластера, которые могут выступать в качестве объекта требования, кроме сервиса лицензирования.
● Дополнительные параметры. Используются для уточнения требований при размещении клиентского соединения или сервиса сеансовых данных. Дополнительный параметр проверяется на совпадение с началом соответствующего параметра объекта требования. Дополнительный параметр может принимать одно из следующих значений:
● Для указания конкретного фонового задания: BackgroundJob.CommonModule..;
● Для указания всех фоновых заданий: BackgroundJob.CommonModule;
● Для указания всех отчетов: BackgroundJob.Report. Указание имени отчета не поддерживается;
● Ввод по строке или поиск в списке: BackgroundJob.SystemBackgroundJob;
● Для указания фоновой реструктуризации: SystemBackgroundJob;
● Для клиентского приложения:
● 1CV8 – толстый клиент;
● 1CV8CDirect – тонкий клиент в случае прямого подключения к серверу «1С:Предприятия»;
● Designer – конфигуратор;
● COMConnection – COM-соединение;
● WebServerExtension – соединение с информационной базой через веб-сервер: веб-клиент, тонкий клиент в случае подключения через веб-сервер, Web-сервис.
Рассмотрим, как работает кластер серверов при обработке требований.
В случае необходимости выполнить размещение объекта требования, кластер выполняет следующие действия:
● На всех серверах, входящих в состав кластера, выполняется обработка заданных для этих серверов требований назначения функциональности. Обход серверов и требований выполняется в порядке следования этих объектов в консоли кластера.
● В каждом списке требований определяется первое требование, которое удовлетворяет размещаемому объекту: по собственно объекту, информационной базе и дополнительному параметру.
● Затем полученный список рабочих серверов сортируется по признаку типа требования так, что первыми оказываются рабочие сервера с явным указанием использования. Рабочие сервера, для которых подходящее требование содержит явный запрет на использование – исключаются из списка доступных рабочих серверов. При этом назначение выполняется следующим образом:
● Есть рабочие сервера с явным указанием использования: в этом случае объект требования будет обслужен одним из этих рабочих серверов.
● Нет рабочих серверов с явным указанием использования: происходит попытка использовать рабочие сервера с автоматическим указанием использования или те рабочие серверы, для которых не указано требований.
● Подробное описание правил выбора рабочего сервера для обслуживания объекта требования см. здесь. ● При размещении клиентского соединения, из списка доступных серверов будет выбран тот, в состав которого входит рабочий процесс с наивысшей доступной производительностью (см. здесь). Подробное описание правил выбора рабочего процесса в конкретном рабочем сервере см. здесь. Клиентское приложение, инициировавшее размещение объекта требования, будет завершено аварийно в одном из следующих случаях:
● Если для объекта требования список рабочих серверов оказывается пустым – нет ни одного рабочего сервера, который может обслужить объект. При этом объект требования не будет размещен и будет вызвано исключение.
● Если невозможно выполнить размещение на выбранном рабочем сервер, например, если выбранный сервер вышел из строя, и нет альтернативных рабочих серверов.
Более подробно рассмотрим алгоритм назначения рабочего сервера для обслуживания сервиса кластера.
Для сервисов кластера (см. здесь) объектом требования может выступать: ● Сервис одного типа, если сервис не делится по информационным базам.
● Сервис одного типа для одной информационной базы, если сервис делится по информационным базам.
● Сервис сеансовых данных.
● Сервис лицензирования.
Сервисы распределяются между подходящими рабочими серверами следующим образом:
● Из перечня выбранных для назначения рабочих серверов выбираются те, которые в данный момент работоспособны. Среди оставшихся рабочих серверов выбираются те сервера, у которых свойство Приоритет содержит максимальное значение.
● Среди отобранных рабочих серверов сервисы распределяются равномерно.
● Сервисы, поддерживающие репликацию, могут назначаться на несколько рабочих серверов. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь). При этом один сервис будет являться активным, а с другими сервисами (резервными) будет поддерживаться репликация служебных данных сервиса. Репликация выполняется асинхронно. Синхронизация выполняется каждую секунду. ● Сервисы, которые не поддерживают перенос данных, назначаются на все рабочие серверы кластера с установленным флажком Центральный сервер (см. здесь). ● Для каждого сеанса, который обслуживает кластер серверов, создается свой экземпляр сервиса сеансовых данных. При отборе рабочих серверов, которые могут обслужить данный экземпляр сервиса, учитываются дополнительные параметры требования. Из списка доступных выбираются сервера с минимальным количеством обслуживаемых сервисов кластера. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь). ● В случае необходимости использования сервиса лицензирования следует явно выбрать рабочий сервер, к которому будет выполняться привязка программной лицензии и явно описать в требованиях размещение сервиса на выбранном рабочем сервере.
● Остальные сервисы назначаются в единственном экземпляре.
Переназначение сервисов кластера между рабочими серверами может выполняться в следующих случаях:
● При добавлении рабочего сервера выполняется частичное переназначение сервисов. Данное переназначение выполняется автоматически.
● При удалении рабочего сервера из состава кластера или недоступности рабочего сервера выполняется переназначение только тех объектов требований, которые обслуживал удаляемый рабочий сервер. Данное переназначение выполняется автоматически.
● При удалении или добавлении информационной базы в кластер выполняется частичное переназначение. Данное переназначение выполняется автоматически.
● Переназначение происходит также в том случае, если администратор кластера выполнит операцию полного или частичного применения требований из консоли кластера (см.здесь). При запуске кластера на каждом рабочем сервере запускается по одному рабочему процессу и начинается процесс вычисления доступной производительности для каждого рабочего сервера (см. здесь). Установка соединения клиентского приложения с кластером серверов «1С:Предприятия» выполняется по следующим правилам:
● В соответствии с требованиями назначения и ограничениями по использованию оперативной памяти отбирается необходимый рабочий сервер.
Ограничения по использованию оперативной памяти учитываются в том случае, если запрос на установку соединения выполняется к информационной базе, к которой нет установленных соединений на выбранном рабочем сервере. В случае превышения лимита использования оперативной памяти рабочий сервер исключается из списка, если существует другой рабочий сервер, который не превысил лимит. Также исключаются рабочие сервера, которые не могут обработать требуемое соединение исходя из требований назначения.
● Для выбранного сервера определяется список рабочих процессов, которые доступны и могут обслужить запрашиваемое соединение. Рабочий процесс относится к списку доступных рабочих процессов в следующих случаях:
● Для рабочего процесса не достигнуто максимальное количество обслуживаемых информационных баз (свойство рабочего сервера Количество ИБ на процесс).
● Для рабочего процесса не достигнуто максимальное количество обслуживаемых соединений (свойство рабочего сервера Количество соединений на процесс).
● Рабочий процесс не находится в состоянии подготовки к автоматическому перезапуску.
● Из выбранных рабочих процессов предпочтение отдается тем рабочим процессам, которые уже обслуживают соединения информационной базы, соединение с которой необходимо обслужить. Если такого рабочего процесса нет – выбирается рабочий процесс с максимальным количеством обслуживаемых соединений.
● Если не удалось выбрать ни один рабочий процесс, то на данном рабочем сервере запускается новый рабочий процесс, который и будет обслуживать запрошенное соединение.
При установке соединения от лица существующего сеанса (если не удалось повторно использовать соединение предыдущего вызова сервера) предпочтение отдается рабочему процессу, который обслуживал предыдущее соединение этого сеанса. При этом возможен выбор другого рабочего процесса, если доступная производительность другого рабочего процесса выше доступной производительности текущего рабочего процесса не менее чем на 25%.
Если на одном рабочем сервере в течении 20 минут существуют 2 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.
При подсчете количества обслуживаемых соединений учитываются соединения, которые создаются отладчиком для проверки прав доступа на предмет отладки.
ВНИМАНИЕ! Приведенные ниже примеры не являются законченными решениями какой-либо проблемы, а служат только для демонстрации принципов работы механизма размещения объектов требований по рабочим серверам в кластере.
Если необходимо разместить все фоновые задания на рабочем сервере SRV1, то для этого необходимо для рабочего сервера SRV1 задать следующее требование назначения функциональности:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.CommonModule.
Необходимо многопользовательскую клиентскую лицензию активировать для компьютера, на котором функционирует рабочий сервер SRV2, разместить на этот компьютер сервис лицензирования и не размещать на этот компьютер больше никаких сервисов. Тогда для рабочего сервера SRV2 следует указать следующие требования:
● Требование 1:
● Объект требования: Сервис лицензирования.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: не указывается.
● Требование 2:
● Объект требования: Любой объект требования.
● Тип требования: Не назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: не указывается.
Требование 1 обеспечит функционирование сервиса лицензирования на сервере SRV2, а Требование 2 обеспечит функционирование на сервере SRV2 только сервиса лицензирования (на сервере SRV2 не будут функционировать другие сервисы кластера).
При активации программной лицензии с помощью сервера «1С:Предприятия» следует указывать имя SRV2, в противном случае активированная лицензия не сможет быть использована кластером серверов, т. к. программная лицензия будет активирована для другого компьютера.
Необходимо разрешить работу сервиса работы с внешними источниками данных на рабочих серверах SRV1 и SRV3, и запретить – на рабочем сервере SRV2. Для этого следует для рабочего сервера SRV2 указать следующее требование:
● Объект требования: Сервис работы с внешними источниками данных.
● Тип требования: Не назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: не указывается.
Необходимо настроить кластер серверов таким образом, чтобы каждая информационная база обслуживалась одним рабочим процессом. Для этого необходимо для каждого рабочего сервера установить свойство Количество ИБ на процесс в значение 1.
В результате на каждом сервере будет создано по два рабочих процесса (всего – 6, по 2 рабочих процесса на каждый из 3 рабочих серверов). При этом обслуживанием одной информационной базы будет заниматься 3 рабочих процесса на 3 рабочих серверах.
Необходимо настроить кластер серверов таким образом, чтобы информационную базу DemoDB обслуживал только рабочий сервер SRV3, а информационную базу WorkDBобслуживали оба рабочих сервера: SRV1 и SRV2. Для этого необходимо настроить следующие правила:
● Для рабочего сервера SRV3:
● Объект требования: Любой объект требования.
● Тип требования: Назначать.
● Имя ИБ: DemoDB.
● Значение дополнительного параметра: не указывается.
● Для рабочих серверов SRV1 и SRV2:
● Объект требования: Любой объект требования.
● Тип требования: Назначать.
● Имя ИБ: WorkDB.
● Значение дополнительного параметра: не указывается.
Указанные правила «разнесут» по рабочим серверам все механизмы кластера серверов: соединения, фоновые задания, сервисы сеансовых данных и т. д.
Необходимо настроить кластер серверов таким образом, чтобы на рабочем сервере SRV1 выполнялись только отчеты, на рабочем сервере SRV2 выполнялись только регламентные задания ОбновлениеИндексаППД и ОбновлениеАгрегатовПродаж, а остальные фоновые задания должны выполняться на рабочем сервере SRV3. Для этого необходимо настроить следующие правила:
● Для рабочего сервера SRV1:
● Требование:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.Report.
● Для рабочего сервера SRV2:
● Требование:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.CommonModule.РаботаСПолнотекстовымПоиском.ОбновлениеИндексаПолнотекстовогоПоиска.
● Требование:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.CommonModule.РегламентныеЗаданияАгрегатов.ОбновлениеАгрегатовПродаж.
homyaks1c.blogspot.com