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

Опубликовал Two World (Prometeus2011) в раздел Администрирование - Системное

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

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

  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.2017.

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

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

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

Скачать файлы

Наименование Файл Версия Размер
Сервис и база с преднастройками_27.01.2017
.rar 609,28Kb
27.01.17
1
.rar 609,28Kb 1 Скачать

См. также

PowerTools от 1 000
Добавить вознаграждение
Комментарии
1. probot (Probot1c) 04.02.17 06:37 Сейчас в теме
Интересно, влияют ли временный задержки (ping) клиента, скорость подключения и другие параметры на выбор нужного сервера?
2. Two World (Prometeus2011) 30 05.02.17 11:14 Сейчас в теме
(1)В общем, конечно. Используется фрейморк, следовательно, будет все работать, как реализовано в библиотеках фреймворка, согласно тех. документации Майкрософт. Вот пинг, например, ждет ответа 5 секунд (https://msdn.microsoft.com/ru-ru/library/hb7xxkfx(v=vs.110).aspx).
Но.
1. Пинг вообще можно отключить, тогда проверка доступности через сокет-соединение вообще происходит мгновенно (есть, конечно нюансы...).
2. Если из 10 серверов 4 первых не работают (проверка их доступности занимает много времени), то тут надо не программу допиливать, а менять что-то в жизни:).