ЛР4_1С_83_тонкий_и_WEB-клиент (1031817), страница 6

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Более подробно рассмотрим алгоритм назначения рабочего сервера для обслуживания сервиса кластера.

Для сервисов кластера (см. здесь) объектом требования может выступать:

• ● Сервис одного типа, если сервис не делится по информационным базам.

• ● Сервис одного типа для одной информационной базы, если сервис делится по информационным базам.

• ● Сервис сеансовых данных.

• ● Сервис лицензирования.

Сервисы распределяются между подходящими рабочими серверами следующим образом:

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

• ● Среди отобранных рабочих серверов сервисы распределяются равномерно.

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

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

• ● Для каждого сеанса, который обслуживает кластер серверов, создается свой экземпляр сервиса сеансовых данных. При отборе рабочих серверов, которые могут обслужить данный экземпляр сервиса, учитываются дополнительные параметры требования. Из списка доступных выбираются сервера с минимальным количеством обслуживаемых сервисов кластера. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь).

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

• ● Остальные сервисы назначаются в единственном экземпляре.

Переназначение сервисов кластера между рабочими серверами может выполняться в следующих случаях:

• ● При добавлении рабочего сервера выполняется частичное переназначение сервисов. Данное переназначение выполняется автоматически.

• ● При удалении рабочего сервера из состава кластера или недоступности рабочего сервера выполняется переназначение только тех объектов требований, которые обслуживал удаляемый рабочий сервер. Данное переназначение выполняется автоматически.

• ● При удалении или добавлении информационной базы в кластер выполняется частичное переназначение. Данное переназначение выполняется автоматически.

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

1.7.3.3. Назначение рабочих процессов

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

Установка соединения клиентского приложения с кластером серверов «1С:Предприятия» выполняется по следующим правилам:

• ● В соответствии с требованиями назначения и ограничениями по использованию оперативной памяти отбирается необходимый рабочий сервер.

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

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

• ● Для рабочего процесса не достигнуто максимальное количество обслуживаемых информационных баз (свойство рабочего сервера Количество ИБ на процесс).

• ● Для рабочего процесса не достигнуто максимальное количество обслуживаемых соединений (свойство рабочего сервера Количество соединений на процесс).

• ● Рабочий процесс не находится в состоянии подготовки к автоматическому перезапуску.

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

• ● Если не удалось выбрать ни один рабочий процесс, то на данном рабочем сервере запускается новый рабочий процесс, который и будет обслуживать запрошенное соединение.

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

Если на одном рабочем сервере в течении 20 минут существуют 2 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.

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

1.7.4. Примеры управления кластером

При рассмотрении примеров требований назначений функциональности будет использоваться следующий кластер серверов:

Рис. 10. Кластер для примеров требований

Кластер обладает следующими характеристиками:

• ● Количество рабочих серверов: 3.

• ● Уровень отказоустойчивости: 1.

• ● Количество центральных серверов: 2 (SRV1, SRV2).

• ● Операционные системы на рабочих серверах:

• ● Сервер SRV1, ОС Windows.

• ● Сервер SRV2, ОС Linux.

• ● Сервер SRV3, ОС Windows.

Кластер обслуживает следующие информационные базы:

• ● DemoDB,

• ● WorkDB.

ВНИМАНИЕ! Приведенные ниже примеры не являются законченными решениями какой-либо проблемы, а служат только для демонстрации принципов работы механизма размещения объектов требований по рабочим серверам в кластере.

1.7.4.1. Размещение всех фоновых заданий на одном рабочем сервере

Если необходимо разместить все фоновые задания на рабочем сервере SRV1, то для этого необходимо для рабочего сервера SRV1 задать следующее требование назначения функциональности:

• ● Объект требования: Клиентское соединение с ИБ.

• ● Тип требования: Назначать.

• ● Имя ИБ: не указывается.

• ● Значение дополнительного параметра: BackgroundJob.CommonModule.

1.7.4.2. Размещение сервиса лицензирования на выделенном рабочем сервере

Необходимо многопользовательскую клиентскую лицензию активировать для компьютера, на котором функционирует рабочий сервер SRV2 и разместить на этот компьютер сервис лицензирования. Тогда для рабочего сервера SRV2 следует указать следующее требование:

