В предыдущей статье о кластере сервера 1С мы рассмотрели основы их устройства и принципы работы. Сегодня мы углубимся в практику и разберем конкретные примеры настройки требований назначения функциональности в кластере. Эти примеры покажут, как гибко распределять нагрузку, управлять сервисами и фоновыми заданиями между рабочими серверами.
Исходная конфигурация кластера для примеров
Для наглядности все примеры будут базироваться на одном тестовом кластере со следующей структурой:
- рабочих серверов: 3 (TS01, TS02, LIC01);
- уровень отказоустойчивости: 0.
Рисунок 1 – Схема работы тестового стенда.
Пример 1: Выделенный сервер для сервиса лицензирования (LIC01) и отказоустойчивый кластер (TS01,TS02)
Задача: разместить сервис лицензирования только на LIC01 и запретить запуск на нем любых других сервисов кластера. Это актуально, если лицензия активирована для этого конкретного сервера. В дополнение, сделаем TS01 основным сервером и TS02 резервным, чтобы второй сервер работал только в случае отказа первого.
Решение: В свойствах рабочего сервера LIC01 создайте два требования:
Требование 1 (Разрешающее):
Объект требования: Сервис лицензирования Тип требования: Назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать)
Требование 2 (Запрещающее):
Объект требования: Любой объект требования Тип требования: Не назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать)
Рисунок 2 – Настройка требований для кластера 1С (сервер лицензирования).
В свойствах рабочего сервера TS01 создайте требование с приоритетом 2:
Объект требования: Клиентское соединение с ИБ Тип требования: Назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать) Приоритет: 2
Рисунок 3 – Настройка требований для кластера 1С (TS01).
В свойствах рабочего сервера TS02 создайте два требования:
Объект требования: Клиентское соединение с ИБ Тип требования: Назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать) Приоритет: 1
Рисунок 4 – Настройка требований для кластера 1С (TS02).
Результат: на LIC01 будет работать только сервис лицензирования. На TS01 будут идти все соединения с базой и фоновые задачи, а в случае отказа они пойдут на сервер TS02.
Важно: при активации программной лицензии через сервер 1С обязательно указывайте имя LIC01, иначе кластер не сможет использовать эту лицензию.
Пример 2: Концентрация всех фоновых заданий на одном сервере (TS01)
Задача: направить выполнение всех фоновых заданий кластера исключительно на рабочий сервер TS01.
Решение:
В консоли кластера перейдите к свойствам рабочего сервера TS01. Создайте новое требование назначения функциональности:
Объект требования: Клиентское соединение с ИБ Тип требования: Назначать Имя ИБ: (Не указывать) Значение доп. параметра: BackgroundJob.CommonModule
Рисунок 5 – Концентрация всех фоновых заданий на одном сервере.
Результат: Все фоновые задания будут запускаться только на TS01.
Пример 3: Ограничение сервиса работы с внешними источниками данных
Задача: разрешить работу сервиса внешних источников данных (ВИД) на TS01 и TS02, но запретить его на LIC01.
Решение:
В свойствах рабочего сервера LIC01 создайте требование:
Объект требования: Сервис работы с внешними источниками данных Тип требования: Не назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать)
Рисунок 6 – Ограничение сервиса работы с внешними источниками данных.
Результат: Сервис ВИД будет отключен на LIC01 и доступен на TS01 и TS02.
Пример 4: Один рабочий процесс = одна информационная база
Задача: настроить кластер так, чтобы каждый запущенный рабочий процесс обслуживал строго одну информационную базу. Это может повысить стабильность и предсказуемость.
Решение:
Для каждого рабочего сервера (TS01, TS02, TS03) в его свойствах найдите параметр Количество ИБ на процесс. Установите значение этого параметра равным 1.
Рисунок 7 – Настройка обслуживания рабочим процессом 1С одной БД.
Результат: на каждом из 3-х рабочих серверов будет запущено по 2 рабочих процесса (итого 6). Каждая ИБ (DemoDB и WorkDB) будет обслуживаться тремя рабочими процессами – по одному на каждом сервере.
Пример 5: Закрепление ИБ за конкретными рабочими серверами
Задача: настроить кластер так, чтобы: ИБ DemoDB обслуживалась только сервером TS01. ИБ WorkDB обслуживалась только сервером TS02.
Решение:
Для TS01 создайте требование:
Объект требования: Любой объект требования Тип требования: Назначать Имя ИБ: DemoDB Значение доп. параметра: (Не указывать)
Рисунок 8 – Закрепление ИБ за конкретным рабочим сервером TS01.
Для TS02 создайте требование:
Объект требования: Любой объект требования Тип требования: Назначать Имя ИБ: WorkDB Значение доп. параметра: (Не указывать)
Рисунок 9 – Закрепление ИБ за конкретным рабочим сервером TS02.
Результат: Весь трафик (соединения, фоновые задания, сервисы данных), связанный с DemoDB, будет идти только через TS01, а трафик WorkDB будет обрабатываться на TS02.
Пример 6: Глобальный запрет сервиса “Дата акселератора”
Задача: полностью отключить использование сервиса “Дата акселератора” на всех рабочих серверах кластера.
Решение (Для кластера с >1 рабочего сервера):
На любом одном рабочем сервере (например, TS01) создайте ДВА требования В СТРОГОМ ПОРЯДКЕ:
Требование 1 (Базовое разрешение):
Объект требований: Любой объект требований Тип требования: Назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать)
Требование 2 (Запрет акселератора):
Объект требований: Сервис Дата акселератора Тип требований: Не назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать)
Рисунок 10 – Отключение использования сервиса “Дата акселератора”.
Если у вас вдруг объекты не по порядку, то необходимо повысить/понизить приоритет, щелкнув ПКМ по объекту:
Рисунок 11 – Отключение использования сервиса “Дата акселератора”.
На каждом из ОСТАВШИХСЯ рабочих серверов (TS02, LIC01) cоздайте требование:
Объект требований: Сервис Дата акселератора Тип требований: Не назначать Имя ИБ: (Не указывать) Значение доп. параметра: (Не указывать)
Решение (Для кластера с ОДНИМ рабочим сервером):
На этом единственном сервере создайте строго в таком порядке:
Требование 1: Любой объект требований -> Назначать Требование 2: Сервис Дата акселератора -> Не назначать
Механизм требований не позволяет применить только запрет (Не назначать) без базового разрешающего правила (Назначать), особенно на сервере, где нет других явных разрешений. Порядок важен, так как правила обрабатываются сверху вниз.
Результат: сервис “Дата акселератора” будет отключен во всем кластере.
Всегда применяйте изменения после настройки требований.
Рисунок 12 – Применение изменений для тербований кластера 1С.
Заключение
Эти примеры наглядно демонстрируют мощь и гибкость механизма требований назначения функциональности в кластерах серверов 1С. С его помощью можно:
- эффективно распределять нагрузку между серверами;
- изолировать критичные сервисы (лицензирование);
- управлять выполнением фоновых и регламентных заданий с высокой точностью;
- закреплять информационные базы за конкретными серверами;
- отключать нежелательные функциональности (Date Accelerator).
Обеспечьте бесперебойную работу 1С с нашей услугой аренда кластера серверов 1С и аренда катастрофоустойчивой 1С! Также возможны разовые проектные работы.
