Организация территориально-распределенной архитектуры системы DIRECTUM

15 1

В прошлых сезонах сериала

Remoteapp  

DCI 5.5

DICS vs. Репликация  

DCI 5.6

Вводное

Многие современные компании имеют географически распределенную структуру или крупную партнерскую сеть, с которой необходимо выстроить взаимодействие по бизнес-процессам. В этой статье рассмотрим возможности системы DIRECTUM, которые позволят организовать такое взаимодействие.
Следуя этим рекомендациям, можно организовать надёжный и эффективно управляемый ландшафт системы
.

Рассмотрим три варианта:

  1. Единая база данных. Территориально-удаленные пользователи работают в системе через веб-доступ.
  2. Единая база данных. Территориально-удаленные пользователи работают в системе через терминальный сервер.
  3. Несколько баз данных. У территориально-удаленных организаций свои БД, у головной организации так же отдельная БД.   

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

Особенности использования веб-доступа: 

  • общие бизнес-процессы, необходимо хранение данных в одной БД, единая точка входа обслуживания инфраструктуры;
  • веб-клиент менее требователен к аппаратным ресурсам на рабочих местах, чем desktop-клиент;
  • настраиваемый интерфейс веб-клиента;
  • подходит для сотрудников с разъездным характером работы.

Особенности использования терминального сервера:

  • общие бизнес-процессы, необходимо хранение данных в одной БД, единая точка входа обслуживания инфраструктуры;
  • есть необходимость использования полного интерфейса desktop-клиента. Настроена локальная интеграция с другими ИС;
  • менее требователен к аппаратным ресурсам на клиентских рабочих местах, чем desktop-клиент.

 

Механизмы для взаимодействия с несколькими базами данных рекомендуются в ситуациях:

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

Об основных преимуществах и недостатках каждой из рекомендаций я расскажу ниже.

Рекомендации

Единая база данных. Территориально-удаленные пользователи работают в системе через веб-доступ: 

Для работы требуется настроить доступ из сети интернет. Существует возможность настройки соединения через протокол https. Такая архитектура требует от администратора наличия хороших компетенций в области настройки и администрирования веб-ферм, потому что в такой архитектуре сервера веб-доступа будут являться высоконагруженным узлом наравне с сервером СУБД.

Плюсы:

  1. Не требует больших аппаратных ресурсов от рабочего места пользователя системы DIRECTUM.
  2. Нет необходимости локальной установки desktop-клиента системы DIRECTUM на рабочие места пользователей. Простота в администрировании рабочих мест пользователя.
  3. Низкие требования к пропускной способности каналов связи, централизация сетевого трафика.
  4. Возможно изменение интерфейса под нужды пользователя путем доработки веб-модулей.

Минусы:

  1. В веб-клиенте доступна не вся функциональность desktop-клиента. Подробнее об ограничениях работы веб-доступа можно почитать в документации, которая идет с поставкой системы. Документ называется: «DIRECTUM 5.х. Ограничения веб-доступа».
  2. Непростая настройка веб-фермы, организация NLB-кластера для соответствия признаку высокой доступности и масштабируемости.
  3. Зависимость сетевого трафика клиент-сервер от объема обрабатываемых данных.
  4. Если в толстом клиенте были какие-то доработки в прикладной части модулей, то для того чтобы эта прикладная работала и в веб-доступе необходима её адаптация.

Архитектура:

  
 

SAN

SAN (Storage Area Network) Сеть хранения данных — предназначена для консолидации дискового пространства серверов на специально выделенных дисковых хранилищах. При использовании сети хранения данных дисковые ресурсы используются экономнее, легче управляются и имеют большую производительность.

Кластер СУБД

Для обеспечения надежной работы системы DIRECTUM необходимо создать активный кластер, который позволит обеспечить отказоустойчивое функционирование СУБД.

Кластер состоит из 2 узлов:  

  • узел №1, где установлен активный экземпляр СУБД;
  • узел №2, где находится пассивный экземпляр СУБД.

Если возникнет сбой и активный узел перестанет работать, работа приложения будет автоматически переведена на второй узел. Это обеспечивает отказоустойчивое предоставление доступа к системе DIRECTUM в любое время, в том числе в течение времени восстановления сбойного узла кластера.

Веб-ферма серверов доступа к системе DIRECTUM и кластер балансировки нагрузки сетевого трафика

Для обеспечения высокой доступности сервиса веб-доступа к системе DIRECTUM необходимо объединить физические или виртуальные серверы веб-доступа в ферму веб-серверов на базе IIS. Инсталляция работает в режиме распределения нагрузки за счет использования кластера балансировки нагрузки сетевого трафика.

Серверам веб-доступа необходимо обеспечить высокую отказоустойчивость и масштабируемость. Мы рекомендуем использовать для этого связку технологий NLB кластера + ARR фермой серверов веб-доступа. В случае отказа одного из серверов, его пользовательская нагрузка перераспределится между остальными серверами фермы.  

Виртуальный сервер служб DIRECTUM

Для увеличения масштабируемости и доступности сервисных служб необходимо вынести службы за кластер и развернуть их на отдельных виртуальных машинах.