• ● Объект требования: Сервис лицензирования.

• ● Тип требования: Назначать.

• ● Имя ИБ: не указывается.

• ● Значение дополнительного параметра: не указывается.

При этом при активации программной лицензии с помощью сервера «1С:Предприятия» следует указывать имя SRV2, в противном случае активированная лицензия не сможет быть использована кластером серверов, т. к. программная лицензия будет активирована для другого компьютера.

1.7.4.3. Запрет размещения сервиса работы с внешними источниками данных на одном рабочем сервере

Необходимо разрешить работу сервиса работы с внешними источниками данных на рабочих серверах SRV1 и SRV3, и запретить – на рабочем сервере SRV2. Для этого следует для рабочего сервера SRV2 указать следующее требование:

• ● Объект требования: Сервис работы с внешними источниками данных.

• ● Тип требования: Не назначать.

• ● Имя ИБ: не указывается.

• ● Значение дополнительного параметра: не указывается.

1.7.4.4. Один рабочий процесс обслуживает одну информационную базу

Необходимо настроить кластер серверов таким образом, чтобы каждая информационная база обслуживалась одним рабочим процессом. Для этого необходимо для каждого рабочего сервера установить свойство Количество ИБ на процесс в значение 1.

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

1.7.4.5. Назначение рабочих серверов для обслуживания выбранных информационных баз

Необходимо настроить кластер серверов таким образом, чтобы информационную базу DemoDB обслуживал только рабочий сервер SRV3, а информационную базу WorkDBобслуживали оба рабочих сервера: SRV1 и SRV2. Для этого необходимо настроить следующие правила:

• ● Для рабочего сервера SRV3:

• ● Объект требования: Любой объект требования.

• ● Тип требования: Назначать.

• ● Имя ИБ: DemoDB.

• ● Значение дополнительного параметра: не указывается.

• ● Для рабочих серверов SRV1 и SRV2:

• ● Объект требования: Любой объект требования.

• ● Тип требования: Назначать.

• ● Имя ИБ: WorkDB.

• ● Значение дополнительного параметра: не указывается.

Указанные правила «разнесут» по рабочим серверам все механизмы кластера серверов: соединения, фоновые задания, сервисы сеансовых данных и т. д.

1.7.4.6. Назначение конкретных фоновых заданий на конкретный рабочий сервер

Необходимо настроить кластер серверов таким образом, чтобы на рабочем сервере SRV1 выполнялись только отчеты, на рабочем сервере SRV2 выполнялись только регламентные задания ОбновлениеИндексаППД и ОбновлениеАгрегатовПродаж, а остальные фоновые задания должны выполняться на рабочем сервере SRV3. Для этого необходимо настроить следующие правила:

• ● Для рабочего сервера SRV1:

• ● Требование:

• ● Объект требования: Клиентское соединение с ИБ.

• ● Тип требования: Назначать.

• ● Имя ИБ: не указывается.

• ● Значение дополнительного параметра: BackgroundJob.Report.

• ● Для рабочего сервера SRV2:

• ● Требование:

• ● Объект требования: Клиентское соединение с ИБ.

• ● Тип требования: Назначать.

• ● Имя ИБ: не указывается.

• ● Значение дополнительного параметра: BackgroundJob.CommonModule.РаботаСПолнотекстовымПоиском.ОбновлениеИндексаПолнотекстовогоПоиска.

• ● Требование:

• ● Объект требования: Клиентское соединение с ИБ.

• ● Тип требования: Назначать.

• ● Имя ИБ: не указывается.

• ● Значение дополнительного параметра: BackgroundJob.CommonModule.РегламентныеЗаданияАгрегатов.ОбновлениеАгрегатовПродаж.

1.8. Профили безопасности

Работающее прикладное решение может использовать для своих нужд различные внешние ресурсы: каталоги файловой системы, COM-объекты (на Windows-системах), внешние компоненты, приложения ОС и т. д. Однако, по соображениям безопасности, для различных прикладных решений могут быть доступны не все возможные внешние ресурсы, а только ограниченное их подмножество. Может потребоваться создать собственный каталог временных файлов для каждой области разделенной информационной базы или задать перечень ресурсов сети Интернет, к которым может иметь доступ прикладное решение.

Характеристики

Список файлов книги