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

Цели, поставленные при разработке системы.

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

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

Программные требования.

1. Установленная платформа 1с-предприятие, версии 8.3.8 и старше. В клиент-серверном или файловом (не тестировалось) варианте.
2. Веб-сервер Apach или IIS (не тестировалось).
3. .Net 4.0.

Как это работает для пользователя.

Пользователю выгружается из конфигурации «Арбитр» и передается только один единственный исполняемый файл — клиентское приложение. Файл надо запустить, ввести туда (однократно) свои учетные данные и пользователь будет подключен к наименее загруженному доступному терминальному серверу с настройками, которые определил администратор системы.

Как это устроено.

1. Арбитр подключений.

В основе лежит конфигурация 1с «Арбитр подключений» с http-сервисом «RDP_Director» для передачи информации о доступных «Подключениях» клиентскому приложению, а также настроек для установки RDP-сеанса (штатный набор параметров для программы mstsc.exe). «Подключение» представляет из себя пару IP:PORT.

Арбитр  хранит в себе такие данные

1. Существующие РДП-серверы, каждому из которых сопоставлены все возможные подключения (пары IP:PORT). Допустим, есть 2 резервных канала: 31.7.1.1 и 82.7.1.1, а также 2 терминальных сервера: Srv1 (на порту 4040) и Srv2 (на порту 4041). Соответственно, будет 4 возможных подключения:

NETBIOS имя	Канал	Проброшенный порт	Подключение
Srv1	31.7.1.1	4040	31.7.1.1:4040
Srv1	82.7.1.1	4040	82.7.1.1:4040
Srv2	31.7.1.1	4041	31.7.1.1:4041
Srv2	82.7.1.1	4041	82.7.1.1:4041

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

NETBIOS имя	Канал	Проброшенный порт	Подключение	Приоритет
Srv1	31.7.1.1	4040	31.7.1.1:4040	1
Srv1	82.7.1.1	4040	82.7.1.1:4040	0
Srv2	31.7.1.1	4041	31.7.1.1:4041	1
Srv2	82.7.1.1	4041	82.7.1.1:4041	0

Т.е. видно, что канал 31.7.1.1 является основным, а 82.7.1.1 — резервным.

3.Сведения о пользователях, паролях и доступных для них подключениях:

NETBIOS имя	Канал	Проброшенный порт	Подключение	Приоритет	Пользователь
Srv1	31.7.1.1	4040	31.7.1.1:4040	1	Иванов
Srv1	82.7.1.1	4040	82.7.1.1:4040	0	Иванов
Srv2	31.7.1.1	4041	31.7.1.1:4041	1	Иванов
Srv2	82.7.1.1	4041	82.7.1.1:4041	0	Иванов
Srv1	31.7.1.1	4040	31.7.1.1:4040	1	Петров
Srv1	82.7.1.1	4040	82.7.1.1:4040	0	Петров

Т.е. для пользователя Иванов доступны все каналы и все серверы, а для пользователя Петров только 1 сервер, но через любой канал. Можно исключить использование некоторыми пользователями резервного канала, если его пропускная способность ограничена, а при аварии требуется сохранить доступ к серверам лишь ограниченному кругу ключевых терминальных клиентов.Учетные пары (логин/пароль) для авторизации пользователей на всех терминальных серверах и в Системе должны совпадать.

4. При наличии запущенных Служб на терминальных серверах, Арбитр содержит сведения о степени загруженности каждого из них. Здесь сразу уточню понятие «степень загруженности». В нашей Организации пользователи на серверах выполняют примерно одинаковые задачи, а значит, уровень загрузки сервера можно определить исходя из количества авторизованных на нем пользователей. Впрочем, при некоторых несложных дописках Службы,  достаточно просто реализовать более продвинутую аналитику загруженности (и др. параметров) терминальных серверов.

NETBIOS имя	Канал	Проброшенный порт	Подключение	Приоритет	Пользователь	Авторизовано
Srv1	31.7.1.1	4040	31.7.1.1:4040	1	Иванов	80
Srv1	82.7.1.1	4040	82.7.1.1:4040	0	Иванов	80
Srv2	31.7.1.1	4041	31.7.1.1:4041	1	Иванов	90
Srv2	82.7.1.1	4041	82.7.1.1:4041	0	Иванов	90
Srv1	31.7.1.1	4040	31.7.1.1:4040	1	Петров	80
Srv1	82.7.1.1	4040	82.7.1.1:4040	0	Петров	80

