В прошлых сезонах сериала
Remoteapp
DCI 5.5
DICS vs. Репликация
DCI 5.6
Вводное
Многие современные компании имеют географически распределенную структуру или крупную партнерскую сеть, с которой необходимо выстроить взаимодействие по бизнес-процессам. В этой статье рассмотрим возможности системы DIRECTUM, которые позволят организовать такое взаимодействие.
Следуя этим рекомендациям, можно организовать надёжный и эффективно управляемый ландшафт системы.
Рассмотрим три варианта:
- Единая база данных. Территориально-удаленные пользователи работают в системе через веб-доступ.
- Единая база данных. Территориально-удаленные пользователи работают в системе через терминальный сервер.
- Несколько баз данных. У территориально-удаленных организаций свои БД, у головной организации так же отдельная БД.
Бывают случаи, когда первый и второй варианты используются совместно, чтобы нивелировать ограничения друг друга.
Особенности использования веб-доступа:
- общие бизнес-процессы, необходимо хранение данных в одной БД, единая точка входа обслуживания инфраструктуры;
- веб-клиент менее требователен к аппаратным ресурсам на рабочих местах, чем desktop-клиент;
- настраиваемый интерфейс веб-клиента;
- подходит для сотрудников с разъездным характером работы.
Особенности использования терминального сервера:
- общие бизнес-процессы, необходимо хранение данных в одной БД, единая точка входа обслуживания инфраструктуры;
- есть необходимость использования полного интерфейса desktop-клиента. Настроена локальная интеграция с другими ИС;
- менее требователен к аппаратным ресурсам на клиентских рабочих местах, чем desktop-клиент.
Механизмы для взаимодействия с несколькими базами данных рекомендуются в ситуациях:
- необходимость децентрализации. Разделение бизнес-процессов между организациями, партнерской сетью;
- необходимость работы в разных версиях системы DIRECTUM, с разной разработкой;
- имеется нестабильное подключение к интернету;
- присутствует большая разница в часовых поясах. Необходимость разделения операций обслуживания единой базы для разных групп пользователей.
Об основных преимуществах и недостатках каждой из рекомендаций я расскажу ниже.
Рекомендации
Единая база данных. Территориально-удаленные пользователи работают в системе через веб-доступ:
Для работы требуется настроить доступ из сети интернет. Существует возможность настройки соединения через протокол https. Такая архитектура требует от администратора наличия хороших компетенций в области настройки и администрирования веб-ферм, потому что в такой архитектуре сервера веб-доступа будут являться высоконагруженным узлом наравне с сервером СУБД.
Плюсы:
- Не требует больших аппаратных ресурсов от рабочего места пользователя системы DIRECTUM.
- Нет необходимости локальной установки desktop-клиента системы DIRECTUM на рабочие места пользователей. Простота в администрировании рабочих мест пользователя.
- Низкие требования к пропускной способности каналов связи, централизация сетевого трафика.
- Возможно изменение интерфейса под нужды пользователя путем доработки веб-модулей.
Минусы:
- В веб-клиенте доступна не вся функциональность desktop-клиента. Подробнее об ограничениях работы веб-доступа можно почитать в документации, которая идет с поставкой системы. Документ называется: «DIRECTUM 5.х. Ограничения веб-доступа».
- Непростая настройка веб-фермы, организация NLB-кластера для соответствия признаку высокой доступности и масштабируемости.
- Зависимость сетевого трафика клиент-сервер от объема обрабатываемых данных.
- Если в толстом клиенте были какие-то доработки в прикладной части модулей, то для того чтобы эта прикладная работала и в веб-доступе необходима её адаптация.
Архитектура:

SAN
SAN (Storage Area Network) — Сеть хранения данных — предназначена для консолидации дискового пространства серверов на специально выделенных дисковых хранилищах. При использовании сети хранения данных дисковые ресурсы используются экономнее, легче управляются и имеют большую производительность.
Кластер СУБД
Для обеспечения надежной работы системы DIRECTUM необходимо создать активный кластер, который позволит обеспечить отказоустойчивое функционирование СУБД.
Кластер состоит из 2 узлов:
- узел №1, где установлен активный экземпляр СУБД;
- узел №2, где находится пассивный экземпляр СУБД.
Если возникнет сбой и активный узел перестанет работать, работа приложения будет автоматически переведена на второй узел. Это обеспечивает отказоустойчивое предоставление доступа к системе DIRECTUM в любое время, в том числе в течение времени восстановления сбойного узла кластера.
Веб-ферма серверов доступа к системе DIRECTUM и кластер балансировки нагрузки сетевого трафика
Для обеспечения высокой доступности сервиса веб-доступа к системе DIRECTUM необходимо объединить физические или виртуальные серверы веб-доступа в ферму веб-серверов на базе IIS. Инсталляция работает в режиме распределения нагрузки за счет использования кластера балансировки нагрузки сетевого трафика.
Серверам веб-доступа необходимо обеспечить высокую отказоустойчивость и масштабируемость. Мы рекомендуем использовать для этого связку технологий NLB кластера + ARR фермой серверов веб-доступа. В случае отказа одного из серверов, его пользовательская нагрузка перераспределится между остальными серверами фермы.
Виртуальный сервер служб DIRECTUM
Для увеличения масштабируемости и доступности сервисных служб необходимо вынести службы за кластер и развернуть их на отдельных виртуальных машинах.
Единая база данных. Территориально-удаленные пользователи работают в системе через терминальный сервер
Плюсы:
- Не требует больших аппаратных ресурсов от рабочего места пользователя системы DIRECTUM.
- Нет необходимости локальной установки desktop-клиента системы DIRECTUM на рабочие места пользователей. Простота в администрировании рабочих мест пользователя.
- Требования к пропускной способности каналов связи ниже, чем для desktop-клиента.
- Отсутствие зависимости сетевого трафика клиент-сервер от объема обрабатываемых данных.
- Полная функциональность и привычный интерфейс при доступе из сети Интернет.
- Удобное обновление клиентской части.
Минусы:
- Настройка фермы терминальных серверов.
- Высокие требования к аппаратной части терминальных серверов.
- Возможно некорректное функционирование периферийных устройств (принтеры, сканеры).
- Покупка лицензии RDP – сессий.
Архитектура:

Ферма терминальных серверов
Для надежной и производительной работы удаленного доступа к системе DIRECTUM необходимо развернуть ферму терминальных серверов.
Терминальная ферма - это группа серверов, которые предназначены для предоставления удаленной рабочей среды (рабочего стола, приложений) пользователям, которые подключаются к ним с помощью программ-клиентов удаленного доступа.
Несколько баз данных. У территориально-удаленных организаций свои БД, у головной организации также отдельная БД
Для данного типа рекомендаций мы можем предложить сразу несколько вариантов организации архитектуры работы системы DIRECTUM. Поэтому я выделю такой тип рекомендаций в отдельный раздел. Не забывая про тот критерий, который я привел в своем вводном слове – простота в управлении архитектурой.
В общем виде схему взаимодействия систем DIRECTUM можно представить, например, так:

На схеме разными цветами выделены системы DIRECTUM, которые изначально никак не были связаны между собой. Они развернуты в разных организациях, имеют разное архитектурное построение системы DIRECTUM внутри каждой организации, разные версии системы, разную разработку, разные настройки.
Далее сюжет нашего сериала разворачивается таким образом, что возникает потребность в организации передачи и синхронизации каких-то данных между этими системами DIRECTUM, построении общих бизнес-процессов. О том, с помощью каких наших сервисов это можно сделать, я буду вести повествование в следующем разделе.
Службы взаимодействия систем DIRECTUM Intersystem Cooperation Services (DICS)
DICS – это механизм, который позволяет организовать взаимодействие и обмен информацией между системами DIRECTUM, которые абсолютно никак не связаны между собой изначально. Подробное описание механизма можно найти в справочной документации и в предыдущих сериях прошлого сезона.
Плюсы:
- При передаче данных синхронизируется и передается только необходимая часть данных, в рамках бизнес-процессов.
- Конфликты при передаче и синхронизации данных в другие системы можно устранять на прикладном уровне.
- Отсутствует необходимость обновления в тандеме. Т.е. если обновилась версия одной системы, то не обязательно нужно обновлять другую территориально-удаленную систему DIRECTUM.
- Масштабируемый сервис, в котором добавление новой системы для взаимодействия несильно влияет на производительность других систем.
Минусы:
- Нет возможности настроить полную синхронизацию данных, когда это необходимо.
- Необходимо устранять конфликты при передаче и синхронизации данных в другие системы.
- Трудоемкая и тягучая настройка правил для синхронизации нормативно-справочной информации.
Механизмы межсистемного взаимодействия DIRECTUM (DIRECTUM Cross-system Interaction Toolset, DCI)
Механизмы межсистемного взаимодействия DIRECTUM (DIRECTUM Cross-system Interaction Toolset, DCI) – решение для взаимодействия разных систем внутри одной группы компаний. Решение предназначено для крупных территориально и юридически распределенных предприятий с децентрализованной базой данных.
DCI – это наш новый продукт, который начал свое развитие с выходом системы DIRECTUM версии 5.5. Задачи, цели, позиционирование данного сервиса схожи с DICS, однако главное его отличие – это развитие инструментов подключения не только к системе DIRECTUM 5.x, но и к системе DIrectumRX, и к другим СЭД. Крутой фишкой продукта является Набор компонентов разработки (Software Development Toolkit, SDK), который упрощает взаимодействие с сервисом адаптера к бизнес-приложению и предоставляет единый API для подключаемой системы. SDK позволяет разрабатывать при помощи .NET и COM. Об остальных изменениях, особенностях и сравнениях с другими инструментами можно узнать в этой и вот этой сериях прошлого сезона.
Плюсы:
- Решение соединяет уже существующие в компаниях бизнес-процессы в единый сквозной бизнес-процесс.
- Инструмент разработки. Разработчик использует готовые средства для связывания систем. Это позволяет ему сфокусироваться на бизнес-логике, не отвлекаясь на инфраструктуру.
- Нет ограничений по размеру передаваемых данных.
- Есть возможность масштабирования каждого из сервисов DCI, т.к. он состоит из отдельных специализированных сервисов, каждый из которых делает свою работу.
- Шифрование трафика и аутентификация на сервисах по сертификатам уже используются в решении. Чтобы обезопасить локальную сеть, транспорт DCI может быть размещен в демилитаризованной зоне (ДМЗ). В этом случае он отвечает на запросы из внешней сети, но не отправляет запросы в локальную.
- Инструмент администрирования. В предыдущих версиях DCI управление процессами и сообщениями велось через справочники DIRECTUM. Теперь управление процессами и сообщениями реализовано универсально для всех систем – через сайт адаптера к бизнес-приложению. Это означает, что логику хранения и управления теперь не надо реализовывать при подключении разных систем.
Минусы:
- Относительно высокие аппаратные требования для развертывания сервисов DCI на одном сервере по сравнению с тем же DICS. Рекомендуется разворачивать сервисы на разных серверах.
- На момент написания данной статьи отсутствует готовый и протестированный адаптер для подключения к DirectumRX и остальным СЭД.
- Работа с версиями системы DIRECTUM 5.4 и выше.
Схема взаимодействия двух систем DIRECTUM:

DCI для связи внутри разных сетей:

В заключение
У вас волчанка админка ©
В статье я преследовал цель систематизирования того опыта и знаний, который накопился внутри нашей компании и лично у меня с проектов внедрения, пресейла. И да, в этой статье приведены не все рекомендации и возможности нашей системы по организации территориально-распределенной архитектуры. Иначе это был бы долгий и скучный лонгрид, вероятность запутаться в котором составляла бы 90%. Но на то он и сериал, чтобы следить за дальнейшим развитием событий и ждать выхода новых серий.
Оставляйте ваши вопросы и пожелания в комментариях под статьей!
На схеме терминальных серверов утеряна роль RD Connection Broker, которая может быть размещена, как на серверах сеансов, так и на отдельных выделенных серверах(2 и более, работающие в режиме активный/активный).
Именно RD Connection Broker реализует распределение нагрузки между хостами сеансов.
Авторизуйтесь, чтобы написать комментарий