Единая база данных. Территориально-удаленные пользователи работают в системе через терминальный сервер 

Плюсы:

  1. Не требует больших аппаратных ресурсов от рабочего места пользователя системы DIRECTUM.
  2. Нет необходимости локальной установки desktop-клиента системы DIRECTUM на рабочие места пользователей. Простота в администрировании рабочих мест пользователя.
  3. Требования к пропускной способности каналов связи ниже, чем для desktop-клиента.
  4. Отсутствие зависимости сетевого трафика клиент-сервер от объема обрабатываемых данных.
  5. Полная функциональность и привычный интерфейс при доступе из сети Интернет.
  6. Удобное обновление клиентской части.

Минусы:

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

Архитектура:

Ферма терминальных серверов

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

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

Несколько баз данных. У территориально-удаленных организаций свои БД, у головной организации также отдельная БД

Для данного типа рекомендаций мы можем предложить сразу несколько вариантов организации архитектуры работы системы DIRECTUM. Поэтому я выделю такой тип рекомендаций в отдельный раздел. Не забывая про тот критерий, который я привел в своем вводном слове – простота в управлении архитектурой.   

В общем виде схему взаимодействия систем DIRECTUM можно представить, например, так: 


 

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

Далее сюжет нашего сериала разворачивается таким образом, что возникает потребность в организации передачи и синхронизации каких-то данных между этими системами DIRECTUM, построении общих бизнес-процессов. О том, с помощью каких наших сервисов это можно сделать, я буду вести повествование в следующем разделе. 

Службы взаимодействия систем DIRECTUM Intersystem Cooperation Services (DICS)

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

Плюсы:

  1. При передаче данных синхронизируется и передается только необходимая часть данных, в рамках бизнес-процессов.
  2. Конфликты при передаче и синхронизации данных в другие системы можно устранять на прикладном уровне.
  3. Отсутствует необходимость обновления в тандеме. Т.е. если обновилась версия одной системы, то не обязательно нужно обновлять другую территориально-удаленную систему DIRECTUM. 
  4. Масштабируемый сервис, в котором добавление новой системы для взаимодействия несильно влияет на производительность других систем.

Минусы:

  1. Нет возможности настроить полную синхронизацию данных, когда это необходимо. 
  2. Необходимо устранять конфликты при передаче и синхронизации данных в другие системы.
  3. Трудоемкая и тягучая настройка правил для синхронизации нормативно-справочной информации.

Механизмы межсистемного взаимодействия 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. Об остальных изменениях, особенностях и сравнениях с другими инструментами можно узнать в этой и вот этой сериях прошлого сезона.

Плюсы:

  1. Решение соединяет уже существующие в компаниях бизнес-процессы в единый сквозной бизнес-процесс.
  2. Инструмент разработки. Разработчик использует готовые средства для связывания систем. Это позволяет ему сфокусироваться на бизнес-логике, не отвлекаясь на инфраструктуру.
  3. Нет ограничений по размеру передаваемых данных.
  4. Есть возможность масштабирования каждого из сервисов DCI, т.к. он состоит из отдельных специализированных сервисов, каждый из которых делает свою работу.
  5. Шифрование трафика и аутентификация на сервисах по сертификатам уже используются в решении. Чтобы обезопасить локальную сеть, транспорт DCI может быть размещен в демилитаризованной зоне (ДМЗ). В этом случае он отвечает на запросы из внешней сети, но не отправляет запросы в локальную.
  6. Инструмент администрирования. В предыдущих версиях DCI управление процессами и сообщениями велось через справочники DIRECTUM. Теперь управление процессами и сообщениями реализовано универсально для всех систем – через сайт адаптера к бизнес-приложению. Это означает, что логику хранения и управления теперь не надо реализовывать при подключении разных систем.

Минусы:

  1. Относительно высокие аппаратные требования для развертывания сервисов DCI на одном сервере по сравнению с тем же DICS. Рекомендуется разворачивать сервисы на разных серверах.
  2. На момент написания данной статьи отсутствует готовый и протестированный адаптер для подключения к DirectumRX и остальным СЭД.
  3. Работа с версиями системы DIRECTUM 5.4 и выше.

Схема взаимодействия двух систем DIRECTUM:


 

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


 

В заключение

У вас волчанка админка © 

В статье я преследовал цель систематизирования того опыта и знаний, который накопился внутри нашей компании и лично у меня с проектов внедрения, пресейла. И да, в этой статье приведены не все рекомендации и возможности нашей системы по организации территориально-распределенной архитектуры. Иначе это был бы долгий и скучный лонгрид, вероятность запутаться в котором составляла бы 90%. Но на то он и сериал, чтобы следить за дальнейшим развитием событий и ждать выхода новых серий.
Оставляйте ваши вопросы и пожелания в комментариях под статьей!

Антон Гончаров

На схеме терминальных серверов утеряна роль RD Connection Broker, которая может быть размещена, как на серверах сеансов, так и на отдельных выделенных серверах(2 и  более, работающие в режиме активный/активный). 
Именно RD Connection Broker реализует распределение нагрузки между хостами сеансов. 

Авторизуйтесь, чтобы написать комментарий