Данные о состоянии терминальных серверов, передаваемые Службами, запущенными на терминальных серверах, принимаются Арбитром через второй -сервис «ServStatusPort».Таким образом, при запросе на подключение пользователя «Иванов», запушеному им клиенту Арбитром будет возвращен такой список возможных подключений:

Srv1	31.7.1.1	4040	31.7.1.1:4040	1	Иванов	80
Srv1	82.7.1.1	4040	82.7.1.1:4040	0	Иванов	80
Srv2	31.7.1.1	4041	31.7.1.1:4041	1	Иванов	90
Srv2	82.7.1.1	4041	82.7.1.1:4041	0	Иванов	90

5. Арбитр содержит настройки подключения к терминальным серверам. Они индивидуальны для пар IP:PORT.

6. Двоичный образ клиента для подключения к терминальным серверам. Клиент выгружается в любое место как файл, может быть отправлен по почте (пока не реализовал), либо на ФТП (не реализовал пока). В момент выгрузки образ патчится в части корректировки ресурсов: устанавливается список пар ЙП:ПОРТ по которым можно подключиться к сервисам — Арбитрам. Всего пар может быть до 5 штук.

2. Клиент пользователя. Это небольшое приложение, на C#, отправляемое конечному пользователю.

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

3. Служба контроля загруженности терминального сервера.

Небольшая win-32 служба, написанная на C#, устанавливается на все терминальные сервера для сбора данных об их состоянии. Раз в секунду осуществляется подключение к Арбитрам, перечисленным в файле «settings.ini» и передает им информацию о состоянии сервера. Установка: стандартный скрипт установки «RDPStatusProviderSetup.msi».

После установки необходимо дополнительно:

1. Определить пользователя, от имени которого будет происходить запуск службы (д.б. административные права на реестр сервера + сетевые права).

2. В файле «settings.ini», расположенном в директории образа службы («C:Program Files (x86)RDPStatusProvider») указать адреса всех Арбитров, какие используются в Системе.

3. Запустить службу (однократно) или перезагрузить сервер.

4. Порядок развертки системы

1. Ставится веб-сервер (Апач, IIS…).

2. Разворачивается прилагаемая конфигурация «Арбитр», публикуются и проверяются на доступность  оба http-сервиса из конфигурации: «RDP_Director» и «ServStatusPort».

Путь к сервису «RDP_Director» должен быть: «http://» + IP:PORT + «/RDP_Director/hs/RDP_Director».

Путь к сервису «ServStatusPort» должен быть: «http://» + IP:PORT + «/RDP_Director/hs/ServStatusPort».

3. На все терминальные сервера ставится служба «RDPStatusProvider», которая контролирует их состояние (Не обязательно. Без службы подключение клиентов будет производится согласно приоритетам, установленным вручную, без автоматического анализа загруженности терминальных серверов). При запуске служб на каждом из серверов, сервер автоматически будет добавляться в справочник «серверы» конфигурации «Арбитр».

4. В справочник «Пользователи» конфигурации «Арбитр» заносятся пользователи терминальных серверов с их учетными записями, совпадающими с учетными записями на терминальных серверах (состав пользователей и их учетные данные должны быть синхронны на всех серверах и в конфигурации «Арбитр»). ВАЖНО: пользователи заносятся НЕ В УЧЕТНЫЕ ЗАПИСИ ДОСТУПА К ИНФОРМАЦИОННОЙ БАЗЕ (ТАМ ВСЕГО 2 ПОЛЬЗОВАТЕЛЯ – привилегированный пользователь и пользователь для передачи и получения данных, а в справочник «Пользователи». Пользователя «CommonLogin» для доступа к ИБ переименовывать и удалять нельзя (пароль тоже) (он используются в службе и клиенте).

5. Заполняется справочники «Арбитры», «Интерфейсы», «Подключения». В общем-то там все интуитивно понятно, как их заполнять.

6. Для каждого из пользователей выгружается клиент – исполняемый файл и передается пользователю.

Планируемые доработки:

1. Шифрование данных, передаваемых на Арбитр и получаемых от него.

2. Дописать развернутую диагностику работы службы сбора статистики работы терм. серверов.

3. Реализация различных способов отправки клиентов пользователям.

4. Много чего можно улучшить/автоматизировать, чтобы упростить развертку системы.

5. Планируется разработка Арбитра как самостоятельного сервиса.

Исправления:

1. От 27.01.2024.

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

1.2. Ввел реквизит «комментарий» в справочник подключений.

P.S. При проблемах с разверткой — пишите в комментарии.